Skip to end of metadata
Go to start of metadata

Space Index

0-9 ... 0 A ... 14 B ... 2 C ... 20 D ... 31 E ... 1
F ... 2 G ... 1 H ... 4 I ... 21 J ... 0 K ... 0
L ... 5 M ... 16 N ... 3 O ... 9 P ... 12 Q ... 0
R ... 24 S ... 12 T ... 12 U ... 5 V ... 1 W ... 8
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 CISAC Confédération internationale des sociétés d'auteurs et compositeurs, the International Confederation of Societies of Authors and Co
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: 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 MLC Messages
The DDEX MLC 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: 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: 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: 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: 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: 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: 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 MLC information exchange
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 MLC Messages are laid out within Section 6 of the standard
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: 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 TechnicalSoundRecordingDetails compos
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: 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
Communicating Binaries Lyrics are Text resources and in all but very rare instances they are secondary resources (for a definition on what that is, please refer to the blue box on the right hand side). To communicate lyrics for a ten-track album, the mess
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: 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: Current Data Dictionary
... for the MLC Standard (Version 4.1) ... Release Notifications (ERN 4.1) ... for Release Deliveries using SFTP or Web Service (Version 1.7) ... f


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. Standard Governance
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. Recently Updated: Music Licensing Company Messag
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
Overview of DDEX Purpose and Governance Next Steps and Q&A DDEX Standards Introduction and ERN DSR, MLC and RIN MWN, MWL and Linking Works to Resources Other Industry Standards ISWC ISRC
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: DDEX's Message Suite Standards
I'm a collection society... screen-capture.png... and I want to implement the process of licensing musical work the process of receiving sales reports the process of communication amongst music licensing companies I'm a label... screen-capture-1.png...
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: Deals and Commercial Aspects
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
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. Administrator A Party administrating Righ
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: 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: 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: 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: 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: DSRF 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: DSRF 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: DSRF 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 Type Definitions
Page: DSRF 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: Record Type Definitions https://kb.ddex.
Page: DSRF 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: 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: 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: 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: 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: 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: 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: 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: 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
Following the MessageNotificationPeriod is the ResourceList, which forms the body of the MLC message. The ResourceList contains one or more SoundRecording composites. The box below illustrates the ResourceList containing one or more SoundRecording compo
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: SoundRecording-DetailsByTerritory
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 overrid
Page: Implementation: XML Declaration
The DDEX MLC Message must begin with an XML Declaration. <?xml version="1.0" encoding="utf-8"?> <DeclarationOfSoundRecordingRightsClaimMessage xmlns="" xmlns:xsi="" xmlns:xsd=http://www.w
Page: Implementing Communications with and between Music Licensing Companies
This part of the DDEX Knowledge Base describes the DDEX MLC Message Suite Standard. The standard itself defines a suite of messages that provide a uniform mechanism for the exchange of data for use in the collective management of neighbouring rights (thes
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 Release Deliveries
This section of the Knowledge Base, 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 operatio
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 DDEX MLC Message Suite Standard
This section of the Knowledge Base intended to aid developers in properly implementing the DDEX MLC DeclarationOfSoundRecordingRightsClaim message. This sheet is written according to DDEX MLC 1.3.1. The example XML (provided by SCPP) is also based on DDEX
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 Licensing & Notification
Works Licensing & Notification 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 gran
Page: Index
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 in most circumstances such a message is non-sensical – after all it instructs the DSP to ingest a set of releases but to not make a single one available. However, there are scenarios where this does
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: 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: 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
Below please find a list of the current version of the various DDEX standards. Current Versions Old Versions Old Versions of DDEX Standards
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: 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: Message Exchange (FTP)
DDEX MLC 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. Unique upload and download
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: 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: Music Licensing Companies (MLCs)
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 licensee. 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: New on
Page: Niels' Conference Call Details
To see the XSD/documents during the call, please point your favourite browser at Passcode: 9794 0008# Phone numbers: +44 207 550 2523 International 08 8111 0631 Adelaide Local
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: 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 MLC 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: 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: 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: 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 MLC Message Suite Standard
The DDEX MLC Message Suite Standard is 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 MLCs. The DDEX MLC Message Suite Standard is
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: Registry of all DDEX Party Identifiers
Background Each company that takes out an DDEX Implementation Licence will be allocated a DDEX Party Identifier DPID in accordance with the DPID standard. Therefore each company that sends or receives
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 MLC Message Suite Standard
MLCs manage data relating to the administration of the rights in the recordings which are owned by their members. More specifically, MLCs administer rights in what are known as eligible recordings. This includes recordings originating from their territory
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: 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 Resoucres 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 MLCs
DDEX recommends the use of the MLC 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
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: RIN ‒ Frequently Asked Questions
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: 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: 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: 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: 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 with a Deal ending today (or even yesterday); or Sending a PurgeReleaseMessage. While the two messages
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 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 Takedowns
If a label messages a take down for one particular territory of say a three territory account, and the product is available in all three territories prior to this take down, the label will need to signal Deal information for all three territories – with o
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: 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: 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: 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: Under construction
Page: Update Indicator (ERN-3 only)
The NewReleaseMessage in ERN-4 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: Upgrading from Version 1.2 to Version 1.3
Based on needs of the MLCs participating in the SCAPR VRDB project the following additions have been made to the Standard: AssociatedSoundRecordingId added into SoundRecording VRDB enables the identification of cases in which mul
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: Versions are Compatible (most of the time)
All 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 are backwards compatible with few exceptions (


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: 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 an MLC Message Suite Standard?
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 MLCs operate. DDEX’s Electronic Release Notification (ERN) Standard that
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: 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





  • No labels