Various artists in ERN

ERN-4

To communicate that an album is from “various artists” the following approach should be taken in ERN-4:

  • Create a Party composite for the “non-party” without a PartyId;

  • Place, into this Party composite one or more PartyNames for the languages required expressing, for example, “various artists”;

  • Place into the relevant Release (or resource) composite a set of DisplayArtistNames for the languages required; and

  • Reference the above Party composite with a Role of MainArtist from the Release (or Resource) composite.

This is shown below:

<Party>
    <PartyReference>P1</PartyReference>
    <PartyName>
        <FullName>Various Artists</FullName>
    </PartyName>
</Party>
 
[…]
 
<DisplayArtistName>Various Artists</DisplayArtistName>
<DisplayArtist>
    <ArtistPartyReference>P1</ArtistPartyReference>
    <Role>MainArtist</Role>
<DisplayArtist>

The sender of the message should, however, satisfy themselves that the message recipient will understand that the above does not create a party with the name “Various Artists” but that, instead, the release was released by a set of artists whose names should not appear on the album cover.

Alternatively, even though “various artists” is not a party, sender and recipient could bilaterally agree a specific PartyId for “various artists” and communicate this ID in the Party composite:

<Party>
    <PartyReference>P1</PartyReference>
    <PartyId>
        <ProprietaryId Namespace=”XXXX”>12345</ProprietaryId>
    </PartyId>
    <PartyName>
        <FullName>Various Artists</FullName>
    </PartyName>
</Party>
 
[…]
 
 
<DisplayArtistName>Various Artists</DisplayArtistName>
<DisplayArtist>
    <ArtistPartyReference>P1</ArtistPartyReference>
    <Role>MainArtist</Role>
<DisplayArtist>

With 12345 being the ID agreed between message sender and message recipient for the “non-party” and XXXX being the DDEX Party ID of the company that was responsible for using 12345 as the Party ID for the “non-party” called “various artists”. This would typically be the either the message sender or the message recipient.

Knowing that a work is a traditional (i.e. a work for which there is no known composer and where the music functions as a marker of identity for a particular cultural group and has grown out of their oral tradition) should equally be communicated to a DSP if the fact is known by the record company. The same approach as shown above should be used for such instances.

<Party>
    <PartyReference>P1</PartyReference>
    <PartyName>
        <FullName>Traditional</FullName>
    </PartyName>
</Party>
 
[…]
 
<Contributor>
    <ContributorPartyReference>P1</ContributorPartyReference>
    <Role>ComposerLyricist</Role>
<Contributor>

The alternative approach discussed above (i.e., bilaterally agreeing on a specific PartyId for a concept such as “traditional” and communicate this ID in the Party composite even though “traditional” is not a party) can also be used here.

ERN-3

While the ERN-3 standard does technically not require a DisplayArtist for each release and sound recording (or video), most implementers’ systems expect such data in ERN-3 messages.

It is therefore recommended to use the principle described above for ERN-4 when creating ERN-3 messages:

<DisplayArtistName>Various Artists</DisplayArtistName>
 
[…]
 
<DisplayArtist>
    <PartyName>
        <FullName>Various Artists</FullName>
    </PartyName>
    <ArtistRole>MainArtist</ArtistRole>
<DisplayArtist>

The alternative approach discussed above (i.e., bilaterally agreeing on a specific PartyId for a concept such as “various artists” and communicate this ID in the Party composite even though “various artists” is not a party) can also be used in ERN-3.

Search