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 (http://www.digital-inn.de/exact-audio-copy-english/28787-andre-wiethoff-who-feels-have-say-offsets.html)
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!
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.
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.
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
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.
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 (http://www.digital-inn.de/showthread.php?threadid=4193)
and :
http://perso.numericable.fr/laguill2/offset/offset.htm (http://perso.numericable.fr/laguill2/offset/offset.htm)
http://pageperso.aol.fr/Lyonpio2001/offset.htm (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 (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.
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
You have 8 million tracks submitted to the database, they are not going to go away.
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.
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 (http://perso.numericable.fr/~laguill2/offset/offset.htm) 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.
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.
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.
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.
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:
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
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...
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][...] 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. [...]
Yeah... If a 30 sample skew meant that I'd actually miss something important, then I'd want to shoot the mastering engineer, not Andre.
[/edit.2]
What part of this did you guys not read?
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.
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 over
write. 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.
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?
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.
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)?
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.
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?
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.
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 (http://club.cdfreaks.com/showthread.php?t=111913&page=2&pp=25) 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.
1: Is the true offset correction for drives always 30 samples less than now?
Yes
Does this mean that most Plextors have a 0 samples read offset
Yes, according to the real reference.
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.
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).
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
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.
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?
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.
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.
No, not with any combination of drives using any of the standard burning software. This is because there are over 20 frames audio data in the lead-in as well as in the lead-out.
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.
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:
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.
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?
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)
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.
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?
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.
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.
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.
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.
...Plextor would seem to have known about this for a while.
Did Ipsedixit by any means used Plextor (parts)
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 (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 (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 (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.
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?
is the data is still there?
no data will be lost between any of the tracks.
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?
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?
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.
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.
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.fulladsl.be/spb2267/offsets/offsets.htm)
http://users.pandora.be/satcp/eacoffsets00.htm#- (http://users.pandora.be/satcp/eacoffsets00.htm#-)
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.
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.
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?
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.
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?
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?
So out of principle, even if it's an offset of one sample, it's one sample too much.
Who's principle?
EDIT: Formatting
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.
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.
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.
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.
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.
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?
[...] I can just confirm that his method is right, while Andre Wiethoff's one was just an approximation.
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.
I never understood this obsession with having a "bit perfect" audio CD copy.
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 never understood this obsession with having a "bit perfect" audio CD copy.
Same here.
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?
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.
So, who is thinking of adopting this new reference?
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.
The ability to ABX a track that is offset by 30 samples can be easier than you think.
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.
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?
So why should I care about bit-perfect copies?
Some ppl are perfectionists and others aren't. that's it
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.
So, who is thinking of adopting this new reference?
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.
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.
No kidding! There's a big difference between saying I can easily ABX
a track and saying I can easily ABX
any track.
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.
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?
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.
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 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=46355&view=findpost&p=452891)
I still think it's important to check the files just in case it looks like there are missing samples.
Besides nonsilent samples at the beginning of track 1, which are so incredibly rare, what are you talking about?
Still, isn't having it bit perfect one of the main reasons for lossless?
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.
I've been an absolute perfectionist before, so why should I stop now when I can apparently make my rips more accurate?
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.
I didn't think you could mount the images because of the non-compliant cues
The "non-compliant" cue type is only for rips of separate tracks with gaps (if present) appended to previous tracks.
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?
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?
so I am now going to have to re-rip all my 135cd's!!??
so I am now going to have to re-rip all my 135cd's!!??
Yes, but you'll need to figure out if it's really 135cd's. It could be 105cd's...or...maybe 165cd's!
-brendan
I'm still a little undecided about the whole thing. I know that using either way i'll end up burning back the same data. I know from looking at the files that 30 samples is completely unimportant and there's a good chance that 100% of those samples will be null for every cd. Considering all the work people have put in to get Andre's offset right, it would be impossible to ask everyone to bump their data 30 samples. Still if I get anything out of this, I can at least fix people's offset who never used one to begin with. It's in this case that it might be important to check for missing samples, but after looking at the ridiculous amount of null samples in the hex editor, I might not even need to.
Anyway, I suppose we should all forget about this, cause there's too many people that never learned how to rip properly in the first place. That's a much bigger problem than what absolute position everyone's music should be at.
I admit I had the crazy urge to bump everything, but I guess I need to control myself. I think I have too much fun ripping and encoding sometimes.
Instead of decoding to RAW PCM samples and using a hex editor, then instead just decode to WAVs and then use a WAV editor like e.g. EACs own WAV editor or Audacity, to trim or padd the WAVs. Note that this is not to say that i would recommend that you do this, as i really wouldn't
Personally, then what i care about, is to get a secure extraction of all the audio samples of a CD-DA and that is nearly always possible, no matter if using read offset correction or not and the only audio samples we are inclined to miss, is some samples of background-noise on some old AAD discs.
Now I'm just getting increasingly confused!
Having started to re-rip with the new offset (I was going to, as I have reinstalled on that computer), my LTR-52327S is still giving Sync Errors (if not more than before) at the end of CDs, which doesn't make sense, since I have subtracted 30 samples from the drive's offset and, thus, it is actually reading earlier . . . surely?
I did previously get similar errors at the end of CDs, but assumed that they could be justified, as I was using the positive offset correction (+6). I actually assumed that I would begin to get errors at the beginning of CDs, since I was not aware that the drive could read into lead-ins, but I have not experienced such a thing yet.
In any case, I haven't seen or heard any errors in the files and, as everybody says, it's probably just silence anyway. Whether I should bother with this new offset or not is debatable . . . but still.
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.
That's right, but this offset is itself inaccurate, since factories can use the one they want.
IpseDixit does not rely on any factory offset. He looks at the raw digital data from the CD and builds up all the relationship between the time codes and the user data, until he finds, starting from the pits and lands themselves, the exact binary sample that is in relation with an exact time code.
I never understood this obsession with having a "bit perfect" audio CD copy.
Same here.
I don't even understand why people call them "bit-perfect", since factories not only use machines that are offsetted from this reference, which introduces a minor deviation (+/- several samples), but produce CDs greatly offsetted from each other, which introduces a bigger deviation (+/- several hundreds or thousands of samples).
So whatever offset we use, we obviously get offsetted copies, not bit-perfect ones.
So, who is thinking of adopting this new reference?
Not me. I consider AccurateRip checks much more important than using the same offset as several other people in the world, whose CDRs I'll never have to re-rip anyway.
Well, I like the idea of correcting my drive's offset to this "reference zero", but the fact that many manufacturers will be using skew makes the whole thing a bit futile anyway.
I never use AccurateRip, so is there any point in me using either of the offsets? Before this I just let EAC configure the standard +6 offset by itself; now I'm just incredibly confused! The fact that I still get the Sync Errors which I mentioned above at the end of many CDs doesn't help to alleviate the confusion!
The fact that I still get the Sync Errors which I mentioned above at the end of many CDs doesn't help ..
Did you disable the "Overread into Lead-in and Lead-out" parameter? If not, please do so.
Just a quick question:
If you use Andre's reference offset and you have samples that are not zero at the end, and then rerip that CD with the new offset, those 30 samples at the end will be lost (with 30 samples gained at the beginning). Thus, even if you use the new offset, perfect 1:1 copies won't be possible in all cases.
So is it possible to read out audio data from the leadin/out to a seperate file?
That way you could use any offset you like and not loose any audio data.
As a consequence you could even use Andre's reference for ripping and Accurate Rip, and then, with the leadin information, make your rip use the corrected offset without ripping twice.
f you use Andre's reference offset and you have samples that are not zero at the end, and then rerip that CD with the new offset, those 30 samples at the end will be lost (with 30 samples gained at the beginning). Thus, even if you use the new offset, perfect 1:1 copies won't be possible in all cases.
That is not true as the pressing factories all use varing offsets, so your 30 offset might gain more samples on some cds, on others it will loose some in relation to andres.
That is not true as the pressing factories all use varing offsets, so your 30 offset might gain more samples on some cds, on others it will loose some in relation to andres.
Yeah, that is what i meant. Sorry if i didn't make my point clear enough with the example i gave.
Nonetheless I'd be very curious how to extract
all audio data that is written on the CD independently of any offset.
One possible use:
- Rip CD only once
- Check result with Accurate Rip
- Save cue+image with the 'new' offset.
--> so you can use both AccurateRip and the corrected offset without the need to rip twice.
You will need a drive that is capable of overreading in both the lead in and lead out or two drives: one that can overread in the lead-in and one that can overread in the lead-out. Even still, you might not be able to get all the data that is there, as it is likely that your ripping program may still return an error.
So what would someone do with all this data which is probably going to be nothing but low-level noise, except when there was a serious mastering error?
After reading every thread I could find on this topic, I've concluded the following (please correct me where I am wrong -- I am new to this):
- IpseDixit has likely discovered where the "absolute zero" is on a theoretically perfect audio CD, and it's 30 samples (or 120 bytes or 5 frames) before where Andre thought it was.
- The AccurateRip database is based on Andre's offset values, so reading using the new offsets in EAC makes AccurateRip unusable.
- Spoon and Andre, for good reason, don't want to start over with AccurateRip.
- This really shouldn't matter to anyone, because a) CD's themselves are manufactured with varying start points anyway, even with the same title, b) standard audio CD players are nowhere near as precise as we're talking about, and c) we're talking about 680 freaking milliseconds
- There are always perfectionists and preservationists in the world, so many people are still upset about this.
DrazardX had the exact same idea I did. Couldn't the following work? (Forgive me if this is wrongheaded; I primarily live on a Mac and have not yet been able to try all this out on a PC.)
- Rip CD in EAC using the *new* corrected offsets to bin/cue
- Add 120 nulls to the end of the bin (I don't know enough about the bin format to know for sure if it is a linear dump of sectors; if not, then we could get the WAV instead as DrazardX did or perhaps tweak the cue sheet).
- Remove the first 120 bytes, and save them somewhere if by some chance they're not all null
- Virtually mount the modified image and let AccurateRip check it out
- If AccurateRip likes it, then put the 120 back on the beginning and remove the 120 from the end, and convert it to FLAC or AAC or whatever floats your boat.
It seems like this ought to allow the uberpurists to both rip with the "accurate" offsets and still check them with AccurateRip. As I said, I've been unable to try yet -- but would this work?
Ivan.
- There are always perfectionists and preservationists in the world, so many people are still upset about this.
I prefer the term obsessive compulsives.
This whole 30 sample thing is blown way outta proportion. It's interesting to learn about but to actually determine a ripping strategy based on it is beyond me.
I use the new offset. It's pretty convenient for me, since I have a Plextor and they're "set" to it by default!
Using either Andre's or IpseDixit's reference for offset correction will not make CD-DA rips any more exact. IpseDixit's result is based on one subchannel to mainchannel skew value, but CD manufacturers skew their discs highly varying(this has been said by a mastering engineer in the thread about this issue at cdfreaks). Also, Andre's reference is not the ultimate Zero starting point of CD-DA's eihter and he has just choosen the most frequently occuring one among his tested discs(6 identical matches among all his tested discs). Personally i don't see the point in using a reference other than Andre's, since this reference is the official one(and this is actually what offset correction is all about, i.e. to adjust ones drives after a common reference - and not to make perfect rips - since that is not possible when CD manufacturers skew/offset their discs highly varying) + used with AccurateRip.
IMHO, then "perfectionism" has nothing to do with what reference should be used, but instead just simply a bit of common sence
funniest thread ever imho.
- This really shouldn't matter to anyone, because a) CD's themselves are manufactured with varying start points anyway, even with the same title, b) standard audio CD players are nowhere near as precise as we're talking about, and c) we're talking about 680 freaking milliseconds
Milliseconds...or microseconds?
- There are always perfectionists and preservationists in the world, so many people are still upset about this.
Er...heh.
-brendan
Milliseconds...or microseconds?
Microseconds. Freaking microseconds.
CD manufacturers skew their discs highly varying(this has been said by a mastering engineer in the thread about this issue at cdfreaks).
For the record, I believe the mastering engineer said that the skew was specified in frames, not samples.
By frames I mean 588 samples; not whatever this 6-sample variety is that Ivan X is talking about.
I'm open to clarification if I'm not understanding this properly.
Some relevant quotes :
For what it's worth...
I am involved with the mastering process at huge CD/DVD factories all over the world. Our software allows the mastering engineer to set the skew (offset between main and subchannel) to whatever they like (including negative!). And, the Red Book does allow +/- 75 sectors.
Source : http://club.cdfreaks.com/showpost.php?p=81...mp;postcount=32 (http://club.cdfreaks.com/showpost.php?p=816969&postcount=32)
Disc factories make discs with different "offsets" all the time (for media it's called skew, subchannel to main channel skew). They sometimes put the 1st sample of a recording in a point slightly far (+- 75 sectors skew) from the exact start of the disc (00:00.00). Wouldn't be optimal to take a disc that has no sub to main skew ("zero offset") as reference (we would have to contact mastering engineer)?
Source : http://www.digital-inn.de/96934-post1.html (http://www.digital-inn.de/96934-post1.html)
IMHO, it dosen't make sence to use a Zero-skew mastered disc for the reference, but instead to rather use the most frequently occuring disc-offset instead, which is what Andre has done :
As different modells of common CD-R writer usually do not add the same offset on writing, it seems that also big CD manufactures also do not always press the same offset on their CDs. So I determined the most common offset of pressed CDs and integrated it into the offset detection routines.
Finally, a quote from Andre Wiethoff about what offset correction's usefullness is about :
'Sample Offset' is another new feature of EAC, it will help to always get the same WAVs compared to a different reader and to prevent generation losses.
Notice that he didn't mention "bit-perfect results"
We know accuraterip is not going to make any accomodations for the people who wants to use the new offset. The question is, are there any brave pioneering souls out there willing to start a new parallel database that would take submissions from people with the new offset?
We know accuraterip is not going to make any accomodations for the people who wants to use the new offset. The question is, are there any brave pioneering souls out there willing to start a new parallel database that would take submissions from people with the new offset?
I'd made a comment some months ago stating my opinion that this should be done, but having read the threads since then, it's pretty clear there's no need to do so. Here's my reasoning:
1. Most of the time, the 30 samples will be null. Not 99.9% of the time, but most of the time.
2. When they're not null, it's quite possible they'll be fade, and therefore low-level.
3. Even if it is audible content, it's so small, and already at the expected "event horizon" of the music/no-music universe, it would never be noticeable.
OTOH, what I'd really like spoon to do is to consider adding HTOA ("extended track 01 pre-gap"?) support to accuraterip. His current plan of making an image by gluing together each of the track+gap rips, audio already covered by accuraterip, leaves me somewhat worried that he'll not do it, as the HTOA audio is outside of that currently covered zone.
-brendan
The trouble with HTOA is no standard way of reading the start of the hidden track, different drives, different software.
The trouble with HTOA is no standard way of reading the start of the hidden track, different drives, different software.
Some drives give errors when attempting to read audio from HTOA.
Some drives give null samples when attempting to read audio from HTOA.
Some drives give the correct audio samples when attempting to read audio from HTOA.
So, it works on some drives. That's really all that matters to me. A list of drives that supports the feature already exists, as I'm sure you know.
This is a similar situation to other features such as "accurate stream" and "c2 pointers being reliable". These also vary from drive to drive.
And two other data points, if you're not already annoyed...
EAC can detect and rip the audio on compatible drives. And Riptastic! detects and rips the audio on compatible drives...as Track 00.
-brendan