IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Different replaygain values when using LAME CBR/VBR, Noted in versions LAME 3.98 & 3.99
Destroid
post Jun 29 2012, 20:07
Post #1





Group: Members
Posts: 544
Joined: 4-June 02
Member No.: 2220



I came across this discrepancy while I was hastily performing an encoding speed test after reading this post since I knew that CBR was slower, but in my rush I forgot to add the switch --noreplaygain that I usually use.
CODE
D:\sounds\test>lame3984.exe -b128 bt.wav bt-3984.mp3

LAME 3.98.4 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding bt.wav to bt-3984.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
90813/90813 (100%)| 2:50/ 2:50| 2:50/ 2:50| 13.954x| 0:00
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
128.0 17.6 82.4 97.9 1.3 0.8
Writing LAME Tag...done
ReplayGain: -8.5dB

D:\sounds\test>lame3984.exe -V 5 bt.wav bt-3984-v5.mp3

LAME 3.98.4 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding bt.wav to bt-3984-v5.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=5)
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
90813/90813 (100%)| 1:51/ 1:51| 1:51/ 1:51| 21.273x| 0:00
32 [ 430] %
40 [ 11] %
48 [ 18] %
56 [ 18] *
64 [ 22] %
80 [ 79] %
96 [ 840] %*
112 [ 8674] %%*************
128 [27558] %%%%%%%%%%%%**********************************
160 [40317] %%%%%%%%%%%%%%%%%%%%%**********************************************
192 [ 7945] %%%***********
224 [ 3045] %%****
256 [ 1153] %*
320 [ 703] %*
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
151.8 24.9 75.1 93.0 3.9 3.0
Writing LAME Tag...done
ReplayGain: -8.9dB

D:\sounds\test>lame3995.exe -b128 bt.wav bt-3995.mp3

LAME 3.99.5 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding bt.wav to bt-3995.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
90813/90813 (100%)| 2:32/ 2:32| 2:32/ 2:32| 15.546x| 0:00
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
128.0 24.9 75.1 97.7 1.3 1.0
Writing LAME Tag...done
ReplayGain: -8.5dB

D:\sounds\test>lame3995.exe -V 5 bt.wav bt-3995-v5.mp3

LAME 3.99.5 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding bt.wav to bt-3995-v5.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=5)
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
90813/90813 (100%)| 1:49/ 1:49| 1:49/ 1:49| 21.575x| 0:00
32 [ 547] %
40 [ 38] %
48 [ 32] %
56 [ 29] %
64 [ 92] %
80 [ 274] %
96 [ 978] %*
112 [ 4931] %*****
128 [60565] %%%%%%%%%%%%%%%%%%%%***********************************************
160 [17204] %%%%%%%%************
192 [ 3207] %***
224 [ 1767] %*
256 [ 1094] %*
320 [ 55] %
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
137.8 29.8 70.2 93.0 3.9 3.0
Writing LAME Tag...done
ReplayGain: -8.9dB
I am aware that a 0.4dB difference is audibly negligible in general, and now I'm in a rush to leave the computer as I post this (so I would appreciate less hair-splitting over my possible grammar errors as this is my busiest time of the year).

I require CBR since I am unfortunate to have one player that screws up VBR. In most cases it plays 90% files OK but many songs do not play to the end of the song (it seems to calculate the bitrate incorrectly, similar to WinXP's native MP3 support, where it apparently assumes the bitrate of the beginning of the file is the average overall bitrate).

FYI smile.gif


--------------------
"Something bothering you, Mister Spock?"
Go to the top of the page
+Quote Post
robert
post Jun 29 2012, 21:19
Post #2


LAME developer


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



ABR/CBR modes apply some scaling to the input data.

http://www.hydrogenaudio.org/forums/index....st&p=323063
Go to the top of the page
+Quote Post
saratoga
post Jun 29 2012, 21:20
Post #3





Group: Members
Posts: 4718
Joined: 2-September 02
Member No.: 3264



MP3 is a lossy format, so using different bitrates will give you different audio and thus different replaygain values.
Go to the top of the page
+Quote Post
greynol
post Jun 29 2012, 21:34
Post #4





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



I thought ReplayGain was computed on the source data by default and only on the decoded stream when --replaygain-accurate is used. I did notice what the documentation included something on scaling, but it specifically mentioned that the scaling was "user-specified."

OT: Proper subject/verb agreement seems to be one of those things that is going by the wayside these days, at least in English-speaking countries and especially in my country which I find shameful. In the name of "American Exceptionalism" (no offense to non-English-speaking Americans, especially to those who do not live in the United States) I would like to think we can do better! biggrin.gif

This post has been edited by greynol: Jun 29 2012, 21:45


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
robert
post Jun 29 2012, 22:17
Post #5


LAME developer


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



QUOTE (greynol @ Jun 29 2012, 21:34) *
I thought ReplayGain was computed on the source data by default and only on the decoded stream when --replaygain-accurate is used.

That's correct. By default Replaygain is computed from the transformed input data. Possible transformations are scaling, swapping left/right channels, downmixing to mono, resampling.
Go to the top of the page
+Quote Post
greynol
post Jun 30 2012, 01:10
Post #6





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



Just to clarify, is it safe to assume that this includes data scaled as a result of the cbr/abr process and as such the scaling is not explicitly user-specified?


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
robert
post Jun 30 2012, 07:53
Post #7


LAME developer


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



At that monent, as ABR/CBR presets became default, scaling is part of the ABR/CBR process (the amount depends on the bitrate). The reasoning behind it is explained by Gabriel, under the link, which i posted above.

Adding --verbose to your command line will show you the scaling value used.
Adding --scale X will overrule the scaling from the presets.
VBR presets don't use scaling.

http://lame.cvs.sourceforge.net/viewvc/lam...amp;view=markup

CBR/ABR <= 160 -> 0.95
CBR/ABR == 192 -> 0.97
CBR/ABR == 224 -> 0.98
CBR/ABR >= 256 -> 1.00
Go to the top of the page
+Quote Post
db1989
post Jun 30 2012, 10:07
Post #8





Group: Super Moderator
Posts: 5171
Joined: 23-June 06
Member No.: 32180



Could I request a relatively simple explanation of why CBR/ABR are at risk of creating (audible) clipping whereas VBR is not affected (at least not to a degree that warrants a fix)?

timcupery said that “samples encoded at lower quality levels will have more variation in peak sample values”, which sounds plausible, but why would this not apply to VBR in just the same way?
Go to the top of the page
+Quote Post
lvqcl
post Jun 30 2012, 11:14
Post #9





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



Ten years ago:

QUOTE (Dibrom @ Apr 7 2002, 01:46) *
The --alt-preset VBR modes are never going to include a scale switch. The reasons for this are:

1. Clipping with VBR is much less of a problem than with ABR and CBR, meaning that it should very rarely be audible.
2. mp3gain is a much better way of handling this than scale.


QUOTE (Dibrom @ Oct 31 2002, 01:16) *
Scale is not included in the vbr presets, because vbr in LAME doesn't have the horrible problems with clipping that abr does, especially as bitrate decreases.
[...]
The only reason the abr include a fixed scale value is because this is the value that the majority of severely audible clipping seemed to go away on most of the samples tested.

Go to the top of the page
+Quote Post
Zarggg
post Jul 4 2012, 17:51
Post #10





Group: Members
Posts: 533
Joined: 18-January 04
From: bethlehem.pa.us
Member No.: 11318



I think db1989 asked why clipping is not an issue with VBR. Even if he didn't, I am. smile.gif

This post has been edited by Zarggg: Jul 4 2012, 17:53
Go to the top of the page
+Quote Post
db1989
post Jul 4 2012, 23:18
Post #11





Group: Super Moderator
Posts: 5171
Joined: 23-June 06
Member No.: 32180



Yep! Although I appreciate the information lvqcl already provided, I’m also interested in a more mechanistic explanation.
Go to the top of the page
+Quote Post
Destroid
post Jul 5 2012, 00:06
Post #12





Group: Members
Posts: 544
Joined: 4-June 02
Member No.: 2220



Ok, scalefactor. I vaguely remember it from the --alt-preset days/R3mix days rolleyes.gif. Maybe I imagined the replaygain result would be the same no matter which mode LAME used (such as, it was calculated from the input material, but I digress from this particular viewpoint).

Not to change issue, but the whole reason of me using CBR was my player would not play some songs to the very end. Can anyone else with 'VBR issues' relate to this? If my hypothesis in the OP is correct I would like to see how my player would negotiate a VBR file where the first frame was null/dummy having a bitrate equal or lesser to the overall average bitrate of the file. (I imagine it would screw up gapless but this player can't negotiate that either, nor replaygain, of course.)

Back to the main issue:
QUOTE (Zarggg @ Jul 4 2012, 16:51) *
why clipping is not an issue with VBR.

2. Is the slower speed of encoding by CBR also related to (what appears to be) compromises made to stay within boundaries of a specified bitrate (of less than 256kbps)?

edit: grammar tongue.gif

This post has been edited by Destroid: Jul 5 2012, 00:09


--------------------
"Something bothering you, Mister Spock?"
Go to the top of the page
+Quote Post
halb27
post Jul 5 2012, 08:01
Post #13





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



If player problems with VBR are the issue you have more options besides plain -b 128 or plain -V5:

a) -V5 -b 128 -B 128 -F thus restricting frame size to 128 kbps frames but still using the VBR audio data production machinery. Quality can be better than that produced by CBR 128. Not clear though whether or not clipping can occur like with CBR because of the restricted frame bitrate as it has not become clear yet for what specific reasons CBR/ABR is more clipping prone than VBR is.

b) use -V5 and have Omion's mp3repacker tool losslessly create a CBR file from the -V5 file. You have to accept though that resulting CBR bitrate can get higher than 128 kbps depending on your music.

This post has been edited by halb27: Jul 5 2012, 08:05


--------------------
lame3100m --bCVBR 300
Go to the top of the page
+Quote Post
pdq
post Jul 5 2012, 13:08
Post #14





Group: Members
Posts: 3309
Joined: 1-September 05
From: SE Pennsylvania
Member No.: 24233



QUOTE (Destroid @ Jul 4 2012, 19:06) *
2. Is the slower speed of encoding by CBR also related to (what appears to be) compromises made to stay within boundaries of a specified bitrate (of less than 256kbps)?

As I understand it (and I am no expert), in CBR mode the encoder tries encoding at a quality level that should produce near the target bitrate. If the result is either too high or too low bitrate then it tries another, etc., until it has an encoding that best matches the traget. As I recall, the -q switch sets how many iterations to try before settling on an encoding.

In VBR mode, the only reason to try a different quality level is if more than 320 kbps would be required, or the bitrate would exceed the -B switch setting.
Go to the top of the page
+Quote Post
db1989
post Jul 5 2012, 13:19
Post #15





Group: Super Moderator
Posts: 5171
Joined: 23-June 06
Member No.: 32180



QUOTE (pdq @ Jul 5 2012, 13:08) *
As I understand it (and I am no expert), in CBR mode the encoder tries encoding at a quality level that should produce near the target bitrate. If the result is either too high or too low bitrate then it tries another, etc., until it has an encoding that best matches the traget. As I recall, the -q switch sets how many iterations to try before settling on an encoding.
I’m pretty sure you’re thinking of ABR here, not CBR! wink.gif
Go to the top of the page
+Quote Post
lvqcl
post Jul 5 2012, 14:54
Post #16





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



For LAME, CBR is just more restrained ABR, with only one frame size allowed...

QUOTE (robert @ Mar 31 2010, 15:33) *
CBR/ABR: the target bitrate is given, the quantization step sizes are adjusted until the target bitrate is reached. LAME does this by in-/decreasing the global gain and evaluating the quantization noise
...
VBR: the target quantization noise within the sfbs is given, the quantization step sizes are choosen such that they result in given quantization noise.

Go to the top of the page
+Quote Post
timcupery
post Jul 5 2012, 16:54
Post #17





Group: Members
Posts: 780
Joined: 19-December 01
From: Tar Heel country
Member No.: 683



Interesting to see this pop up again.

if you want to use CBR or ABR and want scale to be specific, you can always use --scale n as part of the LAME commandline (e.g., --cbr 160 --scale 1)


--------------------
God kills a kitten every time you encode with CBR 320
Go to the top of the page
+Quote Post

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: 23rd April 2014 - 12:04