[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: Fri, 21 Mar 2008 00:26:16 -0400
User-agent: Thunderbird (X11/20071013)

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


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 :-)


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.


reply via email to

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