DDEX Standard

Skip to end of metadata
Go to start of metadata

 

 

This section of the DDEX Knowledge Base contains version 2.0 of the "Recording Information Notification (RIN)"

1 Introduction

This standard was developed by the member organisations of the Digital Data Exchange, LLC (DDEX) and provides a uniform mechanism to enable the capture, storage and communication of “recording information”, i.e. information about recordings between studios – including any places where music is being recorded, mixed or mastered – and companies that make use of such information.

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.

 

Download Standard

Download Standard (PDF)

Download/Print standard tables (XLS)

Download XML Schema Definition Files (ZIP)

Older versions of the RIN standard can be accessed here.

Before starting an implementation, DDEX recommends to read Starting an Implementation and Licensing DDEX Standards.

Essential Reading

RIN Overview and Information

 The DDEX 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 in the general index will take you to the relevant edition of the DDEX Data Dictionary.

Message Editions

... for the Electronic Release Notification (ERN 4.3)

... for the Transfer of Catalogues of Releases and Resources by Reassignment of Rights Controller Information (CT 1.0)

... for Recording Information Notification (RIN 2.0)

... for Media Enrichment and Description (MEAD 1.1)

... for Party Identification and Enrichment (PIE 1.0)

... for the Recording Data and Rights Notification Standard (RDR-N, Version 1.5).

Allowed Value Set Editions

... for the Allowed Value Sets (Version 4)

... for the Allowed Value Sets (Version 3)

... for the Allowed Value Sets (Version 2)

... for the Allowed Value Sets (Version 1)

Data Dictionary editions published before 2022

... for the Recording Data and Rights Choreography Standard (RDR-C, Version 1.0): Message Structure and AVSs

... for the US Letters of Direction Choreography Standard (LoD, Version 1.0): Message Structure and AVSs

... for the Electronic Release Notification Message Suite Standard (ERN, Version 4.2): Message Structure and AVSs

... for the US Musical Work Licensing Choreography Standard (MWL, Version 1.0): Message Structure and AVSs

... for the Standard for the Communication of Media Enrichment and Description Information (MEAD): Message Structure and AVSs

... for the Musical Work Right Share Notification Choreography Standard (MWN, Version 1.1)

... for the Standard for communicating links between Resources and Musical Works (Version 1.1)

... for the Recording Data and Rights Standard (Version 1.4)

... for Release Deliveries using SFTP or Web Service (Version 1.7)

... for the Recording Information Notification (Version 1.1)

... for Work and Share Notifications

... for Works Licensing

 

2 Scope

 2.1 Introduction
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, a new mix, etc. In each of these “studio events”, there are a number of metadata elements that may be worth capturing. Who performed which musical work? Who played which instrument? When and where was this performance recorded? Who was the sound engineer? Which recording components (or, in studio parlance: tracks) were used to create a specific mix? And which sections of these recording components have been used? These pieces of information are important for several reasons, including to attribute credits and royalties to the correct people and because the richer the data provided to retailers, the better they can market the products - which can potentially increase the audience and, thus, the revenue generated.

The Recording Information Notification is a 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.

 2.2 Organisation of the Document

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 6 then define the choreography and the syntax of RIN.

 2.3 Release Notes

Version 2.0 of the RIN standard provides a major update to the way RIN information is shared between RIN Processors in that it now defies an XML-formatted message instead of a file format. In addition, RIN 2.0 no longer differentiates between a "Full Profile" and a "Minimum Profile". As a consequence: 
  • RIN now defines SFTP and Web Service choreographies for the exchange of RIN messages in Clause 5;
  • RIN explicitly defines that the scope of a RIN message is one "deliverable", i.e. a set of recording components that are intended to be mixed and mastered into a single finished sound recording (see Clause 6.2); 
  • The syntax of the RIN message differs from earlier RIN files, created in accordance to the Full Profile, as follows:
    • The FileHeader has been replaced with a MessageHeader;
    • A MessageVersionId has been added into the MessageHeader to allow sequencing RIN messages;
    • An AvsVersionId attribute has been added into the root tag of the RecordingInformationNotification to allow pointing to a specific version of the underlying allowed value sets;
    • The Genre composite now supports both free-form genres as well as GenreCategories as used in others DDEX standards;
    • A MayBeShared attribute has been added to the PartyRelationship tag to allow signalling that a Party-Party relationship may (or may not) be forwarded by the message recipient to third parties;
    • SoundRecordingFileReference tag has been added to the SoundRecording composite to allow describing the file in which the audio of that sound recording is stored;
    • RecordingComponentEquipmentReference has been added into the RecordingComponent composite to allow describing a component that has been used when creating the recording component (note, instruments and equipment used by a specific contributor in their contributions are handled in the Contributor composite); and
    • A new Instrument composite has been added into the Equipment list to differentiate instruments from other (recording/mixing/mastering) equipment. As a consequence the Equipment composite was slightly updated.


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

 Click here to expand...

The following normative documents contain provisions, which through reference in this text constitute provisions of this Standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest version applies.
  • DDEX Data Dictionary Standard. Latest Version
  • DDEX Party Identifier (DPID) Standard. Latest Version
  • IETF RfC 2616. Hypertext Transfer Protocol (HTTP/1.1). 1999
  • IETF RfC 6797. HTTP Strict Transport Security (HSTS). November 2012
  • 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[1]
  • W3C. XML Schema Part 1: Structures. Second Edition. 2004
  • W3C. XML Schema Part 2: Datatypes. Second Edition. 2004


[1] Information on ISO 8601 can be found in Annex D of Part 2 (Datatypes Second Edition) of the XML Schema standard (http://www.w3.org/TR/xmlschema-2/#isoformats).

4 Terms and Abbreviations

 4.1 Introduction
When implementing this standard, it should be borne in mind that the definitions of some terms may well differ from the way in which they are defined and used in different parts of the music industry and/or as they may be defined in different legislations around the world. One such example is “producer” which is sometimes defined to be the company that initiates the production of a sound recording (usually a record company) and sometimes defined to be the individual person that directs the recording process. To avoid this issue, DDEX is using the term “Initial Producer” for the former meaning and "Studio Producer" for the latter (see Clause 4.2).

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.

 4.2 Terms and Definitions

 

Batch

A grouping of one or more DDEX Messages to be processed by the recipient together.

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.

Data Carrier

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.

Element

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.

File

A Resource stored as a single unit, normally in a file system on disk or magnetic tape

Initial Producer

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.

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.

Project

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.

Recording Component

The combining of individual files into a common groupings within a multitrack recording. Examples include “Snare Drum”, “Lead Vocal Comp”, “Lead Guitar” or “Percussion”

RIN Processor

A device or computer software application that ingests, creates or processes RIN messages.

Session

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.

Studio

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.

 

Web Service

A modern set of web technologies that allow small pieces of information, typically in the form of XML files, to be exchanged. Augmented with FTP (or other file exchange mechanisms) they can be used to communicate Releases along the music supply chain.

Web Service Call

The sending of an XML document to a port/address on a web server, using HTTP or HTTPS.

Web Service Response

The sending of an XML document in direct response to a Web Service Call, using HTTP or HTTPS.

For the avoidance of doubt: the appropriate response is always the message indicated in the appropriate Choreography.

 4.3 Abbreviations

AMEPAutomated Message Exchange Protocol
ACAAppointed Certification Agency
AVSAllowed Value Set
BPBusiness Profile
BWARMBulk Communication of Work and Recording Metadata
CISAC

Confédération internationale des sociétés d'auteurs et compositeurs, the International Confederation of Societies of Authors and Composers (see cisac.org)

CACertification Agency
CTConformance Tester
DAWDigital Audio Workstation
DDEX

Digital Data Exchange

DSIGDigital Signature
DSPDigital Service Provider (incudes Mobile Service Providers)
DSRDigital Sales Reporting
ERNElectronic Release Notification
FTPFile Transfer Protocol (FTP specifically includes SFTP)
GRidGlobal Release Identifier
HTTPHypertext Transport Protocol  (HTTP specifically includes HTTPS)
HTTPSSecure Hypertext Transport Protocol
IECInternational Electrotechnical Commission (see iec.ch)
ISOInternational Organisation for Standardisation (see iso.org)
MEADMedia Enrichment And Description
MIMEMultipurpose Internet Mail Extensions
MWLMusical Works Licensing
MWNMusical Works Notification
MRBV

Multi-Record-Block Variant

PCAPrivate Certification Agency
PDFPortable Document Format
PIEParty Identification and Enrichment
RESTREpresentational State Transfer
RINRecording Information Notification
SFTPSecure FTP
SRBV

Single-Record-Block Variant

TISTerritory Information System (a CISAC Standard)
TLSTransport Layer Security
UGCUser-generated content
URLUniform Resource Locator
XMLeXtensible Markup Language
XSDXML Schema Definition
W3CWorld Wide Web Consortium (see w3c.org)
WSWeb Service

5 Choreography

 5.1 Overall Choreography

The figure below depicts the choreography defined by this standard. 

The table below summarises the points in the Recording Information Notification Choreography that a message is sent.

 

Message Name

Initiating Event

SenderRecipient

1a

RecordingInformationNotification

After a session of creating music, which may include making recordings as well as writing, information about the session, the music and the Parties involved is entered into a system that collates the relevant metadata.

If such data is required as input to the metadata maintenance in subsequent sessions, a RIN message is sent to the RIN processor used at that session.

Studio RIN ProcessorStudio RIN Processor
1b

Based on contractual obligations, the RIN Processor used at the session will send a RIN message to the record company

Such communication can also be supported by agents for the Studio RIN Processor and/or the Record company

Record company (or other Party interested in receiving such data)

 

The exchange of the information in these messages can be effected by two different message exchange protocols: SFTP and Web Services. Details on these are defined in Clauses 5.2 and 5.3 respectively.

 5.2 SFTP Choreography
 5.2.1 Introduction

If the exchange of messages defined in this standard is to be effected using SFTP, the rules as laid out in Clause 5.2 shall be applied. For this the following "helper messages" are defined in this standard:
 Message Name

Initiating Event

SenderRecipient
2ManifestMessage

A party has finished collating RecordingInformationNotifications in accordance with this standard into a Batch and wishes its business partner to commence ingesting it. Note: the ManifestMessage is no shown in the above diagrams.

Sender of "main" messagesRecipient of "main" messages
3FtpAcknowledgementMessage

A party receives a Batch of messages in accordance with this standard. The party may then acknowledge receipt of each message (not agreement with its content).

Recipient of "main" messagesSender of "main" messages

The arrival of the Batch on the SFTP server shall be signified by placing a manifest file (as defined below) at the appropriate location. The manifest file shall refer, indirectly or indirectly to all files that are part of the Batch. The Manifest may only be placed on the SFTP server, once all other files have been completely uploaded.

 5.2.2 Folder Naming Conventio

To ensure sequential processing, a Batch is identified by the date and time of its creation in the form YYYYMMDDhhmmssnnn with
  • YYYY being the year of Batch creation;
  • MM being the month of Batch creation;
  • DD being the day of Batch creation;
  • hh being the hour of Batch creation;
  • mm being the minute of Batch creation;
  • ss being the second of Batch creation; and
  • nnn being the millisecond of Batch creation.

 5.2.3 XML File Naming Convention

Each message sent in the Batch shall be named as follows: RIN_NNNN_SSSS.xml with NNNN being the DPID of the sender of the RIN message and SSSS being a string uniquely identifying the file in the Batch.

RIN messages are XML files and, therefore can be opened with any XML editor. However, as opening a RIN messages Files with a generic XML editor is of limited use to most users of RIN messages Files who would instead prefer that RIN messages Files are opened with a RIN Processor.

To allow computers to automatically launch such a RIN Processor when a user wants to access a RIN messages, it is recommended that RIN message files carry the file ending .rin and not .xml.

 

 5.2.4 Manifest

Once the message sender has uploaded all files of the Batch, the sender shall upload a manifest file. The manifest file shall be called manifest.xml and shall be placed into the same folder as all other files.

Its syntax is defined in Clause 6.

 5.2.5 Acknowledgement

Once the message recipient has downloaded a file from within the Batch, the recipient may upload an acknowledgement file. The acknowledgement file shall be called ACK_FFFF.xml with FFFF being the file name (without extension) of the message acknowledged.

The acknowledgement shall be placed into the same folder as the acknowledged file. Its syntax is defined in Clause 6.


 5.3 Web Service Choreography
 5.3.1 Introduction

The approach to RIN message deliveries defined in this standard is asymmetric. Only companies interested in receiving RIN messages will need to publish and maintain a web service. Companies sending RIN messages will be able to call these services and thus effect the (subsequent) deliveries of RIN messages.

As a consequence it is the sender that determines the speed of the communication. 

A further consequence is that the capacity management lies with the recipient of RIN messages who may need to be able to satisfy concurrent (or near concurrent) web service requests from multiple RIN message senders. The number and frequency of such web service requests is likely to vary significantly over time and companies are advised to plan their infrastructure accordingly.

Wherever this standard only mentions the HTTP protocol, it is to be understood that HTTPS communications are also allowed.

 5.3.2 Choreography

The choreography enabled by this standard is depicted in the diagrams below. The actions on both sides (represented by red boxes) are exemplary only and only represent a typical information exchange in accordance with this standard. It comprises of these steps:
  1. A RIN Processor has collated information it needs to share with another RIN Processor. The sending RIN Processor compiles all information into a RIN message file.
  2. The sending RIN Processor calls the web service of the recipient by accessing its web service end point using a secure HTTPS connection in accordance with Clause 5.3.6.
  3. The receiving RIN Processor responds with an appropriate status code as defined in Clause 5.3.6.

This choreography is depicted below.

 

 5.3.3 Personalising the Feed

Many companies interested in recruiting RIN message will want to receive information from different business partners. In these cases it is essential that the web server of a receiving RIN Processor knows who is calling one of its web services. 

This can be done with or without formal authentication (see Clauses 5.3.4 and 5.3.5, respectively). The benefit of using formal authentication is that it also allows the two parties to secure their communication.

 5.3.4 Web Service Set-up and Authentication

This standard does not define an authentication mechanism for the web service-based communication between two RIN Processors. Should the two parties require their communication to be authenticated, they are free to use any of the existing web-based authentication methods including, but not limited to, Basic Auth, HTTP Digest Authentication, HTTPS Client Authentication, OAUTH, etc.

 5.3.5 Identifying RIN Message Senders Without Authentication

Establishing the identity of the caller of the web service can also be accomplished without formal authentication (although in that case the web service cannot be certain that the caller is who it claims to be) by including, for instance, the DDEX Party Identifier (DPID) of the web service caller into the URL syntax.

 5.3.6 POST RIN Message

5.3.6.1 Purpose

This command can be used by a RIN Processor that wants to send a RIN message to another RIN Processor.

The document to be posted is defined as in Clause 6.8.

5.3.6.2 Syntax of Reply

The web server shall return one of the following standard HTTP status codes with their standard HTTP response code semantics (unless where clarified):

  • 204 (The server successfully processed the request but is not returning any content);
  • 400 (Bad request);
  • 401 (Unauthorised);
  • 404 (Not found);
  • 500 (Internal server error); and
  • 503 (Service unavailable due to a temporary overloading or maintenance of the server).

Other standard HTTP status codes may be used on bilateral agreement between the two RIN Processors.

 5.4 Digitally Signing RIN messages

5.4.1 Overview

Determining the authenticity of a RIN message – and thus being able to judge the reliability of the contained data – is a crucial element of handling RIN message. This can be achieved by identifying the device or software application that was used to generate a RIN message, the user that triggered the generation of the RIN message, on whose behalf the RIN message was generated, and by digitally signing a RIN message.

The process of signing a RIN message is in accordance with IETF RfC 3275 (XML-Signature Syntax and Processing):

Before signing a RIN message, the RIN Processor needs to be in possession of the private key of the signing entity. Before evaluating the signature of a RIN message, 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.

5.4.2 Signing

The process of digitally signing a RIN message is as follows:

  1. The RIN Processor to generate the RIN message shall assemble the RIN message – with the exception of the Signature composite in the MessageHeader – and, typically, save it to a permanent storage medium;
  2. The RIN Processor shall calculate a hash sum over the saved RIN message;
  3. This hash sum shall then be encrypted using the private key of the signing entity;
  4. The Signature composite in the MessageHeader shall then be compiled and be added into the RIN message, which then can be stored and shared.

5.4.3 Evaluating a Signature

The process of digitally evaluating a signed RIN message is as follows:

  1. The RIN Processor to evaluate the signature of a RIN message shall open the RIN message and remove the Signature composite from the MessageHeader;
  2. 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 message, using the algorithm indicated in the Signature composite from the MessageHeader;
  3. The RIN Processor shall also generate a hash sum of the RIN message without the Signature composite from the MessageHeader, using the algorithm indicated in the Signature composite from the MessageHeader;
  4. The RIN Processor shall then compare the decrypted signature with the calculated hash sum:
    1. If they are the same, the entity listed as being the generator of the RIN message can be deemed to have generated the RIN message; and
    2. If they are not the same, the entity listed as being the generator of the RIN message cannot be deemed to have generated the RIN message

 

6 Syntax & Semantics of Messages

 6.1 Introduction

The hierarchical structure of the format is provided through indentation in the tabular rendering of the message (available here).

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 Granularity of RIN Messages

Each RIN message provides metadata about one "deliverable", i.e. a set of Recording Components (the exact scope of which will have been determined by the parties involved, typically by contract) that are intended to be mixed and mastered into a single finished Sound Recording. Such deliverables may exist as part of a recording project.

 6.3 General Conformance Rules

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

The 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: “#unknown#” ;
  • In fields of type xd:date: “9999-01-01”;
  • In fields of type xs:datetime: “9999-01-01T99:01:01”; and
  • In fields of typexs:duration: “PT99H01M01S”.

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.

 6.4 Namespace

The full namespace for the XML Schema documents for this Standard are as follows:
http://ddex.net/xml/rin/20

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.

 6.5 Allowed-Value Sets

The message defined in this standard make intensive use of allowed-value sets. These allowed value sets are shared between all DDEX standards and DDEX provides a XML Schema Definition file for all of these allowed values. These values are also contained in the DDEX Data Dictionary available from ddex.net

The message defined in this standard contains a mandatory AvsVersionId XML attribute. The AvsVersionId at publication is 2. DDEX may update the list of allowed value sets (AVS) over time and therefore might increase the AvsVersionId over time. At that stage, the then current AvsVersionId will be made public on the DDEX Knowledge Base.

The full namespace for the XML Schema document for the allowed-value sets is

http://ddex.net/xml/allowed-value-sets

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 Table of AVSs is provided in a separate document. See the blue box here.

 6.6 Proprietary Identifiers

Identifiers are essential for accurate data exchange. Therefore, RIN supports a range of identifiers for different entities. Examples include ISRCs for sound recordings, ISWCs for musical works and ISNIs for parties such as writers, recording artists and sound engineers.

However, many such entities are also identified by proprietary identifiers. These identifiers can also be included in a RIN message 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 message 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:

<ProprietaryId Namespace="PADPIDA1234567890">PropId</ProprietaryId>
<ProprietaryId Namespace="CompanyX">PropId</ProprietaryId>

 

 

 6.7 Linking RIN files and DAW Audio Files

The RIN message allows linking to the audio files representing the deliverable (which may be a work in progress or component thereof) via the File composite's URI element. In addition, the File composite allows provision of a HashSum of the audio file to ensure the URI reference is accurate. The HashSum can also be used to link a RIN message with a previously sent audio file.

 6.8 Syntax and Semantics of Messages

The tabular rendering of the messages  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:

  1. The suitability or fitness of the standards for any particular purpose;
  2. The merchantability of the standards;
  3. The accuracy, completeness, relevance or validity of the standards; or
  4. 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.