Keeping The Beets with Adrian Sampson

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. When you're ready to launch your next project, you'll need somewhere to deploy it, so you should check out linode@podcastinit.com/linode

and get a $20 credit to try out their fast and reliable Linux virtual servers for running your app. And now you can deliver your work to your users even faster with the newly upgraded 200 gigabit network in all of their data centers. If you're tired of cobbling together your deployment pipeline, then it's time to try out GoCD, the open source continuous delivery platform built by the people at Thoughtworks who wrote the book about it. With Go CD, you get complete visibility into the life cycle of your software from 1 location.

To download it now, go to podcastinit.com/gocd.

Professional support and enterprise plug ins ins are available for added peace of mind. You can visit the site at podcastinit.com

to subscribe to the show, sign up for the newsletter, and read the show notes. And if you have any questions, comments or suggestions, I would love to hear them. Your host as usual is Tobias Macy. And today I'm interviewing Adrian Sampson about Beats, the Swiss Army knife for managing your music library. So, Adrian, could you start by introducing yourself?

Absolutely. My name is Adrian Sampson.

I

am the progenitor of Beats and I continue to work on maintaining it. There are so many other people involved now that I I can't claim to own Beats, but I'm happy to represent it on a podcast.

And do you remember how you first got introduced to Python?

I think so. I think I was in high school and friends were trying to get me to use

Python instead of, I guess, c plus plus was what I was using.

And I remember it seems,

I I remember being entirely put off by the white space significant syntax at the time because I was in high school and I didn't know better.

And

it was only through enough wearing down of people trying to get me to try it over and over again that I eventually found it and, embraced it, and it became like my programming language of choice for years to come.

And you mentioned that you're the initial creator of Beats. So I'm wondering if you can describe what your motivation was for creating it in the first place and what the project is and what it might be used for.

Yes. My original

intent with creating beats was to have kind of a, I suppose, a platform for doing interesting things with your music. Like, for example,

I had a collection of m p threes that I've gotten from various places that are ripped from CDs, borrowed from friends, this type of thing, and

I had no idea which of these were of an acceptable bit rate that I would actually wanna listen to, which of them have been, like, cobbled around from various sources, and I should definitely replace by buying new m p threes from Amazon or something. And I I realized I had no way of keeping track of this. I was essentially managing everything by hand.

So the original intent was to have a kind of general system

that I could keep my muted music tracked in 1 database

and then essentially do whatever I wanted with it. That I could apply title case correction, that I could find bad music in my library and root it out, that I could, you know, get the names of artists that were kind of hard to get right correct once and for all and make sure that they all showed up under 1 folder rather than just having this messy thing that I could nudge essentially by hand. I guess going back even earlier than that, I found myself spending, and I think a lot of people do this, spending a huge amount of time in Itunes manually correcting tags. Like, I found it kind of a a calming ritual to sit there and look over all my music and 1 by 1 make sure that all the

articles in the middle of a title are lowercased, for example. Make sure that the does and ands

are are all lowercase,

which sounds, I know, incredibly exciting.

And I I found myself, like, really getting a lot out of this that I I really liked,

sort of being intimately involved with my music and getting every last detail correct. But it occurred to me that there was no reason to be

essentially running a script manually to do this. And I I I wish for some sort of an abstraction to build on,

to apply all the kinds of changes that I wanted to do.

There's, like, a little bit of scriptability in Itunes, but I really wanted something that I could make my own. And when you were creating it, I'm assuming that the primary reason for using Python

to implement that is because of your affinity for it as a programming language. But was there anything else about python in particular that was

conducive to this type of project? And if you were to start it over today, do you think you would make the same choice of language?

Yeah. I think there's a couple of specific things that made it the right language.

1 was Python's built in SQLite library,

which sounds like a small thing but was incredibly huge. It's a really easy to use, well designed library for interacting with SQLite databases. I knew I wanted to use a SQLite database to track music. So using the SQLite 3 library was a really easy way to get started with a table with 2 tables. 1 that was just the

big list of all the tracks

on my system and 1 was a big list of all the albums that they were grouped together, and I could very easily get started without being a database expert. The second thing was an existing library for manipulating tags for multiple audio formats that's called mutagen that we still use to this day. It's a it's a really excellent battle tested

library for reading and writing, not just ID 3 tags on m p threes, but a whole wide range of different files.

And I don't know of any equivalent like mutagen in any other language.

So even if I were even if I didn't like Python, I'd still might pick Python because mutagen is so good. And so as you mentioned, 1 of the primary use cases for Beats is

to make sure that your music library

may has some sort of internal consistency,

whatever

the particular user might choose for enforcing.

And

just as a general overview of what a workflow would look like if I have

a large directory with a lot of subfolders and inconsistent naming conventions,

you know, there might be some random folders that just have a dumping of m p threes from multiple artists, multiple albums.

What would the workflow

look like for using Beats to to bring that into some form of consistent organizational hierarchy? Great question.

So the way that Beats works is it wants to kind of control your entire music library which means that it wants to have a directory that thinks of as where the clean Beats tracked music library lives. So the way that you usually do this is you'd set up beats, install it with pip,

do a little bit of configuration to get the file name structure exactly how you like. But you pick a new empty directory that will be the new clean music directory and you keep that separate from where your

current m p threes live. And then you run

a an importer command. So beats thinks of cleaning your tags and getting them organized not just as inactive moving files around but importing them from external unorganized world

into the clean organized beats world where file names are tracked by the database

and everything is vetted to be correct. So what you do is you after you're done configuring it, you run a beat in import command on the directory containing all your old music and then it goes through album by album

discovering

individual albums and matching them against the music brains database which contains high quality metadata for most music in the world and proposes corrections to you, And then you, the user, get to say, yes or no or you can manually correct the tags

and then when you're done, beats will move them over into the,

into your cleaned music directory.

It does this in what what I think is a fairly involved way. It's a

it it it I I can't pretend that's a simple system to interact with when doing this importing because it sort of takes the philosophy that you want to be in complete control over exactly what happens to your music.

So it will tell you exactly what it's changing on every single field and exactly where it's moving files from 1 point to another.

So I can definitely see that as being quite a verbose output when you're actually

interacting with it. But as you said, the type of person who is most likely going to want to use this is the kind of person who wants to see all of that detail and make sure that nothing is going to be accidentally,

mangled and put into some format that they weren't intending.

Right. It's, it's I guess we have our target market, and it's music nerds who really care about every single detail.

And in terms of the internal architecture,

is there anything in particular that you've done as far as maybe using

asynchronous tasks or multi threading to allow for

speeding up the overall processing speed because of the fact that it's so IO intensive with moving those files around and,

manipulating the metadata?

And how has that overall architecture evolved from the time that you first began working on it? Yes. That is a good point. The original version of Beats was not multi threaded

and this is is maybe 1 of the biggest architectural changes that we made is after the first version. To be specific, here is the problem with the original version of Beats as I first made it. It would

read 1 album. It would try to it would communicate with the music brain servers to match it with a amount of metadata,

and then it would wanna interact with you to confirm those changes. So it would, show you the proposed changes, then it would ask you to accept or reject them, and you'd be sitting at a command line prompt ready to say yes or no and Beats would be completely stuck. Beats wouldn't be doing anything else in the background.

And and, of course, it'd be much better if you could be, you know, off making a cup of coffee or doing something else and just

have Beats run ahead and look at hundreds of albums into the future,

read those files from disk, go off to MusicBrainz,

do its own computation, and come up with proposals for you so that later when you come back and you're enjoying your cup of coffee, you can make a bunch of decisions in a row without waiting for beats to progress.

So that's what the major architectural change was to the importer, and we're still around with this same design today. And it works like a pipeline. So the idea is that there's you can

visualize every single album that is imported into Beats going through a series of stages from left to right and somewhere in the middle, there's interacting with the user. So albums can come in from the left, go through a few stages, communicating with music brains, reading files off the disk, doing beats as computation, and they sort of pile up in a stack right before the stage where they have to interact with the user

and that's this can all happen concurrently. So you can be waiting there for hours, say, and and that will continue to pile up and you can come along and interact with those

in in 1 big batch. And the reason I think this is nice, it it doesn't doesn't just make it faster end to end to deal with your albums. It does make it faster because you can overlap the communication with the music brains with the reading and writing on the disc, for example, but it changes entirely the way that you interact with beats. That is, you don't just have to sit there and wait for it to do its thing and then make 1 decision. Wait for it to do its thing and make 1 decision. Now kind of the recommended way of dealing with beats is to let it run for a really long time and then come and make all your decisions at once, which is completely different And it's thanks to this architectural change. Yeah. That definitely sounds like a much better user experience,

and I'm wondering if you've seen any increase

in usage because of those changes

of where before it maybe have been a much more dedicated type of person who would sit there and wait and interact stepwise,

with the program to ensure that every album is being processed whereas

by allowing somebody to just fire and forget for a while and then come back and do a batch operation

in a much shorter time period, it may make it more likely for a more average music user to actually put in that time investment, in

the

in the early days of Beats that just like this does not make sense to me. I can't see how anyone would ever use this tool. You know, like, I I I get being nerdy about your music, but I just can't imagine sitting here for hours and hours. Even so, we get people, like, even even though we try to explain this clearly in the documentation, we get people sending mailing list messages that that, believe it still works the old way. Essentially, they assume that you just have to sit there and wait for beats to do its thing, and we have to patiently explain it. So, of course, even after changing the architecture, people are still confused, which means that,

you know, it's it's really important we did make the change.

And 1 of the things

that

is

interesting too about the use case and target market of Beats is that, you know, maybe 5, 10 years ago, it was much more common for somebody to have a large library of m p threes because that was essentially the only way that you could have a quantity of music that you could listen to.

Whereas now with the prevalence of streaming services

and the,

increasing number of people who are using those types of services,

I'm wondering

what your thoughts are on

the need for managing a local digital music library as opposed to just tapping into 1 of those streaming services and taking advantage of the,

capabilities that those provide?

That is a really good question. This is actually something I think about a lot because Beats was made for an era where you manage your m p threes. And it seems like in some way, that era might be coming to an end when

people just don't wanna deal with the hassle of tracking their own files. And so

I can sort of see 2

ways forward for Beats, and it's gonna become obvious which of them I prefer. 1 of them is for Beats to sort of maintain its original intent that is for to essentially

to cater to people who still like to have 1 copy of their music on 1 machine

and to organize it meticulously and just listen to it there.

It's like pretty much the same as we've been doing for a couple of decades now. People who have been dedicatedly ripping their CDs or downloading MP threes from DRM free

sources and just maintaining their own music library in 1 place.

The the second is to embrace the fact that people do like

some advantages of streaming,

but to also acknowledge at the same time that we don't have to give up the idea of owning our own music to make that happen. I think it's pretty clear if you look at Spotify or Apple Music or any streaming service that there are trade offs that, like, there are just some music on these services that you can't get. You just have to have that music locally, especially if you have really obscure music. This is certainly true. Or sometimes you, you know, deals fall through and some music you used to have access to just suddenly disappears.

And so it I think there's there's a very real

trade off to be had that, like, that that streaming really does have convenience to people, but at the same time, it also has drawbacks,

which is not to say that everyone who uses streaming services is wrong, but I think that there will always be a certain segment of people who values

those things that you have to trade off when you go to a streaming service. That is if you have obscure music that you got from friends,

this kind of use case isn't well supported and will never be well supported

by a streaming service that's trying to cater to a,

to the mainstream

music listening appetite.

So for that reason, I think that the the second future for Beats that I'm excited about is trying to capture

some of the advantages of streaming services

while still

maintaining the vision of owning your own music. And this means, like, for example,

the idea of having music available on your phone, much more music available on your phone than you can actually possibly fit on your phone, for example, or

having recommendations offered to you based on your listening habits. These are things that Spotify and Apple Music offer you but aren't necessarily exclusive to Apple Music and Spotify. So I'm excited about a future for Beats where we can be a little bit more

independent

of our own machines.

Well, for example,

building streaming clients for Beats libraries that can stream across

network and try to give you sort of a a transparency of where your music files are exactly located

even if we maintain the vision for the kinds of people like me and other people who currently use Beats who really do want to have their hands on their music library and know that nobody else controls it. And 1 of the other aspects of digital music

that works to stymie people who want to have those large local libraries

is the concept of DRM, which you mentioned.

And

nowadays, it's becoming increasingly difficult to actually find anywhere to be able to purchase music in MP 3 or other format and be able to actually download it and own that music

unencumbered by DRM, whereas a lot of services that you can purchase the music, but then the only way that you can download it is via is via their proprietary client. And so they still control the way that you're able to organize and access that music.

Yeah. That's a great point. It yeah. The the it will, at some point, be harder and harder to get actual m p threes to play.

We've, at least for a long time, are going to have I'll always have the alternative to buy physical media and rip from there, but sometime that some some point in the future, that's going to go away too.

On the other hand, like, there are

certain areas of the Internet where this is certainly not changing. Like, if you look at bands whose music is on Bandcamp, for example, it's a really popular platform.

And they, they let you stream music in the browser there, but you can also download things

from Bandcamp. And this is also true. I noticed there are a lot of the larger indie labels out there that you, that you certainly, you can stream their music through Spotify or Apple Music or anything, but they also

offer online downloads of m p threes still. And especially for,

these fussier endier labels, they will,

they will even offer, like, really high quality lossless audio available on their website. So it strikes me that, like, for the moment at least, there's sort of a receding

number of, like, really popular services that are trying to give you,

to get just give you music for a download. But it is sort of distributing out into smaller services,

especially on the,

on the India side of things

that,

where you can still where this is still sort of a core part of their business. Yeah. And for artists who are either not necessarily

aiming

to gain mass distribution

or who are early in their career. There's also sites like the free music archive where they'll

upload their music largely

with a Creative Commons license so that it's easier for people to discover it and share it and not have to worry about issues associated with DRM.

Right. Right. And going back to Beats specifically, I'm wondering what you have found to be some of the most challenging aspects of building and maintaining it whether from the technical or from the social aspects?

Great. I have an answer for both of those, actually. From the technical aspect, there's 1 there's 1 thing that has been far and away

the largest source of bugs in beats and that is Unicode filenames.

There's nothing else that has been more of a headache than that.

As a a tiny bit of background and, like, I guess sometimes it it feels like even though Beats is supposed to be a music manager, it's sometimes a file manager,

which means that, like, everything it deals with is file names. And so we need to be extremely careful and make sure we have an extremely robust way of keeping track of file names. And this means that we get exposed to vagaries in file names across operating systems that I feel like most software does not have to deal with. In particular, there are not very many operating systems that can actually store

file names as unicode. Most file systems actually, especially on all unixes out there, store file names as a string of bytes which means they can be arbitrary bytes except for null bytes and a few other things. They can be any bytes

any bytes you like which means that if a

operating system tells you my my filenames are encoded with a certain encoding, say they're encoded with utf8 or they're encoded with latin1 or any other string encoding,

it might be lying to you. There there always might be files out there whose string of bytes is not a utf8

string or is not a latin 1 string despite what the operating system told you. So there is a there is a very real need to keep file names represented as bytes even though you think of them as text, even though you'd like to think of them as Unicode

if they have non ASCII characters in them. But the, the trouble arises when,

when users,

like, just sort of, like, expect that, expect that their file names are well formed but they find out that they don't obey the encodings,

which means that we, would for example, whenever we, like, print a file name to the console, we have to be very careful about first doing our best to try to decode the the the file name using the file system encoding

reported by the operating system even though it might be lying and then trying to re encode it into the console encoding

and, again, this this system will, will might have a very limited encoding there So we just have to, do our best and occasionally

question marks absolutely have to show up in place of special characters in file names just because of the way the user's system is configured

and this very much confuses users.

And this this, in some ways, this has been

1 of the more difficult things about moving to Python 3 also, whereas in Python 2,

file names were just strings of bytes. They were just blobs of bytes that you got from the operating system. In some ways, that was simpler than what Python 3 tries to do, which is tries to end the way you're getting our Unicode strings, but they in fact are representations of bytes that are pretending to be unicode. They have, certain signals in them that represent

undecodable bytes from the operating system,

which, adds another layer of complexity. So while I really loved moving to Python 3, there's lots of great features. I really like having unicode

everywhere except file names. This has actually been,

slightly more difficult in dealing with Python 3 than it was in Python 2.

As far as the the social aspect of things, I think that the by by far the most difficult thing for me has been

managing my own time, the way I allocate my time to the project. Since I started when I started, I was in college and I had, like, lots of free time for side projects.

It didn't seem that way at the time, but looking back, it did. And since then, I've gone on a personal trajectory of having less and less time.

I'm now an assistant professor in the computer science department at Cornell, which is a profession that is not known for giving you lots of time to pursue side projects, which means that it's basically all I can do to,

keep track of how the project is going and delegate work to other people who are involved in the project. But I myself can't invest huge amounts of time into adding new features,

And that's been really challenging because I feel like the

a a big ingredient in the success of Beats in any open source project is the attention of its creator. Yeah.

There's definitely

the ongoing issue in open source of figuring out what is the,

succession plan for any given project and

when should that plan be,

sort of defined and when should it be implemented? Because as you said, there's there's always this sliding scale of how much attention can be

afforded for a project that's not really providing any monetary remuneration.

So

yeah.

It's a hard problem and 1 that the society at large is still trying to solve.

It certainly is. Yeah. And and here's here's the thing is that there are so many people who use and enjoy developing Beats

that, like, there really is a large workforce out there that's willing to contribute and to write code, which is wonderful, and they really are extremely helpful to in managing the project. And it's and it's it's only because of them that the project has continued to make progress when I've been able to spend,

less attention on it. But on the other hand, there's 1 thing that it's really hard to get external collaborators to do, which is to have a global view of the entire project. That it's a sort of, like, notice that a bug filing bug being filed over here and a bug being filed over here,

are actually connected. And that's extremely important to the health of a project, but it's super hard for any for anyone to do if they're just paying attention to a certain piece of the system.

So that basically still falls to me despite the the amount of energy that's going on in different pieces individual pieces of beats.

Yeah. Being able to promote somebody from within the community is difficult because of that need for having the overarching vision for the project. Because as you said, it's easy to identify. There's an issue here. I can fix this issue, but

how does this issue play into the overall direction that the project wants to be taken in, particularly given what you were saying about wanting to

expand the scope of what Beats can be used for into this hybrid model of being able to

stream to multiple devices

and not just be responsible for managing files on a single machine?

Right. Exactly.

Going a bit deeper on the technical side,

1 of the things that I've always been a little curious about in terms of

managing audio files is how

the

acoustic fingerprinting

comes into play for being able to identify a track

within a service such as MusicBrainz

and differentiate it from something else even if the 2 files might be named the same thing and have the same file size, but they're actually 2 completely different pieces of music.

That's a great point. So what Beats uses for this, it has a it has a plugin for a service that's called, Akoust ID, which uses a fingerprinting algorithm called ChromaPrint,

which I did not develop.

So I'm I'm in awe of the original developer of in chroma print because it's a it's a really it's a piece of signal processing and computer science magic that I think is incredibly cool. But the rough idea as I understand it is that the acoustic fingerprinting is tries to take a very long music file and reduce the dimensionality to a relatively short vector of values

that can then be hashed in a way

such that the hash of 2 similar vectors,

is relatively close, which means that you could you can build a database that's able to look up,

vectors that are kind of close in a certain space according to a certain distance metric and return those. So similar sounding files will get put together.

So this is a this is a actually a service that's run independently of MusicBrainz,

and it relies on a lot of people analyzing their music collection.

1st tagging it with MusicBrainz so that every track has a MusicBrainz ID and then also analyzing it with acoustic ID with chroma print and then uploading to the acoustic ID server both the fingerprint and the music brains ID and then it that that server's job, the acoustic d server's job, is just to associate

a similar cluster

of chroma print fingerprints

with a MusicBrainz ID and this just because a lot of people have volunteered their,

their music libraries and their computing power to do this has built up a an extremely large catalog of these fingerprints so most music can be identified this way. It's on the music brain service. It's really quite remarkable.

But another thing that I append it that I think is interesting is that most of the time, Beats doesn't actually need fingerprints

to do matching. This is an optional feature, and it turns out that metadata based matching where even if you have really bad titles and artists and album names on your music, it it turns out it's pretty easy to, to using fuzzy string matching to try to guess what album you have, and so it only turns out to be necessary to use this incredible fingerprinting technology when you have, like, extremely bad or totally missing metadata.

So it's it's nice to be able to turn that off and, rely on, incomplete metadata at first. Yeah. I imagine that drastically speeds up the overall processing time for a first pass through a music library by not having to do that computational intensive work of creating that fingerprint and matching it against the database.

Absolutely. Yes. Right. So my my general recommendation, and I put this in the documentation too, is that people, if they try to use Beats, they try analyzing their music even if it seems crazy, they try analyzing your music without fingerprinting first because it is extremely expensive to turn that on,

and then only if they run into trouble then turn on fingerprinting.

And when I was doing some of the research to get ready for this conversation,

I noticed that there are a number of other projects that use beats as 1 of the components of

the library management and most of these are more GUI oriented. So I'm wondering if you can talk a bit about some of the more interesting use cases for Beats that you have seen beyond just the typical workflow

of using it via the command line.

That's a good question. So I'm actually not terribly aware of what people are doing with, GUIs to Beats. There's a few of them that I think are really cool. Like, someone recently showed me, like, an Android,

single page web web app thing that interacted with Beats over the network that I thought was

really neat. But for just but just because for my own personal use, I am so invested in just interacting with it through the command line. I'm I'm actually not terribly aware of all the GUIs that people have created. Adversity, what was the 1 that you saw that was the most popular?

I don't remember specifically what the products were. I just know that when I was,

searching around for information about Beats that there were a few

links that appeared to use Beats as 1 of the components of a larger overall project.

Oh, cool. Yeah. Great. There's

I think my favorite example of this is there's there's a a handful of these, the streaming oriented things that uses Beats built in web server plug in. Able to connect to that over a network and then display an interface.

In the the general category of, like, cool things I have seen done done with Beats, 1 really weird thing that someone did a while back was to build a virtual file system to interact with your music, which meant that you could keep your files physically on disk in 1 organization and, like, view them separately

in a different,

in a in a virtual files listen under a different organization.

So you get to, like, you you could, for example, organize your music both by artist and by album title, let's say, and in 1 giant,

directory listed by,

by the title of the track. And you wouldn't have 3 copies of your music. Those would just be virtual views onto the same,

underlying storage. I thought that was, really ridiculous, but also really cool.

This is not particularly technical, but another really cool use of Beats that I heard about was when a, a college radio station was using

Beats to organize their, music collection for playing on the radio, which seems like a perfect use case because you have a a totally massive collection of music for a radio station and need to call up individual tracks really quickly. Both of those definitely sound very useful. I can particularly see with the virtual file system the appeal of

being able to,

slice into your music library along those different dimensions without having to shuffle all the files around to actually do those changes.

Because,

1 of the systems that I use for my music is I have a network file store that uses the, you know, universal plug and play or DLNA server for being able to view the music via these various metadata and sort it by artist or by album or by genre. And so

being able to do something similar at the file system level using Beats, I can see as being very useful. Yeah. Totally. And along those lines too, I'm wondering

if there are any other projects that you're aware of for managing your music library that you see as being similar

in direction to Beats

and how the Beats project compares to them as far as functionality

or capabilities?

Good question. So I think the closest

project that's worth mentioning, which is also a Python project,

is the MusicBrainzPicard

tagger.

MusicBrainz,

has this open source tagger that is it's really great. It's been around for a really long time. It's a QT based GUI for tagging your music. It's kind of like the,

the flagship tagging tool for the music brains database,

and it works really well. I think that the main differences with Beats are obviously that it's a GUI app instead of a of a command line program. But I think that the the I guess that the the main architectural difference is that Beats actually tries to catalog the music. It's sort of a a library manager in addition to just a tagger whereas,

whereas

you can kind of use the card as a library manager, but it really wants to just, tag your music, move it around, and call it done. And I think that also as a result of being command line oriented, I think Beats has a greater focus on being automated whereas Picard really wants you to be,

to be involved in, for example, grouping together,

your music from flat files into albums and then tagging those albums and then moving them. Each of those is separate stuff you kind of need to interact with.

In Beats, we try to automate everything except for the actual decisions of what happens to your music, and we just ask you for consent

instead of of having you take direct action to move your music around. I think that that the original the, like, the the the closest comparison to, like, Beats as a music manager is actually iTunes still, which is a piece of software that literally no 1 likes anymore. But it used to be kind of the best tool that there was out there for,

for, like, keeping your music organized in a consistent file system structure.

And, well,

nobody really likes using Itunes. I still see it as a sort of operation for having, like, a catalog of your music that,

that where the tool owns a directory and keeps track of all your music within that directory and is responsible for the files, and you don't move around the files yourself. You give over control to a higher level database.

And you mentioned that 1 of the overall

design features that you're interested in is that hybrid approach for,

bringing Beats more into the streaming era. But are there any other features or new functionality that you have planned for the future of Beats or that you would like to see contributed by users of the project?

Sure. Yeah. Well, 1 1 thing that I think is relatively near term is that some people got around to contributing a kind of overhaul to the command line interface, so that what the terminal interface looks like to the importer to Beats. It's kind of its main user facing feature where it walks through your music and tries to tag it.

It is because it's gained so much information over the years, it's kind of visually cluttered and confusing.

And to be able to propose that a great set of changes and have actually started implementing a great set of changes to to redesign how it looks in the terminal,

so that things are sort of more logically laid out and easier to navigate.

And, this project is about halfway done, and I would really appreciate anyone's help, bringing that to completion. As far as the toward the grander vision of streaming and, like, multi device,

systems,

the

the direction that I could really use some help with is,

this effort that I started a while back to,

to define a protocol for interacting with your music.

You mentioned DLNA or UPnP

a a little bit ago.

The essential idea behind this new protocol is something that is something that fulfills a similar role to something like that. Like, it's a it's a way for clients to talk to servers that control music libraries,

but should be more extensible by Beats and Beats like tools for communicating between where your music lives and where you wanna play it. And that project is called ARRA. It stands for the ARRA Universal

REST API, I think. It's sort of a backronym.

But the idea is to define an API that will be in common between Beats and other projects that need to manage your music in different ways. I would love to have help

fleshing out that API and building clients and servers and intermediate utilities

for,

for moving music across the network.

And are there any other aspects

of the Beats project

or media management

or music libraries in general that we didn't discuss yet that you think we should talk about? You know, nothing comes to mind. I think we've covered basically everything.

So for anybody who wants to follow the work that you're up to and get in touch, I'll have you add your preferred contact information to the show notes. And so with that, I'll move us on into the picks.

And since this conversation has been so heavily focused towards music and everything that goes along with it, I'm going to choose a few different

musical groups and pieces of music. And so the first is Mozart's Requiem, which is an excellent

classical piece that's very well written, well performed,

very atmospheric and powerful, and I've enjoyed it for a long time. So if you have not taken the time to listen to a performance of it whether recorded or otherwise, I definitely suggest that you do that. And moving in a different direction,

another group that I've enjoyed for a long time is Government Mule led by Warren Haynes who has been

making music for quite a long time, and Government Mule has been,

touring and recording for

well over a decade. I don't even know how long they've been at, but they do some great music and then taking it in a yet a third direction. Another group that I enjoy is Darkest Hour, which is more

hardcore metal but very technical and well executed.

So, yeah, I'm just going to leave it with that. And if you have any picks for us this week, Adrian? Great. Yes. I also have a thematic pick, but, it's a little roundabout. Do if I if I were to

reference the kitchen of plants called the spiralizer. Have you ever heard of this? I have, and I have 1 in my kitchen, actually. Great. Okay. So my recommendation is spiralizing

beets the vegetable.

A spiralizer for the uninitiated

is something that takes a takes a vegetable and kind of spins it around on a on, like, a series of knives and, and turns it into sort of long noodle like things. And you can spiralize all all manner of vegetables.

You get, like,

an entertaining and yet gluten free,

like, pasta

like substance.

I'm I'm not gluten free myself, but I still think it's a pretty cool thing to do. And I think that probably the most popular thing to spiralize is summer squash is zucchini.

But, spiralizing beets can be,

like,

just as good or better. If you like beets at all, or even if you don't like beets, I totally recommend trying it. So my pick is to spiralize your beets,

turn them into

beet noodles, and then, cover them in pesto. Pesto spiralized beets are my pick. That sounds delicious. Yeah. My my children are very fond of spiralized carrots. That was 1 of the ways that we got to them to actually start eating them. Perfect. Alright. Well, thank you for taking the time to join me today and talk about the work that you've done on beets.

It's a very interesting project and 1 that I'm going to have to unleash on my music library to bring it back to some semblance of organization.

It's been years in the making, so hopefully that'll speed things along. So thank you for that, and I hope you enjoy the rest of your day. Great. It was a real pleasure and enjoy using Beats if you do and please ask lots of questions on IRC.

The Python Podcast.init

Summary

Preface

Interview

Keep In Touch

Picks

Links

The Python Podcast.__init__