Improve music discovery aspect of Beets

Help
1

I am a huge fan of Beets and what it can do to organize a music library. As someone who has a massive music library and uses several streaming services to keep track of and discover music, I consider myself a great example of someone who would benefit from Beets (and I have). However, having used Beets for some time, I feel that beets is missing out on a huge opportunity.

There are two distinct challenges that users face as they curate and manage their own music libraries: 1) organizing (including tagging, organizing, etc.) and 2) discovery (recommending music to play).

Beets is very good at organizing the library (tagging, sorting) and that is how it “acquires users.” However, I feel that beets is not very good at discovery and that is a massive missed opportunity that beets can easily address. Currently, users do not benefit much from beets after the initial organization, i.e., there is no ongoing use for beets once the initial library is organized. Thus, they are likely to move on to other tools to benefit from their well-organized library.

It seems to me that this is low-hanging fruit for beets since it already has most of the information. Here are a couple of things that Beets could do that would keep users engaged even after the initial sorting:

1. Transfer and sync playlists: There is a great bit of interest in services that sync playlists across services (e.g., https://soundiiz.com/, https://songshift.com/, https://freeyourmusic.com/, https://musconv.com/). This is not surprising given that many of these services are great tools to discover music or play music. The number of new tools that have come up in this area is not surprising. Beets could definitely contribute to this area. A simple tool to transfer/sync playlists between a few services would be a great addition. I personally use Plex and Spotify and both of them are already included in Beets. I cannot imagine this being a difficult feature to implement.

2. Generate smart(er) playlists: Beets already does this to some extent, but the current approach does not incorporate the popularity of tracks/albums. There are several services that provide popularity information - Spotify, LastFM, Plex user ratings, etc. Including this popularity information in the beets database will significantly improve discovery.

I am not a programmer and I am not sure if these features are beyond the scope of what the devs have in mind for Beets, so feel free to ignore all of these if it is not relevant.

3 Likes
2

‘Unix philosophy’ wants a program to do one thing and do it well. Beets is excellent for organisation. No need to bloat it with discovery functions.

3

First, briefly, re unix philosophy: Beets creates opportunities for other features. Whether those features are implemented in beets, a plugin, or in another program working in concert, I have no opinion. Calliope exists for now, as well as stuff like Confuse that got spun out of beets.

I honestly thought I wrote the OP and it was bumped.

I’ve written similar things, and have similar pain points and suggestions to you. (In the link, other people including adrian have their own ideas on a roadmap, circa May 2020 i.e. pre-1.5.0.)

I really go into detail at the link.

I have no idea what drives people to contribute to open source projects. My model is: some number of users are drawn to the project, and some percentage of them have the desire / expertise to contribute. There are probably additional variables like how constructive the community is when a new user makes a suggestion. But, this is getting complicated.

If I’m right, then evangelizing beets, and tweaking features to make them more useful to novices, would lead to more developers on the project. I understand beets more now, but when I started, I was just making documentation suggestions or finding obscure parts of the source code that didn’t make sense. Those suggestions didn’t take much knowledge of beets.

To put a finer point on it, I don’t care if beets acquires users. But I care a lot about how it acquires contributors. Code, docs, feedback, it’s all important, and beets doesn’t have enough right now. Acquiring users is probably the only way to acquire contributors for an open source project without some company paying contributors. (Ex. Google and Chromium, which is the base for Chrome)

It seems to me that this is low-hanging fruit for beets since it already has most of the information.

Indeed, most other tools for the job are going to stumble on the complexities of a music library. Only a few tools like beets, Musicbrainz / Metabrainz, Picard are going to handle all the edge cases well.

The number of new tools that have come up in this area is not surprising.

All of your links have paid plans, so making a 100% free version would be good.

Generate smart(er) playlists:

Your suggestion is good but not ambitious enough! There’s a whole world out there for algorithmic playlists and I’m not aware of open source tools doing anything interesting with all this data! We have to walk before we run, and that’s where Calliope comes in. Extensions to that can perhaps get into the machine learning side of things.

Here is a more ambitious example, pretty easy in the field of statistics. But it’s purely conceptual for now. We may not have enough data and data processing to make it interesting. Ex. it could say that The Beach Boys and The Beatles are totally different by its algorithm, when they’re really quite similar.

The Metabrainz / ListenBrainz people are really interested in discovery and user-acquisition type things, so there is room to collaborate with them too. But I do see beets as a piece of it.

1 Like
4

Not sure if discovery should be considered as bloating. Beets touts itself as media library management system and not a tagging software (e.g., MusicBrainz Picard or mp3tag). In fact, beets already has several plugins that are along these lines.

That was exactly my thought. I feel that the level of engagement can be significantly improved if there is some value that users can derive on an ongoing basis and not leave the project once their library is organized. This would encourage more users to contribute to the project.

Indeed, I was only shooting for the low-hanging fruits (and quite honestly that would be a huge step already). Once we get the basic infrastructure in place, the sky is the limit.

5

Personally, I already find beets to be valuable on an ongoing basis. The query functions are super powerful. So even though my music is “initially organized” I often use the beets CLI to find what I’m looking for. I have not found any other OSS music program that offers things like regex queries across multiple fields, or custom metadata fields a la beets’s flexible attributes, in a well-engineered way backed by an open standard like SQLite3.

That said, I agree that more features would be nice for:

  1. Helping to sift through your library to create playlists suitable for specific scenarios; and
  2. Helping to identify music not part of your collection, but which matches a taste profile aligned with the music in the collection.

I do think (1) is more “in scope” for beets as it currently exists:

That sounds like something that would make a great beets plugin. There are already a couple of nice plugins for generating playlists (e.g. beets-goingrunning) , but there is plenty of room for more powerful playlist generation based on the information you highlight.

Regarding (2), there could potentially also be a plugin for that, although I agree with @RollingStar: whether it’s a beets-discovery plugin, or a completely separate tool, doesn’t seem that important to me. My architectural impulse would be to create a separate tool first, and then make a plugin for beets that links your beets library with the tool, so that you can do CLI queries.

I haven’t really looked at these playlist syncing services yet, but a fundamental issue is when the source service has a particular track but the destination service doesn’t. And that’s setting aside the issues with validating that track X on service A is actually the same track as track Y on service B. It’s not an easy problem to solve, engineering-wise.

It would help to nail down your requirements more precisely here. What do you want? Do you want to, for a given beets playlist (e.g. M3U file in a playlists folder, understood by the beets-playlist plugin), generate a playlist on some remote service like Spotify? Or go the other way: you have a Spotify playlist and want to generate an M3U file of those same tracks in your beets library? Either of these seems doable on a “best effort” basis, but both directions are likely to have “track misses” where the destination doesn’t have some of the source tracks. How do you want it to behave in that case?

1 Like
6

Actually, I think that Beets already has partly addressed that problem by manual intervention at the time of matching. The fundamental challenge here is the fuzzy matching that most of these services use. Such completely automated matching often misses a lot of tracks. Given the fact that beets already has identifiers or can be obtained (during the import process), the matching can be relatively better. I agree that it can never be a perfect process, but it will still be significant value addition.

I also agree with you that it can reside as an external plugin if that is a better approach. However, I feel that beets can significantly enhance the value proposition with a deeper integration with some of the popular services (most of them provide reasonably robust APIs).

7

Somewhat related, I would love to see an ability to persist matching against alternative input sources. For example, it’d be nice to do something like import to match an album against Spotify and select the correct match, but not replace the MusicBrainz metadata on the items in the db, only supplement it to later utilize the spotify command to generate playlists, for example. This would also ease later application of metadata from those sources to enhance but not replace what we have already, for things like popularity in a consistent way. Basically like mbsync but from every input that has stored the necessary metadata to match this item/album, not just MusicBrainz.

In other words, I’d like to see:

  • The other autotagger sources store their matching metadata in fields other than the mb_ ones
  • A command to add additional autotagger matches to items already in the db, without replacing existing ones
  • A general autotagger sync command to pull down metadata for already matched items from all autotagger sources

I realize this is slightly off-topic, but I think having that saved matching with various inputs, done with user input much like at import-time, would ease further interaction with such services to address mismatches in playlist generation.

3 Likes
8

Absolutely…it would be great to have identifiers for all the supported services (e.g., Spotify, Plex). That would significantly enhance matching and playlist generation/transfer.

9

Hi @kergoth,
I was thinking about the same or similar and started a discussion around it here: Saving additional online sources in DB ¡ Discussion #4220 ¡ beetbox/beets ¡ GitHub

I think saving additional sources that are not used for the initial tagging needs be taken care of in each and every source plugin, one after the other, so it’s a long road to go but in the end will be worth it.

I would love to look into it at some point, maybe starting wit the Discogs plugin but I can’t promise when…the future? ;-))

Are you a programmer by any chance and interested in getting this rolling with one of your favorite source plugins?

10

I implemented this with Spotify and Plex. I would like a couple more sources to be included…hopefully soon. My guess is you can extend the Discogs plugin to create a flexible attribute

The next thing on my list is being able to import playlists. For example, we provide a Spotify playlist URI, and beets can match the tracks and create a playlist to be used elsewhere (Plex, in my case).

1 Like
11

Yesterday I started working on a feature that, when musicbrainz is the source plugin, additionally fetches the link to the release on discogs if musicbrainz provides it, eg. this one: Release “Creatures” by Amon Tobin - MusicBrainz :slight_smile:

On some releases on musicbrainz I also see that it provides links to spotify, deezer and apple music. For example see the links here on the bottom right of the page: Release “Creatures EP” by Amon Tobin - MusicBrainz

This is the draft PR: Save Discogs Release ID via MusicBrainz by JOJ0 ¡ Pull Request #4474 ¡ beetbox/beets ¡ GitHub

1 Like
12

That is pretty epic. In fact, the url-rels has a lot of other useful information that can be extremely useful. For example, I would love to be able to convert artist id from MB_ID to Spotify_ID and so on.