The Recording Information Notification (RIN) will be a DDEX standard. It will allow the capture and communication of all aspects of a studio event, including the minimum metadata set described above. The RIN standard will also enable the capture of metadata about all the parties and tools that were involved in a studio event. It is based around a series of simple and powerful concepts, a few of which are depicted below.

The concepts are:

  • Sessions are the events in which sound recordings of musical works are created.
    Sessions are typically described by the location where, and the time when, the session took place as well as a list of parties that were present;
  • Parties are individuals or groups that contribute to the creation of music. These include, amongst others, the composers, arrangers, lyricists, as well as the performers, both featured and non-featured, and the producers and engineers. Each party is described by a name, hopefully, a unique identifier and, potentially, contact information;
  • Equipment includes the instruments played by the parties in the session as well as other equipment used during the session. Equipment can be described by a simple name, but also more specific information such as the serial number of the particular device used can be captured;
  • Musical works are the compositions (or songs) that are being recorded or mixed. Each musical work can be described by its title, its writers and, hopefully, by a unique identifier;
  • Recording components are the recorded elements that are captured with a view to them being contributed to a sound recording (including those components that are not part of an initial public release). Recording components are typically described by their title, their sequence number and some annotations. Additionally, information about involved parties, their role(s) and instrument(s), if any, can provide further detail about a recording component;
  • Resources are the sound recordings (typically of a musical work), of which many versions can be created. Resources are typically described by their title, a list of parties involved in their creation as well as information such as which work has been recorded, its key, time signature, duration, etc.;
  • Projects are groupings of sound recordings, for both accounting and artistic reasons. Projects are typically described by a reference number, often provided by the commissioning label to tie back to a cost/profit centre, and the main artist as well as other parties and a status code;
  • Data carriers are the specific configurations of sound recordings for use in many scenarios. Data carriers are typically described by the type of carrier (e.g. ¼ inch analogue tape), a unique identifier such as a barcode ID and their location (e.g. “Abbey Road Vault”);
  • Elements are the specific configurations of sound recordings for various uses. Examples include multi-track masters, mix master versions, instrument stems, surround mixes, TV mixes, instrumental mixes and the like. Elements are typically described by their designation, configuration, title, data carrier and format, and file type; and
  • Files are the actual data items associated with the project. These files can be any type, but are usually either audio, image or data files. A RIN file only contains information about the file itself (i.e. the location, the file name, the format and, potentially, a hash sum); the content of file itself is not part of the RIN file.

It is important to stress, that while a RIN file can contain all of the individual data items listed above it does not have to contain all of this information. In many situations, it may not be applicable to assign a key signature to a sound recording resource or it may not be known who was attending a specific session. Conversely, the RIN capabilities are extended to incorporate the ability to provide as granular metadata as possible, as long as it adheres to the RIN standard.

Each of these entities will be described in a RIN file in such a way that is compatible with the data structures used by all other standards published by DDEX. This means that a record company that receives a Recording Information Notification from one of its musicians or a studio manager will find it very easy to forward this information to its retail partners, metadata aggregators and music licensing companies, with all the benefits of efficiency outlined above.

DDEX uses, for most of its standards, XML as the underlying syntax. This is because XML, which has become the lingua franca for many ecommerce applications, allows the capture of very simple and very rich data sets using the same data structures. For RIN this means that the same data structures can be employed to capture the minimum data set discussed above, as well as the data necessary for the more complicated scenario depicted in the figure below and the scenarios captured in the RIN files in the Annex.

This in turn means that implementers of the RIN standard will find that RIN scales very well to their particular needs. When implementing RIN, DAW and studio equipment manufacturers can be expected to create different user interfaces, each working well with their particular application or device, using the terms their users are familiar with, and are appropriate for the type of application or device (instead of the generic terms used in the standard). This will allow one device to guide users to provide the minimum data set, while other devices will allow much richer information to be handled. But whatever the extent of the data being captured, any company in the supply chain that receives and can ingest RIN files will be able to use all types of recording information and make it available.

Figure 3 – Complex Recording Information Notification

Read on here