In the past, I used foobar2000 to apply replaygain values to my music. Now that I run Linux, mp3gain is the only tool available to me (I don't feel like getting fb2k to run under Wine).

I understand that mp3gain applies changes differently from fb2k: fb2k only writes tags, the mp3 player applies the proper gain based on these tags; mp3gain applies the changes directly to the mp3 files, the player does not need to support replaygain.

The mp3gain method seems advantageous because changes made to the file will be heard on all mp3 players, like my new iPod. Are there any drawbacks to using mp3gain, though? Is there anything that makes the tag-only approach superior?

mp3gain uses 1.5 dB steps, whereas the tag-only method isn't.
These 1.5 dB steps give a max amplitude error from 0.75 dB from wanted value, acceptible to me.
(afaik 1 dB is the smallest volumestep that can be detected by the ear)

For mp3gain, you can only reverse it's results when you know how much you altered the volume in the first place
Stripping the tag just gives original file having original volume.

I personally also prefer mp3gain because of the possibility to have the same volume with every OS/HW. It seems that development has stopped, though. It should have been developed a new GUI with support for mp3gain and aacgain, if I remember well.
Well, as long as the command line backend is working fine, there is no problem for me, but still...
People would be more positive if they see some progress of the project, even some small steps.
Just my 2 cents
~

The GUI works just fine with aacgain.

I know Glen is busy with other things, but I think mp3gain is "finished" rather than "stopped"! Well, as finished as any software ever is.

Cheers,
David.

0.75dB error, yes, but with two back-to-back tracks you could potentially have 1.5dB of loudness difference which is noticeable.

Another advantage of Replay Gain (on compliant players) over mp3gain is the ability to switch between album gain and track gain without re-processing your files.

Thanks for the input. I wonder if that 1.5dB difference will bug me much. I doubt it.

Now if I could only find a way to use mp3gain with my favorite cd ripper/encoder (Sound Juicer) in order to make ripping a one step (or at least quicker) process.

Depending on which tracks go back to back, you can easily notice a difference with two tracks that have the same RG figure or even have one that sounds louder even though RG suggests it's quieter. I've had to increase the attenuation with my Beatles tracks because of this. Not that I'm complaining, but I've gotten the impression that some people place too much importance on the numbers.

This is unquestionably the best reason presented so far.

FWIW, humans do have the ability to discern volume differences that are less than 1dB, though this is more likely to occur when comparing the same piece of audio.

For me, the main drawback of MP3Gain is that it doesn't support ID3v2 tags yet.

It's really cumbersome to maintain three different tags in every file (id3v1, id3v2 and APEv2).

It's a mess

Regards.

Here it only writes to APEv2... that leaves ID3v2.x for the original meta data. That it doesn't write to ID3 tags is a feature, because you don't want to mix up the MP3Gain meta data and original meta data! Stupid players might "reinterprete" and rewrite the MP3Gain undo data.

So all you'd have to maintain are the "default" MP3 tags, i.e. ID3v2.x (or ID3v1 in case you have ancient playback hardware/software).

Yes, but you have to rename aacgain.exe to mp3gain.exe and replace the original mp3gain.exe in the MP3Gain folder. Not too flexible if you have both mp3 and aac files.


Well, at the official site one can see the following announcement dated 09 January 2005:

Probably that idea has been abandoned.


That's what I like MP3Gain, it's very easy to increase/decrease a little bit a volume of some tracks if they sound noticeably different or to change the default target value (different than 89 dB) for the whole album. I don't think it's so easy with replaygain.
~

Nonsense.

Aacgain works just fine on mp3 files. I use it all the time.

Hi,



But, in that case foobar2000 will read the APEv2 tag instead of the ID3v2 tag, won't it?

How can I instruct foobar2000 to read only the ID3v2 tag and ignore the APEv2 tag??

Regards.

Linux users have a problem here. mp3gain writes ape tags, yet several linux players (e.g. mpd) only read a replay gain tag when it is in an ID3 tag. Linux users unfortunately are supposed to be good at hacking: http://www.hydrogenaudio.org/forums/lofive...php/t42005.html.

A convenient compromise is not to work with replaygain tags, but to apply gain directly in album mode (-a switch instead of -r switch). After all, it is not a big problem if a track that is supposed to be more quiet in the context of an album is also more quiet when you shuffle between albums. Moreover, this replaygain method works with any playback software or DAP.

Hmm, I think the point here is to have a player that ignores the APE tag and doesn't modify it in any way. The general practice of mp3gain is to alter the gain of the track and store information so that it can be undone or so that further adjustments don't require additional analysis.

There are basically three main drawbacks of mp3gain - two of them are direct, while the third isn't immediatelly obvious:

1. mp3gain directly modifies the mp3-data and saves undo-information in a tag. This means, that if you loose the tag, you cannot undo. Tags are very volatile and can easily by accident get lost - thus, the undo-data isn't stored in a sufficiently safe place. This is less of concern, if you are applying albumgain..... because the original loudness-differences between tracks will be kept intact, even if you lose the undo-data. If however you apply trackgain, then the loss of undo-data can be a serious problem.

2. Only 1,5dB steps.

3. The most popular mp3gain UI, easily allows the user to change the target - i'd even say that its design encourages people to change it, without informing them about the problems associated with using something different than 89dB as reference. Replaygain by design does not save the target/reference! It is just asumed, that by convention, it is always 89dB (basically, the 89dB reference IS part of the replaygain specification!)... if something else is used, then software does not get informed of it... and even humans may depending on the circumstances be unable to find out which reference/target was used. Why is this a problem? Well, it becomes a problem as soon as you enter a multi-user environment... and dont tell me, that you know beforehand, that you will never in a few years, give a file to a friend.

1. If RG information was stored in the Lame header upon initial creation, mp3gain adjustments can still be undone when the undo information is lost. I'm not saying it's easy, just that it's possible.

2. 1.5 dB steps is not a big deal. See my Beatles example; you need to make sure the perceived loudness is actually consistent before you start worrying about resolution. Maybe after I make adjustments to my Beatles tracks, I'm still off by 1.49 dB from tracks from some other album. I have a hard time believing this will be all that noticeable.

3. I find the ability to change the target quite useful, so I personally don't consider it a drawback. If I were to share my tracks with someone else where the reference is set to 92, they could load them into mp3gain and change them however they like. Also, there is nothing stopping someone from scanning an mp3gained track and applying an RG tag for use with an RG aware player; at which point the mp3gain reference used is meaningless. I do see your point, however.

Replaygain inaccuracies and that 1,49dB inaccuracy, can be commulative. Yes, thats a worst-case scenario.

- Lyx

Heh. First time I even load up hydrogenaudio in a few years, and I find a conversation about MP3Gain on the front page. I guess people still care about it

Replies to random points from the thread so far:

Tag format:
My primary reason for using APE tags instead of ID3v2 tags was that at the time, the only program that paid any attention to ReplayGain tags at all was foobar2000, and the only tag format it used was APEv2. My secondary reason was that the ID3v2 tag format had some problems at the time, and I couldn't find a good library. I figured it would be "safer" to just use a tag format that wouldn't get clobbered by some other poorly-written tag program.
In hindsight, I probably should have gone with the more ubiquitous ID3v2 format from the start. I even came up with an ASCII (i.e. semi human-readable) format for putting all of MP3Gain's tag info into the 30-character "comment" area of an ID3v1 tag. Adding options for the tag fomat (i.e. choose APE, ID3v1, or ID3v2) was pretty much the only thing left on my "to-do" list for the command-line half of MP3Gain.

No development:
Yeah, I haven't really done anything with MP3Gain for years now. To be honest, I don't use it myself any more. I joined the iPod crowd, and now I just do a ReplayGain scan with foobar2k, and dump the Track Gain results into Apple's "iTunNORM" tag. Then with Sound Check turned on, the volume on all my stuff is correctly adjusted without having to modify the data.
But even before I stopped using it, MP3Gain already had many more features than I ever needed for myself. So as David put it, I considered it as "finished" as I wanted it.

...except for the tag thing

...and the fact that I wish I hadn't picked Visual Basic for the GUI, as you can see by my news post from nearly four years ago (!) on the MP3Gain site




And that's exactly how MP3Gain stores the tag information. No matter what the user has set in the GUI, the actual stored information is based on the 89dB reference. If a user has their "target" set to 95dB and they use Track Gain on a file, then if someone else opens that file in MP3Gain with the default 89dB target, they will see that the file is about 6dB too loud and should be turned down. The user-adjusted "target" is only used inside the currently-running GUI.

Oh, and greynol is correct: if you re-name aacgain.exe as "mp3gain.exe", then the MP3Gain GUI works on both AAC and mp3 files. No need to swap the original mp3gain.exe in and out.

-Glen

Thats true. However, as long as the undo-information is available, there cannot really be any permanent problem anyways. The part of my argument which you quoted, was only relative to the following scenario:

1. Undo information is lost
2. Trackgain was used
3. Different reference was used
4. Multiuser-Situation

In that case, it may be impossible to get the files of multiple users to be similiar in loudness - they are in terms of loudness permanently incompatible with each other. I should probably have explained those conditions more clearly.

On first sight, it may seem like an unprobably exception-case, because of the sheer number of conditions. But think again:

1. Tags aren't a safe place to put "backups"
2. Trackgain isn't that unpopular with people who listen to mixed playlists
3. mp3gain via its UI encourages users to change the reference - and the loudness-war combined with lack of RG-amp settings in players, and lack of powerful preamp creates a need for changing the reference.
4. Music nowadays is no longer a purely "individual" phenomenon.

The main reason why things like that bothers me, is that they are counterproductive to ever establish replaygain as a mainstream-standard..... something which is in any kind of hifi-components, etc. For something like that to get mass-adoption, it needs to be simple and "just work".... joe average doesn't want to care about "references"... he just wants to know that he just needs to buy a player with a "replaygain-feature" - and into which you can then just load music and press a "trackgain-mode" or "albumgain-mode"-button (with the player automatically doing the scanning beforehand, so that the user doesnt even need to care about scanning files).

1) RG numbers stored in the tag are always relative to the 89 dB reference.

2) Undo information is stored as the amplitude change made to the file and has no direct relationship to the reference, whether is was set to 89 dB or some other number. IOW, the reference chosen is irrelevant.

Indeed, supposing I were to apply track gain to all of my files and then blew away the undo information and did not store RG information in the Lame header, there will be a problem going back to the relative differences between tracks.

If I were to apply album gain and blew away the undo information there really won't be any problem with people who are anal about the level. They can alway re-analyze and add RG tags or apply gain to the data to set them to whatever level they like, track gain or album gain.

Agreed.

I can't see any 100% secure method of putting undo information into the mp3 file. Whatever you do, it could be stripped - it's not as if ID3v2 tags never get stripped!

If your concern is that you might get tracks from someone with TrackGain applied and the undo information removed, I have a simple suggestion: buy the CD and encode it yourself!

When getting an mp3 from a random source, the possibility that it might have track gain applied without your knowledge is the least of your worries. It might have been peak normalised (or clipped) before or after encoding using any number of pre-existing tools, it might have been transcoded, it might have been ripped from a bad mix CD (or even bad commercial CD) where the tracks didn't match in loudness in any useful way, it might have been ripped with serious errors etc etc etc.


mp3gain itself is "counterproductive to ever establish replaygain as a mainstream-standard..... something which is in any kind of hifi-components" because it removes the need to implement any support outside of mp3gain itself. I don't have a problem with this - despite mp3gain being the _first_ ReplayGain implementation available (beyond the MATLAB reference code), plenty of tag-based implementations followed. I don't think having an adjustable target level in mp3gain has impeded this at all - in fact, if you take the ReplayGain standard as a whole, then "tag implementations" need a pre-amp in the player, so implicitly "no-tag implementations" need some adjustment in the utility itself (because there's nowhere else to put it).


Having said all this, I understand the desire to make it as good as it can be. As it's open source, if there is a more robust method of storing undo information which doesn't have any other disadvantages, people are free to implement it.

Cheers,
David.

This relationship:


Is similiar to this relationship:


In both cases - or more precisely any replaygain implementation which respects the 89dB reference - you need some kind of amp-function in the player..... optimally, a hardware-preamp for the headphones, since that would solve the root issue: weak amping of headphones/speakers. Humans have a tendency to just want an "implementation which works" without caring about how efficient that implementation is. If the weak hardware preamping is "fixed" on the software side, then the pressure to fix the actual hardware-problem vanishes. This is the case for both, changing references or on-the-fly amping.... its just that on-the-fly amping is temporary and therefore less destructive.

- Lyx

Hi everybody.

I just wanted to note that I'm using MP3Gain's GUI for applying Track and Album ReplayGain values to my MP3 files in one go and that I noticed the resulting values are far from being restricted to 1.5dB value steps, despite the GUI presenting the results as such.

Maybe I'm missing something here, but I have set up MP3Gain's GUI to calculate "Track Gain" but at the same time I use "Album Analysis" ...

That way it scans each file for calculating track based replaygain values and at the end of each album, the averaged album replaygain values get applied. Those result seem to be calculated in 1/100 dB steps.

Therefore, I can easily switch my player (in this case Winamp with MAD decoder plugin) to use either track or album replaygain values, without a need to re-encode the files again.

Is there anything wrong in my approach ?

Cheers,
Maggi

I, for one, am very grateful to Snelg for having included an easy way to change the default 89 dB volume to something more "reasonable".

Now, don't get me wrong, I think that 89 dB is perfectly fine for Hi-Fi setups or computers, but it's also woefully inadequate for iPods recently bought in the European Union.

The incredibly stupid volume cap mandated by Law in the EU makes all your mp3 files replaygained to 89 dB absolutely inaudible in noisy areas (busy streets with a lot of traffic).

The volume control included in iTunes is also useless (it doesn't matter if you try to crank it up to 100%, the resulting volume just doesn't change at all)

The only solution is to use MP3Gain to force a higher dB value (which also introduces clipping, but that's unavoidable).

So, I vote to keep the current MP3Gain UI unchanged in that respect.

And I'm completely sure that I will NEVER EVER buy an iPod in Europe. The next one will be from the United States. I'm not making the same mistake twice.

Regards.

In this case, what you need are better headphones, with a better ability to reduce external noise. In such situation, pushing the volume of your player higher and higher is not the proper solution, and will possibly damage your hearing.
The default volume limitation on European iPods is limiting the output to 100dB with stock earplugs. If you really need to often go higher than that, I'm afraid to tell you that there will likely be irreversible consequences.

But 100dB of what for what input?

If it's for an input of 0dB FS sine wave, then if you run mp3gain with an 89dB target volume, the actual audio is never going to get anywhere near this loud.

Cheers,
David.


I don't think removing a simple software-level control to force people to upgrade their hardware is "efficient".

In a world where the vast majority of people have never heard of ReplayGain, and the vast majority of players don't support ReplayGain and are designed to "work" with modern hyper-compressed CDs, removing the ability to use a level higher than 89dB wouldn't apply pressure to "fix" weak amplifiers - it would just stop many people from using mp3gain.

Anyway, your core concern - that you might receive files from an unknown source with unknown mp3gain modification pre-applied - wouldn't be solved by fixing mp3gain at 89dB. You would still have the problem of not knowing whether the tracks were set at their original level, or with TrackGain applied, or with AlbumGain applied - and not being able to get back to the original level, or the AlbumGain level, if TrackGain had been pre-applied and the undo information subsequently stripped.

Cheers,
David.

Hey, thanks a lot for that info! Man, I was seriously outdated, I didn't know it was already possible to convert ReplayGain values to iTunNORM values.

I've followed your suggestion, and I'm using MP3Tag to convert the tags. It seems that the most suitable method for me is this one:

- Create a new Action with whatever name you wish.
- Set the action type to Format Value
- Set the field to COMMENT ITUNNORM
- Set the format string to $rg2sc($add(%REPLAYGAIN_TRACK_GAIN%,8))

Applying the newly created action and enabling "Sound Check" on the iPod should then set the volume to approximately 97 dB. That's a bit more reasonable level for listening to "modern" (i.e. overcompressed) music on the streets.

I find it a bit ironic that thanks to your advice now MP3Gain is no longer necessary for me! But nevertheless I'll keep it around for the future, it's been so useful for me for so long that I'm very fond of it!

Regards.

Sorry there but what does FWIW mean?



EDIT: I know now thanks to Dynamic