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

[David Black]

----- "Joseph Mack NA3T" <jmack at wm7d.net> wrote:

> This is a lot more complicated than I'd expected. I don't 
> understand enough about CDs to digest his posting. Neither 
> can I see why Philips/Sony back in the early days would have 
> picked such a complicated (non-standard?) format. It can't 
> have been insanity - there must have been technical reasons 
> for it.

I've wondered about that too, and consider it likely they did so to keep the cost of the controller silicon down, using just enough error correction to allow for good-sounding audio under typical conditions, while maximizing play time (74 min.) for the total number of bits available on the physical disc.

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

> They posting talks about the difficultly turning bits on the 
> CD into audio and about the format on the CD, but it doesn't 
> directly address the problem of why you can't just dd all 
> the bits, no matter what the represent audiowise.

To get at the audio bits at all requires DAE (digital audio extraction) capability in the CD drive.  For a variety of reasons described in the cdparanoia FAQ item, if you ask DAE to do a straight, unchecked transfer of the bits, the result is somewhere between bearable to awful: skips, pops and other noise are heard in the extracted PCM audio data.  The FAQ goes into why.  Advanced software like cdparanoia is effectively an additional advanced, heuristic layer of error correction to make up for the multiple obstacles in getting a clean read of the audio.

> It must be to do with the absence of positioning and 
> synchronisation information. When you dd a partition in a 

Yes, and that's only one of several problems it surmounts with the CD-DA format and drive DAE behavior.

> hard disk, the hardware must be told "go to sector 1 which 
> is at sector x/cyclinder y/head z, now go to sector 
> 2..sector n" and when it gets to the x,y,z position, checks 
> the sector number found against what it expects. I guess I'd 
> assumed that the heads were told to go to a list of x,y,z 
> positions and read whatever was there. Clearly dd must have 

CD-DA doesn't have a functional way to do that.  It is a sector format (2352 bytes/sector) but the drive cannot accurately nor reproducably seek to a sector boundary and stream data exactly from there.   It's only approximate.

> some understanding of the low level format of the hardware, 
> and must look for the low level formatting on the disk 
> (blocks?) that mke2fs (etc) look for, to put down the inodes 
> etc.

OS and PC drive interface hardware all operate solely by requesting read/write of absolute block numbers.
The notion of C/H/S seems outdated and only still there, as far as I know, so the BIOS and first stage boot can calculate correct block numbers.  The low level stuff is entirely inside the drive and out of sight to the OS and user.   Linux and any other OS just says "gimme what's in block 176413489" and back comes the 512 bytes stored there.  It has no clue whether a spinning magnetic platter, flash RAM or carrier pigeon is behind the scenes.
 
> If this were the case, you wouldn't be able to dd a 
> completely blank harddisk that didn't have any 
> sectors/blocks on it, or a disk that had been passed through 
> an erasing alternating magnetic field.

A modern HD new out of the box has a low level format applied so it already knows exactly where all its blocks start.   For that matter, the inevitable bad blocks even in a new drive have already been mapped to spares in a dedicated, user-inaccessible area and the drive quietly continues to remap failing blocks through its lifetime.   Because of the necessity of the low-level format for the drive to function, you're spot on that degaussing a HD - which is very difficult BTW - renders it a doorstop. 

Dave