IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
lame3995m - a constraint vbr variant
halb27
post Nov 18 2013, 23:23
Post #1





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



The constraint vbr mechanism is now available for the latest Lame release version 3.99.5, too.
It can be downloaded from here.



--------------------
lame3100m --bCVBR 300
Go to the top of the page
+Quote Post
eahm
post Nov 18 2013, 23:32
Post #2





Group: Members
Posts: 882
Joined: 11-February 12
Member No.: 97076



Yes, he you said that yesterday: http://www.hydrogenaudio.org/forums/index....st&p=850346

This post has been edited by eahm: Nov 18 2013, 23:36
Go to the top of the page
+Quote Post
halb27
post Nov 18 2013, 23:34
Post #3





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



Yesterday was about Lame 3.100 alpha2, today is about 3.99.5.


--------------------
lame3100m --bCVBR 300
Go to the top of the page
+Quote Post
eahm
post Nov 18 2013, 23:36
Post #4





Group: Members
Posts: 882
Joined: 11-February 12
Member No.: 97076



Ops, my bad, MY BAAAD!
Go to the top of the page
+Quote Post
halb27
post Nov 19 2013, 21:48
Post #5





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



For comparing lame3995m with lame3100m I did a short test with my ususal problem samples for the --bCVBR 236 setting (I also compared against musepack Q7 which yields an average bitrate of 236 kbps for my test set).

Not surprisingly quality for these lameXXXXm versions were very similar to me. The only clear (ABXable) difference was with trumpet_myPrince, and it was in favor of 3100m.
On the other hand harp40_1 was more precise to me when using 3995m, but this is not so clear as I couldn't ABX the difference.
All the other samples were of an identical quality to my ears.
Absolutely speaking quality is very good to me with both versions. Deviations from the original are at the edge of being negligible for me. I'm a tiny bit in favor of 3995m, because the 'issue' with harp40_1 is more obvious than that of trumpet_myPrince for me.

As a consequence I tried lame3995m --bCVBR 260 for harp40_1 and trumpet_myPrince, and I am very happy with the results (not transparant, but to me the remaining differences are negligible).

I should add that my sensitivity for issues varies, and ATM I think I'm a bit less sensitive than I was just a few days ago when I tested lame3100m.

This post has been edited by halb27: Nov 19 2013, 21:50


--------------------
lame3100m --bCVBR 300
Go to the top of the page
+Quote Post
halo001
post Nov 27 2013, 11:05
Post #6





Group: Members
Posts: 15
Joined: 26-February 13
From: Philippines
Member No.: 106896



QUOTE (halb27 @ Nov 20 2013, 04:48) *
Not surprisingly quality for these lameXXXXm versions were very similar to me.


So what lame version do you consider to be a reference for your future variant?
Go to the top of the page
+Quote Post
halb27
post Nov 27 2013, 12:06
Post #7





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



There is a good chance that there will be no more future variant, simply because everything I ever had in mind has gone into the existing variants. Changes in the latest variants were of very minor importance already.
This feeling was the very reason why I ported the extended functionality of 3100m back to 3.99.5, and did not do this with a previous version.

As for whether to use 3995m or 3100m:
For moderate bitrate settings, say <= 200 kbps, I'd prefer 3100m because to me Lame3.100alpha2 is the better choice for certain tonal issues than is Lame3.99.5. I'm well aware though that the basis for this statement is pretty poor (it's based on very few tonal problems I care about).
For high bitrate settings the differences between 3100m and 3995m are pretty negligible, especially when using stronger --cvbr levels. According to the comparison in my last post I personally prefer 3995m a tiny bit.

If you have problem sample(s) which you do like to see encoded well just compare for yourself what is best to you. If you don't: don't care at all.

This post has been edited by halb27: Nov 27 2013, 12:13


--------------------
lame3100m --bCVBR 300
Go to the top of the page
+Quote Post
halo001
post Nov 27 2013, 14:04
Post #8





Group: Members
Posts: 15
Joined: 26-February 13
From: Philippines
Member No.: 106896



Thank you for providing this variant halb27. In my own opinion I'm in favor too for 3995m especially for stereo representation (the thing that I noticed about lame3.100 alpha 2 is that it produce discrete-like stereo sound except when I invoke Joint Stereo on it) But this is merely based on pure perception I experience.

This post has been edited by halo001: Nov 27 2013, 14:18
Go to the top of the page
+Quote Post
halo001
post Dec 6 2013, 15:58
Post #9





Group: Members
Posts: 15
Joined: 26-February 13
From: Philippines
Member No.: 106896





I often use the --replaygain-accurate parameter on lame commandline encoder. I always enable this setting for decoding purpose. So can I also normally use it on foobar's commandline interface?
Go to the top of the page
+Quote Post
halb27
post Dec 6 2013, 22:24
Post #10





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



lame3995m makes use of all the Lame options, and foobar's command line interface should pass any parameter to lame3995m.
Did you encounter any problems?


--------------------
lame3100m --bCVBR 300
Go to the top of the page
+Quote Post
BFG
post Dec 7 2013, 00:52
Post #11





Group: Members
Posts: 205
Joined: 22-July 12
Member No.: 101637



QUOTE (halb27 @ Nov 27 2013, 05:06) *
There is a good chance that there will be no more future variant, simply because everything I ever had in mind has gone into the existing variants. Changes in the latest variants were of very minor importance already.

In that case, the only thing that remains is to convince the owners of the "main" version of LAME to include your variant options, or some version thereof, in future releases. Easier said than done though, I suppose.
Go to the top of the page
+Quote Post
halb27
post Dec 7 2013, 20:55
Post #12





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



QUOTE (BFG @ Dec 7 2013, 00:52) *
QUOTE (halb27 @ Nov 27 2013, 05:06) *
There is a good chance that there will be no more future variant, simply because everything I ever had in mind has gone into the existing variants. Changes in the latest variants were of very minor importance already.

In that case, the only thing that remains is to convince the owners of the "main" version of LAME to include your variant options, or some version thereof, in future releases. Easier said than done though, I suppose.

I should add that I intend to port my variant to future Lame versions.
I just can't imagine any changes in my variant itself. Nothing more to do for me, as far as I can see.


--------------------
lame3100m --bCVBR 300
Go to the top of the page
+Quote Post
BFG
post Dec 11 2013, 19:46
Post #13





Group: Members
Posts: 205
Joined: 22-July 12
Member No.: 101637



Halb27, out of curiosity - would you have the interest, and the ability, to add Replaygain V2.0 support to your LAME variant, and/or switch the existing --replaygain-accurate function so that it writes to ID3v2 tags? Those are pretty much the only missing functions I would still use.

This post has been edited by BFG: Dec 11 2013, 19:47
Go to the top of the page
+Quote Post
halb27
post Dec 11 2013, 19:57
Post #14





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



Implementing another replaygain functionality into Lame is beyond my scope.
Writing the Lame computed replaygain values to ID3v2 tags is beyond my scope at the moment as well, but I guess I am able to implement that after doing some research.
I'll have a look into it, but please don't expect results anytime very soon. I'm busy with other things ATM.

This post has been edited by halb27: Dec 11 2013, 19:58


--------------------
lame3100m --bCVBR 300
Go to the top of the page
+Quote Post
BFG
post Dec 12 2013, 06:37
Post #15





Group: Members
Posts: 205
Joined: 22-July 12
Member No.: 101637



QUOTE (halb27 @ Dec 11 2013, 12:57) *
Implementing another replaygain functionality into Lame is beyond my scope.
Writing the Lame computed replaygain values to ID3v2 tags is beyond my scope at the moment as well, but I guess I am able to implement that after doing some research.
I'll have a look into it, but please don't expect results anytime very soon. I'm busy with other things ATM.

Not a problem! Thank you for being willing to consider it.
Go to the top of the page
+Quote Post
IgorC
post Dec 14 2013, 19:38
Post #16





Group: Members
Posts: 1506
Joined: 3-January 05
From: Argentina, Bs As
Member No.: 18803



It's unclear whether this constraint vbr approach works as expected (if at all).

A bitrate can be safely dropped on easy parts. If an encoder is constrained for a lower limit of bitrate then there will be less possiblities to save these bits and donate them to difficult parts.
It will be insteresting to see some blind tests here.

There was a pesonal test from Kamedo2 (link)
habl27's extension 3.100i was on par with a regular LAME encoders. No quality gain at all? unsure.gif

Also 3.99.5/3.100 habl27's extensions are considerably slower. I have tried in on my Atom-based netbook (all threads are fully loaded):
halb27's extension - 6x
regular LAME - ~30x

This post has been edited by IgorC: Dec 14 2013, 19:48
Go to the top of the page
+Quote Post
halb27
post Dec 14 2013, 21:08
Post #17





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



QUOTE (IgorC @ Dec 14 2013, 19:38) *
... A bitrate can be safely dropped on easy parts. If an encoder is constrained for a lower limit of bitrate then there will be less possiblities to save these bits and donate them to difficult parts. ...

This is wrong as far as my Lame extension is concerned. I always take care of having available data space at the maximum which is possible within the possibilities of the mp3 format. This is one of the basic design principles which is in favor of my extension.

Other than that there's much truth in what you wrote, and I hope I have never risen too much hope that my extension gives a great progress compared to standard Lame.
In the bitrate range up to that of standard -V0 chance of getting better results than that of the standard Lame version is very low. It's not zero however as there are samples where the difference is ABXable (eig, lead-voice). And in terms of increased bitrate it comes at a cost which is next to nothing. In terms of encoding speed cost is not negligible, but when it's essential, that is when you're encoding a lot of tracks, the cost factor is lower than 5 when encoding with a good multicore system and a software like foobar which makes good use of it. On my i7-3930K system it's less than 2.

To me the main advantage comes from the fact that Lame development of recent years focussed on VBR. My extension allows these improvements to be combined with very high bitrate settings which extend the VBR average bitrate range beyond that of -V0. Of course this is usually overkill, but for those who don't care about that but want a very good quality even in extreme cases this can be considered an attractive alternative to CBR 320 or very high bitrate ABR. And again, there are samples where you can ABX the difference towards standard Lame -V0 (harp40_1, herding_calls, trumpet_myPrince).

This post has been edited by halb27: Dec 14 2013, 21:31


--------------------
lame3100m --bCVBR 300
Go to the top of the page
+Quote Post
IgorC
post Dec 14 2013, 21:31
Post #18





Group: Members
Posts: 1506
Joined: 3-January 05
From: Argentina, Bs As
Member No.: 18803



QUOTE (halb27 @ Dec 14 2013, 17:08) *
QUOTE (IgorC @ Dec 14 2013, 19:38) *
... A bitrate can be safely dropped on easy parts. If an encoder is constrained for a lower limit of bitrate then there will be less possiblities to save these bits and donate them to difficult parts. ...

This is wrong as far as my Lame extension is concerned.

Do You have any results of blind tests that can back your assumptions?


QUOTE (halb27 @ Dec 14 2013, 17:08) *
I always make sure to have available data space at maximum for short blocks where bits are needed most.

But then You should take bitrate from anywhere and that means an increase of a bitrate. It's not fair anymore to compare, i.e. "V2+ constraint vbr variant" vs "V2" . It's more like "V2+constraint vbr variant" vs "~V1.5"

QUOTE (halb27 @ Dec 14 2013, 17:08) *
In terms of encoding speed cost is not negligible, but when it's essential, that is when you're encoding a lot of tracks, the cost factor is much lower than 5 when encoding with a good multicore system and a software like foobar which makes good use of it. On my i7-3930K system it's less then 2.

On 3770k your encoder is still 3 times slower than a regular LAME, without any noticeble quality improvement.

QUOTE (halb27 @ Dec 14 2013, 17:08) *
And again, there are samples where you can ABX the difference towards standard Lame -V0 (harp40_1, herding_calls, trumpet_myPrince).

Do You still test on these samples already for years? It's not clear whether these samples (harp40_1, herding_calls, trumpet_myPrince) are enough representative for entire music diversity.

This post has been edited by IgorC: Dec 14 2013, 21:32
Go to the top of the page
+Quote Post
halb27
post Dec 14 2013, 21:36
Post #19





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



QUOTE (IgorC @ Dec 14 2013, 21:31) *
QUOTE (halb27 @ Dec 14 2013, 17:08) *
QUOTE (IgorC @ Dec 14 2013, 19:38) *
... A bitrate can be safely dropped on easy parts. If an encoder is constrained for a lower limit of bitrate then there will be less possiblities to save these bits and donate them to difficult parts. ...

This is wrong as far as my Lame extension is concerned.

Do You have any results of blind tests that can back your assumptions?

This is a question of software design, not listening tests. I choose frame size and SNR increase in a way which keeps bit reservoir at maximum.
If you doubt this you should go into the software code and show up a bug (or use the --frameAnalysis feature for this). If you find one it would help improve the software.

This post has been edited by halb27: Dec 14 2013, 21:42


--------------------
lame3100m --bCVBR 300
Go to the top of the page
+Quote Post
halb27
post Dec 14 2013, 21:41
Post #20





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



QUOTE (IgorC @ Dec 14 2013, 21:31) *
QUOTE (halb27 @ Dec 14 2013, 17:08) *
In terms of encoding speed cost is not negligible, but when it's essential, that is when you're encoding a lot of tracks, the cost factor is much lower than 5 when encoding with a good multicore system and a software like foobar which makes good use of it. On my i7-3930K system it's less then 2.

On 3770k your encoder is still 3 times slower than a regular LAME, without any noticeble quality improvement.

On my system, it's <2. I use a SSD for mass storage, I have 16 GB of RAM, and I use Win 7 Pro, maybe this makes up for the difference.


--------------------
lame3100m --bCVBR 300
Go to the top of the page
+Quote Post
IgorC
post Dec 14 2013, 21:43
Post #21





Group: Members
Posts: 1506
Joined: 3-January 05
From: Argentina, Bs As
Member No.: 18803



Yes, it's clear that it's software design.

But the question is the other, which is "Does it actually improve audible quality"?

Anybody could claim that some particular VBR algorithm has an advantage, still a blind tests should be performed to see whether your constraint vbr variant is any good.
Go to the top of the page
+Quote Post
IgorC
post Dec 14 2013, 21:47
Post #22





Group: Members
Posts: 1506
Joined: 3-January 05
From: Argentina, Bs As
Member No.: 18803



QUOTE (halb27 @ Dec 14 2013, 17:41) *
On my system, it's <2. I use a SSD for mass storage...

How can SSD benefit only your encoder and not a regular LAME encoders?
Go to the top of the page
+Quote Post
halb27
post Dec 14 2013, 21:47
Post #23





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



QUOTE (IgorC @ Dec 14 2013, 21:31) *
Do You still test on these samples already for years?

Yes, I do, and you're perfectly right questioning the meaning for the universe of music. But that's the basic problem with all such samples (though not to the same degree for each of them). And it's very personal. 'My' problems can be irrelevant to others, as are many problem samples published here to me.

This post has been edited by halb27: Dec 14 2013, 21:56


--------------------
lame3100m --bCVBR 300
Go to the top of the page
+Quote Post
halb27
post Dec 14 2013, 21:50
Post #24





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



QUOTE (IgorC @ Dec 14 2013, 21:47) *
QUOTE (halb27 @ Dec 14 2013, 17:41) *
On my system, it's <2. I use a SSD for mass storage...

How can SSD benefit only your encoder and not a regular LAME encoders?

I am not going into a technical investigation why speed penalty is <2 on my system and 3 on yours. I just gathered some technical specs from my system which may have an influence.


--------------------
lame3100m --bCVBR 300
Go to the top of the page
+Quote Post
IgorC
post Dec 14 2013, 21:53
Post #25





Group: Members
Posts: 1506
Joined: 3-January 05
From: Argentina, Bs As
Member No.: 18803



QUOTE (halb27 @ Dec 14 2013, 17:47) *
QUOTE (IgorC @ Dec 14 2013, 21:31) *
Do You still test on these samples already for years?

Yes, I do, and you're perfectly right questioning the meaning for the universe of music. But that's the basic problem with all such samples (though not to the same degree for each of them).

Thank You, halb27, for answering all my questions. Sorry if I was too strict. smile.gif
Now everything is clear for me.
Go to the top of the page
+Quote Post

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: 17th April 2014 - 11:24