Future directions for MusicBrainz

I’ve returned from my much needed vacation in Iceland and now I am ready to get back to working on MusicBrainz. While I was gone, a few shouting matches and arguments over what MusicBrainz should be in the future erupted, so its clear that its high time to give a general update on how MusicBrainz … Continue reading “Future directions for MusicBrainz”

I’ve returned from my much needed vacation in Iceland and now I am ready to get back to working on MusicBrainz. While I was gone, a few shouting matches and arguments over what MusicBrainz should be in the future erupted, so its clear that its high time to give a general update on how MusicBrainz is doing and where we’re headed in the future.

First, lets review what we’ve accomplished in the past 4 months: 1) we have more server capacity in a new home with better bandwidth 2) A new fingerprinting system with a new partner 3) A new search engine 4) A new web service. If you would’ve asked me how long all these would take to turn into a reality 4 months ago, I would’ve told you 6 – 8 months time. So, we’ve made great strides this year alone!

Now that we’ve knocked off a number of serious problems and improved the overall service, the community looks towards the next set of problems that we need to tackle. At first glance, it may seem that all we have are problems and that there are tons of people who are constantly complaining that MusicBrainz is not this or that. Personally, I think this is interesting and not alarming — these “problems” show that people care about the project. None of these problems put MusicBrainz in danger of vanishing tomorrow. I think the biggest problem right now is that the future for the project is not clear now that we’ve implemented many large improvements over the last few months. This blog post and more to follow next week should hopefully address these questions from a high level perspective:

Q: Is MusicBrainz a service aimed at people who wish to clean up (tag) their music collection or is the goal to create a music encyclopedia?

A: Yes! The long term goal of MusicBrainz is to capture all relevant knowledge about music and create a comprehensive music encyclopedia. The goal is also to create killer tagging applications that take this wealth of knowledge and let users apply it to their own music collections.

Thus, when people edit the database, the focus should be to capture the information as accurately as possible, respecting artist intent and trying to work with our guidelines when artist intent is not clear. The focus should not be to capture information such that music collections can get tagged cleanly with the data!

That is not to say that we don’t care about tagger users — on the contrary! Tagger users who make an occasional $10 donation are the people who pay our bills — they keep the servers on and allow the foundation to have an official place of business!

To make both the encyclopedia minded users and tagger users happy in one giant sandbox, I’d like to present a rough road-map where MusicBrainz will be headed in the near future:

Next server update

Server update with UI improvements, nomenclature (album -> release, moderate -> edit) fixes, album editor, XHTML support and more. This is likely to happen mid to end of May and driven by the hard efforts of Keschte.

Picard user interface improvements

Picard users currently fall into two categories — those who hate it and those who love it. If you don’t like drag and drop and you focus mainly on tracks, you are not likely to enjoy Picard. The user interface improvements presented here will be implemented so that the UI can be used without drag and drop and either in a track or album oriented mode. Which exact model we’ll pursue is unclear at this point, but it will likely be one of the variants proposed there. The overall goal is to make the old MusicBrainz Tagger irrelevant as we prepare to put TRM out to pasture — all tagger users should be happy with Picard.

TaggerScript in Picard

TaggerScript is the nick name we’ve given a much discussed, but not yet specified feature that will allow tagger users more control over how their music collection gets organized. The idea is that with TaggerScript, users will be able to extract information from AdvancedRelationships as well as the usual pieces of release data and then shove that data into the tags/filenames of their collection with a lot more flexibility and control that we currently allow. TaggerScript will allow tagger oriented users to extract the data they care about from the encyclopedia oriented database.

Next generation schema

This is the much discussed and much anticipated major upgrade to the MusicBrainz database. The idea behind this is to allow us to handle releases, classical music and many other facets of music metadata much better than we can today. At Summit #7 we worked for 14 hours to create this new schema and its a great start for defining the goal for a more powerful version of MusicBrainz. However, simply because this new schema exists, it does not mean that we will implement this as it currently stands on the wiki page. We need to spend a lot more time thinking about this — but this first version serves as a great stepping stone for eventually getting to our goal.

The most serious problem with this schema is that it will take a huge amount of effort for us implement it. Essentially, it amounts to rewriting most of MusicBrainz. Think one person working on it full time for 12 months — maybe even 24 months. There are a number of problems with this:

  1. If the dev team went away for 12 – 24 months to work on the next version of MusicBrainz, the current users would lose interest in MB due to the lack of progress. If the end-users cannot witness progress being made, they lose interest. So, devs cannot just work on the next gen schema, they also have to go back and fix other issues that arise. That pushes things out even further. 36 months? Ugh.
  2. MusicBrainz is still being coded by volunteers, and volunteers work on personal motivation. If a person is not motivated to work on a huge project for months on end without pay, they will lose interest. Moving from our current schema to the next schema is going to be rough work and a lot of it. I’m sure we don’t have enough volunteers to make this happen!
  3. For large projects like these, when you finally get done with the project it may no longer be what you need when its finished. It will be what you needed 12 – 24 months ago, not what you need today.

So, then how to we proceed with this mess? There are a number of options on how to proceed — we should attempt to work on all of these approaches at the same time:

  1. Work to sell more data licenses. This non-trivial income will then allow us to hire developers to work on the MB server. Paid people can be properly motivated to work on longer projects.
  2. Work to figure out how to break the schema upgrade into 3-4 smaller upgrades, each taking a 2-3 months to complete, thus making visible progress on a continual basis. [ insert wild hand waving here — I have no clue how to accomplish this ]
  3. Possibly create more tools, abstraction layers or a new moderation system that will overall reduce the total amount work needed to move to a new schema. Here too, we’re brainstorming about how to proceed — nothing concrete has emerged yet.

As you may have guessed, we’re not certain on how to proceed with this new schema — we have a lot to think about and a lot of discussions to hold. Certain is that we will not see this next generation schema come to fruition this year. If you’re holding your breath on the new schema and you cannot deal with MusicBrainz’ shortcomings for at least another year, you may want to find another approach to satisfy your music metadata cravings.

One thing I do know for sure is that I am excited to continue working on MusicBrainz. We’ve accomplished a lot in the last few months and we’re not about to stop working hard on this project.

Onward ho!

Technorati Tags: , ,

9 thoughts on “Future directions for MusicBrainz”

  1. Bravo, thanks for the update! Glad you had a good vacation and welcome back!

    Oh, you’re not running me off that easily! Next year? Hmm, I give you to 2010. 😉

    Nyght aka Beth

  2. ruaok, just for telling you. I’d wait 3 years if I had to. I have great faith in the MusicBrainz project. in general and in spesific.

    ❤ 🙂

  3. Wow that was a detailed update. Tahnks a lot!

    I hope the short term goals (Keschte aka G0llum’s Server Cleanup, Picard UI improvements, Tagger Script) will bring some more focus into the community.

    I think part of the difficulties of the last months were due to the fact, that it looked like Nadelnder Bambus was just around the corner, would be the solution to all our problems, but was not clearly specified at all. So everyone went on talking about how they thought MusicBrainz should be — even people who have no clue about how the inner workings of MB look like.

    To make a schema change is not the problem. The problem is that there is a replication system attached to the schema, a webservice, a search engine, clients that depend on the schema, and most complicated of all: the moderation system. Every tiny change to the schema entails dozens of changes in each of these subsystems (and I am sure I have forgotten at least one subsystem).

    User input that disregards all this complexity is not really helpful, and I can understand if the devs get annoyed by all these “Your schema sucks, please include this and that ASAP!” (and there are people who even leave out the “please”).

    Now with stuff like Tagger Script and the Picard UI things are different. This is a realm where user feedback can be much more focussed and helpful for the devs.

    I hope this will get the community back on track, so that I can start reading the users’ mailinglist again.

  4. A note from a user on the direction of picard and tagging. I have a very large collection and I would think that the beauty of MB would be allowing it to scan the whole collection, compare fingerprints and bring back the correct tags/data. This should in no way require to track tracks or album 1 at a time, ect…

  5. A musical encyclopedia is not of much use without tools that can cleanly use it.

    Since the taggers are the ones paying your bills according to your post, they should receive priority .

  6. I was wondering if the MusicBrainz community was aware of the libFooID – free acoustic fingerprinting library ( http://www.foosic.org/libfooid.php ). Sames as the trm and musicip’s solutions but COMPLETELY free, and OS without any restrictions held over the MusicBrainz community. I think it would be worthwhile to have any musicbrainz app calculate both fingerprints so that in the future if MusicIP were to pull support there would already be an established and ready to go fingerprint.

  7. QUOTE: “The focus should not be to capture information such that music collections can get tagged cleanly with the data!”

    Building a music encyclopaedia is all well and good, but we already have thousands of websites (including Wikipedia) where people can get *information*. I’ve always thought that the ability to rename files “accurately” was the Unique Selling Point of MBz. Picard is your jewel in the crown. It’s a Killer App.
    I’m looking forward to the new features it will have, and find it rather shocking that you seem to think that “clean data for tagging” is no longer the main priority.
    In fact, I’m now questioning why I bother to make 1000 edits a week, in an attempt to make the database more accurate or useful for the vast majority of users who use MBz *solely* for tagging.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.