Re: subcode and deinterleaving question

Hi Drew,

> I've been reading all the info I can find but I must admit I'm getting a
> little confused partly because the terms "frame" and "sector" do not
> seem to be used consistently. For instance the ECMA-130 standard seems
> to refer to 588 bits burnt on to the disk as a frame.

Thanks for the headsup, I hadn't seen that ECMA 130 before. I thought 
the gory details were to be found in the Red Book which costs money, so 
it's great to find this info available for download.

I've just had a scan through it, and it distinguishes between sections, 
sectors and frames. We've used sector and frame to describe the same 
thing in the cdgtools code - as the 2352 bytes of audio + (2 * 392) 
bytes error correction/detection + 98 bytes subchannel data. Looks like 
we should replace "frame" by "sector" throughout the code.

Some of the above is filtered out to get the data returned by cdrdao. We 
get the 2352 bytes of audio data, plus 96 bytes of subchannel data. (The 
first two bytes of subchannel data appear to be sync bytes, hence 
getting 96 instead of 98). The subchannel data is contained in the 
"control byte" discussed in the document.

> I know a certain amount of interleaving goes on in the audio data prior
> to it being written onto the disk but I was under the impression that
> the same could not be said about subcode?

It looks that way from the document. The CIRC coding is done before the 
control bytes are added, but perhaps the control bytes are then added in 
the relevant place, i.e. they are not added in order because they are 
placed according to the position of the CIRC-encoded data? I haven't 
read deeply enough yet to figure that out.

As you can probably tell from the above, I'm pretty much in the dark 
about the interleaving process. When writing cdgtools I noticed that my 
drive was returning data that looked almost correct but with the bytes 
spread around. I couldn't find any information on the interleaving 
process, and believed it to be in the Red Book, but came across the 
following:

http://club.cdfreaks.com/showpost.php?p=719361&postcount=13

This guy was in the same position as me, but had the patience to sit 
down and reverse engineer which bytes went where.

> Is it just the r to w channels which are interleaved or is it the whole
> subcode byte? (including the p and q channels).

I'm not sure because I mask out only the P and Q subchannels. Are you 
asking because the CIRC section discusses encoding of P and Q bytes? The 
way I read that was that these are parity bytes, unrelated to the p-w 
subchannels (confusing terminology).

My (probably flawed) thinking is that the control bytes containing 
subchannel data are not put through the CIRC process, but are matched up 
with the new position of the relevant frame after CIRC encoding, and so 
are effectively interleaved. Bear in mind I don't even know if the 
deinterleaving code in cdgtools is actually reversing the CIRC 
cross-interleaving, or if it's some other magic altogether. It would be 
great if you had the time and inclination to check this out :-)

Hope that helps,
Kelvin.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642