lame3100h, a functional extension
lame3100h, a functional extension
Dec 18 2012, 01:11
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015
You can download it from here.
Whatís the functional extension?
It offers additional VBR quality settings -V5+ to -V0+ which cover the average bitrate range from ~144 to ~300 kbps (for a variety of pop music):
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.
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 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
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.
This post has been edited by halb27: Dec 18 2012, 01:27
Musepack --quality 7
Jan 21 2013, 19:49
Joined: 24-June 02
Member No.: 2383
halb27 is correct (although the naming doesn't matter).
Most compilers only compile in one setting. (i.e. targeting a supported instruction set, like SSE, or not).
Back in the days, there were software that had different paths, because of hand-written code (i.e. writing assembly code by hand). LAME used to have an assembly path, but with 64bits, "old" assembly doesn't even compile, so developers have to either use intrinsics, or maintain (again) separated branches.
A semi-automatic way could be done by the use of dlls, (each one built with one support, and loading the one needed), but again, that adds work to the developer.
And also, there's the "bundle" solution. Like the "universal binary" in Apple's OS or the binary of "process explorer" (From Microsoft), which are actually two complete binaries built in each setting, wrapped inside a binary that knows when to use one or the other.
|Lo-Fi Version||Time is now: 12th December 2013 - 12:35|