Given that my elaborations are not making things more clear, I will try one last time to make things more clear. But before I go on, remember that there are bugs in the system right now. What I am going to explain is NOT how its currently working. If you observe behavior that is different from what I am saying, its BECAUSE THE SYSTEM ISN’T WORKING PROPERLY YET! If you’re confused and don’t understand, stop using Picard 0.7.0.

Music analysis vs fingerprinting:

There are two processes that MusicIP makes available. Fingerprinting and music analysis. Let’s touch on music analysis first — this is the process that takes a while (Yes, I know its slow. Yes, I know its going to take days to analyze your collection. Please stop telling me that!) The process of doing music analysis examines up to 10 minutes of a track and examines all sorts of things I know nothing about. All I know is that in order to generate a new PUID, you must analyze a track fully. This full data collection portion is what allows the MusicIP mixer to generate playlists of similar music. This is the secret sauce that makes MusicIP tick and thus this is not going to be open sourced, no matter how much we ask.

Fingerprinting is much smaller process — it only analyzes about 2 minutes of the track. You cannot generate a new PUID to insert into the database from the fingerprinting process. There is not enough information in this process. There is enough information to create a PUID that is suitable for doing an identification, but not for submission. This works a lot different than TRM — this system doesn’t create rampant amounts of useless fingerprints that will never be used.

Submitting PUID’s from Picard:

When the process works, you do a full music analysis on a track and the system generates a PUID for you within 24 hours. But this is not working right now, so Picard will not likely prompt you to submit PUIDs. This means the submit button stays greyed out.

Why can’t we have Picard generate PUIDs?

Because we don’t have that code. Please stop asking for ponies — we’re fresh out and you can’t have one. Telling us that this sucks won’t make it any better. Please keep your comments to constructive criticism.

I don’t understand — its not working as you say it should:

Did I mention that there are some bugs? If it doesn’t work for you, stop using it. We’ll fix it.

Rude comments:

“Reading up on good interface design would also be a suggestion Just google good user interface design” — Please tell me where your FREE software is so I can download it and insult your hard work. I’m sorry that this FREE program isn’t working for you.

There seem to be many questions about Picard at the moment and a lot of people who love the old tagger interface and are frustrated with Picard’s UI. So, let me address the feedback we’re getting from our users:

“MBTagger was perfect. Picard sucks.” — Ok, this feedback doesn’t help much, but we understand that you are frustrated. We’re working to improve Picard as we speak and the latest release is a beta release, so please bear with us.

“I don’t understand the Picard interface.” — We understand that there are some people who prefer to tag tracks, not albums. We also understand that the UI is not immediately intuitive. We have plans to fix this, and to allow Picard to be usable by people who prefer to tag tracks and those who prefer to tag albums. For our thoughts on this improved interface, check out this wiki page. For more documentation on how to actually use Picard, see HowToTagFilesWithPicard. And to calm down all the people who are threatening to leave the project if the old MBTagger goes away, we plan to improve the interface of Picard way before the old MBTagger stops working.

“Picard keeps crashing on me.” — It works for us, which is sucky since we can’t fix your crashes if it doesn’t crash for us. We’re actively soliciting feedback from people who can reproduce crashes. If you have a case where Picard crashes for you consistently and repeatably, please file a bug report.

“Picard screws up my files!” — First, check to make sure you’re writing the right version of id3v2 tags. Depending on what other programs you use, you may need to switch to version 2.3/2.4 or vice versa. We know about some incompatibilities between the MusicIP Mixer and Picard. We’re going to start working on these issues soon.

“How do I get PUID’s into MB?” — This answer has two parts. First, to create a new PUID for a file that MB doesn’t have a PUID for currently, you need to download and run the file through the MusicIP Mixer. (Yes, we know not everyone wants to use the Mixer application — for you we’re going to create stand-alone analyzer applications soon). Once a file goes through the MusicIP Mixer, in theory it should become available to the MusicDNS.org service (that MusicBrainz uses) within 24 hours. In practice, this is not happening yet. The MusicIP folks are working on this! Once the MusicDNS.org service has a PUID, you can re run the file through Picard and it should pick up the PUID and prompt you to submit the PUID to MB. Again, there may be bugs in the process — we’re working to iron out the bugs as we speak.

What can you do if you’re affected by these issues? Here is a quick check list for you:

No: Please stop using Picard 0.7.0 for the time being and go back to Picard 0.6.0 or the old MB Tagger. Then wait for a new release of Picard and see if your problems have improved.

Bottom line: If you’re frustrated by how things are working right now, go back to a non-beta release and give us more time to iron out these issues. We’re aware that you are frustrated and we’re working on it. But if people keep pestering us with the same issues over and over again, it only keeps us from fixing actual bugs.

“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.

This partnership with MusicIP promises to be beneficial for both MusicBrainz and MuiscIP. The rough overview of our new relationship looks like this:

MusicIP provides:

Free fingerprint lookup services for official MusicBrainz projects. The fingerprint services are entirely hosted by MusicIP, which removes the burden of hosting service that is only tangential to our mission.

Other projects that wish to integrate fingerprinting services into their applications will need to sign up with the MusicDNS service. This service is free for non-profit projects (musicdns.org), and price-tiered for commercial projects such that even small startups have access. For more details, please visit MusicDNS.org.

$10,000 held in escrow for MusicBrainz, plus contractual commitment to supply hardware resources should MusicIP exit the fingerprinting business. This is designed to allow us to continue the service should they decide to stop providing the service.

a 10% cut on all income earned from fingerprinting queries where MusicBrainz metadata is provided via the MusicDNS service.

800K acoustic fingerprint ids (PUIDs) that which are already loaded into our DB.

Travel, lodging and registration costs for myself to attend the SXSW

conference, where all of this is being announced and released.

Allow us to exhibit in the MusicIP booth at SXSW this week. Including displaying our logo!

MusicBrainz provides:

One free live data feed for MusicIP’s use.

The right for MusicIP to sub-license the MusicBrainz data to their customers as part of their product offering — at full list price. MusicIP takes no cut.

Community support of the Open Fingerprint Architecture library. Many of the exact details on where the source code will live still need to be worked out over the next few weeks.

As you can see, the deck is stacked much in our favor. MusicIP has gone above and beyond the call of duty to setup this relationship. We’re all very excited by this new partnership, since it extends our reach into the commercial realm and welcomes MusicIP into the open source world. We are also announcing a partnership with the Creative Commons where MusicBrainz will now be able to track Creative Commons licenses.

Due to all of this, there has been a lot of frantic development at MusicBrainz over the last 8 weeks. Moving to a new colocation facility, more bandwidth, more servers, a new web service and a new text search were all in preparation for today. As you may have noticed, the MusicBrainz service has been a little bit more spotty as we’ve worked hard to push out new features and move to the new colo. The good news is that we’ve brought more database servers online to help spread the load to more machines as people come to investigate our new version of the Picard Tagger. Hopefully the web site should still respond well even if the replicated servers are working hard to handle the new web service traffic for Picard 0.7.0. Once I return from SXSW, I’ll be focusing on getting the service stable, better documented and generally ready for the future.

Last, but certainly not least, I would like to thank Relatable for the use of their TRM fingerprint technology. Without Relatable MusicBrainz would’ve never been able to grow as fast as it has. I appreciate everything that Relatable has done for MusicBrainz, but MusicBrainz has simply outgrown TRM and it is time to move on. We will continue to provide the TRM service for another 6 months from today. If you have an application that uses TRM, please visit MusicDNS.org today to find out how you can migrate to this new fingerprinting service.

I bet there will be tons and tons of questions. I will batch up the questions and the post up follow up messages to try and respond to your questions.

We just updated the main server with the latest and greatest features:

New Features

Lucene Search – New search functions that uses a Lucene text search engine. See the text
search documentation for details on how to use this new search. However, indexes are currently only updated once a day, so the old search
feature is still available for when you need to find something that may have changed in the last day.

XMLWebservice – This new XML based web service drastically improves on the old RDF based web service by being more standards compliant and
having a much more granular control over what data is returned for each query. Read the documentation
how to use this new service. Please note that this is in BETA and the service is still subject to change!