More about offsets?

[tgc225]

From what I understand, the absolute most accurate way to rip a CD is with sample offset correction, because if offsets are used, two people can rip the same CD on different drives and get exactly matching file.

Anyway, so how about requiring people to write whether they used offset correct or not when ripping the disc? This should be simple, because all people have to do is write "no offsets corrected" or "offsets corrected" and that will be it. Lots of people just write "EAC (Secure)", but this terminology is unlcear when it comes to whether offsets were used or not.

Also, maybe there could be a little guide on this website (or some links pointing to other guides) that explain and encourage the use of offsets when ripping? This website, for example, has a database for offsets for many drives, so that will eliminate the need to burn sample discs to figure out what your drive offset is:

http://accuraterip.com/driveoffsets.htm

[Five]

This is a good point... I've got the link in my signature to the coaster factory which describes all of this in great detail including why it's important and how to configure EAC properly.

It would be great if ppl posted whether their offsets are corrected, but first priority even before that would be to get ppl to generate an EAC .log and include it with the show. From this log it can be seen whether the offsets have been corrected and other critical data can be reviewed such as track quality. It's great if a CD/CDR is ripped with EAC with the offsets corrected but if the track quality is 67.00% on several tracks then the .log file is the thing that matters much more. Two silvers from the same pressing run can be extracted on two computers with offsets corrected and come up with the same .st5 / .ffp checksum values, but only if the quality is 100.00% (or perhaps very very close) on all tracks.

[tgc225]

Ah, thanks about mentioning that EAC logs had the offsets, I didn't know that.

Anyway, I checked all of my old bootlegs, and I've found a lot of variation. Some had '0' as the offset value, while many others had incorrect values (I found the name of the drive in the log file, and then checked the AccurateRip database for that drive, and many boots had an offset value that didn't agree with the value in the database. For many of these drives, the AccurateRip database had many submitters confirm the correct value, so the person who ripped the disc must have had it wrong). Maybe EAC tries to guess a value in some cases? Also, there were a number of boots whose value did match the AccurateRip database, I guess those are the most accurate. Also, a number had "Overread into Lead-In and Lead-Out : Yes", while most had "No". What's the difference between that?

Anyway, I think maybe that AccurateRip database link should possibly be stickied somewhere or linked in the FAQ. I think some newbies are reluctant to start off with EAC because of the need to configure it, and the offset part was a little lengthy and confusing. With the AccurateRip database, it's as simple as copying and pasting the number and that's it, so maybe more people will take advantage of that feature.

And maybe we could get some of the more advanced users contribute to the database to save time for newbies :D

[Five]

99% of the time, if 0 is the offset value, EAC wasn't set that way. I saw one guy posting that his drive truely has an offset of zero samples, but that's a pretty damn rare case.

For my drive that I could find listed the numbers were accurate compared to what I got by doing all the coaster factory stuff. I used a cd from their list (Zeppelin's BBC Sessions) and ran it several times on both cds to test it. Came up with +98. Some of my earlier seeds you can see in my .log files that my offset was not adjusted (i.e. 0), but you can also see that the extraction quality is 100.00%. Somebody really tedious could look up my drive and shift everything over by exactly 98 samples then the files would theoretically be exactly the same as an offset-adjusted rip. When I've got some time on my hands I'll play around with this. Knowing that the files are otherwise identical by checking extraction quality in the .log this is a nice detail to watch but not exactly the end of the world (don't quote me on that!).

I believe the coaster factory is linked by RainDawg all over the FAQ, check it out.

Also, a number had "Overread into Lead-In and Lead-Out : Yes", while most had "No". What's the difference between that?
I'll have to look that up... does anybody know this offhand?

Anyway, I think maybe that AccurateRip database link should possibly be stickied somewhere or linked in the FAQ. I think some newbies are reluctant to start off with EAC because of the need to configure it, and the offset part was a little lengthy and confusing. With the AccurateRip database, it's as simple as copying and pasting the number and that's it, so maybe more people will take advantage of that feature.
I would rather if ppl took the time to actually test the real offset values for their specific drives. There is possibility for variation even with the same model drive so the only truely accurate way to configure EAC is to do those tedious tests. Even then, some drives will have different offsets at different times of the day! In this case, an average has to be taken by the user and manually entered. Thankfully, this is a rare occurance. If ppl are lazy and just punching in a number it's implied by the .log that they have actually tested their drive several times to arrive at that number. If that's not the case I would rather just see a zero. I'm not sure if everybody would agree with me on this.

Then there are some cases where the coaster factory says your configuration necessitates using the undesirable comined read/write offset which means true exact audio copies would only be possible on the computer the cd was ripped on. So at this point we are demanding EAC and strongly (and I mean strongly!) recommending you visit the coaster factory and take a couple hours to set your offsets properly, which is not possible for 100% of the drives out there. Still, ripping with EAC is always better because of the error reports and strong probability that you can get your offsets perfect if you just take the time to do the tests.

If advanced users want to write tutorials they will be welcomed with open arms! There's not enough hours in a day to write all of the guides we want for the site, so if anybody so inclined is reading this, go for it! Unless the technobabble mods (and technobabble postwhores) find misinformation we will use it.

[tgc225]

Alright, thanks for all the info :)

Anyway, I think the AccurateRip database might be pretty accurate. It says that "A small number of drives have [Purged] as the offset, these drives were found not to have a constant drive offset (perhaps different manufacturing batches, or firmwares), as such they have been removed from AccurateRip's drive database".

I'm not sure exactly how the database works yet, but I believe when you rip one of the key discs they have in the disc database, and your files exactly match someone elses rip, you get added to the offset database. Since drives with different offsets are purged, the drives that do have many submitters with the same offset is probably very accurate at that point.

Anyway, there's so much of this technical stuff with CDs :D Good thing a straight file format was used with DVDs :lol

[Five]

nothing is perfect, is it?

I just saw another thread up in technobabble saying that trading audio is more secure than trading DVDs at this point!

It sounds like the AccurateRip database is pretty good... makes me wonder where some of those ppl are getting their offset values you read in the .log files. :confused:

[Five]

come to think of it, I'm gonna move this to technobabble where we might get more responses. I can always move it back later if you want.

[irishcrazy2005]

It's great if a CD/CDR is ripped with EAC with the offsets corrected but if the track quality is 67.00% on several tracks then the .log file is the thing that matters much more. Two silvers from the same pressing run can be extracted on two computers with offsets corrected and come up with the same .st5 / .ffp checksum values, but only if the quality is 100.00% (or perhaps very very close) on all tracks.

I could be wrong here, but from I understand the track quality percentage is not actually a measure of the accurateness (I have no idea if that is actually a word or not, but I'm going with it) of the extracted track. I believe that it is actually a representation of the physical quality of that track on the disc (it is a measure of how many rereads EAC must do to get an exact copy). As long as there are no errors reported on the track, it is an exact copy of the track. I forget where I read this, but it was either at the Coaster Factory or at the EAC forums. This explains why you can rip a brand new CD that you just took out of the wrapper and note get 100% on all tracks.

-Phil

[Five]

I've never read that... I've had discs where I had to rip several times and switch from secure to paranoid mode to get 100.00% quality. This would imply to me that the track quality is the quality of the rip since I was using the same cd. I've also read other ppl saying that they had to rip several times to get 100.00%...

[irishcrazy2005]

I've never read that... I've had discs where I had to rip several times and switch from secure to paranoid mode to get 100.00% quality. This would imply to me that the track quality is the quality of the rip since I was using the same cd. I've also read other ppl saying that they had to rip several times to get 100.00%...


Right, what I am saying is that you don't need it to say 100% to be a completely accurate rip. As long as each track says "Copy OK" and the bottom says "No errors occured," then the disc was copied exactly. I am going to dig through and try to find where I read this now.

-Phil

Edit: Okay, here it is. It's from The Coaster Factory:

While Peak level tells nothing about the quality of extraction, Track quality does. A Track quality of 100% obviously means that the track was extracted 100% correct. But here's where some people make mistakes; sometimes EAC rereads certain audio sectors multiple times to get accurate extraction results. For every reread EAC does, the Track quality decreases, but this does not mean that the extraction is less accurate. It is possible to have a bit-by-bit perfect copy of a track, while Track quality is lower than 100%. As long as Exact Audio Copy does not report any errors in the Status and Error Messages log, the extracted files are bit-by-bit perfect copies of the original. Track quality should be interpreted as the physical quality of the CD and not of the extracted data. A CD with some scratches or dirty fingers on will certainly cause rereads in EAC and thus a Track quality lower than 100%, but still the extracted tracks may be perfect. Thus if the log says Copy OK for a track that means it's extracted perfect - no matter of the Track quality. So, I hope that made things more clear as many people are confused by the Track quality.

Here is the exact link if you wish to read more http://users.pandora.be/satcp/eac07.htm#-

[tgc225]

I think this is the relevant section:

http://users.pandora.be/satcp/eac07.htm

While Peak level tells nothing about the quality of extraction, Track quality does. A Track quality of 100% obviously means that the track was extracted 100% correct. But here's where some people make mistakes; sometimes EAC rereads certain audio sectors multiple times to get accurate extraction results. For every reread EAC does, the Track quality decreases, but this does not mean that the extraction is less accurate. It is possible to have a bit-by-bit perfect copy of a track, while Track quality is lower than 100%. As long as Exact Audio Copy does not report any errors in the Status and Error Messages log, the extracted files are bit-by-bit perfect copies of the original. Track quality should be interpreted as the physical quality of the CD and not of the extracted data. A CD with some scratches or dirty fingers on will certainly cause rereads in EAC and thus a Track quality lower than 100%, but still the extracted tracks may be perfect. Thus if the log says Copy OK for a track that means it's extracted perfect - no matter of the Track quality. So, I hope that made things more clear as many people are confused by the Track quality.

[irishcrazy2005]

Ah, I beat you to it by just a few seconds!!!

-Phil

[Five]

ahh, I see!

you learn something every day.

so there's only extraction errors when it says something like "suspicious position at..." or if it doesn't say "copy ok". but when you use burst mode, it says "copy ok" too :confused: does that mean that burst mode is also 100% accurate?

[tgc225]

Now that's a good question. Unfortunatly, it looks like The Coaster Factory doesn't go into describing burst mode at all, only reccomending that secure mode is used (which is what many other websites do). Maybe there's a comparison out there ripping a poor quality disc in both mods and seeing if the files are the same for either mode, but I haven't found such a site yet.

Anyway, back to offsets and track quality, that note seems to suggest that as long as offsets are configured correctly, and there are no errors during the extraction process, theoretically everything should match up. In any case, I don't think it would hurt to add the AccurateRip DB link to #6 of the Audio BitTorrent Seeding Policy, along with the "offsets" thing in the #8 lineage section (since many people do it already), though that's completely up the moderators whether that info is helpful or not.

[Five]

that sounds like a great idea to me, I'll pass it along.

[irishcrazy2005]

ahh, I see!

you learn something every day.

so there's only extraction errors when it says something like "suspicious position at..." or if it doesn't say "copy ok". but when you use burst mode, it says "copy ok" too :confused: does that mean that burst mode is also 100% accurate?

So finally all those days I spent hanging around the EAC forums are paying off! Yes, you are correct that there is only an extraction error if it says "suspicious position..." or some other error message.

Here is the thing about Burst Mode: there is no error detection at all. It simply reads through the track as fast as it can and write the data to the file. This is why the track quality is always 100%, because the program never re-reads a sector, and thus according to the quote above, the track quality will be reported at 100%. It will not report any error messages unless ther is a serious problem and it can't read the disc at all. This is why we like secure mode :D .

-Phil

[Five]

thanks so much, I get it now.

one time I ripped twice and got 100.00% and 99.00% on two passes yet the checksums were the same. Now it all makes sense.

[feralicious]

...measure of the accurateness (I have no idea if that is actually a word or not, but I'm going with it)...While accurateness got the point across, accuracy would've been more accurate. ;)

[irishcrazy2005]

While accurateness got the point across, accuracy would've been more accurate. ;)

Haha, thank you! Shows what kind of chemist I am......and to think that they're letting me get my PhD at Berkeley!

-Phil

[tgc225]

Haha, thank you! Shows what kind of chemist I am......and to think that they're letting me get my PhD at Berkeley!

-Phil

Interesting coincidence! My older brother is finishing his PhD at Berkeley in Chemistry (organic I think) this semester :) I'm not as smart as he is though :D Anyway, good luck with that program.

[feralicious]

Maybe EAC tries to guess a value in some cases? Also, there were a number of boots whose value did match the AccurateRip database, I guess those are the most accurate. No, EAC will do what you tell it to do as far as the offsets. You have 3 choices, no offset, combined read/write offset which I believe should be used only when reading and writing with the same drive, and then a separate read and write offset which is what should be used when sharing, I believe.

What confuses me to this day is how to burn audio CDs with someone else's offset? I've looked for an answer a while ago and never found one. I believe you still use your drive's write offset since the read offsets are to correct whatever "inaccuracy" your drive does on audio cds due to not being able to easily locate sectors on audio cds.


Also, a number had "Overread into Lead-In and Lead-Out : Yes", while most had "No". What's the difference between that?The Lead-In and Lead-Out are the parts of the disc before and after the written data. Some drives are able to read into these areas so that if your offset "pushes" some bits of data into one of them those drives can still read it and retrieve it, but those drives that cannot read into them will not be able to. It's been a long time since I configured my drive, but I believe EAC can determine whether or not your drive is able to read into them. If it cannot, I believe you should be sure to have it set to not do so as I think I read that it can harm your drive to set it to try to do it when it can't. Not sure about that part though.
More info: http://users.pandora.be/satcp/eacoffsets00.htm#-a



Another tip for anyone just configuring your drive. After you've spent 3-4 hours hunting through your CD collection to find CDs that match their database as the correct pressings for testing your drive's offsets, make a note on which CDs they were. I can't remember which ones worked for me and I have a feeling that the drive I have all configured is on its last legs. Which means I have to go throught the whole process all over again when I buy a new drive. Wish I knew which CDs those were.... :rolleyes:

Oh, and also write down your read, write and combined offset numbers with the CD names in case you have a bad computer day and you lose your C drive.

[tgc225]

Thanks for the info. I think the most reasonable explanation when it comes to incorrect offsets is that someone bought a new drive but didn't bother to change the offset value. For a few boots that I checked, while the offset value didn't match the drive that was in the log, it did match other drives in the database.

[feralicious]

Haha, thank you! Shows what kind of chemist I am......and to think that they're letting me get my PhD at Berkeley!

-PhilAt least it's not in Linguistics. :lol

[Five]

What confuses me to this day is how to burn audio CDs with someone else's offset? I've looked for an answer a while ago and never found one. I believe you still use your drive's write offset since the read offsets are to correct whatever "inaccuracy" your drive does on audio cds due to not being able to easily locate sectors on audio cds.
As I understand it, with separate read and write offsets this means that any cd ripped with EAC with the read offsets corrected can be written as an exact audio copy on any drive with the write offsets corrected (for that specific drive). If you have a drive that forces you to use a combined read/write offset it is not possible to make exact audio copies unless you do it on your computer only. I think this ties in the the Lead-In and Lead-Out stuff.

Another tip for anyone just configuring your drive. After you've spent 3-4 hours hunting through your CD collection to find CDs that match their database as the correct pressings for testing your drive's offsets, make a note on which CDs they were. I can't remember which ones worked for me and I have a feeling that the drive I have all configured is on its last legs. Which means I have to go throught the whole process all over again when I buy a new drive. Wish I knew which CDs those were.... :rolleyes:
I remember what worked on mine... Led Zeppelin BBC Sessions! You're supposed to test with more than one disc, so this one works great since it's a 2cd set. I should probably also mention that mine is the Canadian pressing. Also a great listen fwiw.

Oh, and also write down your read, write and combined offset numbers with the CD names in case you have a bad computer day and you lose your C drive.
Now this is some good advice! *gets pencil and paper out*

Thanks for the info. I think the most reasonable explanation when it comes to incorrect offsets is that someone bought a new drive but didn't bother to change the offset value. For a few boots that I checked, while the offset value didn't match the drive that was in the log, it did match other drives in the database.
This theory makes sense. It seems like a pretty obvious mistake to avoid, but I could see this happening to ppl who configured EAC a couple years back and have since forgotten everything except "I did it".

[uhclem]

Somebody really tedious could look up my drive and shift everything over by exactly 98 samples then the files would theoretically be exactly the same as an offset-adjusted rip.
Tedious is a polite way of wording it.


I'll have to look that up... does anybody know this offhand?
Some drives can read into the 'leadin', some can read into the 'leadout', some can do both, (most) can do neither. This is also called 'over reading'.

The leadin and leadout are parts of the audio CD required by the redbook standard and placed at the very beginning and very end of the audio respectively, as the names imply. When you rip a disk with correct offsets, your drive doesn't actually read into the leadin or leadout but it thinks it is doing one or the other because it has been told to apply an offset. For instance, if your read offset correction is +98 this tells your drive to start reading 98 samples ahead of usual. The drive therefore thinks that when it gets to the end of the disk it has to read 98 samples into the leadout before stopping. It's not really reading into the leadout but it thinks it is, so if the drive can't read into the leadout it won't be able to read those last 98 samples. If your drive can't read into the leadout set EAC to 'fill missing samples with silence'. Odds are that those missing 98 samples were silence anyway.

You can tell if your drive reads into the leadin or leadout from the tables, or you can tell by adjusting the offset and seeing if you get sync errors. If you have a positive offset correction and always get a sync error on the last track when you tell EAC to over read then your drive can't actually read into the leadout. Likewise if you have a negative offset correction and your drive can't read into the leadin, you will get sync errors on the first track if you tell EAC to over read. Note that there is only one setting for reading into both the leadin and leadout in EAC. So here's a summary:

- positive offset correction - drive must read into leadout - if it can't, turn off over reading and set to 'fill in missing samples with silence'

- negative offset correction - drive must read into leadin - if it can't, turn off over reading and set to 'fill in missing samples with silence'

Strictly speaking exact copies are NOT possible if the extracting drive cannot over read as required. This is most drives. Oh well.


I would rather if ppl took the time to actually test the real offset values for their specific drives.
This is only possible by looking up the values in the published tables or by using a proper EAC configuration disk, i.e. a disc published in the tables or one made on a computer with proper write offset. (There is a third way to determine your read offset using ADD or AAD CDs, but it is so incredibly complicated that I would recommend it to no one.)

There is possibility for variation even with the same model drive so the only truely accurate way to configure EAC is to do those tedious tests. Even then, some drives will have different offsets at different times of the day! In this case, an average has to be taken by the user and manually entered. Thankfully, this is a rare occurance.
This is indeed rare and shouldn't happen with newer drives, i.e. anything more than 3 years old.

If ppl are lazy and just punching in a number it's implied by the .log that they have actually tested their drive several times to arrive at that number. If that's not the case I would rather just see a zero. I'm not sure if everybody would agree with me on this.
I agree. If you don't know what your read offset correction is, don't guess. Set it to ZERO.

Then there are some cases where the coaster factory says your configuration necessitates using the undesirable comined read/write offset which means true exact audio copies would only be possible on the computer the cd was ripped on.
Write offset only matters for burning CDs, and combined offset is only for copying CDs when you don't know your read or write offsets (because you can calculate your combined offset from any CD).

From TTD's perspective all that matters is that the person who ripped a CD for torrenting here used the correct read offset (or used no read offset correction at all). NEVER use combined offset for ripping and torrenting files.

Provided the files were ripped with proper offsets you never have to worry about another person's offsets when you burn the files to CD on your own computer. In fact, you NEVER have to worry about that even if they used the wrong offsets. If they used the wrong offsets and actually lost audio samples, you can't get them back anyway. The only thing you need to be concerned about is if you notice that there is no silence at all at the beginning of the first track or the end of the last track. You could end up losing some of the audio if you burn without write offset correction or can't write into the leadin/leadout. And remember, you want a CD that can play in any CD player out there, and NONE of them use offset correction during playback. But there is a very simple solution: just add a second of pure digital silence to the very beginning and very end of the disc before burning. Even half a second will be more than sufficient since that equals 22,050 samples, which is way way more than any read or write offset that I have ever seen. But I always add one second if necessary since that entirely avoids creating an SBE issue. (Whatever amount you add, just make sure it's an integer multiple of 588.)

[uhclem]

so there's only extraction errors when it says something like "suspicious position at..." or if it doesn't say "copy ok". but when you use burst mode, it says "copy ok" too :confused: does that mean that burst mode is also 100% accurate?
No. Burst mode doesn't apply any error checking so all that 'copy ok' means in burst mode is that EAC was able to read the whole track, but with no guarantee of accuracy. You should only use burst mode on a really bad disk that just can't be read in secure mode or paranoide mode, in which case you should use 'test & copy'. If you get the same CRC for the test read and the copy read then you're getting as high quality as you can possibly get from burst mode.

[tgc225]

From TTD's perspective all that matters is that the person who ripped a CD for torrenting here used the correct read offset (or used no read offset correction at all). NEVER use combined offset for ripping and torrenting files.

So can the offset stuff I mentioned in post #14 be added to to FAQ :) I really like the website for enforcing high standard already, and since most people here are already keen about using silver discs and EAC secure mode, making sure read offsets are set correctly shouldn't be much of a problem.

And sorry for all the complaining and not much contributing yet, but I'm still waiting on PNY for my replacement video card that's on my main computer :(

[Five]

we're waiting for our "Renegade Geek" to step away from World Of Warcraft and approve this :lol

And sorry for all the complaining and not much contributing yet, but I'm still waiting on PNY for my replacement video card that's on my main computer :(
No sweat, seed when you find the time. You've helped me out tremendously with your posts & seeds across several sites now. It's always great seeing a fellow Beatlemaiac around these parts.

Speaking of which, where's your cool avatar?

[tgc225]

I have one more question that I wanted to clear up. I was reading the Coaster Factory link, and I'm a little confused. As far as I understand, to burn a new disc that will match an original, you need:

1) Someone to rip with EAC with the correct read offset
2) Then you need to burn using EAC with the correct write offset (and you can only use EAC to burn, because it's the only program that supports seperate write offsets)

Or, the person who rips can rip with combined read/write offsets, and when you burn the file to a disc, it'll be correct, but the files on the hard drive have incorrect offsets.

Is this correct?

EDIT: I did a little bit of reading, and looks like I was wrong about the second option. If combined offets are used, then the burn must be made on the same drive from which it was ripped.

[Five]

that's right, including the edit... except the combined read/write offsets might be for two drives, your rom drive and your burner would be usual. don't use this option unless you have to!

the best thing to do is test if you can do an exact audio copy using your own computer and separate read and write offsets.

I did this. I set up all my offsets, ripped a silver cd, then I generated a wholefile .md5 for the WAVs. I burned an audio cdr from these WAVs, switched it to the read drive, then ripped this cdr to a new folder. I tested the .md5 I created from the silver rip and it was perfect. EAC also mistook my audio cdr copy for the original silver when I put it in.

The only thing left to test would be to rip a cdr on another computer then follow thru the steps and see if the .md5 still works. I'm pretty sure it will.

[tgc225]

Alright, thanks :)

From what I read, offsets aren't really a big deal anyway because most drives have positive offsets, which forces them to go into the lead out, and only a few drives like Plextors can read into the lead out, so with most drives you end up with silent blocks in those sections.

So it seems to me in those cases, the front of the file is properly corrected, but the end isn't. Of course, in many cases, there's silence at the end anyway, so it doesn't really matter.

[Five]

that's right, including the edit... except the combined read/write offsets might be for two drives
I was drunk when I wrote this, I'm not positive that it's true. But anyhow, avoid combined read/write offsets. In a case where you can't burn with EAC on your computer you can still rip with the correct read offset and somebody else who can write with EAC using the correct offset could burn an exact copy from this.

and yeah, I think what you say about the lead out sounds about right to me.

There's also SHNtool cmp mode optional arguments which I haven't tried that I have a feeling might be useful. Has anybody used these before?

cmp mode optional arguments
-s Check to see whether the WAVE data contained in the input files
are identical modulo a byte-shift. Currently, this will only
detect differences up to the first 529200 bytes (equal to 3 sec-
onds of CD-quality data). This can be used to compare WAVE data
within a pre-burned file to WAVE data in the corresponding track
ripped from the burned CD, which is useful if the ripped track
came from a CD burned TAO, and thus might have a 2-second gap of
silence at the beginning. This option can also help identify a
CD burner/CD reader combined read/write offset.

-l List offsets and values of all differing bytes. Output is simi-
lar to 'cmp -l'; in particular, offsets are 1-based. Can be
used with the -s switch.

-f fuzz
Sets the "fuzz factor" for determining whether byte-shifted data
is identical. fuzz is a positive integer that represents the
maximum number of allowable byte mismatches between the two
files in the area searched by the -s option. This allows one to
check for differing bytes between to files that (a) are byte-
shifted and (b) contain at least one error in the area searched
by the -s option. The higher the fuzz factor, the longer the
search takes, so set it low to begin with (8 or so), and
increase it in small steps if needed. NOTE: this switch can
only be used with the -s switch.

[tgc225]

and yeah, I think what you say about the lead out sounds about right to me.

Yeah, I read more about the "Truth about offsets" guide, and it looks like even Plextor drives can't read absolutely everything, but they'll only lose the combined offset amount at the end of the files (while other drives will lose the amount of samples equivalent to the read offset correction).

I read around on HydrogenAudio, and it seems most recommend setting the read offset correctly, since it's so easy to do. At that point, your file will be virtually identical.

[pernod]

Some drives can read into the 'leadin', some can read into the 'leadout', some can do both, (most) can do neither. This is also called 'over reading'.

The leadin and leadout are parts of the audio CD required by the redbook standard and placed at the very beginning and very end of the audio respectively, as the names imply. When you rip a disk with correct offsets, your drive doesn't actually read into the leadin or leadout but it thinks it is doing one or the other because it has been told to apply an offset. For instance, if your read offset correction is +98 this tells your drive to start reading 98 samples ahead of usual. The drive therefore thinks that when it gets to the end of the disk it has to read 98 samples into the leadout before stopping. It's not really reading into the leadout but it thinks it is, so if the drive can't read into the leadout it won't be able to read those last 98 samples. If your drive can't read into the leadout set EAC to 'fill missing samples with silence'. Odds are that those missing 98 samples were silence anyway.

You can tell if your drive reads into the leadin or leadout from the tables, or you can tell by adjusting the offset and seeing if you get sync errors. If you have a positive offset correction and always get a sync error on the last track when you tell EAC to over read then your drive can't actually read into the leadout. Likewise if you have a negative offset correction and your drive can't read into the leadin, you will get sync errors on the first track if you tell EAC to over read. Note that there is only one setting for reading into both the leadin and leadout in EAC. So here's a summary:

- positive offset correction - drive must read into leadout - if it can't, turn off over reading and set to 'fill in missing samples with silence'

- negative offset correction - drive must read into leadin - if it can't, turn off over reading and set to 'fill in missing samples with silence'

Strictly speaking exact copies are NOT possible if the extracting drive cannot over read as required. This is most drives. Oh well.


I've configured EAC quite some time ago and my settings has Overread into Lead-Out and Lead-In checked. Reading your post and mentioning the fact that most drives can't over read I'm having second thoughts about it being correct. Can I test my drive if it's capable of overreading without having to configure EAC from scratch? And if so, how?

[Five]

here's how you test your configuration:

set your offsets

make sure you're in secure mode.

extract a cd (preferably a short one that you're sure is scratch-free)

save the .log file when you're done and check it for any reports of errors.

when you achieve a perfect extraction:

generate .st5 (or even md5 if you want) from the resulting wav files and save it.

burn a cdr from those wav files using EAC. (use the WRI button and drag the files in order one at a time into the window, then burn. check carefully that the order and # of files is all correct).

take that cdr and put it in the drive that you use for extraction (might be the same drive depending on your setup). If all is well at this point, EAC will mistake the copy for the original and fill in the CRC values for all tracks in its display (!).

extract from this copy and save to a different folder.

generate st5 from these files and compare with the st5 from the other set of wav files that came from the original cd. if they match, congrats, your system is perfectly configured and you are capable of making an exact copy of an audio cd/cdr. anybody who burns an audio cdr with correct write offsets after downloading from bt will get a perfect copy of your original.

test it with several cds until you're satisfied.

I've heard that it is not possible to get it perfect on all systems, but I got it perfect on mine so I hope this helps you out.

instructions for setting offsets and generating checksums are in my signature\/ \/ \/

[pernod]

Thanks Five. I did configure EAC when I first got acquainted with it back in 2004 and haven't changed the settings since then. What I was concerned with after reading uhclem's post was this:

Some drives can read into the 'leadin', some can read into the 'leadout', some can do both, (most) can do neither. This is also called 'over reading'.

I have Overread into Lead-In and Lead-Out checked and I wonder if my drive is one of the few exceptions as mentioned or that it somehow got checked when it should better have been left unchecked. I can't remember if I actually tested it. In other words, how can I determine if my drive is capable of that without going through the fuzz of having to configure my EAC settings all over again? I can't find any information on that.