# Noise Reduction - How's my logic?

Win10/Audacity 3.1.3

Right now this is, for me, an academic question, but it might apply to any two-step Effect on audio tracks.

I am applying Noise Reduction to a 50-minute audio recording; I select a chunk of “noise only” and prime the Effect, Noise Reduction; then I Select All and apply Noise Reduction. This is the regular two-step application of the effect “Noise Reduction”.

Question 1: Since I have primed Noise Reduction from the file, it follows that at least that part of the track must change. Therefore the track that results from Noise Reduction on a track must, by definition, always produce a change in that track, a change that would be picked up by any binary-compare program. Am I correct?

Question 2: The time to process will always be a function of:-
(a) The number of matches of the Noise Profile within the track and hence -
(b) The length of the track, and possibly -
(c) The length of the selection offered up as a Noise Profile
This third parameter is the one of most interest to me. I reason that the shorter the Noise Profile, the greater the chance of a match being made, which would impact (a). Are (a), (b) and (c) correct?

Question 3: (and this is a scarier question IMHO) If the Noise Profile remains in place for successive processing on a series of files, then the binary-compare program could deliver a datum for each file showing what percentage (I am not specifying the units - number of areas of changes, count of bits of change etc) of each track was changed due to the Noise Profile of the first track, and hence one could calculate the probability of improvement in repeated applications of the Noise Profile on a series of tracks recorded in the same venue on the same day over a single period. Is this correct?

Thanks, Chris

Audacity noise-reduction is not intelligent: it’s not looking for matches,
it just attenuates the frequencies which were prominent in the noise profile.
It’s as if it was applying an equalization, (where the sound is above threshold).
That means it always causes some collateral-damage: it does not just act on the noise.

IMO only apply noise-reduction once: each application creates (bubbly) digital artefacts.
Repeated applications will generate artefacts of artefacts, etc.

Assuming that your noise reduction settings are not so low as to stop the effect from working, then yes that’s correct.
(If either “Noise Reduction (dB)” or “Sensitivity” are set to zero, then noise reduction won’t work properly).

(a) No. Processing time is not related to the number of matches of the noise profile. All samples in the selected audio are processed, regardless of whether they match the profile or not. If the match the profile, then they are returned at lower amplitude, if they don’t match then they are returned at (or very close to) their original amplitude.

(b) Yes, longer tracks take longer to process.

(c) No, the length of the profile that is stored in the effect is always the same size, regardless of the length of the selection that was used to create the profile.

Not really relevant as two of the propositions in Question 2 are incorrect.

However, it’s worth noting that applying Noise Reduction twice with 3 dB reduction, is roughly equivalent to applying the effect once with 6 dB reduction, assuming that all other factors (the noise profile and all other settings) are the same, though there will be a very small additional loss when applying twice rather than once. (I think the additional losses are mostly due to rounding errors during the number crunching).

Question 1: Since I have primed Noise Reduction from the file, it follows that at least that part of the track must change. Therefore the track that results from Noise Reduction on a track must, by definition, always produce a change in that track, a change that would be picked up by any binary-compare program. Am I correct?

Steve knows more about what’s going-on “under the hood” than I do but I assume EVERY sample is altered. Probably-mostly just the low byte, so half of the bytes in a 16-bit file would be changed.

On the other hand, a noise gate only touches the audio where it’s below the threshold. But you can often hear a noise gate opening and closing and it can be annoying-distracting hearing the background noise come-and-go.

Thanks for the response, Trebor. If I understand the process, it is a process akin to “Removing all 100cps sound” from one end of the track to the other. or “Removing every yellow blossom in the yard with a pair of (small) scissors” - the yellow daffodils in the driveway beds would disappear along with the dandelions in the lawn.
Is that close?

IMO only apply noise-reduction once:

I agree. By “repeated” I meant "repeated over a zseries of individual tracks using the initial Noise Reduction settings, rather than repeated on a single track. e.g. “Let’s apply NR to all the Bach organ recordings”

(Perhaps I should use “Recording” or File" for something I play back in WinAmp. and "Track"for one of several Audacity components which, together, are exported by Audacity to a “recording”)
Thanks again, Chris

But then to continue with my daffodil/dandelion analogy, ALL of the recording is susceptible to change. Both the matches in what I think of as “should be silent here” and matches within instrumental activity. If I remove all 100cps within the recording, then the 100cps in my supposed-silences changes, but so too does the 100cps in the vocalist’s pieces. yes?

Beacuse my scissor-snipping method requires that I examine every leaf, stalk, slug, snail, seed-pod and blossom, just to see if the object IS a yellow blossom.

(c) No, the length of the profile that is stored in the effect is always the same size,

( am GREATLY simplifying my amateur view here) So this is as if my submitted NP, regardless of length of my selection, is stored as two values - lowest frequency and highest frequency (or lowest/highest anything else) which results in just two internal values, which means, always a fixed-length datum for NP. correct?

OK. Based on my current understanding then, applying the original NP to a series of recordings/files will still effect changes in each of the recordings/files, but the data returned (length or count or interval … of changes) is not useful to me, because it is data about changes across each entire file. It is NOT data related to those sections which I think should be “my silences”, so it does NOT serve as data-about-silences as much as data about the world of audio in general.

However, it’s worth noting that applying Noise Reduction twice with 3 dB reduction, is roughly equivalent to applying the effect once with 6 dB reduction, assuming that all other factors (the noise profile and all other settings) are the same, though there will be a very small additional loss when applying twice rather than once. (I think the additional losses are mostly due to rounding errors during the number crunching).

And thank you too for this, but I think your scenario here was in terms of applying an initial NP twice to the same track, or file, correct?

My original idea, weeks ago now, was to have some simple, time-consuming process run overnight(grin) that produced a report on a collection of MP3 files with a recommendation to which of the 1,000s of files might profit from Noise Reduction. Think of a DOS Batch file that could serve up successive MP3 files to an instance of Audacity, and an Audacity macro that could insert a section of “my supposed silence” to establish a NP, apply Noise Reduction to the file, export the changed file as a copy, and then apply (from DOS) a binary-compare. Heath-Robinson, I know, and would probably drive me into NyQuist (grin), but I was dreaming of making a report on a set of files that would supply a subset of candidates for post-processing.

A suitable response would be “Chris, you have too much time on your hands!”

Steve, thanks for the detailed input on what is, after all, a pipe-dream.
Chris

Thank you Doug. I now understand that changing part of every audio datum effectively changes every byte in the file. Especially if it is a change in loudness/amplitude across every track in the entire file.
I had been thinking of the NP as a chunk of sound, x-milliseconds long, which was matched as a string of bytes against every byte in the file. That, I now see, is not how Noise Reduction works. (The wheels in my brain, like The Wheels of Justice, grind exceedingly slow, but they get me there eventually)
Cheers, Chris

The taller the yellow plant the more it will be cut back, (short yellow plants may escape pruning entirely).

[ BTW if you only want to remove a single 100cps/Hz tone,
a notch-filter will do a more thorough job than Noise Reduction.
Audacity’s Spectral-editing also has a visual notch-filter … https://manual.audacityteam.org/man/spectral_selection.html#example ]

OK! I am now officially out-of-my-depth
Trebor, I understand your point, although I was only at the stage of changing my thinking from “matches this string” to “matches this characteristic” - be it frequency or amplitude or whatever.

Thanks to all of you who responded.

I grew up in a world of character string-processing. So when I “select a piece of an audio wave” I think that since the track is stored in an MP3 file as a string of bytes, then I have selected a “string of bytes”.
My one-track (ugh!) mind then continues to think of the Noise Profile as a “string of bytes”; that has been my forté of Lo! these many years, and it’s how I am conditioned to think. Hence I think of matching small strings of bytes along a larger string of bytes. I suspect that too this is why us users sometimes think of “removing the noise of cars outside my window”

Now I can think a teensy little but like a sound engineer, and I see that MY selected string of bytes can be summarized as a LOW and HIGH value for some characteristic (frequency, amplitude, …).

And for me, that is an important take-away.

Thanks again,
Chris