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 98117 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Andre's EAC Offset Calculation

Reply #1
I'd say it's interesting, but Andre is right. Changing the offset correction now would make a mess of it.
At least by using the EAC way of offsets there is some sort of standard, you get the same results on every (offset corrected) drive.
Though it might have been nice to have it 30 samples more accurate, were talking about 0.68 milisec!
In theory, there is no difference between theory and practice. In practice there is.


Andre's EAC Offset Calculation

Reply #3
Without question, I understand Andre's point of view, and why its far too late in the game for hairs to be split and databases wiped over 30 samples. In the grand scheme of things, compared with how far the AccurateRip database has been implemented, these 30 samples are negligible.

However, as a consumer of EAC, I've bought into the idea of this Holy Grail: as close as possible 'bit perfect' audio extraction. Is that not why EAC was developed?

Is all existing offset data based on what Andre has done with EAC? Has any come directly from the manufacturers that could prove or disprove the exisiting data?

For my own archiving, can anyone confirm the claim that Andre's EAC offsets are -30 samples off? I'm admittedly no expert, but would love to hear if there's any validity to what IpseDixit says.

Thanks.

 

Andre's EAC Offset Calculation

Reply #4
Eh, 30 samples really is nothing.

Andre's EAC Offset Calculation

Reply #5
I wonder if there could just be a checkbox in the offset options, that is on by default, and adjusts the offset by 30 samples.

That way the existing database can stay, and old EAC's would be the same, but new versions of EAC would be able to easily address this issue, whilst still relying on the existing database.

Andre's EAC Offset Calculation

Reply #6
Couldn't those 30 samples create problems if a disk is many times ripped then burned? I know it would probably be a stupid thing to do but it seems like the photocopy of a photocopy empirical experience. It can became a problem for such archives that will be burned and ripped again.
I really think that, even if there are all these databases, if would surely be safer to correct the bug. It could be an option checked by default which would be better than a stealth option activated by offsetting actual offsets...
If all the databases are affected by the bug, which is basically EAC specific, isn't this ugly for other ripping programs which rely on accurate rip?

Sorry but I cannot find reasons to take this as easy as Andre does.
[edit:]spelling
Stupidity is root of all evil.

Andre's EAC Offset Calculation

Reply #7
In order to make a bit-perfect copy one must always correct both read and write offsets (or else use a combined read-write offset) for the particular drive. If you change the read offset by 30, and make the same fix to the write offset, then you still make bit-perfect copies, no matter how many generations deep.

Andre's EAC Offset Calculation

Reply #8
30 samples is really a non issue, and those 30 samples at the end of a CD will 99.99999999% be certainly all 0's.

According to the CD spec, normal (non-computer) cd players would get no where near 30 samples of the right starting point, they could be 1000's out.

Andre's EAC Offset Calculation

Reply #9
But they don't read for the purpose of storing or duplicating the data. Different jobs put different demands on the hardware and accuracy.
Veni Vidi Vorbis.

Andre's EAC Offset Calculation

Reply #10
It's a well-known fact that different CD-DA manufacturers differntiate in their exact starting/ending possitions, as i have read by others that this place also isn't given in a precise and absolute place in the Red Book, but gives some room for differences. What Andre did, was to look at many CDs, and found some that had background noise right up to the start/end sample of the CD, which means that he could found out at where exactly the audio was starting/ending. From this value, then he could found out how much that differentiated from his drive's extraction starting/ending point. After he had looked at many CDs starting/ending possitions, he found 5 or 6(can't remember which) that had the exact same starting/ending possitions of all the CDs he tested(of course many other CDs had other and varying starting/ending possitions), and so he then concluded that as he had 5(or 6) with the same starting/ending possition, then that would probably be the most frequently occuring starting/ending possition that CDs start/end with. This also means that it is very easy to go to some CD-DA manufacturer and look at the offset they use, and found it to be 30 samples of off Andre's.
The point is that offset's are good for having a common reference, as Andre's is, but one should not believe that offsets will make extractions any more exact, since the inbuild offsets of CDs varies from one cd manufacturing plant to another...

More info by the knowledegeble Pio2001  :

(which is where i have learned these things from, by reading his comments...)

http://www.digital-inn.de/showthread.php?threadid=4193

and :

http://perso.numericable.fr/laguill2/offset/offset.htm

Andre's EAC Offset Calculation

Reply #11
http://pageperso.aol.fr/Lyonpio2001/offset.htm


I can't admin this page anymore. Update your bookmarks. The new URL is http://perso.numericable.fr/laguill2/offset/offset.htm

However, as a consumer of EAC, I've bought into the idea of this Holy Grail: as close as possible 'bit perfect' audio extraction. Is that not why EAC was developed?


In practice, correcting the offset with these 30 samples won't give you copies anymore perfect than your current ones. Remember that commercial CDs are all offsetted from each other. There is nearly no one that respects the real offset.
If you want a bit perfect copy, force the overreading into lead-in and lead-out, and remaster these parts yourself, creating a new cuesheet. It's the only way not to miss a single bit from the original, since anyway, the factory always puts some "relevant" info into either lead-in or lead-out, according to the direction they offset their CD. (I mean relevant for bit-exact copy, not for any particular practical purpose).

Is all existing offset data based on what Andre has done with EAC? Has any come directly from the manufacturers that could prove or disprove the exisiting data?

For my own archiving, can anyone confirm the claim that Andre's EAC offsets are -30 samples off? I'm admittedly no expert, but would love to hear if there's any validity to what IpseDixit says.


I can confirm that the way Ipsedixit calculated his offset is correct and gives an absolute result.
He captured the output of the optical sensor in a CD player and stored an image of the pit and lands of a given CD. He then produced a binary version of these pits and lands, then computed all the subcode extraction and audio deinterleaving with a custom software. Then he compared the result with an offset corrected extraction of the same CD.

Since the Red book does not define where the real audio starts, he used the most obvious way, that was confirmed to him by some guys in a CD mastering society : The first symbol of the first frame of the first CD track is in the first sample of the PCM data (Which means that all other symbols in this frame belong to the pregap).

I can't confirm his result because I can't capture the output of the optical bloc of any of my drives. I can just confirm that his method is right, while Andre Wiethoff's one was just an approximation.

Couldn't those 30 samples create problems if a disk is many times ripped then burned? I know it would probably be a stupid thing to do but it seems like the photocopy of a photocopy empirical experience.


No, as long as the read offset correction and write offset are opposed, the copy is not offsetted from the original. This is true whatever offset reference you choose.

If all the databases are affected by the bug, which is basically EAC specific, isn't this ugly for other ripping programs which rely on accurate rip?


All ripping programs which rely on AccurateRip perform the wrong correction. It is the first time that the real offset is published on the Internet to my knowledge. Plextor engineers must have known it before, since they have manufactured drives with this offset for some time already. Even Plextools pro skews the right offset of Plextor drives in order to be compatible with EAC and AccurateRip.

I wonder if there could just be a checkbox in the offset options, that is on by default, and adjusts the offset by 30 samples.

That way the existing database can stay, and old EAC's would be the same, but new versions of EAC would be able to easily address this issue, whilst still relying on the existing database.


Why not ? It would just mean that every ripper should be modified so that it offsets data by 30 samples when it communicates with offset databases or Accuraterip.

The good side would be that manufacturers could then produce non-offsetted drives relying on a very simple standard, turning offset correction a thing of the past. They could even achieve the zero offset without knowing these issues, just taking the first symbol of the first frame of the first track as the first sample of the PCM data.

The bad side would be that CRC calculations would become very difficult from pre-existing wavs. It would not be possible at all to check an isolated wav in AccurateRip database, because we would miss the 30 extra samples necessary for the calculation.

The situation is similar to the gamma correction in television. Engineers decided to include the gamma pre-correction in TV cameras, and let the end user hardware run without correction, instead of the opposite.
In our situation, it would mean letting the drive manufacturers work with EAC's current offset, and let all user databases and CRC calculations unchanged.
This would require to make an addition to the Red book that would state EAC's offset as being the reference offset.

Andre's EAC Offset Calculation

Reply #12
As for the AR issue, I wouldn't be surprised if there were an extra unused bit somewhere in the current protocol that could be set for the submissions/requests that were 30-offset-corrected. 

Yes, it means dual sets of data, but as software started using that method more and more, the older non-corrected records could be removed from the database (several years?).

-brendan

Andre's EAC Offset Calculation

Reply #13
You have 8 million tracks submitted to the database, they are not going to go away.

Andre's EAC Offset Calculation

Reply #14
You have 8 million tracks submitted to the database, they are not going to go away.

Guess the ball's in your court, spoon! 

Andre's EAC Offset Calculation

Reply #15
This is very interesting . . . one to watch for me!

Andre's EAC Offset Calculation

Reply #16
My vote defenetly goes for keeping the current reference offset intact(Andre's). The ones that would like the reference offset to be changed by 30 samples, wants it because they think that there extractions will then be perfect, and fails to understand that the usefullnes of using offset correction hasen't got anything to do with perfect extractions, but rather a) to have an absolute reference so that all extractions start/end at the same place and hence, will give the same checksums no matter what drive was originally used, and b) to avoid generation-loss when making several generations of copies of copies. Ipsedixit has correctly calculated his drive's offset based on a specific starting/ending possition that some manufacturers use, but when the starting/ending possition then changes wildly from one manufacturer to another, then just using Ipsedixit's offset correction value for all the CDs we rip will not make them all perfect, as for that we would need to adjust the value between every disc we rip, and we don't even know the value in advance before we rip them. Since the Red Book alows for varying starting/ending possitions for CDs, then the idea og using one offset correction value for all CDs for making perfect extractions dosen't make sence, but that said, i personally use offset correction when i rip my CDs, as even though i know they will not be any more perfect, then there really isn't any reason not to use it. Also i get the added advantage of later being able to compare the rips easilly with the use of other drives...

Martin.

Andre's EAC Offset Calculation

Reply #17
As I understand, manufacturers can press CD's with various levels of "main to subchannel skew" (or something similarly-named). Ipsedixit seems to have discovered the offset for CDs with no skew - and, hence, the closest thing to a "correct" offset which we can get. Moreover, as Pio2001 has said, Plextor would seem to have known about this for a while. However, I understand the huge problem in now implementing a new correction!

Andre's EAC Offset Calculation

Reply #18
Thanks for everyone's answers on the subject. It has become clear to me now that while "bit perfect" audio extraction is far from a myth, it's a terribly cumbersome process that would have to be uniquely applied to each disc. A streamlined method simply isn't possible with the loose Red Book standard and limitations of the technology.

I think it's fair to say there's a consensus that Andre's calculations are at least a little off. He has stated himself in the thread at the EAC forum that his offset was an "approximation" and was not "the absolute correct and only possible (zero) offset." So my question is this: if he determined his offset using commercial CDs and this method transcribed by Pio2001, and it's accepted that different studios make commercial CDs with different skews, Andre's calculation could be based off a series of discs that were all skewed from zero by the same amount; yielding identical, yet inaccurate results. Therefore, this disc given to IpseDixit that was manufactured with no skew would be able to provide the offset for "absolute zero reference," would it not? Granted in practice, very few, if any, commercial discs would actually adhere to this standard, but if all CDs were manufactured with zero skew, then this would be the vehicle to allow a perfect copy (provided the drive can overread into the lead-in/lead out). So while adopting the new offset won't automatically make your extractions bit perfect, it is a step closer for us perfectionists out there.

Basically, I see two camps developing here: one in support of the standard EAC reference offset, and the other, a small group of purists, who'll integrate the new offset into their extraction process. In any event, Andre's EAC offset is the standard, like it or not. It's the measure for which all drives are calibrated by EAC to produce identical results. None of that is going to change. However, there is an alternative now, a way to get results closer to "perfection" by breaking away from the old convention. Use whichever method you see fit. I can't fault anyone for going either way.

The Legioneer

I am by no means an expert on what I've said above, just had a few extra minutes to think while sitting in traffic on the way home from work. So if I've said anything erroneous, feel free to debunk. Thanks.

Andre's EAC Offset Calculation

Reply #19
However, I understand the huge problem in now implementing a new correction!
I don't think that the implementation is a huge problem whatsoever.  spoon just hits the delete key on the existing database of user submissions, subtracts 30 from the offsets of each drive in the database and everyone gets an updated DriveOffsets.bin and is forced to recalibrate their drives.  The only troublesome part that I can identify is the last part.  Sure this would be a major setback which would require repopulation of the database, but it is still relatively young.  Considering how many people use it now, I wager that it would grow to its current size much more quickly than the time it took to get it to this point originally.

Basically, I see two camps developing here: one in support of the standard EAC reference offset, and the other, a small group of purists, who'll integrate the new offset into their extraction process. In any event, Andre's EAC offset is the standard, like it or not. It's the measure for which all drives are calibrated by EAC to produce identical results. None of that is going to change. However, there is an alternative now, a way to get results closer to "perfection" by breaking away from the old convention. Use whichever method you see fit. I can't fault anyone for going either way.
While this may be true for data that isn't burned back to CD, the fact is the vast majority of discs burned with a proper write samples offset that yields a combined read/write offset of zero will still give you an identical copy with the only difference being those discs where the first 30 samples are not null.  The good thing is that this new offset requires less writing to the lead-out (for drives with a negative write samples offset less than -30 by the currently implemented standard), which doesn't seem to be possible for any drive.

Andre's EAC Offset Calculation

Reply #20
There are no CRC database for image+cue yet so i'd say when we start it off, we should take the opportunity to set it right once and for all with rips coming from drives with the correct offset.
As for the tracks, we should phase it out gradually. I don't know how the transition will be but it shouldn't be that complicated.

Andre's EAC Offset Calculation

Reply #21
If it was corrected to true zero, what percent of our rips will then be truly "Bit Perfect™"? Does anyone know? Might we just end up with more rips being further skewed from reality?

Andre's EAC Offset Calculation

Reply #22
What does "bit perfect" mean to you ?

For me, bit-perfectness does not depends on offsets.


Andre's EAC Offset Calculation

Reply #24
I never understood this obsession with having a "bit perfect" audio CD copy.