Auto Duck misses sections on a 60 minute audio file

Hi,

I’m using Win 10 and Audacity 3.0.3 (but the same thing happens using Audacity 3.0.2 and 3.0.0).

I’m trying to AutoDuck the top file against the second file.

Window001.jpg
The files are about 60 minutes long and when I run AutoDuck on the whole file, it misses ducking in various parts of the file - both middle and end.

Window000.png
But when I run AutoDuck on 20 minute sections of the file at a time, it does end up ducking as I was expecting it to.

Window002.jpg
Any ideas on what is going on?

Thanks,

Mike

It would be much easier for us to see what you are doing if your screenshots showed the waveforms rather than the spectrograms.

Hi Steve,

Okay - here it is in different format. I left the first audio file in spectrogram view because it’s not easily visible in waveform. I also am showing only about 3 minutes of audio at a spot where the issue is occurring (at 31 minutes into the track) so that you can see the detail in the waveform.

I’m attempting to put some brownian noise (top track) in the blank spots that are part of a Zoom audio recording (bottom track) where it is too quiet. So I’m running AutoDuck on the noise track against the Zoom audio and then mixing the two files together.

Again, I’m trying to AutoDuck the top file against the second file.

Window004.png
The files are about 60 minutes long and when I run AutoDuck on the whole file, it misses ducking in various parts of the file - both middle and end.

Window003.png
But when I run AutoDuck on 20 minute sections of the file at a time, it does end up ducking as I was expecting it to.

Window005.png
Thanks,

Mike

Hi,

Here is the same issue using a generated tone instead of a generated noise as the audio to be AutoDucked.

Window000.png
Mike

It’s working for me:

Screenshot_2021-07-30_06-26-13.png
Any suggestions of what I need to do to reproduce the issue?

Steve,

I zoomed in on a section that demonstrates the issue and I think I narrowed it down to maybe the Threshold setting.

First image - a tone track and a control track showing a section of the control track that has a dB level of -74.

Capture1.JPG
Next, are the AutoDuck settings I want to use.

Capture2.JPG
Results of AutoDuck settings when applied to the whole tone track. I expected the tone track to dip where there is silence (-74 dB).

Capture3.JPG
Results of AutoDuck only being applied to the section of the tone track in the window. The track dips where I expected.

Capture4.JPG
If I set the Threshold setting at -49 instead of -50 I get the expected results when I apply AutoDuck to the whole tone track. But since the volume level is -74dB, I would expect the same results using a Threshold setting of -49 or -50. And the fact that AutoDuck works on a small section of audio with Threshold at -50 but not the full selection of audio with a Threshold of -50 seems odd.

Does this help at all?

Mike

Thanks Trebor,

I see what you are saying.

When I first started setting up the process (a while ago) to fill in quiet spots in the audio automatically, that parameter caused many of the spots to be missed during the AutoDuck effect. But when I set it to Zero, all of the quiet spots were picked up. So it does “seem” to work at a setting of Zero.

And, as I mentioned in my prior post, if I set the Threshold at -49 instead of -50, even with the Maximum Pause at 0, it does work. Or if I use my settings with a -50 Threshold on 20 minute portions of the audio instead of on the full audio file, it also works.

So it just seems like the Threshold setting and/or the length of the audio processed is causing the issue.

I do see that the effect does do a look-ahead on the Control Track first and then does the processing on the selected track - so that could be a part of it as well. Especially since it seems to happen in the latter part of the selected track. Maybe the initial scan of the Control Track has something going on when it “stores” the parameters that it is going to apply to the selected track.

Thanks,

Mike

Thanks for the added detail.
I can see something peculiar, and also discovered a couple of “features” that I wasn’t aware of.

“Features”

  1. The amplitude measurement is NOT a peak level measurement. It looks to me to be a “kind of” average square measurement based on a (tiny) 100 sample window.

  2. The fade in / out are logarithmic fades, not linear.

I guess these features make some sense when the effect is being used for the intended purpose of automatically ducking a music track from a speech track, but it does not lend itself well to “technical” or “scientific” use where precise measurements are required.


The peculiar / weird behaviour that I’ve observed only seem to occur when dealing with very low levels, and I don’t yet know what is causing it, or even how to precisely define what is happening, but yes I can confirm that it is doing weird things when dealing with very low level signals.

A workaround:

Temporarily amplify the control track by, say +30 dB (you will need to enable the option “Allow clipping”), and set the threshold in Autoduck to -20 dB instead of -50 dB. After applying Autoduck, amplify the control track by -30 dB to take it back down to normal level.

Steve,

Wow - a great workaround - worked perfectly - very clever!

I hope they double your pay! :smiley:

Mike

Very interesting. I’ll try to get to the bottom of why this is happening. Thanks for reporting!

I transferred the bug report to github: https://github.com/audacity/audacity/issues/1389
You can subscribe to the bug to receive updates and be the first to know when it gets fixed :slight_smile:

Thanks LWinterberg - I will do that! And I appreciate all the effort you all put into keeping Audacity up and running.

A fix has been made: https://github.com/audacity/audacity/pull/1449

Basically, the way audacity calculates peak amplitude is now twice as precise, so it should happen way, way less frequently in the future. It unfortunately can’t be completely eradicated, as computers need to stop calculating digits on a number eventually.

It’s much more precise now (many billions of times more precise). It now uses double the amount of bytes to calculate the running total (8 bytes rather than 4 bytes).

I think there is still an issue with the documentation. I expect that most users will assume that the “Threshold” level is “peak dBFS”, but it isn’t, it’s RMS with a 100 sample window size (extremely small window). This misunderstanding gives the (false) impression that Auto Duck is much less precise than it now is (post fix).

Thanks for fixing this!

Does the fix come out in the next update, or is there a download that just fixes the Auto Duck effect?

Mike

Yes, I expect so.
I looked this morning and the fix was approved but still waiting to be committed to the main code base. (I tested by building Audacity from the source code after manually applying the code fix).

I’d suggest using the workaround that I posted previously (Auto Duck misses sections on a 60 minute audio file - #9 by steve) until the next Audacity release.

I expect that most users will assume that threshold means “louder than”, with only a vague and fuzzy idea of how that’s measured.

Yes, many of our users have little experience working with digital audio, but a significant number are very knowledgeable about such things.

In other plug-ins / effects, past and present, “threshold” is taken to mean a peak level, unless it explicitly says otherwise (Examples: Sound Finder, Silence Finder, Noise Gate, Limiter, Truncate Silence…)

In this one case, not only does it not use the peak level, it uses an exceptionally small window for the RMS measurement. Unless you’ve read the code, you would not know what it is doing, and if you investigated experimentally you would observe that the level detection in Auto Duck is “apparently” rather inaccurate.

My tests with the recent fix indicate that it is accurate, if you understand what it is measuring.

I agree that this doesn’t really matter for most users, and therefore does not require a lot of attention in the manual, but it is unusual and unexpected, so I think it should have a mention in the manual. It may also avoid unnecessary "bug reports in the future.