I wonder whether I can also query for other things, like, e.g.:
Artists (example: "show me all artists that are the conductor in any of my tracks and that start with ‘a’ ")
Composers (example: “show me all composers of any of my tracks that lived in the 18th century”)
In a second query, I could then query for albums / tracks with those artists / composers.
Is this currently possible with beets? If yes, how would I do this? If no, do you think that this is more likely to be a missing feature that people would be happy to have, or rather something that is out of scope of what beets is intended for?
It’s a very reasonable question and an equally reasonable thing to want to do, but it’s not something that beets supports. And not because of any philosophical reason—just because the implementation would be deceptively difficult!
Starting with items and albums, it’s interesting to ask why it’s possible it query these separately. Why is there an --album flag to most commands, but not an --artist one? The reason is that items and albums have an explicit representation in the beets database. There are actual rows in SQLite tables for each album and each item.
Of course we need to have rows for every item, but early in beets’s history (but not in the first version!) we also added explicit albums to the database. Before this, it was still possible to query “albums” by looking for all the items whose $album field had the same name. The problem we solved at the time was that there were lots of albums with the same title and artist (looking at you, Weezer). So we needed some way to distinguish them, especially to make them not go into the same filesystem directory. Beets got much more complex when we added explicit albums—now every item can (optionally) be associated with an album structure; albums have their own metadata that partially overlaps with items; and sometimes it gets confusing because you don’t always know what’s associated with an item and what is associated with its album.
Anyway, we could, in principle, do the same thing with artists and composers and everything else! The problem is just that it would create another level of complexity on top of the already-complex interaction between items and albums.
In the limit, the beets database would become a mirror of the MusicBrainz database—or perhaps just a subset of it that’s relevant to your own music collection. I think the moral of the story here is that, if you’re interested in answering questions like “which composers lived in the 18th century?”, you’re best off querying MusicBrainz directly and then filtering the results to be relevant to your own music collection.
Thanks, @adrian, for this really good to read reply!
I completely see the point regarding significantly increased complexity when adding more entities than tracks and albums.
You say that, in the limit, the beets database would become a mirror of the subset of the MusicBrainz database relevant to one’s own music collection. I agree. I think that, from what I got from the beets docs, beets (plus plugins) is already going into that direction, but without keeping the MusicBrainz data structure but instead flattening the MusicBrainz data into the rows for tracks and albums in the beets database. (Take, e.g., the ParentWork plugin, which takes the MusicBrainz relation to the parent work and copies the parent work information into the beets row for the corresponding track.)
I wonder whether it is possible to integrate the data into the beets database in a non-flattened form using one or more plugins - and I will read the beets docs some more to find out
