dvdisaster VS ParPar

DVDisaster, https://github.com/speed47/dvdisaster

My family has a collection of important pictures, documents, and videos which are currently stored on CD-R, and have been since 2005. Ten out of the ~250 discs have been destroyed by disc rot, but luckily there were redundant copies. I am planning on migrating the collection to BD-R, because they seem much more robust. I'm also going to use ECC to protect the discs (https://github.com/speed47/dvdisaster)

For my optical backups I use this additional software, called DVDisaster. I create image with 10 to 15 % space left and let the program augment the image with recovery data. After that's done, I burn it to optical media.

dvdisaster

dvdisaster has returned to life too.

I hope you use dvdisaster to protect your data. If you use it on an ISO before burning it, you can make a bit-exact recovery in most cases, even discarding the zero padding introduced sometimes on re-ripping the disc and mangling things.

Even with archive-grade media you should use something like dvdisaster to generate error-correction-code (ECC) files for each disk (rule-of-thumb, 20% of each disk should be filled with ECC data. That only leaves you with 80 GB if you are using 100 GB BDXL M DISCs)

https://github.com/speed47/dvdisaster (there's tutorials to show you how this works all over youtube and the internet and the manual)

PAR2 creation (file-based error correction): the core routine here is GF(2^16) matrix multiplication. AVX512 has the GF2P8AFFINEQB instruction, which isn't present on any GPU that I know of, but massively accelerates GF multiplication. Without this instruction, you have to resort to emulating it via bitwise operations or lookup tables, which are much slower. I actually have an OpenCL implementation, but its performance is rather meh compared to CPU

Did you tried to use parpar for creating par2 files? Supposed to be much faster. https://github.com/animetosho/ParPar

I've been developing a performance oriented PAR2 tool (used for generating file-based redundancy for error correction), but without access to a lot of hardware, I don't have that much ability to tune it to various microarchitectures. Currently there's no real benchmark setup defined/implemented (though it shouldn't be hard to come up with one), and it certainly isn't tuned for the number of cores on EPYC, but I've never really thought PAR2 benchmarks would interest that many people.

QuickPar is ancient at this stage, however the PAR2 format hasn't changed since, so the concepts are still the same. For a more modern client, I generally recommend MultiPar. I've also written a PAR2 client, ParPar (CLI, or experimental GUI frontend), but it only supports creating PAR2s, not verify/repair.

Also this implementation of par is the fastest I've seen (for creation only thought) https://github.com/animetosho/ParPar

For PAR2, I did a benchmark comparison here of every tool, which you can use to make up your mind. par2j (Multipar) and phpar2 are Windows only, but work via Wine. ParPar only supports create, so you'll need to use a different client for verify/repair.