You can access the manual BPM calculation window through the context menu (right-click->BPM Analysis->Manually tap BPM for current track). Clicking the Update Tag button will write the BPM to the currently playing file.

No changes have been made to the algorithm itself, but the parameters are now available for tweaking. You will probably have the most luck experimenting with the "Samples Per Song" value, followed by "Seconds Per Sample". Try increasing one or both, though calculation speed will take a hit.

Here's a quick overview of some of the parameters:"Seconds Per Sample" - The number of seconds of audio grabbed from the file at any one time. The result of this sample produces a single BPM value."Samples Per Song" - The number of times we grab an audio sample from the file. This determines the size of the final list of candidate BPMs."Sample Offset (Min/Max)" - When grabbing audio samples from a file, start from the minimum offset and move towards the max offset. These values are used to avoid slow fade in or fade outs of songs."Calculated BPM (Min/Max)" - Limits the range of the BPM calculation to these values. Change the min and max to suit particular styles of music (e.g. 70-110 for hip-hop, 150-200 for d'n'b, etc)

-----------------------------

Hi everyone,

I'd like to introduce my first foobar2000 component: foo_bpm

As the name suggests, it is designed to calculate the BPMs (beats per minute) of any tracks in foobar2000.

I like to DJ a bit in my spare time, and I also buy a fair number of CDs for DJing and general listening. The problem is when DJing, I'm not familiar enough with the tempo of my new tunes to drop them straight into mixes. So I wrote this component so I could use the foobar2000 to sort and manage new tracks by their BPM, helping me select new tracks to play with a minimum of fuss. The component could also presumably be used to come up with playlists of a certain tempo for exercise workouts, etc.

Here's a brief overview of how it works:1. Grab a 10 second sample from the song2. Transform the sample from the time domain into the frequency domain using windowed, overlapping FFTs, also know as Short Time Fourier Transforms (STFTs).3. Onset (or beat) detection is performed on the resulting STFT. The onset detection function takes the spectral flux of the STFT to generate a list of candidate beats.4. The candidate beats are run through an auto-correlation function to determine the dominant beat frequency, and hence the BPM.5. These steps are repeated at different points throughout the song, resulting in a list of candidate BPMs.6. The BPM list is sorted and the average mode value is chosen as the BPM.

The FFTW library is used for calculating the FFT. A dll for this library is included with foo_bpm.

Usage:- Highlight one or more files in your playlist. Rightclick on them and select "BPM Analysis->Automatically analyse BPMs..."- After the analysis has completed, the results are automatically written to the "BPM" field of the tag.- If the BPM field already exists for a song, it will NOT be overwritten.

Known Problems:- The calculated BPMs are not always accurate, especially for songs without obvious beats or large changes in tempo. You can compare the accuracy of the calculated BPM with the included manual BPM tapping function.- In a number of cases a song's BPM may be calculated as double or half of its 'true' BPM. So don't be alarmed if you see some obviously slow R'n'B songs with BPMs of 180 or more! They are actually half of that.- Songs shorter than 10 seconds will automatically have their BPM set to 0. This is by design as it isn't possible to accurately determine the BPM of such a short track.- There can be large discrepancies between BPMs calculated to the nearest BPM and BPMs calculated to 1 or 2 decimal places. I would recommend using either 1 or 2 decimal places as they seem to be closer to the real BPM.- Tapping the spacebar on the manual tapping window when the large Tap Here button loses focus will stop working. The button must be clicked again to regain focus so the spacebar will work.- BPMs calculated for the same song at different bitrates (eg mp3 V0 vs mp3 V5) can have significantly different results. This relates to the spectral flux calculation and will be improved.

Future changes:- Improve the current BPM algorithm (wrong BPMs, double/halved BPMs, overall speed)- Implement other BPM algorithms such as this and this- Add a menu option and dialog window with a button to manually calculate the BPM by tapping/clicking along with the current playing song- DONE- Add a confirmation dialog after a BPM scan has completed before writing the values to the files (similar to ReplayGain) - DONE- Add option to double/halve individual calulated BPMs if need be. - DONE Will also add to context menu. - ALSO DONE- Add a properties page with all of the algorithm parameters available for tweaking - DONE- Specialise the algorithm parameters for different genres, then automatically scan using those parameters based on the GENRE tag- Cleanup and release the source code - DONE- Handle manual BPM calculation when button is pressed down, not released

p.s. The command in my context menu is still under legacy commands, could you make a separate context group for it?

Are you using one of the fb2k 1.0 betas? The 1.0 SDK might need to be made available before I can change the context menu like that. Can anyone confirm this? I was thinking of just moving it under Utils or something anyways.

QUOTE (Jack Schmaltz)

one suggestion so far, would it be possible to have a Results Window open displaying the results once the analysis is complete?

p.s. The command in my context menu is still under legacy commands, could you make a separate context group for it?

Are you using one of the fb2k 1.0 betas? The 1.0 SDK might need to be made available before I can change the context menu like that. Can anyone confirm this? I was thinking of just moving it under Utils or something anyways.

Yes I'm using 1.0 beta 5. I forgot about the SDK, i think you're right there. Utils would be a good group i guess

ah, my apologies. i did read the to do list but obviously didn't sink in.

so far the results are very accurate with styles like Psy-Trance & Hardcore Techno, a bit off with some Breakcore/Hardcore Techno i have but the beats on the inaccurate results are fairly inconsistant anyway so isn't a fault of the component in my opinion.

Autechre, Aphex Twin and Squarepusher were the yard sticks for the more extreme BPM tests and the component doesn't do too badly. You're right though that the results can be fairly inaccurate when it comes to genres like that. Hopefully things will improve!

if i can help in anyway with regards to testing & sending results etc. please let me know as i'd be more than happy to help, as like yourself i like to know the bpm's for dj'ing purposes & currently do it manually with a bpm counter.

regarding testing again, some Drum & Bass i have doesn't appear to perform greatly, with it either being spot on or very off. the off results having pretty consistant beats also.

i'm startled by this plugin, half the tracks i scan to try & catch it out work brilliantly, great work.some come through at half bpm, but as you have already pointed this out & i have noticed the same behaviour previously with other auto bpm counters i won't add them as inaccurate.

analyzing smaller portions (per album) works, so it seems not to be a problem of the individual track. problem happens at track 668 of 11715. analyzing this amount was a little bit optimistic

EDIT: Happens again with smaller portions (about 1000 tracks). Here whole portion hangs but analyzing individual album works. It stops at last track of an album (a Jethro Tull bootleg) next album again already bpm-tagged. (Thick as a brick (studio))

I scanned over 3000 tracks at once yesterday without trouble, so it's not about list size. Unrelated question: Is it intentional that you decode entire track and not just short snippet from it?

That's interesting about the playlist size. What file formats are your songs in grimes and Case? Also what are the sample rates, bit depth, number of channels, etc?

Only a short audio snippet (10 seconds) is used for a single BPM estimate, but that BPM estimate may be inaccurate. So to help ensure the correct BPM estimate is made, multiple 10 second snippets are taken from the song at different points and the BPMs calculated. So it may seem like the whole file is being decoded, but in reality it is multiple 10 second chunks of the file that are being decoded. So yes, it is by design

QUOTE (Sylph @ Dec 24 2009, 01:31)

Reason unknown, but by right-clicking on a track in playlist, it won't show up. In beta 5.

It's probably under Legacy Commands. I'll fix things up once the 1.0 SDK is out.