Welcome Guest ( Log In | Register )

Lame3.98.4x, A Lame 3.98.4 functional extension
post Oct 5 2011, 15:45
Post #1

Group: Members
Posts: 2414
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

lame3100m --bCVBR 300
Go to the top of the page
+Quote Post
Start new topic
post Nov 6 2011, 14:31
Post #2

Group: Members
Posts: 2414
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015

I was on holidays for 14 days, and away from the 3.98.4x business I had the chance to think things over. And your questions just comes in handy on exactly what I thought. Thank you.

My last activities were a bit unlucky with respect to Lame development. I should discontinue 3.98.4x development because there have been improvements with the psy model with 3.99 compared to 3.98.4.
I still care about keeping the percentage of inaccurate frames down, and appreciate a brute-force component like not allowing audio data bit rate to go too low, but this should be done on the basis of the new version.
It should be implemented in form of a pure extension of Lame functionality which is triggered by two special options.

So I will create a variant 3.99.1x.
It will be identical with 3.99.1 except for the new options (details may change yet):
--adbr_min xxxx (keeping audio data bit rate at or above a certain threshold)
--maxres (keeping bit reservoir and thus the available data space for the audio data close to maximum. This minimizes the number of inaccurate frames).
It will work with any -V level.
--maxres will use several tactics: a special frame packaging strategy, a lower lowpass at least for the higher -V levels than is defaulted, and a non-restrictive use of the bit-reservoir for 320 kbps frames.

As for your Lame usage from XLD: what is XLD?

This post has been edited by halb27: Nov 6 2011, 14:37

lame3100m --bCVBR 300
Go to the top of the page
+Quote Post
post Nov 6 2011, 14:39
Post #3

Group: Members
Posts: 5
Joined: 6-November 11
Member No.: 94992

QUOTE (halb27 @ Nov 6 2011, 14:31) *
As for your Lame usage from XLD: what is XLD?

XLD http://tmkk.pv.land.to/xld/index_e.html is the Mac one-stop for transcoding, ripping and encoding. You can take a look at some usage examples here: http://dl.dropbox.com/u/1126247/WhatCD%20Articles/index.html

Still, I would like to keep 3.98.4x alive because I have been very content with 3.98.4 and would only like to push the better button. ;-) I tried 3.99 and was not convinced.

So if you have any good ideas for wrapping your LAME in an XLDbundle, it would be greatly appreciated.

Go to the top of the page
+Quote Post

Posts in this topic
- halb27   Lame3.98.4x   Oct 5 2011, 15:45
- - halb27   I know, there's next to no interest in 3.98.4x...   Oct 16 2011, 13:11
- - halb27   Now that 3.99 is out the question is: does 3.98.4x...   Oct 20 2011, 19:55
- - jetpower   Is only V0 preset modified? Could your modificatio...   Oct 21 2011, 17:01
- - halb27   Currently no. The idea so far was to extend the qu...   Oct 21 2011, 17:27
- - jetpower   I like your idea of changing the behavior of lame ...   Oct 21 2011, 18:12
- - halb27   So I stick with special behavior for -V0 until a r...   Oct 21 2011, 22:24
|- - Thorolf   QUOTE (halb27 @ Oct 21 2011, 22:24) So I ...   Nov 6 2011, 13:30
|- - db1989   QUOTE (Thorolf @ Nov 6 2011, 12:30) I use...   Nov 6 2011, 18:17
|- - Thorolf   QUOTE (db1989 @ Nov 6 2011, 18:17) QUOTE ...   Nov 6 2011, 18:44
- - halb27   I was on holidays for 14 days, and away from the 3...   Nov 6 2011, 14:31
|- - Thorolf   QUOTE (halb27 @ Nov 6 2011, 14:31) As for...   Nov 6 2011, 14:39
|- - kode54   QUOTE (Thorolf @ Nov 6 2011, 06:39) (Set ...   Nov 6 2011, 18:11
- - halb27   It's MAC OS stuff, anyway. Sorry, I am not abl...   Nov 6 2011, 20:31
|- - db1989   QUOTE (halb27 @ Nov 6 2011, 19:31) It...   Nov 6 2011, 22:24
- - ShotCaller   I'm looking forward to 3.99x. Thanks for your ...   Nov 7 2011, 23:02
- - ShotCaller   Any update on 3.99x halb? Or are you waiting for t...   Nov 19 2011, 19:39
- - halb27   Sorry, after having come back from holidays I had ...   Nov 20 2011, 12:24
- - ShotCaller   Whenever you have the time mate. I'm looking f...   Nov 23 2011, 02:54

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:


RSS Lo-Fi Version Time is now: 24th April 2014 - 12:04