[TriLUG] why can't I dd an audio CD?

[Nick Goldwater]

----- "David Black" <dave at jamsoft.com> wrote:

| From: "David Black" <dave at jamsoft.com>
| To: "Triangle Linux Users Group General Discussion" <trilug at trilug.org>
| Sent: Friday, December 26, 2008 9:53:25 AM GMT -05:00 US/Canada Eastern
| Subject: Re: [TriLUG] why can't I dd an audio CD?
|
| ----- "Joseph Mack NA3T" <jmack at wm7d.net> wrote:
| 
| > I guess silicon was expensive in 1980 (or thereabouts). But 
| > then they had to handle the pops and squeaks you mention. 
| > The would seem to require much more Si, but then the pops 
| > and dropouts are being handled by the CPU (sort of like the 
| > winmodem).
| 
| I've read that errors are masked by CD audio players by replaying the
| previous sample for minor errors or muting the output for longer
| stretches - both easy to do in silicon.  The pops/squeaks I mention
| pertain to DAE and are primarily caused by marginal DAE
| implementations in drives.  Some drives are much better at DAE
| (ripping) than others.   A clean and new audio CD will play at 1x
| speed without any audible defects, and the few that are there are
| easily masked.  When you start ripping with DAE at multiples of that
| speed, it gets more complicated.

Below is an excerpt from Andy McFadden cd-r faq that expands on DAE & a
link to additional information on error correction/detection.
http://tinyurl.com/8e677m

"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."



| 
| > >> I would assume then that video DVDs are also different from
| > >> data DVDs in much the same ways.
| > >
| > > Fortunately they got it right with DVD-Video.  It's just a 
| > > restricted case of DVD-ROM and uses the same, strong error 
| > > correction.  You *can* "dd" a DVD-Video disc.
| > 
| > hmm Commercial DRM'ed DVD movie
| > 
| > dd if=/dev/dvd of=foo.out
| > 
| > about 2M of output
| > .
| > .
| > Error: Illegal request
| > Read of scrambled sector without authentication.
| >
| > I take it that you're talking about DVD-Videos you make 
| > yourself then
| 
| After you play a commercial DRMed movie with an approved software
| player, the DVD drive is authenticated at that point and the data may
| be dd-ed - albeit scrambled.  Homemade discs don't need the
| authentication step.  DRMed or not, the DVD-Video and DVD-ROM formats
| are a series of 2048 byte blocks on the disc.
| 
| > I need to know more about the filesystem to understand why 
| > this is so. I'd assumed since you could mount the audio CD 
| > as a cdfs filesystem and then copy all the wav files to your 
| > harddisk, that a CD was just another piece of hardware with 
| > a known normal filesystem.
| 
| You decide whether CD-DA qualifies as a filesystem: it's a simple TOC
| with a list of sector offsets for each track (song) as track 1, plus
| the tracks 2-n themselves.  When a sector offset is requested, the
| drive starts playing audio at *approximately* the specified offset. 
| Cdfs is cool but gives the appearance of something not really there on
| the disc.   I have tried cdfs just as a curiosity and never use it to
| copy audio data.  Wonder if reading a track multiple times using cdfs
| yields .wav files of slightly different lengths, or at least shifted
| according to where the drive starts streaming bits for the instance of
| the read?
| 
| > so dd is just sitting in a loop fetching consecutive block 
| > numbers and the hardisk handles finding the blocks (which if 
| > it's a spare block, will be in the spare area).
| 
| You got it.
| 
| > So how does a tape drive work? Are the blocks numbered? I 
| > assumed the blocks were unnumbered and consecutive and the 
| > drive just kept reading blocks till it found the file or 
| > EOT.
| 
| Tape drives I've dealt with over the years all have the notion of file
| numbers plus block numbers within each file.  The block size can be
| set to a fixed or variable value.  The drive itself usually doesn't
| know how many files and blocks are on a tape: outboard software has to
| take care of that by writing a TOC or keeping that info in a file. 
| The drive navigates around by looking for EOF and EOT marks detectable
| even at high tape movement speeds.
| 
| > In an audio CD then the blocks aren't numbered and the drive 
| > has to pick its way though the CD hopefully picking up the 
| > next block each time.
| 
| The sectors are numbered but in CD-DA mode the request to start
| playing at a certain sector starts streaming audio with limited
| accuracy.  It could be many samples behind or into the actual start of
| the referenced sector.  That's why the standard specifies two-second
| gaps between tracks.
| 
| > I've always assumed by the time you see your first badblock, 
| > you've used all your spares and the surface is loosing 
| > integrity pretty fast.
| 
| Yeah, it means the surface is degrading faster than the drive
| designers expected - a good reason to copy off anything important and
| toss the thing.
|  
| Dave
| -- 
| TriLUG mailing list        :
| http://www.trilug.org/mailman/listinfo/trilug
| TriLUG FAQ  : http://www.trilug.org/wiki/Frequently_Asked_Questions