Hydrogenaudio Forums

Hydrogenaudio Forum => General Audio => Topic started by: Jebus on 21 June, 2003, 04:34:07 PM

Title: Wavegain vs. MP3Gain
Post by: Jebus on 21 June, 2003, 04:34:07 PM
Yes, I know that MP3Gain is lossless. No, I am not talking about how MP3Gain is limited to 1.5dB steps (though this is another reason).
What I am thinking is this:

Psychoacoustic models tend to encode louder signals with more bits, right? This is why remasters (compressed) tend to use higher bitrates than older versions. Correct?

If we are then encoding a VERY LOUD album with LAME -aps for instance, then normalizing it down say 10.5dB (for a really bad one), aren't we wasting bits? Wouldn't we be able to save some bits by normalizing it down to 89dB FIRST, then encoding it?

I know wavegain is NOT LOSSLESS, but I am (incorrectly) assuming that this is just a theoretical lossiness, not a perceptible one. If this is the case, couldn't we argue that wavegained tracks will be of lower bitrates while still maintaining transparency (the goal, afterall, of -aps)?


---------------------------------
| UPDATE (May 21st, 2005) |
---------------------------------

The discussion below basically concludes that running a wavegain analysis, then applying the recommended scalefactor to lame (via the --scale switch) will save bits due to high-frequency bloat inherent in the mp3 format. Lots of people have since chosen to use this method over mp3gain, and in fact it can be automated now from within EAC using Wack (http://www.rarewares.org/files/mp3/Wack.zip), or my own Omni Encoder (http://omniencoder.autobotcity.net). Read on!
Title: Wavegain vs. MP3Gain
Post by: Garf on 21 June, 2003, 04:56:31 PM
Why not test the theory?
Title: Wavegain vs. MP3Gain
Post by: Jebus on 21 June, 2003, 05:02:05 PM
Doing that right now... ETA 5min on the encode
Title: Wavegain vs. MP3Gain
Post by: Echizen on 21 June, 2003, 05:10:52 PM
*lol* a new way to save bits. first decrease the volume, encode and then increase with mp3gain
Title: Wavegain vs. MP3Gain
Post by: john33 on 21 June, 2003, 05:12:04 PM
The theory does work in practice, although I don't believe the difference was huge. But then you wouldn't expect it to be that large would you? I should be quoting numbers here, but I don't have any to hand without retesting!
Title: Wavegain vs. MP3Gain
Post by: M on 21 June, 2003, 05:13:21 PM
Hmmm... I'll hazard a simple guess and say "yes," since I know that you can save bits by first using WaveGain and then compressing with a lossless algorithm (tested extensively for FLAC, Shorten and WavPack, although I suspect Monkey's audio and the rest would exhibit similar behavior).

    - M.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 21 June, 2003, 05:20:12 PM
Here are the exciting results:

"Mer De Noms" by "A Perfect Circle"

MP3Gain wanted to do a -9dB adjustment, so this albums is pretty loud, though not the loudest by any means.

The files repaygained after the fact (MP3Gain) totalled 70.6MB
The files replaygained before encoding (Wavegain) totalled 63.4MB

So, using --alt-preset standard, you end up with about a 10% savings for a relatively loud modern recording. I assume the savings will be less for older recordings and more for hypercompressed drivel like they release today.

I think this is pretty significant...
My only thought it, are the files ABXable against eachother? I don't have the ears to do the test unfortunately... Anyone care to try? I certainly hope they are indistinguishable.
Title: Wavegain vs. MP3Gain
Post by: HansHeijden on 21 June, 2003, 05:22:13 PM
For mp3, it would be an idea if wavegain could pass on just the replaygain value to lame's --scale, thereby avoiding the rounding to 16 bits.
Title: Wavegain vs. MP3Gain
Post by: ExUser on 21 June, 2003, 05:23:39 PM
Quote
Psychoacoustic models tend to encode louder signals with more bits, right? This is why remasters (compressed) tend to use higher bitrates than older versions. Correct?

I believe that assertion may be false. If I understand correctly, the overall loudness of a track should have little effect on the encoding. The total amount of perceptible detail in a track is what affects bitrate. The remastered bitrates are probably like that because the process of compression brings previously inaudible details up to the level of audibility.

By decreasing the volume level, you decrease the amount of detail available overall, with some small-amplitude details being obliterated by the noise floor. Thus, saved bits.

Edit: This is my theory, anyhow... Any knowledgeable rebuttals?
Title: Wavegain vs. MP3Gain
Post by: Jebus on 21 June, 2003, 05:25:35 PM
Quote
For mp3, it would be an idea if wavegain could pass on just the replaygain value to lame's --scale, thereby avoiding the rounding to 16 bits.

Dude, that is a wonderful idea! Any LAME/wavegain developers listening?? This would be SO AWSOME!
Title: Wavegain vs. MP3Gain
Post by: john33 on 21 June, 2003, 05:35:04 PM
Quote
For mp3, it would be an idea if wavegain could pass on just the replaygain value to lame's --scale, thereby avoiding the rounding to 16 bits.

You can do that manually by just having the gain calculated.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 21 June, 2003, 05:39:48 PM
Quote
Quote
For mp3, it would be an idea if wavegain could pass on just the replaygain value to lame's --scale, thereby avoiding the rounding to 16 bits.

You can do that manually by just having the gain calculated.

yeh but what a pain! And AFAIK, replaygain won't display an album --scale value, so I'd have to calculate it manually, then apply this with --scale to every encoded MP3 i do. That's pretty time consuming...
Title: Wavegain vs. MP3Gain
Post by: john33 on 21 June, 2003, 07:12:59 PM
Quote
Quote
Quote
For mp3, it would be an idea if wavegain could pass on just the replaygain value to lame's --scale, thereby avoiding the rounding to 16 bits.

You can do that manually by just having the gain calculated.

yeh but what a pain! And AFAIK, replaygain won't display an album --scale value, so I'd have to calculate it manually, then apply this with --scale to every encoded MP3 i do. That's pretty time consuming...

WaveGain will display the Album Gain value in calculation mode and if you have it write the log file, all the values will be saved in the log file for future reference.

BTW, I am the author of WaveGain.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 21 June, 2003, 07:35:01 PM
ah but i need to manually calculate scalefactor from that number right?

AFAIKT, this is simply 10E(replaygain * 0.05)

am I correct? So an album with a recommended gain adjustment of -10.02dB should have a --scale applied to lame that is 3.17? Seems to be roughly 10x too large. I'm going to write a script to automate this process now (once i figure this calc out), since I think this is all-around preferable to using MP3Gain.

EDIT: Nevermind, got it. I forgot to make the replaygain value negative (duh!).
Title: Wavegain vs. MP3Gain
Post by: mrosscook on 21 June, 2003, 10:48:24 PM
Jebus,

In a problem like yours it can help to consider the asymptotic case, i.e., take the process to its logical conclusion.  Suppose that we first wavegain the file to zero volume (digital silence).  Then it takes only 1 bit to encode it. (Or is it 0 bits? Anyhow, it is a pretty good savings in file size). But if we try to gain back the volume of the encoded file, we find that we've lost all the information.

It's reasonable to expect that for intermediate amounts of wavegain, we should get intermediate savings in file size, and also lose intermediate amounts of information.  (Of course, there's no guarantee that the process is linear or even monotonic; but we know where it has to start and end, so it has to pass through the points in between.)
Title: Wavegain vs. MP3Gain
Post by: westgroveg on 21 June, 2003, 11:03:11 PM
The question of whether wavgain artifacts are perceptible still remains
Title: Wavegain vs. MP3Gain
Post by: Jebus on 21 June, 2003, 11:23:08 PM
Well as it stands, I have just ripped a couple of trial albums...

As recommended, what I did was extract using EAC, then run a wavegain ANALYSIS ONLY on the album. From the resulting suggested album gain adjustment I did 10E(gain * 0.05) to get the scalefactor, then ran LAME using:

lame --alt-preset standard --scale 0.3155 (for example - this is By The Way by the Red Hot Chili Peppers)

The resulting files are 10% smaller than if I had used MP3Gain after the encode, there is no theoretically lossy wavegaining being done, and I get much better than 1.5dB per step precision (the above files are 0.02dB over the ideal as set by replaygain).

I can't think of any reason why this is not the best possible way to encode MP3s. Not even much more work. Anyone have comments?
Title: Wavegain vs. MP3Gain
Post by: mrosscook on 21 June, 2003, 11:35:30 PM
Westgroveq,  I think it might be better to say that the question is not whether wavgain artifacts are perceptible, but when they become perceptible. 

If we wavgained all the way to silence, anybody could ABX that as an artifact.  But of course practical values of wavegain are going to lose much less information, and it wouldn't surprise me if 99.9% of all actual wavgain applications were impossible to ABX, by even the battiest of bat-ears on the forum.

It would be interesting to know when the information loss in wavgain becomes great enough to ABX, and it probably depends on the style of music, degree of compression and clipping in the original file, dynamic range of the music, etc.  Any volunteers?

Jebus,  Are you sure that --scale isn't lossy in itself?  You could in principle use it to reduce the volume to zero, couldn't you, just as wavgain could do?
Title: Wavegain vs. MP3Gain
Post by: ExUser on 22 June, 2003, 12:14:28 AM
Quote
As recommended, what I did was extract using EAC, then run a wavegain ANALYSIS ONLY on the album. From the resulting suggested album gain adjustment I did 10E(gain * 0.05) to get the scalefactor, then ran LAME using:

lame --alt-preset standard --scale 0.3155 (for example - this is By The Way by the Red Hot Chili Peppers)

So, just to be absolutely certain, you are not altering the source WAV file in any way, yet are getting smaller file sizes?

There should be no difference between the MP3 files, or very, very little at most, if my understanding is correct.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 22 June, 2003, 12:33:14 AM
Quote
Quote
As recommended, what I did was extract using EAC, then run a wavegain ANALYSIS ONLY on the album. From the resulting suggested album gain adjustment I did 10E(gain * 0.05) to get the scalefactor, then ran LAME using:

lame --alt-preset standard --scale 0.3155 (for example - this is By The Way by the Red Hot Chili Peppers)

So, just to be absolutely certain, you are not altering the source WAV file in any way, yet are getting smaller file sizes?

There should be no difference between the MP3 files, or very, very little at most, if my understanding is correct.

Yes that is correct. No modification of the source wave. They are quite a bit smaller. I've done a number of albums now from the last 10 years and they are coming out an average of 10% smaller.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 22 June, 2003, 12:37:42 AM
Quote
Jebus,  Are you sure that --scale isn't lossy in itself?  You could in principle use it to reduce the volume to zero, couldn't you, just as wavgain could do?

--scale is absolutely lossy, as is the entire encoding/quantization process during which it is set to a particular --scale anyhow (doesn't --aps use a scalefactor of 0.98 anyhow?). By using wavegain you are introducing an extra lossy step which involves additional dithering. This cuts that step out.
Title: Wavegain vs. MP3Gain
Post by: indybrett on 22 June, 2003, 01:29:42 AM
Geez...

Does this mean I have to re-encode everything again 
Title: Wavegain vs. MP3Gain
Post by: Garf on 22 June, 2003, 03:12:17 AM
Quote
(doesn't --aps use a scalefactor of 0.98 anyhow?).

No, only the CBR presets.
Title: Wavegain vs. MP3Gain
Post by: tigre on 22 June, 2003, 03:16:40 AM
- to avoid loss due to applying wavegain (= lowering volume at 16 bit res.) you could use fb2k's diskwriter @ 24 bit and encode the resulting .wav files with lame

- in my MP3 vs. MPC vs. Ogg: Low volume test (http://www.hydrogenaudio.org/forums/index.php?act=ST&f=1&t=6377&hl=low+volume) I got similar results, but I focussed on quality problems not on bitrate.

- I *think* messing with lame ATH settings could have the same effect (--althlower switch with negative values).
Title: Wavegain vs. MP3Gain
Post by: Hanky on 22 June, 2003, 06:11:36 AM
It does not surprise me that files get lower bitrates when encoding to mp3 after first wavgaining them.
The simple fact that I throw away something like 0.5 to 1.0  bit of digital resolution could explain the lower bitrate easiliy.
For example a full range 16 bit signal scaled with let's say a 0.7 factor gives ~15.48 bits digital resolution left.
In general the loss of bits can be expressed as:
Code: [Select]
n=-2log(scalefactor)


Where n = the loss of bit depth of the signal, 2log is the 2 based logarithm

Of course this effect could be avoided by first resampling to 24 bit wav as mentioned  in another post
Title: Wavegain vs. MP3Gain
Post by: HansHeijden on 22 June, 2003, 06:53:41 AM
--scale is applied to float values so the lower volume doesn't throw away bits.

The question is, if it would be better to let lame encode music that is already at a (supposedly) fixed listening volume level, rather than just encode at original level and make the correction afterwards. I would think the first, but perhaps lame (presets) needs some ath 'retuning' to correct for the usually much lower input volumes.
Title: Wavegain vs. MP3Gain
Post by: john33 on 22 June, 2003, 07:06:19 AM
When applying the gain, WaveGain converts the input data to float, performs all gain/hard limiting adjustment and then converts, with or without dithering, back to desired output bitwidth. You can write out 8 bit, 16 bit, 24 bit, 32 bit integers or floats as you wish regardless of the input bitwidth.
Title: Wavegain vs. MP3Gain
Post by: john33 on 22 June, 2003, 07:45:16 AM
Quote
ah but i need to manually calculate scalefactor from that number right?

I just uploaded WaveGain V1.0.1 that does that for you and displays the Scale next to the Album Gain.
Title: Wavegain vs. MP3Gain
Post by: M on 22 June, 2003, 07:58:02 AM
Quote
I just uploaded WaveGain V1.0.1 that does that for you and displays the Scale next to the Album Gain.

Nice! I had just thought to myself, "I wonder how long it will take John to add a scale-factor calculation to WaveGain," and thirty seconds later you did so. 

  Any chance the author of those CoolEdit plugins shared his algorithms...?

    - M.
Title: Wavegain vs. MP3Gain
Post by: de Mon on 22 June, 2003, 09:17:35 AM
May be I misunderstood something... If we are going to gain before encoding what will happen to signal/noise ratio? Gaining them down will increase noise level. Am I wrong?
Title: Wavegain vs. MP3Gain
Post by: Xenno on 22 June, 2003, 09:39:45 AM
Any non-zero value will be raised by the same amount as the gain applied to the file overall. But the difference between the floor and the peak values will stay constant (assuming no clipping). That's why there's no substitute for strongly recorded track versus a weak one that has been RG'd.

xen-uno
Title: Wavegain vs. MP3Gain
Post by: mrosscook on 22 June, 2003, 09:44:25 AM
Tigre, Hanky, HansHeijden, and John33,

I don't think that going to a greater bitdepth, or even to floating-point calculations, alters the problem in principle.  If we carried out the entire wavgain process, for example, from a floating-point input all the way down to floating-point silence, we have still lost all the information in the original signal;  the asymptote is still complete loss.

I agree that in practice the amount of loss is likely to be so small as to be imperceptible, and that higher bitdepths will eliminate noise that would be introduced by dithering otherwise.  But the basic problem is still there.
Title: Wavegain vs. MP3Gain
Post by: Hanky on 22 June, 2003, 12:57:42 PM
After using the search function and finally realizing that this issue was discussed many times before on HA, I came to the conclusion that the whole ReplayGain concept will always be a compromise.
Surprisingly this was stated very clearly in the Replay Gain FAQ (http://replaygain.hydrogenaudio.org/faq_noise.html) as early as december 2001 by David Robinson himself....
Quote
To maintain full dynamic range, the ideal solution is to feed the Replay Level value out of your PC, to your volume control. Obviously this requires dedicated hardware, and few people are going to do this, but it would be possible for those who demand highest quality to put an end to stupid fluctuations in level in this manner. No compromise. No downside.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 22 June, 2003, 02:19:00 PM
Quote
Quote
ah but i need to manually calculate scalefactor from that number right?

I just uploaded WaveGain V1.0.1 that does that for you and displays the Scale next to the Album Gain. 

Thanks John! I actually made this small change myself, but didn't have access to a windows compiler. This shaves a few seconds off my work.

Whether this process is lossy is I suppose still debatable, but as far as I can tell, inputing a --scale value is in all ways superiour to MP3Gaining or Wavegaining...

1) you get precisely 89.0 dB (not +- 1.5dB) like MP3Gain does.
2) you don't have to dither before encoding like Wavegain requires.
3) newer (louder) albums do not receive an inflated bitrate like they would with MP3Gain.
4) signals below the threshold of hearing AFTER GAINING are simply discarded by the psymodel, instead of being artificially turned down later (by MP3Gain).
Title: Wavegain vs. MP3Gain
Post by: ibm2080 on 22 June, 2003, 03:27:20 PM
Quote
Tigre, Hanky, HansHeijden, and John33,

I don't think that going to a greater bitdepth, or even to floating-point calculations, alters the problem in principle.  If we carried out the entire wavgain process, for example, from a floating-point input all the way down to floating-point silence, we have still lost all the information in the original signal;  the asymptote is still complete loss.

I agree that in practice the amount of loss is likely to be so small as to be imperceptible, and that higher bitdepths will eliminate noise that would be introduced by dithering otherwise.  But the basic problem is still there.

I completely agree with you.
You explain it in an earlier post too (same thread, page 1).
I am not sure how the code works at all, I haven't even looked at it to tell you the truth, but I think mrosscook's point is valid from a logical point of view, assuming that the floor is at a constant value and that values below that floor are dropped. If we apply a negative gain, everything in that file will drop by that much. Keep in mind that before the gain was applied there was some sound info that was just above the floor limit. If all that is true, then there should be some sound info that drops below the floor limit if we apply a negative gain (ie is dropped from the file), meaning there is less sound info after the gain process to encode. It also means that if you take the same track, and apply two different gains to it, one being more negative than the other, the resulting files should have two different sizes.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 22 June, 2003, 03:56:08 PM
The thing is, when you MP3gain a file down a few dB, it ends up clipping sounds from the lowend anyhow... so it is still throwing away sound. It is still there in the MP3, just inaudible in the same sense that a too-loud signal is clipped WITHOUT the normalizing. By doing it my way with --scale you are still loosing the same information, but instead of keeping it in the MP3, it is discarded during the encode process.

essentially what I am saying is that yes, if you --scale 0.0 you will have a 0kB file with no information in it. But if you MP3gain a file down to 0, you are also getting a file that will have no audible information - it's still there, but its all been clipped below playback threshold. So in this sense, both methods are just as lossy... the MP3Gain method is reversible however, while the --scale method has lost that data forever in the interest of space savings.
Title: Wavegain vs. MP3Gain
Post by: mmortal03 on 22 June, 2003, 04:08:08 PM
Quote
4) signals below the threshold of hearing AFTER GAINING are simply discarded by the psymodel, instead of being artificially turned down later (by MP3Gain).

This is what I was thinking.  If we aren't going to amplify (or RG) these mp3s later, who cares if we are leaving out sounds below the threshold?  As long as we were going to listen to them MP3Gained in the end anyway, and probably not ever touch them again, it shouldn't matter to the majority of people, and plus there is a 10% file size savings.

My question is, without amplifying these --scale'd mp3s, is there ANY perceptible difference with an equally MP3Gain scaled mp3?  Peceptibly, there shouldn't be.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 22 June, 2003, 04:58:17 PM
I personally can't ABX a difference, but my ears aren't as well tuned as others... Someone wish to do an ABX test on a highly compressed album done both with MP3Gain and --scale?
Title: Wavegain vs. MP3Gain
Post by: _Shorty on 23 June, 2003, 05:10:09 AM
don't certain portions of the mp3 encoding process rely on the volume level of the signal to begin with?  I'm sure it must determine the audibility of certain things in relation to full-scale, no? Or is it all relative to other portions of the signal content, with no regard for full-scale at all?  Seems to me that if full-scale matters then encoding should be done first with replaygain/mp3gain only being done afterwards.  If full-scale doesn't matter at all though, then it would seem to make sense to --scale the data after all. But this also makes me wonder something else.  Wouldn't mp3 encoder quality, or any lossy format at all for that matter, sound best with a certain standardized playback volume so it could actually match up with what the psy-model is throwing away?  Surely absolute volume matters too, and not just relative volume of differing frequency components.
Title: Wavegain vs. MP3Gain
Post by: 2Bdecided on 23 June, 2003, 05:57:27 AM
In most of this thread, the real problem is only just hinted at.

Don't worry about what replay gain is doing or what scale is doing - you're not losing anything at all here when using the calculated value to set --scale in lame. Also, don't worry about what happens at the very limit: --scale 0.0 isn't possible - it's silence, and it's infinite attentuation. --scale 0.0 is less than -50dB, less than -100dB, less than -200dB, - it's -infinity dB! As such, it's misleading and irelevant. Take -100dB as the limit case: perfectly possible without loss in 32-bit floating point calculations. So, no need to worry there.

We're left with two worries: what lame does, and what happens at the 16-bit output when decoded. OK, forget the second one of these - this is always an issue with Replay Gain, and was discussed before there was even any RG software available (thanks for the quote Hanky!).


So, we have one, and only one issue: what does lame do? IIRC It supposedly looks at the "loudness" of the signal, makes some assumptions from this, and enforces a sensible absolute threshold of hearing. This is most critical for quiet tracks - if it assumed that you will never turn up the volume to hear them, then most of the audio signal is way below hearing threshold, and can be discarded. This used to happen, but people often turn up the volume, and heard problems: so (again, IIRC) for a few years now, lame has taken this into account, and shifted the ath down for quieter tracks. There's a time constant involved, and it may not be a linear process - this is why changing the volume before encoding can change the output file size. If lame were adjusting everything immediately and linearly, scaling a file in the floating point domain would make no difference at all to the resulting filesize.

There are probably other factors at work here. What worries me slightly is that lame --aps has been tuned with tracks ripped from CDs. Not with tracks ripped from CDs and then dropped by 10dB. If you get a smaller file, then by ddefinition it has less information in it. Something has been lost. The question is what? and does it matter?


Maybe it's possible to tell lame that the file has been replay gained, and that you will be listening to this track at a particular loudness - that then fixes the ath. It would be interesting to do this, so fixing the ath at the "correct" value, to see what kind of bitrates this yields.

Replay gain originally targetted 83dB. This calibration assumes that a full scale sine wave will give 103dB SPL. Most of the current implementations target 89dB. This calibration assumes that a full scale sine wave will give 97dB SPL.

I bet that lame is guessing that a full scale sine wave would give about 85-90dB SPL  for highly compressed tracks. What switches can people use to turn off lame's automatic ath adjustment, and to enforce it at a level which makes sense if a full scale sine wave = 97 dB SPL?

(I'm assuming that no one will listen louder than this, and that listening quieter than this will not break the psychoacoustics. Both these assumptions are false, but so are any assumptions that assume how loud people will listen - including the current automatic one in lame - so I'm hoping this doesn't cause any problems).


John - is Wavgain using 83 or 89dB target?

Lame experts - which switches can fix the ath where we want it?

Jebus - can you try whatever gets suggested with your test track and report back please?

Dibrom/other devs = if you're reading this, can you see any way in which this would break --aps or lame in general?

Cheers,
David.
Title: Wavegain vs. MP3Gain
Post by: john33 on 23 June, 2003, 06:10:39 AM
Quote
John - is Wavgain using 83 or 89dB target?

Cheers,
David.

89dB.
Title: Wavegain vs. MP3Gain
Post by: ibm2080 on 23 June, 2003, 08:14:33 AM
Quote
There are probably other factors at work here. What worries me slightly is that lame --aps has been tuned with tracks ripped from CDs. Not with tracks ripped from CDs and then dropped by 10dB. If you get a smaller file, then by ddefinition it has less information in it. Something has been lost. The question is what? and does it matter?

Cheers,
David.

That is the heart of the problem as I see it.
Title: Wavegain vs. MP3Gain
Post by: dev0 on 23 June, 2003, 09:45:11 AM
Let's just take a look at the current possibilities to apply ReplayGain to an MP3 (as pointed out in this thread; excluding fb2k's implementation):

Original -> lame -> MP3Gain

Original -> Wavegain (+ Dither/NS?) -> lame

Original - > (Wavegain to calc. scale) -> lame + scale

Another interesting point to consider is, how the Dithering/NoiseShaping of Wavegain influences/confuses the behaviour of lame (ATH?).

dev0
Title: Wavegain vs. MP3Gain
Post by: 2Bdecided on 23 June, 2003, 10:33:06 AM
Quote
1. Original -> lame -> MP3Gain

2. Original -> Wavegain (+ Dither/NS?) -> lame

3. Original - > (Wavegain to calc. scale) -> lame + scale

Another interesting point to consider is, how the Dithering/NoiseShaping of Wavegain influences/confuses the behaviour of lame (ATH?).

The thing is, 2 can never be better than 3 - as you suggest, there could be interesting consequences of using it, but because 3 must be better than 2, I'd rather forget 2 and explore 3.


3 may be more useful, because the only quality concerns are within Lame itself.


Cheers,
David.
Title: Wavegain vs. MP3Gain
Post by: john33 on 23 June, 2003, 11:59:30 AM
These are the results from using one track only. It may, or may not, be representative, but the results are fairly interesting. I make no comment, I am posting for others to comment. 
Code: [Select]
******** WaveGain, NO DITHER

D:\testdir>lame --preset standard 132.wav 132.mp3
LAME version 3.90.3 MMX  (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!, SIMD
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding 132.wav to 132.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
 8206/8208  (100%)|    0:35/    0:35|    0:35/    0:35|   6.0438x|    0:00
32 [ 151] ****
128 [ 790] %%***************
160 [2880] %%%%%********************************************************
192 [3157] %%%%%%%%%%%%%%%%%*************************************************
224 [ 803] %%%%%************
256 [ 247] %%****
320 [ 180] %***
average: 179.5 kbps   LR: 1384 (16.86%)   MS: 6824 (83.14%)

Writing LAME Tag...done

******** WaveGain, DITHER with NO NOISE SHAPING

D:\testdir>lame --preset standard 132.wav 132.mp3
LAME version 3.90.3 MMX  (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!, SIMD
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding 132.wav to 132.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
 8206/8208  (100%)|    0:36/    0:36|    0:36/    0:36|   5.9545x|    0:00
32 [ 150] %%%*
128 [ 801] %%***************
160 [2848] %%%%%******************************************************
192 [3201] %%%%%%%%%%%%%%%%%%************************************************
224 [ 782] %%%%%************
256 [ 240] %%***
320 [ 186] %%**
average: 179.5 kbps   LR: 1520 (18.52%)   MS: 6688 (81.48%)

Writing LAME Tag...done

******** WaveGain, DITHER with LIGHT NOISE SHAPING

D:\testdir>lame --preset standard 132.wav 132.mp3
LAME version 3.90.3 MMX  (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!, SIMD
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding 132.wav to 132.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
 8206/8208  (100%)|    0:36/    0:36|    0:36/    0:36|   5.9339x|    0:00
32 [  14] %
40 [   1] *
128 [ 916] %%%%****************
160 [2877] %%%%%*******************************************************
192 [3172] %%%%%%%%%%%%%%%%%%************************************************
224 [ 797] %%%%%************
256 [ 249] %%****
320 [ 182] %***
average: 181.2 kbps   LR: 1534 (18.69%)   MS: 6674 (81.31%)

Writing LAME Tag...done

******** WaveGain, DITHER with MEDIUM NOISE SHAPING

D:\testdir>lame --preset standard 132.wav 132.mp3
LAME version 3.90.3 MMX  (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!, SIMD
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding 132.wav to 132.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
 8206/8208  (100%)|    0:36/    0:36|    0:36/    0:36|   5.9831x|    0:00
32 [  10] %
128 [ 916] %%%%****************
160 [2895] %%%%%********************************************************
192 [3156] %%%%%%%%%%%%%%%%%*************************************************
224 [ 810] %%%%%************
256 [ 245] %%****
320 [ 176] %%**
average: 181.2 kbps   LR: 1485 (18.09%)   MS: 6723 (81.91%)

Writing LAME Tag...done

******** WaveGain, DITHER with HEAVY NOISE SHAPING

D:\testdir>lame --preset standard 132.wav 132.mp3
LAME version 3.90.3 MMX  (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!, SIMD
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding 132.wav to 132.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
 8206/8208  (100%)|    0:36/    0:36|    0:36/    0:36|   5.9390x|    0:00
40 [   1] *
128 [1115] %%%%%*******************
160 [3176] %%%%%%%%**********************************************************
192 [2890] %%%%%%%%%%%%%%%%*********************************************
224 [ 653] %%%%**********
256 [ 222] %%***
320 [ 151] %***
average: 177.5 kbps   LR: 1583 (19.29%)   MS: 6625 (80.71%)

Writing LAME Tag...done

******** ORIGINAL WAVE FILE + LAME --scale

D:\testdir>D:\testdir>lame --preset standard --scale 0.691 13.wav 13.mp3
LAME version 3.90.3 MMX  (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!, SIMD
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding 13.wav to 13.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
 8206/8208  (100%)|    0:36/    0:36|    0:36/    0:36|   6.0251x|    0:00
32 [ 152] %***
128 [ 810] %*****************
160 [2876] %%%%%********************************************************
192 [3130] %%%%%%%%%%%%%%%%%*************************************************
224 [ 815] %%%%%*************
256 [ 238] %%****
320 [ 187] %***
average: 179.5 kbps   LR: 1372 (16.72%)   MS: 6836 (83.28%)

Writing LAME Tag...done

******** ORIGINAL WAVE FILE + LAME AS REFERENCE

D:\testdir>lame --preset standard 13.wav 13.mp3
LAME version 3.90.3 MMX  (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!, SIMD
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding 13.wav to 13.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
 8206/8208  (100%)|    0:35/    0:35|    0:35/    0:35|   6.0544x|    0:00
32 [ 151] ****
128 [ 779] %****************
160 [2771] %%%%%*****************************************************
192 [3188] %%%%%%%%%%%%%%%%%*************************************************
224 [ 872] %%%%%**************
256 [ 251] %%****
320 [ 196] %%***
average: 180.6 kbps   LR: 1373 (16.73%)   MS: 6835 (83.27%)

Writing LAME Tag...done

D:\testdir>
Title: Wavegain vs. MP3Gain
Post by: dev0 on 23 June, 2003, 12:07:03 PM
Could you please decode the test files and verify if any of these are the same? If they are we could try grouping some options.

dev0
Title: Wavegain vs. MP3Gain
Post by: tigre on 23 June, 2003, 12:22:14 PM
Quote
Could you please decode the test files and verify if any of these are the same? If they are we could try grouping some options.

dev0

None of them are exactly the same as you'll see e.g. by comparing the numbers of 160 kbps frames for each file.
Title: Wavegain vs. MP3Gain
Post by: mrosscook on 23 June, 2003, 12:32:06 PM
In light of 2Bdecided's comments about the possible role of psymodels and ath in this effect, I thought it might be useful to see what happens if we compress both an original file and a wavegained version using ZIP (which of course has no psychoacoustics in it).

I used the track, "When I Paint My Masterpiece", from Rock of Ages, Disc 2, by Bob Dylan and the Band.  The original is a 44.38 MB wav file.  This was transformed into a gained file using wavegain with a -18.95 dB setting -- the -6.95 dB recommended by the program itself, plus another -12 dB for emphasis. Using ZIP at max compression,

Original compresses 44.38 MB to 42.27 MB (95%)
Gained compresses 44.38 MB to 35.63 MB (80%)

Certainly,  no psymodel has a role here.  I also thought it might be interesting to compress the original and gained files using a lossless audio codec (FLAC high) and two lossy codecs (LAME v.3.92 -aps, and MPC -q5); that gives the little table,

Code: [Select]
              ZIP          FLAC       LAME        MPC
Original   42.27(95%)   27.70(62%)  4.79(11%)  4.51(10%)
Gained     35.63(80%)   18.98(43%)  4.92(11%)  4.25(10%)


FLAC, like ZIP, gets a big boost in compression by aggressive wavegaining.  The lossy codecs don't.  LAME actually makes the gained file a little bit larger than the original, but I doubt that is a meaningful difference.

What is the moral of the story?  Maybe that wavegaining does produce loss (as suggested by ZIP and FLAC) but that the lossy-mode psychoacoustics are much larger effects and swamp out wavegain? Any comments would be welcome.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 23 June, 2003, 01:54:30 PM
Lets forget the actual wavegaining, as 2bdecided said. I would like to hear from Gabriel or maybe Dibrom regarding the issues he brought up with --scale and ATH.

Fellas?

In addition, what this eventually comes down to is an ABX test. I can post some highly compressed tracks done with both mp3gain and --scale if you'd like, but I think you may be more successful with tracks you know well. I for one cannot identify a difference, beyond the slight volume difference due to the 89.0dB accuracy of the --scale method.

Seriously though, forget the wavegain/dithering method - there is no point in pursuing that - it will just confuse matters.
Title: Wavegain vs. MP3Gain
Post by: M on 23 June, 2003, 09:53:09 PM
From a simple numeric comparison (considering the frame breakdown as well as the average bitrate) of john33's examples, it seems the following two are the closest to each other:

Code: [Select]
******** WaveGain, NO DITHER

D:\testdir>lame --preset standard 132.wav 132.mp3
LAME version 3.90.3 MMX  (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!, SIMD
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding 132.wav to 132.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
  Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
8206/8208  (100%)|    0:35/    0:35|    0:35/    0:35|   6.0438x|    0:00
32 [ 151] ****
128 [ 790] %%***************
160 [2880] %%%%%********************************************************
192 [3157] %%%%%%%%%%%%%%%%%*************************************************
224 [ 803] %%%%%************
256 [ 247] %%****
320 [ 180] %***
average: 179.5 kbps   LR: 1384 (16.86%)   MS: 6824 (83.14%)

Writing LAME Tag...done

******** ORIGINAL WAVE FILE + LAME --scale

D:\testdir>D:\testdir>lame --preset standard --scale 0.691 13.wav 13.mp3
LAME version 3.90.3 MMX  (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!, SIMD
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding 13.wav to 13.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
  Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
8206/8208  (100%)|    0:36/    0:36|    0:36/    0:36|   6.0251x|    0:00
32 [ 152] %***
128 [ 810] %*****************
160 [2876] %%%%%********************************************************
192 [3130] %%%%%%%%%%%%%%%%%*************************************************
224 [ 815] %%%%%*************
256 [ 238] %%****
320 [ 187] %***
average: 179.5 kbps   LR: 1372 (16.72%)   MS: 6836 (83.28%)

Writing LAME Tag...done


  Now, most of the time when I use WaveGain I don't use dither anyway (look, if it were really an essential step it should be the default, no?), but I know a lot of folks here do use it - all the time. However, from the bitrate counts it would appear --scale is not pre-dithering anything... so the question becomes, how essential is dither to producing decent-sounding MP3s? Or does it even affect the sound to a measurable degree, since the process of psychoacoustic modeling is later in the chain?

    - M.
Title: Wavegain vs. MP3Gain
Post by: 2Bdecided on 24 June, 2003, 06:52:24 AM
If Dibrom, JohnV, Gabriel etc etc are reading this thread, please see my previous (long!) post for the serious questions which I can't answer - this post is to clear up the simpler stuff (which I can help with!).


john33,

It's surprising how little difference it make to the bitrate. Maybe some of the noise shaping options cause more of the dither to pop up above the ath - I don't know. With a suitable sample, you could look in spectral view to see. TBH it's hard to know exactly what's happening in the different modes. From a theoretical stand-point, I know that the scale version is best, but what lame is actually doing is anyone's guess. I'm not about to volunteer to ABX the differences!


mrosscook,

Decreasing the amplitude by 18dB (without dither) is essentially dropping the lower 3 bits of the 16-bit signal that comes off a CD. So, there will only be 13 bits of real information in the resulting file.

To explain: -18dB = dividing by 8 (2*2*2). If you did this exactly, you would end up with the 3 most significant bits of the new file being 0, and the 3 least singificant bits of the old file being lost - the middle 13 bits are shift but remain intact. In practice, we're not dividng by 8 exactly, so it won't be this neat: but it gives an idea of the kind of data that's going into the lossless codecs, and hence why they achieve better compression ratios afte tha 18dB drop.

The lossy codecs just look at the sound. If the file is loudish throughout, you haven't actually lost any audible content by dropping the level by 18dB - everything is still way above the -96dB CD noise floor, and the compression ratios show this: there's still just as much "sound" to store before and after wave gaining.


M,

Maybe you're reading too much into it! The one with dither (no noise shaping) is very very close too. The ones with noise shaped dither are not as close, which is to be expected because they don't contain the same audio data: they contain extra high frequency noise, added intentionally.

Re: dither/not dither... In this -18dB example, you're losing 3 bits. There's an OTT example at the bottom of this page (http://mp3decoders.mp3-tech.org/24bit2.html) where 10 bits are removed. It shows why (generally) dither is a good thing, though in practice there are times where the signal can self dither, and extra dither doesn't help. It rarely hurts though.


Cheers,
David.
Title: Wavegain vs. MP3Gain
Post by: john33 on 24 June, 2003, 07:16:46 AM
Quote
From a theoretical stand-point, I know that the scale version is best, but what lame is actually doing is anyone's guess. I'm not about to volunteer to ABX the differences!

The benefit with using --scale is that the scaling is applied to the integer samples after they have been copied into a float buffer so the fractional parts of the results are preserved for the encoder.

This discussion has centred on this issue vis-a-vis LAME. It could, however, equally be applied to the ogg vorbis encoders and, probably, others. Certainly in oggenc/oggdropXPd, the scaling is applied to the input samples after they have been converted to floats but before being fed to the encoder.
Title: Wavegain vs. MP3Gain
Post by: 2Bdecided on 24 June, 2003, 09:58:10 AM
Thanks john. That much I'd assumed. It's how the level difference affects the psychoacoustics that interests me. If we use fewer bits then either

a) we were using too many to start with, or
B) the quieter version will actually sound worse.

If (a), then in theory we could change the lame psychoacoustics. What would be more valuable would be to use a replay gain calculation to help lame set the ath properly, and see what effect this has.

Cheers,
David.
Title: Wavegain vs. MP3Gain
Post by: ff123 on 24 June, 2003, 11:01:30 AM
Quote
Thanks john. That much I'd assumed. It's how the level difference affects the psychoacoustics that interests me. If we use fewer bits then either

a) we were using too many to start with, or
B) the quieter version will actually sound worse.

If (a), then in theory we could change the lame psychoacoustics. What would be more valuable would be to use a replay gain calculation to help lame set the ath properly, and see what effect this has.

Cheers,
David.

This issue has been lurking for a long time.  It's probably about time to figure out what might be done, now that replaygain is so well established.  However, it may take a few listening tests to decide if B) is noticeable using the appropriate music replaygained down to 89 dB.

I know that bAdDuDeX once complained about a loss of quality when using --scale to lower the volume before encoding.  His preferred genre was Metal.

ff123
Title: Wavegain vs. MP3Gain
Post by: Garf on 24 June, 2003, 11:13:12 AM
Vorbis should give identical results if scale is applied after float conversion. Would need to check if theory == practise though.
Title: Wavegain vs. MP3Gain
Post by: ErikS on 24 June, 2003, 12:15:35 PM
Quote
Vorbis should give identical results if scale is applied after float conversion. Would need to check if theory == practise though.

It does. At least in my very limited test. But with LAME the difference is huge. Would it be possible to use the same ATH adjustment code in LAME as in the vorbis encoder?
Title: Wavegain vs. MP3Gain
Post by: /\/ephaestous on 24 June, 2003, 02:20:08 PM
Vorbis test:
Code: [Select]
X:\Burn\TEST>dir
Volume in drive X is Temp
Volume Serial Number is 604A-42CF

Directory of X:\Burn\TEST

06/24/2003  12:59 PM    <DIR>          .
06/24/2003  12:59 PM    <DIR>          ..
06/24/2003  12:58 PM        84,907,236 wavegain.wav
06/24/2003  12:58 PM        84,907,236 original.wav
              2 File(s)    169,814,472 bytes
              2 Dir(s)   2,666,123,264 bytes free

X:\Burn\TEST>wavegain -y -g 3 -b 5 wavegain.wav

Analyzing...

   Gain   |  Peak  | Scale | New Peak | Track
---------------------------------------------
 -6.43 dB |  32766 |  0.48 |    15629 | wavegain.wav
Applying Gain to file: wavegain.wav
This file 100% done     All files 100% done
WaveGain Processing completed normally


X:\Burn\TEST>oggenc -q 6 wavegain.wav
Skipping chunk of type "fact", length 4
Skipping chunk of type "PEAK", length 24
Opening with wav module: WAV file reader
Encoding "wavegain.wav" to
        "test.ogg"
at quality 6.00
       [100.0%] [ 0m00s remaining] |

Done encoding file "wavegain.ogg"

       File length:  4m 00.0s
       Elapsed time: 0m 24.0s
       Rate:         10.0278
       Average bitrate: 180.9 kb/s


X:\Burn\TEST>oggenc -q 6 original.wav
Opening with wav module: WAV file reader
Encoding "original.wav" to
        "test2.ogg"
at quality 6.00
       [100.0%] [ 0m00s remaining] \

Done encoding file "original.ogg"

       File length:  4m 00.0s
       Elapsed time: 0m 25.0s
       Rate:         9.6267
       Average bitrate: 186.3 kb/s


X:\Burn\TEST>dir
Volume in drive X is Temp
Volume Serial Number is 604A-42CF

Directory of X:\Burn\TEST

06/24/2003  01:01 PM    <DIR>          .
06/24/2003  01:01 PM    <DIR>          ..
06/24/2003  01:01 PM         5,445,824 wavegain.ogg
06/24/2003  01:00 PM        84,907,280 wavegain.wav
06/24/2003  01:02 PM         5,607,989 original.ogg
06/24/2003  12:58 PM        84,907,236 original.wav
              4 File(s)    180,868,329 bytes
              2 Dir(s)   2,655,064,064 bytes free


This test was done with 32bit Floating Point wavs.

MPC test:

Code: [Select]
X:\Burn\TEST>dir
Volume in drive X is Temp
Volume Serial Number is 604A-42CF

Directory of X:\Burn\TEST

06/24/2003  01:09 PM    <DIR>          .
06/24/2003  01:09 PM    <DIR>          ..
06/24/2003  01:08 PM        84,907,236 original.wav
06/24/2003  01:08 PM        84,907,236 wavegain.wav
              2 File(s)    169,814,472 bytes
              2 Dir(s)   2,666,123,264 bytes free

X:\Burn\TEST>wavegain -y -g 3 -b 4 wavegain.wav

Analyzing...

   Gain   |  Peak  | Scale | New Peak | Track
---------------------------------------------
 -6.43 dB |  32766 |  0.48 |    15629 | wavegain.wav
Applying Gain to file: wavegain.wav
This file 100% done     All files 100% done
WaveGain Processing completed normally

X:\Burn\TEST>mppenc --xtreme --xlevel original.wav
MPC Encoder  1.14  -Beta-   (C) 1999-2002 Buschmann/Klemm/Piecha

encoding file 'original.wav'
      to file 'original.mpc'

SV 7.0 + XLevel coding, Profile 'Xtreme'

   %|avg.bitrate| speed|play time (proc/tot)| CPU time (proc/tot)| ETA
100.0  198.1 kbps 12.85x     4:00.6    4:00.6     0:18.7    0:18.7

WARNING:
 There still occured 1 SCF clippings due to a restriction of StreamVersion 7.
 Use the '--scale' method to avoid additional distortions. Note that this
 file already has annoying distortions due to slovenly CD mastering.


X:\Burn\TEST>mppenc --xtreme --xlevel wavegain.wav
MPC Encoder  1.14  -Beta-   (C) 1999-2002 Buschmann/Klemm/Piecha

encoding file 'wavegain.wav'
      to file 'wavegain.mpc'

SV 7.0 + XLevel coding, Profile 'Xtreme'

   %|avg.bitrate| speed|play time (proc/tot)| CPU time (proc/tot)| ETA
100.0  197.4 kbps 12.86x     4:00.6    4:00.6     0:18.7    0:18.7

X:\Burn\TEST>dir
Volume in drive X is Temp
Volume Serial Number is 604A-42CF

Directory of X:\Burn\TEST

06/24/2003  01:11 PM    <DIR>          .
06/24/2003  01:11 PM    <DIR>          ..
06/24/2003  01:11 PM         5,958,708 original.mpc
06/24/2003  01:08 PM        84,907,236 original.wav
06/24/2003  01:11 PM         5,938,340 wavegain.mpc
06/24/2003  01:10 PM        84,907,236 wavegain.wav
              4 File(s)    181,711,520 bytes
              2 Dir(s)   2,654,224,384 bytes free


The MPC test was performed using 32bit fixed point (longs) wavs.
Title: Wavegain vs. MP3Gain
Post by: Garf on 24 June, 2003, 02:30:49 PM
Does wavgain dither?

Edit: the SCF clipping makes me think of another explanation: the psymodel gives identical results but the entropy coders can do better with smaller values
Title: Wavegain vs. MP3Gain
Post by: Jebus on 24 June, 2003, 03:04:15 PM
I uploaded a bunch of samples for ABX testing on the other (cleaned-up) thread on the matter. Please post any futher information there.

Go Here (http://www.hydrogenaudio.org/forums/index.php?act=ST&f=16&t=10694&st=0&#entry108054)
Title: Wavegain vs. MP3Gain
Post by: sony666 on 24 June, 2003, 03:20:40 PM
My humble experiences with this topic: http://www.hydrogenaudio.org/forums/index....=ST&f=16&t=8046 (http://www.hydrogenaudio.org/forums/index.php?act=ST&f=16&t=8046)
The main "problem" seems to be the sfb21 (high freq) content and lame VBR.
As I understood it, if the track is very loud, this high freq. content goes above the ATH and causes the bitrate bloat (sometimes dramatically). Correct me if that's wrong please:)
You may try to use -Y switch in your tests, the difference between original and replaygained encoding should be far less then.
Title: Wavegain vs. MP3Gain
Post by: john33 on 24 June, 2003, 03:52:22 PM
Quote
Does wavgain dither?

Edit: the SCF clipping makes me think of another explanation: the psymodel gives identical results but the entropy coders can do better with smaller values

On the command lines used: no dither, manual gain of +3dB(Why????), output for vorbis as floats and for mpc as 32bit ints.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 24 June, 2003, 04:33:05 PM
Quote
My humble experiences with this topic: http://www.hydrogenaudio.org/forums/index....=ST&f=16&t=8046 (http://www.hydrogenaudio.org/forums/index.php?act=ST&f=16&t=8046)
The main "problem" seems to be the sfb21 (high freq) content and lame VBR.
As I understood it, if the track is very loud, this high freq. content goes above the ATH and causes the bitrate bloat (sometimes dramatically). Correct me if that's wrong please:)
You may try to use -Y switch in your tests, the difference between original and replaygained encoding should be far less then.

It appears Sony666 has identified the problem. It DOES appear to be sfb21 related with LAME, because here are the resulting bitrates for Ministry's "Impossible":

--alt-preset standard                                              --> 270kbps
--alt-preset standard --scale 0.2515                      --> 230kbps
--alt-preset standard -Y                                --> 181kbps
--alt-preset standard -Y --scale 0.2515        --> 180kbps

When the sfb21 band is removed, --scale makes no damn difference!!

This suggests to me that LAME is spending too much encoding high volume, high frequency sounds with modern overcompressed recordings. Using --scale seems to work around this problem, and -Y is of course a workaround. If Sony666 and I are correct, we have found a serious glitch in LAME that needs addressing!
Title: Wavegain vs. MP3Gain
Post by: ErikS on 24 June, 2003, 04:46:46 PM
Quote
My humble experiences with this topic: http://www.hydrogenaudio.org/forums/index....=ST&f=16&t=8046 (http://www.hydrogenaudio.org/forums/index.php?act=ST&f=16&t=8046)
The main "problem" seems to be the sfb21 (high freq) content and lame VBR.
As I understood it, if the track is very loud, this high freq. content goes above the ATH and causes the bitrate bloat (sometimes dramatically). Correct me if that's wrong please:)
You may try to use -Y switch in your tests, the difference between original and replaygained encoding should be far less then.

But how can the encoder know how much I turned my volume knob when I listen to the song (or if I replaygain them afterwards etc)? The only assumption it should be allowed to make about this is IMO that you don't want to ruin your ears when listening and thus that the peak (up until that point in the file to have a "causual" encoder) is below the threshold of pain. LAME seems to make other assumptions as well according to these tests. Garf, do you know how this works in the vorbis encoder?
Title: Wavegain vs. MP3Gain
Post by: AstralStorm on 24 June, 2003, 04:48:18 PM
Does the -Y --scale version sound worse than --scale only one? (I think it should)

The scale version with volume turned up should sound worse than original too IMHO.
(Some information cut out by ATH)

/EDIT\ Vorbis has problems even with quiet classical music, so... Yes. \EDIT/
Title: Wavegain vs. MP3Gain
Post by: ff123 on 24 June, 2003, 04:55:40 PM
I believe the issue was adjusting the ath curve based on the volume (i.e., how far from full-scale) the music is.  Perhaps the change in the ath happened mostly in the upper frequencies.  If so, that might explain why it appears to be related to sfb21.  In any case, I think this behavior was meant to be a *feature*, not a bug.

ff123
Title: Wavegain vs. MP3Gain
Post by: Jebus on 24 June, 2003, 05:40:52 PM
ff123 That's a 40kbps change in total, 39kbps of which appears to be sfb21 (judging from the -Y results). That is a lot of extra information just for what are essentially louder squeeks, don't you think? Why only 1kbps difference when sfb21 is eliminated?

I think you are right in that it is an ATH issue, but this sfb21 thing helps explain why other codecs don't deal with this issue quite as drastically as LAME does. Don't you think?
Title: Wavegain vs. MP3Gain
Post by: /\/ephaestous on 24 June, 2003, 08:56:35 PM
Quote
Quote
Does wavgain dither?

Edit: the SCF clipping makes me think of another explanation: the psymodel gives identical results but the entropy coders can do better with smaller values

On the command lines used: no dither, manual gain of +3dB(Why????), output for vorbis as floats and for mpc as 32bit ints.

oh.. I use 92dB because my SlimX output is weak.
I used no dither because I though it wasn't worth using with 32bit wavs.
Title: Wavegain vs. MP3Gain
Post by: ErikS on 25 June, 2003, 01:08:34 AM
Quote
I believe the issue was adjusting the ath curve based on the volume (i.e., how far from full-scale) the music is.   Perhaps the change in the ath happened mostly in the upper frequencies.  If so, that might explain why it appears to be related to sfb21.  In any case, I think this behavior was meant to be a *feature*, not a bug.

ff123

The problem as I see it is that volume is not necessarily linked with how far from full scale the digital waveform is. It may as we see depend on other things as well - for example replaygain and volume level on your amplifyer.
Title: Wavegain vs. MP3Gain
Post by: mmortal03 on 25 June, 2003, 05:27:06 AM
I guess we just need to roll out some ABX tests.  My question is, how much do you need to amplify the specifically --scale'd mp3 before you can tell a difference? (speaking of 89dB)  Will it solely depend on how loud or compressed the original was?
Title: Wavegain vs. MP3Gain
Post by: 2Bdecided on 25 June, 2003, 05:42:53 AM
Some answers (but not enough!)...


ErikS,

Replay gain assumes that you're listening quite loud, so that's not a great worry.



Jebus,

The bits aren't going into sfb21 (i.e. higher frequencies). They're going into making the whole frequency range more accurate, so that sfb21 (above 16kHz) can actually get some bits! sfb21 doesn't have a scale factor of its own (stupid mp3 format), so it gets something related to what the others get (I forget the details - it's been discussed to death).

So, the 39kbps don't go to higher frequencies - they go to all frequencies, as this is the only way to give 16kHz+ "sufficient" bits - probably only a few in this case. Otherwise, it gets starved.


ABX tests: well, if it's a 16kHz+ issue, that's me out! You'll need the people who can hear up there, and also can detect ringing up there, which might be an issue. This should be interesting - we might find that those bits are very much needed! (though not for me!)


Cheers,
David.
Title: Wavegain vs. MP3Gain
Post by: DickD on 25 June, 2003, 10:10:35 AM
Finally reached the end of this thread (to date), and glad to see that sfb21 has been found to be the culprit, as I'd been starting to suspect. I agree with 2Bdecided about how the sfb21 problem manifests itself. It's a common misperception that the extra bits are wasted as 16kHz+, when in fact they're wasted on <16 kHz content if certain things happen in the 16kHz+ content that requires the workaround to maintain quality.

This is my educated guess as to what's happening:

By chance, john33 picked a track where the sfb21 issue wasn't causing much bitrate bloat in normal APS (without the -Y), so it wasn't much higher in the version with no --scale applied.

Jebus picked an album where the sfb21 issue was causing bloat in APS at full volume, but wasn't at lower volume. As 2Bdecided said, there is no scalefactor for 16 kHz+ (sfb21) so the global scalefactor has to be used. If the scale required to get fine enough quantization in sfb21 doesn't match the existing global scalefactor, the workaround is to adjust the global scalefactor, which then causes more bits to be used to encode all the other spectral bands (sfb0 to sfb20).  This forces all other bands to be quantized more finely than the masking threshold requires, so wastes bits in encoding detail in the <16 kHz area that is inaudible. (Encoders like Musepack and Vorbis don't have this sfb21 issue, so there's less difference - perhaps a fraction due to the way the adaptive ATH works).

It so happens that the --scale version doesn't need such a big change in the global scalefactor, so it doesn't get forced to waste bits on masked (inaudible) detail in bands 0-20 just to get the quantization noise in sfb21 low enough to go below the masking threshold.

Probably an analysis with mp3x graphical frame analyzer could help to verify whether this is true or not.

So, providing the psychoacoustics are correct about the masking threshold for <16 kHz components of the signal, the lower bitrate file should sound just as transparent as the high bitrate file that has been mp3gained (or had RG in Foobar2000 or similar).

So, if I'm correct, then only for cases where sfb21 bitrate bloat is happening, one should obtain just as good transparency with the smaller file (much closer to Musepack --standard --xlevel bitrates and APS - Y bitrates) when compared to the original lossless file with replaygain applied (even if played back on a 24-bit system, where the noise floor doesn't rise under ReplayGain, because LAME isn't forced to encode inaudible details just to get around the lack of sfb21 scalefactor.

Mind you, can this be right? If so, it implies that one could obtain just as low a bitrate without affecting the original volume by using, for example,  --scale 0.5 to obtain -6.0 dB volume change in the encode step then applying a corrective mp3gain Constant Gain of +6.0 dB after encoding (or use anything else that edits the global gain, like mp3DirectCut) to restore the original volume.

If so, surely Lame APS would already use --scale accompanied with an opposite adjustment of the global gain value, like mp3gain, as a more efficient workaround for the sfb21 issue, and could apply it to individual frames of the MP3 where the bloat occurs.

The only exception is if it doesn't work for changes in 1.5 dB steps, but only happens to work for some values between the steps of the global gain, or that the times when it works can't be predicted by LAME (though LAME is well aware of when the bloat is occuring, because the -Y switch lets it ignore the +16 kHz content at those times instead of implementing the bloat-inducing workaround for the lack of sfb21 scalefactor).

In that case, perhaps some files would become MORE bloated when --scale is applied.

Hmm, I think we need a Lame VBR expert to help here.

Wouldn't it be awesome if full-bandwidth LAME APS could be 20-30 kbps smaller without sounding any less transparent or breaking the MP3 standard! I'm just suspecting there's something to stop it working like that, or it would have been done before.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 25 June, 2003, 02:12:39 PM
Okay, so in summary we need people with good ears to ABX my posted samples, and someone who knows or works on LAME to get in here and bloody sort this out!

I PMed Dibrom and Gabriel but they don't seem to be interested,  or at least I haven't had a response.
Title: Wavegain vs. MP3Gain
Post by: Gabriel on 28 June, 2003, 07:39:53 AM
My opinion is that if you intend to always play your tracks on a specific adjusted level, it would be wise to take this into consideration while encoding.

It seems to me that extraction->album analysis->encoding with proper scale value would be the best choice.

Disabling the ath adjustment would be a bad idea. The ath adjustement is taking care (a little) about a possible misadjustement of track level (that is when the sound engineer did not used a proper level for the track).
But to my mind, it is also taking care of the constant sensitivity adjustement of the middle ear. Disabling this would reduce the quality. (I used "to my mind" because some do not agree about this)

Using the auto ath adjustement to take into consideration a whole track level misadjutement is not very efficient. First, the ath adjustement is limited in amplitude, and second it is progressive and not instantaneous.

You can alter the ath base level with --athlower, but I would prefer to use --scale.
Title: Wavegain vs. MP3Gain
Post by: Garf on 28 June, 2003, 08:05:02 AM
If it is purely an sfb21 problem, why does Vorbis have a 6kbps and MPC a 0.5kbps difference in encoding bitrate respectively?
Title: Wavegain vs. MP3Gain
Post by: Garf on 28 June, 2003, 08:07:46 AM
Quote
But how can the encoder know how much I turned my volume knob when I listen to the song (or if I replaygain them afterwards etc)? The only assumption it should be allowed to make about this is IMO that you don't want to ruin your ears when listening and thus that the peak (up until that point in the file to have a "causual" encoder) is below the threshold of pain. LAME seems to make other assumptions as well according to these tests. Garf, do you know how this works in the vorbis encoder?

Vorbis assumes that the loudest sound is played back at a level no more than what will blow yours ears out, and then takes the most pessimistic assumptions about ATH and masking that are applicably given the above.
Title: Wavegain vs. MP3Gain
Post by: _Shorty on 28 June, 2003, 10:20:16 PM
Quote
It seems to me that extraction->album analysis->encoding with proper scale value would be the best choice.

if you're always going to be playing it back on 16-bit hardware (think portable or car deck, as opposed to something like foobar which would take care of the dithering for you) would you still make this choice?  Or would it be better to do something like replaygain the wavs through foobar and its dither and then encode those wavs?  If I'm not going to be using a >16bit decoder would it not be beneficial to adjust and dither the wavs rather than --scale them?
Title: Wavegain vs. MP3Gain
Post by: Jebus on 29 June, 2003, 02:55:40 AM
Thank you for your response Gabriel. I had already assumed this was the case, and have been reencoding my library with --scale anyhow  (Wanted to do the 3.90.3 upgrade anyhow, and this also saves space on my almost-full jukebox). Good to know that my thinking isn't flawed.

This seems like the sort of thing a lot of people would be interested in. Perhaps we could put this in a FAQ someplace? It certainly doesn't take any longer than using MP3Gain, and seems to have substantial benefits (for MP3, anyhow).
Title: Wavegain vs. MP3Gain
Post by: DickD on 01 July, 2003, 11:36:27 AM
Thanks for the clarification about how the adaptive ATH works, Gabriel.

For most people, we'll either use the volume control to tame excessively loud tracks, or we'll use some form of ReplayGain to do so automatically.

The adaptive ATH is being conservative, however, in assuming that ATH is actually higher and that the loudest parts of the music are the exception (e.g. the loud transients in dynamic music) so the ATH shouldn't be raised. That's a good reason that the current model of ATH should be retained, so we don't start hearing artifacts in highly dynamic music that uses sudden loudness for artistic effect (e.g. classical or older rock/pop) but briefly enough that we don't turn down the volume or our ears don't adjust to the volume (like they do in a loud club).

That's why we possibly should not change LAME's default ATH behaviour.

If we listen to music like overcompressed music so that it's persistently near to the pain threshold, then we should probably encode with LAME as it is. I don't think that's many of us.

However, if we let ReplayGain or our volume control adjust it so that the perceived volume is about normal, the fact it's overcompressed will just mean there aren't loud transients any more - it's all at the maximum already and we've turned down the volume knob, so there's nowhere louder to go - it's already dialled up to 11, as Spinal Tap would say.

So all of us except those who really turn it up to levels where their hearing is at risk, should probably use --scale if they want to save bits but remain transparent in their listening environment. Those who have highly dynamic music will find that it remains transparent because it will be recorded with more headroom (i.e. ReplayGain doesn't need to adjust it much with --scale) and the adaptive ATH will still work fine.

I'm not offering to do it, just sharing my thoughts, but...

I'd have thought that this functionality would be ideally automated in software like Lame with .APE and Cuesheet support (available on Rarewares). For album gain you need to have the whole album ripped before encoding to measure the RG.

This can deal with a whole album ripped using EAC's Create CD Image, for example.

Imagine this process:

1. Rip album in EAC to a single .APE (Monkey's Audio) with .CUE sheet or multiple .APEs with APEv2 tags (created by using wapet as the External Encoder)

2. Load .CUE into Foobar2000 and calculate Track & Album Gain and add the info to the Cuesheet metadata and/or APEv2 tag. Alternatively this scan could be included in the Lame with .APE/.CUE executable.

3. Run Lame with .APE/.CUE/ReplayGain --scale support with a switch that says "apply ReplayGain Album/Track gain using --scale".
This can do all that LAME/APE/CUE can do
- encoding as a single MP3 image with CUEsheet
- encoding to separate MP3s with gaps
- encoding to separate 'near-gapless' MP3s with or without adding the Xing/Lame VBR header frame that helps seeking/time/bitrate display but breaks gapless playback in most dumb decoders that treat it as a silent audio frame.
The non-zero RG value for the other RG mode could be written to the APEv2 tag (APEv2 tagging would be another worthwhile modification to this special Lame compile) or CUE along with similar Undo data as mp3gain uses currently (rounded appropriately if mp3gain requires it).

4. Either LAME/APE/CUE/RG could scan for track peak and album peak on the fly and write it to tags (quick) or you could rescan for ReplayGain in FB2K (slower).


This is achievable. It would be an alternative for people with lots of modern metal and other highly compressed music that encodes to >220 kbps most of the time and feel this bitrate is excessive (esp after reading the stickies, claiming 180-210) but don't want to use the -Y switch.

I can't say I'd be a frequent user though - I usually use Musepack --standard --xlevel and I don't have a portable.

It might also be possible to enable this potential "Lame with APE/CUE/RG support" as a one-stop commandline encoder for EAC's Create Image with CUE (compressed), and as a track-gain only one-stop encoder in the separate tracks mode.

EAC would then pass it a CUEsheet and an uncompressed WAV and the commandline options necessary.  In one pass of the program it could then do all the required steps: scan for RG, apply the appropriate --scale for each track in the required RG mode/preamp setting, split into separate tracks if required, gaplessly if required, apply tagging (ID3v1, ID3v2, APEv2 at user's choice), etc.

This wouldn't be a trivial bit of programming (e.g. it might have to search for a CUEsheet in the same folder as the source file to detect whether it was called from EAC's Image or Copy Selected Tracks mode - the latter supporting Track Gain only), but it would probably only achieve a worthwhile user base if it integrated neatly with EAC so it could be used as the default mp3 encoder as simply as Lame can (i.e. not going via wapet and mac.exe). I suspect EAC's ID3 tagging would have to be off.

A name such as lamegain.exe would differentiate it from lame.exe. It would be slower than lame thanks to the RG process, but probably no slower than running LAME then running mp3gain.

• This approach is probably safer (regarding ATH in highly dynamic music) than bypassing the existing automatic ATH method in Lame, but it seemingly reduces the sfb21 problem's bitrate impact from modern overloud music.

• EAC's commandline options would need to pass over all tagging information to lamegain - i.e. %g %a %t %n etc. Lamegain would use the cuesheet metadata if it found the cuesheet.

• Lamegain's options would need to include the naming scheme.  There's no way to specify alternative Various Artist naming, so 01 - Artist - Title.mp3 would have to be recommended in FAQs.

• Easy near-Gapless encoding would be a bonus. The -t option of lame/CUE (as used by Lame --nogap) is more gapless for most decoders but breaks seeking/timing by removing the Xing/lame VBR header frame. If lamegain gapless mode became popular it might encourage more decoders to skip the lame VBR header frame and become more gapless.

• APEv2 tagging would be a bonus too, for FB2K/mp3gain users. ID3v1 would suffice for legacy support (e.g. portables). The APEv2 tag is flexible enough to store the original RG volume levels and peaks and even the Lame version, commandline options and encoding parameters. The comment can then be kept short enough for the ID3v1.1 limit (28 chars), or an additional APEv2 tag can be used to indicate that some ID3v1.1 tags are truncated. (FB2K might in future use this knowledge to suppress display of duplicate Title Tags when the ID3v1.1 title differs by being truncated or abbreviated, for example).

One other possibility offered by the APEv2 tag would be a standard tag for the encoder to indicate the offset silence at start and end of the MP3 so it can be made sample-accurate, so that true gapless playback would be possible with MP3 if this tag is supported by the decoder without breaking anything.

That's a thought about what could be programmed to make a version of lame that's
• easier for MP3 users who already use mp3gain, fb2k or gapless MP3 encoding because it all happens during the ripping phase.
• rather less likely to suffer from VBR bitrate bloat from the sfb21 workaround.
• usable as people's standard MP3 encoder for all albums - not just for special situations like live/mix gapless albums.

It wouldn't necessarily need to support Monkey's Audio either, though it would be nice.

I'd imagine a few sub-presets for the most common types of operation would be useful, e.g. --rgscanonly --rgalbum and --rgtrack as well as --autocuesheet, --albumimage (which retains the cuesheet with one big MP3), --gapless, --id3v1apev2 (which would curtail id3v1 if necessary). The 'scan only' would save a second operation for FB2K users and could also store RG info in the CUEsheet, but it would only work when APEv2 tags are enabled.

Any thoughts on how worthwhile / difficult / implementable this could be?
Title: Wavegain vs. MP3Gain
Post by: mmortal03 on 02 July, 2003, 02:21:35 AM
I think it would be very worthwhile.
Title: Wavegain vs. MP3Gain
Post by: 2Bdecided on 02 July, 2003, 06:12:54 AM
DickD,

Life is very difficult if you have ideas, but can't program! I should know...


However, if you ask enough people nicely, something may happen. You can email people who you think could help, or start a new thread with your idea at the top and hope they read it.

Cheers,
David.
Title: Wavegain vs. MP3Gain
Post by: john33 on 02 July, 2003, 06:46:29 AM
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'.
Title: Wavegain vs. MP3Gain
Post by: RaWShadow on 02 July, 2003, 07:42:19 AM
After using WaveGain, monkeys audio compress the waves much better. I read it is not lossless, but can anyone hear a difference between wavegained files and non wavegained files? and What information is lost??
Title: Wavegain vs. MP3Gain
Post by: Jebus on 02 July, 2003, 02:58:17 PM
Quote
After using WaveGain, monkeys audio compress the waves much better. I read it is not lossless, but can anyone hear a difference between wavegained files and non wavegained files? and What information is lost??

we aren't talking about using wavegain to modify the files. We just mean running wavegain to give a --scale value so that LAME can alter the volume.

To answer your question though, I don't think anyone has ever actually heard the loss after applying wavegain, but it does loose information since it has to dither.
Title: Wavegain vs. MP3Gain
Post by: _Shorty on 02 July, 2003, 10:00:56 PM
rawshadow, well, a 16bit per sample file can only have 65536 values, -32767 up to 32768.  The data fluctuates above and below 0, 0 being silence, and anything above or below it being sound of some sort.  If you lower the volume of such a file, all the values get pushed closer to 0.  And anything that was already close enough to 0 to actually become 0 means you've lost data.  Like, if you had a (rather odd) file with values that simply stepped up from 0, to 1, 2, 3, 4, 5....32767, 32768, and then back down to 0 and then on through to -32767, and you lowered that file's volume by 50% you would then lose all the values from -16383 to 16384 as they would all be changed to 0.  So if you then turned that file's volume up 100% to bring it back to the original volume, you would actually still be missing all those values, rather, they'd still all be 0.  So you'd have a whole whack of 0's and then all of a sudden 0, 0, 0, 0, 0, 16385, 16386, 16387...  In other words, you lose all the quietest samples as you lower the volume.  The more you lower it, the more you lose.  Dithering while lowering can help you maintain as much of the original sound as possible, but it isn't magic.  You still lose data.  Whether it's noticable or not will be different in every case.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 02 July, 2003, 10:50:42 PM
Quote
In other words, you lose all the quietest samples as you lower the volume.  The more you lower it, the more you lose.  Dithering while lowering can help you maintain as much of the original sound as possible, but it isn't magic.  You still lose data.  Whether it's noticable or not will be different in every case.

There is more to it than that... when you gain down say, 4dB (37% quieter), this does not correspond exactly to a 16-bit integer. So the file has to have these values dithered to the closest integer. THIS is the lossiness they usually refer to. MP3Gain is not lossy in this sense because it changes an integer (global gain field) by exactly 1 each time, which coresponds to 1.5dB.

The point of this thread is that by just doing the analysis and then feeding the --scale value to LAME, you are skipping this extra dithering step (since LAME has to quantize further anyhow) and hence this con to using wavegain is eliminated.
Title: Wavegain vs. MP3Gain
Post by: Differenciam on 02 July, 2003, 11:08:41 PM
Damn, this is a good idea.. I'm surprised no one brought it up sooner. 

I'll have to test for myself.
Title: Wavegain vs. MP3Gain
Post by: mmortal03 on 03 July, 2003, 04:58:28 AM
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'.

I use FLAC and cuesheets.  It would be nice if that was an option as well.  Thanks
Title: Wavegain vs. MP3Gain
Post by: flloyd on 03 July, 2003, 11:04:56 AM
Quote
Damn, this is a good idea.. I'm surprised no one brought it up sooner. 

I'll have to test for myself.

Hey give credit where credit is due (http://www.hydrogenaudio.org/show.php/act/ST/f/1/t/2712). 
Title: Wavegain vs. MP3Gain
Post by: Jebus on 03 July, 2003, 12:13:01 PM
Quote
Quote
Damn, this is a good idea.. I'm surprised no one brought it up sooner. 

I'll have to test for myself.

Hey give credit where credit is due (http://www.hydrogenaudio.org/show.php/act/ST/f/1/t/2712). 

touche, that was a year ago...

I never read that thread though, honest!
Title: Wavegain vs. MP3Gain
Post by: DickD on 03 July, 2003, 01:11:53 PM
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'. ;)

@John33, it's really cool of you to pick up the baton of making these modifications so we can more easily try these things out (and for paying attention to my rather lengthy post). For those times when I want MP3, I nearly always want Album Gain (if not, I want Track Gain to fix a home-made normalised compilation), so I think this will replace the existing lame3.90.3modified+APE+CUE that's already my default MP3 encoder. Will it be based on modified, with --preset, --preset medium, low bitrate abr presets etc?

@2Bdecided: Thanks to you also, for the ReplayGain standard and the testing that led to the -Z change from 3.90.2 to 3.90.3 among other things. While I can program, I'm very rusty and always have been rather slow. I'm not familiar with, and don't have the latest compilers (my last serious C programming was on MS QuickC for 16-bit DOS!), and it would take a lot of familiarisation to get used to the compilers and, for example, the lame and wavegain source codes to do this sort of thing myself.

I really admire people like john33 and others (e.g. fb2k devs and plugin devs like zZzZzZz, Case, Garf and too many others to name individually) who are so capable of producing bug-free modified versions and new, high quality features, seemingly at the drop of a hat in their spare time. And of course, many of them are building on the painstaking work of others (e.g. all the Lame, Musepack and Vorbis devs) thanks to the open source ethos.

Perhaps, when I can make some time, and assemble all the necessary tools, I will try to make further modifications to allow encoding direct using EAC's Image+CUE function, and to try putting gapless playback metadata in APE tags and some of the other stuff I mentioned. That would at least be a familiarisation exercise.

Dick Darlington
Title: Wavegain vs. MP3Gain
Post by: john33 on 03 July, 2003, 01:23:28 PM
Quote
@John33, it's really cool of you to pick up the baton of making these modifications so we can more easily try these things out (and for paying attention to my rather lengthy post). For those times when I want MP3, I nearly always want Album Gain (if not, I want Track Gain to fix a home-made normalised compilation), so I think this will replace the existing lame3.90.3modified+APE+CUE that's already my default MP3 encoder. Will it be based on modified, with --preset, --preset medium, low bitrate abr presets etc?

Yes, it'll be based on the modified version. 
Quote
I really admire people like john33 and others (e.g. fb2k devs and plugin devs like zZzZzZz, Case, Garf and too many others to name individually) who are so capable of producing bug-free modified versions and new, high quality features, seemingly at the drop of a hat in their spare time. And of course, many of them are building on the painstaking work of others (e.g. all the Lame, Musepack and Vorbis devs) thanks to the open source ethos.

Thanks!!  But, as you say, the people I admire are the ones that create the codecs, etc., in the first place. I'm just fairly adept at tinkering!!!
Title: Wavegain vs. MP3Gain
Post by: DickD on 03 July, 2003, 02:17:38 PM
Quote
Yes, it'll be based on the modified version. ;)

Thanks! Just what feature-freaks like me are after!

Happy tinkering!
Title: Wavegain vs. MP3Gain
Post by: john33 on 07 July, 2003, 04:23:17 PM
@DickD: I haven't forgotten this!!! It's just taking a little longer than I anticipated.
Title: Wavegain vs. MP3Gain
Post by: saratoga on 14 July, 2003, 11:54:32 PM
Any word?  A search turned up this topic by accident and I'm facsinated.
Title: Wavegain vs. MP3Gain
Post by: john33 on 15 July, 2003, 10:46:55 AM
Sorry, I still intend doing this, but the weather in the UK over the last week, or so, has been so uncharacteristically hot and sticky that I have been unable to concentrate sufficiently to get this done right!!! Given that I am talking about the UK, it can't last too much longer, so it should be done soon!!
Title: Wavegain vs. MP3Gain
Post by: saratoga on 15 July, 2003, 06:07:02 PM
Thanks John.

Also, I wouldn't mind the UK too much right now.  Here in Tucson my outdoor thermometer hit 111F (44C) the other day!
Title: Wavegain vs. MP3Gain
Post by: john33 on 16 July, 2003, 07:42:54 AM
Quote
Thanks John.

Also, I wouldn't mind the UK too much right now.  Here in Tucson my outdoor thermometer hit 111F (44C) the other day!



But you probably have air-con in the house? However, you're right, that's a pretty unbelievable temperature!! The temperature in the room where my computers are at home was 90F/32C last evening - far too hot for me to concentrate on anything much!!
Title: Wavegain vs. MP3Gain
Post by: mmortal03 on 17 July, 2003, 04:57:46 AM
How can one compare our portable's volume output setting to the --scale value to allow the accurate volume setting to be chosen?
Title: Wavegain vs. MP3Gain
Post by: DickD on 17 July, 2003, 12:19:11 PM
Quote
How can one compare our portable's volume output setting to the --scale value to allow the accurate volume setting to be chosen?

You mean you don't normally target 89 dB because your portable's volume is a bit weedy, so you'd like to specify an RG preamp (e.g. +3.0 dB) or target output volume (e.g. +92 dB SPL) in John's forthcoming lame-with-gain?

If you're talking about calibrating your player to 89 dB SPL loudness (i.e. 89 dB above the threshold of your hearing), that's not really the point of ReplayGain. Just set it to a comfortable level, and you shouldn't need to touch the volume control too often unless your mood changes.

It would be possible to set up a home theatre system to either 83 dB or 89 dB using a calibrated SPL meter and pink noise, as mentioned somewhere on the ReplayGain website hosted here at HA. It's harder to do with headphones/earbuds, and quite possibly pointless if you wish to adjust volume for background noise, (e.g. on trains, planes and buses).

Audiophile recordings of real instruments are supposedly perceived as more realistic if the volume level is close to that of the real instrument, but even most classical CDs aren't calibrated to a specific playback gain (yet).
Title: Wavegain vs. MP3Gain
Post by: mmortal03 on 18 July, 2003, 04:07:02 AM
What I am getting at is the situation about losing details past a certain threshold on the music, regardless of the dB, I do understand what the WaveGain default is, but that doesn't mean it is the only level to be used.  Someone pointed out that if one was to later amplify the music they have encoded and --scale'd to a certain lower level, the details that were too quiet or below the cutoff that were removed in the process could possibly be noticed.  I guess from your point of view, that doesn't matter, i.e. the detail loss is not going to be very perceptible if at all, with the modest drop to 89 dB.  All I am asking is what is the point in amplifying this music where the details lost could be percieved?  I guess it would depend on how overly loud the original recording was.    For example, say the original recording was on average 98 or 99 dB.  Once we scale the volume down to 89 dB, there is a 9 or 10 dB cutoff using this method.  Now, if one then amplifies this music on his portable back to the volume it would have played at if it had not been --scale'd, there is most definately a loss in sound.  We know this, but we don't know how significant the loss is; we have not tested it thoroughly.  How can I be sure that the music is NOT amplified to or past this point though?  You said it would be difficult to measure on a portable.  What are some methods though?  Again, I would assume that it would all depend on the loudness of the original recording for determining the amount a -scale'd mp3 could be amplified to without perceived sound loss, but in practice, how can we find out acceptable amplification limit?  Is it too unbelievably high for anyone to care?
Title: Wavegain vs. MP3Gain
Post by: DickD on 18 July, 2003, 12:08:34 PM
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. (http://www.hydrogenaudio.org/forums/index.php?s=&act=ST&f=1&t=9612&hl=&#entry96366) 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 (http://replaygain.hydrogenaudio.org/equal_loudness.html), 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.

(https://hydrogenaud.io/imgcache.php?id=59c8c93974c3caa846b42c8680574a69" rel="cached" data-warn="External image, click to view at original size" data-url="http://replaygain.hydrogenaudio.org/pics/equal_loudness.gif)
Fletcher Munson Equal Loudness Contours (http://replaygain.hydrogenaudio.org/equal_loudness.html)

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
Title: Wavegain vs. MP3Gain
Post by: Jebus on 18 July, 2003, 12:12:59 PM
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.
Title: Wavegain vs. MP3Gain
Post by: DickD on 18 July, 2003, 01:28:21 PM
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.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 18 July, 2003, 01:45:24 PM
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.
Title: Wavegain vs. MP3Gain
Post by: _Shorty on 18 July, 2003, 02:34:27 PM
89dB isn't particularly loud, and pretty much any concert of any music type will be much louder than that.  120dB isn't uncommon.
Title: Wavegain vs. MP3Gain
Post by: Soren on 22 June, 2004, 11:14:10 AM
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
Title: Wavegain vs. MP3Gain
Post by: Jebus on 22 June, 2004, 12:21:56 PM
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!
Title: Wavegain vs. MP3Gain
Post by: Soren on 22 June, 2004, 01:11:08 PM
  looks my english need more training 

i tough the thread was saying the opposite, darn

Soren
Title: Wavegain vs. MP3Gain
Post by: Synthetic Soul on 03 September, 2004, 11:57:04 AM
Just came across this thread today.

Has a version of LAME been released with this included?

I went to Rarewares (http://www.rarewares.org/) 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.
Title: Wavegain vs. MP3Gain
Post by: k.eight.a on 17 October, 2004, 05:32:08 PM
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...
Title: Wavegain vs. MP3Gain
Post by: k.eight.a on 19 October, 2004, 09:39:44 AM
Anybody out there who can answer my questions and make it clearer for me?
Title: Wavegain vs. MP3Gain
Post by: john33 on 19 October, 2004, 10:56:57 AM
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!!
Title: Wavegain vs. MP3Gain
Post by: k.eight.a on 19 October, 2004, 11:32:33 AM
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...?
Title: Wavegain vs. MP3Gain
Post by: k.eight.a on 19 October, 2004, 12:49:06 PM
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).
Title: Wavegain vs. MP3Gain
Post by: n68 on 19 October, 2004, 03:17:42 PM
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".

Title: Wavegain vs. MP3Gain
Post by: Jebus on 20 October, 2004, 07:06:02 PM
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.
Title: Wavegain vs. MP3Gain
Post by: Synthetic Soul on 21 October, 2004, 04:22:30 AM
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] (http://index.php?act=findpost&pid=248964")
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? 
Title: Wavegain vs. MP3Gain
Post by: k.eight.a on 21 October, 2004, 10:09:00 AM
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] (http://index.php?act=findpost&pid=248964")
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.
Title: Wavegain vs. MP3Gain
Post by: Synthetic Soul on 21 October, 2004, 11:06:40 AM
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 
Title: Wavegain vs. MP3Gain
Post by: k.eight.a on 21 October, 2004, 11:21:29 AM
Quote
Quote
This version of LAME & WaveGain already exist
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=249091")
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 (http://www.rarewares.org/files/mp3/lameDll3.90.3_MOD.zip) / LAME 3.96.1 DLL Modified (http://www.rarewares.org/files/mp3/lameDll3.96.1_MOD.zip) and the latest WaveGain v.1.0.5 with Speek's Frontend (http://www.rarewares.org/files/others/wavegain.zip)

But I think it's not so difficult for you to find it yourself, is it?
Title: Wavegain vs. MP3Gain
Post by: Synthetic Soul on 21 October, 2004, 11:40:21 AM
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.
Title: Wavegain vs. MP3Gain
Post by: k.eight.a on 21 October, 2004, 11:46:25 AM
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...
Title: Wavegain vs. MP3Gain
Post by: Jebus on 21 October, 2004, 01:19:24 PM
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.
Title: Wavegain vs. MP3Gain
Post by: n68 on 22 October, 2004, 04:27:49 AM
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.??


Title: Wavegain vs. MP3Gain
Post by: k.eight.a on 23 October, 2004, 02:04:24 PM
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...
Title: Wavegain vs. MP3Gain
Post by: k.eight.a on 23 October, 2004, 02:22:21 PM
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 so that LAME spits out an error whenever it detects clipping.
[a href="index.php?act=findpost&pid=249128"][{POST_SNAPBACK}][/a]


I want to add "--scale" setting only if the resulting MP3's will introduce clipping!

I've read the LAME documentation and I've never found a switch "--noclip"...
In 3.96.1 rarewares compile I've found "--clipdetect"...
So how is it to make it clear to me?

Quote
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.
[a href="index.php?act=findpost&pid=249128"][{POST_SNAPBACK}][/a]


I can tell you that I hear the difference between the original MP3 and MP3Gain modified by -1,5db lowered volume,
so I want to keep it as loud as possible but without additional clipping introduced by MP3 encoding.
You know what I mean?
Title: Wavegain vs. MP3Gain
Post by: Jebus on 23 October, 2004, 02:49:28 PM
Well then, you have to use "--preset standard --clipdetect" or whatever without any scale applied, and see if it clips. Then if it does, try 0.9999 and see it that clips. Keep refining until you find the magic maximum value that doesn't. Annoying, huh? Just use 0.98; you won't notice the volume change.

EDIT: You're right - it's --clipdetect and not --noclip. My Bad


BTW, 1.5dB is way, WAY more of a gain adjustment than 0.98. I can't remember the calculation off-hand, but 1.5dB is closer to a gain value of like 0.70.
Title: Wavegain vs. MP3Gain
Post by: k.eight.a on 23 October, 2004, 04:21:04 PM
Quote
Well then, you have to use "--preset standard --clipdetect" or whatever without any scale applied, and see if it clips. Then if it does, try 0.9999 and see it that clips. Keep refining until you find the magic maximum value that doesn't. Annoying, huh? Just use 0.98; you won't notice the volume change.
[a href="index.php?act=findpost&pid=249536"][{POST_SNAPBACK}][/a]


Yes, definitely it's annoying!
But I think that there's a possibility to determine the right --scale # with using WaveGain & LAME,
when you know how these programs / format work...
But that's not my case :-(

BTW: What is the shortest step in scale # ?

Quote
BTW, 1.5dB is way, WAY more of a gain adjustment than 0.98. I can't remember the calculation off-hand, but 1.5dB is closer to a gain value of like 0.70.
[a href="index.php?act=findpost&pid=249536"][{POST_SNAPBACK}][/a]


So, that's the reason I want to go by --scale max noclip!

The sad thing is, that the more educated persons do not participate to this (resurrected) discussion to help me

I believe that there's already a possibility to go the way I want...

Edit:

Quote
You're right - it's --clipdetect and not --noclip. My Bad.[a href="index.php?act=findpost&pid=249536"][{POST_SNAPBACK}][/a]


I realized that this switch is not present in 3.93.1 compile and probably the older too. But I'm still using 3.90.3 will it work?
Title: Wavegain vs. MP3Gain
Post by: Jebus on 23 October, 2004, 05:38:48 PM
Quote
So, that's the reason I want to go by --scale max noclip!

The sad thing is, that the more educated persons do not participate to this (resurrected) discussion to help me

I believe that there's already a possibility to go the way I want...



I already answered your question, and I know perfectly well how to answer you correctly - no need for more "educated" people here. This is my thread!

LAME applies certain quantizations based on complex psychoacoustic analysis of the source .wav, so there is no way to predict whether a given sample will be raised (and thus clipped) or lowered in volume until AFTER the encode. If there were, the lame devs would simply include a flag to use the maximum non-clipping scalefactor. As it stands, you can only tell if it is going to clip after the fact. Anyhow this is the last answer i'm going to give on the subject - you are really concerning yourself with nothing as a simple --scale 0.98 or MP3Gain will solve your problem satisfactorily.
Title: Wavegain vs. MP3Gain
Post by: k.eight.a on 23 October, 2004, 06:02:21 PM
OK, thank you for your reply.

The last question:
When I encode MP3 through normal --aps setting and it shows clipping, is there a way how to determine the scale to encode it once more with no-clipping?
So this way it would be needed 2 times encoding but I would get what I want...?

I think, that in a real world there are cases in which scale 0.98 isn't sufficent for no-clipping MP3, is it right?

BTW: What is the shortest step in scale # ? 0.001 or 0.01 ?
Title: Wavegain vs. MP3Gain
Post by: Jebus on 23 October, 2004, 06:04:24 PM
nope. I'd say try 0.98, cause that will probably work, then 0.99 and if that works then 0.995 and so on

4 significant decimal places... 0.XXXX

Seriously though dude, try to ABX 0.98 from no scale at all... impossible. Sound pressure level has to almost double for a preceptible change in volume.
Title: Wavegain vs. MP3Gain
Post by: k.eight.a on 23 October, 2004, 06:29:33 PM
Once again, thanks a lot!

I'm curious can I use a command line:

--alt-preset standard --clipdetect --scale 0.98

Does it matter in which sequence are the switches in the command line?
Does the additonal switches break the --aps command line?

Another thing is that in the documentation of 3.90.3 compile there's no "--clipdetect" switch...
Title: Wavegain vs. MP3Gain
Post by: Jebus on 24 October, 2004, 02:53:12 AM
No it doesn't matter, and use 3.96.1 if you want that feature.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 21 May, 2005, 04:42:26 AM
Just an update that anyone wanting to use this method now has a much easier way to go about it; a fully automated process run from within EAC.

All you need is this Wack bundle (http://www.rarewares.org/files/mp3/Wack.zip) and EAC. Follow the simple install directions in the bundle and you're off and running. Cheers!
Title: Wavegain vs. MP3Gain
Post by: cyborg on 21 May, 2005, 01:05:33 PM
This might be a little bit off topic, but would it be a better idea to use wavegain to replaygain wave files before encoding them to Musepack or Vorbis? So far I have used Musepack v1.15v with these switches: --quality 6 (--xlevel)

And Vorbis (aotuv b3) with this switch: -q6

So far I have used fb2k's replaygain function and it has worked without problems.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 22 May, 2005, 03:58:58 AM
there doesn't seem to be as much benefit as far as bitrate savings using non-mp3 encoders because of the issues described in this thread. Also, as far as I know all MPC decoders also support replaygain metatags natively, so this sort of "hard-coded" gain adjustment isn't all that beneficial. For vorbis? Not sure.
Title: Wavegain vs. MP3Gain
Post by: kindofblue on 06 June, 2005, 06:03:23 AM
Quote
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.
[a href="index.php?act=findpost&pid=249113"][{POST_SNAPBACK}][/a]


Indeed, a diagram might be useful for hopeless n00bs like myself.

I understand one can automate the whole thing with the special Wack bundle on rarewares.  But is there a way to do the process without a Wack setup?

Appreciate any help.
kindofblue
Title: Wavegain vs. MP3Gain
Post by: Jebus on 06 June, 2005, 10:53:49 AM
It needs to be scripted somehow, unfortunately. If you don't want to use Wack (and/or are ONLY doing EAC -> wavegain -> lame) then try my LameGain script, it's really small and simple.

http://www.autobotcity.net/files/LameGain.zip (http://www.autobotcity.net/files/LameGain.zip)
Title: Wavegain vs. MP3Gain
Post by: kindofblue on 06 June, 2005, 11:47:25 PM
Quote
It needs to be scripted somehow, unfortunately. If you don't want to use Wack (and/or are ONLY doing EAC -> wavegain -> lame) then try my LameGain script, it's really small and simple.

http://www.autobotcity.net/files/LameGain.zip (http://www.autobotcity.net/files/LameGain.zip)
[a href="index.php?act=findpost&pid=304002"][{POST_SNAPBACK}][/a]


Great. Thanks, Jebus.  Will go and try it out.
Title: Wavegain vs. MP3Gain
Post by: Synthetic Soul on 07 June, 2005, 05:35:43 AM
After avidly following Jebus' quest, I have now written something similar into my batch files.

As Jebus says, there has to be some intermediary application or script to get the value from WaveGain into LAME (my batch file being that script).

I've had a look at LameGain.vbs and it's very nicely done.  Kudos to Jebus for initiating  this thread, and doggedly pursuing it until the bitter end!

I  use ACDIR (http://nyaochi.sakura.ne.jp/xoops/modules/mydownloads/singlefile.php?cid=1&lid=2) instead of WaveSplit simply as it can pipe from the image WAVE to LAME instead of having to write track files to the hard drive first, and it can read meta data from the cuesheet, like TITLE and PERFORMER commands, which I can pass to LAME for tagging.  NB: Jebus uses ID3.EXE to tag as it has more functionality.

My batch files(s) archive to a Monkey's Audio image with cuesheet and optionally (if the CRC checksum checkbox is checked) create scaled track MP3s at the same time - very similar to the WACK bundle which Jebus was kind enough to put together.

There is an explanation of my batch files on my website (see below) - but not yet with the new functionality.  I hope to update the site to my new files in the near future.
Title: Wavegain vs. MP3Gain
Post by: wdk40 on 15 July, 2005, 01:21:54 PM
i've read this post many times and i'm still a little confused ...
my understanding is after using EAC to get the WAV files, run WaveGain to perform analysis on the whole album (cd).  then use the value generated by WaveGain as input to lame (via the --scale switch).  so far so good, right?

sorry for my ignorance (but how else will i learn w/o asking) why not let WaveGain modify the WAV files directly?

on a related note, what if i am creating a compliation of songs from various cds.  would i run wavegain on the entire collection, as if it were a CD, or individually?
thanks,
wdk40
Title: Wavegain vs. MP3Gain
Post by: Jebus on 15 July, 2005, 01:27:51 PM
Quote
i've read this post many times and i'm still a little confused ...
my understanding is after using EAC to get the WAV files, run WaveGain to perform analysis on the whole album (cd).  then use the value generated by WaveGain as input to lame (via the --scale switch).  so far so good, right?

sorry for my ignorance (but how else will i learn w/o asking) why not let WaveGain modify the WAV files directly?[a href="index.php?act=findpost&pid=313647"][{POST_SNAPBACK}][/a]


That was my original question. The answer is: because that introduces an additional lossy step. Lame has to requantify anyhow, so why not do it all at once? But you certainly could do it that way as well.

And yes, you've got all that right.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 15 July, 2005, 01:29:35 PM
Quote
what if i am creating a compliation of songs from various cds.  would i run wavegain on the entire collection, as if it were a CD, or individually?
thanks,
wdk40
[a href="index.php?act=findpost&pid=313647"][{POST_SNAPBACK}][/a]


Well, ideally you'd wavegain each source album and use those values... Or you could use track gain instead of album gain, but then tracks that are supposed to be quieter won't be.
Title: Wavegain vs. MP3Gain
Post by: wdk40 on 02 August, 2005, 10:09:59 PM
Quote
Quote
what if i am creating a compliation of songs from various cds.  would i run wavegain on the entire collection, as if it were a CD, or individually?
thanks,
wdk40
[a href="index.php?act=findpost&pid=313647"][{POST_SNAPBACK}][/a]


Well, ideally you'd wavegain each source album and use those values... Or you could use track gain instead of album gain, but then tracks that are supposed to be quieter won't be.
[a href="index.php?act=findpost&pid=313649"][{POST_SNAPBACK}][/a]



ok...i'm still trying to understand this.
If I rip a CD and use WaveGain (on the album as a whole) and then encode to MP3, all the MP3 files will be adjusted relative to the album.  So let's say I do this for a few CDs.  At some later time suppose I want to take a few MP3s from each of the ripped CDs and create a compilation.  Since the MP3 were all adjusted relative to their respective source CDs, shouldn't I re-adjust them relatative to the 'new' compilation?  If so, how do I do that?

Or would it be more flexible (but more expensive in terms of filesize) if I apply the gain adjustment after the MP3s are created?

thanks for all your help!
Title: Wavegain vs. MP3Gain
Post by: Jebus on 03 August, 2005, 12:48:29 AM
Well, not really... try track gaining something from ministry and then, say, tori amos, and I guarantee the tori amos is gonna sound way too loud in comparison. That's cause it is SUPPOSED to be quieter music! The replaygain algorithm doesn't know that!

So...

Lets say you're taking a softer track from one album and putting it on a mix CD with a bunch of heavy stuff. Using track gain would make the tracks the same perceived loudness, but is that what you want? Most likely you want the heavy stuff to be heavy, and the soft track to be soft, like they were on their respective source albums, right?

By using album gain, you are adjusting all tracks on a CD by the AVERAGE track gain, essentially. This means that the heavier tracks will remain a bit louder, and the softer tracks a bit softer. The dynamic range of the source CD doesn't change. The ONLY thing that changes is that your CDs are on average the same volume regardless of when they were recorded. So making a mix CD at this point will sound good, with more-or-less proper dynamics being preserved.

And if you don't like the way it sounds, you are always free to apply mp3gain in track mode, even after doing the whole wavegain thing. And mp3gain changes can be reversed afterwards of course, so no harm done.

I'd like to mention that this still isn't quite perfect - making a mix CD of say one track from a completely mellow CD and one from a completely heavy CD will of course result in the mellow track sounding too loud. Sometimes I pull out mp3gain and do a bit of tweaking by ear when the mix disc needs to be perfect.

Hope this makes some sense. Play with it! You'll figure it out.
Title: Wavegain vs. MP3Gain
Post by: wdk40 on 04 August, 2005, 11:20:43 AM
Jebus - once again, thanks for your help.

I've been using your LameGain script and have a question.  Why do rip the CD to an image file/CUE sheet rather than ripping individual tracks?  Just curious ...
Title: Wavegain vs. MP3Gain
Post by: Jebus on 04 August, 2005, 12:26:40 PM
Its a hack... because i need it to run wavegain only after ripping the entire CD. This way it only runs LameGain once at the end.

The side-effect (benefit) is that you don't really need to run LameGain from EAC at all, but can use it from a command-line. So you could for instance store the cue sheets and FLAC the wav images, then make MP3s automatically out of them later.

The downside is that after ripping it needs to split it into separate tracks, which takes a bit of time.

By the way, please upgrade to the latest version of LameGain (2.2), which should be the last one for a while... fixes all known bugs.
Title: Wavegain vs. MP3Gain
Post by: dli on 04 August, 2005, 12:47:30 PM
Jebus,

I see in your script that you are running wavegain -a -x on the directory of individual split WAV tracks. Now, based on my understanding of the matter running the analysis on the WAV image instead should yield the exact same scale factor. However, a quick test I ran does show discrepancies (0.5623 for individual tracks vs. 0.5630 for the full image). Any explanation?
Title: Wavegain vs. MP3Gain
Post by: Otto42 on 04 August, 2005, 01:32:20 PM
Running wavgain on the full image would include those 2 second silences in between the tracks, which would increase the necessary gain slightly (I'd think). The split tracks shouldn't have those silences in them.
Title: Wavegain vs. MP3Gain
Post by: wdk40 on 13 August, 2005, 01:59:49 PM
Quote
The side-effect (benefit) is that you don't really need to run LameGain from EAC at all, but can use it from a command-line. So you could for instance store the cue sheets and FLAC the wav images, then make MP3s automatically out of them later.
[a href="index.php?act=findpost&pid=317872"][{POST_SNAPBACK}][/a]



I tried to run LameGain from the command line but recieved an error when it attempts to parse the wav into separate tracks.  The error popup from LameGain says: Error splitting source WAVE into separate tracks.

It works fine from within EAC though ....

any suggestions?
Title: Wavegain vs. MP3Gain
Post by: wdk40 on 13 August, 2005, 02:02:48 PM
Quote
Quote

The side-effect (benefit) is that you don't really need to run LameGain from EAC at all, but can use it from a command-line. So you could for instance store the cue sheets and FLAC the wav images, then make MP3s automatically out of them later.
[a href="index.php?act=findpost&pid=317872"][{POST_SNAPBACK}][/a]



I tried to run LameGain from the command line but recieved an error when it attempts to parse the wav into separate tracks.  The error popup from LameGain says: Error splitting source WAVE into separate tracks.

It works fine from within EAC though ....

any suggestions?
[a href="index.php?act=findpost&pid=319878"][{POST_SNAPBACK}][/a]



oh yeah, from the LameGain output:
E:\Documents and Settings\auser\My Documents\My Music\WAV>C:\WINDOWS\system32\cs
cript.exe "C:\Program Files\LameGain\LameGain.vbs" "E:\Documents and Settings\au
ser\My Documents\My Music\WAV\CDImage.wav"
Microsoft ® Windows Script Host Version 5.6
Copyright © Microsoft Corporation 1996-2001. All rights reserved.

LameGain version 2.0, 24/06/05
Copyright © 2005 - Jeremy Herbison

Reading metadata from CUE sheet... done
Splitting source WAVE file into separate tracks...
E:\Documents and Settings\auser\My Documents\My Music\WAV>
Title: Wavegain vs. MP3Gain
Post by: Jebus on 13 August, 2005, 03:38:52 PM
Is the wav file named CDImage.wav and the cue sheet named CDImage.cue? Cause if their names don't match it won't find the cuesheet.

edit: also upgrade the latest version, fixed a few bugs.
Title: Wavegain vs. MP3Gain
Post by: wdk40 on 13 August, 2005, 06:59:16 PM
Quote
Is the wav file named CDImage.wav and the cue sheet named CDImage.cue? Cause if their names don't match it won't find the cuesheet.

edit: also upgrade the latest version, fixed a few bugs.
[a href="index.php?act=findpost&pid=319896"][{POST_SNAPBACK}][/a]


it seems to find the cuesheet just fine.  it just craps out during the track splitting.  i can run this from a DOS command window, right?
and where can i find version 2.2?  i can only seem to find 2.0 ....
thanks,
Title: Wavegain vs. MP3Gain
Post by: ezra2323 on 15 August, 2005, 12:57:05 PM
I finally made it to the end of this 2 year long, very interesting, discussion.

I have a couple more questions.

1) Most of the discussion focus around a LAME solution, and why not, as that is probably by far the most popular encoder used here. But what about other encoders such as iTunes AAC encoder, or the Fraunhofer MP3 encoder (2 that I use as well as LAME). Is there anyway to apply the LAMEgain process to these encoders or is it recomended to 1st apply WAVgain and then compress the WAV when using these encoders?

2) A lot of discussion on the theoretical loss of applying WAVgain to a file and then encoding. Has anyone actually noticed a quality loss of a WAVgained file with their own ears?

3) Assuming one WAVgains their CD collection and then encodes, but also has other compressed files (purchased or downloaded) in their library where there is no access to the original WAV file, is there a way to level the volume between tracks when listening on an iPod? If I recall, Apple's soundcheck in iTunes cannot reconcile the large difference between a WAVgained and compressed file and a non-WAV gained and compressed file. I do not want to turn up the volume to listen to a song I compressed only to have my ears shattered by the following song that did not undergo the same process.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 15 August, 2005, 01:52:53 PM
Main download location (http://www.autobotcity.net/files/LameGain.zip) is version 2.2. I just checked. Is someone mirroring me?

Yes, from the command-line in the LameGain folder, just type "cscript LameGain.vbs <path_to_wav>"

It probably ISN'T finding the cuesheet. It has to be in the same directory as the wav file and have the same name but with a .cue extension.
Title: Wavegain vs. MP3Gain
Post by: Jebus on 15 August, 2005, 01:56:51 PM
Quote
I finally made it to the end of this 2 year long, very interesting, discussion.

I have a couple more questions.

1) Most of the discussion focus around a LAME solution, and why not, as that is probably by far the most popular encoder used here. But what about other encoders such as iTunes AAC encoder, or the Fraunhofer MP3 encoder (2 that I use as well as LAME). Is there anyway to apply the LAMEgain process to these encoders or is it recomended to 1st apply WAVgain and then compress the WAV when using these encoders?

2) A lot of discussion on the theoretical loss of applying WAVgain to a file and then encoding. Has anyone actually noticed a quality loss of a WAVgained file with their own ears?

3) Assuming one WAVgains their CD collection and then encodes, but also has other compressed files (purchased or downloaded) in their library where there is no access to the original WAV file, is there a way to level the volume between tracks when listening on an iPod? If I recall, Apple's soundcheck in iTunes cannot reconcile the large difference between a WAVgained and compressed file and a non-WAV gained and compressed file. I do not want to turn up the volume to listen to a song I compressed only to have my ears shattered by the following song that did not undergo the same process.
[a href="index.php?act=findpost&pid=320277"][{POST_SNAPBACK}][/a]


1) Other encoders deal with the high-frequency issues better so its not as big a deal, but yeah, if the encoder doesn't support a --scale switch then simply use wavegain (medium noise shaping, no dither) to adjust instead of just an analysis.

2) No one has heard anything that I know of.

3) I'd just run MP3Gain on those other files after the fact to make them match, roughly.
Title: Wavegain vs. MP3Gain
Post by: wdk40 on 15 August, 2005, 10:13:44 PM
Quote
It probably ISN'T finding the cuesheet. It has to be in the same directory as the wav file and have the same name but with a .cue extension.
[a href="index.php?act=findpost&pid=320293"][{POST_SNAPBACK}][/a]


It finds the cue sheet (if it didn't your code spits out an error msg).

Using EAC, I created a wav image and cue sheet (but didn't execute LameGain).  I then attempted to run LameGain from the command line.

I added some print statements to your program and it seems as if the following line is where the error dialog is generated:
Code: [Select]
Set wavsplit = shell.Exec("""" & baseDir & "\wavsplit\wavsplit.exe"" --c """ & cuesheet & """ --s """ & source & """ --d """ & tempDir & """")


The error dialog says wavsplit.exe has encountered a problem and needs to close.  We are sorry for the inconvenience.  This is one of those standard dialogs that ask if you want to send an error report to microsoft.  Whe I click on 'Don't Send' i then get the LameGain dialog.

I tried to run the wavsplit command from the Windows Command Prompt window and it fails there also.  Same dialog box as above (... encountered a problem .. sorry ..).

Very strange.  There must be something wrong/different environmentaly.

When I run LameGain directly from EAC (i used the same disk that i previously used in the above test), it works fine! 

Any suggestions?

EDIT -
I added a print statement to print out the actual values of the wavsplit command line and ran the process through EAC again.  I noticed that the WAV source file is named ...\My Music\WAV\Ctmp7!1!5.wav.  While LameGain was running, I checked the above directory and did not see this file, but did see a CDImage.wav (and assoicated cue file).  Not sure that means anything ....
Title: Wavegain vs. MP3Gain
Post by: Jebus on 15 August, 2005, 11:37:17 PM
I sent you a private message with upload instructions.
Title: Wavegain vs. MP3Gain
Post by: wdk40 on 16 August, 2005, 08:53:24 PM
Quote
I sent you a private message with upload instructions.
[a href="index.php?act=findpost&pid=320391"][{POST_SNAPBACK}][/a]


i think i figured it out ....

as i mentioned in my post, i noticed that the filename for the wav file was something like Ctmp7!1!5.wav yet i couldn't find that file anywhere.  i added some more print statements to your code and it looks like this is what happens ...

i followed your instructions and from EAC i select Action->Copy Image & Create Cue Sheet-> compressed.  I accept the default (CDImage.wav) when prompted for a filename.  EAC then reads the CD and creates the wav file only the name is a temporary name, something like Ctmp7!1!5.wav.  This file appears to be an uncompressed version as it gets pretty big.  It is this file that is handed off to LameGain for processing.

When I tried to test LameGain from the command line I created a compressed wav file (Action->Copy Image & Create Cue Sheet-> compressed) and was using that one.  It looks like wavsplit didn't like the fact that the file was compressed (or i just don't know how to tell it the file is compressed - i couldn't find any options to do this).

i validated this by pausing your script at the begining, copying the temporary file that eac created and later using this file while running lamegain from the command line.  it worked.

my plan for doing all this (maybe i should have stated this in the begining?) is to rip a bunch of cds and then run lamegain from the command line to process them overnight.

thanks for your help ... if you still want the files i can get them to you  but you can just as easily test this yourself w/o my files.

again, thanks for your help ......
Title: Wavegain vs. MP3Gain
Post by: Jebus on 17 August, 2005, 12:08:58 PM
Well yeah, LameGain needs to be handed an uncompressed wav image  I'm not sure what you were handing it.
Title: Wavegain vs. MP3Gain
Post by: dli on 17 August, 2005, 12:14:11 PM
I've seen wavsplit crash when the FILE reference in the cue sheet did not match up with the WAV file name.
Title: Wavegain vs. MP3Gain
Post by: Otto42 on 17 August, 2005, 02:11:17 PM
Quote
2) A lot of discussion on the theoretical loss of applying WAVgain to a file and then encoding. Has anyone actually noticed a quality loss of a WAVgained file with their own ears?

That theoretical loss is well below anything a human being could reasonably hear. The only reason it's really a consideration is:
a) Perfectionism, and
b) Like a lot of losses, it's additive. Repeated use of these sort of processes adds up, and eventually leads to something you can hear. Therefore, it's a good idea to avoid them whenever possible. Audio people frequently call these sort of things "raising the noise floor", which is a pretty good description from one perspective.

Quote
3) Assuming one WAVgains their CD collection and then encodes, but also has other compressed files (purchased or downloaded) in their library where there is no access to the original WAV file, is there a way to level the volume between tracks when listening on an iPod? If I recall, Apple's soundcheck in iTunes cannot reconcile the large difference between a WAVgained and compressed file and a non-WAV gained and compressed file. I do not want to turn up the volume to listen to a song I compressed only to have my ears shattered by the following song that did not undergo the same process.
[a href="index.php?act=findpost&pid=320277"][{POST_SNAPBACK}][/a]

I don't know why this would be an issue. iTunes SoundCheck does indeed work for this sort of thing. It actually is the same basic process as ReplayGain, except that iTunes' method of determining the volume level of the track is not as robust as ReplayGain's method. But it can make quite large changes to volume levels, if necessary.
Title: Wavegain vs. MP3Gain
Post by: psycho on 14 October, 2005, 08:16:20 AM
Hiya ppl!

I'm new to this forum. I like the stuff you discuss here very much! 
I have read through the most of this thread and I have a question.
It's not about ReplayGaining before encodin, it's about ReplayGaining when I want to make audio CD from my mp3s.
I can't come to the conclusion myself... Is it better to do a MP3Gain before decoding to wav and burning audio CD or is it better to decode mp3 to wav and then do wavgain and burn audio CD?

I'm looking forward to the debate this question will hopefully lead to. 

Goran.
Title: Wavegain vs. MP3Gain
Post by: john33 on 14 October, 2005, 10:20:42 AM
Quote
Hiya ppl!

I'm new to this forum. I like the stuff you discuss here very much! 
I have read through the most of this thread and I have a question.
It's not about ReplayGaining before encodin, it's about ReplayGaining when I want to make audio CD from my mp3s.
I can't come to the conclusion myself... Is it better to do a MP3Gain before decoding to wav and burning audio CD or is it better to decode mp3 to wav and then do wavgain and burn audio CD?

I'm looking forward to the debate this question will hopefully lead to. 

Goran.
[a href="index.php?act=findpost&pid=334321"][{POST_SNAPBACK}][/a]

If the mp3 files have not been replay/mp3gained, then I would mp3 gain before decoding to avoid clipped samples on decode.
Title: Wavegain vs. MP3Gain
Post by: psycho on 14 October, 2005, 11:57:02 AM
Quote
If the mp3 files have not been replay/mp3gained, then I would mp3 gain before decoding to avoid clipped samples on decode.
[a href="index.php?act=findpost&pid=334347"][{POST_SNAPBACK}][/a]


Thank you for the answer. It makes sense... 
And I usually do audio CD from mp3s *only* when I don't have the original or a losslessly encoded source, as is the case, when I download something. And those mp3s aren't in any way replay/mp3gained before, IMO. So, thanks again!

Goran.
Title: Wavegain vs. MP3Gain
Post by: Spam Fodder on 06 December, 2005, 06:06:52 PM
OK, so i tried this going EAC>WaveGain>128 AAC & got no change in file size, maybe even a little _larger_ file.
i did the same files to APS MP3 & saw the smaller files.

File,  dB,    APS LAME,    WaveGain,    128 AAC,    WaveGain
1,  -8.2,  5.6-MB,  5.4-MB,  4.2-MB,  4.2-MB
2,  -7.8,  5.9-MB,  5.8-MB,  4.0-MB,  4.0-MB
3,  -8.0,  9.3-MB,  8.9-MB,  6.2-MB,  6.3-MB

insights anyone?
Title: Wavegain vs. MP3Gain
Post by: Spam Fodder on 08 December, 2005, 10:33:03 AM
last night i ripped 'Tyrannosaurus Hives', -10.9-dB, 12 tracks, in both 128 & 192 AAC, both w/ & w/o the Wave Gain adjustment, Apple AAC.
192 w/o, 41.2-MB total
192 w/ , 41.9-MB
128 w/o, 27.7-MB
128 w/, 28.1-MB

i also used LAME 3.98 APS to verify my two '.wav' directories were OK and saw the ~10% difference in file sizes.
Title: Wavegain vs. MP3Gain
Post by: Shade[ST] on 08 December, 2005, 10:50:46 AM
Quote
Thank you for the answer. It makes sense... 
And I usually do audio CD from mp3s *only* when I don't have the original or a losslessly encoded source, as is the case, when I download something. And those mp3s aren't in any way replay/mp3gained before, IMO. So, thanks again!

Goran.
[a href="index.php?act=findpost&pid=334365"][{POST_SNAPBACK}][/a]

A bit late, but an even better alternative would be to convert to wav (or burn) with foobar, and replaygain enabled, giving you even more precise volume.
Title: Wavegain vs. MP3Gain
Post by: clintb on 08 December, 2005, 11:05:46 PM
Quote
OK, so i tried this going EAC>WaveGain>128 AAC & got no change in file size, maybe even a little _larger_ file.
i did the same files to APS MP3 & saw the smaller files.

File,   dB,     APS LAME,     WaveGain,    128 AAC,    WaveGain
1,  -8.2,  5.6-MB,  5.4-MB,  4.2-MB,  4.2-MB
2,  -7.8,  5.9-MB,  5.8-MB,  4.0-MB,  4.0-MB
3,  -8.0,  9.3-MB,  8.9-MB,  6.2-MB,  6.3-MB

insights anyone?
[a href="index.php?act=findpost&pid=348174"][{POST_SNAPBACK}][/a]

I'm assuming you haven't read through the whole thread?  It was discussed earlier, that other formats/codecs don't suffer from this problem like mp3 does.

Solution for after-the-fact encodes.
1. Load in Foobar
2. Select all
3. Replaygain> Scan selection as multiple albums (if you've selected multiple, distinctly different albums)
4. Enable Replaygain in the Diskwriter component and convert away to whatever format your heart desires.

BTW, I'm referring to a lossless>lossy conversion.
Title: Wavegain vs. MP3Gain
Post by: 2Bdecided on 14 February, 2007, 08:32:44 AM
Is there a collection which includes (or allows you to put together) the latest lame version, the wavegain version with -fast option enabled, and which works from within EAC?

I've tried Wack, but it's crashing for me. If I can solve the crashing,  can I get it to run wavegain in -fast mode?

(I know I should know this, and probably made it all run properly on a PC ~two years ago, but now...!)

Cheers,
David.
Title: Wavegain vs. MP3Gain
Post by: john33 on 14 February, 2007, 10:22:56 AM
Is there a collection which includes (or allows you to put together) the latest lame version, the wavegain version with -fast option enabled, and which works from within EAC?

I've tried Wack, but it's crashing for me. If I can solve the crashing,  can I get it to run wavegain in -fast mode?

(I know I should know this, and probably made it all run properly on a PC ~two years ago, but now...!)

Cheers,
David.

So far as Wavegain is concerned, running in fast, or standard, mode should make no difference to anything else. The only difference is that it analyses a subset of the wave samples rather than the whole file. -s, or --fast work fine here. I've never used Wack so I can't comment specifically, but I can't see why it should make any difference.