Is it possible to do peak finding on audio signal in real-time?

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

Is it possible to do peak finding on audio signal in real-time?

The main problem that I find is that how would I be able to interpret, when is some peak a peak and when it's not, when I cannot see to the future, but I can only see the history as well as the current sample.

Post

Just guessing, you mean plug-ins? When you set the groupDelay to the amount of look-ahead you need, the host will compensate for it. Then it's still a problem? Why?

Post

nerd wrote:Just guessing, you mean plug-ins? When you set the groupDelay to the amount of look-ahead you need, the host will compensate for it. Then it's still a problem? Why?
Because it's impossible to recognize other than local peaks in some finite buffer lengths. One cannot infer global peaks.

Post

You mean a plug-in should make use of some sort of preprocessed peak files? I think I've seen one of those at reaper, I think it's for display, but who knows.

Post

Is it possible to do peak finding on audio signal in real-time?
It would seem to depend on your definition of peaks. If we're talking local extrema, then yes as you've discovered given sufficient latency/lookahead. Usually people just refer to peaks as when the derivative changes sign while on a rising/falling edge with respect to the functions sign.

If we're talking global, then no - that would violate causality. If it's not real-time, then maybe take a look at ARA (audio random access extensions)

Post

yes-
u can find peak in real-time.
I think the delay is one sample.

so_>
1.rectify
2.sample and hold del sample on current sample is less than 1 sample del

Does that do what you want?

Post

What exactly do you plan to do with your peaks? If your goal is to normalize audio, then this is not possible since you cannot look into the future.

For typical dynamic processing, you either do not care about peaks at all (analog-style compression), or you look at a small window of say 1ms in length. The latter will cause a plugin latency of 1ms though which is not always desirable.

You may also want to take a look at sliding window min/max algorithms.

Richard
Synapse Audio Software - www.synapse-audio.com

Post

If the word "peak-finding" is equivalent to "transient detection" or "beat detection" or whatever--

So far as I know, at least a little bit of lookahead makes unambiguous transient detection easier. You would have to delay the processed audio by the amount of the lookahead, as is done by some VST hosts when you decalare a plugin's latency.

If you wish to detect transients even in low-frequency audio with few higher harmonics, like sine-wave kick drum or near-pure bass tracks, I suspect it would be most desirable to have a lookahead at least 2X the period of the lowest frequency of interest. For instance to detect pure wave transients down to 20 Hz perhaps a 100 ms lookahead would do. Or maybe shorter or longer. I'm just guessing based on experience writing such code long ago.

Most real-world music signals are not so cruel. A real-world bass guitar or miked kick drum, or most higher-frequency instruments would have more high harmonics, often with a burst of high frequency harmonics near the onset of a transient. With such instruments you can detect transients easier using less lookahead. The difficulty depends on the instrument. Easy to detect transients in snare drum or acoustic guitar. A bit more difficult with such as sax or trombone. Steel guitar maybe a bit more difficult still. Sometimes doing such coding, I added adjustable parameters so that the process could be tweaked friendlier to each kind of audio.

It also depends on how tolerant you can afford to be of excessive false positives and/or excessive undetected transients. Making the detection "more sensitive" reduces the odds of undetected transients while also increasing odds of false positives.

Sometimes I did multi-band beat detection on pre-recorded files (not in real time), and then after all "possible transients" detected in all the bands, do a final pruning task which rejects the weakest detected transients and pruning so that transients are not "unrealistically close together". For instance if several transients were detected in different bands, all within a few ms of each other, remove all but the strongest. Or alternately, remove all but the earliest. Or perhaps remove all but the one "closest to the middle of the cluster". Depending on the purpose of wanting to know the locations.

An old non-lookahead technique which could sometimes work rather well in analog circuitry and so far as I know has commonly been used in DSP. I've used the method in both analog long ago and in digital, and have read of others using the method. Maybe it has a name, but if so I don't recall the name--

Feed the input into two full-wave peak (not RMS) envelope detectors.in parallel. Well maybe RMS would work as well but I never tried it. In addition to putting the two smoothers in parallel, you could also feed SmootherA output into SmootherB input, and that might actually work better than parallel.

Set envelope SmootherA to instant attack, medium release. Set envelope sSmootherB to instant attack, longer release. Feed the smoother outputs to a comparator, so that the comparator fires when SmootherA level exceeds SmootherB level. If you just want trigger events, only fire on the first sample of every instance when SmootherA transitions from being < to >= SmootherB..Otherwise you could treat it like a triggered gate, and output a signal that is 1 for the time that SmootherA >= SmootherB, and output signal = 0 when SmootherA < SmootherB. For gate purposes might try adjusting the smoother parameters to somewhat control how the gate signal behaves.

As alternative to comparing the two smoothers, perhaps some uses could feed (SmootherA - SmootherB) into a highpass filter. I don't know circumstances that might be useful, but tis a possibility. For instance the highpass output might output a few positive-value spikes even on quiet transients closely following loud transients. For instance in a drum mix, with a loud kick drum and quieter snare, if smoother time constants are too long then maybe snare transients would not be loud enough to overcome large SmootherB level from a previous loud kick drum note. Perhaps the highpass filter could improve sensitivity and catch more quiet transients interspersed with loud transients. OTOH this might also make false positives more likely.

For broad band detecton, perhaps set smoother A release to 10 or 20 ms and smoother B release to 100 ms or more. That is just an offhand guess as its been years since doing such code. If the envelope times are too short then the detector might fire on every peak of a low sine wave, but you only wanted it to fire at the onset of each low sine wave note.

You could experiment with hysteresis, dead-bands near the threshold, to try to further minimize "chatter" of too many accidental triggers. Possibly it could sometimes help to set smoother B attack a little slower than "instant attack". I don't recall trying that but maybe so, dunno.

The parms can be adjusted to better-work on different kinds of music. For non-lookahead realtime use, maybe it could be made smart enough to be adaptive somehow, so that the process tweaks its own parms for best results depending on the input signal? I never tried that but perhaps it would work.

Post Reply

Return to “DSP and Plugin Development”