mixxxdj / mixxx

Mixxx is Free DJ software that gives you everything you need to perform live mixes.
http://mixxx.org
Other
4.51k stars 1.28k forks source link

With 'Re-analyze beats' unchecked, after changing BPM Range Mixxx re-analyzes and resets beatgrids on loading a track #9462

Closed mixxxbot closed 2 years ago

mixxxbot commented 2 years ago

Reported by: beenisss Date: 2018-10-04T18:36:13Z Status: Expired Importance: High Launchpad Issue: lp1796162


Occurs on 2.1 full release and latest master build.

If you update the BPM Range in Preferences and have 'Re-analyze beats' unchecked, Mixxx still re-analyzes any track you subsequently load where BPM lock is not set, and resets the beatgrid. Any subsequent attempts to update the beatgrid manually trigger another re-analyze loop when the track is next loaded, which resets your manual adjustments, effectively preventing you from making any permanent adjustments to the beatgrid.

To reproduce:

(back up your Mixxx folder first)

Go to Preferences > Beat Detection Uncheck 'Re-analyze beats when settings change or beat detection data is outdated' Change your bpm range by some arbitrary value, eg drop the Min value by 1 Click OK Load a track where BPM lock is set to off and you previously had to adjust the beatgrid by a significant/visible amount

Outcome: The track is re-analyzed and the beatgrid is reset to where the analyzer originally detected the downbeats to be.

Easy workaround is to use BPM lock for any track you don't want re-analyzed, but this is only useful if you know about this issue in advance or you're already in the habit of setting BPM lock.

Device & OS:

MacBook Pro (Retina, 15-inch, Mid 2014) macOS 10.13.6 2.8 GHz Intel Core i7 processor Intel Iris Pro 1536 MB graphics

mixxxbot commented 2 years ago

Commented by: rryan Date: 2018-10-06T06:32:48Z


Yikes, that's not good! Sorry about this.

mixxxbot commented 2 years ago

Commented by: beenisss Date: 2018-10-08T20:33:09Z


That's alright, it hasn't really caused any lasting damage. I just went into the database directly and set the bpm_lock field to 1 for my whole library to prevent any changes. It makes sense to have it on anyway.

mixxxbot commented 2 years ago

Commented by: rryan Date: 2018-11-03T06:49:30Z


Do you have a mixxx log file from when this has happened? We print debugging info about why we decide to re-analyze a track.

If the BPM is 0.0 or the first beat is at position 0.0 then we override the preference setting and re-analyze anyway. If the first beat is 0.0 then the code is supposed to only change the grid offset.

mixxxbot commented 2 years ago

Commented by: beenisss Date: 2018-11-03T18:29:31Z


If the BPM is 0.0 or the first beat is at position 0.0 then we override the preference setting and re-analyze anyway. If the first beat is 0.0 then the code is supposed to only change the grid offset.

Right, I have an idea what happened here then. I nuked my library a while back and then after rescanning I used SQL to update the Mixxx library from a backup with bpm, key etc. for each track. If I remember rightly I tried to re-apply grid offset info (partly because the analyzer frequently gets it wrong), but I couldn't work out what the corresponding field in the library was, or for whatever reason the values just seemed to get ignored anyway.

I suspect the outcome of this was that the first beat position for every track in my library was interpreted as 0.0, so the analyzer ran and reapplied the grid offset every time.

The trouble is, as I said above the analyzer very often gets it wrong. Combine this with the fact that there are plenty of tracks in my library where the first beat really is at 0.0 - or at least close enough - and you start to see the problem. When the analyzer regularly bumps the grid offset to a random point in the middle of the beat, the most economical way to get it back to somewhere useful is just to hit the Adjust Beatgrid button on the newly-loaded track. Of course this moves the grid offset back to the very beginning of the track, ie, to position 0.0.

Maybe the real bug is the accuracy of analyzer in figuring out where the beats are. I imagine one of the cheaper ways to improve its accuracy would be to feed a low-passed version of the track to it so that it's more likely to register the low-end transients as beats instead of hi hats or whatever. If I understand correctly the analyzer is a third-party plugin, which rules out the possibility of a plucky Mixxx volunteer trying to improve it directly.

Incidentally, is the 'Enable Offset Correction' option in Beat Detection Preferences meant to stop the analyzer from adjusting the grid offset? Because it's never made a difference for me - it just does it anyway.

mixxxbot commented 2 years ago

Commented by: daschuer Date: 2019-08-19T20:35:41Z


I cannot confirm this using Mixxx 2.2.2 or Mixxx 2.3.0 alpha. Can you? Maybe this was fixed in the meanwhile?

mixxxbot commented 2 years ago

Commented by: beenisss Date: 2019-08-20T18:28:28Z


I will try and take another look when I get a chance.

mixxxbot commented 2 years ago

Commented by: daschuer Date: 2019-12-09T22:22:27Z


I remove the milestone and let it expire

mixxxbot commented 2 years ago

Commented by: janitor Date: 2020-02-08T04:17:35Z


[Expired for Mixxx because there has been no activity for 60 days.]

mixxxbot commented 2 years ago

Issue closed with status Expired.