FR: Loudness scanning and normalization - new requirements

[AironAudio]

Netflix has just changed its delivery requirements. We now need to use a Dolby dialogue-gated(which is now free code), 1770.1 version of the loudness measurement standard. That's the 1770 standard without a relative gate.

http://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-0-200607-S!!PDF-E.pdf

The libebur128 library has been updated as well, and would need to be modified to bypass the relative and absolute gates.

Why Reaper ?
Speed. I normalize the items of the 5.1 or 2.0 mixes in Reaper with the SWS extension and do the split-to-mono playouts that I need to pack up and send off. With other tools there's at least one more inbetween step, as none of them seem to be able to generate single-channel files. Thus, I'd rather use Reaper, even if I need to get another tool in the meantime. Reaper's just the better tool.

Currently the Loudness portion of the extension uses the BS-1770.3 or 4 method of measuring as well as the EBU R128 recommendation.

The whole thing is based on this article which links to the actual recommendations:
https://www.pro-tools-expert.com/home-page/2018/9/18/netflix-respond-to-our-article-on-their-new-loudness-delivery-specs

Basically it's a dialogue gate whose output is scanned by the ITU 1770-1 method. We're using the pure 1770-3 method irrc, or perhaps even 1770.4.

The code for the Dolby dialogue gate is completely free. It's available on request via this link : https://www.dolby.com/us/en/technologies/speech-gating-reference-code.aspx

The Netflix recommendation is here: https://help.prodicle.com/hc/en-us/articles/360001759947-Netflix-Audio-Mix-Specifications-and-Best-Practices

Reaper's extension architecture just lends itself so well to offline scanning, that I'm hoping there's a programmer with a spare few hours to slot in an extra mode in to the existing Loudness portion of the SWS extension.

I've got no C++ IDE experience at all, or I'd try to do this. I'd donate a good chunk to get this in to the SWS extension. The tools to do it more slowly than in Reaper cost at least $400, so I'd be perfectly willing to drop at least $200 in donations.

[AironAudio]

After filling out the form on the Dolby site, you can download the code right away. Nobody sits there approving any organization or person.

Checking the "Dolby Dialogue Intelligence" code, it's very well documented pure ANSI C. It converts the input to 16kHz, runs it through a bunch of detectors and combines the results to get a value on whether speech is there or not. That probably has to be used to control a gate or volume parameter across the sections.

Still studying the stuff.

[nofishonfriday]

Just took a look at the Dolby Dialogue Intelligence source files, it says:

This program is protected under international and U.S. copyright laws as an unpublished work. This program is confidential and proprietary to Dolby Laboratories. Reproduction or disclosure, in whole or in part, or the production of derivative works therefrom without the express permission of Dolby Laboratories is prohibited.

Someone may correct me, but I don't think it's possible to incorporate this in SWS, being open source / MIT licensed, is it ?

[AironAudio]

That is correct. For that reason I may need to make an extension all by itself for which the source code can only be made available who have gotten the source from Dolby itself, which is free and only requires filling out that form.

I'm investigating how to do that. I've got Visual Studio installed, got some extension code form Cfillion to start with and the all the other source code, but to be honest, that could take a very long time, because my experience level with C++ is almost zero.

[cfillion]

The foreign (dolby's) source code does not need to be integrated into the open-source codebase. Each interested developer could download their own copy and have the open-source part pick it up at build time (this could somewhat complicate things for automated CI builds which seems to be on the table however.)

Another possibility is to make the dolby code available to SWS's existing loudness code via a DLL (assuming supporting that and 1770.1 doesn't require rewriting the whole thing... in which case re-inventing the wheel from scratch in a new extension might be easier).

[AironAudio]

The DLL approach seems feasible. Thank you. If I can figure out how to make a DLL of that ANSI C code, perhaps someone at SWS can create a modified copy of the existing loudness code from the libebur128 library. The Dolby code is supposed to act as an on/off gate only.

Scan sample block with dialogue gate, gate sample block, scan with 1770-1 loudness scan. That 1770-1 version is just the same without the relative gate in the 1770-3/4 version.

Learning C++ atm, so I don't know how long this might take. Working a lot at the same time too. I'll be asking questions :) .

[nofishonfriday]

@AironAudio
I'm currently in the process of updating the in SWS used libebur128 library to latest version (v1.2.4), something I had in mind to do for longer anyway.
First runs with the EBU provided testfiles look ok so far.
Here's a SWS test version with the updated library:
https://www.dropbox.com/s/kv2383b2tawjiai/reaper_sws64.dll?dl=1

Branch is here:
https://github.com/nofishonfriday/sws/tree/libebur128_-_update_to_v1.2.4

Would be nice if you (or anyone interested) could give it a test drive and compare results with other Loudness scanners if you have a chance. I only have the free r128gain available. Results also seem ok there so far, but it doesn't show short term / momentary max.

Regarding implementing the Netflix loudness scanning in SWS:
An idea would be doing a FR issue for implementing functions to bypass the gating at https://github.com/jiixyj/libebur128 directly, maybe they'll also find it useful.

This would save us from doing the mod ourselves

[AironAudio]

Finally found time to do a couple of scans. I'm currently evaluating another application, Nugen LM Correct.

The 1770-4 scans from that matches the updated library you posted for integrated loudness. The maximum short term (3 second loudness) and maximum momentary does vary a bit. LM Correct gets higher values quite consistently, so they must be measuring stuff a little differently.

The files that have to check out are the test files. I got them here:
https://tech.ebu.ch/publications/ebu_loudness_test_set

And here's a spread sheet of exported stuff from the Loudness window for all those files.
https://www.dropbox.com/s/b548kfxwolwy1cu/SWS%20-%20libebur128%20v142%20-%201770-4%20scans.ods?dl=0

What these values need to be is detailed here: https://tech.ebu.ch/docs/tech/tech3341.pdf on page 10+

and here https://tech.ebu.ch/docs/tech/tech3342.pdf

They all check out for "file based" scanners as far as I can tell, except for the seq-3341-13-*.wav files. Those are the only ones that do not check out, so there's something up with the momentary calculations. Only the first file, seq-3341-13-1-24bit.wav check out at -23 LUFS maximum momentary loudness.

This is something we need to post for the libebur128 guys too.

Other than that, it's all great. Integrated loudness over entire mixes all check out file, as do all the true-peak measurements, which I never use however, since my oversampled limiter takes care of those.

[nofishonfriday]

That's helpful, thanks.

I just did a loudness scan with the EBU testfiles with the libebur v1.0.1 that's used in SWS currently and I get the exact same results (also short term / momentary max.) as with my updated v1.2.4 version, so I'm not even sure if it's even worth updating the lib (seems none of the fixes affect us). The lib is quite modified for use in SWS so the updating was not that straight forward and may have introduced new issues during my update process.
I'll probably submit it to SWS as optional pull request requesting a review.

[nofishonfriday]

Posted at libebur128 about the seq-3341-13-* files, seems the issue is on our end.
jiixyj/libebur128#93

Will try to look into it.

[audionuma]

Concerning max momentary issue, see my comment on the libebur128 closed issue:
jiixyj/libebur128#93 (comment)

[nofishonfriday]

Found the culprit, thanks to @audionuma's hint.

[BeyondVertical]

@nofishonfriday: When can we use it in SWS? I had also noticed this when testing with the EBU files.

[AironAudio]

Nice one. With that we have 1770-4 compliance.

Next thing on my bucket list is trying to make a DLL out of the Dolby Dialogue Gate code. I've got most of the stuff installed and tutorials at hand, because I realize it's an extremely niche thing I need.

I'm using the Nugen LM Correct tool atm, and it's a bit slow. You can't turn off truepeak scanning, and I only analyze files and do all the gain changes in Reaper anyway, because that's where I render to multiple mono files with the limiter of my choice, and across as many episodes as I need. The Nugen tool is one-at-a-time and has no drag'n'drop. No commandline version either.

That's my motivation to get the Dolby Dialogue Intelligence Gate in to the SWS extension. I'm hoping it won't take terribly long. Breeder is terribly busy.

I will ask questions once I get that library compiled somehow. Maybe even create a little extension. Who knows.