4 ms·
He has no idea if he has an exact copy of the actual track. He has a copy of the data that is consistently ripped by his drives. There is nothing to assure that
by wang_li 8y ago
He has no idea if he has an exact copy of the actual track. He has a copy of the data that is consistently ripped by his drives. There is nothing to assure that these are the same. Sounding fine -- for some values of fine -- is the only way to tell if it's correct -- for some values of correct.
- iforgotpassword 8y agoSounding fine says nothing, it's rather that not sounding fine tells you something, namely that ripping failed. Having some of the least significant bits of a sample flip for example is inaudible and will sound fine. Sure, op has no absolute guarantee, but the fact that his crc32 matches that of the AccurateRip DB is, apart from his statistical approach, another strong indicator that he actually got it right. The alternative is that either the other user who submitted the crc32 to the database coincidentally ended up with exactly the same read errors, or that it's a hash collision (not entirely unlikely given the size of the checksum). It's reasonable to assume op got a perfect rip.
- wang_li 8y agoHe didn't get a match against the AccurateRip database: > That single AccurateRip entry for this album matched my CRCs for all tracks except track #3 – they had 0x84B9DD1A, vs my result of 0xA595BC09. I suspect that original ripper didn’t realize their disk was bad.
- iforgotpassword 8y agoHuh you're right; I stand corrected then. (Btw did you see the addition at the beginning of the article? Funky stuff going on...)