Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bspachman]

So I'm still recovering from my RAID failure from a few weeks ago. I've replaced hardware & rebuilt arrays as needed. I've restored as much as possible from my backups.

However... (you knew this was coming) ...

A great many of my APLs don't play properly. They either play silence for the length of the track, or some combination of digi-noise and silence.

MC has imported them fine. They show the proper duration and bitrate, but they refuse to play.

Verifying them with the MAC3.99 tools shows that they have "Error: Invalid Checksum" on all the APLs and their associated APEs.

Can moving my APEs/APLs around from my primary RAID to a backup RAID cause this? Is there any way to recover my master APEs without re-ripping everything?

Any suggestions are welcome!

Best,
Brad

[ralphberner]

I like WMA lossless.

[marko]

I had a motherboard with an onboard promise raid controller that went bad. It appeared to be working fine, but any file that passed through it was coming out the other side with corruption.

Google for an sfv or md5 checksum program to verify files before and after they pass through the controller, and do copy operations rather than move. Delete the files from their original location once they've passed the checksum test.

There was no fix for this, I ended up purchasing a new motherboard.

-marko.

[JimH]

I hope this helps, though it doesn't give a optimistic perspective.

That's an understatement.

Marko, thanks for your post.  I added it to the "Weird and Wonderful" thread.  There are a lot of ways to drop a bit.

"The Fly" was probably THE scariest movie I ever saw.

[Matt]

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)

[Matt]

As an aside, WMA Lossless doesn't do bit-integrity checking.

It just outputs an incorrect file if a bit is flipped in the WMA file.  That means the errors would still be there.  You just won't know it. (which is probably a worse approach for lossless)

[bspachman]

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

[hit_ny]

RAID5 had a drive failure, which corrupted the NTFS directory.

I'm a bit surprised you had problems restoring from  RAID 5 failure of a single drive.

Isn't the whole point of RAID5, that one can recover gracefully from such an event as there is redundancy of data in exchnge for a smaller total capacity.

I admit i'm not very knowledgeable about RAID, just curious.

[IanG]

Raid Level 5 gives striping (with interleaved parity), but it's Level1 that provides redundancy.

Ian G

[hit_ny]

so why would one use RAID 5 at all then ?

[bspachman]

I'm a bit surprised you had problems restoring from  RAID 5 failure of a single drive.

Isn't the whole point of RAID5, that one can recover gracefully from such an event as there is redundancy of data in exchnge for a smaller total capacity.

That is the point. Unfortunately, what happened was a minor failure in the array after I had already had the dead drive. Once you've lost a drive in RAID5, you have no redundancy until you replace it. Most quality controllers allow you to assign a drive in your array as a spare and will begin the rebuild process automatically. Suffice it to say, I learned that lesson...my new setup has a dedicated (hot) spare. The old one didn't, so a second partial failure lead to my directory corruption (I think).

So...RAID5 does give you a degree of redundancy, plus the advantage of fast reads. However, the penalties are slow writes and the loss of 1 drive worth of space for parity checking.

Let me also recommend the use of a hot spare.

Regardless, any ideas on my APE errors?

Best,
Brad

[KingSparta]

I have a Raid 1 for the server

I also back it up on another drive (each week)

I also have the data back up on 3-each 300 Gig USB\FireWire drives

[GHammer]

Regardless, any ideas on my APE errors?

From bitter prior experience with a LARGE Exchange database that went south under the same circumstances, I'd say your APE files are trashed.
May be hard to believe, but from the sequence you described it would be hard to think otherwise.

[hit_ny]

I have a Raid 1 for the server

I've heard this is actually more risky than RAID-0 or the usual master slave configuration. The reason is you get more speed with RAID-1, but the risk is if one drive develops a problem you lose the whole lot. Hence its safer to have a master slave config where you only lose the drive (assuming one develops problems) and the remaining lot are unaffected.

Sorry to digress from your topic here Brad. I dont have much experience with APE as i tend to do mp3s only. I did try earlier to checksum the whole lot but found i got inconsistent results. Meaning, i would see tracks that were otherwise perfectly fine develop crc errors in a random fashion. I then checked them for mp3 integrity and found no problems with them. I'm not sure as to why these crc errors occurred from time to time. The drives were in perfect order too.

Its a pity as i was looking for a way to monitor my media against such an an event.

[Matt]

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 wish I had some good news for you.  "Invalid Checksum" means some bits in the file got flipped.  If the files played before copying, and no Monkey's Audio code was ever run, and then after the copy the same files don't play, I think the problem has to be in the hardware. (or RAID copying software)  My first guess would be that you have failing memory -- it's more common than you'd think.  A buggy northbridge (VIA, etc.) could also do it.

I don't suppose you have any other backups?

[bspachman]

I wish I had some good news for you.  "Invalid Checksum" means some bits in the file got flipped.  If the files played before copying, and no Monkey's Audio code was ever run, and then after the copy the same files don't play, I think the problem has to be in the hardware. (or RAID copying software)  My first guess would be that you have failing memory -- it's more common than you'd think.  A buggy northbridge (VIA, etc.) could also do it.

I don't suppose you have any other backups?

Heh, all I have is leftover Thanksgiving food and a long week of re-ripping from my original media. Rip a disc...bite of pumpkin pie...rip a disc...glass of wine...rip a disc...turkey leg...etc., etc.

I wish I knew exactly what caused the problem. I'll probably do some tests with Retrospect's duplicate function to see if I can narrow down what happened any better. I don't think it's a hardware problem, but I'm going to also track down a memory tester and see if I get any errors (although I thought using ECC memory would prevent--or notify--memory errors).

Best,
Brad

[bspachman]

Bumping this back up a bit...

I'm nearing the end of the re-ripping process. I've found a couple of my master disc images where I used the exact same version of MAC that I'm using in the re-ripping.

I'm wondering if it's possible to do a comparison between the original (corrupt) file and the new (working) file to see what the differences are. Perhaps that can lead to either a more robust error-correction for MAC, or give me a hint as to what caused my problems in the first place.

Any ideas?
Brad

[Matt]

Bumping this back up a bit...

I'm nearing the end of the re-ripping process. I've found a couple of my master disc images where I used the exact same version of MAC that I'm using in the re-ripping.

I'm wondering if it's possible to do a comparison between the original (corrupt) file and the new (working) file to see what the differences are. Perhaps that can lead to either a more robust error-correction for MAC, or give me a hint as to what caused my problems in the first place.

Any ideas?
Brad

To compare files, you can use "comp" at a command prompt.  Otherwise, Total Commander has a nice graphical compare feature built in. ( http://www.ghisler.com/ )

Let us know what you find.

[hit_ny]

Or use EAC, i think its got an audio file compare.

Note to King.

i mixed up my RAID definitions...your RAID 1 is fine, its RAID-0 thats the risky one.