Category: General

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: musicbrainz, road map, vacation

As promised, here and some answers to most common questions:

• “Is there a contact at MusicDNS?” — Yes, use this link. A contact us page will be added soon.
• “libofa doesn’t build on OS X” — the first rev, 0.9.1 with the first patch included will be posted later today. Stay tuned — this should also build on OS X.
• “Are there plans to implement the Creative Commons sampling license options?” — Yes. I’ll add that and the Public Domain ‘license’ later today.
• “What does PUID stand for?” — They are Portable Unique Identifiers.
• “How do I get a PUID into the fingerprinting system?” — Right now you need to use the MusicIP Mixer (free) to analyze the track to get a PUID generated for any tracks that do not have PUIDs yet. PUIDs should become visible to MusicBrainz within 24 hours. This is far from perfect, but all we could get done for now. We’ll improve this before too long.
• “It’s nice that we have an alternative to TRM now, but I’m disappointed that this is a one-way relationship.” — Thats not quite accurate. Our partnership is focused on creating a balanced relationship, but there is a limit to what we were able to accomplish for this initial release. We’ll be working on improving this soon.
• “When will a version for OS X be available?” — Hard to say. One of the underlying toolkits still has a number of bugs that prevent us from releasing it on the Mac. Hopefully I’ll have some time to look into this soon.
• “Maybe an obvious question (or answer), but does this excellent news mean I’ll have to re-tag all my files?” — No. The fingerprints are only used to resolve the proper metadata. Once the tagger identifies the right track, it writes MusicBrainz ids to the files, which have not changed.
• “Since the accoustic fingerprint is opensource is there a role that MusicIP NEEDS to play?” — There is a server component to this as well but that is not open source. Without the server, the client portion is less than useful.
• “How well does it compared to TRM?” — It should have a lot fewer duplicates and collisions than TRM. But really, time will tell. Let’s start using it and we’ll see how well it works. I do know that the PUIDs won’t have to be trimmed to keep the service alive, so this is already a drastic improvement.

Let me know if there are more questions!

(Update: The support link is now fixed.)

Technorati Tags: acoustic fingerprinting, musicbrainz