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: Andre's EAC Offset Calculation (Read 98708 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Andre's EAC Offset Calculation

Reply #51 –
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

Andre's EAC Offset Calculation

Reply #52 –
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?

Andre's EAC Offset Calculation

Reply #53 –
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.

Andre's EAC Offset Calculation

Reply #54 –
Quote from: benski on
Quote from: Sebastian Mares on

So Nero CD/DVD Speed also relies on EAC's calculation?


I would assume that all CD reading/writing programs that implement offset support are based on EAC's calculation. 


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

Quote from: Sebastian Mares on
I would answer all questions with "yes". Thing is, I have an LG unit with a 0 samples write offset. What I would like to be able to do is create a real 1:1 (excluding subcodes) copy of a CD.


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.

Andre's EAC Offset Calculation

Reply #55 –
Quote from: dv1989 on
...Plextor would seem to have known about this for a while.

Did Ipsedixit by any means used Plextor (parts) 
In theory, there is no difference between theory and practice. In practice there is.

Andre's EAC Offset Calculation

Reply #56 –
Quote
Did Ipsedixit by any means used Plextor (parts)
Yes. 716 & Premuim.

Andre's EAC Offset Calculation

Reply #57 –
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

Andre's EAC Offset Calculation

Reply #58 –
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?

Andre's EAC Offset Calculation

Reply #60 –
Quote from: Sebastian Mares on
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.

Andre's EAC Offset Calculation

Reply #61 –
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.

Andre's EAC Offset Calculation

Reply #62 –
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?

Andre's EAC Offset Calculation

Reply #65 –
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?

Andre's EAC Offset Calculation

Reply #66 –
Quote from: Spare Tire on
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?

Quote from: greynol on
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.

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.

Andre's EAC Offset Calculation

Reply #67 –
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.

Andre's EAC Offset Calculation

Reply #68 –
Quote from: greynol on
Think of it like specifying temperature in degrees Celsius or degrees kelvin.


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#-

Quote from: dv1989 on
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.


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.

Andre's EAC Offset Calculation

Reply #69 –
Quote from: greynol on
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?


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.

Andre's EAC Offset Calculation

Reply #70 –
Quote from: Spare Tire on
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.
So you can grasp how utterly trivial this whole thing is?

Quote from: Spare Tire on
And how important is it? You're asking it as if track boundaries are arbitrary.
They pretty much are.  Read the following questions and you'll better understand why.

Quote from: Spare Tire on
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.
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?

Quote from: Spare Tire on
I don't see how it seems picky to want the track to start where it is, in absolute terms.
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?

Quote from: Spare Tire on
So out of principle, even if it's an offset of one sample, it's one sample too much.
Who's principle?



EDIT: Formatting

Andre's EAC Offset Calculation

Reply #71 –
Quote from: The Legioneer on
Quote from: greynol on
Think of it like specifying temperature in degrees Celsius or degrees kelvin.

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.

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. 

Andre's EAC Offset Calculation

Reply #72 –
Quote from: greynol on
Quote from: The Legioneer on
Quote from: greynol on
Think of it like specifying temperature in degrees Celsius or degrees kelvin.

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.

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. 

Andre's EAC Offset Calculation

Reply #73 –
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.

Andre's EAC Offset Calculation

Reply #74 –
Quote from: Pio2001 on
But when someone uses the absolute offset, he can't check his rips in AccurateRip.
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.

Quote from: Pio2001 on
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.

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