Tuesday, May 31, 2011

Introduction


Hi. \o I'm working on a GSoC project for MusicBrainz Picard this summer. You can follow the imaginably exciting development progress on this blog.

What will my coding entail? First, giving Picard basic support for the new MusicBrainz NGS web service. Would you believe that this is already done?! Download the recently-released Picard 0.15beta if you don't believe me.

This week I'll be keeping an eye on bugs people report for the beta, and try to address them. But now that the groundwork's implemented, I can also start working on some new features in Picard that take advantage of NGS:
  • Ability to use "standardized" recording metadata (instead of track metadata) and artist metadata (instead of artist metadata as credited on a specific release). I'd like to start working on this during the week, so expect a blog post concerning it soon.
  • Collections support. The ability to add or remove releases you're tagging from a collection on your MusicBrainz account.
  • Investigate improvements to how we're displaying multi-disc releases. (This requires further discussion with other developers.)
  • More? We'll see what else I have time for, if the community can think of any additional features that are wanted.
You might now be wondering about specific details of how these features are going to be implemented, or work in the interface. That will all come in future posts. For now, I hope this has shed some light on how I'll be spending my time.

2 comments:

  1. Something I'd love to see in Picard is an option for it to use the "earliest release year" when filling in the Year field of a track. For example, compilations will assign the release year of the compilation to every track, but often the liner notes give the original copyright year for each individual track. Personally I find this more useful in my collection. Since Picard associates the track with a MusicBrainz recording, it could look through every release associated with that recording (not just the release this particular track is associated with) and choose the earliest release year if such an option was set.

    Such an option would be also useful for various re-releases of albums if people prefer the earliest release date. For re-releases (and not compilations) an alternative strategy would be to pick the earliest release year in the release group if this option was set.

    However, remasters should be new recordings, so that would make things a bit more complicated as you would need to up a level to examine the earliest recording of the work by the same performance artist. Still, even with remasters I'd prefer to have the earliest release date...

    ReplyDelete
  2. Ross: a built-in option to use the earliest release year from a release group is something I plan on looking into. It's technically already possible to implement, because we make a release-group request for every release anyway; but that's done in the background, and since I think the date should be set before we mark the release as loaded, http://tickets.musicbrainz.org/browse/MBS-2767 would have to be added to the web service first.

    The compilation issue you brought up isn't as easy to deal with. Making a recording request for every track on a release would be very slow and inefficient; not to mention there's the issue with remasters you brought up. The mbserver developers would probably have to add an earliest-date node to every recording on the web service to make that feasible, which would be a hard idea to sell...

    The closest workaround I could think of would be looking for recording engineer relationships on every recordings, and checking for dates on those. A downside to that is, a majority of recordings won't even have those relationships.

    ReplyDelete