"Wave Stats" plug-in

There have been a few posts recently concerning how to view information such as peak level, RMS level, and so on, for a waveform.

endolith began some work on this some time ago and this plug-in leads on mostly from the discussions in that forum thread: https://forum.audacityteam.org/t/how-to-compute-spl-from-sound-inputed-from-a-microphone/11138/1

Here’s a typical output from the plug-in:
The A-weighted measurements are based the A-weighting curve by Edgar, following the general methodology suggested by endolith.
I don’t have other software to check the A-weighted measurements, so would be very interested to hear from anyone that can verify these measurements.

The plug-in is installed in the usual way - just put it into your Audacity plug-ins folder and restart Audacity.
The plug-in is called “Wave Stats…” and will appear in the “Analyze” menu.
stats.ny (2.12 KB)
Note that this plug-in is currently experimental. During testing it caused Audacity to crash when analysing more than 40 seconds, so this version is limited to a maximum of 30 seconds. If anyone has an in-depth knowledge of audio signal measurement and would like to collaborate on developing this plug-in further, please PM me.

As always, comments/feedback are most welcome.

1 Like

You can confirm that the A-weighting is working by putting sine waves through and comparing with an A-weighting curve.

My latest version is here: http://gist.github.com/514077

Thanks endolith.
Testing both your version and this one, the results are pretty good. Checking sine waves against the on-line calculator on this page http://www.diracdelta.co.uk/science/source/a/w/aweighting/source.html

In the mid-range the A-weighted values match extremely closely (within 0.1 dB)
At bass frequencies, the accuracy drifts off slightly but is still within 1 dB at 20 Hz
High frequencies drift off a little more, but still within 3 dB at 20 kHz.

Regarding normalizing the results (what you call “the fudge factor”, but could be called “the normalisation coefficient:wink: )
I notice that we have both normalised so that 0 dB RMS reads as 0 dB RMS(A) at 1000 Hz.
Google is very sketchy about implementation - I presume that we are correct in calibrating against 0 dB RMS rather than against 0 dB peak?

A more significant limitation of both of our implementations is the limited number of samples that can be analysed without crashing Nyquist.
I was not sure how to overcome this limitation correctly, but I think you’ve given the answer when you pointed to Cumulative moving average. This does however raise the question:
Which is more useful - a single measurement for the entire selection, or a series of measurements along the time line (which could be output as labels)?
Perhaps a plug-in that offers a choice of either? (there can only be one output from a Nyquist plug-in - either text output, or labels, or sound.)

Are A-weighted measurements always RMS?
I realise that A-weighted measurements are of limited real-world relevance, but is there ever a need for A-weighted peak?

How useful would other weightings be?
For example C-weighting follows human hearing at mid to loud levels much more closely than A-weighting.

The more I’ve read about A-weighting, the less I like it. It seems to be a horrible fudge based on an arbitrarily chosen hearing response curve that is at too low a level for most real-world applications (other than perhaps looking at signal noise) that has been approximated to suit old analogue filter design, that we are now trying to replicate digitally.

You can use these for SPL measurement by correlating the dBFS with a test tone of known SPL, but I’m mostly interested in this for measuring the noise floors of ADCs. I just posted in that thread because it was related.

that we both get at low, and particularly at high frequencies compared with the on-line calculator:

As I understand, A-weighting is undefined at frequencies higher than 10 kHz, so it’s ambiguous at high and low frequencies. Hopefully it doesn’t have a huge effect on your measurement. I’m going to make a spreadsheet comparing the different filters I’ve seen (Edgar’s, the Matlab bilinear version that I used in my Python script, diracdelta.co.uk, and the filter used in Audio Precision products).

I’ve been considering trying a multi-band “graphic” equalizer instead of the nested lp/hp filters. An FFT filter would probably be the best solution, but that’s a bit beyond my programming abilities at the moment.

I think these would both be worse, actually, especially at low and high frequencies. I previously used the FFT filter in Audition and it didn’t give correct results at low levels, which is why I made the Python script.

Would it suit your purposes better to output a series of rolling average values as labels, or as a text file, rather than just one average RMS/RMS(A) value?

Well, one of the other things I wanted to implement was a maximum and minimum RMS level, like Audition does. In other words, do a sliding window of RMS measurements across the waveform, and find the highest 50 ms and lowest 50 ms, for instance. For something constant like a sine or white noise, the minimum RMS and maximum RMS will be the same. For music, it will find the quietest and loudest parts.

I have a list of other measurements I might implement here: http://github.com/endolith/waveform-analyzer/blob/master/readme.txt

I notice that we have both normalised so that 0 dB RMS reads as 0 dB RMS(A) at 1000 Hz.

I believe this is what the standards all do. My Audio Precision normalizes here, as well.

Which is more useful - a single measurement for the entire selection, or a series of measurements along the time line > (which could be output as labels)?

Both are useful in different contexts. :slight_smile: For me, I just want a single measurement of the entire selection, because my entire selection is usually a constant noise or test tone.

Are A-weighted measurements always RMS?

Yes, A-weighting is inherently related to subjective loudness, and loudness correlates with the energy, or RMS value.

The instantaneous peak value is not related to audibility. It’s just the amount of headroom you have to boost something before it clips. That’s why I’m not sure if the peak value should be before or after removing DC.

How useful would other weightings be?
For example C-weighting follows human hearing at mid to loud levels much more closely than A-weighting.

C-weighting is basically “flat”, so it should be very similar to the unweighted measurement, unless you have a lot of infrasound or ultrasound.

The more I’ve read about A-weighting, the less I like it.

Keep in mind the Wikipedia articles on the subject are written mostly by a guy with an axe to grind. In the real world, I always see A-weighted measurements, both for consumer products and for electronic components. So you need it if you want to do an apples-to-apples comparison between competing products. I was going to try to implement the ITU-R 468 curve anyway, though.

Thanks for the plug-in. Suggest eliminating the bell sound at the end of analysis. Also suggest putting the maximum length to analyze setting in the results window itself, changeable for subsequent analyses. This would save an entire dialog box and click every time the plug-in is used.

Thanks for the feedback scaud.

The “bell sound” is not in the plug-in - there is a setting in Audacity to “beep on completion of longer activities”. It may be switched off in “Edit menu > Preferences > Interface”.

The interface options for Nyquist plug-ins are extremely limited. User input is only available in the initial GUI (graphical User Interface). The “output screen” is just a message box that allows the display of plain text and nothing more. It would be very nice if Nyquist plug-ins could have an interactive GUI that allowed messages to be displayed interactively within the GUI, but unfortunately that is not currently possible.

Thanks. I have “Beep on completion of longer activities” unchecked, but Wave Stats still gives a bell sound along with the Nyquist message box. I am using 1.3.13-alpha-Sep 30 2010.

Sorry, I’ve no idea where that bell sound is coming from and I’ve not noticed this occur myself.
If you open the stats.ny file in a text editor you will see that there is no mention of a bell sound anywhere in the plug-in code.

I get the same effect, running on Windows XP, but it is not related to Audacity or the specific plug-in.

What happens is that Windows generates a tone when the pop-up window opens, as part of its “Sound Scheme”.
You should be able to change it, or turn it off, in the “Sounds and Audio Properties” section of Windows Control Panel.


Thanks Irish - and that explains why I’m not getting the sound.

mfgrs use A weighting cause it makes their snr , mike sensitivity, and other ratings look better on paper.

It more accurately represents the loudness of the noise. We don’t hear low-frequency noise as much as 3 kHz noise, even if they’re the same RMS level. Noise shaping shifts dither noise up into the ultrasound where we don’t hear it, for instance. If you just tried to use RMS to measure it, it would seem worse than it really is.

May I say this is a fantastic tool but is there any way of exporting the values? I have lots of file (6000 + ) I need to analyse in a short period of time and if I could export as a text file of some sort, that would be brilliant.

That’s a lot of files. What stats do you want from them? SoX can display some info using the stat or stats commands

You could also use Python

The plug-in could be adapted to output to a text file, but you would still need to run the effect 6000+ times as Audacity does not (yet) support Nyquist plug-ins in chain commands (batch processing). I agree with endolith that for such a large number of files it would be far more practical to write a script that could batch process using a command line application such as SoX.

I do not mind running it 6000 times as producing the numbers is really quick, it is just to get it into a format that its easier to edit with. Currently I am putting in each value one by one in excel and its time consuming however If it can be in a text file, I can open in excel copy and paste.

Rather you than me :smiley:

Which of the measurements do you need?

Which of the measurements do you need?[/quote]

Its the Peak level, RMS and RMS A-weighted I am working with.

The reason theres so many is because they are 15 second long pieces

Would you want a list of values for Peak level, RMS and RMS A-weighted with the additional text removed?
Would you prefer the values to be comma separated, space separated, or each value on a new line?

For example, if values are comma separated:
If you imported 10 mono files so that they stacked one above the other in Audacity, then press Ctrl+A (select all), then applied the plug-in
Would it be useful if you had an output that you could copy and paste that looked like:


Are the files all mono, all stereo or a mixture of mono and stereo?
How many decimal places do you want?

The files are stereo (two channels) and to two decibel places would be great. At the moment I am selecting all and running the plug in and just manually copying over but there is no direct copy and paste feature (as you are aware I am sure) so to have a output like you suggested would be fantastic.

As for the delimiter, a comma probably would be best but I am not bothered what the delimiter is.

As for additional text, the peak ‘+’ and peak’ -’ would be useful as well if it can be included in the copy function.

Thank you for helping me on this.