Importing RIN files into RIN files (RIN 1.0 only)
The process of recording music is iterative and often involves different “sessions” with different contributors in different locations. Ideally each of these sessions will lead to two outputs: a set of audio files containing the recorded music and a RIN file providing the metadata for the session.
In many cases, a session will make use of audio assets that were created in a previous session and which are, ideally, accompanied by a RIN file with the metadata relating to that previous session. It is advisable to incorporate the RIN file from a previous session into the RIN file for the subsequent session. The RIN standard supports this through the ImportedRinFiles composite.
There is, however, one aspect that implementers of a RIN-1.0-enabled application need to consider in this context and that relates to the ID/IDREF pairs that are used by the RIN standard to allow the communication of links between different composites. The XML code segment below contains data that shows that the sound recording with the ISRC GB-CBR-050006-4 is based on the musical work with ISWC T-913.186.956-2.
<MusicalWork> <MusicalWorkId> <ISWC>T9131869562</ISWC> <MusicalWorkId> <MusicalWorkReference>M1</MusicalWorkReference> <!-- Metadata about the work: title, writers, IDs --> </MusicalWork> <SoundRecording> <SoundRecordingId> <ISRC>GBCBR0500064</ISRC> </SoundRecordingId> <ResourceReference>A1</ResourceReference> <SoundRecordingMusicalWorkReference>M1 </SoundRecordingMusicalWorkReference> <!-- Metadata about the recording: title, contributors, IDs --> </SoundRecording> |
The “M1” in the MusicalWork/MusicalWorkReference element acts as an anchor to which the “M1” in the SoundRecording/SoundRecordingMusicalWorkReference composite points. The XSD data type for the anchor is xs:ID and for the pointer it is xs:IDREF. There may only be one anchor “M1” in any given RIN file but it may be used multiple times in multiple SoundRecording/SoundRecordingMusicalWorkReference composites to point to that anchor.
A problem can arise when importing a RIN file with an anchor “M1” into a RIN file which already contains an anchor “M1”. This will lead to (i) an invalid XML file and (ii) misdirected pointers. The situation gets arguably worse when a RIN file is to include multiple RIN files with conflicting ID/IDREF pairs. This is a situation that is not unlikely when creating a RIN file for a mixing or mastering session that needs to include information from multiple RIN files for multiple recording sessions.
To avoid these problems, implementers need to make sure that their application is able to adapt ID anchors – and consequently IDREF pointers – when importing a RIN file into another RIN file.
One approach an implementer might chose is to use simple digits for anchors in the main body of the RIN file (preceded, of course, by the letter that indicates which type of entity is being referenced): M1, M2 and M3 would be the first three musical works, A1, A2 and A3 would be the first three sound recordings, and P1, P2 and P3 would be the first three parties listed in the RIN file.
Anchors in the imported RIN files could then be changed to include a number unique to each imported file: M1-1, M2-1 and M3-1 would, in this approach be the first three musical works in the first imported RIN file, whereas M1-2, M2-2 and M3-2 would be the first three musical work in the second imported RIN file.
Note that there is no guarantee that a suffixed anchor (as described above) is automatically unique as some implementers may have chosen, say, M3-5 as an anchor in their RIN files.