AccurateRip comparison database... how big is it?

[LeeC22]

Re: AccurateRip comparison database... how big is it?

So the last track being short by 588 samples (I have no idea how that relates to track length, seeing as they are the same time length 5:32 and the same data amount 55.92MB) causes the second track onwards to fail verification? Surely only the last track should fail verification... or for that matter, all tracks should fail.

Doing a simple calculation based on frequency and sample count, it works out that the missing samples, relate to less than 1/60 of a second. I'm guessing it probably finishes too soon, after a period of silence. If PerfectTUNES is rejecting full albums, due to missing periods of silence of that size, at the end of the last track, then I am definitely not going to use it. That's like saying a DVD rip fails, because the black screen after the credits was on screen 1/60 of a second too short.

At least we've cleared up where an error (of debateable significance) lies, and saved me some money in the process, so I guess we can call that a successful investigation/resolution.

Thanks guys.

[Spoon]

Re: AccurateRip comparison database... how big is it?

AccurateRip works on more precision than minutes and seconds, it uses frames (which are 1/75 of a second). 588 samples are 1 frame.

AccurateRip uses the track lengths (accurate to 1/75 of a second) to generate a disc identifier, if the last track is the wrong length, then the wrong disc identifier is generated, there can be no match for any of the tracks.

[LeeC22]

Re: AccurateRip comparison database... how big is it?

If there was no match for any of the tracks, then the fact that track 1 of this album registers as accurate (as you can see in the image), completely dispels that theory.



Clearly, using that level of accuracy, to determine a disc that seems to be easily (and accurately) identified by your CD ripper, using other methods, is a flawed process. I cannot understand why you would re-identify a disc, that has already been correctly identified by the ripping process. All it is doing, is using an overly-accurate comparison method, to generate an ambiguous level of error reporting, that is no help to the user, in determining which actual tracks, may have ripping errors in them.

It is no good being able to say "This rip is 100% accurate", unless you can also say "This rip is not 100% accurate, and the reason is...". It's like taking your car for its MOT, and them saying "it failed", without telling you why. You can't fix unspecified errors...

There's no doubt that the technology has promise, but in its current state, it's just too vague to be of use to me. As such, it's probably best if you just let this thread fall into the abyss. I'll remove my thread subscription after posting this. Thank you for your input and clarification.

[Spoon]

Re: AccurateRip comparison database... how big is it?

I can 100% be certain any track is of a different length then the disc lookup id will be different, not what is to be expected.

For the 1 track match, many strange discs are out there, it could be WMP has that one right (track lengths).