2 ms·
Why would we need to change it, from something that works? Isn't Reed-Solomon already at (or very close to) the theoretical maximum efficiency for redundancy co
by Erlich_Bachman 6y ago
Why would we need to change it, from something that works? Isn't Reed-Solomon already at (or very close to) the theoretical maximum efficiency for redundancy codes?
- Tomte 6y agoI'm not talking about changing anything, I'd like to understand whether LDPC, Turbo codes, Reed-Solomon etc. "do the same thing".
- Erlich_Bachman 6y agoReed-Solomon, as implemented in par2, splits the original file into a number of blocks. The total possible number of blocks I believe is 16k for par2, or some similar number. The specific number of blocks for each file can be configured, and the tradeoff is that the more blocks you want per file, the slower the generation will be. Then it generates some parity data. Using that parity data it is possible (and guaranteed, if the parity data itself is not corrupt) to detect and completely restore 1 or more complete blocks of the target file. The more parity data is saved, the larger number of blocks that can be restored with it. But it doesn't matter which blocks get corrupted, or how they are corrupted. For example, if a given parity data supports restoring 10 blocks, any 10 blocks of the source file can become corrupted, in any ways (even completely missing), as long as the corruption is contained in those blocks - the complete original file will be possible to restore. AFAIK, some other codes are possibly better suited for other tasks, such as stream redundancy measures in radio networks, or other applications where the data corruption has certain known and restricted parameters. But for general purpose file protection, bitrot, bad blocks, bad drives, scratches on an optical disc, download errors etc - Reed-Solomon is very well suited for the task.