removing incessant, metronomic clicking

Attached is a wav and 3 screen shots showing my problem. Periodically when recording 2 inputs on my Scarlett 2i2, a recording will suddenly become infected with this beating and I have no idea what prompts it. The clicks are almost exactly 0.094 seconds apart and increase in volume with the sound of my voice.

  1. Any insights on why this happens would be appreciated (so I can prevent it from happening again).
  2. Which audacity plugin(s) can I effectively use to repair the recording (it’s an hour in total)?
    Screen Shot 2018-08-13 at 7.19.52 PM.png
    Screen Shot 2018-08-13 at 7.18.54 PM.png
    Screen Shot 2018-08-13 at 7.18.26 PM.png

Which computer?

I don’t remember the particulars, but the digital bitstream is periodically failing to follow your voice. That’s why it seems to get worse with volume.

Because it’s a sharp absence of sound rather than a spike or “up-tick,” the regular click removers aren’t going to help. I thought there was a separate “Tick Removal” that knew about this problem. Looking.


This is a message thread that discusses various methods of removing clicks from vinyl.

There is a process that can do a wonderful job repairing the distortion…one click at a time. Can’t take you more than six months.

I think one of the other elves is more up to speed on this than I am.


Mac OSX (2015). Not sure what “failing to follow your voice means.” As in it literally can’t keep up with the bits coming in fast enough? and just throws out some bits? My system resources aren’t particularly taxed when I’m recording, which is what that link suggests might be the problem.

In that case I might as well write some python that goes sample by sample with some algorithm or perhaps a filter and detects the clicks and removes the offensive samples (usually just a few for every click)

That sounds like the infamous “clicky recordings on Mac” problem. See if this helps:

If you do, I hope you make it open source and let us know about it.

Fixing clicks automatically is surprisingly difficult. There are two distinct parts to the problem: 1) Detection 2) Repair.

Originally, Audacity’s “Repair” effect was intended to do both, so that you could simply select a track, and the Repair effect would search the clicks and fix them. Unfortunately, the developer never solved the first part (detection) well enough, but nailed the second (repair) part. So now we have an effect that just does the repair part, which usually works extremely well, one click at a time.

One of the biggest problems for the detection part, is avoiding false positives - we don’t want to be fixing transients that are supposed to be there.

Audacity’s “Repair” effect uses cubic interpolation, taking a few samples either side of the selection, and interpolating into / replacing the selection.

  1. Any insights on why this happens would be appreciated (so I can prevent it from happening again).

I’m a Windows guy, but don’t run any other applications and try to minimize the number of “background” operations.

If you are recording at 96kHz or 192kHz, try 48 or 44.1kHz.

Try increasing the [u]Latency/Buffer Length[/u].

My system resources aren’t particularly taxed when I’m recording,

It’s not just the total CPU/system utilization… Your system is always multitasking, even if you’re only running one application. The audio data streams into a buffer (like a holding tank) at a smooth-constant rate. Whenever the operating system gets-around to it, it reads the buffer and writes the data to your hard drive in a quick burst. If some application/process/driver “hogs” the system for a few milliseconds too long, you get buffer overflow and a glitch.

When you play-back (or monitor), data is written to the playback buffer in a quick-burst and it flows-out at a smooth-constant rate. For playback the danger is buffer underflow.

…A faster computer helps, but only because it finishes the background operations faster.

Hmm, maybe I’ll take a look at the source this weekend. I can’t imagine it would be that hard. Viewing the, spectrogram it’s pretty obvious where each spike occurs, granted fft is really an average / operates on a fairly large buffer when the actual size of the error is just a few samples long, but at least the fft would give it a very close range to operate in. I’ll see what I can do.

I’ve been playing around with this it’s not too difficult to do the detection. With a bit of python, you can just apply a very strong high-pass filter and then just identify the remaining large bumps in the signal that are left. This is possible because the clicks have strong frequencies across the entire freq range.

The problem I have now is the repair. Audacity’s repair is quite excellent but I can’t integrate that c++ (namely Repair.cpp and InterpolateAudio.cpp) into python. Converting it or writing a module is just going to be too time consuming.

I was hoping python would have some lib that did autoregression by least squares for a 1d vector but I couldn’t find much by googling atm.

Any suggestions?

Ok, I got my phd friend to help me use this very academic python library (statsmodels) and it seems to work to great effect:

Here is another pic showing the before and after of each ruined section (the thin line is the original ruined signal, the repaired is the thick line).

I’ll make another post with a release of this (in one form or another) soon. I’ll at minimum post the source code… maybe even make an aws lambda and a basic webpage that can fix a whole file for you.

source code is here: