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

PIE and MEAD 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).

The PIE standard in version 1.1 supports information about parties (such as writers, recording artists and studio personnel).

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

When a record company or a distributor sends a new album or track to a DSP, they usually use the ERN standard which enables the communication of essential “label copy” data, together with data about where, when and how the music may be made available to consumers. This data, along with the files themselves, then enable the DSP to offer the music to its consumers.

However, to effectively market music and music services requires more data than can be communicated in an ERN message.

Enabling a service to add music into play lists or for consumers to discover new music on their own needs additional “soft” data. A study made by Universal Music and Amazon showed [LINK] that augmenting ERN data with such soft data led to the music being played back up to 10% more with, at the same time, a reduced skip rate of over 7.5%. These results were facilitated by utilisation of DDEX’s standard for communicating such soft data for musical works, sound recordings, music videos and the releases they are contained in: MEAD.

MEAD, and its sister standard PIE which enables the communication soft data about parties such as writers, recording artists and engineers, offers over 50 data points ranging from genres to data about instrumentation or related music and related musicians to historic charting data or pronunciation aids to the lyrics of a work or recording. The potential need to communicate this extremely wide and deep selection of such data means that both standards have of necessity been drafted as very large standards.

For implementers this size may well appear very daunting, particularly if the implementer only wants to communicate a limited type of data to its business partners. Therefore, both these standards have been constructed in such a way that they can be successfully implemented only using a small portion of the standard that the implementer needs to communicate limited types of data to its business partners. It is, therefore, not necessary to implement the entire standard. Existing implementations have shown, implementations can be highly successful when they make use of a just a small subset of the available data points in the standards.

For example, one record company has successfully implemented MEAD with just five data points. It is anticipated that taking such a restricted approach would also work for the PIE standard. The five data points are:

• Activity;

• Artist/title pronunciations;

• Focus tracks;

• Mood; and

• Theme.

The company expects to add further data points in the future, as the data requirements of their business partners expands. To accommodate this the company will just expand its MEAD implementation. They will not need to start all over again.

A second record company’s implementation includes only:

• Artistic style;

• Classical period;

• Dance style;

• Form;

• Genre;

• Instrumentation;

• Intensity and BPM

• Key and time signatures;

• Mood;

• Rhythm style; and

• Vocal register.

These two data sets represent around 10% or 20% of the data points that MEAD and PIE offer. If both standards are implemented, they can, through the provision of more soft data offer a significant increase in the music’s reach and commercial success. However, implementing these standards in their entirety is not necessary as is demonstrated above.

While it is recognised that collecting and maintaining such soft data requires additional work, the companies that have started to use MEAD have reported that the investment is justified by increased revenue from streaming services.

Currently, PIE is a messaging standard to be exchanged between companies with the relevant data and DSPs. We envisage that PIE 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.

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

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

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: 

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.