test.mp3 is 128 kbps with ID3v2 where every field (Artist,Title,...) is in unicode.
The unicoded field starts with byteorder-mark (0xFFFE) which I believe is mistaken for a valid mp3 frame.
This is what LAME --decode test.mp3 outputs:
Input file is freeformat.
input: test.mp3 (44.1 kHz, 2 channels, MPEG-1 Layer III)
output: test.mp3.wav (16 bit, Microsoft WAVE)
skipping initial 1105 samples (encoder+decoder delay)
Frame# 2/11184810 320 kbps bitstream problem: resyncing...
Frame# 3/11184810 162 kbps L R ibitstream problem: resyncing...
Error: number of channels has changed in MP3 file - not supported
Frame# 4/11184810 353 kbps bitstream problem: resyncing...
Error: number of channels has changed in MP3 file - not supported
Frame# 5/11184810 158 kbps bitstream problem: resyncing...
Error: number of channels has changed in MP3 file - not supported
Frame# 6/11184810 386 kbps bitstream problem: resyncing...
Error: sample frequency has changed in MP3 file - not supported
Frame# 7/11184810 420 kbps L R bitstream problem: resyncing...
Error: sample frequency has changed in MP3 file - not supported
Frame# 8/11184810 96 kbps L R ibitstream problem: resyncing...
Error: sample frequency has changed in MP3 file - not supported
:
:
:
By Removing the ID3v2 (via WinAmp) results in:
input: test.mp3 (44.1 kHz, 2 channels, MPEG-1 Layer III)
output: test.mp3.wav (16 bit, Microsoft WAVE)
skipping initial 1105 samples (encoder+decoder delay)
Frame# 2266/2266 128 kbps MS
Also, the problem goes away when the ID3v2 is saved with 'unsynchronisation' (every 0xFFFE is replaced with 0xFF00FE).
A good solution to this would be if LAME skipped ID3v2 when decoding.