12

My friend tried to export cdrom device over network using nbd server but we noticed that while it works for data CDs, audio CDs don't really behave the way ordinary data disks do. And I'm not talking about presence or lack of filesystem but about raw block level access.

While I understand that audio CDs can't be really interpreted on files level, thus can't be really mount, I understand that they contain a lot of additional information that is really specific to audio and I understand that they don't really have CRC in the same way Data disks do so whole data read process is different, I still don't quite understand why they can't be read like an ordinary block device from /dev/sr0 or /dev/cdrom. What's so special about CDDA that they can't be just read on block level by ordinary software?

I mean in the end it's just stream of bytes - if not like block device then like any character device so why dd/cat/nbd can't use them like any other block/character device? Is there some actual, technical reason or it's just because nobody found rational use case for implementing such access to CDDA medium in Linux?

Lapsio
  • 890

2 Answers2

15

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.

agc
  • 636
  • 5
  • 16
dirkt
  • 17,461
2

CDDA for audio CD was created before anyone created a filesystem for CD-ROM (High Sierra first, and later ISO 9660). Before that, a CD simply coldn't behave as an ordinary data disk. And after that, audio CDs still had to be backward compatible with old CD players, so they couldn't change it.

Ulf Tennfors
  • 21
  • 1