I have read more, and now I also blame 9298 for changing the geometric averaging of gain factors in frequency smoothing (which I think makes more sense) to arithmetic.
It seems a lot of intermediate results stored as dB were changed by somebody to ratios, BUT not all the changes necessary for consistency happened. This changed the frequency smoothing and the attack/decay in bad ways, and the fixes to that seem not yet complete.
NoiseRemoval.cpp
Forum rules
If you require help using Audacity, please post on the forum board relevant to your operating system:
Windows
Mac OS X
GNU/Linux and Unix-like
If you require help using Audacity, please post on the forum board relevant to your operating system:
Windows
Mac OS X
GNU/Linux and Unix-like
Re: NoiseRemoval.cpp
Tortoise showed fewer revisions in the Revision Graph than in the "Show Log" dialog, before I discovered the "Show all revisions" button, so I may not have identified the exact revisions that introduced bugs. Still there is a story here of some things getting messed up and only partly restored. It was 9290 that introduced much of the badness.
Comments for rev 9290:
"Change NoiseRemoval processing to use new RealFFTf function for improved performance
also change variable definitions from exp(log(a)+log(b)) to a*b for improved performance"
The change did remove some calls to log10 and pow, but made what must have been unintended changes to the results!
Comments for rev 9290:
"Change NoiseRemoval processing to use new RealFFTf function for improved performance
also change variable definitions from exp(log(a)+log(b)) to a*b for improved performance"
The change did remove some calls to log10 and pow, but made what must have been unintended changes to the results!
Re: NoiseRemoval.cpp
I just tried this simple experiment:
Take some speech including pauses. Duplicate. Apply Noise Removal. Invert the original. Mix and render the two tracks.
The result is a whispery thing indicating the difference of tracks. Perhaps not what "Isolate" was meant to do, which is pass the noise through with a gain of 1, instead of the difference of original and reduced noise. But still a better indication of how much the effect is changing my sound inside words.
The resulting wave often looks "furry" and zooming in shows it zigzagging with each sample -- in other words, some Nyquist frequency stuff superimposed on the other differences -- the result of that mistaken zeroing out of that frequency before the inverse FFT.
Still, the aural impression of this difference is MUCH quieter than what the confused Isolate button feature is doing. Try isolate with a long attack and a low noise reduction factor -- you hear way too much non-noise passed through, and it often "swells" in loudness before pauses, then drops down again, all of which I know how to explain from what the code is doing.
Take some speech including pauses. Duplicate. Apply Noise Removal. Invert the original. Mix and render the two tracks.
The result is a whispery thing indicating the difference of tracks. Perhaps not what "Isolate" was meant to do, which is pass the noise through with a gain of 1, instead of the difference of original and reduced noise. But still a better indication of how much the effect is changing my sound inside words.
The resulting wave often looks "furry" and zooming in shows it zigzagging with each sample -- in other words, some Nyquist frequency stuff superimposed on the other differences -- the result of that mistaken zeroing out of that frequency before the inverse FFT.
Still, the aural impression of this difference is MUCH quieter than what the confused Isolate button feature is doing. Try isolate with a long attack and a low noise reduction factor -- you hear way too much non-noise passed through, and it often "swells" in loudness before pauses, then drops down again, all of which I know how to explain from what the code is doing.
-
Gale Andrews
- Quality Assurance
- Posts: 41761
- Joined: Fri Jul 27, 2007 12:02 am
- Operating System: Windows 10
Re: NoiseRemoval.cpp
So I assume you now mean r9290, right? https://code.google.com/p/audacity/source/detail?r=9290 .Paul L wrote:... and it looks like revision 9298 not long before that made some major changes, INTRODUCING a bug in attack/decay, and also introducing the bug in handling the DC bin!
Can you give steps to reproduce the bug in attack/decay and handling DC?
Gale
________________________________________FOR INSTANT HELP: (Click on Link below)
* * * * * Tips * * * * * Tutorials * * * * * Quick Start Guide * * * * * Audacity Manual
* * * * * Tips * * * * * Tutorials * * * * * Quick Start Guide * * * * * Audacity Manual
Re: NoiseRemoval.cpp
Neither effect would be obvious I think. They are differences in calculated results more than roundoff, introduced by what was supposed to be a performance improvement only according to the comments in svn.
Re: NoiseRemoval.cpp
Gale, I tried this extreme example:
Make a track, generate 1 s of sine wave at 11025 Hz (that's 44100/4), amplitude .99. Make that your noise profile.
Make a new track, generate some silence, select it all, go to Nyquist prompt, type:
The result is a big triangular wave with exactly two samples period.
Do we agree that noise removal should do nothing to that wave, because the spectrum is completely unlike that of the noise?
But try it, you get silence.
Try this formula instead to get a sound that is all DC:
Not a nice sound, but can we agree Noise removal "should not" affect it? But it is also silenced.
I must think more about how to demonstrate that attack and release are not right, and that frequency smoothing is no longer as Dominic Mazzoni intended.
Make a track, generate 1 s of sine wave at 11025 Hz (that's 44100/4), amplitude .99. Make that your noise profile.
Make a new track, generate some silence, select it all, go to Nyquist prompt, type:
Code: Select all
(hzosc 22050.0 *table* 90)
Do we agree that noise removal should do nothing to that wave, because the spectrum is completely unlike that of the noise?
But try it, you get silence.
Try this formula instead to get a sound that is all DC:
Code: Select all
(snd-offset (s-rest 1) 0.5)
I must think more about how to demonstrate that attack and release are not right, and that frequency smoothing is no longer as Dominic Mazzoni intended.
Re: NoiseRemoval.cpp
Will you test a few-lines change if I write it for you?
I have identified a few different problems, all in one source file, but I might not persuade you to take all of my changes.
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.
I have identified a few different problems, all in one source file, but I might not persuade you to take all of my changes.
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.
Re: NoiseRemoval.cpp
I have posted at Nabble too. http://audacity.238276.n2.nabble.com/bu ... 62446.html
-
Gale Andrews
- Quality Assurance
- Posts: 41761
- Joined: Fri Jul 27, 2007 12:02 am
- Operating System: Windows 10
Re: NoiseRemoval.cpp
For comparison, Noise Removal in 1.3.3 reduced the bulk of the waveform to -20.6 dB and 1.2.6 kept most of the waveform at the same level but with the amplitude sharply reduced for about 1/10th of a second in numerous places.Paul L wrote:The result is a big triangular wave with exactly two samples period.
Do we agree that noise removal should do nothing to that wave, because the spectrum is completely unlike that of the noise?
So what is the reason in the code for the current behaviour? What makes Audacity see the audio not in its profile as something to be removed? Are there any cases in real world audio where that behaviour would be beneficial?
Steve discovered a while ago thatPaul L wrote:Try this formula instead to get a sound that is all DC:
Not a nice sound, but can we agree Noise removal "should not" affect it? But it is also silenced.Code: Select all
(snd-offset (s-rest 1) 0.5)
Apart from the final glitch, the DC removal is arguably better than in Normalize if the whole track does not have offset.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.
Are there disbenefits from removing offset as well as noise?
Gale
________________________________________FOR INSTANT HELP: (Click on Link below)
* * * * * Tips * * * * * Tutorials * * * * * Quick Start Guide * * * * * Audacity Manual
* * * * * Tips * * * * * Tutorials * * * * * Quick Start Guide * * * * * Audacity Manual
Re: NoiseRemoval.cpp
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.
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.