Sorry to blatantly post a link to another thread, but I'm curious as to what the forum's take on this is:
http://www.digital-inn.de/exact-audio-copy...ay-offsets.html
Full Version: Andre's EAC Offset Calculation
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!
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!
I have yet to dive into the discussion and links, but I'd really like to see a reponse from both spath and Pio on the subject.
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.
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.
Eh, 30 samples really is nothing.
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.
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.
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
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
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.
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.
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.
But they don't read for the purpose of storing or duplicating the data. Different jobs put different demands on the hardware and accuracy.
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
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
QUOTE(Martin H @ Nov 19 2006, 17:11) 
I can't admin this page anymore. Update your bookmarks. The new URL is http://perso.numericable.fr/laguill2/offset/offset.htm
QUOTE(The Legioneer @ Nov 18 2006, 20:45)
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).
QUOTE(The Legioneer @ Nov 18 2006, 20:45)
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.
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.
QUOTE(damaki @ Nov 18 2006, 23:55)
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.
QUOTE(damaki @ Nov 18 2006, 23:55)
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.
QUOTE(rh2600 @ Nov 18 2006, 23:54)
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.
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
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
You have 8 million tracks submitted to the database, they are not going to go away.
QUOTE(spoon @ Nov 20 2006, 00:31)
You have 8 million tracks submitted to the database, they are not going to go away.
Guess the ball's in your court, spoon!
This is very interesting . . . one to watch for me!
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.
Martin.
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!
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.
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.
QUOTE(dv1989 @ Nov 21 2006, 15:23)
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.QUOTE(The Legioneer @ Nov 21 2006, 17:53)
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.
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.
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.
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?
What does "bit perfect" mean to you ?
For me, bit-perfectness does not depends on offsets.
For me, bit-perfectness does not depends on offsets.
I think he means having an exact image of the audio CD.
I never understood this obsession with having a "bit perfect" audio CD copy.
For what it's worth, I used a method similar to the one described on Pio2001's page. I did it on 74 CDs, the results are here:
The numbers listed are offsets (with respect to the current EAC reference offset) needed to make the first track start on a non-zero sample, and to make the last track end on a non-zero sample, respectively. The start offsets can go no lower than -1160 for the start tracks, and no higher than +472 for the end tracks (these are the offsets of the drives I used to rip the start and end tracks, they can't overread). Most of the numbers aren't helpful because the beginning/end are padded with silence. There is only one number that sticks out to me which is -12 (3 CDs have that as their start offset, and 11 CDs as their end offset). There are no CDs with a -30 offset, so to me it seems pointless to change the reference offset when it's not going to bring any practical benefit.
CODE
2Gether-2Gether 15622 -4507
2Gether-Again 15319 -20753
98_Degrees-98_Degrees_And_Rising 14477 -29145
98_Degrees-Revelation 16172 -7003
98_Degrees-This_Christmas 15337 -108250
Aly_And_AJ-Acoustic_Hearts_Of_Winter 14760 472
Aly_And_AJ-Into_The_Rush -1160 -12
Aly_And_AJ-Into_The_Rush_(Deluxe_Edition) 318 472
Aly_And_AJ-Into_The_Rush_(Japan) 147 -789
Aly_And_AJ-Into_The_Rush_(Rerelease) -1160 -13
A-Teens-Teen_Spirit 15674 -23659
A-Teens-The_ABBA_Generation 16968 -5169
Avril_Lavigne-Let_Go 15360 -13854
Backstreet_Boys-Backstreet_Boys 16551 -12
Backstreet_Boys-Black_And_Blue 23348 -11448
Backstreet_Boys-Millennium 17101 -5585
BBMak-Into_Your_Head 17921 -36561
BBMak-Sooner_Or_Later 43914 -12
BBMak-Sooner_Or_Later_(Japan) 45078 -33264
BBMak-Sooner_Or_Later_(UK) 45250 -93604
Brie_Larson-Finally_Out_Of_PE 14163 -12266
Britney_Spears-Baby_One_More_Time 24254 -12
Cheyenne_Kimball-The_Day_Has_Come -12 -12
Christina_Aguilera-Christina_Aguilera 12724 -32087
Christina_Aguilera-What_A_Girl_Wants_(Single) 15301 -15511
Covent-Nexus_Polaris 17111 -7652
Dream_Theater-Metropolis_Pt_2_Scenes_From_A_Memory 24053 -1878
Dream-He_Loves_U_Not_(Single) 15445 -17251
Dream-It_Was_All_A_Dream 18256 -3148
Dream-This_Is_Me_(Remixes) 16825 -6995
Evanescence-Fallen 11468 -15763
Hilary_Duff-Santa_Claus_Lane 634 -12
Hoku-Hoku 15367 -4506
In_Flames-Come_Clarity 658 -12
JC_Chasez-Schizophrenic 15466 -3667
Jesse_McCartney-Beautiful_Soul -1160 -12
Jessica_Simpson-Sweet_Kisses 14755 -5378
Jump5-All_The_Time_In_The_World 636 -87648
Ks_Choice-The_Great_Subconscious_Club 19119 -5920
Lacuna_Coil-Comalies 45977 -118426
Lacuna_Coil-In_A_Reverie 45449 -120340
Lacuna_Coil-Unleashed_Memories 45502 -6635
LFO-Life_Is_Good 2 -12
Liberty_X-Thinking_It_Over 49261 -84313
Lindsay_Pagano-Love_And_Faith_And_Inspiration 15691 -6411
M2M-Shades_Of_Purple -12 -4804
Mandy_Moore-Candy_(Single) 17957 -3705
Mandy_Moore-Mandy_Moore 39136 -9195
Mandy_Moore-So_Real 722 -16303
McFly-Room_On_The_3rd_Floor -1160 -86372
McFly-Wonderland -12 -12
Mudvayne-The_End_Of_All_Things_To_Come 14537 -7110
No_Doubt-Tragic_Kingdom 14725 -3224
NSync-Home_For_Christmas 17234 -23933
NSync-No_Strings_Attached 7972 -4574
NSync-NSync 16831 -519
Opeth-Blackwater_Park 14799 -5383
O-Town-O2 698 -11294
Play-Dont_Stop_The_Music 15340 -5052
Play-Girls_Mind 16525 -13544
Play-Play 14018 -22647
Play-Play_Around_The_Christmas_Tree 636 -12
Play-Replay 37409 -44907
Play-Us_Against_The_World 16623 -16246
Sarah_McLachlan-Surfacing 8876 -2096
Stacie_Orrico-Genuine 15586 -3172
The_Gathering-Mandylion 46148 -7756
The_Kovenant-Animatronic 16903 -2445
Tool-Undertow -1157 -15455
VA-Kaerlekens_Spraak 24164 -29135
VA-Pixel_Perfect 670 -88212
VA-Radio_Disney_Holiday_Jams_2 15400 -3978
Winds-Reflections_Of_The_I -1160 -22
2Gether-Again 15319 -20753
98_Degrees-98_Degrees_And_Rising 14477 -29145
98_Degrees-Revelation 16172 -7003
98_Degrees-This_Christmas 15337 -108250
Aly_And_AJ-Acoustic_Hearts_Of_Winter 14760 472
Aly_And_AJ-Into_The_Rush -1160 -12
Aly_And_AJ-Into_The_Rush_(Deluxe_Edition) 318 472
Aly_And_AJ-Into_The_Rush_(Japan) 147 -789
Aly_And_AJ-Into_The_Rush_(Rerelease) -1160 -13
A-Teens-Teen_Spirit 15674 -23659
A-Teens-The_ABBA_Generation 16968 -5169
Avril_Lavigne-Let_Go 15360 -13854
Backstreet_Boys-Backstreet_Boys 16551 -12
Backstreet_Boys-Black_And_Blue 23348 -11448
Backstreet_Boys-Millennium 17101 -5585
BBMak-Into_Your_Head 17921 -36561
BBMak-Sooner_Or_Later 43914 -12
BBMak-Sooner_Or_Later_(Japan) 45078 -33264
BBMak-Sooner_Or_Later_(UK) 45250 -93604
Brie_Larson-Finally_Out_Of_PE 14163 -12266
Britney_Spears-Baby_One_More_Time 24254 -12
Cheyenne_Kimball-The_Day_Has_Come -12 -12
Christina_Aguilera-Christina_Aguilera 12724 -32087
Christina_Aguilera-What_A_Girl_Wants_(Single) 15301 -15511
Covent-Nexus_Polaris 17111 -7652
Dream_Theater-Metropolis_Pt_2_Scenes_From_A_Memory 24053 -1878
Dream-He_Loves_U_Not_(Single) 15445 -17251
Dream-It_Was_All_A_Dream 18256 -3148
Dream-This_Is_Me_(Remixes) 16825 -6995
Evanescence-Fallen 11468 -15763
Hilary_Duff-Santa_Claus_Lane 634 -12
Hoku-Hoku 15367 -4506
In_Flames-Come_Clarity 658 -12
JC_Chasez-Schizophrenic 15466 -3667
Jesse_McCartney-Beautiful_Soul -1160 -12
Jessica_Simpson-Sweet_Kisses 14755 -5378
Jump5-All_The_Time_In_The_World 636 -87648
Ks_Choice-The_Great_Subconscious_Club 19119 -5920
Lacuna_Coil-Comalies 45977 -118426
Lacuna_Coil-In_A_Reverie 45449 -120340
Lacuna_Coil-Unleashed_Memories 45502 -6635
LFO-Life_Is_Good 2 -12
Liberty_X-Thinking_It_Over 49261 -84313
Lindsay_Pagano-Love_And_Faith_And_Inspiration 15691 -6411
M2M-Shades_Of_Purple -12 -4804
Mandy_Moore-Candy_(Single) 17957 -3705
Mandy_Moore-Mandy_Moore 39136 -9195
Mandy_Moore-So_Real 722 -16303
McFly-Room_On_The_3rd_Floor -1160 -86372
McFly-Wonderland -12 -12
Mudvayne-The_End_Of_All_Things_To_Come 14537 -7110
No_Doubt-Tragic_Kingdom 14725 -3224
NSync-Home_For_Christmas 17234 -23933
NSync-No_Strings_Attached 7972 -4574
NSync-NSync 16831 -519
Opeth-Blackwater_Park 14799 -5383
O-Town-O2 698 -11294
Play-Dont_Stop_The_Music 15340 -5052
Play-Girls_Mind 16525 -13544
Play-Play 14018 -22647
Play-Play_Around_The_Christmas_Tree 636 -12
Play-Replay 37409 -44907
Play-Us_Against_The_World 16623 -16246
Sarah_McLachlan-Surfacing 8876 -2096
Stacie_Orrico-Genuine 15586 -3172
The_Gathering-Mandylion 46148 -7756
The_Kovenant-Animatronic 16903 -2445
Tool-Undertow -1157 -15455
VA-Kaerlekens_Spraak 24164 -29135
VA-Pixel_Perfect 670 -88212
VA-Radio_Disney_Holiday_Jams_2 15400 -3978
Winds-Reflections_Of_The_I -1160 -22
The numbers listed are offsets (with respect to the current EAC reference offset) needed to make the first track start on a non-zero sample, and to make the last track end on a non-zero sample, respectively. The start offsets can go no lower than -1160 for the start tracks, and no higher than +472 for the end tracks (these are the offsets of the drives I used to rip the start and end tracks, they can't overread). Most of the numbers aren't helpful because the beginning/end are padded with silence. There is only one number that sticks out to me which is -12 (3 CDs have that as their start offset, and 11 CDs as their end offset). There are no CDs with a -30 offset, so to me it seems pointless to change the reference offset when it's not going to bring any practical benefit.
It's nearly always possible to get all the audio samples extracted from a CD-DA, even without using offset correction/overreading, and if it isn't, then it's just a matter of loosing some samples of background noise and not any real music, unless the mastering engineer has f***** up the mastering process. Now getting real "bit-perfect" extractions i.e. not only getting the audio samples extracted, but also the precise number of null samples extracted from the beginning/end of the first/last track also, is just not possible(except for some lucky few, which actually matches the choosen offset we are using), no matter if using Andre's or Ipsedixit's reference offset, since the first/last sample of each CD-DA isn't located at the exact same place, and instead starts/ends at highly varying sample possitions...
QUOTE(Pio2001 @ Nov 23 2006, 06:39)
What does "bit perfect" mean to you ?
For me, bit-perfectness does not depends on offsets.
''Bit Perfect'' doesn't really mean anything to me, but I assume that most people who like to use that term intend it to mean a perfect 1:1 image. All I care about personally is accurate extraction of actual audio data. [edit] I mean actual music. I don't really care too much if silence is actually null samples or not. [/edit]
It seems that anyone who wants to change the current standard for offset correction does not understand the complete issue, or is jumping to a conclusion without sufficient proof that more accurate results can be obtained from a majority of CDs. Personally, I still wouldn't care. But at least there would then be a valid argument to be made.
[edit.2]
QUOTE(Martin H @ Nov 23 2006, 08:52)
[...] then it's just a matter of loosing some samples of background noise and not any real music, unless the mastering engineer has f***** up the mastering process. [...]
[/edit.2]
What part of this did you guys not read?
Moitah's numbers are irrelevant here. I looked over Pio's test earlier and can tell you that it has nothing to do with the method that IpseDixit used.
As for reproducing the greatest amount of samples on a copy while still maintaining the same track lengths, it is important to take into account not only a drive's ability to overread but also it's ability to overwrite. In the case of Plextors with a read sample offset correction of 30 and a write samples offset of -30, you will always get a more complete copy without using a read sample offset correction or a write samples offset than you will using the currently accepted ones when duplicating a disc where this would make a difference. This is and has always been true regardless of where the "absolute" postition of the audio is.
QUOTE(Pio2001 @ Nov 19 2006, 14:35)
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.
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.
Moitah's numbers are irrelevant here. I looked over Pio's test earlier and can tell you that it has nothing to do with the method that IpseDixit used.
As for reproducing the greatest amount of samples on a copy while still maintaining the same track lengths, it is important to take into account not only a drive's ability to overread but also it's ability to overwrite. In the case of Plextors with a read sample offset correction of 30 and a write samples offset of -30, you will always get a more complete copy without using a read sample offset correction or a write samples offset than you will using the currently accepted ones when duplicating a disc where this would make a difference. This is and has always been true regardless of where the "absolute" postition of the audio is.
I should have worded that last sentence differently. I don't doubt that his numbers are correct, rather that in practice it doesn't seem to matter.
QUOTE(Moitah @ Nov 23 2006, 08:19)
I don't doubt that his numbers are correct, rather that in practice it doesn't seem to matter.
I agree, and it's minutia if you ask me.My comment earlier about how spoon could reset the database was only an observation, BTW. I think I would actually prefer that AccurateRip remain the way it is. These issues regarding offsets and images can easily be managed by the user without the need for any changes to AccurateRip or its database.
...and FWIW I have a disc [The Rolling Stones - Aftermath (London 820 050-2)] that produces non-zero samples at least up to the 11760 sample limitation of EAC's GUI before the first track and produces non-zero samples after the last track at least up to 11759 samples (11760 gave me a missing samples error) using my PX-716. If anyone's interested, I can get more precise numbers by bypassing EAC's GUI as well as trying a different drive to check the lead-out to see if I can avoid the missing samples error.
Anyhow, I don't think I'll be able to make a "bit perfect" copy of this disc anytime soon.
Regarding the concept of skew, is it applicable to IpseDixit's test or is it only applicable to Pio's test?
QUOTE(kwanbis @ Nov 23 2006, 09:20)
I never understood this obsession with having a "bit perfect" audio CD copy.
Reference standards are useful. Without some sort of positional reference, AccurateRip wouldn't be possible, meaning it can be difficult to be sure a rip was correct (programmatically).
So far, no one I know of is arguing for a *real* bit-perfect copy of audio CDs, including bit-perfect copies of all the subcodes and error correcting code (some, but not all, of which will be automatically generated to similar values when writing a copy of the audio). Just all of the audio (excepting pre/post silence) and a standard to put the track/index marks in the same places across drives/rippers.
In rare cases, such as greynol's above, this may fail, but I think it handles 99.99% of CDs just fine.
QUOTE(greynol @ Nov 23 2006, 12:31)
Anyhow, I don't think I'll be able to make a "bit perfect" copy of this disc anytime soon.
...well, not with a single make/model of drive, at least.
-brendan
I am a bit confused and hope that you can help me out. During the past months, I realisd that it's really nonsense to care about 6 or 30 samples at the end of a CD (at least for me). Anyways, I would like to understand this debate:
1: Is the true offset correction for drives always 30 samples less than now? Does this mean that most Plextors have a 0 samples read offset and that LITE-ONs need a negative read offset correction (meaning that they have to overread from lead-in)?
2: You say that for some audio CDs, the offset is different because different write offsets were used. Isn't the read offset of a drive always constant? What does it have to do with the write offset of a CD? For me, an 1:1 copy of a CD should be 1:1; if a CD has 40 samples of silence because of a write offset, the copy should also have 40 samples of silence, even if the actual audio data does not begin at sample 1.
1: Is the true offset correction for drives always 30 samples less than now? Does this mean that most Plextors have a 0 samples read offset and that LITE-ONs need a negative read offset correction (meaning that they have to overread from lead-in)?
2: You say that for some audio CDs, the offset is different because different write offsets were used. Isn't the read offset of a drive always constant? What does it have to do with the write offset of a CD? For me, an 1:1 copy of a CD should be 1:1; if a CD has 40 samples of silence because of a write offset, the copy should also have 40 samples of silence, even if the actual audio data does not begin at sample 1.
QUOTE(Sebastian Mares @ Nov 23 2006, 14:40)
1: Is the true offset correction for drives always 30 samples less than now? Does this mean that most Plextors have a 0 samples read offset and that LITE-ONs need a negative read offset correction (meaning that they have to overread from lead-in)?
According to IpseDixit's industrial tests, yes. Whatever the previous offset was, subtract 30 to determine the new offset for your drive. So most LITE-ONs, that I believe were around +6, would now be -24.
QUOTE(Sebastian Mares @ Nov 23 2006, 14:40)
2: You say that for some audio CDs, the offset is different because different write offsets were used. Isn't the read offset of a drive always constant? What does it have to do with the write offset of a CD? For me, an 1:1 copy of a CD should be 1:1; if a CD has 40 samples of silence because of a write offset, the copy should also have 40 samples of silence, even if the actual audio data does not begin at sample 1.
Except in rare cases of extremely old (and bad) drives, the read offset of your drive will always be constant. The main problem is that where the audio begins on a CD varies from disc to disc, making true absolute 1:1 extraction a very difficult thing. The read offset is a method to allow your drive to produce results identical to other drives, not the disc itself. The offset proposed by IpseDixit just moves the offset to a position on the disc where audio would begin if the disc was manufactured with absolutely zero skew, which is a pretty rare occurance. The offset calculated by Andre was where he found the audio to begin on most the discs he owned, which were more than likely manufactured with deviation from zero skew, thus making his offset an admitted estimate.
In real world practice, no matter which offset you use, Andre's or IpseDixit's, you won't have a perfect 1:1 copy for every disc.
Ah, I see, so the problem is finding out how to detect read offset. So, are 0 samples write offset discs seldom?
QUOTE(Moitah @ Nov 23 2006, 14:44)
For what it's worth, I used a method similar to the one described on Pio2001's page. I did it on 74 CDs, the results are here:
(...)
There is only one number that sticks out to me which is -12
Using my three old reference CDs, I find +44. One of them was made by DADC around 1990, one other by Interpress around 1988. And the third by one of these two.
QUOTE(greynol @ Nov 23 2006, 17:31)
Regarding the concept of skew, is it applicable to IpseDixit's test or is it only applicable to Pio's test?
What do you mean ?
The "main to subchannel skew" was introduced by RichMan in the CDFreaks thread about absolute offsets, but he then said that it was like Nero's offset correction : it can only be adjusted by an integer number of sectors.
QUOTE(Sebastian Mares @ Nov 23 2006, 20:40)
1: Is the true offset correction for drives always 30 samples less than now?
Yes
QUOTE(Sebastian Mares @ Nov 23 2006, 20:40)
Does this mean that most Plextors have a 0 samples read offset
Yes, according to the real reference.
QUOTE(Sebastian Mares @ Nov 23 2006, 20:40)
2: You say that for some audio CDs, the offset is different because different write offsets were used. Isn't the read offset of a drive always constant? What does it have to do with the write offset of a CD? For me, an 1:1 copy of a CD should be 1:1; if a CD has 40 samples of silence because of a write offset, the copy should also have 40 samples of silence, even if the actual audio data does not begin at sample 1.
In order to get back exactly what was burned or pressed onto the CD, you must rip with exactly the same offset as the one that was used during the burning.
QUOTE(Pio2001 @ Nov 24 2006, 00:38)
In order to get back exactly what was burned or pressed onto the CD, you must rip with exactly the same offset as the one that was used during the burning.
Yes, if you want to get the exact data that was used during the burning process - but I want to get the exact data from the CD (like what a reader with a 0 samples read offset would get).
QUOTE(The Legioneer @ Nov 23 2006, 21:20)
The main problem is that where the audio begins on a CD varies from disc to disc, making true absolute 1:1 extraction a very difficult thing. The read offset is a method to allow your drive to produce results identical to other drives, not the disc itself. The offset proposed by IpseDixit just moves the offset to a position on the disc where audio would begin if the disc was manufactured with absolutely zero skew, which is a pretty rare occurance. The offset calculated by Andre was where he found the audio to begin on most the discs he owned, which were more than likely manufactured with deviation from zero skew, thus making his offset an admitted estimate.
In real world practice, no matter which offset you use, Andre's or IpseDixit's, you won't have a perfect 1:1 copy for every disc.
Exactly - Very well put
Cheers mate
QUOTE(Sebastian Mares @ Nov 24 2006, 07:10)
but I want to get the exact data from the CD (like what a reader with a 0 samples read offset would get).
Is the pregap data part of "the data from the CD" ?
Is the lead-out data part of "the data from the CD" ?
Is the lead-in data part of "the data from the CD" ?
Are hidden tracks before track one part of "the data from the CD" ?
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.
Then, without manually checking pregaps and lead-in/out areas (which would surely be a tortuous process), your best bet would be to apply a -30 samples correction - if I understand correctly.
I agree with whoever said that this provides an updated reference, rather than anything else. If all manufacturers created CDs with no skew or fancy bits in non-standard areas, we wouldn't need to worry! I personally don't think that there's any guaranteed way to get everything from a CD without greatly increasing your workload.
However, although I'm the type to say "30 samples doesn't matter!", I'll probably get paranoid and start re-ripping anyway.
I agree with whoever said that this provides an updated reference, rather than anything else. If all manufacturers created CDs with no skew or fancy bits in non-standard areas, we wouldn't need to worry! I personally don't think that there's any guaranteed way to get everything from a CD without greatly increasing your workload.
However, although I'm the type to say "30 samples doesn't matter!", I'll probably get paranoid and start re-ripping anyway.
Wondering about one thing... I remember burning a Nero CD/DVD Speed DAE test CD with my LG (that has 0 samples write offset) and tested my Plextor which was reported to have a read offset of 30 samples. How is this possible if the LG has 0 samples write offset? Does this mean that my LG now suddenly has a 30 samples write offset and that the Plextor has 0 samples read offset?
QUOTE(Sebastian Mares @ Nov 24 2006, 12:31)
Wondering about one thing... I remember burning a Nero CD/DVD Speed DAE test CD with my LG (that has 0 samples write offset) and tested my Plextor which was reported to have a read offset of 30 samples. How is this possible if the LG has 0 samples write offset? Does this mean that my LG now suddenly has a 30 samples write offset and that the Plextor has 0 samples read offset?
Yes. Because the write offsets were calculated based on the read offsets.
QUOTE(bhoar @ Nov 23 2006, 11:23)
QUOTE(greynol @ Nov 23 2006, 12:31)
Anyhow, I don't think I'll be able to make a "bit perfect" copy of this disc anytime soon.
...well, not with a single make/model of drive, at least.QUOTE(Sebastian Mares @ Nov 23 2006, 11:40)
2: You say that for some audio CDs, the offset is different because different write offsets were used. Isn't the read offset of a drive always constant? What does it have to do with the write offset of a CD? For me, an 1:1 copy of a CD should be 1:1; if a CD has 40 samples of silence because of a write offset, the copy should also have 40 samples of silence, even if the actual audio data does not begin at sample 1.
I'm not sure if you were addressing me, but I'll try to clarify what I wrote earlier. Drives using a negative write samples offset would require writing to what the drive believes to be the lead-out. This seems to be commonly accepted as impossible. It is certainly not possible with Plextor drives that have a write samples offset of -30 (per Andre's reference) using either EAC or Plextools.This means that when using the classic write samples offset of -30, the last 30 samples of any burn will always be null. Simply put, if the last 30 samples of the last track in the source file aren't null they will be lost. Let's say that this same disc also began with samples that aren't null and these samples continued into the lead-in. If you were to use the new offset, you would be able to get an additional 30 non-null samples which you can burn. IOW, shifting the correction by -30 samples will allow a Plextor drive like a PX-760A to reproduce 30 more samples because instead of zero-padding the beginning of the data and prematurely ending at the lead-out which it cannot write beyond, there will be no zero-padding and the end of the data will conincide with the beginning of the lead-out.
QUOTE(The Legioneer @ Nov 23 2006, 12:20)
The offset calculated by Andre was where he found the audio to begin on most the discs he owned, which were more than likely manufactured with deviation from zero skew, thus making his offset an admitted estimate.
I don't believe you can know what I have bolded with any certainty whatsoever. Where non-zero data begins isn't necessarily related to skew.Pio wrote this in CD-Freaks:
QUOTE
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.
Also, from reading the thread over at cdfreaks, it seems that the skew is in sectors, not samples.
QUOTE(Pio2001 @ Nov 23 2006, 15:38)
QUOTE(greynol @ Nov 23 2006, 17:31)
Regarding the concept of skew, is it applicable to IpseDixit's test or is it only applicable to Pio's test?
What do you mean ?
I hadn't read the cdfreaks article prior to asking the question. I was wondering if IspeDixit's determination of the read offset could be influenced by skew like the test that you, Andre and Moitah performed.
So Nero CD/DVD Speed also relies on EAC's calculation? 
QUOTE(Sebastian Mares @ Nov 24 2006, 14:26)
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.
The only way to determine write offset is to burn a disc, and read it back, comparing the offset with the original burned data. Since the asbolute offset is in question, you don't really know if the write/read offsets at 0/0 or -30/+30 (or -X/+X)
QUOTE(greynol @ Nov 24 2006, 20:25)
It is certainly not possible with Plextor drives that have a write samples offset of -30 (per Andre's reference) using either EAC or Plextools.
This means that when using the classic write samples offset of -30, the last 30 samples of any burn will always be null. Simply put, if the last 30 samples of the last track in the source file aren't null they will be lost. Let's say that this same disc also began with samples that aren't null and these samples continued into the lead-in. If you were to use the new offset, you would be able to get an additional 30 non-null samples which you can burn. IOW, shifting the correction by -30 samples will allow a Plextor drive like a PX-760A to reproduce 30 more samples because instead of zero-padding the beginning of the data and prematurely ending at the lead-out which it cannot write beyond, there will be no zero-padding and the end of the data will conincide with the beginning of the lead-out.
I know that when burning with a Plextor, I am going to lose 30 samples anyways. The scenario I am thinking of is that I have a drive with a 0 samples write offset (like the LG E10L as far as I know). My test with Nero CD/DVD Speed (burn test CD with LG unit, read with Plextor unit) showed that my PX-755A has a read offset of -30 samples (therefore it needs a read offset correction of +30 samples). If what was said previously regarding the correct read offsets being actually 30 samples off the current figures, this would mean that my Plextor has a 0 samples read offset, but that my LG has a 30 samples write offset.
QUOTE(Sebastian Mares @ Nov 24 2006, 12:20)
If what was said previously regarding the correct read offsets being actually 30 samples off the current figures, this would mean that my Plextor has a 0 samples read offset, but that my LG has a 30 samples write offset.
Exactly. Now, the question is, will you be able to burn the first 30 samples of a disc correctly using your LG if they are not null?A Plextor PX-760A configured with a write samples offset of 0 will be able to burn every sample without replacing non-null samples with null samples. In light of the new absolute read offset, these Plextor drives are already optimized and can be used with any burning program (besides PlexTools, lol) without first having to apply an offset since there is no need for calibration.
One more thing - do Plextors have a 0 samples read and write offset, or do they still have a -30 samples write offset?
QUOTE(Sebastian Mares @ Nov 24 2006, 13:42)
One more thing - do Plextors have a 0 samples read and write offset, or do they still have a -30 samples write offset?
As benski already stated, the write offset will change along with the read offset.The whole goal of offset correction (EDIT: from the copying perspective rather than from the rip comparison perspective) was to create a system by which audio data was shifted to produce a combined read and write offset of 0. If you shift the read offset in order to conform to a different standard, you much also shift the write offset.
The only point I'm trying to make is that the ability to create (or not create) sample perfect copies hasn't really changed.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.