Hi. Sorry if someone has answered this before but I've had a pretty good look and can't seem to find an answer.

I've got a whole load of MP3s from over the years and I've dumped them off various discs, external drives etc all into one location so I can finally get round to sifting through dupes, tagging them etc.

One thing I really want to do with them is check them all for any errors. I've tried a few programs and they seemed to be working fine but being the paranoid individual that I am I thought I'd check to see if they were actually working as I wanted. I took a perfectly good MP3 that I'd made myself and altered one byte about half way in using a hex editor. Tested it and it came up as "fine".

If I examine the Lame header I see the following:

Music CRC: 9AD3
Actual Music CRC: 3FDF

So, it's pretty obvious that it's NOT "fine" but all the MP3 checking programs I've used clearly aren't looking here when determining whether a file is corrupt etc, they mainly seem to go on file length or that sort of thing.

Is there any program or method that I can use which will either check all these CRCs automatically or at least export them in one go so I can whack them into a spreadsheet or something? I've been looking and I can't seem to find anything that'll do this.

The programs I've tried:
EncSpot
Audio Identifier
MP3Test
MP3-check
MP3val

I've possibly even tried a few other programs but I grabbed a load and just installed/uninstalled and deleted anything that didn't do what I wanted.

Like I said, sorry if this has been answered elsewhere but I'm probably just being stupid in not seeing where!

as far as i know one 16 bit crc covers one frame.
so i suppose there are lots of sums in there.
are you sure that you compared the right sum?

i'm not sure what to think about those inbuild 16 bit sum...
is every frame coverd with such a sum?

Including the crc in every frame is optional, and by default Lame does not include it. As I understand it, its main application is streaming audio, where you need to know on-the-fly whether you have correct data or not. It is generally not used when you have access to the entire file because there are much better ways to determine if the data are corrupt or not.

Agree. Rather than just checking for errors, why not take the extra step and protect them with ECC? That way if you end up with a corrupt MP3 you can restore them.

QuickPar comes to mind

The annoying thing with general options (be it checksums with sfv's or parity blocks with quickpar) is that they work on the entire file, not just the audiostream. I'm in the (possibly bad ) habbit of changing tag-schemes every now and then, and then you have mismatches although the audio is fine. That's why I like FLAC's integrated checksums so much.

I once thought of a general way to do this checksumming only on the audio part and it wouldnt be very difficult. Just decode the files, and checksum the decoded stream, and check against a stored checksum for accuracy. Havn't gotten around to writing such a script yet.

The ideal solution would be for any encoder to reserve bits for correction, just like CD's have (don't they?).

Could it be that bad if LAME actually integrated some sort of MD5 or SHA1 hash in headers of a file which will not be affected by tagging?