foo_bpm, Automatic song BPM analysis Options

[Case]

All my files were 44.1 kHz 16 bit stereo FLACs.

[grimes]

44100/16/Stereo
In my opinion the mix of bpm-tagged and untagged tracks and big playlist size makes the problem.
I had also no problems yesterday with 1389 and 3531 bpm-untagged tracks

[Sylph]

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

Thanks!

I searched for it in the Legacy Commands, but it's not there. I can wait.

[fraganator]

Perhaps the component didn't load at all. Does it show up under the component list in the preferences window?

[fraganator]

44100/16/Stereo
In my opinion the mix of bpm-tagged and untagged tracks and big playlist size makes the problem.
I had also no problems yesterday with 1389 and 3531 bpm-untagged tracks

I've just finished testing a couple of playlists, both with a number of pre-BPM tagged files/albums. One list was about 1200 files and another with a bit under 2000. The BPM scan finished successfully in both cases without freezing, so I'm unsure of the cause of the problem you saw.

When you say the component hangs, is it the BPM analysis window progress bar that freezes? Or does foobar hang completely?

The code for the next release has been refactored a fair bit, including the logic for handling whether to skip a BPM tagged file. If you could try reproduce the problem with that release (should be out in the next day or two), that'd be very helpful. If the problem still persists, I may send you a build with some debugging info to help narrow down the cause.

This post has been edited by fraganator: Dec 24 2009, 14:30

[fraganator]

Version 0.1.1 has been released. See the first post of this thread for details.

[Jack Schmaltz]

thanks for the update

[neothe0ne]

Would it be possible to have this component behave similarly to ReplayGain in UI? As in, you scan the file(s), then you get a dialog window where you can see the results and choose whether or not to save the BPM tags.

This also gets around the problem of scanning a read-only file and getting an error message at the end because the tags can't be changed.

[fraganator]

Future changes:
- Add a confirmation dialog after a BPM scan has completed before writing the values to the files (similar to ReplayGain). Here would be the option to double/halve individual calulated BPMs if need be

[2E7AH]

I posted about bpm and some other tags here, and while I had the table with me I compared and added also foo_bpm to it:


btw, beaTunes uses same Ray Shooting algorithm as in OP link (Werner)

[fraganator]

Thanks for the info 2E7AH, and doing up that nifty chart. It's nice to see how foo_bpm fits in with other bpm scanners. By the looks of things it can certainly be improved! Is there a list of correct (manually calculated) bpms for the songs in that list?

I'm close to releasing version 0.2.0 which will include confirmation dialogs (ala ReplayGain), and in the event that the calculated bpm is wrong, a dialog for manually tapping out the bpm. The configuration parameters for the bpm algorithm will also be included, so hopefully things can be tweaked to determine the best parameters for the widest range of music.

[2E7AH]

Yeah, I should have tapped them before posting such lists.
But also tracks are known, except I guess two binaural beat artists which maybe should be there

Adding configurable parameters is great idea (thou I don't know the algorithm;)

[Jack Schmaltz]

looking forward to the features in the next update fraganator, finding this component very useful indeed

[fraganator]

Version 0.2.0 is out. Please let me know if you have any questions regarding the algorithm parameters, or if you find any bugs

[2E7AH]

some major improvements, it really looks great now, and I haven't seen any BPM analyzer with such configurable options
BPM precision is just so obviously useful, and while I tweaked all parameters for one album BPM detection, it seems that default values are tuned best
about changing granularity of detected BPM, it can be achieved only by changing min/max range of calculated BPM, right?

and manual tapping is just cute (and best way to do BPM). makes we want to write mainBPM, subBPM or start/endBPM...
what is "tap to average", which is reseted anyway if changed?

I guess that implementation of those two algorithms (rayshoot, finalscratch) from OP, means that we'll have option to choose which one we want to do BPM in the future?

[edit] can somewhere be added option for halving/doubling BPM result?
[edit2] eh, it's in OP future changes as point 1, just now I saw it

This post has been edited by 2E7AH: Dec 31 2009, 08:20

[fraganator]

about changing granularity of detected BPM, it can be achieved only by changing min/max range of calculated BPM, right?

When you say granularity, are you referring to the precision of the BPM result? ie. 125 vs 125.39?

what is "tap to average", which is reseted anyway if changed?

The manual tapping calculation keeps a moving average of the last "Taps To Average" values. So in the default case, the BPM calculated from the manual tapping takes the average of up to the last 30 taps. This helps to smooth out any user errors with clicking in time, and any error arising from the precision of the system software timer (due to interrupts, events, etc)

I believe you've found a bug for the Taps To Average value always being reset. I shall release a fix for it in the next couple of days.

I guess that implementation of those two algorithms (rayshoot, finalscratch) from OP, means that we'll have option to choose which one we want to do BPM in the future?

Yes, that's the plan I was also thinking of implementing a voting scheme where each BPM algorithm is run on a file, and then the results are voted on and the most common BPM is selected.

This post has been edited by fraganator: Dec 31 2009, 18:57

[2E7AH]

Nice

about granularity I was thinking about beat frequency that are considered in detection, i.e. main beat is generally reported as BPM value, but there are layer of beats that can be considered also
example: Plastikman - Plasticity, main beat is 125 sublayer is 190 and combined together go above 250

[Steve Forte Rio]

Big thank you for your plugin. Happy New Year!




But why does there is a double in the list of components?

This post has been edited by Steve Forte Rio: Jan 1 2010, 12:16

[fraganator]

Version 0.2.1 is out. It contains a number of fixes for the reported bugs. Thanks for everyone's feedback!

[q-stankovic]

You forgot one bug fix!

In the "Manually tap BPM ..." window you can tap either with mouse on big tap button or with spacebar. But once you have reseted BPM the spacebar activates the "Reset BPM" button: To get it working again you have firstly to click in tap button.

I played around with this component. How expected stuff like Psytrance is calculated accurately and many Hip-Hop tracks are calculated with double BPM. I then changed the "Calculated BPM (Min/Max)" settings to match the range of Hip-Hop and because of that the correct (means: halved) BPM is calculated. I am fascinated about that feature and am looking forward to the feature to set different presets based on genre tag.

However i have some questions to the other parameters: If i increase the number of "Seconds per Sample" and/or "Samples per Song" then the scanning will take more time. But does increasing these settings also mean that the result will automatically become more accurate?

Thanks for foo_bpm, i always looked for a bpm counter that is able to handle all file types, not only mp3.

EDIT
Out of curiosity: How do you plan to integrate the "Manually tap BPM ..." window into scan result window. Right click a song and playback starts automatically?

This post has been edited by q-stankovic: Jan 1 2010, 19:12

[fraganator]

In the "Manually tap BPM ..." window you can tap either with mouse on big tap button or with spacebar. But once you have reseted BPM the spacebar activates the "Reset BPM" button: To get it working again you have firstly to click in tap button.

Oops, I didn't notice that. I'll fix it for the next release.

However i have some questions to the other parameters: If i increase the number of "Seconds per Sample" and/or "Samples per Song" then the scanning will take more time. But does increasing these settings also mean that the result will automatically become more accurate?

It doesn't guarantee that the results will be more accurate, but I've found increasing those values can make the difference between a correct and incorrect bpm result. I currently use 20 & 20 for those values and it does seem to improve results for a few tracks.

Out of curiosity: How do you plan to integrate the "Manually tap BPM ..." window into scan result window. Right click a song and playback starts automatically?

I haven't thought that far ahead yet. I'll have a think about the best way to do it and what makes sense. My next priority is improving the current bpm algorithm, and then implementing some of the other bpm algorithms.

[q-stankovic]

I haven't thought that far ahead yet. I'll have a think about the best way to do it and what makes sense.

Just a quick idea that is simple and clean: right click song -> "Play" -> Using just spacebar to avoid additional window -> result shown in extra column.

[MedO]

Changing the BPM precision changes the result for me (in big ways). Here's a list of tracks i scanned in both "nearest 1" and "1 decimal" precisions:

151 - 150.3
159 - 119.6
126 - 189.3
175 - 175.2

The tracks are from the Machinarium Soundtrack Bonus EP, which can be downloaded for free. I didn't expect a very good rate of detection with that music, but I didn't expect these differences to appear from changing precision.

[Nemphael]

I tried converting some files to compare BPMs. Most of the files were originally either >192kbps or FLAC files. Original files at the top, then the corresponding converted file below. They're converted with Nero's AAC encoder at q0.19 Or ~45kbps). I also chose to compare FFT sizes of 2048 (standard, I believe?) and 8192.

Sometimes, the differences between a converted file and its original are huge. For this small set of tracks - 47 beats per minute max!


EDIT: Compared a set of FLAC files to AAC files at q0.40 and q0.20. Standard settings, using an FFT size of 2048.


(I believe spaces should be the same on all systems, compared to tabs?)

CODE

Artist || Title || BPM || Bitrate
===============================================================================
Elvis Presley || (Marie's the Name) His Latest || 105 || 1007
Elvis Presley || (Marie's the Name) His Latest || 105 || 128
Elvis Presley || (Marie's the Name) His Latest || 105 || 55
Mark Knopfler & Emmylou Harris || All the Roadrunning || 154 || 908
Mark Knopfler & Emmylou Harris || All the Roadrunning || 98 || 125
Mark Knopfler & Emmylou Harris || All the Roadrunning || 105 || 52
Yann Tiersen || Le Banquet || 156 || 886
Yann Tiersen || Le Banquet || 156 || 132
Yann Tiersen || Le Banquet || 159 || 49
Travis || Closer || 107 || 980
Travis || Closer || 108 || 122
Travis || Closer || 108 || 52
Matchbox Twenty || Cold || 176 || 1130
Matchbox Twenty || Cold || 176 || 146
Matchbox Twenty || Cold || 176 || 60
Yann Tiersen || Comptine d'été n°17 || 173 || 1025
Yann Tiersen || Comptine d'été n°17 || 173 || 134
Yann Tiersen || Comptine d'été n°17 || 173 || 52
Nightwish || Dead Boy's Poem || 133 || 982
Nightwish || Dead Boy's Poem || 133 || 137
Nightwish || Dead Boy's Poem || 133 || 56
Yann Tiersen || La Dispute || 169 || 637
Yann Tiersen || La Dispute || 166 || 108
Yann Tiersen || La Dispute || 166 || 40
Coheed and Cambria || The End Complete IV: The Road || 93 || 1101
Coheed and Cambria || The End Complete IV: The Road || 139 || 143
Coheed and Cambria || The End Complete IV: The Road || 139 || 58
Nightwish || Ever Dream || 147 || 1107
Nightwish || Ever Dream || 147 || 143
Nightwish || Ever Dream || 147 || 59
Sigur Rós || Góðan daginn || 126 || 965
Sigur Rós || Góðan daginn || 166 || 138
Sigur Rós || Góðan daginn || 176 || 53
Dire Straits || Going Home (Theme From Local H || 167 || 862
Dire Straits || Going Home (Theme From Local H || 157 || 127
Dire Straits || Going Home (Theme From Local H || 153 || 50
Fall Out Boy || Grenade Jumper || 174 || 1119
Fall Out Boy || Grenade Jumper || 174 || 146
Fall Out Boy || Grenade Jumper || 174 || 61
Fall Out Boy || I'm Like a Lawyer With the Way || 193 || 1143
Fall Out Boy || I'm Like a Lawyer With the Way || 193 || 146
Fall Out Boy || I'm Like a Lawyer With the Way || 193 || 60
Mark Knopfler || The Last Laugh || 108 || 829
Mark Knopfler || The Last Laugh || 108 || 117
Mark Knopfler || The Last Laugh || 106 || 47
Thomas Newman || Marine || 150 || 641
Thomas Newman || Marine || 139 || 129
Thomas Newman || Marine || 139 || 47
Owl City || On the Wing || 115 || 1081
Owl City || On the Wing || 115 || 142
Owl City || On the Wing || 115 || 57
Mark Knopfler || One More Matinee || 160 || 816
Mark Knopfler || One More Matinee || 162 || 121
Mark Knopfler || One More Matinee || 160 || 47
Anberlin || Reclusion || 169 || 1112
Anberlin || Reclusion || 169 || 141
Anberlin || Reclusion || 169 || 58
Mark Knopfler || Secondary Waltz || 152 || 846
Mark Knopfler || Secondary Waltz || 152 || 111
Mark Knopfler || Secondary Waltz || 152 || 46
Elvis Presley || See See Rider || 144 || 1006
Elvis Presley || See See Rider || 144 || 119
Elvis Presley || See See Rider || 144 || 56
Coldplay || Strawberry Swing || 172 || 894
Coldplay || Strawberry Swing || 172 || 122
Coldplay || Strawberry Swing || 172 || 51
Dire Straits || Tunnel of Love || 154 || 978
Dire Straits || Tunnel of Love || 156 || 132
Dire Straits || Tunnel of Love || 154 || 52
Mew || Web || 104 || 974
Mew || Web || 104 || 130
Mew || Web || 104 || 55

This post has been edited by Nemphael: Jan 1 2010, 23:55

[fraganator]

Changing the BPM precision changes the result for me (in big ways).

Try unchecking "Interpolate Flux" in the preferences and see if that makes a difference.

Sometimes, the differences between a converted file and its original are huge. For this small set of tracks - 47 beats per minute max!

Thanks for the great job with testing. I think the inconsistent results for different bitrates are to do with the calculation of the 'spectral flux', or the difference between a set of frequencies at a given FFT with the set of frequencies of the previous FFT. As lossy codecs will discard certain indistinguishable frequencies, it's possible that the missing frequencies are having an effect on the spectral flux calculation, and hence the final BPM result. I'll have a look into how I can tweak this part of the algorithm to make it more robust.