NoiseRemoval.cpp

[Paul L]

Steve discovered a while ago that

The overlapping FFT windows each remove the DC offset over the period of each window. That just leaves the final window that does not have the offset completely removed.

Apart from the final glitch, the DC removal is arguably better than in Normalize if the whole track does not have offset.

Where did Steve say that?

[Paul L]

I see there is something weird going on at start and end. In my examples, in fact the last 1024 samples of DC or Nyquist frequency are not silenced but fade in with a half a Hann window.

When I attempt a fix, now the beginning of the sound has such a fade in.

Something else seems off and I didn't catch that by reading.

[Gale Andrews]

Will you test a few-lines change if I write it for you?

Um, are you having problems compiling Audacity? What platform are you on?

Try this, to demonstrate that attack times are only half as long as they are supposed to be. (The particular numbers are not very important, we just need tone significantly louder than noise.)

New project. Generate 2 s of white noise, amplitude .5. View it in Waveform dB. Do Noise removal, Get Noise Profile.

Hit right arrow, generate tone, 440 Hz Sine wave amplitude .99, 2 seconds. Ctrl-f, ctrl-j, ctrl-a: Now tone follows noise in a single clip all of which is selected.

Now do noise removal with 48 dB reduction and 1 s attack/decay.

The envelope of the noise should drop from -6 to -54, and does nicely. It should rise in anticipation of the tone -- that is attack time. The rise in the envelope should be exponential, meaning a straight line in dB view, and that appears roughly so.

But the duration of this rise is about .5 seconds, not 1 second.

At the moment, after having tested in 1.3.3 as above I am only getting a reduction of noise to -24 dB whatever noise reduction level I select. And the attack/decay is not changing with setting. I will have to reboot later (I'm on Windows 8 at the moment).


Gale

[Gale Andrews]

Steve discovered a while ago that

The overlapping FFT windows each remove the DC offset over the period of each window. That just leaves the final window that does not have the offset completely removed.

Apart from the final glitch, the DC removal is arguably better than in Normalize if the whole track does not have offset.

Where did Steve say that?

Off the public forums.


Gale

[Robert J. H.]

These changes were simply mistakes introduced in version 9290 which was supposed to be for performance only.

In my opinion, Normalizer should be made a better Normalizer. It is not the purpose of this effect to normalize.

I have also written a fix for the frequency smoothing which accidentally became arithmetic when it should be geometric. Though it may be hard to make the strong case for it, showing why arithmetic averaging is wrong, but it is restoring Dominic's original intent.

It is not always clear which mean one gets, especially when dB are involved, thus mistakes happen easily enough:

Code: Select all

;; Linear magnitudes
(setf li '(1.0 0.3 0.6 0.8))
;; A-mean in dB
(print (linear-to-db (* (/ 1.0 (length li)) (apply '+ li))))
;; G-mean in dB
(print (linear-to-db (expt  (apply '* li) (/ 1.0 (length li)) )))
;; G-mean equals A-mean over dB-values
(print (* (/ 1.0 (length li)) (apply '+ (mapcar 'linear-to-db li))))

[Paul L]

"G-mean equals A-mean over dB-values." Yes, the ApplyFreqSmoothing function has always done arithmetic averaging. But whereas originally it did that to dB values, version 9290 caused it to be done to gain factors.

I think in this case it makes sense to have "A-mean over dB-values" or the equivalent computation of G-mean over gain factors.

[Paul L]

Will you test a few-lines change if I write it for you?

Um, are you having problems compiling Audacity? What platform are you on?

Windows, and I am not having problems, but surely somebody else has to test my proposed patches.

Try this, to demonstrate that attack times are only half as long as they are supposed to be. (The particular numbers are not very important, we just need tone significantly louder than noise.)

New project. Generate 2 s of white noise, amplitude .5. View it in Waveform dB. Do Noise removal, Get Noise Profile.

Hit right arrow, generate tone, 440 Hz Sine wave amplitude .99, 2 seconds. Ctrl-f, ctrl-j, ctrl-a: Now tone follows noise in a single clip all of which is selected.

Now do noise removal with 48 dB reduction and 1 s attack/decay.

The envelope of the noise should drop from -6 to -54, and does nicely. It should rise in anticipation of the tone -- that is attack time. The rise in the envelope should be exponential, meaning a straight line in dB view, and that appears roughly so.

But the duration of this rise is about .5 seconds, not 1 second.

At the moment, after having tested in 1.3.3 as above I am only getting a reduction of noise to -24 dB whatever noise reduction level I select. And the attack/decay is not changing with setting. I will have to reboot later (I'm on Windows 8 at the moment).


Gale

Version 9290 broke the attack and decay, and 10512 changed it to its present state, which still has that factor of 2 error. I don't know which version was in Audacity 1.3.3. Was it 5586? The attack and decay feature does not yet exist in that version.

[steve]

Where did Steve say that?

It came up in a discussion about voltage bias on audio signals, about 18 months / 2 years ago. Gale has an excellent memory

Try this formula instead to get a sound that is all DC:

Code: Select all

(snd-offset (s-rest 1) 0.5)

Not a nice sound, but can we agree Noise removal "should not" affect it? But it is also silenced.

I don't agree that it is "silenced", because DC is already silent.
DC is not valid audio, so it shouldn't be present in audio signals in the first place. In audio hardware it is standard practice to decouple DC.

Considering that Noise Removal is intended to be an audio effect (rather than a "scientific transformation"), what is the practical benefit for retaining DC offset?

[Paul L]

Maybe there is something below 43 Hz that is not really DC but excites that lowest band of the FFT variably?

[steve]

There's a similar issue with your other example.
From Wikipedia http://en.wikipedia.org/wiki/Nyquist%E2 ... ng_theorem

Modern statements of the theorem are sometimes careful to explicitly state that x(t) must contain no sinusoidal component at exactly frequency B, or that B must be strictly less than ½ the sample rate

Maybe there is something below 43 Hz that is not really DC but excites that lowest band of the FFT variably?

Discussion about low frequency performance is not quite the same issue as discussion about DC performance.
IF we accept (and I'm not saying that we should) that the Noise Removal effect discards DC, then low frequency response depends on the FFT size. With an extremely large FFT size very low frequencies are supported, but with a small FFT size low frequencies will be considerably attenuated. However, we probably don't want to use an "extremely" large FFT size. Although I've found that for some material, better noise reduction can be achieved by doubling the size, I expect that unwanted effects will occur if the size is too great (I've not tested). It therefore seems that there is a reasonable argument for supporting DC - not because we really want to retain DC, but simply that we don't want to roll-off low frequency audio prematurely.