[sdiy] OT: Scratchy CDs

[Kevin Downs]

The CD standard is a very clever thing...

<warning - extreme geek mode>

Here's a quick, but detailed, description of "Cross Interleave
Read-Solomon Code" (CIRC) used to encode CD Audio.


The original musical signal is sampled as two 16-bit words, one for the
left channel and one for the right channel. 

Six samples (six of the left and six of the right for a total of twelve)
are taken to form a frame.


L1 R1 L2 R2 L3 R3 L4 R4 L5 R5 L6 R6


The frame is then encoded in the form of 8-bit words. Each 16-bit audio
signal turns into two 8-bit words.


L1 LI R1 R1 L2 L2 R2 R2 L3 L3 R3 R3 L4 L4 R4 R4 L5 L5 R5 R5 L6 L6 R6 R6


This gives a grand total of 24 8-bit words.

The even words are then delayed by two blocks and the resulting "word"
scrambled. This delay and scramble is the first part of the interleaving
process.


The resulting 24 byte word (remember, it has an included two block delay
-- so some symbols in this word are from blocks two blocks behind) has 4
bytes of parity added. This particular parity is called "Q" parity. This
is used to correct errors due to the physical condition of the CD and
the way that the CD was recorded


Now, the resulting 24 + 4Q = 28 bytes word is interleaved. Each of the
28 bytes is delayed by a different period. Each period is an integral
multiple of 4 blocks. So the first byte might be delayed by 4 blocks,
the second by 8 blocks, the third by 12 blocks and so on. The
interleaving spreads the word over a total of 28 x 4 = 112 blocks. 


The resulting 28 byte words are again subjected to a parity operation.
This generates four more parity bytes called P bytes which are placed at
the end of the 28 bit data word. These are used to correct large scale
errors due to fingerprints and scratches. 

The word is now a total of 28 + 4 = 32 bytes long.


Finally, the another odd-even delay is performed -- but this time by
just a single block. Both the P and Q parity bits are inverted (turning
the "1s" into "0s") to assist data readout during muting. 


An 8-bit subcode is then added to the front end of the word. The subcode
specifies such things as the total number of selections on the disk,
their length, and so on. More on this later.


Next the data words are converted to EFM format. EFM means Eight to
Fourteen Modulation and is an incredibly clever way of reducing errors.
The idea is to minimize the number of 0 to 1 and 1-0 transitions -- thus
avoiding small pits. In EFM only those combinations of bits are used in
which more than two but less than 10 zeros appear continuously. 


For example, a digital 10 given as a binary 0000 1010 is an EFM 1001
0001 0000 00


Each frame finally has a 24-bit synchronization word attached to the
very front end -- (just for completeness the word is
(100000000001000000000010) and each group of 14 symbols is then coupled
by three merge bits. 


These merge bits are chosen to meet two goals:


1. No adjacent 1's from neighboring EFM encoded words


Remember that there are lots of EFM words which end in "1" -- as one
example, all the eight-bit binary words from 128 to 152 end in "1".
Similarly, there are EFM words that start in "1". Thus, it is relatively
straightforward to have to have adjacent EFM words that create adjacent
"1s". 


For example -- binary 128 and binary 57


10000000 in EFM is 00111001 in EFM is

01001000100001 10000000001000



2. The digital sum value is kept near zero


Minimizing the digital sum value is just an attempt to keep the average
number of "0's" and "1's" about the same. The value of +1 is assigned to
the "1" states and the value of -1 is assigned to the "0" states. Then,
the value of the merge bit is chosen to maintain the average near zero.


SO! The final frame (which started at 6*16*2 = 192 data bits) now
contains:



1 sync word          24  bits                                
1 subcode signal     14  bits                                 
6*2*2*14 data bits   336 bits                                
8*14 parity bits     112 bits                                
34*3 merge bits      102 bits                                

GRAND TOTAL          588 bits                                

And the data in this frame comes from 112 original sample blocks....




Now why on earth did they make it that complicated?

Well, by spreading the data all over the place (the "interleave"
processes) and adding large amount of TWO DIMENSIONAL parity data, it is
possible to reconstruct errors in the data read from the CD. These
errors range from single bit defects from the manufacturing process up
to large scratches.

The CIRC decoder is able to completely reconstruct error bursts of up to
3,500 bits (2.4 mm in length). It can also interpolate much larger error
bursts of up to 12,000 bits (8.5 mm). Any error more drastic than these
will cause the CD to mute the output to avoid serious speaker
damage....and it sounds horrible!

If a CD skips, it is usually a tracking error in the read assembly, much
like a needle jumping vinyl grooves....







> -----Original Message-----
> From: owner-synth-diy at dropmix.xs4all.nl 
> [mailto:owner-synth-diy at dropmix.xs4all.nl] On Behalf Of Ola Andersson
> Sent: Thursday, 2 October 2003 6:21 PM
> To: synth-diy at dropmix.xs4all.nl
> Subject: Re: [sdiy] OT: Scratchy CDs
> 
> 
> On Wednesday 01 October 2003 18:16, you wrote:
> > There is the low level parity check (well, actually it's two parity 
> > checks in a row) in each frame, which contains 6 stereo samples. It 
> > takes 588 channel bits (pit/land bits) to code those 6 samples (192 
> > payload
> > bits) - that's quite a ratio...
> > And for the question, whether ripping an audio track does error
> > correction - I think it's safe to assume that low level 
> correction does
> > take place, but high level correction can't be used - it's 
> simply not
> > present on an audio CD.
> 
> Well, a parity check isn't error correction, only error 
> detection. The question is what do ripping programs do when 
> they detect a parity error? I think professional CD players 
> tries to guess the correct sample values 
> (interpolation or something).
> For ripping CDs, see www.exactaudiocopy.de, this program 
> tries to do it right.
> 
> -- 
> Ola Andersson
> http://cullyn.ling.umu.se/synthdiy
>