Lame3.98.4x, A Lame 3.98.4 functional extension
Lame3.98.4x, A Lame 3.98.4 functional extension
Oct 5 2011, 15:45
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015
How to use
Download Lame 3.98.4x
You can use lame3984x.exe as you use lame.exe, with the extensions described below.
You have to install the provided (or downloaded on your own) Microsoft Visual C++ 2010 Redistributable Package invcredist_x86.exe as Lame3984x.exe was compiled with Visual C++ 2010.
What’s the functional extension?
3.98.4x’s extended functionality is about using -V0.
It’s for mp3 users out for the safer side of using mp3. There is no chance of a quality regression compared to standard 3.98.4. The details of the extensions are explained below so everybody can see.
When using --verbose you get some information about the extended behavior on the encoded track.
These are the extensions:
Preserving accuracy of output frames
With spots in the music which Lame considers hard to encode it happens rather often that standard Lame runs out of data space due to mp3 limitations and the way 3.98.4 packages audio data into output frames.
In an out of data space situation Lame has to simplify the -V0 audio data production.
With full length tracks of pop music this happens to typically 5 percent of all frames, and can go up to 10 percent. With problem sample snippets like castanets, it can be more than 20 percent of the frames.
To sum it up: a high percentage of hard-to-encode frames is affected.
Lame 3.98.4x -V0 uses another frame packaging strategy which eliminates roughly 95 percent of the out of data space situations with its otherwise inaccurately encoded frames.
This can have a significant effect on pre-echo prone and other hard-to-encode spots in the music.
By using 3.98.4x -V0 or one of the -V0 variants described below you get this improved behavior.
Bitrate increase is small: For my standard test set of various full length pop tracks Lame3.98.4x -V0 uses an average bitrate of 238 kbps, whereas for Lame3.98.4 -V0 it is 232 kbps.
It should be mentioned that Lame 3.99 uses a similar frame packaging strategy as Robert told me.
Using -b 320 -F solves the problem too, at the cost of 320 kbps frames throughout.
Optionally: Increasing accuracy with a bias on spots which Lame thinks are easy to encode
By using -V0+ instead of -V0 the user can make -V0 more defensive in a way similar to what some users try to achieve by adding -b xxx to -V0. These users are targeting at preventing Lame from producing too low a quality on occasion due to imperfections of the psy model.
The -b xxx approach doesn’t work because for VBR -b is about output frame packaging and has no impact on the audio data creation process.
-V0+ uses a strategy targeting at increasing mp3 audio data accuracy requirements, with a stronger focus on spots which Lames thinks are easy to encode.
In no case is the accuracy lowered compared to what -V0 requires.
Increasing accuracy requirements is done by decreasing the nominal hearing threshold in an sfb-dependent way, a technique which is available in standard Lame and is actively used there for reducing sfb21 accuracy (and for using the --ns-bass/alto/treble parameters which aren't available any more with 3.98.4x because they would interfere with the -V0+ mechanism).
Because of the cost in terms of bitrate increase, accuracy of very high frequencies is not increased by much. sfb21 is not touched at all compared to standard Lame behavior.
-V0+’s increased accuracy demands are dynamic in order not to reintroduce inaccurately encoded frames.
Bitrate increase is moderate: For my standard test set of various full length pop tracks Lame3.98.4x -V0+ uses an average bitrate of 261 kbps.
-V0++ is the strong variant of -V0+. Accuracy requirements are increased strongly, as is the bitrate which is 308 kbps for my standard test set.
This is for the very cautious, and is an alternative to using CBR 320.
Optionally: Increasing available data space for an output frame
By using -V0x, -V0+x, or -V0++x instead of -V0, -V0+, -V0++, Lame3.98.4x can make use of more bits for taking up the audio data of a frame than does standard Lame.
The highest amount of audio data that can be used for an output frame is when Lame chooses a 320 kbps frame, and when the bit reservoir (unused space in previous frames) is at maximum.
There is a limitation of 511 Byte maximum bit reservoir according to the mp3 specs, however when the current frame is a 320 kbps frame the specs should probably be interpreted to be more stringent. Unfortunately the mp3 specs aren’t very clear in this respect.
The dilemma: if you’re going to be very defensive in this respect (for instance don’t use bit reservoir at all with 320 kbps frames - AFAIK some FhG encoders do that - you give away a pretty high amount of potential audio quality). And if you’re not defensive, you have the potential risk that certain mp3 players can’t play your music.
When thinking about potential decoding problems fear that a player won’t play your music shouldn’t worry too much. From a decoder’s developer point of view it’s all about how large the buffer is that can hold the audio data of a frame. For a decoder developer it doesn’t make sense to be restrictive here. On one hand being restrictive for the special case of 320 kbps frames makes life more complicated to him. It’s also not so good for a decoder developer if mp3 tracks don’t play with his decoder, especially when considering that mp3 specs aren’t clear in this regard. So why should he make his life and that of others harder, and we are talking about pretty small buffer sizes anyway?
Things weren’t so theoretical when a FhG decoder came up on Windows PCs which caused some trouble. But the amount of trouble was not clear - from my understanding hardly anybody ran into real trouble, and the problem is solved anyway.
Standard Lame takes care of these considerations by allowing a bit reservoir of 396 Byte for 320 kbps frames. The idea behind it is that a decoder developer will use a buffer of at least this size when using a rather stringent mp3 spec interpretation for a 32 kHz sample frequency track, and to use this buffer size for any sample frequency. 32 kHz is the frequency that requires the largest buffer under these considerations.
With -V0x, -V0+x, -V0++x, 511 Byte of bit reservoir are allowed also for 320 kbps frames. The idea behind it is that something else is unnecessarily complicated on the decoder side and wouldn’t make any sense (no advantage for whomsoever).
I tried several tracks encoded with -V0++x using various players on a 32bit Windows XP system. I tried them also on my Nokia C7 smartphone as well as on my Sansa Clip+ mobile player, without and with Rockbox. Everything was fine.
Looking at the benefits: For the German group Juli’s song ‘Geile Zeit’ the behavior is somewhat typical:
Lame 3.98.4 -V0: 3.96% inaccurate frames
Lame 3.98.4x -V0: 0.08% inaccurate frames
Lame 3.98.4x -V0x: 0.03% inaccurate frames
This post has been edited by halb27: Oct 5 2011, 16:40
Musepack --quality 7
|Lo-Fi Version||Time is now: 10th December 2013 - 14:02|