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-R 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.)
This page contains, in addition to the sample on the right, the following information:
Which fields need to be provided?
DeclarationOfSoundRecordingRightsClaimMessage of DDEX’s RDR Standard in Version 1.4 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 table below sets out firstly “core” and secondly “recommended” tags to be included in Declaration messages. The genesis of this information was a meeting with many record companies and music licensing companies which took place in Berlin with the objective 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:
The set of tags marked as “core” should be understood as being sufficient data for many music licensing companies to register a recording and allocate revenue against it when the recording is used. However, the rights owner may – dependent on the distribution rules of the particular music licensing company – need to supply some additional data in order to meet the music licensing company's threshold for pay out.
The set of tags marked as “recommended” are generally sufficient for many music licensing companies to allocate revenue when the recording is used and to pay out within the distribution.
In the table below, tags are shown as “include” as within the core or the recommended datasets for a recording, and thus core or recommended for inclusion in Declaration messages. Implementers must also ensure that they deliver messages that are technically valid against the XSD. 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 – the table below is for general guidance.
DetailsByTerritory Fields for a SoundRecording Within ResourceList
Core Data Profile
Include for classical
Include for classical
Include unless the claim or mandate is open ended
Include unless the claim or mandate is open ended
At least one ID should be included
At least one ID should be included
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 in accordance with ERN-3 profile rules. See also: Title
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 composite 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:
Some music licensing companies need data about the contributors to a recording and the nature of their contributions, so that contributors that are eligible and qualifying for equitable remuneration can be paid. The “contribution category” of a contributor can be “featured” or “non-featured”, and “contracted” or “non-contracted”. This information is communicated using the flags
HasMadeContractedContribution in the
PerformingContributor\Contribution. Music licensing companies use the contribution category along with the role and/or roles in determining remuneration.
PerformingContributor is either an individual person or a collective (such as an orchestra), referred to by their name and/or the identifier used to designate them within systems such as SCAPR’s IPD.
A “featured” contribution is one made by a performer who is prominently featured in relation to the release (as opposed to a session musician, who would typically make a “non-featured” contribution
There will often be multiple
PerformingContributors, enumerated using the
SequenceNumber attribute. For each
PerformingContributor, the following are necessary:
PartyId\ProprietaryIdwith sender’s proprietary ID
DateAndPlaceOfBirth(place is optional) 
Roles – Within the
PerformingContributor composite each
Contribution node expresses one
Role in which the performer has contributed to the recording.
Roles such as soloist, musician, conductor, and so on can be expressed using DDEX role codes or if appropriate using SCAPR SDEG role codes.
InstrumentType details can also be provided, and the
Event node can convey the date and location of the performance.
Contributions to the recording that are not performance based, such as certain studio roles, should be carried in the
OtherContributor node, annotated by details of the role(s) such as
Example: to show that a role of video director is displayed on a product, use:
Video\VideoDetailsByTerritory\OtherContributor and use
PartyName\FullName for the director, also using the
Contribution\Role with a role code for “director”.
DDEX defines the term
InitialProducer as being a party that initiates the creation of the
SoundRecording. This is the legal entity responsible for the creation of the recording. This term relates to a definition “producer of phonograms” in the WIPO Performances and Phonograms Treaty, being “the person, or the legal entity, who or which takes the initiative and has the responsibility for the first fixation of the sounds of a performance or other sounds, or the representations of sounds.” Music licensing companies sometimes term this party “commissioning producer”.
This is mandatory along with the following fields
OriginalResourceReleaseDatecan be to the nearest year and is used by music licensing companies in assessing whether the copyright term has expired or not. The TerritoryCode conveys the country(ies) of (simultaneous) first publication, which is a “point of attachment” determining eligibility under the treaties.
PartyId\ProprietaryIdwith sender’s proprietary ID. Local producer ID is always used by music licensing companies.
PartyId\ProprietaryIdwith recipient’s proprietary ID
RightsControllerType– This is necessary for several music licensing companies. Type of rights holder can be
ExclusiveLicenseeas defined by the DDEX AVS.
RightSharePercentage.The percentage of rights owned between the start and end dates of ownership. (12.5 = 12.5%).
UseType.The type of use for which the recording may be licensed. This takes a value from the DDEX AVS.
TerritoryOfRightsDelegationexpressed as ISO 3166-1 alpha-2 codes or Worldwide.
This field can be to the nearest year and is used by music licensing companies in assessing whether the copyright term has expired or not. The TerritoryCode conveys the country(ies) of (simultaneous) first publication, which is a “point of attachment” determining eligibility under the treaties.
PLine states the rightsholder detail at the time 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
PLineText will be deprecated by DDEX in future versions of the standard but remains mandatory for the time being, it may be left blank.
For the 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 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
Genre –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, MLCs 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
 For collectives such as bands and orchestras, no such date is needed.
 Elements marked with an asterisk, i.e. “Included*” are technically mandatory, i.e. if they are omitted the resulting XML file would not pass an XSD validation and would, therefore, be invalid.
 The date of birth is a key field for many music licensing companies to disambiguate contributors. It is therefore recommended that message senders provide this information at all times, assuming they have access to it.
 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.