A new libdiscid version was uploaded today.
Changes:
- 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:
http://musicbrainz.org/doc/libdiscid
That includes builds for Windows and Mac OS X.
MetaBrainz Blog 
To make that a bit more clear:
There are also problems in PICARD that are not actually problems in libdiscid. We do want to allow automatic disc drive detection either way and most of that is already in place. (For Windows there is a patch, but not applied yet. All other systems work)
The interesting questions are these:
1. Should discid_get_default_device() return “1” on Mac OS X, rather than /dev/rdisk* ?The reason is because the first disc drive can be /dev/rdisk2 or /dev/rdisk5, depending on what .dmg etc. are mounted)
2. Should discid_get_default_device() return “1” on Windows, rathern than D:, E: ?(drive letters are fairly stable, but can change when using USB drives)
3. Should DEFAULT_DEVICE on python-discid be a constant?(probably only if the answer is yes to both of the above)see python-discid#30