Differences between ERN 3 and ERN 4
The main changes that have been made between ERN 3.8.2 (the most commonly used version of ERN 3) and ERN 4.2 and the benefits that these changes bring to users of the ERN standard are set out below. The three most important benefits are:
ERN 4 is more efficient than ERN 3 because the need to duplicate information within the
NewReleaseMessagehas been greatly reduced;
ERN 4 decreases the potential for confusion about where certain data needs to be placed within the message; and
The inclusion of a
PartyListmakes disambiguating artist and other contributors much easier.
These improvements have been achieved by virtue of the changes described below.
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 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
PartyListit only appears once in the message and is not repeated in the
ResourceListwith every track.
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.
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
DetailsByTerritorycomposite 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
DetailsByTerritorycomposite 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
DetailsByTerritorycomposite any more. Instead, where territorial variations need to be communicated this appears in the main tag for the creation (e.g.
//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
SoundRecording composites, for instance, still both allow
DisplayTitle information to be communicated. However, DDEX has introduced a rule stating that the
DisplayTitle must only be used if the title of the
TrackRelease differs from the title of the
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:
DisplayArtistNameis 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
DisplayArtistNamemust be provided and multiple
DisplayArtistNamescan be used for different territories, languages and scripts;
DisplayArtistelement is similar to the
DisplayArtistNamebut the two elements together enable the splitting of multiple artists' names combined together in the
DisplayArtistNamefield into their components parts. For example:
The brand “Coldplay vs. Swedish House Mafia” will appear in the
The two component entities “Coldplay” and “Swedish House Mafia” can be separately identified in two
DisplayArtistis a composite and as well as enabling the link to the relevant
Partycomposite, enables the communication of:
DisplayArtistRoleto differentiate between main artists and featured artists;
ArtisticRoleto enable the differentiation between remixers and remixed artists; and
TitleDisplayInformationfield to enable the sender of the
NewReleaseMessageto specify exactly how the name of a
DisplayArtistshould be displayed to consumers by the DSP.
Contributoris different from the
DisplayArtistin 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
Partycomposite that the
Contributoris linked to. The relevant
Partycomposite 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:
CatalogListMessageis not part of ERN 4;
Contributorfield in the
PurgeReleaseMessagehas been simplified to only support those fields needed to communicate a purge request. The composite has been renamed
Contributorin ERN 4 from
ResourceContributorin 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:
UserDefinedResourcecomposites in the
ResourceListplus a few elements that were used to identify the number of artists that contributed to a resource; and
CollectionListin ERN 3 has been re-structured in ERN 4 and renamed
ChapterList. This is because
CollectionListwas 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
NewReleaseMessagebut can be referenced by an identifier or title. If, for any reason, such resource or work data does appear in the
NewReleaseMessageit can be referenced directly within the
The following changes have been made to the
There is a more logical ordering of the sub-elements in those composites;
SoundRecordingTypehas been shortened to
SoundRecordingIdis now called
IndirectResourceIdis now called
IndirectResourceContributorhas been removed and composers, lyricists and other writers are now communicated in the
Contributorfield in ERN 4; and
The same changes apply to the other
Resourcecomposites in the