Try this:
wave-info.ny (2.14 KB)
After installing and restarting Audacity it will appear in the “Analyze” menu as “Wave Info…”
You may want to check the accuracy of the results against the “Wave Stats” plug-in.
Data from the “Debug” window can be copied and pasted into other applications.
Read all of the text in the plug-in carefully.
If you have comments/questions please post them here.
Thanks so much Steve it works perfectly!!!
Interesting use of the debug output, Steve. I may borrow that idea for some of the stuff I’m working on.
Dave
Just sharing my edition of the wave stats plugin that meets my criteria…
Thank you Steve for the original plugin!
Changes in this version:
File:
stats.ny (1.88 KB)
Thanks vpd. Nice to see someone modifying the plug-in to suit their needs. That’s one of the great things about Nyquist plug-ins 
Your code works fine.
A couple of notes from a programming perspective that may be useful for you (or disregard if not 
)
(setq selected (/ len *sound-srate*))
(setq time (min 20 (max 0 selected))) ; 0 < time < 20
(setq bignum (truncate (* time *sound-srate*)))
(setq step (truncate (min bignum LEN))) ; 'peak' requires blocksize and stepsize as integers
As there is no duration control in this version, this code can be simplified:
(setq time 20)
(setq bignum (truncate (* time *sound-srate*)))
(setq step (truncate (min LEN bignum)))
In fact it could be simplified into one line, but as we need “bignum” and “time” later on for the messages they may as well all be set here.
(defun s-rms (s-in)
(linear-to-dB (sqrt (peak (snd-avg (mult s-in s-in) step step OP-AVERAGE) bignum))))
(defun x-rms (s-in)
(* (sqrt (peak (snd-avg (mult s-in s-in) step step OP-AVERAGE) bignum)) 100))
We don’t really need to calculate the rms level twice (although it really makes very little difference in this case because we are only processing a few seconds of audio).
We could just calculate the rms once as a linear value:
(defun s-rms (s-in)
(sqrt (peak (snd-avg (mult s-in s-in) step step OP-AVERAGE) bignum)))
(setq rms-lin (s-rms s-in))
Then convert to dB or % as required.
(print (linear-to-db rms-lin))
(print (* rms-lin 100))
Hi Steve!
Thanks for Wave Info! I do voice overs and may in some cases have to deliver sound files with a specified “LKFS”. From what I understand thats is almost equivalent with LUFS and average RMS power.
Please be patient with my inexperinece 
but will Wave Info give me the true average RMS when analyzing a two minute recording with both loud laughter and almost silent whispering?
The “Wave Stats…” plug-in (file name “stats.ny” posted here: https://forum.audacityteam.org/t/wave-stats-plug-in/15515/1) is limited to analyzing 30 seconds of audio.
The “RMS” measure is true RMS (unweighted / Zero Weighted / Z-Weighted) relative to full scale (0 dB) for the entire selection OR 30 seconds, whichever is the shorter.
ITU-R BS.1770-2 (March 2011) brought LKFS in line with LUFS (as defined in EBU R128 August 2010), so that after March 2011 both units are identical.
The “EBU R 128 - 2014” specification is available here: https://tech.ebu.ch/docs/r/r128.pdf
OK, thanks! I used wave-info.ny posted here https://forum.audacityteam.org/t/firebox-or-inspire/174/1
So to get the average RMS for a two minute recording I guess I can copy the file, calculate 30 seconds, delete the 30 seconds, calculate the next 30 seconds, delete and so on until the end.
Interesting pdf! I have worked in broadcasting many years but never thought of that part of EBUs work.
Pretty sweet pluggin, thanks.
I did run the pluggin, and there is one minor aspect that I do not understand, as well as one improvement suggestion.
I generated a full scale sine wave (generate, tone, sine, frequency 1000, amplitude 1). I process 10s of audio samples through the wave stats pluggin.
Results reported:
peaks all at 0dBFS as expected
DC 0% also expected
RMS value at -3dBFS, okay
RMS (A-Weighted) at -6.6dBFS ???, this I do not understand.
A-Weighting is supposed to be precisely centered around 1K, so why 3.3dB less after A filtering ?
I checked the spectrum of the generated signal, it looked relatively clean.
improvement: it would be sooooo conveninent to just be able to copy and paste the output of the analysis 
Some more on this:
On windows, the whole window can be copied as text by simply pressing Ctrl-c, as soon as the dialog appears.
The result looks like this:
---------------------------
Nyquist
---------------------------
Length of selection: 521.790 seconds.
23010939 samples at 44100 Hz.
Analysis of first 521.790 seconds:
(23010939 samples)
CHANNEL 1
Peak Level: -1.9 dBFS
Peak Positive: -1.9 dBFS
Peak Negative: -1.9 dBFS
DC offset: 0.0 %
RMS: -21.7 dBFS
RMS (A-weighted): -28.5 dBFS
CHANNEL 2
Peak Level: -2.0 dBFS
Peak Positive: -2.0 dBFS
Peak Negative: -2.1 dBFS
DC offset: 0.0 %
RMS: -21.5 dBFS
RMS (A-weighted): -28.8 dBFS
---------------------------
OK
---------------------------
Please note that it isn’t quite the same plug-in as my version has no thirty s limit, thus the odd selection length.
Thanks Robert, works like a charm.
Windows raises a warning beep somewhat telling I’m doing something not allowed, but it works still, thanks.
Back to your version of the pluggin: How do you manage time then : you have RMS windows and perform RMS averaging in the end?
(side question: where can I pick this from? )
I don’t use windowing. That’s actually only needed for real time display, e.g. display update at each second.
This means, all samples are summed and averaged.
I might go back to windowing when I want to exclude silences as it is e.g. done in the R128 recommendation.
However, the difference is not that overwhelming.
I’m sure that Steve will soon enable longer durations since Acx/Audible measure 60 s blocks for instance.
Until then:
wavestats.ny (2.3 KB)
Thanks Roberts!
So you make a real full length RMS then?
as in here:
Pretty cool then.
Note time windowing for RMS has other use than real time display, it can provide interesting stas on a signal, such as min RMS, max, average, and total (mostly identical to avg).
Note Audition gives you also the A-Weighted RMS, which happens to be very usefull when you deal with some DC, but I agree here this is just a nice to have.
Me again.
I think I found a minor bug in your pluggin.
When measuring a Signal that is always positive due to DC Offset, I find the peak negative value is wrongly initialized:
(the same problem projects to peak positive value if you invert the signal)
The problem is also present in the original pluggin.
---------------------------
Nyquist
---------------------------
Length of selection: 1.055 seconds.
8441 samples at 8000 Hz.
Analysis of first 1.055 seconds:
(8441 samples)
Mono Track.
Peak Level: -20.9 dBFS
Peak Positive: -20.9 dBFS
Peak Negative: -1.$ dBFS
DC offset: 8.9 %
RMS: -21.0 dBFS
RMS (A-weighted): -63.4 dBFS
---------------------------
OK
---------------------------
“Absolute silence” is “-infinity” dB. (minus infinity)
What number is less than “- infinity”?
The way that “- infinity” is represented by computers is different on different systems. On Linux it is represented as “-inf”, on your system it is represented as “-1.$”.
They say about computers “garbage in; garbage out”, or to put that another way, if you input invalid data, you shouldn’t expect to get something sensible out.
In your test, the negative going peaks are on the wrong side of silence, that is, they are less than - infinity.
There are an infinite number of odd numbers.
There are an infinite number of even numbers.
How many numbers are there? (odd + even) ?
I don’t think that additional Rms values, based on windowing give useful information.
The min Rms value is often -infinity, depending on the window length.
There’s not much agreement on how to define those window lengths and how to treat “silence”.
Minima and maxima approach the average the longer the window length gets (until the entire track length is reached).
R128 differentiates 4 Window length, momentary Rms (some centiseconds), short-term (1 s), long-term (3 s) and integrated Rms (entire audio).
It is in principle no problem to display avg, max and min for those types.
However, the meaningfulness is rather questionable.
It is better to implement statistical functions that are independant, such as mean + Standard deviation (e.g. in percent).
Unfortunately, this values are actually only applicable to a normal distribution (Gauss) and that’s not always given–only for white noise in fact.
I’m writing a plug-in that shows instead the whole Rms histogram (of course resized to fit into the dialog box, i.e. 25 lines is the max).
This represents the energy distribution much better in my opinion.
For example, you can see at a glance at the -inf (= 0) bar how high the silence percentage is, and if there’s nothing but instead at around -73 dB, the audio has been dithered and that’s the silence amount now.
There will be other peaks too, e.g. for different speakers in a phone conversation or a noisy input.
By the way, Steve’s plug-in gives the A-weighted Rms too.
Your sample-output shows that the Rms level is corrected by -40 dB due to the heavy DC-offset.
Waking up an old thread…
I just finished a new cut on the “wave stats” plugin. The attached is roughly based on “measurements.ny” however it’s been reworked to remove the time limitations that measurements.ny had (it would fail if you selected more than about 45 seconds) stats.ny has a similar limitation, but it forces users to not analyze more than 30 seconds.
It needs a better name, for the moment I just called it “my Amplitude Statistics”.
I’ve tested it on ~40 minute stereo files, and it can give you the answer in about 30-40 seconds. However the progress bar is totally confused by the multiple passes that the code takes.
better-measurement.ny (2.72 KB)
I think it does that during auto analysis of multiple tracks, too. It never failed to give numbers and the numbers seemed rational, so I didn’t worry about it.
Koz
Nice one flynwill, good to see this resurrected.
Unfortunately if you go much bigger than that, Audacity will crash.
The problem is snd-maxsamp which computes the samples in memory and retains them until the script completes. As Nyquist is purely 32-bit, I think that gives you a limit of 2 GB before it explodes. This problem is not unique to your plugin, it affect many (most?) Nyquist plugins and there is no way around it until we improve the way that Nyquist accesses the audio.
Probably better to use PEAK and set a reasonable limit.
I think what is confusing the progress bar is the time taken to load and release memory. The actual processing is very fast, and that is shown reasonably accurately by the progress bar, but writing hundreds of MB of data to ram, (and then releasing the ram), takes time that the progress indicator cannot take account of.
There is another problem which is that A-weighting filter is specific to 44.1 kHz sample rate. If, for example, you analyze white noise with a peak of 1.0, the A-weighted result shows -7.1 dB, which I think is about right, but for a sample rate of 192 kHz it shows -12.85 dB. Fortunately the Nyquist filters are clever enough to recalculate their parameters so that the “shape” of the filter remains correct, so it’s only the “fudge factor” that needs to be tweaked.