libdiscid 0.6.0 (and 0.6.1) released

This is a feature release of libdiscid.

It took more time than planned, but 0.6.0 is done now with lots of changes.
Main changes are the TOC string api (handy for fuzzy lookup) and a much better default drive detection on all platforms.
An example to use libdiscid together with libmusicbrainz (including fuzzy lookup) is also provided now.

Unfortunately I found one major bug only while merging changes to another branch. Libdiscid 0.6.1 fixes reading of ISRCs on Windows again (introduced in 0.6.0).

The full set of changes:


  • [LIB-48] – Fix asserts/return values on empty object
  • [LIB-59] – windows: unable to read ISRC (0.6.1)


  • [LIB-52] – validate parameters for put()
  • [LIB-53] – don’t use old redirect for submission_url

New Feature

  • [LIB-28] – allow using numbers as devices on Mac OS X
  • [LIB-41] – Add TOC (id) to API
  • [LIB-43] – Use first CD drive letter on Windows as default device
  • [LIB-45] – Linux/BSD/Solaris: search for an existing default device from a list of devices
  • [LIB-54] – Add example: libmusicbrainz / query for metadata
  • [LIB-55] – Allow using numbers as devices on Windows
  • [LIB-56] – Allow using device numbers on Linux

I want to thank Philipp Wolfer for the Windows drive detection, Laurent Monin for the TOC string API and also Sebastian Ramacher and Lukáš Lalinský for smaller changes.

Testing wanted for raw ISRC reads

Reading ISRCs raw from the device with SCSI commands ([LIB-11, duplicate ISRC problems) is already implemented for Linux and Windows and works quite well on most drives. There is no code for support on Mac, yet. The Windows and Linux implementation still need some testing (with different drives).

If you are willing to test this or really need this feature you can build the code in the “isrc_raw” branch from the github repository.
There is also a windows binary available.
We do want to know about problems (some drives are already reported with strange behavior, possibly due to Alignment), but also a short note about working systems is helpful to get a bit of insight on how rare or frequent failures are.

We also happily accept patches to send SCSI commands on Mac OS X. There is some information in the ticket how this could work, but this is probably the most difficult of the platforms to implement.

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

libdiscid 0.5.2 released

This is a bugfix release of libdiscid.

There are already lots of changes (features) ready for 0.6.0, but I did want to release these fixes separately, since they have a high impact on the platforms involved.
0.6.0 is probably ready in a couple of weeks.


  • [LIB-50] – Solaris: segfault in mb_disc_load_toc
  • [LIB-51] – Mac: Unable to read ISRC for track

New Feature

  • [LIB-26] – disc access test suite
  • print time information in the discid example (zas)

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

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.

libdiscid 0.5.0 released

A new libdiscid release was made available today.


LIB-29: add read_sparse() for faster reading again
LIB-35: add HAVE_SPARSE_READ and VERSION_* defines
LIB-36: hide internal symbols on Linux/Unix
LIB-34: distmac and distwin32 cmake targets

The important change is the read_sparse() function:

Philipp Wolfer added a read_sparse() function. With this function you can either only read the TOC or specifiy which features of the disc you want to read.
The normal read() also extracts ISRCs starting with 0.3.0.
You might want to change existing applications to use read_sparse if you care about performance and don’t use ISRCs. The TOC is usually cached, so read_sparse() can be faster (0,5 vs. 3 seconds measured).
The difference is only in where the time is spent. It doesn’t really save overall time, but the TOC is read right when the disc is inserted so no additional disc access is performed when using the TOC in your application.
To make it possible to keep using read() when read_sparse() is not available we provide the HAVE_SPARSE_READ define, which can be used like that:

#define discid_read_sparse(disc, dev, i) discid_read(disc, dev)

discid_read_sparse(disc, device, 0)

We also provide defines for the libdiscid version numbers.
However, you should rather test for features/functions in the build files and create specific defines for your use case.
The above define is only provided as a convenience for read_sparse().

There are more details about the other changes in the full announcement mail.

If you didn’t follow the musicbrainz-devel list:
This year brought several new releases for libdiscid, starting with ISRC and MCN support in libdiscid 0.3.0. Applications using libdiscid 0.2.2 (or even lower) still work with libdiscid 0.5.0.

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

Announcing libmusicbrainz releases 4.0.3 and 5.0.1

Regrettably, a couple of errors were found close to the release of v4.0.2 and v5.0.0. I have just released v4.0.3 and v5.0.1 with the following changes:

– Fix LMB-32 – Correctly ignore unrecognised nodes
– Don’t compile using -Werror when building from tarball

The releases are available:

(MD5 checksum: 19b43a543d338751e9dc524f6236892b)

(MD5 checksum: a0406b94c341c2b52ec0fe98f57cadf3)

Documentation for the new version is available under

Apologies to all for the need to make this release so soon after the last one.


Announcing libmusicbrainz4 releases 4.0.1 and 5.0.0

Andy Hawkins says:


I am pleased to announce two new versions of libmusicbrainz:

libmusicbrainz-4.0.2 has been updated to take account of changes made to the server on 15th May 2012. Some interfaces are now marked as deprecated, as they have been extended during the work.

Full documentation is available here:

The release can be downloaded here:

(MD5 checksum 5ff62abeca00fdad1bb3a8f99065ae61)

libmusicbrainz-5.0.0 has been introduced to enable the library to be more easily included in Debian due to a conflicting package name. It is identical to libmusicbrainz-4.0.2, with the following exceptions:

1. All include files are now in the musicbrainz5 directory

2. You should now link against libmusicbrainz5 (-lmusicbrainz5)

3. All previously deprecated functions have been removed.

Please note that all future work is likely to only occur on the 5.x library, so this should be used wherever possible.

Full documentation is available here:

The release can be downloaded here:

(MD5 checksum 3396e0c66cfacfa1f32abc7cfdbcbe13)

As ever, please report any issues in JIRA at

under the project ‘libmusicbrainz’.

If you have any questions, please post them in the musicbrainz-devel mailing list. I will also attempt to be available on the #musicbrainz-devel IRC channel on Freenode.

Announcing libmusicbrainz4 release 4.0.1

v4.0.1 of libmusicbrainz4 has now been released. This is primarily a maintenance release to fix a couple of bugs that were reported. Additionally, the code has now moved to GitHub, and can now be found at

The main changes are:

  • Fixed bug LMB-30 – Unable to access all relation lists on objects with multiple relation lists
  • Fixed bug LMB-31 – mb_relationlist_get_targettype always returns “target-type”

The interface has changed as regards to retrieving relation lists, due to LMB-30. Previously, the library only returned the last relation list that was returned in the XML response. The old ‘RelationList’ method on the Artist, Label, Recording, Release, ReleaseGroup and Work classes has been marked ‘deprecated’, and a new ‘RelationListList’ method will return a list of all relation lists for the entity.

For backwards compatibility, the ‘RelationList’ method will operate in the same manner as release 4.0.0, only returning the last relation list.

As ever, please see the enclosed README for details on support and bug reporting. The release is available for download at