Chip's CD Media Resource Center:
Recall that a single sample of CD digital audio requires 16 bits. Since CD audio is always stereo, there must be two samples for each point in time, and so you have 32 bits. The CD standard (IEC 908) collects 6 such samples (i.e. 6 for the left channel and 6 for the right) into a frame (I've also seen these called CD blocks. The ECMA-130 CD-ROM standard calls them frames, so that's what I'll use). At 44.1kHz, each sample represents 1/44,100 second, so these six samples in the frame represent 6/44,100 = 1/7350 sec, or about 0.14msec. Each frame contains 6*32 = 192 data bits which are divided into 8-bit chunks. We may as well call these 8-bit chunks "bytes". Of course it takes 24 bytes to hold 192 bits.
To these 24 data bytes we add 4 parity bytes. This is known as "Q" parity; Q parity errors are called C1 errors and are the CDs first line of defense against data corruption. C1 errors can actually be measured and will show up later on when we look at disc reliability. We're now up to 28 bytes in a CD frame.
A certain amount of data interleaving has also taken place by this time -- I won't really discuss interleaving here, but it's a technique for improving error recovery by "smearing" the bits belonging to a particular 0.14msec time frame across multiple frames -- and the Q parity was computed on the interleaved data. But additional interleaving is now performed and a new 4 byte "P" parity value is computed on the newly interleaved data. P parity errors will show up later as C2 errors. The combination of interleaving and parity used on CD-DA is known as Cross Interleaved Reed-Solomon Code, or CIRC. We're now up to 32 bytes in a frame.
Next a single subcode byte is added to the front of the frame, giving us 33 bytes, and then the entire 33 bytes is encoded using EFM: each 8-bit byte is replaced by a 14-bit group and each 14-bit group is separated from its neighbor by 3 merge bits. The merge bits are chosen to ensure that 1's at the end and beginning of adjacent EFM groups will still have at least three 0's between them. So in effect, EFM uses 17 channel bits to represent 8 data bits.
Finally a 24-bit synchronization word is added to the start of the frame. As the name implies, it helps the CD player synchronize to the start of each frame. Note that there is another set of three merge bits after the sync word.
So... let's add up the number of bits in a frame:
24 data bytes = 192 bits = 336 EFM bits 4 Q parity bytes = 32 bits = 56 EFM bits 4 P parity bytes = 32 bits = 56 EFM bits 1 subcode byte = 8 bits = 14 EFM bits 1 sync word = 24 bits (no EFM) 34 * 3 merge bits = 102 bits ------------------------------------------- Total: 588 bits
Thus it requires 588 channel bits to represent 192 data bits, which represent 0.14 msec of CD audio. We can now compute the capacity of the CD-DA program area at various recording velocities.
Track length of program area: 5378 meters Channel bit length: 277.662 nm/bit (at 1.2 m/s) Channel Bit capacity of program area = 5378 meters / 277.662 nm/bit = 19,368,867,000 bits Data capacity of program area = 19,368,867,000 bits / 588 bits/frame = 32,940,250 frames then 32,940,250 frames * 24 data bytes/frame = 790,566,000 bytes (754 megabytes) and 33,018,983 frames * 6/44,100 sec/frame = 4482 seconds (74 minutes 42 seconds)
Sources vary for maximum standard CD-DA capacity. In practice it's going to depend on the precise location at which the Lead-in, Program and Lead-out areas begin. However I was pleased to find that the Taiyo Yuden discs are specified with a playing time of 74 minutes, 43 seconds (click here). The table below summarizes the calculated capacity of a CD in terms of playing time and size of the digital audio, at various different recording velocities.
|Velocity||Bit Size||DA Time||DA Size|
|1.2 m/sec||278 nm||74 min 42 sec||754 Mbyte|
|1.3 m/sec||301 nm||68 min 57 sec||696 Mbyte|
|1.4 m/sec||324 nm||64 min 01 sec||646 Mbyte|
Aside: It has been reliably asserted that the audio capacity of a CD was dictated by the total duration of Beethoven's Ninth Symphony.
Last Updated Monday October 15, 2001 17:58:13 PDT