http://www.geocities.com/mp3gain

It's been a while since the last update. Here's the quick list of what's new:

• A little smarter about ignoring corrupt mp3 data
  
• Beep when finished
  
• TAGS:
  • Store analysis info in mp3 (so you only ever have to analyze an mp3 once)
  • Store "undo" info directly in the mp3

Make sure you read the other notes in the News post at the top of the MP3Gain page before you download...

-Glen

Cheers
One of THE few essential tools getting even better, thanks for all the time you spend on it.

i use it regularly.

thank you again.

Thanks for improving a valuable tool. You are on the short list of "saints to be."

Hi

First of all I'd like to thak you for creating such a great tool. I've been using it for some time now and it comes in very handy.
I just tried the newest version and I like it very much. The "Undo" is a great idea, couple of times I really did need it but it wasn't there
I was also pleasantly suprised that now MP3Gain adds the Replaygain information to tags.

But than I've noticed one thing... Why the "REPLAYGAIN_TRACK_GAIN" and "REPLAYGAIN_ALBUM_GAIN" are with only 0.5dB adequacy?? I use foobar2000 and it's more adequate... I know MP3Gain has to use 0.5dB steps when replaygaining but does it have tu use them here?
I don't know much about mp3 and maybe it doesn't matter but if it does could you pretty please do something with it?

Again, thanks for creating the MP3Gain.

Great work! That was the feature I waited for! I'll test it later!

PS: We have now the 23th MAY! Not April! A little mistake on your page.

Is there any place where one can download the .exe without the gui?

Get the sources and compile them.

Now on the serious side, I tried compiling the old backend with the CodeWarrior 8.0 and after a bit of trickery it did compile with P4 optimizations but the version I've got was a little slower than the official compile.
Any ideas if it's the compiler or should I play more with the optimization settings?

(Sorry if this is a bit OT)

Having tried it myself, it is using +/- 1.5 dB accuracy on screen, as it always has, because 1.5dB is the minimum step size it can apply. (Actually, it might some non-round number like 1.55 dB, I think)

1.5 dB is the minimum step size in the MP3 format's global gain field, so it's the smallest step you can apply easily without having to re-encode the MP3 (which is transcoding and causes a permanent loss of quality)

Although at certain frequencies, smaller changes that 1.5 dB can be perceived (just!), it really accurate enough for audible purposes in setting track volume to be roughly equivalent. Foobar2000 has 0.01dB steps, which is overkill, but harmless.

mp3gain writes a tag called MP3GAIN_MINMAX and another called MP3GAIN_UNDO to an APEv2 tag, and it adjusts the tags shown in Foobar2000 (Reload from file to see the changes) by the gain it has applied.

If you've already scanned the file in Foobar2000 and added APEv2 tags with the Replaygain info in them, mp3gain doesn't even need to scan the files - it just uses and trusts the gain and peak info supplied by Foobar.

Here's a test I did:
1. Use erhu.flac (decoded to wav) test problem sample
2. Encode using lame --alt-preset standard -Z to erhu_APSZ.mp3
3. Load it into mp3gain v1.1beta. No info shows.
4. Scan track gain. MP3gain reports Track Volume = 91.2 dB, Track Gain = -1.5 dB, Max No Clip Gain = 6.0 dB
5. Don't apply track gain, just add file to Foobar2000 without playing.
6. Examine file info (Reload from file). The following tags are shown:
MP3GAIN_MINMAX = 146,175
REPLAYGAIN_TRACK_GAIN = -2.1600 dB
REPLAYGAIN_TRACK_PEAK = 0.4739

So clearly, mp3gain is only displaying to 1.5 dB (and 0.1 dB for track volume) but is scanning to the same resolution as Foobar2000. However, unlike fb2k, it may use each mp3 frame (26 ms) as its loudness measuring window, while I think fb2k uses 50 ms chunks.

Continuing the experiment:
7. Apply Track Gain
Now displays are 89.7 dB, 0.0 dB, 7.5 dB
8. Foobar2000: Reload info from file: (It's a shame that mp3gain can't force FB2K to update its database, if the database is enabled)
MP3GAIN_MINMAX = 145,174
MP3GAIN_UNDO = +001,+001,N
REPLAYGAIN_TRACK_GAIN = -0.6550 dB
REPLAYGAIN_TRACK_PEAK = 0.3985

So it appears that -1.505 dB gain has been applied (and this concurs with the change in track_peak value)

9. Now in MP3Gain, Undo Gain Changes (right click menu)
Now displays are: 91.2, -1.5, 6.0 as before.

10. Foobar2000: Reload info from file:
MP3GAIN_MINMAX = 146,175
MP3GAIN_UNDO = +000,+000,N
REPLAYGAIN_TRACK_GAIN = -2.1600 dB
REPLAYGAIN_TRACK_PEAK = 0.4739

11. MP3gain: Undo gain changes. No change to display.
12. Apply Track Gain, and everything is same as before.

13. Remove tags from file.
14. FB2K reload info
15. FB2k Scan per file track gain
16. View info: Track gain = -1.150000 dB, track peak = 0.473909

So FB2k has calculated a different value, which is to be expected given its different chunk size and implementation, but isn't significant enough to worry about. The peak value, as expected, is identical (only it's calculated to 6 dp in the version 0.62)

17. MP3gain. Clear analysis then Add File.
Display reads: 90.2 dB, -1.5 dB, 6.0 dB having read info from tags, as supplied by Foobar2000.
18. FB2k, info still as in step 16.
19. MP3Gain Apply Track Gain.
Display is now: 88.6 dB, 0.0 dB, 7.5 dB
20. Fb2k: Reload info:
(there is no MP3GAIN_MINMAX tag)
MP3GAIN_UNDO = +001,+001,N
REPLAYGAIN_TRACK_GAIN = +0.3550 dB
REPLAYGAIN_TRACK_PEAK = 0.3985

Note that the tags are only to 4 decimal places now.

21. MP3gain: Undo gain changes.
Display: 90.2 dB, -1.5 dB, 6.0 dB
22. Fb2k: Reload info:
(there is no MP3GAIN_MINMAX tag)
MP3GAIN_UNDO = +000,+000,N
REPLAYGAIN_TRACK_GAIN = -1.1500 dB
REPLAYGAIN_TRACK_PEAK = 0.4739

Seems to work fine, and the loss of the 3rd and 4th dec places is negligible.

I thought I'd found a bug with the APS (no -Z) encode of erhu_APS.mp3, but I couldn't reproduce it. I thought maybe I rescanned in FB2K and the undo data messed up, but didn't seem to happen on a second try with the same file.

@DickD: I really goofed with those 0.5dB, didn't I? Something must have blackened my mind
I understand that when changing as you call it "global gain" MP3Gain has to use 1.5dB steps... But does it have to use them when writing Replaygain info to tags? Couldn't it be like in foobar2000? I know you said it's an overkill and you're probably right but it would be nice and it shouldn't be very hard to add...

Please don't think I'm picky. I do think the program is very good and off course I will keep on using it

It's me again. Good you corrected the date at the top, but at the buttom (where you can download the files) still stand 22april!

Big_Berny

Ok, I have made a complete fool of myself... I've checked some other albums and now the difference in Replaygain info (REPLAYGAIN_TRACK_GAIN and REPLAYGAIN_ALBUM_GAIN) between foobar2000 and MP3Gain is no more than 0.005dB...

I see three possibilities:
1. There is something very funny going on with my PC
2. The album I used at first is somewhat strange or not typical (but I very much doubt that)
3. I REALLY have to visit an eye doctor

One other thing though... I might make myself look stupid again but I've found something that could possibly be a source of trouble. Foobar2000 uses a dot to separate the integer part of a number from the fractional (I'm not sure if I used the right words - I don't know English very well) while MP3Gain uses a comma. Well, probably the dot/comma is only a graphical symbol and it won't cause any problems...

MP3Gain stores the numbers in the tags with a dot, just like foobar2k. The GUI displays dot or comma depending on your computer's regional settings.

As for the 4 vs. 6 decimal places, the version of foobar2k I've been using only writes 4 decimal places...?
It's simple enough to make the switch in mp3gain, if needed.

-Glen

this is perfect for making mp3 cds for a portable/car player...


nice!

Thank you Snelq for the answer.

Foobar 0.62a uses 6 decimal places. The extra digits are obviously overkill, but it would be a little cleaner if both apps used the same format, if only to avoid endless questions about "accuracy." ;-)

In any case, thank you for the update to mp3gain, Snelg.

I actually would suggest turning that Tag feature off by default! I played a little around with it and mp3test or mp3trim always said that the last frame is corrupted and that the mp3 has some errors! Also, it would be nice if there is an option 'only read'. Currently I turned that feature entirely off, but if I get some music from friends (or whatever ), I would like to read the settings out...or it would be even better if this option 'only read' could also remove the tags automatically once I change the mp3.

It thinks the ape2-tag is corrupted frames. Ape2 is not in the mp3 specs so this is logical for a program that doesn't recognize ape2-tags.

Ok, what is an "ape2-tag"? I'm also worried that many portables might have their problems playing that file...btw. Mp3Trim is constantly updated and IMHO very advanced (I talked to the author many times), so I don't get it why the program wouldn't be able to spot it as an "ape2-tag" (what ever that is)...

If I understood correct mp3gain now uses ape2-tags to store the replaygain value.

An ape2-tag is a system to put information (artist, genre, album, title) into mp3 (or other) files just like id3v2-tags.
He could be using id3v2 tags to save the replaygain vaue also though...

Id3v2-tags have been used for a long time with mp3 files and many player supports them. AFAIK only foobar currently supports ape2-tags in mp3 files.

After adjusting the gain and checking the files out with encspot, there are sync errors in all of them. Is this going to be a problem? What problems will this cause if any? Is there another way to tag the files without causing sync errors? Should I remove the tag? The sync errors just sort of worry me a little bit.

The "Sync error" is just because Encspot doesn't recognize the APEv2 tags (which are placed at the end of the file, just before ID3v1 and/or Lyrics3 v2 tags), so it assumes that this unrecognized data is just corrupt mp3 data.
It shouldn't be a "real" problem, but I'm already thinking that I'll have to provide ID3v2 tag support (as an option to APEv2 tags) just so everyone doesn't keep asking me about this

...and someone else has already pointed out to me that the 1.1 version (actually, it's the back end's problem, so version 1.4.0) does not "play nice" with most Lyrics3 tags I'll have to fix that quickly...

yes I believe ID3v2 support would be the perfect solution!

I hope that's really optional, since don't use tags and remove any and all tags from MP3s that have them. I wouldn't want the MP3gain tags to fall victim to that...

Maybe I missed something, but wasn't the intention already a few year ago to place replaygain values in that modified Xing header (the 'Lame tag')? Because that apparently doesn't do harm in Lame, that by default writes a Xing header even for CBR.

Yes, there is space reserved in Lame header for those info:
* replaygain peak value
* replaygain radio adjustement
* replaygain album adjustement
* mp3gain potential modification

http://gabriel.mp3-tech.org/mp3infotag.html

Right now (3.94 alpha), Lame stores the peak and radio values. It seems to me that mp3gain could use the stored peak and radio values to save the analysis time, and could store the modification value into the mp3gain field

Same here, I don't use tagging, and remove all id3v2 tags. Ideally, mp3gain would fill in replaygain values in the Lame header if present, and add a Lame header if not present yet...

And I think that the few initial reports about Lame tags causing any trouble died out by now?

I would also like replaygain info stored in the lame tag, as I have asked for In the past...

I do use tags, but remove id3v2 tags.
If you add a Lame header you get i.e. Xing (or fhg) files with a Lame header. Wouldn't that be more confusing?
APE2 seems like the near future (for mp3).
--
Ge Someone

The Lame header is in fact a INFO header, that could be used for any encoder.
But I'm not sure if adding an Info tag after encoding to files generated by other encoders would be good.

Perhaps ability to store values into the Info header if present and if not adding an ape2 tag?

I think that it would be nice if mp3gain could use the value stored into Info tag instead of computing it once again. That would save a lot of time.

Thoughts:

Storing Replay Gain values with more than 1 decimal place is pretty silly. More than 2 is just plain stupid. Really. It's just like having a broken calculator which you know doesn't usually get the answer correct to the nearest whole number, let alone several decimal places - but writing down the answer it gives you to 6 decimal places anyway! It won't do any harm, but it won't do any good either. And it may make people think that those decimal places are significant - they're not. At all. Ever.

The peak values are different - these need to be 16, 24, or even 32-bit accurate (in theory) for some applications


There should be 1 - just 1 - way of storing the replay gain data in an mp3 file. The Lame tag way seemed like a good idea at the time, but in retrospect, it seems like a mistake. It made sense for lame created files - but what about other mp3s? Adding tags at the start of an already created file is silly - they should go at the end. That's just common sense. Having one way of adding replaygain info for lame files, and another for all others is also silly. So it's better to put it at the end, and only the end.


Though I originally suggested ID3v2 as a way of storing replay gain info in mp3s, nothing uses this (to my knowledge). It would be very sensible to decide, now, once and for all, that the correct place for replaygain info in an mp3 is in an Ape 2.0 tag at the end. If it scares people to talk about yet another format, just call it the replay gain tag. Those in the know will know what's happening - others will be happy.


The only prolem is that some tools will report it as a corrupt frame. But if they didn't understand ID3, they'd report that as a corrupt frame. If they didn't understand Lyrics3, they'd report that as a corrupt frame. So, the answer is simply to update these tools. If the answer was always "do not put anything in that existing tools won't understand", then Lyrics 3 and ID3 could never have been invented. The replay gain tag (i.e. replay gain info in an ape 2.0 tag) is backwards compatable with players, because they'll just ignore it, so there's no actual problem.



In conclusion (!) my suggestion is this:

Store replay gain values in an Ape 2.0 tag near the end of the file.
For newbies, just refer to it as the "replay gain tag".
Use whatever number of decimal places you like - one is more than enough!
If someone complains that the "replay gain tag" is being reported as a corrupt file, just say "the file checking tool doesn't recognise the replay gain tag yet - it'll get updated eventually".
If someone asks why replay gain info isn't in ID3v2, say
1) no player supports it
2) some players do support the replay gain tag, and other are encouraged to do so
3) Some players choke on ID3v2
4) No players choke on the replay gain tag - it does no actual harm
5) Many people strip ID3v2 tags or re-create them on mass from file names - this would destroy replay gain info!
6) Only tools that understand replay gain will touch the replay gain tag, so it's safe.


That's my opinion. Feel free to ignore it. I'm only guessing Ape 2.0 tags have no compatibility problems - can someone confirm this?

I hope Ape 2.0 tags become more widely used - if so, some of the points above would become false (i.e. people will strip them!), but then more tools will correctly recognise them. It's a pity ID3v2 came first - hardware devices support this that will never support APE 2.0 - though hopefully some will support at least the replay gain part, and maybe the rest of it, eventually.

Cheers,
David.

I am not opposed to apev2 tags at the end. After all, what is important is to have a way to read the gain values, and to rollback the changes.

I'd just like mp3gain to be able to read the already computed values stored into Lame tag.

I know this sounds unreasonable, but is there anyway to remove RG from the lame tag now? Seriously. If Lame is going to calculate RG values, can it store them the same place as mp3gain? And only there? please?

Does anything actually use the RG values in the lame tag? Because, if not, now would be a great time to drop them. Permanently.


Otherwise, every subsequent software or hardware device that wants to find RG values in mp3s will have to look in two places. This just seems so stupid!



This is only a suggestion. I can imagine that it won't be popular. But is there any reason why it is not sensible?

Cheers,
David.

Well, I am very surprised. There has been a place reserved for RG values in the Lame tag since the beginning, and only now there are some concerns about it.

Right now there is now way to remove those values (except with an hex editor).

Do you think that this is a bad thing for the encoder to compute the RG values?

I am not sure if it would be a good thing for the encoder core to store an other tag structure. If you really want an ape2 tag, perhaps what we need is a converter. (That is why I suggested that mp3gain could read those values from the Lame tag if present. It could still store it into an ape2 tag)

You could also decide to completely ignore what is inside the Lame tag, but this would probably be the worst choice.


Perhaps it would also be the right time to start a deeper thinking about tags and containers.
Right now we have:
id3v1: supported by about every program
id3v2: supported by hardware players, standard winamp decoder, itunes
ape2: supported by foobar, winamp mpc/ape plugins
XING/Lame tag: supported (partially) by winamp standard decoder, probably supported by Real
VBRI: supported by FhG.
mp4: supported by apple tools

Perhaps ape2 are wise, but I immediately see 2 problems:
*placed at the end, could be a problem for hardware players
*The name. How would you expect FhG to accepte something with such a name? (I know, the problem is the same with the Lame name)

You make a good point - one that I've thought about, and got nowhere with.

I was thinking about it in the context of replay gain, and decided that the best way was for it to have it's own "tag". This seems stupid (enough tag format already), but none of them are ideal. ID3v2 breaks some players. ID3v2 is usually at the start of the file (that's terrible for updating on HDD). ID3v1 doesn't have enough room. Lame tag is a good concept, but it isn't widely supported, and it makes no sense to add it to other files. It should contain lame specific things, not general things!

I'm sorry to put forward this surprising idea. I know RG was in there from the start - it was the idea of including some kind of volume thing in the lame tag that made me put ReplayGain together. However, in retrospect, it seems like the wrong place for the information.


Tags: I'm not qualified to comment on this, so flame away... I've heard of (but not used) a version of ID3v2 which is stored at the end - there's a small header block at the start of the file which points to the main tag at the end. If the header block is 100% compatable with all mp3 players, and if the header block size can remain unchanged even when the tag itself is changed, and if ID3v2 data stored in this way is compatable with all existing ID3v2 devices (especially hardware players) then this seems like the best solution. However, I don't know the answer to all these "if"s.

There's also work in Mpeg 7 which may or may not be relevant. Storing metadata (i.e. data about data) is a big headache because so many existing formats don't have it defined, and those that do all have individual ways of doing it.

A globally understood metadata block format which can work with all formats (e.g. wav, mp3, mpc, ogg etc maybe even CD-DA), can be transferred between formats (so encoding or decoding or transcoding simply requires the meta data block to be copied, with a small update), and can be automatically identified and sent first (even though it's stored last or separately or whatever) whenever files are shared or streamed - that's the dream. Of course, everyone has to support this one standard. We're good at that, humans, aren't we? Picking a world-wide standard and sticking to it? NTSC/PAL/SECAM, driving on the right or left side of the road, etc etc etc!

Cheers,
David.

On the other hand, tags stored at the end are a draback for hardware devices: seeking at the end means more power used, and so less battery life.

I really think that we have to initiate a discussion about tags and what should be inside those.
It seems to me that inside the Lame tag, we mixed 2 things:
*internal info: preset used, lowpass value, ath used, vbr mode,...
*player related info: codec delay, replaygain values, seek table, surround mode,...

There is also a third category, which is user related: track name, track author, album name,...

Perhaps the player related ones could even be splitted between player related and decoder related:
*decoder: seek table, codec delay
*player: replaygain values, surround modes

TBH, looking at it again, the whole thing makes my head spin.

I don't like tags at the start of files because adding or updating+extending them means re-writing the whole file. I don't like tags at the end of files because the data is the last thing to be transferred in p2p, and, as you say, means a double seek when playing the file. I certainly don't like data stored (only) separately from the file because it will get lost.

If you have mp3+cue or mpc+cue (or any other instance where you have a ~100MB lossy file) the first problem is not trivial - it makes changing tags very slow!

If you're downloading a file, it's annoying having the info at the end - especially if it's info that would make you stop the download - e.g. encoding quality (or lack of), recording version etc etc

The logical compromise seems to be an all-player compatable fixed length tag at the start which is written (maybe partly blank) by all mp3 encoders, and filled with a fixed amount of information. Then there can be an extensible, variable length tag at the end which can hold all other information. The problem is: what is important enough to put at the start, and what is trivial enough to leave until the end? Who decides, and how?

The best answer to this is maybe to say: OK, it's a 4kB (say) block at the start - always. This is universally fixed - mp3s should start with a block this size - always. It's in ID3v2 format. What you decide to put in there (and what you decide to leave for the variable length tag at the end of the file) is up to you. You get the best of both worlds. Or maybe the worst!

Can this be done in a compatible way?

Cheers,
David.