# Combining time domain and frequency domain data for BPM detection in real time

I would like to write a BPM detector. Does either of the domains provide more information for this type of analysis?

What exactly is being looked for in the data to detect onset for BPM detection in either domain?

Does tracking energy values in the time domain lead into rhythm detection?

Obviously pattern recognition can be used but how can it be done fast enough in real time using c?

• Onset of what? – Phonon Feb 21 '14 at 1:06
• This question is extremely broad. What have you tried? What methods have you researched? Many exist. Some are discussed, eg, in amazon.com/DAFX-Digital-Udo-ouml-lzer/dp/0470665998 – Bjorn Roche Feb 21 '14 at 14:55
• @Phonon - Onset for bpm detection. – jarryd Feb 21 '14 at 21:10
• just for everyone's information, "BPM" means "Beats Per Minute". – robert bristow-johnson Feb 22 '14 at 15:24

BPM detectors work by finding the strongest period in the onset detection function - a function of time indicating how likely it is that there is an onset at time t. Which brings the topic of onset detection...

Tracking energy/envelope in the time domain is a weak strategy for detecting rhythm/notes, because:

• For some instruments, there are playing techniques which create new notes without a significant change of energy (for example moving the finger on a string of a cello with no change in bowing, or changing the fingering on a flute with continuous blowing). This has the effect of creating changes in fundamental frequency without a noticeable change in the time-domain envelope.
• A lot of commercial music is so heavily compressed that the signal is almost "pumped" to maximum amplitude all the time.
• While this is yet another corner case, it is worth reminding that some instruments or playing techniques have very slow attacks.

So naively looking for peaks in the time-domain (via energy) will not be very robust. You have to look for better "clues", and the frequency domain is the answer. The simplest thing that can be done in the frequency domain is to compute the difference of energy between adjacent STFT frames (a measure known as the "spectral energy flux").

A more elaborate metric, which is actually as cheap in terms of computing costs, consists in checking the deviation between the actual and expected value of the complex amplitude in a STFT bin (reference here) - this deviation would be null in the stable segment of a note (as the amplitudes are just sustaining or slowly decaying; and the phases are just keeping on rolling), and high at an onset.

All these techniques have very modest computational costs and can be implemented in realtime even on relatively cheap microcontrollers - a complete beat-tracker (onset detection + BPM detection + beat tracking) is in the 10 MIPS range.

• "The simplest thing that can be done in the frequency domain is to compute the difference of energy between adjacent STFT frames (a measure known as the 'spectral energy flux')." for a single frame in time, you might want to weight that difference of energy spectra with something proportional to $\frac{1}{\omega}$ so that the effect per octave is the same. there might be cheaper ways to do this than the STFT (like a bank of filters equally spaced in log frequency). also, you may have issues with glissando and vibrato. – robert bristow-johnson Feb 22 '14 at 15:32