Architecture of libmd

The libmd library uses a plugin architecture in which independent plugins support different sets of metadata fields. When a client requests metadata, the library extracts it using one or more plugins and then returns the set of filled-in metadata fields to the client.

The library is implemented in three layers:

Data processing
This layer:
  • stores and updates the plugin ratings for metadata fields from specific media file types
  • collates (i.e., combines and orders) the metadata field values returned from plugins
Plugin management
This layer:
  • parses the configuration file to learn which library files implement the plugins and to read the preference order for various file types
  • loads, initializes, and unloads plugins
This layer consists of many Metadata Provider (MDP) plugins, each of which:
  • manages communication sessions for responding to metadata requests and for reporting errors
  • rates itself on its ability to retrieve the requested metadata fields
  • retrieves metadata by extracting media information from the named item (media file)

This design lets libmd offer a common, high-level interface for extracting metadata from many file types on many device types. Clients need to name only a media file and the metadata fields they want and libmd then invokes the necessary MDP plugins to read the metadata and returns the extracted metadata fields to the client.

Each MDP fills in as many fields as it can. The order that libmd uses to invoke the MDPs depends on the plugin preferences stated in the configuration file. The preferential order for plugins can vary from one file type to another.

The file types and their associated URL prefixes supported by libmd are:

File type URL prefix
CDDA track cdda:
POSIX file file:
iPod media file ipod:
HTTP stream http:
RTSP stream rtsp:
File on an MTP device mtp:
Note: If no URL prefix is given, the POSIX file type is assumed (e.g., a URL of /fs/usb0/one.mp3 is equivalent to file:/fs/usb0/one.mp3).

MDPs hide the details of the media interface used for reading metadata so clients can extract it through different network protocols from a variety of hardware. Clients can read metadata from the following device types:

Note: The plugin-based architecture makes it possible for future releases of libmd to support additional file and device types. The libmd library could add new MDPs to provide more sources of metadata while clients continue to use the same commands to extract it.