.NET / Mono bindings for libdiscid

There has been quite some activity regarding libdiscid in the last few months, here is some more: I have released dotnet-discid 0.2 which provides .NET / Mono bindings for libdiscid. The source is available at GitHub. For easy usage Windows users might want to use the NuGet package. Alternatively you can download source and binary releases at http://users.musicbrainz.org/~outsidecontext/dotnet-discid/. To use the assembly you will also need the native libdiscid release (e.g. discid.dll on Windows or any other native package for your platform). On Unix-like platforms you can just use the system wide installation of libdiscid.

No API docs yet, but the examples on Github will get you started. The library should be straight forward to use. This is an early release but it supports all the features provided by the latest libdiscid 0.5 (while still supporting earlier versions).  I don’t expect many changes in the API but I will provide better documentation soon.

ruby-discid 1.0

This has already been announced on the mailing list back in May: ruby-discid, the Ruby bindings for libdiscid, have been released in version 1.0. This libdiscid binding for Ruby is the successor of mb-discid. As libdiscid has gained quite a few features in the past I took the opportunity to simplify the API and do some fundamental changes to rubydiscid.

The most important features of this release are:
  • Full support for libdiscid 0.1 to 0.5, including ISRC and MCN reading and feature detection.
  • Uses FFI to load libdiscid, so no compilation is required.
  • Support for Ruby 1.8.7 – 2.0, jRuby and Rubinius.

The probably easiest way to install and use ruby-discid is by using the Ruby gem. For Ubuntu users there is a PPA and for Arch Linux users an AUR package available.

The source code is available on Github, there you will also find more detailed installation and usage instructions.

If you have previously used mb-discid you can continue using it, but you should consider updating to rubydiscid. The API is quite similar and simple enough to make that a painless process.

python-discid 1.0.0 (and 1.0.2) released

In februar I announced a beta version of the first python binding of libdiscid. A couple months have passed and I can now announce the first stable release of python-discid.

The main purpose is the calculation of MusicBrainz Disc IDs from a CD-AUDIO disc or a TOC of such a disc, but reading of ISRCs and the MCN (EAN/UPC) are also supported.
Disc IDs can be submitted without further dependencies. For lookup and ISRC submission it is recommended to use it together with python-musicbrainzngs.
Python 2 >= 2.6 or Python 3 >= 3.1 as well as libdiscid >= 0.2.2 are required. Newer libdiscid features need a newer libdiscid, but there are methods available to check for these conditions.

If you still have a program using python-musicbrainz2, I recommend upgrading to the combination of python-discid and python-musicbrainzngs, since python-musicbrainz2 uses a deprecated web service and is not actively maintained anymore.

The main website and API documentation is at readthedocs, the repository and bugtracker are at GitHub.
Official source tarballs are available on pypi and releases are announced in this blog. There are several linux packages available and listed in the documentation.

If you have been using a pre-release version of python-discid you will have to update your code.
Compared to python-discid 0.5.0 you now have to use discid.get_default_device(), rather than discid.DEFAULT_DEVICE. If you were using 0.4.0, you should also stop using DiscId() directly or a DeprecationWarning is displayed.

There is also a patch release 1.0.2 available, which has no code changes compared to 1.0.0.
There was an intermediate 1.0.1, which tried to make some convenience changes for beta users, but failed. 1.0.1 was never available as a tarball, but the tag and changelog exists.

Server Update, 2013-06-25

We’ve just finished pushing out another version of MusicBrainz. Sorry that we’re a day behind on this one, yesterday we had a few tests that needed fixing before we could release. This release is mostly bug fixes and small improvements, and should solve problems with the “remember me” login feature working incorrectly. This upgrade might have lost a few remember me tokens, but if you are still seeing problems after a few days of the site, please leave a comment on MBS-6471.

Many thanks to Lukáš Lalinský, Michael Wiencek, Nicolás Tamargo and the rest of the MusicBrainz team for their work on this release. Here’s what changed:


  • [MBS-3427] – "Internal Server Error" submitting CD Stubs with invalid data
  • [MBS-5524] – Edit relationship type edits are missing information for identifying the relationship type
  • [MBS-5903] – JSON webservice doesn’t return release-list in collection query
  • [MBS-5958] – Release editor did something very very wrong
  • [MBS-6027] – JSON webservice returns asin: null for releases with ASINs
  • [MBS-6073] – Inaccurate range of credits when grouped at the bottom of a release page
  • [MBS-6101] – Redis should only be required if sessions are used
  • [MBS-6206] – Soundtrack Collector URLs should not be possible at the Release level
  • [MBS-6244] – Private data dump contains bcrypt column and can’t be imported
  • [MBS-6261] – "Date unknown" is inconsistent with our handling of unknown values elsewhere
  • [MBS-6296] – Area alias links are shown for non-location-editors
  • [MBS-6315] – Recordings tab of the RE showing lots of [removed]
  • [MBS-6349] – Artist credits display wrong on add release edit
  • [MBS-6364] – "Possibly duplicate artists" report doesn’t show any results
  • [MBS-6374] – Release editor seeding is broken
  • [MBS-6383] – Can’t add search hint to area
  • [MBS-6416] – release editor loses track identifiers when editing a medium.
  • [MBS-6467] – "you may add a new label" in area search
  • [MBS-6471] – "Keep me logged in" is broken


  • [MBS-2782] – "Edit medium" edit type > Don’t show pointless artists credits changes (e.g. when only join phrase has been changed)
  • [MBS-2848] – New "Add medium" artist credits section is cluttered and hard to parse
  • [MBS-3663] – "No" votes should allow time for the original editor to respond
  • [MBS-4652] – Add a link to How To under Documentation
  • [MBS-5911] – Display source for non-CAA cover art
  • [MBS-6205] – Clean up Soundtrack Collector URLs
  • [MBS-6207] – Check formatting for Soundtrack Collector URLs
  • [MBS-6259] – Bring back date/country columns in tables
  • [MBS-6352] – ExportAllTables::check_tables_completeness should be updated and used
  • [MBS-6363] – Update Twitter URL cleanup to use https

The Git tag for this release is v-2013-06-25.

Libdiscid 0.5.1 released

A new libdiscid version was uploaded today.


  • LIB-40: discid_get_webservice_url() (web service version 1) is deprecated.
    Please use libmusicbrainz to gather metadata by disc ID
  • LIB-7: Rewrote data track handling, releases with multiple data tracks. This also fixes LIB-18 (no ID for DVDs) and LIB-9 (PS/PS2 CDs)
  • LIB-44: fix invalid disc IDs on first read of multi-session discs
  • LIB-37: Autotools optimization (non-recursive build etc.)
  • LIB-42: remove Windows 9x platform code
  • renamed openbsd platform code to netbsd, still used by both.

The data track/multi session disc handling was rewritten. This was started by Lukáš Lalinský quite some time ago and I finished this now. This should fix several issues with data tracks and data track handling works the same on all platforms now.

Christophe Fergeau contributed some changes to remove lots of clutter from the autotools build. This stops changing directories during the build all the time (non-recursive build) and should make it easier to see actual problems when building.

Additional contributions come from Philipp Wolfer and Sebastian Ramacher again.

Feedback needed:

We are (still) a bit stuck in the discussion for LIB-28 which also blocks several connected things in python-discid and possibly Picard.
The main question is how to name the “default device”, especially on Mac OS X. Usually real/internal device names are used. However, especially on Mac OS X these device names change quite frequently for various reasons, even when the same physical disc drive is “meant”. So I don’t know if using these makes any sense. It also might not be good to add these device names to a configuration file, since they will “break” easily (opening a .dmg before inserting the disc already breaks it).
I proposed using “1” to define “use the first disc drive”. I am no actual Mac user and really would like to know how you guys feel about this.
For Windows the drive letters are much more stable, but can change when USB disc drives are used. Using “1” is an option, but might make less sense, since drive letters are actually known to the normal user.
On Linux/BSD/Solaris the disc drive names are only used for disc drives (not for hard disks) and are quite stable.
This relates to python-discid#30 (should DEFAULT_DEVICE be a constant?) which again somewhat blocks PICARD-503 (using python-discid). This question is the only thing keeping python-discid from a stable API release.

LIB-28 is probably the best place for feedback, but you can also just answer here or in the announcement mail.

Information, documentation and other links are at:
That includes builds for Windows and Mac OS X.

Summer of Code: We're in for another round!

I’ve not had a chance to blog about our participation in Google’s Summer of Code program this year, so it is time to fix this now. As you might guess, we’ve been accepted into the program again and were given 3 slots. We awarded the slots to:

  • Rearchitect/Improve the Release Editor by Michael Wiencek (bitmap): This proposal aims to re-work the guts of our Release Editor and to change the architecture to use one page and not a series of pages. This project is potentially massive, so the goal is to work on the guts of the editor while not making many (if any!) changes to the UI. But, bitmap is a veteran GSoC student and long time Picard contributor, so we’re excited to have him back!
  • MBS-6200: Add a “place” entity by Nicolás Tamargo (reotab): Our very own Reosarevok joins the GSoC ranks to implement the Places support. In our previous schema change release we added support for Areas and Reotab aims to finish this project by implementing Places. For more discussion and background on Areas and Places, please see this ticket in jira.
  • Repository for music reviews by Maciej Czerwiński (mjjc): The goal of this project is to create a site that allows anyone to write a non-neutral point of view review of an artist, a release or a recording. All of the reviews in this site will be licensed under a Creative Commons license to be compatible with MusicBrainz and its data.

I’m really excited by all of these projects and the people who are contributing. Summer of Code started yesterday, so we’ll see very soon what our three students will accomplish.

Search server update: June 13

On 13th June we updated the search servers once more. Thanks for fixing bugs and adding Area support, Paul!

Release Notes – MusicBrainz Search Server – Version 2013-06-13


  • [SEARCH-297] – Webservice Json output for aliases when searching is inconsistent with output when doing a lookup
  • [SEARCH-302] – search server json output use singular for a list of release-groups.


  • [SEARCH-292] – Include area info in the indexed search artist and label results
  • [SEARCH-299] – Ouput TrackIds

New Feature

  • [SEARCH-301] – Search for Area by ISO 3166 code


  • [SEARCH-273] – Support for multiple country/release events on release as as part of schema changes
  • [SEARCH-286] – Add areas to the indexed search

Upcoming feature: contested edit extension

The next release (a week from Monday) will include a useful new feature: extending the expiration of edits that receive ‘No’ votes! I’d like to take a bit to explain how it’ll work.

The problem

Especially since the amount of time edits stay open was reduced to 7 days, but also before, several problematic situations could arise when edits were contested:

  • If voters cast ‘No’ votes shortly before the expiration of the edit, the original editor may not have time to respond to the concerns before the edit closes. As a result, it’s generally been considered bad etiquette to cast ‘No’ votes right before an edit expires unless the edit is particularly destructive.
  • In a somewhat related case, sometimes an edit can get many ‘No’ votes in short succession. Since 3 unanimous ‘No’ votes will close an edit, the period between the first vote cast and the edit being closed can be as short as an hour, which is certainly not enough time for the original editor or other voters to respond.
  • It’s also occasionally possible for edits to be put at risk of failing without an email being sent. Specifically, the current code only sends an email on the very first ‘No’ vote. Therefore, if a voter votes ‘No’ early in the voting period and later changes their vote, a second voter later voting ‘No’ would not result in an email being sent. However, a tied vote or a majority of ‘No’ votes will result in an edit being closed, so even a lone vote can tip the balance.

The solution

In light of all of these problems, the next release will work differently to give editors time to respond to votes against their edits.

In short: editors will always have at least 72 hours (three days) to respond after the first vote against their edits.

More specifically, and more technically:

To address the third point above, the emails for ‘No’ votes will now be sent whenever the count of ‘No’ votes goes from 0 to 1. That is: if two people vote ‘No’ with neither changing their vote in-between, only one email will be sent. But, in a case like the one described above, where an early ‘No’ vote is superseded and the total count goes back to 0, a subsequent ‘No’ vote will send a new email.

To address the second point above, ModBot will not reject an edit before its expiration time due to three unanimous ‘No’ votes unless 72 hours have passed since the earliest ‘No’ vote (that is, the vote which resulted in an email being sent). If the expiration time passes or an edit has three unanimous ‘No’ votes after 72 hours, the edit will be closed as usual.

Finally, to address the first point above, when new ‘No’ votes are cast close to an edit’s expiration time, the edit’s expiration time will be extended to allow 72 hours for response. This extension will, once again, only happen when the total count of ‘No’ votes goes from 0 to 1 – so only when an edit becomes contested and previously was not.

In total, these changes should hopefully ensure that editors are better informed about edits that are in danger of being voted down, and given sufficient time to respond to voter concerns.

In summary

First of all, this change will be fully live on Monday, June 24th. Before then, votes cast on the beta server may result in a small number of edits having their expiration times extended, but it won’t happen on the main server or for the majority of edits.

While editing: Rest assured you’ll be informed and given time to fix problems with your edits!

While voting: Don’t worry too much about casting ‘No’ votes when edits need improvement. Certainly be ready to supersede your votes if things do get fixed up, but if you find an edit in need of fixing just before it closes, or which already has a bunch of recent ‘No’ votes, don’t hold back or vote differently to give the original editor time to respond. This should take care of that for you!

Happy editing!

Server Update, 2013-06-10

Another week, another release! This release is mostly bug fixes, but I’m sure a lot of people will be happy to notice that we have finally resolved MBS-357. That’s right – we no longer have a single clear text password in the MusicBrainz database. We’re sorry that it took so long, but at least it’s finally been done! Other than that, this release mostly builds on top of the new schema change features, and provides bug fixes for things that have regressed.

Many thanks to Michael Wiencek, Nicolás Tamargo and the MusicBrainz team for their work in this release. Here’s what’s changed:


  • [MBS-6007] – JSON release webservice doesn’t include works
  • [MBS-6179] – Sorting a collection by catalog number sorts ‘8BP117’, ‘8BP126’ and ‘8BP127’ in the wrong order
  • [MBS-6260] – Dates and countries are displayed inconsistently
  • [MBS-6263] – Adding an area without ISO 3166 codes shows blank values in edits
  • [MBS-6264] – Languages/Scripts statistics have an empty "Last updated field"
  • [MBS-6297] – Can’t create relationships from areas to other entities from the area page, but only from the other entities’ page
  • [MBS-6325] – Moving a release with a release date into an empty release group does not provide it with a date (sorting doesn’t work)
  • [MBS-6326] – ModBot is unable to close some edits as they still use ‘country_id’
  • [MBS-6334] – Release editor: loses join phrases and artist credits when switching to tracklist tab
  • [MBS-6355] – 502 displaying relationships for prolific artist
  • [MBS-6357] – Track/medium tables have indexes/constraints with bad names
  • [MBS-6370] – Beta: Inline search can load duplicate results
  • [MBS-6377] – Track ACs appear changed but the edit isn’t submitted
  • [MBS-6385] – Strange results when pasting an area URL in the inline search
  • [MBS-6409] – ModBot leaves translated edit notes
  • [MBS-6441] – Release (date, country) are blank when displaying a disc ID
  • [MBS-6443] – Ascending and descending sorting of releases in a collection results in the same order


  • [MBS-357] – Don’t store passwords in clear text
  • [MBS-4962] – Slave servers should cache heavily due to hourly update process
  • [MBS-6203] – Only allow recognised URLs for relationship types which are for specific sites
  • [MBS-6233] – Ensure SecondHandSongs links are added at the right level
  • [MBS-6300] – Link to countries in country statistics
  • [MBS-6301] – Consider linking to areas {artist,release,label} list in country statistics
  • [MBS-6347] – Show parents somehow for underlying areas
  • [MBS-6358] – Add basic area stats display
  • [MBS-6362] – Improve how release data is displayed in Google searches
  • [MBS-6371] – Extend Wikipedia and Wikidata autoselect to areas

New Feature

  • [MBS-6269] – Expose track identifiers in the webservice
  • [MBS-6270] – Expose track identifiers on the website

The Git tag for this release is v-2013-06-10.