On Mon, 2006-06-26 at 22:33 +0000, [EMAIL PROTECTED] wrote: > > 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.
I've been looking at the bin images again and I can see what you mean. It does look like the RW file contains just the audio (2352 bytes) and no subcode (the subcode blocks are pretty easy to spot in a hex editor). The only thing I don't understand is that the RW and RW_RAW rips are exactly the same size. I would have thought that if it had defaulted to just ripping the audio (2352 bytes instead of 2448) then the RW file would be smaller. My initial thought was that maybe the subcode is stored somewhere else maybe at the end of each track, but thinking about it again this seems a bit unlikely. It still seems strange to me that the images are byte for byte the same size, maybe I'm missing something. 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
