5

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?

5

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.

  • +1 for actually answering the question “Is there some actual, technical reason …?” But it would be a better answer if it linked to the Red and Yellow books. – Scott Mar 11 '18 at 23:08
  • @Scott: The Red and Yellow books are not publicly available, so I can't link to them. – dirkt Mar 12 '18 at 4:47
  • OK, thanks. (But you might want to put that statement into your answer.) – Scott Mar 12 '18 at 16:59
1

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.

  • But — is a music CD analog (like a vinyl phonograph disk/record) or digital?  If it’s digital, is it composed of 17-bit bytes?  If it’s a stream of 8-bit bytes, why can’t a process read those bytes? – Scott Mar 11 '18 at 1:14
  • @Scott I assume you're asking rhetorically if a CD is digital vs analog? – Twisty Impersonator Mar 11 '18 at 2:13
  • Yes, of course. – Scott Mar 11 '18 at 2:14
  • @Scott it's the firmware of the CD drive, and also probably the CD driver that prevents you from doing those things. It's just like bluray discs which contain perfectly normal video streams/files but you can't read it without compromised key to decode[ – phuclv Mar 11 '18 at 2:55
  • See Why can't we write over a CD/DVD after it's been burned/finalized?, where the firmware also prevents you from burning a burned spot on the disc to wipe it – phuclv Mar 11 '18 at 3:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.