After running checksums on some of my WBFS files I've noticed a few have become corrupted on more than one occasion. I always do a safe eject and run chkdsk regularly, so I suspect something else is to blame. I've yet to be able to trace out the cause, so to help counteract this problem and avoid having to re-rip, I made a little batch file to automatically create and verify parity data for me. Code: @echo off for /R \wbfs %%z in (*.wbfs) do ( ÂÂecho Working with variable "%%z" ÂÂecho Titleid is %%~nz ÂÂif exist "%%~pnz.par2" ( ÂÂÂÂpar2 v "%%~pnz.par2" ÂÂÂÂecho Errorlevel was %errorlevel% ÂÂÂÂpause ÂÂÂÂ) ÂÂif not exist "%%~pnz.par2" ( ÂÂÂÂecho %%~pnz.par2 not found.ÂÂCreating... ÂÂÂÂpar2 c -r10 -n1 -v "%%~pnz.par2" "%%~pnz.wbf?" ÂÂÂÂ) ) Save this as ProtectMii.bat and throw it into your wbfs folder along with par2 0.4. Now run ProtectMii from the wbfs folder. It should walk the tree, verify the par2 data if it exists for a given title, and generate it if it doesn't. Please let me know if you run into any bugs -- all my wbfs files are in one folder, so recursion may require a tweak. If one of the wbfs files gets damaged, you can rebuild it with "par2 r titleid.par2" and poof -- magic. If there were documentation on the errorlevel handling, you could have the batch file do it automagically on failure. Now, as a bonus, you can burn your backups to DVD-R with a copy of QuickPar, it's essentially portable. The disc can theoretically be up to 10% scratched/unreadable but still be rebuilt 100%. You can adjust the redundancy settings to above 10% if you want, or change from WBFS to ISO files if that's your thing, just edit the batch file. Let me know if this ends up helping any of you, I might improve upon it then. I think my next project will be that incremental NAND timemachine I brought up, except for SNEEK NANDs (so it can run PC-side, I still can't code for shit on Wii).