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: 2489
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 -V1 --insane_factor 0.75
Go to the top of the page
+Quote Post
Start new topic
post Nov 20 2011, 12:24
Post #2

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

Sorry, after having come back from holidays I had to do other things. Maybe I also hesitated a bit because before my holidays I started some work on 3.98.4x in order to bring the amount of inaccurate frames further down, and now that I decided to discontinue 3.98.4x had problems to make up my mind whether to continue this work with 3.98.4x or 3.99. And, yes, the current discussion about 3.99's Lame header had an influence on it.

But I have gone back to work since several days having decided to do the final work with 3.98.4x and switch to 3.99x afterwards. Not a bad decision as Robert has come out now with 3.99.2 and the old Lame header strategy.
The final 3.98.4x work will be finished soon, and I can say already that I succeeded in bringing down the number of inaccurate frames to a further extent. I guess this will be important to bring over to 3.99x as the job of avoiding inaccurate frames will be harder there.

This post has been edited by halb27: Nov 20 2011, 12:25

lame3100m -V1 --insane_factor 0.75
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: 27th November 2015 - 00:13