isn't that accuraterip?
1) Integrity check of md5, sfv, par, par2 files. 2) Directory recursive. 3) Multiplatform.4) GUI-based.These would be awesome
How about having the resulting hash be simple enough that it can be included as a field of the metadata of the file itself?I'm not sure what I mean by "simple"... I guess I'm leaving it up to the reader to decide.It'd be nice if this is something that would eventually find native support in all major music players.The hash should also ideally be immune to changes to the audio stream that don't affect the decoded output, like audio that's been padded with digital silence should have the same hash as audio without silence.
thats the main feature of my oss application, be patient .
Maybe you could base the audio decoding part on existing plugins (eg: 1by1 player uses winamp plugins)
- application will store audio hash in a tag (already on TODO);
While we're on the topic of hashes...Why must audio files be hashed using MD5? It's too complicated I think. I mean, MD5's main function is not for error-checking, rather to prevent willful tampering.For the normal damages that happen to audio files, CRC32 is enough. Perhaps 2 CRC32 values with different polynomials. Should be quite robust. And it's easier to implement. Not to mention a wholelottafaster.
Well, no one forced whoever to use MD5 for hashing. And well, MD5 is still the hash algorithm which attains the best speed/security ratio. You could use MD4, which is faster but is known to be flawed.
Yeah, you could use CRC32, but you have the probability of 1 in 4 billion that the error will not be detected.
QuoteMaybe you could base the audio decoding part on existing plugins (eg: 1by1 player uses winamp plugins)what you mean by that ? audio hash doesnt need encoding, fingerprint does.
@sn0wman: Any news on your project?