Round scanned BPM values #9464
Comments
|
Commented by: daschuer Thank you for the bug. We have a related visual and usability issue, Can you file a new bug that describes the related issue you suffer? like: "The calculated BPM is imprecise" A related discussions on Zulip are here: https://mixxx.zulipchat.com/#narrow/stream/109122-general/subject/Library.20-.20Limit.20view.20to.20mixable.20BPM |
|
Commented by: xeruf 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. |
|
Commented by: daschuer Do you have a significant sample song? |
|
Commented by: beenisss 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. |
|
Commented by: xeruf 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? |
|
Commented by: beenisss 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.) |
|
Commented by: beenisss 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. |
|
Commented by: xeruf 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. |
|
Commented by: beenisss 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.. |
|
Commented by: beenisss I'm on Mac/OS X for the record. |
|
Commented by: beenisss I get 90.036 if I enable the Fast Analysis option with the (QM) Tempo and Beat Tracker. |
|
Commented by: xeruf Maybe I did have fast analysis on when scanning this. But regardless, could this be implemented as an option? |
|
Commented by: beenisss 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. |
|
Commented by: geozubuntu Is it really a point to have BPM counted in a non integer number ? |
|
Commented by: beenisss 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. |
|
Commented by: mxmilkiib A button in the BPM tab of the file Properties dialog to round the detected or tapped BPM would be handy. |
|
Issue closed with status Fix Released. |
Reported by: xeruf
Date: 2018-10-05T10:02:17Z
Status: Fix Released
Importance: Medium
Launchpad Issue: lp1796262
Attachments: [wrong scans.zip](https://bugs.launchpad.net/bugs/1796262/+attachment/5203300/+files/wrong scans.zip), [Analyzer Test.csv](https://bugs.launchpad.net/bugs/1796262/+attachment/5203440/+files/Analyzer Test.csv), [Beat Detection Settings.png](https://bugs.launchpad.net/bugs/1796262/+attachment/5203707/+files/Beat Detection Settings.png)
Too often I encounter a song where the BPM scanned by mixxx is something like 90.07 or 95.3522 or 170.01. Almost always, the real BPM value is the nearest whole (or half, because of half-time) value, and these numbers are just annoying because I have to correct them all.
So I would like to have an option, that, when turned on, simply rounds every scanned BPM value to the nearest half number.
The text was updated successfully, but these errors were encountered: