> Great, thanks for sending that. On a first look it appears to me that the CDG > data may actually be missing from the RW version. The data at offset 6816 in > the > RW version and 7008 in the RW_RAW version looks the same, except the RW_RAW > version is 192 bytes further on. This could mean that we're into the 3rd block > in both files, but one of them is missing 2x 96 byte CDG blocks (i.e. could be > 2352 byte audio blocks back to back). I did notice, however, that there were a > few bytes somewhere in the 2nd audio block that differed, so the audio wasn't > completely identical. I'll have a look further in to see if a pattern > emerges.
I've looked at all the sector boundaries and I'd say that (at least this far into the track) there is no CDG data in the RW version at all. The RW_RAW version contains 2532 bytes of audio followed by 96 bytes CDG (easily recognised by the abundance of zeroes), whike the RW version contains the same 2352 bytes back to back. i.e. each block is 2352+96 bytes in the RW_RAW version, and each block is 2352 bytes in the RW version. For example, take block 15. The audio data begins at offset (2440 * 15) in RW_RAW, and offset (2352 * 15) in RW - comparing these two offsets the data to my eye appears to be the same. But scrolling up in each, you'll find the CDG data for block 14 in RW_RAW and the audio data for block 14 in RW. So what does this mean? That (at least for this drive) RW mode is no good to us, unless it does something like spew all the CDG data out at the end in one go. This leads me to wonder about the following: * If RW mode really doesn't return the CDG data, what are the Windows rippers going on about when they distinguish between software and hardware deinterleave? Also didn't you say you found better error-rates by using RW mode in a Windows ripper? * Could it be that cdrdao has handily stripped out the subcode data for us in RW mode? * Can we assume that all RW drives will work with RW_RAW? Though I was hoping we could use the RW mode to get better quality rips. It smells to me like cdrdao is stripping the subcode data, otherwise what is the hardware deinterleaving and error-correcting about? I'll take a look through the cdrdao source to see if anything jumps out. Meanwhile it sounds like the thing to do is to recommend people only rip in RW_RAW mode. Thanks again for sending the rips. Kelvin. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
