RDR-N: SoundRecording DetailsByTerritory (version 1.4)

Each 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?

• Implementation Notes

  • TerritoryCode

  • Title

  • DisplayArtistName

  • DisplayComposer 

  • PerformingContributor

  • OtherContributor

  • InitialProducer

  • RightsController

  • OriginalResourceReleaseDate 

  • Pline

  • HostSoundCarrier

(Note: "RDR" is the new name for the "MLC" Standards.)

Which fields need to be provided?

Whilst the DeclarationOfSoundRecordingRightsClaimMessage of DDEX’s RDR Standard in Version 1.4 can accommodate several hundred tags, a few of these in SoundRecording and 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.

Implementation Notes

TerritoryCode

This defines the territory or territories covered by this node.  Worldwide is defined as an allowed value.  When listing an exception (i.e. to Worldwide) an ExcludedTerritoryCode should be used.

Title

In SoundRecordingDetailsByTerritory this 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 LanguageAndScriptCode\TitleText\SubTitle.

Example of Title

<Title LanguageAndScriptCode="en" TitleType="DisplayTitle">
 
      <TitleText>My Song</TitleText>
      <SubTitle>Album Version</SubTitle>
</Title>

DisplayArtistName

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 DisplayArtistName in a “compound string”: “The Beatles & Tony Sheridan”

• Example of a “virtual” band DisplayArtistName: “Gorillaz”.

When the DisplayArtist is provided, the following are necessary:

• FullName

• DisplayArtistRole

MainArtist is a Role and only applies to DisplayArtist.  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.

Example of DisplayArtistName and DisplayArtist

<DisplayArtistName> The Weeknd ft. Daft Punk</DisplayArtistName>
 
<DisplayArtist SequenceNumber="1">
  <PartyName LanguageAndScriptCode="en">
    <FullName>The Weeknd</FullName>
  </PartyName>
  <PartyId>
    <ProprietaryId Namespace="PADPIDA2007061301U">1234567
    </ProprietaryId>
  </PartyId>
  <DisplayArtistRole>MainArtist</DisplayArtistRole>
</DisplayArtist>
<DisplayArtist SequenceNumber="2">
  <PartyName LanguageAndScriptCode="en">
    <FullName>Daft Punk</FullName>
  </PartyName>
  <PartyId>
    <ProprietaryId Namespace="PADPIDA2007061301U">7654321
    </ProprietaryId>
  </PartyId>
  <DisplayArtistRole>FeaturedArtist</DisplayArtistRole>
</DisplayArtist>

DisplayComposer 

This field is mandatory when the Genre is 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.
When the DisplayComposer is provided, the following are mandatory:

• FullName

• PrimaryRole

PerformingContributor

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 HasMadeFeaturedContribution and HasMadeContractedContribution in the PerformingContributor\Contribution.Music licensing companies use the contribution category along with the role and/or roles in determining remuneration.

A 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:

• PartyName\FullName

• PartyId\IPN (if available)

• PartyId\ProprietaryId with sender’s proprietary ID

• DateAndPlaceOfBirth (place is optional) [1]

• Contribution\Role

• Contribution\InstrumentType

• Contribution\HasMadeFeaturedContribution

• Contribution\HasMadeContractedContribution

• Contribution\Event

• Contribution\Event\ApplicableTerritoryCode

Example: PerformingContributor

 <PerformingContributor SequenceNumber="1">
  <PartyId>
    <IPN>12345678</IPN>
  </PartyId>
  <PartyId>
    <ProprietaryID Namespace="PADPIDA2007061301U">12345678</ProprietaryID>
  </PartyId>
  <PartyName>
    <FullName>Jane Doe</FullName>
    <NamesBeforeKeyName>Jane</NamesBeforeKeyName>
    <KeyName>Doe</KeyName>
  </PartyName>
  <DateAndPlaceOfBirth>1968-06-12</DateAndPlaceOfBirth>
  <Contribution>
    <Role>Musician</Role>
    <HasMadeFeaturedContribution>true</HasMadeFeaturedContribution>
    <HasMadeContractedContribution>true</HasMadeContractedContribution>
    <InstrumentType>Banjo</InstrumentType>
    <Event ApplicableTerritoryCode="GB" LocationDescription="Abbey Road Studios">2017-02-04</Event>
  </Contribution>
</PerformingContributor>

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.

OtherContributor

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 Director etc.

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”.

InitialProducer

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”.

RightsController

This is mandatory along with the following fields

• OriginalResourceReleaseDate 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.

• PartyName\FullName

• PartyId\ProprietaryId with sender’s proprietary ID.  Local producer ID is always used by music licensing companies.

• PartyId\ProprietaryId with recipient’s proprietary ID

• RightsControllerType – This is necessary for several music licensing companies. Type of rights holder can be OriginalCopyrightOwner, SuccessorInTitle, or ExclusiveLicensee as defined by the DDEX AVS.

• RightSharePercentage.  The percentage of rights owned between the start and end dates of ownership. (12.5 = 12.5%).

• DelegatedUsageRights

• UseType.  The type of use for which the recording may be licensed.  This takes a value from the DDEX AVS.

• PeriodOfRightsDelegation\StartDate

• TerritoryOfRightsDelegation expressed as ISO 3166-1 alpha-2 codes or Worldwide.

OriginalResourceReleaseDate 

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.

Example: OriginalResourceReleaseDate

<OriginalResourceReleaseDate TerritoryCode="US">2011-01-02</OriginalResourceReleaseDate>
<OriginalResourceReleaseDate TerritoryCode="GB">2012-01-02</OriginalResourceReleaseDate>

Pline

The 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 PLIne are:

• Year

• PlineText

Since PLineText will be deprecated by DDEX in future versions of the standard but remains mandatory for the time being, it may be left blank.

HostSoundCarrier

For the ReleaseId - at least one of the following sub elements must be provided:

• ICPN

• CatalogNumber

• ProprietaryId

In addition

• HostSoundCarrier\Title is the title of the sound carrier / album that contains the track.

• HostSoundCarrier\DisplayArtistName are the name(s) of the artist(s) of the sound/carrier on which the track is featured.

• HostSoundCarrier\LabelName is used for matching.  It is safer to include label information at the HostSoundCarriernode for a release than in the SoundRecordingDetailsByTerritory.

• HostSoundCarrier\NumberOfSoundRecordingsClaimedInCarrier helps 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 Genre\isClassical flag.

Example for Additional Performer Data in the SoundRecording Composite

<NumberOfFeaturedPerformingContributors>4</NumberOfFeaturedPerformingContributors>
<NumberOfNonFeaturedPerformingContributors>2</NumberOfNonFeaturedPerformingContributors>
<LineupComplete>false</LineupComplete>

[0] For collectives such as bands and orchestras, no such date is needed.

[1] 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.

[2] 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.

[3] 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.