Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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.

Introduction of a PartyList

Parties such as musicians, writers, labels and others will now be collated into a PartyList. Each 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 Party composite.

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

Territorial Differences

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:

  • In ERN-3, each composite that describes a creation (i.e. a Work, Resource or Release) contains one …DetailsByTerritory composite 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 ...DetailsByTerritory composites. It also had the effect that title information had to be provided on, both, global and territorial levels.
  • In ERN-4 there are no …DetailsByTerritory composites 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. //Release or //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.

Track Releases

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

Description of Contributors and Artists

The last main change in ERN-4 is the handling of contributors and artists. There are three reasons for the update:

  • The update allows a clear delineation between the “brand” an artist works and publishes under (i.e. the name under which the Release or Resource is being marketed; this is, basically, the name that is written in large letters on the cover of the Release), and the person or group that went into the studio and wrote the song and/or made the recording;
  • It fixes the problems that occurred in relation to role codes because of some mis-classification of roles; and
  • It aligns the approach to contributors and artists with that taken in the Recording Information Notification standard (RIN) [LINK] and the Musical Work Notification Standard (MLC) [LINK] with ERN. This harmonisation means that information can flow much more easily from the studio environment via labels to online retailers and music licensing companies.

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:
• The DisplayArtistName is 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 DisplayArtistNames can be used for different territories, languages and scripts.
• The DisplayArtist is similar to the DisplayArtistName. However, this composite allows the splitting up “compound” DisplayArtistNames into its components. For example, the DisplayArtistName “Coldplay vs. Swedish House Mafia” can be split into two DisplayArtists: “Coldplay” and “Swedish House Mafia”. DisplayArtist is 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 Display Artist should be displayed as part of the title).
• The Contributor is 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 Party composite, 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.
Miscellaneous Simplifications
In addition to the above major changes, a number of smaller changes were made between ERN-3 and ERN-4. These include:
• ERN-4 no longer supports the CatalogListMessage that has, to DDEX’ knowledge, not been widely deployed;
• The Contributor field in the PurgeReleaseMessage has been simplified to only support those fields needed to communicate a purge request (also, the composite was been renamed from ResourceContributor to Contributor);
• A number of elements and composites marked as “deprecated” in the last ERN-3 version have been removed from the NewReleaseMessage. The same applies to a number of elements and composites that DDEX considered superfluous when re-structuring the ERN standard. This includes the UpdateIndicator and isBackfill flags on the root tag, the CatalogTransfer and WorkList (also on the root tag), the MidiResource and UserDefinedResource composites in the ResourceList plus a few elements that could be used to provide the overall number of artists that contributed to a Resource as well as the ReleaseResourceReferenceList within SoundRecording;
• The CollectionList in ERN-3 has proven to be mainly used to communicate chaptering information for Videos. It was therefore re-structured and renamed as ChapterList;
• The means to reference Cues has been updated to allow Resources or Works to be pointed to, that are described in the NewReleaseMessage as well as Resources or Works that are not described in the NewReleaseMessage;
• The following changes were made to the SoundRecording composite:
• The sub-elements were re-ordered to be more logical;
• Some elements’ names were shortened or harmonised with other composites.
Two such examples are the SoundRecordingType which is now called Type, and the SoundRecordingId which is now called ResourceId;
• The IndirectResourceId element was renamed to WorkId;
• As indicated above, the IndirectResourceContributor was removed as composers, lyricists and other writers must be communicated in the Contributor field in ERN-4;
• The same changes apply to the other Resource composites in the ResourceList; and
• ERN-4 allows for the communication of additional information in a separate document. Indicating to the recipient that such additional information is available is possible through the SupplementalDocumentList in the root tag.

  • No labels