LOOK AT THE 6TH REPLY TO FIND OUT ABOUT YAYA BUG

I have crashed into a problem with lame.exe (v3.93.1 - 196 608 bytes). I use Oggifier to convert my big pile of mp3s to Ogg Vorbis. Oggifier uses lame.exe to interpret mp3 information.

Some mp3s crash lame.exe. I did not upload an example, maybe later.

The other mp3s become 2 times faster! Meaning you input a normal song, and lame.exe reads it so, that the output sounds, like it's been performed by Mickey Mouse or some other gay-voice character. That kind of mp3 I got here: 3,25 Mb Song

You will have to rename the extension to mp3 after downloading.

So, who of you guys know, when this mess is expected to be fixed?

Convert the mp3s to wav with Foobar2000, MAD, or Winamp. Then feed the wav files into oggifier.

Thanks for the advice, but converting is not a problem for me. I have ways to convert. The Fraunhofer decoder, implemented in Cool Edit Pro, never refused to read mp3 files correctly.

The point is, that when I convert, for example, 700 mp3s in one go, there is a way to find out, which of them crashed lame.exe (the Ogg Vorbis output will be several kilobytes long), but it is very hard to find out, which mp3s got messed with the "goofy cartoon" bug. The size won't be small. So to determine that I gotta go through the whole collection making an acoustic test, listening to each file with my ears.

I have just made a test, in which the 3.25 Mb Song got decoded to wav with lame.exe. Everything went smooth. So I don't know, or let's just say, I don't feel like digging in the details, what function of lame.exe disfunctions during the direct mp3 to ogg convertion process, if I can ask it. Any guesses, people?

Sounds like the mp3s that failed are 22 kHz? That would explain why they are "2 times faster".

I hope you know that transcoding mp3 -> ogg is not going to improve quality, but only make it worse!

The original:

3.25 Mb mp3 file -- 128kbit (CBR), 44100Hz Mono, 3:33

After converting the file to ogg with -q3 parameter it becomes:

1,35 MB ogg file -- 106kbit (VBR), 44100Hz Stereo, 1:46

If you're using Oggifier with lame.exe and oggenc.exe, the output from lame is being piped into oggenc. Since oggenc is, therefore, receiving input via stdin, it is assumed to be RAW input. By default, RAW input is treated as 44.1kHz, 16 bit stereo, and anything else requires parameters specifying otherwise. Your mono input is consequently being encoded as though it were stereo!! Should sound quite interesting!!

So, it's not a lame bug, you're just not specifying the input correctly for oggenc.

Edit: Actually, that is not strictly correct!! Oggifier specifies the lame decode not to write the Wave Header on output to stdout. This is because the Wave Header specifies the file length and this gets added to the intially written header after the decode has completed. When writing to stdout, this is not really very sensible. Since the decoded stream from lame is written without a header, the input to oggenc must be specified as RAW and the defaults mentioned above, apply. But, it's still not a bug!!

bitstream problem: resyncing...
bitstream problem: resyncing...
Error: number of channels has changed in MP3 file - not supported
bitstream problem: resyncing...
Error: number of channels has changed in MP3 file - not supported
bitstream problem: resyncing...
Error: number of channels has changed in MP3 file - not supported
fatal error. MAXFRAMESIZE not large enough.
Error: number of channels has changed in MP3 file - not supported

That is something lame.exe desperately writes, when decoding "incorrect" mp3 file.

Lame thinks, that variable frequencies grab him by the balls.
But the true problem is in the tags! The mp3 is tagged in a way that crashes Lame.
I give you an example: Svinopass.mp3 (16 kb)

Try this command: lame.exe --decode Svinopass.mp3 Svinopass.wav
You will get a corrupted wave file. So how does it happen? I can tell you. There were at least 20 cases, when this problem occured with different mp3s on my computer. Svinopass.mp3 is first one I decided to test. I trimed it (so you could download it quicker) and got rid of the tags, that have no power to screw Lame.

The tag that fools Lame into thinking there is something wrong with mp3 is the two identical letters from the very end of the Russian alphabet - they are pronounced "ya-ya". To crash Lame, they should be in any of the ID3v2 fields. In ASCII code it's represented by FF FF. The combination of those two letters is used to end many of the Russian adjectives. So, one "ya" cannot break Lame. But 2 "ya's" is a weapon of mass destruction! And it has to be fixed in Lame 3.93.2!


P.S. Why can't I use BBcode or HTML in the signature area? I close all tags and still I get the code displayed instead of what it is supposed to be interpreted into!

If I recall, isn't it recommended to avoid using ID3V2 tags?