NoiseRemoval.cpp

[steve]

I read this in the 2.0.5 manual page for the effect:

Sadly, the people writing the manual rarely receive detailed information from those contributing new code. This is an example of where the documenters seem to have drawn an incorrect conclusion about what the effect does. The manual suggests that the "Isolate" feature is the inverse of "Remove", but as you say, that is not the case.

With extreme high settings, what should happen is fairly clear.
If "Noise Reduction" is very high, then when removing noise, all of the noise should be removed leaving only the non-noise (ideally).
If "Noise Reduction" is very high, then when isolating noise, all of the non-noise should be removed leaving only the noise.

What is less clear is what should (ideally) happen for lower settings.
If "Noise Reduction" is zero and "Remove" is selected, we should remove no noise. Output = input.
If "Noise Reduction" is zero and "Isolate" is selected, then there are two possible ideal behaviours:
A) If we think of "Isolate" as the inverse of "Remove", then the result should be silence.
B) If we think of "Isolate" as "reducing non-noise", then the result should be no change. Output = input.

The 2.0.5 manual suggests case "A", but the effect behaviour is (almost) case "B".

As the effect in 2.0.6 will be the same as now, I've changed the 2.0.6 manual to say:

Isolate: Select this option to keep the noise and reduce other sounds in the selection.

[Paul L]

But the existing thing is just a botch under either interpretation.

[steve]

Maybe so, but it is not going to be fixed in time for the 2.0.6 release so we need to be pragmatic about it.

[Paul L]

Then, let's look ahead to .7.

[steve]

Indeed

[kozikowski]

[adjusting spectacles to distant vistas]

That doesn't mean it shouldn't be worked on. It might take between now and then to get corrections.

Noise Removal would be pure gold if it worked better than it does now. Also see: Auto Profile. Noise Removal is ripe for improvements including changing the name to Noise Reduction.

Koz

[waxcylinder]

I agree with Koz (and others) that it would be a good change just to change the name of Noise Removal to Noise Reduction.

I like stuff that "does what it says on the tin" - and reduction, not removal, is what the effect does - clarity of purpose should be explicit in the syntax nomenclature, otherwise we find ourselves setting unrealistic expectations for users.

Personally I would like to see such a change made before 2.0.6. Surely such a simple change cannot de-stabilize the code? I can't change the code - but I'll be happy to spend time fixing the Manual if this change gets made ...

In order to make such a change it would be necessary to consult with Vaughan as the Release Manager for 2.0.6

Peter.

P.S. But of course this simple change does not and should not preclude future work on improving the efficacy of this effect.

[Paul L]

The truly minimal change would leave a mismatch between names in the code and names in the dialog. Programmers might live with that. Ah, but would it break saved Chain files and preferences? That might make some users a little unhappy during migration.

[Paul L]

Who can explain to me the "tinkle bell" problem and the history of attempted solutions? Some discussion here http://wiki.audacityteam.org/wiki/How_N ... oval_Works

It looks like Dominic varied his solution to it. I wonder too if the sensitivity slider, added by others later, was motivated in part by this problem.

That wiki page says

The first pass of noise removal is done over just noise. For each windowed sample of the sound, we take a Fast Fourier Transform (FFT) and then statistics are tabulated for each frequency band - specifically the maximum level achieved by at least <n> sampling windows in a row, for various values of <n>.

But I believe n is always 2 (at least with 44100 sample rate).

Then frequency-smoothing is applied so that a single frequency is never suppressed or boosted in isolation, followed by time-smoothing so that the gain for each frequency band moves slowly.

Actually the procedure does first time-smoothing, then frequency smoothing. This incorrect description is replicated in comments in NoiseRemoval.cpp.

The tinkly artifacts happen when individual pure tones are near the threshold to be preserved -- they are small pieces of the background soundscape that survived the thresholding, perhaps because the background noise is slightly different from the fingerprint or because the main sound has overtones that are imperceptible but that boost them slightly over the threshold.

I think that some of the artifacts I hear, when time and frequency smoothing are set to minimum values, are the opposite: bits of foreground are mistaken for noise and subtracted causing a drop-out in a frequency band.

I tried rewriting Noise Isolation so that it simply assigns gain factors of 1 to noise and 0 to the rest before inverse FFT, with no time or frequency smoothing. In one trial, this isolates something that does a very good job of cancelling noises in the pauses of speech when inverted and mixed with the original. However, hearing it alone, there are plenty of tinkles inside the words.

So while the Audacity noise gating algorithm could perhaps be improved [...]

Already I am speculating about one way to remove the tinkles from the words. It might put them back in the pauses. However, a positive sensitivity setting may then offset that effect. Will experiment today.

[waxcylinder]

The truly minimal change would leave a mismatch between names in the code and names in the dialog. Programmers might live with that. Ah, but would it break saved Chain files and preferences? That might make some users a little unhappy during migration.

A very good point Paul - a regression with Saved Chains ...

So maybe we just let sleeping dogs lie ??

Peter.