FFAStrans forum

I would like to suggest adding the ability to conform to arbitrary true peak limits. The loudness block already asks for a peak variable. This would allow compliance with non EBU specs. Some content distributors want very high program loundess as well as peak limits. Here is Amazon's tech doc on the subject https://developer.amazon.com/fr/docs/fl ... ntent.html. In short they want an LRA of -14 with a true peak limit of -2. Google's specs are very similar. Currently FFASTrans can comply with arbitrary LRA requests, but has no way to force true peak limiting without a custom FFMPEG block using loudnorm. Requesting a "conform to" value of -14 in a FFASTrans encoder block works, but usually results in a true peak of nearly 0.

Apologies if I missed how to do this with the current functionality.

Thank's for the request crispyjones! I will take a look at it.

-steinar

crispyjones speaks to me from the heart.
may it possible to have simultaneously conform loudness and true-peak-limiting in the xdcam-encoder?
transwrap in the xdcam-encoder in version 0.9.2 is a great feature which would make it even more worth than it already is

I have looked into it and it's a bit more challengig than it might seem: Modifying one thing (max peak or loudness) affects the other, which in turn affects the one you modified in the first place. So it's a contiunous adjustment of the two parameters until you reach something which is true to specs. Of course, I'm not an audio expert and there might be ways to do it in one go that will work, but I have not found it yet. But I WILL look deeper into the matter.

-steinar

Thanks for your efforts steinar!

Yes, thanks for your efforts looking into this. I've used this ffmpeg loudnorm filter in two pass mode to get very accurate results. It has issues that make it difficult to work with, it has a limited number of supported file types and it's audio only.I managed to make an extremely clunky loudnorm workflow in an earlier version of FFAStrans before the loudness node existed. It required Ruby on the machine, had filename parsing problems, was audio only, and wasn't trustworthy for production. Using it in a video workflow involves demuxing the audio, running the two pass algorithm and then remuxing the audio with all the problems that can add. My idea was to use FFAStrans variables generated from the new loudness node to populate the meausured TP and I values in a custom ffmpeg block running loudnorm. Unfortunately I haven't had the time to devote to it, and I just can't get the hang of how FFAStrans moves variables between blocks. If do make any progress I'll be sure to post the results.

Hi All,

My use case is the need to conform input .WAV files to .MP3 while changing the dynamics to hit -16 LUFS and -3 true peak for podcast purposes.

Has any progress been made on using the FFMPEG in two pass mode within FFAStrans or in FFAStrans itself being able to use variable targets from the EBU spec? I'm able to use FFMPEG with custom string of "-af loudnorm=I=-16:TP=-3 -ab 128k -ar 44100 -f mp3" but that only does the single pass.

Hi jonathonz, thank you for using FFAStrans and welcome to the forum!

I was working on this a while ago and have a proof of conept, but it's not finished enough for a release. Also, I had to put it to rest for a while because of other work. The problem with setting both LUFS and TP is that the one affects the other. So it's a kind of contant adjustment of both until you reach your values. Hopefully we will get there soon

-steinar

Thanks for the response! And the welcome. Building workflows is very satisfying.

We’re auditioning minnetonka audio tools server expressly for this purpose of intelligent audio normalization given the complexities which you already know. But it’s amazing what can be done just with these free tools.

Thanks so much for sharing all your hard work. I hope to have my first FFAStrans workflow in production soon.

Take care,
-Jonathon

Hi,

As an update, I ended up using ffmpeg-normalize (https://github.com/slhck/ffmpeg-normalize) and building it into the workflow. It made the workflow more complex as I needed to drop the output file of the normalization into a special folder, and then use compspec commands to complete some file moves because I couldn't figure out how to pass back to FFASTrans the output file created by calling the ffmpeg-normalize process, but was able to work around the complications and now have a workable workflow. Of course now that I write this, I see that I can probably eliminate those custom commands by adding in a second watch folder to re-grab the output. Hmm...