Official LAME v3.98 Beta 7 is out on April 6 2008:

• Robert Hegemann:
  • libmp3lame API: allow frontends to separately retrieve LAME/Xing and ID3 data, because the old library automatism makes it impossible to make fully buffered encodes.
  • libmp3lame API: added some experimental unicode ID3 tagging code.
  • frontends: write itself final ID3 tags and LAME/Xing header frame
  • lame_enc.dll: writes itself final LAME/Xing header frame
  • Latest changes to the new VBR psymodel:
    • uses a different spreading function
    • bug-fix for out-of-bounds array access (program stack corruption possible)

Homepage - www.mp3dev.org

Sources - sourceforge.net

Changelog - history.html

Win32 - rarewares.org

LAME 3.98 stable not yet released, the currently recommended LAME version is - 3.97

CVS - cvs.sourceforge.net

Has this been addressed?
http://www.hydrogenaudio.org/forums/index....st&p=537861

I realise it's in the listening rather than the average kbps, but there seems to have been some pretty large changes, as the difference between encodes with this and beta 6 are in the 20kbps below range.

at -V 2 --vbr-new, I should add.

It's 2008, not 2007. Might want to correct that to avoid confusion.

I'm finding similar reductions in output filesize with some source material as wootabega but at -V3, VBR-new.

Looking at my output files with EncSpot reveals that, although the average bitrate has decreased to around 165Kbps, the occurrence of blocks toward the higher bitrates, especially at 320Kbps, has increased. I've only tested this with 5 albums so far, so I can't draw any broad-sweeping conclusions from this as yet. As -V3 is perceptually transparent to me and has been for some time, I can't say with any degree of certainty whether the files created with this new Beta sound any better than those created with the last one. I'll leave that for the 'golden ears' members to thrash out between themselves.

I'd like to take this opportunity to thank whoever is putting so much effort into all of this development work. Sorry for not knowing your name(s), but you know who you are.

Cheers, Slipstreem.

Could you avoid using direct links please as these change, and this one has!! Better to link to the page: http://www.rarewares.org/mp3-lame-bundle.php

wootabega, Slipstreem may be you already know, but since 3.98 "--vbr-new" is default when using "-V x" (unless you add --vbr-old)

Jebus, john33 fixed

That's "since", not science, right?

Thanks for the info. I was wondering about it also (I don't use command-line encoders).

Hey john33/others- anyone know why LameDropXPd defaults to Encoding Engine Quality of "Standard", not "Fast"- is there any reason for it?

- Spike

For "Encoding Engine" - because 'Fast' is worse than 'Standard'. It is '-f' switch, not '--preset fast'

...But, "Variable Bitrate Mode" setting is also 'Standard'.

Has anybody tested this release enough to recommend it over 3.97 yet?

I am probably being a little hasty!

I don't know whether this count as a serious test or not, but I was up half the night re-encoding a UK Sci-Fi radio series (almost 15 hours worth) which I'd originally encoded with 3.97 Final in VBR at -V6 to fit onto one CD-R for listening to in the car.

With 3.97 Final, it came out at 717MB and made very rare usage of the 320Kbps rate according to EncSpot.

With 3.98 Beta7, -V6 was clearly going to overshoot my desired total encoding size by around 10% so it would appear that we now have an increased average bitrate in the lower -V settings although mine and wootabega's tests earlier showed a slight under-shoot at the -V2 and -V3 levels.

I started the encoding process again, but this time at -V7. The total encoding size for the whole exercise now came out at 711MB vs the 717MB at -V6 with LAME 3.97.

Once again, more frequent use was made of the 320Kbps rate. There is a distinct peak at 112Kbps with the distribution of the remaining blocks being biased more heavily toward the high end of the graph than with 3.97 Final.

According to EncSpot, the upper cut-off frequency was 15kHz with 3.97 Final at -V6 and was 14.5kHz with 3.98 Beta7 at -V7.

Although I haven't carried out any proper ABX comparisons, voices definitely sound slightly less granular to me personally with -V7 with 3.98 Beta7 than at -V6 with 3.97 Final.

For what it's worth, this new Beta gets a big thumb's-up from me personally for low bitrate VBR encoding.

Cheers, Slipstreem.

EDIT: I forgot to mention that the new Beta makes much more use of SS during stereo encoding than 3.97 Final which tended to be much more heavily biased toward MS than SS according to this test. This may just be a trait of 3.98 in general as I'd never taken much notice before.

I just did an ABX test with the Children sample posted here:
Children Sample

To my ears this sample with LAME 3.98b7 -V 2 --vbr-new sounds much worse than with LAME 3.97 -V 2 --vbr-new

ABX logs:
ABX LAME 3.97 -V 2 --vbr-new vs. LAME 3.98b7 -V 2 --vbr-new


ABX original vs. LAME 3.98b7 -V 2 --vbr-new

Wow, those ABX results seem pretty conclusive...
Thanks for the replies, the bit rate differences appear to be inconsistent don't they (i.e. lower at V2 but higher at V6)

I suppose this doesn't matter too much since it is what it sounds like which is the real test!

About bitrates... I tested LAME 3.98 beta7, beta6 and beta7 with added '-Z 2' option. Average bitrate is in the table below (my test file set consists of 18 tracks).



'beta6' and 'beta7 -Z2' differ only at V6 and V7 settings. And beta7 is bigger than beta6 only at -V6.

What is the -Z2 option?

One of latest changes before releasing beta7 was:
"some simpler spreading function for VBR NEW" (http://lame.cvs.sourceforge.net/lame/lame/...me/?sortby=date).
-Z option changes this behavior: -Z1 forces new 'simpler' spreading function and -Z2 -- older one.

Very informative. Thanks.

Cheers, Slipstreem.

I just finished testing 'my' usual problem samples using -V3. I decided to add castanets because I wanted to have a pre-echo prone sample of natural music and not just eig.
I used -V3 because I am not much used any more to ABXing these ugly mp3 samples.

I started with eig, and one of the impulses (at ~ sec. 2.8) is smeared pretty much.
I'm not very sensitive to pre-echoes from natural instruments, so I was surprised I could abx castanets pretty easily 10/10.
Birds was ok to me.
harp40_1 was easily abxable as was expected.
I did not expect I was also able to pretty easily abx herding_calls 10/10.
The tremolo of lead_voice was pretty ugly to me - but more or less expected.
trumpet however was pretty bad again which came as a surprise.
The tremolo of trumpet_myPrince was pretty audible too.

I started abxing -V0, but castanets, eig, harp40_1 and herding_calls were so clearly below my expectations (though a lot better than the -V3 results) that I stopped. I was so happy with the results from the December edition of 3.98b6 that I'm rather disappointed with this version .

Thanks for the info Halb.

If you have time it would be really interesting to see what results you get using the "-Z2" switch as explained above. I've got a suspicion that it might be that new "speading function" that's making beta7 perform worse than beta6.

Ok, I'll try -Z2 within the next days.

AFAIK, beta7 with -Z2 should be almost identical beta6 (except vbr V6, V7). And: with latest changes in CVS -- old spreading function is default again.

LAME also enables floating point value for -V option. Here is graph of bitrate vs V value for some song (thin line represents encoding with -Y option added).

It appears as of a couple of minutes ago there is an option for -Z3. Any idea as to what this option is? I'm trying to read the code, but since my knowledge of the code is infinitesimal at best; perhaps someone could provide insight?

I'd try to compile myself, but I honestly couldn't figure out how to utilize the -Z parameter in foobar, as it continually spit out the same file with or without the parameter set. Any assistance on this would be greatly appreciated.

-Z = Experimental !

I think its disabled in normal builds.

Couldn't agree more. And since new (disputable) spreading function was disabled by default... It's useless to test parts of lame encoder that are subject to change.

Yes, it's disabled. I just encoded my test set with and without -Z2 and the results are identical as was expected now.

Sadly there is something wrong with compiling on PPC. I often compiled Lame on my iMac G5 with

./configure
make
sudo make install

and this also works with Beta7 without compiling errors, but when I encode music with Beta7 then the resulting file is just noise (no matter if I use wav or aiff as input files).

Is there any hidden option for us PPC users that we have to activate?

Current version of lame frontend is broken on big-endian environments. Apply this diff:

Thanks a lot Nao, the patch works perfectly

The latest CVS changes in get_audio.c do not fix the problem because
1) variable in_endian is always zero unless --big-endian option is used
2) variable hi_lo_order passed to function unpack_read_samples should contain the endianness of the input file regardless of the machine byte order

So, the machine byte order detection in function read_samples_pcm is not required and simply the change above fixes the problem.

P.S. Compile time detection works correctly on ppc machine.

What about the new v3.98 Beta 8 at ComputerBase?
Is it official?

http://sourceforge.net/project/showfiles.php?group_id=290
LAME 3.98 beta 8 features some major new feature: VBR quality setting can now be any floating point value from 0 to 9.999. This allows finer quality/bitrate control.