Fix const beat grid first beat placement #3965
Conversation
…t of the track as possible.
|
Thank you for jumping in here. I have not found time at a whole to dive into the issue myselfe. |
|
This is kind of a workaround, since I think the first beat calculation should be more robust, but I this fixes the specific issue in a safe way. No worries! |
You mean: ...that the fist beat is in the middle of the track. Yes that's quite obvious eithbe the new algorithm. My intended question was: What are the track where this is relevant. It is only relevant whenevet the best detector detects the wrong tempo, and it is not fixable by a multiplayer along with a simple shift for phase correction. If you have such tracks I am curious, why the detector fails. |
|
Let's talk about example tracks on Zulip, it is off topic for this fix. Just because the user "shouldn't" see the problem unless they try to adjust the track doesn't mean there is no bug. We should still apply this fix regardless of whether the detector has a problem with a specific track. If for some reason you think this fix is wrong, please explain why rather than bringing up tangential issues. |
I can acknowledge that there is a bug and this PR fixes the bug. I am just curious to know the track where the bug arise. |
|
There is one source code comment open. Do you want to add the suggestion? |
|
Do we want to bump the version number because of that? This will reanalyze all the tracks according to the prefence settings. The issue is only relevant when the detection fails anyway. I am heading to yes, bump the version. |
... because of the moved first beat in const beat grits introduced in mixxxdj#3965
|
see: #3973 |
|
I posted a link to the track in Zulip |
Make sure the first beat in a const beat grid is as close to the start of the track as possible. Workaround fix for lp#1930930