IPB

Welcome Guest ( Log In | Register )

3 Pages V   1 2 3 >  
Reply to this topicStart new topic
Changing minimum bitrate for VBR (LAME 3.98.3)
Aleron Ives
post Mar 22 2010, 01:11
Post #1





Group: Members
Posts: 189
Joined: 22-March 10
From: California
Member No.: 79208



I've been experimenting with various VBR options, and I'm slightly confused as to how LAME decides what birate to use for each frame. As I understand it, LAME will try different bitrates and select the lowest bitrate that achieves acceptable quality. When using -V 2, the general output is ~192 Kbps, but when altering the -b switch, the output results do not match what I would expect. On my particular test file, when using:

lame -V 2 <input> <output> I get:



Now, as I understand how VBR works, frames are encoded at a bitrate higher than 192 Kbps when LAME feels that their complexity warrants it. Less complex frames are encoded at a lower bitrate to save space without, presumably, sacrificing perceived quality. If, however, one wanted to be paranoid and not trust LAME's judgement on which frames can safely be encoded at less than 192 Kbps, setting -b 192 would raise the threshold to "guarantee" 192 Kbps quality or greater at the expense of efficient compression. I would assume that encoding this way could be seen as CBR+, i.e. you always get the minimum quality afforded by your minimum bitrate, while unlike CBR, VBR still allows LAME to exceed that bitrate when necessary. Consequently, my assumption would be that adding -b 192 to the mix would cause all the frames encoded at less than 192 Kbps to instead be encoded at 192, since it's the new minimum bitrate (except for silence). I would also assume that the number of frames encoded at a bitrate higher than 192 Kbps would remain unchanged, as those frames would still be complex enough to warrant a higher bitrate. However, when I use:

lame -V 2 -b 192 <input> <output> on my test file, I get:



My question, therefore, is why has the number of frames encoded at 224, 256, and 320 Kbps actually decreased instead of remaining the same? My only guess is that this comes from LAME attempting to maintain the desired quality level associated with -V 2, and since it cannot use bitrates less than 192, its only option is to reduce the number of times it uses higher bitrates so that the average can remain closer to 192. This, however, sounds like what ABR mode does, so I do not see why VBR mode would act this way. Is there a switch combination that would produce the result I expected, or am I misunderstanding the way VBR works and consequently such a result is impossible? Either way, thanks for reading and any guidance you can provide.
Go to the top of the page
+Quote Post
DreamTactix291
post Mar 22 2010, 01:18
Post #2





Group: Members (Donating)
Posts: 552
Joined: 9-June 04
From: A place long since forgotten...
Member No.: 14572



My guess would be when you change the minimum bitrate to -b192 that the encoder uses the bit reservoir more liberally in an attempt to not balloon the size up as much since it can not use smaller than 192kbps frames.

This post has been edited by DreamTactix291: Mar 22 2010, 01:23


--------------------
Nero AAC 1.5.1.0: -q0.45
Go to the top of the page
+Quote Post
Aleron Ives
post Mar 22 2010, 01:36
Post #3





Group: Members
Posts: 189
Joined: 22-March 10
From: California
Member No.: 79208



QUOTE (DreamTactix291 @ Mar 21 2010, 16:18) *
My guess would be when you change the minimum bitrate to -b192 that the encoder uses the bit reservoir more liberally in an attempt to not balloon the size up as much since it can not use smaller than 192kbps frames.

That's an interesting theory. If I understand the purpose of the bit reservoir correctly, this would mean that the quality would be equal to my expected result while the file size remains low? If so, it would seem that I have underestimated LAME's ingenuity.
Go to the top of the page
+Quote Post
robert
post Mar 22 2010, 01:52
Post #4


LAME developer


Group: Developer
Posts: 788
Joined: 22-September 01
Member No.: 5



When using LAME in VBR mode, setting a low bitrate minimum doesn't affect audio quality. The minimum bitrate setting is used after encoding the frame, when audio data gets packaged into sufficient sized frames.
Go to the top of the page
+Quote Post
Aleron Ives
post Mar 22 2010, 02:30
Post #5





Group: Members
Posts: 189
Joined: 22-March 10
From: California
Member No.: 79208



I see. Does that then mean that there is no way to raise the minimum bitrate in VBR mode in respect to audio quality?
Go to the top of the page
+Quote Post
halb27
post Mar 22 2010, 09:03
Post #6





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



QUOTE (robert @ Mar 22 2010, 01:52) *
When using LAME in VBR mode, setting a low bitrate minimum doesn't affect audio quality. The minimum bitrate setting is used after encoding the frame, when audio data gets packaged into sufficient sized frames.

Yes, and we had the same question in the lame command line thread.
Only thing I do't understand: why is audio data stream not exactly the same when using -Vx -b nnn as with plain -Vx? (I tried last night - foobar said that there is a difference, and peak difference isn't small).


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
onkl
post Mar 22 2010, 09:37
Post #7





Group: Members
Posts: 125
Joined: 27-February 09
From: Germany
Member No.: 67444



[wild speculation]

Probably because the bit-reservoir is full (with wasted bits) most of the time and therefore it's not needed to go to higher bitrates that often. Without a minimum bitrate the reservor is empty or quite small since the encoder uses the smallest possible framesize.

So I guess minimum bitrate will smooth "quality peaks" out in terms of framesize. Maybe it can even improve quality for rare cases when frames exceed 320kbit and would otherwise have no bit-reservor to add extra bits. In that case it could make sense to add some kind of 2-pass encoding that increases frames that come before difficult passages to have a full bit-reservoir.

How big can the reservoir become? Is it even possible to add it to 320kbit frames?

This post has been edited by onkl: Mar 22 2010, 09:57
Go to the top of the page
+Quote Post
Aleron Ives
post Mar 22 2010, 10:54
Post #8





Group: Members
Posts: 189
Joined: 22-March 10
From: California
Member No.: 79208



What I don't understand is why there isn't at least the possibility of forcing LAME to use only bitrates greater than or equal to a certain value, if for some reason you want to ensure/maximize quality at the expense of file size. Since LAME can occasionally select the wrong bitrate in VBR mode, it seems like it would be a good failsafe to allow such a behaviour "just in case" and for the overly paranoid.

From the LAME documentation:

QUOTE
*NOTE* No psy-model is perfect, so there can often be distortion which
is audible even though the psy-model claims it is not! Thus using a
small minimum bitrate can result in some aggressive compression and
audible distortion even with -V 0. Thus using -V 0 does not sound
better than a fixed 256 kbps encoding. For example: suppose in the 1 kHz
frequency band the psy-model claims 20 dB of distortion will not be
detectable by the human ear, so LAME VBR-0 will compress that
frequency band as much as possible and introduce at most 20 dB of
distortion. Using a fixed 256 kbps framesize, LAME could end up
introducing only 2 dB of distortion. If the psy-model was correct,
they will both sound the same. If the psy-model was wrong, the VBR-0
result can sound worse.


Since the psy-model can be wrong, from what I'm reading in this topic, if you do happen to encounter a file that gets encoded with audible artifacts even at -V 0, your only option is to use -b 320 -q 0 instead. I realize that the chances of this happening at high bitrates like those used with -V 0/1/2 are unlikely, but still. tongue.gif
Go to the top of the page
+Quote Post
ojdo
post Mar 22 2010, 10:57
Post #9





Group: Members
Posts: 894
Joined: 18-June 06
From: Germany
Member No.: 31980



QUOTE (Aleron Ives @ Mar 22 2010, 10:54) *
[lossy codec] for the overly paranoid.

I think the overly paranoid should simply use a lossless codec instead.


--------------------
http://freemusi.cc/
Go to the top of the page
+Quote Post
Bodhi
post Mar 22 2010, 11:06
Post #10





Group: Members
Posts: 261
Joined: 10-June 06
Member No.: 31712



QUOTE (robert @ Mar 22 2010, 01:52) *
When using LAME in VBR mode, setting a low bitrate minimum doesn't affect audio quality.

Are you talking about the "psychological" audio quality?

Because in this case (Aleron Ives example), it does affect the bitrate (and then the quality) since it goes from 193 to 201 Kbps!

This post has been edited by Bodhi: Mar 22 2010, 11:45
Go to the top of the page
+Quote Post
robert
post Mar 22 2010, 11:25
Post #11


LAME developer


Group: Developer
Posts: 788
Joined: 22-September 01
Member No.: 5



QUOTE (onkl @ Mar 22 2010, 09:37) *
How big can the reservoir become? Is it even possible to add it to 320kbit frames?

Your speculation is right. The bit reservoir can grow up to 4088 bits. A 320 kbps frame, plus maximum previously unused bits from the reservoir, can result in a ~470 kbps peak. (use 3.99 and add --buffer-constraint maximum -b320, after encoding feed it into mp3repacker to make it VBR again)
Go to the top of the page
+Quote Post
robert
post Mar 22 2010, 11:32
Post #12


LAME developer


Group: Developer
Posts: 788
Joined: 22-September 01
Member No.: 5



QUOTE (halb27 @ Mar 22 2010, 09:03) *
Only thing I do't understand: why is audio data stream not exactly the same when using -Vx -b nnn as with plain -Vx? (I tried last night - foobar said that there is a difference, and peak difference isn't small).

What onkl said.
Go to the top of the page
+Quote Post
robert
post Mar 22 2010, 11:37
Post #13


LAME developer


Group: Developer
Posts: 788
Joined: 22-September 01
Member No.: 5



QUOTE (Aleron Ives @ Mar 22 2010, 10:54) *
Since LAME can occasionally select the wrong bitrate in VBR mode, it seems like it would be a good failsafe to allow such a behaviour "just in case" and for the overly paranoid.

How do you determine the "occasionally wrong selected bitrate in VBR mode" ? Eye or ABX ?
When by eye, how do you know that a 32 kbps frame doesn't refer to 180 kbps of audio data ?
Go to the top of the page
+Quote Post
robert
post Mar 22 2010, 12:40
Post #14


LAME developer


Group: Developer
Posts: 788
Joined: 22-September 01
Member No.: 5



QUOTE (Aleron Ives @ Mar 22 2010, 01:11) *
I've been experimenting with various VBR options, and I'm slightly confused as to how LAME decides what birate to use for each frame. As I understand it, LAME will try different bitrates and select the lowest bitrate that achieves acceptable quality.

LAME doesn't try bit-rates in VBR mode, well it actually worked that way in its very first incarnation, until mid 1999. LAME's psy model determines how much quantization noise is allowed, what block-type to select and how two channels are best represented. In VBR mode LAME encodes a frame with the allowed amount of quantization noise, and picks the smallest frame large enough to hold the audio data. In CBR mode, frame size is fix and bitrate distribution among granules and channels is determined by the psy model, and LAME tries to minimize the quantization noise until the desired bitrate is reached. (Note: current VBR uses a slightly different psy-model than for CBR)
Go to the top of the page
+Quote Post
halb27
post Mar 22 2010, 15:59
Post #15





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



QUOTE (robert @ Mar 22 2010, 11:32) *
QUOTE (halb27 @ Mar 22 2010, 09:03) *
Only thing I do't understand: why is audio data stream not exactly the same when using -Vx -b nnn as with plain -Vx? (I tried last night - foobar said that there is a difference, and peak difference isn't small).

What onkl said.

So is this correct?:
When using -V0 -b 320 there can be situations where the audio stream determined by the VBR mechanism can be placed into the current frame + bit reservoir of the previous frame(s), but it has to be simplified a bit in the case of pure -V0 due to lacking space.

So for those who don't care about the slightly increased encoding time but are nitpicking about quality: it's a good idea to use -V0 -b 320 and afterwards mp3repack the output to get rid of the unused space!?

This post has been edited by halb27: Mar 22 2010, 16:41


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
Steve Forte Rio
post Mar 22 2010, 16:50
Post #16





Group: Members
Posts: 453
Joined: 4-October 08
From: Ukraine
Member No.: 59301



I think -b 320 -q 0 will be better idea...

Audible differences (on problem samples) between -V 0 and -V 0 -b 320 is much smaller than between -V 0 and -b 320 -q 0

For me VBR sounds too bad with any settings

-V 0 vs -V 0 -b 320

This post has been edited by Steve Forte Rio: Mar 22 2010, 16:53
Go to the top of the page
+Quote Post
halb27
post Mar 22 2010, 17:11
Post #17





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



CBR 320 takes roughly 100 kbps more on average than -V0 -b 320 | mp3packer. Other than that -V0 can produce better quality than CBR320 with specific samples as was found by I guess it was /mnt.

I was talking about potential quality impovement on (rare) occasion of -V0 -b 320 | mp3packer over plain -V0. Bitrate of these variants are nearly identical on average.

This post has been edited by halb27: Mar 22 2010, 17:12


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
Steve Forte Rio
post Mar 22 2010, 17:17
Post #18





Group: Members
Posts: 453
Joined: 4-October 08
From: Ukraine
Member No.: 59301



QUOTE (halb27 @ Mar 22 2010, 14:11) *
I was talking about potential quality impovement on (rare) occasion of -V0 -b 320 | mp3packer over plain -V0. Bitrate of these variants are nearly identical on average.


You're right. See my testing results, I've got little average bitrate increase (+10 kbps) and some quality improvement. smile.gif
But I'm not sure that quality improvement is possible without avg bitrate increase... I think it must be some bitrate redistribution (which requires psy model changes. or not?) to achieve higher quality with same file size

QUOTE
-V0 can produce better quality than CBR320 with specific samples


Does anyone can to provide this samples? smile.gif

This post has been edited by Steve Forte Rio: Mar 22 2010, 17:32
Go to the top of the page
+Quote Post
halb27
post Mar 22 2010, 17:41
Post #19





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



Here is /mnt's post with the sample.
It was done with 3.98.2 though as the discussion in february about max bit reservoir/buffer size for 320 kbps frames led to the improvement robert gave us with 3.98.3. But that was later.

Bitrate difference for regular music (my standard test set of various kind of popular music):

-V0: 227 kbps
-V0 -b 320 | mp3packer: 234 kbps

I just ABXed eig -V0 against -V0 -b 320 | mp3packer. It wasn't difficult, -V0 -b 320 | mp3packer is clearly better.

I also tried the -V0 --ns-xxx variant I recently used, together with -b 320. It was clearly worse than -V0 -b 320. Obviously the generally increased quality demand by using --ns-xxx doesn't allow for high audio data bitrate when it's needed due to lack of space. Without -b 320 things should be even worse. So at least for pre-echo prone stuff it's not a good idea.

This post has been edited by halb27: Mar 22 2010, 17:56


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
lvqcl
post Mar 22 2010, 17:59
Post #20





Group: Developer
Posts: 3383
Joined: 2-December 07
Member No.: 49183



I encoded eig.wav with -V0 and -V0 -b320 settings:

-V0:
469127 bytes of MP3 data (249.427333 kbps) = minimum bitrate possible
Largest frame uses 9501 bits = 1188 bytes = 363.710156 kbps

-V0 -b320:
484181 bytes of MP3 data (257.431304 kbps) = minimum bitrate possible
Largest frame uses 10976 bits = 1372 bytes = 420.175000 kbps
Go to the top of the page
+Quote Post
halb27
post Mar 22 2010, 18:10
Post #21





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



@robert:

Would it be a difficult change if frame bitrate was always chosen in such a way that bit reservoir is always kept close to maximum when using -Vx (without -b n)?
That would keep available space for the audio data stream at maximum and wouldn't increase bitrate over what is needed by the VBR mechanism. It just inhibits reducing quality considered necessary due to lacking space (resp. restricts it only to the limits of the audio data stream given by the mp3 format).


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
Steve Forte Rio
post Mar 22 2010, 18:23
Post #22





Group: Members
Posts: 453
Joined: 4-October 08
From: Ukraine
Member No.: 59301



QUOTE
Largest frame uses 10976 bits = 1372 bytes = 420.175000 kbps


And now, who will explain me how frame can use 420 kbps when the largest possible bitrate for frame is 320?

This post has been edited by Steve Forte Rio: Mar 22 2010, 18:24
Go to the top of the page
+Quote Post
greynol
post Mar 22 2010, 18:31
Post #23





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



You know what a bit reservoir is, right?

This post has been edited by greynol: Mar 22 2010, 20:23


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
Steve Forte Rio
post Mar 22 2010, 18:39
Post #24





Group: Members
Posts: 453
Joined: 4-October 08
From: Ukraine
Member No.: 59301



I don't fully understand what a bit reservoir really means and how it works in reality...
Where reserved bits are "physically" located? In previous frames?

This post has been edited by Steve Forte Rio: Mar 22 2010, 18:49
Go to the top of the page
+Quote Post
greynol
post Mar 22 2010, 18:49
Post #25





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



And in frames that follow as well, I believe; that's correct. The unused portion of a frame can hold data for other frames. The point of VBR is to minimize the reservoir. Mp3packer is designed to use the reservoir as efficiently as possible.


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post

3 Pages V   1 2 3 >
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: 21st September 2014 - 23:03