IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
Lame3.99.5y, A 3.99.5 functional extension
halb27
post Mar 18 2012, 11:12
Post #1





Group: Members
Posts: 2428
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



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.

This post has been edited by halb27: Mar 18 2012, 11:37


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
halb27
post Mar 18 2012, 11:13
Post #2





Group: Members
Posts: 2428
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



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

This post has been edited by halb27: Mar 18 2012, 11:28


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
GeSomeone
post Mar 19 2012, 00:22
Post #3





Group: Members
Posts: 921
Joined: 22-October 01
From: the Netherlands
Member No.: 335



QUOTE (halb27 @ Mar 18 2012, 12:13) *
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.
Go to the top of the page
+Quote Post
halb27
post Mar 19 2012, 08:08
Post #4





Group: Members
Posts: 2428
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



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

This post has been edited by halb27: Mar 19 2012, 08:11


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
ggunnell
post Apr 14 2012, 21:25
Post #5





Group: Members
Posts: 5
Joined: 7-April 12
From: Missouri
Member No.: 98510



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!
Go to the top of the page
+Quote Post
chi
post Apr 15 2012, 05:53
Post #6





Group: Members
Posts: 45
Joined: 27-November 11
Member No.: 95439



QUOTE (ggunnell @ Apr 14 2012, 22:25) *
…, 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
lame -V 0 -V 8
lame -V 8

both result in an output file of 28704 bytes, while
CODE
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).
Go to the top of the page
+Quote Post
halb27
post Apr 15 2012, 09:43
Post #7





Group: Members
Posts: 2428
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



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?


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
ggunnell
post Apr 15 2012, 17:15
Post #8





Group: Members
Posts: 5
Joined: 7-April 12
From: Missouri
Member No.: 98510



QUOTE (halb27 @ Apr 15 2012, 03:43) *
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.
Go to the top of the page
+Quote Post
halb27
post Apr 15 2012, 20:20
Post #9





Group: Members
Posts: 2428
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



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

This post has been edited by halb27: Apr 15 2012, 20:25


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
ShotCaller
post Apr 16 2012, 05:40
Post #10





Group: Members
Posts: 34
Joined: 8-August 11
Member No.: 92854



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?
Go to the top of the page
+Quote Post
ggunnell
post Apr 16 2012, 05:57
Post #11





Group: Members
Posts: 5
Joined: 7-April 12
From: Missouri
Member No.: 98510



QUOTE (halb27 @ Apr 15 2012, 14:20) *
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!
Go to the top of the page
+Quote Post
halb27
post Apr 16 2012, 07:31
Post #12





Group: Members
Posts: 2428
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



QUOTE (ShotCaller @ Apr 16 2012, 05:40) *
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.

This post has been edited by halb27: Apr 16 2012, 07:46


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
skamp
post Apr 16 2012, 07:39
Post #13





Group: Developer
Posts: 1430
Joined: 4-May 04
From: France
Member No.: 13875



QUOTE (halb27 @ Apr 16 2012, 08:31) *
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?

This post has been edited by skamp: Apr 16 2012, 07:47


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
halb27
post Apr 16 2012, 07:54
Post #14





Group: Members
Posts: 2428
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



QUOTE (skamp @ Apr 16 2012, 07:39) *
QUOTE (halb27 @ Apr 16 2012, 08:31) *
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.

This post has been edited by halb27: Apr 16 2012, 08:11


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
soundping
post Apr 16 2012, 21:22
Post #15





Group: Members
Posts: 36
Joined: 3-February 12
Member No.: 96900



QUOTE (skamp @ Apr 16 2012, 01:39) *
QUOTE (halb27 @ Apr 16 2012, 08:31) *
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.
Go to the top of the page
+Quote Post
halb27
post Apr 16 2012, 23:08
Post #16





Group: Members
Posts: 2428
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



That's why freeformat isn't of practical use.


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
naturfreak
post Apr 17 2012, 14:06
Post #17





Group: Members
Posts: 176
Joined: 16-October 03
Member No.: 9338



A simple question to satisfy my curioustiy:

Will this functional extension be part of a future release of a official lame version?
Go to the top of the page
+Quote Post
halb27
post Apr 17 2012, 19:28
Post #18





Group: Members
Posts: 2428
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



I welcome this, but it's up to the Lame devs.


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
GeSomeone
post Apr 18 2012, 00:37
Post #19





Group: Members
Posts: 921
Joined: 22-October 01
From: the Netherlands
Member No.: 335



QUOTE (halb27 @ Apr 16 2012, 08:31) *
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.
Go to the top of the page
+Quote Post
halb27
post Apr 18 2012, 00:50
Post #20





Group: Members
Posts: 2428
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



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.

This post has been edited by halb27: Apr 18 2012, 00:51


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
IgorC
post Apr 18 2012, 02:53
Post #21





Group: Members
Posts: 1556
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



QUOTE (halb27 @ Apr 17 2012, 20:50) *
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.
Go to the top of the page
+Quote Post
halb27
post Sep 8 2012, 19:46
Post #22





Group: Members
Posts: 2428
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



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

This post has been edited by halb27: Sep 8 2012, 19:48


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
goa pride
post Sep 9 2012, 21:37
Post #23





Group: Members
Posts: 61
Joined: 13-January 12
Member No.: 96416



QUOTE (halb27 @ Sep 8 2012, 19:46) *
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?
Go to the top of the page
+Quote Post
Dynamic
post Sep 9 2012, 22:37
Post #24





Group: Members
Posts: 803
Joined: 17-September 06
Member No.: 35307



QUOTE (goa pride @ Sep 9 2012, 21:37) *
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.

This post has been edited by Dynamic: Sep 9 2012, 22:38
Go to the top of the page
+Quote Post
halb27
post Sep 9 2012, 23:29
Post #25





Group: Members
Posts: 2428
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



QUOTE (goa pride @ Sep 9 2012, 22:37) *
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.


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post

2 Pages V   1 2 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 27th August 2014 - 12:39