Skip to end of metadata
Go to start of metadata

Space Index

0-9 ... 0 A ... 21 B ... 3 C ... 44 D ... 42 E ... 5
F ... 3 G ... 4 H ... 10 I ... 30 J ... 1 K ... 1
L ... 7 M ... 27 N ... 4 O ... 10 P ... 16 Q ... 0
R ... 28 S ... 19 T ... 18 U ... 8 V ... 3 W ... 13
X ... 0 Y ... 0 Z ... 0 !@#$ ... 0    



Page: Abbreviations
AMEP Automated Message Exchange Protocol ACA Appointed Certification Agency AVS Allowed Value Set BP Business Profile BWARM Bulk Communication of Work and Recording Metadata CISAC Confédération internationale des sociétés d'auteurs et compositeurs, the In
Page: Access Credentials
Record companies, aggregators and DSPs work closely together with one another to make sure that Releases are available, with accurate metadata, on a DSP’s service. They also work together to ensure that usage information, particularly information that all
Page: Acknowledgements and Non-repudiation
Non-repudiation refers to a state of affairs where the purported maker of a statement will not be able to successfully challenge the validity of the statement or contract. Source: Wikipedia (accessed in April 2
Page: Active Deals at Time of Sending an ERN
When sending NewReleaseMessages to update the descriptive metadata or to provide additional Deals, the message sender is required to send all existing Deals to the DSP. In many cases this will include deals that are “live” at the moment of sending the New
Page: Adding and Removing Specific Encodings
Some Releases are made available in different encodings. A record company may for example, provide lossless encodings (e.g. using FLAC) as well as lossy encodings (e.g. using MP3 or AAC) or stereo mixes as well as multi-channel mixes side by side. Usually
Page: Adding tracks to a playlist before "street date"
An essential aspect of a deal is when the music may be made available to consumers as well as when the music may be shown to consumers (see
Page: Album Streaming
Albums cannot be streamed. When someone talks about "streaming an album" he or she is, in effect, talking about creating a play list of all the tracks of the album and then streaming each track in turn. Consequently, it is not permissible to create a stre
Page: Allowed Value Sets (aka Code Lists)
Page: Allowed-value sets and UserDefinedValues
DDEX makes heavy use of allowed-value sets (aka code lists). This is essential for automated processing of DDEX messages. There are, however, circumstances where the DDEX-defined list of allowed values does not meet a particular business need. For such ca
Page: Anatomy of DDEX RDR Messages
The DDEX RDR Message Suite uses a file format with: a file header and a resource list that contains details for each resource. Each resource can be a sound recording or a music video recording. All the data is provided as XML, using a schema and tags th
Page: ApplicableTerritoryCode vs Deal Territories
The ERN Standard allows communicating territorial differences for Releases, SoundRecordings as well as other Resources. At the same time the Deals that can be linked to those Releases and Resources which also have a territorial scope. If Releases or Resou
Page: Are ResourceGroups mandatory?
All resources are referenced from a Release in the ReleaseResourceReferenceList. This list is, however, only a "bill of material" it does not state how the resources make up the release. This is done in the ResourceGroup structure. It is therefore mandato
Page: Artist Name changes over time
to be added to Contributors, Artists and Writers Name changes over time Sometimes artists' names change over time (e.g. “Pink”>“P!ink”). If that happens it is the label's task to disseminate the change (i.e. re-deliver all those releases that are affected
Page: Artist Roles and DisplayCredits
ERN-4 as well as the RIN 1.1 file format supports rich communication of roles and credits information. This supports the presentation of "liner notes" to consumers as well as classification of what a specific Contributor did in the process of writing or r
Page: Asymmetric Web Service Architecture
In the asymmetric WebService messaging the communication is always initiated by only one partner, which is calling the WebService provided by the second partner. This leads to an increased number of messages attempting to receive a changed response. Thi
Page: Attribute Ordering
The order of attributes within an XML tag are of no significance. For instance, the two XML snippets below are functionally equivalent, even though, in the first example the xs:schemaLocation http://xsschemaLocation is located in the middle of the tag an
Page: Automated Message Exchange Protocol Standard
Introduction This standard describes how DDEX message suite standards and other data, such as content files, can be exchanged using FTP and/or Web Services. It is used in conjunction with the choreography standards associated with the message suite standa
Page: Availability and Visibility
Release Availability A NewReleaseMessage provides information about a Release, its constituent Resources and how it can be made available to consumers. The latter aspect is what is usually referred to as “a deal”. Deals are communicated in the ReleaseDeal
Page: Avoiding "Dropouts" (or: how to signal Deal changes)
Adding a new Offering Assume this scenario: A label has communicated to a DSP that a Release can be made available to consumers in a specific territory as a download from, say 1st May. Today is the 15th May and the DSP has made the Release available as in
Page: Avoiding the use of proprietary Identifiers
An efficient supply chain relies on identifiers. Ideally they are industry identifiers. However, while industry identifiers such as ISRC, ISWC, UPC etc are becoming more and more common, there are still plenty of proprietary identifiers in use today. The
Page: AVS Changes
The changes between versions 3 and 4 are: Version 4 has additional values in the AdditionalTitleType AVS: MusicalWorkTitle (to allow the communication of a work title in addition to the title of the recording in, primarily, ERN); TranslatedTitle and Trans


Page: Band Members
To communicate band members please use the ResourceContributor composite as shown for the band U2. Note, however, that the provision of the members of the band is not mandatory. <SoundRecordingDetailsByTerritory> ... <DisplayArtist SequenceNumber="1"> <Pa
Page: Bar codes of various lengths
The definition of the ICPN tag (ICPN stands for International Code Product Number and is a term used by DDEX to encompass the various bar codes used for product identification such as Universal Product Codes, UPC, European Article Numbers, EAN, Japanese A
Page: Binaries


Page: Can a Release be Identified by an ISRC?
No. The ISRC is a unique identification system for sound recordings. Sound Recordings are not Releases. Formally, DDEX defines a Release as: An abstract entity representing a bundle of one or more Resources compiled by an issuer for the purpose of distrib
Page: Can a Release contain the Same Sound Recording Multiple Times?
Yes, it can! Typical examples include Boxed Sets where a record company publishes both "original" albums and "best of" compilations together. In such cases the same Recording can be in one Release more than once. Two cases(*) need to be differentiated: Th
Page: Cancelling a Deal Before “Street Date”
In some instances it may be that a label has to cancel a deal before the street date has arrived — and sometimes this happens after the Release and its deal or deals have already been communicated to DSPs. Assuming that a Deal with a StartDate of 1st Dec
Page: Canonical Spellings for Names
There are no canonical spellings for names. The K-Pop artist known in the Western world as “Psy” is, for example, spelled 싸이 in his native language and while his name written in Korean using Hangul characters might be considered canonical as this is how
Page: Catalogue Transfers (and Identifier Persistency)
Reality When one label buys a catalogue from another label the purchasing label often has to replace the cover image – if only to replace the logo. As a consequence the release's identifier, be it a GRID or a UPC will change. Problems for DSPs and Consume
Page: Change Requests
This section of the DDEX Knowledge Base contains change requests that have been made from January 2014 onwards.(*) The individual entries contain the version of the affected standard as well as a short description of the change requests and, where an item
Page: Changes between ERN 4.2 and 4.3
Structural changes Below is a list of the structural changes between ERN 4.2 and 4.3 The namespace has been changed from to and with it the location of the XSD file on the DDEX server; ERN 4.3 makes us
Page: Changes from ERN 4.1 to 4.2
Changes to the XSD Below is a list of the changes from ERN 4.1.1 to ERN 4.2. The ERN standard now Provides enhanced support for the delivery of Releases in different encodings (e.g. stereo, binaural, Atmos, etc.) by augmenting the TechnicalResourceDetails
Page: Choosing a Delivery Choreography
After receiving the business and technical information, the content provider and DSP will configure the supply chain to accept/receive the content delivery and/or message communications. The orchestration tests could include (s)ftp server and Web Servers
Page: Choreography "Conformance"
Content owner and DSP will need to agree upon the best protocol and choreography for sending/receiving the metadata about the Releases as well as for receiving the Resource files that make up these Releases. The different options are being described in
Page: Choreography to Automate Information Exchange
DDEX defines two mechanisms to exchange DDEX messages between two business partners. As such it establishes a (reliable) "pipe" to transfer DDEX messages, other XML documents and/or files, including binaries containing, for instance, Releases or Resources
Page: Choreography to automate RDR information exchange
For details please read here... DDEX defines the mechanisms to exchange DDEX messages between two business partners. This mechanism is termed a ‘choreography’. Examples of the choreographies for the DDEX RDR Message Standards are laid out within Section
Page: Classical music in ERN-3 and ERN-4 (Examples)
Attached to this article are a number of XML documents representing two classical releases in ERN 3.8, 4.2 and 4.3. These two releases are: A classical album of Mozart’s Symphony No. 40 in G Minor (K. 550) recorded by the Wiener Philharmoniker directed by
Page: Classical Music – Genre vs Structure
The term “classical music” can have multiple meanings: “Classical music most commonly refers to the formal musical tradition of the Western world, considered to be distinct from Western folk music or popular music traditions” (Source: Wikipedia). Classica
Page: Classical Music: Genre vs Structure
Classical Music – Genre vs Structure
Page: Clip samples
Below are four samples showing how to communicate clips in ERN 4.3: Sample 1 contains one sound recording with a short preview clip. This clip is provided just as an instruction to the DSP to generate. There is no deal for this clip as it's just a previe
Page: Collecting, Paying and Claiming Music Licensing Company (RDR-R)
The message defined in the Recording Data and Rights Revenue Reporting Standard provides a uniform mechanism for the declaration of revenues generated from the usage of Releases and/or Resources to owners or administrators of rights in sound recordings or
Page: Comments
There are two ways to communicate comments in DDEX messages. Either in the <Comments> tag in the messages or using the XML's native commentary syntax <!-- … -->. Neither of these approaches are recommended to be used as such commentary is targeted at a hu
Page: Communicate Territory Information in Different Kinds of Releases
NewReleaseMessages are designed, primarily, to allow record companies and aggregators to communicate information about Releases to DSPs, and about how such DSPs can make Releases available to consumers. The NewReleaseMessage also supports cases where a DS
Page: Communicating audio and video clips such as previews and clips used for “shorts” (ERN 4.3 and later)
Short clips are a typical means to promote music. Such clips, whether they are audio or audio-visual, can be used as previews or as independent sound recordings or videos. The way they are handled depends on whether or not the clips have the same core met
Page: Communicating awards in MEAD/PIE
Whether a musician or an album has won an award, or has been nominated for an award can be useful information when marketing a release. DDEX supports both with their MEAD and PIE standards: Awards for parties To communicate that a party – be it a composer
Page: Communicating Binaries
One Binary for each Resource Composite To indicate that a binary (a.k.a. Resource file such as an AAC-encoded sound recording) is being communicated as part of a Release delivery, the Message Sender needs to provide a TechnicalDetails composite (in ERN-3
Page: Communicating Classical Releases and Resources
Basic considerations Communicating classical music has three distinct challenges: The name of the composer is often an essential piece of information needed to uniquely identify a classical work or recording. For example, “Violin Concerto in D Major” is t
Page: Communicating Display Artist(s) and Display Artist Name(s)
Display Artist Names and Display Artist roles are a major issue in Release Deliveries. DDEX's profiles define that both a Display Artist Name string, as well as each constituent artist role that is represented in a collaboration, must both be broken out
Page: Communicating Links between Resources and Musical Works
DDEX has developed a standard that provides a mechanism for companies that have established the identity of the Musical Work or Works embodied in a Sound Recording or Video recording and enable them to inform their business partners of this fact. The mess
Page: Communicating of focus tracks in MEAD/PIE
A “focus track” is a recording that is receiving significant attention at a specific point in time and is therefore a focal point for an artist. Record companies use this aspect when marketing new releases from an artist. A sound recording can be designat
Page: Communicating recording locations in MEAD
MEAD allows to communicate information about where and when music has been recorded. This can be done using the LocationAndDateOfSession composite that allows providing (all elements are optional):: The venue with, potentially, a name, a street address, a
Page: Communicating Remixe(r)s
Remixing an existing sound recording into what is often called a Remix is a common way of creating new music. Remixes comprise of significant portions of the existing (“original”) recording, augmented by new material. Remixing is a common way to rework or
Page: Communicating Stems
Increasingly, artists release not only fully-mastered sound recordings but also some of the “stems” that contributed to those sound recordings. ERN-4 allows communicating stems in two ways, depending on the approach taken by the record company and artist:
Page: Communication of Identifiers in DDEX Messages
Below please find a summary of the rules of handling identifiers in DDEX. Formatting Identifiers Different identifiers have different formats. The correct use of these identifiers is listed below. In many cases identifiers are often printed with dashes be
Page: Communication of Lyrics
Until the publication of MEAD, the only way to communicate lyrics was to use one of the messages in the ERN standard. Specifically, this was achieved by including the lyrics in a separate, secondary, resource file linked, to its “parent” recording, via a
Page: Communication of Percentages in DDEX
A number of DDEX composites allow the communication of percentage information (e.g. the RightSharePercentage composite). In DDEX messages, percentages should be communicated as numbers between 0 and 100 (e.g. “12.5” for 12.5%) rather than a decimal value
Page: Complex Deals can be Dangerous
Deals can be complex DDEX allows complex deals to be communicated with many different aspects: "Everything should be kept as simple as possible, but no simpler" (attributed to Albert Einstein)
Page: Conference Call Details - Mark
Please join the meeting from your computer, tablet or smartphone This meeting is locked with a password: MarkI You can also dial in using your phone. United Kingdom: +44 330 2
Page: Conference Call Details - Niels
Please join the meeting from your computer, tablet or smartphone. You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United
Page: Conference Call Details - Steffen
Please join the meeting from your computer, tablet or smartphone. You can also dial in using your phone. United Kingdom: +44 330 221 0097 United States: +1 (786) 535-3119 Acc
Page: Conference Call Details - Vanessa
Please join my meeting from your computer, tablet or smartphone. You can also dial in using your phone. United Kingdom: +44 330 221 0097 Access Code: 182-852-877 More phone nu
Page: Contact
If you have a question or suggestion or if you are experiencing problems with your implementation, please feel free to contact the DDEX Secretariat; we may be able to help.
Page: Contributors, Artists and Writers
Differentiating the various types of contributors and artists The indirect/musical work contributors are involved in the creation of the abstract work… i.e. the composition The resource contributors are involved in the creation of the the sound recording
Page: Core Definitions and Terminology
Core Definitions and Terminology Abbreviations Current Data Dictionary
Page: Creation Dates
The NewReleaseMessage allows communicating one CreationDate for each SoundRecording or Video. This date is typically the date on which the sound recording's mastering process ended. Consequently, the CreationDate should, in most cases, contain the same da
Page: Currency conversion in DSR and CDM
The DSR and CDM standards enable the communication of three types of monetary amounts in multiple currencies: The currency of the transaction (DSR); The currency of reporting (DSR and CDM); and The currency of invoicing (CDM). Both standards enable the
Page: Current Data Dictionary
General Index The general index contains all terms used in the latest AVS (Version 4) as well as all terms from RIN 2.0, MEAD 1.1, PIE 1.0 and RDR-N 1.5. Other standards will be added over time. Clicking on an entry
Page: Current Version of the AVS
The current version is 004. It was issued on 16th January 2023. The XSD of this latest version can be found at The data di


Page: Data Dictionary
Introduction This standard defines all the terms used in the DDEX messages including the semantics associated with them and the process by which the dictionary is updated. Below please find the current editions of the DDEX Data Dictionary as published in
Page: Data Mismatch Message Suite Standard
This standard describes a message format for alerting business partners of data mismatches. Over time the use of this standard amongst businesses operating in the digital supply chain should raise data quality. XML Schema Definition files are available he
Page: Dates in Deals are being phased out (in favour of datetimes)
ERN-3 as well as ERN-4 contains a number of fields that can communicate dates or date-times. Some of these are to communicate “historic” information: when was “Hey Jude” recorded? When was it released? These fields are typically dates and support a variet
Page: Dates: exclusive vs. inclusive
All dates are inclusive In any DDEX messages, <xxxDate> elements are indicated inclusive of the date value within the element. For instance, the ERN XML codes below shows that the release R0 is available for permanent download in Canada with price of $99.
Home page: DDEX Knowledge Base
Welcome to the primary resource for information regarding the DDEX Standards On this site you can find information on how to implement specific DDEX Standards. The areas addressed are listed depicted below. ... go to the List of Standards available from t
Page: DDEX On A Page
DDEX (Digital Data Exchange, typically pronounced "Dee-Dex") is a consortium of leading media companies, music licensing organisations, digital music service providers and technical intermediaries focused on creating standards for use by businesses in the
Page: DDEX On YouTube
Metadata: "You know you want it" Metadata.png Overview of DDEX Purpose & Governance.png 2020 Webinars Screenshot 2020-03-31 at 15.40.5
Page: DDEX Party Identifier Standard
Introduction This standard describes an identification system used to identify each sender and receiver of a DDEX message and how the identification allocation process is undertaken. Each party implementing DDEX messages is allocated a DDEX Party Identifi
Page: DDEX Party IDs (DPIDs)
Page: DDEX Standards
List of Standards available from the DDEX Knowledge Base Please note that DDEX also provides articles about various aspects of the implementation of the DDEX standards. Please click on the appropriate topic in the left panel or go to the Knowledge Base h
Page: Deal List
The Deal List provides the availability of the Releases. It describes when, where and how the releases can be made available. The Deal List provides a list of Release Deals, each having a reference back to a Release and defining the deal terms. Each Relea
Page: Dealing with uncommon use cases
The music industry is complex. There are many ways in which music is exploited and traded, especially since the methods of distributing music are constantly evolving. This means that the mechanisms for the reporting of such exploitations, DDEX calls them
Page: Deals and Commercial Aspects
Page: Deals without StartDate/StartDateTime (ERN-3 & ERN 4.1)
The StartDate or StartDateTime in the Deal composite was optional in ERN-3, ERN 4.0 and ERN 4.1; from ERN 4.2 onwards it will be mandatory. The reason for this change is that the semantics of having no StartDate or StartDateTime is ambiguous and DDEX str
Page: Definition of Terms and Allowed Values
DDEX provides naming conventions in two main areas: The XML composite and tag names, and the Allowed Value Sets. The XML is defined in the Schema files available under a link from here The DDEX Allowed Value Sets are sp
Page: Definitions and Terminology
Acknowledgement An XML message notifying the successful receipt of a Batch or File. In an FTP context this means successful ingestion. In a Web Service context in means the reply to a Web Service Call. Acquiring Aggregator/Distributor An Aggre
Page: Deprecated Cells in DSR and CDM
The DSR and CDM standards evolve over time. As part of this evolution some Record definitions are updated by (i) adding Cells to the end of a Record, (ii) changing some aspect of Cells or (iii) “deprecating” Cells. Deprecated Cells are to be treated as if
Page: Differences between ERN-3 and ERN-4
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
Page: Differentiating "Inserts" from "Updates"
The rule: NewReleaseMessages are self-sufficient Release delivery messages are - like the internet - stateless. That means that whenever information is sent, such information does not rely on previously sent information (there is one exception, see below)
Page: Differentiating versions using SubTitle in ERN and RDR-N
The SubTitle tag in ERN-4 allows the following information to be communicated: 0-n SubTitle strings (The handling of different languages is handled on Title level, see also the relevant section below)); An optional SubTitleTag attribute for each subtitle
Page: Digital Sales Reporting Choreography
Page: Digital Signatures Standard
This standard describes how DDEX messages can be signed so that a recipient knows they have received a message in its entirety and that it has not been corrupted in transit.
Page: Direction of writing
Mono-directional text Different languages have different directions of writing. In the western world most languages write Left-to-Rights (or LTR). However, a good number of languages/scripts are Right-to-left, or RTL). They include: Arabic and Hebrew. The
Page: Display Titles in RDR
The concept of a “display title” has been introduced into the DDEX ecosystem via the Electronic Release Notification (ERN) message suite standard. It is used by record companies to send information to online retailers on how the record company prefers tit
Page: DisplayArtist? DisplayArtistName? Contributor? IndirectContributor? What is this all about?
Artists play different roles in a recording. Artists also have different contractual entitlements when it comes to being named (and being paid[1] #_ftn1). In addition, a label may wish to specifically promote certain artists. To support these aspects, DDE
Page: DisplayArtistNames for Releases and Resources
Display Artist composite and Display Artist Name element DDEX messages allow for the communication of the "main artist" – i.e. the artist name that is shown in big letters on the product sleeve. This information can be provided in two ways: DisplayArtist
Page: Displaying Artists for Remixes [ERN-4 only]
ERN-4 now better supports how artists are communicated in remixes. The XML sample below shows two remixes, made by Johnny "Remixer" Smith of a recording by Peter Miller. In the example below we have two display artists, Johnny Smith and Peter Miller. Smit
Page: Displaying Deal Dates to Consumers
The NewReleaseMessage communicates information about sound recordings, videos, releases and artists that enable DSPs to market such creations. This includes Information the DSP may display to consumers (titles, names, etc.); and Data about the commercial
Page: Do DPIDs have hyphens?
It depends. The canonical form of a DPID is without a hyphen. Hence DPIDs should be used, in DDEX messages, without hyphens: <PartyId>PADPIDA3897722461G</PartyID><PartyId>PA-DPIDA-3897722461-G</PartyID> However, for human consumption hyphens may be added.
Page: Do not use CDATA to concatenate Data
The following code block is not correct. <ResourceContributor> <PartyName> <FullName> <![CDATA[Anne Sofie von Otter [Contralto] & Susan Addison [Trombone] & Barbara Bonney [Soprano] & Hans Peter Blochwitz [Tenor] & Sir Willard White [Bass] & English Bar
Page: DoNotDisplayDates (ERN 4.3 and later)
ERN 4.2 saw the introduction of two composites that enable a record company to signal to DSPs the date on which they may show to consumers the existence of an album which is to be released at some point in the future. These composites include the album’s
Page: DPID Registry
Registry of all DDEX Party Identifiers
Page: Drafts Home
This is the home of the Drafts space. To help you on your way, we've inserted some of our favourite macros on this home page. As you start creating pages, blogging and commenting you'll see the macros below fill up with all the activity in your space. Nav
Page: DSR and CDM messages exported from spreadsheet applications
DDEX’s flat file standards such as the DSR and CDM standards require that each Record that makes up part of a message created in accordance with the relevant standard, contains the specific number of Cells defined in the standard, even if some of those Ce
Page: DSR Audio-visual Profile
DDEX Flat-file Sales Usage Reporting Standard Part 1: Architecture Part 2: Allowed Value Sets Part 5: Audio-visual Profile Part 8: Record T
Page: DSR Basic Audio Profile
DDEX Flat-file Sales Usage Reporting Standard Part 1: Architecture Part 2: Allowed Value Sets Part 3: Basic Audio Profile Part 8: Record Typ
Page: DSR Basic Audio Profile for The Mechanical Licensing Collective
DDEX Flat-file Sales Usage Reporting Standard Part 1: Architecture Part 2: Allowed Value Sets Part 8: Record Type Definitions Part 11: Basic
Page: DSR Masterlist Profile
DDEX Flat-file Sales Usage Reporting Standard Part 1: Architecture Part 2: Allowed Value Sets Part 8: Record Type Definitions Part 10: Master
Page: DSR Profile for Financial Reporting to Record Companies
DDEX Flat-file Profile for Financial Reporting to Record Companies Part 1: Architecture Part 2: Allowed Value Sets Part 8: Record Type Definitions
Page: DSR Radio Broadcast Profile
DDEX Flat-file Sales Usage Reporting Standard Part 1: Architecture Part 2: Allowed Value Sets Part 7: Radio Broadcast Profile Part 8: Record
Page: DSR Royalty Reporting Profile
DDEX Flat-file Sales Usage Reporting Standard Part 1: Architecture Part 2: Allowed Value Sets Part 6: Royalty Reporting Profile Part 8: Rec
Page: DSR UGC Profile
DDEX Flat-file Sales Usage Reporting Standard Part 1: Architecture Part 2: Allowed Value Sets Part 4: UGC Profile Part 8: Record Type Defini


Page: ERN Message without Resources
An ERN feed containing a NewReleaseMessage but no Resource file is valid. In most situations, a DSP should receive binaries with the initial NewReleaseMessage but, especially when communicating pre-order Releases, this may not always be the case. DSPs mu
Page: ERN Messages as a “Statements of Truth”
ERN Messages are “Statements of Truth[1]”. This means that a sender of a NewReleaseMessage must always include all relevant information in the message, including all metadata and all active and future deals that it has communicated in the past. This means
Page: ERN WG Conference Call Details
Please join the meeting from your computer, tablet or smartphone. You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) U
Page: Evaluation Licence for DDEX Standards
Subject to your compliance with the terms and conditions of this Agreement, DDEX™ grants you a limited, nonexclusive, non-transferable, non-sublicenseable, royalty-free licence solely to reproduce, distribute within your organisation, and use the DDEX sta
Page: Excluded Territories and Worldwide
The Deal composite in the ERN standard allows communicating a list of countries in which a deal applies. This list can be provided in one of two tags, TerritoryCode and ExcludedTerritoryCode. Both of these tags can be populated with ISO territory codes as


Page: Field Length and Precision
Many companies in the music industry use relational databases that have limitations on the length of strings that can be stored efficiently. In addition, applications – whether b2b applications such as a record company’s label copy system or a DSP’s conte
Page: File naming convention for Masterlist Reports
The file naming convention for all DSR files is structured as follows [LINK]: DSR_MessageRecipient_MessageSender_ServiceDescription_MessageNotificationPeriod_TerritoryOfUseOrSale_xofy_MessageCreatedDateTime.ext Unfortunately, this structure means that w
Page: Frequently Asked Questions
Implementers of DDEX standards sometimes have questions regarding some of the fields (or tags). The most common issues are discussed here:


Page: GDPR and UGC
The UGC profile requires that the DSP sends information about UCG resources that consumers have created and uploaded to the DSP’s service for distribution to other consumers. This is communicated in an RU record defined in the UGC profile of the DSR stand
Page: Generating and Processing ERN Batches
When a record company or aggregator wants to add a Release into a new batch of Releases to be communicated to a DSP, the record company or aggregator needs to ensure that that the batches containing that Release are closed in the exactly the same order th
Page: Genres
DDEX does not standardise genres. Every so often a new proposal is made to attempt genre specification – and each time, DDEX experts have determined that this would be not a good idea. Some of the reasons are: Genres differ from territory to territory ("W
Page: Guide to Territorial Variations in the SoundRecordingDetailsByTerritory Composite in RDR-N (v 1.5)
Introduction Within the DeclarationOfSoundRecordingRightsClaimMessage of the RDR-N Standard, the SoundRecordingDetailsByTerritory (SRDBT) composite within ResourceList/SoundRecording composite can be repeated to indicate territorial differences. The type


Page: Handling Conflicts
The RDR standards allows record companies to provide rights claims or mandates to music licensing companies. The standard also allows music licensing companies to “forward” such claims/mandates to other music licensing companiess. There are cases where an
Page: Handling long titles and special characters in the DSR, CDM and RDR-R standards
Receiving a message with, say, a sound recording title that exceeds the field length restrictions in a recipient’s systems, can be problematic. However, a recipient’s system limitations should not force the sender of the message to such a recipient to sho
Page: Handling of Tracks that are “not cleared”
Record companies or aggregators sometimes ask DSPs to make available a Release even if some tracks on that Release are not (or not yet) available to consumers. This case can easily be communicated before “street date” (i.e. the date a Release is allowed t
Page: Handling “immersive audio”
From Stereo/Surround to Immersive An increasing number of audio recordings are produced not only in stereo and surround sound but also in “immersive audio” which positions sounds over the half- or full-sphere. The production of these recordings requires s
Page: Handling “odd” characters
Artist names and song titles can be written in different scripts, from Thai and Cyrillic to Kanji to Roman and Greek – but they can also contain glyphs that are not part of any common script. Examples include “the symbol” used by the artist formerly known
Page: Hidden Sound Recordings
"Hidden Tracks" are not meaningful for online trading and DDEX recommends that they should not be used. However, when a physical album is being digitised and made available in an online environment, it may be ne
Page: Hidden....
Page: Hints for Implementing RIN
Page: How long can artist names and titles be?
DDEX does not impose an upper limit. But senders of messages are advised that recipients databases may well impose a limit and, thus should only send long names and titles if necessary Artificially long titles, including multiple subtitles as part of the
Page: How many DPIDs Do I need?
Contact Purpose of DPIDs In order to use any DDEX standard, a company needs to have taken out an implementation licence The licence is free (as in free beer) and can be applied for on the DDEX website htt


Page: Identification of Chapters
Chapters are used to split a long-form video into sections. A typical example for this is the separating out of the individual songs that are performed in a concert video. In order to enable DSPs to report usage on a chapter level, the DSP requires data a
Page: Identifiers and ISO Codes Lists
Page: Identifiers for Resources, Releases and Parties
DDEX supports the communication of different identifiers for different purposes. Below please find a table of permissible identifiers for some of the entities: Sound Recordings Videos Releases Parties ISRC ISRC GRid DPID ISAN ISRC (see below) ISNI V-I
Page: Images for Box Sets
For (nearly) all Release types defined in the Release Profile standard one cover art image needs to be communicated. This also applies to box sets. However, in most cases a box set is accompanied by one image for each of the "constituent albums" plus one
Page: Impact Date
One of the crucial aspects of the MEAD standard is that it allows a record company to communicate an “impact date” (i.e. the date when a track started receiving a significant amount of airplay) to a DSP. Impact dates are especially useful for helping musi
Page: Implementation: Message Header
The Message Header indicates the sender and recipient of the Message. The sender and recipient are each named and defined by a unique DDEX Party ID (DPID). The Message Header also provides a date & timestamp of when the message was created. <MessageHeade
Page: Implementation: Message Notification Period
This composite can appear in various places, as described below. It describes the time period to which the message content is relevant. <MessageNotificationPeriod xmlns=""> <StartDate>1985-01-01</StartDate> <EndDate>2017-05-03</EndDate> </MessageNotifica
Page: Implementation: ResourceList
For details please read here... Following the MessageNotificationPeriod is the ResourceList, which forms the body of the RDR-R message. The ResourceList contains one or more SoundRecording or Video composites. The box below illustrates the ResourceList
Page: Implementation: SoundRecording
Each SoundRecording composite itself comprises two main sections of information, firstly details at the SoundRecording level, which are invariant across territory; then one or more SoundRecordingDetailsByTerritory composites containing territory-specific
Page: Implementation: SoundRecordingDetailsByTerritory (v 1.3)
For details please read here... Each SoundRecording node must include one or more SoundRecordingDetailsByTerritory nodes. The first SoundRecordingDetailsByTerritory node includes data which would apply for this SoundRecording in all territories as a defa
Page: Implementation: SoundRecordingDetailsByTerritory (v 1.4)
Each SoundRecording node must include one or more SoundRecordingDetailsByTerritory nodes. The first SoundRecordingDetailsByTerritory node includes data which would apply for this SoundRecording in all territories as a default, unless specifically overridd
Page: Implementation: SoundRecordingDetailsByTerritory (v 1.5)
Each SoundRecording node must include one or more SoundRecordingDetailsByTerritory nodes. The first SoundRecordingDetailsByTerritory node includes data which would apply for this SoundRecording in all territories as a default, unless specifically overri
Page: Implementation: XML Declaration
The DDEX RDR-N Message must begin with an XML Declaration. <?xml version="1.0" encoding="utf-8"?> <DeclarationOfSoundRecordingRightsClaimMessage xmlns="" xmlns:xsi="" xmlns:xsd=http://www
Page: Implementing Catalogue Transfers
This section of the Knowledge Base is aimed at explaining how to implement catalogue transfers to technical implementers as well as operational personnel. Before starting an implementation, DDEX recommends to read Starting an Implementation and Licensing
Page: Implementing DDEX Standards
This section of the DDEX Knowledge Base is intended to guide users to implement specific standards. Over time DDEX expects to cover all its (main) standards here. Content: Contact
Page: Implementing Media Enrichment and Description Information (MEAD) and Party Identification and Enrichment (PIE)
One main part of the music industry supply chain is the delivery of Resource, Release and product information from Release Creators – typically record companies – to Release Distributors – typically DSPs. This information flow can happen either direct or
Page: Implementing Recording Data and Rights Standards
This part of the DDEX Knowledge Base describes the DDEX RDR Message Suite Standards. This suite of standards was previously known as the Music Licensing Company Message Suite and Choreography Standard or MLC Standard. With the creation of the Mechanical L
Page: Implementing Release Deliveries
This section of the Knowledge Base is aimed at explaining how to implement and use the DDEX standards for Release Deliveries – typically sent from record companies to online retailers/digital service providers – to technical implementers as well as operat
Page: Implementing Sales and Usage Reporting
DDEX Flat-file Sales Usage Reporting Standard Part 1: Architecture Part 2: Allowed Value Sets Part 3: Basic Audio Profile Part 4: UGC Profil
Page: Implementing the Claim Detail Message (CDM)
The Claim Detail Message Suite Standard (CDM) provides (i) a format (the Claim Detail Message) for a response to a sales/usage report received by an owner/administrator of Musical Works which sets out the claim each owner/administrator is making in resp
Page: Implementing the Recording Information Notification
The process of creating a recording is complex and iterative, with many production stages between capturing sound and releasing a finished recording. Every stage in this cycle can lead to new audio creations, be they a new composition, a new guitar track,
Page: Implementing Works Notification and Licensing Standards
DDEX's musical works standards provide a suite of messages that give a uniform mechanism to enable companies to exchange information on claims of ownership of musical works embedded in Releases, and to request and to be granted licenses for using such mus
Page: Importing RIN Files into RIN Files
The process of recording music is iterative and often involves different “sessions” with different contributors in different locations. Ideally each of these sessions will lead to two outputs: a set of audio files containing the recorded music and a RIN f
Page: Index
Page: Instrument Information in MLC 1.3 and 1.3.1
The RDR standard allows for the communication of the role of contributors to sound recordings and music videos and, where appropriate, information about the instrument or instrument(s) played. For details please read here... This article discusses MLC 1.
Page: Instrumental Music
Not all music contains singing. But there are a number of different types of what can be termed “instrumental” music. Below is a table with the recommended way of signalling different cases using the IsInstrumental and LanguageOfPerformance tags in the ER
Page: Introducing DDEX
This section of the DDEX Knowledge Base addresses questions about DDEX itself, its mission and purpose. Content: Contact
Page: Invalid Messages
Recipients should reject any DDEX message that is invalid. This includes: Messages that do not parse against the relevant XML Schema Definition file. Messages that violate the rules of the profile or profiles indicated in the messge (exceptions may be spe
Page: Is a NewReleaseMessage with no Deal valid?
In Release Deliveries from Label to DSP Yes it is. While it is technically valid, all NewReleaseMessages must contain a Deal composite. The only exception to this rule are NewReleaseMessages that indicate a takedown. In feeds to Metadata companies, chart
Page: Issues Tracker
DDEX is tracking all (well: most) of its work items, large or small, in a issue tracker. The issues are listed below. There are lists for various areas of standardisation: Release deliveries Sales and usage reporting Issues regarding the communication amo


Page: Java Library's Date Bug for 2020
We were alerted to a bug in Java’s date library: twitter.png More details can be found at


Page: Keywords
The ERN standard allows communicating keywords for Releases and Resources. Keywords can be used to enhance user experiences by furnishing DSPs with information they can use when displaying the content as well as for music searches. To provide two or more


Page: Licensing DDEX Standards
Introduction The Digital Data Exchange (DDEX), a standards-setting organisation for the global media industries, has developed a series of standards aimed at reducing the cost of managing and communicating metadata and content across the digital media sup
Page: Limitations of Proprietary Identifiers
Companies in the music industry supply chain make wide use of standard identifiers when communicating data to their business partners. Within company databases, proprietary identifiers may also be used for such purposes as distinguishing different encod
Page: Linking different Releases and Resources
Releases and Resources such as Sound Recordings do not exist in isolation. Increasingly recordings make use of other recordings and multiple Releases are created from a single recording project or studio session. The NewReleaseMessage has always been able
Page: List of DDEX Standards
Standard Status Release Deliveries Release Profiles for Common Release Types Increasingly widely used for communications from record companies to DSPs Business Profiles for Common Deal Types ERN Choreography Standard Choreography for the Transfer of Catal
Page: List of Standards available from the DDEX Knowledge Base
Core Definitions and Terminology Below please find a list of the current version of the various DDEX standards. Current Versions Best Practice Documents Old Versions Old Versions of DDEX Standards
Page: LiveStream
Over the last few years, UGC video services have started to allow their content creator users to “go live”, i.e. to record a video and stream it to their “followers” at the same time. Once the live event has finished, the recorded video usually continues
Page: Locations of XSDs
The XML Schema files for all DDEX standards are available in two forms: Zip Archive Implementers can download a zip archive with all relevant XML Schema definitions from the same page where the relevant standard itself is available for download. These fi


Page: Malformed Identifiers
Most standard identifiers communicated in DDEX messages have a well-documented syntax. ISRCs, for example, are made up of two characters (the country code), followed by three alphanumeric characters (the registrant code), two digits (the year of reference
Page: Mark's Conference Call Details
Primary dial in number 0845 634 0049 (Local UK) Participant Code: 8092418# Alternative dial-ins: 0207 965 211 Amsterdam Local 021 2375 5074 Ankara Local 0800 444 1956 Argentina Freephone 021 1181 3889 Athens Local 09 919
Page: Marks NEW Conference Call Details
Call-in Details Dial in using one of the numbers on the right Enter conference ID: 30128262# Follow audio instructions PIN 30128262# Phone Numbers Argentina 011 5983 9523 Australia 02 8014 4750 Austria 0720 883384 Bahrain 16199321 Belgium 02 588 5
Page: MEAD as a “Statement of Truth”
The messages defined by all DDEX standards are stateless; they provide “statements of truth”, i.e. 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 MEAD. Howeve
Page: MEAD Information for a Taken-down Release
If a record company sends a MeadMessage as part of an ERN message feed to a DSP, and if all deals for all Releases communicated in that feed have expired (incl. via a takedown message), then the DSP in receipt of that MeadMessage may no longer use the dat
Page: MEAD or PIE Messages as Secondary Resources in an ERN Feed
One rule of the ERN Choreography is that when one primary Resource file (e.g. the resource files that make up the “essence” of the Release) is to be sent as part of an ERN message, all primary Resources are to be sent. Similarly, when one secondary Resour
Page: Media Enrichment and Description (MEAD)
Introduction DDEX’s Standard for Release Deliveries (ERN) enables record companies to send musical products to DSPs who are thereby enabled to make them available to consumers (notwithstanding any obligations to other rights holders). ERN is designed to c
Page: Message Exchange (FTP)
DDEX RDR Messages are exchanged using file transfer protocol. In fact Secure File Transfer Protocol (SFTP) is preferred because it encrypts both the command that execute the file transfer, as well as the data being transferred. For details please read he
Page: Message Exchange and Choreography
Page: Message Header
The Message Header indicates the sender and recipient of the NewReleaseMessage Message. The sender and recipient are each defined by a unique DDEX Party ID (DPID). The Message Header also provides a creation date which is a timestamp of when the message w
Page: Metadata "Conformance"
During the integration phase, the content provider and DSP will need to conduct a "peer conformance procedure" where the content owner determines if the DSP is able to receive and ingest the content according to the provided test packages and the DSP
Page: Metadata in different languages
DDEX standards allow to include an XML attribute called LanguageAndScriptCode on most free-form string fields as well as composites that contain free-form string fields. The definition of this field is "The Language and script […] as defined in IETF RfC
Page: Miscellaneous
Page: Mixing classical with popular music
Signalling the presence of a classical resource (ERN-3 and ERN 4.0-4.2) To indicate that a NewReleaseMessage contains at least one resource that is “classical in nature” the following rules are defined in the relevant release profile standards: For ERN-3,
Page: Mood in MEAD
MEAD is a standard to communicate “rich” metadata about sound recordings, releases and musical works. (PIE is a similar standard for “rich” information about musicians and other parties involved in creating and marketing the music). Two aspects of this ri
Page: MRBV vs SRBV
Some DSR Profiles come in two variants: a Multi-Record Block Variant (MRBV) where the detailed sales and usage information is provided in multiple Records (e.g. one Record for the transacted release, one Record for each of the sound recordings and musical
Page: Multiple CommercialModelTypes or UseTypes in one Deal
The examples on this page use the syntax of ERN-3. The only difference for ERN-4 would be the order of the subelements of DealTerms. When communicating Deals it is crucial that record companies include values that are as precise as possible – especially f
Page: Multiple consecutive Deals
Record companies sometimes require that a DSP makes available a Release under terms and conditions that may change over time. For example, the recommended retail price may change before, during, or after a specific event (Christmas, a sports event, etc).
Page: Multiple Data Dictionaries
One of the most important aspects of DDEX is that it provides a common language for all the terms that are used in any music related business transaction. This common language is documented in the "DDEX Data Dictionary". Somewhat counter-intuitively, ther
Page: Multiple Deals for one Release
When communicating two Deals for the same Release please use this syntax shown on the left (i.e. two Deals in one ReleaseDeal) and not the one shown on the right: <ReleaseDeal> <DealReleaseReference>R1</DealReleaseReference> <Deal> <DealTerms> <Usage> <
Page: Multiple Identifiers for Multiple Parties
Party Names and Party Identifiers Some records in the DSR and CDM standards allow to report multiple parties, this happens for instance in MW01 records with the need to send multiple writers, this fields would generally be broken down into two cells: One
Page: Multiple Proprietary Identification Systems
All DDEX messages allow the communication of proprietary identifiers in addition to standardised and widely-used industry identifiers such as ISRCs for recordings, ISWCs for musical works and ISNIs for parties. The syntax to communicate such proprietary i
Page: Music licensing companies
The collective management of neighbouring rights is concerned with remunerating the producers of recordings and/or performers when their recordings are used in specific ways. The usage types under collective management typically include radio and TV broad
Page: MWN and the Common Works Registration (CWR)
The functional specification document for the Common Works Registration defines the reason for creating CWR: "The purpose of the Common Works Registration (CWR) format is to provide publishers and societies with a standard format for the registration of w
Page: MWN Request
The MusicalWorkClaimRequestMessage allows a licensee to request information on musical work(s) from a licensor. In this example a record company requests information from a music publisher.. When creating the request, a requestor should include as much in
Page: MWN Response Providing a Claim
The MusicalWorkClaimNotificationMessage allows a licensor to respond to a MusicalWorkClaimRequestMessage with information on musical work(s). Response Overview The licensor has an interest in the requested work, and will describe its interest in the res
Page: MWN Response Providing a Claim with Co-Ownership
The MusicalWorkClaimNotificationMessage allows a licensor to respond to a MusicalWorkClaimRequestMessage with information on musical work(s). The licensor has an interest in the work, and will describe its interest in the response. This is a rather more c


Page: Namespace and File Locations for the XSD for Allowed Value Sets
All DDEX XML Standards are expressed, besides the textual description, by an XML Schema Definition file (XSD). Each of these message XSD files is uniquely identified with a namespace in the form of a URI. For ERN 4.1.1 this namespace is
Page: New on
Page: No Data for Mandatory Fields
A number of Cells are marked as being “mandatory” in the DSR and CDM standards. This is because the information from these Cells is essential for the recipient in fulfilling their business function in the music industry value chain. One such example are
Page: No Takedown in Initial Deal
Latest NewReleaseMessage contains the active Deal Deals in subsequence NewReleaseMessage override each other. In other words when a DSP receives a set of Deals in a NewReleaseMessage (and enacts them) and then receives a further NewReleaseMessage for the


Page: Old Versions of DDEX Standards
Here you can find the old version of DDEX Standards. DDEX recommends to always implement the latest version but sometimes users require access to an older version (e.g. for debugging or maintaining an implementation based on an older version, or even for
Page: Older versions of Works Licensing and Works Notification Standards
This page contains standards that have been superseded by newer versions of the same standards. DDEX strongly recommends to always implement the latest version of the relevant DDEX Standards and to regularly update any implementation to work with the curr
Page: One artist with two roles
The following XML snippets each expresses a different reality: <ResourceContributor> <PartyName> <FullName> John Smith </FullName> <PartyName> <ResourceContributorRole> Soloist </ResourceContributorRole> <ResourceContributorRole> Producer </ResourceContri
Page: Open Change Requests
The tables below contain change requests that have been made from January 2014 onwards that have not yet been resolved completely.
Page: Open Source Software
DDEX is a standards setting organisation - and its main output are specifications in the form of text documents, XML Schema Definition files and XML sample files. DDEX thrives on implementations being created by companies and individuals and some of these
Page: Opus and Composer Catalogue Numbers
Typically a classical composer's works are numbered using Opus numbers (opus being the Latin expression for “work” or “labour”) in, usually, chronological order. They allow the differentiation of one work by a single composer from all the other works of t
Page: Order of ERN Processing
DDEX has defined three different protocols by which various different entities (usually record companies or aggregators) can communicate ERN messages to their business partners. These are: Web services; Release-by-Release via SFTP; and Batched SFTP. The o
Page: Origin and Trustworthiness of MEAD and PIE information
MEAD and PIE standards that allows a DSP (or other company) to collate information about a musical work, sound recording, release or an artist from different sources. The DSP would then want to combine this information into a complete picture about the mu
Page: Original Release Date, Release Date and other Dates
The original Release Date is what enables a DSP to appropriately catalogue a track or album and put them into chronological order in which they were released. The following dates can be communicated: For a Release ReleaseDate – the date where the Release
Page: Ownership Claims for Single Resource Releases in ERN
DDEX recommends the use of the RDR standard to communicate rights claims to music licensing companies. The NewReleaseMessage has two places where rights and ownership information about a sound recording or other Resource can be communicated. Such ownershi


Page: Party List (ERN-4 only)
One of the main differences between ERN-3 and ERN-4 is the introduction of a PartyList. Akin to the ResourceList, it allows the label to collate all artists, musicians, writers and labels into a single list and then reference these parties from Releases a
Page: Party WG Conference Call Details
Please join my meeting from your computer, tablet or smartphone. You can also dial in using your phone. United Kingdom: +44 20 3713 5028 Access Code: 570-730-997 More p
Page: PLine and CLine
DDEX messages can provide P and C lines for different entities. While both have the same structure, they have different legal meaning. Background - ℗ and © Notices The Ⓟ Notice The purpose of a ℗ notice is to signify that rights exist in a sound recording
Page: Podcasts
Podcasts are becoming more and more common. DDEX is in the process of agreeing how to communicate podcasts in all of its messages. In the meantime, the approach currently recommended for reporting podcast usages in the DSR standard is to use a user-define
Page: Preambles for XML-based DDEX Messages
All XML files based on an XML Schema Definition (XSD) have a "preamble". This preamble points to the XSD that is used to validate the XML file. This also applies to all XML based DDEX messages and files. Below is a valid preamble for a NewReleaseMessage c
Page: Preview Resources
Previews are special resources that are used to provide users with a track to sample – with the hope that the consumer will buy (or otherwise pay for the) full track or album. In many cases previews are short snippets from the "full" track. Signalling th
Page: Previews
Page: PriceInformation
ERN-4 In ERN-4 some of the pricing fields have been removed as they were no longer in use. The PriceInformation composite within the DealTerms now contains all pricing information, including PriceCode which replaced the PriceRangeType and PriceType. The p
Page: Primary and Secondary Resources
The NewReleaseMessage distinguishes between "primary" and "secondary" Resources. The former are "Resources that are a main Resource of a Release" whereas the latter are "Resources that are not a main Resource of a Release supporting the Primary Resources
Page: Priorities for Metadata Items
There are cases where different flavours of essentially “the same” data apply to a musical work, a musician, a recording or a Release. The name of the Russian composer Dmitri Shostakovich, for example, can be provided in Russian as Дмитрий Шостакович, in
Page: Product Deliveries using FTP
File Transfer Protocol (FTP) is the standard protocol for transferring files to and from remote machines running FTP service. FTP offers less interactivity for the communication between labels and DSP. Secure File Transfer Protocol (SFTP) is similar to FT
Page: Product Deliveries using Web Services
Introduction DDEX provides the ability to use web services for delivery of the metadata and also for communication between partners. There are many useful calls that cover the following capabilities: Well defined messaging interface between the sender's a
Page: Product Types in Titles
The Subtitle element should not be used for commercial information such as "Exclusive to ServiceX".
Page: Profiles for Specific Use Cases
DDEX has defined a uniform message for the communication of Release details, including information about their parts, i.e. Resources (such as SoundRecording or Videos) and, in some circumstances also Musical Works from Release Creators (typically: record
Page: Proprietary Identifiers
When using proprietary identifiers, the sender needs to be able to provide a namespace attribute to signal which organisation the proprietary identification is controlled by (as the organisation may not be the one allocating or sending the message). Thus,
Page: Public Domain Works in ERNs
Most of the musical works and sound recordings for which metadata is communicated between business partners, using the ERN standard, is owned by one or, typically, multiple rights holder(s). This applies to both the rights in the recording and the rights



Page: Rationale of the DDEX RDR Message Suite Standards
The DDEX RDR Message Suite Standards are relevant for the communication with and between music licensing companies. In the past, a variety of different and largely incompatible formats were used with and between music licensing companies. The DDEX RDR M
Page: RDR Implementers’ Contacts List
This article provides companies that are planning to implement the Recording Data and Rights (RDR) standards or those who are currently in the process of implementing them the possibility to contact companies that have already gone through this process an
Page: Recommended use of CommercialModelType and UseType in ERN-4
Introduction Sections on this page In order to support the many ways in which companies can express how a Creation may be used or has been used, DDEX Standards such as ERN use two key allowed value sets – CommercialModelType and UseType – to provide users
Page: Reference Material
This section of the DDEX Knowledge Base provides reference material regarding DDEX standards Contact
Page: ReferenceTitle of a SoundRecording
The ReferenceTitle of all SoundRecording elements must, in ERN-3, represents the track title and not the title of the album which contains the track. Likewise, in Track Releases (i.e. where the ReleaseType is TrackRelease), the ReferenceTitle represents
Page: Referencing Composites using ID and IDREF
Untitled.jpg XML allows for two mechanisms that can be employed to express a relationship between two entities: embedding and referencing. The difference is shown on the right. DDEX uses both mechanisms. Referencing is used typically when a composite may
Page: Registering Compilations in RDR-N (v 1.5)
Introduction In certain territories, there is a requirement to report sound recordings which were released on a compilation based on unit sales and duration of tracks, typically but not exclusively for the payment of private copy levies. For some music li
Page: Registry of all DDEX Party Identifiers
Background Each entity that takes out an DDEX Implementation Licence will be allocated a DDEX Party Identifier (DPID) in accordance with the DPID standard
Page: Release and Resource Metadata
Page: Release Delivery Standards
The following standards have been developed by DDEX to support the process of labels delivering Releases to DSPs. They are: Older versions of the Release Delivery Standards can be accessed here
Page: Release List
The Release List section defines the different releases that make up the "product" being delivered. For example, a standard ten-track album will contain one album release and 10 track releases, for a total of 11 Releases. The album level release is typica
Page: Release Types for TrackReleases
In the ReleaseList of ERN-3, it is in many[1] cases not only correct but mandatory to include multiple Releases: One to represent the main release and One for each track on the release (the so-called "Track Releases"). The Main Release is identified by th
Page: Repertoire, Data and the RDR Message Suite Standards
Music licensing companies manage data relating to the administration of the rights in the recordings which are owned by their members. More specifically, music licensing companies administer rights in what are known as eligible recordings. This includes r
Page: Reporting of Release based Royalties
2016-11-28 11.28.42 am.png Typical use for this block includes the reporting of Physical releases Bundle downloads etc… Each block for release based royalties is made of: One release record At least one resource record giving details about the resources i
Page: Reporting of Resource based Royalties
2016-11-28 11.24.56 am.png Typical use for this block includes the reporting of Single track downloads Recording / video streams etc… Each block for resource based royalties is made of: One resource record giving details about the resources included in th
Page: Reporting of User-generated content based Royalties
2016-11-28 11.27.30 am.png Typical use for this block includes the reporting of user-generated content. Each block for release based royalties is made of: One resource record giving details about the resources included in that release for which royalties
Page: Reporting Sales/Usages for Individual Tracks (e.g. for Streaming Deals)
Streaming services should be using the Basic Audio Profile for reporting the usages of music on their service to musical works licensors. This is defined in Clauses 5.2 and 5.3 of Part 3 of the DSR standard [LINK]. These two clauses explain two different
Page: Requesting and Receiving Right Share Information
The Musical Work Notification request/response choreography supports a number of use cases. These include: A licensee requesting information on a licensor's claim(s) to musical work(s) A licensee wanting to augment and enrich the data they have on musical
Page: Resolved Change Requests
The tables below contain change requests that have been made from January 2014 onwards that have been resolved.
Page: Resource Groups and Track Releases
Track Releases need to be communicated in each NewReleaseMessage. In ERN-3 all Releases – whether album Releases or whether Track Releases – are described in the same way. And this means that while a TrackRelease can only contain one primary Resource, it
Page: Resource List
The Resource List provides details of the different assets that make up the entire release. Typical resources are sound recordings, videos and images. Each resource will have a unique reference anchor within the message (e.g. A1, A2, A3) which corresponds
Page: Resource Types
DDEX messages allow categorising Resources in several ways: Firstly by separating sound recordings from videos, MIDI resources(*), images, text resources, pieces of software and sheet music. Each of these resource types have different attributes (e.g. a
Page: Resource-specific Previews
In many cases a Release Creator wishes to communicate previews for some (or all) of the resources contained in a release. To effect this, two things need to be done: Firstly, for each sound recording there have to be (at least) two binaries. Details on ho
Page: Rights Controller Information in ERNs to music licensing companies
DDEX recommends the use of the RDR standard to communicate rights claims to music licensing companies. DDEX messages support different types of Rights Controllers. This article deals with companies that control rights in sound recordings. More information
Page: RightsClaimPolicy (update in v3.8.1 and ERN-4)
In the NewReleaseMessage it is possible to communicate a RightsClaimPolicy. Its structure has changed between different versions of ERN and users should be aware of these differences: In versions 3.7, 3.7.1 and 3.8, a RightsClaimPolicy comprises of one ma
Below is a list of frequently asked questions on the Recording Information Notification (RIN). If your question is not answered, please get in touch with DDEX Recording Information Notification (RIN) is a standard for the stru
Page: RIN Implementations
Current RIN compliant software of which DDEX has been made aware is listed here: RIN implementations are currently included among audio plug-in, desktop app, web i
Page: Role Code Synonyms and Credits
DDEX standards make extensive use of “allowed value sets” (AVS), i.e. controlled lists of well-defined terms. Typical examples are currency and territory code lists (that DDEX imports from the relevant ISO standards) and classifications for how consumers


Page: Sales/Usage Reporting
Page: Same Recording with Different Metadata
The SoundRecording composite in an ERN message is “Release specific”. This means that there is the possibility that some of the metadata for a recording might be different between different Releases — despite the recoding carrying one identifier. One ex
Page: Semantics of LineupComplete
MLC versions 1.3 and 1.4 allow signalling for a SoundRecording whether the line-up for that recording is complete. The flag for this is called LineUpComplete. This flag signals that the Message Sender believes that it has a complete list of all performers
Page: Semantics of repeating XML tags
DDEX messages allow, in certain places, to place the same tag, with different content, side-by-side. For example: <UseType> Download </UseType> <UseType> PerformInPublic </UseType> This XML snipped changes it's semantic depending whether it is an instru
Page: Sequencing Recording Artists and Writers
DDEX allows to sequence artists using the SequenceNumber attribute which is available on various composite, including DisplayArtist, ResourceContributors and IndirectResourceContributors. The code bloc below shows its use on the DisplayArtist composite. T
Page: Sequencing Resources
<ResourceGroup> <ResourceGroup> <Title TitleType="GroupingTitle"> <TitleText>Component 1</TitleText> </Title> <SequenceNumber>1</SequenceNumber> <ResourceGroupContentItem> <SequenceNumber>1</SequenceNumber> <ResourceType>SoundRecording</ResourceType> <Rel
Page: Should I use an ISRC as the primary key for my database?
No. While ISRCs are the preferred identifier for identifying sound recording when communicating about releases and contained resources, they are not able to be used as primary keys in anyone's database.There are at least three reasons for this: When recei
Page: Signalling Rights conflicts in ERN-C Status Updates
The ErnAcknowledgementStatusMessage defined in the ERN Choreography standards can be used as a technical acknowledgement. The same message can, however, also be used to signal, to the original sender of the ERN message, a change of the status of a deliver
Page: Single-Record Block Variant or Multi-Block Variant?
DDEX has defined some of its profiles in two forms: Multi-Record Block Variants (MRBV) and Single-Record Block Variants (SRBV). For most profiles, the MRBV is the default. In MRBVs the main body of the sales/usage report is made out of "Blocks" which co
Page: Special Characters
Special Characters Some artist names contain special characters. Unfortunately sometimes labels send concatenated artists in the form "Name 1/Name 2", a style that is discouraged unless the two artists have agreed to have their joint "brand" to be display
Page: Special XML Characters (and how to avoid &amp;amp;)
Some characters cannot directly expressed in XML. They need to be expressed in a special way using XML's escape charter &. They are: Character XML Representation < &lt; & &amp; > &gt; There are two more characters that may need "escaping". Details can be
Page: Specialising DDEX-Defined Values
As discussed here, DDEX standards allow the communication of user-defined values when none of the DDEX-defined values is suitable in a specific context. Such user-defined terms are, however, only useful to the recipient of the message if it knows, precise
Page: Splitting Names & the "Key" Name
Splitting a Name Names have different parts."First Name" and "Last Name" are two ways of calling these parts. Other ways are "Christian Name" and Family Name" while some countries have the concept of a "Middle Name". DDEX also allows splitting names into
Page: Start Dates, End Dates, Start Date-Times and End Date-Times of Deals
Dates in Deals are being phased out (in favour of datetimes) Deals provide the terms and conditions under which a Release can be offered to consumers. These include the points in time from when, and until when, a given Release may be made available. DDEX
Page: Starting an Implementation
This section focuses on Release Deliveries. However, its concepts apply to implementing all other DDEX message standards. This section provides an introduction to the digital supply chain integration process between a content provider and a digital servic
Page: Structure of the NewReleaseMessage
The DDEX message to communicate details about a release and its availability is the NewReleaseMessage defined in the Electronic Release Notification Message Suite Standard (often referred to as "ERN"). The NewReleaseMessage is the industry standard mechan
Page: Studio Roles in MLC 1.3 and 1.3.1
The RDR standard allows for the communication of a role that a contributor to a sound recordings and/or music video played. For details please read here... This article discusses MLC 1.3.x. The issue described herein has been fixed in MLC 1.4. This role
Page: Sub Titles in Multiple Languages
The ERN standard allows communicating titles of recordings and releases in multiple languages. The standard also allows the separation of the “main” title from the “sub title”. In some instances, a record company may send a title and sub title in one lang
Page: Symmetric Web Service Architecture
In the symmetric choreography both partners host a server and both are able to initiate the communication. This option greatly reduces the number of messages that are needed to perform the same actions and places more control in the hands of both partners


Page: Takedowns
There are two ways to communicate 'take-downs', i.e. the request from a Release Creator to a DSP to stop trading a Release: Sending a NewReleaseMessage without any Deal or Sending a PurgeReleaseMessage. While the two messages were designed for different p
Page: Technical Description of RIN
The Recording Information Notification (RIN) is a DDEX standard. It allows the capture and communication of all aspects of a studio event, including the minimum metadata set described above. The RIN standard also enables the capture of metadata about all
Page: Technical Information Gathering
Before starting the technical supply chain's integration process, both, content provider and DSP operations personnel, need to gather the technical information and business requirements to configure their part of the supply chain. The information usually
Page: Territorial RightsController Information
The RightsController composite can communicate information about who owns what right in a sound recording. It sits, in ERN-3 and MLC versions 1.1 through 1.4 in the SoundRecordingDetailsByTerritory composite. The RightsController composite has one subele
Page: Territorial scope for visibility dates (ERN 4.3 and later)
ERN 4.2 saw the introduction of two composites that enable a record company to signal to DSPs the date on which they may show to consumers the existence of an album which is to be released at some point in the future. These composites include the album’s
Page: Territorial Scope of a Deal
DDEX messages contain data that can vary between different territories. The band "Suede" is, for instance called "The London Suede" in the US. More critically for many applications is that music ownership may be
Page: Territorial variations in Release desciptions
Rules for ERN-3 DDEX messages are explicit in all communicartins. For instance a DSP may only offer a release to its users, if an explicit Deal is provided. Typical uses of territorial vartiants: For display: the DSP should show the relevant data for the
Page: Territories in Deals and Release Descriptions
Release information can vary between territories. To support this, ERN-3 provides a ReleaseDetailsByTerritory composite whereas ERN-4 allows communicating territorially different information directly in the Release composite. The same applies to Sound Rec
Page: Territory Codes (ISO 3166-1, ISO 3166-3, TIS)
Territory Codes in XML DDEX messages allows four ways to communicate territories: Either as a list of of one or more territory codes for which a specific set of XML tags apply. The code below applies to Germany, Belgium, The Netherlands and Luxembourg: <T
Page: Theme in MEAD
MEAD is a standard to communicate “rich” metadata about sound recordings, releases and musical works. (PIE is a similar standard for “rich” information about musicians and other parties involved in creating and marketing the music). Two aspects of this ri
Page: Things to know when implementing DDEX
This section of the DDEX Knowledge Base deals with generic issues that apply to various - some of them to all - standards. Companies do not need to be a member of DDEX to use any of the DDEX standards. All that is required is that they have a licence — w
Page: Time stamp for data accuracy
All DDEX standards contain a time stamp of the message creation (the MessageCreatedDateTime tag in the MessageHeader). They do notcontain a separate tag for the date/time when the data in the message is deemed to be current. A recipient is therefore requi
Page: Tips and Tricks for Implementing the RDR Standards
This section of the Knowledge Base intended to aid developers in properly implementing the DDEX RDR DeclarationOfSoundRecordingRightsClaim message. This sheet is written according to DDEX MLC 1.3.1. The example XML (provided by SCPP) is also based on DD
Page: Titles and SubTitles in ERN-3
In the ERN-3 standard, titles appear in many places. Some of these are specified to carry an additional SubTitle element, and others are not. The approach in ERN-4 is somewhat different. The FormalTitle and ReferenceTitle should break out subtitles into t
Page: Titles and SubTitles in ERN-4
The approach to communicating Titles in ERN-4 has been significantly simplified in that the differentiation between the ReferenceTitle and other titles has been removed. The communication of SubTitles remains, however, the same. In effect, the following p
Page: Track Releases
The general rule is that a NewReleaseMessage must contain the main Release (such as an album) plus one Track Release for each of the primary Resources that make up the Main Release. Thus a ten-track album will lead to a NewReleaseMessage containing eleven
Page: Translating and Transliterating Names
Sometimes names of contributors to a release, recording or work need to be translated or transliterated. Example include names of composers, for example: Sergei Rachmaninoff (English), Serguéi Rajmáninov (Spanish) or Сергей Рахманинов (Russian, his mother
Page: Translating and Transliterating Titles
Sometimes titles of a release, recording or work need to be translated for customers speaking a different language or transliterated for customers using a different alphabet. The “Phantom of the Opera” might be called “Το Φάντασμα της Όπερας” in Greek, “L


Page: Under construction
Page: Update Indicator (ERN-3 only)
The NewReleaseMessage in ERN-3 contains a field UpdateIndicator. This field has been deprecated and users are strongly discouraged to make use of it. DDEX has removed the field in ERN-4. Rationale The only purpose for such an UpdateIndicator field would b
Page: Updating a Claim
The DeclarationOfSoundRecordingRightsClaimMessages of the RDR standard (RDR-R) can be used by record companies to send claims for sound recordings and music videos to music licensing companies. The same message can also be used by a music licensing compan
Page: Upgrading from Version 1.2 to Version 1.3
Based on needs of the music licensing companies participating in the SCAPR VRDB project the following additions have been made to the Standard: AssociatedSoundRecordingId added into SoundRecording VRDB enables the identification
Page: Upgrading from Version 1.3 to Version 1.4
Version 1.4 of the MLC standard contains various minor updates, including a better description of artists and contributors and a closer alignment of role codes to ERN and RIN. In addition, Version 1.4 contains a new message to allow recipients of Declarat
Page: Upgrading from Version 1.4 to Version 1.5
Introduction The messages contained in the Recording Data and Rights Notification standard (RDR-N) provide a mechanism for record companies and music licensing companies to claim interest in a resource to a second music licensing company and to revoke and
Page: User-defined Values
DDEX standard message formats are used to carry information from one company to another. They do so by clearly defining the semantics of each “tag” as well as, where appropriate, the value that is communicated. The UseType tag, for instance provides infor
Page: UseType for Fingerprinting Services
The UseType in the NewReleaseMessage defines what a DSP may offer to its customers. However, some companies that receive NewReleaseMessages are not consumer facing. One such example are fingerprinting services. It therefore makes no sense to communicate a


Page: Validating DDEX Messages
DDEX develops standards for the electronic communication of music-related metadata using, to the most part, messages. One step in verifying that a message has been created in accordance with the standard is “validation”. For those DDEX standards based on
Page: Versioning Allowed Value Sets (AVSs)
Background Each of XML messages is defined by an XML Schema Definition (XSD) file. These files provide the structure of the messages defined in the relevant standard. These “message XSD” files then import a further XSD file that defines all the allowed va
Page: Versions are Compatible (most of the time)
DDEX standards come in different versions. Over time, DDEX members and licensees have identified additional requirements that are then added into subsequent versions of a specific standard. DDEX standards with the same major version number (that’s the “3


Page: What can I do if I have data requirements not addressed by DDEX?
DDEX standards are developed by consensus amongst its members and while DDEX standards are typically created comparatively speedily, there are instances where a company’s data requirements are not addressed by a new version of a DDEX standard. Examples in
Page: What is a "Public Draft"?
Update Cycle In 2013 DDEX moved to a regular update cycle. This means that DDEX will wait for at least one year before issuing a new version of a particular standard. There are two exceptions to this rule, however: Should an error be found in a DDEX stan
Page: What is RIN?
DDEX has developed Recording Information Notification (RIN), a standard that allows studio equipment manufacturers, including Digital Audio Workstation (DAW) manufacturers, to enable their users to capture and store essential metadata and then communicate
Page: What should a RIN File contain?
RIN is a complex file format – it has to be, to be able to adequately document the salient aspects of a recording, mixing or mastering session. Yet, at the core RIN is also quite simple. It enables the storage and communication of who did what to, and wit
Page: What should I do if I have data requirements that are not addressed by DDEX?
DDEX standards are developed by consensus amongst its members and while DDEX standards are typically created comparatively speedily, there are instances where a company’s data requirements are not addressed by a new version of a DDEX standard. Examples in
Page: Which Profile for which XSD?
Profiles for Specific Use Cases
Page: Who owns which rights?
There may be multiple rights associated with a Sound Recording or music Video (or any other audio or audio-visual recording) irrespective of the rights in the Sound Recording or music Video itself. As this is a complex topic, this article can only provide
Page: Why DDEX?
Businesses along the music supply chain have long experienced a lack of standardised data exchange formats and protocols. This has resulted in significant inefficiencies in ingesting and processing data. DDEX greatly alleviates these inefficiencies by dev
Page: Why is there artist information in multiple places
Music products are complex items. They comprise of several nested creations: A Musical Work, i.e. the composition and/or lyrics of a song; A Resource, i.e. the sound recording or video that an artist has created by performing and recording a musical work
Page: Why the RDR Message Suite Standards?
The scope of data used within the collective management of related rights is very specific, and is generally the subject – at least indirectly – of national legislation under which music licensing companies operate. DDEX’s Electronic Release Notificatio
Page: Why update to ERN 4.3
ERN-3 is a widely-used standard that enables record companies or distributors to provide Digital Service Providers (DSPs) with data about releases and commercial terms and conditions under which the DSPs may make available such releases to consumers. The
Page: Worldwide
DDEX messages make use of two-letter ISO territory codes. This allows a label to state that a Release may be used in, say the DACH countries: <TerritoryCode>DE</TerritoryCode> <TerritoryCode>AT</TerritoryCode> <TerritoryCode>CH</TerritoryCode> It also all
Page: Writer Roles
Communicating the name of a writer of a Musical Work is an important part of a number of DDEX messages – specifically: ERN, RIN, DSR and the various messages to support the licensing of Musical Works. There are, several aspects to writing a Musical Work t





  • No labels