Chipsets and failing memory can both cause bit-flips that'll give you invalid checksums.
This is not a Monkey's Audio problem -- it is only correctly reporting a hardware failure. APE files tend to show the problem first because they are large and they report errors if even one bit is flipped. (which is good if you're paraniod about lossless)
I understand that this may not be a MAC problem, but I have a few more details that make me reasonable suspicious. The part of my workflow that I'm suspicious of went like this:
1) RAID5 had a drive failure, which corrupted the NTFS directory.
2) Before rebuilding the array, ran CHKDSK, which recovered a lot of things.
3) Before rebuilding the array, played some music--all was fine, no APE corruption.
4) Moved all music from the RAID5 to a new RAID0 with Retrospect's "Duplicate" function.
5) Rebuilt the original RAID5.
6) Moved all music from the RAID0 back to the new RAID5. (I think also w/Retrospect).
7) Restored all of my backed up music from backup sets (all the APLs & CUEs--but NOT the master APEs).
8) Created a new library in MC and imported all my music to begin looking for things that are missing.
This is where I noticed playback problems. Running the "Verify" function in MAC on the master APEs shows every APE that went through the above process (even those that were unaffected by the directory corruption) result in "Error: Invalid Checksum" or "Error: Invalid Input File".
I find it difficult to believe that over 700 APEs can get corrupted by copying them back and forth between 2 different RAID volumes.
Can anyone give me and direction or guidance?
Best,
Best