CD-R quality (was Re: Shameless CDR vs CD questions)
Paul Mather
paul at GROMIT.DLIB.VT.EDU
Mon Feb 18 07:51:41 EST 2008
On 13 Feb 2008, at 8:07 AM, John Rennie wrote:
> A boffin starts:
>
> Data CDs can be copied as many times as you like, and barring
> failures of your CD drive all the copies will be identical.
>
> However audio CDs are not encoded onto the disk in the same way as
> data CDs. Different CD drives will read the same audio CD and return
> different data depending on the exact way they process the data on
> the audio CD. That's one reason why expensive CD players sound better
> than cheap ones.
That's partly true, but a little misleading. It's true, as you say,
that data CDs and audio CDs are encoded differently on the disc,
although the low-level encoding (e.g., 8-to-14 coding and Reed-Solomon
cross-interleaved error correcting code) is the same. On data CDs,
each sector encodes 2048 bytes of application-level data; on an audio
CD, each frame (sector) encodes 2352 bytes, which represents 588 16-
bit stereo samples (or 1/75th second of CD-quality audio @ 44.1 KHz).
The data CD gets less data per sector because they use some of the raw
sector data for extra data integrity checking: it's more important
that you detect that the balance in your bank spreadsheet file has
erroneously changed than some audio samples in a frame. The former
would be potentially catastrophic, whereas the latter would probably
be perceptually unnoticeable.
(BTW, the main reason expensive CD players sound better than cheap
ones is due mostly to the better quality of the analogue components.)
> So if you take an original CD, copy it and burn the copy to a CDR,
> the copy will be close to the original but not identical. If you make
> a second generation copy the second copy will be different again, and
> so on. The recording speed won't make any difference. The difference
> comes only from the way the electronics in the CD drive extract data
> from the audio CD.
It's not true that you can't make a bit-identical copy of an audio
CD. You just need to take certain safeguards. The main trouble CD
drives have in extracting audio data is deciding exactly where audio
frames begin. Between different drives, there can be a sector sample
offset, particular to the drive, which represents the offset between
the true frame start and the one delivered to the extractor
application. (To complicate matters, CD writers also have a write
sector sample offset.)
So, to make bit-identical copies, you need: a) decent CDDA extraction
software aware of the issues (e.g., EAC; cdparanoia; etc.), and b) to
calibrate your CD drive. There are lots of tutorials on how to do
this, via a variety of mechanisms, on the Web. (E.g., do a search for
"EAC sample offset".) Some extractors, like EAC and dBPowerAMP
support AccurateRip, which lets you calibrate your drive with respect
to a database of known pressed CDs and even compare your rips with
others.
Once you have calibrated your drive, you can make second-generation
copies that are verifiably identical to the first-generation ones.
(Note, also, that firmware support for accurate CDDA extraction has
improved enormously since the early days.)
To return to the original query, a lot of the problems with copying
CDs stems from trying to do real-time (i.e., one-pass, burst-mode)
style copies. In those cases, the emphasis is on speed, not accuracy,
and so errors can be passed through. Doing a secure extraction to an
image file that you then burn as the copy is a much better way to
ensure fewer (or no) errors in the copy, because the extractor can
take greater pains to detect and correct (via re-reading) bad source
data. For example, EAC operating in secure mode is different to the
way it operates in burst mode. The former is much more preferred for
bit-identical copies, even though it may be slower.
I hope this helps.
Cheers,
Paul.
e-mail: paul at gromit.dlib.vt.edu
"Without music to decorate it, time is just a bunch of boring production
deadlines or dates by which bills must be paid."
--- Frank Vincent Zappa
More information about the boc-l
mailing list