> 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.
Yes. I've seen frame used to describe 1/75 of a second of audio (1 sector) in several different places as in MM:SS:FF. As far as I can tell this is wrong but it's used often enough that everyone understands what is means anyway. > > 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, Yes from what I've read I'd agree with that, it also seems sensible given how easily cdg data gets damaged. > 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. I'm not sure about that either but at the moment I'm betting against it the reasons are explained later. > > 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 Very interesting link. That's where you got your mysterious offsets form then I suppose. > 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). The Q and P bytes are added before the first scrambling occurs and have nothing to do with the p and q subcode channels from the control byte. >From what I understand the subcode byte is added to the frame (in the ECMA-130 sense) after all the scrambling and reed-solomon coding has been done. > My (probably flawed) thinking is that the control bytes containing > subchannel data are not put through the CIRC process, I agree. > but are matched up > with the new position of the relevant frame after CIRC encoding, and so > are effectively interleaved. That could be right but I don't think it is and I'll tell you why :) I've been experimenting with q channel data. Some time ago I wrote a program to read through a .cdg file (generated with some older windows software which was not open source) and extracted the q channel info. It seems this other software left the p and q channels in the .cdg file. Recently I wrote some more software which reads bin files directly and extracts the q channel. (I'm sure you know this but just in case the q-channel holds timing and track info about the current track and the disk there is one q-channel "section" for every sector) What I found was that in bin file (which was extracted with RW_RAW and so would need the karaoke info deinterleaving) has the q-channel subcode bits (bit 6) in the right place and in the right order already (ie they are do not need deinterleaving) Also the q channel bits in the .cdg file extracted with the old windows software had q-channel bits in the expected place. This got me thinking. I looked at pykaraoke and noticed that it masks out the q and p bits. So i did a little experiment and changed the mask from 0x3f to 0x7f (to preserve the q-channel). I then extracted some cdg files from a (bin file with the modified mask) and ran the .cdg file through my q channel program. The result was garbage, the deinterleaving had scrambled the q-channel. Conclusions: I probably haven't explained any of this very well so I'll sum up what I think I've found from research and experiment. The subcode is not interleaved in standard CDs The RW_RAW bin file extracted with cdrdao --read-subchan RW_RAW contains q-channel bits in the correct order. The 12 byte q-channel of one "section" is made up of bit 6 of the first subcode byte followed by bit 6 of the second and so on. The R-W channels ARE interleaved. Judging by the offsets, across two sectors. I do not know if the interleaving of the CDG data matches up the bytes in any way with scrambling of the audio sectors. I think it is likely that the interleaving in the R-W channels is part of a completely separate error correction system added by the inventors of CDG. Have you noticed that the 24 byte DG packet contains 6 "parity" bytes it would be nice if these could be used to correct broken cdg files. > It would be > great if you had the time and inclination to check this out :-) If you want any of the code I've been using (it's all is very rough and ready state) I could post it. It's in C :) not sure how python programmers feel about C. Drew ------------------------------------------------------- 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 _______________________________________________ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
