Project roadmap?

Awesome. I do think this would be an awesome thing to collaborate on. In particular, if we can get AURA to a state where it fulfills that need for a higher-quality, open standard for building this sort of tool, hopefully we can all save ourselves a lot of work! We can build servers, clients, and even “translators” to existing/proprietary APIs independently and interchangeably. It need not necessarily be under the “beets umbrella”—as long as beets has a way to speak the right protocols, we can let a thousand flowers bloom as independent, interoperable projects.

I like these ideas for generally making beets friendlier and more foolproof. I think it would be great to divide these kinds of goals into two categories: core improvements that are undebatable improvements everyone would want (e.g., add an option to move to trash instead of deleting), and a “higher-level” wrapper for novices that might amount to a different kind of interface (e.g., requiring no prompts by default). The latter might be best to explore in the context of extensible importer UIs—the sort of importer sibling of AURA, which would let anyone build their own interface that harnesses beets’s autotagging power.

Hello! I’ve started working on an AURA plugin for beets using flask and taking inspiration from the existing web plugin. Any feedback on what I’ve done so far would be cool.

I haven’t added anything for a couple months (trying to get another project finished), but want to get back onto it soon.

1 Like

Cool! It would be great to finish the spec because until then any implementations of it are at risk of being incomplete / out of date / incompatible. I’d love to help get to 1.0 on the AURA spec so that projects like this can really run with it. I will try to find some time to share more thoughts about how to tackle some of the remaining problems.


Yes getting to 1.0 would be great. I think it’s not too far off, with the main areas for improvement being:

  • filtering
  • sorting
  • images
  • authentication
  • standard errors

I saw your github issues for searching, sorting and compound filters, so I think you’ve been thinking about it harder than me :slight_smile:

1 Like

Haha on that particular day, yes I probably was. I’m still noodling on the filtering problem…

1 Like

Is there a plan for when 1.5.0 will be released?

One thing I think would be helpful especially for newcomers would be to have some coverarts from the get-go. I think many people identify their albums by their covers (maybe I’m old-fashioned). So when there is a proposal for an album, some way to display the coverart next to it (as soon as it exists, but for most there is either one on MB or one on amazon/discogs). I know the terminal has a possibility of displaying images, as ranger does it.
Another point that I think is making things complicated for newbies is the distinction MB makes between releases and release groups. In most cases a release group contains different editions of the same release and having to choose between them could be seen as needlessly complicated, also they end up having the same name and tracklist in many cases, the only difference being the year, catalognumber, barcode (things a newcomer wouldn’t necessary care about) and the coverart (here we are again). Also, duplicates can appear because one imports twice the same stuff and it ends up in the same release group but not the same release, duplicates which are tricky to find if you don’t know what you’re doing. I don’t say there is no point in having both release groups and releases, but I believe it complicates matters, and maybe suggestions should propose release groups and let then choose the exact release in the release group.
Different releases in a release group can have different tracklists because one in on 4 vinyls and the other on 2 CDs but the actual recordings and their ordering are the same.

Not sure if this is also planned, but I think it’s worth dropping support for python 3.4 as well with this release since it is no longer supported upstream by python.

Yeah, I think that’s right.

1 Like

It’s worth noting that Debian has deprecated mutagen-1.40.0 in testing so beets is currently unusable there since that was the last version that supported python 2.

Ah, one idea I have that would make beets a lot more useful: If I could use all the tags beets provides to be displayed somewhere when I play my music, or even be able to sort by them, that would be great! I’m using Clementine as a music player, but for example it doesn’t allow to sort by albumartist_sort, just by albumartist and when I play it I would love to be able to see all these tags somewhere (especially if the performers are getting fetched by beets). I don’t think that this is something that is to be done on beets’ side, but to try to find come compatibility with other music library systems that actually play the music could be great (or get some crude front-end to plug beets into some music player). As far as I get it, all these libraries have some SQL library where they store all the data about the recordings they have, making them communicate somehow could be a good idea.

Are there any particular bugs/features that are blocking the 1.5.0 release? I’d like to help with them if I can. +1 for Github Projects; it could be helpful for categorizing the “we want this done for the 1.5.0 release” and “this would be cool at some point” type issues.

This may be outside the intended scope of this thread (and maybe even the Beets project in general) but my focus is on the media player UI - and since Beets has a web UI, why not make it awesome?

I’d like to see something that looks more like a sophisticated, glossy magazine, put together by very talented graphic artists - rather than a “media player app”. If I was put in charge of designing a new UI, it would look something like this…

(This may look somewhat familiar to anyone who has used Roon - which is very, very cool and beautiful but rather pricey. This is my take on the Roon UI, tweaked for cleanliness and increased functionality.)
The screen would be split (approximately) in half, with the main “control bar” dividing the two halves of the screen. The control bar could be dragged up or down to change the size of the upper/lower sections.

The upper section would consist of a nice piece of fan art as the background - swipe left/right to change the image. (Clickable arrows would be displayed if you’re on a traditional computer but I’ll focus on a tablet interface for the rest of this.) Below that, the artist bio - again, swipe left/right to switch to a different bit of text (an interview, artist overview, etc.)

The lower section, from left to right, would have a “feature text” section about the album. Swipe up/down to see different text about the album. In the center, a nice shot of the album cover, and to the right of that, a track list (with or without track duration times - a user preference). Tap any track for a small popup to start playing the track (with buttons for selecting the source - a disc icon if the track is in the library, Pandora, Spotify, Tidal, iTunes, etc.), favorite it, add it to the queue, add it to a playlist, etc. Swipe left/right on the bottom section to switch from album info to album personnel (including producer and studio info), the artist’s discography, awards, related artists, and a genre tag cloud.

A lot of this content would have to be contributed by the user community. The thought bubble in the control bar is for activating the social media controls, allowing the user community to add images, text (with attribution), user reviews, etc. Once the thought bubble is tapped/clicked, each of the elements on the screen would have a little overlay - thumbs up if you like it, thumbs down if you don’t, and a flag in case some moron tags a Miles Davis album with the Classic Rock genre. (It’s bound to happen and I suggest a three strikes rule – if it’s flagged by 3 separate users, it goes away without moderation.) Music lovers tend to be passionate about their music, so I think people would be quick to contribute a variety of content – including information regarding non-commercial recordings. Over time, I’m confident that this would grow into something pretty robust and extraordinary.

This is a really cool concept, @DonnieFontaine! With the revitalized effort to implement the new AURA protocol for beets:

It seems like a great time to be building new web-based frontends. The nice thing about the new plugin is that it doesn’t bake in any particular client—so it should be conceptually easy to provide new ones like this separately. Maybe it’s worth looking into making this the first web-based AURA client?

1 Like

Thanks, Adrian! Seems like the best (and simplest) way to accomplish this is to define the building blocks of the web UI (and the individual bits of content that each block can contain). To the extent that we want to allow community contributions (reviews, ratings, images, copied/pasted magazine/external website articles, interviews, reviews, etc. — AND community ratings for each bit of community contributed content) we’ll probably need to add 1 or more tables and numerous fields to the underlying database.

From there, it should be just a matter of creating themes so that users can choose something other than the default - or even create their own if they’ve got CSS/JavaScript/python skills. And from there we need to figure out the best way to get from web UI to iOS/Android/Roku/FireTV/Apple TV app.

I’m stoked that you like the idea and I’m ready to get started but I’ve only recently discovered Beets so I haven’t participated in any of the dev efforts. Nor am I familiar with how the dev community operates. What should be the next step?

1 Like

I’d split out this web UI to its own thread. People might skip over this thread because they’ve already read the first few posts.

Looks cool! I like the waveform play bar. Foobar2000 with very minimal customization has been my player of choice for a decade, but the closed-source and somewhat obtuse customization options make it imperfect. I hope this works out.

1 Like

Hi there, there is android app available by the name beetsplayer

It’s fairly naive in design as i’m incrementally working upon integrating as much as i can, but it certainly works well for most of my use cases.

Here is the repo for the player for setting up SSL and reverse proxy,


Wow; this is super awesome!!

I wonder if there is any new about some alternative importer interfaces, especially web interfaces. I know about Beetwerk, which basically is a command line web interface dedicated for beet. Is there anything ?