I’ve happily been using cdparanoia to rip my CDs for years. In the last few days, however, I’ve been finding out things about CDDA extraction in general and cdparanoia in particular that made my bit-exact confidence in my ripped CDs drop to zero. I was trying to exactly recreate a CD by reading the TOC and audio data with cdrdao and then burning it to a CD-R. Ripping the CD-R and comparing it with the original rip showed that the waves did not line up exactly, they were slightly shifted. A little googling revealed that most CD drives read audio data offset by a fixed number of samples that is constant for each drive. I found the offsets for my CD drives from the AccurateRip website, verifying them by ripping the same track with both drives using the offsets (cdparanoia has a –sample-offset option). However, burning a new CD-R with the new audio still didn’t produce an exact duplicate… it turns out that there’s an offset when burning too. Never mind.
When researching the offset issue I found several mentions that cdparanoia was not safe with caching drives, which is worrying as my NEC burner has a 2 MB cache. I tried ripping a scratched CD twice and comparing the resulting waves. They were not the identical. Evidently, cdparanoia with a caching drive is no better than any other cd ripper, perhaps worse since it gives false confidense in the rips. It seems that no development on cdparanoia has been done for the last five years but when asking on paranoia-dev, I learned that libcdio has incorporated cdparanoia with some improvements, although the cache-problem is said to still be unsolved.
Finally, there’s one more thing to get paranoid about which I haven’t seen discussed anywhere. When using cdparanoias –sample-offset option on my LG drive with an offset of +594, ripping the last track of an album fails because of a read error. This is not very surprising because a sector on a CD is 588 samples which means that at least some samples must be read by asking the CD drive to read from a sector which doesn’t exist. Ripping with my NEC burner (offset +48) does not fail in the same way, but a little testing showed that the last 48 samples of the last track were set to zero. Most albums I’ve checked have thousands of zero-samples at the end of the last track, but I found a few which did not where 48 samples (1 millisecond of audio) were lost. This doesn’t matter at all on my drive, but some drives have much bigger offsets. Also, verifying cdparanoia rips with something like AccurateRip (if it should be released as Free Software) is impossible if these samples have been lost.
In summary, there’s work to be done before we can have perfect CD rips using only Free Software.