![]() ![]() This article does not cover playback of music with the ACS100. For this evaluation I chose the relatively inexpensive ACS100 to study the process. This would include as of date of this article three models - A30, ACS10, and ACS100. Sharing this to illustrate the value of addressing glynor's original question/issue.It's been a while since I have written a new article but decided to sit down and share my thoughts on how Aurender digital transports capable of CD-Ripping work. I'm all for a one-stop software solution, i.e. The local database is then compared with AccurateRip and errors or non-matches are flagged. Note my audio collection has about 10,000 tracks, so searching for needles in the haystack was made achievable.įor those wanting more background, PerfectTunes first "listens" to the audio files that it's directed to and builds a database. Personally, I found the software worthwhile in terms of time saving. I used this cut down list to back up all the broken or suspect files rather than the whole lot. It identified broken files that I deleted and files that didn't match the AccurateRip database. I had PerfectTunes in my bottom drawer and gave it a go. I was able to recover the partition using some recovery software but how could I be sure the audio was in a good state and hadn't been corrupted? Also, how to avoid the long drawn out process of backing up the data from network storage? I was having system hassles and on the journey, the partition where I had my local audio files stopped being recognised. I've made good use of PerfectTunes recently (you can find it over at dBpoweramp). (which I have actually seen people claim to be true!) ![]() I don't mean to suggest that two rips with the same checksum could possibly result in different audio without intentional manipulation. Without external verification, that disc appeared to be a "good" rip. When listening to the audio that rip resulted in, there were obvious problems. I have had a visibly damaged disc which has verified as being ripped "correctly" after multiple passes on it, because it got the same bad data each time. If you don't do that comparison, they are probably good, but you can't be certain about it. If they are, now you know that your rips are good. If you compare that against the accurate rip database, you can confirm whether or not other people are getting the same results that you are. ![]() If the drive is only checking against its own data, then it will not report an error if it gets the same bad data back each time. What I mean is, if the drive is not reading the disc correctly (outputting bad data) or the disc itself is damaged in some way (perhaps a bad pressing, even though it is not scratched up) then my drive could rip the disc and think everything went fine. Sorry, I don't think I was clear in my previous post. I'd bet it is something like the chances that all the particles in the sun are going to spontaneously align their quantum states such that fusion stops, or something like that. The chances of a "broken hardware" CRC-32 collision matching? I can't even imagine the odds. In this case, the hashes won't ever match (neither of them) in the real world. Oh, and if the hash generation is actually failing on your hardware (and producing incorrect results), then that means that your computer can't do basic math properly, which means all bets are off. If you get a hash collision on the actual Secure Rip check, then the AccurateRip hash check tells you nothing (because it is going to result in the exact same collision). Plus, and more importantly, AccurateRip is just recalculating the same hashes, so the chances of this check resulting in a collision are equivalent, especially given the same inputs. In other words, you're far more likely to be hit by lightning or eaten by a shark. The birthday problem would apply, I suppose, if someone was intentionally trying to defeat the CRC32 hash check (by feeding it different inputs over and over and searching for one that matches), but with only two "random" inputs (the hash of the information on disc, and the hash of the file post-ripping) the chances this would happen are something on the order of 1 in 4 billion. While the birthday problem does certainly apply to the CRC32 hash algorithm, this issue doesn't specifically apply to your use-case. ![]() Just because you're paranoid, don't mean they're not after you.įor the record: The chances of this happening are infinitesimally small. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |