On Wed, 2006-06-21 at 23:17 +0100, Kelvin Lawson wrote: > Thanks a lot for posting your code Drew, glad to hear you got it > working. If you don't want the hassle of packaging it up yourself in a > release it sounds like a good addition to the cdgtools suite. I tend to > use Python for home projects simply because I find it quicker to get > something functional, but I see no reason why C code shouldn't go into > cdgtools. Let me know if you're interested (cdgtools is LGPL by the way). >
Yes, absolutely. I would like to know if anyone else has successfully compiled and test it. > > It decodes the q channel and checks to see if the track number has > > changed. > > > > If it has the program then does a CRC check (there is a CRC value built > > into the q channel) and if the CRC is bad the change of track is > > ignored. Initially I didn't include the CRC checking but I found that > > the q data was often corrupted in one or two sectors in the track so the > > CRC eliminates these erroneous track boundaries. > > This is good stuff. Thanks I was quite pleased with that bit :) > My drive returns the data interleaved, so I've only ever tested rw_raw > mode (using the software-deinterleave) hence the note of caution in the > instructions for rw mode. My thinking was that the data returned in rw > mode would need nothing doing to it at all, it could be written straight > out to the CDG file as it came from the CD drive. Have you found this > not to be the case? Could it be that the drives concerned don't support > rw mode? This is exactly what I believed. I basically used what cdgrip does as my guide and wrote an equivalent in C. I tested it on a disk image from one of my drives. cdrdao reports that the drive I used can return RW info so I ripped a cdg disk in RW mode and then tried to split the image into audio and cdg files. Aside: With most of the drives I tried cdrdao reported that they could not extract in RW mode only RW_RAW and when I tried to extract in RW mode cdrdao failed without extracting anything, with a message about the drive not supporting RW. The one drive that did work claims to be able to extract RW and RW_RAW. When I had extracted the .bin image I ran it through dcdgrip to split it but the results were not as expected. The CDG info was garbage and the audio was very badly distorted (like samples were missing and maybe cdg data was still present) There are several possible reasons this could have happened. 1. The drive was returning incorrect data. However the fact that the audio was distorted suggests to me that it was not just returning RW_RAW data because that would have resulted in normal audio and garbage cdg. 2. cdrdao is doing something to the data. 3. The data returned is not in the expected order. (What we were expecting is audio sectors followed by DEINTERLEAVED cdg info) 4 It is possible that the drive (or the driver) is wrong about it's own capabilities and is corrupting data in an unpredictable way. I'm tempted to believe that 3 is the correct answer and that the returned data is not in expected order. (I have had a look through the data with a hex viewer but can figure out what it's putting where) I must admit I haven't tested cdgrip.py and I might get round to doing that today (after the football). I'll post the results if I do. 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
