Which CD ripper?

[Chachi420]

so...my dbpoweramp program is not acceptable??

[drpino]

and what about plextools pro if you have a plextor drive? arguably considered better than EAC in terms of bit accurate rips...

[ssamadhi97]

foobar2000 0.9 beta has secure ripping with offset correction as well, but the feature still needs to be widely tested. So next time you're bored and don't know what to do with all your free time, feel free to stress-test it a little (and report your findings on the fb2k forum)

[jazzbo]

Originally Posted by ffooky

I believe it is the case that cdparanoia does not empty the cache between reads (in drives that cache audio, obviously) so correction is basically impossible/nullified if your drive does cache audio. I've asked xACT's author if the same situation obtains for cdda2wav and he said not, though I'd welcome further advice from knowledgeable sources.

I'd be interested to know why he thinks that is the case. If you look on cdda2wav's webpage, it states the routines come right from cdparanoia, i.e the paranoia library.

Regardless, the point is that if Mac users are using cdda2wav via xACT, then Linux users should be able to use cdda2wav (if not cdparanoia) as well. Unless some modification has been done to the Mac version.

Can someone point me to sources that say cdda2wav on Macs is actually as reliable as EAC? My quick looks on Hydrogen Audio don't bode well.

[ffooky]

This link makes mention of a difference in action between cdda2wav and cdparanoia.

I did a lot of testing and comparison of EAC/xACT/iTunes/Finder during this thread which demonstrated that there was error correction with xACT and both the drives I used do cache audio. Far from proof positive but that indicates to me that cdda2wav & lib paranoia may well behave differently from cdparanoia.

I've managed to get cdparanoia up and running on my Mac now and my first experiments have shown that it produces a different result on a damaged disc from xACT, and that result differs from rip to rip whereas xACT produced matching rips from two extractions.

I'd be very interested if you or another Linux user could test the two of them and if you could run EAC as well it'd be extremely useful.

[jazzbo]

Originally Posted by ffooky

This link makes mention of a difference in action between cdda2wav and cdparanoia.

Interesting. I was using this thread to look at the effectiveness of cdda2wav (just quickly) and not on Macs.

I've managed to get cdparanoia up and running on my Mac now and my first experiments have shown that it produces a different result on a damaged disc from xACT, and that result differs from rip to rip whereas xACT produced matching rips from two extractions.

I'd be very interested if you or another Linux user could test the two of them and if you could run EAC as well it'd be extremely useful.

I'll take a look at this tonight and give it a try, unfortunately I don't have EAC (or Windows) to run on my machine on home. But at least I can look at the consistency of the extractions.

One thing I found interesting in the thread you linked to on hydrogenaudio was a comment that cdda2wav was linked staticly to its own version of the paranoia library. If so, maybe that code has been patched with regards to audio caching.

Perhaps I did speak too soon earlier.

[jazzbo]

Originally Posted by ffooky

I'd be very interested if you or another Linux user could test the two of them and if you could run EAC as well it'd be extremely useful.

One of my problems was finding a disc with scratches . I did find a disc that some crud and marks on the play layer, and so I gave it a shot, first with cdparanoia.

kevin@dizzy:/tmp$ cdparanoia 11-11 try1.wav ; cdparanoia 11-11 try2.wav
cdparanoia III release 9.8 (March 23, 2001)
(C) 2001 Monty <[email protected]> and Xiphophorus

Report bugs to [email protected]
http://www.xiph.org/paranoia/


Ripping from sector  206152 (track 11 [0:00.00])
          to sector  226074 (track 11 [4:25.47])

outputting to try1.wav

 (== PROGRESS == [                         -    | 226074 00 ] == :^D * ==)

Done.


cdparanoia III release 9.8 (March 23, 2001)
(C) 2001 Monty <[email protected]> and Xiphophorus

Report bugs to [email protected]
http://www.xiph.org/paranoia/

Ripping from sector  206152 (track 11 [0:00.00])
          to sector  226074 (track 11 [4:25.47])

outputting to try2.wav

 (== PROGRESS == [                         -    | 226074 00 ] == :^D * ==)

Done.

Note that both times that was a slight jitter correction about 7.8th of the way across the read line. Then I tried cdda2wav with paranoia (logs are edited for clarity and to remove some of the diagnositic stuff about disc information.)

kevin@dizzy:/tmp$ cdda2wav -paranoia -t 11 ; mv audio.wav try3.wav
cdrom device (/dev/cdrom) is not of type generic SCSI. Setting interface to cooked_ioctl.
126976 bytes buffer memory requested, 4 buffers, 8 sectors
#Cdda2wav version 2.01.01a03_linux_2.6.13_i686_i686, real time sched., soundcard, libparanoia support
[...]
samplefile size will be 46858940 bytes.
recording 265.6399 seconds stereo with 16 bits @ 44100.0 Hz ->'audio'...
using lib paranoia for reading.
100%  track 11 recorded with minor problems
100%  0 rderr, 0 skip, 0 atom, 9 edge, 0 drop, 0 dup, 0 drift
100%  271 overlap(0.5 .. 0.5)

kevin@dizzy:/tmp$ cdda2wav -paranoia -t 11 ; mv audio.wav try4.wav
126976 bytes buffer memory requested, 4 buffers, 8 sectors
#Cdda2wav version 2.01.01a03_linux_2.6.13_i686_i686, real time sched., soundcard, libparanoia support
[...]
100%  track 11 recorded successfully
100%  0 rderr, 0 skip, 0 atom, 0 edge, 0 drop, 0 dup, 0 drift
100%  271 overlap(0.5 .. 0.5)

Interestingly, cdda2wav reports minor problems the first time it tried to read the track and 'recorded successfully' the second time

Now, let's look at the results

kevin@dizzy:/tmp$ ls -la *.wav
-rw-r--r--  1 kevin kevin 46858940 2005-09-30 21:01 try1.wav
-rw-r--r--  1 kevin kevin 46858940 2005-09-30 21:02 try2.wav
-rw-r--r--  1 kevin kevin 46858940 2005-09-30 21:09 try3.wav
-rw-r--r--  1 kevin kevin 46858940 2005-09-30 21:11 try4.wav

kevin@dizzy:/tmp$ md5sum *.wav
62e4a8485c02ee1122d6aa61907cd1ee  try1.wav
62e4a8485c02ee1122d6aa61907cd1ee  try2.wav
62e4a8485c02ee1122d6aa61907cd1ee  try3.wav
62e4a8485c02ee1122d6aa61907cd1ee  try4.wav

All 4 rips return the same files. I hate to say it, but I almost wonder if it did cache with cdda2wav and that's why it didn't do any correction.

The drive used for ripping is a Sony DDU 1621; I'm running kernel 2.6.12.

Originally Posted by Chachi420

so...my dbpoweramp program is not acceptable??

I used to use dbpoweramp to rip until i came across a couple errors from rips. I ran the same discs through eac and had no problem.

does anyone know if error correction is 100% effective (or atleast close)? I know everyone in the trading community is pretty set on good quality media but would it matter so long as the disc was run through eac?

[ffooky]

Originally Posted by jazzbo

All 4 rips return the same files. I hate to say it, but I almost wonder if it did cache with cdda2wav and that's why it didn't do any correction.

Hmm...it's certainly looking that way according to your results.

I've never managed to get any discs with "edge" values, they're pretty much all either fine or have "atom" values and even EAC can't do anything about those.

I've always assumed that the bank of red lights in EAC display when error correction is taking place so when I get a couple of rows of lights in a track which then produces a matching rip with xACT/cdda2wav, I take that as proof of correction.

Anyway, your results were very interesting, if a little disheartening, but it'd be nice to get a definitive answer from someone and even nicer if someone would take up development of cdparanoia.

[ffooky]

Right, I don't know how illuminating this is but I managed to find a disc that only produced some "edge" errors and ripped it with EAC, xACT (cdda2wav w/paranoia) and cdparanoia.

The drive used was 'PIONEER ' Model 'DVD-RW DVR-107D' Revision '1.21'.

Throughout here I've removed paths and (I hope) redundant text where necessary to make things more readable.

First I ripped with EAC

EAC extraction logfile from 1. October 2005, 11:39 for CD

Weezer / Buddy Holly (EP)

Used drive  : MS   Adapter: 1  ID: 0
Read mode   : Secure with NO C2, accurate stream, disable cache
Read offset correction : 0

Overread into Lead-In and Lead-Out : No

Used output format : Internal WAV Routines

                     44.100 Hz; 16 Bit; Stereo

Other options      : 

    Fill up missing offset samples with silence : Yes
    Delete leading and trailing silent blocks : No
    Native Win32 interface for Win NT & 2000

Track  3

     Filename C:\Documents and Settings\Waldo Jeffers\Desktop\Buddy Holly EAC\03 Surf Wax America (Live Version).wav


     Peak level 96.3 %
     Track quality 100.0 %
     Test CRC E38800B9
     Copy CRC E38800B9

     Copy OK

Track  4

     Filename C:\Documents and Settings\Waldo Jeffers\Desktop\Buddy Holly EAC\04 Jamie (Geffen Rarities LP Version).wav

     Peak level 81.7 %
     Track quality 100.0 %
     Test CRC 3618AA62
     Copy CRC 3618AA62

     Copy OK



No errors occured

End of status report

No error correction lights were lit during the extraction but the peak level value for Track 4 seems to show that re-reads were necessary.

Next up are three rips with xACT:

#Cdda2wav version 2.01a32_darwin_7.4.0_power-macintosh_powerpc, libparanoia support
using lib paranoia for reading.

100%  track  3 'Surf Wax America (Live Version)' recorded with minor problems

100%  0 rderr, 0 skip, 0 atom, 2 edge, 0 drop, 0 dup, 0 drift

100%  249 overlap(0.5 .. 1.125)

100%  track  4 'Jamie (Geffen Rarities LP Version)' recorded with minor problems (1.4% problem sectors)

100%  0 rderr, 0 skip, 0 atom, 265 edge, 0 drop, 0 dup, 0 drift

100%  265 overlap(1.125 .. 1.125)

Rip 02

#Cdda2wav version 2.01a32_darwin_7.4.0_power-macintosh_powerpc, libparanoia supportusing lib paranoia for reading.

100%  track  3 'Surf Wax America (Live Version)' recorded with minor problems

100%  0 rderr, 0 skip, 0 atom, 3 edge, 0 drop, 0 dup, 0 drift

100%  250 overlap(0.5 .. 1.125)


100%  track  4 'Jamie (Geffen Rarities LP Version)' recorded with minor problems (1.4% problem sectors)

100%  0 rderr, 0 skip, 0 atom, 264 edge, 0 drop, 0 dup, 0 drift

100%  264 overlap(1.125 .. 1.125)

and Rip 03

#Cdda2wav version 2.01a32_darwin_7.4.0_power-macintosh_powerpc, libparanoia supportusing lib paranoia for reading.

100%  track  3 'Surf Wax America (Live Version)' recorded with minor problems

100%  0 rderr, 0 skip, 0 atom, 2 edge, 0 drop, 0 dup, 0 drift

100%  241 overlap(0.5 .. 1.125)


100%  track  4 'Jamie (Geffen Rarities LP Version)' recorded with minor problems (1.4% problem sectors)

100%  0 rderr, 0 skip, 0 atom, 266 edge, 0 drop, 0 dup, 2 drift

100%  254 overlap(0.5 .. 1.125)

Note that the "edge" values and overlaps differ between all three rips.

Lastly, two rips with cdparanoia, which produced an identical output:

eMac:~ ffooky$ cdparanoia -B -- "-4"
cdparanoia III release 9.8 (March 23, 2001)

outputting to track03.cdda.wav

 (== PROGRESS == [                             -*| 046696 00 ] == :^D * ==)   

outputting to track04.cdda.wav

 (== PROGRESS == [------------------------------*| 066081 00 ] == :^D * ==)   

Done.

Note the constant jitter correction on Track 04 and slight correction for track 03.

Here are the results:

76ceab472c728fabbb5166d694ed13be  [shntool]  EAC_t04.wav
497017126cfc3255bee0efc35a90632d  [shntool]  CDP_rip01_t04.wav
497017126cfc3255bee0efc35a90632d  [shntool]  CDP_rip02_t04.wav
cda0c5e693b965bdd60d73735e8c9692  [shntool]  xACT_rip01_t04.wav
cda0c5e693b965bdd60d73735e8c9692  [shntool]  xACT_rip02_t04.wav
cda0c5e693b965bdd60d73735e8c9692  [shntool]  xACT_rip03_t04.wav

I've omitted the results for Track 03 as they were bit identical for all six rips which surprised me considering the Peak level, "edge" value and jitter correction results.

I then ran EAC's compare WAVs function:

EAC rip compared to xACT's gave "441 repeated samples 0:00:00.168" (on the EAC side of the comparison table).
EAC rip compared to cdparanoia's gave "96 repeated samples 0:00:00.176" (on the EAC side of the comparison table).
xACT rip compared to cdparanoia's gave "345 repeated samples 0:00:00.168" (on the cdparanoia side of the comparison table).

These are the sort of results I'd expect to see if I ripped with xACT etc and then compared with an offset-corrected EAC rip but I made sure to remove offset correction for this test (see EAC log).

I'd need to know what an "edge" value actually means to evaluate these results properly, in fact I'd like to know what all the values that cdda2wav gives mean. I already know that any "atom" value means "you ain't going to get a guaranteeable rip" but I'm at a loss with the rest.

The only conclusion I can come to is that I'm minded to agree with jazzbo that the cache is not flushed between reads with cdda2wav.

Bugger!

[jazzbo]

Originally Posted by ffooky

Anyway, your results were very interesting, if a little disheartening, but it'd be nice to get a definitive answer from someone and even nicer if someone would take up development of cdparanoia.

What worries me too, is I can't even find much development is going on of cdda2wav either. I had the hopes of looking at the changelogs for the code and see if it mentioned any enhancesments over the base cdparanoia code.

Source can be found, but none of the 'official respositories' for the project seem to work: http://www.cdda2wav.de/

[ffooky]

Blimey, just out of interest I ripped the offending track with iTunes 5.01 (w/error correction), Toast 7.0.1 and by dragging the track to the Finder (OS X 10.3.9)

76ceab472c728fabbb5166d694ed13be  [shntool]  Finder.aiff
76ceab472c728fabbb5166d694ed13be  [shntool]  iTunes.wav
76ceab472c728fabbb5166d694ed13be  [shntool]  Toast.wav

Compare this to the rips with the previous apps.

76ceab472c728fabbb5166d694ed13be [shntool] EAC_t04.wav 
497017126cfc3255bee0efc35a90632d [shntool] CDP_rip01_t04.wav 
497017126cfc3255bee0efc35a90632d [shntool] CDP_rip02_t04.wav 
cda0c5e693b965bdd60d73735e8c9692 [shntool] xACT_rip01_t04.wav 
cda0c5e693b965bdd60d73735e8c9692 [shntool] xACT_rip02_t04.wav 
cda0c5e693b965bdd60d73735e8c9692 [shntool] xACT_rip03_t04.wav

As you can see, Finder, iTunes and Toast produced identical results to EAC.

I give up

[ffooky]

It occurred to me that all my previous tests were performed with an internal (ATAPI) drive and that I have no idea at what point point the audio data cached by the drive is flushed. Accordingly I repeated the tests using an external (Firewire) drive, 'LITE-ON ' Model 'LTR-24102B ' Revision '5S57' which was turned on and off between each rip, except the three named "LO_UNQUIT_...."

I ripped the track that produced problems in the first set of tests, multiple times with EAC, xACT, Toast 7.0.1 and by dragging to the Finder (OS X 10.3.9). Unfortunately I was unable to include cdparanoia as I could not get it to recognise my external drive.

With the EAC rips I shut down the virtual machine, closed Virtual PC and then deleted the Undo Drive file between rips as well as turning the CD drive on and off so there was absolutely no chance of anything being cached. Error correction lights were lit (one row) at varying points of all test and copy routines.

EAC extraction logfile from 3. October 2005, 22:41 for CD
Weezer / Buddy Holly (EP)

Used drive  : MS   Adapter: 1  ID: 0
Read mode   : Secure with NO C2, accurate stream, disable cache
Read offset correction : 0
Overread into Lead-In and Lead-Out : No

Used output format : Internal WAV Routines
                     44.100 Hz; 16 Bit; Stereo

Other options      :
    Fill up missing offset samples with silence : Yes
    Delete leading and trailing silent blocks : No
    Native Win32 interface for Win NT & 2000


Track  4
     Filename C:\Documents and Settings\Waldo Jeffers\My Documents\04 Jamie (Geffen Rarities LP Version).wav

     Peak level 81.7 %
     Track quality 99.9 %
     Test CRC 58D43EC9
     Copy CRC 58D43EC9
     Copy OK

No errors occured


End of status report

Now xACT. Four rips separated by ------------ (unnecessary output omitted)

There is no sound support configured!
Type: ROM, Vendor 'LITE-ON ' Model 'LTR-24102B      ' Revision '5S57' MMC+CDDA
176128 bytes buffer memory requested, 4 buffers, 13 sectors
#Cdda2wav version 2.01a32_darwin_7.4.0_power-macintosh_powerpc, libparanoia support

Track  4: 'Jamie (Geffen Rarities LP Version)'
samplefile size will be 45593564 bytes.
recording 258.4666 seconds stereo with 16 bits @ 44100.0 Hz ->'audio'...
using lib paranoia for reading.
percent_done:
100%  track  4 'Jamie (Geffen Rarities LP Version)' recorded successfully

100%  0 rderr, 0 skip, 0 atom, 0 edge, 0 drop, 0 dup, 0 drift

100%  258 overlap(0.5 .. 0.5)

----------------------------------------------
recording 258.4666 seconds stereo with 16 bits @ 44100.0 Hz ->'audio'...
using lib paranoia for reading.
percent_done:
 100%  track  4 'Jamie (Geffen Rarities LP Version)' recorded successfully

100%  0 rderr, 0 skip, 0 atom, 0 edge, 0 drop, 0 dup, 0 drift

100%  258 overlap(0.5 .. 0.5)

-----------------------------------
recording 258.4666 seconds stereo with 16 bits @ 44100.0 Hz ->'audio'...
using lib paranoia for reading.
percent_done:
 100%  track  4 'Jamie (Geffen Rarities LP Version)' recorded successfully

100%  0 rderr, 0 skip, 0 atom, 0 edge, 0 drop, 0 dup, 0 drift

100%  258 overlap(0.5 .. 0.5)

----------------------------------------
recording 258.4666 seconds stereo with 16 bits @ 44100.0 Hz ->'audio'...
using lib paranoia for reading.
percent_done:
100%  track  4 'Jamie (Geffen Rarities LP Version)' recorded successfully

100%  0 rderr, 0 skip, 0 atom, 0 edge, 0 drop, 0 dup, 0 drift

100%  258 overlap(0.5 .. 0.5)

As you can see, the output from the four rips was identical and no errors or problem sectors were reported.

The results

7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_EAC1.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_EAC2.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_EAC3.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_EAC4.wav
a5fdea1a598f2a68be6e55585107ebf2  [shntool]  LO_Finder1.aiff
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_Finder2.aiff
7b826dea52078c8cea25847fd361c985  [shntool]  LO_iTunes1.wav
4876a55f547c70f000ee8ace94ef2a27  [shntool]  LO_iTunes2.wav
f6a027fea6664bfec81e39deb61ea2b1  [shntool]  LO_iTunes3.wav
b9610ce44fadcc4da5bfef3271ce7d41  [shntool]  LO_Toast1.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_Toast2.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_UNQUIT_Finder.aiff
4fe6f039c146db5489b7ce10acfac10a  [shntool]  LO_UNQUIT_Toast.wav
bb580449b92e51764678c1d41f4f7df8  [shntool]  LO_UNQUIT_xACT.wav
92136c8a759964fe0b359f5607b8c717  [shntool]  LO_xACT1.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_xACT2.wav
243eb0cae251aa05d00531e063fae24d  [shntool]  LO_xACT3.wav
bb580449b92e51764678c1d41f4f7df8  [shntool]  LO_xACT4.wav

The obvious and most important features of the results are firstly that EAC produced identical files from all rips and its accuracy under VPC should not be questioned. Secondly and most perturbingly, it's clear that a clean bill of health in an xACT output is absolutely no guarantee of an accurate rip. Four rips, four clean output logs and four non-matching checksums.

It surprised me that this drive produced error correction lights with EAC and no problem sectors with xACT whereas with the Pioneer, the results were reversed.

I'm afraid this appears to rule out xACT as a guaranteeable ripper, even with an unblemished output log. The only get-out clause may be that the LiteOn is just not compatible with cdda2wav and in the interests of exhaustiveness I ought to try multiple rips with xACT using the internal Pioneer, rebooting (maybe even shutting down completely and starting up) between each one to see if it will produce matching data w/a clean output log. Maybe another time

[jazzbo]

Originally Posted by ffooky

I'm afraid this appears to rule out xACT as a guaranteeable ripper, even with an unblemished output log.

I don't think a worse outcome (for non-Windows platforms) could have came out of this. After looking at your extensive testing -- I may go back and give cdparanoia and/or cdda2wav a little more of a workout under Linux but I don't have a lot of hope.

I'd prefer not to do a lot of reboots so maybe I'll just rip a whole CD, rip another, and take the first again and see how they compare.

[Beleaguered]

ffooky,
Can you check and see it it's really the audio data that's different or if there's just a difference in the read offset/lead-in. I believe EAC has a wave comparer.