SoundRecording node must include one or more
SoundRecordingDetailsByTerritory nodes. The first
SoundRecordingDetailsByTerritory node includes data which would apply for this
SoundRecording in all territories as a default, unless specifically overridden by further information provided in subsequent
SoundRecordingDetailsByTerritory nodes . Most implementers of the RDR-N message currently specify that only one
SoundRecordingDetailsByTerritory node should be supplied per
SoundRecording. This does not preclude the delivery of multi-territory rights ownership information. For further guidelines on territorial variations consult the following article: Guide to Territorial Variations in the SoundRecordingDetailsByTerritory Composite in RDR-N (v 1.5).
SoundRecordingDetailsByTerritory composite in v 1.5 has been simplified and as a result the following elements have been deleted from that composite and moved to the
All other elements listed as part of the Recommended or Core Data Profile in the table below remain unchanged and in line with v 1.4.
Which fields need to be provided?
DeclarationOfSoundRecordingRightsClaimMessage of DDEX’s RDR-N Standard in Version 1.5 can accommodate several hundred tags, a few of these in
SoundRecordingDetailsByTerritory are quite critical to effective use of the message in practice. The table below itemises the most critical tags which should be provided by record companies to music licensing companies.
The "Recommended Profile" is what DDEX recommends is sent, at a minimum, from record companies to music licensing companies as well as from music licensing companies to other music licensing companies in order to register a claim. The data set has been defined because it will enable most music licensing companies to accept the claim as stated and thus collect revenue for the rights holder. In some cases it may not be possible for the sender of the message to collate all the data elements listed in the "Recommended Profile". In that case the message sender should consider using the "Core Data Profile". This data set typically allows a claim to be registered, but the data provided may not be sufficient, on their own, to enable the music licensing company to accept the claim and thus undertake the correct collection of revenues. Amalgamated with data from other sources it may, however, be possible for music licensing companies to collect revenues and to pay out.
In the table below, tags are shown as "mandatory" or “include” as within the core or the recommended datasets for a recording, and thus core or recommended for inclusion in Declaration messages. The tags marked as "mandatory" are to ensure that implementers deliver messages that are technically valid agains the XSD. The tags shown as "include" have been added to provide practical guidance to record companies (and other senders of the claim message) on which data is generally needed by music licensing companies on operational grounds.
It is noted for good order that DDEX is not able to give definitive advice on the data policy of any specific music licensing company as there may be bilateral and contractual requirements for additional data sets – the table below is for general guidance.
DetailsByTerritory Fields for a SoundRecording Within ResourceList
Core Data Profile
Include for classical
Include for classical
At least one ID should be included
At least one ID should be included
The following notes are more detailed guidelines including sample data for some of the tags listed in the above table.
Worldwideis defined as an allowed value. When listing an exception (i.e. to
ExcludedTerritoryCodeshould be used.
SoundRecordingDetailsByTerritorythis tag can be used to express the title in another language, or an alternative title applicable in a given territory.
This is the artist name as associated with the recording. (See also the HostSoundCarrier node for artist name as associated with a given release on which the sound recording appears). The “artist name” element is solely descriptive information (i.e. does not convey or necessarily imply information about rights, performances or contributions.) Music licensing companies use this for matching to usage.
In the case that there are several artist names associated with the recording, the
DisplayArtistName acts as a “compound string”, as it would be displayed to the public.
- Example of a band name
DisplayArtistName: “The Weeknd”
- Example of several artists as
DisplayArtistNamein a “compound string”: “The Beatles & Tony Sheridan”
- Example of a “virtual” band
DisplayArtist is provided, the following are necessary:
MainArtist is a
Role and only applies to
MainArtist is the principal credited artist associated with a resource.
Note that the
DisplayArtist node may occur several times with the tag
SequenceNumber set to different integer values. The
SequenceNumber value is used as part of the enumeration of the artists to whom the recording is associated.
This field is mandatory when the
Classical, which is indicated by setting the
IsClassical flag to
true. For classical recordings, this is needed (along with the work title) in order to disambiguate the recording and to match usage.
DisplayComposer is provided, the following are mandatory:
PLine states the rightsholder detail at the time when the recording was published, and is not necessarily the same as the InitialProducer. It is the nationality of the InitialProducer that is one of the “points of attachment” determining eligibility under the treaties. The mandatory fields for PLine are:
ReleaseId - at least one of the following sub elements must be provided:
HostSoundCarrier\Titleis the title of the sound carrier / album that contains the track.
HostSoundCarrier\DisplayArtistNameare the name(s) of the artist(s) of the sound carrier / album on which the track is featured.
HostSoundCarrier\LabelNameis used for matching. It is safer to include label information at the
HostSoundCarriernode for a release than in the
HostSoundCarrier\NumberOfSoundRecordingsClaimedInCarrierhelps to avoid double claims in compilations, and helps to avoid omitting relevant recordings.
HostSoundCarrier\NumberOfTracksInCarrierindicates how many Tracks are included on the compilation. This needs to be provided if MessageSenderIsCompilatinCreator is set to true.
HostSoundCarrier\IsInternalCompilationindicates whether the rights to all
SoundRecordingson a compilation are controlled by the same record company.
HostSoundCarrier\MessageSenderIsCompilationCreatorindicates whether the
MessageSendercreated the compilation.
The latter three elements have been introduced into RDR-N 1.5 to facilitate the registration of compilations and the accurate repatriation of revenue to individual licensors of individual tracks released on a compilation. In addition to the
HostSoundCarrier elements listed in the recommended and core data profile those three additional elements are essential for the registration of compilations. For more detailed guidelines on how to register compilations and the use of elements required for each message sender depending on whether they are the compilation creator of an internal compilation, the compilation creator for a release with various artists licensed-in from a third party or a licensor of a sound recording on such a compilation please refer to Registering Compilations.
There are hundreds of genres and they correspond more to how an artist wants to be perceived or placed than to any objective criteria.
Typically, music licensing companies use Genre only for classical music as a trigger for special processing, such as to ensure composer information is present, and to apply matching rules better suited to classical metadata. When sending data about classical music it should be indicated using the
 It is important for music licensing companies to receive information about as many
HostSoundCarriers – physical or electronic – as possible to in order to aid them in their matching and distribution efforts.