mixxxdj / mixxx

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

Avoid playing multiple versions of the same song #13391

Open dustinpaluch opened 1 week ago

dustinpaluch commented 1 week ago

Feature Description

I DJ for swing dancers, and my library is filled with multiple versions of the same song, maybe recorded by different bands, or live versions, alternate takes, etc. My workflow is adding an entire Crate to the Auto DJ, shuffling it, and then maybe manually curating a few songs from there. But when I have multiple versions of a song in the Crate, I run the risk of playing "the same song" twice or more.

It would be great if playing one version of the song causes every other version to receive the "played" checkmark. I would be able to quickly scan the Auto DJ queue for any tracks with checkmarks and remove them. I would be responsible for manually associating songs with each other.

ronso0 commented 1 week ago

I think #13337 will help: it enables sorting in the AutoDJ queue and you can remove duplicate songs. (assuming the related songs have the same title (prefix))

daschuer commented 1 week ago

Sorting won't help, because the played track is already evicted from the Auto DJ playlist.

The feature involves to look up similar tracks. The question is how Mixxx can do this automatically. What would be the rule to find them?

dustinpaluch commented 1 week ago

I don't see a way to do this automatically. You couldn't do it by track name, as there are certainly different songs out there that are coincidentally named the same. Waveform analysis wouldn't work, as I'm trying to match recordings as disparate as

https://www.youtube.com/watch?v=SiacwK85Fgc https://www.youtube.com/watch?v=R0crYaC0Azc

Where the keys, tempos, instrumentation, vocals (or lack of) and even the decade they were recorded in are all different.

daschuer commented 1 week ago

So what do you have in mind to solve this request?

I can imagine to add a similarity column (we plan it anyway at some point) and mark tracks as "equal" or such. Than we can mark all equal tracks a played when one of them has been played.

dustinpaluch commented 1 week ago

I guess I would break it down into sub-tasks:

DB support for associating tracks with each other

A table for "similarity groups"? And then individual tracks can have a similarity group id column? Logically it should be thought of as adding or removing a track to a group. If I have 8 tracks I want to associate with each other, I should not have to manually create 28 associations between each combination.

This means that a track can't be in multiple groups, which makes sense to me, but leads to some edge cases which we could discuss.

UI for creating/removing associations

Maybe a new right click menu option "Assign similar tracks"? Which pops open a window like so:

fig1

UI for communicating which tracks have associations

You mentioned a "similarity column", which I'm not sure if you just mean what I'm saying above about a backend DB column, but on the front end in the library browser, there could be a similar tracks column which just contains the number of tracks that have been marked as similar to that track. And after seeing that, you could right click and choose the new menu option described above to make changes. We'd need something like this for transparency.

UI for communicating that you've already played another version of any given song

When I'm looking at my track list or a crate or a playlist, I should be able to see at a glance that a given song has had a similar version played already. My initial request was that similar songs would receive the "played" check mark, which would meet my needs, but it would be better if it received a different colored check mark to communicate "this track wasn't played, but a similar one was".

daschuer commented 6 days ago

To reuse the column for finding a successor track, I had a slightly different model in mind: A association table of two tracks with a percentage value. Suitable successors have a rate of let's say 70 to 90 % higher similarity can be considered as boring and from 98 % or such we can even mark them as played as you have suggested.

dustinpaluch commented 6 days ago

Still thinking about auto-detecting similarity? I don't really know what is possible in that space but I am excited to see what could be done!

daschuer commented 5 days ago

Not in the first place. It is probably more easy to tab online services like Spotify. We have a PR that fetched the info from it.

dustinpaluch commented 5 days ago

I'd guess a good chunk of the music I DJ is not on Spotify. Some of it is not even on musicbrainz or discogs.

daschuer commented 5 days ago

In a final version there will be all, a manual editor, a Mixxx algorithm and a feature to retrieve info from Spotify Discogs and friends. Do you have interest to help?

dustinpaluch commented 5 days ago

Sounds good! I don't know C so I won't be any help there. If there are development versions or a feature branch that needs testing, I could perhaps do that. Or writing documentation on the finished feature.

daschuer commented 4 days ago

Cool thank you for offering your help. We have way to view contributors taking care of the manual and the tedious work of translations.

For this we need also a fluent c++ contributor.