Skip to main content

Topic: Different replaygain values when using LAME CBR/VBR (Read 4198 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • Destroid
  • [*][*][*][*][*]
Different replaygain values when using LAME CBR/VBR
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: [Select]
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
"Something bothering you, Mister Spock?"

  • robert
  • [*][*][*][*][*]
  • Developer
Different replaygain values when using LAME CBR/VBR
Reply #1
ABR/CBR modes apply some scaling to the input data.

http://www.hydrogenaudio.org/forums/index....st&p=323063

  • saratoga
  • [*][*][*][*][*]
Different replaygain values when using LAME CBR/VBR
Reply #2
MP3 is a lossy format, so using different bitrates will give you different audio and thus different replaygain values.

  • greynol
  • [*][*][*][*][*]
  • Global Moderator
Different replaygain values when using LAME CBR/VBR
Reply #3
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!
  • Last Edit: 29 June, 2012, 04:45:44 PM by greynol
Your eyes cannot hear.

  • robert
  • [*][*][*][*][*]
  • Developer
Different replaygain values when using LAME CBR/VBR
Reply #4
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.

  • greynol
  • [*][*][*][*][*]
  • Global Moderator
Different replaygain values when using LAME CBR/VBR
Reply #5
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.

  • robert
  • [*][*][*][*][*]
  • Developer
Different replaygain values when using LAME CBR/VBR
Reply #6
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

  • db1989
  • [*][*][*][*][*]
  • Global Moderator
Different replaygain values when using LAME CBR/VBR
Reply #7
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?

  • lvqcl
  • [*][*][*][*][*]
  • Developer
Different replaygain values when using LAME CBR/VBR
Reply #8
Ten years ago:

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.


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.


  • Zarggg
  • [*][*][*][*][*]
Different replaygain values when using LAME CBR/VBR
Reply #9
I think db1989 asked why clipping is not an issue with VBR. Even if he didn't, I am.
  • Last Edit: 04 July, 2012, 12:53:02 PM by Zarggg

  • db1989
  • [*][*][*][*][*]
  • Global Moderator
Different replaygain values when using LAME CBR/VBR
Reply #10
Yep! Although I appreciate the information lvqcl already provided, I’m also interested in a more mechanistic explanation.

  • Destroid
  • [*][*][*][*][*]
Different replaygain values when using LAME CBR/VBR
Reply #11
Ok, scalefactor. I vaguely remember it from the --alt-preset days/R3mix days  . 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:
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
  • Last Edit: 04 July, 2012, 07:09:47 PM by Destroid
"Something bothering you, Mister Spock?"

  • halb27
  • [*][*][*][*][*]
Different replaygain values when using LAME CBR/VBR
Reply #12
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.
  • Last Edit: 05 July, 2012, 03:05:14 AM by halb27
lame3995n -Q0.5

  • pdq
  • [*][*][*][*][*]
Different replaygain values when using LAME CBR/VBR
Reply #13
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.

  • db1989
  • [*][*][*][*][*]
  • Global Moderator
Different replaygain values when using LAME CBR/VBR
Reply #14
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!

  • lvqcl
  • [*][*][*][*][*]
  • Developer
Different replaygain values when using LAME CBR/VBR
Reply #15
For LAME, CBR is just more restrained ABR, with only one frame size allowed...

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.


  • timcupery
  • [*][*][*][*][*]
Different replaygain values when using LAME CBR/VBR
Reply #16
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