[Top][All Lists]

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

[Libcdio-devel] Re: isrc API?

From: R. Bernstein
Subject: [Libcdio-devel] Re: isrc API?
Date: Fri, 21 Mar 2008 07:09:11 -0400

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 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.

reply via email to

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