> I have modified the subcode injection program so that it labels the > lower nibble of each byte (from 0 to F) I will write this on the liteon > and read it back in RW mode to see if the drive tries to deinterleave > the subcode. (the only reasons I don't use the whole subcode byte is > that I'm worried about overwriting p and q channels and confusing the > drive)
A little update. I've done as above and from looking in the hexeditor it seems the liteone has made not attempt to change the order of any of the subcode bytes when reading in RW mode. the output of a subcode sector from the extracted disk (with the subcode labeled) looks like this: 000025E0 00 01 02 03 04 05 06 47 08 09 0A 0B 0C 0D 0E 4F 000025F0 00 01 02 03 04 05 06 47 08 09 0A 0B 0C 0D 0E 0F 00002600 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 4E 4F 00002610 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00002620 00 01 02 03 04 05 46 07 08 09 0A 0B 0C 0D 4E 4F 00002630 40 01 02 03 04 45 06 07 48 09 0A 4B 4C 0D 0E 4F (aside: 0x4? represents q channel bit set. 0x8? p channel set which happens at track transitions and 0xC? is p and q set.) However there seem to be differences in the audio outside the subcode blocks.... I'm getting rather confused now. I think the only real conclusion I've come to is that RW mode is unreliable (at least with cdrdao) and should probably be avoided. I think, unless anyone has any great ideas or breakthroughs, I'll go back to working on the ripping program and forget supporting RW mode. 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
