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

[Joseph Mack NA3T]

On Thu, 25 Dec 2008, David Black wrote:

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

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

I didn't know what this was about. Thanks for pointing me in 
the right direction.

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

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.

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

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

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.

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.

Captain: so where are we bosun?

Bosun: Well we've found a block, but we won't know what it 
is till we play it, and we can't backtrack to try again if 
it's the wrong one. We don't even know if it's music. It 
could be garbage or the directory.

Captain: good work bosun, keep it up.

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

yes I haven't low level formatted a disk in about a decade. 
I don't even know if I could do it anymore if I had to.

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

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.

> 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

yes, it was just a thought experiment to get rid of the low 
level formatting

> - renders it a doorstop.

yes it would make more sense to ask the hardware to fetch a 
block and let the hardware tell the head go position itself 
over blocknumber=x, rather than have the hardware move 
itself to a certain physical position and then just read and 
hope to hell that there's something there. This is what the 
low level format is about.

Thanks Joe
-- 
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!