Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: CD Drive Offset and CueTools (Read 8621 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CD Drive Offset and CueTools

I’ve got a couple of questions I can’t find the answer to (really sorry if that’s down to my poor searching skills...)

I’ve got some rips that clearly weren’t done with drive offset correction applied. So when I verify with Cuetools a couple of tracks come up as ‘No Match’ for 0 offset. Cuetools of course does its clever thing to try different offset values and, low and behold, all tracks are marked accurately ripped when offset is +667 (or whatever it happens to be).

Now, as I understand it, an offset of +667 means that when the CD drive head is told to go to sample 1 of an audio track, it actually reads 667 samples 'early'. In an ideal world, the correct offset correction has been set in the ripping program and it always starts 667 samples late and rips 667 samples into the lead-out data??

Assuming that’s approximately correct, I’ve got three questions.

Firstly, if offset correction has not been set, what happens to the ‘early’ and ‘late’ samples? In some circumstances are the first 667 filled with digital silence and the last 667 audio samples simply cut-off and lost forever?

Secondly, given that Cuetools sometimes reports all tracks  accurately ripped when it assumes some sort of offset value, does that mean that in some instances, whilst offset correction hadn’t been applied, the ripping program managed to rip every sample of the audio data because there happened to be enough “padding” around the audio samples? Therefore if I apply offset correction, CueTools will ‘trim’ the files of this padding and I’ll have a perfect rip?

Thirdly, on the basis of the above assumptions, how can there be multiple offset settings that are reported as being accurately ripped? Surely there is only one offset correction that will ensure bit-for-bit accuracy of the original audio samples?

CD Drive Offset and CueTools

Reply #1 –
Quote from: james76smith on
...how can there be multiple offset settings that are reported as being accurately ripped? Surely there is only one offset correction that will ensure bit-for-bit accuracy of the original audio samples?


This can often be the case with (usually older) CDs that have different pressings. They are the same masters, have the same CRC values, but were pressed at different locations and/or times. I have more than a few CDs I bought lately that only match the overwhelming database consensus when offset is applied.

...sorry my knowledge is limited with regards to your other questions.
The Loudness War is over. Now it's a hopeless occupation.

CD Drive Offset and CueTools

Reply #2 –
Some discs have 6 or more pressings.

CD Drive Offset and CueTools

Reply #3 –
Thanks for the replies. 

When you say different pressings with respect to offsets, I guess that means the same CD but with different lead-in/lead out durations?

Assuming these are filled with null samples, presumably when CueTools does it's correction thingy, it's changing the number of null samples at the beginning or end of the rip? As long as the lead-in and lead-out didn't contain audio data (which I gather is very rare) you then have a perfect bit-for-bit mapping of what was on the CD for one of the pressings?

I'm sure we're only talking a split second here (and I really shouldn't be worried about this in the grand scheme of life!) but it's bothering me whether to apply offset correction to my rips that don't come back accurate at 0 offset. Essentially what I'm listening to without offset correction applied is either a pressing that didn't make it into the accurerip Db yet, or one that's never existed?

CD Drive Offset and CueTools

Reply #4 –
Quote from: james76smith on
Now, as I understand it, an offset of +667 means that when the CD drive head is told to go to sample 1 of an audio track, it actually reads 667 samples 'early'.
This really isn't how it works, but for the layperson it is as good an explanation as any.  The data for Audio CDs is organized into sectors of audio data and sub-code information which is spread out over the area of the disc using CIRC and EFM.  IOW there is no single spot to read a particular sample.

Quote from: james76smith on
In an ideal world, the correct offset correction has been set in the ripping program and it always starts 667 samples late and rips 667 samples into the lead-out data??
When configured that way, which for a drive that has a read offset of -667 samples based on Andre Wiethoff's reference, this is how it is done in practice, yes.  I'm not sure why you're expressing it as being in an ideal world, unless you're taking into account that many drives cannot overread.

Quote from: james76smith on
Firstly, if offset correction has not been set, what happens to the ‘early’ and ‘late’ samples?
The drive presents the data based on its internal "uncorrected" offset.  If it reads 667 samples earlier than Wiethoff's reference then that's what you get.  From the drive's point of view if it is being instructed to grab audio without an offset correction then there are no early or late samples; the data ripped begins after the lead-in and ends before the lead-out.  It is quite possible for these first 667 samples to be something besides digital silence, perhaps non-silent samples even before that.  It is also possible for samples after the official end of the last track (again, from the drive's perspective) to be non-silent as well; even on the very same disc.

Quote from: james76smith on
Secondly, given that Cuetools sometimes reports all tracks  accurately ripped when it assumes some sort of offset value, does that mean that in some instances, whilst offset correction hadn’t been applied, the ripping program managed to rip every sample of the audio data because there happened to be enough “padding” around the audio samples?
Perhaps, but AccurateRip also ignores the first five frames and the last five frame on the disc, widening the window of acceptance.

Quote from: james76smith on
Therefore if I apply offset correction, CueTools will ‘trim’ the files of this padding and I’ll have a perfect rip?
CUETools will discard samples from one end and zero-pad the other end when applying an offset, this is correct.

Quote from: james76smith on
Thirdly, on the basis of the above assumptions, how can there be multiple offset settings that are reported as being accurately ripped?
Different production runs of discs often create offsets in the data.

Quote from: james76smith on
Surely there is only one offset correction that will ensure bit-for-bit accuracy of the original audio samples?
"Bit-for-bit accuracy" means nothing unless you're burning burning a copy. When burning a copy you need a combined read-write offset of zero to duplicate the pressing being ripped without the data being offset.


Quote from: Engelsstaub on
They are the same masters, have the same CRC values, but were pressed at different locations and/or times.
This makes no sense.  Tracks ripped with different offsets will create different files.  Different files create different hash values.


Quote from: james76smith on
When you say different pressings with respect to offsets, I guess that means the same CD but with different lead-in/lead out durations?
Nope. Well I suppose this is one way of looking at it, though I think it's more useful to think of it with a disc that has the same table of contents (same track lengths) just that the data has shifted in time.  What data (digital silence or otherwise) ends up in the lead-in and lead-out will change as a necessary consequence, of course; just like the data at the edges of the tracks, for that matter.

I'd like to point out that in this sense the term "pressings" is actually a construct which is somewhat limited to AccurateRip.  In reality pressings can an often do have tracks with different lengths.  In the case of AccurateRip, pressings with differences in track lengths will have different disc IDs.

Quote from: james76smith on
perfect bit-for-bit mapping of what was on the CD
Considering that a disc may contain non-silent samples in both the lead-out and lead-in (as just one example), this isn't always possible.

CD Drive Offset and CueTools

Reply #5 –
Quote from: greynol on
Quote from: Engelsstaub on
They are the same masters, have the same CRC values, but were pressed at different locations and/or times.
This makes no sense.  Tracks ripped with different offsets will create different files.  Different files create different hash values.



Thanks for correcting me, greynol. I re-read that later and thought to myself "man, I really should have thought that out before posting.
The Loudness War is over. Now it's a hopeless occupation.

CD Drive Offset and CueTools

Reply #6 –
Quote from: greynol on
Quote from: james76smith on
Therefore if I apply offset correction, CueTools will ‘trim’ the files of this padding and I’ll have a perfect rip?
CUETools will discard samples from one end and zero-pad the other end when applying an offset, this is correct.

So if I were to take a non-offsetted rip that has already been split into tracks, and run it through cuetools correcting for a +100 offset, then the first 100 samples of track 2 will be shifted to become the last 100 samples of track 1. And the first 100 samples of track 3 will be shifted to become the last 100 samples of track 2. Etc. Right?
 

CD Drive Offset and CueTools

Reply #7 –
A correction for a +100 sample offset would be -100 samples, so the tail end of track one would be moved to the beginning of track two, and so forth.  A +100 sample offset correction would go the other way.  The numbers listed in a CUETools log is the offset that is applied (an offset correction).