MP3Gain 1.1 Beta Options

[Snelg]

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

[sony666]

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

[wagner reatto]

i use it regularly.

thank you again.

[boojum]

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

[Crocodil]

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.

[Big_Berny]

[*]Store analysis info in mp3 (so you only ever have to analyze an mp3 once)

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.

This post has been edited by Big_Berny: May 23 2003, 13:55

[dewey1973]

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

[schuberth]

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)

[DickD]

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?

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.

[Crocodil]

@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

[Big_Berny]

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

[Crocodil]

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...

[Snelg]

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

[joeg]

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


nice!

[Crocodil]

Thank you Snelq for the answer.

[DustMagnet]

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.

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.

[Jojo]

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.

[Jan S.]

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!

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.

[Jojo]

It thinks the ape2-tag is corrupted frames.

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

[Jan S.]

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.

[rmoody]

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.

This post has been edited by rmoody: May 25 2003, 22:09

[Snelg]

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...

[Jojo]

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

yes I believe ID3v2 support would be the perfect solution!

[CiTay]

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...

[HansHeijden]

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.