Dynamic Audio Normalizer

[webfork]

Do you have a batch method for conversion yet? Or do I need to get the VST into something like Wavosaur and go that route?

[deathcubek]

Do you have a batch method for conversion yet?

You can do, for example, something like this:

Code: Select all

@echo off
for %%f in (*.wav) do (
   DynamicAudioNormalizerCLI.exe -i "%%~f" -o "%%~nf.normalized.wav"
)

Or do I need to get the VST into something like Wavosaur and go that route?

That's also possible, of course.

Though I think that Wavosaur currently is a bad choice for VST processing (see here for details!).

Instead, I'd recommend Audacity (version 2.0.6+) for this task:
http://gaclrecords.org.uk/win-nightly/

Another very good freeware audio editor with VST support is Acoustica Basic Edition:
http://acondigital.com/downloads/

[Midas]

Or do I need to get the VST into something like Wavosaur and go that route?

That's also possible, of course.

Though I think that Wavosaur currently is a bad choice for VST processing (see here for details!).

• As he's somewhat of a regular here at TPFC, has the Wavosaur developer been informed of this issue?
  
  EDIT: I did it, just now...

[deathcubek]

Or do I need to get the VST into something like Wavosaur and go that route?

That's also possible, of course.

Though I think that Wavosaur currently is a bad choice for VST processing (see here for details!).

As he's somewhat of a regular here at TPFC, has the Wavosaur developer been informed of this issue?

Yes. I posted the problem in the Wavosaur forum several weeks ago. But no reaction thus far...

[deathcubek]

Dynamic Audio Normalizer v2.07:
https://github.com/lordmulder/DynamicAu ... s/tag/2.07

Changelog:

• Implemented .NET API → Dynamic Audio Normalizer can be used in, e .g., C#-based applications
• Implemented JNI API → Dynamic Audio Normalizer can be used in Java-based applications
• Implemented Pascal API → Dynamic Audio Normalizer can be used in Pascal-based applications
• Core library: Added new getConfiguration() API to retrieve the active configuration params
• Core library: Fixed a bug that caused the gain factors to not progress as "smoothly" as intended

[webfork]

Which behavior is "better" (or "worse") highly depends on what you are trying to achieve, of course

Just in terms of voice conversion, I actually preferred the output from your program over Levelator. Any chance you've got something in the way of a basic front-end on the way?

Edit: just ran a test on the latest version of Dynamic Audio Normalizer and it didn't seem to have any impact on a voice recording (sounds the same). Did something change?

Edit 2: from more testing, it looks like there were several volume changes throughout the file. Starts out quiet, then loud, then quiet again. The last time I tested this I recall it sounding really sharp throughout so maybe my files are different? Will keep testing.

[deathcubek]

Which behavior is "better" (or "worse") highly depends on what you are trying to achieve, of course

Just in terms of voice conversion, I actually preferred the output from your program over Levelator. Any chance you've got something in the way of a basic front-end on the way?

We have CLI (Command-Line) front-end, a SoX (Sound eXchange) front-end, a VST (Virtual Studio Technology) front-end, as well as a Winamp front-end.

In addition to that, the "core" library provides bindings for C++, C99, Java, Microsoft.NET and Pascal/Delphi. What more do you need at this point

Edit: just ran a test on the latest version of Dynamic Audio Normalizer and it didn't seem to have any impact on a voice recording (sounds the same). Did something change?

I don't know how your original recording looks. But the whole purpose of this tool is increasing the volume in "quiet" parts, in order to harmonize these parts with the "loud" parts. In the "loud" parts we cannot increase the volume any further. At least not without applying a "real" compression (i.e. cut off the signal peaks) - which is what we want to avoid. Furthermore, the gain factors are smoothed by a Gaussian kernel in order to avoid fast fluctuations of the gain - which could result in unwanted "pumping" effect. Instead, we ensure that the gain adapts smoothly/continuously and early/slowly. And this means that a "quiet" section needs to have a certain minimum length before it will be effected.

So, if your original audio is already "loud" all the way, or if you only have very short "quiet" sections that are surrounded by "loud" sections, then there simply is nothing to be changed! Of course you could make the Normalizer adapt more quickly by adjusting the "--gauss-size" parameter. If you think the default of 31 adapts to slowly, try 21 or 11. Of course, the lower you set this, the higher the chance the there will be noticeable "pumping". That's why the default was chosen with a certain "safety margin".

Edit 2: from more testing, it looks like there were several volume changes throughout the file. Starts out quiet, then loud, then quiet again. The last time I tested this I recall it sounding really sharp throughout so maybe my files are different? Will keep testing.

Well, the gain factor starts at ×1.0 and then adapts to the content. So it all depends on your input

Please consider this artificial example file:
http://i.imgur.com/U0yD05l.png
(upper view is original input, lower view is processed waveform)

The Gain factors look like this for the above example:
http://i.imgur.com/oymAHpT.png

[deathcubek]

Dynamic Audio Normalizer v2.08:
https://github.com/lordmulder/DynamicAu ... s/tag/2.08

Changelog:

• CLI front-end: Very short files (shorter than Gaussian window size) are now handled properly
• Core library: Fixed case when flushBuffer() is called before internal buffer is filled entirely
• Core library: Workaround for the FMA3 bug in the Microsoft Visual C++ 2013 runtime libraries
• Makefile: Various improvements

[deathcubek]

After all, here is a new TEST version:
https://sourceforge.net/projects/mulder ... r/Testing/

This update fixes a problem with the "pre-filling" code, i.e. generation of the samples before the first "real" input sample. The old code could result in clipping at the beginning of the file under certain circumstances.

Example:

• Original input file: http://i.imgur.com/7Z4Ppe4.png
• Result with "old" code: http://i.imgur.com/Cb5HeqX.png
• Result with "new" code: http://i.imgur.com/Vl6YEad.png

[shnbwmn]

Would this work as a plugin in Foobar2000? I'm not familiar with Foobar's compatibility with Winamp plugins.

[deathcubek]

Would this work as a plugin in Foobar2000? I'm not familiar with Foobar's compability with Winamp plugins.

In theroy, yes. There exists a component for Foobar2000 to load Winamp DSP plug-in's:
http://wiki.hydrogenaud.io/index.php?ti ... sp_winamp)

In practice, I have no idea, because I haven't tried.

Also, because Foobar2000 processes audio samples as flaoting-point, just like the DynAudNorm library does internally, but Winamp uses integer samples, you would end up with four conversions!

(You actually want a "native" Foobar2000 component)

[Specular]

I use this in ffmpeg as a filter, works great. Only option I didn't hear a difference with was the n option ('Enable channels coupling'). Though perhaps normalizing each channel independently makes less of a difference than expected.

[Andrew Lee]

Do you have a batch method for conversion yet?

I have updated Media Cookbook to include this method of audio volume normalization (recipe: Normalize volume of audio files dynamically).

I am interested because I download talks from YouTube in audio form and normalize the volume before moving them to my smartphone for offline listening.

Some of them have short ads in-between that are louder than the rest of the show, causing mp3gain/aacgain to be less effective at making the normalized audio as loud as they can be. This algorithm appears to solve the problem on the audio files that I have tried so far.

[deathcubek]

I use this in ffmpeg as a filter, works great. Only option I didn't hear a difference with was the n option ('Enable channels coupling'). Though perhaps normalizing each channel independently makes less of a difference than expected.

It makes the more difference, the more the original volumes of those channels differ. And, because the filter uses a pretty large window (by default), if the channels only differ for a short moment, it won't have any effect. Those very short volume variations simply get smoothed away by the Gaussian kernel. You will see a difference, hopefully, if one channel is louder/quieter than the other one in average, e.g. badly balanced recording. Or when there is a longer quiet passage in one channel, but not the other.

Do you have a batch method for conversion yet?

I have updated Media Cookbook to include this method of audio volume normalization (recipe: Normalize volume of audio files dynamically).

Cool

[deathcubek]

After all, here is a new TEST version:
https://sourceforge.net/projects/mulder ... r/Testing/