Upgrading from RDR-N Version 1.2 to Version 1.3

Based on needs of the music licensing companies participating in the SCAPR VRDB  project the following additions have been made to the Standard:

AssociatedSoundRecordingId added into SoundRecording

VRDB enables the identification of cases in which multiple ISRCs have been erroneously assigned to a given sound recording. This element allows VRDB societies to take into account ISRCs that have been erroneously assigned to a recording, without ignoring the ISRC properly assigned to uniquely identify a sound recording. This is done using an AssociatedSoundRecordingId composite alongside the SoundRecordingId, having the same structure as the SoundRecordingId.  (The use of this element is not mandatory).

RecordLastUpdatedDate added into SoundRecording

Music licensing companies have to decide when they download the record if they need to update their local system data.  By including a RecordLastUpdatedDate into the SoundRecording, the source of data can specify the last time a record was changed, which can be compared with the date on the target system.  (The use of this element is not mandatory).

VRDB2RepertoireManagerCode added into SoundRecording

VRDB has business rules that codify which music licensing company is principally responsible within the VRDB system for dealing with metadata about a given recording.  In essence VRDB delegates the data management to the music licensing company which is best placed to interact with the rights owner(s) for the specific recording. The VRDB2RepertoireManagerCode identifies the music licensing company that is repertoire manager of the metadata for a given SoundRecording within VRDB.  (The use of this element is not mandatory).

Booleans added at the SoundRecording level

  • In order to flag a recording for which metadata is not agreed or is under review, the flag IsSoundRecordingMetadataUnderReviewcan be attached at the SoundRecording level, taking TRUE/FALSE values.

  • In order to flag a recording with limited access to some metadata the flag IsSoundRecordingMetadataAccessRestricted can be attached at the SoundRecording level, taking TRUE/FALSE values. This might be used in the case where relevant music licensing companies do not have a reciprocal agreement in place between them to cover inter alia data sharing.

The use of these flags is optional.

Other changes implemented in v1.3 are:

  • PartyID becomes a top-level composite with sub-element that indicate the type of identifiers.

  • ICPN no longer has the IsEAN attribute, since it doesn’t matter whether UPC or EAN is used.

Studio Roles in MLC 1.3 and 1.3.1

The RDR standard allows for the communication of a role that a contributor to a sound recordings and/or music video played. 

This role code can be communicated in the Role element of the, for example, ResourceContributor composite. DDEX has, over the last few years, collated a large list of role codes for different types of contributors: performers, writers and studio personnel. 

However, the XML Schema Definitions for MLC 1.3 and 1.3.1 has a bug in that the Role element is does not all the role codes collated by DDEX. 

Implementers are requested to use role codes from the list used in MLC 1.4 and communicate them as UserDefinedValues with a namespace of “MLC14”. It is available from the Data Dictionary for MLC 1.4.

The role of a mixing engineer can thus be communicated with 

<ResourceContributor>
     […]
     <Role UserDefinedValue=”MixingEngineer” Namespace=”MLC14”>
        UserDefined
     </Role>
     […]
</ResourceContributor>

Instrument Information in MLC 1.3 and 1.3.1

The RDR standard allows for the communication of the role of contributors to sound recordings and music videos and, where appropriate, information about the instrument or instrument(s) played. 

This can be communicated in, for example, the InstrumentType element of the FeaturedArtist composite. DDEX has, over the last few years collated a large list of instruments that can be used within this tag. 

However, the XML Schema Definitions for MLC 1.3 and 1.3.1 has a bug in that the InstrumentType element is not limited to this allowed value set. 

Implementers are requested to use instruments from the list used in MLC 1.4. It is available from the Data Dictionary for MLC 1.4. If – and only if – an instrument that is not included in the above list, should the message sender should simply use its own value.

Search