[Libcdio-devel] Re: isrc API?

[R. Bernstein]

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
 > > <address@hidden> 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.
 > 
 >