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: lame3100i, a functional extension (Read 31241 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

lame3100i, a functional extension

You can download it from here.

What’s the functional extension?

It's an extension to Lame 3.100 alpha2.
It offers additional VBR quality settings -V5+ to -V0+ which cover the average bitrate range from 148 to 317 kbps (for a variety of pop music).

-V5+       148 kbps
-V4.5+    162 kbps
-V4+       176 kbps
-V3.5+    192 kbps
-V3+       208 kbps
-V2+       224 kbps
-V1.5+    240 kbps
-V1+       256 kbps
-V0.5+    291 kbps
-V0+       317 kbps

An alternative way to use the functional extension is --brV+ x, where x is the average bitrate (for a variety of pop music) you want to use, with x between 148 and 317. You can use for instance --brV+ 224 instead of -V2+.

What is it good for?

Lame’s moderate VBR quality settings like -V5 or -V4 usually yield a very good quality. That’s why many users are happy with these settings. Sometimes however tracks contain spots which are not encoded well. Many users want a better quality also for these rather rare events. From current experience Lame3.100 alpha2 quality of tonal problems seems to scale well with -Vn level, but temporal resolution can still be an issue.

-Vn+ uses -Vn as the encoding basis, but adds a certain amount of brute-force safety by forcing audio data bitrate to a target bitrate which depends on -Vn+ level. Moreover care is taken to always provide maximum possible audio data space for the encoding of short blocks which are used when the encoder thinks it is appropriate for a good temporal resolution. Also Lame's default lowpass is lowered a bit in order to make best use of the encoded bits (use --lowpass if you don't like this).

Emphasis is on issues with temporal resolution, but the higher quality levels starting with -V4+ can also have a positve effect for tonal problems.

In a sense -Vn+ combines the quality advantages of both VBR and CBR.

Recommendations

Users who care much about filesize and are content with the functional extension improving short block (pre-echo) behavior, can use -V5+ to -V4+.

Users who don’t like rather obvious issues in their music even when they’re rare but who also care about filesize are best to choose from -V3.5+ to -V1.5+ according to their needs.
For a significant potential for improving tonal issues -V3+ or better is recommended.

Users who don’t care much about filesize but much more about universal top quality are best served by using -V1+ or V0+, or anything in between. -V0.5+ is a good choice which is extremely close to maximum quality possible with lame3100i.

Installation

lame3100i.exe was compiled with Visual C++ 2010. For this reason it is necessary to install the Microsoft Visual C++ 2010 Redistributable Package vcredist_x86.exe. You can download it from http://www.microsoft.com/en-us/download/details.aspx?id=8328.

lame3100i.exe uses the fast and lossless mp3packer tool internally to squeeze the otherwise unused bits out of the mp3 file. You can download mp3packer from http://www.hydrogenaudio.org/forums/index....st&p=282289. Put mp3packer.exe into the same folder where lame3100i.exe is located. Many thanks to Omion for this great tool.
In case there is no mp3packer.exe in lame3100i.exe’s folder lame3100i.exe will work, but the mp3 files will be somewhat larger than necessary.
lame3995o -Q1.7 --lowpass 17

lame3100i, a functional extension

Reply #1
The feature brV+ seems to be working as advertised. Great.
Code: [Select]
cores\lame3100i\lame3100i --brV+ %v %i %o
%v  bitrate[bps] of pops and jazz albums(5 min snippet)
0 146932
4 146932
144 146932
148 146932
152 155511
156 157544
160 159483
164 161866
168 163641
172 165594
176 175418
180 179288
184 183231
188 187309
192 191600
196 195465
200 199285
204 203215
208 207176
212 212092
216 215688
220 219378
224 222879
228 227044
232 230911
236 235030
240 239413
244 243539
248 247469
252 251648
256 255503
260 259525
264 263342
268 267286
272 270995
276 274723
280 278480
284 282119
288 285841
292 289190
296 293361
300 297445
304 301341
308 305350
312 309225
316 312301
320 312732
324 312732

lame3100i, a functional extension

Reply #2
My personal listening test of MP3 224kbps including this encoder is ongoing, and I've ABC/HR-ed 5 samples.
Lame3100i V2+, LAME3.99.5 V1, LAME3.98.4 cbr224k, Helix V146, BladeEnc cbr224k(low anchor)

lame3100i, a functional extension

Reply #3
Wonderful! I'm quite curious about the results.
lame3995o -Q1.7 --lowpass 17

lame3100i, a functional extension

Reply #4
I like what I experienced so far with lame3100i. Something just brought up on my mind, what about lame use CVBR (Constrained Variable Bitrate) instead of a Plain ABR (Average Bitrate) as Encoding Strategy?

lame3100i, a functional extension

Reply #5
What the functional extension does is exactly CVBR, at least to a major extent.
I welcome anything within main Lame devolopment that does something like this, no matter whether it's exactly what I've done or something else (maybe better).

However I must admit that to me official Lame's overall progress is so good that I'm not sure I would have done what I've done with Lame's current state at the time I started.
I personally still like the idea of CVBR, but I'm hard-pressed to give very convincing reasons for it with the arrival of Lame 3.100alpha2.
lame3995o -Q1.7 --lowpass 17

lame3100i, a functional extension

Reply #6
I agree with that. It will be close to perfection by the time lame 3.100 is officially released. 

Something about your work, I think lame developers are fully aware of your functional extension. Do you have any plans proposing this (functional extension) to be part of lame's official project?

 

lame3100i, a functional extension

Reply #7
I did. Guess CVBR isn't what they like to do.
lame3995o -Q1.7 --lowpass 17

lame3100i, a functional extension

Reply #8
I did. Guess CVBR isn't what they like to do.


CVBR will result in better sound compared to VBR, both having same average bitrate/ same size?

lame3100i, a functional extension

Reply #9
I doubt that. At least in theory, constraining the bitrate reduces the ability of the encoder to allocate bits as it sees fit, hence potentially reducing the quality as some sections are forced to higher bitrates and others lower. Then you have this, three posts above yours:
I personally still like the idea of CVBR, but I'm hard-pressed to give very convincing reasons for it with the arrival of Lame 3.100alpha2.

lame3100i, a functional extension

Reply #10
Kamedo2 is doling a test ATM which may bring some insight.

Other than that for people who are concerned about average quality for a test set CVBR is definitely not attractive.
CVBR is for people who are concerned about worst case behavior, people who like say -V3 as the perfect match for their quality needs in the vast majority kind of music, but are not content with -V3 on certain occasion.
In this case a CVBR variant of -V3 might do the job. An average bitrate equivalent -Vx is the fair competitor to this, and it's a priori not clear what gives the better quality. We don't have sufficient experience with it to make it real clear.

No reason however to be very doubtful towards the functional extension's usefulness because there has been positive experience with it (listen to sec. 3.0 of eig for instance: the functional extension brings the solution which standard Lame fails to give even with -V0). I personally am interested mostly in real inadequate VBR behavior however. For me everything started with problem sample 'trumpet' in Lame 3.97 times where VBR provided a real bad quality so I was shocked. The issue was solved with 3.98/3.99. Meanwhile problem sample 'lead-voice' lead to an even bigger shock when using VBR. 'lead-voice' was the main real life background for the development of the functional extension. I don't agree with db1989's argumentation as general arguments as in terms of Lame 3.99 lead-voice is a strong proof that CVBR makes sense - CVBR eliminated the issue. With Lame 3.100.alpha2 the issue with lead-voice is gone (most of the time it's like this when I do a listening test) or is at least brought down to next-to-nothing (sometimes I can still ABX the problem).

That's the situation.
lame3995o -Q1.7 --lowpass 17

lame3100i, a functional extension

Reply #11
Kamedo2 is doling a test ATM which may bring some insight.

Yes, I'm testing MP3 encoders including Lame3100i at 224kbps, and I've done 21 samples out of 25 samples (84% done). I think I can upload the result within 10 days.


lame3100i, a functional extension

Reply #12
Kamedo2 is doling a test ATM which may bring some insight.

Yes, I'm testing MP3 encoders including Lame3100i at 224kbps, and I've done 21 samples out of 25 samples (84% done). I think I can upload the result within 10 days.

Isn't that bitrate too high to ABX? Wasn't ~175 or ~190 more appropriate? Will we be surprised?

lame3100i, a functional extension

Reply #13
IMO it's matter of training.  1+ year ago I've trained a lot for ABXing of high bitrates and wasn't happy with V2. Only V0 was good. Now I've tried V2 and basically it's (close to) transparent.

lame3100i, a functional extension

Reply #14
Kamedo2 is doling a test ATM which may bring some insight.

Yes, I'm testing MP3 encoders including Lame3100i at 224kbps, and I've done 21 samples out of 25 samples (84% done). I think I can upload the result within 10 days.

Isn't that bitrate too high to ABX? Wasn't ~175 or ~190 more appropriate? Will we be surprised?

I'm successfully ABXing around 80% of the encoded test materials that had been already tested, but this is tough. ABX criteria is 15+/20(p = 0.02).


lame3100i, a functional extension

Reply #16
I'd like to report about recent development and future plans for the functional extension.

In the last few weeks I did some changes for a preliminary version 3100j. It was all about having details more balanced. One of the changes is worth mentioning: the energy (loudness) dependent minimum audio data bitrate. I've always concentrated on a reference energy level which is very moderate and had minimum audio data bitrate decrease/increase rather strongly for energy levels below/above the reference level. This is very welcome for low energy levels as minimum audio data bitrate requirements are low. But I've realized it's not so welcome for very loud spots in the music. It increases average bitrate of pop music pretty much, or the other way around: holds minimum audio data bitrate requirements for the reference energy level rather moderate in order not to increase average bitrate too much.
I decided to increase bitrate requirements for higher energy levels to a smaller amount. In return I could increase the bitrate requirements for the reference energy level and below.

I did intensive listening tests at -V3+ with the problem samples I care about. I couldn't hear any difference to version 3100i with one exception: harp40_1 improved so much that I could ABX the 3100j result against the 3100i result.

I also felt that in the quality range around -V1+ average bitrate is too high. The background is that minimum audio bitrate requirements are pretty strong already at -V2+ and should be increased by a much smaller extent for the higher quality levels.

With the preliminary j version I still had average bitrate increase up to 317 kbps when using -V0+. Severe bitrate increase started with -V0.5+.
But I want to reconsider this totally. I think of something like a parameter -Vplus x, 1 <= x <= 10, to be used together with the standard -V parameter. -Vplus x controls the minimum audio data bitratre requirements. For a low x only cheap requirements concerning only short block behavior are triggered (which come practically for free for very high quality levels). For a high x very expensive requirements are used (makes sense only for -V0). For x ~ 5 'normal' requirements are used which make sense for -V3 or better (and are cheap for the highest quality levels).
I still think of having the -Vx+ and --brV+ options, but with respect to Kamedo2's test I will consider having a lower average bitrate increase of -Vx+ against -Vx for all x, resp. use a higher -Vn for --brV+ x than with version i.

As for Kamedo2's test I will try to find out for the samples Trust, Quizas and Experiencia (3100i was inferior to 3.99.5 here), if original 3.100.a2 and 3.99.5 behave different or why 3100i does a relatively poor job here. Sure this might have an influence on further changes for 3100j.
lame3995o -Q1.7 --lowpass 17

lame3100i, a functional extension

Reply #17
Thank you, as usual, for the work on your functional extension, and continued pursuit of perfection!

...did you intend to include a link to 3.100j in your previous post?

lame3100i, a functional extension

Reply #18
...did you intend to include a link to 3.100j in your previous post?

I didn't as for now it's a preliminary version, and I wrote what I want to do yet before going final.

However it's fully tested, and if you like to, I can publish it, and have 3100k do what I have planned for 3100j final.
lame3995o -Q1.7 --lowpass 17

lame3100i, a functional extension

Reply #19
However it's fully tested, and if you like to, I can publish it, and have 3100k do what I have planned for 3100j final.

I appreciate that, but there is no need to publish the current version just for me.  I am very poor at ABXing and would not be able to provide any good testing for you.

lame3100i, a functional extension

Reply #20
I would be interested in checking out the latest version if you wouldn't mind uploading it halb27... Thanks!

lame3100i, a functional extension

Reply #21
OK, here comes version 3100j. As this is an intermediate version, I will not start a new thread for it.
Whatever comes out of my further plans will be published in version k.
lame3995o -Q1.7 --lowpass 17

lame3100i, a functional extension

Reply #22
I did some listening tests with those of Kamedo2's samples I mentioned.

Most important to me is Trust, as with a 4.0 score this sample had the worst 3100i result in his test.
I could rather easily ABX the issue in the leading applaud part when using 3.99.5 -V5 and -V4 as well as 3.100.a2 -V5 and -V4.
Doing an ABC/HR test with these quality levels revealed 3.99.5 to yield the better quality. I also tried -V3 and found 3.99.5 to be a tiny bit better, too, but the difference was so small to me that this doesn't really matter. Sure my hearing isn't by far as good as Kamedo2's.

I also tried Experiencia and Quizas, but my hearing is so bad that even at -V5 I didn't get distinguishing results.

Sample Trust shows that using 3.100.a2 as the basis for the recent versions of the functional extension may not have been a wise decision. Sure this one sample doesn't mean 3.99.5 would have been the better basis.

As a consequence I'd love to know: shall we have upcoming version k
- both on a 3.100.a2 and a 3.99.5 basis
- only on a 3.100.a2 basis
- only on a 3.99.5 basis?

What do you think?
lame3995o -Q1.7 --lowpass 17

lame3100i, a functional extension

Reply #23
I'd personally rather wait until 3.100 is in final release before I used it for anything more than testing purposes, so I'm all for using 3.99.5

lame3100i, a functional extension

Reply #24
Probably one of those cases of win some, lose some.
If 3100a2 is generally an improvement for the range -V2 to -V0 it might be good to stick to it.
In theory, there is no difference between theory and practice. In practice there is.