But what do you do with drives that have asymmetric read and write offsets where you cannot get a combined read and write offset of 0 (like for BenQ for example)?

Just follow the regular equation:

write samples offset = combined offset correction - read offset correction

For a BenQ according to Andre's reference:
write samples offset = 684 - 66 = 618

In the case of the shifted "absolute" reference:
write samples offset = 684 - 36 = 648


...or for a Lite-On SOHR-5238S (which, like the PX-760A, has combined offset of 0):

Andre's reference:
write samples offset = 0 - 6 = -6

"Absolute" reference:
write samples offset = 0 - (-24) = 24

To be honest, I guess I will dump this whole offset thingy and use 0 samples read offset and 0 samples write offset for all drives. It's not that I will miss any important data, but considering that nothing is 100% correct (Andre's method is an average, the other method works well only for CDs with 0 samples offset), why bother?

From what I understand, Andre used the median value from 10 discs which he (erroneously) assumed the beginning coincided with the first sample that wasn't null in order to determine his reference.

Anyway...

If you're trying to copy CDs so that the data won't be shifted from the original, you need to shift the data before burning so that the combined effect of your reader's read offset and writer's write offset is zero.

If you're trying to rip tracks so that they will be the same regardless of the drive used as a reader, you need to pick a common reference. If you want to use AccurateRip, you'll need to use Andre's reference which is the accepted standard, even though it has now been shown to be incorrect.

I was trying to address a subtlety regarding which reference you choose so that you're able to duplicate the most samples that are not null. For the vast majority of discs, especially the ones made today, this is totally irrelevant. But considering that it seems there are a number of people here who feel it is terribly important that they can preserve every last sample, I thought it would be an interesting point to raise.

I don't know Nero, but I think that it only implements combined offsets (maybe set as read offset), without any reference.



But there is no way to get all the (irrelevant) data from the lead-in, nor from the lead-out. It is already barely possible to do so for the first pre-gap, hacking into the registry settings of EAC.

Did Ipsedixit by any means used Plextor (parts)

Yes. 716 & Premuim.

If you mean the drive used for the experiment, it was this : http://ch.twi.tudelft.nl/~sidney/fpga/sanyo.jpg
The "GND EFM" plug outputs the pits and lands seen at the CD's surface.

The pits and lands are recorded with this : http://ch.twi.tudelft.nl/~sidney/fpga/fpga.jpg

...Then analyzed in the computer.

Read more : http://forum.cdfreaks.com/showthread.php?t=111913#post726955

Does this issue only effect the first 30 samples of the first track? or each track? I can understand how losing these 30 samples isn't an issue for most CDs because they are going to be 30 samples of silence, but does this cause problems with (live etc) albums that have tracks directly running into each other?

It affects either the first or the last track.

No, it doesn't.

The issue at hand is a shift in the reference point and since it's a shift it will affect all of the tracks.

But because it is a shift, no data will be lost between any of the tracks.

And since we're talking about a reference point, there really is no point in discussing what is "lost" without making some kind of comparison and specifying the reference.

I was referring to data being lost, sorry. Of course all tracks are affected because everything is shifted either x samples forth or back. Thing is that an incorrect offset correction will have negative consequence on either the first (samples missing at the beginning) or the last (samples missing at the end) track.

Oh ok, so in theory, the 30 samples that should be at the start of track 2 are going to wind up on the end of track 1 (or there other way round, doesn't matter)... but the point is the data is still there?

For a moment I thought you mean "no, data will be lost between any of the tracks". What a simple comma can do.

If you rip only certain tracks, then you could say that yes data is lost for that track. It would also have extra data from some other track. Right?

So, with this in mind, if you rip two adjacent tracks with two different offsets, you'll either get repeated samples or missing samples.

IMO, it is pretty pointless to talk about what samples belong to what track unless you also specify a reference. And even if you do specify a reference, how important is this really?

Think of it like specifying temperature in degrees Celsius or degrees kelvin.

Do skew or the corrected offset affect the accuracy of indexes, track starts, etc.?

Overall, the corrected offset is the best reference value that we can get; is that the case? I can't see a better way, short of manually hacking into the beginning/end of every CD to extract all non-silent samples. It's obviously a huge shortcoming of the standard that confusion like this still reigns - although I can understand that sample-perfect extraction was not high on the list of priorities when compiling the Red Book.

I can see your argument, but I have to disagree. I think that analogy is going to cause more confusion than clarification. If a CD were a phonograph or record, then the offset would affect precisely where the needle was dropped to start playing the album. Yeah okay, I'm not sure that comparison's any better, but in any event, if you're still unclear on what the offset actually is, here are the two best reads I can offer:

http://users.fulladsl.be/spb2267/offsets/offsets.htm
http://users.pandora.be/satcp/eacoffsets00.htm#-



Yes, adjusting the offset will, in effect, shift the entire scope of audio extracted from the disc.

I believe the consensus is that IpseDixit's proposed offset in the most accurate reference available to date. Anyone who sees it differently is free to dispute that claim. It's unfortunate there's so much leniency in the Red Book specifications, but it helps to bear in the mind that the standard is 26 years old.

We've been talking about the 30 sample offset since the beginning of the thread, for three pages, why do i have to explicitly say that the there are 30 samples different from the "real" offset and what i've been using up to now.
And how important is it? You're asking it as if track boundaries are arbitrary. How much sense would it make for a live musician to start playing at the middle of a song when you ask him for that song, or to start playing from the middle of last song when you ask for the one after that. I don't see how it seems picky to want the track to start where it is, in absolute terms. So out of principle, even if it's an offset of one sample, it's one sample too much.

So you can grasp how utterly trivial this whole thing is?

They pretty much are. Read the following questions and you'll better understand why.

As if 680 microseconds is even comprable to the middle of a song.

You do realize that the finest resolution for which an album can be cut is 1/75 of a second? This is over an order of magnitude greater than this shift that is being discussed.

Do you think a live musician is going to alter the tempo of his or her performance just so the CD can be cut at precisely the correct point?

It isn't that it seems or doesn't seem picky, it is literally irrelevant.

Are you aware that the red book standard on digital audio has no definition of where a track starts in absolute terms?

Are you aware that CD players of all shapes and sizes, makes and models, do not adhere to any notion that a track begins in some absolute and calibrated spot?

...and last but by no means least...

Are you aware that you can buy two copies of the exact same title and the points where tracks are divided can be off by thousands of samples between the two copies?

Who's principle?



EDIT: Formatting

The temperature analogy is spot on if you ask me. It's much better than the needle drop since there is no precision with which the needle will fall unlike a CD player.

Kelvin is an absolute system which is directly proportional to molecular motion which is what temperature literally measues. This is the same as this new offset figure with zero skew. Each track begins at a certain temperature on the scale with the very first sample after the lead-in corresponding to zero.

Celsius is a system that has a reference that is relative to the point where water freezes.

The resolution of both systems are identical and are defined by dividing the difference between where water boils given a specific pressure and where it freezes by 100. In the case of the offset, the resolution between the two systems is also identical and is that of one sample.

Most of the world gets by just fine using the Centigrade system without the need for an absolute reference. In day-to-day life for the entire world, temperature is related to the freezing of water, a practical yet arbitrary reference point; much like Andre's reference.

Fahrenheit is a bit more funky and has a different resolution and a slight shift when it comes to the zero point. Maybe we could compare it to the 48kHz sample rate or 45 RPM instead of 33 1/3 RPM (back to your record analogy). Of course as an American, I think the extra resolution is more useful since the human body is capable of sensing changes of a single degree. It's getting a bit thick now, isn't it? Well, that's probably why I chose to compare Celsius and kelvin instead of Celsius and Fahrenheit.

PS: Those are good links, BTW. They are exactly the same ones that I use.

Okay then, I retract my statement.

I prefer the analogy of the needle. When someone uses Celsius degrees, someone using Kelvins can convert the Celsius into Kelvins. But when someone uses the absolute offset, he can't check his rips in AccurateRip.

By the way, the Red Book is not a very loose standard. If you think about it, there is only one way to interpret the subcode / data offset in a simple way without having to introduce pre-buffering, and this is the way that defines IpsetDixit's offset.
It is just implicit in the red book. It assumes that the reader will obviously use the right offset. The "problem" is just that it is not explicitely given.

Sure he can. I often check my rips that don't exist in the AR database against different pressings that do quite frequently by doing the exact same thing you would do when converting betwen Celsius and Kelvin: subtraction.


Thanks for this and all of your contributions to this thread. I have learned a lot from you over the years.

So, who is thinking of adopting this new reference?

I think that I will: assuming that my understanding of earlier posts is correct, I will be changing the offset for my Lite-On LTR-52327S from +6 to -24. Am I correct to assume that the write offset will also require changing - in this case, from -6 to +24?

Hi Pio2001

I have been thinking about this for some time know and i must confess that based on your quoted comment above, then it seems that i do not understand this subject at all

Could you please tell me how Andre's results could ever just be an aproximation ? What i seemed to think, was that as Andre looked at discs where there where non-null samples i.e. background noise up untill the very last sample before the lead-out begun, then he actually did have the ability to calculate the precise CD offset values of the CDs that he tested, and not just an aproximation of the CD offsets used on them. To me, then the new reference result and Andre's result, just vitnesses that two different CD offsets was used for the measurement. In fact, it could be that Andre also found the new CD offset that we are discussing here, when he did his tests, but as he decided on the one specific value, that repeated itself the most often(6 times out of all the ones tested), then he could e.g. have found the new reference 2 times and the established reference 6 times, since as you know, Andre said that he found many different CD offsets on the tested discs, but just selected the most frequently occuring. So pio2001, i would be very happy if you would please enlighten me on the following thoughts of mine, please

Thank's in advance.

@dv1989: Yes, the write offset will of course also be affected if changing from one reference to another one

CU, Martin.

Same here.

Martin, I agree; any more light shed by such knowledgeable people such as Pio2001 is always welcome! And thanks for the clarification with regard to the write offset (not that I ever use it, but let's be consistent!)

I agree. I do want the audio part that I can hear to be bit-perfect. With FLAC files of each track, I can then recreate a copy of the original CD that for all practical intents will be the same as the original. I can put it in a CD player and it will play each track as it did from the original CD. Maybe it would not hit freecddb as it used to, but I don't really care. After all, the FLACs are just backup copies to be used if some of my CDs break.

So why should I care about bit-perfect copies?

Some ppl are perfectionists and others aren't. that's it

@dv1989: Cheers mate

This new reference isn't going to give you copies that are any more bit-perfect than Andre's reference except for discs that begin with 30 audio samples that are not null which are becoming increasingly rare.

edited my bad grammar (and spelling, sheesh!)

As if that is audible anyway.

HA upholds audibility difference (re: TOS #8), explicitly demanding all poster to prove audible difference using ABX... and all this high standard gets thrown out of the window when you're ripping

Let me think of a proper term... not audiophile... bitperfectionophile

The ability to ABX a track that is offset by 30 samples can be easier than you think.

Not me. The Accuraterip database is too important a reference IMO and I agree with Spoon's decision in not changing it. It's not worth it for all the reasons cited already.


ABX requires time aligned samples.

I know, I know. The purpose of the test would be to see if you can tell whether or not you music is offset by 30 samples. Pointless.

...as opposed to 29 or 31?

How about a blind test to determine the exact size of the offset between two samples?

Yeah, it's absolutely pointless, but that's not what I meant originally.

But what if those 30 samples are null? Can you ABX the extra silence?

Ok, I can buy that. Perfect acceptable reason in my book. And thank you for your answer, because you confirmed to me that I don't care

Now, please go back to your regular bit copy talk and I will shut up.

This is beginning to remind me of Aquarium's posts in that thread at Digital-Inn . . . and that's not a good thing!

In case that was directed at me, here are my ABX results:

foo_abx 1.3.1 report
foobar2000 v0.9.4.2
2006/12/11 18:40:05

File A: C:\Untitled (1).mp3
File B: C:\Untitled (2).mp3

18:40:05 : Test started.
18:40:41 : 01/01 50.0%
18:40:45 : 02/02 25.0%
18:40:50 : 03/03 12.5%
18:40:53 : 04/04 6.3%
18:40:57 : 05/05 3.1%
18:40:59 : 06/06 1.6%
18:41:01 : 07/07 0.8%
18:41:14 : 08/08 0.4%
18:41:21 : 09/09 0.2%
18:41:26 : 10/10 0.1%
18:41:33 : 11/11 0.0%
18:41:43 : 12/12 0.0%
18:41:58 : Test finished.

----------
Total: 12/12 (0.0%)

I will gladly upload my samples if anyone is interested.



PS: I can repeat the test for the original lossless files and upload them instead if you think this will make a difference.

What did you test though? 30 samples of null or a song offset by 30 samples?

The end of a track just prior to the beginning of the next and the same thing offset by 30 samples.

You do realise that the audiophile crowd (those who can tell the difference between wav and lossless compression ie numpty's) are going to see this ABX test as being quite significant.

Not at all, it's futile,
first, this is not a standard (to me at least ). It's just an interesting result.
second, I'm stil sceptic that this result might be (Plextor) hardware specific (although that might not be very important).

Also, as long as the offset of your drive is not exactly zero, you will still lose a few samples (at the beginning or the end).
And with write offset correction you burn the the samples on the right spot, still with the current EAC read offset correction.

Oh and 30 samples is not the thing to worry about, it's getting similar results with different drives, that is the point.

Personally i will continue to use Andre's reference also. I am also not obsessed with "getting the perfect rip", but i just think that the issue is interessting to discuss Another thing i would like to say, is that i think that we need to begin to use a consistent terminology for using the word bit-perfect. To me, then the word bit-perfect means that all the bits of the original CD-DA is copied perfectly(but only the mainchannel data and not the subchannel data, lead-in(with the TOC), lead-out and the parity bytes of the CIRC system). Many people use the term for meaning that just all the audio bits are copied perfectly, but IMHO that is not bit-perfect. To me, then bit-perfect means that as all bits needs to be copied perfectly, then we cannot just take the audio bits into account, but also the null samples before and after the first and last track. This is the reason why i often say that it isn't possible to make bit-perfect rips, since CDs themselves have their own built-in offsets also. Sure, all audio bits can be copied without a problem, but to me, then bit-perfect should stand for also getting the precisely number of mastered null samples before/after the first/last track of the album also copied perfectly. Please understand that this isn't something that i personally is concerned about doing, and i'm happy if just the audio bits have been copied error-free, but this is what the term bit-perfect personally mean to me.

CU, Martin.

All of this reminds me of something I wanted to try a long time ago. I was always annoyed when people used the wrong offset, so I got the idea that if the samples in the beginning and end were null, couldn't I just delete the extra bytes in the beginning and add the same amount of null samples to the end in order to fix the offset correction?

So here's what I did,

I ripped the same track with both Andre's offset and the new one.
Andre's (old) = +97 (CRC=B8954265)
New = +67 (CRC=6E1701B7)

Luckily for me the first track began and ended with plenty of null samples.

I was going to be messing with the raw audio data, so I used wvunpack to decode my WavPacks to raw audio with the command (-mr).

Then, I opened up my hex editor (XVI32) and the old rip (Andre's offset) (.raw). Then I added 120 bytes (=30 samples) to the beginning of the file and removed 120 bytes from the end. (I knew I was on the right track when I did a CRC hash in XVI32 and it matched the CRC from the new rip (6E1701B7))

After saving the new file, I encoded it to FLAC with the command (-V -8 --endian=little --sign=signed --channels=2 --bps=16 --sample-rate=44100). Then I decoded it to wav, and then encoded it back to WavPack. The original MD5 stored in both this new file and the one made from the new offset were exactly the same (2E4284CD29FEF1E0C19DD3D02658B289).

So, by using this method you can fix someone's rip with a wrong offset simply with a hex editor. Although, if the samples in the end of each track are not null, you would have to do this with the album as one large wav. There is also the chance that some bytes may be missing from thier wrong offset, so it's always important to check the beginning and end for null samples.

The funny thing is, it's probably easier to just to burn a CD-r with the proper offset and rip from there.

Anyway, I doubt anyone will seriously do this just to fix someone's offset correction to match the new calculation, but I thought i'd be funny to simple show that it was possible in some cases.

No kidding! There's a big difference between saying I can easily ABX a track and saying I can easily ABX any track.

You may find that it is much much easier to mount the tracks as an image to a virtual drive and configure that virtual drive with a read samples offset of -30.

I'll be sticking with the classic reference so long as it is the one being used in AccurateRip.

I didn't think you could mount the images because of the non-compliant cues, but editing the cue is definitely faster and safer than burning a cd. I still think it's important to check the files just in case it looks like there are missing samples.

I think I want to use the new reference, but it doesn't look like it'll be too popular. Still, isn't having it bit perfect one of the main reasons for lossless? I've been an absolute perfectionist before, so why should I stop now when I can apparently make my rips more accurate?

You can't with noncompliant sheets, but with EAC it's really easy to make a compliant cue sheet. I've also created a batch that will make a compliant sheet out of a noncompliant one.
It can be found here:
http://www.hydrogenaudio.org/forums/index....st&p=452891

Besides nonsilent samples at the beginning of track 1, which are so incredibly rare, what are you talking about?

I think this is an illusion and have already went out of my way in saying why in this thread. To me lossless is a compression format which is completely independent of DAE.

Go back and read what I said to SpareTire regarding frame boundaries and different pressings.

Also, don't take my comment regarding the ABXing of two tracks that differ by an offset too seriously. If a track boundary is so close to the beginning of a song that 30 samples is going to make a difference I would consider the disc as not being mastered well. I've seen a few discs where the track boundary noticeably starts into a song. If you don't agree with me on my previous example hopefully you'll agree that these other discs have legitimate problems.

The "non-compliant" cue type is only for rips of separate tracks with gaps (if present) appended to previous tracks.


But, as was said above, not all discs are manufactured in conformance with that "new" zero offset reference. If you use the new reference, what percent of your rips will be more accurate vs. less accurate?