[audiograbber] Geen ASPI of MSCDEX

[BasieP]

mensen, ik wilde vandaag een mooie queen CD rippen naar mp3, maar toen ik audio grabber opende zag ik bij settings dat ik zowel ASPI als MSCDEX niet kon aanvinken.

dit houd dus in dat ik alleen via dat analoge draadje me cd's kan rippen. dit werkt traag, en kwaliteit word er ook niet beter van.

vroegah (*kuch*) toen ik nog een CD fikker in me computer had zitten kon ik altijd (ik geloof) ASPI kiezen (en anders dus MSCDEX).
Zo kon ik snel en zonder veel last cd's rippen.
nu heb ik een tijdje terug een DVD brander gekocht, en sindsdien kan ik dat dus niet meer.

relevante specs:
OS: win2k
DVD: Samsung dual layer fikker (weet type zo 123 niet)

Nu vroeg ik me af, hoe kan het dat ik met deze DVD fikker opeens die opties niet meer kan kiezen?

(weet ook niet of dit in SA, WOS of OM moest maar heb maar gegokt)

[ Voor 6% gewijzigd door BasieP op 10-04-2005 20:47 ]

[chucky666]

en als je een ander programma probeert ?
bv. CDex ?
doet die het wel gewoon ?

[BasieP]

die begint nadat ik er op klik met

Failed to load the nwaspi32.dll driver!
Use the "Native NT SCSI library" driver instead?

maar doet het daarna wel met die native zut.

EN hij heeft ook automatisch opzoeken van CD's via internet (dus niks typen) leuk progje


HOWEVER...
dat ding ript rete traag.. moet wel 1 speed zijn ofzo want hij doet ongeveer (gok precies) even lang over een nummer als dat het nummer duurt

[ Voor 26% gewijzigd door BasieP op 10-04-2005 21:37 ]

[chucky666]

ik gebruik hem meestal om een cd over te zetten naar mp3 of wav of van mp3 naar wav off.....

[The Third Man]

Audiograbber is een zogeheten burstgrabber die de data uit de cache van je cd-romspeler leest waardoor er 0 controle op correcte inlezing van de data is, voor hetzelfde gemak zitten er allemaal foutjes in. Cdex daarentegen gebruikt directe aansturing van de speler waardoor hij in wezen de data sector voor sector van de cd haalt (vandaar dat hij er langer over doet). Als je het helemaal goed wilt doen gebruik je EAC, die heeft een eigen speler database voor de juiste instellingen, is het allerbeste qua kwaliteitscontrole en heeft ook de handige dingetjes zoals het raadplegen van de cddb.

[BasieP]

Lekkere Kwal schreef op zondag 10 april 2005 @ 23:55:
Audiograbber is een zogeheten burstgrabber die de data uit de cache van je cd-romspeler leest waardoor er 0 controle op correcte inlezing van de data is, voor hetzelfde gemak zitten er allemaal foutjes in. Cdex daarentegen gebruikt directe aansturing van de speler waardoor hij in wezen de data sector voor sector van de cd haalt (vandaar dat hij er langer over doet). Als je het helemaal goed wilt doen gebruik je EAC, die heeft een eigen speler database voor de juiste instellingen, is het allerbeste qua kwaliteitscontrole en heeft ook de handige dingetjes zoals het raadplegen van de cddb.

das niet helemaal waar.

met audiograbber kan je kiezen voor een driver (ASPI/MSCDEX) of analoog. analoog betekent dat je via die 3 dradige audio kabel van je cd speler naar je geluidskaart (of mobo soms) ze data ophaalt.
het probleem hierbij is, dat wanneer ik tussendoor andere audio af ga spelen (waar ik best wel eens zin in heb) dat audiograbber er gewoon mee kapt.
ik krijg dan prachtige files van mooie realischtische grotes, maar ze zijn 'leeg' (geen geluid)

CDex doet altijd alles via dat audio kabeltje.. das best frustrerend..

wanneer ik 'vroegah' met audio grabber via aspi of mscdex (weet ik niet meer) iets deed, deed ik dat gewoon op 20x.
dan coderen erbij en je had na 10/15 minuten een audio CD als mp3 op je schijf staan.
nu doe ik alleen over het lezen al 70 minuten (als het geen 80 is).

ik geloof ook niet echt dat er 0,nix geen controlle op die data zit die er gelezen word via een driver. Dit zou betekenen dat ik fouten zou moeten krijgen, die heb ik in zo'n 300 zelf geripte mp3's nog niet 1x gehad. Volgens mij maakt audio grabber gebruik van een windows buffer. Windows zelf (of dan mscdex of aspi) regelt dan de error handling.

[ Voor 4% gewijzigd door BasieP op 11-04-2005 00:11 ]

[The Third Man]

BasieP schreef op maandag 11 april 2005 @ 00:10:
[...]

CDex doet altijd alles via dat audio kabeltje.. das best frustrerend..

Sorry maar ik gebruik al sinds '99 cdex en die heeft altijd al digitaal geript, analoog rippen is behalve ouderwets simpelweg kwalitatief idioot (digitaal naar analoog om laten zetten door een goedkope chip in de cdromspeler om die vervolgens weer na over een onafgeschermd kabeltje door een mierenhoop van EMI te zijn gegaan weer naar digitaal om te zetten). Alleen bij de aller-antiekste cd-spelers was dat de enige manier maar dat is al sinds de 8x spelers niet meer nodig. Als cdex er extreem lang over doet is er misschien iets anders mis maar ik haalde altijd (inclusief realtime mp3 encoding) minstens 4x op antieke pentiums op mijn school.

wanneer ik 'vroegah' met audio grabber via aspi of mscdex (weet ik niet meer) iets deed, deed ik dat gewoon op 20x.
dan coderen erbij en je had na 10/15 minuten een audio CD als mp3 op je schijf staan.
nu doe ik alleen over het lezen al 70 minuten (als het geen 80 is).

In dat geval zou het kunnen dat je Cdex op 1x laat rippen maar dat lijkt me onlogisch aangezien Cdex dit standaard niet doet. Wat dan wel de oorzaak is zou ik echt niet weten, wellicht dat je nog Eac kan proberen (misschien is Cdex wel niet compatibel met jouw cdromspeler).

ik geloof ook niet echt dat er 0,nix geen controlle op die data zit die er gelezen word via een driver. Dit zou betekenen dat ik fouten zou moeten krijgen, die heb ik in zo'n 300 zelf geripte mp3's nog niet 1x gehad. Volgens mij maakt audio grabber gebruik van een windows buffer. Windows zelf (of dan mscdex of aspi) regelt dan de error handling.

Dat kan onmogelijk zo zijn omdat op audio cd's de data in Mode 2 staat weggeschreven waardoor geen level 3 (= software) error correction code (het bekende ECC) 'bij' de data staat. Zou je audio in Mode 1 wegschrijven dan zou er maar een kleine 70 minuten muziek op een 700 MB cd passen. Het nadeel van Mode 2 correctie is dat er slechts 2 levels van error correction zijn die alleen hardwarematig afgehandeld kunnen worden en dus worden geregeld door de controller in de cdspeler. Echter sommige cdromspelers kunnen level 2 fouten (populair C2-errors genoemd) rapporteren waardoor het ripprogramma hier rekening mee kan houden en de data opnieuw kan proberen te lezen. Bij een Mode 1 cd zou in dat geval namelijk de level 3 ECC kunnen controleren of de data nog intact is. Eac's truuk hierbij is de data meerdere keren opnieuw lezen om te controleren of elke keer dezelfde data gelezen wordt om hiermee te schatten of de gelezen data correct is.

Welnu Audiograbber maakt om snelheidsredenen hier geen gebruik van, het laat simpelweg de cdspeler de tracks zo snel mogelijk afspelen en kopieert vervolgens de data direct uit de cache naar het RAM en via dat weer naar de harde schijf. Dat dat in de praktijk geen (hoorbare) fouten oplevert is meer geluk en kan dus niet betrouwbaar worden genoemd (zeker niet als je cd's wilt backuppen of beschadigde cd's wilt inlezen).

EDIT
Ik heb net een eigen 'benchmark' uitgevoerd door 1 van de weinige albums die ik bezit (ik ben meer van de films en heb m'n albums altijd al als mp3) geript met een verse cdex met alleen een e-mailadres ingevuld voor de cddb en de compressieinstelling op Lame met --alt-preset standard gezet (= VBR 192/kb/s ongeveer). De cd (Marilyn Manson - Holy Wood uit 2000) in m'n dvdbrander gestopt, laten rippen en dus realtime naar mp3 laten omzetten. Dit kwam neer op ruim 70 minuten muziek wat hij in 16 minuten heeft geript en gecomprimeert wat neerkomt op een gemiddelde snelheid van zo'n 4,4x. Conclusie: je doet dus iets fout

[ Voor 11% gewijzigd door The Third Man op 11-04-2005 01:27 ]

[Jazco2nd]

Voor de best mogelijke kwaliteit heb je maar 1 keus: Exact Audio Copy.

een algemene aspi driver kun je heel makkelijk via google vinden...

[Rafe]

(ASPI) problemen met branden/rippen?

[satcp]

BasieP schreef op maandag 11 april 2005 @ 00:10:
analoog betekent dat je via die 3 dradige audio kabel van je cd speler naar je geluidskaart (of mobo soms) ze data ophaalt.
het probleem hierbij is, dat wanneer ik tussendoor andere audio af ga spelen (waar ik best wel eens zin in heb) dat audiograbber er gewoon mee kapt.

Niet alleen dat, maar de digitaal-naar-analoog-omzetters van vrijwel alle cd-romspelers zijn zo belabberd dat de audiokwaliteit erg te lijden heeft onder deze methode. Analoog rippen moet je dus ten allen koste vermijden.

CDex doet altijd alles via dat audio kabeltje.. das best frustrerend..

Dan doe je iets mis want CDex gebruikt dat kabeltje helemaal niet.

ik geloof ook niet echt dat er 0,nix geen controlle op die data zit die er gelezen word via een driver. Dit zou betekenen dat ik fouten zou moeten krijgen, die heb ik in zo'n 300 zelf geripte mp3's nog niet 1x gehad. Volgens mij maakt audio grabber gebruik van een windows buffer. Windows zelf (of dan mscdex of aspi) regelt dan de error handling.

Geloof me vrij, die foutdetectie is er niet. En neem maar van me aan dat er ook daadwerkelijk leesfouten in een aantal van je geripte mp3's zullen zitten.

_{Hieronder volgt een herwerking van een bericht dat ik eerder voor GoT schreef}

Je zegt dat je met AudioGrabber 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 een tijdje geleden heb uitgevoerd: AudioGrabber, 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

AudioCatalyst gebruikt een oudere versie van de AudioGrabber extractie-engine zodat de resultaten ook voor dit programma gelden.

Tijdens het uitlezen geeft AudioGrabber "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 wat helemaal een veeg teken is. Niet alleen las het programma fouten, het laat nog eens data wegvallen ook!

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 beschikt 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.

Recente update: De gebruikte hardware buffert audio-data (zoals heel veel recente loopwerken). Een aandachtige lezer attenteerde me op het feit dat de cd-paranoia documentatie stelt dat de software enkel betrouwbaar werkt bij loopwerken die niet bufferen. Dit zou de ogenschijnlijke slechte resultaten van CDex in deze test kunnen verklaren. Maar dat neemt niet weg dat het nog steeds bijzonder verdacht is dat CDex geen leesfouten aanduidde. Zelfs al zou het programma enkel met niet-bufferende loopwerken overweg kunnen, dan nog zou het op z'n minst fouten hebben moeten detecteren want de leestechniek van CDex gebruikt geen herlezen om fouten te detecteren (zoals EAC bijvoorbeeld wel doet). Dat betekent dat fouten tijdens de eerste leespoging gedetecteerd moeten worden. Aangezien uit mijn testen blijkt dat dit niet het geval is, betwijfel ik of CDex beter zou presteren met een niet-bufferend loopwerk. Maar als ik nog eens wat vrije tijd over heb herhaal ik de testen wel met een ander loopwerk.

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 ten goede.

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 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

[chucky666]

weet je trouwens zeker dat dma aanstaat voor die dvd fikker
lijkt wel of pio mode geselecteerd is aan de snelheid te zien.

oja aspi driver : http://www.ncf.carleton.ca/~aa571/aspi.htm

[satcp]

chucky666 schreef op maandag 11 april 2005 @ 09:19:
weet je trouwens zeker dat dma aanstaat voor die dvd fikker
lijkt wel of pio mode geselecteerd is aan de snelheid te zien.

Hoewel dit natuurlijk niet uit te sluiten valt, haal je onder PIO mode 4 nog steeds heel wat hogere snelheden dan de 1x waar de topic starter nu aan ript. Anyway, *waarschijnlijk* lost een goede ASPI layer het probleem wel op. Heel wat mensen ervaren namelijk allerlei problemen met de Native Win32 Interface (ook bij andere software die deze ondersteunt zoals Exact Audio Copy). Dat neemt niet weg dat de topic starter met inferieure software bezig is, maar dat moet hij natuurlijk zelf weten

[BasieP]

chucky666 schreef op maandag 11 april 2005 @ 09:19:
weet je trouwens zeker dat dma aanstaat voor die dvd fikker
lijkt wel of pio mode geselecteerd is aan de snelheid te zien.

oja aspi driver : http://www.ncf.carleton.ca/~aa571/aspi.htm

ja das het eerste wat ik nagekeken heb.
ik heb een nforce2 bordje, en die driver zegt:
'ultra dma2: dma 33'

bij cdex staat mijn configuratie als volgt (standaard, ben er niet aangeweest)

read sectors: 26
read overlap: 7
start offset: 0
end offset: 0
nr of retries: 0
block compare: 1
cd speed: 0 <-- dit zou dus 'dynamisch' zijn neem ik aan (zo snel mogelijk)
spin-up time: 0

er staat ook een vinkje bij 'use native NT scsi library' (zie hierboven ergens)

cd speed op 5 ofzo zetten werkt niet, het gaat dan nog net zo snel (langzaam)

---

ik heb nu die aspi driver geinstalleerd van chucky666, en ga zo even rebooten. ook heb ik eac gedownload.. ben benieuwd

edit: w00t 19x EN error correction (voor zover eac dat doet, (ja ik heb geleerd van dit topic))

---

^^ oke dat was voor de reboot.. en toen waren alle .wav's 'leeg' (as in silence)

daarna gereboot (omdat ik die aspi driver nog moest doen enzo) en nu zegt eac 'no audio cd in drive' terwijl er dezelfde in zit als voor de reboot (ook ff er uit en er weer in wil niet werken)

in eac staat nu ook bovenaan 'Adapter 1: ID 1' in plaats van 'TSSTcorp CD/DVDW TS-H552B' (wat er eerst stond)

trouwens laat audio grabber nog steeds de aspi optie disabled, dus ik ga eens kijken of die misschien niet goed is geinstalleerd

---

oke nu met aspi4all gedaan, en nog steeds zegt ie 'no audio disc in drive' terwijl windows er wel gewoon bij kan
ook audiograbber vind nog steeds niks geen aspi..
even de nero fix proberen (uit onze lieve faq)

---

oke na de nero aspi driver naar de eac directory te kopieeren vind hij opeens weer audio cd's.
nu even kijken of ze weer 'stil' zijn of dat hij nu wel werkt

w00t hij werukt!!! *blij is* tnx all

[ Voor 66% gewijzigd door BasieP op 11-04-2005 11:15 ]