After last weeks mixed success, I started implementing the more advanced techniques Yov408 describes in his article. However, nothing seemed to improve the calculated beats per minute. I was about to go and implement the Fourier Transform, something which I wanted to avoid in order to keep the algorithm zippy. But I went back to the spreadsheet and discovered a much simpler solution.
The second sample I tried has about 3 or 4 beats too much. Upon closer inspection of those misses, those are all instances where the energy went above the threshold during for only one sample.
Once I understood the nature of the problem, it was easy to implement a solution that only detects a beat when the energy is high enough for a few more samples. I put this into code and was amazed by the results. Pretty much any song I used resulted in a BPM count withing 5 BPM of the actual count.
The adapted algorithm is:
Every 1024 samples:
Compute the instant sound energy ‘e’ on the 1024 new sample values taken in (an) and (bn) using the formula (R1)
Compute the average local energy <E> with (E) sound energy history buffer:
(R3)
Shift the sound energy history buffer (E) of 1 index to the right. We make room for the new energy value and flush the oldest.
Pile in the new energy value ‘e’ at E[0].
If ‘e’ > ‘C*<E>’ we detect a possible beat. If a possible beat was not detected in the previous calculation, we start counting, N = 0. Otherwise, N is increased by one.
If N equals a threshold (3 is a pretty good value), a true beat is detected.
Given the simplicity of the algorithm I think this is an incredible result and good enough to move into the next step of the project: Porting this to small devices.
N?ce work. How can we both play the music and calculate instant bpm?
http://www.streamhead.com Peter Backx
I've put this project on the back burner until I can get my hands on a Droid. If you want to do real time calculation, you would just calculate the BPM according to the algorithm up until the data you have. Just shift the buffer in accordance to the real time output (you need a powerful enough processor to handle this, give the simplicity, I think that won't be a problem)
http://www.streamhead.com/android-nocost-development-platform/ Android, No-cost Development Platform – Streamhead
[...] The last post on my current project already teasered the next step: taking it mobile. Considering the fact that I was programming the algorithm in Java, you might have concluded that it was going to be an Android application. If you did, you’re right. [...]
Easy BPM Calculation in Java
After last weeks mixed success, I started implementing the more advanced techniques Yov408 describes in his article. However, nothing seemed to improve the calculated beats per minute. I was about to go and implement the Fourier Transform, something which I wanted to avoid in order to keep the algorithm zippy. But I went back to the spreadsheet and discovered a much simpler solution.
The second sample I tried has about 3 or 4 beats too much. Upon closer inspection of those misses, those are all instances where the energy went above the threshold during for only one sample.
Once I understood the nature of the problem, it was easy to implement a solution that only detects a beat when the energy is high enough for a few more samples. I put this into code and was amazed by the results. Pretty much any song I used resulted in a BPM count withing 5 BPM of the actual count.
The adapted algorithm is:
Every 1024 samples:
(R3)
Given the simplicity of the algorithm I think this is an incredible result and good enough to move into the next step of the project: Porting this to small devices.
To be continued …
BTW for those following along via e-mail or the RSS feed, come visit the site and let me know what you think of the new logo.
Image credit