Re: [Libcdio-devel] Re: isrc API?

[Robert William Fuller]

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.