Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

What's actually on an audio CD?

What's actually on an audio CD?

  • Comments 6
Before I can talk about reading audio CDs using DAE (Digital Audio Extraction), I need to talk a bit about what data's actually on the audio CD, since we're going to be reading the raw audio data from the CD.

An audio CD contains audio samples sampled at 44.1kHz, stereo.   Each sample is 16 bits of data long.  So one second of data takes up 176,400 bytes.  This will become important during playback, since we'll need to tell the audio adapter what its rendering.  There's a lot of math and physics that went into figuring out those numbers, essentially, 44.1kHz/16bits is "good enough" to be considered full fidelity to most people. 

The data on the audio CD is laid out in "sectors", each of which contains 1/75th of a second worth of data.   So each sector is 2352 bytes in length.

That number will be critical to the reading process later, since we'll be reading the data from the CD one sector at a time.

Note that the sector size for a CDROM drive is 2048 bytes - that's used to make life easier for applications.

When the CDROM filesystem sees an audio CD, it reads the track database off the CD (I'll talk about that when I'm showing the code that reads the database) and synthesizes a tiny RIFF file for CD audio.  The file contains enough information for Windows to hand to the media player to have it play the media back.

 

How Stuff Works has a pretty good tutorial on how the actual data is laid out on the CD here.

Oh, and they have a much better series of examples of how digital audio is sampled here.

Prof. Kelin Kuhn has an awesome breakdown of the details in the course materials for UW's EE498 course

  • I did a project back in High School on how an Audio CD actually works from the hardware
    standpoint....
  • A source was tricky to track down, but the reason for 44.1kHz - besides being a little more than twice 20KHz, hence possible to encode the highest pitches supposedly discernable by the human ear without aliasing - was due to the tape system used to prepare the CD master. Digital tape preceded the CD.

    The tape machine used was in fact a video recorder. In each of the 490 lines of the picture, you can stuff 3 16-bit stereo samples. At 30 fps you get 44,100 samples per second. That's a US/NTSC recorder, of course. IIRC, 44,100 is a common factor - the numbers work out the same for PAL/UK (50Hz, 25 fps) decks.

    Sources: http://arts.ucsc.edu/ems/music/equipment/digital_recorders/Digital_Recorders.html, http://www.solorb.com/dat-heads/FAQ, http://recforums.prosoundweb.com/index.php/m/48729/0#msg_48729
  • This is slightly off-topic (slapping is welcome) but I figured you or a reader could answer this for me.

    I've had thoughts on making burning software but I want to be able to handle BIN/CUE as well as ISO. From what I can gather, a BIN/CUE file is broken down into sectors of 2352, while a ISO is usually broken down into sectors of 2048. I may be wrong about them being exact but from the majority I've seen they do match these numbers.

    So from the math I could assume that a BIN/CUE is really just Data being streamed on the CD in Audio format (Redbook I believe), but I'm confused on how to actually get it to work. Do I treat it as an Audio CD with just one track as it appears to be, or is there something else I need to do? Basically I'm thinking about implementing an open source CD burner that can actually handle practically any image format you throw at it without having to convert them all to ISO as practically every other open source app requires. I just can't wrap my head around the BIN/CUE Audio connection, so I'm probably wasting my time.
  • Jeremy: Typically you'd use a program such as isobuster to convert that RAW data into user data (or, in vcds, mpeg frames, which are written in a different format). Of course if you're implementing it that doesn't help you, but it might be valueable to compare inputs and outputs. The last link in Larry's letter might help you decipher the data; actual C sources are available online if you'd rather not translate the mathematics and tables, though I'm not sure where. I remember looking into this a couple of years ago.

    Oh, ISOs and bins can contain raw or user data, but generally tend to stick to their usual that you pointed out. Bins particularly can be a wide variety of non-standard formats. Some formats, like tao, can only contain user data.

    Hope any of that helps!
  • Audio doesn't really have a strong association between the nominal start of a sector and what the audio's doing at that time. The sector is flagged by the S0S1 sequence in the subcode (embedded navigation information), but what's being read from the cd at that time (actually, what's being read from the cd a couple of microseconds ago).

    Part of the problem here is the age of the spec and the primitive nature of the early CD readers (much like record players, they'd "fall into the groove" and keep playing until they ran out of data) and the fact that the subcode is easy to decode compared to the audio, so it's available much earlier in the reading pipeline than the audio. Depending on the chipset, the delay between the availabilty of subcode and the availability of the audio can vary significantly between different models - meaning that navigation ("are we there yet") decisions are taken when different data is in the pipeline.

    What's more, drives are only required to return audio data with an accuracy of +/- 1 *second* (although in modern drives they're almost all within +/- 2 sectors because the only substantive difference is whether the data already in the deconvolution pipeline (see the link above ;) is returned as well.)

    This means that cd reads jitter - depending on the hardware, doing two reads - one 27 sectors starting at X, then 27 from X+27 might overlap or might miss a couple of sectors. Stitching subsequent reads together is one of the more challenging aspects of writing code which does DAE.

    Drives which support 'accurate streaming' shouldn't have too much of a problem with this, because they guarantee that reads will be sequential if you ask for sequential reads. (Although that doesn't remove the absolute error, it does hide it from the reading application)

    Lastly, the question above about trying to write bin/cue data as audio betrays a fundamental misunderstanding about the nature of what's on a CD and how drives write it. I strongly recommend getting hold of the yellowbook spec from somehere (there's an ISO equivalent, but I forget the number - (it's not 9660)) and understanding how different data and audio are.
  • PingBack from http://blogs.msdn.com/larryosterman/archive/2005/05/06/playing-audio-cds-part-11-why-isn-t-my-sample-ready-for-prime-time.aspx

Page 1 of 1 (6 items)