### 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 is NOT lossless (Read 12606 times)
0 Members and 1 Guest are viewing this topic.

## mp3gain is NOT lossless

##### 2005-05-20 02:44:37
Years ago I read the source code of mp3gain. Since then I always whince when somebody says that it is a lossless conversion. I have not  bothered to prove it is not, but this week I read this mentioned so ma ny times that I have to speak up.

Before I start let me tell you that I will not use the precise terms because I do not remember them. It was years ago and I was never into MP3 terminology.

Anyway. MP3 files are a sequence of, let's call them "frames". Each of these have a "gain" associated with. This is a integer number ranging from, say, 0 to 255. Say, a single increment represents "1.5" dB. Now, say, the mp3gain analysis concludes that we have to reduce the volume by 6 dB. Then mp3gain will decrement all these gains by 4. (4*1.5 = 6) and saves this 6dB reduction as a metadata (in some obscure tag format for good measure). So the idea is that when you want to restore the original state you just read this tag and add that 4 to all these gain values. The trouble is that if you have some frame that had gain value that is below integer 4 would need to become negative numbers after the decrement by 4, but the lowest value is 0. So they are set to 0. Now when you "recover" they are end up become 4, but they were less then 4 before. And of course the same argument applies at the top limit of 255.

So in practice it is lossless in the majority of the cases, but not for most of us on this forum who generally bother about digital audio in a rather geekish way.

Boy! I posted onto the wrong forum. Moderators please move it somewhere more appropriate.

## mp3gain is NOT lossless

##### Reply #1 – 2005-05-20 07:31:22
Well i suppose that might be true... but think about it - you're complaining that a sample with ZERO volume might accidentally get turned up a few db in the event that you decide to reverse your gain adjustment. Hardly anything to worry about. Anyhow, if you're anal like me, use --scale instead

## mp3gain is NOT lossless

##### Reply #2 – 2005-05-20 07:54:24
If this is true then couldn't you use MP3Gain as an mp3 compressor? First, apply a constant gain of say -12db then undo it.

## mp3gain is NOT lossless

##### Reply #3 – 2005-05-20 08:26:09
I'm no expert, but reading the mp3gain help ("mp3gain /? wrap") the other day I saw this:

Quote
Here's the problem:
The "global gain" field that mp3gain adjusts is an 8-bit unsigned integer, so the possible values are 0 to 255.

MOST mp3 files (in fact, ALL the mp3 files I've examined so far) don't go over 230. So there's plenty of headroom on top-- you can increase the gain by 37dB (multiplying the amplitude by 76) without a problem.

The problem is at the bottom of the range. Some encoders create frames with 0 as the global gain for silent frames. What happens when you _lower_ the global gain by 1? Well, in the past, mp3gain always simply wrapped the result up to 255. That way, if you lowered the gain by any amount and then raised it by the same amount, the mp3 would always be _exactly_ the same.

There are a few encoders out there, unfortunately, that create 0-gain frames with other audio data in the frame. As long as the global gain is 0, you'll never hear the data. But if you lower the gain on such a file, the global gain is suddenly _huge_. If you play this modified file, there might be a brief, very loud blip.

So now the default behavior of mp3gain is to _not_ wrap gain changes. In other words,
1) If the gain change would make a frame's global gain drop below 0, then the global gain is set to 0.
2) If the gain change would make a frame's global gain grow above 255, then the global gain is set to 255.
3) If a frame's global gain field is already 0, it is not changed, even if the gain change is a positive number

To use the original "wrapping" behavior, use the "/w" switch.

So, using the /w swtich would insure lossless gain, right? With the aforementioned chance of a badly-encoded frame having a huge gain.

## mp3gain is NOT lossless

##### Reply #4 – 2005-05-20 08:26:14
In my opinion, if these mp3 which contain non-silent frames with non-zero global gain really exist, there is a straightforward two-pass solution where mp3gain would do:

Pass One (g[] = global gains;  n = gain_change)
Code: [Select]
`If n > 0   For each g[i]      If g[i] + n > 255         n = 255-g[i]Else If n < 0   For each g[i]      If g[i] - n < 0         n = 0-g[i]Print a warning in case n had to be changed.`

Pass Two (what mp3gain currently does -- but without clipping/wrapping checks):
Just apply the gain variations, as clipping or wrapping can't happen anymore.

Question: But is this rare problem really worth doing two passes ?
Answer: We already do two passes: so maybe we could combine this first pass with the replaygain processing ?

## mp3gain is NOT lossless

##### Reply #5 – 2005-05-20 11:30:22
another option would be to handle 0 and 255 as special values (never changing them) and in the case that a global gain code is within 1..254 and becomes <=0 or >=255 after adjusting the program could output a complaining error message. This is how i did it once in a similar application -- I never encountered this special situation (i called global gain clips).

Sebi

## mp3gain is NOT lossless

##### Reply #6 – 2005-05-20 11:46:59
I think we need to put this into persepctive...

The 0-255 range of GlobalGain, in 1.5dB steps, give a 384dB range. CDs, as best, have a 96dB range in theory. (Though it could be more or less, depending on the equipment, the signal, and how you measure it).

If you start with a full scale 1k sine wave (0dB FS), you can go down to -200dB FS and back again, and up to +160dB FS and back again without problems. I know - I've just tried it!

At -212dB you hit problems, and at +172dB you hit problems.

Digital silence is minus infinity dB, so that's the only place you can realistically have an issue - and the way Glen has now implemented it marks out a global gain of 0 as a special case, so there's no problem here.

You might think something near digital silence could be a problem - if so, consider this case: A global gain of 4 (which would get mapped down to 0 if you did a 6dB or greater drop, and hence couldn't be increased back to 4 if you did a greater than 6dB increase) would represent a level of -206dB FS. That's 0.000003 of the least significant bit at 16-bits (in a lossy format!!!), or 0.00000000005 of digital full scale. If an mp3 encoder is encoding this value, it really doesn't mean anything!

The kind of values an mp3 encoder might, at best, meaningfully encode (e.g. from just below the least significant bit, up to just above digital full scale), still gives you over 100dB of room at both ends of the scale in this simple example, and easily well well over 40dB with real music - who is applying mp3gain adjustments of +/-40dB?

Cheers,
David.

## mp3gain is NOT lossless

##### Reply #7 – 2005-05-20 17:15:33
I'm not sure but that might be the reason for the problem I've posted in another thread: http://www.hydrogenaudio.org/forums/index....3296&hl=mp3gain
--alt-presets are there for a reason! These other switches DO NOT work better than it, trust me on this.
LAME + Joint Stereo doesn't destroy 'Stereo'

## mp3gain is NOT lossless

##### Reply #8 – 2005-05-20 18:46:15
OK I rest my case. 2dBdecided has a good point. I never thought it over. Parly because in those days Lame had issues with overcompressed signal I planned to use --scale just as Jebus mentioned. In fact I gather all this from one of the thread he started. Before I trascoded my collection from FLAC and settled on ogg so there you have it. I just felt having a myth-busting day yesterday. I hope it helped some though.

Triza