[Wishlist] Feature request for future versions

[mvondev]

Hello I would appreciate if future versions of par2cmdline can support the following.

1. '-r' option can take redundancy > 100%.
2. Add two new modes (besides create, verify and repair) that:
   a. prints the paths and md5 digests of files that a recovery file is intended to repair, in the format of 'md5sum' utility.
   b. prints the recovery set ID of a recovery file.
3. When creating a recovery set, allows getting file list from a file instead of command line arguments.

Thanks.

[mdnahas]

4. It would be useful if par2cmdline would function as a library that could be compiled into usenet readers and other programs. That would mean command line text processing and output to terminal would have to be modified.

5. Add support for LDPC. A new class of parity codes, call "low density parity codes" (LDPC) were patented starting in 1997. LDPC makes creating parity files and recovery MUCH faster. The first of those patents is now expired. Adding support for "Tornado Codes" would be cool. ("Tornado Codes" are different from "Turbo Codes", which are also cool.)

6. Should architecture-specific code (e.g., WIN32) be put into separate files?

7. Pseudo-random tests. It looks like the tests run with specific files. I usually like writing at least one test that uses a pseudorandom number generator to test a wide range of input values (file sizes, file contents, amount of damage, amount of recovery data, etc.). The checked in code would have a chosen seed and fixed run length for the test, but developers could use random seeds and unlimited run length to thoroughly test the code.

I'm just getting into the code. I'll probably have more suggestions later.

[animetosho]

It would be useful if par2cmdline would function as a library that could be compiled into usenet readers and other programs

There's libpar2, though it's a bit out of date compared to par2cmdline.

Add support for LDPC

Neither PAR1 nor PAR2 would support this, meaning that you'd need to come up with a new PAR standard ('PAR3'?) for that. There have been discussions regarding this, but I haven't seen anything solid come out from them. If you're interested in developing a new PAR standard, check out some of the discussions here for ideas that have been brought up.

[trafgals]

I'd love to see support for >32768 files/parts. Reason being:

1. PAR2 is used extensively on Usenet as THE way to ensure archive integrity
2. Usenet article size is limited to 1MB Max (sometimes 2MB)
3. If PAR files overlap across multiple articles due to the 32k part limit (e.g. any post > 32768 * 1MB = 32GB) there is a massive reduction in repair efficiency (down to 1/2 between 32-64GB, 1/4 between 64-128GB, etc., assuming 1MB article size)

64GB archives once seemed ridiculous, but there are now lots. Usenet is quite archaic, and many servers would have to agree in order to lift the article size. PARs supporting more parts is an ideal fix.

[mdnahas]

@ky7749 The latest checkin enables par2cmdline to supports more than 100% redundancy. (Your #1.)