Thats for 10 seconds: from second 100 till second 110.

I have similar result for video with tanks column driving on road.
I even can not distinguish those audio tracks by examining it's BPM.

The soundtouch website says "The BPM detection algorithm works by detecting repeating bass or drum patterns at low frequencies of <250Hz. A lower-than-expected BPM figure may be reported for music with uneven or complex bass patterns" - is this the case here?

Would be good to compare it against some other soundtouch-using application to see whether the problem is in the library or our use of it.

Now, they aren't lower-than-expected at all: it's 2-to-3 beats per second.

I just implemented something to use the bpmdetect plugin in python:

https://gist.github.com/virtuald/c30032a5b8cdacd1a6c0

For a given file, I get the following output:

BPM: [30.310665130615234, 101.57039642333984, 50.529014587402344, 34.0688591003418, 50.531585693359375, 30.80596160888672, 32.05588912963867, 34.01376724243164, 154.14556884765625, 34.32243347167969, 103.87847900390625, 154.23440551757812, 34.306034088134766, 154.53562927246094, 38.48063659667969, 154.63739013671875, 38.483619689941406, 154.60488891601562, 38.50436019897461, 154.60694885253906, 38.50547409057617, 154.2655792236328, 38.618038177490234, 154.63363647460938, 38.62126159667969, 154.69009399414062, 152.59304809570312, 38.71311569213867, 151.76808166503906, 51.883724212646484, 152.06051635742188, 51.83548355102539, 151.66751098632812, 38.665931701660156, 151.60060119628906, 152.7415313720703, 51.886207580566406, 153.15924072265625, 51.88606643676758, 153.16085815429688, 38.81463623046875, 36.11669921875, 62.634368896484375, 77.99734497070312, 187.94322204589844, 189.19671630859375, 38.08533477783203]

Lots of noise here. Lucky for us, the bpmdetect plugin uses an external library (soundtouch) to do the calculation, and has a utility program that outputs BPM. So, I convert the same file to wav, and then run "soundstretch output.wav -bpm" to see what I get:

Detected BPM rate 157.7

From this result, I suspect what the real problem is that the soundtouch library expects to get the whole file, whereas GStreamer is calling getBpm() every time transform_ip() is called (eg, when a new buffer comes in). Is there a way to force the bpmdetect plugin to process the entire file, as opposed to just a few buffers here and there?

For our case we had to implement our own version without libSoundTouch.
Let's decide how the element should work and get rid of this dependency at all.

Well, my point was that the problem wasn't libsoundtouch, but rather the way that gst is using it. 

BUT. I found a legit bug.

There's something wonky about the way the plugin is mixing the channels when it does the memcpy. If I use a capsfilter to mix it down to a single channel before the bpmdetect plugin, then it returns results that match the output of 'soundstretch output.wav -bpm'.

I looked at it, and it seemed fine to me. Probably a padding problem or some mismatch between the buffer gst is sending and what libsoundtouch is expecting.

The workaround is good enough for me (though it would be good to fix this!), I've updated the gist with it.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/263.