greynol

The way this is written it is not correct. Previous rips using the original correction had 30 samples that were lost from the beginning. Rips using the new offset lose 30 samples from the end compared to those using the old offset. The 30 samples at the beginning were actually gained.

To be honest, I fail to see the significance in all of this if you are not talking about burning the data back to CD. This whole discussion is about a delay of a mere 680 millionths of a second.

In the case of burning the data back to CD-R, so long as the combined offset is zero, the location of the data will remain the same. Copying discs with the 30/30 Plextors with the new offset numbers (0/0) will allow you to duplicate more data than using the previous offsets because these drives cannot write to the lead-out (barring the annoying way in which PlexTools handled this issue by appending an extra frame of silence to the end). Regardless of the revelation, this has always been the case.

Regarding the reply from Plextor, I don't believe it is a confirmation that the absolute offset is 120 bytes more than what is reported by PlexTools.

calestyo

Plextor-Europe tells me this:

Aquarium

Here is a link to the discussion at cdfreaks where they discuss the technical issues involved and more info is given on how the new offset was determined.http://club.cdfreaks.com/showthread.php?t=111913 Go to page 3 most importantly.

TheLegioneer

Nothing against the Plextor tech support folks, but personally I would tend err on the side of caution when trusting this info, as Andre has said:

So the PlexTools offset integration was based on the research of Andre on EAC and not independently verifed to the best of my knowledge.

Ivan X

Hello,

I have a suggestion regarding using the existing AccurateRip database with the newly discovered "corrected" offsets.

I'm a complete newbie to EAC, this forum, and the whole topic, but I decided I wanted to archive my CD collection so I have been doing a lot of reading about EAC, AccurateRip, dBpowerAMP, the forthcoming PerfectRip, etc. Fortunately, I'm technically inclined, so I've been able to follow most of it.

I'd like if you could please tell me where I am misunderstanding things here -- also, bear in mind that I haven't actually used any of this software yet, only read about it. (That's because I'm primarily a Mac guy, and my PC is at work.)

As I understand it, it has been determined (or at least well-theorized) that EAC's drive offset ratings are off by 30 samples (or 120 bytes, or 5 frames); that is, they indicate the absolute start of the audio to be 30 samples later than it actually is. Of course, this should make just about no difference to anyone except crazy purists such as myself, who can go ahead and add 30 samples from EAC's suggested read offset correction settings.

However, changing the EAC offsets makes AccurateRip not usable, because as the AccurateRip database of track extraction checksums is based on rips using the EAC offsets; that is, the checksum is based on tracks that are missing 30 samples at the beginning and contain 30 samples past the end of the track. Thus Andre has pointed out that it is too late to really start over with a new database, as it is that body of checksums which makes AccurateRip useful.

My thought: would it be possible to add the an option to EAC and/or
AccurateRip to actually create checksums based on the original EAC offsets, but then save to disk according to the "corrected" offsets? Then, the AccurateRip database could be used for confidence, but the user ends up with, well, an exact audio copy. And then, perhaps, a new checksum could be created from that and stored in a new field in the database, allowing AccurateRip to begin building a database of new checksums which already have a extremely high degree of confidence, because they've already been verified against the original offset checksums.

To spell this out a little more clearly:
- EAC adds two options: "correct 30-sample start offsets" and "use corrected offsets with AccurateRip" (or something like that)
- If set, then EAC will peform the rip based on the corrected offsets, plus read 30 more samples past the end (the lead-out?)
- AccurateRip calculates the checksum starting 30 samples in and adding 30 bytes past the end of each track
- AccurateRip reports the confidence level and submits to the database as usual
- optional: If there's confidence, then AccurateRip calculates a new checksum based on the corrected offsets, and submits that to a new field in the database; once this gets built up, AccurateRip can simply use it rather than checking the old one against the original EAC offsets.

If that all seems too unlikely, would it be possible to take a EAC bin/cue rip with the corrected offsets, and either a) rewrite the cue sheet so all the track positions are indiciated as five frames later, or b) remove the first 120 bytes from the bin, and append 120 nulls at the end, and then mount the image and run it though AccurateRip?

Thanks for your patience and help with this, and particular to Andre and Spoon and Carlos and Sidney and everyone else who's put so much time into figuring this all out and creating these great tools.

Ivan.

hlloyge

I don't know about you, folks, but my CDs sound exactly the same, songs start where they should whether I use offset correction or not. I agree that there are some anal folk that want maximum precision with ripping and who think that is important, but to me it's most important that I have quality error correction. And after all, as someone stated (can't remember was it here or on cdfreaks), it's the measurement of only that one CD encoder. What about the others, hm?

Mike_A

As far as I'm concerned, there is not enough evidence to support the adoption of the new offset. Ipsedixit has not provided any technical evidence to support his claim. Furthermore, it is unclear whether the 30 sample correction would apply to all drives, or only certain Plextor models.

Aquarium

Here is a link to a long technical discussion about the offsets.http://club.cdfreaks.com/showthread.php?t=111913 on page 3 Isedixit gives his evidence.

hlloyge

No, he only tells us a story. It's hardly an evidence.

ianwatt

To me, after reading all of this, it seems quite obvious that no one well-defined standard for offsets exists. Any given commercial cd may or may not have been pressed using the "true" offset that Ipsedixit has established.

In fact, that "true" offset is just the standard defined by whatever software and hardware used to generate his results; but obviously that standard isn't used by all producers of all CDs, so it's not much of a standard. From my perspective, the standard that Andre has defined is *more* useful than Ipsedixit's, because it is based on empirical evidence regarding what offsets most actual CDs use, rather than the arbitrary offset used by one set of tools.

Obviously, Andre's measurements could have been skewed by sample error, but in that case, is there any evidence that Ipsedixit's is less skewed? He just used one sample! Granted it came from what he calls (on the other forum) "THE optical disc encoder company," but what does that mean? They have a monopoly? Nobody else produces audio CD equipment? If the offset is going to be arbitrary, it should be arbitrary in a useful way; and from what I can see, Ipsedixet's isn't.

-i

FredTr

to sum it up for a user point of view:

- is this problem also exists with dBPowerAmp??

- is it a problem happening only with plextor drives or any drive??

- if the offset correction was not detected by EAC but given by AccurateRip, is it ok or we have the same problem??

- if i understand, 30 frames is equal to 1/10 000 second??

- is it something that could be fixed on EAC in a future version??

- if I put an offset of +0, there is no loss of frame, but I cannot use AccurateRip??


Right???

Thanks

greynol

1. Calling this a problem is an exaggeration.
2. We're talking about a shift in the reference so it would have to be addressed with every drive.
3. AccurateRip uses the same reference as EAC.
4. The supposed "true" reference differs from the one used by EAC and AccurateRip by 30 samples, not 30 frames. 30 samples is approx. 680 millionths of a second. One frame is 588 samples.
5. EAC could be changed though personally I don't feel that it should.
6. It really makes no sense to talk about data that is lost, but yes, you cannot use AccurateRip with this new offset.

Andre Wiethoff

1. Yes, dBpoweramp just use exactly the same offset as EAC (as this is what accuraterip works with)
4. 30 samples are not 680 millionths of a second... there are usually 44100 samples per second, so this will be a 1470 part pf a second (I know, that previous answer was sarcastic )
5. EAC will not change...

cu, Andre

greynol

30 samples are 30 samples. The duration of 30 samples (assuming 44,100 samples per second) is 680 microseconds or 680 millionths of a second.

Andre Wiethoff

Ah, yes, of course you are right... I muddled up with milli and micro
Anyway, it is now 4 oclock in the morning - things happen...

cu, Andre