[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 2.0.0.6 (X11/20071013) |
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.
- [Libcdio-devel] isrc API?, Robert William Fuller, 2008/03/19
- [Libcdio-devel] Re: isrc API?, Robert William Fuller, 2008/03/19
- [Libcdio-devel] Re: isrc API?, R. Bernstein, 2008/03/19
- Re: [Libcdio-devel] Re: isrc API?, R. Bernstein, 2008/03/20
- Re: [Libcdio-devel] Re: isrc API?, Peter Creath, 2008/03/20
- Re: [Libcdio-devel] Re: isrc API?,
Robert William Fuller <=
- Re: [Libcdio-devel] Re: isrc API?, Robert William Fuller, 2008/03/21
- Re: [Libcdio-devel] Re: isrc API?, Robert William Fuller, 2008/03/21
- [Libcdio-devel] Re: isrc API?, R. Bernstein, 2008/03/21