Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Wavegain vs. MP3Gain (Read 173500 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Wavegain vs. MP3Gain

Reply #75
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?

Wavegain vs. MP3Gain

Reply #76
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).

Wavegain vs. MP3Gain

Reply #77
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?

Wavegain vs. MP3Gain

Reply #78
I think it would be very worthwhile.
WARNING:  Changing of advanced parameters might degrade sound quality.  Modify them only if you are expirienced in audio compression!

Wavegain vs. MP3Gain

Reply #79
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.

 

Wavegain vs. MP3Gain

Reply #80
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'.

Wavegain vs. MP3Gain

Reply #81
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??

Wavegain vs. MP3Gain

Reply #82
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.

Wavegain vs. MP3Gain

Reply #83
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.

Wavegain vs. MP3Gain

Reply #84
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.

Wavegain vs. MP3Gain

Reply #85
Damn, this is a good idea.. I'm surprised no one brought it up sooner. 

I'll have to test for myself.

Wavegain vs. MP3Gain

Reply #86
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
WARNING:  Changing of advanced parameters might degrade sound quality.  Modify them only if you are expirienced in audio compression!

Wavegain vs. MP3Gain

Reply #87
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
Sorry, I have nothing witty to say here.

Wavegain vs. MP3Gain

Reply #88
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

touche, that was a year ago...

I never read that thread though, honest!

Wavegain vs. MP3Gain

Reply #89
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

Wavegain vs. MP3Gain

Reply #90
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!!!

Wavegain vs. MP3Gain

Reply #91
Quote
Yes, it'll be based on the modified version. ;)

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

Happy tinkering!

Wavegain vs. MP3Gain

Reply #92
@DickD: I haven't forgotten this!!! It's just taking a little longer than I anticipated.

Wavegain vs. MP3Gain

Reply #93
Any word?  A search turned up this topic by accident and I'm facsinated.

Wavegain vs. MP3Gain

Reply #94
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!!

Wavegain vs. MP3Gain

Reply #95
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!

Wavegain vs. MP3Gain

Reply #96
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!!

Wavegain vs. MP3Gain

Reply #97
How can one compare our portable's volume output setting to the --scale value to allow the accurate volume setting to be chosen?
WARNING:  Changing of advanced parameters might degrade sound quality.  Modify them only if you are expirienced in audio compression!

Wavegain vs. MP3Gain

Reply #98
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).

Wavegain vs. MP3Gain

Reply #99
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?
WARNING:  Changing of advanced parameters might degrade sound quality.  Modify them only if you are expirienced in audio compression!