Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: lame3995m - a constraint vbr variant (Read 15505 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

lame3995m - a constraint vbr variant

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

lame3995o -Q1.7 --lowpass 17

lame3995m - a constraint vbr variant

Reply #2 –
Yesterday was about Lame 3.100 alpha2, today is about 3.99.5.
lame3995o -Q1.7 --lowpass 17

lame3995m - a constraint vbr variant

Reply #3 –
Ops, my bad, MY BAAAD!

lame3995m - a constraint vbr variant

Reply #4 –
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.
lame3995o -Q1.7 --lowpass 17

lame3995m - a constraint vbr variant

Reply #5 –
Quote from: halb27 on
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?

lame3995m - a constraint vbr variant

Reply #6 –
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.
lame3995o -Q1.7 --lowpass 17

lame3995m - a constraint vbr variant

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

lame3995m - a constraint vbr variant

Reply #8 –


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?

lame3995m - a constraint vbr variant

Reply #9 –
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?
lame3995o -Q1.7 --lowpass 17

lame3995m - a constraint vbr variant

Reply #10 –
Quote from: halb27 on
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.

lame3995m - a constraint vbr variant

Reply #11 –
Quote from: BFG on
Quote from: halb27 on
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.
lame3995o -Q1.7 --lowpass 17

lame3995m - a constraint vbr variant

Reply #12 –
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.

lame3995m - a constraint vbr variant

Reply #13 –
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.
lame3995o -Q1.7 --lowpass 17

lame3995m - a constraint vbr variant

Reply #14 –
Quote from: halb27 on
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.

lame3995m - a constraint vbr variant

Reply #15 –
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? 

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

lame3995m - a constraint vbr variant

Reply #16 –
Quote from: IgorC on
... 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).
lame3995o -Q1.7 --lowpass 17

lame3995m - a constraint vbr variant

Reply #17 –
Quote from: halb27 on
Quote from: IgorC on
... 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 from: halb27 on
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 from: halb27 on
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 from: halb27 on
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.

lame3995m - a constraint vbr variant

Reply #18 –
Quote from: IgorC on
Quote from: halb27 on
Quote from: IgorC on
... 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.
lame3995o -Q1.7 --lowpass 17

lame3995m - a constraint vbr variant

Reply #19 –
Quote from: IgorC on
Quote from: halb27 on
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.
lame3995o -Q1.7 --lowpass 17

lame3995m - a constraint vbr variant

Reply #20 –
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.

lame3995m - a constraint vbr variant

Reply #21 –
Quote from: halb27 on
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?

lame3995m - a constraint vbr variant

Reply #22 –
Quote from: IgorC on
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.
lame3995o -Q1.7 --lowpass 17

lame3995m - a constraint vbr variant

Reply #23 –
Quote from: IgorC on
Quote from: halb27 on
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.
lame3995o -Q1.7 --lowpass 17
 

lame3995m - a constraint vbr variant

Reply #24 –
Quote from: halb27 on
Quote from: IgorC on
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. 
Now everything is clear for me.