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: Wavegain vs. MP3Gain (Read 173500 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Wavegain vs. MP3Gain

Reply #100
Actually, while the usual intuitive picture of digital signal representation implies that sound is suddenly cut off, in fact, dither ensures that sound below the lowest bit isn't suddenly muted at all but gradually fades into the hiss.

This post of mine demonstrates this phenomenon in a graphical manner that approximates in many respects how the ear works. Look at the graph of the full scale 1760 Hz tone and onwards. Ignore the harmonic distortion graph.

So, if we took a 16-bit PCM WAV and Replaygained it down by 9 or 10 dB, with normal dither (e.g. Foobar2000 diskwriter or Wavegain), then raised the resulting WAV by 9 or 10 dB, the sound would still retain its analogue nature of quiet sounds in fadeouts sinking gradually into the noise, but the noise floor would be higher by about 9 to 10 dB than the original CD.

However, if the original CD had flat dither (as many do) and we applied strong ATH noise shaping dither when Replaygaining, the perceived noise floor would get no worse than before (or an imperceptible worsening), because the perceptual loudness of this noise shaping dither is something like 15 dB lower than the perceptual loudness of normal dither, meaning that the perceptual loudness of the original CD's flat dither would dominate.

I actually used ReplayGain as a way of estimating the perceived loudness of the two dither types. Using Foobar2000 to play 10 seconds of silence, Add Location... silence://10 I then used diskwriter with dither and only Resampler DSP to convert to 44100 S/s, to write out an 8-bit PCM WAV, first with dither but no noise shaping, then with strong ATH noise shaping dither.

Don't forget this was 8-bit, so the dither noise is fairly audible.
No noise shaping dither: RG reports +31.51 dB gain (peak = 1/128 = 0.007813)
Strong ATH n-sh dither: RG reports +45.15 dB gain (peak = 25/128 = 0.195313)

This is an approximation of the gain required to reach 89 dB SPL perceptual loudness, and indicates that the strong ATH noise shaping dither is likely to be perceived as something like 13.64 dB quieter than dither without noise shaping.

(The RG gain required to reach 89 dB SPL would be 48 dB higher for 16-bit sources)

Replaygain only uses and approximation to the Fletcher Munson equal loudness curves, and in fact, the ear is a little less sensitive to high and low frequencies at sound levels close to the absolute threshold of hearing (0 dB SPL) than it is at volumes around 89 dB SPL (where ReplayGain's curve is optimised) so it makes sense to imagine that the true perceived difference in loudness of dither types in 16-bit recordings is a few dB greater than the suggested 13.64 dB when played back at normal volumes.


Fletcher Munson Equal Loudness Contours

Anyhow, this isn't directly applicable to Lame using the --scale, then applying mp3gain to restore the volume to the original >>89 dB loud level.

Firstly, Lame uses floating point arithmetic internally, so doesn't lose any information or raise the relative noise floor when scaling down.

However, it does have an adaptive ATH which is applied to the frequency spectrum to ignore anything presumed inaudible. A simple adaptive ATH model would keep a known dynamic range from the general loudness of the music to the presumed threshold of hearing and assume that volume would be adjusted to a comfortable listening level. However, Lame assumes that sometimes loud music is played at higher than normal volumes, so the adaptive ATH isn't raised so much in case of details being lost in fade-outs. It will then simply quantize remaining details to the accuracy demanded by the calculated psychoacoustic masking threshold and ignore any details that are completely masked.

The inefficiencies of the sfb21 scalefactor workaround problem seem to occasionally cause bitrate bloat, and this does seem most pronounced with modern overly loud (extremely dynamically compressed) recordings. Sometimes an appropriate --scale will happen to hit a happy spot where the sfb21 problem doesn't require the workaround, so saving major bits. I guess it could possibly make it worse sometimes too.

If you intend to play back the sound at comfortable volumes (as people using mp3gain or even people using volume controls usually do), there shouldn't be any audible problem (apart from the bad quality and lack of punch of the original CD, caused by its dynamic compression). If you play it particularly loud yet somehow some of the loud sounds don't mask extremely quiet sounds at very different frequencies and very near the threshold of hearing, then I guess there might be a problem that certain sounds that should be audible have been removed by the higher relative ATH of the --scale version. I'd have thought this would be very rare if it happens in any music or test tones at all, and it would need ABXing to prove if it really happens.

My guess (and it's only a guess) is that problems would be so rare, if they happen at all, that even the loudest playback would be worth expending so many extra kbps on when other unfixable artifacts might be far more common. But that is only a guess and a personal value judgement.

The other question is a matter of playback decoder. If the decoder doesn't dither, you may be lucky and find that enough self-dithering occurs (various tones and noiselike signals that are incommensurate with the quiet tones usually provide enough variation in the decision threshold of the last bit that the quiet tones get through without significant/audible truncation distortion). An exception is in exceptionally quiet fadeouts, but this is a problem of the decoder and should occur with or without the --scale. (That's unless the adaptive ATH doesn't vary quickly enough during certain fades, and temporal masking isn't enough to hide the ultra-quiet sounds anyway)

Any corrections?

DickD

Wavegain vs. MP3Gain

Reply #101
mmortal03:

Well, I just did a quick test with a SPL meter, and it appears I like to listen to music at about 70dB average SPL. This means that the 89dB audio files still have 19dB of material below the threshold of hearing.

Listening at 89dB is in itself very painful. Do many metal concerts even hit that? I'd say that 89dB was an excellent choice for replaygain to use - I have only one album that is quieter than that (and only by a scale of 1.032 or so), so it removed clipping entirely, and doesn't throw out anything I might miss when played back at below ear-splitting volumes.

Wavegain vs. MP3Gain

Reply #102
I think the key point, Jebus, is the word average (as you mentioned in our quick exchange of PM's)

Replaygain chooses the instant ranking 95% of the way from quietest to loudest, as this is perceived to be pretty close to the representative perceived loudness of the audio, whether the audio has lots of silence (like speech) or is punchy or dynamic (like orchestral) or is of an almost constant level (like modern overcompressed pop and rock).

You average SPL measurement is probably nearer to 50% of the way from quietest to loudest (though probably not quite that low in fact)

It would match ReplayGain when listening to constant pink noise (like how theatre/cinema sound is calibrated), so if you listen to pink noise at 89 dB SPL then adjust your music to sound equally loud, you might well find it's much closer to 70 dB average SPL (perhaps 76 dB or so) on that same piece of music you just used. Programs like CoolEdit 96 (shareware) can generate pink noise, and ReplayGain can adjust it to the same perceived loudness as a piece of music, but because it's constant, the pink noise will register higher on your average SPL meter.

Wavegain vs. MP3Gain

Reply #103
Fair enough...

I did another test, worst case scenario:

Joy Division track "Dead Souls" (chosen because, recorded in 1980, it actually came at 89dB on the CD, with none of the compression that plagues modern recordings)

At a comfortable listening level I was getting peaks around 80dB. If I crank it to a slighly uncomfortable level, I get peaks around 86dB. Not average volume this time. These were the loudest volumes the needle hit.

Now this particular recording has peaks around 100dB when scanned with wavegain, so you can assume I am listening at around 20dB below the volumes LAME is tuning for. AND, as DickD mentioned, LAME assumes you will be listening above the assumed average gain, just in case.

Given this information, I really don't see a problem with loss of information at 89dB. Don't forget that modern compressed recordings have their noise floors artificially raised as well, so you might be loosing 0 information, even in theory.

Wavegain vs. MP3Gain

Reply #104
89dB isn't particularly loud, and pretty much any concert of any music type will be much louder than that.  120dB isn't uncommon.

Wavegain vs. MP3Gain

Reply #105
I tested an album, Thomas Fersen - Pièce montée des grand jours, with the command line --alt-preset extreme --scale 0.xxxx (lame 3.90.3 recommended version) and the result is that the non --scale album is bigger than the scaled one ?? 

Aynone have a clue ?

Soren

Wavegain vs. MP3Gain

Reply #106
Quote
I tested an album, Thomas Fersen - Pièce montée des grand jours, with the command line --alt-preset extreme --scale 0.xxxx (lame 3.90.3 recommended version) and the result is that the non --scale album is bigger than the scaled one ??  

Aynone have a clue ?

Soren

that's like, the whole point of this thread!

Wavegain vs. MP3Gain

Reply #107
  looks my english need more training 

i tough the thread was saying the opposite, darn

Soren

Wavegain vs. MP3Gain

Reply #108
Just came across this thread today.

Has a version of LAME been released with this included?

I went to Rarewares and I see John33 has posted a version of Lame on 27th June, but not since (i.e.: since the last post in this thread).

I'd like to give this a try.
I'm on a horse.

Wavegain vs. MP3Gain

Reply #109
Hi there!
Uff, it took me almost two days to read all the posts and I have a few questions...

1) Is there a option which can determine the value for the --scale switch that do maximum volume no-clip like in MP3 gain? I've noticed that in some cases MP3 peak level goes higher than the original sometimes lower... Is it possible to determine the scale value so simply that if I create those MP3's and analyze them through MP3Gain it don't show me any clipping?

2) Someone here has said that --scale lowers the quality, where's the truth? I'm listening mainly to extreme metal and there was said that this issue was deteected in metal music.

My goal is to have MP3's as close to the original files but with no clipping. I've noticed, that this way I can lower the bitrate and also be more precise with lowering the gain to max. no-clip...
Sorry for my poor English, I'm trying to get better... ;)
"The greatest trick the Devil ever pulled, was convincing the world he didn't exist."

Wavegain vs. MP3Gain

Reply #110
Anybody out there who can answer my questions and make it clearer for me?
Sorry for my poor English, I'm trying to get better... ;)
"The greatest trick the Devil ever pulled, was convincing the world he didn't exist."

Wavegain vs. MP3Gain

Reply #111
1) To the best of my knowledge there is no way of predicting what may result in a clipped sample when encoded into mp3. I would imagine that this will vary as between one encoder and another, anyway.

2) --scale can technically result in a lowering of quality in that when reducing the scale, there will, no doubt, be some samples that consequently fall below the threshold and are ignored by the encoder. However, were you to turn the volume control down instead, effectively the same thing will also happen. To be honest, I'd be amazed if anyone can produce an example where the difference is identifiable when listened to at the same volume. It's important to bear in mind that we are, in any case, talking about a lossy encoder, where the object of the exercise is to throw away inaudible information!!

Wavegain vs. MP3Gain

Reply #112
Thanks a lot John!
The sad thing is, that without your or anyone other's help I can't do my MP3's noclipped only with WaveGain & --scale switch and I must stick with MP3Gain.
Well, MP3Gain is a wonderful piece of SW but when I could do an MP3's that would be a bit smaller and doesn't clip I'd love to choose this way...
Maybe anyone (Jebus, DickD...) has some idea...?
Sorry for my poor English, I'm trying to get better... ;)
"The greatest trick the Devil ever pulled, was convincing the world he didn't exist."

Wavegain vs. MP3Gain

Reply #113
Quote
1) To the best of my knowledge there is no way of predicting what may result in a clipped sample when encoded into mp3. I would imagine that this will vary as between one encoder and another, anyway.
[a href="index.php?act=findpost&pid=248706"][{POST_SNAPBACK}][/a]


Well, I will always use a recommended LAME setting & compile (--alt-preset standard & 3.90.3 nowadays). I just want to know if is there a possibility to guess what's the lowest level I have to scale down to have MP3's without clipping (or possible clipping as MP3Gain mainly reports in today's music)...

I remeber that in r3mix there was a "--scale 0.98" switch in the command line explained as:

Quote
This will systematically "normalize" down all encoded pieces to 98% of what you put in.  Don't worry, this is by far unaudible and will guarantee that even the signals with the highest peak volumes, up to 100% will have virtually no clipping after the mp3 encoding-decoding cycle.


But when I looked at MP3's made by r3mix command line (not the actual remapped) MP3Gain showed these MP3's to be clipped (or possibly clipped).
Sorry for my poor English, I'm trying to get better... ;)
"The greatest trick the Devil ever pulled, was convincing the world he didn't exist."

Wavegain vs. MP3Gain

Reply #114
Hello.

Don`t bite me.
Quote
I remeber that in r3mix there was a "--scale 0.98" switch in the command line explained as:

This will systematically "normalize" down all encoded pieces to 98% of what you put in.  Don't worry, this is by far unaudible and will guarantee that even the signals with the highest peak volumes, up to 100% will have virtually no clipping after the mp3 encoding-decoding cycle.


But when I looked at MP3's made by r3mix command line (not the actual remapped) MP3Gain showed these MP3's to be clipped (or possibly clipped).


To my knowledge of lame, this is not possible.
Even if the source is perfect levelled, there is always gonna be added "noise".
either true decoding, or both enc/dec.
in comparrisons, lame seems to have higher gain numbers, than ex: mpc.
So it would be pretty safe to say it would be coused by the "mp3 format".


Wavegain vs. MP3Gain

Reply #115
Quote
Thanks a lot John!
The sad thing is, that without your or anyone other's help I can't do my MP3's noclipped only with WaveGain & --scale switch and I must stick with MP3Gain.
Well, MP3Gain is a wonderful piece of SW but when I could do an MP3's that would be a bit smaller and doesn't clip I'd love to choose this way...
Maybe anyone (Jebus, DickD...) has some idea...?
[a href="index.php?act=findpost&pid=248710"][{POST_SNAPBACK}][/a]


What would be nice is a front-end which ran a max-noclip or 89dB analysis of an entire directory using wavegain, then plugged this value into LAME as a --scale and ran lame on all the files. I'd love such a thing to exist but I unfortunately don't have the coding expertise as of yet.

Wavegain vs. MP3Gain

Reply #116
Quote
What would be nice is a front-end which ran a max-noclip or 89dB analysis of an entire directory using wavegain, then plugged this value into LAME as a --scale and ran lame on all the files. I'd love such a thing to exist but I unfortunately don't have the coding expertise as of yet.[{POST_SNAPBACK}][/a]
I thought that this is what John intends to do.

[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=10637&view=findpost&p=110529]http://www.hydrogenaudio.org/forums/index....ndpost&p=110529[/url]

Or was that a subtle hint? 
I'm on a horse.

Wavegain vs. MP3Gain

Reply #117
Quote
Quote
What would be nice is a front-end which ran a max-noclip or 89dB analysis of an entire directory using wavegain, then plugged this value into LAME as a --scale and ran lame on all the files. I'd love such a thing to exist but I unfortunately don't have the coding expertise as of yet.[{POST_SNAPBACK}][/a]
I thought that this is what John intends to do.

[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=10637&view=findpost&p=110529]http://www.hydrogenaudio.org/forums/index....ndpost&p=110529[/url]

Or was that a subtle hint? 
[a href="index.php?act=findpost&pid=249037"][{POST_SNAPBACK}][/a]


This version of LAME & WaveGain already exist, but it don't solve the adjustment I want to do...

I don't think it is a subtle hint, but as John33 already said:

Quote
1) To the best of my knowledge there is no way of predicting what may result in a clipped sample when encoded into mp3. I would imagine that this will vary as between one encoder and another, anyway.

2) --scale can technically result in a lowering of quality in that when reducing the scale, there will, no doubt, be some samples that consequently fall below the threshold and are ignored by the encoder. However, were you to turn the volume control down instead, effectively the same thing will also happen. To be honest, I'd be amazed if anyone can produce an example where the difference is identifiable when listened to at the same volume. It's important to bear in mind that we are, in any case, talking about a lossy encoder, where the object of the exercise is to throw away inaudible information!!
[a href="index.php?act=findpost&pid=248706"][{POST_SNAPBACK}][/a]


It seems that this is not an elementary problem...

But I hope there's a possibility to determine the safe amount of --scale level (maybe by WaveGain) to avoid MP3 clipping but keep it as close to the loudness of the original.
Sorry for my poor English, I'm trying to get better... ;)
"The greatest trick the Devil ever pulled, was convincing the world he didn't exist."

Wavegain vs. MP3Gain

Reply #118
Quote
This version of LAME & WaveGain already exist
[a href="index.php?act=findpost&pid=249091"][{POST_SNAPBACK}][/a]
Cool.  Can someone please tell me where I can I get it?

If it's at Rarewares with John's other work you are going to have to be specific because I can't see it for looking 
I'm on a horse.

Wavegain vs. MP3Gain

Reply #119
Quote
Quote
This version of LAME & WaveGain already exist
[{POST_SNAPBACK}][/a]
Cool.  Can someone please tell me where I can I get it?

If it's at Rarewares with John's other work you are going to have to be specific because I can't see it for looking 
[a href="index.php?act=findpost&pid=249104"][{POST_SNAPBACK}][/a]


Sure! Here they are: [a href="http://www.rarewares.org/files/mp3/lameexe3.90.3_MOD.zip]LAME 3.90.3 EXE Modified[/url] / LAME 3.90.3 DLL Modified / LAME 3.96.1 DLL Modified and the latest WaveGain v.1.0.5 with Speek's Frontend

But I think it's not so difficult for you to find it yourself, is it?
Sorry for my poor English, I'm trying to get better... ;)
"The greatest trick the Devil ever pulled, was convincing the world he didn't exist."

Wavegain vs. MP3Gain

Reply #120
Thanks for the links.  I was looking for some with "WAVEGAIN" and "SCALE" in big red letters...

I guess I must be confused.

I thought  that, when John said:

Quote
Give me a couple of days, or so, and I'll post a 3.90.3 version with APE and Cuesheet support, but optionally with a WaveGain first pass to generate Track/Album gain values for automatic use in '--scale xxx'.
[a href="index.php?act=findpost&pid=110529"][{POST_SNAPBACK}][/a]
...  this meant that LAME would call WaveGain (or maybe even that the WaveGain functionality would be built into the LAME exe).

I've looked at the readme's for both the LAME exe and WaveGain and I can't see how the information is transferred "automatically".

Maybe someone could draw me a diagram. 

Edit: I know the Modified EXE allows you to set the --scale value from an INI file - but that's no leap in itself is it?  I thought the --scale switch was part of the core LAME development.  Therefore, what I still have is two separate EXEs doing related things, but no direct link.  I think.
I'm on a horse.

Wavegain vs. MP3Gain

Reply #121
Quote
I've looked at the readme's for both the LAME exe and WaveGain and I can't see how the information is transferred "automatically".

Maybe someone could draw me a diagram. 
[a href="index.php?act=findpost&pid=249113"][{POST_SNAPBACK}][/a]


Yeah, that's the same think as I'm searching, but meanwhile there's nothing other to use except MP3Gain.
Well, to be honest I don't need all this in one package, just some advice how to do what I want to do...
Sorry for my poor English, I'm trying to get better... ;)
"The greatest trick the Devil ever pulled, was convincing the world he didn't exist."

Wavegain vs. MP3Gain

Reply #122
well if ALL you want to do is encode things with no clipping, just use --scale 0.98 on everything. Also maybe add --noclip so that LAME spits out an error whenever it detects clipping.

The problem is that encoders quantize stuff, so a given sample at full scale for instance might get raised (and thus clip) or might get lowered a bit (which is not an issue). You can only fix this behaviour after the fact using MP3Gain, or by just lowering things a bit before encoding. I'd say this is far preferable, since MP3Gain does things in big 1.5dB chunks. Just use --noclip to make sure 0.98 is sufficient.

Wavegain vs. MP3Gain

Reply #123
Hello.

Quote
well if ALL you want to do is encode things with no clipping, just use --scale 0.98 on everything. Also maybe add --noclip.

I belive that was the point, when r3mix guys wrote that above,
there is pretty safe to say most ppl. here is into the encoding part of the music,
but i think ppl. in general uses music compression as a temperary prosess.
That in turn lead to the issue of "what-goes in, must-go-out" in the same
condition. We are talking about a lossy  prosess, and to have a identical output
seems impossible atm, if not at all.
In my above post, i mentioned that mpeg 2.5 aren`t so "agressive" when it
comes to this. [Q]Is it possible to improve the quantesize code in lame.??



Wavegain vs. MP3Gain

Reply #124
I want to get my MP3's to the volume of original as possible with no clipping. I know that it's lossy so I can't have a perfect copy...
Sorry for my poor English, I'm trying to get better... ;)
"The greatest trick the Devil ever pulled, was convincing the world he didn't exist."