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

LoRd_MuldeR

7th July 2015, 22:54

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.

I was referring to DynAudNorm, not Wavi or avs2pipemod (or whatever). And DynAudNorm certainly does requires "raw" PCM, if you want to read from STDIN. Or, more precisely, it will assume that the input is "raw" PCM data in this case (i.e. libsndfile will be connected to the input pipe with SF_FORMAT_RAW flag). This is also the reason why "--input-bits", "--input-chan" as well as "--input-rate" have to be specified in this case, as those cannot be inferred from "raw" PCM data.

Of course you can still feed a Wave file into STDIN and pretend that it's "raw" PCM. The first few samples will be scrambled, because the preceding Wave header is interpreted like PCM data, but the rest of the file will probably decode fine ;)

(...provided that "--input-bits", "--input-chan" and "--input-rate" have been specified accordingly to the file's actual contents)

See also:
http://muldersoft.com/docs/dyauno_readme.html#command-line-usage-examples

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 have created a 24-Bit PCM file with ffmpeg (http://ffmpeg.zeranoe.com/builds/) using the following command:
ffmpeg.exe -i original.flac -f s24le -c:a pcm_s24le temp_s24le.pcm
And then I processed it with DynAudNorm like this:
DynamicAudioNormalizerCLI.exe -i - -o - --input-bits 24 --input-chan 2 --input-rate 44100 < temp_s24le.pcm > output_s24le.pcm

The result can be imported into Audacity and plays perfectly fine. So I cannot reproduce the problem. If you have a 24-Bit PCM stream that does not work, please provide a short chunk for testing...

manolito

8th July 2015, 10:26

Alright, sorry for the false alarm... :stupid:

Using STDIN with headerless input does work for all bit resolutions (using Wavi.exe /R).

I was just used to the behavior of all other audio software I know which does handle WAV headers in the input stream.

Cheers
manolito

LoRd_MuldeR

11th July 2015, 12:23

It seems somebody has ported Dynamic Audio Normalizer to plain C, for inclusion into libavfilter:
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-July/175331.html

Here is a quick test build I made, just "vanilla" FFmpeg, no external libraries or any optional stuff included:
(link expired)

ffmpeg.exe -i input.wav -af dynaudnorm output.wav

Brazil2

11th July 2015, 13:56

Dynamic Audio Normalizer
Although it would be nice to make DynAudNorm being able to run on XP just like MediaInfoXP does ;)

LoRd_MuldeR

11th July 2015, 15:19

Although it would be nice to make DynAudNorm being able to run on XP just like MediaInfoXP does ;)

Not that I care about an operating system that has many known security vulnerabilities, which are never going to be fixed (because the system reached "end of life" more than a year ago), and therefore is practically impossible to use nowadays. Still, I don't see any reason why DynamicAudioNormalizer (the "stand-alone" version) shouldn't work on Windows XP. I'm not so sure about SoX and FFmpeg, because these third-party projects probably don't care about obsolete legacy systems either...

Brazil2

11th July 2015, 16:28

Still, I don't see any reason why DynamicAudioNormalizer (the "stand-alone" version) shouldn't work on Windows XP.
It does the same thing as MediaInfoXP before you 'fixed' it: nothing happens, it doesn't run without any error message. Not even the CLI.

As described in this post:
Double clicking on MediaInfoXP.exe seems to do nothing. The GUI doesn't open.

LoRd_MuldeR

11th July 2015, 17:27

It does the same thing as MediaInfoXP before you 'fixed' it: nothing happens, it doesn't run without any error message. Not even the CLI.

The "problem" with MediaInfoXP was that, at a certain point, I used a specific Registry-related function (RegDeleteTree), which simply isn't available in Windows XP.

It's fixed now. And it's completely unrelated to DynamicAudioNormalizer. There is no registry code at all in DynamicAudioNormalizer.

DynamicAudioNormalizer is a CLI tool. You have to run it from the command-prompt, with the proper parameters. What happens if you run it from the command-prompt?

I just fired up my XP machine, just to be sure. But both, the "stand-alone" version and the SoX filter, as well as the Log Viewer appear to work fine for me:

http://i.imgur.com/fkyesH1l.png (http://i.imgur.com/fkyesH1.png)

http://i.imgur.com/Bbrmrjpl.png (http://i.imgur.com/Bbrmrjp.png)

http://i.imgur.com/vGrYs48l.png (http://i.imgur.com/vGrYs48.png)

Just to be sure: You have the latest Service Pack and all updates release till April 2014 installed, right?

And you have a CPU from this millennium, i.e with SSE support ?!

manolito

18th July 2015, 18:40

And you have a CPU from this millennium, i.e with SSE support ?!

SSE support is not enough, SSE2 support is required.

Cheers
manolito

hello_hello

18th July 2015, 21:25

Not that I care about an operating system that has many known security vulnerabilities, which are never going to be fixed (because the system reached "end of life" more than a year ago), and therefore is practically impossible to use nowadays.

I still use XP daily. Running on two PCs. Not an anti-virus program in sight. It hasn't been anywhere near Windows Update in at least two years. Aside from a few recent programs that I've had to stop updating, it's just as usable today as it was 10 years ago.

Still, I don't see any reason why DynamicAudioNormalizer (the "stand-alone" version) shouldn't work on Windows XP. I'm not so sure about SoX and FFmpeg, because these third-party projects probably don't care about obsolete legacy systems either...

Anyway, I really only posted to report the current version of MediaInfoXP runs as well on my XP computer as it's name might suggest it should, and despite not having used a software firewall or anti-malware software in years, DynamicAudioNormalizer works fine too. I tested the static and dll versions.

Thanks!

manolito

19th July 2015, 14:52

@ Brazil2,

FWIW I do have a non-SSE2 version of DynamicAudioNormalizer (version 2.04-2 static, compiled especially for me :) ). Let me know if I should upload it for you.

Another option is to use DynAudioNorm through SoX. The current version of LameXP contains a patched version of SoX which includes DynAudioNorm. After starting LameXP you can grab the SoX executable (lxp_sox.exe) from your temp folder. This SoX version does work without SSE2, and DynAudioNorm is integrated as a SoX filter.

Cheers
manolito

LoRd_MuldeR

20th July 2015, 18:51

Just for the notes, the FFmpeg patch has been officially committed a few days ago:
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=21436b95dc96e9cb2ae3f583f219349976ec1b7e

So you can simply grab an up-to-date FFmpeg now to use DynAudNorm. No custom modification needed. Find recent Windows builds here (http://ffmpeg.zeranoe.com/builds/).

ffmpeg.exe -i input.wav -af dynaudnorm output.wav

See also:
https://ffmpeg.org/ffmpeg-filters.html#dynaudnorm

pandy

20th July 2015, 22:11

Wantedwaffle

29th July 2015, 18:31

LoRd_MuldeR, thank you for the work you've put into this DynamicAudioNormalizer. I think it definitely has a place in my workflow. I've been experimenting with it for a bit, and I'm excited that it's been implemented into ffmpeg.

I'm just starting to tear my hair out trying to figure out how to set the options within ffmpeg. I only need to set the alternative boundary mode on, and the ffmpeg documentation has confused me more. Any help would be appreciated, thank you!

LoRd_MuldeR

30th July 2015, 21:35

The ffmpeg filter syntax can be a bit confusing. I think you need to do:
ffmpeg ... -vf dynaudnorm=<options> ...

Also the options themselves are in <key>=<value> format and, if multiple options need to be set, they are separated by colons:
ffmpeg ... -vf dynaudnorm=g=11:f=250 ...

richardpl

31st July 2015, 07:53

For the "alternative boundary mode" you probably just set the "b" option without an equals sign.

ffmpeg ... -af dynaudnorm=b=1 ...

LoRd_MuldeR

1st August 2015, 14:58

For the sake of testing, here is a fresh set of VS2015 and VS2013 builds:
http://sourceforge.net/projects/muldersoft/files/Dynamic%20Audio%20Normalizer/Testing/

LoRd_MuldeR

2nd August 2016, 22:53

After all, here is a new TEST version that fixes a problem with the "pre-filling" code, i.e. generation of the samples before the first "real" input sample:
https://sourceforge.net/projects/muldersoft/files/Dynamic%20Audio%20Normalizer/Testing/

The "old" code sometimes resulted in clipping at the very beginng of the audio file, especially when alterantive boundary mode was used. This should be fixed now (hopefully).

Old: http://i.imgur.com/Cb5HeqX.png
New: http://i.imgur.com/Vl6YEad.png

raffriff42

3rd August 2016, 21:28

The ffmpeg filter syntax can be a bit confusing. I think you need to do:
ffmpeg ... -vf dynaudnorm=<options> ... Here's a working example:-filter:a "dynaudnorm=f=100:p=0.71:m=20.0"* for an audio filter you call -af or -filter:a
* quotes around the filter string are required, it seems (https://ffmpeg.org/ffmpeg-all.html#Filtergraph-syntax-1)

pandy

5th August 2016, 15:36

I use something like: -af dynaudnorm=p=1/sqrt(2):m=100:s=12

CactusMan

12th October 2016, 20:44

Having trouble with ffmpeg using the filter dynaudionorm when the audio source is multi-channel.
Always downmixing to 2ch.

Wav extract from avi with 6ch ac3:
ffmpeg.exe -i %1 -vn -map 0:a:0 -acodec pcm_s16le -ac 2 -ar 44100 "%~n1.wav"
https://s22.postimg.org/4tv5axhdd/screenshot_1.png

The new wav converted with dynaudionorm exe:
DynamicAudioNormalizerCLI.exe -i "%%~nxZ" -o "%%~nZ.DynAudNorm10.wav"
https://s22.postimg.org/6a6nt2ka9/screenshot_2.png

Again, the new wav converted with ffmpeg using filter:
Same result...
ffmpeg.exe -i %1 -acodec pcm_s16le -af dynaudnorm "%~n1.dynaudnorm.wav"
https://s22.postimg.org/oe9odphyp/screenshot_3.png

When trying to extract from avi (ac3 6ch) with ffmpeg using filter:
Different result...
ffmpeg.exe -i %1 -vn -map 0:a:0 -acodec pcm_s16le -ac 2 -ar 44100 -af dynaudnorm "%~n1.wav"
https://s22.postimg.org/hcbqriecx/screenshot_4.png

I'm trying to do this with one pass process so I can feed via pipe to encode the result to a new mp3 or aac...

There is a way to handle properly those multi-channel audio with ffmpeg using the filter?

raffriff42

12th October 2016, 22:54

@CactusMan, what's -ac 2 doing in there if you don't want it downmixed ;)

CactusMan

12th October 2016, 23:04

@CactusMan, what's -ac 2 doing in there if you don't want it downmixed ;)

I Wrote: "Always downmixing to 2ch."
Just don't care about the quality of audio. Those will be temporary files.
So, it's best to work with 2ch.

raffriff42

13th October 2016, 02:08

CactusMan

13th October 2016, 05:18

OK I see what you mean. If I understand this, in the first case you downmix before applying dynaudnorm. In the 2nd case I think downmixing is happening afterwards.

To get a fair comparison, tryffmpeg.exe [...] -af "aformat=channel_layouts=stereo[A];[A]dynaudnorm" "%~n1.wav"

Thank you. Not the same result of dynaudnorm on the wav. But a lot better than my first try with ffmpeg and the filter.

AC3 donwmix with ffmpeg (no filter) to wav. (https://s21.postimg.org/ox6hlx493/screenshot_1.png)

That wav with dynaudionorm. Same result. (https://s21.postimg.org/9cz3vdu4n/screenshot_2.png)

That wav with ffmpeg with filter dynaudionorm. Same result. (https://s21.postimg.org/pchrexq6f/screenshot_3.png)

Ac3 downmix with ffmpeg and filter dynaudionorm. No good. (https://s21.postimg.org/iajtsqmkn/screenshot_4.png)
ffmpeg.exe -i %1 -vn -map 0:a:0 -acodec pcm_s16le -ac 2 -ar 44100 -af dynaudnorm "%~n1.v1.wav"

Your code. Different result. Looks like a little bit louder on some parts. (https://s21.postimg.org/5x6zltww7/screenshot_5.png)
ffmpeg.exe -i %1 -vn -map 0:a:0 -acodec pcm_s16le -ac 2 -ar 44100 -af "aformat=channel_layouts=stereo[A];[A]dynaudnorm" "%~n1.v2.wav"

I can live with that, quality is not the important factor in this case.
Just keep asking myself if there is a way to replicate the same results with filter on ffmpeg. :D:D:D
Dynamic Audio Normalizer and ffmpeg are incredible tools.

LoRd_MuldeR

29th January 2017, 21:32

Here is a new TEST version:

Version 2.10 (2017-01-??)
- CLI front-end: Added new CLI option -t to specify the desired output format
- CLI front-end: Added new CLI option -d to specify the desired input decoder library
- CLI front-end: Added support for decoding input files via libmpg123 library
- Windows binaries: Updated the included libsndfile version to 1.0.27 (2016-06-19)
- Windows binaries: Updated build environment to Visual Studio 2015 (MSVC 14.0)

Version 2.09 (2016-08-01)
- Core library: Improved pre-filling code in order to avoid possible clipping at the very beginning

Brazil2

30th January 2017, 14:21

Here is a new TEST version:

When I'm running DynamicAudioNormalizerGUI.exe it's asking me for a log file. There is no log file, it doesn't create one, so when I cancel the program just closes.

What am I missing ?

LoRd_MuldeR

30th January 2017, 16:48

When I'm running DynamicAudioNormalizerGUI.exe it's asking me for a log file. There is no log file, it doesn't create one, so when I cancel the program just closes.

What am I missing ?

Log files are not created by default. You need to use the "--log-file" option to create one. See here for details:
http://muldersoft.com/docs/dyauno_readme.html#command-line-options

Once you have created a log file, you should be able to open it in the GUI application.

Brazil2

30th January 2017, 18:27

Log files are not created by default. You need to use the "--log-file" option to create one. See here for details:
http://muldersoft.com/docs/dyauno_readme.html#command-line-options

Once you have created a log file, you should be able to open it in the GUI application.
OK, I've processed a WAV file and created a log file with the CLI but the GUI doesn't like it and still doesn't open:
Error: failed to parse the header of the log file!
Probably the file is of an unsupported type.

LoRd_MuldeR

30th January 2017, 21:51

OK, I've processed a WAV file and created a log file with the CLI but the GUI doesn't like it and still doesn't open:
Error: failed to parse the header of the log file!
Probably the file is of an unsupported type.

Are you sure you really tried to open the proper .log file in the GUI program?

It works fine for me:
https://i.imgur.com/339hQ0Il.png (https://i.imgur.com/339hQ0I.png)

If you open the .log file in your favorite text editor, the first line read like:
DynamicAudioNormalizer Logfile v2.10-0

Brazil2

30th January 2017, 22:15

Are you sure you really tried to open the proper .log file in the GUI program?
Yes I'm really sure as I've just create the log file and there is only one in the folder which is this one.

If you open the .log file in your favorite text editor, the first line read like:
DynamicAudioNormalizer Logfile v2.10-0
Yes, here is the full content of the log file:
DynamicAudioNormalizer Logfile v2.10-0
CHANNEL_COUNT:2

2.75301 1.00000 1.00166 2.75301 1.00000 1.00166
2.44692 1.00000 1.00451 2.44692 1.00000 1.00451
3.29739 1.00000 1.00939 3.29739 1.00000 1.00939
2.97966 1.00000 1.01721 2.97966 1.00000 1.01721
3.04154 1.00000 1.02928 3.04154 1.00000 1.02928
2.99083 1.00000 1.04721 2.99083 1.00000 1.04721
3.12233 1.00000 1.07288 3.12233 1.00000 1.07288
2.96224 1.00000 1.10831 2.96224 1.00000 1.10831
2.66928 1.00000 1.15539 2.66928 1.00000 1.15539
2.62904 1.00000 1.21568 2.62904 1.00000 1.21568
3.20739 1.00000 1.29007 3.20739 1.00000 1.29007
2.58469 1.00000 1.37847 2.58469 1.00000 1.37847
3.44174 1.00000 1.47971 3.44174 1.00000 1.47971
3.14164 1.00000 1.59140 3.14164 1.00000 1.59140
3.35350 1.00000 1.70980 3.35350 1.00000 1.70980
2.94528 2.44692 1.83079 2.94528 2.44692 1.83079
2.60786 2.44692 1.94972 2.60786 2.44692 1.94972
2.98663 2.58469 2.06205 2.98663 2.58469 2.06205
2.92932 2.58469 2.16379 2.92932 2.58469 2.16379
2.77101 2.58469 2.25172 2.77101 2.58469 2.25172
2.97577 2.58469 2.32391 2.97577 2.58469 2.32391
3.43440 2.58469 2.37950 3.43440 2.58469 2.37950
3.04096 2.58469 2.41835 3.04096 2.58469 2.41835
2.75635 2.58469 2.44155 2.75635 2.58469 2.44155
3.21672 2.58469 2.45057 3.21672 2.58469 2.45057
3.53032 2.58469 2.44718 3.53032 2.58469 2.44718
2.98803 2.54117 2.43328 2.98803 2.54117 2.43328
2.94175 2.54117 2.41055 2.94175 2.54117 2.41055
2.82039 2.54117 2.38004 2.82039 2.54117 2.38004
2.72843 2.24780 2.34338 2.72843 2.24780 2.34338
3.53767 2.24780 2.30159 3.53767 2.24780 2.30159
2.66838 2.24780 2.25439 2.66838 2.24780 2.25439
3.03057 2.24780 2.20353 3.03057 2.24780 2.20353
3.46730 2.24780 2.14883 3.46730 2.24780 2.14883
2.79168 2.11739 2.09025 2.79168 2.11739 2.09025
3.81846 2.11739 2.02753 3.81846 2.11739 2.02753
4.27056 2.11739 1.96047 4.27056 2.11739 1.96047
3.47703 1.83697 1.88908 3.47703 1.83697 1.88908
3.29773 1.83697 1.81359 3.29773 1.83697 1.81359
3.40390 1.83697 1.73466 3.40390 1.83697 1.73466
2.79807 1.83697 1.65335 2.79807 1.83697 1.65335
2.54117 1.83697 1.57112 2.54117 1.83697 1.57112
2.71538 1.68212 1.48978 2.71538 1.68212 1.48978
2.71074 1.06274 1.41124 2.71074 1.06274 1.41124
2.24780 0.99739 1.33743 2.24780 0.99739 1.33743
2.66346 0.99739 1.27025 2.66346 0.99739 1.27025
2.57734 0.99739 1.21072 2.57734 0.99739 1.21072
2.79610 0.99739 1.15964 2.79610 0.99739 1.15964
2.55346 0.99739 1.11725 2.55346 0.99739 1.11725
2.11739 0.99739 1.08325 2.11739 0.99739 1.08325
2.44995 0.99739 1.05699 2.44995 0.99739 1.05699
2.84407 0.99739 1.03733 2.84407 0.99739 1.03733
1.83697 0.99739 1.02312 1.83697 0.99739 1.02312
2.37721 0.99739 1.01340 2.37721 0.99739 1.01340
2.05107 0.99739 1.00684 2.05107 0.99739 1.00684
2.17316 0.99739 1.00258 2.17316 0.99739 1.00258
1.89217 0.99739 0.99991 1.89217 0.99739 0.99991
1.68212 0.99739 0.99830 1.68212 0.99739 0.99830
1.06274 0.99739 0.99746 1.06274 0.99739 0.99746
0.99739 0.99739 0.99739 0.99739 0.99739 0.99739

Maybe you should try it not in your development environment but on a "fresh" regular machine or an emulated virtual one (VirtualBox).

LoRd_MuldeR

30th January 2017, 22:56

Maybe you should try it not in your development environment but on a "fresh" regular machine or an emulated virtual one (VirtualBox).

If it was a problem of missing dependencies, program wouldn't even start. But your error indicates that the header lines was not found.

Indeed, works even on my Windows XP machine:

https://i.imgur.com/qpXJ1gEl.png (https://i.imgur.com/qpXJ1gE.png)

So, not sure what the problem on your side is :confused:

Could you please share your log file? Please add the exact file that fails to open in the Log Viewer to a ZIP archive and share that ZIP file. Thanks.

Brazil2

30th January 2017, 23:52

Could you please share your log file? Please add the exact file that fails to open in the Log Viewer to a ZIP archive and share that ZIP file. Thanks.
Here it is: http://s000.tinyupload.com/index.php?file_id=70506542745581243530

BTW I'm using DynamicAudioNormalizer.2017-01-29.v120-DLL.zip and I've just unpacked it.

LoRd_MuldeR

31st January 2017, 00:04

Here it is: http://s000.tinyupload.com/index.php?file_id=70506542745581243530

BTW I'm using DynamicAudioNormalizer.2017-01-29.v120-DLL.zip and I've just unpacked it.

Your log files looks good to me:

https://i.imgur.com/FtEYhR2.png

Tried MSVC 12.0 and MSVC 14.0 build of the viewer application. Both work fine for me...

Brazil2

31st January 2017, 00:37

OK, I've downloaded the ZIP again, extracted it and now it works with the same log file. Not sure what happened but thanks for your help.
BTW the GUI is only a log viewer ? I thought it would allow to use the CLI and select several files at once ;)

LoRd_MuldeR

31st January 2017, 15:41

OK, I've downloaded the ZIP again, extracted it and now it works with the same log file. Not sure what happened but thanks for your help.

Well, that sounds strange :confused:

BTW the GUI is only a log viewer ? I thought it would allow to use the CLI and select several files at once ;)

Yes, at this point "only" a log viewer is provided.

If you want a fully-fledged GUI, you can use the VST plug-in in your favorite Audio Editor:
http://muldersoft.com/docs/dyauno_readme.html#vst-plug-in-usage

Or you can write a simple Batch script in order to process several files at once. Or you can use whatever SoX or FFmpeg GUI that exists out there...

LoRd_MuldeR

3rd February 2017, 21:31

OK, I've downloaded the ZIP again, extracted it and now it works with the same log file. Not sure what happened but thanks for your help.
Well, that sounds strange :confused:

FWIW, I have improved diagnostic output, in case an "invalid" log file is encountered.

LoRd_MuldeR

5th February 2017, 02:46

Here is a new TEST version:
* https://sourceforge.net/projects/muldersoft/files/Dynamic%20Audio%20Normalizer/Testing/DynamicAudioNormalizer.2017-02-05.Windows-DLL.v140.zip/download
* https://sourceforge.net/projects/muldersoft/files/Dynamic%20Audio%20Normalizer/Testing/DynamicAudioNormalizer.2017-02-05.Windows-Static.v140.zip/download

This should fix the slowness of "static" builds, when libsndfile is used for I/O. Turns out that some C standard library functions that libsndfile uses extensively are forbiddingly slow in MSVC.

hello_hello

8th February 2017, 09:57

LoRd_MuldeR,
Do you use or know much about foobar2000? I've been playing sound with the DynamicAudioNormalizer but I've bumped into an issue I can't fix. Chances are it's something simple I've missed, because I'm a GUI kind of guy.

So far I'm using the DynamicAudioNormalizer with ffmpeg quite successfully, but I can't do the same thing with the CLI version, and I'm at the "have to know why" stage even though I can work around it.

This command line in the foobar2000 converter set up works fine (the various options such as -f or -g also work), so I assume I'm not missing any dependencies.

(wave file out)
Encoder: DynamicAudioNormalizerCLI.exe, Command line: "-i %s -o %d"

This works fine (wave file out):
Encoder: ffmpeg.exe, Command line: "-i - -y -c:a pcm_s16le -af dynaudnorm %d"

As does this for compressing and encoding with QAAC:
Encoder: cmd.exe, Command line: " /d /c c:\progra~1\foobar2000\encoders\ffmpeg.exe -i - -c:a pcm_f32le -af dynaudnorm -f wav - | c:\progra~1\foobar2000\encoders\QAAC\qaac.exe --ignorelength -s --no-optimize --no-delay -V 91 -o %d -"

This is the log file for the above successful encoding job, just in case it helps.
CLI encoder: cmd.exe
Destination file: D:\Source.m4a
Encoder stream format: 48000Hz / 2ch / 16bps
Command line: "C:\WINDOWS\system32\cmd.exe" /d /c c:\progra~1\foobar2000\encoders\ffmpeg.exe -i - -c:a pcm_f32le -af dynaudnorm -f wav - | c:\progra~1\foobar2000\encoders\QAAC\qaac.exe --ignorelength -s --no-optimize --no-delay -V 91 -o "Source.m4a" -
Working folder: D:\
Encoder process still running, waiting...
Encoder process terminated cleanly.
Track converted successfully.
Total encoding time: 0:06.422, 34.60x realtime

Please be gentle, as I'm a command line moron, but when trying to duplicate the above in order to pipe the output from the DynamicAudioNormalizer itself, I'm experiencing a 100% failure rate.
Encoder: cmd.exe, Command line: " /d /c c:\progra~1\foobar2000\encoders\DAN\DynamicAudioNormalizerCLI.exe -i %s -o - | c:\progra~1\foobar2000\encoders\QAAC\qaac.exe --ignorelength -s --no-optimize --no-delay -V 91 -o %d -"

Am I trying to do something impossible or suffering from a case of the sillies? The temporary file is being created, but the show stops there. This is what foobar2000 has to say about it:

CLI encoder: cmd.exe
Destination file: D:\Source.m4a
Encoder stream format: 48000Hz / 2ch / 16bps
Command line: "C:\WINDOWS\system32\cmd.exe" /d /c c:\progra~1\foobar2000\encoders\DAN\DynamicAudioNormalizerCLI.exe -i "D:\temp-9D08B8C9A24E4D1A37B40CB5624121E7.wav" -o - | c:\progra~1\foobar2000\encoders\QAAC\qaac.exe --ignorelength -s --no-optimize --no-delay -V 91 -o "Source.m4a" -
Working folder: D:\
An error occurred while finalizing the encoding process (Object not found) : "D:\Source.m4a"
Conversion failed: Object not found
could not enumerate tracks (Object not found) on:
D:\Source.m4a
Total encoding time: 0:00.828, 268.43x realtime

I tried bypassing the temporary input file without any luck, but maybe I'm doing that wrong too.
CLI encoder: cmd.exe
Destination file: D:\Source.m4a
Encoder stream format: 48000Hz / 2ch / 16bps
Command line: "C:\WINDOWS\system32\cmd.exe" /d /c c:\progra~1\foobar2000\encoders\DAN\DynamicAudioNormalizerCLI.exe -i - -o - --input-bits 16 --input-chan 2 --input-rate 48000 | c:\progra~1\foobar2000\encoders\QAAC\qaac.exe --ignorelength -s --no-optimize --no-delay -V 91 -o "Source.m4a" -
Working folder: D:\
An error occurred while writing to file (The encoder has terminated prematurely with code 2 (0x00000002); please re-check parameters) : "D:\Source.m4a"
Additional information:
Encoder stream format: 48000Hz / 2ch / 16bps
Command line: "C:\WINDOWS\system32\cmd.exe" /d /c c:\progra~1\foobar2000\encoders\DAN\DynamicAudioNormalizerCLI.exe -i - -o - --input-bits 16 --input-chan 2 --input-rate 48000 | c:\progra~1\foobar2000\encoders\QAAC\qaac.exe --ignorelength -s --no-optimize --no-delay -V 91 -o "Source.m4a" -
Working folder: D:\
Conversion failed: The encoder has terminated prematurely with code 2 (0x00000002); please re-check parameters
could not enumerate tracks (Object not found) on:
D:\Source.m4a
Total encoding time: 0:00.281, 56.48x realtime

Windows XP (I feel like that's an apology, these days) and DynamicAudioNormalizer.2017-02-03.v140, but I tried DynAudNorm.2015-01-20.Windows-Static.zip from the VideoHelp site without any more luck.
Sorry if my post is a bit lengthy, but I figured too much info is probably better than too little.

Cheers.

sneaker_ger

8th February 2017, 10:19

Is DynamicAudioNormalizerCLI outputting wave? I think it may only output PCM when piping and you need to set PCM input parameters in qaac.

manolito

8th February 2017, 10:42

Yes, when using STDIN and STDOUT, DynAudNorm can only use RAW Headerless PCM. For qaac this means that you also must specify the properties of the stream:
Options for Raw PCM input only:
-R, --raw Raw PCM input.
--raw-channels <n> Number of channels, default 2.
--raw-rate <n> Sample rate, default 44100.
--raw-format <str> Sample format, default S16L.

As an alternative you can let DynAudNorm write a temp WAV file and then use this file as the input for qaac. And yes, in this mode DynAudNorm can write long non-standard WAV files > 4GB, and using the "ignorelength" parameter qaac will handle those files correctly.

Cheers
manolito

tebasuna51

8th February 2017, 13:55

The way than many other audio soft solve this problem is:

a) For input data
Add a parameter like -ignorelength to DynamicAudioNormalizerCLI.exe to accept wav input.

That solve two problems:
1) WAV input files bigger than 4 GB, with wrong header fields RIFF_length and DATA_length
2) Piped WAV's with still unkow fields RIFF_length and DATA_length

The rest of parameters needed (channels, rate and format) are always correct in this fake header and don't need to be included.

b) For output data
Seems than already can write WAV files > 4GB (with wrong length fields headers).

Then for pipe output admit send a fake wav header (with unknow fields RIFF_length and DATA_length) before raw data, with a parameter like:
-f wav (ffmpeg)
or
-t wav (sox)

Then the soft than receive that header (with a -ignorelength parameter) read the channels, rate and format without need be in command line.

manolito

8th February 2017, 16:07

Thanks tebasuna for chiming in...
but I and a few others have discussed this with LoRd_MuldeR more than once already, and he always refused to use "illegal hacks" for his software. So I have my doubts if he will implement your suggestions.

Cheers
manolito

hello_hello

8th February 2017, 17:39

Thanks everyone. The readme file doesn't seem to specifically mention raw PCM output, or doesn't harp on it enough for the penny to drop for someone like me. I read this after trying to get stdin to work for about 20 minutes.

Passing "raw" PCM data via pipe is supported too. Just specify the file name "-" in order to read from or write to the stdin or stdout stream, respectively. When reading from the stdin, you have to explicitly specify the input sample format, channel count and sampling rate.

So I figured I was golden on the way out, especially after seeing this command line example in the readme.

Read input from Wave file and write output to stdout (output is passed to FFmpeg via pipe):
DynamicAudioNormalizerCLI.exe -i "input.wav" -o - | ffmpeg.exe -loglevel quiet -f s16le -ar 44100 -ac 2 -i - -c:a libmp3lame -qscale:a 2 "output.mp3"

Oh well.....

Thanks tebasuna for chiming in...
but I and a few others have discussed this with LoRd_MuldeR more than once already, and he always refused to use "illegal hacks" for his software. So I have my doubts if he will implement your suggestions.

I had no idea that was considered a hack. If it is it must be the most widely supported hack since packed bitstreams in AVIs. It kind of seems silly to not join the party.
It's nowhere as convenient having to specify input and output bitdepths and channel count and sample rate etc, especially with a GUI, because then you have to change the saved preset or create a variety of them for every contingency.

Ideally I'd preferred to run the DynamicAudioNormalizer as a DSP rather than an encoder anyway, but the foobar2000 WinAmp Bridge won't acknowledge the WinAmp version exists. Neither does ffdshow, which might have been a way of shoe-horning it in to the GUI. I guess they both only support WinAmp 2 plugins. If the name is an indication, is the WinAmp version of the DynamicAudioNormalizer a Winamp 5 plugin?

Thanks.

hello_hello

8th February 2017, 19:13

As an alternative you can let DynAudNorm write a temp WAV file and then use this file as the input for qaac. And yes, in this mode DynAudNorm can write long non-standard WAV files > 4GB, and using the "ignorelength" parameter qaac will handle those files correctly.

If there's mention of it in the readme I'm missing it. I tried a few variations on this theme without any luck.
temp.wav is being written, so I guess I'm missing something on the QAAC side, but I can't work out what looking at it's options. Command lines....

/d /c c:\progra~1\foobar2000\encoders\DAN\DynamicAudioNormalizerCLI.exe -i %s -o D:\temp.wav | c:\progra~1\foobar2000\encoders\QAAC\qaac.exe --ignorelength -s --no-optimize --no-delay -V 91 D:\temp.wav -o %d

Mind you foobar2000 has to create a temp file, the DynamicAudioNormalizer would have to create one, then finally QAAC would be able to encode. Two temp files seems somewhat excessive, so I'll confess this is just a "need to know" exercise now, then it'll be back to using the DynamicAudioNormalizer with ffmpeg. :)

Thanks.

sneaker_ger

8th February 2017, 20:08

If you use a temp file then certainly the pipe symbol ("|") is not correct. Try to replace it with two ampersands ("&&"). At least that's how it works in the Windows terminal.

tebasuna51

8th February 2017, 20:35

... he always refused to use "illegal hacks" for his software.

Well, read or write "illegal" wav files >4GB can be considered a "hack", but accept stdin (and send to stdout) with a header, than inform about the relevant parameters of the next raw pcm data, is not a hack at all.

Is follow the standard method.

LoRd_MuldeR

9th February 2017, 10:12

Is DynamicAudioNormalizerCLI outputting wave? I think it may only output PCM when piping and you need to set PCM input parameters in qaac.

It uses libsndfile (http://www.mega-nerd.com/libsndfile/) for audio I/O, which handles many formats. And I don't feel like re-inventing the wheel, as far as audio I/O is concerned ;)

Normally, the output format is "guessed" from the file extension, so you can have WAV, W64, FLAC, Vorbis, etc. When writing to a pipe, though, output format is set to "raw" PCM. That's because, other file formats, like WAV or W64, would require the given file descriptor to be seekable - which pipes obviously are not.

Actually I'm not certain what libsndfile does when you explicitely ask it to create a WAV file but pass a non-seekable file descriptor...

(But it would probably error out at some point)

Well, read or write "illegal" wav files >4GB can be considered a "hack", but accept stdin (and send to stdout) with a header, than inform about the relevant parameters of the next raw pcm data, is not a hack at all.

Think of YUV4MPEG format. That was designed with streaming in mind, so you have a minimal header with the relevant info and then only "raw" data. WAV/RIFF, on the other hand, was never designed with streaming in mind. It is a purely file-based format. That's why all data is wrapped in "chunks" that have a (32-Bit) size field at their beginning. Sending a "fake" WAV header with illegal (incorrect) size values over a pipe and hoping that the other side will be able to deal with this situation - which often requires a special command-line option to be set in that program! - clearly is a "hack" in my opinion. Yes, it's a hack that is widely employed, due to the lack of a proper solution. Still, what you actually want to have as a "proper" solution would be an YUV4MPEG-equivalent for audio data.

manolito

9th February 2017, 11:50

Sending a "fake" WAV header with illegal (incorrect) size values over a pipe and hoping that the other side will be able to deal with this situation - which often requires a special command-line option to be set in that program! - clearly is a "hack" in my opinion. Yes, it's a hack that is widely employed, due to the lack of a proper solution.

And all things which are widely employed do become some kind of a standard over time. If you are the only one in the world who does it "correctly", but at the cost of some functionality (like not being able to process long files where an intermediate WAV file is >4GB), and the rest of the world uses "illegal" hacks which actually work even if they are illegal, what have you gained then? Just the warm fuzzy feeling that you have done it correctly, while all the others say "Whatever works...".

Needless to say that I prefer the solutions that do work.

Cheers
manolito

tebasuna51

9th February 2017, 13:12

...Sending a "fake" WAV header with illegal (incorrect) size values over a pipe and hoping that the other side will be able to deal with this situation - which often requires a special command-line option to be set in that program! - clearly is a "hack" in my opinion.

But you uses already this "hack" when write wav files > 4GB hoping that the other side will be able to deal with this situation.

You can output W64 or RF64 files instead "fake" WAV, at least ffmpeg, not all audio soft, can manage them.

Yes, it's a hack that is widely employed, due to the lack of a proper solution. Still, what you actually want to have as a "proper" solution would be an YUV4MPEG-equivalent for audio data.

When don't exist a proper solution we need suggest a easy solution.

All audio soft have parser to read wav header and is easy ignore some fields, there are many fields ignored, some redundants, in wav headers.

We need only Format (bitdepth), Samplerate and Mask-channels (better than Num-channels than force to assume a default Mask-channel).

Took ten years doing feature requests in all audio soft about that.
The first time than I make that in ffmpeg it was rejected with similars reasons than you.
I'm happy to know (this year) than ffmpeg have already the requested -ignorelength parameter.

And all things which are widely employed do become some kind of a standard over time.
That is what I think.

hello_hello

9th February 2017, 21:22

Hack or not, the "fake" WAV header is used so widely I had no idea it was a hack until yesterday.

Packed bitstreams in AVIs and (possibly) variable bitrate audio.... I had no idea they were hacks until I'd watched thousands of AVIs in a variety of players without issue, and read about them in a forum or somewhere similar. If I get a vote, this is a hacking situation.. ;)

If every program forced you to specify bitdepth and sample rate etc when using pipes, life would be a lot harder, especially when using GUI's. Instead of one saved encoder configuration for every source I'd need to create one for 44.1k, one for 48k, each one needs a 16 bit, 24 bit and 32 bit version, then multiply that by the number of possible channel configurations...... and if I want a DynamicAudioNormalizer encoder preset to output wave, and another for flac, multiply that by two.
Or every time I convert I'd need to check and/or alter the encoder preset, which starts to defeat the purpose of a GUI, but creating encoder presets for my most commonly used encoders and settings is almost out of control as it is.

https://s23.postimg.org/k7nmym7az/encoder_configurations.gif

An encoder preset is only part of a conversion preset in foobar2000. To complete the job the required DSPs have to be added, ReplayGain/preamp configured, output file naming scheme set, etc, Then you have a conversion preset. If you change an encoder configuration used in more than one conversion preset, each conversion preset needs to be updated, otherwise when you use an altered conversion preset, foobar2000 happily adds the encoder preset back in it's original form for you, and the number of encoder presets continues to grow........ but now there's encoder presets with identical names and different command lines.

Fortunately ffmpeg supports the hack, which is how I'm using the DynamicAudioNormalizer. I think if the ffmpeg people have decided a hack is okay it's a sign. Actually isn't that the point at which a hack ceases to be a hack in almost every sense? When it's achieved ffmpeg acceptance?

LoRd_MuldeR

9th February 2017, 23:08

And all things which are widely employed do become some kind of a standard over time. If you are the only one in the world who does it "correctly", but at the cost of some functionality (like not being able to process long files where an intermediate WAV file is >4GB), and the rest of the world uses "illegal" hacks which actually work even if they are illegal, what have you gained then? Just the warm fuzzy feeling that you have done it correctly, while all the others say "Whatever works...".

Just because something has become a "de-facto standard" after somebody started using it, due to the lack of a proper solution, does not make it a "good" solution that we should advocate.

There are quite a lot of "de-facto standards" that are quite horrible ;)

As far as the original question is concerned:

I have changed the Audio I/O module so that you can explicitly specify the output format, even when writing to a pipe. We no longer force "raw" PCM in that case. But, coming as no surprise, libsndfile fails to write WAV to a pipe:
"Error : this file format does not support pipe write."

Please note that libsndfile supports other file formats (e.g. AU) that can be written to pipe without problem. Actually, the AU formats looks like a promising candidate for this kind of task.

But you uses already this "hack" when write wav files > 4GB hoping that the other side will be able to deal with this situation.

You can output W64 or RF64 files instead "fake" WAV, at least ffmpeg, not all audio soft, can manage them.

These are actually two different problems. The 4 GB file size limit of WAV/RIFF format is because of the 32-Bit size fields. And, indeed, with W64 there exists a proper solution for that issue.

DynamicAudioNormalizer supports W64 (and also RF64) just fine, thanks to libsndfile-based Audio I/O.

The fact that RIFF/WAV (and similarly W64, by the way) do not support streaming, is more fundamental. Those are purely file-based formats, never designed with streaming in mind.

All audio soft have parser to read wav header and is easy ignore some fields, there are many fields ignored, some redundants, in wav headers.

We need only Format (bitdepth), Samplerate and Mask-channels (better than Num-channels than force to assume a default Mask-channel).

It's actually not quite that simple :)

WAV/RIFF is not simply a global header followed by "raw" data. Instead, its a sequence of "chunks", where each chunk has its own header with size + type. To correctly parse such file, you must consider the size of each chunk, because it is the only way to know where one chunk ends and where the next one starts. Also, you must consider the type of each chunk, because you must skip chunks that you don't know (or don't care about) and find the chunk you actually care about.

Surely, you can simply ignore all that and assume that the given WAV/RIFF is the most simple form of a WAV/RIFF file that can exist. Indeed, this will appear to work as long as you really got the most simple form of a WAV/RIFF file. But it is going to fail in all other cases! Be aware that there could be many other chunks (http://www.robotplanet.dk/audio/wav_meta_data/) present in the WAV/RIFF file, before or after the "data" chunk that contains the actual PCM data. See example here (https://i.imgur.com/6Px8VUj.png).

This is also the reason why the "ignore length" hack always needs to be enabled manually by the user - and only when absolutely needed. You could never make that the default behavior, as it would fail on many legit WAV/RIFF files.

manolito

10th February 2017, 01:29

This is also the reason why the "ignore length" hack always needs to be enabled manually by the user - and only when absolutely needed. You could never make that the default behavior, as it would fail on many legit WAV/RIFF files.

Do you have any examples where this would fail? (Not just a RIFF chunk list, but a real file)

I always use these "ignorelength" or "readtoeof" parameters in SoX and Aften, now even in FFmpeg and qaac, and I never had any problems (with the exception that the progress indicator might show funny values).

Cheers
manolito

tebasuna51

10th February 2017, 10:33

WAV/RIFF is not simply a global header followed by "raw" data. Instead, its a sequence of "chunks", where each chunk has its own header with size + type. To correctly parse such file, you must consider the size of each chunk, because it is the only way to know where one chunk ends and where the next one starts.

Of course, but all wav parsers are ready to ignore all extrachunks between the "fmt " chunk (than define Format, Samplerate and Channels) and the "data" chunk than contain the PCM data.

Is also legal put extrachunks at end of "data" chunk but don't exist a crazy soft than put that in a wav > 4GB or in stdout.

Is really easy make a wav parser to manage the decisions, you have a sample in the source code of wav2w64 (https://forum.doom9.org/showthread.php?t=174279)

With only a few lines of code can read wav "legal" (with any chunk) and "illegal" files or piped (with any chunk between "fmt " and "data"), and output legal w64 files or pipe that header (accepted by ffmpeg even without the -ignorelength parameter).

tebasuna51

10th February 2017, 10:43

Do you have any examples where this would fail? (Not just a RIFF chunk list, but a real file)

I always use these "ignorelength" or "readtoeof" parameters in SoX and Aften, now even in FFmpeg and qaac, and I never had any problems (with the exception that the progress indicator might show funny values).

There are legal wav files (<4GB) than can have extrachunks at end of "data" chunk, using "ignorelength" or "readtoeof" the end chunks are considered like pcm data, and you obtain a end click.

Many audio editors can put these extrachunks.
Then the parameters "ignorelength" or "readtoeof" must be used only for wav > 4 GB or piped data.

LoRd_MuldeR

10th February 2017, 13:23

Do you have any examples where this would fail? (Not just a RIFF chunk list, but a real file)

A WAV file, by definition, is nothing but "a RIFF chunk list". There is an example file in the link I provided above. Also, the screenshot showing the RIFF chunk tree was taken from that example file. But here is another example of a simple WAV file I saved from Audacity (http://www.audacityteam.org/) audio editor, so nothing special or uncommon at all:
https://i.imgur.com/RIYwzAM.png

Obviously, if here you assume anything after the start of the "data" chunk (to the end of the file) is PCM data, you will get garbage at the end of the track.

I always use these "ignorelength" or "readtoeof" parameters in SoX and Aften, now even in FFmpeg and qaac, and I never had any problems (with the exception that the progress indicator might show funny values).

As said before, the "ignore length" hack is going to work on a very specific type of file or stream which uses a "WAV-format inspired" header followed only by "raw" data. It certainly is not going to work with all valid WAV/RIFF files! Also, even worse, there is no reliable way for an application to distinguish between a valid WAV/RIFF file and "raw" data preceded by "fake" WAV header - even though both cases require very different handling (as we have seen). That is exactly why you have to manually tell the application every single time - via command-line switch - that this file/stream is non-standard and requires special handling.

(For me, the need for this kind of manual workaround is the definition of a "hack" ;))

manolito

10th February 2017, 13:57

If it is true what tebasuna said (the worst that can happen will be a click at the end of the file) then I can probably live with it. And when using pipes nothing bad can happen at all.

I would have appreciated a link to a real WAV file which contains such extra chunks after the data so I could do some tests. You say that Audacity produces such files. Do you have to apply special settings in Audacity to obtain such a file, or does this always happen?

Cheers
manolito

hello_hello

10th February 2017, 17:03

That is exactly why you have to manually tell the application every single time - via command-line switch - that this file/stream is non-standard and requires special handling.

Then let's do that. ;)
I assume the alternative is having to manually provide the application every single time, via several command line switches, enough information about the raw audio for the application to process it? I can't write software, so my perspective is a user one, but from where I stand it seems a no-brainer.
I'm not sure a fake wave header has ever caused me problems, but once again from a user perspective (using a GUI) will the "proper" method improve or change my user experience in any way. If not... it makes it harder to care about hackery. From a user perspective, having the functionality now instead of not having it while waiting for a non-hacked implementation that mightn't be available for years seems kind of silly.

Personally I think the hack label should be removed for a rebranding. Sure it might still technically be a hack, but maybe a small warning on the packaging will suffice given the current "fake wave header" is almost as universally supported as the non-fake wave header will be, when the proper solution arrives.

LoRd_MuldeR

10th February 2017, 17:11

If it is true what tebasuna said (the worst that can happen will be a click at the end of the file) then I can probably live with it.

It is not the worst that can happen. The "click" sound is a symptom of the fact that, if you ignore the length field and read all the way to the end, then any chunks that follow after the "data" chunk (which is perfectly possible and common practice) are interpreted as PCM data - although they are not. The result is that you get an undefined number of corrupted samples (i.e. samples with undefined content) at the end of the file. It could manifest itself as anything between "silence" and a loud "buzz" sound that blows up your speakers. After all, undefined is... undefined. But, in any case, getting corrupted input samples from a perfectly valid WAV file clearly is not acceptable behavior.

And when using pipes nothing bad can happen at all.

This has nothing to do with pipes per se. The "problem" is: When the writing application produces a "fake" WAV header followed by an undetermined number of PCM samples, then the reading application must enabled the "ignore length" hack to deal with this non-standard situation. At the same time, the reading application must not enable the "ignore length" hack when reading normal correct WAV files, because this can cause problems with some perfectly legitimate WAV files.

The reading application's dilemma is: It can not know, from the data (header), whether this is a "fake" WAV header or a real (correct) WAV file, because the "fake" WAV header imitates the header of a real (correct) WAV file... This is why real world applications do not use the "ignore length" hack by default. They do "correct" parsing, unless you explicitly tell them, via command-line option, to enable the "ignore length" hack for this particular input.

(And, nope, you are not "save" when using a pipe. That's because sending a valid standard WAV file over a pipe is also possible - provided that the source application can determine the actual file size beforehand)

I would have appreciated a link to a real WAV file which contains such extra chunks after the data so I could do some tests. You say that Audacity produces such files. Do you have to apply special settings in Audacity to obtain such a file, or does this always happen?

Nope, I did not use any special settings. Just plain standard Audacity with "factory" settings. It will probably include the "id3" tag only, if the source files contained meta information, or if you edited the meta information in Audacity.

FWIW, here you can see a standard WAV file exported from Audacity, then encoded with NeroAAC - once with the "-ignorelength" option set and once without - and finally re-imported into Audacity:

https://i.imgur.com/p0E4d1zl.png (https://i.imgur.com/p0E4d1z.png)

(Version that was encoded with "-ignorelength" option and thus has corrupted samples at the end is at the bottom, if that isn't obvious ^^)

tebasuna51

10th February 2017, 23:33

It could manifest itself as anything between "silence" and a loud "buzz" sound that blows up your speakers.
You don't need scare, a extrachunk LIST, like the image show, in a wav 2.0 16 bits 44100 Hz is less than 7 ms, if that can damage your speakers...

(And, nope, you are not "save" when using a pipe. That's because sending a valid standard WAV file over a pipe is also possible - provided that the source application can determine the actual file size beforehand)

Is possible, but I don't know any decoder or other soft, like sox, than send extrachunks at end of audio data.

BTW this is your thread and your soft.
Sorry for disturb you.

LoRd_MuldeR

11th February 2017, 00:05

You don't need scare, a extrachunk LIST, like the image show, in a wav 2.0 16 bits 44100 Hz is less than 7 ms, if that can damage your speakers...

Well, the point was that you can get some "garbage" at the end of the file if you ignore the length. And, because you are interpreting something as PCM data that isn't PCM data, it is completely undefined how it will sound like. But it's not going to sound "nice", that's for sure. Some programs (e.g. Audacity) include meta data as "id3" chunk. ID3 tag can contain even artwork as JPEG image. This could easily map to a few seconds of playback time, I suppose.

But the duration of the glitch is not all that important. Even a very short glitch at the end of a track can already be annoying. If I pass my valid input file trough some tool and that tool adds a glitch to the end of the track, I call that a bug.

BTW this is your thread and your soft.
Sorry for disturb you.

Discussion went kind of off-topic, but I want to make it clear again: The CLI front-end relies on libsndfile for audio I/O, which handles all the "nasty" stuff like endianess conversion, float/integer conversion, many different file formats and so on. I don't intend to go away from that. And, as a matter of fact, libsndfile refuses to write WAV format to a pipe, which is not a big surprise. You can select other formats, like AU/SND or FLAC, if you don't like it "raw"...

manolito

11th February 2017, 01:11

I tried to reproduce these extra chunks thing with audacity, but I had to use the older version 2.03 because new versions did not run on my non-SSE2 CPU (again,,, what a surprise).

And guess what, I imported an MP3 with lots of tags and then exported it to a standard 16-bit WAV file without removing any tag information. And the resulting WAV had absolutely no extra chunks after the WAV data chunks.

So these extra chunks may be totally legal, but IMO they are absolutely sick and should not be there.

And even if you do get these artifacts at the end of the resulting file, in my work flow the audio will be muxed in the end with some video stream. And if the audio is longer than the video then these artifacts will (hopefully) be cut off.

For the DynAudNorm CLI version I do have my workarounds for handling long multichannel sources. And for general audio format conversions I have completely abandoned LameXP in favor of FFmpeg (using dmMediaConverter as a GUI). Same or better quality, much faster and more options like using a container as the source. And no problems whatsoever using long multichannel sources (where LameXP is broken as soon as a 6-ch source exceeds a length of 2h 4m).

Cheers
manolito

LoRd_MuldeR

11th February 2017, 02:07

So these extra chunks may be totally legal, but IMO they are absolutely sick and should not be there.

The RIFF format, and everything based on it (WAV, AVI, etc), is defined as a tree of nested "chunks". Whichever way you look at it, that's just how the format is designed.

Now, if you misinterpret this tree-structure as "global header followed by raw data all the way to the end of the file" (which it really isn't) then things are expected go wrong - and often will go wrong.

So you can't say that something that is fundamental to how to format is defined is "sick and should not be there", just because you don't like it :rolleyes:

Take it: Sending a "fake" WAV header followed by an undetermined amount of raw data is going to work, if and only if the reading application employs the "ignore length" hack - which in turn is asking for trouble when reading normal WAV files!

You simply can not get both things to work correctly at the same time with (pseudo) WAV format. That is the reason why the "ignore length" hack needs to be enabled manually by the user, and only when absolutely needed.

(If, on the other hand, we used a proper "streamable" format - for example AU format - then no such hackery would be needed, because the format actually supports what we are trying to do)

hello_hello

11th February 2017, 09:39

I don't see a distinction, as pretty much every encoder I've configured for a foobar2000 preset uses "ignore length" and accepts stdin with a fake wave file.

stdin and "ignore length" work for every source and doesn't require advanced knowledge of the audio sample rate or channel count etc, assuming the encoder understand it..
Without the hack, each input needs to have information added to the command line describing the raw audio. I know which is easier when working with a GUI, but a question (although I appear to be suffering from some sort of invisibility), from a user perspective what's the difference between having to remember not to specify bitdepths and sample rates etc when the hack is used, and remembering not to use "ignore length" when the output is raw. For most applications it's probably in the manual, and you'd hope it says "these options only apply to raw input", just as you'd hope there'd be a description for "ignore length" which includes something like "only for fake wave" or however it's usually described.
The inclusion of raw input command line options proves the encoder isn't supposed to know everything, and without the hack an additional burden on a user who's not to be trusted with "ignore length".

If the audio is being decoded to temporary wave files along the way, there's no longer an option to convert two, four or even more simultaneously as the hard drive wouldn't keep up, and knowing when to use a temporary wave file as input is possibly just as important as knowing when to use the "ignore length" or "raw input only" command line options, I assume.

When you pipe to an encoder with DynamicAudioNormaliser, the temporary wave file count doubles, doesn't it? With the hack, the hard drive is free to write several lossy output files as their processed simultaneously, not having wave creation to worry about.

If you're doing it all by the command line it might be a different story, but I guess you have the official command line compressor if you're using the command line, and ffmpeg with the compressor included for GUI users. Without ffmpeg I think the CLI compressor would be far less practical for GUI use.

Foobar2000 has a command line decoder DSP that gives it the ability to decode with any CLI decoder, which is handy when there's no native decoding for a particular type of audio. I use it to decode EAC3 with ffmpeg. I can pipe and the audio loads into a playlist instantly, but the duration isn't displayed and there's no navigating. Forcing wave output means everything works as usual, but unfortunately the process repeats when you stop and restart playback or when you begin converting. Loading and converting movie length audio files becomes so slow and tedious you might as well be extracting thermfor loading into Audacity to compress and export as AAC etc, so after configuring the decoder initially, I didn't take long to switch to using the hack. Decoding that way is reserved for converting audio foobar2000 can't natively decode anyway (for my use), so the hack is fine. There's only so much coffee to be made while wave file creation is in progress.

LoRd_MuldeR

11th February 2017, 13:27

I don't see a distinction, as pretty much every encoder I've configured for a foobar2000 preset uses "ignore length" and accepts stdin with a fake wave file.

Surely, if both sides - the writing application and the reading application - agree on some non-standard format, then it's going to "work" - no matter how obscure their non-standard format is.

But things are going fail, as soon as the source actually is not in the non-standard format (but in the valid standard format), while the reading application still assumes the non-standard format. Similarly, things are going the fail as soon as the writing application produces the non-standard format, while the reading application expects the valid standard format (rather than the special non-standard format).

Thus, in addition to the prerequisite that both applications must support the same non-standard format, there is no way around some "out of band" signaling of when to actually use/assume the non-standard format.

stdin and "ignore length" work for every source and doesn't require advanced knowledge of the audio sample rate or channel count etc, assuming the encoder understand it.

It does not work "for every source". It works only if the writing application generates a "fake" WAV header followed by "raw" data; it works only if the reading application supports the "ignore length" hack; and it works only if the reading application is explicitly made aware (via CLI switch) that, this particular time, the "ignore length" hack is supposed to be enabled. The latter must not be done for normal WAV files, because it could easily produce garbage (see above).

So, after all, you don't gain much with "fake" WAV header, compared to just plain "raw" PCM. In both cases, an additional "out of band" information must be passed from writing application to reading application, i.e. outside of the stream (pipe).

If, on the other hand, you pass a proper "streamable" format over the pipe - for example, AU or FLAC format - then no such hackery and no "out of band" information whatsoever are needed:
DynamicAudioNormalizerCLI.exe -i "E:\Orange and Blue.wav" -t au -o - | ffmpeg.exe -i - final_output.wav

When you pipe to an encoder with DynamicAudioNormaliser, the temporary wave file count doubles, doesn't it? With the hack, the hard drive is free to write several lossy output files as their processed simultaneously, not having wave creation to worry about.

If you pipe from DynamicAudioNormaliser CLI front-end to an encoder, the content is passed in memory. No temporary file is created.

DynamicAudioNormaliser can output any format supported by libsndfile, either to a file or to a pipe. The latter, of course, requires a format works on non-seekable pipes. This includes AU and FLAC format, but not WAV/RIFF format.

...which is not my "idea" or "opinion", but simply how things have been implemented in libsndfile. And it's quite obvious (to any person familiar with WAV/RIFF format internals) why it has been implemented that way.

(Of course, using a temporary file always an option too)

manolito

11th February 2017, 18:26

Using a streamable format for piping like AU or Flac is nice, but the application you are piping to neds to understand this format. FFmpeg sure does, but Aften only supports WAV, and for many other encoders this is the same.

And somehow the -t switch is missing in my older (Non-SSE2) version of DynAudNorm... :devil::D

I made a couple more tests, and as a result I will stick to my current workflow. I used an MP3 with a cover picture in the meta data and tried to convert it to a WAV file which also included this cover. The older Audacity 2.03 would not do it, the very old WaveLab 3.0 would not do it, even the current LameXP created a WAV without the cover (in fact without any metadata even though the option to write metadata into the output was activated).

The only way to create such a WAV file with extra chunks after the WAV data was to use TagScanner and import the metadata from the MP3 into the WAV file. And true enough, piping this WAV file into Aften with the ignorelength parameter resulted in an AC3 with an artifact at the end.

I still think that I am not really affected by this. It only happens if the WAV file has these extra chunks after the WAV data, and this does not happen for me. Mostly these intermediate WAV files are created by Wavi, maybe by FFmpeg from an AVS script. No metadata here. The same is true when creating a WAV file or stream from SoX.

And in the very unlikely case that my source is such a WAV file, loading it into WaveLab and saving it again will get rid of these extra chunks. Or I can fire up TagScanner and remove those tags. I still believe that such metadata have no place in an intermediate file or stream. If I want them I will apply them to the final encoded file.

Cheers
manolito

hello_hello

12th February 2017, 22:09

It does not work "for every source". It works only if the writing application generates a "fake" WAV header followed by "raw" data; it works only if the reading application supports the "ignore length" hack; and it works only if the reading application is explicitly made aware (via CLI switch) that, this particular time, the "ignore length" hack is supposed to be enabled. The latter must not be done for normal WAV files, because it could easily produce garbage (see above).

As I'm generally using a GUI I guess I have a different perspective. Open a file with foobar2000 and convert it, it's decoded and piped using the hack. Unless an encoder won't accept stdin in which case you can tell foobar2000 to create a temporary input wave file instead.

Here's the list of encoders for which I'm currently using stdin:
Aften, fdkaac, ffdcaenc, ffmpeg, fhgaac, flac, lame, musepack, NeroAAC, ogg, opus, qaac, wavpack, WMAEncode

The list of encoders configured to use a temporary input file:
DynamicAudioNormalizer

So until recently the hack worked for every source because fooobar2000 decodes them all to a "common denominator" and sends it to the encoder. Including standard wave files. "ignore length" still required. The source itself is kind of irrelevant in that respect and I can't see how it'd be likely to work any other way with most GUIs. At least GUI's capable of playback too.

Foobar2000 has presets for many encoders. Select one and it gives you an appropriate GUI for basic settings, adjust them, switch to "custom" and the command line is filled in waiting for you to modify it. The encoder's version of "ignore length" will be included automatically along with stdin.
Creating multiple encoder presets to cover all the sample rate, bit depth and channel count contingencies defeats the purpose, and I'm not sure where that leaves channel mapping, so it's hack or temporary wave file.

No doubt there's times when the user would be setting up an encoder preset from scratch, if the GUI allows, in which case it's the user's responsibility to get the options right, and in relation to this discussion that's pretty much knowing when to use "ignore length" and when not to. Well I have to know now, whereas a few days ago....

If, on the other hand, you pass a proper "streamable" format over the pipe - for example, AU or FLAC format - then no such hackery and no "out of band" information whatsoever are needed:
DynamicAudioNormalizerCLI.exe -i "E:\Orange and Blue.wav" -t au -o - | ffmpeg.exe -i - final_output.wav

The last paragraph had so many flavours of emphasis, after tuning it into a quote I struggled to read it. :)

If an encoder accepts one of those formats as input I can't argue about that one.
(editing out some stuff after realising I misread the above command line)

I did create an encoder preset for DynamicAudioNormalizer to simply output a wave file itself, and in the end a two step process might be easier. Compress and convert a bunch of files to wave, then convert the wave files to the final format with the usual encoder. That's possibly how I would have done it anyway, because then I don't need one preset piping to encoder A, another piping to encoder A with different command line options, a preset piping to encoder B, another piping to.....
It's really just a few extra clicks to do it in two steps, but after creating the first encoder preset I thought I'd give piping a try mainly for the sake of it, and I've learnt a bit as a result.

PS. I noticed the only encoder preset for which I appear to have no "ignore length" equivalent in the command line is ffmpeg. I couldn't find much information on it, but the little I did find seems to indicate ffmpeg decides for itself when to ignore. Is that correct?

hello_hello

12th February 2017, 22:25

I used an MP3 with a cover picture in the meta data and tried to convert it to a WAV file which also included this cover. The older Audacity 2.03 would not do it, the very old WaveLab 3.0 would not do it, even the current LameXP created a WAV without the cover (in fact without any metadata even though the option to write metadata into the output was activated).

If you need to know for future reference, foobar2000 will do it.
I don't put cover art in files normally, but I was curious. The option to transfer attached pictures worked when converting an MP3 to wave, as did attaching a pic to a wave file loaded into a playlist (right click Tagging/Attach Pictures menu).
I've been using foobar2000 for so long I've no idea which features are native any more. The picture attaching options probably are, but if not I have the Quicktagger and TagBox DSPs/plugins installed, one of which would be responsible for them.

manolito

12th February 2017, 22:27

PS. I noticed the only encoder preset for which I appear to have no "ignore length" equivalent in the command line is ffmpeg. I couldn't find much information on it, but the little I did find seems to indicate ffmpeg decides for itself when to ignore. Is that correct?

No, FFmpeg does have a (poorly documented) "ignore length" parameter. See this post:
https://forum.doom9.org/showthread.php?p=1795583#post1795583

Cheers
manolito

hello_hello

13th February 2017, 11:45

Thanks. Should I find myself confused as to why I wasn't having problem without it, or should I just add it and pretend it was always there?
It might explain a couple of log file warnings I didn't understand. I probably should test that later. I might learn a little more.
Cheers.

hello_hello

13th February 2017, 15:43

Nothing's ever easy or I missed the obvious, but ffmpeg possibly has the only ignore length command line option requiring an argument, so the full story turned out to be:

-ignore_length true

Testing so far hasn't revealed a difference. The log files are the same aside from acknowledging the extra command line option. With and without -ignore_length, ffmpeg's output flac files have been identical. Same number of samples, same bitrate, same audio md5. I supposed it can't hurt to leave it in the command line though.

manolito

13th February 2017, 16:05

The only time when this option can possibly make a difference is when the input is a WAV file which has extra data chunks (like a cover artwork) AFTER the main WAV data. WAV files which have been created as intermediate temporary WAV files (or WAV streams when using a pipe) will never have these extra chunks after the WAV data, so the "ignorelength" parameter will not make any difference in this case.

Cheers
manolito

hello_hello

14th February 2017, 18:06

Maybe a mod can split this off into a new thread if it's in the way here, but because I didn't know the hack was a hack until very recently, I played around a little more.

From a GUI perspective again, where the audio is always decoded by the GUI, a couple of encoders seem to assume "ignore length" for stdin and don't have an "ignore length" option (that I could find). They were LAME and MusePack. I'm not sure about the latter but for LAME stdin seems to assume the hack unless you specifically tell it the input is raw.
FFmpeg's "ignore length" probably fits into the above category too, simply because it's not well documented.

For the encoders with an "ignore length" option, many still seem to apply the same rule for stdin. The following encoders produced output files with the correct number of samples either way. FDKAAC, FFmpeg, FhGAC, Flac, Ogg, Opus, QAAC, WMAEncode.
The only anomaly I found there was the Flac file size was slightly larger without it's version of "ignore length" in the command line, yet according to foobar2000 the bitrate, sample count, and audio md5 were the same.

The encoders that failed without it were Aften, ffdcaenc, NeroAAC, and WavPack.
Fortunately though, encoders either exited with an error or they encoded normally, there seemed to be no middle ground, so from that perspective it's a good thing.

Not being able to encode with Nero if I used stdin without "ignore length" (a temporary input wave file worked fine) I tried with Audacity to see what would happen, but I must have been using the wrong incantation, because the progress meter would get to the halfway point each time and Audacity would stop responding, but I'm quite interested to learn why NeroAAC just exits with an error for foobar2000 if I use stdin without "ignore length", if it'll encode for Audacity, however I need to find out why it's not working at all first (I had an older Audacity installed so I upgraded to the latest but the result was the same).

The command line for Audacity I'm using:
"C:\Program Files\foobar2000\encoders\neroAacEnc.exe" -q 0.40 -ignorelength -if - -of %f

LoRd_MuldeR

19th February 2017, 20:57

FWIW, here is a new Test version with Python bindings included:
https://sourceforge.net/projects/muldersoft/files/Dynamic%20Audio%20Normalizer/Testing/DynamicAudioNormalizer.2017-02-22.Windows-DLL.zip/download

LoRd_MuldeR

14th April 2017, 21:07

Dynamic Audio Normalizer v2.10
• https://github.com/lordmulder/DynamicAudioNormalizer/releases/tag/2.10
• https://www.mediafire.com/folder/flrb14nitnh8i/Dynamic_Audio_Normalizer
• https://bitbucket.org/muldersoft/dynamic-audio-normalizer/downloads

Changelog:
• Core library: Added process() function, i.e. an "out-of-place" version of processInplace()
• Implemented Python API → Dynamic Audio Normalizer can be used in, e .g., Python-based applications
• CLI front-end: Added new CLI option -t to explicitly specify the desired output format
• CLI front-end: Added new CLI option -d to explicitly specify the desired input library
• CLI front-end: Added support for decoding input files via libmpg123 library
• CLI front-end: Implemented automatic/heuristic selection of the suitable input library
• CLI front-end: Properly handle input files that provide more (or less) samples than what was projected
• Windows binaries: Updated the included libsndfile version to 1.0.27 (2016-06-19)
• Windows binaries: Updated build environment to Visual Studio 2015 (MSVC 14.0)

kolamorx

12th June 2017, 04:37

LoRd_MuldeR

12th June 2017, 15:51

Hello.
I've been experimenting with FFmpeg's dynaudnorm filter recently (on movies), and the results are good.
However, the loud parts (music, effects) are sometimes slightly louder than the quiet parts (dialogue).
My goal is to get a completely constant volume, with no need to raise and lower the volume at all.
What options and settings should I use in order to achieve this goal?

First of all, it is possible that the "quiet" part is so quiet, compared to the "loud" parts, that the maximum gain factor (default: 10×) doesn't suffice to bring it up to the same volume. So you can try increasing the maximum gain factor.

Secondly, it is possible that the "quiet" part is shortly after a "loud" part and the filter takes a moment to adapt. Keep in mind that the filter adapts slowly and smoothly, in order to avoid nasty "volume pumping" effect. Anyway, you can try using a smaller Gaussian filter window size (default: 31) to make the filter adapter faster.

Finally, it is possible that the "quiet" part simply has more dynamics compared to the "loud" part. What it means is that the "quiet" part contains a few signal peaks that prevent it from being amplified even further (without clipping), even though the average amplitude is relatively low. In this case you can give RMS mode a try. Or you can try adding some input compression. Or both ;)

See also:
http://muldersoft.com/docs/dyauno_readme.html#configuration

kolamorx

13th June 2017, 04:14

Since I'm not going to check this options for every movie, what I'm looking for is the best general settings to cover these options.

Secondly, it is possible that the "quiet" part is shortly after a "loud" part and the filter takes a moment to adapt. Keep in mind that the filter adapts slowly and smoothly, in order to avoid nasty "volume pumping" effect. Anyway, you can try using a smaller Gaussian filter window size (default: 31) to make the filter adapter faster.
I changed it already, (g=11) and it improved the results.
Finally, it is possible that the "quiet" part simply has more dynamics compared to the "loud" part. What it means is that the "quiet" part contains a few signal peaks that prevent it from being amplified even further (without clipping), even though the average amplitude is relatively low. In this case you can give RMS mode a try. Or you can try adding some input compression. Or both
RMS - I haven't tried it much.
input compression - tried it already, and it causes FFmpeg to freeze right at the beginning. (I use rogerdpack version for XP.)

hello_hello

15th June 2017, 22:52

kolamorx,
Try just reducing the frame size. For ffmpeg:

-af dynaudnorm=f=150

or even f=75 and g=11 if it doesn't result in too much "pumping".

Edit see post #133 regarding the compression option and a newer version of ffmpeg (XP friendly)

LoRd_MuldeR

16th June 2017, 01:48

input compression - tried it already, and it causes FFmpeg to freeze right at the beginning. (I use rogerdpack version for XP.)

FFmpeg actually doesn't use my "original" code/library, but they re-implemented everything.

So, if you get "freeze" with FFmpeg and DynAudNorm when input compression is enabled, I suggest you try it with the "standalone" version of DynAudNorm:
https://github.com/lordmulder/DynamicAudioNormalizer/releases/latest

If you can re-produce the "freeze" with that, please send my a sample file and your exact options. Otherwise, please send a bug-report to the FFmpeg developers.

hydra3333

16th June 2017, 11:53

FFmpeg actually doesn't use my "original" code/library, but they re-implemented everything.
<snip>
... Otherwise, please send a bug-report to the FFmpeg developers.
Goodness me.
How to they deal with updates you may produce from time to time ?

stax76

16th June 2017, 12:28

kolamorx,
Try just reducing the frame size. For ffmpeg:

-af dynaudnorm=f=150

or even f=75 and g=11 if it doesn't result in too much "pumping".

Does anybody know where I can find the documentation for this?

edit:

To answer my own question after going through the thread: https://ffmpeg.org/ffmpeg-filters.html#dynaudnorm

richardpl

16th June 2017, 12:52

Goodness me.
How to they deal with updates you may produce from time to time ?

There had be no updates to core for very long time. And relevant changes are committed when they appear.

hello_hello

16th June 2017, 22:30

RMS - I haven't tried it much.
input compression - tried it already, and it causes FFmpeg to freeze right at the beginning. (I use rogerdpack version for XP.)

As I don't normally use the compression option I didn't remember straight away, but I now recall someone at VideoHelp mentioning the same problem.
I tested with the following ffmpeg command line myself and it works fine using this version of ffmpeg (https://github.com/rdp/ffmpeg-windows-build-helpers/issues/219#issuecomment-306066471), which is probably more recent than the version you're using and it runs on XP.

-af dynaudnorm=f=75:g=11:s=12

manolito

17th June 2017, 10:11

If you have trouble getting the desired results with DynAudNorm you can try the "Loudnorm" filter which comes with current versions of FFmpeg, Muxson wrote a nicle little GUI for it:
http://www.muxson.com/winloud

Cheers
manolito

kolamorx

17th June 2017, 21:07

I tested with the following ffmpeg command line myself and it works fine using this version of ffmpeg (https://github.com/rdp/ffmpeg-windows-build-helpers/issues/219#issuecomment-306066471), which is probably more recent than the version you're using and it runs on XP.

-af dynaudnorm=f=75:g=11:s=12

Thanks.
Any other suggestions for general settings?

v0lt

23rd June 2017, 04:20

@LoRd_MuldeR
I have a sound in float format, in which the range is higher than [-1.0, +1.0]. DynamicAudioNormalizer (FFmpeg implementation) can reduce the sound level to [-1.0, +1.0]?

richardpl

23rd June 2017, 15:16

@LoRd_MuldeR
I have a sound in float format, in which the range is higher than [-1.0, +1.0]. DynamicAudioNormalizer (FFmpeg implementation) can reduce the sound level to [-1.0, +1.0]?

See alimiter filter documentation.

raffriff42

23rd June 2017, 19:24

From the ffmpeg source, it looks like all audio filtering is done at double-precision floating point, with nominal +1/-1 range - but no clipping outside that range. FFmpeg dynaudnorm default peak volume is 0.95 (-0.4 dB on a +1/-1 scale). It looks to me like it'll normalize any input range without problems; you'll have to try it for yourself though.

kolamorx

29th July 2017, 20:12

First of all, it is possible that the "quiet" part is so quiet, compared to the "loud" parts, that the maximum gain factor (default: 10×) doesn't suffice to bring it up to the same volume. So you can try increasing the maximum gain factor.
In some movies, the dialogue is so quiet that even a maximum gain factor of 100× (20 dB) doesn't suffice.
What should I do in this case?

LoRd_MuldeR

29th July 2017, 21:15

In some movies, the dialogue is so quiet that even a maximum gain factor of 100× (20 dB) doesn't suffice.
What should I do in this case?

If the original source was encoded in AC3/EAC3 (Dolby Digital) from, then you may try enabling the DRC (Dynamic Range Compression) feature of the AC3/EAC3 decoder already.

Apart from that, you can try the "--compress" option of the DynamicAudioNormalizer. See the manual for details...

kolamorx

29th July 2017, 22:30

If the original source was encoded in AC3/EAC3 (Dolby Digital) from, then you may try enabling the DRC (Dynamic Range Compression) feature of the AC3/EAC3 decoder already.

Apart from that, you can try the "--compress" option of the DynamicAudioNormalizer. See the manual for details...
Actually, my idea was to increase the volume before using dynaudnorm. (-af "volume=15dB,dynaudnorm=m=100...")
Is there a limit for the loss factor as there is for the gain factor?

LoRd_MuldeR

29th July 2017, 23:15

Actually, my idea was to increase the volume before using dynaudnorm. (-af "volume=15dB,dynaudnorm=m=100...")
Is there a limit for the loss factor as there is for the gain factor?

If the volume can be increased any further using a fixed gain factor without causing clipping in the "loud" sections (i.e. there is some unused "headroom" in the file), then you should be doing this, of course.

However, if you use a tool like DynamicAudioNormalizer, it usually means that "traditional" normalization doesn't work on your file, because the "loud" sections are at maximum signal level already and yet the "quiet" sections are still too silent.

After all, the DynamicAudioNormalizer is not about "increasing" the volume (you could achieve that by simply turning up your speakers). It is all about "equalizing" the volume of "quiet" and "loud" sections ;)

kolamorx

29th July 2017, 23:38

LoRd_MuldeR

30th July 2017, 00:23

So, I guess I don't really understand how this tool works.
I tought that if, for example, the loud parts are 90dB, the quiet parts are 65dB, and you set the target value to 80dB- it decreases the loud parts by 10dB and increases the quiet parts by 15dB.

Yes, when using the DynamicAudioNormalizer, any "frame" whose level is below the target level will be amplified to the target level, and any "frame" whose level is above the target level will be attenuated to the target level – with some trickery (Gaussian filter) to avoid fast fluctuation of the amplification/attenuation factors. In other words, the DynamicAudioNormalizer will "equalize" the volume of "quiet" and "loud" sections.

The more simple "volume" filter will just apply the same fixed amplification factor to all samples. So, if the "loud" sections of your file already are at maximum signal level, then the "volume" filter can not further increase the volume of your file, as this would unavoidably result in clipping (in the "loud" sections). In other words, with the "volume" filter, the "loud" sections may prevent further amplification of the "quiet" sections. The DynamicAudioNormalizer can help in this situation.

If, on the other hand, the "loud" sections of your file are not at maximum signal level yet, i.e. there is some "headroom" in your file, then the "volume" filter can increase the volume of your file – to the extent that brings the "loud" sections to the maximum signal level. But even in that case, the "volume" filter does not "equalize" the volume of "quiet" and "loud" sections! It's just like turning up the volume of your speakers a little more. There is no "dynamic" adjustment.

Still, if you actually do have some "headroom" in your file, I would suggest to apply the "volume" filter first, to get "traditional" normalization. And then, if still required, use DynamicAudioNormalizer to bring up the "quiet" section some more...

kolamorx

30th July 2017, 00:36

How do I check how much headroom I have in my file?

LoRd_MuldeR

30th July 2017, 00:49

How do I check how much headroom I have in my file?

For example, with the "volumedetect" filter:
https://ffmpeg.org/ffmpeg-filters.html#volumedetect

(it is max_volume that you are interested in)

kolamorx

30th July 2017, 01:56

Thanks.
Any chance you will increase the maximum possible value of the maximum gain factor in the future?

LoRd_MuldeR

30th July 2017, 16:03

Thanks.
Any chance you will increase the maximum possible value of the maximum gain factor in the future?

I don't think so. An amplification factor of 100× already is equivalent to +40 dB.

If the "quiet" sections really are that much quieter than the "loud" sections that even an amplification by 100× (+40 dB) doesn't suffice, it probably means that the "quiet" sections are already lost in the noise.

Again: Don't use DynAudNorm to eliminate the "headroom" in your file. Use a "traditional" normalizer for that purpose. Use the DynAudNorm to "equalize" the volume of "quiet" and "loud" sections...

manolito

30th July 2017, 19:21

Still, if you actually do have some "headroom" in your file, I would suggest to apply the "volume" filter first, to get "traditional" normalization. And then, if still required, use DynamicAudioNormalizer to bring up the "quiet" section some more...

Not so sure about this recommendation...

I downloaded a short random clip with "sane" audio levels and did a few tests:

The source had these levels:
Integrated Loudness: -19.83 LUFS
Sample Peak: -6.07 SPFS

After conversion using DynAudNorm with default settings:
Integrated Loudness: -12.72 LUFS
Sample Peak: -0.45 SPFS

This time using peak normalizing first followed by DynAudNorm with default settings:
Integrated Loudness: -12.64 LUFS
Sample Peak: -0.36 SPFS

The loudness values are almost identical for both conversions. At least for "sane" source audio levels it is not necessary to apply regular peak normalization before DynAudNorm.

Just for fun I converted the same clip using the LoudNorm filter which is part of current FFmpeg versions. Since I do not like the defaults all that much I used the following parameters:
SET LUFS=-18.00
REM Target Loudness in LUFS
SET TruePeak=-1.5
REM Target True Peak value
SET L_Range=14
REM Target Loudness Range

I used 1-pass mode which of course has problems reaching the desired loudness values, but is much faster. The result came out like this:
Integrated Loudness: -16.27 LUFS
Sample Peak: -0.96 SPFS

To my ears this conversion did sound a little better than DynAudNorm, and it has the advantage that a target LUFS level can be specified.

Cheers
manolito

kolamorx

31st July 2017, 11:25

I don't think so. An amplification factor of 100× already is equivalent to +40 dB.
I mistakenly thought it's equivalent to +20 dB...
To my ears this conversion did sound a little better than DynAudNorm, and it has the advantage that a target LUFS level can be specified.
I prefer dynaudnorm since it evens out the volume better.

smok3

31st July 2017, 11:28

Anyone using loudnorm and if so with what settings? Defaults are kinda ok, if a little sissy (lacks a bit of dynamics).

Have this in mpv input.conf
F1 cycle-values af "lavfi=[dynaudnorm=s=30]" "lavfi=[loudnorm]" ""

manolito

31st July 2017, 14:00

The effect of LoudNorm depends a lot on the parameters, it goes from subtle to very strong dynamic compression.

These are the FFmpeg defaults:
I, i
Set integrated loudness target. Range is -70.0 - -5.0. Default value is -24.0.

LRA, lra
Set loudness range target. Range is 1.0 - 20.0. Default value is 7.0.

TP, tp
Set maximum true peak. Range is -9.0 - +0.0. Default value is -2.0.

The target Integrated loudness is quite low, it complies to the ATSC standard. For EBU R128 it would be -23, for ReplayGain it is -18.

The target loudnesss range is small, it results in a strong dynamic compression.

True peak is OK, maybe it could be increased a little to -1.5 or even -1.

There is a GUI for LoudNorm called WinLoud (by Muxson). His defaults are optimized for podcasts, see them here:
http://www.muxson.com/winloud

The author of Loudnorm prefers different values again:
http://k.ylo.ph/2016/04/04/loudnorm.html

And myself I do not want too strong dynamic compression, and my target level is Replaygain. So I use
Target Integrated Loudness: -18 LUFS
Target Loudness Range: 14 dB
Target True Peak Level: -1.5 SPFS

Takes a little experimentation to find your preferred settings.

Cheers
manolito

smok3

31st July 2017, 15:17

Hmm, 7dB seems like it should be enough of dynamics, I guess I'll have to measure and compare that with something. p.s. I don't use anything-win.

LoRd_MuldeR

31st July 2017, 21:52

The loudness values are almost identical for both conversions. At least for "sane" source audio levels it is not necessary to apply regular peak normalization before DynAudNorm.

Yes, with a properly produced/leveled recoding, the "loudest" peaks in the file should already be at maximum signal level, or just below the maximum signal level.

In that situation a "traditional" (non-dynamic) normalizer will do exactly nothing, because the "loudest" peaks prevent further amplification without clipping. But a tool like DynAudNorm (or maybe LoudNorm) might be used to bring up the "quiet" sections a little more – provided that there are some long enough "quiet" sections that are significant quieter than the "loudest" sections. Still, after such processing, a "traditional" (non-dynamic) normalizer will again do exactly nothing, because the "loudest" peaks still are at maximum signal level (or just below) and therefore further amplification is still prevented. Summary: With a properly produced/leveled recoding, a "traditional" normalizer is pretty pointless.

My point was: If you have a poorly leveled recording, where even the "loudest" peaks are way below the maximum signal level, i.e. the recording does not utilize the complete signal range, then the first step should be using a "traditional" (non-dynamic) normalizer in order to get rid of the unused "headroom". A tool like DynAudNorm is not needed (and probably not the best choice) for that purpose. If and only if, after the "traditional" (non-dynamic) normalization you still think that the volume of the "quiet" sections should be brought up more closely to the "loud" sections, then a tool like DynAudNorm is the right tool. Used in the right way, a max. amplification factor of 100× should be more than you'll ever need.

hydra3333

2nd September 2017, 11:54

Anyone using loudnorm and if so with what settings? Defaults are kinda ok, if a little sissy (lacks a bit of dynamics),

Not sure if this is what you mean ... I use loudnorm in ffmpeg to try to adjust recordings all to a usable level. Here's the code lifted directly from my script without all relevant variables defined, so buyer beware.
REM snip

set audiofreq=48000
set audiobitrate=384k
SET audiodelayadjms=010
set AudioDelayms=000
REM audiodelayadjms delays audio just a tad extra .01s so that it comes out after the lips move
REM AudioDelayms is the final calculated delay for audio with audiodelayadjms added to it
SET lI=-16
SET lTP=0.0
SET lLRA=11

REM snip

REM to adjust Audio volume. find the loudness parameters in a first pass
ECHO !DATE! !TIME! ***************************** start Find Audio Loudness ***************************** >> "%vrdlog%" 2>&1
ECHO file "%~f1" ...
ECHO "%ffmpegexex64%" -threads 0 -nostats -nostdin -y -hide_banner -threads 0 -i "%~1" -vn -threads 0 -af loudnorm=I=%lI%:TP=%lTP%:LRA=%lLRA%:print_format=json -threads 0 -f null - >> "%vrdlog%" 2>&1
"%ffmpegexex64%" -threads 0 -nostats -nostdin -y -hide_banner -threads 0 -i "%~1" -vn -threads 0 -af loudnorm=I=%lI%:TP=%lTP%:LRA=%lLRA%:print_format=json -threads 0 -f null - 2> "%jsonFile%"
SET EL=!ERRORLEVEL!
IF /I "!EL!" NEQ "0" (
Echo ********* Error !EL! was found >> "%vrdlog%" 2>&1
Echo ********* Error !EL! was found >> "%vrdlog%" 2>&1
Echo ********* Error !EL! was found
Echo ********* ABORTING ... >> "%vrdlog%" 2>&1
%xpause%
EXIT !EL!
)
REM all the trickery below is simply to remove quotes and tabs and spaces from the json single-level response
set input_i=
set input_tp=
set input_lra=
set input_thresh=
set target_offset=
for /f "tokens=1,2 delims=:, " %%a in (' find ":" ^< "%jsonFile%" ') do (
set "var="
for %%c in (%%~a) do set "var=!var!,%%~c"
set var=!var:~1!
set "val="
for %%d in (%%~b) do set "val=!val!,%%~d"
set val=!val:~1!
REM echo .!var!.=.!val!.
IF "!var!" == "input_i" set !var!=!val!
IF "!var!" == "input_tp" set !var!=!val!
IF "!var!" == "input_lra" set !var!=!val!
IF "!var!" == "input_thresh" set !var!=!val!
IF "!var!" == "target_offset" set !var!=!val!
)
echo input_i=%input_i% >> "%vrdlog%" 2>&1
echo input_tp=%input_tp% >> "%vrdlog%" 2>&1
echo input_lra=%input_lra% >> "%vrdlog%" 2>&1
echo input_thresh=%input_thresh% >> "%vrdlog%" 2>&1
echo target_offset=%target_offset% >> "%vrdlog%" 2>&1
REM check for bad loudnorm values ... if baddies found, use dynaudnorm instead
set AUDprocess=loudnorm
IF /I "%input_i%" == "inf" (set AUDprocess=dynaudnorm)
IF /I "%input_i%" == "-inf" (set AUDprocess=dynaudnorm)
IF /I "%input_tp%" == "inf" (set AUDprocess=dynaudnorm)
IF /I "%input_tp%" == "-inf" (set AUDprocess=dynaudnorm)
IF /I "%input_lra%" == "inf" (set AUDprocess=dynaudnorm)
IF /I "%input_lra%" == "-inf" (set AUDprocess=dynaudnorm)
IF /I "%input_thresh%" == "inf" (set AUDprocess=dynaudnorm)
IF /I "%input_thresh%" == "-inf" (set AUDprocess=dynaudnorm)
IF /I "%target_offset%" == "inf" (set AUDprocess=dynaudnorm)
IF /I "%target_offset%" == "-inf" (set AUDprocess=dynaudnorm)
REM
REM later, in a second encoding pass we MUST down-convert from 192k (loadnorm upsamples it to 192k whis is way way too high ... use -ar 48k or -ar 48000
REM
IF /I "%AUDprocess%" == "loudnorm" (
ECHO "Proceeding with normal LOUDNORM audio normalisation ..." >> "%vrdlog%" 2>&1
ECHO "Proceeding with normal LOUDNORM audio normalisation ..."
set loudnormfilter=loudnorm=I=%lI%:TP=%lTP%:LRA=%lLRA%:measured_I=%input_i%:measured_LRA=%input_lra%:measured_TP=%input_tp%:measured_thresh=%input_thresh%:offset=%target_offset%:linear=true:print_format=summary
echo "loudnormfilter=%loudnormfilter%" >> "%vrdlog%" 2>&1
) ELSE (
ECHO "********* ERROR VALUES DETECTED FROM LOUDNORM - Doing UNUSUAL dynaudnorm audio normalisation instead ..." >> "%vrdlog%" 2>&1
ECHO "********* ERROR VALUES DETECTED FROM LOUDNORM - Doing UNUSUAL dynaudnorm audio normalisation instead ..." >> "%vrdlog%" 2>&1
ECHO "********* ERROR VALUES DETECTED FROM LOUDNORM - Doing UNUSUAL dynaudnorm audio normalisation instead ..."
ECHO "********* ERROR VALUES DETECTED FROM LOUDNORM - Doing UNUSUAL dynaudnorm audio normalisation instead ..."
set loudnormfilter=dynaudnorm
echo "loudnormfilter=%loudnormfilter% (Should be dynaudnorm)" >> "%vrdlog%" 2>&1
)
ECHO !DATE! !TIME! ***************************** end Find Audio Loudness ***************************** >> "%vrdlog%" 2>&1
REM ------------------------------ audio conversion ------------------------------
echo !DATE! !TIME! ***************************** start ffmpeg %makeaudiotype% AUDIO conversion ***************************** >> "%vrdlog%" 2>&1
REM mp3 audio conversion "%~f1" ...
IF /I "%makeaudiotype%" == "mp3" (
ECHO mp3 audio conversion "%~f1" ... >> "%vrdlog%" 2>&1
ECHO mp3 audio conversion "%~f1" ...
ECHO "%ffmpegexex64%" -threads 0 -nostats -threads 0 -i "%~1" -threads 0 -vn -threads 0 -map_metadata -1 -af %loudnormfilter% -c:a libmp3lame -ab %audiobitrate% -ar %audiofreq% -threads 0 -y "%parmp3%" >> "%vrdlog%" 2>&1
"%ffmpegexex64%" -threads 0 -nostats -threads 0 -i "%~1" -threads 0 -vn -threads 0 -map_metadata -1 -af %loudnormfilter% -c:a libmp3lame -ab %audiobitrate% -ar %audiofreq% -threads 0 -y "%parmp3%" >> "%vrdlog%" 2>&1
SET EL=!ERRORLEVEL!
IF /I "!EL!" NEQ "0" (
Echo ********* Error !EL! was found >> "%vrdlog%" 2>&1
Echo ********* Error !EL! was found >> "%vrdlog%" 2>&1
Echo ********* Error !EL! was found
Echo ********* ABORTING ... >> "%vrdlog%" 2>&1
%xpause%
EXIT !EL!
)
)
REM aac audio conversion "%~f1" ...
IF /I "%makeaudiotype%" == "aac" (
ECHO aac audio conversion "%~f1" ... >> "%vrdlog%" 2>&1
ECHO aac audio conversion "%~f1" ...
ECHO "%ffmpegexex64%" -threads 0 -nostats -threads 0 -i "%~1" -threads 0 -vn -threads 0 -map_metadata -1 -af %loudnormfilter% -c:a libfdk_aac -cutoff 18000 -ab %audiobitrate% -ar %audiofreq% -threads 0 -y "%paraac%" >> "%vrdlog%" 2>&1
"%ffmpegexex64%" -threads 0 -nostats -threads 0 -i "%~1" -threads 0 -vn -threads 0 -map_metadata -1 -af %loudnormfilter% -c:a libfdk_aac -cutoff 18000 -ab %audiobitrate% -ar %audiofreq% -threads 0 -y "%paraac%" >> "%vrdlog%" 2>&1
SET EL=!ERRORLEVEL!
IF /I "!EL!" NEQ "0" (
Echo ********* Error !EL! was found >> "%vrdlog%" 2>&1
Echo ********* Error !EL! was found >> "%vrdlog%" 2>&1
Echo ********* Error !EL! was found
Echo ********* ABORTING ... >> "%vrdlog%" 2>&1
%xpause%
EXIT !EL!
)
)
echo !DATE! !TIME! ***************************** end ffmpeg %makeaudiotype% AUDIO conversion ***************************** >> "%vrdlog%" 2>&1

REM snip

Sill reconsidering dynanorm as the default.

smok3

4th September 2017, 15:22

^ That any different than ˇ ?
mpv --af=lavfi=[loudnorm] file.mp4
edit: Oh I see, your LRA is higer than default.

To test:
af=lavfi=[loudnorm=LRA=10]

osgZach

12th December 2017, 04:02

Just a quick question, and an observation if you will... (this is a big thread)

Q: How concurrent is the ffmpeg filter with your source builds? In terms of any major improvements. I'm probably going to be writing myself a huge script of some sort, or maybe even a program, to automate batch processing of audio tracks from movies (I'm trying to automate the whole encoding chain really, video, subs, etc), so the less tools I have keep track of the better. Keeping it all inside ffmpeg would be preferable.

The observation: I think someone may have posted something similar to this a few pages back, but I've pretty much been up and down the race track trying out different methods of downmixing multichannel (5.1, 7.1) audio tracks to Stereo and avoiding the dynamic range problems associated with it. At first when I was playing with dynaud in ffmpeg, I wasn't noticing much difference, then I downloaded the CLI off Mulder's repo, and noticed a big improvement in reaching what I was trying to achieve.

The one major difference was when I used Mulder's CLI I was operating on a Stereo track generated from ffmpeg with -ac 2. while trying the filter in ffmpeg though I was feeding it the AC-3 source directly though (I did throw -ac 2 before the filter also). There is a distinct difference in my opinion. So I re-ran the Stereo track through ffmpeg and got pretty much the same result as using the separate CLI . I'm not an audio expert by any means, but I would say there is around a 1dB difference or more in loudness. Is there a reason for that?

It seems like for my workflow I need to generate a Stereo track as an intermediate file, and then re-filter that file to get my final output.
It goes pretty fast so I don't really care, just found it odd.

if needed I can probably find some time to trim a sample clip and provide an example package if that suits you.

sneaker_ger

12th December 2017, 12:18

(I did throw -ac 2 before the filter also)
Does this really ensure the down-mix comes before the audio filtering (e.g. dynaudnorm)? I guess not.

LoRd_MuldeR

12th December 2017, 15:13

Just a quick question, and an observation if you will... (this is a big thread)

Q: How concurrent is the ffmpeg filter with your source builds? In terms of any major improvements.

There haven't been any significant improvements to the "core" algorithm, only a few fixes here and there.

kolamorx

7th May 2018, 12:32

LoRd_MuldeR

7th May 2018, 19:02

Hello.
I've read your documentation about the maximum gain factor, that ususally it's not recommended to increase the value above the default but sometimes it may be necessary to allow higher gain factors.
So if I understood correctly (and from my experience), when you have to allow higher gain factors, it's better to set it as less value as possible.

No matter what you do, the gain factor for each frame will never be allowed to exceed the frame's local max. gain factor – the maximum that this particular frame could be amplified without any clipping (distortion).

Furthermore, the actual gain factor applied to a frame will usually be even lower than the "local max. gain factor", because we apply a minimum filter followed by a Gaussian smoothing filter to each "neighborhood" (sliding window) of frames.

The "max. gain factor" option is an additional hard limit on the maximum gain factor that can be applied to frame. This mostly exists to avoid humongous amplification factors in extremely quiet (almost silent) sections of the file.

What free tool for Windows do you recommend for volume measurement, so I can get data about the dialogue volume levels in some scenes per movie (which sometimes are very low), in order to set the maximum gain factor as less value as possible?

This tool, for example, can create a graph of the "loudness" (ITU BS.1770 and CBS) of a given file:
https://www.orban.com/meter/

kolamorx

8th May 2018, 12:24

No matter what you do, the gain factor for each frame will never be allowed to exceed the frame's local max. gain factor Â– the maximum that this particular frame could be amplified without any clipping (distortion).
I know it, that's not what I meant.
Let me put it this way: if I set the maximum gain factor to too high value for a certain movie, sounds like breathing could have too high volume and that's a problem.
On the other hand, if I set the maximum gain factor to too low value for a certain movie, the dialogue volume could be too low comparing to the sound effects and music volume and that's a problem too.
Am I right?

LoRd_MuldeR

8th May 2018, 18:53

I know it, that's not what I meant.
Let me put it this way: if I set the maximum gain factor to too high value for a certain movie, sounds like breathing could have too high volume and that's a problem.
On the other hand, if I set the maximum gain factor to too low value for a certain movie, the dialogue volume could be too low comparing to the sound effects and music volume and that's a problem too.
Am I right?

Nope, not really.

The DynamicAudioNormalizer will amplify each part of the file, which is quieter than the target volume, so that it is brought up to the target volume. Also it will attenuate each part of the file, which is louder than the target volume (if any such part exists), so that it is brought down to the target volume. In the end, all parts of the file will have "equal" volume. Of course, that all combined with Gaussian smoothing in order to avoid fast fluctuation of the gain factors.

Now, what the "maximum gain factor" option really does: It imposes an additional limit on how much a "quiet" frame may be amplified in order to reach the desired target volume. The default "maximum gain factor" value, which is 10.0×, should be enough for most needs. But it can, of course, be increased, if it should really be needed. Anyhow, probably the vast majority of your frames (if not all of them!) will not need more amplification than what the default "maximum gain factor" value allows. And again: This is only an upper limit, not the actual amount of gain that will be applied! The actual gain factor will be determined dynamically for each frame, and it probably will be way lower than the limit in most cases!

The "maximum gain factor" limit exists primarily in order to avoid humongous amplification factors in extremely quiet (almost silent) sections of the file. If there was no such limit, it could easily result in excessive amplification factors in those extremely quiet sections – which you do not want. If we'd amplify extremely quiet (almost silent) sections by such an excessive amount, the result will sound very "noisy", because the quantization noise becomes audible...

(I suggest you let DynamicAudioNormalizer write a log file and inspect that log file in DynamicAudioNormalizer GUI, which will easily show whether you run into the limit or not)

JuliusJac

19th December 2018, 15:43

LoRd_MuldeR

19th December 2018, 16:50

Hei,

I know this Thread is rather old. But I have been searching the internet, and tried myself for 2 full days :( with almost no result. We have several hundred videofiles where the "volume" changes within the soundtrack. And I was trying all/a lot. But no loudnowm or dynaudnorm setting I use seems to giv an acseptable result.? can anyone Help me?

Here is one of the arguments I tried:

$ ffmpeg -i testin.mp3 -af "dynaudnorm=p=0.8:m=25:r=0.5"

Here one of our examples
testin.mp3 (https://drive.google.com/open?id=1fB2QYYf94PbJ9PvNdsbwC8Uw3vjfP3KD)

THANKS and Greetings from Norway

Hello.

Well, what are you trying to achieve? Or what is wrong with DynAudNorm default settings?

DynAudNorm was designed to retain the "dynamics" that exist in each local neighborhood, so that the characteristics of the original audio are preserved. Default settings have been chosen rather conservative.

Anyway, if you want to force DynAudNorm to act more "aggressively", first try decreasing the filter size ("--gauss-size" option). Default is 31, but you may want to try something like 11.

In addition to that, you may also try decreasing the frame length ("--frame-len" option). Default is 500 ms, but you could try 250 ms or even 125 ms. Note that filter size is expressed in frames, so these option mutually influence each other!

(I'm writing about the DynAudNorm CLI options here, because I'm more familiar with that one than with the FFmpeg port, but things should work for FFmpeg just the same way)

Your original:
https://i.imgur.com/LLJtA2d.png?1

DynAudNorm default settings:
https://i.imgur.com/wF3i76R.png?1

More aggressive settings (filter size reduced to 11):
https://i.imgur.com/Pcp2fpm.png?1

Something extreme (filter size reduced to 5 + frame length reduced to 125):
https://i.imgur.com/AGq8Mt9.png?1