Hi!

I'd like to have my whole music collection playing at the same level. The answer is of course the album (aka audiophile) mode of replay gain. Now, the problem is that my collection consits of files encoded with few different codecs such as MusePack, Vorbis, MP3 and FLAC.

My platform is Linux x86

I have no doubts with Ogg/Vorbis and FLAC as the support for replaygain in these formats seems quite native and fully reversible (it's just some info stored in tags), and
what's also crucial, XMMS (the player) respects these settings and plays files at expected volume.

I'm also pretty sure that ReplayGain doesn't do any harm (just stores a tag) to MPC files as in the same file before and after applying replaygain only some starting bytes are different (stripping first 1KB makes them identical).

Now the doubts, questions and dillemas: replaygain and mp3. There are two tools having sth to do with rg: normalize and mp3gain.

normalize
It's surely safe as its manpage says:

It's also convenient as there's XMMS plugin which takes advantage of those RVA tags and sets the output volume. Also madplay respects them saying "id3: -14,4 dB relative volume adjustment (normalize)".

On the other hand, there's quite a major drawback: it doesn't really work as expected. While tools for other formats (vorbisgain, metaflac and ReplayGain) produce very similar sound levels, normalize by default (normalize -b *.mp3) sets the volume way higher so mp3 albums are much louder. There seems to be a way to adjust it:

but after a while of experimenting I wasn't able to come up with a setting which would fit with other replaygainers.

mp3gain
It does the thing - sound level is same as with vorbisgain etc.
It has a great advantage - every player seems to "support" it. But this advantage makes me suspicious.

Although mp3gain ought to be trustworthy (mentioned at replaygain.hydrogenaudio.org), I have some doubts about its losslessness (nice word ). It's fully transparent so it seems that it's not the player which adjusts the volume according to some tag. It doesn't really seem fully reversible - yeah, there is -u option, but 1) it's based on undo data written in the file 2) stripping first xxx bytes doesn't make the original and replaygained file identical.

I found some topics on this forums where people had similar thoughts but there never was a final answer I guess.

Anybody to answer my doubts?

ps. cmdline options used (are they proper?):

mpc: ReplaiGain 0.81d --auto
ogg: vorbisgain v0.34 -a
mp3: mp3gain 1.4.3 -a
flac: metaflac 1.1.0 --add-replay-gain

about what mp3gain changes-
(...)APETAGEXÐ^G^@^@"^A^@^@^G^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^G^@^@^@^@^@^@^@MP3GAIN_MINMAX^@123,179^G^@^@^@^@^@^@^@MP3GAIN_ALBUM_MINMAX^@123,(...)
here's what you can find if you look at the very end of your mp3 file. it's placed just before the id3, or maybe as the id3 - i'm no pr0, so i can't tell, either way i have found it before the artist/title/album etc tags. it contains of course some more data, try to look at it for yourself. the question is, is there any way of xmms supporting it? the plugin supplied with normalize does not detect any replay gain tuning :blink:.
i also wonder, if ogg123 uses replaygain tags? it does read them, but does it apply the gain? if so- are there any command-line options to change from normal to audiophile mode?

An easiest way would be using foobar2000 replaygain component, the values are then stored in the tag (apev2 prefferably, id3v2 is also possible).

The only disadvantage is, they are only readable by foobar2000 itself (AFAIK).

there's another slight drawback as well - there's no foobar2k for linux

Yes, it seems there is ReplayGain for all formats, and then there is also mp3gain. Mp3gain is nice and all, but i like the Replaygain method better, as used in foobar2000, even with mp3 files.

Replaygain just stores an info tag that players can choose to ignore or comply with. Ideally you should add per track (radio) gain to all files, and then also add per album (audiophile) only where a series of songs have correlation to each other, as often seen in those "live" albums. The player usually picks the "album" tag when it sees both, but this behaviour can be changed, which is nice for example when you are random playing songs instead of listening to albums in sequence.

In my opinion the names "radio" and "audiophile" are totally misleading, it somehow implies "quality". Only when i played with foobar2000, which uses the track/album terminology i could finally grasp the whole ReplayGain thing.

Now mp3gain is different, it actually uses a "gain" value that can be altered in the mp3 format, and that mp3 decoders comply with. It then stores the deviation made in the tags, so you could undo it later, provided the tags remain unaltered...

That is cool for the mp3 format as you don't need the player to actually read the info tags, on the other hand it removes you flexibility, you can not enable/disable/track/album mode like you can with ReplayGain. Also something in my mind remembers about 1.5db steps in that mp3 gain thing, but don't pay me attention with that These tools do calibrate loudness to the ReplayGain standard of 89db. (well the proposed standard actually says 83db, go figure!) "Normalize" seems to be doing something else...

The real solution is to use an mp3 input plugin in xmms that supports the ReplayGain method, just like the vorbis plugin now reads VorbisGain.

My proposals to the Replay Gain proposed standard: Settle with 89db already, and get rid of the "radio" and "audiophile" terminology, just use "per track" and "per album".

Slightly off-topic but of course agreed :-)


That's what I've suspected - thanks for assuring me. So what I understand is that this "gain" thing is a single value somwhere in the MP3 header, is that right? (I just want to know how big the modifications made by mp3gain are)



So I guess the most righteous way is the path of normalize, except that it should go along with standard of 89dB and output adjustment should be done by the input plugin not an effect plugin (as it happens now - librva.so). I can live with the second one, any ideas how to force normalize to set adjustment about the standard sound level used in other replaygain programs?

hi,

about foobar inserting replaygain data in tags- if it's true, than this is the way it should be done, in id3v2.4 there's a special field for it (not all players are said to accept that, especially those hardware ones, either way 'normalize's manual page explains it quite nicely). i've been told that foobar actually has some kind of database for that, not touching the files at all.

besides, foobar is strictly windoze .

what i would find perfect, is exactly what normalize is- with a 'slight' change, that is, making sure it complies to the proposed-draft-standard (whatevah) of replaygain at least at the level that vorbisgain does (a slight dB change).

[solid]

foobar can be run in wine and a few people do so judging by the threads in the forums, but thats less then ideal i'd imagine.

Also foobar's replaygain can be configured to do several different things. By defualt the values are stored in its database and in tags (whichever you've selected excepting ID3v1). However it can also be made to not write the data to tags and using the transcoder it can make the changes permanet to virtually any format (though obviously this should only be done to lossless files).

Take a look at the Hydrogenaudio Wiki, this might answer some of your questions:
http://doc.hydrogenaudio.org/wikis/hydroge...udio/ReplayGain

The WIKI doesn't say much actually:

So Audio or Meta?
And what in fact are those things?
Does "gain" value in mp3 format count as Audio or Meta?
What does exactly mp3gain do?

Here's mp3gain -? output:

There doesn't seem to be much choice between tagging and editing audio data here.
mp3gain's FAQ leaves some doubts as well.

Anyway, I've decided to investigate the changes applied by mp3gain myself.

I prepared three versions of one file:
nogain.mp3 - freshly encoded file
gain.mp3 - product of "mp3gain -a nogain.mp3" cmd
undo.mp3 - product of "mp3gain -u gain.mp3" cmd

gain.mp3 file isn't really important here - we will be comparing nogain.mp3 and undo.mp3 as they're expected to be identical in order for mp3gain to be called lossless.

First let's take a look at their sizes and md5sums:

First major observation is that mp3gain -u doesn't bring the file back to original shape or even size. The size difference gives us hope that it's only some additional data which make the md5sum different.

Let's check it by doing some binary, byte-by-byte comparison with cmp command:

Hurray! This indicates that there's no difference between the files but the size (mp3nogain ended first). So basically what makes the files different is only the data in additional 322 bytes at the end).

Let's find out what's in the additional 322 bytes:

Which means that mp3gain -u doesn't remove its own metadata written in APE tag while it should.

CONCLUSION
There should be no doubts about mp3gain's losslessness except that it should remove its undo information after executing undo.

UPDATE
OK, it's not that clean I described above, as for mp3gain modified files (gain.mp3 and undo.mp3) madplay throws out the following error at the very end of decoding:

which means that the last frame has been somewhat affected. mp3guessenc says that it has been truncated. On the other hand, when you decode nogain.mp3 and undo.mp3 back to WAVs you will find the resulting files to be identical. There are no audible differences, clicks at the end or any other distortions neither. So the final(?) conclusion would be, that mp3gain is rather safe but it should do its job cleaner.

Hope this would be helpful to anybody. Happy New Year!

I'm quite exactly in the same situation.
I use my mp3 collection from both windows and linux, and am trying to find the best way to add replaygain info of some sort to them all.

1. the linux normalize program is not up to par with ReplayGain programs.
the algorithm chosen to pick a 'loudness' value is doing some kind of 'sustained maximum' (sustained meaning it averages some things over 1 second).
My first reaction was to write a patch so that it would take a given percentile of local rms maximums, which is obviously making much more sense.
I learnt afterwards about the ReplayGain 'proposed standard', so I chose this percentile to be 95% and now my normalize is very similar to replaygain, it only lacks the filter to model human ear frequency sensibilities.
But in fact there's already a very nice piece of C code in lame to do all that,
http://www.leidinger.net/lame/doxy/html/ga..._8c-source.html
so it would just be better to use it (and that would mean a little bit more refactoring of normalize's not-so-modular code) to make normalize produce exactly the same number.
that would take like a day of work.
I mailed normalize's author to know what he thought about that, and whether he would do that or would accept patches a few days ago, I'm waiting for an answer.

2. in fact I'm more concerned with the replay and tag storage problem.
normalize stores id3v2.4 RVA2 tags, while personnally I'd prefer using APEv2 tags, as it would allow for very flexible and extensible tag-based stuff (like, you put some custom MY_RATING tag in your files, then ask the software to sort on %MY_RATING%, and everything is smooth and easy)

I'm about to post a msg to discuss about whether APEv2 tags could eventually become widely supported (even by linux players), and whether I could try to make this happen sooner.

--
SamK

The only problem is that you didn't tell mp3gain to remove the tag, if that's what you wanted. I replicated your test:See - perfectly lossless