I guess loudnorm can do this.

I don't even think any special code is necessary. The trouble is, we need to establish a specific LUFS value as normative (or at least as recommended).

If we e.g. see a LUFS value of -15, lower overall gain by e.g. -6dB. But someone needs to take responsibility for that -21 LUFS ;-)
The trouble is, once we do that, we get complaints that -21 LUFS turned out too high or too low for 'their' content. Then we're back at explaining that even a sophisticated loudness number can't express the proper presentation level for every given content.

I plead guilty for suggesting -20 LUFS in the german translation, but that is triggered only if peak level is too high. Maybe, similar as peak approaching 0dB, we could trigger for too low and too high LUFS and issue hints?

But - LUFS is not defined for DCP. Also, for the intended (broadcast) LUFS use, -23 is the target value. People may confuse that with a suitable LUFS for cinema (which is a higher level than for broadcast).

BTW - there was a discussion about some guy from italy recently having implemented LEQ and applying it to DCPs. Maybe he is working or willing to add his code to FFMPEG? Or maybe he would be willing to add it to DCP-o-matic?

Having LEQ would be a better base for a level suggestion or automation (although I personally use LUFS often to my satisfaction).

BTW - at some point, we may need to deal with that analysis properly between content and DCP related. In many project layouts, content derived R128 numbers mean nothing (e.g. with individual channel files). For some simple 1:1 layouts, content and DCP analysis are identical. I don't think many users understand that difference. One could go as far as disabling R128 for content, and only showing it for DCP.

• Carsten

It is luca dot trisciani at dcp-werkstatt dot ch

I'll contact him about it.

• Carsten

Oops...

https://github.com/lucat/leqm-nrt

By the way - are we sure that R128 in DCP-o-matic is always using the proper channel set for analysis?

• Carsten

Just to say, I have had bad experiences with FFMPEG's loudnorm filter.

I was trying to use it to target -23 LUFS with max true peak no higher than -1dB.

loudnorm filter includes a limiter so you can add gain in order to get to your desired LUFS value, but the limiter brings down the peaks and prevents them going "into the red". Sounds great!

However, in practice, I couldn't get it to work. You have to provide target integrated loudness, max true peak AND loudness range. Problem is, I don't think we care about loudness range, but you have to specify it.

I tried using high loudness range values in the hope that it would be taken as targeting that range as maximum, but it didn't work that way. It prioritised targeting this high range and so didn't increase the LUFS. On the other hand, with a lower range value, it achieved the desired LUFS and max true peak, but often went beyond that and heavily compressed the dynamic range.

I remember one film in particular with a quiet scene where a character meanders through a corn field. It was rendered as a deafening cacophony of bird song and insect noises - what had been subtle background effects were whacked up to the same volume as dialogue.

So, unfortunately I've still found no good way to achieve this. Would be very happy to hear if anyone else has!

I've posted a question about this on Super User and emailed the author of loudnorm filter.

https://superuser.com/questions/1434096/ffmpeg-loudnorm-filter-without-target-range

I think it is not a good idea to deal with this within dcp-o-matic. I think it's good to give an indication about peak and average and LUFS or LEQ(m). But people still need to make their own decisions about the proper level. No software can decide wether a cacophony of bird song and insects is in a lyric nature documentary or a horror movie...

The idea of a tool in DCP-o-matic is to have clear indicators to cinema referenced loudness, and to help in deciding wether it's too soft or too loud.

I think it would be a big improvement if Carl could implement https://github.com/lucat/leqm-nrt in DCP-o-matic. And then find a way to suggest a useful level change to the user. Many users now have to obey TASA or SAWA level recommendations. That is a challenge beyond personal loudness preference.
LEQ(m) would allow this without guessing from LUFS to LEQ(m).

• Carsten

@carl some hacks done to leqm-nrt in my local branch. Working towards a 'push' interface so that it fits well inside analyse_audio_job.cc. Last thing was to remove multiprocessing; now I have to remove the Worker class and inline it into the current caller.

@carsten: can you explain what you mean by "By the way - are we sure that R128 in DCP-o-matic is always using the proper channel set for analysis?"

I guess I was just thinking wether DCP-o-matic or the EBU R128 filter is always using the correct set of audio channels for analysis. What if e.g. we use a 5.1 DCP channel layout, but have only L and R populated? What about 7.1, where 7,8,9,10 are empty? What about HI/VI-N tracks?

• Carsten

Shouldn't a 5.1 DCP with only L/R populated be analysed as if it were a 5.1 DCP with "very quiet" C/Lfe/Ls/Rs? I'll have to look into how the EBU R128 FFmpeg stuff handles channel mappings.

I don't know how that filter works for multichannel. I think there are modules in it that detect typical speech patterns. One would think that it should know something about a dedicated center channel? It may be sufficient to sum everything up - but then at least, we need to take care of HI/VI-N and back surrounds? And these channels (surrounds in 7.1 systems) are calibrated to a lower SPL than the others.

Not trying to make something up here - so far, I haven't been disappointed by the results of the analysis. I now use it for all DCPs that contain audio.

It would probably be sufficient to do some simple test using some special mappings, based on any 5.1 mix:

• put stereo into a 2ch package - memorize LUFS

• put stereo into a 5.1ch package - LUFS should stay the same

• put stereo into a 7.1+HI/VI-N package, map L/R additionally to 7/8 - LUFS should stay the same

• plain 5.1 to a 6ch DCP - memorize LUFS

• map e.g. L/R additionally to 7/8 for an 8ch/ simulated HI-VI-N package - LUFS shouldn't change.

• map e.g. L/R additionally to 11/12 for a simulated 7.1/12ch package - LUFS should increase

OK, those tests should be in the unit testing, I'll add them. First crack at LEQ(m) is in 2.15.52 if anybody wants to try it.

Hmm - how do you build 2.15.52+? I can't find the source for leqm-nrt as a library, which seems to be what's required for newer DCPomatic versions.

leqm-nrt is here: https://github.com/cth103/leqm-nrt