- Created by DDEX Secretariat, last modified on 2021-07-02
This section of the DDEX Knowledge Base contains Version 1.0 of the Best Practices for Catalogue Transfers
1 Introduction
In 2011, DDEX published a choreography standard to improve the catalogue transfer process. However, that standard has not been implemented widely. These Best Practices replace this standard in order to assist companies relinquishing a catalogue of sound recordings, music videos and/or Releases, companies that acquire such catalogues and any DSPs that offer content from a transferred catalogue to make the transfer as smooth as possible for the three parties involved and without disrupting consumer experience. Any organisation wishing to implement a DDEX standard is required to apply for an Implementation Licence. The terms of the licence and an application form can be found on https://ddex.net/implementation/implementation-licence-and-ddex-party-identifiers.
2 Scope
It has been argued that there is no incentive for the company that relinquishes the rights to make the transfer smooth. However, this approach appears to be short-sighted as most record companies regularly acquire and relinquish catalogues. Thus, a company that is relinquishing content today is likely to acquire content tomorrow – where it would greatly benefit from a smooth transfer.
In addition, and as mentioned above, catalogue transfers cause additional workload for all involved companies, including the company relinquishing a catalogue as well as the aggregators and distributors providing services to the companies relinquishing and or acquiring content (e.g. for answering emails and telephone calls from a DSP who has detected an apparent overclaim from two record companies). Resolving such overclaims and other queries does also cause additional work for the acquiring rights controller and any involved DSPs.
Therefore, it seems reasonable to also expect record companies or aggregators/distributors who relinquish content to also help with the process of transferring catalogues.
3 Use Cases
A similar differentiation has to be made for the acquiring company: either the acquiring company is a Rights Controller (i.e. a company that has a direct relationship with the Relinquishing Rights Controller, hereafter referred to as an Acquiring Rights Controller) or an Aggregator/Distributor (who does not have such a direct relationship, hereafter referred to as an Acquiring Aggregator/Distributor):
A fifth case can be said to exist where a Rights Controller is moving its catalogue from one Aggregator/Distributor to another. This is, however, a simplification of case IV in the figure above and is, therefore, not addressed separately in this document.
Not in scope is the situation where a catalogue is transferred to an Acquiring Rights Controller or Acquiring Aggregator/Distributor that has no commercial relationship with a specific DSP. This is not addressed herein as such a Catalogue Transfer is, for that DSP, just a take-down.
4 Terms and Definition
Acquiring Aggregator/Distributor
An Aggregator/Distributor who is providing distribution services to an Acquiring Rights Controller.
Acquiring Label
The label (i.e. the brand under which a Release and/or Resource is issued and marketed) in whose catalogue the transferred Catalogue will appear after the Catalogue Transfer.
Acquiring Rights Controller
A Rights Controller, usually a record company, that is acquiring a Catalogue of Releases and/or Resources from a Relinquishing Rights Controller in a Catalogue Transfer.
Aggregator
A company that sends or receives DDEX messages on behalf of other companies. Aggregators enable smaller companies to participate in the DDEX ecosystem.
Catalogue Transfer
The process of transferring rights in a Catalogue of Releases and/or Resources from one Rights Controller to another Rights Controller. Catalogue Transfers may involve Distributors/Aggregators. .
Digital Service Provider (DSP)
A Digital Service Provider (DSP), a Party making Releases available to Consumers or other DSPs over a public Telecom network. This includes MSPs (Mobile Service Providers) and ISPs (Internet Service Providers).
Mapping Table
A message defined in accordance with these Best Practices that aids companies in a seamless Catalogue Transfer.
Relinquishing Aggregator/Distributor
An Aggregator/Distributor who is providing distribution services to a Relinquishing Rights Controller.
Relinquishing Label
A Music Publisher that has relinquished Right Shares of Musical Works, typically collated into a Catalogue, to another Music Publisher (the Acquiring Music Publisher).
Relinquishing Rights Controller
Rights Controller, usually a record company, that is relinquishing a Catalogue of Releases and/or Resources to an Acquiring Rights Controller in a Catalogue Transfer.
Rights Controller
A Party that controls rights in one or more Creations in respect of some or all rights for specific territories, time periods, Rights Types, Usage Types and Commercial Model Types (which may be anything up to and including all rights for the world, in perpetuity, for all types of Usage and for all types of Commercial Models). Creations include Musical Works, Sound Recordings and other Resources as well as Releases.
A Rights Controller is in many cases also the Licensor.
A Rights Controller may be a human being or other legal person or corporate entity.
A Rights Controller may or may not also be the Rights Administrator, the Licensing Agent or the Rights Holder.
A Rights Controller may or may not be the Message Sender or Message Recipient of a message in a specific information exchange defined by a DDEX Standard.
For the purposes of these Best Practices it is a party controlling rights in Releases and/or Resources such as Sound Recording and Music Videos.
5 Catalogue Transfer Procedure
- Establishing a contract between the Relinquishing Rights Controller and the Acquiring Rights Controller (see also Clause 5.2);
- Where the Relinquishing Rights Controller is using the services of an Aggregator/Distributor, the Relinquishing Rights Controller will need to obtain a copy of all the data from its Aggregator/Distributor (see also Clause 5.3);
- Establishing an operational communication between the Acquiring Rights Controller and the Relinquishing Rights Controller (see also Clause 5.4);
- Where the Acquiring Rights Controller is using the services of an Aggregator/Distributor, the Acquiring Rights Controller will need to provide all necessary data to its Aggregator/Distributor (see also Clause 5.5);
- Establishing an operational communication between the Acquiring Rights Controller or Aggregator/Distributor to any DSPs (see also Clause 5.6);
- Communication of Release and Deal information from Acquiring Rights Controller or Aggregator/Distributor to any DSPs (see also Clause 5.7);
- Provision of status reports from the DSP to the Acquiring Rights Controller or Aggregator/Distributor (see also Clause 5.8); and
- Communication of take-down notices from the Relinquishing Rights Controller or Aggregator/Distributor to any relevant DSPs (see also Clause 5.9).
In each of these stages, the additional aspects documented in Clause 6 should be taken into account.
The contract between the Relinquishing Rights Controller and the Acquiring Rights Controller should ideally be executed well in advance of the actual transfer date so that any DSPs and, where involved, Aggregators/Distributors can be informed well in advance to allow the process detailed in the remainder of this clause to be executed in good time.
In cases where the Relinquishing Rights Controller is distributing its content to DSPs using an Aggregator/Distributor, it is the Relinquishing Rights Controller’s responsibility to have access to its own instance of the data describing the Releases and Resources contained in the Catalogue to be transferred. This data should be separate from but identical to that held by the Aggregator/Distributor.
The preferred process for this communication is the process defined for the Data Transfer between the Rights Controllers detailed in Clause 5.4 below.
The preferred mechanism for this is a NewReleaseMessage as defined in the latest version of the Electronic Release Notification Message Suite Standard.
Such feeds should also include any data communicated by the Relinquishing Rights Controller to its business partners in a MeadMessage as defined in the latest version of the Media Enrichment and Description Information Standard.
If another mechanism has to be used, e.g. because the Relinquishing Rights Controller does not have the ability to communicate the creations using the Electronic Release Notification Message Suite Standard, all necessary data available to the Relinquishing Rights Controller and necessary to the Acquiring Rights Controller to effect the catalogue transfer should be sent in a mutually agreeable computer-readable format.
The data should include for all Releases, Track Releases, Sound Recordings and Videos the following data points (expressed, herein, as XPath fragments to the relevant XML tags in the NewReleaseMessage).
Release/ReleaseTypeRelease/ReleaseId/GRidRelease/ReleaseId/ICPNRelease/ReleaseId/CatalogNumberRelease/ReleaseId/ProprietaryId(all available proprietary identifiers)Release/DisplayTitle/TitleTextRelease/DisplayTitle/SubTitleRelease/DisplayArtistNameRelease/DisplayArtist(all available Display Artists, including, where appropriate, those that created the underlying Musical Work should be included)Release/DisplayArtist/SequenceNumberRelease/DisplayArtist/RoleRelease/ResourceGroup/ResourceGroupContentItem/ DisplaySequenceRelease/ResourceGroup/ResourceGroupContentItem/ SequenceNumberRelease/ResourceGroup/SequenceNumberRelease/ResourceGroup/TitleText for multi-disk Releases(with an appropriateRelease/ResourceGroup/TitleType)Release/Genre(all genres)Release/GlobalOriginalReleaseDateRelease/CLineRelease/GenreRelease/ParentalWarningTypeRelease/AvRating(for audio-visual releases)Release/KeywordsRelease/SynopsisRelease/MarketingCommentRelease/LabelReference(providing FullName and PartyId of the releasing label)
TrackRelease/ReleaseTypeTrackRelease/ReleaseId/ICPNRelease/ReleaseId/GRidTrackRelease/ReleaseId/CatalogNumberTrackRelease/ReleaseId/ProprietaryId(all available proprietary identifiers)TrackRelease/DisplayTitle/TitleTextTrackRelease/DisplayTitle/SubTitleTrackRelease/Genre(all genres)TrackRelease/KeywordsTrackRelease/SynopsisTrackRelease/MarketingCommentTrackRelease/LabelReference(providing FullName and PartyId of the releasing label)
SoundRecording/ResourceId/ISRCSoundRecording/ResourceId/ProprietaryId(all available proprietary IDs)SoundRecording/DisplayTitle/TitleTextSoundRecording/DisplayTitle/SubTitleSoundRecording/DisplayArtistSoundRecording/DisplayArtist/SequenceNumberSoundRecording/DisplayArtist/RoleSoundRecording/Contributor(performers, other recording artists, writers, engineers and the InitialProducer) with the following information:Party/PartyName/FullNameParty/PartyName/PartyId(any of them)
SoundRecording/Contributor/HasMadeFeaturedContributionSoundRecording/Contributor/HasMadeContractedContributionSoundRecording/Contributor/RoleSoundRecording/Contributor/InstrumentTypeSoundRecording/CreationDateSoundRecording/CreationDate/@ApplicableTerritoryCodeSoundRecording/DurationSoundRecording/LanguageOfPerformanceSoundRecording/WorkRightsController(incl. a name, identifier, sequence number, territory, period and role)SoundRecording/RightsController(incl. a name, identifier, sequence number, territory, period and role)SoundRecording/PLineSoundRecording/ParentalWarningType
Video[1]/CLine- Video/AvRating
Also, any available writer and publisher information should be communicated.
In addition, any other relevant information such as metadata sent to a DSP, for example using a MEAD message, should also be provided.
Any automated data exchange will need to be augmented by establishing contact between the operational teams at the Acquiring Rights Controller and the Relinquishing Rights Controller to ensure, amongst other things, that the above data exchange has successfully transferred all necessary data.
[1] For Videos the same data elements as marked above for Sound Recordings need to be provided as well.
The process of any data transfer from an Acquiring Rights Controller to its Aggregators/Distributors is defined by the bilateral agreements between these companies.
The Acquiring Rights Controller shall, however, indicate to its Aggregators/Distributors that the affected Releases are part of a Catalogue Transfer so that any DSPs affected by the Catalogue Transfer can, in turn, be informed accordingly.
This process shall equip the DSP to effect the Catalogue Transfer with, ideally, no down-time for any Releases and with all data linked to such Releases (e.g. playlists and user comments) being continuously available.
The Acquiring Rights Controller or Aggregator/Distributor shall communicate a Mapping Table in accordance with Clause 7 to the DSPs that it wishes to change the Catalogue over.
These Best Practices do not define a specific method of delivering the Mapping Table. Possible approaches include email attachments or placing the updated Mapping Table onto a mutually agreed SFTP server.
This data exchange will need to be augmented by establishing contact between the operational teams at the Acquiring Rights Controller or Aggregator/Distributor, and the DSP to accompany the entire Catalogue Transfer to completion.
One aspect to be agreed between Acquiring Rights Controller or Aggregator/Distributor, and the DSP is whether, how and when the DSP wishes to receive:
- New Release Notifications from the Acquiring Rights Controller or Aggregator/Distributor (as defined in Clause 5.7) and
- Take-downs from the Relinquishing Rights Controller or Aggregator/Distributor (as defined in Clause 5.9).
Options for these two communications include:
- Receipt of take-downs before the transfer date of the Catalogue with appropriate end dates;
- Receipt of take-downs after the transfer date of the Catalogue;
- Receipt of takedowns only after the DSP has successfully ingested new Release notifications;
- Receipt of new Release notifications with deals that overlap with the existing deals (or not); and
- Others.
Such Release Notifications shall contain, as part of the Deal section, the date/time of the Catalogue Transfer – as discussed between Acquiring Rights Controller or Acquiring Aggregator/Distributor and DSP – as the Deal’s start date/time.
This entire process will need to be co-ordinated by the two companies’ operational teams.
This status shall then be provided, in a bilaterally agreed interval, as feedback to the Acquiring Rights Controller or Aggregator/Distributor from whom the DSP has received the Mapping Table.
The status report back shall be the same file as received from the Acquiring Rights Controller or Acquiring Aggregator/Distributor with the status cells being filled in.
These Best Practices do not define a specific method of delivering the feedback report. Possible approaches include email attachments or placing the updated Mapping Table onto a mutually agreed SFTP server.
The following states may need to be reported:
- No delivery received yet;
- Successfully ingested and mapped;
- Delivery received; ingestion led to issues;
- No take-down notice from the Relinquishing Rights Controller or Relinquishing Aggregator/Distributor has been found yet; and
- Others as mutually agreed.
At that stage, the Relinquishing Rights Controller or Aggregator/Distributor should send relevant take-down notices to the DSPs. These take-down notices should communicate end dates as agreed between the involved parties.
There is no requirement for the Relinquishing Rights Controller or Aggregator/Distributor to communicate any details of a Catalogue Transfer to any DSPs.
6 Further Aspects for Catalogue Transfers
2020-06-30T24:00:00+00:00 in the take-down and 2020-07-01T00:00:00+00:00 in the new Deal) – assuming that the DSP supports such timed Deals.However, some DSPs may require that there is an overlap of the old and new Deal for a short period of time (e.g. a week) to be able to efficiently effect a Catalogue Transfer. Conversely, some DSPs would consider such concurrent Deals to be an overclaim and, thus, may take down the content as a precaution or stop any relevant payments to the sound recording Rights Controller.
When determining which approach to take, the Relinquishing Rights Controller or Aggregator/Distributor, the Acquiring Rights Controller or Aggregator/Distributor, and the DSP shall consider that it is preferable to manage overclaims than to lose content availability or content metadata on a live service.
If acceptable to the Relinquishing Rights Controller, the Acquiring Rights Controller and the relevant DSP, the DSP may effect a catalogue transfer without Release Deliveries from the Acquiring Rights Controller or Aggregator/Distributor, and without take-down notices from the Relinquishing Rights Controller or Aggregator/Distributor.
In that case, the Acquiring Rights Controller or Aggregator/Distributor will typically send new Release Deliveries for all affected Releases in the period following the Catalogue Transfer in order to ensure that it is confident that it has the ability to successfully update such Releases or Deals for such Releases in the future.
6.3.1 Stability
When obtaining data from a Relinquishing Rights Controller, an Acquiring Rights Controller should, if at all possible, continue to use, wherever possible, previously used identifiers. Ideally, these identifiers should not be proprietary identifiers but either standard or widely used industry identifiers.
For example, identifiers uniquely identifying parties, musical works or sound recordings should, if at all possible, not be changed – in most cases the assignment rules of the relevant identification systems would not allow the allocation of a new identifier in any case.
6.3.2 Provision of Old and New Identifiers
In cases where the Acquiring Rights Controller needs to update an identifier, it should provide this identifier, together with previously-used identifiers for the same entity, to the DSP. The purpose of this is to furnish the DSP with a mapping between old identifiers, particularly ICPNs/UPCs, and their replacements.
This mapping should be provided:
- From the Acquiring Rights Controller to any Aggregator/Distributor the Acquiring Rights Controller is using to distribute its content to DSPs; and
- From the Acquiring Rights Controller or Acquiring Aggregator/Distributor to any DSPs who will receive Electronic Release Notification messages with transferred content in the future.
The content of this Mapping Table is provided in Clause 7.
These Best Practices do not define a specific method of delivering the Mapping Table. Possible approaches include email attachments or placing the Mapping Table onto a mutually agreed SFTP server.
DSPs should use this Mapping Table to identify any creations in a Release delivery received from (or on behalf of) the Acquiring Rights Controller that are subject to a Catalogue Transfer and apply any logic that assists in transitioning the transferred creations over.
When the Acquiring Rights Controller needs to update the information sent in the Mapping Table, it should replace the entire Mapping Table (i.e. not send a Mapping Table for just the updated creations). This approach makes the process of applying the mappings consistently much easier – especially when managing the Catalogue Transfer manually.
The only exception to this rule is when (i) the DSP has provided feedback to the Acquiring Rights Controller or Acquiring Aggregator/Distributor that it has successfully ingested the Mapping Table and (ii) the two companies have mutually agreed to using Mapping Tables for just the updated creations.
7 Mapping Table
| Data Element | Definition |
|---|---|
RecordType | The Type of the row; always to contain ‘Header’. |
MappingTableId | A string used to uniquely identify the Mapping Table. The MappingTableId shall be, in combination with the MessageSenderId, globally unique. Thus, a MessageSender shall never re-use a MappingTableId. |
MappingTableCreatedDateTime | The DateTime on which the Mapping Table was created (the only allowed format is ISO 8601: YYYY-MM-DDThh:mm:ssTZD). |
CatalogName | The name of the Catalogue that is transferred. |
ApplicableTerritoryCode | The Territory/ies for which the Catalogue is transferred. |
RelinquishingRightsControllerName | The name of the Relinquishing Rights Controller. |
RelinquishingRightsControllerDPID | The DPID of the Relinquishing Rights Controller. This shall be provided if available to the sender. |
AcquiringRightsControllerName | The name of the Acquiring Rights Controller. |
AcquiringRightsControllerDPID | The DPID of the Acquiring Rights Controller. This shall be provided if available to the sender. |
In addition, it may be beneficial to also communicate the Name and DPID of the Aggregator/Distributor companies acting for the Relinquishing and/or Acquiring Rights Controller (if applicable) and Name and DPID of the sender and recipient of the Mapping Table. However, this information may be clear from the context in which a Mapping Table is sent.
For each Release that is part of the Catalogue Transfer the following information shall be included into the Mapping Table. Cells for which no information is available may be left empty. There is no need to include such a record if no Releases are to be transferred,
| Data Element | Definition |
|---|---|
RecordType | The Type of the row; always to contain ‘Release’. |
RecordId | The unique Identifier (specific to the Mapping Table) of the Record. This Identifier may be used to reference this Record in discussions between the various parties affected by the Catalogue Transfer. |
Status | The Status of the transfer of the Release described in this Record (see Section 5.8 for details). |
Title | The Title of the Release. |
SubTitle | The SubTitle of the Release. |
ICPN | The International Code Product Number (i.e. bar code) for the Release as used by the Acquiring Rights Controller and/or Acquiring Aggregator/Distributor. |
ICPN previously used by Relinquishing Rights Controller | The International Code Product Number (i.e. bar code) for the Release allocated by the Relinquishing Rights Controller. |
GRid | The Global Release Identifier for the Release as used by the Acquiring Rights Controller and/or Acquiring Aggregator/Distributor. |
GRid previously used by Relinquishing Rights Controller | The Global Release Identifier for the Release allocated by the Relinquishing Rights Controller. |
AcquiringRightsController ReleaseId | The Proprietary Identifier for the Release allocated by the Acquiring Rights Controller. |
RelinquishingRightsController ReleaseId | The Proprietary Identifier for the Release allocated by the Relinquishing Rights Controller. |
OtherProprietaryReleaseId | Any Proprietary Identifier(s) for the Release allocated in the form xxx:yyy where xxx is a string identifying the company or organisation responsible for the identification system and yyy is the identifier. If multiple identifiers are available, they should be separated by commas. |
DisplayArtistName | The string containing the Name to be used by a DSP when presenting Artist details of the Release to a Consumer. |
Genre | The Genre(s) for the Release. If multiple Genres are available, they should be separated by commas. |
SubGenre | The SubGenre(s) for the Release. If multiple SubGenres are available, they should be separated by commas. |
Comment | An Annotation providing additional information or a commentary to the information provided in this row. |
For each Resource that is part of the Catalogue Transfer the following information shall be included into the Mapping Table. Cells for which no information is available may be left empty. In order to indicate that a Release contains multiple Resources, the relevant Release row should be immediately followed by the appropriate set of Resource rows.
| Data Element | Definition | |
|---|---|---|
RecordType | The Type of the row; always to contain ‘SoundRecording’ or ‘Video’. | |
RecordId | The unique Identifier (specific to the Mapping Table) of the Record. This Identifier may be used to reference this Record in discussions between the various parties affected by the Catalogue Transfer. | |
Status | The Status of the transfer of the Resource described in this Record (see Section 5.8 for details). | |
Title | The Title of the Resource. | |
SubTitle | The SubTitle of the Resource. | |
ISRC | The ISRC for the Resource as used by the Acquiring Rights Controller and/or Acquiring Aggregator/Distributor. | |
ISRC previously used by Relinquishing RightsController | The ISRC the Acquiring Rights Controller and/or Acquiring Aggregator/Distributor are aware of being previously used for the Resource. | |
AcquiringRightsController ResourceId | The Proprietary Identifier for the Resource allocated by the Acquiring Rights Controller. | |
RelinquishingRightsController ResourceId | The Proprietary Identifier for the Resource allocated by the Relinquishing Rights Controller. | |
OtherProprietaryResourceId | Any Proprietary Identifier(s) for the Resource allocated in the form xxx:yyy where xxx is a string identifying the company or organisation responsible for the identification system and yyy is the identifier. If multiple identifiers are available, they should be separated by commas. | |
DisplayArtistName | The string containing the Name to be used by a DSP when presenting Artist details of the Resource to a Consumer. | |
Duration | The Duration of the Resource, ideally using the ISO 8601 PT[[hhH]mmM]ssS format (where lower case characters indicate variables, upper case characters are part of the string, e.g. one hour, two minutes and three seconds would be PT1H2M3S). The seconds section ss may include fractions (e.g. one minute and 30.5 seconds would be PT1M30.5S). | |
Contributor | The Names of the contributor or some of the contributors separated by commas. This is solely for aiding the recipient of the mapping table in identifying the Resource to be transferred and would only need to be provided when new identifiers – especially ISRCs – are being allocated by the new Rights Controller. The list does not need to be exhaustive and there is no need to provide identifiers or role codes for the Contributor(s). | |
PLine | The (P) RightsNotice for the Sound Recording. | |
CLine | The (C) RightsNotice for the Video. | |
Comment | An Annotation providing additional information or a commentary to the information provided in this row. | |
Evaluation Licence for DDEX Standards
Subject to your compliance with the terms and conditions of this Agreement, DDEX™ grants you a limited, nonexclusive, non-transferable, non-sublicenseable, royalty-free licence solely to reproduce, distribute within your organisation, and use the DDEX standard specifications (“DDEX Standards”) solely for the purpose of your internal evaluation. You may not make any commercial use of the DDEX Standards under this agreement. No other licences are granted under this agreement.
No representations or warranties (either express or implied) are made or offered by DDEX with regard to the DDEX Standards. In particular, but without limitation, no representations or warranties are made in relation to:
- The suitability or fitness of the standards for any particular purpose;
- The merchantability of the standards;
- The accuracy, completeness, relevance or validity of the standards; or
- The non-infringement of any third party intellectual property rights related to the DDEX Standards.
Accordingly, DDEX and/or its members shall not be liable for any direct, indirect, special, consequential or punitive loss or damages howsoever arising out of or in connection with the use of the standards. IN THE EVENT THAT ANY COURT OF COMPETENT JURISDICTION RENDERS JUDGEMENT AGAINST DDEX AND/OR ITS MEMBERS NOTWITHSTANDING THE ABOVE LIMITATION, THE AGGREGATE LIABILITY TO YOU IN CONNECTION WITH THIS AGREEMENT SHALL IN NO EVENT EXCEED THE AMOUNT OF ONE HUNDRED U.S. DOLLARS (US$ 100.00).
Users of the DDEX Standards are cautioned that it is subject to revision. Users are recommended to use the latest versions, which are available at http://www.ddex.net. The use of outdated versions of the standards is not recommended but may be required by agreement between implementers in particular cases.