Second, I apologize for beating a dead horse, but in the event that a few people read my earlier posts, I wanted to make a correction to what I originally wrote. In particular, the statement that "there is no error correction" on audio CDs is wrong. The following (taken from ttp://www.cdrfaq.org/faq02.html) is rather long, but interesting:
Subject: [2-15] What are "jitter" and "jitter correction"? (1998/04/06) (below) Subject: [2-17] Why don't audio CDs use error correction? (2007/08/08) (below) On 7/6/2010 2:27 AM, Mark Allums wrote:
On 7/5/2010 3:43 PM, Urs Thuermann wrote:Now my question is where these [CD-rip] differences come from and which results are the correct (better) ones.
Audio CDs live in a world where there is no guarantee that any two passes across a "sector" will ever give the same result. For one thing, there is no error correction. Give up the idea of getting a correct, or "perfect", rip; it's theoretically impossible. In fact, that's why cdparanoia exists. In the days of CD-ROM drives, the drives were not very good at ripping audio discs, and cdparanoia compensated for the problems. It was also unbelievably slow. Today, DVD drives have a much better disc transport, etc., and a lot of software is smarter than it used to be, so ripping is only a real problem with copy-protected CDs, and very damaged discs.
Subject: [2-15] What are "jitter" and "jitter correction"? (1998/04/06)The first thing to know is that there are two kinds of jitter that relate to audio CDs. The usual meaning of "jitter" refers to a time-base error when digital samples are converted back to an analog signal; see the jitter article on http://www.digido.com/ for an explanation. The other form of "jitter" is used in the context of digital audio extraction from CDs. This kind of "jitter" causes extracted audio samples to be doubled-up or skipped entirely. (Some people will correctly point out that the latter usage is an abuse of the term "jitter", but we seem to be stuck with it.)
"Jitter correction", in both senses of the word, is the process of compensating for jitter and restoring the audio to its intended form. This section is concerned with the (incorrect use of) "jitter" in the context of digital audio extraction.
The problem occurs because the Philips CD specification doesn't require block-accurate addressing. While the audio data is being fed into a buffer (a FIFO whose high- and low-water marks control the spindle speed), the address information for audio blocks is pulled out of the subcode channel and fed into a different part of the controller. Because the data and address information are disconnected, the CD player is unable to identify the exact start of each block. The inaccuracy is small, but if the system doing the extraction has to stop, write data to disk, and then go back to where it left off, it won't be able to seek to the exact same position. As a result, the extraction process will restart a few samples early or late, resulting in doubled or omitted samples. These glitches often sound like tiny repeating clicks during playback.
On a CD-ROM, the blocks have a 12-byte sync pattern in the header, as well as a copy of the block's address. It's possible to identify the start of a block and get the block's address by watching the data FIFO alone. This is why it's so much easier to pull single blocks off of a CD-ROM.
With most CD-ROM drives that support digital audio extraction, you can get jitter-free audio by using a program that extracts the entire track all at once. The problem with this method is that if the hard drive being written to can't keep up, some of the samples will be dropped. (This is similar to a CD-R buffer underrun, but since the output buffer used during DAE is much smaller than a CD-R's input buffer, the problem is magnified.)
Most newer drives (as well as nearly every model Plextor ever made) are based on an architecture that enables them to accurately detect the start of a block.
An approach that has produced good results is to do jitter correction in software. This involves performing overlapping reads, and then sliding the data around to find overlaps at the edges. Most DAE programs will perform jitter correction.
Subject: [2-17] Why don't audio CDs use error correction? (2007/08/08)Actually, they do. It is true that audio CDs use all 2352 bytes per block for sound samples, while CD-ROMs use only 2048 bytes per block, with most of the rest going to ECC (Error Correcting Code) data. The error correction that keeps your CDs sounding the way they're supposed to, even when scratched or dirty, is applied at a lower level. So while there isn't as much protection on an audio CD as there is on a CD-ROM, there's still enough to provide perfect or near-perfect sound quality under adverse conditions.
All of the data written to a CD uses CIRC (Cross-Interleaved Reed-Solomon Code) encoding. Every CD has two layers of error correction, called C1 and C2. C1 corrects bit errors at the lowest level, C2 applies to bytes in a frame (24 bytes per frame, 98 frames per sector). In addition, the data is interleaved and spread over a large arc. (This is why you should always clean CDs from the center out, not in a circular motion. A circular scratch causes multiple errors within a frame, while a radial scratch distributes the errors across multiple frames.)
If there are too many errors, the CD player will interpolate samples to get a reasonable value. This way you don't get nasty clicks and pops in your music, even if the CD is dirty and the errors are uncorrectable. Interpolating adjacent data bytes on a CD-ROM wouldn't work very well, so the data is returned without the interpolation. The second level of ECC and EDC (Error Detection Codes) works to make sure your CD-ROM stays readable with even more errors.
It should be noted that not all CD players are created equal. There are different strategies for decoding CIRC, some better than others.
Some CD-ROM drives can report the number of uncorrected C2 errors back to the application. This allows an audio extraction application to guarantee that the extracted audio matches the original.