4 ms·
hi, I don't understand why they use ffmpeg for bitrot checking and not a simple hash checksum or a merkle tree.
by daedalus2027 4y ago
hi, I don't understand why they use ffmpeg for bitrot checking and not a simple hash checksum or a merkle tree.
- arendtio 4y agoFrom my very limited understanding of the software I understand, that it doesn't compare an earlier version with a later version as you would with hash sums, but rather utilizes ffmpeg to check if something odd/irregular shows up. In addition, it can use PAR2 files which can be used to restore the original version which would not easily be possible with hash sums. But as I said, I just read the description, nothing more.
- mmastrac 4y agoThis is correct. I have a large media library and I wasn't sure how rotted it was. Test decoding won't catch every error, but it identified albums where there has clearly been a bitflip in a song (at which point I can try to find a lossless copy of that song to replace it). Once I'm happy with the state of the library, I use automedia to add on par2 files to avoid this going forward. Verification is for libraries that have no existing hashes or parity, essentially.
- UncleEntity 4y agoI think par2 just uses a list of hashes to determine if it needs to do some error correction. Though I do see the value of checking the files when first ‘checked in’ to this recovery scheme so you start with a known good copy. The idea is solid and since it has transcoding build in it makes perfect sense to just use ffmpeg. —edit— The author beat me to the answer…
- fnordpiglet 4y agoIn addition to the other comments I don’t think a merkle tree would help in this situation. Bitrot is a random event and wouldn’t trigger anything that would take advantage of the tree data structure.