NGS Beta 1 is coming: Monday January 18

I’m pleased to announce that we’re almost ready to release beta 1 of the much anticipated Next Generation Schema. All of the important core functions are complete and we’ve even done a first round of sanity checking to make sure what what we release will be useful. We won’t have all of the features for NGS done — there will be some things that we simply won’t have finished by then.

But, this release is important since we feel that we want the community to help us take a look at NGS and help us flush out problems before we polish NGS for release.

We’ll have loads of more details and even some documentation for you by next monday. Stay tuned!

Picard 0.12

We have released the next version of MusicBrainz Picard. Picard 0.12 includes a lot of bug fixes and new features, including:

  • Support for ratings and folksonomy tags.
  • Live syntax checking for tagger script and naming strings.
  • Embed cover art into WMA and APEv2 tags.
  • New script functions $matchedtracks(), $initials(), $firstalphachar(), $truncate() and $firstwords()
  • New plugin extension point ui_init, allowing plugins to add new UI elements to the main window.
  • A new high quality application icon.
  • Support for originaldate tag. While this is not filled by Picard itself it can be used from within plugins such as the Original Release Date plugin.
  • Write ISRCs from MusicBrainz into tags.
  • CD drive dropdown selection on Linux.
  • Various small improvements to the UI.
  • Updated translations and the option to choose the user interface language.

A complete list of changes be found in NEWS.txt.

Picard 0.12 is available for download for Windows and Linux. The Mac OS X version will be released later, sorry for that. We are still in search for a long term maintainer of Picard on OS X.

Thanks to everybody who contributed to this release.

Web service users: What do you think of our current URL structure?

I’m about to finish writing the web service (version 1 & 2) for NGS, based on the work that Lukas started a few months ago. The NGS web service currently does not have a compete means of tweaking how much XML is returned for a given resource. Lukas wondered if we should keep our existing approach or start using a new approach that (and others) use.

Compare our current approach:

/ws/1/release-group/052c7adb-5e2d-3cf3-b303-6c2a7d3e5b1c/?type=xml&inc=releases (docs)

to the approach:

/2.0/?method=album.getinfo&artist=Cher&album=Believe (docs)

Should we keep our current resource focused URL structure or move to a method centric approach in our v2?

If you’re a fan of the old skool structure, please leave a comment and tell us what could be improved. What do you like about the web service? What do you hate?

For some background — as of the NGS release we will be making a lot of changes:

  • the old RDF web service will no longer work.
  • The old v1 XML interface will continue to work, but not optimally since we will be shoe-horning the spiffy new NGS XML into the old skool v1 XML. Concepts like artist-credits and works will not be available in the v1 compatibility interface.
  • The new v2 XML interface will expose all the NGS goodies like artist-credits and works.

Getting ready for our Next Generation Schema!

After many years of planning, anticipating and gathering resources, we’re finally tangibly close to our Next Generation Schema (NGS).

This blog post is intended as an official notification to everyone in our community and our customers who are using MusicBrainz services right now. Our next generation schema is drastic evolution for MusicBrainz — we’ve included many of the features that our customers and our community has asked for over the past few years. This means that if you’re using the MusicBrainz data right now, you will need to prepare your systems in order to be ready for the switchover when it comes in the fall. Please do not delay examining our new schema — this change is drastic change from our previous schema!

Our current plans are to enter beta testing of the new server on August 31. The exact release date is very much dependent on the results of our beta phase, but I hope to have the release within 60 days of entering beta.

The most important changes that you will need to consider/address:

  • No old (RDF) web service — the old RDF web service will no longer be supported as of NGS.
  • We will provide an XML v1 web service that is backward compatible to our current XML web service.
  • We will also provide an XML v2 web service that will expose new NGS concepts.
  • Postgres 8.3 will be required. Upgrading your old database will not be possible. You will be required to import the first post NGS data-dump in order to upgrade to NGS. Our provided upgrade script (see below) is very useful for testing purposes but not suited for upgrading deployed servers.
  • MBID changes — The MBIDs will be stable and maintained for artists, release-groups and tracks. All of the MBIDs for our current releases will also be kept, but we are changing what we are calling releases. Essentially all release events (with label, date, country and barcode information) will become releases each with their own MBID. This means that we’re adding a whole slew of new MBIDs for the releases that will not be assigned a legacy MBID.

NGS is documented on our wiki — please take some time to read up on our documentation! If you’d like to play with NGS now, follow these steps:

1. Download and install the 20090524 release according to these instructions. For going to NGS, installing a database only install is the perfect approach. Download and import an existing data set.

2. Download the NGS codebase with subversion.

3. Follow the install instructions. Instructions are included for how to migrate the 20090524 data to NGS — please note that the upgrade script may run for quite some time!

There are a lot of changes to the database from the current release! Please note that we’re done with the overall database design — I am not anticipating major changes past this point. However, I do anticipate a few smaller changes as we get closer to our goal. We will keep the schema diagram and documentation up to date with our changes.

If you care to follow our progress getting to NGS, please see our roadmap.

RDF Web Service will cease to exist after the NGS release

The old skool RDF based web service (at /cgi-bin/ /cgi-bin/ /cgi-bin/ and /cgi-bin/ will cease to exist when we release the Next Generation Schema (NGS) release that will go into a beta release on August 31. This web service has been deprecated for three years now, its finally time to put it out if its own misery.

As of this release the Classic Tagger will completely stop functioning. RIP Classic Tagger!

Wiki Migration

Today’s the day – our wiki is being migrated to MediaWiki.  The old “moin” wiki is now read-only (and will remain so, at least for a few months), and is available on  The new wiki, once all the data has been migrated across, will be at the usual address.

As soon as the migration is complete, I’ll switch over to point to MediaWiki.

Unfortunately it won’t be possible to also migrate the user accounts from moin to mediawiki, so regrettably this means that once mediawiki us up, you’ll have to re-create your accounts.  Sorry about that.

Update: the switch has been made – if you have any questions to ask or problems to report about this, please see the WikiMigration page.  Thanks!

New Picard builds for Mac available

Timothy Lee says:

After a month of trying universal builds through macports unsuccessfully, using a tool named ‘unify’ (h/t John) to lipo i386 and ppc arch bins together unsuccessfully, and bugging just about everyone I know to use their i386 tiger machine (I have an i386 leopard and a ppc tiger) unsuccessfully I’ve made the decision to halt my progress on trying to deliver a UB.

What I do have though is two builds. I have one PPC build that was built on a tiger machine and one i386 build that was built on a leopard machine. I have not had a chance to test my i386 leopard build on a tiger machine (read above failure to ‘borrow’ a tiger machine) but there is a chance it may work. If you feel like you have a better handle on the ‘lipo’ process, please, take my builds and smash them together and let me know! (It may be desirable NOT to deliver a UB as
each separate build of Picard is fairly large).

Timothy is looking for feedback on these builds. If you’ve been waiting for a complete version of Picard that includes working PUID generation, then please try these builds:

Picard for OS X Intel i386 (md5)
Picard for OS X PPC (md5)

If you have problems running these please enter a bug report and use the component “Picard Tagger (Mac OS X Packaging)“. Thanks very much Tim and everyone else who has helped along this somewhat frustrating process.

Testing PPC build of Picard

If you have a PPC Mac that runs 10.4/10.5 and have been waiting for a DMG of Picard, please try download and install this version. Please let us know if it works in the comments.

Jon Hermansen and I have been working on building Picard with only MacPorts prerequisites — that is how this DMG has been built. If this install works then we can proceed to work on a Universal Binary that should work on 10.4/10.5. If we can reach that, we should be able to release Mac binaries at the same time as we release binaries for other platforms.

Thanks for all your hard work Jon!

UPDATE: We’ve found a problem with PUID generation and have fixed it — we hope. The above link now points to the updated dmg. May not work on Tiger yet — if you have a Tiger PPC box, please try it and let us know.