On Wed, 2006-06-21 at 23:39 +0100, Kelvin Lawson wrote: > > 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) > > Could it be that the q data is deinterleaved by the drive or cdrdao, > while the rw data isn't?
Yes, I think this is very likely. > > > 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. > > I'm not so sure about this because some Windows CDG rippers boast of > their software deinterleaving support. They say that some drives can > return the CDG data ready-deinterleaved, while others need an extra > software deinterleave. Check out the following message from the > Audiograbber author (make sure you also scroll down to look at his reply > about the deinterleave process): > > http://www.karaokeplayground.co.uk/ubbcgi/ultimatebb.cgi?ubb=print_topic;f=9;t=001020 > The point I was making was that the interleaving of the CDG was separate from the interleaving that goes on at a lower level as part of the error correction mechanism of all CDs. I'm not convinced either way but in either case we already know the offsets and we know that the de-interleaving of RW_RAW data works in cdgrip. What we don't know is what RW data looks like. > > 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. > > Definitely worth a try. According to the Audiograbber author's message > above he gets more errors when using software deinterleave as the > deinterleave-capable drives seem to be error-correcting. I guess we're > missing that stage in the software-deinterleave. > Yes. I'm going to have to try to read up on the format of the parity bytes in the cdg packet and how they are generated from the rest of the cdg data (I assume pykaraoke just ignores these bytes Although I haven't checked :) ). If they are a checksum type arrangement the drives which deal with de-interleaving may look at them and re-read the disk if the check fails. This would not help us because by the time we get the data in cdgrip we don't have the opportunity to re-read the sectors. However if we are trying to correct data... There are certain types of errors which are more likely than others. For example most errors I've seen in subcode reads consist of a single bit being flipped. I can imagine a way to try to correct errors by looking at a cdg packet where the parity check has failed and simply flipping bits in a logical way until the packet passes the parity check. (a sort of brute force attack on the corrupted packet.) Also, We know quite a lot about what the data in the next CDG packet is likely to be. For instance usually the lyrics change colour in a well defined and predictable way and normally they don't randomly change to a different colour for one block for example (I'm sure you know more about this than I do.) If we were to do the parity check and find a packet was corrupted it might then be possible to make an educated guess (in software) as to what might be wrong with it (wrong colour, wrong position on the screen etc.) and try changing the packet in way that would make sense and do the parity check again. In this way I think you could eliminate a lot of errors. This assumes that the "parity bytes" are a simple CRC or checksum and not a better error correction method, in which case recovering correct data would be even easier. > Apologies for the tardy response by the way, I tend to work on this in > bursts. No probs, I'm much the same. Drew Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
