The ERN standard has recently been significantly updated. Below is a list of the main changes between ERN 3.8.2 and ERN 4.1 and the benefit that these changes bring to users of the ERN standard. Overall it can be said that ERN-4 is more efficient than ERN-3 as the need to duplicate information has been greatly reduced – which has a beneficial side effect of decreasing the potential for confusion of where what information needs to be placed. In addition, the inclusion of a
PartyList makes disambiguating artist and contributors much easier.
One of the changes is superficial: ERN-4 is only supported by one Profile standard: The Release Profiles describing common Release Types. The Business Profile standard has partly been amalgamated into the core ERN-4 standard. Some of the provisions of the ERN-3 Business Profiles will be provided on the DDEX Knowledge Base as a non-normative document at some stage.
Parties such as musicians, writers, labels and others will now be collated into a
Party composite within this
PartyList can still contain a
PartyName and/or a
PartyId, just like in ERN-3. And, as with ERN-3, the
Party composite can provide different names for different territories as well as names in different languages and in different scripts.
As a consequence of this change, all references to parties in the rest of the
NewReleaseMessage, e.g. when listing
Contributors to a
SoundRecording, now do not provide a name and/or an identifier but only a reference, internal to the message, to a
PartyList was introduced for two reasons: Firstly, having all party information in one place will make ERN messages, on average, smaller as tracks on one release often share writers and/or performers as well as display artist information. The second reason is that the new approach makes it much easier to “disambiguate” artists – which will make help DSPs in making compelling offerings to consumers.
ERN-3 and ERN-4 both support the means to communicate territorial differences for the names of artists, titles, for genres and other information (in addition to allowing different
Deals for specific Releases). However, the approach differs greatly between ERN-3 and ERN-4:
Release) contains one
…DetailsByTerritorycomposite that contains all fields that can differ between territories. This has the unfortunate consequence 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 ...
DetailsByTerritorycomposites. It also had the effect that title information had to be provided on, both, global and territorial levels.
…DetailsByTerritorycomposites any more. Instead, each element or composite for which variations need to be communicated for different countries – or where different languages or scripts need to be communicated – can be provided multiple times in the main tag for the creation (e.g.
//SoundRecording): once for each combination of territory, language and script.
All of this is, of course, independent from the ability to provide different
Deals for different territories; this aspect has not changed between ERN-3 and ERN-4.
The reason for this change is that in most cases only few aspects differ between territories. For example, the parental warning information might differ for a specific Release 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 – reducing the amount of data that needs to be repeated.
The third major change between ERN-3 and ERN-4 is the handling of Track Releases.
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 – comparatively simple – Track Releases were handled like – comparatively complex – album Releases. This had the effect that Track Releases needed to be described with, for example, information about the Track Release’s display artist – whereas that information is always already available from the composite describing the Sound Recording or 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. In ERN-4, a typical 10-track album would contain exactly one
Release composite and 10
TrackRelease composites and while 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 TrackRelease’s
DisplayTitle must only be used if the title of the TrackRelease differs from the title of the SoundRecording.
The last main change in ERN-4 is the handling of contributors and artists. There are three reasons for the update:
The consequence of this work is a consistent set of three elements and composites that can be used to describe Releases as well as Resources as follows:
DisplayArtistNameis an element that allows the provision of the “brand name” under which the Release or Resource is being marketed. At least one DisplayArtistName must be provided and multiple
DisplayArtistNamescan be used for different territories, languages and scripts.
DisplayArtistis similar to the
DisplayArtistName. However, this composite allows the splitting up “compound”
DisplayArtistNamesinto its components. For example, the
DisplayArtistName“Coldplay vs. Swedish House Mafia” can be split into two
DisplayArtists: “Coldplay” and “Swedish House Mafia”.
DisplayArtistis a composite and allows, besides the link to a Party composite, the communication of a
DisplayArtistRole(to differentiate between main artists and featured artists), an
ArtisticRole(mainly to allow the differentiation between remixers and remixed artists) and
TitleDisplayInformation(to allow the specification of whether, and how, the name of a
DisplayArtistshould be displayed as part of the title).
Contributoris different from the above two elements in that it describes a specific contribution of a person or group of people made in creating the Release or Resource. Contributors include writers as well as recording artists and engineers. They are described by a link to a
Role, information about the instrument(s) played, whether the contribution is seen as “featured” and/or “contracted” and how the Contributor’s credits should be displayed.
In addition to the above major changes, a number of smaller changes were made between ERN-3 and ERN-4. These include:
CatalogListMessagethat has, to DDEX’ knowledge, not been widely deployed;
Contributorfield in the
PurgeReleaseMessagehas been simplified to only support those fields needed to communicate a purge request (also, the composite was been renamed from ResourceContributor to Contributor);
NewReleaseMessage. The same applies to a number of elements and composites that DDEX considered superfluous when re-structuring the ERN standard. This includes the
isBackfillflags on the root tag, the
WorkList(also on the root tag), the
UserDefinedResourcecomposites in the
ResourceListplus a few elements that could be used to provide the overall number of artists that contributed to a Resource as well as the
CollectionListin ERN-3 has proven to be mainly used to communicate chaptering information for
Videos. It was therefore re-structured and renamed as
Cueshas been updated to allow Resources or Works to be pointed to, that are described in the
NewReleaseMessageas well as Resources or Works that are not described in the
SoundRecordingTypewhich is now called
Type, and the
SoundRecordingIdwhich is now called
IndirectResourceIdelement was renamed to
IndirectResourceContributorwas removed as composers, lyricists and other writers must be communicated in the
Contributorfield in ERN-4;
SupplementalDocumentListin the root tag.