Over sampling and hard/soft clipping

DSP, Plugin and Host development discussion.
RELATED
PRODUCTS

Post

I’ve read that on devices such as digital compressors, if the maximum output level is, say, -0.5 dB, then with over sampling enabled, very loud peaks may still exceed 0dB.

Intuitively, I’d think the opposite, as oversampling would not only reduce the number of clipped peaks due to sharper sampling resolution, but also because there would be less aliasing-related distortion… yet the opposite is true. Can anyone help me understand why, please?

Post

I guess, they may be talking about intersample peaks which are conceptually peaks in the underlying continuous time signal that happen to occur in between the sample instants such that they are not visible in the sampled signal. By interpolating the sampled signal "correctly", namely using (approximated) sinc-interpolation, they may become visible. D/A conversion and oversampling can be considered as such an interpolation process. These overshoots are related to the Gibbs phenomenon which is probably the most intuitive way to understand what's going on there:

https://en.wikipedia.org/wiki/Gibbs_phenomenon
Last edited by Music Engineer on Sat Nov 26, 2022 1:51 am, edited 1 time in total.
My website: rs-met.com, My presences on: YouTube, GitHub, Facebook

Post

...well - "intuitive", if you are familiar with the relevant math (Fourier analysis), that is. The gist of it is: if you compose a discontinuous periodic waveform (such as sawtooth- or squarewave) from sines according to that waveform's Fourier spectrum but then truncate the Fourier series at some finite value (i.e. you use only finitely many sines), then you'll get overshoot and ripples at the signal's discontinuities. That hard truncation of the Fourier series can also be understood in terms of applying a brickwall filter - and that brickwall filtering is also what the sinc interpolator does ....in very informal terms

I call it intuitive because when you look at a plot of a truncated Fourier series, i.e. a finite sum of sines, you can literally *see* the overshoot and have perhaps some sense of why such an overshoot should be expected from a finite sum of sines - after all, sines tend wiggle a lot :hihi:
My website: rs-met.com, My presences on: YouTube, GitHub, Facebook

Post

Music Engineer wrote: Sat Nov 26, 2022 1:42 am I guess, they may be talking about intersample peaks which are conceptually peaks in the underlying continuous time signal that happen to occur in between the sample instants such that they are not visible in the sampled signal. By interpolating the sampled signal "correctly", namely using (approximated) sinc-interpolation, they may become visible. D/A conversion and oversampling can be considered as such an interpolation process. These overshoots are related to the Gibbs phenomenon which is probably the most intuitive way to understand what's going on there:

https://en.wikipedia.org/wiki/Gibbs_phenomenon
Hello and thank you! I am familiar with the mathematics, however a qualitative description is sufficient for my current purposes.

What you write makes sense, if I’m understanding correctly. Obviously (very) loosely speaking: a sampled waveform may have Inter-sample peaks which are “invisible” in DSP such as a compressor. As such, post-effect, after the compressor has acted on the sampled waveform, when the signal is oversampled and converted to analog, these Inter-sample peaks may reappear (and exceed the previously anticipated threshold level).

I was under the impression that the compressor acted on an oversampled input signal- but it sounds like oversampling refers to the D/A (or, where applicable, A/D) process specifically?

Post

losangeles wrote: Sat Nov 26, 2022 2:03 am I was under the impression that the compressor acted on an oversampled input signal- but it sounds like oversampling refers to the D/A (or, where applicable, A/D) process specifically?
OK, there are way more knowledgeable people here than me, but I'll take a crack at this anyway. A virtual compressor (or other plug-in type) that implements oversampling has a signal coming in at the project sampling rate, and it outputs its treated signal at that rate. If oversampling is turned on, the plug-in up-samples the incoming signal internally to a higher rate (usually a factor of a power of 2), does its business, and down-samples to the project rate. The purpose might have something to do with intersample peaks (although I've never seen that goal mentioned), but it's mostly about avoiding aliasing, which can be introduced by any non-linear process (compression, soft-clipping, etc.). The higher sample rate makes it possible to more effectively avoid the aliasing.

So, your initial impression was correct, as long as you realize it's the compressor (or clipper or whatever) that is doing the up/down-sampling internally. Make sense?

Post

dmbaer wrote: Sat Nov 26, 2022 9:29 pm The purpose might have something to do with intersample peaks (although I've never seen that goal mentioned) ...
Actually, I will amend that a little. Some limiters include intersample overage prevention in their charter - so I have seen that goal mentioned, but only for limiter plug-ins.

Post

losangeles wrote: Sat Nov 26, 2022 2:03 am What you write makes sense, if I’m understanding correctly. Obviously (very) loosely speaking: a sampled waveform may have Inter-sample peaks which are “invisible” in DSP such as a compressor. As such, post-effect, after the compressor has acted on the sampled waveform, when the signal is oversampled and converted to analog, these Inter-sample peaks may reappear (and exceed the previously anticipated threshold level).
Exactly.
I was under the impression that the compressor acted on an oversampled input signal- but it sounds like oversampling refers to the D/A (or, where applicable, A/D) process specifically?
Depends on the compressor. Some plugins oversample (ie. upsample, process at the higher rate, then downsample again), while some plugins don't. Oversampling is also sometimes used as an implementation detail in D/A conversion, but that's not really relevant to us.

What's relevant is that the digital samples really represent the unique continuous-time band-limited(*) signal that matches the sampled values at the sampling points and this signal can oscillate between those sampling points thanks to Gibbs. This means that if we only look at the sampled values, we might underestimate the true amplitude. If we interpolate to a higher sampling rate, then we get some "in between" points and we will likely underestimate significantly less.

(*) It's the limited bandwidth that makes the signal unique, but it's also what causes Gibbs phenomenon. Mathematically we can represent any sinusoidal frequency below half the sampling rate (and nothing beyond that point), but if we look at the sampled points only, then the higher the frequency, the less those points look like a sine.. yet when reconstructed in continuous time they will become true sines that can oscillate higher than the sampled points would suggest.

Post

I've always been a bit puzzled by inter-sample peaks - surely their presence and/or location depends on how the digital signal is ultimately converted to analog? If it's going to be done by sending, say, a 44.1KHz sample stream through a DAC and an analog filter, then wouldn't you need to use a particular IIR to simulate the analog filter in order to prevent it producing unwanted peak values? Whereas if the digital stream is up-sampled using a FIR prior to the DAC then you'd want to use a corresponding FIR (maybe followed by an IIR) to predict and avoid peaks in that case.

Basically, I don't see how a digital signal can be attenuated so as to avoid inter-sample peaks without knowing details of the subsequent signal processing. Can anyone shed some light on this?

Post

kryptonaut wrote: Mon Nov 28, 2022 10:04 am I've always been a bit puzzled by inter-sample peaks - surely their presence and/or location depends on how the digital signal is ultimately converted to analog? If it's going to be done by sending, say, a 44.1KHz sample stream through a DAC and an analog filter, then wouldn't you need to use a particular IIR to simulate the analog filter in order to prevent it producing unwanted peak values? Whereas if the digital stream is up-sampled using a FIR prior to the DAC then you'd want to use a corresponding FIR (maybe followed by an IIR) to predict and avoid peaks in that case.

Basically, I don't see how a digital signal can be attenuated so as to avoid inter-sample peaks without knowing details of the subsequent signal processing. Can anyone shed some light on this?
You got it correct. The best you can do is try to reduce the (estimated) theoretical peaks in hopes that it'll reduce the actual peaks. Any actual DAC will need some headroom, so mostly you can just hope to reduce the headroom requirements.

Post

Thanks for your reply.

After posting I wondered whether the principal reason for trying to avoid ISPs is (a) to prevent the post-filtering analog signal exceeding (nominally) +/-1 and then clipping in the analog domain, or (b) to avoid a situation where a subsequently-upsampled digital signal has values greater than the DAC's full digital range and so can't be accurately converted. I guess (b) is more likely to be an issue in practice?

Do most output stages upsample/resample prior to DAC?

Post

kryptonaut wrote: Mon Nov 28, 2022 11:00 am After posting I wondered whether the principal reason for trying to avoid ISPs is (a) to prevent the post-filtering analog signal exceeding (nominally) +/-1 and then clipping in the analog domain, or (b) to avoid a situation where a subsequently-upsampled digital signal has values greater than the DAC's full digital range and so can't be accurately converted. I guess (b) is more likely to be an issue in practice?
Neither really. The principal reason is to give you a warm and fuzzy reason and help sell more plugins.

Post

mystran wrote: Mon Nov 28, 2022 11:50 am
kryptonaut wrote: Mon Nov 28, 2022 11:00 am After posting I wondered whether the principal reason for trying to avoid ISPs is (a) to prevent the post-filtering analog signal exceeding (nominally) +/-1 and then clipping in the analog domain, or (b) to avoid a situation where a subsequently-upsampled digital signal has values greater than the DAC's full digital range and so can't be accurately converted. I guess (b) is more likely to be an issue in practice?
Neither really. The principal reason is to give you a warm and fuzzy reason and help sell more plugins.
no one does such a thing for dacs. Realistically it's done for mp3 conversion or the like, especially when you're distributing a song for people to listen to. In streaming platforms the signal is limited on some loudness values, but this is NOT always the case (I happened to listen on youtube to tracks with RMS around -3dB with intersample peaks everywhere and completely broken). Without expedients even 2db headroom is often not enough, which is why people resort to true peak limiting (which is not the ultimate solution, but comes very close)

Post

Yeah - I always wondered, why intersample peaks should be an issue for DACs at all. I mean, from a theoretical perspective, all it takes to avoid clipping on the DAC side would be to have some headroom of around 9% (more precisely, the Wilbraham-Gibbs constant, times 100%) - so how expensive could it possibly be to give a DAC that little bit of headroom? Even if the actual filter rings more strongly than the ideal theoretical one, we'd still always talk about numbers of the order of 10%. Seems to me that this really shouldn't make much of a difference in terms of design complexity/cost. Or am I missing something here? Obviously, I don't know much about DAC design.

Edit: hmm....well - if you upsample/oversample in the digital domain before the actual DAC and assuming a fixed-point representation, you may need one extra bit for the headroom - and that would give you 6 dB headroom - much more than the required ~10%
Last edited by Music Engineer on Mon Nov 28, 2022 9:16 pm, edited 1 time in total.
My website: rs-met.com, My presences on: YouTube, GitHub, Facebook

Post

Music Engineer wrote: Mon Nov 28, 2022 7:38 pm Yeah - I always wondered, why intersample peaks should be an issue for DACs at all. I mean, from a theoretical perspective, all it takes to avoid clipping on the DAC side would be to have some headroom of around 9% (more precisely, the Wilbraham-Gibbs constant, times 100%)
From a purely theoretical point of view I don't think there's really an upper bound. For practical purposes the theoretical upper bound depends on the reconstruction filter. In practice, that's mostly theoretical though, because truly degenerate situations are not going to happen by chance.

Post

mystran wrote: Mon Nov 28, 2022 9:08 pm From a purely theoretical point of view I don't think there's really an upper bound. For practical purposes the theoretical upper bound depends on the reconstruction filter.
Hmm...I mean, the Wilbraham-Gibbs constant already assumes an ideal brickwall filter. Could an actual, non-ideal filter actually be *worse* than that in terms of overshoot? I mean, sure - it certainly can if it happens to have a crazy frequency response like, say, a resonant lowpass. But if we assume that it reasonably approximates a brickwall, my intuition tells me that an actual, true brickwall should feature more ringing than a real filter with a transition band. ...but as said - it's just a gut feeling at the moment - I didn't seriously check the math. The rationale is: the transition bands in practical filters constitute a softer tapering in the frequency domain which tends to reduce ringing in the time domain. From that perspective, an idealized brickwall filter seems to be the worst case scenario already.

Edit: but maybe the overshoot may also increase from the idealized case due to the minimum-phase vs linear-phase nature. In a minimum-phase filter, all of the ringing is brought to one side (it's "causalized", so to speak), so it may overshoot more at that side. But if that's the case, I'd expect that doubling of the headroom from 10% to 20% should be enough
Last edited by Music Engineer on Mon Nov 28, 2022 9:39 pm, edited 2 times in total.
My website: rs-met.com, My presences on: YouTube, GitHub, Facebook

Post Reply

Return to “DSP and Plugin Development”