Synchronise ratings and crates with MusicBrainz.org

[naught101]

https://musicbrainz.org/ is an open music encyclopaedia that collects music metadata and makes it available to the public, under open licenses. Mixxx already uses it for grabbing metadata (I don't use this functionality, because I'd rather have the metadata stored in file tags).

MusicBrainz also has the ability to store per-user per-track ratings (out of 5 stars) and tags (which can be completely arbitrary). These two features correspond almost perfectly with Mixxx's track ratings and crates. It would be *great* to have a way to synchronise Mixxx's ratings with MusicBrainz. This would be particularly useful in 3 ways:

1. As a back-up if the local Mixxx database is corrupted.
2. It would help build MusicBrainz's database, which would eventually help to provide a good quality folksonomy of less definite metadata, like genre and mood information.
3. It would provide a way to synchronise ratings and tags between software and devices (which will be especially great if Mixxx for android ever happens!).

point 2 would be especially useful when https://bugs.launchpad.net/mixxx/+bug/671632 is implemented, as we could synchronise multilevel crates like "genre/electro-swing" -> "genre:electro-swing", and provide a de facto name-spacing for MusicBrainz tags (see https://community.metabrainz.org/t/similarity-synonyms-merging-for-folksonomy-tags/326055/5 for discussion)

[Be (be.ing)]

Cool idea! Uwe and I discussed the possibility of doing a collaborative GSOC project with MusicBrainz with one of the MetaBrainz developers at the GSOC Mentor Summit. I think this project would fit that idea really well. :)

[Uwe Klotz (uklotzde-deactivatedaccount)]

YES! The dynamic organization of a library based on metadata is much more powerful than statically dropping tracks into just crates and playlists. Sharing, exchanging, and enriching this metadata with others and from different sources provides so many chances for exploring and discovering unknown possibilities.

I already was thinking about something similar. A simple system of custom tags composed of
  - a "namespace" (optional, but might be necessary when thinking globally),
  - a "name" (mandatory),
  - zero or more "values" (just strings for now)
for dynamically classifying and organizing your music. A "label" is then just a custom tag without any values, solely represented by the combination of "namespace" + "name" or just the "name".

To give you an idea here are some examples of names and values from my own library:
"Rating" (0 to 5): "r0" / ... / "r5"
"Energy" (0 to 5): "e0" / ... / "e5"
"Mood" (0 to 5): "m0" / ... / "m5"
"Epoch" or "Decade": "1980s" / "1990s" / "2000s" / ...
"Occasion": "Cruise" / "Dinner" / "Lounge" / "Party" / "Wedding" / ...
"Season": "Xmas" / ...
"DjSet": "Arrival" / "Warmup" / "FloorFiller" / "PeakTime" / ...
"Commercial" or "Advertising": ...value refers to the company/product where it appeared...
"Soundtrack": ...value refers to the name of the movie or series where it appeared...
"Cover": ...value references the original artist (and optionally the title if different) that has been covered...
"CoveredBy": ...the other direction if the cover version itself is very popular...
"Sample: ...value references the track by artist and title that has been sampled...
"SampledBy": ...the other direction if the track that used the sample is very popular...
"Soundcheck"
"Mainstream" or "Charts"
"Evergreen" or "Classic"

Currently I store my custom tags unorganized as space-separated textual tokens in the comments field. Just the values of "Rating", "Energy", "Mood", and "Epoch" in a predefined order followed by others, unordered, some of them with just their value (if more or less unique) and some as <name>:<value> pairs. All names and values encoded in CamelCase style to reserve whitespaces for separating individual tags. This works ok for filtering, but of course is very awkward and time-consuming to maintain and not suitable for parsing.

All custom tags associated with a track should permanently be stored (import/export) in one of the track's file tags in some well-defined format. I suggest using a well-adopted, machine-readable format like JSON. Enclosed in delimiters like {{ }} for distinguishing it from the remaining contents of the field when storing it side-by-side in a file tag that might already contain user-defined content. This would be much more sophisticated than what I've seen in Rekordbox: They simply enclose the list of custom "labels" into one C-style /* */ comment block and append it to the "COMMENT" file tag. I would also suggest to append the custom tag data to the comments field when exporting tags, but definitely not adopting such an oversimplified solution.

In the database custom tags should be stored in an appropriate relational schema for efficient searching, grouping and filtering. This schema s...

[naught101 (naught101)]

Awesome. Musicbrainz already has the capacity for some relationships between different entities. Definitely the covered by/cover of is there.

I think rating is best left as the musicbrainz rating widget.

The mood thing I think is not a linear scale, so it's best left as crates/tags.

The energy thing is more interesting, and I *think* it's linear (or at least monotonic :P), and so makes sense as a rating style thing, but who's going to decide what's the middle, and what's "high" and "low" (I guarantee that my "low" is some other people's "high"). I guess MusicBrainz would need to implement another rating-style scale for ordered tags like that though? Might be difficult...

Personally I think all values like this (rating, energy) should be stored as arbitrary decimals between 0 and 1, even if they're displayed by most systems as an out-of-5 rating. Then things like https://bugs.launchpad.net/mixxx/+bug/973145 could easily be implemented as just a UI change.

Not sure how MusicBrainz stores ratings internally, but if it's an integer, I guess that might cause data loss/aliasing.

All of the namespacing could be done with nested crates. Multi-level namespacing should then be possible too..

[Daniel Schürmann (daschuer)]

I would love to have something like this as well. Can this also be a data base for our long dream to have a track suggestion feature?

[Be (be.ing)]

Possibly related: ListenBrainz scrobbling Bug #669273

[naught101 (naught101)]

Musicbrains also has a "collections" feature, which would I guess be equivalent to playlists, except that it doesn't have an order. Might be a worthwhile feature request to musicbrainz to have playlists/orderable collections though.

I am also keen to use this data for track suggestion. I guess an external app would be fine, sounds like scope creep for Mixxx... Using playlists as the basis for track selection would be somewhat similar to how Spotify's recommender engine works, I think. I've been wanting to play with something like that for quite a while., but haven't had the time..

The scrobbling data could be really cool for this, too, because they provide association via proximity - a recommender that could handle "what tracks are often played immediately after the current track" would be a pretty killer AutoDJ feature :D

[naught101 (naught101)]

Added a playlist request to musicbrainz: https://tickets.metabrainz.org/browse/AB-329

[gramanas (gramanas)]

Collections are equivalent to crates, since as you said they are unordered.

I also think mood is not in a linear scale.
I remember a feature in an old samsung music player app
(idk if it's still around, I don't use samsung any more) where
there was a grid of coordinates with (0,0) in the middle, and the Y axis was
sad/happy while the X axis was fast/slow.

You would tap on a coordinate on the grid and it would play a song relative
to the grids position (top right would be happy and fast for example).
It would then curate a playlist for you based on the first song picked.

An even cooler "autogenerated" playlist would have the user pick a startpoint,
an endpoint and a route through the grid and it would create a playlist of songs that take you
from mood A to mood B continuously! (some calculus required)

Implementing a multidimensional (2D at first) mood widget to capture the actual mood of the song
shouldn't be that hard. Making it fit with the rest of Mixxx would be tho (filter by mood etc)

Mood could be set either manually or by ML algorithms that already exist.

[Uwe Klotz (uklotzde-deactivatedaccount)]

http://www.rcharlie.net/sentify/

[naught101 (naught101)]

I also remember that Samsung app, though I barely used it, and I can't remember how reliable it was.

Fast/slow we already have in BPM (although there are other music aspects that affect the feeling of speed - some 174 bpm DnB tracks feel a lot slower than most techno). But I don't think happy/sad are two ends of a linear scale either - you can be both at the same time (nostalgia is an example), and anger doesn't fit there. That Sentify visualisation captures it a bit better, but I suspect there are still cases that could be in multiple quadrants at the same time...

Acousticbrainz (https://acousticbrainz.org/1ce7ee57-8870-46c4-9dde-6a64e460f2c0) does it by having a separate axis for each major mood (Electronic, Party, Aggressive, Acoustic, Happy, Sad, Relaxed), which I think is a better way to store the data, but perhaps a lot of information to display. Also, I note that 4 of those moods are the same as the Sentify map, so maybe that is a good enough scale... Along with the danceability metric from acousticbrainz, that would provide a LOT of useful information.

FWIW, My current energy/mood crates are:
agro, ambient, bounce, building, chilled, disconcerting, driving, funky, grind, gritty, groovy, heavy, introspective, iraphilia, latenight, melancholic, poppy, punchy, salad, sexy, smooth, thump, upbeat, weird, wonky, WTF.

Of the ones that are strictly mood related (as opposed to energy), some fit in those four categories (agro, chilled, iraphilia, melancholic, salad), but others don't (disconcerting, introspective, sexy, weird, WTF). Not sure if there are likely to be other things like that that are worth putting in a scale-variable (I don't think any of those are, really, they can all just stay as crates).

disconcerting

[naught101 (naught101)]

On further thought, I think this would need to be enabled on a white-list basis for crates (or crate trees, when the nested crates feature is implemented. I have a bunch of utility crates that allow be to group tracks in a way that is not useful for a global database (like "tracks for <friend>", or "broken files", or "recommended by <blah>"). These would need to be excluded. With nested crates, it would make sense to have the ability to include all crates in a tree (e.g. grenre:* or mood:*).

Some of those crates might be useful for me to keep and sync to a web service, but only if the service allowed private tags as well as public tags. I'll submit a feature request to musicbrainz for that, although I wouldn't be surprised if they consider it out of scope.

[naught101 (naught101)]

Ah, the private crates could be stored as private collections on musicbrainz, which would make a lot of sense.

[Swiftb0y (swiftb0y)]

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