I bought a brand new CD, and when I was removing it from its cardboard slipcase, I scratched the disc.

When I ripped the disc with cdparanoia, it appeared to rip without error. However, the resulting WAV was filled with audible clicks and pops.

Just for kicks, I put the CD in a Windows box (different hardware) and ran EAC. The resulting WAV sounded perfect, with no audible problems.

I then went back to my Linux box, and ripped the disc with cdrdao. Cdrdao reported that it "Found 351 Q sub-channels with CRC errors." I then used bchunk to generate WAV files of the tracks, and listened to the problematic track. It sounded perfect -- like the EAC rip.

I've studied the cdparanoia manual page, and tried ripping the problem-track any number of different ways. cdparanoia doesn't even *complain* about the track -- it displays constant smiley faces and never aborts even when I tell it to "abort-on-skip".

Strangest of all, when I rip the track with cdda2wav (no paranoia), it sounds fine. I even get a bit-for-bit match with my cdrdao-ripped file. I expected cdda2wav -- with its lack of error correction -- to be the least reliable.

I've noticed that cdparanoia hasn't been updated in a *long* time (March, 2001). My drive (ATAPI plextor 40/12/40A) is newer than that. Does my drive have some kind of built-in error correction that cdparanoia isn't smart enough to use? Why is cdparanoia not working for me? Has anybody else experienced issues with it?

Your drive probably caches audio data.

AFAIK, in that case cdparanoia's error correction doesn't work.

Well, until now tests have proven that CDEx is not reliable for drives that cache audio. There have been no real reliability tests using cdparanoia itself. And apparently there is an important difference:
http://www.hydrogenaudio.org/forums/index....howtopic=16188&

Now, christopher_farley's results seem to suggest that cdparanoia itself may also be unreliable. This is interesting to know, since spath mentioned that code to utilize the FUA bit is used in cdparanoia.

Note to self: please make some time to do the cdparanoia vs CDEx vs EAC test you've wanted to do for weeks now......

Maybe this will be interesting, but:


cdda2wav (compiled with libparanoia support and using the -paranoia flag) gives me a good rip.

cdda2wav with no -paranoia gives me a good rip.

grip (using libparanoia) gives me garbage

cdparanoia command line gives me garbage

cdrdao always gives me a good rip.


These results are all pretty repeatable on my hardware, using my scratched disc.

I check my files with an md5 hash, and all the "good rips" are equal to each other. Strangely, EAC gives me (audibly) a good rip, but I can't get a matching md5 hash. I may try harder later tonight...

It sure seems strange that the drive caches uncorrected audio data. I've played the disc in two CD players and it sounds fine.

What drive are you using and what are the other details on the system you were using for the test? What are the exact command line parameters and/or preferences settings that you are using on each software package?

That is important information for a valid comparison.

The gritty details:

The OS: Gentoo Linux (kernel 2.4.23)
The drive: PLEXTOR CD-R PX-W4012A, firmware V1.05
Computer: EPIA-M 9000 (Via C3 processor)
The disc: John Coltrane's Giant Steps, with a scratch affecting the end of track 11, and the beginning of track 12.
Cdda2wav version: 2.0_linux_2.4.20_i686_via-ezra, real time sched., soundcard, libparanoia support
Cdrdao version: 1.1.7
Cdparanoia version: cdparanoia III release 9.8 (March 23, 2001)

Rips are analyzed by converting all WAV files to raw "CDR" audio with sox, ie: `sox test.wav test.cdr`. Because some ripping methods append the next track's pregap to the end of the current track and some don't, I analyze only the beginning of each file using 'head' or 'dd'.

Some test rips:

test1 - CDDA2WAV:


test2 - CDPARANOIA:


test3 - CDDA2WAV with -paranoia:


test4 - CDRDAO:


test5 - EAC:
Ripped with "Test & Copy Selected Tracks --> Uncompressed"
Copied the wav to my Linux box, and converted to cdr as above
Different drive, computer, and OS.

RESULTS
File sizes:

test1.cdr: 76091904
test2.cdr: 76091904
test3.cdr: 76091904
test4.cdr: 75355728
test5.cdr: 76091904

md5 hashes: (`head testx.cdr | md5sum`)

test1.cdr: e18c043fdbb25322593030439203680c
test2.cdr: bf47654535e0de14ee9e56b51bc02882
test3.cdr: e18c043fdbb25322593030439203680c
test4.cdr: e18c043fdbb25322593030439203680c
test5.cdr: 5058d55c95dd4ba49da849b7df0c8931


All files sound pretty much perfect except test2, which has numerous pops.

> I've noticed that cdparanoia hasn't been updated in a *long* time
> (March, 2001). My drive (ATAPI plextor 40/12/40A) is newer than that.
> Does my drive have some kind of built-in error correction that
> cdparanoia isn't smart enough to use? Why is cdparanoia not working
> for me? Has anybody else experienced issues with it?

Ok, first of all no DAE software perform any error correction : when
dealing with scratched discs they try to read multiple times the same
sector and/or try to mask errors. And since each program uses its own
algorithms, the result can differ. However, none of them changes the
error correction strategies used by the drive, so your recent drive
is not a problem.

Now cdparanoia has no masking algorithm and a bad retry strategy, which
explains your bad results. As you noticed its error detection is flawed
(so that it will not retry when it should) and from my experiments cache
handling and statistical combining also don't work as the author claimed.
Its '-z' option might help a bit in your case, but not much. Finally you
should know that a plextor drive with Plextools on windows is a killing
combination for DAE, so it could be worth exchanging the drives of your
two boxes.

But what confuses me is that cdda2wav, when used with the "-paranoia" flag, still gives good results. Oddly, while programs like grip (which also fails) and cdparanoia itself link to libcdda_paranoia, cdda2wav does not use this shared library. Instead, it looks like source from Monty Schilling's cdparanoia-III-alpha9.8 is distributed with cdda2wav, and compiled right in. Same deal with cdrdao.

In any case, both grip and cdparanoia have something wrong with them (on my system), while cdrdao and cdda2wav seem to work okay.


(Also, I have not been successful in getting ANY EAC rip to match the hashes I am getting from both cdda2wav and cdrdao, scratches or no scratches. It just makes me curious.)

Spath, can you please elaborate a bit more over this ? Why the combination you mentioned is so bad for DAE ?
Thanks.

I think you misunderstood spath. He means that Plextor with Plextools is an excellent combination ("ultimate" combination, "killing" combination, whatever...).

And I tend to agree. Too bad Plextools doesn't have many of the features of EAC. (CUE sheets, anyone?)

Note that the OP has a Plextor drive in his Linux box. Spath's suggestion is to move this Plextor drive to his Windows box and use Plextools for DAE.

This is most probably caused by different read-offsets of the two drives.

Day..


i did a rip from a relatively bad cd..
(bad sectors.. scratch.) and compared
EAC 0.95 prebeta4.. Foobar 0.7.6
cdda2wav -paranoia (Version 2.01a20_cygwin32_nt_1.5.5(0.94-3-2)-i686.)
and isobuster 1.5..
(i did not run CDex atm..)

i do not have any numbers for ya..
but all did came out bit like..
(except foo/akrip..)
this is a asus cdr5224a
which i am quite happy with.. (takes long time to spinnup though..)

Ok, just to summarize here (kill me if I am mistaken):

* cdparanoia isn't reliable
* CDEx is claimed not to be reliable

Let me just add that I have a number of examples of 'diffs' between "perfect" rips (of mirror-blank cds) made with both EAC and PlexTools.

I still haven't understood why that should be the case, but for the time being I am jotting it down to PlexTools being the inferior ripper.