Parties such as musicians, writers, labels and others will now be collated in the NewReleaseMessage into a PartyList rather than that data appearing potentially several times through the NewReleaseMessage. Linking those parties to the release and resources they have contributed to is then achieved by a reference, internal to the message, in the relevant composite which links back to the relevant Party in the PartyList. 

The PartyList was introduced for two reasons:

• No duplication of party information:

  • Having all party information in one place will make ERN messages generally smaller. This is because, for example, where there are several tracks on one release each track often shares the same display artist, writers and/or performers. By placing this information in the PartyList it only appears once in the message and is not repeated in the ResourceList with every track.

• Disambiguation:

  • This approach makes it much easier to clearly disambiguate two parties who might appear to be the same, for example, having the same name. This disambiguation helps DSPs use party names to make more compelling offerings to consumers.

Each Party composite in the PartyList in ERN 4 contains the same data points as in ERN 3 such as a PartyName or a PartyId. Similarly, the Party composite enables the provision of different names to be used for a party in different territories as well as the provision of names in different languages and in different scripts.

Both ERN 3 and ERN 4 support the means to communicate territorial differences for the names of artists, titles, genres and other information (in addition to allowing different deals for specific releases). However, the approach differs greatly between ERN 3 and ERN 4:

• In ERN 3, each composite that describes a creation (i.e. a work, resource or release) contains a DetailsByTerritory composite that contains all fields that can be used to communicate how data differs between territories. This means that, even if, say, the title of a recording does not change between different territories but the genre does, the title needs to be repeated in the relevant DetailsByTerritory composite in order to communicate the different genre. It also means that the title information has to be provided on both the global and territorial levels of the message.

• In ERN 4 there is no DetailsByTerritory composite any more. Instead, where territorial variations need to be communicated this appears in the main tag for the creation (e.g. //Release or //SoundRecording) and this can be applied for each combination of territory, language and script.

The reason for this change is that in most cases only a few elements regarding a release or resource differ between territories. For example, the parental warning information might differ for a specific release in a specific territory whereas the artist and contributor names, titles and genre are the same everywhere. In ERN 4 only those elements that actually differ need to be repeated, significantly reducing the amount of data repetition.

In ERN 3, all releases, whether they are album releases or track releases, need to be communicated in the same release composite. As a consequence, the track releases were handled as if they were album releases. This had the effect that track releases needed to be described with, for example, information about the track release’s display artist when that data is already available in the composite describing the sound recording or music video that is referenced from the track release. 

This unnecessary duplication of information is avoided in ERN 4 by the introduction of a TrackRelease composite which contains a lot less data points than the full track release in ERN 3. So when describing a 10-track album there is exactly one Release composite and 10 TrackRelease composites. Although there is still some data duplication possible, the danger of causing confusion has been all but eliminated. The Release and SoundRecording composites, for instance, still both allow DisplayTitle information to be communicated. However, DDEX has introduced a rule stating that the TrackRelease’s DisplayTitle must only be used if the title of the TrackRelease differs from the title of the SoundRecording.

The handling of contributors and artists has been changed in three ways:

• There is a clear delineation between the “brand” an artist works and publishes under and the party or parties that went into the studio and wrote the musical work and/or made the sound recording. The brand refers to the name under which the release or resource is being marketed (if you like, the name that is written in large letters on the cover of the physical release);

• Mis-classification of role codes which had caused confusion in ERN 3 has now been corrected; and

• The way contributors and artists are handled in ERN 4 has been aligned with the approach taken in the Recording Information Notification (RIN) and the Recording Data and Rights Standards (RDR). This harmonisation means that data can flow much more easily from the studio environment via labels to online retailers and music licensing companies.

These changes have been achieved as follows:

• The DisplayArtistName is a new element in ERN 4 that enables the communication of the brand under which the release or resource is being marketed. At least one DisplayArtistName must be provided and multiple DisplayArtistNames can be used for different territories, languages and scripts;

• The DisplayArtist element is similar to the DisplayArtistName but the two elements together enable the splitting of multiple artists' names combined together in the DisplayArtistName field into their components parts. For example: 

  • The brand “Coldplay vs. Swedish House Mafia” will appear in the DisplayArtistName field; and

  • The two component entities “Coldplay” and “Swedish House Mafia” can be separately identified in two DisplayArtist fields;

• DisplayArtist is a composite and as well as enabling the link to the relevant Party composite, enables the communication of:

  • A DisplayArtistRole to differentiate between main artists and featured artists;

  • An ArtisticRole to enable the differentiation between remixers and remixed artists; and 

  • A TitleDisplayInformation field to enable the sender of the NewReleaseMessage to specify exactly how the name of a DisplayArtist should be displayed to consumers by the DSP.

• The Contributor is different from the DisplayArtistName and DisplayArtist in that it describes the nature of a specific contribution made by a person or group of people in the creation of the release or resource. Contributors include parties such as writers, arrangers, producers or engineers. Such contributors are described in the Party composite that the Contributor is linked to. The relevant Party composite indicates the role of the contributor, if relevant, what instrument(s) was played, whether the contribution is seen as “featured” and/or “contracted” and how the contributor’s credits should be displayed.

A number of smaller changes were made between ERN 3 and ERN 4, including:

• The CatalogListMessage is not part of ERN 4;

• The Contributor field in the PurgeReleaseMessage has been simplified to only support those fields needed to communicate a purge request. The composite has been renamed Contributor  in ERN 4 from ResourceContributor in ERN 3;

• A number of elements and composites marked as “deprecated” in the last version of ERN 3 have been removed from the ERN 4 NewReleaseMessage. The same applies to a number of elements and composites that DDEX considered superfluous when re-structuring the ERN. This includes:

  • From the root tag:

    • The UpdateIndicator and isBackfill flags; and 

    • The CatalogTransfer and WorkList;

  • The MidiResource and UserDefinedResource composites in the ResourceList plus a few elements that were used to identify the number of artists that contributed to a resource; and

  • The ReleaseResourceReferenceList within the SoundRecording composite;

• The CollectionList in ERN 3 has been re-structured in ERN 4 and renamed ChapterList. This is because CollectionList was mainly being used to communicate chaptering information for music videos;

• In ERN 3 the mechanism to reference cues made the inclusion in the message of the data about the resources or music works in that cue mandatory. In ERN 4 this mechanism has been changed so that such resource or musical work data itself does not have to appear in the NewReleaseMessage but can be referenced by an identifier or title. If, for any reason, such resource or work data does appear in the NewReleaseMessage it can be referenced directly within the NewReleaseMessage;

• The following changes have been made to the SoundRecording and Video composites:

  • There is a more logical ordering of the sub-elements in those composites;

  • The SoundRecordingType has been shortened to Type;

  • The SoundRecordingId is now called ResourceId;

  • The IndirectResourceId is now called WorkId;

  • The IndirectResourceContributor has been removed and composers, lyricists and other writers are now communicated in the Contributor field in ERN 4; and

  • The same changes apply to the other Resource composites in the ResourceList.