Recent changes to feature-requests

#49 New CPU technology

2026-04-17T08:59:35.880000Z

You'd probably find a large market for a 64-bit multi-threading mp3Gain app. When can we expect an .exe release?

#49 New CPU technology

2026-04-16T14:43:05.813000Z

Hmm. I just posted a rebuild of the whole project into Visual Studio 2026. It is now 64-bit and fully Unicode. I probably could add multi-threading...

#49 New CPU technology

2024-02-12T18:18:34.269000Z

Sorry, it's more like "in 13 years I've had time to forget most of the code" :)
I have no plans for any further changes, especially not changes that would require fundamental structural changes like multithreading.

#49 New CPU technology

2024-02-12T01:39:53.501000Z

Same question was asked in 2011... Guess the answer was no then since it hasn't happened yet but surely in 13 years you've had time to rethink that....

New CPU technology

2024-02-11T07:28:50.457000Z

Is there a chance that we will see mp3Gain take advantage of multi-core CPU technology in the near future? Would save oodles of time on large batch jobs...

Option to speed up

2022-02-12T14:51:01.062000Z

An option would be great to speed up the analysis,
like 2x: only analyse half the file (either till middle, or randomly sample half-length)

Sometimes it can take minutes to analyse, by understanding the compromise it could be speed up.

#40 Remove or update ReplayGain info

2019-01-21T04:46:55.618000Z

Old problem but here is a potential solution...

Let's say you normalized with -a -d 4 -c
The replaygain values will be off by -4dB since they are modeled around 89dB and you normalized to 93dB. Replaygain will always try to lower the volume to 89dB. If you adjust the replaygain values by subtracting the 4dB then you must add that 4dB back when loading the files the next time. If you don't, mp3gain will assume the current values are based on 89dB. If you do the same -a -d 4 -c then it will raise the volume since it thinks they are at 89dB currently.

How will mp3gain know to add back the 4dB the next time. You create a new tag and put a value of 93.0. This give you a normalized reference point.
Load the file - if the dBlevel_tag exists then adjust the replaygain values back to their original value by doing...
x = (replaygain_album_gain - (dBlevel_tag - 89))
y = (replaygain_track_gain - (dBlevel_tag - 89))

You must restore the original replaygain values before any new calculations are done.
If you use a previous version of mp3gain later then you must use -s r to force recalculation.

My current aacgain mod sets a "normalization_level_dB" tag (currently for aac files only) and sets it to "93.0" if that's what I normalized to.

If you use -m then you have to adjust the dBlevel tag accordingly. If you use -g later then you would have to read the existing normalization_level_dB and adjust it's value by adding ( x 1.5)

#47 Does the MP3gain program work for Windows 10 64 bits?

2018-07-21T23:03:50.504000Z

Yes.

Does the MP3gain program work for Windows 10 64 bits?

2018-07-20T23:29:21.233000Z

Does the MP3gain program work for Windows 10 64 bits?

Update the homepage

2018-05-08T13:05:17.459000Z

http://mp3gain.sourceforge.net still contains links to the historical 1.5.2r2 and every security researcher seems to be using that as target, producing bogus CVEs.