Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: replaygain with various file formats (Read 5299 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

replaygain with various file formats

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:
Quote
MP3 files are "adjusted" by setting a relative volume adjustment frame in their ID3 tags. There is  a frame  for  this,  called  "RVA2",  that does exactly what we want, and is a native frame in ID3v2.4.

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:
Quote
-a, --amplitude=AMPLITUDE
              Adjust  the  RMS  volume  to the target amplitude AMPLITUDE; must be between 0.0 and 1.0. If a number suffixed by "dB" or "dBFS" is specified, the amplitude is assumed  to  be  in  decibels from full scale.  The default is -12dBFS.

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

replaygain with various file formats

Reply #1 –
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?

replaygain with various file formats

Reply #2 –
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).
criZZb

replaygain with various file formats

Reply #3 –
Quote
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

replaygain with various file formats

Reply #4 –
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".
She is waiting in the air

replaygain with various file formats

Reply #5 –
Quote
In my opinion the names "radio" and "audiophile" are totally misleading, it somehow implies "quality".

Slightly off-topic but of course agreed :-)

Quote
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'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)

Quote
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.
(...)
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...


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?

replaygain with various file formats

Reply #6 –
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]

replaygain with various file formats

Reply #7 –
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).

replaygain with various file formats

Reply #9 –
The WIKI doesn't say much actually:
Quote
MP3Gain (http://mp3gain.sourceforge.net/)
Format: MP3
Method: Audio or Meta
Limitations: Limited to 1.5db steps in Audio Data mode

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:
Quote
mp3gain version 1.4.3
copyright© 2003 by Glen Sawyer
uses mpglib, which can be found at http://www.mpg123.de

Usage: mp3gain [options] <infile> [<infile 2> ...]

options:
        -v - show version number
        -g <i>  - apply gain i to mp3 without doing any analysis
        -l 0 <i> - apply gain i to channel 0 (left channel) of mp3
                  without doing any analysis (ONLY works for STEREO mp3s,
                  not Joint Stereo mp3s)
        -l 1 <i> - apply gain i to channel 1 (right channel) of mp3

        -r - apply Track gain automatically (all files set to equal loudness)
        -k - automatically lower Track gain to not clip audio
        -a - apply Album gain automatically (files are all from the same
                      album: a single gain change is applied to all files, so
                      their loudness relative to each other remains unchanged,
                      but the average album loudness is normalized)
        -m <i> - modify suggested MP3 gain by integer i
        -d <n> - modify suggested dB gain by floating-point n
        -c - ignore clipping warning when applying gain
        -o - output is a database-friendly tab-delimited list
        -t - mp3gain writes modified mp3 to temp file, then deletes original
             instead of modifying bytes in original file
        -q - Quiet mode: no status messages
        -p - Preserve original file timestamp
        -x - Only find max. amplitude of mp3
        -f - Force mp3gain to assume input file is an MPEG 2 Layer III file
             (i.e. don't check for mis-named Layer I or Layer II files)
        -? - show this message

        -s c - only check stored tag info (no other processing)
        -s d - delete stored tag info (no other processing)
        -s s - skip (ignore) stored tag info (do not read or write tags)
        -s r - force re-calculation (do not read tag info)
        -u - undo changes made by mp3gain (based on stored tag info)

        -w - "wrap" gain change if gain+change > 255 or gain+change < 0
              (use "-? wrap" switch for a complete explanation)

If you specify -r and -a, only the second one will work
If you do not specify -c, the program will stop and ask before
     applying gain change to a file that might clip

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

replaygain with various file formats

Reply #10 –
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:
Code: [Select]
3b43eb698efee680ce567a63fbd08dc3  mp3nogain.mp3  (7799117 bytes)
a955070c3bba31bb8e5dff1cf2aa4596  mp3gain.mp3    (7799439 bytes)
35fc682308928832547ff43a1bcb9203  mp3undo.mp3    (7799439 bytes)


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:
Code: [Select]
% cmp mp3undo.mp3 mp3nogain.mp3
cmp: EOF on mp3nogain.mp3

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:
Code: [Select]
 % dd if=mp3undo.mp3 bs=1 skip=7799117
APETAGEXÐ" MP3GAIN_MINMAX079,210MP3GAIN_ALBUM_MINMAX037,210
                                                           MP3GAIN_UNDO+000,+000,N
                                                                                  REPLAYGAIN_TRACK_GAIN-6.970000 dREPLAYGAIN_TRACK_PEAK1.034387
                REPLAYGAIN_ALBUM_GAIN-7.140000 dREPLAYGAIN_ALBUM_PEAK1.050027APETAGEXÐ"€

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:
Code: [Select]
% madplay -vvv -onull: undo.mp3 
MPEG Audio Decoder 0.15.0 (beta) - Copyright (C) 2000-2003 Robert Leslie et al.
error: frame 11198: lost synchronization
11198 frames decoded (0:04:52,5), -4,7 dB peak amplitude, 0 clipped samples

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!

replaygain with various file formats

Reply #11 –
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

replaygain with various file formats

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

The only problem is that you didn't tell mp3gain to remove the tag, if that's what you wanted. I replicated your test:
Code: [Select]
copy test.mp3 gain.mp3
mp3gain /a gain.mp3
copy gain.mp3 ungain.mp3
mp3gain /u ungain.mp3
mp3gain /sd ungain.mp3
md5sum *.mp3

a663f72939a4d4d5a672a7571470c2bb *test.mp3
e65467a92437304758930363203dda74 *gain.mp3
a663f72939a4d4d5a672a7571470c2bb *ungain.mp3
See - perfectly lossless