Audacity Forum

Posted: **Mon Sep 08, 2014 3:29 am**

steve wrote:
Paul L wrote:I am eager to learn how that process goes...
The formal process is along the lines of:
1) Log bug/enhancement on bugzilla. This should clearly define the issue.

That usually implies that separate issues in the code should be separate bugs, but that interface issues could possibly be subsumed into one bug.

If one patch depends on another and so must be applied after another, that must be stated.

Gale

Posted: **Mon Sep 08, 2014 4:38 am**

This is steps for Mac, with follow on steps for Windows at the end.

I have not yet made the issue happen with simpler steps.

Generate 2s white noise at 0.5 amplitude.
Change to Waveform (dB) view
Effect > Noise Removal and capture the Noise Profile.
K
Generate > Tone, 2s, 440 Hz, 0.99 amplitude.
View > Fit in Window.
Double-click the noise clip between 0s and 2s, Edit > Copy.
K then Edit > Paste.
View > Fit in Window.
Click in Track Info to select all the track.
Open Noise Removal and apply at -48 dB Noise reduction and attack/
decay 1s.
Edit > Undo.
Double-click in the noise at 4s to 6s.
Effect > Repeat (10 times).
View > Fit in Window.
The first time I did this I clicked in the track between 14s and 16s
so though it is not needed after step 15, I now had to drag from the
end of the track at 26s to 4s (the end of the tone). Wait for the
yellow boundary snap guide to appear at 4s.
Effect > Noise Removal, apply same settings.
Edit > Undo Noise Removal or COMMAND +Z
Observe flash in the clip between 8s and 10s. Edit > Undo still says
Undo Noise Removal
Effect > Repeat Noise Removal.
Now I can Undo Noise Removal twice.

You may have to do 17 and 18 several times before the problem happens.

You may then have to do 20 several times before you can do both Undo
Noise Removals.

On Windows, step 18 has not failed (yet). From Step 18 above, do this
on Windows:

Click in the track info to select all the track
Effect > Noise Removal, apply the effect.

If step 2 does not reduce the entire waveform to silence or -54 dB, Edit > Undo then Effect > Noise Removal > OK until it does.

For Windows step 1 you may instead drag-select from 26s to 2s (start of the tone) then Step 2. The tone will then still be reduced (sooner or later) if you keep undoing and reapplying from the effect's GUI.

Feel free to try with other effects - as Paul says this may be nothing to do with Noise Removal per se, but whatever it is, 2.0.5 does not seem to do it.

I have also made the problem happen on my Win 7 netbook, after many "Undo then Effect > Noise Removal > OK" after Windows step 2.

Gale

Posted: **Mon Sep 08, 2014 5:00 am**

steve wrote:4) One of the developers will then review the patch and if they are happy with it they will commit it.

Meaning one of the seven people listed in the "About Audacity" dialog?

Posted: **Mon Sep 08, 2014 5:05 am**

Gale Andrews wrote:This is steps for Mac, with follow on steps for Windows at the end.

I have not yet made the issue happen with simpler steps.
...

Gale

This should be an improvement. I might debug the Windows problem. How big is "several?" What I am looking for is a difference of results after undoing and reapplying the effect, and I must use the effect dialog, not "Repeat last effect."

Posted: **Mon Sep 08, 2014 5:26 am**

Gale! I repeated your steps on Windows 7, debug build running in the debugger, and I DO see an undo problem! Intermittently, but not too rarely.

I noticed the application sometimes gets in a state where Edit menu lists "Undo Noise Removal" but if I select the menu item, NOTHING HAPPENS, and the track remains as it was. And the same "Undo Noise Removal" remains. Is that also what you saw?

I even hit a breakpoint in the debugger that may tell developers something:

Code: Select all

void AudacityProject::OnUndo()
{
   if (!mUndoManager.UndoAvailable()) {
      wxMessageBox(_("Nothing to undo"));
      return;
   }

   // can't undo while dragging
   if (mTrackPanel->IsMouseCaptured()) {
      return;
   }

The second return is the path by which the Undo command may silently do nothing, and I did indeed hit that statement.

I am guessing we are seeing some weird timing dependent thing involving the UI code, and I am not likely to figure it out faster than someone more familiar with it.

Posted: **Mon Sep 08, 2014 5:35 am**

More detail: I caught the application doing this again, and I stepped inside this function:

bool TrackPanel::IsMouseCaptured()
{
return (mMouseCapture != IsUncaptured);
}

mMouseCapture had the value "isOverCutLine".

This suggests that cutlines are a necessary condition. If indeed I am seeing the bug that you saw.

Posted: **Mon Sep 08, 2014 5:50 am**

Paul L wrote:I think I can explain the apparent fade-out at the end of track (and did you notice fade-in at the start too?).

Yes, just a little fade in at the start.

Paul L wrote:
Gale Andrews wrote:Edit > Undo, double click the pasted noise and Effect > Repeat 10 times for noise of 22 seconds. CTRL + A, then apply Noise Removal at the same settings by opening the effect. The pasted/repeated noise is still at about -20 dB.
Try 1024 repetitions instead, and I predict the result will have some intervals where correct noise reduction happens. You might need shorter attack time to make that effect undisguised.

It all has to do with how the FFT windows of 2048, staggered by 1024 sample steps, align in the repeated piece of noise. Wait long enough and you happen to get "in phase" with the noise removal profile again sometimes

Yes, there are about a dozen short sections in the circa 34 minutes of noise after the tone where there has been noise removal to the expected level.

So is this regarded as a bug in this demo case, or expected at zero Sensitivity? A naive user would probably see it as a bug.

What should Decay look like? I assumed it was supposed to be (after the tone) a fade down into the reduced noise level, but my test case did not show it.

In the few sections of reduced noise after the tone (as above), I do see (with attack/decay set to 1s) a 1s fade down to the lower level of noise and a 1s fade up from the lower level to the higher level of noise. Fade length changes to about 0.5s at 0.5s attack/decay setting.

When we have a separate attack/decay setting these will have to be defined in the Manual. How would you define them?

Gale

Posted: **Mon Sep 08, 2014 5:50 am**

If I zoom far out on this project with many cut lines, and select all, and call up the dialog, and wiggle the mouse over the cut lines while the progress dialog fills, and then use the menu... it seems to make the bug I saw more frequent, but still not every time.

I have a suspicion that this may have some connection with the code that switches the cursor between ibeam and arrow when near cutlines.

I don't want to spend more time on this. I am convinced it is a strange UI issue with nothing peculiar to this effect.

But I did not complete your list of steps, and there may be that distinct problem.

Posted: **Mon Sep 08, 2014 6:02 am**

Paul L wrote:Gale! I repeated your steps on Windows 7, debug build running in the debugger, and I DO see an undo problem! Intermittently, but not too rarely.

I noticed the application sometimes gets in a state where Edit menu lists "Undo Noise Removal" but if I select the menu item, NOTHING HAPPENS, and the track remains as it was. And the same "Undo Noise Removal" remains. Is that also what you saw?

Exactly what happens. And funnily enough I have just seen it on Windows 8.1 now while I was playing around with the steps.

Paul L wrote: I am convinced it is a strange UI issue with nothing peculiar to this effect

OK, but by the time we release 2.0.6 it would be useful to know for the Release Notes whether all effects will be subject to it.

Do you agree 2.0.5 does not do it?

There is still the question of incorrect reduction of level to the tone, if you do complete the steps. I have not seen that yet on Mac. Could (any) effect become confused by the failed Undo in some way that could lead to unexpected results?

Gale

Posted: **Mon Sep 08, 2014 6:10 am**

Gale Andrews wrote: Yes, there are about a dozen short sections in the circa 34 minutes of noise after the tone where there has been noise removal to the expected level.

So is this regarded as a bug in this demo case, or expected at zero Sensitivity? A naive user would probably see it as a bug.

I would call it very unsatisfactory behavior and would not disagree with calling it a bug. Or an algorithm that was never sufficient. Mind you, how often in the real world do we have noise peaking at -6 dB? But extreme cases do reveal things sometimes.

I have started to think of Sensitivity as the "compensate for our inadequate analysis of your noise profile" button.

Gale Andrews wrote: What should Decay look like? I assumed it was supposed to be (after the tone) a fade down into the reduced noise level, but my test case did not show it.

Push Sensitivity up to about 6 dB and it should look better.

Gale Andrews wrote:
In the few sections of reduced noise after the tone (as above), I do see (with attack/decay set to 1s) a 1s fade down to the lower level of noise and a 1s fade up from the lower level to the higher level of noise. Fade length changes to about 0.5s at 0.5s attack/decay setting.

yep.

Gale Andrews wrote:
When we have a separate attack/decay setting these will have to be defined in the Manual. How would you define them?

Gale

Hmm, we (including steve) might debate how best to say this.

Foreground sounds are supposed to be non-attenuated, and background noise is attenuated. Attack/decay time defines the length of a transitional period. The transition affects only the background. Some of the background noise is less attenuated just before the loud sound, and we can call that one "attack," and there is another transition after, which we can call "decay."

("Attack" and "decay" usually refer to attack and decay of loud sounds, not of the effect, right? Though actually then, "attack" happens at the END of a portion affected by noise removal, and "decay" happens at the START of the affected portion. So a pedant might say the terms are reversed.)

In other words "decay" happens where the sound decays.

If a musical chord fades out, we might do less noise removal in the relevant frequency so that we preserve more of the fade-out. This is why I think it makes sense to have a separate decay setting that can be set longer than attack.

A long enough decay to preserve that fading chord, if constrained to be equal to the attack time, might have the undesirable effect of making an unnatural "whoosh" leading up to the sound.

I am not sure why we really need nonzero attack time, but that is a matter for experiment and judgment once we separate them.

That is not too perspicuous, I need an editor

Audacity Forum

NoiseRemoval.cpp

Re: NoiseRemoval.cpp

Re: NoiseRemoval.cpp

Re: NoiseRemoval.cpp

Re: NoiseRemoval.cpp

Re: NoiseRemoval.cpp

Re: NoiseRemoval.cpp

Re: NoiseRemoval.cpp

Re: NoiseRemoval.cpp

Re: NoiseRemoval.cpp

Re: NoiseRemoval.cpp