lame3100i, a functional extension Options

[halb27]

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.

This post has been edited by halb27: Feb 15 2013, 10:17

[Kamedo2]

The feature brV+ seems to be working as advertised. Great.

CODE

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

[Kamedo2]

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)

[halb27]

Wonderful! I'm quite curious about the results.

[halo001]

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?

[halb27]

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.

This post has been edited by halb27: Mar 30 2013, 22:47

[halo001]

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?

[halb27]

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

This post has been edited by halb27: May 3 2013, 13:24

[o-l-a-v]

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?

[db1989]

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.

[halb27]

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.


This post has been edited by halb27: May 4 2013, 19:55

[Kamedo2]

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.

[eahm]

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?

This post has been edited by eahm: May 5 2013, 21:35

[IgorC]

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.

[Kamedo2]

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

[Kamedo2]

The test of MP3 encoders including this encoder has finished, and I uploaded the result in here:
http://www.hydrogenaudio.org/forums/index....howtopic=100896