"Wave Stats" plug-in
"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: http://forum.audacityteam.org/viewtopic ... 21&t=15153
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. 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.
endolith began some work on this some time ago and this plug-in leads on mostly from the discussions in that forum thread: http://forum.audacityteam.org/viewtopic ... 21&t=15153
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. 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.
Learn more about Nyquist programming at audionyq.com
Re: "Wave Stats" plug-in
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
My latest version is here: http://gist.github.com/514077
Re: "Wave Stats" plug-in
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/sou ... ource.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"
)
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.
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/sou ... ource.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"

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.
Learn more about Nyquist programming at audionyq.com
Re: "Wave Stats" plug-in
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.stevethefiddle wrote:Is your end-result still concerning SPL measurement?
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).that we both get at low, and particularly at high frequencies compared with the on-line calculator:
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.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.
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.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?
I have a list of other measurements I might implement here: http://github.com/endolith/waveform-ana ... readme.txt
I believe this is what the standards all do. My Audio Precision normalizes here, as well.I notice that we have both normalised so that 0 dB RMS reads as 0 dB RMS(A) at 1000 Hz.
Both are useful in different contexts.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)?

Yes, A-weighting is inherently related to subjective loudness, and loudness correlates with the energy, or RMS value.Are A-weighted measurements always RMS?
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.
C-weighting is basically "flat", so it should be very similar to the unweighted measurement, unless you have a lot of infrasound or ultrasound.How useful would other weightings be?
For example C-weighting follows human hearing at mid to loud levels much more closely than A-weighting.
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.The more I've read about A-weighting, the less I like it.
Re: "Wave Stats" plug-in
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.
Re: "Wave Stats" plug-in
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 "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.scaud wrote:Also suggest putting the maximum length to analyze setting in the results window itself, changeable for subsequent analyses.
Learn more about Nyquist programming at audionyq.com
Re: "Wave Stats" plug-in
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.
Re: "Wave Stats" plug-in
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.
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.
Learn more about Nyquist programming at audionyq.com
Re: "Wave Stats" plug-in
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.
POL
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.
POL
Re: "Wave Stats" plug-in
Thanks Irish - and that explains why I'm not getting the sound.
Learn more about Nyquist programming at audionyq.com