dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: mp3gain vs. replaygain

mp3gain vs. replaygain

From: Matthias Wächter <>
Date: Mon, 19 Aug 2002 16:18:48 +0200 (CEST)

On Mon, 19 Aug 2002, Mat Pritchard wrote:

> > MP> Errm, my reading of this is that the player needs to interpret the gain
> > MP> information which is stored in the header. Simply running mp3gain on
> > MP> your mp3 collection will not have the desired affect with with Rockbox
> > MP> (nor Archos, Winamp, Xmms etc).
> > That is not true!
> > As I understand it, every MP3frame has a gain information - and every
> > player must use this value.

> I'm just looking here:
> which I believe is the algorithm mp3gain is using.

Yes, mp3gain uses the statistical analysis proposed by replaygain. But as
I understand the issue, it _does_ change each mp3 frame's gain information
instead of the replaygain-proposed additional header.

> > I tested it:
> >
> > - it works with Rockbox
> > - it works with WinAmp (2.80)
> > - it works with Win Media Player (V6)
> Ahh, well, I can't argue with that :) This must be supported in the
> archos hardware then?

When I look at the quantity of question marks about player/encoder/driver
support used on the replaygain homepage, I seriously doubt that Win Media
Player would have support for this yet. Maybe Rockbox could ...? (oops,
another question mark :-))

> > And what MP3Gain does is much better than re-encoding, because there's
> > no loss in quality.
> Without a doubt. I assume it can be removed from the header as easily
> as it is added...

Besides: I think that the 'no loss in quality' is a relative issue. Of
course you spare the mp3 decoding/encoding so no additional mp3 noise is
recoded. But adjusting (multiplying) the gain parameters introduces a
per-frame gain quantization noise which of course is small compared to a
mp3 recoding noise, but at least the mp3 contents is altered and rounding
information is lost. The replaygain's idea of storing the overall gain
adjust parameter as an additional header field would leave the mp3
contents unaltered.

So, from low to high quality, these are the options:

1. Using mp3 decoding - amplification - mp3 encoding gives us the worst
quality. I think most of us know this process and its drawbacks.

2. Using mp3gain gives us nearly perfect quality (compared to the original
mp3 file), and it's compatible to all existing players (sw or hw). When
raising the gain we get less amplification noise (a larger s-to-n ratio)
from the DAC while we get a (very) small per-frame gain quantization
noise anyway.

3. Using replaygain and adjusting the gain inside the MP3 decoder.
Depending on the decoder's implementation the resulting quality is about
equivalent to variant 2.

4. Using replaygain and adjusting the DAC's (pre)amplification parameter
to the value stored in the mp3's replaygain-header on a per-track basis -
this usually leads to the same quality as manually adjusting the volume:
No additional (digital quantization) noise is introduced in the mp3
decoding, the amplification is done in the analog world, the noise is
simple analog amplification noise and thus constant.

I think it's a matter of taste (or in some cases a matter of sound data)
whether you prefer digital per-frame amplification noise over constant
analog amplifier noise. At least using the replaygain value would leave
the choice to the implementation (on a per-track basis, switch between
variant 3 and 4): The higher the overall gain the better the result when
using digital (early) amplification, the lower the gain the better use the
DAC's analog amplification prescaler (especially attenuation should be
done in the analog world).


Sehr Wus,
- Matthias

                    "To get control over people, make them trust you.
                                            To make people trust you
                      don't try to tell them the truth about history
                 but make happen what you told them about the future."
Received on 2002-08-19

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy