NoiseRemoval.cpp

[Gale Andrews]

There is no linguistic problem if we say we are "removing" noise and specifying "how much" we are removing. The effect of "removing" some of the noise is that we have "reduced" the amount of noise. To say that we have "removed" the noise is misleading because it implies that we have removed all of the noise, which as we all know causes unwanted side effects that can be worse than the problem that we started with.

The dialogue refers twice to "filtering". I doubt naive users know what that might mean but I assume it means remove, and the action choice is "Remove" (or "Isolate").

It is clearly confusing for the name of the effect to be called something other than the action choice.

We can add Goldwave and CoolEdit to Steve's list of apps that have better noise reduction (better also in that they give better results at default settings).

My objection to the rename is not that we may seem to be saying we've watered it down but we are admitting it is not as good as it should be. If Audacity Noise Removal was better there would be much less demand for a name change (though "Noise Reduction" would have been a better choice to begin with).

I agree with Steve that any rename should be deferred until there is a substantial change in the effect (and probably therefore also GUI changes).


Gale

[Gale Andrews]

Dare I hope that I might be discovering improvements?

Thanks for your perusal of the code and your interest, Paul.

I am sure the current algorithm can be further tweaked but I am not sure to what extent that tweaking it will solve the basic problem.

My impression is that we should be looking at spectral subtraction or noise coring as the future of Noise Removal (or whatever it's called) and/or present choice of algorithm as the main parameter to change when removing noise rather than users spending hours fiddling with combinations of different parameters of the same algorithm.

We always want to offer detailed control of parameters for advanced users but for more basic users they need simpler choices like "algorithm 1, 2, or 3" and "Weak, medium or strong reduction".


Gale

[Paul L]

I think the variations of algorithm could still share much of the existing code that handles the business of going to frequency domain and back again.

I have begun another thread about changes that I consider experiments, rather than the bug fixes I talked about here above.

http://forum.audacityteam.org/viewtopic ... 21&t=80241

[steve]

Just a thought:

Rather than having the options "Remove" and "Isolate", we could have 3 options:

• Remove: Removes some of the profiled noise so as to reduce the noise level.
• Residual: Inverse of "Remove". Returns the sound that would be removed if we used "Remove". (Original sound - noise reduced sound).
• Isolate: Removes some of the "non-noise" so as to reduce the non-noise level. Isolates the profiled "noise".

There may be a better name than "Residual". Perhaps "Inverse" or something else, but important to distinguish it from "Isolate" (which is very different for low settings).

[schmide]

So seeing this go on for 8 pages made me want to see what's going on. I walked through the code and to me it seems to allocate the right number of buffers and do the attack decay over the correct number of windows. 1s = 87. I do see that the isolate function does not invert/shift the attack decay function so it has the opposite effect on the floating gains. Just to test this case added the inverted case for isolation at line 489.

Code: Select all

   // Decay the gain in both directions;
   // note that mOneBlockAttackDecay is less than 1.0
   // of linear attenuation per block
   // A.C.H inverted the funuction for isolate
   if (mbLeaveNoise) {
      for (j = 0; j < mSpectrumSize; j++) {
         for (i = mHistoryLen-2; i > center; i--) {
            if (mGains[i][j] < mGains[i + 1][j] * mOneBlockAttackDecay)
               mGains[i][j] = mGains[i + 1][j] * mOneBlockAttackDecay;
            if (mGains[i][j] < mNoiseAttenFactor)
               mGains[i][j] = mNoiseAttenFactor;
         }
         for (i = 1; i <= center; i++) {
            if (mGains[i][j] < mGains[i - 1][j] * mOneBlockAttackDecay)
               mGains[i][j] = mGains[i - 1][j] * mOneBlockAttackDecay;
            if (mGains[i][j] < mNoiseAttenFactor)
               mGains[i][j] = mNoiseAttenFactor;
         }
      }
   } else {
      for (j = 0; j < mSpectrumSize; j++) {
         for (i = center + 1; i < mHistoryLen; i++) {
            if (mGains[i][j] < mGains[i - 1][j] * mOneBlockAttackDecay)
               mGains[i][j] = mGains[i - 1][j] * mOneBlockAttackDecay;
            if (mGains[i][j] < mNoiseAttenFactor)
               mGains[i][j] = mNoiseAttenFactor;
         }
         for (i = center - 1; i >= 0; i--) {
            if (mGains[i][j] < mGains[i + 1][j] * mOneBlockAttackDecay)
               mGains[i][j] = mGains[i + 1][j] * mOneBlockAttackDecay;
            if (mGains[i][j] < mNoiseAttenFactor)
               mGains[i][j] = mNoiseAttenFactor;
         }
      }
   }

Sorry for the resolution and resize. (I'm at 4k)


The other big thing I can see is places where data is unavailable are not being handled correctly. (I.e. Beginning and Ending) There should probably be some replication of the first sample into the null space to handle this.

Realize I've only poked around at this for a few hrs. It seems to be nothing more than a floating auto level; very useful, but only designed to do so much.

[Paul L]

5) Noise profiles with narrow spectrum do not result in a narrow notch effect with frequency smoothing off. Test case described. Could fix.

Have fix.

[Paul L]

But that raises the question, what should happen when noise profie is shorter than 2048samples. An error dialog?

[Robert J. H.]

But that raises the question, what should happen when noise profie is shorter than 2048samples. An error dialog?

Imo, the window size should be at least twice (rule of thumb, 1024 for voice, 4096 for music).
Has anyone tested at different sample rates?
Modern approaches use multi-rate FFT's anyway, mostly following human perception.
The smoothing could thus be linear under 1000 Hz and logarithmic above it.
Windowing should be two-fold, on the analyse and synthesize side and something that is adapted to the smoothing mechanism.
The profile should perhaps rather be made outlayers-free (median or something else non-linear).

[Paul L]

I am not sure I understand multi rate FFT or twofold windowing.

You mention medians. I was just about to suggest to steve, in the other recent thread about this, that the right thing to do with the profile is find a certain quantile of the power for each bin.

I suspect that the time and frequency smoothings and the sensitivity setting might be complications just to compensate for thresholds being set too low by the analysis now done on the profile. So fluctuations above the theshold in the noise cause tinklebells in the silences. Dominic added frequency smoothing while Marco Aureliano later added Sensitivity so you can raise the thresholds.

Should we figure out how to make noise removal work well in most cases even when smoothing and sensitivity are all set to zero?

[steve]

Would it be correct to say that Noise Removal is working like a multi-band noise gate?