Beat detection

Hi all,

I'm looking for a way to do beat detection on a stream of music (coming from an mp3 player or whatever via standard 3.5mm audio cable, probably).

I know I can do beat detection externally using a laptop, then piping commands over serial to the Arduino, but I'm hoping there is a way to do it either onboard the Ardunio, or through some other chip/whatever.

So, anyone got any ideas? I know FFT will probably be involved, and I know that is pretty expensive - is it even be possible to do FFT (and have it useful for beat detection) on the arduino?

If so - how do I do it? And, will I be able to do other things at the same time (probably just drive a few servos)?

If not, then how does one go about doing this? Are there dedicated FFT chips out there? Would a different version of the Arduino board running a faster chip be any better?

I know, so many questions, but I don't know a lot about this and there's almost certainly someone out there (maybe you?) who knows about this.

Any help is appreciated.

Just been pointed to this link. No FFT involved as far as I can see, and in the video at the bottom the lights often blink on the beat.

http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=120

How, then, would I turn these blinks into a "beat"? Any ideas?

A strong "beat" is normally associated with 2 things; a lower frequency and a higher amplitude.

The simple way (requires parts) I would do it is to pre-process the analog stream with a low pass filter and then follow that up with a comparator with adjustable threshold. (THE AVR has a comparator but you have little control over it)

The low pass filter might involve 1/2 of a generic op amp and the comparator function can be done the other half of the op amp comparing the filter to say an potentiometer value. You could then use digital read to determine a 1 or 0 for beat or no beat.

Yeah, it needs external parts... but there are many google hits if you want examples of Low pass audio filters and op amp comparators.

Okay, so FFT related shenanigans aren't really needed?

I've got a little experience with low pass filters and comparators, so that should be fine. Are there any algorithms available that would calculate the threshold, though? If (for example) the source changes from a loud song to a quiet one, the required threshold will change. I assume there must be some algorithms or something out there related to this sort of crap...

Cheers for the help

Detecting an actual beat is computationally intense activity that requires a lot of memory to store preceding samples. There are some algorithms of varying complexity, usually performing better the harder they are to implement. It may be possible to reliably detect a beat on an Arduino, but I wouldn't bet on it. I put "beat detection" into Google and this was the first link: http://www.gamedev.net/reference/programming/features/beatdetection/

Now, if you just want to have some logical-appearing reaction to sound, you should look into VU measurement. Audio power sometimes does follow a beat, and measuring it does not require much processing.

Well, the actual beats are not so important - just so long as I can get something happening in sync with the music. Essentially, I don't need to know about every time a snare/kick/hat happens - just the tempo would do.

I'm not sure if this is any easier than "real" beat detection...

This sort of thing?

Nope - more like the type of beat detection you do in order to nod your head in time with the music (as opposed to the type of beat detection you would do in order to air-drum along).

It's the head-nodding beats I'm after, not the air-drum beats :slight_smile:

bump :slight_smile:

Well, I think one general algorithm of it is as follows:

  • keep a small array of beat predictions, each with a next-time expected, and a count of how many predictions came true

  • listen until you hear a beat (a local maximum in amplitude)

  • mark the time

  • see which prediction comes within a few milliseconds, or add a new prediction (replacing the prediction with the least hits, if you've run out of room)

  • increment the prediction hit count

  • erase any prediction that hasn't been hit in the past, say, five seconds

  • repeat the process

  • at any point, the prediction with the highest count is the most confident guess; once it's at least four, you can start blinking to that rhythm

In fact, now you got me wanting to code it up.

Aye, in theory that sounds fairly straightforward. If you want to implement it, go ahead :wink: I'd love to see how you do it!