Skip to main content

Topic: dB losses on mp3 encoding with Lame (Read 3104 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • timcupery
  • [*][*][*][*][*]
dB losses on mp3 encoding with Lame
Awhile back I started to notice that mp3's that I had encoded with Lame on ABR and CBR settings had slightly different replaygain values than those that were encoded with VBR preset settings. A related discussion has recently arisen in this thread. Anyway, back when I noticed this, I carried out a few tests to determine how much volume was being lost upon encoding with Lame ABR and CBR settings. Here's what I did:
* took a selection of 30-second wav files (folk/pop/rock sort of stuff) and used wavegain to adjust the volume - one set was done track by track (so each track was at 89 dB) and the other set as an album. So, both groups had an album volume of exactly 89 dB, and one group had every song exactly at 89 dB
* encoded these tracks at various ABR and CBR settings
* decoded these mp3's using foobar (tried dither and no dither, which didn't affect the volume at all of course, so mainly stuck with no dither because it's faster)
* used wavegain to test the volume values of the individual tracks, and of the tracks as an album (since both groups of wav files should have been exactly 89 dB album volume)

General findings:
* The amount of volume lost wasn't exact at a given encoder setting - it varied within a range of +/-5 dB, usually. The range (and thus the standard deviation) was tigher at higher bitrates.
* Higher bitrates had less volume loss.
* Variation in dB loss from song to song (in the second group, where the song volumes varied) did not appear to be correlated with volume. So, a wav file with a volume of 98 dB should lose the same amount of volume upon encoding with --preset 128 as a wav file with a volume of 92 dB.
* Using --scale 1 did not guarantee exactly equivalent volume; the songs still varied within a range, but given a sufficiently large sample the mean deviation was 0 dB.

Specific findings - volume loss at given settings:
--preset (abr) 128 - lost 0.58 dB avg, range 0.54 to 0.65 dB
--preset cbr 128 - lost 0.60 dB avg
--preset 128 --scale 1 - lost 0.00 dB avg, range -0.08 to +0.03
--preset 136 -b 128 - lost 0.61 dB avg, range 0.54 to 0.69 dB
--preset 145 - lost 0.43 dB, range 0.41 to 0.47 dB
--preset 160 - lost 0.44 dB, range 0.42 to 0.47 dB
--preset cbr 160 - lost 0.44 dB, range 0.41 to 0.46 dB
--preset 176 - lost 0.26 dB, range 0.21 to 0.34 dB
--preset 192 - lost 0.25 dB, range 0.23 to 0.30 dB
--preset cbr 192 - lost 0.26 dB, range 0.22 to 0.31

Note that this was done over a year ago, and I think I was using Lame 3.92 or 3.95. However, I have no reason to believe things would be different with 3.90.3 or 3.96.1 or 3.97alphas.
Overall, this doesn't matter for people who are encoding using VBR presets, but it might be useful if you have other mp3's sitting around from Lame abr and cbr encodes.

edit: formatting
  • Last Edit: 27 August, 2005, 02:29:58 PM by timcupery
God kills a kitten every time you encode with CBR 320

  • Gabriel
  • [*][*][*][*][*]
  • Developer
dB losses on mp3 encoding with Lame
Reply #1
http://cvs.sourceforge.net/viewcvs.py/lame...=1.54&view=auto
You can see there that there is a scaling done in abr.cbr, up to 256kbps where the scaling is then 1.
This is to prevent clipping that was otherwise noticed on abr/cbr. Other differences are probably caused by the lowpass filtering.

  • Axon
  • [*][*][*][*][*]
  • Members (Donating)
dB losses on mp3 encoding with Lame
Reply #2
Yuck yuck yuck. So can I add --scale 1 if I know I have ReplayGain somewhere in the chain (and I know it's negative enough to avoid clipping), and this will go away?

  • Gabriel
  • [*][*][*][*][*]
  • Developer
dB losses on mp3 encoding with Lame
Reply #3
Yes, but anyway if you are using replaygain latter, this will not change anything for you.

  • timcupery
  • [*][*][*][*][*]
dB losses on mp3 encoding with Lame
Reply #4
Quote
http://cvs.sourceforge.net/viewcvs.py/lame...=1.54&view=auto
You can see there that there is a scaling done in abr.cbr, up to 256kbps where the scaling is then 1.
This is to prevent clipping that was otherwise noticed on abr/cbr. Other differences are probably caused by the lowpass filtering.
[a href="index.php?act=findpost&pid=323063"][{POST_SNAPBACK}][/a]

Yeah, I figured that this was done to prevent clipping, as samples encoded at lower quality levels will have more variation in peak sample values. Good to have that confirmed. Thanks.
God kills a kitten every time you encode with CBR 320