Documentation request: difference between "true-peak" (ITU-R BS.1770) and "peak-sample"

[suterma]

I suggest you extend the documentation, explain the differences, or add a link to an online resource.

Also, I have found that the "true-peak" algorithm is way more expensive in computing consumption. Using it on a lower-spec desktop PC with about ten tracks simultaneously renders the browser unusable, whereas the "peak-simple" variant remains very responsive.

An explanation of the benefits of each would help make a decision.

It has been suggested elsewhere, but maybe using the more modern "Analyser Node" with a fallback for older devices would be beneficial here.

[evoyy]

I wanted to ask the same question. If my understanding is correct, true peak metering is more accurate, and so it makes sense that it would be more expensive.

[esonderegger]

Thank you for bringing this up. I included a link to the ITU specification in the README in the changes for version 3. However, that doesn't really help with understanding why the difference exists.

The short answer is: inter-sample clipping.

The longer answer is better explained by linking to places where others have explained the concept much better than I ever could. Here are some that I think explain it pretty well:

1. https://benchmarkmedia.com/blogs/application_notes/intersample-overs-in-cd-recordings
2. https://splice.com/blog/what-are-inter-sample-peaks/
3. https://www.masteringthemix.com/blogs/learn/inter-sample-and-true-peak-metering
4. https://phantom-sounds.com/en-us/blogs/blog/what-are-inter-sample-peaks-and-true-peaks

I'm leaning towards linking to the first one, but what do you two think? Do one of the others explain it better in your opinion?

As for the performance implications, the way the true-peak meter works is: it up-samples the source audio, extrapolating values for those in-between samples. It's not surprising that this is computationally expensive. However, two days ago I released version 3 of this library, which converts from using ScriptProcessorNode to AudioWorkletNode. This means the processing is no longer happening on the main thread, which I'm hoping will make a big difference.

Finally, I feel like I should add... I believe there is a bug in the way the oversampling algorithm is implemented in this library, causing it to report incorrect levels. It is the main thing that held me back from releasing v3 when I first wrote it a little over a year ago. I currently have neither the time, nor the expertise, to properly look into this. It's why I made peak-sample the default audio meter standard in the configuration. I finally realized I wasn't going to get to this and that it was better to release a version with audio worklet support (and lots of other fixes too) even if this feature wasn't in the state I'd like it to be in.

[suterma]

I like 3) for it's conciseness, 4) because it has a slow start, and 1) because it's super technical.

That said, I would maybe go for 4) as the average audience for a peak meter on a website is maybe not that technical.

To be honest, reading all this up, I wonder whether this is an issue at all for sound level meters in the context of a web application. And I am a trained electrical engineer and amateur sound engineer. I would expect no one to do actual studio quality mixes/mastering in a web page, and for the occasional user it's just not that relevant IMHO.

[evoyy]

To be honest, reading all this up, I wonder whether this is an issue at all for sound level meters in the context of a web application. And I am a trained electrical engineer and amateur sound engineer. I would expect no one to do actual studio quality mixes/mastering in a web page, and for the occasional user it's just not that relevant IMHO.

This is a good point. Though, I do appreciate having accurate web audio tools. I have many recordings made using analog equipment such as turntables and hosted on my web app. These are already mastered in pro-grade desktop applications before being uploaded, but it's nice to be able to monitor these recordings in my web app, like if one channel really is louder than the other (or am I just imagining it?) and then can decide if it needs to be remastered.

[suterma]

I don't intend to be picky. And just "because it's a web app" should be no excuse to use or produce subpar software. However, for deciding on loudness, any peak algorithm would not be a good choice, and something like a VU-Meter would be more helpful. Maybe @esonderegger could implement such a VU-type algorithm?

Anyway, if seeing "intersample overs" in a web app is relevant to your use case, I would encourage you to look at peaks.js and maybe add or request this feature there? It would produce something like this: https://cdn.shopify.com/s/files/1/0321/7609/files/Intersample_Overs_-_Gaslighting_Abbie.png which is shown in link 1).