Level meters: RMS or Peak?

Cantabile
1

Hey All,

I’m reworking Cantabile’s internal sample library and have added support for calculating RMS levels.

This means there’s now two ways level meters could operate:

  • Peak level
  • RMS level

Currently Cantabile shows peak levels.

What would you prefer?

  • Always peak
  • Always RMS
  • Both
  • Switchable globally
  • Switchable per-meter
  • Something else?

I’m leaning towards both where the existing peak indicator (orange) and clipping indicator (orange border) are driven by peak, but the main meter content (grey bar) is RMS.

image
image914×164 634 Bytes

If you’re not sure on the difference, here’s a quick explainer from Claude…

Peak Level vs. RMS Level

When you see level meters in audio software, you’re usually looking at one of two measurements — Peak or RMS — and they tell you different things about the same signal.

Peak Level

Peak level shows the highest instantaneous point the waveform reaches, even if it’s just for a fraction of a millisecond. It’s useful because it tells you how close you are to clipping (digital distortion). If your peak meter hits 0 dB, you’re clipping — full stop.

RMS Level

RMS level (Root Mean Square) is closer to how loud the sound actually feels to your ears. Instead of catching brief spikes, it averages the signal’s energy over a short window of time. Two sounds can have the same peak level but very different RMS levels — a sharp drum hit might peak high but sound quieter overall, while a sustained, compressed guitar tone might have a lower peak but sound much louder because its RMS level is higher.

Why It Matters in Practice

  • Watch peak to avoid clipping and distortion.
  • Watch RMS to judge and manage perceived loudness — useful for keeping levels consistent between songs or performers.

A signal with a high peak but low RMS sounds quiet and dynamic. A signal where peak and RMS are close together sounds loud and heavily compressed (this is the “loudness war” effect you may have heard about in modern music production).

2

I would favour both RMS and peak switchable globally. I use mvMeter2 | TBProAudio in my output rack which allows me to switch between different measurement modes PEAK, RMS, EBU. etc. ../Steve

3

This would work for me. Nice addition, RMS & LUFS levels are my go to for my own master out meters.

4

Agreed and another vote here too. I “view” meters in terms of loudness and having the peak visible as an orange highlight will be great for checking any potential clipping issues. Wonderful addition!

5

I’d like that - RMS is more meaningful for managing levels, but you gotta watch them peaks!

6

Both works great. I believe this is dBFS for digital realm. Isn’t there a specific time for RMS (300ms has been mentioned by some sources, but AES17 quotes 25ms) for the calculation? What duration will Cantabile use? Will Cantabile perform the entire full calculation every x ms OR using some type of smoothing algorithm?

Will there be some color codes for visual cues? Yellow peak above X dBFS? Red peak above Y dBFS?

7

Hi. I would favour both being show, as both are useful for the reasons you describe.

8

As above - RMS with peak.

9

Just to be clear, this is purely RMS and not LUFS/EBU which I don’t think warrants the additional processing for everywhere Cantabile displays a level meter. Use a proper level meter plugin for that.

There’s two main ways to do this - either a sliding window and recompute the entire window every update or a leaky integrator. Leaky integrator is not as accurate but simpler, faster and gives similar result on a level meter - so that’s what I’ll be using.

As for the time period there’s no official standard I’m aware of but 300ms is common for loudness monitoring whereas “fast rms” is closer to 100ms. I’m open to either.

2 Likes
10

I had to look up Leaky Integrator. Seems close to Exponential Smoothing. Both appear much lighter on CPU than doing a sliding 300 ms window on a 48kHz signal. I prefer the slower 300 ms as long as the peak is real time with a clip indicator (turn red?).

2 Likes
11

Just out of curiosity… Why not sliding-sum of squares to get rms without recomputing the entire window?

sum -= oldest_datapoint * oldest_datapoint;
sum += newest_datapoint * newest_datapoint;
rms = sqrt(sum / window_size);
12

Good question. I think I overstated the recompute part and understated the sliding window.

I wouldn’t do this on a sample by sample basis. Instead these calcs are done on blocks of samples with sse/avx optimized routines. So it would need to be a sliding window of block sum of squares. Which works but means the period would need to be rounded to the block size - which is probably fine but perhaps not for large block sizes. If not it means the blocks need to be subdivided and then it gets messy because the sse/avx routines have memory alignment requirements.

I think I’ll stick with leaky integrator for now but keep this is mind.

13

Since even a 4096-sample buffer at 44.1 kHz tops out at 93ms, I think probably just using one data point per buffer in a sliding window always works. If so, sliding-sum rms seems very efficient (one float of state, and a couple of multiplies, two adds, a division, and a sqrt of computation per cycle) and is perfectly precise (no approximations). But whatever works. Just tossing out my gut instinct. :slight_smile:

1 Like
14

I would like to have the option for an offset margin. Like many digital hardware DAW (I have the VS Roland serie in mind) that shows peak at -3 as an option. For a live setup, seeing the red light before shit happens may help to catch attention!

1 Like
15

I would prefer both thank you Brad! The colors idea is great for me!

3 Likes
16

Same here.

1 Like