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: MP3GAIN BUG (Read 7180 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MP3GAIN BUG

Hi, I made an account here to post this bug that's been killing me.

Maybe I'm delusional but none of these commands work as expected (or advertised).

/k - automatically lower Track/Album gain to not clip audio
/m <i> - modify suggested MP3 gain by integer i
/d <n> - modify suggested dB gain by floating-point n


Examples: As shown below, the baseline result for 89dB = -12.130000
Code: [Select]
>mp3gain /s r "SNSD - Gee.mp3"
Recommended "Track" dB change: -12.130000
Recommended "Track" mp3 gain change: -8
Max PCM sample at current gain: 38378.265261
Max mp3 global gain field: 192
Min mp3 global gain field: 93


Recommended "Album" dB change for all files: -12.130000
Recommended "Album" mp3 gain change for all files: -8


But, -12.130000dB is too quiet, so I tried this:
Code: [Select]
>mp3gain /d 9 /s r "SNSD - Gee.mp3"
Recommended "Track" dB change: -3.130000
Recommended "Track" mp3 gain change: -2
Max PCM sample at current gain: 38378.265261
Max mp3 global gain field: 192
Min mp3 global gain field: 93


Recommended "Album" dB change for all files: -3.130000
Recommended "Album" mp3 gain change for all files: -2


-3.130000dB seemed like a good value, but when I checked the taginfo on the mp3 file itself, I found the replay gain was still -12.130000dB along with the resultant very quiet sound levels. Same goes for when I used the /m switch.

So I gave up on that and tried:

Code: [Select]
>mp3gain /r /k "SNSD - Gee.mp3" (also tried the /a /k switches)
SNSD - Gee.mp3
Applying mp3 gain change of -8 to SNSD - Gee.mp3...


Then I turned off the Winamp Replaygain feature in order to simulate a non-replaygain player -- one of the reasons mp3gain was created. I still got the sound levels corresponding to -12.130000dB. This doesn't make sense because the /k switch is suppose to reduce the sound level only up to the level of eliminating clipping.

Here's what the file looks like in the GUI:



From the above picture, my understanding from the docs was that the "/r /k" switch (or "/a /k") should have only changed the volume by -1.5dB.

So, if I'm not crazy, the "/m" and "/d" switches don't work in combination of the "/s r" switch, which I think is a bug. And also, the "/k" switch doesn't seem to be working properly either.

I'm new at this so I'm most likely wrong. If this is not a bug, some help please, it's killing me. Oh, I also tried manually changing by hand the REPLAYGAIN_TRACK_GAIN to -3.130000 in the APE tag which gave ok results, but this is not optimal since I don't know how to calculate the other variables such as MP3GAIN_MINMAX and  REPLAYGAIN_TRACK_PEAK.

MP3GAIN BUG

Reply #1
AHA! Once again I've made a fool of myself!!!

Between the functionality in Winamp and a new understanding of what MP3Gain does, I can achieve what I desired.
But, going through all this makes me want a way to make this a one step process.

The problem is, my car has a replaygain aware player but no pre-amp function like Winamp. At home, I play music on Winamp with Replaygain set to "Apply Gain / Prevent Clipping" and Replaygain Pre-amp +3.0. In order to get the same results in the car, I have to go through three steps.

Code: [Select]
1. Collect the files I want in a folder

2. Because of unicode filenames, I need to copy them to my linux machine and run:
    find . -name *mp3 -exec mp3gain /d 3 /r /k {} \;

3. Because the car player will recognize the gain information in the tags and re-reduce the volume again, I must strip tag info:
    find . -name *mp3 -exec mp3gain /s d {} \;


Instead of all this, could the author make it possible to do:
Code: [Select]
mp3gain /d 3 /s r filename.mp3


So an arbitrary dB level other than 89 can be chosen to store tag information. That way, the above process can be reduced to one step -- 1. Collect the files already stored at desired dB levels on HD with no further processing needed for replaygain aware players (like my car).


MP3GAIN BUG

Reply #3
I'm not sure it's that dead. These links indicate activity as recent as Aug. 2010:

Snelg (Glen Sawyer, the mp3gain author) last logged into these forums in Dec. 2010. Trying sending a PM to him to point him to this thread. davelasker (Dave Lasker, the aacgain author) was logged in today, and posted as recently as a few days ago.

MP3GAIN BUG

Reply #4
Dave Lasker, the aacgain author) was logged in today, and posted as recently as a few days ago.
Yes I am here. I have very little time for aacgain these days; I only look into issues that appear to be serious bugs caused by Apple's ongoing changes to the m4a file format. I do not have write access to Glen's mp3gain code which interpret the parameters, which is shared by both mp3gain and aacgain. I was able to confirm that /d seems to have no effect when combined with /s r. Most users avoid using the /s parameters, since they make it impossible to automatically undo changes to return the file to its original (pre-mp3gain) gain.

If all of your players are mp3gain aware, why do you need to modify the gain (with /r or /a)? If mp3gain doesn't allow you set the tags as you wish without modifying the gain, then take a look at Foobar 2000.

MP3GAIN BUG

Reply #5
I'm not sure it's that dead. These links indicate activity as recent as Aug. 2010.....


Right, but the OP's issue is with mp3gain and not aacgain. Not aware of any core updates to mp3gain since 2005 (2004?). Please correct me if I'm mistaken as I'd love an updated version related to mp3--don't use aac.

MP3GAIN BUG

Reply #6
the OP's issue is with mp3gain and not aacgain. Not aware of any core updates to mp3gain since 2005 (2004?).

One of the three places I pointed to was aacgain because it's built on mp3gain and does everything mp3gain does, including handling MP3 files. It just has additional features and capabilities for handling AAC files as well. In theory, any newly discovered bugs that aren't MP3-specific, like the OP is asking about, could be fixed in either program, so if snelg is unresponsive, davelasker could solve it in his branch. (However davelasker's response indicates that's not actually true at the moment for this particular issue.)

The OP also wasn't asking about a core issue. You were skeptical the bugs wouldn't be fixed because there'd been no "active development" for years, and you pointed to a pretty dead branch of the source code repository. But I looked at the main parts of the repository and saw relatively recent activity—little bug fixes and enhancements no less significant than what the OP is asking for—so I am more hopeful that nudging snelg could have positive results.

MP3GAIN BUG

Reply #7
I was able to confirm that /d seems to have no effect when combined with /s r. Most users avoid using the /s parameters, since they make it impossible to automatically undo changes to return the file to its original (pre-mp3gain) gain.

If all of your players are mp3gain aware, why do you need to modify the gain (with /r or /a)? If mp3gain doesn't allow you set the tags as you wish without modifying the gain, then take a look at Foobar 2000.


Thanks to everyone who posted here. It's nice to get some answers, if not to solve my problem but to indicate there's still some interest in mp3gain.

Now, if I'm not mistaken, the /s switch only does a scan and /s r only writes to tag. Undoing any changes simply involves deleting the tags with /s d... if I'm not mistaken...

The problem with mp3gain (and as I've found, all other replaygain taggers like metaflac etc...) is they persist with the 89dB target with no way to change it. If I wanted more than 89dB, I must alter the file itself with the /d, /r, /a switches instead of using the tag method with the /s switch. If I leave it at 89dB, I must put winamp volume at max and increase speaker volume, making everything else (like Windows sounds, youtube, etc) too loud.

I think another problem with replaygain is in the algorithm itself. Some music is supposed to be louder. Replaygain sets everything to 89dB with no way to change it except modifying the files. I feel a good feature would be to allow tagging with a different target level other than 89dB, much like "mp3gain /d 3 /s r filename.mp3" should do if it weren't bugged.

 

MP3GAIN BUG

Reply #8
Now, if I'm not mistaken, the /s switch only does a scan and /s r only writes to tag. Undoing any changes simply involves deleting the tags with /s d.

/s r means "force re-calculation (do not read tag info)". This ignores the MP3Gain tags currently written, as if you are running it for the first time on the file. /s d removes the tags, without undoing any gain changes made to the file. If you want to undo gain changes, you must use /u prior to /s d. If you use /s d without first using /u, it is impossible to automatically undo any changes made with /r or other gain-changing parameters.

Dave