I'm not sure how many of you are using the 3.93 alphas, but I spent a little bit of time with the new alpha (first time in a long while), and the bitrates for my testcases are way off.. some by 30kbps. I'm not sure what is causing this, but until I find out exactly where the changes have come from and can get them under control, I recommend that everyone stay away from this alpha.

Of course.. it should be common sense that an alpha shouldn't be used for everyday encoding, but I just thought I'd bring this up in case some were unaware.

Unfortunately some recent beta versions of CDex 1.5 included 3.93 alpha .dll as the default MP3 internal encoder. This has been corrected now but I haven't seen a warning posted about this. It isn't mentioned in the change log on the website !!

Haven't checked in alt.music.mp3 lately but if there's nothing about this problem I'll post a warning.

ß

It seems the problem was caused by Robert's this change on 2002/05/20 18:22:00

http://cvs.sourceforge.net/cgi-bin/viewcvs...118&sortby=date

I don't know what he thought and why he changed it.
anyway, FYI.

I'm making this thread sticky until the issue is resolved, just so that everyone knows not to use 3.93 if they are planning on using the --alt-presets. However, it seems as though all of VBR is affected, so I'd just generally stay away from 3.93 altogether for now.

I just reverted this change on my tree. It seems OK for me.
Could someone double check it ? you can get my tree(takehiro-2002_05_07-experimental) by

cvs co -r takehiro-2002_05_07-experimental lame

It seems that Robert just commited the fix into the main branch

Now that this problem is fixed, I think that it would help if some of you could try playing with 3.93 in order to test it.

Seems that Dib is very busy, but I'll try to do some testing.

Btw. hopefully you guys can combine Tak's CVS branch soon to the official...

Yes, Dibrom seems quite busy.

But I hope that there are more people than you, Dib and me interested in this...

Ok, did some very quick preliminary testing. So far I didn't encounter any quality problems with Lame 3.93a2 (I tested Sep 7 build ) compared to 3.92. Quality seemed quite similar (I didn't do tests which I prefer more).

I tested the basic test clips like: castanets,death2,hihat,horn,serioustrouble,gekkou-intro, track01b, and some music trakcs.

Bitrate and bitrate distribution seems to be indeed different. Especially with --vbr-mtrh (fast) the bitrate/distribution difference can be quite wild with some clips.

Lame 3.92 --alt-preset fast standard death2.wav

Lame 3.93a2 (Sep 7) --alt-preset fast standard death2.wav

--vbr-old gave almost the same bitrates for 3.92 and 3.93a with death2.wav though.

Still more testing needs to be done, until nothing certain can be said.. And I didnt test vbr-mtrh (fast) yet much at all except for the above distribution charts...
But at least the "old" horrible quality bugs of 3.93a seem to be gone. Also the bitrate distribution seems to go towards higher bitrates than in 3.92, at least I didn't encounter a track yet which would fall clearly lower than 3.92. Lame393a seems to give much more 320kbps frames with --alt-preset standard.

Of course, I'm sure there will be pretty many complainings about 3.93 --alt-preset bitrates, if nothing is done regarding it before the beta release..

While I suppose erring on the high-bitrate side is better than erring on the low-bitrate side, that histogram you pasted looks an awful lot like it's bloating (thus the almost exclusive 320kbps frames), which probably means something internally is messing up fairy badly.

due to a bug fix in the newer vbr code Dibrom will have to retune his "fast" setting.

So 3.93 status for presets:

*regular presets (standard/extreme) are fine

*fast presets need so work

OK, the last thing we should (?) fix is --preset fast standard, but the difference is smaller.

This is my test result, with lame 3.92 and the latest lame3.93(2002-10-05).

except DEATH2.wav with --preset fast standard, I think they are ok.

And I did one more test including my branch, after added it one more "block switching tweak".

only fast-standard results.


The bitrate is reduced for most of samples. For "vangelis1" and "awe32" which are known as "weak point of aps", it is increased.

And testing with my poor ears, I say LAME of my branch can handle these samples. But, I am sorry to say that it needs more heavy test for fatboy.wav and so on.

weeee! my sample file tested there! B)

It seems that this release (and takehiro's branch as well) will be another great one :·)