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. 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 seems to scale well quality of tonal problems 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 x if you don't like this).

Emphasis is on issues with temporal resolution, but tonal problems are tackled as well.

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.

lame3100h.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 lame3100h.exe is located. Many thanks to Omion for this great tool.In case there is no mp3packer.exe in lame3100h.exeís folder lame3100h.exe will work, but the mp3 files will be somewhat larger than necessary.

Looks like it's working as advertised! If it's possible to do so, I'd recommend extending the existing algorithm so that -brV+ 32 through -brV+ 320 are also recognized. I know that -V+ 32-143 isn't particularly useful, but I could see uses for 301-320.

So those that I've bolded are not close to the bitrate requested. I guess anything below 143 should ideally be mapped to 144 and anything above 300 should be mapped to 300 and possibly throw a warning that the requested bitrate target is out of range and specify the one actually used.

So those that I've bolded are not close to the bitrate requested. I guess anything below 143 should ideally be mapped to 144 and anything above 300 should be mapped to 300 and possibly throw a warning that the requested bitrate target is out of range and specify the one actually used.

It looks like the new --brV+ function is using the standard -V+ function for values 0-9, and anything outside of the 144-300 range (the range that -V+ is defined for) errors out. Either 32-143 should be mapped to 144, and 301-320 to 300 like Dynamic suggests, or the --brV+ function should be extended to the full range of MPEG-1 bitrates (32-320).

I've changed --brV+ x behavior for x < 144 and x > 300.No more error message and stop, instead: --brV+ 144 is used for x < 144, --brV+ 300 is used for x > 300.You'll get this behavior when downloading now.

The --brV+ x -> -V y+ mapping isn't very good when x is a little bit higher than 144.The background is that -V5 yields an average bitrate of 130 kbps, wheras -V4.99 takes an average bitrate of 140 kbps. This bitrate jump is at least softened when going -Vx+.

The progressbar does not move, estimated time just get higher and higher. Whats wrong here? I use foobar. I got mp3packer.exe in the same folder, and haven't renamed the lame3100h.exe.Also got c++ 2010 installed

Why are you comparing VBR with 3.99.5 and 3.100h against CBR with 3.98.4? If you want the target bitrates to be close to 224 kbps for comparison purposes for each version, it seems to me that you ought to use V 1.5 or some other non-standard value in 3.98.4 so you're comparing VBR against VBR in all cases, rather than quality-based encoding schemes against a filesize-based one. Perhaps I have misunderstood the purpose of your test.

As far as lame3100h is concerned: I have no plans for a newer version.But I see you don't include Lame 3.100 alpha2 in the test. This brings the problem that in case lame3100h would show up quality advantages in your test we don't know whether these are due to the improvements of 3.100 or whether they are due to the functional extension.