A question about CD-Rs

There seems to be some confusion over this issue, not least because it’s quite confusing. I used to tour the world giving trainings on just this very subject, and I know many of the people who developed the original CD-R systems, so here it is straight from the horse’s mouth:

Audio CD-Rs (and audio CD-RWs) are designed to a higher quality level than data CD-Rs (and data CD-RWs), and are more suitable for archiving valuable recordings as they will last longer. How long exactly only time will tell - maybe a few decades if they’re kept in a cool dark place.

As mentioned, they have data encoded on them that tells an audio CD recorder that royalties have been paid, and a lot of recorders (including mine) won’t record to data discs. On some models you could fool them by inserting an audio disc, letting it read the manuafcturer’s data, and then open the CD drawer a small amount by poking the emergency drawer-open hole with a bent paper clip, taking out the audio disc, and replacing it with a data disc. My recorder doesn’t have a manual tray eject, so I record everything to one scratchpad audio CD-RW, and then copy that to a data CD-R on my PC.

It’s not true that all CD-Rs are the same. They’re often very different. Avoid no-name discs, or branded discs sold suspiciously cheap from a dodgy source, as they’re probably inferior pirates that won’t last very long. Certain discs work better with certain recorders. There’s a very good reason for this - the complex laser pulses used to write the pits on the disc (know as the “write strategy”) is optimised for every manufacturer’s disc, and is different for each possible recording speed. The recorder manufacturers have to tune their designs to give the best results with a range of discs, but there are so many brands out there that not all can be tested and optimsed for. Thus the disc brands that the recorder manufacturer recommends are usually guaranteed to work reasonably well, and you take your chances with the rest.

Data is not mere data when recording audio. It’s not stored as a sequence of ones and zeros; rather they’re a series of dark coloured pits and light coloured lands that vary in length from 3 clock periods to 11 clock periods. There will be certain errors when writing and reading this data (know as jitter), and if the jitter is too high, the pit/land length is wrong. All CDs contain many such errors, but these can usually be compensated for by the redundant data in the CIRC error-checking algoriithm. Correctable false pit/land lengths are known as C1 errors, and if there are too many of these the error correction can’t cope, and uncorrectable C2 errors are produced. An audio CD player will try and smudge over these errors if it can (else it will start skipping or dropping out), but it’s a disaster for non-audio data.

Jitter figures also play a small part in CD sound quality, though this will be unnoticed by most. The clock signal for the CD is derived from the CD data, and if the data jitter is high, then the clock jitter will be higher too (though there are ways to reduce it a little). Too much clock jitter on a CD makes the soundstage a little “muddy”, even before it starts generating errors.

For best results, record with a disc brand and type as recommended by the recorder manufacturer. Record CD-Rs at half the maximum recorder speed, and CD-RWs at half the maximum disc speed (it’s a write strategy thing).

This is all a bit of a simplification - it gets much more complicated if you want it to…

I don’t beleive that there is any thing specific to audio CDRs beyond the information on then that tells some players they are audio CDRs. I am sure some brands are more suitable than otheres for long storage life. But that is the same a data CDRs.

      • The CD-Rfaq website says that there is nothing guaranteed to be “higher quality” on a CD-R encoded for audio–>see the link in my post above.
  • As to the higher-quality brands of media–some brands of disks are generally better, but different drives are particular about what brands they may or may not work well with, so there is something of a trial-and-coaster process to finding which CD-R brands your CD-R drive works well with. These differences mostly come into play with the cheaper brands; the brands of CD-R’s that are better will work in pretty much any functioning drive. …-But do note the first brand mentioned on the CDRfaq: Mitsui.
    http://www.cdrfaq.org/faq07.html#S7-4-1
    ~

I’ve seen this little tidbit (that the clock is derived from the data on the CD, and thus that the quality of the bits on the disc can effect the sound of the disc) trotted out about a million times in the never-ending debates over CD audio quality. It’s argument by repeated assertion, since there’s never a shred of evidence to back it up.

I am not a digital circuit designer myself, but I’m peripherally involved in the design and engineering of digital systems professionaly. From what I’ve picked up, I’d have to guess that it would be utterly insane to use a mechanical system (like a spinning piece of plastic) as a clock generator for a computer-controlled device (a CD player) which very probably already requires ultra-accurate crystal oscillators to run the other digital parts. I’m pretty sure it would actually be more difficult and more expensive to use the spinning disk as a clock source than to do it the right way and use an actual clock crystal as the clock source.

CDs store data at a constant linear density. CD players require data to come in at a constant rate. That means the speed of the disk must be carefully controlled by the player (and not the other way around) to maintain a constant flow of data into the player. You can hear this at work yourself, if you listen to the “tick, tick, tick” of the disc spinning in the player; the first track (the inside track) plays at something like 300RPM - about 5 ticks per second. By the time the read head gets to the outer tracks, the disc will be turning about half that speed. This isn’t because the disc is changing its mind about how fast to spin; the player controls the speed of the disc.

Even if it were practical to design a player in which the mechanical and electronic parts were matched in perfect lockstep, the CD player would still have to read the incoming data into a fairly large data buffer to function at all. (For added scratch tolerance, data isn’t stored on a CD sequentially, meaning a fair bit of data has to be read before it’s possible to decode any of it. A buffer is required for a player to function, and every CD player has one.) That buffering effectively de-couples events at the read head from events at the D/A converters. The sensible way to design a CD player would be to allow the player to control the speed of the disc in order to keep the buffer partially full, and to use a crystal-derived clock to control the speed that the buffer is emptied into the D/A converter.

I wish someone espousing the wisdom that a CD player’s clock is derived from the incoming data would exaplain why, or provide some evidence.

I absolutely agree. The CD-R FAQ is a great resource, but parts of it haven’t been updated in a long time (since July of 2003 in this case). As noted there, “Mitsui” is now “MAM-A.” But Kodak doesn’t make CD-Rs any more, TDK stopped making their own media some time ago, and even Verbatim is re-branding others’ products sometimes now.

Because these manufacturing issues change freuqently, I find that it’s more effective to use a resource like the CD Freaks Media Forum to stay on top of which media to seek and which to shun.

I am a digital ASIC designer, I agree with a lot of what you say brute force. However, I can see why early CD players would deriver the clock from the spining CD. When CDs first came out memory was expensive. In order to not buffer much data you could set up things such that the difference between a reference clock counter and a recovered clock counter stayed small. The recovered clock could be used for the data path and D to A conversion. This loop could control the rotational speed of the CD but would be subject to a fair amount of jitter. I really have no idea if that is what is done or not.

Looking these things up on the net is really hard. You get a lot of audiophile sites. You know the kind where people argue about the polarity of copper wires.

I have found some sites that all the conversion is done with the oscillator and not recovered clock.

from here
http://www.tc.umn.edu/~erick205/Papers/paper.html#jitter
and here
http://www.tc.umn.edu/~erick205/Papers/paper.html

Thank you, it’s gratifying to hear that from someone more qualified.

I’ve tried to look this up before, and I’ve had the same problems you mention. You’ve been far more successful than I ever was - that’s a great summary paper. Thanks for the link!

The block diagram (figure 1) in the paper is most legible in the PDF version, and I see that it includes a couple of RAM buffers and what appears to be a (partially?) crystal-derived clock driving the DACs. It’s probably best to not trust the block diagram in a high-level overview like this too much, but it’s great to see (and hear) that my surmising isn’t completely insane.

Guys, I’m not making this shit up, I really did use to train engineers in the finer aspects of optical recording, mostly to do with the laser end of things, and admittedly mostly DVD and Blu-Ray rather than CD. But the principles are very similar, just different levels of complexity. I know some of the guys who wrote the Red Book (and the Orange Book, and +RW and Blu-Ray specs), and I’ve had the privilege to be trained myself by some of the leading figures in the field. CD-Rs were invented at a party (it’s a long story), and were originally only for professional music studio use.

Sadly, the optical storage division I worked for got closed down (I left about a year beforehand), and the dusty display cabinet by the coffee machine that contained the world’s first prototype CD player is no more.

As for recovering the clock from the data, that is indeed how it’s done. Sure there’s a master reference clock from a crystal oscillator on the CD player/recorder, but the clock for the recovered data is derived from the data itself. You can retime it with a phase-locked loop to iron out the jitter a tad, but you’ll never get rid of it entirely. As for jitter causing a deterioration in audio quality - well that’s a whole other debate. High jitter certainly does increase the C1 and C2 Block Error Rates (BLER), and decreases the playability of a disc (that is, some players might be fussy about playing it).

For an audio CD player, the disc spin rate is set by the data/recovered clock in a tecnique known as Constant Linear Velocity (CLV), so the disc spins progressively slower as the laser pickp moves towards the outer edge. Data CDs can often be read faster in Constant Angular Velocity mode (CAV), which is actually quite tricky to do properly. Usually what is maketed as CAV is actually a number of CLV zones, and should more properly ba called Zoned-CAV (Z-CAV).

Sorry Fridgemagnet, if my tone has been unpleasant it’s just my frustration with the topic. I’m not trying to make anyone out as a fibber or a fool. It’s good to hear that you do have some connection to the matter.

It makes sense that the clock used to distinguish one bit from the next on the incoming data stream would be derived from the datastream, but I don’t understand what that has to do with the DAC clock. I don’t understand why those two clocks would have anything in common. The raw data from the read head is going to be something like 2 to 3 Mbps of serial bits, including all the EFM encoding, CIRC codes, etc. The DAC needs fully corrected and decoded 16-bit wide samples at a much lower rate.

Surely my $40 portable anti-skip CD player isn’t deriving a DAC clock from the spinning disc - the disc’s linear velocity is (very deliberately) not even close to constant.

This is indeed the case BFO; my apologies for not making this clearer in my earlier post. The playback jitter from an optical disc will be mostly a function of the jitter on the clock to the output DAC, which is derived from a crystal, not the clock derived from the disc data. Aftermarket low-jitter clocks are available to upgrade your CD player (here’s some examples from an old respected colleague at Tentlabs.)

Bad jitter on the CD data itself won’t affect audio quality (as BFO mentioned, it’s buffered) unless the jitter is so bad that C2 errors are produced.

Going back to the OP, possibly what Staple matey meant was that HP CD-Rs are more suitable for archiving photos as they have a longer life than other brands. Whether this is true or nor I don’t know. Brand of disc won’t affect picture quality - the file is either readable or it isn’t - but photos are generally required to be kept for longer than the average chunk of data burnt to CD. Future historians may curse us for losing a generation of photos, as there’s still no commercially available digital storage medium that has the robust qualities of a shoebox full of prints in the attic. A good CD-R might last 10 years if you keep it in a cool, dark place, a music CD-R should last a few decades. Hopefully.

Back when there was a TechTV, Patrick Norton would often rant about the longevity of CD-Rs. According to him, one magazine editor was doing an experiment where he kept CD-Rs in his desk drawer, and would periodically pull one out to check to see if it was still usable. He claimed that some of them barely made it 18 months. No idea of what brands these might have been or who the magazine editor was. His advice was if you really wanted to keep the stuff around, keep it on a hard drive, and make sure you transfer it to a new drive the moment it started making funny noises. Not really applicable for everyone, and not practical in every situation, but it’s something to think about.