Hacker News Reader

Comment by daedalus2027 | Hacker News Reader

daedalus2027·

hi, I don't understand why they use ffmpeg for bitrot checking and not a simple hash checksum or a merkle tree.

From 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.

This 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.

I 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…

In 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.

Reply on news.ycombinator.com