More about offsets?

[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]

Originally Posted by 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]

Originally Posted by Five

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]

Originally Posted by uhclem

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:

Originally Posted by uhclem

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.