The EAC/AR method for calculating drive offset is apparently prone to error. If you're using a Plextor drive, please check the manufacturer-reported offset by downloading PlexTools here (any version):

http://www.plextools.com/download/download.asp

Plextor's instructions for determining the offset are:

"Use the PlexTools Professional or PlexTools applications. Select "Drive Information" from the test menu and the "General" tab. The offsets are listed in the lower right corner of the tabbed page."

http://www.plextor.com/english/support/faqs/G00049.htm

What is your drive model and PlexTools offset? Does it match the AR offset reported here:

http://www.accuraterip.com/driveoffsets.htm

Do you have any evidence of EAC detecting or reporting the wrong offset for any plextor drive? I've owned a number of them and never had it be wrong. Also if I recall, plextools lists it's offset in samples or something, which would make the number different than EAC. When you convert the plextools number it would match the listing in accuraterip. Could be wrong, but I don't think so.

Assuming that you are correct and AR/EAC uses a different offset than the Plextor corporation, what would be the point of using Plextor's offsets if they aren't compatible with the AR database?

This whole topic has been covered in length some years ago, when it was first pointed out that the offset reported by EAC was based on an erroneous method. (at digitalinn, if i'm not mistaken) But seriously, it's all hot air. Who cares if you are 30 samples off the right offset, if

a) the AR database is built on that for pretty much one gazillion drives, users and submissions

b) these 30 samples don't matter to anyone that's seriously considering what it actually means to be off by such an extremely low number

Get real.

As for compatibility with the AR database, I'm not sure it's necessary. If you're using a secure ripper with the correct offset, the appropriate overreading ability, and audio caching disabled as necessary, the rip will be perfect every time. The fact that different pressings of the same release frequently won't validate with each other makes the AR system more troublesome, as does the fact that since the AR offsets are incorrect, validating with the AR database is actually confirmation that you are missing some audio data!

As for whether or not that extra audio data matters, I'm hoping there will eventually exist a method for identifying accurate FLAC rips, and an offset mistake would make that impossible. Every FLAC file actually contains a checksum which could be used to make this identification really easy.

And you're saying this because you ripped a ton of CDs? I thought you were just starting out with gibbyrip or something similar for your linux!? You can easily have a secure rip be faulty if your reader repeatedly makes the same mistake, giving you a perfect test&copy result but not an accurate rip.



The problem with different pressings is well known to 'spoon', and he repeatedly explained (understandably) that this was impossible to be anticipated. Still yet, he announced a new version that will have a 'rolling' CRC check, and which should help greatly reduce the number of inaccurate-due-to-different-pressing rips.

And I am not sure you have audio data in your 30 samples.... .



Like I said in the other thread you started: you should just get yourself a couple of drives and keep your own database. I doubt the offsets will be changed from either DBpoweramp's or EAC's side. Understandably so.

Can anyone confirm this? Non-caching drives easily make the exact same mistake during multiple passes, resulting in identical checksums?

The above is not true.

"The second kind of error is random noise, caused by a damaged disc,
failing drive laser etc. There errors are manifested as random changes
in the data read, and will not be consistent across multiple reads
(ignoring any caching performed by the drive). Because these errors are
random and infrequent, if two independent reads of a disc give the same
data (or almost equivalently, the same checksum), then it is
overwhelmingly likely that both reads of the disc read the correct
data."

http://www.nabble.com/Re%3A-Verify-data-in...76684s2885.html

This mean AR is not necessary, as I said before.

I agree with you completely, flacflac. My question was rhetorical. I see no point in figuring out the 'real' offset, when the single best reason for using offset correction is to compare your rip with the AR database. I.e. I'll stick with the AR/EAC offsets.

Keeping it real.

There's not much point in this. Changing the offset by 30 samples will not improve your ability to get correct rips.

Suggested reading: http://www.hydrogenaudio.org/forums/index....showtopic=50301

Deep_Elem,



I still don't see what the point of verifying with AR is. Quoting myself:



verbajim,



It's the only way to get correct rips if by correct you mean correct.

And if you read the posts at digitalinn you will find that PlexTools uses the same offsets as EAC because PlexTools implemented the feature specifically for use with EAC. So the OP is wrong on that count.

ggking, this is getting ridiculous. I would much rather have my rip confirmed as accurate by the AR database than care about whether it is skewed by 30 samples of silence.

Do some more reading. You can't hear a 30 sample skew, and CD players don't correct for offsets anyway. You are producing a tempest in a tea pot.

the reason for the eac/dbpa offset (whether it is 'correct' or not) is so that rips from different players/people can be compared.

That is ALL that accurate rip is, a database of checksums that can be compared on a discid basis.

If 3 or 30 people all have the same checksum(s) for the same discid, it simply telling you that everyone got the same extraction. (based on a shared offset standard)

Where is Greynol when you need him

ggking7, it is almost as though you are setting out to 'dis' accuraterip, no facts are presented, some random links to other quotes are all that is needed. When you make statements like "This mean AR is not necessary, as I said before", does it matter? not for you personally, if that is what you want to believe that is fine by me, do not use it, but if you are spreading miss-information, which others might take as a truth, it needs correcting (squashing).

All I can offer in defense is solid facts, from people who have been secure ripping for many years (Andre of EAC has what a decade?), so lets take each one of the statements you have made:



Out of 50,000 people who have calculated offsets through AccurateRip I have only noticed 2 which calculated the wrong offset, this is possible on drives with a low user submission rate and only if 3CDs from a box set are used to calculate the offset which happens to be a different pressing. It is possible to get it wrong, but hardly prone to error as you say, I would take a 2 in 50,000 odds any day of the week (those 2 did not follow the offset finding instructions presented when the offer to find the offset, I verified their offset submissions and a 3 disc box set was used). If you have a popular drive (any Plextor), AccurateRip will not configure to an offset which disagrees to the submitted value.



Please do some research under the phrase 'consistent error', they do happen and are more common than most people believe, because before AccurateRip these were missed by people. The idea that a re-read of a scratch will return random results is not from an understanding of how CD drives work (with various error recovery layers and possible interpolation) there is a good chance that an error will return the same each rip.

About offsets again, even Plextools uses the same offset standard as EAC. The offsets are not right or wrong, it is like saying that Degrees C is wrong and has errors where Fahrenheit is right, they are just measuring the same thing with different offsets.

Some would even see your posts as trolling. The lack of experience of secure ripping is shown through not knowing about consistent errors.

Oh to answer your first question:

"Use the PlexTools Professional or PlexTools applications. Select "Drive Information" from the test menu and the "General" tab. The offsets are listed in the lower right corner of the tabbed page."
"What is your drive model and PlexTools offset? Does it match the AR offset reported here:"

Yes they match 100% PlextTools offsets are well known and verified in the 1000's

This is false.

Drive specific issues (firmware bugs, build quality, bad design, hours in use, etc.), disc surface quality, and secure-ripping strategy all can cause you to get incorrect data read repeatedly with non-caching drives, which means that traditional "secure" rippers can be fooled. Hence, one reason for AccurateRip.



It does not make it more troublesome, just makes it more likely you will get less matches for your less-common pressing.

Offset of 30 from the "natural" offset isn't an issue (as I posted elsewhere).

IIRC, assuming you rip the entire CD, the only missing audio data is likely to be at the end of the last track (if all gaps were appended and your drive has a positive offset) and that missing data is likely to be silence.

-brendan

This is all worrisome and would justify AR. Can anyone cite a reference for any this?

I'd like to state again that the point of including the extra 30 samples is not to hear the extra split second of silence, but to create a technically correct FLAC file. Such a FLAC file would contain a checksum that would match the checksum of every other FLAC file ripped from the same pressing of the same release, as long as each of those FLAC files were ripped with the correct offset. I understand that the offset need not be correct to be useful as a point of reference, but the functionality I'm describing does not currently exist, and if it does ever exist, I'll bet it would be based on the correct offset as opposed to the EAC/AR offset. This functionality is actually being discussed on the Musicbrainz list.

Hehe, yeah, I meant to quote Mr King there, sorry 'bout that.




Nuff said.

No offense, but it would seem that you have a great deal to learn about this subject still. Much of what you have written is incorrect and has been addressed many times on this forum and elsewhere. That you are asking for references suggests that you haven't been very successful in your research.

As for checking your rips against different pressings, maybe you should have a look at this thread...
http://www.hydrogenaudio.org/forums/index....showtopic=63132
...or wait until AR2 is finished.

The fact that different pressings DO exist and often differ by only an offset which is often orders of magnitude larger than 30 samples should tell you that the idea of a perfectly offset flac file is nothing more than misplaced anal retention. I would submit that offsets are important when it comes to burning duplicates, in which case it is having a net offset of zero that is important. Unless there is data lost due to a lack of overreading and/or overwriting, the reference is not important. If data is in fact lost, take a step back and think what it is that you're losing. Is it audio or just low-level noise?

In the case of Plextor drives with a read offset correction of 30 samples (or 120 bytes which is the same damn thing ) and a write offset -30 samples, you will not be able to faithfully copy the final 30 samples overread from the lead out if they are non-silent because the drive is not able to overwrite. OTOH, you might be skipping over non-silent samples at the beginning of the disc which CAN be burned. I'm presenting this only as something to think about, not something to stress over.

I have a Rolling Stones disc that has non-silent samples prior to the beginning of the 00 index before the first track as well as in the lead-out. IIRC, these samples go at least a full second in either direction. How would you go about getting a perfect rip of this disc? How about a perfect burn? It would seem impossible, no? Again, just something to think about.

greynol, thank you for taking the time to write.

It seems like a lot of people in this thread have had this argument over and over in the past and are just regurgitating what they've said before, even if it doesn't address the argument I'm making. I'll quote myself from a couple posts back:

You keep talking about FLAC files, why? It is certainly one of the best lossless formats, but I am sure there are Wavpack or Ape or Tak users on this forum that would disagree... .



I don't see how this is revolutionarily different from what is happening right now? (comparing checksums of ripped audio data BEFORE having it encoded into FLAC or whatever format you may want)



And that is because...? I just don't get your point, sorry.

Have you used Musicbrainz? Check out musicbrainz.org if not. Think it over in that context.

Sorry, but if you cannot explain yourself here I don't see what the point is in opening a thread.

OK: automatic file identification and verification of perfect data.

It already exists, it's called AccurateRip. Please stop this nonsense.

Can't see the worth of having automatic file identification and data verification in Musicbrainz huh?

Thinking about it...

...the one question I come up with is this: is it the case that this disc fully complies to the redbook standard?

(the answer very well could be yes...but just something to think about... )

I take it that most audio CD players would skip the first second or so of audio on this disc, which just seems to me to indicate that the person who did the cd mastering (glass mastering?) did a poor job.

-brendan

Wouldn't it be wiser to attempt to partner with AccurateRip and simply reuse the massive amount of submissions in it's database to verify a proper extraction? I guess competition is usually good when you have two competing services, but I think in this case AccurateRip is already doing what they want. Why reinvent the wheel?

I agree with you Zoom. There's a discussion on that here:

http://www.nabble.com/Verify-data-integrit...72778s2885.html