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

[Robert William Fuller]

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

<snip>

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

I was right to be suspicious of my memory here.  I should have taken 
notes when I looked at cdrdao.  I went back and looked at the cdrdao 
code to refresh it in my mind.  It's the PQ sub-channel read that could 
be returned in BCD or hex.  MMC spec states that drives return BCD, but 
some drives return hex.  Note that the cdrdao code erroneously states 
that CRC cannot be calculated for drives that return BCD, yet cued 
properly calculates it!

Raw P-W only comes back in one format :-)

<snip>

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

I found the diagram.  It's in MMC-3 (r10g,) section 5.17.1, page 163, 
Figure 42.  I think you are right.  I think the "raw" P-W is more likely 
to be "in sync" although it is still true that there will be the pesky 
read sample offset.

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

<snip>