HydrogenAudio

Welp. I went and made a normalizer DSP out of libebur128. Have fun with it (http://www.foobar2000.org/components/view/foo_r128norm). Oh, and I posted the source (http://kode54.foobar2000.org/foo_r128norm_source.zip), which requires the libebur128 files from the R128Scan source (http://kode54.foobar2000.org/foo_r128scan_source.zip).

It's currently hard coded to maintain a preview latency of 500ms, and uses the short-term loudness level measured from a three second window as the gain correction reference, which it updates every 100ms. I may make this configurable in the future.

Change log:

• Version 1.10 - 2011-02-07 14:12 UTC:
  
  • Fixed a bug in libebur128 when handling weird sample rates.
• Version 1.9 - 2011-02-05 06:11 UTC:
  
  • Re-enabled increasing the gain level.
  • Changed momentary and short-term loudness to gated loudness.
• Version 1.8 - 2011-02-04 13:44 UTC:
  
  • Disabled the gain from increasing above 1.0, for now.
• Version 1.7 - 2011-01-28 06:19 UTC:
  
  • Fixed initial gain values on startup, again.
• Version 1.6 - 2011-01-27 23:43 UTC:
  
  • Now correctly flushes the buffer on playback termination.
• Version 1.5 - 2011-01-27 23:07 UTC:
  
  • Reenabled momentary loudness polling.
  • Changed volume ramping to 1 dB every 50ms.
  • Current scale is now forced to the detected target scale after the initial buffering completes.
• Version 1.4 - 2011-01-27 20:19 UTC:
  
  • Increased the latency to maintain at least 500ms worth of samples.
• Version 1.3 - 2011-01-27 20:06 UTC:
  
  • Reverted short-term gain level changes to instantaneous again.
• Version 1.2 - 2011-01-27 19:58 UTC:
  
  • Disabled momentary loudness polling and increased short-term loudness polling frequency.
• Version 1.1 - 2011-01-27 19:22 UTC:
  
  • Adjusted gain level changes a bit.
• Version 1.0 - 2011-01-27 19:00 UTC:
  
  • Initial release.
• Version 0.0 - 2011-01-27 16:53 UTC:
  
  • Created project.

Seems useful for night listening among other things. Thanks!

Oh yeh, its around 2.8x faster than my port of Garf's Dynamics Compressor.

So, its quite nice, really.

its around 2.8x faster than my port of Garf's Dynamics Compressor.

They don't do the exact same thing, as you will know. The effect of foo_r128norm is more like that of Vlevel (http://www.hydrogenaudio.org/forums/index.php?showtopic=22057&hl=Vlevel), i.e. it seems to adjust the volume (slowly) over time as opposed to compressing the dynamics to make it sound louder. It sounds obviously radio-ish. The calculations will probably be much different (from Vlevel) though, and a fixed 3 sec. sliding window is used.

It could have it's use, configurable settings are welcome. It might need something like a maximum gain or lowest (source) level to amplify (threshold). Right now start of (next) track after a couple of seconds silence and some fade-outs are handled unpleasantly.
A name suggestion? foo_dsp_r128norm .

When I add configuration, I will add an option to only reduce gain instead of also increasing it.

Thank you for making this DSP kode54, now I can finally get rid of that horrible Vlevel.

I don't  mind that it raises volume of quiet parts personally but it gets extremely loud right at the start of tracks. This becomes especially annoying when listening to live recordings. I guess I'm reporting a simmilar issue as GeSomeone. Perhaps adding buffer och that's capable of looking ahead into the next track would be a solution for the issues I'm experiencing. FWIW

It already looks ahead, but it doesn't ask for track change notifications, so it keeps whatever amplification level was achieved by the end of the previous track.

That would explain the loud blasts during track transitions.

It should not be blasting, because it adjusts the gain level fairly quickly, and it looks ahead by half a second.

It should not be blasting, because it adjusts the gain level fairly quickly, and it looks ahead by half a second.

I noticed momentary blasts also. I think it happened with Last FM with songs from different artists. I believe it also happened when playing songs on a playlist with Replaygain shut off.

A great component.

Here's an excerpt where output clips at a track transition: http://www.box.net/shared/0qpuv6r21f (http://www.box.net/shared/0qpuv6r21f)
From 0:18 I start the second track directly and gain is more reasonable.

Hopefully, locking the gain scale to 1.0 or less will fix that problem. I can't make the component request track change marks because it could cause gaplessness issues when using resampling DSPs and such.

Hopefully, locking the gain scale to 1.0 or less will fix that problem.

Version 1.8 highlights: Disabled the gain from increasing above 1.0, for now

Yes, it does ... but now it is just a limiter instead of a normalizer. Wouldn't the correct solution be to make it work "gated", meaning ignore the silence (and probably also near silence like tape noise etc)? Somewhat like you did in the R128scanner.
Another possible approach could be looking ahead just as much as looking back. e.g. look back 1.5s and look ahead 1.5, still a 3s sliding window :-)  Just adding suggestions to the pile.

That change certainly made School from Crime of the Century by Supertramp much better. With version 1.7, it would get almost deafening in parts as it is a very dynamic song. It did not seem to change anything with the flac file previously posted though. Might that be because the quiet part is so long?

Thanks for working on this.

I agree with GeSomeone. With the lastetst update R128Norm loses functionality that makes it a gem of a volume leveler for me. Please consider making it selectable. And if convenient please add track change awareness, also selectable.

Try now. Although I had to make some ugly additions to the library so I could use EBUR128_MODE_I indefinitely without allocating more and more memory.

I installed 1.9 and tried it. At around the 12 second mark the song School i mentioned before blasts pretty strongly. That part of the song was recorded to go from near silence to quite loud instantly. I did not try the blast flac that was posted before. Thanks.

It's better, blasts are reduced even though they're not avoided completely. Volume leveling sounds more natural than before. Thanks for your great work so far!

Thanks very much for your work, I'm sorry it made the code ugly.
What you changed, did help, but unfortunately, not a lot. If a track ends really abrupt the next track may start at a reasonable volume. However when a track fades out a bit slower, R128norm is cranked up at the start of the next track (the "blast" effect). Is the look ahead you mentioned is working as intended?

This happens not only at track changes. I uploaded a sample (http://www.hydrogenaudio.org/forums/index.php?showtopic=86619) of the intro of Monkey Wrench by Foo Fighters from their Greatest Hits. There is a 1.15s break at 0:11.5 that triggers the "blast" effect. At least when played from the beginning, the strange thing is when I start it and skip to 0:10 immediately it won't happen.

In this same sample after seeking (with the seekbar) to 0:09 the volume becomes instantly very high as well. When doing so to 0:08 or 0:10 this doesn't happen.

Another example I will just mention is the intro of Echoes by Pink Floyd. R128norm (used as only DSP) introduces severe clipping there. That can't be right.


used foobar 1.1.2 with track gain applied and only active DSP "EBU R128 compressor" (1.9)

Updated.

This DSP is not guaranteed to prevent clipping. Use the Advanced Limiter if you also need that.

Installed 1.10 and I think it blasted louder than the previous versions. So far, version 1.8 has been the only one that has not done it. ReplayGain on and Advanced Limiter on. Thanks.

1.8 didn't increase the gain at all, so it was only a limiter.

I understand. Well, the song "School" really blasted with version 1.10. It was louder than with 1.9. I think I heard it on streaming radio also. Thanks.

This DSP is not guaranteed to prevent clipping.

Ah, it's just that every other dynamics compressor I've come accross (by far not all that exist) did have a mechanism to keep the signal (just) below 0dBFS. Maybe the term is commonly used for a compressor/limiter combination.

I hope you have an opportunity to play with that sample (and others) to find out what's going on.

If you get more time to tweak this plugin I think you'll find this audio material useful. It's really a stress test for R128Norm

http://www.villex.com/downloads/villex.mp3 (http://www.villex.com/downloads/villex.mp3)

Thanks a lot for this plugin.
However, could you add some tweakable settings (threshold etc), as it is, it's almost unusable for classical music (for which this kind of effect is almost necessary), as even the silent parts are maximized to 0db or so...

Thank you

Since Replay Gain changed to R128,
R128Norm adds Noise first and irregularly.

Because I detour around it with Replay Gain's normalize(94db?)
If R128Norm will be one as Replay Gain's normalize,
please unify them definitely(e.g. Target MP3 alteration volume level : 89db to 94db)

It's a nice plugin and very useful but I have to say I also experience the blasts in the beginning of some songs.

I'm not sure if you're still updating this, but I'd prefer to use this over tagging because I regularly use MusicBrainz Picard to update my tags and I have CLEAR TAGS checked so it re-writes everything. I figure there might be a change and a tag gets removed entirely so if I don't do that the older one would stay present. I want it to mirror their database completely.

Thanks for the great work!

Just tried version 1.11. It is really impressive. I think you nailed it.

Thanks for continuing updates to this plugin

Thank you for making this DSP kode54, now I can finally get rid of that horrible Vlevel.

I wish I could but I cant do so, on classical music, r128norm is unusable
When there's a super quiet section, it stays quiet, then suddenly volume rises a lot, its far from being as smooth as Vlevel (which probably only reacts quicker, i dunno).
I think we should have access to a few parameters at least..

Thanks anyway

I wish I could but I cant do so, on classical music, r128norm is unusable
[..] its far from being as smooth as Vlevel

Yes, two different beasts. Vlevel is designed to be smooth and you can configure it to match your liking best.
This plugin however tries to implement the EBU R128 (broadcasting) norm in a usable way. That means the kind of compression commonly used on pop/rock/country etc. (FM) radio.
I think that is not usable on classical music and that Vlevel is the better choice there.

Maybe with an "advanced" mode or something, which would allow user to set their threshold, gain etc ?

Yes, I did make a lot of constants into variables, because I plan to add a configuration dialog. The current variables are:

Startup latency. The minimum amount of input sample data which will be processed into the EBU R128 scanner before any volume level is calculated and eventually applied. Currently 10 seconds.

Processing window. The duration worth of gated loudness samples, taken 2.5 times per second by the library, which will be retained and processed every time a gain correction is made. Currently 20 seconds.

Minimum latency / look-ahead. The minimum amount of sample data which will remain buffered after the startup period occurs. Volume changes occur at least this much behind the data which has been fed through the scanner. Currently 4 seconds.

Volume change sensitivity. This is the rate at which volume changes occur between the current level and the new level. Currently 1dB per 50ms.

Reference loudness level. This is the volume level that the scanner tries to achieve. Currently -18 LU, which is equivalent to the ReplayGain scanner component.

This plugin is great. It's perfect for evening background music playback without using radio station style compression, which hurts the sound.
Would it be possible for you to compile it into a VST plugin? I would buy a VST provided it wasn't priced outrageously.
By the way, Waves just released a R128 compliant meter and they are asking a lot of money for it- $299.00. http://www.waves.com/content.aspx?id=11884 (http://www.waves.com/content.aspx?id=11884)
Your plug could display the measured values plus ride the gain in real time.

The thing is, I'm not sure if VST supports such latency as this component needs. It needs to absorb the first 10 seconds worth of sample data fed into it, and then it maintains a constant latency of 4 seconds. Not to mention that I've only ever worked on a VST (instrument) host, not the plug-in side of things, even if it shouldn't be that much different.

The thing is, I'm not sure if VST supports such latency as this component needs. It needs to absorb the first 10 seconds worth of sample data fed into it, and then it maintains a constant latency of 4 seconds. Not to mention that I've only ever worked on a VST (instrument) host, not the plug-in side of things, even if it shouldn't be that much different.

I'm not sure what the limit on pre-buffering audio in VST is. Considering that there are VST delay processors, which can be set up to output fully wet or 100% effect signal, I see no problem with having your plugin act like one. Yes, it would not be a real time effect, as it would push audio back by 10 seconds every time, but for processing complete stems inside a VST host it could be valuable.
Also, there is technology in the VST spec that allows for outside of host processing as used by Melodyne or similar pitch correcting processors. Basically complete audio track is temporarily exported to the VST, processed in whole and then inserted back where it belongs on a time line. Something to consider for you.

People compress complete mixes or submixes with various dynamics processors. Automatic gain riding like your processor does, could be used to very transparently compress audio to a different standard- just another cool tool for music creators.

Yes, I did make a lot of constants into variables, because I plan to add a configuration dialog. The current variables are:

Startup latency. The minimum amount of input sample data which will be processed into the EBU R128 scanner before any volume level is calculated and eventually applied. Currently 10 seconds.

Processing window. The duration worth of gated loudness samples, taken 2.5 times per second by the library, which will be retained and processed every time a gain correction is made. Currently 20 seconds.

Minimum latency / look-ahead. The minimum amount of sample data which will remain buffered after the startup period occurs. Volume changes occur at least this much behind the data which has been fed through the scanner. Currently 4 seconds.

Volume change sensitivity. This is the rate at which volume changes occur between the current level and the new level. Currently 1dB per 50ms.

Reference loudness level. This is the volume level that the scanner tries to achieve. Currently -18 LU, which is equivalent to the ReplayGain scanner component.

May I suggest you make maximum gain your processor applies also a variable?  Sometimes long quiet parts of music get amplified too much. This happens mostly with acoustic, jazz and classical. If you could specify a max gain of let's say 12-18dB all that ambiance would not come up too drastically in those moments.

I think this plugin works quite nice. It gives a certain FM radio 'feeling' by compressing and pumping the volume. Sometimes it even gives a nice punch to the certain parts of the songs by doing that.

A very nice plugin when you want to listen to for example your whole library, there sure is some volume differences between some songs - especially if you haven't done ReplayGain scan to your files. I haven't and I have lot of music.. I tried it.. but it would have taken quite a long time to complete it.

But, I have two wishes:
1) sometimes it pumps levels too much, for example in the end of the songs that have a long fade out or in songs that have long quiet parts
2) it would be also nice if the reference level could be changed. Foobar's own preamping isn't working either with this plugin.

Hey guys,

how is this plugin different from replaygain?
what's the benefit of using it ?

thanks

It uses the same algorithm of volume measurement as the current ReplayGain scanner, only it uses a pre-fill scan and latency window to apply a short-term volume correction on the audio in real-time. It may have a similar volume measurement and scaling effect, but it is more of a normalizer, as it only scans small amounts at a time, and is prone to volume swings being scaled to more of a flat response, while normal ReplayGain and R128 scan the volume level of the entire track or album at once and only apply a single correction level on a track by track or album by album basis.

Hm, having read the whole thread now and only been listening to some tracks for a short while, I wonder what this plugin does when a replaygain scanned track is being played.

In case it's always active and ignores replaygain information, it should still have an effect if the song has sections with highly differing dynamics, right? If that is the case wouldn't an option be good to disable this DSP if replaygain information is present? Well, ideally I'd also love to see an option to only activate this plugin on internet streams.

http://www.hydrogenaudio.org/forums/index....=0&p=823073 (http://www.hydrogenaudio.org/forums/index.php?showtopic=99159&st=0&p=823073)

post 15 onwards will be of interest.

Well, the question has been raised in #18, but it wasn't answered. I might look into this Dynamic DSP, but I don't think it's worth the hassle just for a few radio streams.

@kode54
Can you add like this?

1. If There is ReplayGain information, R128Norm pass through.

or

2. Add check box for Preamp of foobar2000 (eg. Use R128Norm for Without RG info)

I think the latter is more better

@kode54
Can you add like this?

1. If There is ReplayGain information, R128Norm pass through.

The third party Dynamic DSP component already handles this perfectly, as outlined in [a href='index.php?act=findpost&pid=826334']this post[/a]. Just be sure to add this instance of the Dynamic DSP to the top of your playback chain.

2. Add check box for Preamp of foobar2000 (eg. Use R128Norm for Without RG info)

I think the latter is more better

Sorry, that's beyond my control.

I thank you very much.

1. RG info with Daymic DSP to R128Norm = x645.249

2. RG info with nothing = x673.728

3. RG info with only R128Norm = x359.160

Got a question about how to use this component.

Before you created this component, I've scanned my entire FLACs library and applied RG in track mode.

So now, in order to try to hear the difference between the old RG and this R128 one, in options -> playback, I shout disable RG (source mode and processing set to none) and only use your R128 component in the DSP manager right ?

Thank you

Aldem

You do not need to disable ReplayGain to use this normalizer. From your post I kind of got the impression you consider this a ReplayGain replacement. If you merely want to see how R128 loudness scanner's result differ from the old ReplayGain scanner just scan your files again with the built-in scanner. It uses the R128 method nowadays.

Is this possible to make any configuration for this component available? Maybe it will help tune this plugin to work better? It could be nice to listening music at night with this plugin , but I noticed that mostly it works bit to slow. When there is quieter part in track, at first it is played at low volume, after some time (about 1 - 1,5s) quiet becomes loud enough. When loud parts come back, then at first moment they are bit louder than they should be, but after some time (like several seconds) they have proper volume. Other thing is that I have impression that quiet parts, after making them louder, are even louder than parts that are regularly loud. Is there any update for this plugin expected?

Is this possible to make any configuration for this component available? Maybe it will help tune this plugin to work better? It could be nice to listening music at night with this plugin , but I noticed that mostly it works bit to slow. When there is quieter part in track, at first it is played at low volume, after some time (about 1 - 1,5s) quiet becomes loud enough. When loud parts come back, then at first moment they are bit louder than they should be, but after some time (like several seconds) they have proper volume. Other thing is that I have impression that quiet parts, after making them louder, are even louder than parts that are regularly loud. Is there any update for this plugin expected?

For symphonic, classical, ambiant, etc, I still use V-Level. I think kode54 said somthing about being able to change "some" settings in the next release.

For symphonic you've said... How about for progressive and melodic trance?

I can't edit my older post so I have to double post. For trance vlevel also works better... On default settings. Even on Sunny Lax'es "M.I.R.A." which has serious level dropdown in the middle of the track vlevel works very good, as well as on several Oliver Smith tracks. Or on Kyau vs Albert's "Falling Anywhere". On Original Mix of Menno de Jong's "Guanxi", Nitrous Oxide's "Morning Light"... Vlevel everywhere works better for me.

Really like this component, it's almost perfect. Using it when converting different songs for one use case. MP3 player for sport, USB flash drive for in the car, etc.

My car stereo lacks some performance unfortunately. The default reference loudness level makes sense, but I'd like to be able to adjust it for in this case. The files are all so low after conversion, that my weak sauce of what can barely be called a car stereo won't produce an acceptable level of loudness for my needs.

I know I can boost the signal with otherwise, but I'm not into the whole matter and would prefer to keep it as simple as possible.

tl;dl: Suggestion - Include an "oomph mode" that produces much higher output levels by choosing a higher reference loudness level.

Thanks for all your time and work you put into all these countless tools. Much appreciated.

I use VST plugin to boost sound..
But possibility to choose a higher loudness level would be great..

Sure, adding more DSPs/VSTs are an alternative do increase volume/loudness. But since I'm really happy with how the R128 stuff does its thing, there's actually no need for additional DSPs, if you could just select different reference levels as a setting.

Here's what I'd do (until r128Norm has an option to alter reference levels). This DSP chain can be setup for conversion only:

DSPs:

• r128Norm
• Graphic Equalizer (http://www.foobar2000.org/components/view/foo_dsp_xgeq)  (just to boost volume) say +6dB
• Advanced Limiter (this will ensure no samples clip)

There may well be better ways to do this - but I do something similar and this works for me.

C.

Sounds like a reasonable approach. Thanks for the suggestion.

I started using the foo_r128norm component in foobar about 3 weeks ago. I like how it handles flac, ape, wv files etc. but when I play an SACD iso file it usually comes out too quiet. Perhaps kode54 could test this for me?

If you're using the SACD component's ASIO output method, it bypasses all DSPs and goes straight to your sound device. Or at least I assume as much, since DSP chains rightly can't process DSD content directly.

@kode54 is there a chance you make standalone app for this dsp ?

@kode54 is there a chance you make standalone app for this dsp ?

I ask because I've been using this dsp for conversion in foobar, I've never use it as live dsp.

I don't even see how that would work. Maybe it would be more constructive to ask the author of VB-Audio Voicemeeter Banana to add such a thing to their software.

just curious, does this compressor would be louder if audio source is mono than stereo?

reproduce:
insert 'downmix channels to mono' before this compressor.

Thank you.
Nice plugin like Vlevel, but more advanced.
The question is, your plugin do any change to dynamic range of track?
And question num 2, your plugin do any compression to sound, when is playing?

It may affect the dynamic range, since it tries to keep a near constant volume level, so quiet parts will become louder, and louder parts may become quieter. It does not do any equalization type compression, however, nor does it reshape the peaks to squash them, it should lower the volume overall instead.

While waiting for the arrival of new headphones for portable audio player, I have to use broken ones to listen for a course of Youtube-downloaded lectures. Broken headphones are barely audible, yet amping the volume of sound files does the trick more or less. Question is — in this particular case when irreversible changes are acceptable — whether it is better a) to transcode MP4 into MP3 and apply Replaygain to file content or b) to transcode MP4 into MP3 with EBU R128 in DSP?

For those who like to dig under the hood, below are the five minute cuts of a two hours lecture (https://www.youtube.com/watch?v=f-wWBGo6a2w) mentioned in the previous message.
Cuts are made according to the following pattern: FFmpeg -i Lecture.Original.Full.mp3 -ss 00:00:29 -t 296 -codec copy Lecture.Original.Cut.mp3
MP3Gain cut is omitted, because, to my astonishment, it did not impact that period (even its checksum matches Original cut) and in general had a subtle impact.
Waveforms are generated via nameless online tool (http://convert.ing-now.com/mp3-audio-waveform-graphic-generator/), resized via IrfanView (http://www.irfanview.com/) and optimized via Pingo (https://css-ig.net/pingo).

(https://images.vfl.ru/ii/1519768794/48151c80/20760891.png)
Lecture.Original.mp3 (https://filebin.net/jqzf4m9vebr86mje/Lecture.Original.mp3) (transcoded from AAC into MP3 via Foobar2000 using Lame 3.100 --abr 128)

(https://images.vfl.ru/ii/1519768794/1f0460ca/20760892.png)
Lecture.Replaygain.mp3 (https://filebin.net/jqzf4m9vebr86mje/Lecture.Replaygain.mp3) (track replaygain +5.30 dB applied to Original after transcoding from AAC into MP3)

(https://images.vfl.ru/ii/1519768792/2fca3e17/20760890.png)
Lecture.EBUR128.mp3 (https://filebin.net/jqzf4m9vebr86mje/Lecture.EBUR128.mp3) (EBU R128 and Advanced Limiter used during transcoding from AAC into MP3)

Aha, MP3Gain did not amp the volume due to “Don’t clip when doing track gain” checkbox or, if you prefer command-line interface, due to /k switch (which stands for “automatically lower Track/Album gain to not clip audio”). Similarly, if I turn on “Prevent clipping” in Foobar2000’s Replaygain settings, nothing happens and the console says “Reducing applied gain due to clipping: +5.30 dB to +0.00 dB”. Dream of increasing loudness without touching the overloaded parts is still a dream.

(http://images.vfl.ru/ii/1519822481/5595a4d3/20769660.png)   (https://images.vfl.ru/ii/1519779250/2d7e5b6c/20761564.png)

When “Prevent clipping” is off, Foobar2000 does apply the track gain, but too many annoying peaks emerge closer to the end of a lecture (not present in the five minute cut above). On the contrary, the result of EBU R128 DSP paired with Advanced Compressor is almost free of clipped samples. Audition’s analysis as follows.

(https://images.vfl.ru/ii/1519822335/922d4f66/20769638.png)   (https://images.vfl.ru/ii/1519822336/f13d741e/20769639.png)

Thus, answering my own question (https://hydrogenaud.io/index.php/topic,86444.msg953627.html#msg953627) whether it is better — in this case — to apply Replaygain or transcode with EBU R128 in DSP, it seems the latter option produces fewer annoyances, although it is not entirely natural to hear applause from the gallery at the same volume as the speaker’s voice. Do you agree?

If you find the R128 Compressor DSP compresses too much (it works very well, but compresses too much for me) you can try the Dynamic Audio Normaliser. It's built into ffmpeg so if you use ffmpeg as the encoder, try this as the command line in fb2k. It's what I mostly use myself:

-i - -ignore_length true -af dynaudnorm=f=150 -c:a pcm_s16le %d

This should compress a bit harder:

-i - -ignore_length true -af dynaudnorm=f=75:g=11 -c:a pcm_s16le %d

And if you don't want to output a wave file or encode with ffmpeg, this is an example command line for compressing and piping the output to QAAC (you have to set cmd.exe as the encoder). Works on XP. I'm not sure about other Windows flavours.

 /d /c c:\progra~1\foobar2000\encoders\ffmpeg.exe -i - -ignore_length true -c:a pcm_f32le -af dynaudnorm=f=150 -f wav - | c:\progra~1\foobar2000\encoders\QAAC\qaac.exe --ignorelength -s --no-optimize --no-delay -V 91 -o %d -

PS If you don't wan to compress as such, there's always MP3DirectCut. For MP3s it can be used to manually reduce the volume of any unusually load peaks. It doesn't re-encode.

And two more compressors are available for foobar2000 - foo_dsp_dynamics (http://www.foobar2000.org/components/view/foo_dsp_dynamics) and foo_dsp_vlevel (http://wiki.hydrogenaud.io/index.php?title=Foobar2000:Components/VLevel_(foo_dsp_vlevel))

yetanotherid, how nice to get valuable feedback from the other side of the world! Dynamic Audio Normalizer served me well and relatively fast (for example, compared to another FFmpeg’s filter called loudnorm (https://ffmpeg.org/ffmpeg-filters.html#loudnorm)). However, after several hours of experiments I slightly modified its execution to better meet the need of increasing loudness of lectures recorded on the stage:

/d /c ffmpeg.exe -i - -ignore_length true -af "dynaudnorm=s=30:r=0.1:p=0.9" -c:a pcm_f32le -f wav - | lame.exe --ignorelength --noreplaygain --abr 128 - %d

Subtle compression (https://muldersoft.com/docs/dyauno_readme.html#input-compression) (s) is added to soften towering noises from clothes and possible transcoding glitches. RMS (https://www.learndigitalaudio.com/normalize-audio) processing (r) is enabled to amplify voice fluctuations more harmoniously by taking into account not only the peaks but also the quieter parts. Normalization threshold (p) is lowered from default 0.95 to 0.90 to leave more headroom (around -1 dB) for future enhancing (e.g. portable player’s EQ). Frame length (f) and Gaussian window size (g) are not adjusted as you suggested, because the speaker’s breath becomes accentuated. Having said that, I welcome amendments and additions.

Rollin, thanks for mentioning other Foobar2000 compatible solutions. Alas, both dsp_dynamics and dsp_vlevel require prior knowledge of compressor’s anatomy (https://gist.github.com/scottburton11/3222152). Lack of graphical preview or at least presets for common scenarios makes applying them correctly even harder for amateurs like myself.

(https://images.vfl.ru/ii/1520003680/41d46039/20797889.png)   (https://images.vfl.ru/ii/1520006387/07998625/20798460.png)

Ah, Hydrogenaudio allows to edit own messages for so short period of time.

Edit: r=0.1 -> r=0.12

(https://images.vfl.ru/ii/1520010331/0b3500ec/20799287.png)
Lecture.Dynaudnorm.mp3 (https://filebin.net/jqzf4m9vebr86mje/Lecture.Dynaudnorm.mp3)

/d /c ffmpeg.exe -i - -ignore_length true -af "dynaudnorm=s=30:r=0.1:p=0.9" -c:a pcm_f32le -f wav - | lame.exe --ignorelength --noreplaygain --abr 128 - %d

Subtle compression (https://muldersoft.com/docs/dyauno_readme.html#input-compression) (s) is added to soften towering noises from clothes and possible transcoding glitches. RMS (https://www.learndigitalaudio.com/normalize-audio) processing (r) is enabled to amplify voice fluctuations more harmoniously by taking into account not only the peaks but also the quieter parts. Normalization threshold (p) is lowered from default 0.95 to 0.90 to leave more headroom (around -1 dB) for future enhancing (e.g. portable player’s EQ). Frame length (f) and Gaussian window size (g) are not adjusted as you suggested, because the speaker’s breath becomes accentuated. Having said that, I welcome amendments and additions.

I have no clever ideas for the sort of audio you're compressing. I mainly use the DAN to compress soundtrack audio where I prefer the response to volume changes to be very fast.

I think lame accepts 32 bit float input but converts to 24 bit integer before encoding. Probably no big deal, but you might be better off encoding with ffmpeg, given it uses LAME for MP3 encoding anyway.

Maybe I should have mentioned it in my last post (it didn't occur to me at the time) but there's RockSteady (https://winampheritage.com/plugin/rocksteady-2-1/1099) if you want to try something else. I use it daily  because I compress soundtrack audio on playback via RockSteady & ffdshow's WinAmp filter (rather than compress when converting), but there's a WinAmp DSP bridge (http://wiki.hydrogenaud.io/index.php?title=Foobar2000:Components/Winamp_DSP_Bridge_%28foo_dsp_winamp%29) for fb2k so you can run RockSteady that way. I don't know if it'll necessarily do a better job than the Dynamic Audio Normaliser. Maybe just different, so to speak.

It's limited to stereo and 16 bit input (at least that's all I can get to work with ffdshow) and tends to crash fb2k if you try to encode more than one file at a time (I think the Winamp bridge is to blame), but one at a time is fine.
On the plus side.... it has a GUI and you could add it as a DSP to the playback chain and fiddle around, without having to convert the audio to hear the result.

yetanotherid, luckily, the author of Dynamic Audio Normalizer is responsive via Videohelp’s thread (https://forum.doom9.org/showthread.php?t=170980) and e-mail, I’ll keep posted of his thoughts on the case, if any.

Conversion to MP3 via LAME library of FFmpeg’s 3.4.2 is somehow slow compared to piped processing via LAME 3.100 as follows.

yetanotherid, luckily, the author of Dynamic Audio Normalizer is responsive via Videohelp’s thread (https://forum.doom9.org/showthread.php?t=170980) and e-mail, I’ll keep us informed of his ideas if any.

You meant doom9 I assume?
I had a discussion there about the stand-alone DAN not supporting a fake wave header.
https://forum.doom9.org/showthread.php?p=1796307#post1796307 (hello_hello ID)
It makes it somewhat impractical for use with a GUI. Fortunately there's ffmpeg.
As a "fake" wave header is so universally supported, I had no idea it was technically a hack until then, but I still think it's kind of silly not to support it.

Conversion to MP3 via LAME library of FFmpeg’s 3.4.2 is somehow slow compared to piped processing via LAME 3.100 as follows.

I had noticed that. I've no idea why. The main reason I tend to use ffmpeg for MP3 encoding though, is the encoder seems perfectly capable of encoding peaks above 0dB, but because LAME converts the input to 24bit integer before encoding it clips any peaks above 0db. That doesn't seem to happen when encoding with ffmpeg.
It's just a laziness thing. Sometimes I downmix to stereo and use ReplayGain/fb2k to losslessly adjust the output files to the same volume, so it means I don't have to stress about clipping when encoding so much.

Also, I noticed the later approach makes a highly fragmented output.
In my case, a file with normalized lecture (duration 2 h 38 min, size 113 MB) consists of 500+ fragments according to Contig (https://docs.microsoft.com/en-us/sysinternals/downloads/contig)’s report.

That's something I never would have checked, although I usually defragment by accident as I have fb2k writing the output files to one drive/partition before moving them to another for storage. :)

Hi.
kode54, the plugin is good! Thank you.

But, using it together with "skip silence (mod)" DSP and "crossfade (internal)" functions, I've noticed that "silence" in tracks causes cutting a "non-silent" part of track which is close to the "silent" part in the end. Tried bigger out buffer (normally 2000ms, increased to 5000ms). Crossfade in 500ms, out 1500ms.

Found a workaround. Instead of internal crossfader (on automatic track change) used separate crossfader DSP with the same duration (1500ms). Since that no problem. :-/

Hi, thanks Kode54 for this plugin :)

I'm having a couple of problems…

1. First, I'm not even sure the plugin is working? I've added it in the DSP manager, but I don't hear any obvious difference to the overall volume level. Is there any way to know that it's running?

2. How do you access the controls? Assuming it's working, the rate of volume change doesn't seem fast enough, and the compression isn't as high as I'd like: parts of the music still seem too quiet. I want the volume to be completely even throughout a song, including at the end when the song fades out - I want the noise during silence to be as loud as the music. (This is how the normalizer works in Daum PotPlayer and I really like it that way.) And if this plugin can't do this, what can?

3. The reason I want a normalizer is to have a completely smooth volume curve to protect my ears during headphone listening. But since I'll only use it with headphones, I'd like to be able to toggle it on/off quickly, ideally with a keyboard shortcut. Is there any way to quickly toggle it without going into the DSP prefs?

By the way, thanks for Carpman for the excellent suggestion of boosting audio by adding the Graphic Equalizer and Advanced Limiter to the DSP stack. Foobar is a little too quiet by default.

I only made it as a proof of concept. It has no configuration, it's meant to be subtle, and it was designed more for making loud music quiet, not for making every quiet piece of music as loud as your line will allow.

If you don't like it, consider contributing to the source code repository. Pull requests are welcome, although they're no guarantee of accepting user changes. Or use that PotPlayer thing to blast your music.

(...)
3. The reason I want a normalizer is to have a completely smooth volume curve to protect my ears during headphone listening. But since I'll only use it with headphones, I'd like to be able to toggle it on/off quickly, ideally with a keyboard shortcut. Is there any way to quickly toggle it without going into the DSP prefs?

By the way, thanks for Carpman for the excellent suggestion of boosting audio by adding the Graphic Equalizer and Advanced Limiter to the DSP stack. Foobar is a little too quiet by default.

1. Yes, it is possible to add keyboard shortcut to certain saved DSP chain - just go to Preferences and look for Keyboard shortcuts and dig through available options. Remember to save your chain before attempting making shortcut.

2. You present VERY interesting point of view... You want to protect your ears and you perceive foobar as "too quiet" so you are looking for ways to modify its operation by trashing your music with excessive, boosted loudness, using limiters, equalizers, compressors... Let me explain something to you: it doesn't work like that. The more "smooth volume curve" and the bigger volume is (at the same time), the quicker your ears become tired - on a daily basis. And you quicker become deaf as you grow older - on a longer perspective. You can protect your ears by not modifying music dynamics AND using ReplayGain, choosing processing for example as "track+prevent clipping" and simply listening to music not so loud. Avoiding big loudness/volume is the best way to protect ears and hearing. I can tell you this as an employee of hearing aids manufacturer, with background in audiology. Especially if you listen on headphones, big loudness shouldn't be necessary for good music sensations. Plus increased humidity under headphones unfortunately make things worse, when compared to high volumes exposure in free field (no head/earphones).

BUT if you just want to boost loudness, "smoothen volume curve", etc. because you like it - then OK, do this - it is all up to your free choice, but don't lie yourself, that you are "protecting your ears". Occasional peaks aren't that harmful as continuous high loudness level. People's hearing abilities survives peaks coming from blasting bombs or crackers close to them. But people working in places where there is continuous high loudness level (factories, mines, etc.) suffer from ordinary deafness. Think of it.

kode54,

Thanks for your reply. I hope I didn't come across as ungrateful, that was not my intention. A subtle normalizer is still useful, and better than nothing. I assumed there was configuration because on page 2 you listed some of the variables? I guess that's something only you can change. I'm certainly not clever enough to change code myself.

Epicforever,
Thanks for the tips and advice, I appreciate what you're saying.

Firstly, I should clarify that I use earbuds (I was just using the generic term "headphones" for simplicity, but I guess in a forum like this I ought to be more precise!) As a matter of fact, I absolutely hate headphones and IEMs. Cannot stand either of them. The only type of headphone I could bear to use is ear buds.

As for Foobar's loudness, the program really does seem a little quiet to me, on my hardware. But it's not that I want to have Foobar at maximum volume, I just think it has a limited top range.

If I listen to music in Foobar, I'd normally have the volume at around 50% and wouldn't dream of turning it up much higher, there is no need. But Foobar's maximum volume really does seem quiet to me. There are other applications that go way louder, so Foobar seems a little deficient in its range, and I like to feel that I have full control over the volume rather than it being restricted by software.

There's also the matter of consistency: Normally, I have my volume level set really low, maybe about 20%, because most other software has very loud maximum volume. But then when I come into Foobar, I need to turn the volume up to something like 40% because Foobar seems much quieter.

I appreciate what you're saying about ear fatigue, but I don't listen to music very often (certainly not every single day, as you suggest). I listen to maybe about a dozen songs per week. I generally like to spend my days in silence, and I hate noise There is a big difference between spending 8 hours a day in a noisy environment, and spending maybe 10 minutes per day listening to music.

I should also clarify that I spend more time making music than listening to it, and when I've got my earbuds in, it's almost always to analyze the music, pick out the notes, chords etc. So I may have it a little louder just to hear everything more clearly. But whether I'm "trashing" the music, does not concern me.

Surely anyone who wanted a high quality, enjoyable, listening experience would not even dream of using a normalizer, as it fundamentally changes the dynamics of the music, which defeats the point?

Yes, I use ReplayGain. I can't imagine why anyone wouldn't, it is absolutely essential, surely? Who wants inconsistent track volumes?

I love this thing!
I get loads of pleasure from my music without irritating my neighbours!

Hello!

This plugin is really interesting. But there might be a problem for me:
Quieter passages of a musical piece get also normalized after a few seconds and get (almost) as loud as the other, louder parts. I think it would be better, if this plugin would only focus on the peak volume of an audio file in order to preserve the dynamics of the music.

------------------------------------

Update:
Sadly, foo_dsp_dynamics doesn't behave much different. I listened to a tune that has a rather quiet intro. Without compression, the volume stays low as intended. With compression, it is almost as loud as the next part.
Aren't there any compressors that preserve the dynamics (i.e. the loudness variation within an audio file)? Or is this just a question of settings?

Compressors compress dynamics by their very definition, so finding a compressor that preserves dynamics is a bit of an oxymoron.

If you are looking for something that keeps all of a track or album's internal dynamics, but evens out the average volume track to track (or album to album), then just use the built in ReplayGain (set to Track or Album gain, as required).

Thanks! Then it was my misunderstanding of how compressors work. I will use ReplayGain instead.

R128Norm is a dynamics compressor, by definition, but not the same as some compressors. For instance, it's not a multi-band compressor, so it only affects perceptible volume level to be approximately the same, using a running average that collects over a small window, and ramps the result smoothly. It won't adjust the frequency response of different frequency bands, but yes, it does try to flatten out the overall dynamics of whatever passes through it.

R128Norm is a dynamics compressor, by definition, but not the same as some compressors. For instance, it's not a multi-band compressor, so it only affects perceptible volume level to be approximately the same, using a running average that collects over a small window, and ramps the result smoothly. It won't adjust the frequency response of different frequency bands, but yes, it does try to flatten out the overall dynamics of whatever passes through it.

@kode54 is there any chance of getting just a few simple options added to this plugin? Raising the LUFS to Spotify's -16 would be fantastic! Or even a way to post-processing raise the volume of all songs in general?

Thank you so much for such a great plugin!