Offsets handling (syncing of audio data vs. Q channel)

Very interesting discussion.

However, one thing puzzles me. If the offset is caused by a lack of specification, and each manufacturer chooses its own, how comes that there are drives with variable offsets ? Like the Yamaha 6416S, for example, whose offset correction changes everytime you read a track.

Reddish, if you're still here, I wrote a page, long ago, where I redid Andre Wiethoff's work in order to find a reference offset. I think that his method was the same as mine. Here it is : http://perso.numericable.fr/~laguill2/offset/offset.htm

At that time, I was still calling "lead-in" the pregap of the audio session, like EAC does. So when I say "lead-in", you must understand "pregap".

I also studied a way of detecting the C2 error correction strategy of a drive looking at a burst error in a wav file : http://perso.numericable.fr/~laguill2/dae/dae.htm
See appendix 2.
At that time, the "use of EFM" to flag wrong bytes was unclear to me. My interpretation might be true, but what I really detected under the column "use of EFM" is actually if the drive is capable of identifying wrong bytes in a C1 frame, and pass the good ones only to the C2 stage, or if it always passes all-good or all-wrong C1 frames.

My guess would be the following. The high-bandwidth audio, and low-bandwidth sub-channels of the CD player are essentially independent, i.e., it is entirely possible to make a device that reads streaming audio data from a CD (not ever considering the subchannel data), or vice versa, a device that reads and interprets the subchannel data, but discards all audio/circ data.

In a real-life CD player, the two data streams are handled by essentially independent chains of digital logic. For most drives, this would not in itself lead to a variable offset, since both data streams behave fully deterministically (yielding a "de-facto" constant offset for the drive). With some delay lines in either data-path, the offset could be controlled to conform to the value it should have, according to the drive engineers.

Now I could imagine a (bad) design where the de-facto deterministic nature of the offset would be destroyed by FIFO buffers (in the audio data path), i.e., a queue of audio samples. It could be that the trigger to start filling the FIFO is not properly synced to the incoming data stream (for example, if the incoming side of the FIFO -whether to accept data or not- is controlled by a signal that runs in an asynchronous clock domain), or that the FIFO is not correctly flushed when starting to read data.

This is basically no more than an educated guess; somehow non-deterministic behavior has to enter the data processing chain, and clock domain mismatches are the most likely candidates from the digital design point-of-view. Then again, although I would say that the FIFO scenarios described above are possible, I am not a digital logic designer- so perhaps there are other explanations.

Interesting stuff! I had already seen this page before. I am not sure though that even if we do find a reference CD that can be used easily to determine the offsets, the problem is fully solved. We still need to consider the possibility that the people who make Master CDs are in the same predicament as the people who make CD players, i.e., it may be necessary to know the brand/software versions of the mastering equipment used for any given CD to make the call on the "correct" offset. It's messy!

That's cool stuff. It can be a lot of fun to try to understand the inner workings of a complicated system only by looking at the external behavior....

Regards, Sidney

Manufacturers don't really "choose" the offset value of their drives, it's a
side effect of the architecture of the main chipset (you can tune offsets
a bit afterwards, but it's really not something you base your design on).
As for variable offsets, I have never seen any such chipset and I can
only guess that this is the consequence of a weird (bad) design.

I've just discovered the nightmare is real, Plextor PX-716A C2 report is 8 pointers off.

BTW, here are another words from Andre Wiethoff: http://www.digital-inn.de/exact-audi...y-offsets.html

I've talked to Richard Wall, Technical Suport Manager
(http://www.dcainc.com/news/index.html#wall) at DCA
(Doug Carson and Associates),
THE optical disc encoder company (www.dcainc.com), he allowed me
to disclose about the offset experiment: he prepared a DDP file
(Disc Descriptor Protocol) where 1st byte of 00: 02.00 was !00
and encoded it for me in a MIS VIII encoder
(http://www.dcainc.com/products/MIS/MIS_V8/), then captured analog
response from LBR (Laser Beam Recorder) in a raw reading file, discovering
encoder places main channel's 1st byte aligned into channel frame 00: 02.00,
then came genial Mr. Sidney Cadot (http://ch.tudelft.nl/~sidney/)
with his audio readout system (http://club.cdfreaks.com/showthread.php?t=111913 ),
made with an old Plextor drive which precisely returns such !00 when asked
for 00:02.00, Then I concluded when I saw such drive in Wiethoff's database
having a +30 samples offset correction.

Please feel free now to disclose and quote me in forums so people gets convinced.

Regards, Carlos Hernández, PerfectRip project.

---

Last edited by IpseDixit; 20-11-2006 at 12:59.

Good work !

Through our MSN conversations, I have understood that this offset is the one defined if we assume that the first user symbol of the first EFM frame of the first sector of the track is located into the first sample of the wav file that should be got ripping this track.

Your exepriment showed that this is what happens in the MIS VIII encoder. I think that the above definition is more fundamental, because otherwise, all you would have measured would have been the particular offset of the MIS VIII device.

In order to match subcode channel with audio data, we have three sensible ways : the above one, where the user data starts with the subcode channel. We can also state that the user data ends where the subcode channel ends. Or we can also choose the average value between these two offsets.

This gives us three theoretical offsets, whose values differ by an amount of 324 samples. The fact that the offset that you found is only 30 samples away from Andre Wiethoff's one (that is itself 6 samples away from mine !) shows that both Andre's result and mine come from nonsensical data.
It's more logical to choose the first EFM frame as featuring the first actual user data than something 30 samples away.

Exactly. See my post #27 in this thread.

It's logical alright -- it's just a pity that the Red Book doesn't plainly tell us. I can make logical-sounding arguments for other offsets too!

Given that, the +30 has a logical appeal to my engineer's mind - and apparantly also to the Plextor engineers - all their newer drives have precisely the correct read and write offsets for this interpretation.

What does !00 mean ?

If I understand properly (putting aside this !00), you first discovered that the first byte of the first EFM frame was in the first user sample by capturing the output of a laser beam recorder, then Reddish, using his pit/land reading system found that according to this convention, the real audio data of a given CD was 30 samples after the place where EAC, Plextools and AccurateRip put it.
Is that so ?

Exactly.

I know discussion on this topic has continued raging elsewhere, but this seems like the most appropriate place. I want to fully understand the logical reasoning behind IpseDixit's conclusion that EAC's drive offset database is 30 samples late.

I'm making some inferences and out-and-out guesses here, as it's not 100% clear to me how he and Sidney (reddish) performed their analysis. That's why I'm seeking clarification. As I understand it:

- IpseDixit had a CD "disc descriptor protocol" file prepared for him which defined non-zero, easily identifiable data at 00:02.00 (the legal start of audio on a disc)
- this DDP was then prepared by a professional encoding device
- from that a laser beam recorder was used to make a physical disc
- the LBR's raw output file indicated that the non-zero data was in fact at 00:02.00, precisely where it should be
- he and Sidney (reddish) used Sidney's own homemade analyzer to determine that the non-zero data on the disc was in fact at 00:02.00, using a Plextor drive
- when same the Plextor drive was installed into a computer and read using readcd (or similar), he was able to locate that same data, and in so doing discovered that EAC's drive offset database was off by 30 samples

The conclusion was drawn as such:
- Given: DDP file defining non-zero data at 00:02.00
- Given: LBR's output file shows non-zero data starting at 00:02.00
- Therefore: encoder and LBR has likely prepared a disc in which the data start point can is in a precise place (00:02.00), with no offset

- Given: Sidney's analyzer, using a Plextor drive, showed the data start point on the CD to be at 00:02.00
- Therefore: The analyzer confirms the LBR output, meaning the CD can now be trusted to have its data start at 00:02.00, with no offset

- Given (I'm really making things up here): When the same drive read the disc using readcd, it located the data, but at an offset 30 samples before the published EAC offset for that drive.
- Conclusion: The EAC offset table indicates audio starts 30 samples after it should.

Questions:
- What model of Plextor drive was used, and what method was used to arrive at these conclusions? I'm completely guessing above so I am assuming I don't have it right.

- Has IpseDixit's reference CD been used with different drive models, and if so, are they consistently 30 samples off from the EAC drive database?

- Is this sufficient to draw a hard conclusion, or is it more circumstantial? It sounds solid, but towards the end of this thread, Pio2001 and reddish offer "makes sense, sounds logical" type comments, suggesting that there is still grey area here.

- Did I even get any of this right? If so, please correct me!

Thanks,
Ivan.

Hello Ivan X.So far, everything is true.DDP is prepared for encoder. We've never needed the content on a disc.Yes, capture from LBR's signal had 1st audio symbol as 1st channel frame's 1st main channel byte.Sidney Cadot, with his low level readout system discovered his Plextor picked 1st channel frame's 1st main channel byte as 1st audio symbol.Sidney's offsetless drive appears in Wiethoff's database needing a +30 samples offset "correction", this is enough to conclude database's reference is 30 samples off from absolute zero.

You have to understand CD encoding and decoding processes first, here are two key diagrams.