At the moment I'm editing a recording with the following problem:

Click the picture for full-size screenshot; most of the recording is fine, but at a few points this clip occurs.

As you can see it's not a regular clip: whenever the signal was too high, its polarity was apparently inversed. I doubt this is a unique problem although I haven't read much about it on the Net and the declippers I tried can't deal with it. Below I'll provide some background information on how this recording was made but I'm mostly interested in developing a fix. If there already is a fix that I don't know about, then ignore everything below and tell me.

According to me... making this fixable should be quite easy. We need only turn the "inverted" clips into regular clips (with a flat line at the max. of the waveform):


Surely it would be possible to construct an algorithm that detects the start of the clip, i.e. the sudden extremely negative slope, i.e. the drop from a very positive to a very negative value of the wave? Then in the same fashion to find the end of such a clip, by detecting the sudden postive slope?

After having thus identified the beginning and end of the clip, the area in between can be assigned a constant value corresponding to the highest values of the wave, which are found just before the 'drop' and just after the 'return'. As illustrated by the red line in the picture above.

As soon as the red line is made we have a regular clip that surely can be fixed with a regular clipfixer. So basically all that has to be programmed is a detection of the inverted clipping area. Unfortunately I'm not an experienced programmer - not even a real sound engineer. But by the maths courses and little programming I had as a chemistry student I'm convinced that fixing this wave should be possible. Of course it's not a real fix but a phoney reconstruction, but still much better than the sound I get now.

So yeah, this is what my post is actually about: is there anyone who can take this idea and turn it into a simple program / plugin? Compatibility with Audacity would be great but I can't make any demands of course. I'm just presenting this here in the hope that something good will come out of it.

By the way, if you need a sample of the recording, let me know. Is there upload functionality on these forums or should I host myself?

The promised background info.
This recording was made in the following setup:
Microphones etc. --> Samson TM500 Mixer --> MD Recorder --> Laptop
I was testing a Sennheiser wired mic instead of the AKG wireless set we usually use. Lacking a compressor I tend to use the first available link in the chain to limit the volume of each mic to a certain level, to keep the dynamic range within bounds. (The system isn't only used for recording but also for live amplificaton and I can't blow people's ears off just to get a good recording, y'know.)

For the wireless mic this link is the receiver's volume setting. The receiver would clip where appropriate and its max. output signal to the mixer was set not to clip anything further down the chain. These recordings never gave distortion like this and were straightforward to edit. I guess the AKG box handles clipping nicely.

However the Sennheiser wired mic obviously doesn't have a receiver with a volume setting, but is inserted straight into the mixer by XLR, so it clips there instead. In this situation I know I made sure that the signal sent through to the MD recorder and laptop was at an appropriate level (but of course the damage had already been done there). So I'm suspecting that the mixer just doesn't deal so well with clipping. I wish I had a compressor but that's just no option financially.

Then again I'm just a chemist doing some amateur sound engineering on the side - so my methods may well be primitive / stupid. Feel free to give advice on how to improve that.

I guess somewhere the audio overflows in stead of clipping:
MAXINT + 1 = MININT

I would guess this is from a badly designed amp. Many old opamps used to clip to the negative rail when the output tried to go too positive and vice versa. That's doesn't help fix it, though - but I would imagine some sort of adaptive filter would be the best solution.

Thank you for your replies. I'm afraid the mixer is indeed to blame. Anyway I've been thinking about translating the observations from the graph into a usable computational definition, so here's my shot. Correct me where I'm wrong and I hope that the characters Δ (delta) and ≈ (approx. equal to) show correctly on your system.

Considering that the distance Δt between two samples on the x-axis is constant (defined by the sample rate 44.1kHz), the slope Δy/Δt is proportional to Δy. The beginning of the clip (sudden negative slope) can be identified by a very negative Δy and the end of the clip by a very positive. This Δy can simply be found by y(sample) - y(previoussample).

Of course we still have to establish what exact value of Δy is required for something to be identified as a clip. This could be left a variable for the user to set himself while executing the plugin. A second requirement for an area to be identified as clipping (to prevent false positives) is that the y-value must remain in the negative until a sudden high slope is found, marking the end of the clip.

A third characteristic that I distinguish in this particular waveform is that when you revert the polarity of the clipping area back to positive, the line seems to approximate the red line that I drew earlier. Verify this by looking at the numbers in the full-sized screenshot. Computationally speaking -y(clip) ≈ y(just-before-clip). I'm not sure this should be used in a detection algorithm though. If it would be, a user-set variable determining how much the values can differ for an area to still be identified as 'clip' is recommended. But that would probably amount to a lot of unnecessary work. Also for a waveform that doesn't have its zero line at 0 this is an unusable property. An alternative definition would be y(clip) + 1 ≈ y(just-before-clip) - thanks to DualIP.

But the first two properties should be sufficient and easy to implement.

I've been making some advancements to a practical solution in Audacity Nyquist. Because it's so specific I'll redirect to the topic on their forums, but it's basically an implementation of the ideas I described here. Please take a look if you're into this material.

Actually, this is the property that caused such a strange clip to begin with.

It is not strange to see this in the digital domain, when working with fixed point values.
As said by DualIP, this looks as a digital overflow, on which the max value + 1 flips, and is then the min value.
I wouldn't expect a hardware to do this, even a digital one, but it is definitely either a design limitation (or fault).

So the detection could still be based on a highpass filter, near fs/2
and the repair method taking the values and shifting them up or down (depending if the clip is on the upper side, or the lower side) by the clipping value. This value is what may take a bit more to know. It is a value higher than the point where the "clip" appears, although i guess it could be approximated to the value at the point of the "clip".
It is not the same as mirroring, which is what you seem to suggest you tried, although that gives a relative good approximation as well.