Deal with tracks with non constant bpm

Bug #1114643 reported by Daniel Schürmann
22
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Mixxx
Confirmed
Wishlist
Cristiano Lacerda

Bug Description

For example:
"ABBA - Dancing Queen"
The beat grid with the default constant bpm assumption is pretty useless.
A non constant beat grid looks fine. But whats the use for such a beat grid?

I am not experienced enough to have a good idea for a solution.
But at least we should at reflect such non const tracks in the GUI

How does an expert DJ deal with such tracks?
Forth them to sync may sounds odd, right?
Are the suitable for beat matching?
Maybe we should assume a constant bpm at the start and the end only?

Any ideas?

Tags: beatgrid
Revision history for this message
RAFFI TEA (raffitea) wrote :

Luckily, almost 99% of modern dance music is composed in a 4/4 signature.

You can't mix a non constant BPM track the classic way because the beats distances vary. So what can you do?
1. Play the track completly.
2. Most tracks have some breaks, i.e, silent parts with no dominant bass. Bring the next track in is a good idea.
3. Use effects
4. Make use of scratching
5. Bring the next track in using a fast-cut. Very sophisticated because you must know your music, i.e., the next track must fit the current context or key code.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Thank you for your DJing hints!

But what does it mean for the Mixxx GUI?
What is the best way for Mixxx to support a DJ in doing it like proposed?

It looks like It is important to mark those tracks.
What about display a additional "~" in the BPM coloum or display the BPM range?
Or change the color or those non constant beat grid?

What should happen if we introduce a "Master Sync" clock in an upcomming version.
And how should the beatmaching mode of the upcomming Auto DJ deal with it.

Revision history for this message
Owen Williams (ywwg) wrote :

If a track doesn't have a constant BPM, there's not much the master sync can do right now. In some cases, a track has a BPM that isn't constant, but doesn't vary by a whole lot. In those cases, master sync will probably still work ok. For tracks where the BPM varies wildly, I believe the groundwork has been laid for non-constant beatgrids. In this case more testing needs to be done, but it should be possible for master sync to work if it has access to one of these special beatgrids.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

We may not be able to do much for the general case of a song that has gone totally arrhythmic but we see lots of patterns of tempo-shifts in songs (breakdowns or dubstep-interludes are the most common I can think of).

I think if we can accurately detect cases like these we could do something reasonable with the master sync. For example, if we know there is a distinct tempo shift (i.e. before point X it is 100bpm and after it shifts to 110) then we can simply adjust decks that are following that track to match the new BPM.

If there is a breakdown or interlude, if the beat 'goes away' then we could look ahead to when it comes back and make sure that following decks are on-track to be in sync when the beat comes back.

Syncing phase alignment is already done locally -- i.e. we only look at the previous and next beats from both tracks. Syncing the tempo is done globally (looking at the global BPM) but we could switch to syncing that locally as well. For a fixed-tempo-assumption user this will have no effect as the local BPM is the same as the global.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

In this context our "Assume constant beat tempo (Recommended)" is not suitable because with non constant tracks it will be pretty useless at the end of the track.

For me one bullet point on this is that we knew the kind of a track.

Can one explain what is the use of this feature and why it is recommended and default?

It looks like we have two kinds of tracks:
1. Constant Beat grid and master clock able. (Breaks and other short therms tempo shifts are allowed)
2. Non constant tracks like live recordings or "Zorba - Sirtaki" with different BPM at start or at the beginning.

Mixxx should be already able to distinguish between those types.
What about reflect this information in the GUI and for an upcoming beat matching Auto DJ?

RJ Skerry-Ryan (rryan)
Changed in mixxx:
status: New → Confirmed
importance: Undecided → Wishlist
Revision history for this message
Raf Van De Meirssche (rafvdm) wrote :

I somewhat have the impression that things are being mixed up.
Now, I can be wrong, it can be that everyone is clear about this.
In that case ... Sorry to be interfering. :-)
In the other case ... Hope this will help to come to a solution.

At one side we have music with a non-constant tempo that clearly changes and is intended to change.
At the other side we have music that has an intended constant tempo, but because there's a real drummer, it never can be fully constant.
The latter is typical for the pre-drum-machine-age of the nineties. ;-)
Abba with Dancing Queen is from the earlier age and so can never be of a constant tempo.

If anyone was not aware of that, than I'm glad I could straighten this out.

I guess that for the drum-machine-age-music the master sync will do.
For the earlier age, all will depend on the power of the master sync.
How to finally do it? ... I'm sorry ... I don't have the answer. :-(

Revision history for this message
naught101 (naught101) wrote :

For acoustic tracks, the BPM isn't going to vary *much* between bars. Maybe 5% max. It may drift over the course of a song, but probably not much *if it's not meant to*. Pro drummers are usually pretty reliable, especially for studio recordings. For those tracks, I think master sync stretching them on the fly would work - rubberband could handle that fine. That kind of automatic stretching should *always* be key-locked, because a 2 or 3% tempo shift would sound fine rhythmically, but it will sound shite harmonically. Manual non-key-locked tempo stretches should be made on top of that.

Personally, I think for *intentional* tempo shifts, it would be fine for Mixxx to automatically stretch those to fit the master sync. Otherwise, the DJ can also set the tempo-changing track to be the master, and what ever else is playing can stretch to follow that. It might sound bad, but if it does, it's only because the DJ is asking too much of her tools. In most situations, an intentional tempo change is going to be played solo, I would think, and so it won't be a problem anyway.

Revision history for this message
Pander (pander) wrote :

It is genre-specific and weather acoustical instruments are used or not, see https://www.youtube.com/watch?v=3O9wQEAUNC0 For this genre it is not uncommon at all.

To solve this issue, I would like to propose a setting in Preferences which is off by default. When switched on, the BPM detection also runs separately for the first 10% and last 10% of the track. (The percentage could also be less or adjustable in Preferences with a certain maximum of e.g. 15%.) In stead of percentages, also absolute time could be used.

When the BPM in the beginning is higher than the BPM in the end, the overall BPM of the track can be displayed in blue color, indicating the BPM considerably decreases over time. When the BMP at the beginning is lower at the beginning compared to the BPM at the end, the overall BPM can be displayed in red, indicating considerable increase of BPM.

For this, also a relative difference in a percentage or an absolute difference in BPM should be used to determine if BPM in the beginning and the BPM at the end differs enough. For example, a difference of 0.0001% is not interesting.

As a next step, BPM could displayed as BPM_begin/BPM_overall/BPM_end instead of now only BPM_overall. Here the color coding could be used as well for begin and end in relation to overall BPM and be removed on the overall BPM. This data might be put in different columns, in order to sort on each of them.

Also (automated) searching for tracks with matching BPM (see https://bugs.launchpad.net/mixxx/+bug/889898 ) will have to be more intelligent as the beginning BPM will have to match the ending BPM.

Note that this is only for certain types of music. For sure, there might be even simpler ways to present this information without making it too complex.

Revision history for this message
Daniel Schürmann (daschuer) wrote :
Changed in mixxx:
assignee: nobody → Cristiano Lacerda (crislacerda)
tags: added: beatgrid
Revision history for this message
Swiftb0y (swiftb0y) wrote :

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

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.