ACX Check fails in 2.4.1

[steve]

There's also quite a lot that get rejected. Did we not have a case a while back where someone was rejected for excessive noise, even though the short sample they sent to us sailed through our ACX-Check?

Another thing to factor in: I have come into possession of an audiobook that we would expect to fail on multiple counts. It has background music, the noise was gated, it has peaks over -3dB ... it was accepted and published.

[kozikowski]

even though the short sample they sent to us sailed through our ACX-Check?

Correct. My theory on that one was "Noise" is a convenient excuse for a really poor reading. Rather than complain about specifics and offer constructive suggestions as is normal (and would have taken forever), they failed the submission on Noise which all home readers fail. I chalked that one up to Occasional Outlier or an actual mistake. That's not normal.

the noise was gated

I think there's a place on one of their instructions where it says to do that. I gasped in horror.

I think it's possible their own QC may be falling apart. Nobody is coming in to work (or are already sick) and there are millions of candidates waiting for analysis. You look out the window and the line goes—masked and 2M apart—into the next county. There's only so much rejection an inspector can manage before they have to go sit on a quiet moor somewhere with a strong cuppa.

Couple that with the adverts and postings insisting you can read on your kitchen table, become a star and retire.....or at least be able to afford your next meal.

There is one other level of acceptance past the book author, assuming they're different. Customer complaints and demanding their money back.

~~

Real Life is catching up to me a bit.

Koz

[kozikowski]

We lost flynwill. He posted the last legacy correction and had to go play his own Real Life. That version works as expected, except it it takes minutes to get through the check on a long show.

Koz

[steve]

From flynwill's Acx-check.ny:

Code: Select all

NoiseFloor - the RMS level of the quietest 500 mS in the selection

Is that what you want Koz?

If it's a very long selection, does it need to check the entire selection for the lowest 500 ms, or just the first bit?

If just the first bit, how much does it need to test? Would the first minute be enough? 5 minutes? 30 minutes?

[kozikowski]

I broke free some time to patch the wiki and buffed up the original test suite.

I got around the noise problem by making the performer pick the noise test site.

Drag-Select room tone or a pure, quiet background portion of your file.

https://www.kozco.com/tech/audacity/ACX ... sting.html

the entire selection for the lowest 500 ms, or just the first bit?

In theory, if you can't find a half-second of good room tone anywhere in your performance, you failed—no question. That was the idea there.

It's far more involved to certify health, and further, as you pointed out, it's possible to game the system. "Look at me with -96dB noise." Sure. I believe you.

There's another vector with this, too. It's relatively easy to analyze a finished piece with the two room tone segments at the ends. It's far harder to do a partial chapter, where there's no guarantee of anything. That's when you start analyzing the spaces between syllables, or throwing up your hands. That's the admonition that if you didn't leave enough time for background noise, we're going to give you a bogus high value.

Maybe half-second is too long.

I'm not fond of surgically diving for noise with 1/100 second samples. That just feels wrong, plus I don't think anybody would ever pass.

Koz

[steve]

I broke free some time to patch the wiki and buffed up the original test suite.

Yes I saw. That's what prompted me to get back to this topic.
We're close to next release candidates, so it would be good to get this plug-in fixed up as necessary before my time all gets eaten up by RC testing.

In theory, if you can't find a half-second of good room tone anywhere in your performance, you failed—no question. That was the idea there.

I can do that, but I'm thinking, what if the trailing silence is -65 dB and the leading silence is -45 dB?

It's far more involved to certify health, and further, as you pointed out, it's possible to game the system.

Yes, and that's the point of giving readings for 30 second chunks.

"Look at me with -96dB noise." Sure. I believe you.

It's far harder to do a partial chapter, where there's no guarantee of anything. That's when you start analyzing the spaces between syllables, or throwing up your hands.
...
Maybe half-second is too long.

I've checked through some audiobook recordings, and found that there is invariably at least one "gap" of 0.5 seconds or more (usually around 5 such gaps per 30 seconds), but most of these gaps include breaths. Unless the engineer has gone through the recording subduing breaths and mouth sounds, most of these half second gaps will be above the noise floor.

If we're trying to measure the noise floor in these gaps we have to catch a gap between "word ...... breath ... word".
0.5 seconds is too long to reliably catch these gaps between words and breaths, though 0.2 seconds seems to work pretty well.

I'm not fond of surgically diving for noise with 1/100 second samples

1/100th second is too short - you could get "lucky" and find 1/100th second that measure -60dB during near continuous noise.


ACX specs say:
"Each file must have 0.5 to 1 second of room tone at its beginning and 1 to 5 seconds of room tone at its end."
We can easily, and quickly test for the lowest 0.5 seconds within the first 5 seconds of the selection. If this is what we test, then we can have high confidence that the measurement is accurate.

[steve]

We can easily, and quickly test for the lowest 0.5 seconds within the first 5 seconds of the selection.

I'm liking this idea, but more importantly, do you like it Koz?

[kozikowski]

"Each file must have 0.5 to 1 second of room tone at its beginning and 1 to 5 seconds of room tone at its end."

Each finished, submitted chapter must have.... That doesn't work for production steps in the middle.

We can easily, and quickly test for the lowest 0.5 seconds within the first 5 seconds of the selection.

That doesn't work for production steps in the middle, pretty much as I'm doing right now with the hour-long interview. Can we do a legacy file test @ 0.25 second instead of 0.5 second? Pick the lowest value?

Is it a law that we have to open up the whole performance at one go? That seems to be cause the memory issues. I don't suppose there's any way to provide a progress bar.

Koz

[kozikowski]

We can easily, and quickly test for the lowest 0.5 seconds within the first 5 seconds of the selection.

First and last?

Koz

[steve]

Each finished, submitted chapter must have.... That doesn't work for production steps in the middle.

That's down to workflow.

If the original recording is done as:
1. Start recording
2. Silence
3. Start talking
then it does work.

If the recording is done as:
1.Start recording
2. Start talking
3. Stop recording
4. Record room tone
5. Paste the room tone to the start
then it does not work.

It's questionable whether the second workflow is authentic. It would be tempting, and very easy to cheat.

Is it a law that we have to open up the whole performance at one go? That seems to be cause the memory issues.

It is a law that we can only read the selection once.

We can't do:
Read data -> Analyze -> Read data -> Process -> Output

We have to do:
Read data -> Analyze -> Process -> Output

The memory issue occurs if we analyze from start to end, then process from start to end, because the data would need to be held in RAM.
The solution is that Read -> Analyze -> Process happens as a continuous stream, so that as samples are processed, they can be discarded from RAM.

I don't suppose there's any way to provide a progress bar.

There is no progress bar when running code in the Nyquist Prompt, but when run as a proper plug-in a progress bar should automatically appear when required. Unfortunately progress bars in Nyquist effects may not be accurate, because Audacity has to estimate how long it will take Nyquist to process before it returns a result. It's like Audacity is subcontracting part of the job to Nyquist, and then asking Audacity how long the job will take.

First and last?

To get at the last bit we have to process the entire selection. We don't have random access to the data, only sequential access.
So long as the code is reasonably efficient, it shouldn't take too long to process an hour long track.

Can we do a legacy file test @ 0.25 second instead of 0.5 second?

I can probably make the length of required silence adjustable so that you can test with different values. You can then let me know what value you like best, and I'll hard code that value.