WinLoud released. Loudness normalize with Loudnorm.

[rogerdpack]

Thanks very much Muxson for this nice tool...

Regarding the virus alerts this is getting worse all the time with the usual Antivirus software. The WinLoud executables are compiled AutoIt scripts, and many AV tools mark those executables as malware no matter what. The same is true for compiled batch files and for UPXed executables. Just plain stupid, AV software is getting more and more useless these days.

For anyone who is still paranoid, there are some (not exactly legal) AutoIt decompilers available, and Muxson did not make any efforts to conceal his source code. So go ahead and check the code, there is nothing suspicious in it IMO...

This brings me to another question for Muxson:
Neither your website nor the WinLoud download tells me much about your license. Is it GPL, is it just free but not open source, can I use it in one of my plugins I made for other software?

The reason I ask is that I would like to integrate your WinLoudCLI tool into my audio normalization plugin for AVStoDVD, and I would also like to nag the author of DVDStyler to add this method to his software. Right now both these programs can use the normal EBU R128 or the ReplayGain methods with added clipping protection, but there is no way to add a peak limiter (i.e. real dynamic compression) if the target LUFS value would cause clipping. In these cases the target LUFS is decreased to avoid clipping, but of course this is counterproductive if your goal is a constant perceived loudness.

Whatever, thanks again for this nice tool,
I wish you and everyone else on this forum a very Happy New Year...

Cheers
manolito

Or just integrate FFmpeg itself, since I think that's what WinLoud uses somehow or other under the covers (useful indeed).

It appears libebur is LGPL
libavfilter/ebur128.c
so hopefully you're good there, just build an LGPL ffmpeg anyway that has it (my script has an option for it here https://github.com/rdp/ffmpeg-windows-build-helpers as well, if helpful.
Cheers!
-roger-

[manolito]

@ Muxson
Just did a few tests to determine if WinLoudCLI really is to blame for the slow speed, and yes it is...

I used a WAV file with a length of 8min, used the 1-pass mode to convert it to LUFS -18, Range 11 and TP -1.5.
Results:
WinLoud GUI: 15min 30sec
GUI but pausing the WinLoudCLI from the taskbar icon: 8min 00sec
Using FFmpeg Loudnorm directly: 7min 45sec

Pausing the WinLoudCLI of course disabled the progress bar in the GUI, but for this large speed gain this is worth it, at least for me.


@ roger
Thanks for the tip. Using FFmpeg directly for my plugin is easy for 1-pass mode, but implementing 2-pass mode is a pain with the Windows Batch language. Being the lazy person I am I would much prefer if someone else did this work for me. And Muxson also added a SMART mode where the decision between 1-pass and 2-pass is made automatically, and I like this mode very much.


So all I am waiting for are some speed optimizations...

Cheers
manolito

[Muxson]

manolito, I found the bug!

Will send you the CLI update in PM and publish an full update... next year.
Thanks for your valuable inputs.

[manolito]

Yes, the test release fixes it, thanks a lot. It is just a tad slower than with the script paused, but this is probably due to the FFmpeg progress calculation. (Would you care to explain the bug?)

I just found another small bug:
For the sample frequency this is what the CLI help says:

-FREQ <freq> Sample Frequency in Hz (Default: 44100)
<freq>: 32k, 44100, 48k
If not specified: as original

The "If not specified" line does not work. I converted a WAV file with an 48k sample rate without using the -FREQ parameter, and the result came out at 44100 sample rate. You should also update the GUI to offer the option "As Original" for the sample rate.

Have a great 2017,
Cheers
manolito

[Muxson]

Version 1.1 released on http://www.muxson.com/winloud

Would you care to explain the bug?

I was reading the FFmpeg StdErr too often.

I just found another small bug:
For the sample frequency this is what the CLI help says:

-FREQ <freq> Sample Frequency in Hz (Default: 44100)
<freq>: 32k, 44100, 48k
If not specified: as original

Correct, that was a mistake. It is corrected in the new release, but not the way you think!
Let me explain.

I initially thought that the Loudnorm FFmpeg filter would act that way, i.e. output a file that has the same Sampling Frequency as the input file.
But soon realized it is not the case. If the Samp. Freq. is not specified, it output a 192 kHz file. It has to do the the ISP calculation I believe.
--> BTW, I wonder if that could explain the processing speed?!

The plan was to implement that feature but it turned out to be a bit more involved. I may work on it for the next release.
In the meantime, you have to chose one of the 3 Sampling Frequencies, 44.1 kHz being the default.
--> The Sampling Frequency has actually much less impact on the quality than many people think.
--> For fixed Bit Rate encoding such as mp3, the lower the Sampling Frequency, the less losses!! But this is not the place to debate this...

[manolito]

Thanks for the new version, looks good...

If the Samp. Freq. is not specified, it output a 192 kHz file

Yes, the blog post of the LoudNorm author explains that for accurate TruePeak detection the audio is upsampled to 192kHz. Of course it makes sense to use an upsampled file for the analysis, but for applying the processing I think the original source file should have been used. The way it works now the source has to be resampled twice, and audio resampling is not lossless so it should be avoided if possible. BTW I wonder how good the FFmpeg resampling algorithm is...

Whatever, your tool is now perfect for me, I will start right away to integrate it into my AVStoDVD plugin...

BTW I went over your source code real quick, I think this is very good programming. (But you did not write all the user functions for arrays and JSON yourself, did you?)


Cheers
manolito

[Muxson]

Whatever, your tool is now perfect for me, I will start right away to integrate it into my AVStoDVD plugin...

Nice, thanks. Have fun with it!

[manolito]

Thanks, I already do have fun with it...

First of all I discovered that the slow speed issue is not completely fixed. When I force 2-pass through the command line only the first pass is fast. For the second pass WinLoudCLI again consumes more than 40% of my CPU cycles.

And I have another problem where I could use some help. The basic integration into my plugin (which is just a batch file) worked immediately, but I would like to write a log file. And this log file should just have the summary for every source, I really do not want the progress messages in it.

What I tried so far is to add a "ConsoleWriteError" command for the summary, then I redirected STDERR to the log in my batch file (2>my_log_file.txt). This worked nicely for the log file, but somehow redirecting STDERR also disabled STDOUT for my console window. No more progress messages. Do you have a better idea? Should I better write directly to a file from WinLoudCLI?


Cheers
manolito

[Muxson]

... I discovered that the slow speed issue is not completely fixed.

You are so sharp manilito! Totally right.
Is already fixed. Will be published in the coming days with the "as original" option for the Sampling Frequency.

I still have to take care of the fact that mp3 supports only a limited list of frequencies where wav supports (m-)any.
That is for the case where a wav file with a non-mp3-supported frequency is loaded...
I will probably have a fall-back to 44.1 kHz is such case.

The solution for you logging question is that I actually use StdErr for the progress and StdOut for the results.
I was anyway thinking about this as it seams to the proper way to do it.
I will work on it for the next update, so stay posted.

And by the way,

... there are some (not exactly legal) AutoIt decompilers available, and Muxson did not make any efforts to conceal his source code. So go ahead and check the code, there is nothing suspicious in it IMO...

Decompiling is not only "not exactly legal" but completely illegal, so please don't do it. And if you do (I'm not naive about it...), don't publish it! You risk being banned from the community and expose yourself to legal actions!
And on more thing: there is no point in "making efforts to conceal the source code". Every code can be cracked, it is only a matter of time.
My approach is to forget it and concentrate on constructive things...
Ill got, ill spent! You have nothing to gain on the long run with such attitude.

[manolito]

Regarding the last paragraph of the previous post I do see things a little differently...

First of all AutoIt had an official decompiler which worked for scripts compiled with AutoIt v3.2.5.1 and earlier. Only after this version they changed their mind.

From one of your previous posts: I would gladly share the code, but it seems you cracked it already!! Gives me the impression that publishing your source code is OK.

US and European laws both define exceptions where decompiling is explicitly allowed for ensuring interoperability with other software.

Reverse engineering (even if declared illegal by a license) is common practice everywhere in the software industry.

I went over the creativecommons license you linked to, and the words "decompile" or "disassemble" or "reverse engineering" are nowhere to be found. It is not obvious to a user that the software author does not allow decompiling.

My reason for doing this is strictly for educational purposes, I want to learn. Of course I would not publish any source code, but just mentioning that I did use a decompiler falls under the Freedom of Speech.

Anyways, I already made the decision to not use WinLoud for my AVStoDVD plugin and use Loudnorm directly, mainly because I do not have much use for the 2-pass mode. It slows down the conversions too much, and for my purposes the results from 1-pass mode are more than adequate. I compared a few conversions made with 1-pass and with 2-pass. While 2-pass does a better job to reach the desired target values, these differences are hardly audible IMO. (Plus I prefer GPL and Open Source software over other licenses...)


Cheers
manolito