Why you can't just "dd" CD Audio like an ordinary data CD?
Audio CDs (also called CD-DA, specified in the proprietary Red Book) are the oldest format of the CD. The format is inspired by the audio record, so you have a spiral track with continuous data, and interleaved with this data is timing information. There are no proper block headers. The smallest unit of information is one frame, or 1/75 second, which contains 2352 data bytes (for 2 channels, 2 samples/byte, 44.1 kHz).
Note that this is not a power of two, and doesn't even divide by 256 or 512. So treating audio frames as data blocks is a bit awkward. On top of that, early CD drives cannot always position properly, so if you tell it "go read the frame at 12 minutes 4 seconds and 5 1/75 seconds", it will sometimes start a few bytes early or late. That why there are so many programs to "properly" read audio CDs (like cdparanoia
).
Now contrast this with a Data CD (also called, CD-ROM, specified in the Yellow Book): They took the 2352 bytes of an audio frames and used some of those for header information to identify a block. They also added another level of error correction, so the 2352 bytes of an audio frame become 2048 bytes in a data frame.
Now we have a power of two as block size, we have proper headers and can do exact seeks, and we can really pretend that this is just a block device.
So this is the reason why, by default, an Audio CD is not treated as a block device, while a Data CD is.
That said, there's no reason not to make the information on the Audio CD available in the filesystem, say, as a WAV file for each track. And in fact, there are some open-source projects like CDfs, or others I can't remember right now which use FUSE, that represent the CD data this way. However, you are still stuck with the problem that there's no jitter correction etc., so you're better off using something like cdparanoia
.
And the kernel people also thought it was a bad idea.