Weird thing on Spectral edit Ver 2.3.1

I all,

Can any one shed some light on the following:

When editing in spectral view, if a selection is cut-out/attenuated, weird smearing in the low end.
To illustrate what I mean:

  1. Create some white noise.
  2. High pass filter it, say from 100Hz (not critical).
  3. Now in spectral edit mode, select a portion of the noise and use either “spectral edit multitool” or “spectral edit parametric EQ” to attenuate it.
  4. Weird smearing happens in the low end.

Audacity 2.3.1 on MacOS 10.12 (Sierra)


Forgot to mention, does the same thing with music.
Select a portion, press Z to ensure it’s at the zero crossing points and do the same thing.
Smearing still happens.

Can you post a screenshot to illustrate what you mean by “weird smearing”.

Hi Steve,

By smearing, I’m referring to the vertical tails shown in my original post, just above the red arrows with the question marks.



Could it have something todo with ringing or (ripple in the freq. domain) of the filters?
I notice it also happens if I apply a notch filter to a selection.

Which “original post”? There are no pictures in this forum topic.

Thanks, I downloaded the image from the direct link and uploaded the image into your first post so that it will show for everyone.

The “smearing” is due to a short crossfade at the start and end of the selection.
The crossfade is created automatically by the effect so as to avoid creating an audible click at the start / end of the filtered section.

OK, I see the lines in the .ny code:

        (transition (truncate (* 0.01 rate))) ; 10 ms
        (t1 (min transition (/ tn 2)))        ; fade in length (samples)
        (t2 (max (- tn transition) (/ tn 2))) ; length before fade out (samples)

As I normally take out (attenuate) very small portions, any advantage in tweaking the fade in/out values to other durations?
What would the minimum fade times be to avoid a click?
One sample as it crosses zero?
Just thinking out aloud here.

The longer the transition, the quieter the transition will be, but obviously you would usually want to keep it as short as possible.

In effect, the transition is like a low frequency, low amplitude pulse. The longer the fade, the lower the frequency. At 10 ms, the effective frequency is low enough to be inaudible. Much less than 10 ms and you may hear a subtle “thud”.

10 ms is a good compromise between avoiding an audible glitch and keeping it as short as possible.

That makes perfect sense Steve, thanks, although I’m gonna try with 3mS, 5mS and 7mS and check out the results.

Giving it more thought, there could be a lot more ny plugins that could be tailored to spectral editing, making Audacity even more versatile.
The fact that these spectral editing plugins are external and not compiled into Audacity is a very big bonus.

For example, when a biggish chunk of audio (freq. wise) is heavily attenuated, it could leave a “hole” of near silence which will sound pretty un-natural.
How about a copy and paste function (of a nearby similar selection) but not applied to the whole track, but rather the users selection?

Another idea would be noise generation.
The high and low limits of the selection will be known to Nyquist and I’m assuming level as well.
The noise would then be applied shaped and leveled to the users selection.


A fade in or out (or both) over the complete selection, could be nice to sculpt percussion when the isolated track is not available.
Then the big one…ability to select irregular shaped regions.
I’m assuming it would be pretty tough to implement programmatically.

With these in mind, would it be OK if I change the title of this thread to something like…“Questions & ideas about Spectral editing”?


I’d suggest that you do a bit more digging into the code, try writing some Nyquist code that uses the “spectral” selection, then start a new topic.

That is not possible in the current implementation.
The frequency selection is handled in the main Audacity app (C++). Nyquist just makes use of the low-hz, high-hz, center-hz and bandwidth variables, which it accesses with:
(get 'selection 'property)
where property is one of: low-hz, high-hz, center-hz, bandwidth.

As a simple example, you can run this code in the Nyquist Prompt to print the centre frequency of a spectral selection in a message window:

;type analyze
(setf center (get '*selection* 'center-hz))
(if center
    (format nil "The center frequency is: ~s Hz." center)
    (format nil "Make a spectral selection before running this code."))

No worries Steve.

Will definitely experiment and post back under a new thread.

I did expect that the actual selection was handled in the main application, no problem, can make multiple smaller square and rectangular selections to approximate the irregular shape.
Not ideal but also not a deal breaker.

Thanks for the example and your time.

Cheers for now.

I do agree that it would be nice to have more flexibility in spectral selection beyond a rectangular selection. I believe that it was intended all along to add more features, but there’s a lot of ideas on the back burner and always a great amount of immediately pressing issues.

Personally I think that the main application should handle more. Rather than just defining the frequency range, Audacity should (in my opinion) handle the frequency separation so that the “spectral” selection can be passed to any effect for processing (including built-in effects, VST effects, and any other effects that are installed). However, this is not the way that it is currently implemented.

That would be awesome and almost getting into RX8 territory.
The ability to pass only the spectral selections to VST’s, to separate tracks, etc would open up so many possibilities.

I’m currently working on a BPF for spectral editing.
The user makes a selection, Nyquist is then aware of start time, end time, BW, center freq, rms and so on.
The plugin will calculate the ideal Q and band pass filter only the selection.

Could be very handy to isolate certain sounds (as opposed to nuking them).
It’s slow going as the Nyquist/Lisp syntax is not exactly what I would call intuitive.

If it’s possible, may even implement a copy and paste selection feature to another track.
Wonder if that is not being too optimistic though.

“Band Pass Filter”?

There have been Holy Wars about LISP syntax :smiley:
The basics are very easy:

  1. Open parentheses
  2. Function name (symbol)
  3. Arguments (parameters, values, etc)
  4. Close parentheses

(my-function arg1 arg2 ...)

Of course it does get more complex than that in some cases, as you might expect for a full programming language, but it does become more intuitive with practice.

Once you have more than a few lines of code, it becomes very useful (essential) to adopt good indentation. I recently added this guide to the Audacity wiki:

“Band Pass Filter”?

Yep, band pass.
Other “big brand” spectral editors have two play buttons.
First one plays everything as per normal, but the second one only plays the selection.
In Audacity, that they may not be possible, so instead it would be a work around where one makes a selection, band pass filters it then plays it normally.
If not wanted, then simply undo.

Similar to when using de-clicker.
First select “isolate changes” to hear what it will take out, if happy then undo and run it again but this time with “apply changes”.
That kind of thing.

There is a SpectralEditParametricEQ.ny but that only amplifies or attenuates the selection.
The idea is to keep the selection unaltered whilst nuking everything else in the selected time range, if that makes sense.

Uses include getting rid of short background noises, clicks, harmonics etc and one does not always know which one to nuke.

There have been Holy Wars about LISP syntax > :smiley:

I’m not surprised. :smiley:

The basics are very easy:

Errrr, no. :smiley:
To make matters worse, Lisp uses something similar to RPN.
For example, add 2 to a variable.
(sum s-in 2)

Would be much more straight forward if it were:

(s-in sum 2) or even better, (s-in + 2).

But it is what it is, so will knuckle down and learn this Lisp thing.
It’s a steep learning curve, but when compared to VST or AU compilation, not so bad.

Yes. LISP uses “s-expressions” (

That would certainly be more familiar :slight_smile:

However, in languages like C / C++ we see inconsistencies where sometime the function symbol comes first,

FunctionSymbol(arg1, arg2);

and other times, as in arithmetic operators, the functional symbol is somewhere in the middle,

val = 5 + 2;

In Nyquist, it’s consistent:

(FunctionSymbol arg1 arg2)
(setq val (+  5 2))

The “+” symbol is valid for adding numeric values.
“SUM” (or “SIM” which is an alias for SUM) is required when adding signals / sounds.

Similarly “*” can be used for multiplying numeric values, but “MULT” is required for sounds.

I can’t believe it, actually made my first plugin in Nyquist/Lisp, all 4 lines of it. :laughing:
Thank you very much Steve for your help and patience.

It’s not perfect yet, but getting there.
I know there are other ways of achieving the same thing, but it’s a pain to get out of spectral mode, find the spot, apply a filter, then back into spectral mode.
This way, can just do a quick BPF and compare.
Just wish there was a steeper bandpass in Nyquist, can I cascade bandpass2?

Congratulations :slight_smile:

However, I don’t think that your calculation of Q is correct.
I think it should be:

Q = sqrt(2 ^ bw) / ((2 ^ bw) - 1)
where “bw” is the bandwidth in octaves.

In Nyquist:

(setf q (/ (sqrt (power 2.0 bw))(- (power 2.0 bw) 1)))

However, I don’t think that your calculation of Q is correct.
I think it should be:

Q = sqrt(2 ^ bw) / ((2 ^ bw) - 1)
where “bw” is the bandwidth in octaves.

Perfect, thanks Steve.
Modified the code accordingly and added it as a plugin, works like a charm.

Steve, sorry 3 more questions if I may:

Many moons ago, you wrote a Nyquist ultra narrow BPF.
I want to modified it to work in spectral mode.
Modifying lines 1 - 5 is easy.
Making “freq” set to “'selection 'center-hz” and “repeat” set to 10 is also straight forward.
(Don’t need sliders).

The questions I have are:

  • what do I do with all the “s-in” 's, do I change them to track ?
  • and what about the single “s” in line 20, that becomes track as well?
  • lastly, what does the “peak” on line 18 do?



All good Steve.
Tried the modifications I wrote about and it works really well, too well in fact, had to reduce the iterations to 3.

Slowly getting the hang of this Nyquist/Lisp thing.