"Wave Stats" plug-in

Programming and Development New Plug-Ins
61

I have uploaded the latest revision of acx-check.ny to the wiki: http://wiki.audacityteam.org/wiki/File:Acx-check.ny
The changes are largely cosmetic. There is now a large section of comments at the head which I would also use in the wiki description of the plugin.

Koz has suggested that this tool should be split, and that “acx-check” should only measure the three parameters that are listed in the ACX spec (noise_floor, unweighted RMS and peak) and there should be a separate tool that returns all the numbers without bothering with the acx comparisons.

I agree that the simplified tool might be a bit more friendly to non-engineers. The problem I have with this idea is that I don’t see any good way for nyquist plugins to share common code. Is there any mechanism where a .ny file could supply two different plugins? Or is there way for two plugins to share a common library? Otherwise any future fixes or improvements to the underlying code have to be carefully duplicated in both plugins.

Any suggestions, opinions?

62

I don’t think we need two plugins, just rejig the layout and remove the duplications. Something like:

Clip FAILS to meet ACX requirements! 

* Peak level of <value> 
  exceeds ACX specification of  -3 dB
* RMS level of <value>
  outside ACX specification of -18 to 23 dB
* Noise floor of <value>
  outside ACX specification of -60 dB

Other Details:
* Mono, 44100 Hz
* Selection length 1 minute (44100 samples)
* RMS(A): <value>   
* Noise Floor(A): <value>
* DC offset: <value>

Gale

63

Yes, it is theoretically possible, but it is not simple, not well tested, and would require a great deal of testing to ensure cross-platform compatibility.

In most cases it would be better to structure your code carefully so that all of the internal workings are within a self contained function or group of functions. You then have the option of either, copy and pasting from one plug-in to the other, or perhaps better, provide two lots of ‘headers’ in one plug-in with one set commented out:

;; Advanced version
;control a .....
;control b ....
(setf param1 ...)
(setf param2 ...)

;; Commented out simple version
;;control a .....
;;control b ....
;(setf param1 ...)
;(setf param2 ...)

;; Code body
64

I’ve already pretty much “rejigged the output” as you say. And I agree I don’t think we need two tools either, so I will probably re-brand the version I just posted as “release 1.0” (using the term “release” to avoid confusion for the “version” plugin directive).

65

I agree I don’t think we need two tools either

That’s because you’re not Aunt Minnie trying to figure out how much her “A” needs to weigh to make it through ACX testing. This is not an Engineering problem and More Is Better doesn’t apply.

Tech Check and ACX Check are different.

Koz

66

hi
may i ask a question ?
is there still the 30 seconds limit?
thanks

67

If you use ACX Check the maximum selection it will analyze is 100 million samples (about 37 minutes at 44100 Hz sample rate).

“Wave Stats” won’t analyze more than 30 seconds whatever the length of the selection.


Gale

68

Hi Gale
thanks a lot!

69

Minor update to Acx-check.ny
http://wiki.audacityteam.org/wiki/Nyquist_Analyze_Plug-ins#ACX_Check

Functionally there should be no change, just tidied up the code formatting. Ref: http://dept-info.labri.fr/~strandh/Teaching/PFS/Common/Strandh-Tutorial/indentation.html

If you have downloaded previously, it may be necessary to clear your browser cache, or download in a private/incognito window to get the updated version.

70

Hi

Question ACX check plugin
Is the limitation of 37 mins persistent? as in once the 37 mins limit is reached, it doesn’t scan any further track even if its a new request
What’s happening currently is that after scanning for 37 mins ACX plugin isn’t doing check for any new file which are more than 10 mins

71

Hello, I have a question for the software creator of this plugin. What type of RMS stat are you using? I need to understand how this plugin is measuring RMS values compared to other tools I normally use.

I ask because I’m getting different results using other software. I have been creating audiobooks for decades, and recently ACX has been rejecting files, saying they’re “too low in volume,” or whatever the automated language says. I haven’t changed a thing on my end, especially on the projects using the same voice, mic, studio, software, etc. All of a sudden the last several months, my projects are getting flagged. I deliver to many other publishers and have never had any files rejected for levels, so I’m perplexed why this is happening. BTW, most others follow the same general guidelines with -23 to -18 db range of total RMS.

ACX is being very unhelpful with this issue, repeatedly giving us automated or canned suggestions. I do my main work in Steinberg Nuendo. I check the RMS (total RMS) in Izotope RX and Adobe Audition for good measure. They agree on values. Hover, when I run the files through Audacity using this plugin, I get a lower (3 db) value. ACX has told us they use Audacity and this plugin to check all files.

I suspect it might be something Audacity is doing. It almost appears that they are invoking an aggressive pan law on mono files or something.

Thank you in advance for your answer, I appreciate your hard work on open source software.


Here’s a readout from one file that got rejected. I’ve included my independent software stats as well:

Audacity (using ACX Check plugin)

Peak level: -3.06 dB Pass

RMS level: -23.40 dB Fail (too quiet - RMS must be in range -23 to -18 dB)

Noise floor: -117.90 dB Warning (too low - Dead silence sounds unnatural.)


Isotope RX

Peak -3.05

Total RMS level -20.39



Adobe Audition

Peak -3.06

Total RMS level -20.39

Steinberg Nuendo

Title;Statistics - “002 Chapter 1 - Outriders-premix”
Date;Jul 21, 2021
Loudness_Value;-22.4 LUFS
Loudness_Range;5.5 LU
Max_True_Peak_Level;-3.05 dBTP
Max_Momentary_Loudness;-13.5 LUFS
Max_Short_Term_Loudness;-17.8 LUFS
Loudness_DG_Value;-23.2 LUFS
Loudness_DG_Range;5.4 LU
Dialogue;97 %
Sample Rate;44.100 kHz
Average RMS (AES-17) Middle;-20.40 dB
Max. RMS Middle;-12.36 dB
Max. RMS;-12.36 dB
Min. Sample Value Middle;-3.06 dB
Max. Sample Value Middle;-3.07 dB
Peak Amplitude Middle;-3.06 dB
True Peak Middle;-3.05 dB
DC Offset Middle;-oo dB
Bit Depth Middle;24 bit
Estimated Pitch Middle;3209.5Hz/G6

72

You should wait for the author/s of the plugin to respond, but I noticed something that
may well account for the 3dB discrepancy, AES-17.

From your post above:
Screen Shot 2021-07-22 at 5.35.37 PM.png
What I have noticed between different applications, is that some base their
measurements on AES-17, whilst others do not and do not mention it.
Nuendo does state it.

I use Izotope all the time, but since I only work in LUFS, don’t even
know if they use AES-17 or not.

Note that RMS readings are affected, peak is not.

ACX is one of those places that still use RMS and Peak, most others, like
TV, radio and even streaming services, have moved on to the LUFS system,
which makes much more sense, as it takes into account the perceived loudness
and takes into account, the Fletcher Munson Curves relating on human
perception of loudness versus frequencies.

73

The issue is described in this quote from the Replay Gain algorithm (Replay Gain - A Proposed Standard):

The only difficulty lies in what to do with stereo files. We could sum them to mono before calculating the RMS energy, but then any out-of-phase components (having the opposite signal on each channel) would cancel out to zero (i.e. silence). That’s not how we perceive them, so it’s not a good solution.

The alternative is to calculate two RMS values (once for each channel) and then add them. Unfortunately a Linear addition still doesn’t give the same effect as our ears. To demonstrate this, consider a mono (single channel) audio track. We replay it over 1 loudspeaker, and remember how loud it sounds. If we now replay it over 2 loudspeakers, how large should the signal to each speaker be such that, overall, the sound is still as loud as before? You’d think the answer would be half as large (since we have two speakers - that’s what a linear addition would suggest) but if you try it, you’ll find that the answer is about 3/4.

We get the right answer if we add the means of the channel-signals before calculating the square root. In mixing pan-pot terms, we’re using “equal power” rather than “equal voltage”. If we also assume that any mono (single channel) signal will always be replayed over two loudspeakers, we can treat a mono signal as a pair of identical stereo signals. Hence a mono signal gives (a+a)/2 (i.e. a), while a stereo signal gives (a+b)/2, where a and b are the mean squared values for each channel. After this, we carry out the square root and conversion to dB.

The ACX plug-in does the same as the ReplayGain algorithm. The RMS for stereo tracks is calculated as:
sqrt( ((mean-sq left) + (mean-sq right)) / 2)

Audacity’s “Contrast” tool works the same way Contrast - Audacity Manual

74

That document appears to be behind a paywall, but it is also discussed here: Forum

I think the basic solution is a lot simpler than it sounds and is down to the k-metering standard requiring the AES-17 RMS value which makes the RMS value of a sine wave equal to it’s peak value. As has been previously mentioned, the RMS value for a sine wave should normally be -3dB below the peak value. But for AES-17 and k-metering, 3dB is added to the RMS value so they both read the same.

75

The ACX plug-in does the same as the ReplayGain algorithm. The RMS for stereo tracks is calculated as:
sqrt( ((mean-sq left) + (mean-sq right)) / 2)

And the way I see it, therein lays the problem.
That formula assumes pure sine waves.
Speech and music and even noise, are not pure sine waves, but rather complex waves, more similar
to square waves.
The AES-17 standard tries to take this into consideration.

EDIT:

@Steve

I see you posted just before I posted this response.

@dynamix

Some DAWs like Cubase, give the user the option of not using AES-17.

76

Thanks. Yes I noticed that AES-17. Steinberg uses AVERAGE RMS, which can differ with TOTAL RMS at times, so I don’t use that as a guide when working on audiobooks. I mix for network television every week, so metering is straight forward there. ACX did tell me early on (when they actually had tech people that would call you back), that they used TOTAL RMS and used Adobe Audition to measure levels. They’ve since changed according to their latest email.

In regards to the ReplayGain algorithm, yes I’m aware of that. However, when every other publishing house requires TOTAL RMS values of a mono file to be -23 to -18, ACX is actually requiring them to be -20 to -15 when measured using professional software. I would have to raise the levels of all my books that I deliver to ACX, and keep others at the industry standard levels. That’s crazy.

77

Steve wrote:

That document appears to be behind a paywall,

Chrome’s developers tools are your friend. :wink:
Say no more…

78

dynamix wrote:

That’s crazy.

That’s ACX for you, so glad I don’t dabble in audio books for them.

79

Are you working with mono or stereo?
ACX prefers mono, but last time I looked they said that they would accept stereo so long as the entire book is stereo.

There’s the problem - there’s more than one “industry standard”.

If “RMS (AES 17) == RMS + 3dB”, what is “industry standard RMS”?

By the way, I’ve previously tested the ACX plug-in against ACX test files, and the plug-in agrees with the test files supplied by ACX.
You can find some test files here: A Critical Ear: The ACX Reference Sample Pack | ACX

80

Well, I agree that there is no industry standard, bad choice of phrase. I should have said common industry measurements. ACX’s test file would fail if I sent to another publishing house, just sayin’