I hate to sound like I'm agreeing with Mr. Vestman, because he really has got the wrong end of the pineapple (Computers crash, computers are based on ones and zeros, therefore ones and zeros are not perfect? A fallacy, just to start). But there is an important consideration, especially in copying or mastering CDs to CD-R media. It's not perfect.

This comes back to something that's been talked about here before - the fact that if you take 74 minutes of 44.1KHz 16-bit stereo music, it actually works out to fit in 783,126,000 bytes, or ~746MB (1KB=1024B). So why does the same size CD-R advertise '650MB'? Where is the extra ~100MB? Why have you lost 15% of your recording space?

The answer comes down to the way information on CDs. It's not just linear like a hard disk, because there are all sorts of issues with light phases, interference and timing when you read data optically. You can't simply encode a 1 bit as a rise and a 0 bit as a pit (for example). You have to make sure that if you're encoding a certain number of bits in a row that are the same, that there's some way of telling which bit you're actually currently reading.

This combines with the fact that even the tiniest bit of grease or dust totally and utterly changes the information coming from the disk. So the way the CD Audio format is written is that the data is expanded[1] into a form that errors can be detected and corrected completely inaudibly. That is: the media can detect and correct a certain amount of errors and this is done automatically.

However, no system is perfect and there is always a point at which you can't detect a large enough error (as Hamming showed). There are ways to reduce the effect of these errors, so most of the time you won't hear a thing. But a badly made copy of a CD, or even an original CD that has a lot of surface wear, will start physically sounding different. Given that not all CD-R dye media is the same, that it is more sensitive to the effects of time and wear (e.g. sunlight) than a metal-pressed CD-ROM, and that the faster you write the less impression on the dye you make(so to speak), there will be a point at which a copy can be differentiated from the original by ear alone.

But what of DAE, you say? If we've extracted the data from the CD digitally we don't have transcription problems, I hear you cry. And, indeed, this is partly the case. You are more likely to get the same bits off a CD as were on the original master tapes if you use DAE. And, likewise, ExactAudioCopy is better than AudioGrabber which is better than Dodgy Bob's Hi-speed Ripper, because in general the more times you read the source the more likely you are to work out which bits are correct in which copies (but you have to read at least three times in order to know positively. Proof of this is left as an exercise for the reader).

But still you have the problem of writing that information onto a CD-R. The page on Jitter that Tony mentions has a case in point - on really good quality equipment and when you know what you're listening for you can hear the difference between a write at 1x speed, 2x speed and 4x speed. And it's my prediction that all those people who think that 40x speed writers are excellent for writing copies of CDs and software will be laughing on the other side of their faces in two years time as the dye gradually loses its markings and the CDs become more unreadable. Already I'm having problems reading CDs that I wrote at 4x speed over five years ago...

So while Vestman's article is more pseudoscience, mumbo-jumbo and self-justification than anything, there is truth underneath the layer of grime...


[1] The simplest expansion encoding is 0 => 01, 1 => 10. This not only ensures that you never get more than two of the same bit in a row, but also allows one bit of error correction. If you receive the sequence 0101111010, then you can detect that the '11' pair is wrong. Depending on the way the media works you can make an educated guess as to whether this should actually represent a 1 or a 0. There are, of course, much more intelligent ways of encoding than this simple example.