Audacity Forum

Starting a new topic about possible noise removal improvements (not bug fixes). Maybe this should instead go in the "new features" thread?

Here are tinkle-bells made visible! Please pardon the big images.

Depicted here: Views are all Spectrogram log f to emphasize lower frequencies. Spectrogram settings are Rectangular and 2048 (because that is what noise removal "sees" too). Also Gain was set to 60, range 80 so that -60 and above is white, -80 is red, -100 is magenta, -120 is pale blue, -140 fades to gray.

First track is a bit of speech followed by some room tone. (I did some highpass filtering first.)

Second track is the result of Noise Removal (in 2.0.5) applied to the first track. The labelled portion was used as profile. The noise removal settings were (besides Sensitivity) extreme, at 48, 0.00, 0, 0.00.

Third track is the result of mixing the second and the inversion of the first for the difference of waveforms (what Isolate is supposed to do?).

Some soft "tinkebells" are seen in the pauses in the second. The are apparently at about -80 at most.

The third view makes evident the distortions in the words that are audible in the second track. These are the serious tinklebells! Many are above 1000 Hz where perceived loudness is much greater than for equal amplitudes at lower frequencies.

How did those tinkles above 1000 Hz get there when my noise sample is below -100 dB for that frequency range and the words are much louder there? I think I know the answer and a possible remedy in code, but there are tradeoffs.

Wait for my next post...

At line 478 of NoiseRemoval.cpp change this:
to this:
A one-character change! (Though min should then be called max.) I am doing the opposite of what Dominic put there in version 5979.

Repeat the experiment, and now look at the second and third tracks. The pauses are worse, but I think the words are improved more than the pauses are worsened, AND, this is the right change in algorithm that would let you increase the Sensitivity setting without bringing the tinkles back into the words. I don't yet have a demonstration of Sensitivity, but I was keeping all other settings equal to show the effect of this one change.

These pictures also reflect another bug fix in my build, which affects only the lowest frequency bin of the results. The next lowest bin is centered at 21.533 Hz (though the display aligns that with the bottom of the stripe instead of the middle).

My interests are with narration as you know. What does this do to your favorite musical examples?

UPDATE: loaded another version of the picture. There seems to be a bug that mislabels the vertical scale of Spectrogram Log F, unless you zoom out to the maximum.

Paul L wrote:There seems to be a bug that mislabels the vertical scale of Spectrogram Log F, unless you zoom out to the maximum.

Would that be: http://bugzilla.audacityteam.org/show_bug.cgi?id=525

steve wrote:

Paul L wrote:There seems to be a bug that mislabels the vertical scale of Spectrogram Log F, unless you zoom out to the maximum.

Would that be: http://bugzilla.audacityteam.org/show_bug.cgi?id=525

yes

Tried it again with the bug fix, increasing sensitivity 1 dB at a time until I saw no tinkles in the pause. That happened at 6 dB. Then repeat the procedure and look at the differences.

Can I say "Eureka" now?

Paul L wrote:At line 478 of NoiseRemoval.cpp change this:

How about changing: to: The main problem being that with either, in my initial test, the remaining noise becomes a lot more tinkly.
For music, the effectiveness on "silence" is often more important than on higher amplitude sound because, as long as the noise is reasonably low level to start with, it is largely masked by the (much louder) sound of the music.

As you anticipated, this is substantially mitigated by increasing the "Sensitivity" control, so that would need to be recalibrated.

By contrast, unmodified 2.0.5 only required 4 dB sensitivity to make all the tinkles in the final pause go away (and really there was just one left at 3). But then, look at the distorting effect in the words.

steve wrote:

Paul L wrote:At line 478 of NoiseRemoval.cpp change this:

How about changing:

Code: Select all

      float min = mSpectrums[start][j];
      for (i = start+1; i < finish; i++) {
         if (mSpectrums[i][j] < min)
            min = mSpectrums[i][j];
      }

to:

Code: Select all

float min = mSpectrums[center][j];

The main problem being that with either, in my initial test, the remaining noise becomes a lot more tinkly.

Why did you think this change would help?

Making "min" (rename it!) the maximum of the power over at least two successive windows is exactly what I need to fix the problem of foreground noise distortion as I understand the cause of it. I predict you will still have that problem with this change.

I just had another thought. The need to increase sensitivity would be lessened if the noise profile were examined more thoroughly.

I said noise removal "sees" the spectrogram with rectangular windows of 2048, but it steps by half a window so it really sees only every 1024th column of colors. That may be adequate for good noise removal but when examining the profile, we can afford to take smaller steps. Profile is supposed to find for each bin the 50 ms period in which the least amplitude is greater than in other periods and make that the theshold. Testing more than two amplitudes in each 50 ms would raise the threhold. A higher threshold means more gets recognized as noise. Tinkles in the background happen when too little is recognized as noise. (Distortions happen in foreground when to much is recognized.)

Paul L wrote:Why did you think this change would help?

What I was thinking was, looking at how the profile is created, rather than take the min or max, why not take the average?