Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction

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. 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[1]. 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).

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?

Expand

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 support voice-activated services or devices.

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 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?

Expand

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? 

Expand

The forthcoming MEAD standard supports information about musical works, recordings (primarily sound recordings), releases as well as parties such as writers, recording artists and studio personnel. 

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 the communication of the name of the author of any of the pieces of information. A label might, for instance, include in their MEAD feed a review of an album written by a reputable journalist. The name of this journalist might then aid recipients of the media enrichment and description information to assess the reliability of the received information.

This list represents the current extent of what MEAD can express. DDEX expects this to expand significantly over the years:

Type of Information

For…

 

Likely Source of information

…Works?

…Recordings?

…Releases

…Parties

Absolute pitch music is played in[2]

Record companies

3rd party metadata providers

 

X

 

 

Alternative titles (including “false” titles)

Record companies

3rd party metadata providers

X

X

X

 

Awards

Award organisations

X

X

X

X

Biographies

Record companies

3rd party metadata providers

 

 

 

X

Commentary notes

Record companies

3rd party metadata providers

X

X

X

X

Composer class[2]

Record companies

3rd party metadata providers

X

 

 

X

Dance style

Record companies

3rd party metadata providers

X

X

X

 

Epoch information

Record companies

3rd party metadata providers

X

X

X

X

Focus track for a specific musician

Record companies

 

 

 

X

Form of the work or recording[2]

Record companies

3rd party metadata providers

X

X

 

 

Genre

Record companies

3rd party metadata providers

X

X

X

 

Harmony information[2]

Record companies

3rd party metadata providers

X

X

 

 

Historic charting information

Charting companies

X

X

X

X

Images

Record companies

3rd party metadata providers

X

X

X

X

Influences

Record companies

3rd party metadata providers

X

X

X

 

Instrumentation

Record companies

3rd party metadata providers

X

X

 

 

Location of parts of a recording (e.g. where the chorus starts)

Record companies

3rd party metadata providers

 

X

 

 

Location of recording, mixing, mastering, …

Record companies

3rd party metadata providers

 

X

X

 

Lyrics

Record companies

3rd party metadata providers

X

X

 

 

Mood

Record companies

3rd party metadata providers

X

X

X

 

Period in which a party was active or when music was created[2]

Record companies

3rd party metadata providers

X

 

 

X

Playlist suggestions

Record companies

X

X

X

 

Pseudonym information

Record companies

3rd party metadata providers

 

 

 

X

Query-by-humming data

Record companies

X

X

 

 

Recordings of a Work

Record companies

3rd party metadata providers

X

 

 

 

Relevancy date

Record companies

 

X

 

 

Samples

Record companies

3rd party metadata providers

 

X

 

 

Similar or related items or parties

3rd party metadata providers

X

X

X

X

Style

Record companies

3rd party metadata providers

X

X

X

 

Theme

Record companies

3rd party metadata providers

X

X

X

 

Time signature information[2]

Record companies

3rd party metadata providers

X

X

 

 

Type of artist (e.g. “Mariachi Band”)

Record companies

3rd party metadata providers

 

 

 

X

Usage information (e.g. in a particular advert)

Record companies

3rd party metadata providers

X

X

 

 

Vocal register of an artist or a piece of music (especially for classical music)

Record companies

3rd party metadata providers

X

X

 

X

Work hierarchy information[2]

Record companies

3rd party metadata providers

X

 

 

 

 

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.

 


[2]

Anchor
FN2
FN2
This data is specifically for supporting the communication of metadata for classical music.

Some Technical Details

Expand

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 first method is an XML-based query message that can be sent via FTP or web services to a metadata provider;
  • The second method is using web services. DDEX has defined a simple, yet powerful, URL syntax to convey the important query parameters:

The above example could be expressed by calling the following URL:

Code Block
http://base.domain/path?API=1.0&
        QueryTarget=Work&
        RequestedInformation=HistoricChartingInformation&
        ISNI=0000000121174585

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).

Status (as of February 2019)

Expand

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.


[1]                 MEAD was called CAI (Communication of Auxiliary Information) during the initial phase of developing the standard.