Mark's Blog

If you ever did, you wondered right: There is no point for checksums in Torrents. Every chunk to download comes already with its own checksum, hence the file once downloaded cannot be corrupt – except it was already seeded so.

But you’re doomed to restart a download if it does not match the MD5 checksum or its extraction yields in CRC errors. Then you might wish to be able to repair that broken download. Unfortunately, although SFVs are tiny – or whatever checksum file format has been used – they can only prove the download valid or not. (See QuickSFV for a reliable tool for this.)

Repairing is easy but requires some overhead. Another file has to be calculated, this time with data for error correction. The most popular tools are QuickPar for creating PAR/PAR2 files and ICE ECC, being a mightier and faster tool.
By adding an 3-25% overhead you can not only verify the  files (and directories) integrity, you can also fix corruptions. And, only having to download 25% of a DVD image is far better than the DVD again… most probably with another corruption. Error correction codes can even correct errors and corruptions of itself!

Even when it is not for downloads, you could create such checksums for your DVDs (have a look at DVDisaster) or valueable data. (Or detect forged drivers’ licenses. See here.)

And, you can even distribute kind of tiny updates and patches by publishing “the wrong ECC” resulting in you application being modified. An advantage of this is that your customer can always verify whether his application was modified and (by the ECC of previous version) revert to an earlier version.

BTW, for binary patches you should known XDelta3. But this is another story.

My wish for today is, no more SFV in Torrents and ECC files for large downloads. Thank you.

Bookmark to: