Ripping CDs: is ‘lossless’ really lossless?

[Tod]

I read somewhere recently that ripping CDs using iTunes / Apple Music does not produce an exact copy of the digital data, even when using a lossless format such as ALAC. According to the author, Apple’s error correction somehow interpolates for ‘absent’ data caused by scratches, etc. such that the ripped copy sounds different to the original CD.

Is this true? I have been ripping my CDs for years and wouldn’t want to start again.

 

[charleski]

FUD

Error correction is built into the basic CD specification, it has nothing to do with iTunes. Data is encoded on the disc in a highly redundant fashion (each 8 bits of data are expanded to 14 actually stored on the disc), and a disc would have to be severely damaged for it to need to interpolate data that has truly been lost. Such extensive damage almost always affects the track alignment as well, so the CD will fail to read properly.

 

[theREALdotnet]

Clicks and skips are not at all uncommon when playing CDs that are scratched or scuffed (not even severely but just the right way). Ripping such CDs will likely yield a better if not error-free result than playing them in a CD player, simply because the ripping software is not bound by realtime constraints and can try reading a block as often as it takes.

iTunes uses the cdparanoia library I believe (at least it did way back then), and you can enable an option called “User error correction when reading Audio CDs” which comes with a warning that ripping could take longer when enabled.

If you want to be sure what you get use the command line version of cdparanoia (or a modern equivalent such as EAC), which will tell you exactly how many errors were encountered and how many were uncorrectable.

In any case, a rip that is not error-free will not sound worse, as in “thin bass”, “veiled mids”, ”collapsed soundstage” or any of that nonsense – it will simply have short drop-outs or clicks, possibly audible.

 

[Frank Sol]

+1 on EAC

 

[Atanasi]

Audio CDs have less reliable error-correction compared to data CDs. It was considered acceptable that audio could not always be read bit-perfectly, and drives would compensate imperfect sectors with interpolation. On the other hand, one failed sector of a data CD could render the whole disc unusable. One sector of an audio CD has 2352 bytes of payload (1/75 seconds of CD audio), but one sector of a data CD has only 2048 bytes of payload, and the difference is used for better error-correction. CD rippers that try to reconstruct bit-perfect results usually read each sector twice and check that the results are identical. If the results are identical, it is assumed that the read was successful, otherwise the ripper would perform more retries and try to reconstruct the sector from those.

Retries are complicated because different CD drives exhibit different behavior when reading audio CDs. One of the main complications is caching. The ripping program has to make sure that the cache is emptied before retrying a sector, otherwise the sector is not physically read and the cached result is produced instead.

It has been a while since I have last ripped CDs, but I think EAC had better retrying and reconstruction algorithms than cdparanoia, but I don't know if cdparanoia has been updated.

 

[AnalogSteph]

In this day and age, it is also easy to verify rip integrity of any not-entirely-exotic CD against crowdsourced online databases, such as the AccurateRip and CUETools (CTDB) ones. If you enable CTDB metadata in EAC, it'll check both. CTDB has the additional advantage of also being able to tell you if a track matches bar a limited number of samples, and CUETools on your computer can also be used to repair a rip under these conditions (or rather, spit out a new copy that's fixed). If you have any doubts about your rips you can always download the program and check them.

I have found that this tends to work much better than letting EAC chew away at problematic tracks in secure mode for hours on end. One CD I dragged home from a thrift store lately turned out to have a nasty tangential scratch about 2 cm in length (and some lesser ones), the absolute worst kind to have as it tends to throw off laser tracking. The affected track ripped in burst mode was reported to "differ in 40097 samples" across an interval of about 20 seconds. The same after finally finishing in secure mode after 2 hours (no kidding) gave "no match", which can't even be repaired. So I used the first version for the repair, which I could have done a lot earlier...

(Now this particular type of defect may be particularly problematic for EAC's secure mode strategy, which tries to read the same sectors over and over. "Glossing over" the problematic area at 24X speed may not give the pickup enough time to get upset, whereas reading a small portion at much lower speed may return garbage a lot of the time.)