LAME 3.96 and newer have a serious bug in the newer vbr routine (aka vbr-new, vbr-mtrh). please don't use it for archiving purposes. a bug fix is coming soon.
the bug results not always in crashes.

...but also results in [insert here]?

the bug is fixed in 3.97 alpha2

Guys, LAME gurus and MP3 heads: I am running EAC 0.9pb5 with LAME 3.96 and getting a lot of skipped compressions. I have not had this problem before. The original WAV file exists after the subdirectory is partially compressed. It seems to happen with operas and classical concerts mostly, but that could also be because that is what I am now doing.

Question: is anyone else having WAV files not compressed on a rip???

boojum, if you expect some help, it would be nice to give more detail on what exactly you are doing: parameters used, dll or exe, etc.
if you call lame manually from the command terminal, does it succeed then?

I am running EAC using LAME 3.96 as an external compressor "--preset standard". I am using the exe file. It fails when called and runs alone. What else do you need to know??

poeple using overclocked computer systems often have problems like you describe. maybe your computer falls into this category. if that's not the case, it would be nice if you can isolate and provide a small (100-200 k bytes) sample where lame does crash on your system.

This is now at Rarewares.

Small sample of what?? There is no MP3, the WAV is as original and there is no ABEND.

well, a small wave file triggering the misbehaviour on your system would be nice to have, so that we can have a look at it and maybe confirm that the problem is with lame and not with your computer.

OK, the computer is an out-of-the-box stock DELL with a PIIII Celeron 2Ghz w/1 meg of memory. No overclocking or anything weird. I will run tests, one with compression running concurrently and another runing compression after the extraction is done and U/L the smallest file not compressed. These are wave files, so they will be large.

So, the question is... will there be a 3.96.1 for those who don't trust alphas/betas?

OK, smallest non-compressed file in either test if a 25 second recitativo of 4 574 684 bytes

How do I upload the file??

those who don't trust alphas and betas will have to wait untill the next stable labled version. if this version will come out the release date will be as usual: when it's ready

boojum:

if it isn't already flac compressed, please use flac.

do you have some webspace anywhere?
if not, you can try to email me:
robert at users dot sourceforge dot net

There is a small bug in the latest version of EAC, which occurs if the absolute path of the files is very long. Perhaps you should generate the files in a directory with a shorter absolute path. It should already solve your problem.
BTW: older versions of EAC also had a limit in the length of absolute file paths, when using an external encoder, but in the latest version it somehow got smaller ...

HTH, jenz

so what does the bug exactly do? I'll still use LAME 3.96 though, because --preset standard doesn't use anything of this

3.96 encoded way too high in that mode. Can't remember but I believe it was on "preset 112" --> Lame always created fiiles with an average of ~190

???

What does the bug do ???

I encoded lots of wavs with 3.96 and --preset extreme --vbr-new -q 0
and it sounds all fine to me.

Possible corruption of Data

So, if someone wants to use --vbr-new, should he use 3.97 alpha 2, which corrects the bug, even if it's alpha?

How can I "see" if an Mp3 ist corrupted by this bug ?
Are there audible "artifacts" ?
This Question is important for me because I used Lame 3.96 --vbr-new for archiving purposes during the last few months.
I feel really bad about this bug. Maybe I should encode it all again ?

Unfortunately you can not.

Excuse me again.
If I can`t see it I can hear it ?
Does it make any strange noises ?

Shingetsu you can't be sure the bug did not bite you. Well, you can be sure it bite you once if you have a mp3 that was not complete encoded because lame crashed. But if you don't hear anything wrong in your mp3s, then there is no need to reencode. mp3s are lossy anyway.

Gabriel, I reported it here: http://www.hydrogenaudio.org/forums/index....5&&#entry214542

"preset 112" gives you files around 112 kbps (abr). So how the heck can you get files around 190 kbps?? That sounds more like something's screwed up with the bit rate display.

Erm, did you test it with the command line I reported?
I'm using Foobar and I think it calculates the average bitrate correctly as its not a ms media crapper. I could also see it in the encoding dos window.

Your command line doesn't make any sense to me. You seem to mix abr and vbr in the same command line, just like mentioned in the earlier thread.

Yes, this has already been cleared up. Even if the command line was senseless, why did lame encode at that high bitrates?

The question is, if with a command line that makes sense lame3.96 encodes properly at the expected low bitrate. Maybe a cmdline like

--V 6 -b 80 --vbr-mtrh --athaa-sensitivity 1 -q 1

But we should stop arguing about that. Makes no sense and theres no need to test as I know it works as expected in latest alpha