Most encryption algorithms, whether implemented on a file or real-time on a disc, are not primarily concerned with ECC. Plenty use hashes, but not for the purpose of correcting errors caused by disk corruption. There are even less of the kind the author is looking for (real-time total disc encryption with ECC seamlessly integrated). It's not my speciality so I don't know of them

But if we're talking about sending and receiving data from long-term storage (rather than real time), that is easily attainable if you separate the encryption and error detection tasks. For error detection, and just as important, being able to fix those errors when they happen (two separate things) the term you're looking for is Forward Error Correction (FEC) software. If you're serious about backing up your data, and it still being around and undamaged in a few years, you should be serious about FEC. It amazes me how many enterprise-level companies frequently back up millions of files, but have no strategy for ECC.

Using vdmfec (my favorite FEC software. For linux), say you have a file that is 1gb that you'd back up with it (Large archive files are especially important to use forward error correction on, because plenty of them, if they get data corruption in the wrong place, get totally screwed up.) So, let's say with vdmfec you select the blocksize to be 5 kb, and then you select two positive whole number parameters, K and N. For every original K blocks, N blocks are written so that if up to N-K fail, you can still recover all original K blocks.

In plain english, if I set a K value of 10 and an N value of 30, then the first 50kb of the file would be transformed into 150kb. There could be quite a few bits accidentally flipped in that 100kb over time, but as long as any 10 of the 30 blocks did not suffer any damage, that set of blocks would be entirely fine. You can pass different K and N arguments according to your needs (reliability v. size) for a reasonably reliable disc over the short term, K=15 and N=20 would do just fine.

For encryption, use whatever you'd like, total disk encryption, folder encryption etc. One concern is that if you use any error detection or correction, it establishes a reliable data pattern which can be used to break the encryption. This concern can be solved by encrypting before applying error correction instead of after, or using encryption of sufficient bitstrength so that it will take another several decades for the hardware to be developed to crack it.

it's true. I moved my all of my old screenplays into my /dev/null drive a year ago, and just recently I decided to have a look at them again so I typed head -n50000 /dev/urandom; they came back, and boy was I glad: they actually seem to make more sense now than I remember them making before.

I thought video games were about escaping reality. If developers start making video game world where success mirrors the player's real-life wealth, rather than their skill, then what would be the point? If I wanted to see rich people getting what they want, and the average joe getting screwed because they don't have enough money, all I have to do is read the news. I don't see why I should shell out $60 and hours of my time to do that. Furthermore, wasn't the video-game industry originally about entertaining kids? A kid can't afford to buy power-ups, to pay for new race tracks, and all but the most spoiled won't be able to coax their parents into it. So if a kid sees a game like GT, they get all excited, they wait all year for it, they buy it with their birthday money, they get, what? A couple cars, a few tracks. You know, for all this talk of next-gen, the gaming experience seems to have gone significantly backwards. It's all about the money these days, and never about the fun.