I'll browse the Wiki today in an attempt to answer these questions, but I didn't think it would hurt to post them here in the meantime.

After a false start (where I forgot to deselect "delete leading and trailing silent blocks"), I am now merrily archiving my CD collection using EAC and FLAC. I've come up with a few questions during the project:

1. Are pregap tracks aka "Track Zeroes" stored in the AccurateRip DB? If so, are they stored as part of Track 1?2. I'm trying to decide how to handle tracks which have hidden second songs (typically at the end of the album). It appears AccurateRip assumes both songs will be ripped as a single track. But for archiving purposes, is there any reason not to split these tracks apart, provided I don't delete any of the intermediate silence?3. I'm used to seeing albums that aren't present in the AccurateRip DB or that are "different pressings/versions" of an album. But I had one strange situation come up. I don't remember the album, but it had 11 tracks. Tracks 1-8 and 10-11 matched the DB. But track 9 - which EAC reported at 100.0% quality (i.e. no sectors were reread), didn't match the DB. What could cause this?4. My CD reader has a +6 offset and no ability to overread either direction. I assume this means I'm losing 6 samples - or 0.136 milliseconds - on one end of the track. Is that correct?

1: No. 2: Then you need to join them (perfectly!) if you wish to be able to retro-check against AccurateRip later.3. You don't say anything about the number. The submitted could be wrong.4. No lengths will change, but everything will be moved 6 samples to get it aligned to the “0” reference. But nothing says that “0” (or was it thirty it should have been) is in line with the offset used in the mastering process. So in reality, it is moved an unknown number of samples. Nothing you can do about it, nothing you need to do about it (unless you feel like making a fix in those cases where track boundaries are audibly off).

3. I'm used to seeing albums that aren't present in the AccurateRip DB or that are "different pressings/versions" of an album. But I had one strange situation come up. I don't remember the album, but it had 11 tracks. Tracks 1-8 and 10-11 matched the DB. But track 9 - which EAC reported at 100.0% quality (i.e. no sectors were reread), didn't match the DB. What could cause this?

Even if the quality is 100.0%, that simply means that the track read exactly the same twice. There is still the possibility that it read incorrectly but made the same error both times.

You might try to reread that track a few more times to see if it ever reports a different checksum, and then match that against AR.

If C2 pointers are being used then the track was only read once, not twice. Additional re-reading does occur for synchronization checking as well as any additional re-reads as indicated (which didn't happen since the accuracy was 100%), but not over the entire track.

I'm pretty sure I covered this under a previous discussion between the same participants only three days ago. Was it overlooked?