True Peak Detection

[JCJR]

Reckon what would be the cheapest fastest way to get a "good enough" intersample peak estimation for an audio level meter or limiter?

Supposedly at 44.1 or 48 K samplerate, oversampling by 4x would get fairly close, then again to get super accurate would require big oversampling.

Maybe something as simple as hermite could get close enough. Seems doubtful but dunno. Been awhile since using hermite interpolation, maybe I should run a test case and find out.

Alternately one might use a fairly small n sinc interpolator, for instance evaluating at 25, 50, and 75 percent between each sample pair. Dunno how big an fir kernel would be needed for a quick'n'dirty but acceptably accurate peak estimation.

Something I haven't given close thought to, maybe this is a dumb idea that can't work or would be too inefficient-- Maybe windowing would be required, or maybe not--

For instance maybe if you are working with sample buffers n = 64-- What would happen if you fft that buffer, zero pad the result to size 256 and then ifft? Would that result in a buffer which antialias connects the dots at a 4x oversample rate?

If something like that would work, wonder if it would run faster than applying approx 192 short sinc fir's to that same 64 sample buffer?

[camsr]

There is probably an easier way which does not require the use of any filters at all. (and I'm not being sarcastic )

[JCJR]

Thanks camsr

For instance, samplerate 44.1 K. Sine wave of 11.025 KHz. Sample sequence repeats [0.707, 0.707, -0.707, -0.707].

The true peak is 1.0. How do I determine that without a filter or some kind of interpolator?

Or given a repeating sequence of [0.383, 0.924, -0.383, -0.924]. That one also has a true peak of 1.0.

As well as the sequence [0, 1, 0, -1] and any number of other combinations which could have a true peak of 1.0?

[Mayae]

For instance maybe if you are working with sample buffers n = 64-- What would happen if you fft that buffer, zero pad the result to size 256 and then ifft? Would that result in a buffer which antialias connects the dots at a 4x oversample rate?

If something like that would work, wonder if it would run faster than applying approx 192 short sinc fir's to that same 64 sample buffer?

The true-peak limiters i know do 4x oversampling. But I'm interested in ideas as well. You can maybe do a parabolic curve fit and solve for the maxima (similar to how people do peak frequency estimation of fft bins)? Won't be 100% true but will perform better than any degree of oversampling in certain cases, I suppose.

e: sorry, I misread your post, disregard the quoting.

[sault]

Cascade two polyphase half-band filters. Even getting into the 30 and 40-tap range would still be vastly cheaper than multiple 192-point sinc filters.

[JCJR]

Thanks Mayae and sault.

I was hoping maybe as small as 7 or 9 point windowed sinc might be good enough to estimate peaks, but have not a clue. Perhaps much bigger kernels would be required to measure peaks properly. Ought to test sometime. Was just thinking if one were to use that method, then about 192 fir's would need to be calculated to search for peaks at quarter sample intervals within a small 64 sample buffer.

Haven't looked at oversampling for awhile. Years ago tested a bunch of cheap oversample methods for execution speed, freq response and aliasing, trying to determine speed vs quality for realtime playback samplerate conversion. But during that quest I was not concerned about high frequency phase shift. If aliasing would be low and the code would run fairly fast and flat, then high freq phase response didn't matter to the task at hand.

Some IIR polyphase halfband filters I tested had very good performance considering their "relatively light" cpu load. Heavier cpu load than IIR lowpasses or whatever, but the polyphase had much better antialiasing performance than simple methods.

I can't recall if those IIR polyphase filters were advertised as linear phase. Maybe I am thinking about it wrong, but it would seem that a true peak meter would need to interpolate without shifting the phase? If the oversample filter adds phase shift, then it might tend to incorrectly measure the intersample peaks?

IOW, seems phase shift could alter the crest factor, and then one would measure different peaks than actually exist in the audio being tested? Measuring peaks in the phase shifted upsampled copy might not give the correct answer?

Do you recall about phase response in the polyphase filters you mention?

Thanks!

[juha_p]

Could this type of peak detection algorithm suite for audio applications? Too slow perhaps?

[Aletheian-Alex]

If you have not come across this yet, there is a decent amount of relevant info in papers relating to the ITU's bs.1770 standard that might be helpful. Specifically, the "Algorithms to measure audio programme loudness and true-peak audio level" PDF here: https://www.itu.int/rec/R-REC-BS.1770/en. There is inter-sample peak stuff near the end and in the appendix that might be helpful.

[Max M.]

I can't recall if those IIR polyphase filters were advertised as linear phase.

Certain polyphase filters (there're actually several different methods for making those) have "nearly" linear phase. I.e. they have some phase-shift ripple around the cutoff frequency, but the rest of the area is actually flat, e.g.:



(A few of papers as usual)

[kryptonaut]

Maybe I'm misunderstanding things, but isn't the 'intersample peak' ambiguous since it is going to depend on how the series of samples is ultimately converted back to the analog domain? I think you'd need to consider that when deciding on how to estimate the peak value.

If the 44.1K signal is going to be sent directly to a DAC and then filtered with an analog LPF then I imagine you'd want to do some kind of zero-stuffing upsampling followed by an IIR with similar characteristics to the analog filter.

However if the 44.1K signal is going to be digitally upsampled (maybe using a FIR/Sinc interpolator) before further processing or output to DAC, then you'd need to digitally replicate that processing path in your peak estimator.

[camsr]

There's a true mathematical reason for this, it's not just compensating the analog DAC filter. However, compensation for the analog DAC filter is a good idea, but unfortunately falls under that realm of audio known as "translation".
I think interpolation only may be possible. If two neighbor samples were to be assumed as points of a sine function, the midpoint may be able to express the maximum possible value at that time.

[juha_p]

If you have not come across this yet, there is a decent amount of relevant info in papers relating to the ITU's bs.1770 standard that might be helpful. Specifically, the "Algorithms to measure audio programme loudness and true-peak audio level" PDF here: https://www.itu.int/rec/R-REC-BS.1770/en. There is inter-sample peak stuff near the end and in the appendix that might be helpful.

http://techblog.izotope.com/2015/08/24/ ... detection/

EDIT: IIRC, here's an implementation for this http://kode54.foobar2000.org/ (foo_r128norm/scan)

[aciddose]

http://www.drdobbs.com/database/a-cubic ... /184409860

http://mikecourtney.tripod.com/extrema/CubicCode.html

[kryptonaut]

There's a true mathematical reason for this, it's not just compensating the analog DAC filter. However, compensation for the analog DAC filter is a good idea, but unfortunately falls under that realm of audio known as "translation".
I think interpolation only may be possible. If two neighbor samples were to be assumed as points of a sine function, the midpoint may be able to express the maximum possible value at that time.

I understand the principle that a bandlimited analog signal is completely represented by the digitised stream and can be perfectly reconstructed by summing scaled sinc functions at each sample point. But whether that is how a real-world analog signal would be reconstructed from the digital stream is another question - my feeling is that it's quite likely that an analog filter would be used.

If the purpose of this exercise is to predict the analog peak level after conversion (say, to prevent clipping distortion in analog circuitry) then I'd suggest an IIR might be more appropriate. If the purpose of the exercise is to report the analog peak assuming reconstruction with sincs, then of course a sinc-like FIR should be used for the calculation. And if the purpose is just to come up with some plausible number to display on a readout, then use whatever method's easiest.

I just wanted to point out that it's not obvious from the initial question what the application is and thus what kind of measurement is actually required.

[BertKoor]

If the purpose of this exercise is to predict the analog peak level after conversion (say, to prevent clipping distortion in analog circuitry)

It is questionable whether clipping of the analog signal path will happen at value 1.01. More likely squashing limiters have done more harm to your signal previously.

The only good use case for this I can think of, is to predict whether your signal has any chance of surviving lossy compression. And maybe you should think about what battle do you want to fight: the Loudness War for that extra 0.2 dB, or deliver pristine & enjoyable music in the best possible way?