Fast Fourier Transform to Detect BPM in Streaming Audio

Status
Not open for further replies.

AltAudio

New Member
Hello,

Using Microchip PICKit and MPLAB IDE, I am looking for some direction in creating an algorithm(in C I presume) that will take continuous samples of streaming audio and output an impulse commensurate with bpm of that sample period. Is Fourier analysis necessary for this endeavor? Why not simply derive bpm from changes in amplitude?

Many Thanks...Mick
 
Because the beat doesn't always exist throughout the entire course of a song, and it also changes. Tuning such an algorithm is not always reliable. You can do basic peak detection, but this is not going to provide a high quality reference to the total BPM of the song.
 
You could also use a digital band-pass or low-pass filter to detect the low frequencies present in the beat. That is likely easier then calculating an FFT.
 
An FFT is not going to get you the information you're seeking. It gives the frequency spectrum of a time varying signal, not the tempo. If you try to sample the signal with a slow clock, you'll get massive alising, which will require a very low pass filter to remove. If, in fact, you do such filtering, you could concievely use FFT to obtain the frequency of the beat, as it is really just a low frequecy periodic signal.

You might try "peaking" the music or low pass filtering, and see what you get. Since the beat can be changed or syncopized ( ie, alternated between upbeat and downbeat) you'll need some pretty intellignet software to sort it out. I do know there is inexpensive software that does some of the work for you. Not sure what you're trying to do, but something like "The Amazing Slow Downer" might be a start. Might spend a few minutes researching that.

Edit: After thinking more about this, I added the underlined part. It seems to contradict my earlier comments, but reflects a modified conclusion after more consideration.
 
Last edited:
Hi,

Brownout: Just so you know, i didnt read that as a contradiction just as a continuation.

My question would be just how fast can the signal be sampled using the proposed uC chip?
 
Brownout:
Thank you for your consideration. I am trying to determine the feasibility of programming an algorithm onto an IC that would calculate bpm of streaming audio. I suppose the clock rate would need to be at or above 44.1KHz, correct?
 
Brownout:
I suppose the clock rate would need to be at or above 44.1KHz, correct?

1. I wouldn't think so. First, I think you want to filter the audio stream to pass low frequency rhythm information, and then sample that at a couple times the expected "beat" frequency. For example, LPF to a few Hz, and sample at least 2X the cutoff frequency. That removes most of the information you're not interested in.

I would recommend that you simulate before you start writing code. If you have Matlab, you can simulate your idea pretty quickly. You can also just use old-fashioned Fourier transforms and calculus to get a quick result.
 
Last edited:
Before you attempt it on an embedded solution. Do it on your PC as a proof of concept.
Get a C compiler, take a wav file and have at it. If you can't get it to work or it's too hard you have zero chance of getting it to run on a PIC. The algorithms you come up with can probably be trimmed down to a microcontroller.
Now streaming will probably be MP3 or some form of compressed audio, you're also going to need to decode it and unless the routines are in the public domain or a library available for your compiler on the PIC it's going to be very difficult to write from scratch. Again try doing it on a PC first.
 
Most of the BPM detector routines on the net will give you an average over some time. Are you looking at doing it in real time?
Andy
 
blueroomelectronics: you state 'get a C compiler...' I have the Microchip MPLAB IDE and starter board. With more advanced boards/components, would I not be able to write/compile C code and embed on a chip using Microchip solution?
 
Yes 4pyros, I am looking to do this in real-time. It's an experimental device that outputs an electrical impulse commensurate with tempo. So it seems with FFT, there'd have to be some kind of buffer to store/process and output and that would necessarily introduce timing mechanisms to sync output with sound.
 
I don't want to speak for blueroom, but I think he only wanted you to prototype your method and code using a c compiler and some sample files before you try to run it on an actual system. Better to do as much simulation as you can, and the more abstract the method, the better.
 
Last edited:
You will need to determine a sampling rate. May be use your range of BPM as a starting point.
 
blueroomelectronics: you state 'get a C compiler...' I have the Microchip MPLAB IDE and starter board. With more advanced boards/components, would I not be able to write/compile C code and embed on a chip using Microchip solution?

To clarify. Don't bother with using MPLAB or any embedded IDE to start. There are public domain C compilers for your PC get one and use that. Remember you'll have to depend on your own libraries and those nice visual tools are not available with an embedded MPU.

I think the ancient Turbo C went free, the one for DOS is sufficient. Write a command line program that takes in a .WAV file and outputs the BPM. Once you get that working try it in real time with a sound card microphone input.

PS I'm not sure you can reliably do BPM in real time. Why would you want to?
 
Last edited:
Well I am trying to experiment with a device that outputs an electrical impulse through electrodes based on musical tempo. I've successfully built one using a low pass filter and that works fine with percussive audio, but I'd like to incorporate a steady 1/4 note cadence even in less dynamic passages.
 
I assumed all along you were talking about something with heavy percussive or base rhythm. For less dynamic passages, it's going to be much trickier. IMO, you'll need to do peak detection, but the peak detection will need to be adaptive to account for changing volume. This I'd try a software PLL that syncs up to the peaks. You'll have to generate the peaks from subtle voice inflections and such. It should be a decent challenge.

I think peak detection and PLL synchronization is a better idea than FFT. Honestly, you can get the base frequency without FFT, so it’s not really needed. But the PLL should keep the BPS during times when there are insufficient discernable peaks.
 
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…