DynamicAudioNormalizer

[LoRd_MuldeR]

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]

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]

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]

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

[LoRd_MuldeR]

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]

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]

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]

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]

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]

@ 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]

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]

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


This is GREAT news LoRd_MuldeR - Thank You Very Much!

[Wantedwaffle]

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]

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]

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

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

[LoRd_MuldeR]

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]

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]

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]

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

[CactusMan]

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]

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

[CactusMan]

@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]

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"

[CactusMan]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[manolito]

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]

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]

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]

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]

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]

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]

... 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]

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]

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]

...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]

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?