GNOME Bugzilla – Bug 651182
BPM detection is horrendous
Last modified: 2011-11-28 08:40:13 UTC
This issue was filled at: https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/784824 I'm really not sure what can be done about it, but the BPM detection feature is extremely happy to give a lot of up beat songs a BPM under 50, and it just generally doesn't know what its talking about. This is probably more under wishlist than bug, but since there's no attempt at Genius style stuff on Banshee, this is the closest thing and it would be nice if it worked better.
I think Banshee's bpm detection comes directly from gstreamer, so I'm inclined to think this may be a gstreamer bug. However, I can confirm that the bpm is frequently detected as half of the actual tempo. My assumption is this: Most popular music has a 4/4 time signature, and generally the snare drum emphasizes beats 2 and 4. Gstreamer's bpm detection probably notices those points of emphasis and thinks that they represent the quarter note, thus, bpm ends up being detected as 62 for a song with a tempo of 124. This is all speculation, on my part, though.
I have to say that this speculation, which I also did, is unfortunately false. The problem comes indeed from the bpmdetect gst element, which never succeeded in giving me one correct BPM. I tried with a lot of tracks, which BPM's I calculated with Mixxx, and they never were good. I also had an example, the song "Sing it back" by Moloko, which I knew was 168 BPM. The command line : gst-launch -m filesrc location=/path/to/my.mp3 ! decodebin2 ! audioconvert ! bpmdetect ! fakesink which replicates how banshee does, gives me 61. There's no integer that I know of which is able to multiply that to go to 168 xD As I have a personal interest in this, I will try to see with slomo, the creator of the plugin, what he thinks about that. Apart from that, my suggestion for Banshee is to remove this feature, but this is totally up to you. Regards.
(In reply to comment #2) > I also had an example, the > song "Sing it back" by Moloko, which I knew was 168 BPM. The command line : > gst-launch -m filesrc location=/path/to/my.mp3 ! decodebin2 ! audioconvert ! > bpmdetect ! fakesink which replicates how banshee does, gives me 61. If the problem is given by gst-launch outside Banshee, then it's not a bug that can be fixed in Banshee core source code or extensions. > As I have a personal interest in this, I will try to see with slomo, the > creator of the plugin, what he thinks about that. Adding him to the CC then. And retargetting bug to gstreamer.
Does the command: soundstretch $file.wav -bpm give the correct bpm value ? You'll have to decode the mp3 to wav, as soundstretch (the frontend tool to the soundtouch library that gstreamer uses for bpm detection) only supports reading this format. For a couple files here, gst and soundstretch seem to agree. If they do not agree for you, can you please upload the offending file ? Thanks
Tried this for a few files as well and can't see any difference. if you are unhappy with the quility of the bpmdetection in soundtouch, please disscuss with the upstream project.