MEAD explained

The MEAD standard enables record companies, distributors or metadata companies to communicate non-core metadata to DSPs so that they can offer a rich user experience, for example, to support voice-activated music discovery and playback. The metadata that can be communication includes a significant range of information, but includes such items as:

  • Journalistic material;

  • Lyrics;

  • Information about artist nicknames;

  • Information about historic chart positions; 

  • Awards won by a recording or album; or

  • Information of interest to aficionados of classical music.

You can access the current MEAD specification in version 1.1 here.

 MEAD, PIE and ERN

MEAD supports more than thirty different mechanisms for the description of parties, releases, resources such as sound recordings, and musical works. This type of descriptive information is therefore for music discovery or marketing and different from the “core” information about releases and resources communicated using ERN.

MEAD and PIE are very similar standards. They both provide “rich” metadata that is intended to enable DSPs to offer better user experiences to their customers. The difference between these two standards is that while MEAD focuses on creations (musical works, resources and releases), PIE focuses on parties (writers, recording artists, engineers, publishers and labels).

 What does MEAD support?

The MEAD standard in version 1.1 supports information about: 

  • Musical works;

  • Recordings (primarily sound recordings); and

  • Releases; and 

(Version 1.0 also supports information about Parties (such as writers, recording artists and studio personnel. This has been since moved into PIE.)

The table below lists, in alphabetical order, the types of information that the MEAD standard currently supports. The table represents the current extent of what MEAD can express. We expect this to expand significantly over the years, 

Type of information

Musical Works

Recordings

Releases

Absolute pitch of music

 

✔︎

 

Alternative titles (including “false” titles)

✔︎

✔︎

✔︎

Awards

✔︎

✔︎

✔︎

Commentary notes

✔︎

✔︎

✔︎

Is it a Cover?

 

✔︎

 

Dance and rhythm style

✔︎

✔︎

 

Form of the work or recording

✔︎

 

 

Genre

✔︎

✔︎

✔︎

Harmonic information

✔︎

✔︎

 

Historic charting information

 

 

✔︎

Images

 

✔︎

✔︎

Influences

✔︎

✔︎

✔︎

Instrumentation

✔︎

✔︎

 

Time stamps (for example, where the chorus starts)

 

✔︎

 

Location of, for example, recording, mixing or mastering.

 

✔︎

 

Lyrics

✔︎

✔︎

 

Mood

✔︎

✔︎

✔︎

Period/epoch in which a party was active or when music was created

✔︎

✔︎

✔︎

Recordings of a musical work

✔︎

✔︎

 

Relevancy date

 

✔︎

 

Samples

 

✔︎

 

Similar or related items or parties

✔︎

✔︎

 

Theme

✔︎

✔︎

✔︎

Time signature information, including Beats Per Minute (BPM)

✔︎

✔︎

 

Usage information (for example, in a particular TV advertisement)

 

✔︎

 

Vocal register of an artist or a piece of music 

✔︎

✔︎

 

Work hierarchy information (for example, movements in a symphony)

✔︎

 

 

 The future for the MEAD standard

Currently, MEAD is a messaging standard to be exchanged between companies with the relevant data and DSPs. We envisage that MEAD will eventually be extended to work as a query API. Such an API will allow a DSP to call a record company's, distributor's or metadata provider’s web service to request a specific piece of information. The reply to such a request should only contain a response to the request and not any other previously sent information. The response would not therefore update or retract any other information.

 Communicating data sources

The standard also enables the communication of information about the source of any of the data. For example, a record company might include in their MEAD feed a review of an album written by a reputable journalist. Providing the name of this journalist aids recipients of the data in assessing the reliability of the received information.

 MEAD as a statement of truth

The messages defined by all DDEX standards are stateless. That is, they provide “statements of truth”, which means that the latest message always contains a complete view of the situation as known by the message sender at that moment it time. This also applies to MEAD.

However, MEAD and PIE differ from the other DDEX message standards in that it not intended to always provide a full picture. MEAD and PIE can be used by to send information just to describe, say, a sound recording. Recipients of MEAD and PIE messages may then take the various pieces of information received from multiple metadata providers about the same entity to create the data set it wants to use to describe that entity on its service.

However, it is possible that such metadata will change or require updating over time. Therefore, a message sender may need to correct or update some of the information it has sent out in the past. As a result the following rules apply when sending changed or updated information: 

Action required

Approach using a MEAD/PIE message

A message sender previously sent information describing fact X and now wishes to sent information describing fact Y.

MEAD and PIE messages state information describing facts XY.

A message sender previously sent information describing fact XY and now wants to withdraw information describing fact Y.

MEAD and PIE messages state information describing fact X (the absence of information describing fact Y indicates it is no longer valid as far as the message sender is concerned).

A message sender previously sent information describing three genres for a resource and now wants to withdraw one of them.

MEAD and PIE messages state information describing the two genres that remain valid (omitting the third).

A message sender previously sent information describing genre X and now wants to withdraw that and state Y now.

MEAD and PIE messages state states information describing Y genre only.

A message sender previously sent information describing a genre and now wants to withdraw all genres.

MEAD messages state completely omits the GenreCategory tag.

The same approach can be used to completely withdraw any information previously communicated, in a MEAD or PIE message, about a specific party or creation. In that case the message sender shall send a new MEAD or PIE message with only a:

  • ResourceSummary composite where the subject of the MEAD message is a Resource;

  • ReleaseSummary composite where the subject of the MEAD message is a Release;

  • WorkSummary composite where the subject of the MEAD message is a Work; or

  • PartySummary composite where the subject of the PIE message is a Party.

This approach has many advantages. However, in the context of MEAD and PIE, a standard whereby multiple sources may provide data to a single recipient about the same entity, it also has a few drawbacks. These include:

  • Message senders need to know what information they have provided in the past to all of their recipients, and always re-send previously sent information; and

  • Message recipients need to know what information was sent by whom, to enable them to disregard data only once it has been withdrawn by all metadata providers that have provided information of that kind in the first place.