Robert William Fuller wrote:
Peter Creath wrote:
On Wed, Mar 19, 2008 at 11:33 PM, Robert William Fuller
<[EMAIL PROTECTED]> 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>
