Request for Option in Peak Watcher to report LUFS, or RMS values

[GarthHum]

Requesting additional functionality within Peak Watcher such that the mode could be set to either RMS over a set or configurable window, and/or LUFS momentary /short term / integrated since last reset, or the existing peak value. You would pick the mode within the dialog and than the existing keys could be used for reporting back the results

There's good support for LUFS and RMS from SWS offline analysis, however no way of grabbing the values in real time. Ideally, LUFS would be an option, but no idea of the difficulty of implementation or availability of the appropriate API.

[jcsteh]

I've no idea about these things. In terms of realtime metering, I can only get the level in dB from REAPER. SWS actually pulls the sample data from takes to do its analysis, but you can't do this for realtime, processed audio. Do REAPER's visual realtime meters support this kind of thing? Or can you somehow convert from dB to RMS/LUFS?

[GarthHum]

Visual meters certainly support RMS, and a Reaper Mania video indicates LUFS however I’m less certain about this. Will get some eyes on this in the next day or two.

As for converting from Peak to RMS or LUFS, than I guess RMS would be easier, this would involve storing a number of peaks over the given rolling window. Eg, 400ms worth of samples and averaging this out. I assume for standard visual meters, they don’t actually use every sample to calculate and just grab 1 from every X number of samples to do the calc. LUFS is a bit more involved as it is the RMS value however the audio is basically put through an EQ or K weighting, prior to the RMS calculation, as it is going for perceived loudness. Momentary is the last 400ms, and short-term is a rolling 3sec. Integrated is the whole of what is being measured, however anything below a certain value is removed entirely from the calculation.

Seems like the sort of thing that if isn’t actually available in Reaper’s API to poll, than would bring too much overhead.

On 30 May 2018, at 8:31 pm, James Teh <notifications@github.com mailto:notifications@github.com> wrote:

I've no idea about these things. In terms of realtime metering, I can only get the level in dB from REAPER. SWS actually pulls the sample data from takes to do its analysis, but you can't do this for realtime, processed audio. Do REAPER's visual realtime meters support this kind of thing? Or can you somehow convert from dB to RMS/LUFS? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/166#issuecomment-393112637, or mute the thread https://github.com/notifications/unsubscribe-auth/AeTyix1AR18CTQg533FF6fX2R-iWmsloks5t3nUQgaJpZM4UTAgF.

http://schema.org/ https://github.com/jcsteh/osara/issues/166#issuecomment-393112637 https://github.com/jcsteh/osara/issues/166#issuecomment-393112637 https://github.com/ https://assets-cdn.github.com/images/email/message_cards/header.png https://assets-cdn.github.com/images/email/message_cards/avatar.png https://github.com/jcsteh/osara https://github.com/jcsteh/osara/issues/166#issuecomment-393112637 http://schema.org/extensions https://assets-cdn.github.com/images/email/message_cards/avatar.png https://api.github.com/ https://api.github.com/ https://github.com/jcsteh/osara/issues/166#issuecomment-393112637 https://api.github.com/

[jcsteh]

In essence, I retrieve the peak in dB every 30 ms (the peak since the last check). If it's possible to calculate these things with that level of data, it should be possible to do it in Peak Watcher, in theory. I don't have any understanding of how to do the calculation, though.

[GarthHum]

That may give some useful info, if not the same as RMS, or LUFS. As i understand it, you would need the actual sample value rather than peak in dB since last check. Every 30ms would also be too infrequent for anything other than really large windows I think. The fact that it is peak since last check overcomes the infrequency to a large degree and it might turn out that you get something quite useable but really not sure.

On 30 May 2018, at 10:41 pm, James Teh notifications@github.com wrote:

In essence, I retrieve the peak in dB every 30 ms (the peak since the last check). If it's possible to calculate these things with that level of data, it should be possible to do it in Peak Watcher, in theory. I don't have any understanding of how to do the calculation, though. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/166#issuecomment-393146426, or mute the thread https://github.com/notifications/unsubscribe-auth/AeTyi0Q6JKmj2ahQPsy8imW1hr7ZUSR5ks5t3pN6gaJpZM4UTAgF.

[ScottChesworth]

@GarthHum , would the js Audio Statistics plug-in from TB Software solve this workflow for you? That seems to track LUFS in real time from my admittedly limited testing.

[ScottChesworth]

Just a thought on this, are the SWS loudness tools controllable via API? If so, couldn't they be polled for real-time LUFS/RMS info and reporting be integrated into Peak Watcher somehow?

[jcsteh]

As far as I know, they aren't. Even if they were, my understanding is that they work by analysing the entire audio, which means they probably can't work in realtime. I'm not sure I see how you could do LUFS without analysing a pretty large chunk. Is there any tool in any DAW that does realtime LUFS?

[ScottChesworth]

Tons of metering plug-ins do it in real-time, yeah. Unfortunately, not accessibly. There is one JS plug I know of that does it in a semi accessible fashion (semi-accessible as in the LUFS info is readable with NVDA but not particularly practical to digest due to the frequency of updates). The gap in functionality I'm looking to get filled here is hearing updates over a given threshold, hence why I'm hassling you about Peak Watcher being able to do it. Given that all JS plug-ins are open source, is there any mileage in me linking you to that so you could check how it's analyzing? They're written in EEL, I think.

[ptorpey]

When working on the JSonar scripts for JAWS and Sonar Vic and I added a mode to dynamically display the real-time meter values, positions, etc. in braille. I later extended this functionality to Steve Spamer’s scripts for Samplitude.

By using either a keyboard toggle or braille routing buttons we could switch between several display modes in either program using JAWS scripts. The various display modes included:

• A track status display: This would show the status of items such as mute, record armed, solo, etc. plus the track name
• A time display: this would show the time in either hms or bmt formats
• A meter display: switchable between real time max values, rms values, or ACT values

For the meter values this offered a real-time view of the varying meter values as the project played or was recorded depending on which track had focus. This was handy for folks having a braille display and certainly minimized speech output while providing instant and continuous feedback.

I wonder if any of this can be extended to Reaper?

I checked the Reaper API functions but didn’t see anything that might be helpful in grabbing meter values. There was a track_GetMeterInfo function that returned a double but there was no documentation as to what the return v value was and whether it was pre or post fader. I’m not even clear how or if sighted folks get this info.

Anyway, it would be nice to have some kind of post fader metering on tracks available if possible, but I’m not sure how this can be accomplished even if I tried it with JAWS.

Maybe some food for thought and discussion. If folks have any ideas I would be happy to pitch in where I can.

--Pete

From: ScottChesworth @.> Sent: Sunday, March 28, 2021 2:03 PM To: jcsteh/osara @.> Cc: Subscribed @.***> Subject: Re: [jcsteh/osara] Request for Option in Peak Watcher to report LUFS, or RMS values (#166)

Tons of metering plug-ins do it in real-time, yeah. Unfortunately, not accessibly. There is one JS plug I know of that does it in a semi accessible fashion (semi-accessible as in the LUFS info is readable with NVDA but not particularly practical to digest due to the frequency of updates). The gap in functionality I'm looking to get filled here is hearing updates over a given threshold, hence why I'm hassling you about Peak Watcher being able to do it. Given that all JS plug-ins are open source, is there any mileage in me linking you to that so you could check how it's analyzing? They're written in EEL, I think.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/166#issuecomment-808951355 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEPTJNLJJIDONTOYTXS2ALTF6KRPANCNFSM4FCMBACQ . https://github.com/notifications/beacon/ADEPTJIRYGF2ZKP6JMAUZTTTF6KRPA5CNFSM4FCMBAC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGA3Z4OY.gif

[jcsteh]

JS plugs have access to the sample data. OSARA does not. REAPER's API only provides a way to access peak values. If there's some way to calculate other meter types from peak, it's possible in OSARA. My understanding is that other meter types can't be calculated from peak.

I assume Sonar and Samplitude provide info to sighted users for those meter types, hence JAWS being able to access it?

[ptorpey]

I don’t remember how we accessed the meter values in Sonar. I know that Cakewalk had an SDK that allowed us to grab some parameters and values directly, so it is possible that is what we did.

As for Samplitude, yes, there was a meter display dialog from which JAWS was able to scrape the meter values from the screen.

In both programs I think we were getting post fader values since changes to FX and other parameters were reflected in the meters.

Also, as you say, one cannot calculate other values from just the peak values. One needs data along the entire waveform (unless one is working with a pure sine wave).

I wonder if it is worth a request to Cockos. After all, they do have these values buried in there some place! Then, of course, there is the question of providing pre versus post fader values. It may be hard to get Cockos to do something here since SWS seems to have done it for them, albeit not in a way that is easy for us to deal with.

--Pete

From: James Teh @.> Sent: Sunday, March 28, 2021 3:35 PM To: jcsteh/osara @.> Cc: ptorpey @.>; Comment @.> Subject: Re: [jcsteh/osara] Request for Option in Peak Watcher to report LUFS, or RMS values (#166)

JS plugs have access to the sample data. OSARA does not. REAPER's API only provides a way to access peak values. If there's some way to calculate other meter types from peak, it's possible in OSARA. My understanding is that other meter types can't be calculated from peak.

I assume Sonar and Samplitude provide info to sighted users for those meter types, hence JAWS being able to access it?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/166#issuecomment-808962945 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEPTJP7XGPSRM2DMJAR5H3TF6OHNANCNFSM4FCMBACQ . https://github.com/notifications/beacon/ADEPTJKQ3F2TS6JHO5K3FS3TF6OHNA5CNFSM4FCMBAC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGA34XAI.gif

[jcsteh]

Can we clarify something here? People keep saying SWS has done this. But as I understand it, that isn't realtime. Or is it?

If non-realtime is enough for sighted users, why isn't it enough for OSARA users?

And if it isn't enough for sighted users, then surely sighted users need something from REAPER that neither REAPER nor SWS provide?

And if sighted users do have this already somehow in REAPER, then what do they use? And why can't we use it?

I feel like I'm always getting 10% of the story from people on this and I can never piece together the entire 100%.

[ptorpey]

I tried to find some documentation on how the JS Audio Statistics package works but I didn’t find anything that was very helpful.

I tried an experiment to see what I could figure out. Here is what I did and the results I saw:

• I put the JS Audio Statistics on the Master track. I figured this way it couldn’t be analyzing any static items or tracks with data on it, just analyzing audio levels through the Master.
• I looped a section of audio that had a quiet passage in the middle to see if I could notice meter readings changing in relation to what I heard

Results:

The rms readings do seem to vary in relation to the audio I heard. When the quiet passage was playing the rms values dipped to -40 or so. During the audio that was making noise, values climbed to -20 or so.

I believe that one of the settings in there is how long of a time period over which the rms is calculated. For short times the braille display changed very quickly, as expected.

The peak values seemed to clamp at the maximum, as expected, but I didn’t look at this too much because it didn’t seem to change after it settled down.

Summary: It looks like this plug-in does report real-time values, since the values I saw seemed to cycle as the section of audio I was playing looped. Hard to be 100% sure of what is going on though.

Conclusion: It might be possible to pick up these values from the display when the plug-in is open by scraping the screen with JAWS, but it could get a bit messy. Also there are a lot of other parameters in this display that I don’t understand. I think they might be related to how large of a meter sighted folks see, response time of the meters, etc. Documentation is sparse.

If you have any ideas or other tests I can do let me know. Would be nice to know how sighted folks do this stuff but Googling around on this it seems like other folks have similar questions and everything I read is kind of vague.

Also, I don’t know if this is the appropriate forum for this discussion or not. Perhaps we shouldn’t clutter up the Github forum. Your call if you think this is worth pursuing or not.

--Pete

From: James Teh @.> Sent: Sunday, March 28, 2021 5:33 PM To: jcsteh/osara @.> Cc: ptorpey @.>; Comment @.> Subject: Re: [jcsteh/osara] Request for Option in Peak Watcher to report LUFS, or RMS values (#166)

Can we clarify something here? People keep saying SWS has done this. But as I understand it, that isn't realtime. Or is it?

If non-realtime is enough for sighted users, why isn't it enough for OSARA users?

And if it isn't enough for sighted users, then surely sighted users need something from REAPER that neither REAPER nor SWS provide?

And if sighted users do have this already somehow in REAPER, then what do they use? And why can't we use it?

I feel like I'm always getting 10% of the story from people on this and I can never piece together the entire 100%.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/166#issuecomment-808978815 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEPTJMMUBRAK2LUIURJW63TF64DVANCNFSM4FCMBACQ . https://github.com/notifications/beacon/ADEPTJIY3RHRIAYZG7Y3AP3TF64DVA5CNFSM4FCMBAC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGA4AS7Y.gif

[Lo-lo78]

Hello guys! On Reaper you can't read LUFS in real time; we know that with SWS we have the action: SWS / BR: Analyze loudness ... There is an accessible JS but it is not by default on Reaper, it is called: JS: EBUR128 Loudness Measurement; I know Reaper does not parse LUFS in real time by default, this JS does. I am attaching the JS to you. Greetings!

[Lo-lo78]

This is the attachment... TBProAudio_JSFX.zip

[Lo-lo78]

Excuse me, are we talking about RMS or LUFS? JS Audio Statistics is on Reaper by default but it reads RMS; today we no longer follow RMS, in the mainstram we analyze LUFS. LUFS are a very different thing from RMS! They are two profoundly different topics ...

[ScottChesworth]

Excuse me, are we talking about RMS or LUFS?

We've been talking about both, because right now it's a speculative inquiry whether OSARA is gonna be able to provide productively digestible real-time info. At this point, productive feedback on either unit of measurement would be a big step forward.

Today we no longer follow RMS, in the mainstram we analyze LUFS. LUFS are a very different thing from RMS! They are two profoundly different topics ...

Hmmm, dunno about profoundly different. Sure, LUFS is the superior standard, but I've managed mastering delivered to spec and done plenty of gigs where analyzing RMS has at least gotten me in the ballpark. So, if it were to be the case that RMS was gonna be easier to integrate into Peak Watcher than LUFS, I'd still love to see that happen, even if it's not the most current standard.

[ScottChesworth]

On Reaper you can't read LUFS in real time;

This tutorial from Kenny suggests that LUFS can be displayed in real-time without any third-party plug-ins: https://www.youtube.com/watch?v=0wPnlND92QU The window he's configuring in that video is reachable by running an action called "SWS/BR: Global loudness preferences...". There are however, many details in that video that aren't easy to interpret without description from someone sighted. I'll try to collect more information on his configuration and report back.

[ScottChesworth]

Can we clarify something here? People keep saying SWS has done this. But as I understand it, that isn't realtime. Or is it?

It can be measured and displayed in real-time, as evidenced by the Reapermania tutorial I linked to in the previous comment. If non-realtime is enough for sighted users, why isn't it enough for OSARA users?

Sighted users have a plethora of third-party metering solutions available which can collectively provide information at a glance across a range of measurement scales, whereas right now, OSARA does peaks and that's all she wrote. I'm yet to find a single third-party VST meter that's accessible with a screen reader, and I've downloaded tons of the buggers. The more quantity of paid mastering work ramps up here, the more I'm realising that real-time loudness feedback is a gap I need to get filled to finish up with a decent hourly rate. So essentially, the difference is that to sighted folk, it doesn't particularly matter that Reaper's real-time capabilities seem to be squirreled away because they have plenty of readily available options elsewhere. We don't. And if sighted users do have this already somehow in REAPER, then what do they use? And why can't we use it?

That's the crux of the matter isn't it. I'll get notes written up on that video from Kenny and see what light that sheds. I feel like I'm always getting 10% of the story from people on this and I can never piece together the entire 100%.

Fair point, I probably should've researched reaper's in-built capabilities more before bumping this.

[jcsteh]

There is one JS plug I know of that does it in a semi accessible fashion (semi-accessible as in the LUFS info is readable with NVDA but not particularly practical to digest due to the frequency of updates).

Can you elaborate on this? Why isn't this practical?

The gap in functionality I'm looking to get filled here is hearing updates over a given threshold, hence why I'm hassling you about Peak Watcher being able to do it.

I don't really follow this. I thought the whole point of LUFS is that you're not dealing with peaks, but rather averages over time?

This tutorial from Kenny suggests that LUFS can be displayed in real-time without any third-party plug-ins: https://www.youtube.com/watch?v=0wPnlND92QU The window he's configuring in that video is reachable by running an action called "SWS/BR: Global loudness preferences...".

I'm not convinced that's the same window. The window you mention is definitely an SWS window, not a REAPER window. But if he's right clicking the track meter (which I've seen discussed on the forums), then that is almost certainly a REAPER window.

[jcsteh]

Hacky implementation thought: JSFX allows you to set parameter values from the FX code using sliderX variables. (We may also need to call sliderchange or slider_automate to notify REAPER; I'm not sure.) Could we use a fake parameter to output the LUFS/RMS value and have OSARA monitor that?

[jcsteh]

Given that all JS plug-ins are open source, is there any mileage in me linking you to that so you could check how it's analyzing?

That might be useful given my hacky implementation thought above. It's horrible and I'd really prefer REAPER had a better way, but it might be worth exploring.

I wonder if it's worth just asking Cockos whether they definitely support LUFS on the master and whether they'd be willing to expose it via the API if they don't already? The worst they can do is say no, and this seems important enough to "bother" them with.

[Lo-lo78]

Hi, the rms are the average of the peaks, the LUFS is the actual sound pressure of the volume. It is not a question of old or new, there are two ways of calculating the volume, the first on the peaks and the second in the sound pressure. Greetings!

[ScottChesworth]

The js plug-in I'm currently using for real-time info isn't really practical for screen reader users because:

1. Loudness fluctuates rapidly. Every measurement delivers an update to the text field I'm monitoring for reports, and even with speech rate cranked as fast as I can comprehend it, the information isn't spoken fast enough for me to accurately relate loudness information to specific musical moments, which is particularly important when mastering collections of songs (more on that in a bit). There's no such thing as being able to thin out the notifications right now, it's all or nothing, and "all" is totally overwhelming.
2. To have the real-time info I can get at right now reported, I have to be in the FX window, which means most of the time, it's not possible to tweak a plug-in and get an updated LUFS value without constant window-hopping (particularly when using third-party plug-ins).

In case it helps anyone's understanding of what I'm chasing, the ideal workflow for me would be reports being delivered automatically to my screen reader above a given LUFS level I could specify in Peak Watcher's Threshold field, so that I could tweak and shape with plug-ins being controlled from a surface, basing those initial moves purely on sound and feel until I cross the threshold of loudness. I'd set the threshold in Peak Watcher to be a couple units below my eventual target, so the screen reader stays out of the equation and only starts reporting once I'm within the ballpark of being "loud enough". Then I'd pay close attention to the reports to gauge the finishing touches and deliver to spec. I'm fine relying on referencing and gut instinct until I get within that ballpark here, but I know more data driven users who'd prefer to play a section and have the highest LUFS value held until reset, which is already a workflow that Peak Watcher can provide, just not measuring in LUFS yet. For me, the main benefit that'd be up for grabs if real-time LUFS could be integrated into Peak Watcher is objectivity from song to song. Ideally, I'd use real-time access to loudness info to be more intentional, the idea being that I could sculpt dynamic range with specific targets in mind. The rationale I've observed plenty of mastering folk using goes something like "loudness is hovering around X throughout the record, these more impactful moments tend to hit somewhere around Y, and I've intentionally preserved just enough headroom for these specific riffs which need to be perceived as being huge to reach Z each time one of those pops". As things stand, yes, I can get a broadstroke grasp of dynamic range from section to section of a song, but because the screen reader reports start to get queued up after only a few seconds of music, it's impossible to gauge loudness in context of those key musical moments. Of course, the acid test when considering dynamic range is what the music feels like, but that's difficult for me to compare objectively across multiple songs, and from conversations with other users who do mastering work, I know I'm not the only person who struggles with it.

I've sent a breif summary of everything that's been asked above in to Cockos, will report back when I hear back.

[Lo-lo78]

Hi Scott,

more precisely, at this moment with SWS we can read the LUFS not in real time:

SWS/BR: Analyze loudness...

We can read the RMS:

SWS: Analyze and display item peak and RMS (entire item)

LUFS, to be clear, are the sound pressure of the audio coming out of the monitors; the RMS are the average of the peaks of a song. They are two different ways of analyzing the audio. Forgive me if I am too insistent but it would be very nice to read the LUFS and RMS in real time. Nice idea but I don't know how applicable; on Reaper there is nothing to read LUFS in real time, not even with SWS.

With the JS you can do it but by default on Reaper there is only

JS: Audio Statistics;

missing one like

JS: EBUR128 Loudness Measurement V2.4 (TBProAudio);

the latter reads the LUFS in real time. Greetings!

[pitermach]

What I also think would help in this case, at least for me as well, is also having an option to get these warnings in tones instead of speech - so basically the accessible peek meter plugin except using LUFS instead of DB for setting the thresholds. Hearing a quick ping, which could optionally also get higher in pitch if the sound goes far above the limit, would probably be much easier to process quickly and keep up with the rapidly changing levels. Options for hearing and obtaining the actual values in speech would also be really useful though.

[ScottChesworth]

the accessible peek meter plugin except using LUFS instead of DB for setting the thresholds.

Can't believe I hadn't thought of this. I've had some contact with the chap who maintains APM, will hit him up quicksharp to see if there's any possibility of getting that done.

[ScottChesworth]

I wonder if it's worth just asking Cockos whether they definitely support LUFS on the master and whether they'd be willing to expose it via the API if they don't already? The worst they can do is say no, and this seems important enough to "bother" them with.

Response from Justin: REARER's MCP master meter can show you RMS metering with an offset, which I suppose is LUFS (though we don't call it that). Track meters are peak-only. We can definitely add an API to allow querying the master RMS, let me do that...

[ptorpey]

the accessible peek meter plugin except using LUFS instead of DB for setting the thresholds.

[PT] I believe that the Accessible Peak meter is an open source project with code available. The download link and link to where the source code is can be found at:

http://depic.eecs.qmul.ac.uk/apm/downloads.html

I don’t know if having the source code helps. They support many metering types but I’m not sure if LUFS is one of them.

--Pete

[ptorpey]

REARER's MCP master meter can show you RMS metering with an offset, which I suppose is LUFS (though we don't call it that). Track meters are peak-only. We can definitely add an API to allow querying the master RMS, let me do that...

[PT] What is Rearer’s MCT?

[PT] Would be great if the Cockos folks could put peak and rms values into their API. Then the question is are we talking about pre fader or post fader? Although I appreciate the importance of pre fader when recording, I like knowing the output level of each track after FX have been applied. I guess if they’re thinking of only adding this for the Master, one can just solo an individual track and get the output of that track.

I don’t know exactly how LUFS are calculated but believe it is like an RMS but weighted by the ear’s response, so it isn’t as straightforward as calculating a simple RMS.

--Pete

[ptorpey]

Using a braille display I do see these values changing real time. But as Scott indicated before, if one is stuck in the FX UI one can’t readily change parameters and/or easily skip to other parts of the audio to make a quick check of values.

Also, is there a description of what these values are? For example I see such things as:

Il lufs

Sl lufs

Ml lufs

Etc.

Thanks.

--Pete

From: Lo-lo78 @.> Sent: Monday, March 29, 2021 2:17 AM To: jcsteh/osara @.> Cc: ptorpey @.>; Comment @.> Subject: Re: [jcsteh/osara] Request for Option in Peak Watcher to report LUFS, or RMS values (#166)

Hello guys! On Reaper you can't read LUFS in real time; we know that with SWS we have the action: SWS / BR: Analyze loudness ... There is an accessible JS but it is not by default on Reaper, it is called: JS: EBUR128 Loudness Measurement; I know Reaper does not parse LUFS in real time by default, this JS does. I am attaching the JS to you. Greetings!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/166#issuecomment-809174025 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEPTJMXWMURFNRPCHJFOWTTGAZQNANCNFSM4FCMBACQ .

[jcsteh]

Justin notes that RMS with an offset is basically LUFS and Kenny's video suggests similarly (he talks about LUFS but notes that he's changing RMS values). However, everything I've read says there's no direct correlation between RMS and LUFS because LUFS is weighted in certain frequency areas. This is all so damned confusing.

[ptorpey]

Jamie,

You are correct, one cannot directly correlate RMS and LUFS. RMS simply takes a root mean square value of the varying signal over a specified time period. LUFS does something similar but is based on human perception and weighting various components according to how our ears perceive sound. Thus LUFS is a subjective metric. In fact, calculating LUFS also involves gating the signal to minimize the effect of long periods of quiet audio on the long term averages.

If it helps (and if anyone is interested) the Wikipedia article on loudness normalization gives an OVERVIEW:

https://en.wikipedia.org/wiki/Audio_normalization

The Wikipedia article on ebu 128 is also enlightening on this subject:

https://en.wikipedia.org/wiki/EBU_R_128

In fact this last article answered my previous question about the various values shown in the ebu 128 plug-in:

• Momentary (M), using a sliding time window of 400 ms, best describes the instantaneous loudness;

• Short-term (S), using a sliding time window of 3 s, describes a more averaged, less event-dependant loudness of the past three seconds;

• Integrated (I), averaging the programme from start to finish, describes the loudness of the whole programme.

Thus I assume in that plug-in that “ml” = momentary, “sl” = short term, and “il” = integrated values for LUFS.

If anyone is really interested in the gory details (to which the logical answer is “no”!) here is a link to a document that describes the algorithm, weighting values, etc. It is quite complex:

https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf

The bottom line is that it isn’t simple to compute LUFS but it is a more accurate measure of what people hear and is being used more and more as an audio standard.

Anyway, just figured folks might be interested.

--Pete

From: James Teh @.> Sent: Monday, March 29, 2021 2:39 PM To: jcsteh/osara @.> Cc: ptorpey @.>; Comment @.> Subject: Re: [jcsteh/osara] Request for Option in Peak Watcher to report LUFS, or RMS values (#166)

Justin notes that RMS with an offset is basically LUFS and Kenny's video suggests similarly (he talks about LUFS but notes that he's changing RMS values). However, everything I've read says there's no direct correlation between RMS and LUFS because LUFS is weighted in certain frequency areas. This is all so damned confusing.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/166#issuecomment-809697090 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEPTJK75RJGJFI36N2YC43TGDQMZANCNFSM4FCMBACQ .

[jcsteh]

It looks like TBProAudio forked Accessible Peak Meter and it supports EBU R128:

EBU: EBU R128, target level -23 LUFS, LUFS

The fact that they specify a target level of -23 LUFS (as per EBU R128) might be problematic if you want to use other LUFS levels, though. I'm not sure if you can change that.

[ptorpey]

Observations on using this plug-in:

• The UI doesn’t show any meter values in the FX UI as do some of the JS plug-ins. Thus this is purely sonification and won’t show up in braille.

• One of the adjustable parameters is the type of meter. Not sure what all of them are, but the short term LUFS, medium term LUFS, and integrated LUFS seem to be supported. There are also lots more.

• Putting the plug-in on the master track and closing the FX dialog I did the following:

• Hit “P” to open the FX parameters list

• Change the meter to short term LUFS

• Navigated to the “Threshold parameter with the project playing

• Used the slider to vary the threshold. I had previously gotten my LUFS values on the track to around -23. As I moved the threshold above about -23 there was no audio from the plug-in because it presumably didn’t go past the threshold. When I lowered the threshold to around -20, the plug-in produced almost a continuous sound that varied in pitch. Higher pitches mean more over the threshold.

• The sonification also works in stereo. I had two tracks, one panned hard left and one hard right, sent to the Master. The sonification came out of the left and right speakers as they should.

Summary: Presumably one can use this plug-in to get audio feedback on how far one is above a specified threshold value for various types of meters. Varying the threshold parameter in the parameters list wile the project is playing can help one narrow in on where the audio value for the selected meter is maxing out. Thus, although one cannot read the meter values directly, one can listen to the frequency of the sonification and/or vary the threshold value to get an idea of the varying meter values as the project plays.

This might be an acceptable solution for many folks. One limitation is that there is no spoken or braille feedback of meter values. Scott indicated that he would like the capability of knowing the effect on the changes in the output as he varied parameters real-time. This might be possible by setting a threshold value and listening to the sonification to see when clipping of the meter occurs relative to the threshold that is set.

Hope that is helpful. Let’s see what others think.

--Pete

From: James Teh @.> Sent: Monday, March 29, 2021 8:19 PM To: jcsteh/osara @.> Cc: ptorpey @.>; Comment @.> Subject: Re: [jcsteh/osara] Request for Option in Peak Watcher to report LUFS, or RMS values (#166)

It looks like TBProAudio forked Accessible Peak Meter https://www.tbproaudio.de/products/accessiblemeters and it supports EBU R128:

EBU: EBU R128, target level -23 LUFS, LUFS

The fact that they specify a target level of -23 LUFS (as per EBU R128) might be problematic if you want to use other LUFS levels, though. I'm not sure if you can change that.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/166#issuecomment-809853697 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEPTJN7XYIBAHNA3J3663TTGEYHXANCNFSM4FCMBACQ .

[jcsteh]

Note that you could use a JS plugin to get the precise meter values in speech or braille. The issue Scott had with this approach was that it didn't allow for setting of a threshold, but if you want a threshold, the Accessible Peak Meter serves that purpose.

Scott, which JS plugin were you using? The TBProAudio EBU R128 plugin?

[ptorpey]

Yes, the two tools seem to compliment each other well.

I think that Scott also had two other issues with the JS tool:

1. The quickly changing meter values produced too much speech
2. He wasn’t able to vary parameters real-time from within the FX dialog where he was monitoring the meters.

The accessible Peak meter should scratch the second itch.

--Pete

From: James Teh @.> Sent: Monday, March 29, 2021 9:12 PM To: jcsteh/osara @.> Cc: ptorpey @.>; Comment @.> Subject: Re: [jcsteh/osara] Request for Option in Peak Watcher to report LUFS, or RMS values (#166)

Note that you could use a JS plugin to get the precise meter values in speech or braille. The issue Scott had with this approach was that it didn't allow for setting of a threshold, but if you want a threshold, the Accessible Peak Meter serves that purpose.

Scott, which JS plugin were you using? The TBProAudio EBU R128 plugin?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/166#issuecomment-809872170 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEPTJIED2VSFA3W7JPWR7TTGE6Q3ANCNFSM4FCMBACQ .

[jcsteh]

Ah. Both the Audio Statistics (RMS) and EBU R128 (LUFS) JS effects already expose the relevant values as FX parameters. So, it should be possible to make Peak Watcher query these for the data. It would depend on having the effect on the track, though. The question is: is this worthwhile given we now know threshold can be done with the Accessible Peak Meter?

[jcsteh]

I'm also not sure yet how to reset the value for LUFS integrated. That probably isn't controllable with an FX parameter.

[ScottChesworth]

The question is: is this worthwhile given we now know threshold can be done with the Accessible Peak Meter?

Somehow I missed that the new fork of APM could calculate LUFS. My gut instinct is telling me that I'd likely get more info from feedback in the form of numbers being reported instead of beeps and boops, but lemme work on some songs using the APM feature in situ and I'll report back on what the UX was like. All being as planned, I should be spending some time on a project with plenty of dynamic range later this week, just gotta wait for a final round of mix tweaks to arrive before I can dig into it. @pitermach, if you can also find time to test LUFS feedback from this fork of APM, I'd love to know what you make of it.

[ptorpey]

Just FYI, looks like the latest version of Reaper (6.26) released today now supports RMS as part of the API:

• “update Track_GetPeakInfo()/Track_GetPeakHoldDB() to support master track RMS, update documentation”

Thanks for asking @.***> @Scott Chesworth

--Pete