Recently, (after upgrading xmms) I’ve noticed that a non-trivial portion of my mp3s have starting skpipping/making weird noises. In addition, the ‘elapsed time’ will jump around, as will the ‘total time’. When I try to play the same mp3s in
mpg123, I get errors like th following:
tekniklr@minips1:~ $ mpg123 Harry_and_the_Potters-Wizard_Chess.mp3
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2 and 3.
Version 0.59s-r7 (2000/Oct/27). Written and copyrights by Michael Hipp.
Uses code from various people. See 'README' for more!
THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK!
Title : Wizard Chess Artist: Harry and the Potters
Album : Harry and the Potters Year : 2003
Comment: www.eskimolabs.com/hp Genre : Unknown
Playing MPEG stream from Harry_and_the_Potters-Wizard_Chess.mp3 ...
MPEG 1.0 layer III, 128 kbit/s, 44100 Hz joint-stereo
Illegal Audio-MPEG-Header 0xfa9260bb at offset 0xa000.
Skipped 417 bytes in input.
Illegal Audio-MPEG-Header 0xfa92605a at offset 0xab6d.
Skipped 417 bytes in input.
This has been happening on both my computers simultaneously, and as I haven’t noticed any widespread mp3 file changes being propagated between the two (via unison), I am left to conclude that these files have always been this way, and my computers have simply recently decided to take issue with them.
I tried downgrading xmms all the way back to 1.2.8 (which I know was behaving properly), but the issues persist. Ironically,
mpg321 seems to play these files, while not perfectly, still much better than either xmms or mpg123.
After doing a bit of googling, I determined that these problems seem to be the result of variable bit rate (VBR) mp3s having malformed headers – telling the mp3 decoder that frames are different sizes than they actually are. I found accounts from other people who seemed to be having the exact same problems when xmms tries to play an affected file.
Let me reiterate the fact that these files (to the best of my knowledge) have not been changed (nor do both of my computers have identical hardware failings). Regardless, on both of my systems most of my mp3 players are suddenly incapable of playing these files through to completion without either skipping or making horrible scratching noises, while just a few weeks ago I was not experiencing any problems.
Now, since I don’t have a good explanation (except possibly that something like
libid3tag got upgraded simultaneously on both systems, and that has some new bug) I decided I’d simply try to ignore the reasons and instead concentrate on fixing the borken files.
First I tried mp3check. For shits and giggles (because the problems I’ve noticed are widespread, and because I can use the aforementioned unison program to revert my changes) I ran the program against my entire playlist with the following command:
mp3check -r --fix-headers --cut-junk-start --cut-junk-end --fix-crc mp3s/Playlist/
and was shocked to see this as an end result (afterseveral minutes and a whole lot of scrollback)
910 files checked, 666 erroneous files found
Repeating the command gave this result:
910 files checked, 665 erroneous files found
Well, crap. At least one file got fixed (nevermind that approximately 66% of my mp3s have issues- a more serious problem then I had thought). If you care, here is what the output of that command looks like for the same file I tried before with
tekniklr@minips1:~ $ mp3check --fix-headers --cut-junk-start --cut-junk-end --fix-crc Harry_and_the_Potters-Wizard_Chess.mp3
cut-junk-start: no junk found
cut-junk-end: valid id3 tag trailer v1.0 found, protecting it
cut-junk-end: no junk found
valid id3 tag trailer v1.0 found
frame 97/ 0:02: frame too short at 0x00009e5e, 1 byte mising
frame 104/ 0:02: frame too short at 0x0000a9cb, 1 byte mising
frame 469/ 0:12: frame too short at 0x0002fdb5, 1 byte mising
frame 733/ 0:19: frame too short at 0x0004acb9, 1 byte mising
frame 988/ 0:25: frame too short at 0x00064d0c, 1 byte mising
frame 1098/ 0:28: frame too short at 0x000700a2, 1 byte mising
frame 2037/ 0:53: frame too short at 0x000cfdb1, 1 byte mising
frame 2085/ 0:54: frame too short at 0x000d4c0e, 1 byte mising
frame 2273/ 0:59: frame too short at 0x000e7efd, 1 byte mising
frame 2861/ 1:14: frame too short at 0x00123efc, 1 byte mising
frame 2997/ 1:18: frame too short at 0x00131d06, 1 byte mising
md5sums tell me that the file is unchanged at the end of the command.
This post is long enough for now, but I’m going to keep trying other programs. I’ve already tried mp3asm with no better luck, and mp3_check is going to be the program I try next. I’ll possibly update later, if/when I have more information or a solution, but if anyone has any related experience, I’d appreciate it if you drop me a note.
Oh, and happy thanksgiving (what’s left of it).