Skip to main content
Topic: LAME v3.98 Beta 7 (Read 24332 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME v3.98 Beta 7

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


LAME v3.98 Beta 7

Reply #2
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.

LAME v3.98 Beta 7

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

LAME v3.98 Beta 7

Reply #4
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. 


LAME v3.98 Beta 7

Reply #6
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

LAME v3.98 Beta 7

Reply #7
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

LAME v3.98 Beta 7

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

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

LAME v3.98 Beta 7

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

I am probably being a little hasty! 

LAME v3.98 Beta 7

Reply #10
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.

LAME v3.98 Beta 7

Reply #11
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
Code: [Select]
foo_abx 1.3.1 report
foobar2000 v0.9.4.4
2008/04/08 00:31:31

File A: E:\Children 397 (edit).mp3
File B: E:\Children 398b7 (edit).mp3

00:31:31 : Test started.
00:31:55 : 01/01  50.0%
00:32:10 : 02/02  25.0%
00:32:20 : 03/03  12.5%
00:32:33 : 04/04  6.3%
00:32:40 : 05/05  3.1%
00:32:54 : 06/06  1.6%
00:33:05 : 07/07  0.8%
00:33:19 : 08/08  0.4%
00:33:24 : 09/09  0.2%
00:33:33 : 10/10  0.1%
00:33:43 : 11/11  0.0%
00:33:44 : Test finished.

----------
Total: 11/11 (0.0%)


ABX original vs. LAME 3.98b7 -V 2 --vbr-new
Code: [Select]
foo_abx 1.3.1 report
foobar2000 v0.9.4.4
2008/04/08 00:15:19

File A: E:\Children (edit).wav
File B: E:\Children 398b7 (edit).mp3

00:15:19 : Test started.
00:15:47 : 01/01  50.0%
00:16:16 : 02/02  25.0%
00:16:26 : 03/03  12.5%
00:16:31 : 04/04  6.3%
00:16:38 : 05/05  3.1%
00:16:56 : 06/06  1.6%
00:17:08 : 07/07  0.8%
00:17:20 : 08/08  0.4%
00:17:32 : 09/09  0.2%
00:17:49 : 10/10  0.1%
00:18:02 : 11/11  0.0%
00:18:11 : 12/12  0.0%
00:18:21 : Test finished.

----------
Total: 12/12 (0.0%)

LAME v3.98 Beta 7

Reply #12
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!

LAME v3.98 Beta 7

Reply #13
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).

Code: [Select]
           beta7        beta6        beta7 -Z2
                                    
-V0        248.4        259.0        259.0
-V1        218.4        227.5        227.5
-V2        195.4        205.1        205.1
-V3        163.8        167.6        167.6
-V4        149.7        153.6        153.6
-V5        134.6        138.4        138.4
-V6        123.5        122.0       _127.0_
-V7        103.1        105.4       _106.9_
-V8         86.8         89.7         89.7
-V9         66.1         68.0         68.0
                                    
-V0 -Y     216.0        219.5        219.5
-V1 -Y     192.9        196.6        196.6
-V2 -Y     176.8        180.6        180.6


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

LAME v3.98 Beta 7

Reply #14
What is the -Z2 option?


LAME v3.98 Beta 7

Reply #16
Very informative. Thanks.

Cheers, Slipstreem. 

LAME v3.98 Beta 7

Reply #17
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 .
lame3995o -Q1.7
opus --bitrate 140

LAME v3.98 Beta 7

Reply #18
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.

LAME v3.98 Beta 7

Reply #19
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.
lame3995o -Q1.7
opus --bitrate 140

 

LAME v3.98 Beta 7

Reply #20

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).

LAME v3.98 Beta 7

Reply #21
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.

LAME v3.98 Beta 7

Reply #22
-Z = Experimental !

I think its disabled in normal builds.
wavpack 4.8 -b256hx6c

LAME v3.98 Beta 7

Reply #23
-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.

LAME v3.98 Beta 7

Reply #24
Yes, it's disabled. I just encoded my test set with and without -Z2 and the results are identical as was expected now.
lame3995o -Q1.7
opus --bitrate 140

 
SimplePortal 1.0.0 RC1 © 2008-2020