Metadata profiles

This is an early description of the concept of changeable metadata profiles in xmms2. I have placed it here for public comment. I will revise it over the next one or two months as I begin work on it in a private branch of xmms2-devel. nollidj 13:07, 17 September 2007 (CEST)

Overview

The medialib should not be limited to cataloging a static or hard-coded set of fields. Users should be able to determine which metadata fields they care about in their media library, tell medialib this, and search their media library using these fields. Conversely, users should not need to know a great deal about the different tagging formats that their media streams are using and have a simple set of fields in their medialib that still give them a powerful search.

There should be a flexible behavior built into xmms2 which provides a choice between a few, simple field names and a complex, powerful field hierarchy.

Caveats

I'm still adjusting to the codebase, concepts, and terminology used by xmms2 and its developers. I am not totally sure, for example, if using the term metadata is confusing. I use it here to refer to properties of media streams as provided by stream and container formats such as Ogg, FLAC, and id3v2. This probably corresponds most strongly to the concept of xmms2 properties and not to the concept of mediatags.

Elaboration

An MP3 file tagged with id3v2 may have values in the TCOM (composer), TOPE (original artist/performer), TPE1 (lead performer), TPE2 (ensemble/accompaniment), TPE3 (conductor/specific performer), and TPE4 (remixer or whatever else you want) fields. An Ogg Vorbis file may have its own Vorbis comments with keys "composer", "artist", "soloist", "ensemble", "conductor", and "performer".

A power user who really cares about how their data are presented (or someone who is as neurotic about tagging their music as I am) will want to be able to search their music library according to these fields. They may even go so far as to want their playlists or "currently playing" items to be labeled according to metadata pulled from these fields. There are bugs like this one indicating as much.

Public field name	FLAC field key(s)	id3v2 frame name(s)
composer	composer	TCOM
ensemble	ensemble	TPE2
performer	performer	TPE1, TPE3
title	title	TIT1, TIT2, TIT3
discnumber	discnumber	TPOS
tracknumber	tracknumber	TRCK
album	album	TIT1

A naive user may not particularly care how their music is tagged. Under such circumstances, all of these fields should still be accessible but not foisted upon the user. (Maybe the fields would still be searchable but displayed only as various values for the "artist" of the stream, so that a naive user could search for "Wagner", "Boston Pops", "Solti", or "Masur" without worrying about which metadata field to search in.)

Public field name	FLAC field key(s)	id3v2 frame name(s)
artist	composer, ensemble, performer	TCOM, TPE1, TPE2, TPE3
title	title	TIT1, TIT2, TIT3
album	album	TIT1
discnumber	discnumber	TPOS
tracknumber	tracknumber	TRCK

Right now, the public medialib tags in medialib.h define a set of metadata keys. xform plugins such as those for FLAC and id3v2 provide a mapping from the metadata fields of their respective stream formats to this public metadata keyset. There should be a programmable interface for this mapping so that a user can, through a client, declare that the medialib should consist of a given set of fields (for example, "composer", "performer", and "ensemble"). Additionally, each xform plugin that exports metadata fields needs to have a mapping for those of its fields which should be mapped to public fields. The existing set of public metadata fields is at tags.

Types of metadata

Metadata profiles are supposed to improve the interface for metadata which are about the semantic content of a media stream as it is interpreted by a user. They are not intended to provide creative mappings for information about the data stream itself.

That is to say, it makes sense to provide flexible mapping of fields like artist, album, title, and recording year, but fields like bitrate, number of channels, and sampling frequency are probably best left with static mappings in the xmms2 properties API.

It might make sense to provide further separation in the properties API between those metadata which are about the stream (bitrate, number of channels, MIMEtype, etc.) and those which are about the content of the stream.

Details of possible implementation

xform plugins export metadata from media streams. The xmms2 properties API exports metadata from the xform plugins. It may suffice to have just one interface which is implemented by xform plugins and the medialib. Metadata will be exported by this interface as a set of keys, each of which is mapped to one or more values.

The mappings between xform plugins' metadata fields and the medialib's metadata fields will be provided independently of this interface.

Metadata interface details

The interface should provide the following information:

• Whether a given key is exported by the implementor. (In the case of the id3v2 xform plugin, this is true if the key is the name of an id3v2 field. In the case of the Vorbis or FLAC plugin, this is true for anything that meets the field definition in the Ogg Vorbis comment specification.)
• The value(s) of a given key. This would probably be a function from a key name to a set of values, returning an iterator or array.

It may be necessary or useful also to provide:

• Constraints on values that may be associated with a given key. (This is necessary to support writing tags. id3 and id3v2 do not support one-to-many relationships between keys and values. id3 allows only 30 bytes for the "artist" field.)
• A localized name for the field (might be useful so that Vorbis/FLAC fields named "artist" are translated nicely).
• A description of the field (quite useful for id3v2 fields; needs localization).
• Codepage/character encoding/language of a field or of all fields. (Could some media formats provide "lyrics" or "title" values that differ by language? It may be necessary to do translation to a local character encoding if a media stream's metadata aren't in UTF-8.)

Metadata mapping details

Each medialib metadata field may be mapped to arbitrarily many xform metadata fields. This mapping may be changed programatically. It will probably be necessary for the medialib to rebuild itself when the mapping is changed, so it should be understood that modifying the mapping is a very expensive operation.

When a mapping is in place, adding a song to the medialib should be pretty much the same as it is now, except the song is queried for those values which the medialib is currently "interested in" according to the current metadata mapping.

It would make sense to encode mapping information in a file that uses the same format as the xmms2 configuration file, which is currently a simple XML file. Users could then create their own mappings by editing this file, overwriting it with files created by other users, using a stand-alone xmms2 metadata editing tool, or using a sophisticated xmms2 client.

Support for getting and writing of metadata through the medialib should be workable by delegating certain xform metadata fields as "primary" or "preferred" fields for the medialib metadata interface. This way, a profile could specify that "artist" in the medialib should correspond to "TP1", "TPE1", and "TCOM" in an id3v2 stream, but when writing to the "artist" medialib tag, write only to the "TP1" field. (How is this problem handled now?)

Issues

• Make sure this will play nicely with the current de facto "default" public metadata profile.
• How to integrate this with properties as per generic properties policy?
• How will this play with the ability to write metadata to song files?

Possible future work

Most of these ideas probably entail pushing too much logic into metadata profiles, violating the KISS principle.

• Defined types and parsing logic for different fields (so as to improve storage and searching of dates, lengths of time, other typed fields?)
• Namespaces for public metadata profiles (to allow multiple profiles to be loaded at once, e.g., Dublin Core, MPRIS Metadata, some standard profile, and my personal profile)
• Allow interaction between profile and values of metadata fields (e.g., if "genre" field is "opera" or "theater", look for "act" and "scene" fields; otherwise, just set them to NULL)