OFF : CDRDAO Problems

[Paul Mather]

I'm Cc'ing this to BOC-L, where the thread originated, as folks
might be interested in the explanation, too.  I hope you don't mind.

On Thu, Mar 14, 2002 at 08:48:17PM +0000, Chris Gibbs wrote:

=> I notice their explanation of betwwen track silence is different to
=> mine.
=>
=> But why?  I definately have solved my problem.  It occured much more
=> with commercial cds though and that is at odds with what they say.   I
=> copy same cd's as one wav and no silences anymore. The faq seems to
=> suggest the silence should still be there

The silences are probably still there; they're just indexed properly
now.  Let me explain...

A track on an audio CD may have several index markers spread
throughout it.  These are encoded via subcodes, and, although you may
have many in each track, only two are really important to the
discussion in hand: index 0 and 1.

Index marker 0 denotes the start of a track.  Index 1 indicates the
start position of the track as listed in the CD's table of contents
(TOC).  In other words, index 1 is the position at which the track
will start playing when you seek to that track when playing the CD.

Any audio between index 0 and 1 is known as the "pre-gap," and
typically is silence in commercial CDs composed of individual tracks
that don't segue.  When you burn a disc "track-at-once" (TAO), the
pre-gaps default to 150 sectors, or two seconds.  When you play CDs,
the pre-gap audio is usually distinguishable by the elapsed time
counting down (negative times) rather than up.

Whether you get silence at the end of your tracks when doing DAE on
CDs depends upon how your application does it.  Almost always, when
simplistically grabbing tracks, the application will just grab all
audio between consecutive index 1 markers reported in the TOC.  So, if
you're grabbing track 5, and it starts at LBA X in the CD's TOC, and
track 6 starts at LBA Y (Y > X) in the TOC, the DAE application will
grab Y-X sectors of audio from the CD starting at LBA X.

If you've been following the discussion of encoding, you'll see that
this will include the pre-gap of track 6.  In other words, if track 6
has the 2 second gap in front of it, this silence will appear at the
*end* of the grabbed track 5.

The other method of doing DAE is to do so with respect to subcodes,
i.e., to read the audio data from the CD along with the subcode
information.  With the subcode information, it can also know where the
different index markers lie, and so can correctly recreate the disc's
layout.  (It also has the opportunity to "eliminate" pre-gaps if it
wants.)

This method is more intensive; not perfect; and won't work for all
CD-ROM drives, particularly older ones that don't support reading
subcode information.  (The other method will work with all drives,
because all drives support reading the TOC.)  There are various
heuristics that will speed up scanning for the index markers that may
miss some in non-standard discs.  For example, some "fast-TOC"
scanning algorithms will seek to the LBAs listed in the TOC minus N
seconds (N*75 sectors) and then scan that "pre-gap" area for index
markers to add to the CUE sheet.  Obviously, it will miss index
markers in discs that have very large pre-gaps.  (The only sure-fire
way is to scan the entire disc, alas.)

Cdrdao's read-toc or read-cd commands operate pretty much this way.
The CUE sheet can encode subtleties of index markers, and so can
faithfully recreate pre-gaps.

Incidentally, currently MS-Windows is superior for grabbing audio from
CDs because of the EAC software available for it (see
http://www.exactaudiocopy.de), which is not available under Unix.  I
believe it is *still* the only non-proprietary audio grabber that
correctly compensates for drive read and write sample offsets when
extracting and writing audio.  I heard once of some experimental
patches to cdparanoia to support sample offsets, but I don't think
they are in the distributed version.  Drive sample offset support
(along with your drive being able to overread into the lead-in and
lead-out) is the *only way* to *guarantee* being able to make
*identical clones* of CDDA discs (i.e., such that your DAE'd version
matches MD5s of my version).  Of course, this requires you to
configure your sample offset correctly for the drive you use, as
different drive models have different sample offsets.  The Plextor
CD-ROM I use, for example, has a sample offset of +688 samples.

That is another reason I prefer to trade SHN copies of shows, because
it eliminates the DAE step and all the potential headaches that can
introduce.

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