Any organisation wishing to implement this (or any other DDEX standard) is required to apply for an Implementation Licence. The terms of the licence and an application form can be found at https://ddex.net/implementation/implementation-licence-and-ddex-party-identifiers.
The Recording Information Notification is a metadata file format that can capture and communicate such data. RIN is designed for machine-to-machine communication. It is not designed to be read by humans. Interpretation of RIN XML files will be performed by many front-end processor systems, including digital audio workstations and metadata collection applications.
This standard has six clauses and one annex. Clauses 1-4 provide an introduction the scope as well as normative references and definitions that form part of this standard. Clauses 5 and 5 then defines the details of the RIN format before Annex A provides the allowed values used in RIN.
Version 1.1 of the RIN standard contains minor changes from Version 1.0; they include:
- Ability to communicate how artist information should be displayed as part of a title;
- Ability to communicate display credits;
- A file-naming convention;
- Correction of errors in artists role codes; and
- A series of smaller changes to closer align the RIN file format with messages defined in other DDEX Standards, particularly ERN and MLC.
3 Normative References
- DDEX Data Dictionary Standard. Latest Version
- DDEX Party Identifier (DPID) Standard. Latest Version
- IETF RfC 5646, Tags for Identifying Languages. Latest Version.
- IETF RfC 3275. XML-Signature Syntax and Processing
- ISO 639-1988, Code for the representation of the names of languages
- ISO 3166-1:1997 Codes for the representation of names of countries and their sub-divisions – Part 1: Country codes
- ISO 3901:2001, Information and documentation – International Standard Recording Code (ISRC)
- ISO 8601:2004, Data elements and interchange formats – Information interchange – Representation of dates and times
- W3C. XML Schema Part 1: Structures. Second Edition. 2004
- W3C. XML Schema Part 2: Datatypes. Second Edition. 2004
4 Terms and Abbreviations
Implementers/users of this standard must make sure that they map the terms used in their application/domain to the appropriate term defined herein to ensure consistent semantic interoperability.
Digital Audio Workstation (DAW)
A Digital Audio Workstation (DAW) is an electronic device or computer software application for recording, editing and producing audio files such as songs, musical pieces, human speech or sound effects.
The physical entity created during the recording project. Data Carriers can be linked to more than one Project, Session, Sound Recording, or set of Recording Components.
A unique permutation of the Sound Recording. Elements can contain the original Recording Components ("Multitrack Master"), sub mixes of these components into common themes (Stems), or single mix files created from the combining of recording components (Master Mix, Instrumental Mix). A specific SKU or UPC can be set for each element.
A Resource stored as a single unit, normally in a file system on disk or magnetic tape
A Party that initiates the creation of a Sound Recording or Resource and is sometimes referred to as a commissioning rights holder. An Initial Producer may be a person or an Organisation and the term contrasts with the role of a Studio Producer.
A Party who directs, and has overall creative and technical oversight of, the entire recording project and the individual recording sessions that are a part of the project. The Producer participates in and/or supervises the recording session and works directly with the Artist, Musicians and Engineers. The Studio Producer makes creative, technical and aesthetic decisions that realize the goals of both the Artist and the Sound Recording Copyright Holder in the creation of musical content. The Studio Producer may perform direct Performances, choose final takes or versions, and oversees the selection of songs, Musicians, singers, Arrangers, studios, etc. The Studio Producer in collaboration with the artist, assigns credits to Performers and technical personnel, and is responsible for supplying accurate crediting information to the record label or media company as official documentation. Other duties of the Studio Producer may include, but are not limited to, overseeing other staffing needs, keeping budgets and schedules, adhering to deadlines, supervising mastering and overall quality control.
Note: A Studio Producer is a person and thus may contrast with the role of an Initial Producer.
A Project combines together many Sound Recordings, Recording Components, Sessions, Musical Works and Data Carriers. A project might be a 12 song album, or it might simply be a remix. A project could be a compilation of older recordings from different projects. And a project could also be a "Various Artists" type of compilation.
The combining of individual files into a common groupings within a multitrack recording. Examples include “Snare Drum”, “Lead Vocal Comp”, “Lead Guitar” or “Percussion”
An XML file created in accordance with this standard.
A device or computer software application that ingests, creates or processes RIN Files.
The location where musical works are recorded. During the creation of a Sound Recording, sessions may take place in many locations, including the recording studio as well as live venues, remote locations and the like.
The term “studio” denotes any facility for sound recording, mixing and mastering.
The term specifically includes large studios (such as the ones in Abbey Road in London) as well as digital audio workstations (DAW) installed on a personal computer and used in a musician’s home and portable units used for recording live events.
|AMEP||Automated Message Exchange Protocol|
|ACA||Appointed Certification Agency|
|AVS||Allowed Value Set|
Confédération internationale des sociétés d'auteurs et compositeurs, the International Confederation of Societies of Authors and Composers (see cisac.org)
|DAW||Digital Audio Workstation|
Digital Data Exchange
|DSP||Digital Service Provider (incudes Mobile Service Providers)|
|DSR||Digital Sales Reporting|
|ERN||Electronic Release Notification|
|FTP||File Transfer Protocol (FTP specifically includes SFTP)|
|GRid||Global Release Identifier|
|HTTP||Hypertext Transport Protocol (HTTP specifically includes HTTPS)|
|HTTPS||Secure Hypertext Transport Protocol|
|IEC||International Electrotechnical Commission (see iec.ch)|
|ISO||International Organisation for Standardisation (see iso.org)|
|MIME||Multipurpose Internet Mail Extensions|
|MWL||Musical Works Licensing|
|MWN||Musical Works Notification|
|PCA||Private Certification Agency|
|Portable Document Format|
|RIN||Recording Information Notification|
|TIS||Territory Information System (a CISAC Standard)|
|TLS||Transport Layer Security|
|URL||Uniform Resource Locator|
|XML||eXtensible Markup Language|
|XSD||XML Schema Definition|
|W3C||World Wide Web Consortium (see w3c.org)|
5 Message Overview
All messages and file formats developed within DDEX are based upon a common set of elements and their definitions. These are contained in the DDEX Data Dictionary available from ddex.net.
The full namespace for the XML Schema document for the allowed-value sets is
DDEX may regularly extend this list of allowed-value sets. Any such extensions to this list are issued on a date later than the date on which this Standard is issued form part of this Standard. Thus the list of allowed-value sets provided Annex A contains the list of allowed-value sets valid on the data of issuance of this Standard.
- The Full RIN Profile provides the full feature set to communicate recording information.
- A second profile defines a data set that focuses on essential information such as who contributed to a recording and what role did that person play. This profile is referred to as the Minimal RIN Profile.
However, many such entities are also identified by proprietary identifiers. These identifiers can also be included in a RIN file and are expressed in two parts: the organisation that is responsible for allocating the identifier (the identifier’s “namespace”) and the identifier itself.
If a company that has allocated a proprietary identifier has been allocated a DDEX Party ID (DPID), and if the RIN Processor adding this proprietary identifier into the RIN File knows of this DPID, the namespace shall be the DPID.
Otherwise the RIN Processor shall be using a mnemonically sensible string to identify the company allocating a proprietary identifier. Below are two examples of this:
Determining the authenticity of a RIN File – and thus being able to judge the reliability of the contained data – is a crucial element of handling RIN Files. This can be achieved by identifying the device or software application that was used to generate a RIN File, the user that triggered the generation of the RIN File, on whose behalf the RIN File was generated, and by digitally signing a RIN File.
The process of signing a RIN File is in accordance with IETF RfC 3275 (XML-Signature Syntax and Processing):
Before signing a RIN File, the RIN Processor needs to be in possession of the private key of the signing entity. Before evaluating the signature of a RIN File, the RIN Processor needs to be in possession of the public key of the signing entity. The process by which these keys are generated and distributed/shared is out of scope for this standard.
The process of digitally signing a RIN File is as follows:
- The RIN Processor to generate the RIN File shall assemble the RIN File – with the exception of the Signature composite in the
MessageHeader– and, typically, save it to a permanent storage medium;
- The RIN Processor shall calculate a hash sum over the saved RIN File;
- This hash sum shall then be encrypted using the private key of the signing entity;
- The Signature composite in the
MessageHeadershall then be compiled and be added into the RIN File, which then can be stored and shared.
5.6.3 Evaluating a Signature
The process of digitally evaluating a signed RIN File is as follows:
- The RIN Processor to evaluate the signature of a RIN File shall open the RIN File and remove the Signature composite from the
- The RIN Processor shall then decrypt the Signature element from the Signature composite using the public key of the entity listed as being the generator of the RIN File, using the algorithm indicated in the Signature composite from the
- The RIN Processor shall also generate a hash sum of the RIN File without the Signature composite from the
MessageHeader, using the algorithm indicated in the Signature composite from the
- The RIN Processor shall then compare the decrypted signature with the calculated hash sum:
Note: DDEX expects that such a link may be added in the future. For the time being, however, it is recommended that users of RIN Processors and DAWs use sensible file naming convention to keep their RIN Files and DAW projects aligned.
6 Message Definition
The Standard comprises two file formats of the
RecordingInformationNotification, one in each profile defined herein.
The hierarchical structure of the format is provided through indentation. On the File Header for example, the
PartyName is a child of
FileCreator. Thus, a
FileCreator contains a
PartyName (plus a
Looking at the
FileHeader it shows that exactly one
FileID needs to be provided. This is shown in the cardinality column with a "1". Other possible cardinality entries are: "0-1" (for none or one), "1-n" (for one or more) or "0-n" (for none to multiple). Elements shown in italics are represented in the XML Schema as XML Attributes. In several places within the messages, the Message Sender may need to make a choice between using two or more XML elements. These instances are marked in the tabular representation of the messages below with the keyword
XmlChoice. This keyword is not part of the messages; instead exactly one of the “branches” below the
XmlChoice keyword has to be used.
In addition to the tabular description of the message, which should always be read in conjunction with the XML Schema files, additional conformance rules, which go beyond XML Schema validation, are provided where necessary. The general conformance rules for all messages within this Standard are provided in Clause 6.2.
Specific business processes between sender and recipient may require even further conformance rules. These are, however, not part of the standard and will need to be agreed between business partners. Rules relating to the authority of business partners to unilaterally change the standard in this way are set out in the current version of the Procedures for the Development and Maintenance of DDEX Standards which forms part of the overall governance of the DDEX Standards.
The syntax as well as the semantics of the various elements in the messages is provided in this Clause. They are taken from the current version of the DDEX Data Dictionary as defined through, and maintained in accordance with, the DDEX Data Dictionary Standard.
6.2.1 Schema Validation
A message is conformant to this specification only when it validates against the set of XML Schema files provided.
6.2.2 Allowed Value Lists
The allowed values are listed, defined and provided through the DDEX Data Dictionary Standard in accordance with its latest version. Other values are not possible unless by using the mechanism described below:
This Standard does not explicitly list allowed values. The XML Schema files contain the allowed values at the time of writing of this Standard (see Annex A). Some of the allowed value sets contain a provision to either use a User Defined Value instead of a DDEX-defined value (in that case the
MessageSender has to select the value “
UserDefined” from the AVS and provide its own value in the XML attribute “
UserDefinedValue”) or to augment a DDEX-defined value (in that case the
MessageSender may not select the value “
UserDefined” from the AVS but shall provide its additional information in the XML attribute “
UserDefinedValue”). In either case the
Namespace attribute shall be used to indicate where the
UserDefinedValue is defined and maintained.
6.2.3 Allowed Values for
Namespace attributes can be used to allow message parties to use proprietary value lists.
The allowed value for the
Namespace attribute which is recommended to be used is the DDEX Party Identifier of the party controlling the proprietary allowed value, as defined in, and administered in accordance with the latest version of the DDEX Party ID Standard.
6.2.4 Indicating Unknown Values
When the sender of a message is required to provide a data element but cannot do so, the following values shall be entered:
- In fields of type xs:string: “
- In fields of type xd:date: “
- In fields of type xs:datetime: “
- In fields of typexs:duration: “
The circumstances under which such behaviour is permissible may be limited in the specific business relationship between message sender and message recipient.
6.2.5 Character Coding
All messages shall be sent in UTF-8.
Table 2 — Allowed-Value-Sets used in the Electronic Release Notification Message Suite Standard
The Table of AVSs is provided in a separate document. See the blue box here.
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 standard specifications (“DDEX Standards”) solely for the purpose of your internal evaluation. You may not make any commercial use of the DDEX Standards under this agreement. No other licences are granted under this agreement.
No representations or warranties (either express or implied) are made or offered by DDEX with regard to the DDEX Standards. In particular, but without limitation, no representations or warranties are made in relation to:
- The suitability or fitness of the standards for any particular purpose;
- The merchantability of the standards;
- The accuracy, completeness, relevance or validity of the standards; or
- The non-infringement of any third party intellectual property rights related to the DDEX Standards.
Accordingly, DDEX and/or its members shall not be liable for any direct, indirect, special, consequential or punitive loss or damages howsoever arising out of or in connection with the use of the standards. IN THE EVENT THAT ANY COURT OF COMPETENT JURISDICTION RENDERS JUDGEMENT AGAINST DDEX AND/OR ITS MEMBERS NOTWITHSTANDING THE ABOVE LIMITATION, THE AGGREGATE LIABILITY TO YOU IN CONNECTION WITH THIS AGREEMENT SHALL IN NO EVENT EXCEED THE AMOUNT OF ONE HUNDRED U.S. DOLLARS (US$ 100.00).
Users of the DDEX Standards are cautioned that it is subject to revision. Users are recommended to use the latest versions, which are available at http://www.ddex.net. The use of outdated versions of the standards is not recommended but may be required by agreement between implementers in particular cases.