I'd like to understand if we clear onthe strategy verus the tactics; that is whether right interface and approach have been determined versus who will do and when.
Also, if this is appropriate for a Google Summer of Code project, I'd appreciate it if someone would write it up. If you look at http://www.gnu.org/software/soc-projects/ideas.html you'll find something extremely paltry. Volunteers to add or amend are welcome! Robert William Fuller writes: > Peter Creath wrote: > > On Wed, Mar 19, 2008 at 11:33 PM, Robert William Fuller > > <[EMAIL PROTECTED]> wrote: > > <snip> > > > You're definitely right to avoid the READ SUB-CHANNEL command. I > > remember looking into it some time ago and thinking it was a mess too. > > > > But what about using READ CD to read RAW P-W subchannel data? I > > thought RAW P-W was more widely supported, as it required the drive to > > do less. (It's still optional, but it's a lot easier to implement > > than Q extraction.) > > Raw P-W is a possibility. It seems like a logical deduction that raw > P-W would be better supported by the hardware people because it is > easier for them to implement. I did Q sub-channel first because you > still need a Q sub-channel parser to get the Q out of the P-W. I > stopped there because it met my needs. Raw P-W is easier for the > hardware people to implement, but harder for us software people (I know > Peter knows this, but other people on the list may not.) You have to > de-interleave the raw P-W data. I saw an algorithm for this somewhere, > and if I recall correctly, there is code in cdrdao to do it. > > The other tricky aspect of P-W--and again my memory of cdrdao code is > hazy, so don't quote me on this--is that even though it is supposed to > be "raw", some drives "cook" it. Again, IIRC, there's code in cdrdao to > determine whether or not the "raw" P-W is returned as hex values or BCD, > depending on the drive. > > There was code in cdrdao to parse the Q sub-channel, but I did not find > it until after I had started my own, and I continued with my own because > I tend to write more general solutions to problems. More of the code in > my Q sub-channel parser is functionally decomposed to be usable for > other purposes and projects (like my routines to extract nibbles from > character arrays as well as extract what I decided to call nabbles, > 6-bit values.) The cdrdao code is very specific to its purpose, which > makes it somewhat less readable--although I had no difficulty reading > it--and not terribly re-usable due to the general lack of abstraction. > > > I also thought that reading RAW P-W allowed you get a better sync with > > the audio, whereas Q was not guaranteed to be sector-matched with the > > audio you're playing. > > I saw a flow diagram for this somewhere that I think answers that > question. I just looked for it for about 20 minutes and did NOT find > it. Very frustrating. The fact that some drives "cook" the "raw" P-W > makes me suspicious about the sync being any better, but it might be :-) > I wish I could find that diagram. If I don't turn it up, I'll have to > decode P-W from a number of drives to see if I can figure that out. > > Fortunately, even if the audio is out of sync with the sub-channel data, > the track times are stored in the Q data, so you can determine with > which sector the sub-channel data goes. Of course, the other side of > this is that some drives have such huge audio read sample offsets (> 1 > frame/sector), that there is no way for any of the sub-channel data to > be in sync with the audio returned. I have a drive that has a read > offset of 738! That's 2952 byte, which is greater than the 2352 byte > sector size. > > > Among other things, it looks like RAW P-W format (2448 = 2352+96) can > > also be used to get the subchannel data for the disc lead-in. I > > doesn't appear that you can do that with just Q queries. And P-W > > seems to be required to support CD+G, if we ever get there. > > I saw something like that back when I read the MMC spec for READ CD, > many months ago now. That brings us back to audio read sample offsets > and the need for overread support to get the missing samples from either > the lead-in or lead-out, depending on whether the drive has a positive > or negative read sample offset. > > That brings us back to needing a free database that provides some of the > same functionality as the Accurate Rip database, or finding a way to get > the read offset from the drive without commercial reference discs. > (It's easy enough to figure out the combined write+read offset without a > reference database, but getting just the read offset without a reference > database is a serious problem.) > > > So what do you think about issuing a RAW P-W read and then extracting > > whatever subchannels you want in software? > > I think it's a great idea. It's a bit of a ways down on my list. If > somebody can get to it sooner, I'd be happy to be a reference for > snagging the Q sub-channel parser from cued and putting it in libcdio. > >
