I thought the same thing when using PAR files. They're still useful today if you save things on media that can be damaged (CD, DVD, Blue-Ray) or across multiple multiple media.
Eventually, I decided to dig into the math behind it. It is a surprisingly simple principle:
Given polynomial of a degree X and an array of data points of size X, there is one and only one solution to the polynomial's coefficients such that it will pass through those data points.
So, stripe the data into bands of arrays, compute the polynomial, and compute additional data points of the curve, and save it with the original data. If you have at least the array's size of data points ( original array and/or parity values) and know the place in the list for each data point (thus which data is missing), there is one and only one solution to the polynomial equation. Once you solve the polynomial again, you can compute any point, including the missing ones. Again, because there is one and only one solution for the curve.
The devil is the math necessary solve the polynomials, which is why it is so computationally intensive.
"If anything seems like magic you're not asking enough questions." -- Mario Romero Vega
For writable disk media, there is also dvdisaster:
Galois Fields are really awesome (and are related to CRC codes). The level of effort to learn is quite high. NASAs guide to ReedSolomon was amazing though
-----------
XOR codes are easier and sloppier. But are actually what's used today despite being imperfect.
Let's say you have A, B, C... Z as your data.
Parity#1 could be XOR(A, B, Z). If B were missing, Parity#1 XOR A XOR Z can back-calculate B.
Parity#2 can be a random set of all previous entries (including Parity#1). Etc. etc. etc.
Keep adding XOR parity codes until your probability of reconstruction is high enough to please you.
I believe this concept is called a Fountain Code.
It's a very shallow introduction to Galois Fields but it's just barely enough to reach Reed Solomon encoding and understand error correction codes.
As I said earlier: it's a lot of math, even in this simplified form. Abstract conceptual math. But I do find this kind of abstractness very fun.
Arithmetic wouldn’t be a good implementation due to integer overflow (a problem XOR doesn’t have) but it’s helpful if you ever have to explain it to the less technical business person who you need to sign off on the purchasing decision.