SoundRecording composite itself comprises two main sections of information, firstly details at the
SoundRecording level, which are invariant across territory; then one or more
SoundRecordingDetailsByTerritory composites containing territory-specific information for that
LanguageAndScriptCode applied at this level applies to all child nodes, unless overridden in any of the child nodes.
SoundRecording Fields Within ResourceList
Core Data Profile
Mandatory if available
SoundRecordingType– in most cases, parties will be communicating details of a
SoundRecordingthat is related to a musical work (as opposed to
SoundRecordingTypeof an audio book or ambient recording, say).
IsReplacedflag in the
SoundRecordingIdtag indicates whether this Identifier is old and has been replaced by a new one (=true) or not (=false). The Flag may only be set to True when the new Identifier is also provided.
IsArtistRelated- is an optional Boolean that flags whether the resource is related to an artist. In most cases this will be set to “true”.
- While the
ResourceReferencefield is superfluous for the communication of claims, it is technically mandatory in the current MLC standard. Each
SoundRecordingis identified locally within the scope of a single message by an anchor reference formed of the letter ‘A’ concatenated with an integer that increments for each SoundRecording composite.
The example shows is for the the first SoundRecording. The second would contain a value ‘A2’ and so on. These references need only be unique within in a given message
- ReferenceTitle - This is part of the 'reference descriptive metadata' for the recording. It is structured as the TitleText and SubTitle. In the DDEX standards, the TitleText is for the normal title of a recording and the SubTitle is a catch-all for version and/or subtitle information.
SubTitle is used to differentiate different recorded versions such as ‘live’, ‘radio edit’, ‘extended mix’ etc. The language of the title is carried within the tag (represented by an ISO 639 LanguageCode).