Greetings,

my PC recently had a problem with a broken RAM module which caused major data corruption on my HD (Argh, quick boot option in BIOS is a sin!). Among other files, several mp3s were affected so that mpeg errors were (in some cases) audible. Actually that was the way I noticed something was wrong with my PC: I've heard the typical glitches in a fresh encoded file.

So, now with a replaced RAM module I am about to re-encode my music collection, because I don't know any 100% accurate way to tell if a mp3 was corrupted or not. Thus, with an eye on the possibility of future data damage, I'm curious to know if using the -p option with lame is a good idea, or if maybe this code is broken (I've read about bad CRC implementations on this forum). The version of lame I use is 3.90.3.

Here are some questions now:

1. Is adding CRCs to mp3s in any way a "bad idea"?

2. Is there a secure, accurate and comfortable way to check mp3, mp2, mpc or <add any other format> which have no crc?

3. Which is the program of choice to check a huge amount of CRCed mp3s without listening to them? (I know a lot of players check the crc... but that's a slow way of checking your whole collection)

4. Are bit errors in mp3s always audible?


P.S.: I dealt with the idea of creating a md5 or crc or whatever database of all my files, but in the end it's not an option for me since I usually like to rename files quite often.

It gives minor loss in quality... some quality is sacrificed to make room for the crc for every frame.


For MPC there's MPCscan.

For MP3 there's mp3check and EncSpot. Not sure how accurate/secure those are to find bitstream errors though...

All the lossless formats (usually) have a builtin checksum.

You can use Frontah with Verify to check errors in mp3,mpc,ogg,ape,flac,optimfrog,wavpack.
But you'll need mp3check, mpcscan, vorbis-tools and the commandline version of the decoder for all other formats you want to check.


"Depends."

If the music is loud and already clipped (=poorly mastered) then you're less likely to hear any bit errors...

-p is not a real CRC solution. It only covers a portion of the file and occupies 16 bits per frame that could otherwise be used for encoding. Also, it was intended for streaming, at least i wouldn't know how to check your MP3s without decoding each frame. SFV or MD5 seems more practicable to me, even if you rename a lot. You can make multiple checksum files, for small groups of files.

In my opinion it's not the job of a codec to ensure data integrity. This is better done using MD5 sums, SmartPAR or QuickSFV, this way you have all verification info in a single file.

This way also, verification is faster and is done on the whole file (not just the mp3 audio frames).

Ok thanks so far.

I instantly checked out mp3check and was surprised to see an old "friend" again. Back in my Linux days, I used this program quite a lot (together with lame ) but I forgot about it, since I switched back to 98se/XP. Tho it seems to me that this prog didn't change that much. Still it assumes 128kbit, jointstereo, crc, etc. as "normal". And the only tag it recognises is ID3v1. APE and ID3v2 are "junk" and give an error. Also is only checks for CRC inconsistency and corrupt headers. A mp3 with an audible glitch will get through the test without being recognised as corrupt, so this prog is of no use for me, sorry.

As for lame's CRC option, I'm now sure I won't use it, tho the files only get sligthly bigger and the fewer bits for the audio won't result in much quality loss audible to me. But since a mp3 not only consists of the audio frames which seem to be the only part to be checked by the -p option, I will give the sfv program a try, also because DC++ uses this to verify downloaded files.