Audio CD's tegelijk grabben?

[jsiegmund]

Ik heb 2 CD-rom station (1x DVD / 1x cd writer); is het mogelijk om van de 2 bronnen tegelijk te grabben naar HD? Heb nogal wat CD's die naar MP3 omgezet moeten worden, en met 2 stations zou dit wel mooi 2x zo snel gaan. Iemand een idee hierover?
Werk normaal met audiocatalyst, maar die kun je maar 1x tegelijk opstarten. Zijn er programma's met meerdere instances mogelijk? Moeten wel de mogelijkheid hebben om te archiveren naar album directory's e.d. en CDDB aan te spreken. Liefst eigenlijk een zelfde programma als catalyst omdat ik daar goed mee kan werken.

[ Voor 14% gewijzigd door jsiegmund op 08-12-2003 13:34 ]

[Verwijderd]

Ja, als jij het programma 2x kan starten kan dat gewoon, bijvoorbeeld Exact Audio Copy.

Een andere optie is om je geliefde programma vanuit een 2e directory te starten. Hierdoor heb je wel deze files dubbel staan, maar kun je het wel dubbel starten.

[ Voor 49% gewijzigd door Verwijderd op 08-12-2003 13:36 ]

[Xtremelead]

Ik heb even geen systeem met meerdere cd drives bij de hand, maar probeer het eens met EAC (ExactAudioCopy) zou ik zeggen.

te laat

[ Voor 7% gewijzigd door Xtremelead op 08-12-2003 13:37 . Reden: te laat ]

[Verwijderd]

exact audio copy is sowieso het beste ripprogramma (of grabber, net hoe je het wil noemen) dat er thans is, zeker in combinatie met lame mp3 (alt-preset standard). voor meer info, zie http://www.ping.be/satcp/cd2mp3.htm.

/edit: grammaticale fout.

[ Voor 7% gewijzigd door Verwijderd op 08-12-2003 13:40 ]

[deepbass909]

Ik doe het regelmatig met CDeX.

Houdt er alleen wel rekening mee dat de grootste rem op de extractie, je compressie stap is. Je zult je processor tijd met 2 compressies delen.

Bij mij betekend dat, dat audio extractie bijna 2 keer zolang duurt, en dat ik er dus eigenlijk geen tijdswinst mee haal.
Nu moet ik wel zeggen dat ik een AMD Duron 900 gebruik.

Als bij jou de processor niet de beperkende factor is, dan kan je best 2 extracties tegelijkertijd doen

[satcp]

Het is reeds een aantal maal vermeld, maar ik wil er nog wat informatie aan toevoegen.

Gebruik degelijke extractiesoftware: Exact Audio Copy. Dit programma gebruikt een geavanceerde leesmethode om leesfouten te herkennen en verbeteren. Bij andere programma's als AudioGrabber en AudioCatalyst heb je er maar het raden naar of er fouten zijn opgetreden... Wist je trouwens dat AudioCatalyst zowat de slechtste mp3-encoder aan boord heeft en een vreselijk slechte audio-extractie-engine? AudioCatalyst is niet in staat om leesfouten te detecteren, laat staan corrigeren. Je weet dus nooit zeker of je rip gelukt is. Dat je schijnbaar op het eerste zicht (oor?) niets hoort, wil niet zeggen dat er geen kleine leesfouten optraden. En dan word je nog verondersteld te betalen voor dit stukje baggersoftware. Met EAC is dat allemaal verleden tijd, je krijgt er tonnen functionaliteit bij en bovendien is EAC gratis. Wat meer kun je wensen?

Exact Audio Copy (EAC) vereist wel wat configuratiewerk, maar als je de Exact Audio Copy & LAME Snelstart Handleiding volgt, dan ben je binnen 10 minuten bezig aan je eerste kwaliteitsrip. De handleiding beschrijft eveneens het omzetten naar mp3 met de gratis, maar superieure LAME mp3 encoder.

Eens je EAC kent, dan zul je merken dat het programma veel gebruiksvriendelijker is dan bijvoorbeeld AudioCatalyst.

[jsiegmund]

Werkt goed, op de CDDB functie na. Met dat freedb ding vind ik mijn cd's niet, en cddb lukt me niet. Krijg elke keer bij elk server adres "Server error" te zien; waar kan dat aan liggen?

[Linchpin]

Even een andere server instellen bij de freedb-opties, de lijst met servers is te vinden op http://www.freedb.org/mod...s&sop=viewarticle&artid=9

[Tranquility]

Gewoon niet doen, Met dubbel rippen vergroot je alleen maar de kans op artifacten zoals tikjes in het geluid e.d. Zelfs EAC is dan niet meer feilloos. Als ik een CD rip doe ik gewoon op dat moment even niks anders met de computer. Het rippen van audio is gewoon een kritisch karweitje en kun je beter even wat tijd gunnen. Ik rip ook nooit op hoge snelheid, maar op zijn hoogst op 10 speed. Gewoon om er zeker van te zijn dat ik een 100% klasse rip verkrijg zonder bijgeluiden.

Je moet eens weten hoezeer ik mij groen en geel erger aan gedownloade mp3's van anderen met goeie muziek die later vol met tikken blijkt te zitten veroorzaakt door slecht rippen..

[ Voor 3% gewijzigd door Tranquility op 08-12-2003 15:25 ]

[satcp]

JazzySOB schreef op 08 december 2003 @ 15:24:
Gewoon niet doen, Met dubbel rippen vergroot je alleen maar de kans op artifacten zoals tikjes in het geluid e.d. Zelfs EAC is dan niet meer feilloos. Als ik een CD rip doe ik gewoon op dat moment even niks anders met de computer.

Waarom zou EAC dan niet meer feilloos werken? Ik heb in m'n testen geen enkel probleem ondervonden met simultaan rippen... Behalve dat het soms langer duurt om 2 cd's tegelijk naar mp3 om te zetten, dan wanneer je de cd's sequentieel inleest. Dit komt mogelijk door inefficiënt processorgebruik door EAC waardoor beide processen elkaar negatief beïnvloeden. Dit heeft als gevolg dat de effectiviteit van EAC omlaag gaat. Met andere woorden, er zullen makkelijker leesfouten ontstaan welke het proces vertragen. Maar aangezien EAC deze toch detecteert (en doorgaans kan corrigeren) gaat de betrouwbaarheid van het programma niet achteruit. Zeker wanneer je C2-ondersteuning uitschakelt in EAC is het programma vrijwel onfeilbaar wat het detecteren van fouten betreft.

Extractiesnelheid is iets dat langs twee kanten snijdt. Beschadigde sectoren met rechtstreeks effect op de eerste stage van de CIRC-decoder die uitgelezen worden aan maximale leessnelheid geven vaak veel minder fouten in de eerste stage (en met als logisch gevolg ook in de tweede stage) van de CIRC-decoder. De kans op correctie zonder tussenkomst van de software (zoals EAC) is dan ook veel groter dan wanneer op een lagere snelheid gelezen zou worden. Fouten die effect hebben op de tweede stage schijnen dan weer makkelijker uit te lezen bij een lagere snelheid. Daarom zal EAC steeds op zo hoog mogelijke snelheid proberen te rippen (mits de drive het toelaat want EAC's extractiemethode is nu eenmaal erg traag) en wanneer er fouten optreden de drive afremmen en opnieuw proberen. Ideaal is dus een keer proberen op maximale snelheid en op lagere snelheid en de beste waarden uit beide pgingen behouden. Software als PlexTools gebruikt een gelijkaardige filosofie. In de praktijk haalt PlexTools soms zelfs betere resultaten dan EAC! Dit geldt wel alleen wanneer gebruikt in combinatie met moderne Plextor drives.

Dat gedownloade muziek vaak tikken bevat ligt doorgaans aan de gebruikte software en niet zozeer de omstandigheden waaronder gewerkt moet worden. Denk maar aan AudioCatalyst, AudioGrabber,... Foutloze rips zijn daar eerder een uitzondering op ietwat beschadigde cd's. Tikken in muziek geript met EAC zijn vrijwel uitgesloten, tenzij de software niet correct geconfigureerd werd, of de software oncorrigeerbare leesfouten aanduidde na het rippen.

[voodooless]

Als je de 3 CD-ROM stations aan een IDE kabel hangt, ben je idd vaak langer bezig als je ze beiden gebruikt dan dat je er eentje gebruikt. Dit is simpelweg omdat de apparaten zich op de kabel in de weg zitten. In theorie is er natuurlijk voldoende plek, maar de de praktijk wil dat nog wel eens flink botsen. Verder is het zo dat als ja op goede kwaliteit wil encoden, het encodin net zo lang duurt als het rippen, waardoor je dan eigenlijk ook nog eens dubbele CPU power nodig zou hebben om er optimaal gebruik van te maken. Heb je CPU tijd over (of een dual systeem ), dan is het natuurlijk geen probleem .

Onder linux gebruik ik ripperX. Deze maakt gebruik van cdparanoia (beste linux ripper) en lame of gogo (voor SMP leuk). Je kunt deze zo vaak opstarten als je wil en ik heb een CD soms binnen 5 minuten volledig naar hoge kwaliteit MP3 omgezet. Ik heb dan nog CPU power over, dus zou ik ook nog de tweede drive kunnen laten rippen, maar ik denk dat het er niet veel sneller op zal worden.

[deepbass909]

SacCD, ik gebruik nu al jaren CDeX (voorheen audiocatalist, maar die rips zijn waar mogelijk inmiddels vervangen). Ik heb met CDeX nog nooit een lees fout gehad die niet gedetecteerd was! een enkele keer wil hij een cd niet foutloos lezen, maar mijn ervaring is, dat dan de cd echt kritisch beschadigd is, en dat alleen een spelen soms uitkomst biedt.
Daarnaast heb ik werkelijk nog nooit een snelheids verschil waargenomen tussen plextools en cdex. Beide waren evensnel, om de simpele reden dat DAE een hardware optie in je speler is, waar software relatief weinig invloed op heeft. Het enige wat de software kan doen, is een extra check uitvoeren en eventueel de snelheid terug schroeven, maar meestal doet de cd-rom dit zelf ook al.

De reden dat audiocatalist zo brak klinkt, komt voor 90% voor rekening van de gebruikte codec. De is van Xing en gewoon rond uit slecht!. Tikjes ontstaan wanneer je een trage pc hebt, en verkeerde software gebruikt (vroeger had mijn cellie 333 met audio catalyst er ook last van, met cdex niet meer, want die merkte de fout op).

[satcp]

deepbass909 schreef op 08 december 2003 @ 16:52:
SacCD, ik gebruik nu al jaren CDeX (voorheen audiocatalist, maar die rips zijn waar mogelijk inmiddels vervangen). Ik heb met CDeX nog nooit een lees fout gehad die niet gedetecteerd was! een enkele keer wil hij een cd niet foutloos lezen, maar mijn ervaring is, dat dan de cd echt kritisch beschadigd is, en dat alleen een spelen soms uitkomst biedt.

Het is "SatCP", maar dat even terzijde

Je zegt dat je met CDex nooit een leesfout hebt gehad die niet gedetecteerd werd. Hoe kun je nu weten of er geen leesfouten optraden als ze niet aangeduid worden (ik ga hier later wat dieper op in)? Vaak zijn kleine leesfouten niet meteen hoorbaar. Pas als je weet waar ze staan kun je ze horen bij aandachtig luisteren. Je kunt jezelf natuurlijk afvragen of het wel zin heeft om achter zulke kleine fouten te gaan zoeken als je ze vaak niet eens bewust kunt horen, maar waarom niet gaan voor perfectie als dat evengoed mogelijk is. Trouwens, heel wat leesfouten zijn wel degelijk hoorbaar.

Hieronder de resultaten uit testen die ik vorig jaar heb uitgevoerd: AudioGrabber (AudioCatalyst gebruikt een oude extractie engine hiervan), CDex, Exact Audio Copy en PlexTools (er zaten ook andere programma's in de test, maar die doen nu niet ter zake). De programma's kregen allen dezelde artificieel beschadigde cd's voorgeschoteld. De onderstaande figuur toont hoe de beschadigingen verdeeld zijn over de verscheidene tracks op de test-cd die we hier nu zullen gebruiken als voorbeeld. De eerste drie beschadigingen zijn puntvormig. De vijf daarop volgende zijn steeds groter wordende krassen loodrecht op de as van de compact disc. Dan volgt een dubbele kras en daarna drie beschadigingen in de draairichting van de cd. De laatste beschadiging is een compleet zwart gemaakt stuk cd. Sommige van deze beschadigingen zijn zo zwaar dat de cd-romspeler geen kans heeft om de track foutloos uit te lezen terwijl andere zo klein zijn dat ze waarschijnlijk ook frequent voorkomen in uw cd-collectie.



Het gaat er nu om welke software zoveel mogelijk data van de cd kan redden. Belangrijk hierbij is dat de software duidelijk aangeeft of er fouten optraden en liefst nog met de exacte posities.

Omdat het om een referentiecd gaat weten we dus exact welke data er op de cd dient te staan. gewoon uitlezen en vergelijken is voldoende om te zien of er al dan niet fouten optraden. Natuurlijk speelt de kwaliteit van de gebruikte cd-romspeler ook een rol, maar die was voor alle software identiek (en bovendien een zeer goede drive).

AudioGrabber / AudioCatalyst

Tijdens het uitlezen geeft het programma "speed errors" op bepaalde tracks. Volgens de handleiding duidt dit echter niet noodzakelijk op leesfouten, en de resultaten in onderstaande tabel bevestigen dat. Er worden zowel snelheidsfouten aangeduid in tracks waarin geen fouten voorkomen als in tracks met fouten. Deze foutaanduiding is dus totaal onbetrouwbaar.

	Duidt de software leesfouten aan?	Zijn er leesfouten in werkelijkheid?	Opmerkingen
Track01	Nee	Nee
Track02	Nee	Nee
Track03	Nee	Nee
Track04	Nee	Nee
Track05	Nee	Nee
Track06	Nee	Nee
Track07	Nee	Ja
Track08	Nee	Ja	AudioGrabber duidt snelheidsfouten aan.
Track09	Nee	Ja	AudioGrabber duidt snelheidsfouten aan.
Track10	Nee	Ja
Track11	Nee	Ja
Track12	Nee	Ja
Track13	Nee	Ja
Track14	Nee	Nee	AudioGrabber duidt snelheidsfouten aan.
Track15	Nee	Ja	Uitgelezen track heeft niet de juiste lengte.
Track16	Nee	Ja	AudioGrabber duidt snelheidsfouten aan.
Track17	Nee	Ja	AudioGrabber duidt snelheidsfouten aan.
Track18	Nee	Ja	AudioGrabber duidt snelheidsfouten aan. Uitgelezen track heeft niet de juiste lengte.
Track19	Nee	Nee	AudioGrabber duidt snelheidsfouten aan.
Track20	Nee	Nee	AudioGrabber duidt snelheidsfouten aan.
Track21	Nee	Ja	AudioGrabber duidt snelheidsfouten aan.

De testresultaten tonen dat AudioGrabber op geen enkele track leesfouten detecteerde terwijl na verificatie blijkt dat maar liefst twaalf tracks fouten bevatten.
De fouten manifesteren zich hoorbaar in de vorm van nauwelijks waarneembare tot duidelijk hoorbare tikken. Bovendien ontbraken er enkele monsters aan het einde van twee tracks.

Het extractieprogramma AudioGrabber (en dus ook AudioCatalyst) kan dus als erg onbetrouwbaar worden beschouwd, hoofdzakelijk omdat het niet aanduidt of er fouten zijn.

CDex

CDex is een programma dat aan een sterke opmars bezig is. Er wordt beweerd dat het programma een superieure audio-extractiekwaliteit heeft. Daarvoor kan het gebruik maken van de zogenaamde cd-paranoia-bibliotheken. Deze bieden geavanceerde foutcorrectie- mogelijkheden voor audio zoals het herstellen van muziekdata beschadigd door krassen.

	Duidt de software leesfouten aan?	Zijn er leesfouten in werkelijkheid?	Opmerkingen
Track01	Nee	Nee
Track02	Nee	Nee
Track03	Nee	Nee
Track04	Nee	Nee
Track05	Nee	Nee
Track06	Nee	Ja
Track07	Nee	Ja
Track08	Nee	Ja
Track09	Nee	Ja
Track10	Nee	Ja
Track11	Nee	Ja
Track12	Nee	Ja
Track13	Nee	Ja
Track14	Nee	Ja
Track15	Nee	Ja
Track16	Nee	Ja
Track17	Nee	Ja
Track18	Nee	Ja
Track19	Nee	Nee
Track20	Nee	Nee
Track21	Nee	Ja

Helaas vertalen de beweringen zich niet naar concrete resultaten. De testresultaten vallen erg tegen. Maar liefst veertien van de eenentwintig tracks werden foutief ingelezen. Bovendien duidde het programma geen enkele fout aan. Gezien de snelheid waarmee het programma leest is het erg waarschijnlijk dat CDex gebruik maakt van dezelfde burst-extractiemode als AudioGrabber.

De testen werden uitgevoerd met de paranoia full repair-mode ingeschakeld. Hoewel de resultaten in de tabel slechter ogen dan die van AudioGrabber moet wel worden gezegd dat de cd-paranoia-bibliotheken die CDex gebruikt leesfouten kunnen verhullen met geavanceerde foutcorrectietechnieken.

De meeste leesfouten waren nauwelijks hoorbaar. Alleszins beduidend minder dan AudioGrabber.

Het programma leest wel meer fouten (*), maar de paranoia-bibliotheek kan de meeste fouten netjes verhullen. Desalnietemin waren er wel degelijk hoorbare artifacten. Op zich is dat niet zo erg gezien sommige beschadigingen, maar het programma duidde geen enkele fout aan. De conclusie is dan ook uiterst negatief. CDex is onbetrouwbaar.

CDex zou goed kunnen zijn als het de leesfouten ook daadwerkelijk zou aanduiden. Het programma becshikt over veel potentieel dankzij de cd-paranoia bibliotheken.

*: Het is vermoedelijk niet het programma dat meer fouten leest, maar de cd-paranoia bibliotheken die ook correcte audio durven aanpassen. Dit heeft echter geen negatieve invloed op de audiokwaliteit (eerder een positieve gezien de sterke vermindering van het aantal hoorbare fouten). Zonder cd-paranoia zijn de resultaten vergelijkbaar met AudioGrabber.

Exact Audio Copy

Exact Audio Copy werd geschreven door Andre Wiethof, iemand die de belabberde kwaliteit van de meeste extractiesoftware danig beu was. EAC gebruikt geavanceerde leesroutines voor het inlezen van audiodata die de kwaliteit van de audio garanderen. In tegenstelling tot alle andere software leest EAC elke audiosector twee maal in. Is er een verschil tussen beide leespogingen dan weet EAC dat er een leesfout is opgetreden. Die sector zal dan indien nodig tot 82 maal toe worden ingelezen tot een bevredigend resultaat wordt bekomen. Kan zelfs EAC de data niet meer redden dan wordt de exacte positie van de leesfout in de log weergegeven zodat je na het extractie proces snel eventjes kan luisteren of er werkelijk een hoorbaar artifact is.

Het twee maal inlezen van de audio data is meteen ook EAC's zwakke punt. Het extractieproces gaat de helft trager dan bij Burst Copy Mode tools zoals CDex en AudioGrabber, en vaak zelfs nog trager door de traagheid van de cd-romspeler's laser pickup (die moet zich telkens herpositioneren). Verder kan het herlezen van sectoren (en dus onderbreken van de burst) leiden tot synchronisatiefouten wat het proces nog meer vertraagt. Echter synchronisatie is bij vrijwel alle moderne cd-romspelers geen probleem meer.

Als je zeker bent van betrouwbaarheid van de C2-informatie die je cd-speler geeft dan kan je EAC daar gebruik van laten maken. EAC hoeft dan niet meer elke sector tweemaal te lezen omdat de cd-speler reeds vertelt welke sectoren fout zijn. Enkel de foutieve sectoren dienen dan herlezen te worden. Dat komt de snelheid tengoede.

Allemaal mooi en wel, maar hoe presteert het programma nu?

	Duidt de software leesfouten aan?	Zijn er leesfouten in werkelijkheid?	Opmerkingen
Track01	Nee	Nee
Track02	Nee	Nee
Track03	Nee	Nee
Track04	Nee	Nee
Track05	Nee	Nee
Track06	Nee	Nee
Track07	Nee	Nee	Foutcorrectie door herlezen.
Track08	Nee	Nee	Foutcorrectie door herlezen.
Track09	Nee	Nee	Foutcorrectie door herlezen.
Track10	Nee	Nee	Foutcorrectie door herlezen.
Track11	Nee	Nee	Foutcorrectie door herlezen.
Track12	Nee	Nee	Foutcorrectie door herlezen.
Track13	Nee	Nee	Foutcorrectie door herlezen.
Track14	Nee	Nee	Foutcorrectie door herlezen.
Track15	Nee	Nee
Track16	Ja	Ja
Track17	Ja	Ja
Track18	Nee	Nee
Track19	Nee	Nee
Track20	Nee	Nee
Track21	Ja	Ja

Niet minder dan achttien van de eenentwintig tracks worden foutloos ingelezen door Exact Audio Copy en ook de foutaanduiding is onberispelijk. De tracks die als correct ingelezen aangeduid zijn bevatten geen fouten.

Waarom is dat nu zo belangrijk?

Stel, je hebt een cd met enkele zwaar beschadigde sectors. Zo zwaar beschadigd dat ook EAC ze niet meer kan lezen. Als je die cd inleest met AudioGrabber is er zeer veel kans dat het programma niet eens een fout aanduidt (een zeer reële kans zoals de test aantoonde). En mocht het al zien dat er een synchronisatiefout is opgetreden (wanneer de leesfout zo groot is dat de cd-romspeler het spoor bijster raakt) dan weet je nog steeds niet waar.

EAC daarentegen zal tot op de seconde juist, de exacte positie van de leesfout aanduiden zodat je na het extractie proces maar eventjes naar een paar seconden hoeft te luisteren om te beoordelen of je de leesfout hoort of niet. Op alle andere plaatsen garandeert EAC dat de data 100% correct is...

Bij vrijwel alle Burst Copy Mode tools zul je de volledige cd moeten beluisteren om de fout terug te vinden. En wie kan er nu 74 minuten onafgebroken z'n aandacht houden bij het beluisteren van een cd met enkele foute sectors? Vrijwel zeker dat je dan de foute sectors niet hoort, terwijl als je (zoals met EAC) alleen het foute gebied beluistert er veel meer kans is dat je een mogelijk hoorbaar artifact wel opmerkt.

Als EAC geen fouten aanduidt in de log dan weet je dat de rip 100% perfect is. Bij de meeste andere software kan je het alleen maar hopen...

PlexTools (met vernieuwe audio-extractiemethode)

PlexTools valt eigenlijk buiten dit topic, maar het programma gebruikt sinds enige tijd een interessant concept dat verbluffend goed werkt (*). PlexTools zal net als CDex en AudioGrabber de cd uitlezen in Burst Copy Mode. Met andere woorden, op maximale leessnelheid. Maar in tegenstelling tot AudioGrabber en CDex heeft dit programma wel een leesfoutdetectie: de C2-foutinformatie geleverd door de Plextor drives. PlexTools gaat hier wel uit van een vrij gevaarlijk standpunt. Het programma neemt aan dat de C2-informatie geleverd door de Plextor drives onvoorwaardelijk betrouwbaar is. Nu is de C2-informatie bij moderne Plextor drives erg goed, perfect is het nooit. Op papier blijft EAC's methode van dubbel uitlezen dus de meest betrouwbare wat foutdetectie betreft.

Wat foutcorrectie betreft gebruikt PlexTools een totaal nieuwe strategie die de resultaten van meerdere leespogingen kan combineren, en hieruit zoveel mogelijk correcte data proberen te halen.

*: Oudere PlexTools versies stellen niet veel voor wat de audio-extractie betreft.

	Duidt de software leesfouten aan?	Zijn er leesfouten in werkelijkheid?	Opmerkingen
Track01	Nee	Nee
Track02	Nee	Nee
Track03	Nee	Nee
Track04	Nee	Nee
Track05	Nee	Nee
Track06	Nee	Nee
Track07	Nee	Nee	Foutcorrectie door herlezen.
Track08	Nee	Nee	Foutcorrectie door herlezen.
Track09	Nee	Nee	Foutcorrectie door herlezen.
Track10	Nee	Nee	Foutcorrectie door herlezen.
Track11	Nee	Nee	Foutcorrectie door herlezen.
Track12	Nee	Nee	Foutcorrectie door herlezen.
Track13	Nee	Nee	Foutcorrectie door herlezen.
Track14	Nee	Nee	Foutcorrectie door herlezen.
Track15	Nee	Nee
Track16	Ja	Ja
Track17	Nee	Nee	Foutcorrectie door herlezen.
Track18	Nee	Nee
Track19	Nee	Nee
Track20	Nee	Nee
Track21	Ja	Ja

De techniek die PlexTools gebruikt is zelfs in staat om de heersende 'kwaliteitskoning' EAC van de troon te stoten! Maar liefst negentien van de eenentwintig tracks werden foutloos ingelezen en de overige correct als foutief aangeduid. En dit bovendien met een gigantisch snelheidsvoordeel ten opzichte van EAC. De foutvrije data werd ingelezen aan dezelfde snelheid als AudioGrabber en CDex. Pas wanneer fouten optraden vertraagde de software en las het de foutieve sectoren opnieuw om de correcte data hieruit te combineren.

Onder bepaalde omstandigheden is PlexTools dus duidelijk in staat om EAC te verslaan. Er moet wel opgemerkt worden dat qua features PlexTools nog ver achterligt op EAC. EAC is dus zeker nog niet aan z'n pensioen toe

Daarnaast heb ik werkelijk nog nooit een snelheids verschil waargenomen tussen plextools en cdex. Beide waren evensnel

Er is dan ook geen verschil. Beiden gebruiken dezelfde leestechniek. Enkel EAC gebruikt een totaal afwijkende techniek. Maar PlexTools heeft dan weer wel in tegenstelling tot CDex een veel beter foutdetectie/correctie mechanisme.

om de simpele reden dat DAE een hardware optie in je speler is, waar software relatief weinig invloed op heeft. Het enige wat de software kan doen, is een extra check uitvoeren en eventueel de snelheid terug schroeven, maar meestal doet de cd-rom dit zelf ook al.

Op alles wat door de cd-romspeler wordt uitgelezen (niet alleen audio) heeft de software weinig (zeg maar gerust geen) directe invloed. Maar dat wil niet zeggen dat de software geen grote invloed kan hebben op het resultaat!

De foutdetectie en -correctie op een audio-cd is eigenlijk zelfs erg krachtig. Tot een bepaalde hoeveelheid fouten maakt het niet uit of de data op een cd fouten bevat.

Ook een cd nieuw uit de winkel leest reeds ettelijke fouten per seconde. Sterker zelfs, zonder de CIRC-decoder (Cross Interleaved Reed-Solomon Code - het hart van de foutdetectie/correctie in een cd-speler) zou een cd op z'n best klinken als een zwaar beschadigde LP. CIRC is echter in staat om (naar verhouding) gigantisch grote fouten volledig foutvrij te verbeteren.

Dus zolang CIRC in staat is de aanwezige fouten verliesvrij te corrigeren is er geen kwaliteitsverlies! Pas wanneer de error rate zo hoog wordt dat CIRC niet langer in staat is uit de aangeboden data de juiste data te achterhalen komen we op het veld dat de software invloed kan gaan uitoefenen. Afhankelijk van de optische kwaliteit van het loopwerk, de constructie van CIRC-decoder en het uit te lezen medium zelf kan dat variëren van problemen vanaf slechts vingerafdrukken tot krassen om 'U' tegen te zeggen... De eerder genoemde test toont duidelijk aan dat de software een erg grote invloed kan hebben op het resultaat.

Het grootste probleem is echter de fouten herkennen. Heel wat cd-spelers duiden op geen enkele manier aan of de gelezen data fout is (de interne CIRC-decoder weet het nochtans wel). Dus de software kan ook op geen enkele manier weten of er een fout optrad, tenzij een methode zoals die van EAC gebruikt wordt (tweemaal inlezen en vergelijken). De meeste moderne cd-romspelers kunnen echter het E32-signaal van de CIRC-decoder (dat duidt de uncorrectables aan) naar buiten brengen. Doorgaans wordt dit C2-foutinformatie genoemd. Jammer genoeg is de kwaliteit van dit signaal vaak onbetrouwbaar (de C2-informatie van AOpen cd-romspelers bijvoorbeeld is vaker fout dan juist). En zelfs al heb je perfecte C2-informatie, dan zit je nog met het probleem dat software als AudioGrabber, AudioCatalyst, WinDAC, Nero, CDRWin, MusicMatch, WMP,... en vrijwel *alle* andere extractie software er gewoonweg niets mee aanvangen. De drive duidt de fouten wel aan, maar de software negeert ze volkomen...

Plextor's PlexTools maakt gebruik van een nauwe koppeling met de CIRC-decoders in de Plextor drives om de foutinformatie zo optimaal mogelijk te benutten.

De reden dat audiocatalist zo brak klinkt, komt voor 90% voor rekening van de gebruikte codec. De is van Xing en gewoon rond uit slecht!. Tikjes ontstaan wanneer je een trage pc hebt, en verkeerde software gebruikt (vroeger had mijn cellie 333 met audio catalyst er ook last van, met cdex niet meer, want die merkte de fout op).

Tikken ontstaan in het extractieprogramma, niet de mp3-encoder. Tikken ontstaan wanneer de software leesfouten negeert... Zelfs mijn oude Pentium 166 is in staat om perfecte mp3's af te leveren met EAC en LAME (mits wat geduld weliswaar). En die is toch een kar trager dan uw Celeron 333...

Wat de kwaliteit van de Xing encoder betreft kunnen we het eens zijn... Die is vreselijk. Zelfs op de hoogste bitrates slaagt Xing erin om hoorbare artifacten te produceren in het geluid. De oude Xing versies hadden bovendien een zwaar probleem met geluid dat boven de 16 kHz volledig werd afgekapt. Iets wat de audiokwaliteit natuurlijk niet ten goede komt. De nieuwere versies zouden volgens Xing dit probleem verhelpen, maar luister- en meettesten tonen duidelijk aan dat de 16 kHz cut-off er nog steeds is, weliswaar in mindere mate, maar nog steeds genoeg om de encoder als onbruikbaar voor audio-archivering te bestempelen.

Variable Bitrate is bij Xing ook al een ramp. Het mechanisme dat de bitrates reserveert naar gelang de complexiteit van de muziek kan in de verste verten niet tippen aan dat van LAME. VBR met Xing is dan ook taboe.

De Joint Stereo mode die vooral bij lagere bitrates (en VBR) wordt gebruikt heeft dankzij Xing ook een slechte naam gekregen. Vaak hoor je zeggen dat Joint Stereo slecht is terwijl dit helemaal niet zo is. Joint Stereo is een geweldig mechanisme om te switchen tussen Mid/Side Stereo (in de stijl van FM) en normale Stereo mode. Het nadeel aan Joint Stereo is dat veelvoudig switchen tussen beide modes artifacten kan opleveren in het geluid. LAME bijvoorbeeld heeft een vrijwel perfecte Joint Stereo implementatie. Xing aan de andere kant, heeft een rampzalige implementatie...

[ Voor 1% gewijzigd door satcp op 21-07-2004 01:09 . Reden: Link update ]

[Verwijderd]

SatCP

Als je de 3 CD-ROM stations aan een IDE kabel hangt, ben je idd vaak langer bezig als je ze beiden gebruikt dan dat je er eentje gebruikt.

Zolang je PCI bus niet 'volloopt' heb je geen snelheidsverlies, zeker niet als de optical drives alleen master op de kabel staat en (u)dma is ingeschakeld (52speed inlezen = 7,6 MB/sec terwijl PCI een bandbreedte heeft van 132 MB/sec [een beetje kromme redenatie, want 52x audiograbben moet ik nog meemaken, het hoogst is nu zo'n 40speed ] ). 3 stations kun je overigens nooit op 1 kabel kwijt, het maximum is 2 (master/slave).

[ Voor 17% gewijzigd door Verwijderd op 08-12-2003 19:04 ]

[voodooless]

Verwijderd schreef op 08 december 2003 @ 19:02:
SatCP


[...]
Zolang je PCI bus niet 'volloopt' heb je geen snelheidsverlies, zeker niet als de optical drives alleen master op de kabel staat en (u)dma is ingeschakeld (52speed inlezen = 7,6 MB/sec terwijl PCI een bandbreedte heeft van 132 MB/sec [een beetje kromme redenatie, want 52x audiograbben moet ik nog meemaken, het hoogst is nu zo'n 40speed ] ). 3 stations kun je overigens nooit op 1 kabel kwijt, het maximum is 2 (master/slave).

Het is toch al knap om 3 drives aan een kabel te krijgen

[Verwijderd]

deepspace schreef op 08 december 2003 @ 19:41:
[...]
Het is toch al knap om 3 drives aan een kabel te krijgen

Dat zeg ik al heb ik daar met SCSI geen last van, en heb je al vlot een dichtgelopen PCI bus als je er een beetje RAID op loslaat.
Meerdere opticals rulen sowieso, je hoeft niet te wachten totdat hij klaar is met die ene schijf, terwijl je lekker door kan gaan met de overigen.

[jsiegmund]

Gebruik toch 2 drives tegelijk nu, en moet zeggen dat dat prima bevalt. Natuurlijk ga je er qua compressie helemaal niks op vooruit om 2 processen te draaien: maar het inlezen gaat net zo snel (per drive). Voordeel is dan automatisch dat ik na dezelfde tijd al 2x zoveel compressie jobs heb staan wachten. En het voordeel daarvan is weer dat je rustig even iets anders kunt gaan doen, dat comprimeren gebeurt toch wel. En wanneer je jobs dan weer bijna op zijn ga je weer fijn een uurtje cd-tjes in en uit je drives halen. Ben tot nu toe erg tevreden over EAC. Kan helaas no way alles gaan beluisteren, daarvoor is het echt veeeeel te veel, maar in mn random picks zitten geen hoorbare fouten dus ga er maar vanuit dat die netjes uitgesloten zijn.
Moet trouwens zeggen dat mn plextor sowieso een stuk beter inleest dan m'n Sony DVD drive. Heeft echt merkbaar minder problemen met minder goeie cd's (maar is wel een stuk trager helaas).

[ Voor 3% gewijzigd door jsiegmund op 09-12-2003 11:38 ]