DDEX’s Standard for Release Deliveries (ERN) enables record companies to send musical products to DSPs who are thereby enabled to make them available to consumers (notwithstanding any obligations to other rights holders).
ERN is designed to communicate “core information” about such products (in the form of releases, resources and deals) as part of the supply chain between labels and distributors, and DSPs.
– but However, DSPs require more metadata to be successful in marketing that music.
DDEX is in the latter stages of developing a standard for the communication of this type of metadata which would not normally form a part of the data communicated along the supply chain. This is MEAD – the DDEX standard for the communication of Media Enrichment and Description information  . As of today, MEAD supports more than 30 different mechanisms for the description of parties, releases, resources such as sound recordings, and works in ways that are different from the data exchanged using ERNs.
A few examples of such information includes:
- Information about “focus tracks”, which is crucial for voice-activated services (i.e. which sound recording or video is to be played when a consumer asks for, for example, “the latest George-Ezra track” – which may well differ from Ezra’s most recently released song because of advertisement campaigns or other events);
- Journalistic material such as reviews about a musical work, a recording, an album or a musician;
- Lyrics of musical works or recordings;
- Information about artist nicknames, whether “official” or not;
- Information about historic chart positions of and/or awards won by an artist, a work, a recording or a release;
- Extended information of interest for aficionados of classical music;
- And many more (see also the "What does MEAD support today" section on the right).
DDEX is in the latter stages of developing a standard for the communication of such information: MEAD – the DDEX standard for the communication of Media Enrichment and Description information  . As of today, MEAD supports more than 30 different facets to describe parties, releases, resources such as sound recordings, and works.
This document summarises what MEAD can be used for (and how) and provides some information about the status of the development.
MEAD: From whom to whom?
DDEX envisages two “modes” for MEAD. The first mode is where media enrichment and description information is sent as part of an ERN feed from a record company to a DSP (potentially, as with all DDEX standards, via aggregators or technical service companies). Labels would be able to send, for example, focus track information to DSPs that supports support
The second mode is where such media enrichment and description information is sent from a “metadata provider” to a DSP independently of an ERN feed. A DSP would subscribe to a metadata feed and would receive such information once new data becomes available. Such metadata providers can include record labels (although the label-internal data sources for MEAD may be different from the one used for an ERN feed) as well as companies companies that specialise in the aggregation of enriched data about parties, releases, resources and works not normally included in supply chain activities.
How is MEAD exchanged?
If media enrichment and description information is communicated alongside an ERN message, the MEAD message is sent like a resource that accompanies the ERN message. This approach works with ERN-3 as well as ERN-4. Therefore, neither the sender nor the recipients will need to update their message exchange process. There is, of course, code to be written for creating and ingesting the MEAD message itself.
Where media enrichment and description information is communicated independently from an ERN feed, the process depicted below is envisaged. This process can be implemented using (S)FTP or a web services API similar to the one used today to communicate ERN messages and their resource files.
What does MEAD support today?
The forthcoming MEAD standard supports information about Musical Works
The table below lists, in alphabetical order, the types of information that the draft version of the MEAD Standard currently contains, and who the likely sources of such information are. In addition, the standard will allow
This list represents the current extent of what MEAD can express. DDEX expects this to expand significantly over the years:
It is essential to note that no company is expected to send or receive all types of media enrichment and description information. Instead, the standard provides a flexible “menu” approach were only those items that a party wishes to send (or receive) are actually communicated.
 This data is specifically for supporting the communication of metadata for classical music.
Some Technical Details
MEAD is based, like most DDEX standards, on an XML Schema Definition (XSD) that will seamlessly integrate with all other DDEX standards as all DDEX standards are based on a common data dictionary. Implementers of the ERN standard will therefore find it very easy to implement the new standard.
As indicated above, MEAD is intended to be used in two modes: media enrichment and description information can be sent either as an accompaniment to an ERN message or independently of an ERN message. In the latter case, the organisation that wishes to receive media enrichment and description information will need to let the metadata provider know what information it seeks. This is done by means of a query which serves, effectively, as a subscription to a metadata feed about the entity (or entities) that match(es) the query.
A DSP might, for example, ask a metadata provider about historic chart positions for John Lennon’s works. The metadata provider would then reply, until the DSP unsubscribes, with all charting information about John Lennon it knows of. And if it learns of a previously unknown chart entry, it would forward that information to all subscribers. DDEX has developed two approaches to allow DSPs – or other companies – to query metadata providers:
The above example could be expressed by calling the following URL:
This can be read as “I am using the MEAD API in version 1.0; please provide me charting information for all works by the person with ISNI 0000 0001 2117 4585” (i.e. John Lennon).
Quo (as of February 2019)
The MEAD specification has been developed by DDEX’s ERN Working Group for a number of months now. However, before DDEX can publish MEAD as a standard that can be implemented and used by members and non-members alike, it needs to be evaluated and tested so that DDEX can be sure that the specification meets the requirements and that, ideally, all bugs have been removed.
Once this process has been completed, MEAD is excepted to be published, as a “DDEX Standard”, in the course of 2019.