Round scanned BPM values

Thank you for the bug.

We have a related visual and usability issue,
but the proposed solution does Imho not work well because there are also tracks without a whole number. So we have no chance to not trust the analyzer. We just can improve it. Just rounding to the nearest integer only linds the symptoms.
So I like to set this bug to "won't fix."

Can you file a new bug that describes the related issue you suffer? like:

"The calculated BPM is imprecise"
Or
"Nothing is found when I search for BPM ..."

A related discussions on Zulip are here:

https://mixxx.zulipchat.com/#narrow/stream/109122-general/subject/Library.20-.20Limit.20view.20to.20mixable.20BPM
And
https://mixxx.zulipchat.com/#narrow/stream/109122-general/subject/BPM.20sorting

That's why it should be an option. Even when the BPM is not a whole number, the analyser probably gets them wrong with its weird 4-digit number, and a lot more often the nearest whole number is simply correct.
This is not a "visual and usability issue", it is only about the scanner.

Do you have a significant sample song?
A YouTube link would be nice.

I used to have issues with the bpm detection always being ever so slightly out. It happened a lot when I had a collection that was mostly vinyl rips, though I think it would sometimes get things wrong that were genuinely at a whole bpm too. I very rarely encounter it these days, but I reckon I could easily run some bits through the analyzer again and provide some example tracks from the results.

How can you improve the analyzer though? I thought it was a third-party plugin.

How about a 'round values within 0.x of a whole bpm' option, where the tolerance is user definable?

I would've thought dealing with half BPMs is a case of setting the BPM Range correctly, though I guess some people will have collections where it's necessary that the highest value is more than twice the lowest value, which makes it easier to get it wrong. It could still help to be able to round whole values though.

I have attached a zip containing 3 examples. I ran them through the scanner multiple times and the result was always a broken number, but very very close to the actual one, which is simply the value rounded to the nearest whole.

Btw is there a place to submit songs that the scanner gets completely wrong so it can be improved?

Which version of Mixxx are you running, and what OS? The Pegboard Nerds and Rootkit tracks are both coming out at exact BPMs for me.

The Riot Games track isn't really long enough to verify if the BPM calculation is genuinely off. I have a metronome track I made directly out of a sequencer and it's not obviously out of sync by the end of the track if I set it to match the calculated BPM of that track (89.968, for the record.)

A while back when my library contained a lot of vinyl rips I went through and checked that the BPM values were right to around 1/1,000th of a BPM - ie accurate enough that over a long transition between two tracks I could rely purely on bpm sync. I checked around 400 tracks this way.

From that bit of my library I've extracted about 250 tracks that are currently set to exact BPM values, and re-analyzed the lot, to see if the analyzer agrees.

In about 180 cases the analyzed value matched the one I previously had for that track.

In about 30 cases the analyzed value needed to be changed to 3/4 of what it was, even though the upper limit I set for the BPM Range was below the value it calculated.

In about 35 cases the analyzed value was off by somewhere between 0.0001 and 0.1 bpm

In 6-7 cases the value was basically just wrong.

So I think it's fair to say there's some room for improvement in the analyzer algorithm, but again, isn't it a third-party plugin, in which case how could we make changes to it anyway?

csv attached in case anybody is interested.

I'm currently running 2.2.0-beta (build 2.2 r6578) on Kubuntu. Have you tried removing the BPMs and re-scanning them? The Pegboard Nerds one always results in 90,02829268 for me, btw I have set the BPM range between 90 to 180.

Weird, if I run build 2.2-r6566 and analyze that track it just comes out as 180 (as in exactly 180). Same on the current release or most recent master build.

I've attached my Beat Detection settings, are yours the same? Though I can't see why that would make a difference..

I'm on Mac/OS X for the record.

I get 90.036 if I enable the Fast Analysis option with the (QM) Tempo and Beat Tracker.

Maybe I did have fast analysis on when scanning this. But regardless, could this be implemented as an option?

Yeah, I think there's value in implementing this. I am still getting to grips with C++ and Qt so I can't say I'll personally be working on it, but it deserves attention.

Is it really a point to have BPM counted in a non integer number ?
In order to mix we will use the waveforms or our ears. We only need to know how many bits per minute the track is, just to find compatible tracks easily. A number with 4 decimal digits makes it difficult. I have a huge database of about 80000 tracks and only one out of fifteen (or even more than 15) has an integer BPM. I think it is pointless.
I have to agree with xerus for an option to round them if I would like. A checkbox in preferences "Integer BPM" or something similar would be the best solution for me.

There's some discussion about bpm sorting/rounding on the Mixxx Zulip: https://mixxx.zulipchat.com/#narrow/stream/109122-general/topic/BPM.20sorting

I think there's a general agreement that it could be improved but it's not high enough up anybody's priority list that they are working on it currently.

Somewhat-related PR: https://github.com/mixxxdj/mixxx/pull/2001

A button in the BPM tab of the file Properties dialog to round the detected or tapped BPM would be handy.

This has been fixed in https://github.com/mixxxdj/mixxx/pull/3790 and https://github.com/mixxxdj/mixxx/pull/3626

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/9464