Friendly Robot Overlord

I was recently given the task of cleaning up some audio tracks that were recorded on a setup where there were word clock synchronisation issues between two of the boxes in the recording chain. The glitches looked a bit like this:

And they were very frequent (about 1 a second, but sometimes more or less, sometimes two within a few samples of each other).

I wrote a program that would fix them automatically, it was written fairly quickly, and fairly experimentally (I didn't know exactly which approach would be best for fixing them, so I tried several, and hacked lots of methods to see if they could be improved). As a result, the code isn't particularly nice to follow, but it is farily short, and gives a nice starting point if you have a similar problem.

The basic approach was to look at windows of samples, and calculate some statistics about them (e.g. mean and variance) then calculate those same statistics, but with the very middle sample ignored. If the statistics for these two windows were too different, then the middle sample is declared to be a possible glitch and given some sort of score for how wrong the stats were.

Then, all the possible glitches are filtered somehow, to get rid of some of the common cases for false positives. For me, this was somewhere in the middle still, there were still some glitches that were missed, and lots of false positives in noisy sounds (like 'esses'). I did experiment with an 'ess' detection thing, but the repairing was so subtle, I turned it off in order to fix as many glitches as possible, since they were very noticable.

Repairing was done by just taking the mean of the adjacent samples. This was fine, but I'm guessing if the glitches were longer than 1 sample, then this would sound bad.

Get the GPL3 C Code for it. Should compile without anything fancier than gcc and make.