Skip to main content

Topic: Lame3.99.5y (Read 16793 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • halb27
  • [*][*][*][*][*]
Lame3.99.5y
You can download it from here.

What’s the functional extension?

It offers a VBR quality setting -V0+.

-V0+ is -V0 with extra properties. These properties can improve upon difficult-to-encode spots in the music like temporal smearing issues as with problem sample eig or with tremolo problem isues as with problem sample lead-voice. eig and lead-voice are fine to me when using -V0+.

How is it done?

-V0+ uses a strategy which is targeting at providing maximum possible audio data space for hard-to-encode spots in the music. -V0+ increases the accuracy demands for spots in the music with detected impulses, and it has a general demand for audio data bitrate to stay rather high.

What’s the price to pay?

Average bitrate goes up a little bit. For my standard test set of various pop music average bitrate is 256 kbps with -V0+, whereas -V0 takes 252 kbps.
Moreover, in order to prevent another 10 kbps increase in average bitrate, the fast and lossless mp3packer procedure is recommended to be called for the produced mp3 file. Used with a bat file invoked from the explorer’s folder context menu this is comfortably done for the mp3 files of an entire folder.
The 10 kbps bitrate bloat is a consequence of the strategy for providing maximum possible data space. For doing so a 17.5 kHz lowpass is also used internally. If you don’t like that use a lowpass according to your likings. But even if you are able to distinguish higher frequencies in an isolated listening test, this doesn’t mean you can take profit of that with real life music. Not talking about the fact that the musical contents of higher frequncies is next to nothing.
  • Last Edit: 18 March, 2012, 06:37:12 AM by halb27
lame3995o -Q1

  • halb27
  • [*][*][*][*][*]
Lame3.99.5y
Reply #1
Some remarks about ‘why a new variant after 3.99.5x was recently released?’.
I’m sorry to have to do that, and I certainly should have spent more time doing all this with 3.99.5x.

After finishing 3.99.5x I spent a lot of time with the remaining obvious issue among ‘my’ problem samples: the problem at sec. 2,82 of eig.
I ended up giving very high accuracy demands to short blocks (used when impulses are detected in the music). I also searched for improvement in providing as much data space as possible for hard-to-encode spots like impulses, and lowered a corresponding restriction (on the channels of a granule which is used for inaccurate frame handling and occasionally does not make full use of the available space in a frame. I stretched these restrictions to make full use of the available frame data space).
While doing all this I noticed that I had been focussing on avoiding inaccurately encoded frames too much.  This target isn’t so important per se. It’s important to try to provide maximum available data space for difficult spots IMO, and such a strategy tends to avoid inaccurately encoded frames, but the maximum available data space is what counts in the first place.

The properties of the concern for short blocks made me reconsider what -Vx+ levels are really interesting. Lower quality levels of -Vx+ have always been questionable because using a higher quality -Vx is the more natural and more attractive alternative. With the new special concern for short blocks this is even more so: this special concern is expensive except for the highest -Vx+ levels, whereas for -Vx+ levels which internally use -V0 it comes nearly for free.

During my listening tests I became tired of testing problem samples like ‘herding_calls’. I am able to ABX them using -V0, but it is hard to do so. With practical listening without reference to the original their tiny issue would go unnoticed. I decided not to care about them any more. For tremolo problem samples like ‘trumpet_myPrince’ I optimized the minimum audio data bitrate demands in such a way that the remaining issue is similarly unimportant.

As a consequence I ended up with just one -Vx+ level, -V0+.
  • Last Edit: 18 March, 2012, 06:28:51 AM by halb27
lame3995o -Q1

  • GeSomeone
  • [*][*][*][*][*]
Lame3.99.5y
Reply #2
As a consequence I ended up with just one -Vx+ level, -V0+.

I understand that you're mainly interested in V0+ but wouldn't the extra focus on impulses help the other levels like -V1+ or even -V1.5+ ?
In theory, there is no difference between theory and practice. In practice there is.

  • halb27
  • [*][*][*][*][*]
Lame3.99.5y
Reply #3
-V0+ is now more or less what was -V1+ before, added the special focus on impulses.
Lower -Vx+ levels than -V1+ didn't use -V0 internally, and my feeling is: the normal -Vx levels should be used in the first place when struggling for better quality.

Anyway: if you want to use a lower -Vx together with the extras of 3.99.5y just tell me what you want to use.
My only restriction is: for transparency reasons I do want for the future -Vx+ to use -Vx internally, and I do not want to have a low or moderate -Vx+ level any more as this really doesn't make sense because the impulse handling is too expensive here.
  • Last Edit: 19 March, 2012, 03:11:52 AM by halb27
lame3995o -Q1

  • ggunnell
  • [*]
Lame3.99.5y
Reply #4
I use dbPoweramp as a Lame front end.  Currently dbPoweramp has a slider that selects the VBR level -- although you can add swiches to the Lame command line you have to start with a -Vx (x=0-9) term that can't be deleted.  Before I request a change to dbPoweramp, can one  get around this by simply adding -Vx+ after the initial 'preloaded' -Vx?  What is the result of a command line -V0 -V0+ ?  Thanks!

  • chi
  • [*]
Lame3.99.5y
Reply #5
…, can one get around this by simply adding -Vx+ after the initial 'preloaded' -Vx?  What is the result of a command line -V0 -V0+ ?


On a short test input,
Code: [Select]
lame -V 0 -V 8
lame -V 8

both result in an output file of 28704 bytes, while
Code: [Select]
lame -V 8 -V 0
lame -V 0

both give a file of 95208 bytes.

So it seems that the last option takes precedence (which is common, and good for your use case).

  • halb27
  • [*][*][*][*][*]
Lame3.99.5y
Reply #6
I can confirm your idea and chi's result.
For two full length tracks I compared the lame3995y -V 0 -V0+ and lame3995y -V0+ results. They were bit-identical.

But AFAIK dbPoweramp has a command line interface. Can't you use that?
lame3995o -Q1

  • ggunnell
  • [*]
Lame3.99.5y
Reply #7
I can confirm your idea and chi's result.
For two full length tracks I compared the lame3995y -V 0 -V0+ and lame3995y -V0+ results. They were bit-identical.
But AFAIK dbPoweramp has a command line interface. Can't you use that?

Thanks, everyone!
dbPoweramp has had a full Lame command line builder available in a separate program, but in respose to user requests, the developer of dbPoweramp included a command line builder in the 'Advanced' button of the latest version of the main program (ver 14.3, files dated 3/22/12) -- with the exception that the Vx value is currently uneditably preloaded via a slider control -- not an issue if, as folks have posted above, the the Lame command line is parsed in order with subsequent terms "overwriting' preceding ones.

I did have an issue getting the program to work when I replaced the lame.exe in the dbPoweramp directory, which I'm sure is my own unfamiliarity with compiling Lame, as the Lame3995y.exe I ended up with is only 323Kb, compared with the 994Kb size of the 3.99.2.5 64-bit version I was using or the 625Kb size of the 3.99.2.4 version I was using before that.

  • halb27
  • [*][*][*][*][*]
Lame3.99.5y
Reply #8
So you compiled both Lame 3.99.5 and 3.99.5y yourself and got such a big difference in file size. That's real strange, and this goes for the file size difference of 3.99.4 and 3.99.5 as well.
323 KB BTW is nearly exactly the size of the 32 bit version I compiled (using MSVC++ 2010 Express).
  • Last Edit: 15 April, 2012, 03:25:04 PM by halb27
lame3995o -Q1

  • ShotCaller
  • [*]
Lame3.99.5y
Reply #9
halb, seeing that -V0+ tends to be in the 300+ kbps range, is there any reason not to use just regular old -b 320 -q 0 (with same lowpass setting)? What one is the best choice for highest quality?

  • ggunnell
  • [*]
Lame3.99.5y
Reply #10
So you compiled both Lame 3.99.5 and 3.99.5y yourself and got such a big difference in file size. That's real strange, and this goes for the file size difference of 3.99.4 and 3.99.5 as well.
323 KB BTW is nearly exactly the size of the 32 bit version I compiled (using MSVC++ 2010 Express).

I did not deliberately compile anything.  The most I ever did was unpack .zip files.  Since I am just a retired music lover I think I will just continue to use the Lame files that are working for me now.  Thanks for your help!

  • halb27
  • [*][*][*][*][*]
Lame3.99.5y
Reply #11
halb, seeing that -V0+ tends to be in the 300+ kbps range, is there any reason not to use just regular old -b 320 -q 0 (with same lowpass setting)? What one is the best choice for highest quality?

3.99.5y -V0+ yields an average bitrate of 256 kbps (266 kbps when not postprocessed by mp3packer) for my usual test set, just a little bit more than -V0 does (252 kbps). Significantly lower than 300 kbps.

An open question is when struggling for best quality no matter the bitrate whether good old CBR 320 or -V0+ yields the overall better quality.
Because of the high quality in either case I guess a widely accepted answer can be provided by people with a good pre-echo sensibility who try both variants on a number of pre-echo samples.
Personal answers can be found by using both variants on those hard-to-encode samples that matter to you. Don't forget to use -V0 too for comparison. If you have never encountered problems that bother you, I wouldn't care at all and use just -V0. After all plain -V0 is great.
  • Last Edit: 16 April, 2012, 02:46:38 AM by halb27
lame3995o -Q1

  • skamp
  • [*][*][*][*][*]
  • Developer
Lame3.99.5y
Reply #12
An open question is when struggling for best quality no matter the bitrate whether good old CBR 320 or -V0+ yields the overall better quality.


I wondered about that. Can "brute force" 320 kbps CBR be bested?
  • Last Edit: 16 April, 2012, 02:47:34 AM by skamp
See my profile for measurements, tools and recommendations.

  • halb27
  • [*][*][*][*][*]
Lame3.99.5y
Reply #13
An open question is when struggling for best quality no matter the bitrate whether good old CBR 320 or -V0+ yields the overall better quality.


I wondered about that. Isn't 320 kbps the highest a standard MP3 can go? Is there some other parameter to MP3 quality?

CBR uses another strategy of producing mp3 data than does VBR.
It was shown already for pre-echo problems that plain -V0 can provide a better quality than CBR 320 does.

My functional extension tries to combine both worlds. It uses the more advanced target-orientation of VBR, while using the defensive orientation of CBR to a significant amount. Moreover it is constructed to provide the best data situation for musical situations where a high amount of data is required. mp3 locally allows for an audio data bitrate roughly 50% higher than 320 kbps, and I try to take good care of this.
  • Last Edit: 16 April, 2012, 03:11:10 AM by halb27
lame3995o -Q1

  • soundping
  • [*][*]
Lame3.99.5y
Reply #14
An open question is when struggling for best quality no matter the bitrate whether good old CBR 320 or -V0+ yields the overall better quality.


I wondered about that. Can "brute force" 320 kbps CBR be bested?

Free format mp3 lame can go up to 640kbps but you're limiting player support.
"The Emperor is not as forgiving as I am"

  • halb27
  • [*][*][*][*][*]
Lame3.99.5y
Reply #15
That's why freeformat isn't of practical use.
lame3995o -Q1

  • naturfreak
  • [*][*][*]
Lame3.99.5y
Reply #16
A simple question to satisfy my curioustiy:

Will this functional extension be part of a future release of a official lame version?

  • halb27
  • [*][*][*][*][*]
Lame3.99.5y
Reply #17
I welcome this, but it's up to the Lame devs.
lame3995o -Q1

  • GeSomeone
  • [*][*][*][*][*]
Lame3.99.5y
Reply #18
3.99.5y -V0+ yields an average bitrate of 256 kbps (266 kbps when not postprocessed by mp3packer) for my usual test set, just a little bit more than -V0 does (252 kbps). Significantly lower than 300 kbps.

When I tried it with a bit more conventional lowpass (like 18600 or 19200) the bit rate quickly went to around 300 where normal (Lame) -V 0 gave about 256 kbps (as you say). It probably was "demanding" music and not a representative test set.
In theory, there is no difference between theory and practice. In practice there is.

  • halb27
  • [*][*][*][*][*]
Lame3.99.5y
Reply #19
Using a higher lowpass frequency has an effect on bitrate, but not to this extent.
Main reason for very high average bitrate is a high percentage of short blocks used. 3.99.5y -V0+ tries to encode them with the maximum accuracy possible.
  • Last Edit: 17 April, 2012, 07:51:26 PM by halb27
lame3995o -Q1

  • IgorC
  • [*][*][*][*][*]
Lame3.99.5y
Reply #20
Main reason for very high average bitrate is a high percentage of short blocks used. 3.99.5y -V0+ tries to encode them with the maximum accuracy possible.

There is no more obvious artefact  than pre-echo is for MP3 at high bitrates (~256 kbps, eig and castanets ). So I'm totally agree that  switching to short blocks is the effective (if not the most effective) remedy.

  • halb27
  • [*][*][*][*][*]
Lame3.99.5y
Reply #21
Big trouble!

I managed to put a premature version into the zip file!
That's why you got at an average bitrate around 300 kbps, GeSomeone.

I'm deeply sorry for this.

The correct version is in the zip file now.

A big thanks to Dynamic whose findings lead to the revelation of the issue (and will lead to a new version because he found that -V n+ is worth while for lower quality settings too).
  • Last Edit: 08 September, 2012, 02:48:21 PM by halb27
lame3995o -Q1

  • goa pride
  • [*][*]
Lame3.99.5y
Reply #22
Big trouble!

I managed to put a premature version into the zip file!
That's why you got at an average bitrate around 300 kbps, GeSomeone.

I'm deeply sorry for this.

The correct version is in the zip file now.

A big thanks to Dynamic whose findings lead to the revelation of the issue (and will lead to a new version because he found that -V n+ is worth while for lower quality settings too).

is this developer version of Lame recommended for electronic music?
Lame 3100a [32bit and 64bit]                           https://bit.ly/1VPTGbO
WinMP3Packer all-in-one [32bit and 64bit]     https://bit.ly/1PAtMS1
MP3Suite.bat customizable [64bit encoders]   https://bit.ly/1ZVOVxx

  • Dynamic
  • [*][*][*][*][*]
Lame3.99.5y
Reply #23
is this developer version of Lame recommended for electronic music?


I guess there's plenty of potential for highly tonal signals and sharp transients to combine in some kinds of electronic music.

This version is probably best reserved for problem cases because it does add quite a lot to the bitrate.

Come to think of it, I should probably try out the Angel Falls guitar picking problem sample this fixes with another encoder like Helix (using the  VBR -X2 -U2 -V60 setting from the 128kbps MP3 listening test where Helix tied with LAME) just to see if it has the same issue. No time tonight, but maybe another time.
  • Last Edit: 09 September, 2012, 05:38:40 PM by Dynamic
Dynamic – the artist formerly known as DickD

  • halb27
  • [*][*][*][*][*]
Lame3.99.5y
Reply #24
is this developer version of Lame recommended for electronic music?

Yes, especially the improved handling of attacks should improve upon the encoding of electronic music.
lame3995o -Q1