Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: A couple of basic AccurateRip questions (Read 4458 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

A couple of basic AccurateRip questions

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?

Thanks in advance.

 

A couple of basic AccurateRip questions

Reply #1
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).

A couple of basic AccurateRip questions

Reply #2
3. You don't say anything about the number. The submitted could be wrong.

Thanks for replying.  To answer your question, AR's confidence was 6 on that track.

A couple of basic AccurateRip questions

Reply #3
3. You don't say anything about the number. The submitted could be wrong.

Thanks for replying.  To answer your question, AR's confidence was 6 on that track.


And that is the same as on the other tracks? (If not, there could be manufactoring errors that lead different players to read different numbers.)

I would make the guess that you have a CD drive which does not support the so-called C2 error pointers?

A couple of basic AccurateRip questions

Reply #4
And that is the same as on the other tracks? (If not, there could be manufactoring errors that lead different players to read different numbers.)

I would make the guess that you have a CD drive which does not support the so-called C2 error pointers?

Yep, confidence was 6 on all tracks...and my drive is C2-capable.  I should also note these were AccurateRip V2 CRCs.

Is it possible that an alternate pressing of an album would only have a different CRC on one track?  I'm scratching my head over here...

A couple of basic AccurateRip questions

Reply #5
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.

A couple of basic AccurateRip questions

Reply #6
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?

What could cause this?

You may want to read what is written about C2 pointers here as a possibility, in case you haven't already:
http://wiki.hydrogenaudio.org/index.php?ti...#Drive_Features

More reading of the forum and wiki articles should cover a lot (if not all) of the questions being raised.  This material has been covered to death.

A couple of basic AccurateRip questions

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

Guilty as charged.  Even though I've been closely monitoring the topics I started, I somehow missed that post.  Thanks.