[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Robert William Fuller
Subject: Re: [Libcdio-devel] Re: isrc API?
Date: Thu, 20 Mar 2008 20:18:53 -0400
User-agent: Thunderbird (X11/20071013)

Peter Creath wrote:
On Wed, Mar 19, 2008 at 11:33 PM, Robert William Fuller
<address@hidden> wrote:


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]