The Nyquist notch suite “MultiNotch” was designed to pull out the USB data management audio interference that can affect affordable USB microphones and some other simple USB devices. This particular filter suite affects 1000Hz, 2000Hz, 3000Hz, and 4000Hz, the most audible and objectionable of the USB tones.
It’s simple (too simple—no housekeeping) and remarkably effective.
– Why does the Quality or “Q” of the filters go up with frequency?
–Why would I need anything else, given I may need higher frequencies if the noise is severe? There is posted a much more complex Nyquist method of USB filtering with do loops, setq iter, etc. It’s elegant and well laid out, but doesn’t work.
I assume the authorship is in alphabetic order since I didn’t have anything to do with the code past gaze at it.
“version” was in my list of questions. I know what it means now, I didn’t know what the appropriate number was.
Where do you put revision or date?
Is there an acoustic or filter behavior reason the Q goes up with frequency and how is that chosen? I always thought Q was a relationship of the frequencies affected and changed naturally.
You can add any information you like as “comments”, provided that you begin each comment line with a semicolon.
Most computer languages support “comments” (some languages call them “remarks”), as a way to annotate the code for the benefit of humans. This is most commonly achieved by adding a special character, or series of characters, to the start of the line before the comment.
General idea: When running the code, the computer disregards comments.
More precisely: The compiler / assembler / interpreter (depending on the computer language) disregards comments.
The Nyquist language uses a semicolon as its special “this is comment” character.
Example:
; This line is ignored
;so is this
;;;;; and this
; and this
(hzosc 440) ; the first part of this line is run by Nyquist, but everything after the semicolon is ignored
; The code at the end of this line will be ignored because this line is "commented out" (hzosc 1000)
“Special” comments.
Audacity/Nyquist plug-in code has a number of “special” comments. As with all other Nyquist comments, they are ignored entirely by the Nyquist interpreter, but are read and used by Audacity. These are the “header” comments.
Header comments should be placed at the top of the script, and need to comply exactly with the specified form (syntax) described in the documentation. If the syntax is incorrect (but the line does begin with a semicolon), then it is treated as a regular “comment” - it is disregarded.
Many years ago there was an info “header”.
The syntax was:
;info "one line of quoted text"
This header is now obsolete and treated by Audacity and Nyquist as an ordinary comment. That is, the line is disregarded.
In some obsolete versions of Audacity, the “info text” was displayed near the top of the plug-in GUI.
The centre frequency of the notches match the frequencies that we wish to remove
The narrowness (Q factor) is about two things: (a) factoring in a ‘fuzz factor’, (b) damage limitation.
A true notch filter is virtually “infinitely deep” at its centre frequency. That is, at that frequency the attenuation is total. However, in real life we are unlikely to know the “exact” frequency. If the notch is extremely narrow, then a small error in determining the required frequency, or a small frequency change in the sound that we want to remove, will have a big impact on the effectiveness of the filter. A wide notch spreads the net wider and provides a good amount of attenuation for a broader range of frequencies.
If the notch is wider than required, we will be attenuating parts of the “good” sound in addition to the “bad” sound. On the other hand, the narrower the notch, the more the filter will “ring”. Ringing is not a problem for constant unchanging sounds, but can be a problem when the energy within the notch frequency band changes. The narrower the notch, the more it will ring, so the bigger the problem if the amplitude within the filter band changes. So in practice, setting the Q is a compromise: as narrow as possible but not too narrow.
As Trebor wrote, Q is related to bandwidth, where “bandwidth” is defined as a ratio (for example, as “octaves”). One octave either side of 50 Hz are 25 Hz and 100 Hz - a spread of only 75 Hz. One octave either side of 4000 Hz are 2000 Hz and 8000 Hz, a spread of 6000 Hz. If we want to specify a notch as, for example, “frequency +/- 100 Hz”, then at low frequencies the notch can be very “broad” (as a ratio), but for high frequencies it would need to be extremely narrow.
Not worth it. My goal was to collect instances of Yeti Curse solution. I was impressed with the massively different solutions for what appeared to be the same problem.
You’re right, you should really check that the Nyquist frequency isn’t exceeded.
Also, there’s no need to use an additional variable for the track audio, you can use track directly.
Here’s an example of how you might do that: Mosquito-Killer3.ny (361 Bytes)
Also, do we know that the Yeti Curse is always on a base frequency of 1000 Hz?
Also, do we know that the Yeti Curse is always on a base frequency of 1000 Hz?
I think there was one instance that didn’t start with 1000. But then, we weren’t entirely sure the damage was caused by USB leakage, either.
There is a known mechanism for the standard problem. Apparently, 1000Hz USB management goes pounding down the lines as an unbalanced (sloppy) data stream. It’s not a precious service compared to the actual data. USB Battery is also unbalanced. The common shield and the close proximity of the two wires just cries out for radiation leakage.
Any poor power management goes straight into the sound as frying mosquitoes. I think flynwill did the legwork on that when a microscopically small version of the noise showed up on a UCA-202. His UCA-202 runs from a small lab power supply plugged into the wall instead of the USB battery. His mosquitoes went undetectable when he did that.
I don’t know if anyone has done inspection with USB3.
Mosquito-Killer3.ny
I’m pleased REV is making it into the filename.
How high up do the notches go? I’ve never seen damage go past 8000Hz, and there was only one posting with that.
Given all this trash is harmonics and overtones of 1000 and given the “legacy” code pulls out 3000 and 4000 (infant screaming on a jet) how much do you realistically need?
Yes, I got that and yes it does that. I’m in the blizzard of what could go wrong.
Really 16 notches? We are curing an acoustic phenomena, right? 16000 is higher than FM radio. Can you hear 16000? 16th harmonic of nearly inaudible 1000 leakage comes out to…not significant?
My effect woke up at 5 notches. I think that’s a rational number. How do I get back to default if I forget? Right this second, mine thinks I want 16 forever. The middle of the slider is 9.
How do we tell a user the method of choosing their own number? Both Analyze > Plot Spectrum and Spectrogram Display are obscure/magic diagnostic tools. To make the problem recursively worse, how sophisticated is the average owner of an affordable USB microphone?
How would you even know you have the Yeti Curse to apply the tool?
Taking this upside down, what’s wrong with 16 notches forever? Why set it at all? Notch Damage gets progressively less audible as you go up, and remember chances are good we’re solving someone’s ACX rejection. Anything we do is better than what they got. Here, apply this filter-with-no-adjustments to make that whine go away. Boop. Gone. Submit for publication, make a mint and retire to St Tropez.
Is this something to hold in the forum quiver against people showing up with USB Whine? That would work. It would still be good to get back to graceful, default number of notches.
