Structure of RIN
The structure of RIN is built around a number of concepts.
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 the composers, arrangers, lyricists, performers (both featured and non-featured), producers and engineers. Each party is described by a name, a unique identifier (optional but valuable), and contact information (optional);
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, 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 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 and 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 actual file itself is not part of the RIN file.
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. On the other hand, the RIN functionality is intended to enable the capture as granular a set of metadata as possible.
Each of the entities described above are structured in 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 RIN file 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.
When implementing RIN, DAW and other 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.