DynamicAudioNormalizer [Archive]

hello_hello

4th August 2014, 18:49

It seems to work very much like the WinAmp "compressor" plugin I've been using with ffdshow for years. I'm not a fan of altering/compressing the audio before encoding it (at least not for general soundtrack audio), so I do it on playback instead, but not everyone uses a PC as a media player. If the DynamicAudioNormalizer works as well as the WinAmp RockSteady (http://uploadgeneration.info/Winamp/www.winamp.com/plugin/rocksteady-2-1/1099.html) plugin, and they seem to work in a similar fashion, it should be a good thing.

If you're interested, I posted about the way I compress audio on playback in this thread (http://forum.videohelp.com/threads/364801-Any-VST-plugin-%28or-%29-to-automatically-and-heavily-compress-dynamic-range?p=2324026&viewfull=1#post2324026). I also included a few samples. I was comparing the RockSteady plugin to Levelator (http://web.archive.org/web/20130729204551id_/http://www.conversationsnetwork.org/levelator/). I wasn't overly excited about Levelator but it's not designed for soundtrack audio.

Compressing the audio the traditional way and "compressing it" by increasing the volume of the quiet parts are both susceptible to the same "pumping" problem, where you can hear the volume of background sounds going up and down. The more you compress, the more it's likely to happen. Normalising the way the DynamicAudioNormalizer does it tends to be easier to configure than standard compression though..... well my setup is pretty much set and forget.... I'm not needing to constantly adjust it as you probably would using standard compression.

Anyway..... I wouldn't normally compress while encoding, but I will give the DynamicAudioNormalizer a spin at some stage.
There's another free WinAmp "compressor" DSP here (http://loudmax.blogspot.com.au/). Once again you can use it with ffdshow. Same principle, easier to configure.

tebasuna51

4th August 2014, 19:34

LoRd_MuldeR

4th August 2014, 22:51

The author, LoRd_MuldeR, is a moderator in this forum then, maybe, can help you about this.

I think can be applied to some audios bad recorded, but I don't think is for use always.
Good audio tracks have the Dynamic Range than the author want, and compress it is not recommended at all.
But, of course, is your choice.

I recommend read Loudness war (http://en.wikipedia.org/wiki/Loudness_war)

Since you mention "compression" and "loudness war" I just want to clarify that the Dynamic Audio Normalizer doesn't quite work like a compressor. The compressor first "flattens" the signal peaks (by reducing all samples above a predefined threshold), which results in a certain headroom, and then applies a fixed gain in order to bring the signal to the maximum level again. The results in a much "louder" signal, but the peaks are gone for good. The dynamic range has been reduced significantly.

At the same time, the Dynamic Audio Normalizer works more like a "standard" normalizer. It simply applies a certain gain factor to the samples, but doesn't prune any samples before that. This means that the maximum gain factor is restricted by the highest magnitude sample. The difference between a "standard" normalizer and the Dynamic Audio Normalizer is that the latter readjusts the gain factor over time, so "quiet" sections of the track can get a stronger amplification than "loud" sections. In a certain way, this also is a dynamic range compression, yes. But within each section the full dynamic range is retained. And if your input file already contains peaks of maximum signal level in regular intervals, it will be passed trough unmodified.

It's probably better to think of this as harmonizing the volume of the "quiet" and "loud" sections of the file. And if that isn't desired, then the Dynamic Audio Normalizer is not the proper tool for whatever you are trying to achieve :)

Compressing the audio the traditional way and "compressing it" by increasing the volume of the quiet parts are both susceptible to the same "pumping" problem, where you can hear the volume of background sounds going up and down.

This would be the case, if we simply calculated the maximum possible gain factor for each frame and then applied that gain factor to the frame - which would result in strong and unsteady gain fluctuations. The Dynamic Audio Normalizer mostly avoids the "pumping" problem by looking at a certain neighborhood around each frame rather than individual frames. Think of it like a sliding window approach. First, a minimum filter is applied, which is pretty effective in filtering out short-term gain variations. Secondly, a Gaussian smoothing kernel is applied, which ensures the remaining gain changes are smooth and steady. If you still get noticeable "pumping" after all, you should probably try a larger window size...

Is it safe to run ?

Safe? In regard to what?

tebasuna51

5th August 2014, 07:48

...
It's probably better to think of this as harmonizing the volume of the "quiet" and "loud" sections of the file. And if that isn't desired, then the Dynamic Audio Normalizer is not the proper tool for whatever you are trying to achieve :)
...

I read your full explanation in https://github.com/lordmulder/DynamicAudioNormalizer#chap_cfg and I really apreciate your method to harmonize the loudness.

I don't want to be critic, but if the user question "Is it safe to run?" want say "Is it safe to run always?", I think than is recommended when the track is bad recording or the user want this effect, but many artists (Alan Parsons, Bob Dylan, ...) want your songs with quiet and loud parts like was recorded.

But maybe is better than the user answer your question:

Safe? In regard to what?

LoRd_MuldeR

5th August 2014, 12:02

I don't want to be critic, but if the user question "Is it safe to run?" want say "Is it safe to run always?"

Well, I am confident it is "safe" to always use it, in the sense that it won't screw up your audio.

But is the effect always desired/advisable? Probably not :scared:

hello_hello

5th August 2014, 12:39

This would be the case, if we simply calculated the maximum possible gain factor for each frame and then applied that gain factor to the frame - which would result in strong and unsteady gain fluctuations. The Dynamic Audio Normalizer mostly avoids the "pumping" problem by looking at a certain neighborhood around each frame rather than individual frames. Think of it like a sliding window approach. First, a minimum filter is applied, which is pretty effective in filtering out short-term gain variations. Secondly, a Gaussian smoothing kernel is applied, which ensures the remaining gain changes are smooth and steady. If you still get noticeable "pumping" after all, you should probably try a larger window size...

I'm no expert on this, but isn't there always some sort of compromise between reducing the "pumping" effect, and the amount of time over which the volume is adjusted, in respect to how much you can "compress"?

I've had a brief play with the DynamicAudioNormalizer (this isn't a criticism as it seems to work well) but the default frame length of 500ms seems too large to me. At least for "soundtrack" audio.

So I had a look at my RockSteady settings and it's RSM window (which I guess is it's name for "frame length") defaults to 75ms, so I added --frame-len 75 to the commandline along with --gauss-size 11 and so far I much prefer the result, at least for stereo "soundtrack" audio. For example, when going from a loud peak to relative silence with dialogue, the default settings take too long to increase the level of the dialogue for me, whereas with the smaller frame length the dialogue seemed to commence with full amplification. Admittedly if you listen closely the really quiet background stuff behind dialogue is on the verge of "pumping" at times, but it still sounds good to me. And it's definitely better than my TV's "night mode" which does cause audible "pumping".

Anyway, each to their own.... thanks for quite a nice audio utility.

hydra3333

5th August 2014, 12:51

Yes, thanks for the program.
Safe? In regard to what?
Well, it didn't seem to have a mention here, so it seemed possible someone could have been trading on your name and passing off ad-ridden (or worse) software ...

manolito

5th August 2014, 21:41

Sorry, but could not test the software... The Guru strikes again. :angry:

F:\Download\DynAudNorm.2014-08-03.Windows-DLL>DynamicAudioNormalizerCLI.exe -i "
i:\test.wav" -o "i:\norm.wav"
---------------------------------------------------------------------------
Dynamic Audio Normalizer, Version 2.02-0, Shared
Copyright (c) 2014 LoRd_MuldeR <mulder2@gmx.de>. Some rights reserved.
Built on Aug 3 2014 at 19:15:00 with MSVC 2013.2 for Win-x86.

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License <http://www.gnu.org/>.
Note that this program is distributed with ABSOLUTELY NO WARRANTY.
---------------------------------------------------------------------------

Using libsndfile-1.0.25, by Erik de Castro Lopo <erikd@mega-nerd.com>.

GURU MEDITATION: Unhandeled structured exception error!

Looks like SSE2 is required. The static version has the same behavior.

Cheers
manolito

LoRd_MuldeR

6th August 2014, 00:38

I'm no expert on this, but isn't there always some sort of compromise between reducing the "pumping" effect, and the amount of time over which the volume is adjusted?

That's pretty much the trade-off that is controlled by the filter length parameter. And since the filter length is expressed in frames, changing the frame size has a similar effect.

I've had a brief play with the DynamicAudioNormalizer (this isn't a criticism as it seems to work well) but the default frame length of 500ms seems too large to me. At least for "soundtrack" audio.

So I had a look at my RockSteady settings and it's RSM window (which I guess is it's name for "frame length") defaults to 75ms, so I added --frame-len 75 to the commandline along with --gauss-size 11 and so far I much prefer the result, at least for stereo "soundtrack" audio. For example, when going from a loud peak to relative silence with dialogue, the default settings take too long to increase the level of the dialogue for me, whereas with the smaller frame length the dialogue seemed to commence with full amplification. Admittedly if you listen closely the really quiet background stuff behind dialogue is on the verge of "pumping" at times, but it still sounds good to me. And it's definitely better than my TV's "night mode" which does cause audible "pumping".

There is no sophisticated justification for the default filter length of 31 and the default frame length of 500 ms. It's just what seemed to work reasonably well in my tests ;)

Depending on what kind of input you are dealing with and on what you are trying to achieve, you may need to adjust the defaults.

You may also want to check out the "maximum gain" setting. With the proper limit, you can allow just enough gain to get sufficient volume in "dialogue" sections, but avoid a further volume in crease in really "quite" sections.

Looks like SSE2 is required. The static version has the same behavior.

Yes, the pre-compiled binaries were made with SSE2 enabled.

This is 2014. SSE2 has been supported by mainstream processors since ~2000. Also SSE and SSE2 have been adopted as "core" instructions in all x64 processors.

Last but not least, current compilers have moved on to always enable SSE/SSE2 instructions, even for 32-Bit, unless those are explicitly disabled...

So I hope you understand that it's about time to have SSE2 enabled in the "standard" builds. If you need to run this on legacy hardware, you'll need to make your own build.

(But be aware that all the "external" libraries, such as libsndfile, libvorbis and libFLAC would have to be recompiled as well)

manolito

6th August 2014, 19:11

Today I had some time to test the software with a variety of CD tracks with different characteristics. I only used the defaults, and I must say that I am very impresssed how musical and artifact-free the results were. Even with critical sources I was unable to detect any pumping. And the dynamic characteristics were preserved nicely, while the quieter parts became much more present than in the original.

The effect might not be strong enough when listening to movie soundtracks at a very low listening volume like hello_hello already pointed out, but IMO the defaults are perfect for "real" music. I was particularly impressed how a rather quiet Jazz track with a very high dynamic range came out (I cover the waterfront by Joy Denalane). I consider this software a winner.

Maybe future versions could come with a couple of presets to cover different needs... ;)

Any plans to integrate it into LameXP?
Does the software support STDIN and STDOUT so it can be used with pipes?

Cheers
manolito

LoRd_MuldeR

7th August 2014, 00:07

Any plans to integrate it into LameXP?

Probably yes.

Does the software support STDIN and STDOUT so it can be used with pipes?

Not yet. Currently all I/O is handled by libsndfile internally.

This would not only require to by-pass libsndfile, but also additional options to specify the sample format and the number of channels would have to be added.

Maybe in some future version ;)

LoRd_MuldeR

8th August 2014, 22:48

Here is a new Test version that features support for "raw" audio data, including reading from the STDIN and writing to the STDOUT. See included manual for details!
http://sourceforge.net/projects/muldersoft/files/Dynamic%20Audio%20Normalizer/Testing/

I have also implemented a new optional RMS-based normalization mode for volume adjustment. It can be enabled with the "--target-rms" switch.

manolito

9th August 2014, 16:38

LoRd_MuldeR

10th August 2014, 01:09

Sorry, the NON-SSE test version is not working here. It does work when calling it without any parameters or with the -h parameter. But as soon as I want to convert a file, the GURU starts meditating again...

Note quite sure. I think I did the same thing as for the previous "No SSE" build, i.e. I recompiled libsndfile and the program itself with SEE/SSE2 explicitly disabled :confused:

Did you happen to use FLAC or Vorbis as input or output? This could be a problem, since I was too lazy to recompile those libs as well ;)

Anyway, since I already reverted the changes that I did for the last "No SSE" build and also cleaned-up the intermediate files, we will never know. So here is a new attempt:

http://sourceforge.net/projects/muldersoft/files/Dynamic%20Audio%20Normalizer/Testing/DynamicAudioNormalizer-TEST.2014-08-10.Win32-NoSSE.zip/download

manolito

10th August 2014, 16:41

My input file was a regular PCM Wave file ripped from an Audio CD. Looks like libsndfile still needed SSE2.

Whatever, the latest version works nicely... :D

Still I am a little confused about the new RMS parameter. I converted several files of the more quiet kind, using the default parameters first, then adding -r 1, and at last using -r 0. Every time the three resulting files were bit identical. Did I do something wrong? :confused:

Another question:
When I process a file which starts rather quiet and stays quiet for about a minute, then gets louder, the processed file (default parameters) will also start quiet, but after about 8 seconds the gain increases. Is there a way to make the processed file start with the increased gain without destroying the dynamics? Reducing the gauss window size does not help. I guess that only a 2-pass approach could solve this.

Cheers
manolito

LoRd_MuldeR

10th August 2014, 18:20

Whatever, the latest version works nicely... :D

Good to know.

Still I am a little confused about the new RMS parameter. I converted several files of the more quiet kind, using the default parameters first, then adding -r 1, and at last using -r 0. Every time the three resulting files were bit identical. Did I do something wrong? :confused:

A value of zero is the default (if you don't use "--target-rms") and it has a special meaning: It simply disables the RMS processing.

What would a target RMS of zero mean anyway? Only 100% silent audio could have such RMS.

Furthermore, a target RMS value of 1.0 is too high. All samples would have to be at 0 dBFS (maximum possible sample value) to reach such RMS value, i.e. you'd need a 100% constant signal level.

For a "real" audio signal, with varying signal levels, try something like "--target-rms 0.2". And keep in mind "--target-rms" can only result in lower gain values, compared to not using "--target-rms".

When I process a file which starts rather quiet and stays quiet for about a minute, then gets louder, the processed file (default parameters) will also start quiet, but after about 8 seconds the gain increases. Is there a way to make the processed file start with the increased gain without destroying the dynamics? Reducing the gauss window size does not help. I guess that only a 2-pass approach could solve this.

The "gauss window" takes into account a certain number of frames before and after the current frame.

Naturally, at the very beginning of the file we have no preceding frames. And at the very end of the file we have no subsequent frames. So what gain factors should we assume for those "missing" frames outside the file?

Currently, by default, a gain factor of 1.0 is assumed. This results in a smooth "fade in" and "fade out". It also avoids that we start/end with very strong amplification, if the the file starts/ends with silence - as is the case with many files.

However, you can use "--alt-boundary" to enable the alternative boundary mode. This will assume the "missing" frames at the beginning/end have the same gain as the very first/last frame in the file...

manolito

10th August 2014, 20:29

LoRd_MuldeR

10th August 2014, 22:48

Alright, thanks for the explanation how --target-rms works. I made some more tests, but or the specific source file I used the parameter range is too coarse.

For a value of 0.2 the output is almost identical to the source file, and for a value of 0.3 the output is very similar to the default peak mode. A value of 0.5 makes for a result which is almost identical to peak mode.

Keep in mind that without "--target-rms", the gain factor for each frame is already is the maximum possible gain factor (without clipping).

Consequently, by adding the "--target-rms" switch, the gain factors cannot become even higher. They can only become smaller.

This means that you will need to specify a target RMS value that leaves enough room for the normalizer to work.

With a target value of 0.5, most frames probably have a much smaller RMS than the target RMS, but it's simply not possible to amplify these frames enough to reach that target RMS.

As a result, you will be running into the maximum peak limit all the time. And then, of course, the output is the same that you would have gotten without "--target-rms" ;)

For the other problem the --alt-boundary mode does not help at all. Maybe files with such properties (starting quiet and staying quiet for some time) require a special treatment. Like determining the peaks for the first few seconds first and applying the required gain factor right from the start of the file.

Your "Original.wav" file doesn't contain much volume variation to begin with:
http://i.imgur.com/NefTxvQ.png

The only thing noteworthy is that very short but huge peak (much higher than all the rest of the file!) in the left channel at the very beginning of the file:
http://i.imgur.com/cFEu9Dh.png

As expected with such input that has almost no volume variation, the resulting gain factors are constant as well – more or less:
http://i.imgur.com/ib7gI2K.png

Note that the "fade in" and "fade out" effect that we see towards the beginning and the end of the file are expected with the standard boundary mode. That's because we start off (and also end up) with a gain factor of exactly 1.0.

The alternative boundary mode changes the behavior at the beginning and at the end of the file. But with your specific file, the huge peak at the beginning prevents even higher gain factors there!

As a result, the beginning of the file looks pretty much the same with alternative boundary mode, but towards the end of the file the gain factors are now going up, because the original audio is fading out:
http://i.imgur.com/KuGmkJs.png

I'm not quite sure what else you have expected. But if we disable the channel coupling and only look at the right channel, which does not have such huge peak at the beginning, we get this:
http://i.imgur.com/Hx6YUXB.png

manolito

11th August 2014, 01:12

OK, so the --target-rms option is not for me. If I decide to use Dynamic Range Compression at all, then I want the resulting file to be LOUDER, not quieter than the source.

For the other issue you are absolutely right, the peak in the left channel at the beginning prevents the --alt-boundary mode to work. After I edited the original file removing this peak I did get a perfect result with the --alt-boundary option.

But I think that files like this are not too rare. Could the --alt-boundary mode be modified to ignore single peaks like the one in my original source file?

Cheers
manolito

LoRd_MuldeR

11th August 2014, 02:04

OK, so the --target-rms option is not for me. If I decide to use Dynamic Range Compression at all, then I want the resulting file to be LOUDER, not quieter than the source.

After all, this whole stuff is not some much about making the audio "louder" (or "quieter"), but more about harmonizing the volume.

The absolute volume should be controlled by the user, using the volume control of his speakers/amplifier.

If you want to increase the volume of the file beyond what a "smart" normalization filter can achieve, then you will need to apply a "real" compression.

For the other issue you are absolutely right, the peak in the left channel at the beginning prevents the --alt-boundary mode to work. After I edited the original file removing this peak I did get a perfect result with the --alt-boundary option.

But I think that files like this are not too rare. Could the --alt-boundary mode be modified to ignore single peaks like the one in my original source file?

Well, this has absolutely nothing do with "boundary" processing.

Regardless of where a frame is located: The maximum gain factor that can be applied to a certain frame, without clipping, is always defined by the frame's highest magnitude sample value.

So if we have a file with more or less constant volume, but there are a few frames with huge peaks now and then, we necessarily have to drop the gain factor around these "peak" frames in order to avoid distortions.

That's also the only way to preserve the "characteristics" of the original audio. Or how are we supposed to distinguish between "desirable" and "adverse" peaks? (*)

Only way to apply even stronger amplification (and still avoid clipping) would be cutting off all peaks above a certain threshold. And then we are on the territory of "real" compression once again...

(*) The closest thing to this is probably the "Click/Pop Elimination" filter that you find the the "Restoration" section of some audio editors. But regardless of how they do it, that's always a trade-off between "false positives" and "false negatives".

manolito

11th August 2014, 22:05

After all, this whole stuff is not some much about making the audio "louder" (or "quieter"), but more about harmonizing the volume.

Well, I do not really agree. Your software does compress the dynamic range (in my tests using only default parameters the RMS value of my test tracks was raised between 2 and 5 dB). It sure works differently than "real" or traditional compressors, but it still does compress.

I also think that the term "Harmonizing" the volume is unfortunate. This term is already established and occupied in audio processing (do a search for "Harmonizer"), and a harmonizer does something very different from what your software does.

I got another thing to bug you... :devil:
I played a little bit with the new stdin / stdout feature, and it works well the way it is implemented. But I would like to have this feature enhanced to include the ability to accept formatted standard wave files for stdin where it would not be necessary to explicitly specify the input properties.

SoX and Aften can do this (for SoX you only need to specify the file type, e.g. wav), and it makes using pipes a lot easier.

I use a test template where Faad.exe (or Wavi.exe) provide a standard MS Wave file and send it to stdout. Then SoX takes over and does its thing sending the result to stdout again. At last Aften is used for the final encode.

faad.exe -b 1 -w test.aac | dynamicaudionormalizercli.exe -i - --input-bits 16 --input-chan 2 --input-rate 48000 -o - | aften.exe -b 224 -readtoeof 1 - test.ac3

Being able to skip the red part would make it much more versatile. Here is the SoX version:
faad.exe -b 1 -w test.aac | sox.exe --ignore-length -t wav - -t wav - %normalize% %samplerate% | aften.exe -b 224 -readtoeof 1 - test.ac3

Cheers
manolito

LoRd_MuldeR

13th August 2014, 17:49

Well, I do not really agree. Your software does compress the dynamic range (in my tests using only default parameters the RMS value of my test tracks was raised between 2 and 5 dB). It sure works differently than "real" or traditional compressors, but it still does compress.

Sure it does. But (hopefully) in a much more subtle way than a "standard" compressor.

Keep in mind that within a neighborhood of ±(frame_size/2) 100% of the dynamic range will be retained. Only if you have "quiet" and "loud" sections of a significant length each, the volume of these sections will be "harmonized" (it's the best word I know to describe it). At the same time, a "standard" compressor would significantly reduce the dynamic range within "loud" sections (by cutting off the peaks) and not modify "quiet" sections at all (since they probably remain below the threshold).

And again: Dynamic range compression doesn't making things "louder" overall - even though this may be the goal of the unaware user. Whether you make the "silent" sections louder or the "loud" sections quieter, the result is exactly the same: Less dynamic range. The former may appear "louder", as long as you keep the volume control of your speakers/amplifier at the same level, yes. But in the end, the listener is going to adjust the volume of the speakers/amplifier to get the desired overall volume. So if the audio was compressed in order to get a "louder" volume, it will end up at the same volume as before - only with significant less dynamic range now (which makes it sound more "flat").

I got another thing to bug you... :devil:
I played a little bit with the new stdin / stdout feature, and it works well the way it is implemented. But I would like to have this feature enhanced to include the ability to accept formatted standard wave files for stdin where it would not be necessary to explicitly specify the input properties.

SoX and Aften can do this (for SoX you only need to specify the file type, e.g. wav), and it makes using pipes a lot easier.

I use a test template where Faad.exe (or Wavi.exe) provide a standard MS Wave file and send it to stdout. Then SoX takes over and does its thing sending the result to stdout again. At last Aften is used for the final encode.

I currently have no plans to implement this for three reasons:

First of all, I hate reinventing the wheel. Especially when it comes to "necessary evils" like the I/O stuff, that isn't even related to the "core" functionality. So using libsndfile to handle all the I/O stuff for us is very slick. And it does a great job for reading from or writing to a wide range of file formats, while hiding all the nasty details from us. It naturally doesn't work well with pipes, because most file formats (including Wave!) simply are not designed for this scenario. By adding the "raw" I/O stuff alongside libsndfile, in order to allow pipelining, things have already become more obscure/complex than I like. Rather than making the I/O code even more complex, I'd prefer simplifying it.

Secondly, sending "fake" RIFF/Wave headers over the pipe is absolutely non-standard and error-prone, even if it does work with certain tools. Having to parse a RIFF/Wave headers is also unnecessarily complex and cumbersome for this purpose. After all, we simply need to signal the sample format, sampling rate and channel count. So if there was a proper and widely-accepted YUV4MPEG equivalent for audio, I'd consider implementing it.

Finally, the "core" library of the Dynamic Audio Normalizer is completely independent from any input/output formats. The CLI font-end is more or less an "example" application that shows how to use the library and that allows for testing the library. Rather than adding more and more functionality to the CLI front-end, it would probably make more sense to simply ingrate the "core" library as a filter into FFmpeg or SoX or whatever your favorite audio processor is...

manolito

17th August 2014, 17:03

Just noticed that you have removed the non-SSE2 builds from the Sourceforge testing folder.
Any chance for a non-SSE2 build of the current stable version 2.03?

Cheers
manolito

LoRd_MuldeR

17th August 2014, 17:52

Just noticed that you have removed the non-SSE2 builds from the Sourceforge testing folder.
Any chance for a non-SSE2 build of the current stable version 2.03?

Yeah, I clean up the previous test builds after v2.03 release. Anyway, you've got mail ;)

manolito

17th August 2014, 18:50

Thanks a lot, much appreciated... :D

Cheers
manolito

manolito

18th August 2014, 03:11

Alright, I played with this new version for a couple of hours, and I am finally very happy with it... :D

Still I have a few remarks and questions:

I am still a little confused about the STDIN / STDOUT feature. The command line help mentions the --raw-input and --raw-output parameters, but these parameters are not present in the Readme. As I understand it so far, the STDIN input is always treated as raw (so I have to specify the input file properties), what is different when I use the --raw-input parameter additionally?

And for STDOUT I was under the impression that the output will also be raw using the same properties as for the input. False assumption? Because when I feed a 6-ch input to Aften over STDOUT Aften always sees its input as 2-ch or even mono. Aften has no problem recognizing the correct format when feeding it with the STDOUT from FAAD, Wavi or SoX.

Anyways, I got it working for my needs, that's all I want.

I also noticed a small (purely cosmetic) bug. If I use STDIN for my input and a normal WAV file as the output, the console window still tells me that I am using STDIN and STDOUT.

The thing I am currently working on is integrating DynamicAudioNormalizer into a plugin I made for AVStoDVD. By default it uses Wavi -> Aften with piping, and I intercept the process and add SoX or DynamicAudioNormalizer into the chain. Additionally I want to be able to use large 6-ch audio files without being stopped by the 4GB limit.

This works nicely with SoX and Aften as they happily accept non-standard oversized WAV files (using --ignore-length for SoX and -readtoeof 1 for Aften). DynamicAudioNormalizer was not that easy...

Using an oversized WAV file as input did not work, the file was truncated to 4GB. Trying to use STDIN /STDOUT did not work for Aften since it could not detect the correct channel number. By trial and error I finally found the solution:

Use STDIN as the input, but as the output use a normal WAV file. DynamicAudioNormalizer will write an oversized non-standard WAV file which Aften recognizes correctly. Bingo!

This brings me to my last question:
I want to publish my AVStoDVD plugin soon, and since AVStoDVD itself does not require a SSE2 capable CPU I really do not want to change the hardware requirements for the software. OTOH I know that you do not want to spread the Non-SSE2 versions you compliled for me. So how do I go about this?

Would you consider to permit the distribution of Non-SSE2 builds together with the plugin? Or would you prefer that I only distribute the official builds, maybe with a note that for ancient CPUs the user should contact me (or you) for a Non-SSE2 build?

Anyways, thank you so much for this tool,

Cheers
manolito

Brazil2

18th August 2014, 12:50

LoRd_MuldeR

18th August 2014, 13:46

I am still a little confused about the STDIN / STDOUT feature. The command line help mentions the --raw-input and --raw-output parameters, but these parameters are not present in the Readme. As I understand it so far, the STDIN input is always treated as raw (so I have to specify the input file properties), what is different when I use the --raw-input parameter additionally?

Reading from the STDIN or writing to the STDOUT implies using "--raw-input" or "--raw-output", respectively. So, in this case, you don't need to specify these flags manually.

You still may wish to specify them explicitly when reading from or writing to a file containing "raw" PCM data.

And for STDOUT I was under the impression that the output will also be raw using the same properties as for the input. False assumption? Because when I feed a 6-ch input to Aften over STDOUT Aften always sees its input as 2-ch or even mono. Aften has no problem recognizing the correct format when feeding it with the STDOUT from FAAD, Wavi or SoX.

As far as the Dynamic Audio Normalizer is concerned, the output format will be chosen as closely to the input format as possible.

Note, however, that not all file formats support all sample formats. Furthermore, when "raw" output is used, only 8-Bit Signed Integer, 16-Bit Signed Integer and 32-Bit Float are currently supported.

I also noticed a small (purely cosmetic) bug. If I use STDIN for my input and a normal WAV file as the output, the console window still tells me that I am using STDIN and STDOUT.

Should be fixed now:
https://github.com/lordmulder/DynamicAudioNormalizer/commit/543d01334b50581fb3425bba04761508ebbeb930

The thing I am currently working on is integrating DynamicAudioNormalizer into a plugin I made for AVStoDVD. By default it uses Wavi -> Aften with piping, and I intercept the process and add SoX or DynamicAudioNormalizer into the chain. Additionally I want to be able to use large 6-ch audio files without being stopped by the 4GB limit.

This works nicely with SoX and Aften as they happily accept non-standard oversized WAV files (using --ignore-length for SoX and -readtoeof 1 for Aften). DynamicAudioNormalizer was not that easy...

Using an oversized WAV file as input did not work, the file was truncated to 4GB. Trying to use STDIN /STDOUT did not work for Aften since it could not detect the correct channel number. By trial and error I finally found the solution:

Use STDIN as the input, but as the output use a normal WAV file. DynamicAudioNormalizer will write an oversized non-standard WAV file which Aften recognizes correctly. Bingo!

This kind of stuff would become much easier and cleaner, if we simply integrated the Dynamic Audio Normalizer library into something like SoX/FFmpeg.

Maybe I will look into this one day ;)

Would you consider to permit the distribution of Non-SSE2 builds together with the plugin? Or would you prefer that I only distribute the official builds, maybe with a note that for ancient CPUs the user should contact me (or you) for a Non-SSE2 build?

The software is released under licenses that explicitly allow redistribution (LGPL v2.1 for the library, GPL v2 for the CLI and GPL v3 for the GUI), so no additional permission is required :)

Why don't you want to make it public ? :confused:
It might be helpfull for many people ;)

Sorry, I have come to the conclusion that I don't want to "officially" support Non-SSE2 builds anymore. Even the build I sent to manolito isn't "100% safe" to run on CPU's without SSE/SSE2 support, since we use various third-party libraries and I didn't bother with re-compiling those too. Honestly, SSE2 has been supported by CPU's since year 2000 when the Pentium 4 came out. That was 14 years ago! Since then, SSE2 has been adopted as "core" instructions into all 64-Bit processors. According to a recent hardware survey (http://store.steampowered.com/hwsurvey), 99.96% of all systems support SSE2 these days. Is the extra effort worth it for the remaining 0.04%? Microsoft obviously thinks it is not. At least they require SSE2 (http://windows.microsoft.com/en-US/windows-8/what-is-pae-nx-sse2) for installing recent Windows versions now...

(If people take it as a "challenge" to get recent software running on their legacy hardware, I'm perfectly fine with that. But then I assume these kind of people know how to compile software themselves ^^)

manolito

18th August 2014, 16:55

Why don't you want to make it public ? :confused:
It might be helpfull for many people ;)

I found a table which shows the CPUs supporting SSE2 and those which do not here:
http://www.palemoon.org/technical.shtml#CPUsupport

I suppose that some of these "ancient" CPUs are still being used... :(

Sorry, I have come to the conclusion that I don't want to "officially" support Non-SSE2 builds anymore.

Is this true for all of your software? Should I "freeze" the current version of LameXP?

Cheers
manolito

rbauer

19th August 2014, 17:35

LoRd_MuldeR

19th August 2014, 18:10

Hi.
It would be useful for this case scenario (5.1 converted to 2.0 movies in order to hear dialogues)?
http://forum.doom9.org/showthread.php?p=1637275#post1637275

I think so. Note, however, that if the dialogues are rather "short", sourrounded by "loud" scenes, you may need to reduce the "--gauss-size" parameter a bit.

And if the dialogues are only on some channels while, at the same time, the other channels have "loud" environement noise, using "--no-coupling" may be needed.

Is this true for all of your software? Should I "freeze" the current version of LameXP?

At some point, certainly. This will simplify quite a few things (until AVX comes around ^^).

In the next version? Not decided yet...

rbauer

19th August 2014, 20:55

I think so. Note, however, that if the dialogues are rather "short", sourrounded by "loud" scenes, you may need to reduce the "--gauss-size" parameter a bit.

And if the dialogues are only on some channels while, at the same time, the other channels have "loud" environement noise, using "--no-coupling" may be needed.

Sorry LoRd_MuldeR, I'm an audio noob :o : could you please give an example of command line about this case scenario (my previous post)?

- Original audio track from DVD/Blu-Ray movie (e.g. action movies), DTS/AC3 format/5.1ch (Its dialogue's volume is very low and overpowered from music/background effects when played on 2.0ch tv/audio equipment).

- Destination audio track (after conversion): .wav format (or .aac, etc.) with 2ch and clear dialogue's audio (while the music and explosions remain a background effect and don't overpower dialogues).

Many thanks

LoRd_MuldeR

19th August 2014, 22:21

Sorry LoRd_MuldeR, I'm an audio noob :o : could you please give an example of command line about this case scenario (my previous post)?

Have you looked at the manual? :confused:
http://muldersoft.com/docs/dyauno_readme.html#chap_cli

foxyshadis

19th August 2014, 23:34

Since you mention "compression" and "loudness war" I just want to clarify that the Dynamic Audio Normalizer doesn't quite work like a compressor. The compressor first "flattens" the signal peaks (by reducing all samples above a predefined threshold), which results in a certain headroom, and then applies a fixed gain in order to bring the signal to the maximum level again. The results in a much "louder" signal, but the peaks are gone for good. The dynamic range has been reduced significantly.

You might be thinking of a limiter, which only reduces peaks.

Sure it does. But (hopefully) in a much more subtle way than a "standard" compressor.

Keep in mind that within a neighborhood of ±(frame_size/2) 100% of the dynamic range will be retained. Only if you have "quiet" and "loud" sections of a significant length each, the volume of these sections will be "harmonized" (it's the best word I know to describe it). At the same time, a "standard" compressor would significantly reduce the dynamic range within "loud" sections (by cutting off the peaks) and not modify "quiet" sections at all (since they probably remain below the threshold).

And again: Dynamic range compression doesn't making things "louder" overall - even though this may be the goal of the unaware user. Whether you make the "silent" sections louder or the "loud" sections quieter, the result is exactly the same: Less dynamic range. The former may appear "louder", as long as you keep the volume control of your speakers/amplifier at the same level, yes. But in the end, the listener is going to adjust the volume of the speakers/amplifier to get the desired overall volume. So if the audio was compressed in order to get a "louder" volume, it will end up at the same volume as before - only with significant less dynamic range now (which makes it sound more "flat").

Sounds like a compressor; the definition of one is just the normalizing part, raising the low and reducing the high around a certain inflection point, though it can do just one or the other. It works very similar to the curves filter in an image editor. The other main difference with a limiter is the shorter window size, though in modern implementations a limiter is just a preset of a widely configurable compressor. Often a limiter is run on top of a compressor to allow extra gain but prevent the "pumping" that you get if you try to squeeze too hard with a long window.

Gain beyond is usually applied before compression/limiting, not necessarily -- but I've always seen it at least included with every compressor, since so many people want it. The primary reason for applying extra gain with compression is to override environmental noise, which overpowers quiet parts, that's the whole point of AC3's "daytime" compression. Crappy digital compressors usually only support straight gain, but advanced ones support curved gain and even separate gain/compression by frequency band.

A harmonizer, on the other hand, creates a chorus effect. Definitely not something you want to imply you do (though it'd be fun to hear a movie that way :p).

I guess the best way to describe this is as a very limited compressor; it doesn't work quite like a classical compressor, having a very long window (more non-linear behavior and more skipped valleys), and with no limiting protection can't have gain beyond a peak at 1.0, but the results are still similar to a compressor configured similarly. Compressors in audio tools are flexible enough to emulate this, but I really think adding a limiter would be important to prevent pumping around isolated peaks.

LoRd_MuldeR

20th August 2014, 01:03

You might be thinking of a limiter, which only reduces peaks.

Well, both, a "traditional" limiter and compressor, will prune the peaks. The major difference is that the limiter will simply cut off all values above a certain threshold, while the compressor reduces the values above the threshold by a certain ratio. So, in the end, both reduce the dynamic range. The Dynamic Audio Normalizer does nothing like that. Yes, it still performs a certain kind of "dynamic range compression" - but only if we regard the complete file over the whole time. Within each "local neighborhood" 100% of the dynamic range is always retained. The "traditional" limiter or compressor does not, since it prunes the peaks in the "loud" parts of the file (i.e. everywhere where the selected threshold is exceeded).

http://i.imgur.com/S1hcDMP.png

Compressors in audio tools are flexible enough to emulate this, but I really think adding a limiter would be important to prevent pumping around isolated peaks.

I think if the original audio contains isolated peaks, we usually want to retain those peaks. This clip (https://www.youtube.com/watch?v=3Gmex_4hreQ) illustrates quite well what happens if isolated peaks, like drum beats, are compressed way. The Dynamic Audio Compressor uses a large lookahead buffer combined with a smoothing filter, so we can reduce the gain early and smoothly around the peak, which means we can retain the peak without distortions (clipping) and still keep noticeable "pumping" at a minimum. If there isn't a significant "grap" between those peaks, the gain will not even be increased at all between the peaks. Nonetheless, the next version contains an optional compression filter that can be combined with the current approach.

manolito

20th August 2014, 02:40

If you want to use "real" compression, then I agree with hello_hello that you probably should do this in the playback chain and not alter your audio source permanently and irreversibly.

The approach of DynamicAudioNormalizer allows for applying its "harmonizing the volume" without doing audible damage to the source dynamics. It does bring up quiet parts, but not at the cost of destroying the original dynamic characteristics of the source. And (with the defaut parameters) it is "musical", all the artifacts associated with traditional compressors are absent. I used it on many CD tracks and on a couple of movie conversions, and the results always sounded good.

Treatment of peaks is a whole different matter. I was a recording studio owner and audio engineer in the good old (almost) analog times in the 80s of the last century, and I was able to follow the development when music became more and more digital.

It used to be that real high peaks mostly resulted from percussive instruments. Good condenser mikes with their lightweight diaphragm could catch these peaks easily, but the rest of the chain had difficulties handling these peaks. It started with the mike preamp of the console (a lot of engineers used separate external tube preamps), and most importantly a normal dynamic speaker could not reproduce these peaks. But everything was analog at these times, the peaks were just flattened out without much audible clipping, and the call for maximum loudness was not that loud at these times.

All this changed when synthesizers took over. Suddenly the input signals containend "pathological" peaks which did not contribute to the percieved loudness at all, but they did overdrive op-amps in the console and caused audible distortion. Reducing these peaks was essential to achieve a reasonably "loud" mix. And since the whole chain was now digital and there was no good-sounding analog clipping any more it was essential to employ good sounding brickwall limiters in the chain.

So for treating peaks in a musical way you have to determine first if these peaks are "musical" or if they are "artificial" and unwanted. I do not believe that this can be determined automatically, this still takes ears.

Cheers
manolito

LoRd_MuldeR

24th August 2014, 22:11

FWIW, I have finished SoX integration today:
https://github.com/lordmulder/DynamicAudioNormalizer/releases/tag/2.04

You can now do something like this:
SoX.exe -S "in_original.wav" -o "out_normalized.wav" dynaudnorm

LoRd_MuldeR

27th August 2014, 00:15

FWIW, we also have a VST plug-in now:
http://sourceforge.net/projects/muldersoft/files/Dynamic%20Audio%20Normalizer/Testing/DynamicAudioNormalizer.2014-08-26.VST-Plugin.zip/download

Seems to work fine in Audition and GoldWave. However, Audacity and Wavosaur seems to ignore the "initial delay" value, so the whole audio gets shifted. Not sure if this is a bug in Audacity or on my side ;)

At the moment, options can not be controlled by the user yet...

LoRd_MuldeR

5th September 2014, 22:15

Here's a new TEST version with a much improved VST wrapper:
http://sourceforge.net/projects/muldersoft/files/Dynamic%20Audio%20Normalizer/Testing/DynamicAudioNormalizer-TEST.2014-09-05.Static.zip/download

Settings can now be configured in the GUI:
https://raw.githubusercontent.com/lordmulder/DynamicAudioNormalizer/master/img/VSTPlugInConf.png

rbauer

6th September 2014, 07:10

Right, I'm doing something wrong :( (about audio dialogues boost)

Please, could you give me some hints?

movie.mkv (audio track inside is ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s).

my command line:

c:\>ffmpeg.exe -i "movie.mkv" -map 0:a:0 -f wav -acodec pcm_f32le - | DynamicAudioNormalizerCLI.exe -i - --gauss-size 21 --nocoupling -o "normalized.wav"

error:

Stream mapping:
Stream #0:1 -> #0:0 (ac3 (native) -> pcm_f32le (native))
Could not write header for output file #0 (incorrect codec parameters ?): Error number -22 occurred

Thanks

LoRd_MuldeR

6th September 2014, 13:36

You need to configure FFmpeg to output "raw" PCM data, not a "fake" WAVE header.

Also, if you use input from STDIN with the CLI front-end application, you need to specify the bit depths, channel count and sample rate explicitly!

So try something like (please edit bit depths, channel count and sample rate as needed):
ffmpeg.exe -i "movie.mkv" -vn -f s16le -c:a pcm_s16le - | DynamicAudioNormalizerCLI.exe -i - --input-bits 16 --input-chan 2 --input-rate 48000 --gauss-size 21 --nocoupling -o "normalized.wav"

You could also try with SoX, which can deal with "fake" WAVE headers:
ffmpeg.exe -i "movie.mkv" -vn -f wav -c:a pcm_s16le - | sox.exe --ignore-length -t wav - "normalized.wav" dynaudnorm

LoRd_MuldeR

21st January 2015, 22:30

Dynamic Audio Normalizer v2.08
https://github.com/lordmulder/DynamicAudioNormalizer/releases/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 (https://connect.microsoft.com/VisualStudio/feedback/details/987093/x64-log-function-uses-vpsrlq-avx-instruction-without-regard-to-operating-system-so-it-crashes-on-vista-x64) in the Microsoft Visual C++ 2013 runtime libraries
• Makefile: Various improvements

Selur

21st January 2015, 22:43

FWIW, I have finished SoX integration today:
Will this integration also be part of the official sox repository?

LoRd_MuldeR

21st January 2015, 23:13

Will this integration also be part of the official sox repository?

At least I haven't made any efforts into that direction (yet). So you'd have to ask the SoX team ;)

Anyway, SoX development doesn't seem to be very active these days. Last release was February 1, 2013, and only a couple of smaller fixes have been done since then.

manolito

7th July 2015, 12:50

While toying around with different bit depths of the intermediate WAV file I noticed that the stdin interface of DynamicAudioNormalizer seems to be restricted to 16bit int samples.

I still use the older version 2.04-2 (does not require SSE2), and I absolutely cannot use the normal file input because files >4GB will be truncated.

When I feed a 32bit float WAV to DynamicAudioNormalizer via stdin all I get is an error message (could not parse...). Using 24bit int input the normalizing proceeds without errors, but the result is just loud static noise.

Is this the expected behavior? Or do later versions handle 24bit and 32bit input via stdin correctly?

Cheers
manolito

//EDIT//
Sorry I was wrong about 32bit float input. This format works fine, but 24bit int is definitely broken.

LoRd_MuldeR

7th July 2015, 20:20

Nothing in the Audio I/O class has changed after the v2.04 release. Also 24-Bit "raw" audio seems to works flawlessly for me:

http://i.imgur.com/E2DOxbWs.jpg (http://i.imgur.com/E2DOxbW.jpg)

BTW: Is your 24-Bit file LE or BE? And is it signed or unsigned? Please make sure that it is LE and signed, as libsndfile has no unsigned 24-Bit PCM type (appears to be very unusual) and the "native" endianness on x86 is LE!

manolito

7th July 2015, 21:53

The 24bit int source is signed LE.

http://i.imgur.com/Nrg6hAy.jpg

Haven't tried raw input yet because SoX and Aften have no problems with this format through stdin...

Cheers
manolito

LoRd_MuldeR

7th July 2015, 21:59

The 24bit int source is signed LE.

Please provide a sample then...

Haven't tried raw input yet because SoX and Aften have no problems with this format through stdin...

Not quite sure what you mean with this, because "raw" PCM is necessarily required, if you want DynAudNorm to read input from STDIN :confused:

manolito

7th July 2015, 22:28

Not quite sure what you mean with this, because "raw" PCM is necessarily required, if you want DynAudNorm to read input from STDIN :confused:

Now I am getting confused...

What do you mean by "raw" ? Samples without a WAV header?

This kind of "raw" is certainly NOT necessarily required for STDIN. I use Wavi as well as avs2pipemod, and both export streams WITH WAV headers by default. To get "raw" streams without headers you have to explicitly specify this.

From avs2pipemod:
-rawaudio[=8bit|16bit|24bit|32bit|float default unset]
output raw pcm audio(without any header) to stdout.
if optional arg is set, audio sample type of input will be converted to specified value.

From Wavi:
WAVI accepts the following options:
/R - Write a raw file of samples without the WAV header.

I do not see the need to provide a sample, it happens with each and every audio stream extracted by Wavi or avs2pipemod. It works for 16bit int and 32bit float, but not for 24bit int.

I will test 24bit int again with a headerless audio stream and report back...

Cheers
manolito