Song translationEN

Multilingual Music Metadata: ISRC, DSP Submission, Naming

Jack Clawson

Dictem Editorial

September 16, 2026

13 min

Multilingual Music Metadata: ISRC, DSP Submission, Naming

In short

Multilingual music releases rarely fail because of the audio – they fail because of the metadata: incorrect ISRC assignment, rule violations in titles and credits, unclear language tagging. This guide brings together the official rules from IFPI, Apple Music and Spotify on ISRC, DSP submission and naming.

Table of contents

Why metadata determines visibility and payouts
ISRC: structure, assignment and rules for language versions
Multilingual titles and localizations at DSPs
Naming rules of the major DSPs compared
The DSP submission: mandatory fields, roles and DDEX delivery
Common mistakes and their consequences: rejection, correction, royalties
Checklist for multilingual releases
Frequently asked questions
Sources

Key takeaways

Every recording variant (remix, edit, live, language version) needs its own ISRC; an already assigned code must not be reused.

Apple requires the metadata language at album level and the audio language at track level; side-by-side translations in a single field are rejected.

On all major DSPs, version suffixes belong in brackets after the title, feat./with in lowercase and in English, with featured artists as a separate role.

Spotify displays music exactly as delivered and recommends a release date at least 7 days in the future; corrections only go through the distributor.

Incorrect casing, promotional text and misplaced version suffixes are the most common causes of rejection at Apple Music.

Why metadata determines visibility and payouts

Every music release goes through the same chain: from the studio to the distributor, from the distributor to the DSP. The metadata transmitted along the way controls three things at once: how a track looks in the app, who the credits are attributed to, and who ultimately receives which payout. Spotify displays music exactly as it is delivered; corrections go exclusively through the distributor, who must send an update to the platform.[1] The distributor is therefore the only correction loop in the system, and every correction costs time that a release campaign rarely has.

The ISRC is the key to stream attribution. Almost every system that distributes money uses the code to determine which specific recording generated a stream, a download or a sync usage. If the identifier is missing or wrong, the usage report goes nowhere and the attribution has to be reconciled manually. This is exactly why metadata is not peripheral form-filling, but infrastructure.

Multilingual catalogs significantly increase the susceptibility to errors, in three places:

Umlauts and special characters: German, French or Nordic titles need correctly set language codes, otherwise accents and special characters appear incorrectly.

Writing systems: Catalogs with Arabic, Hebrew, Cyrillic or Asian titles must separate the original script from transliteration.

Language variants of the same work: An English, a Spanish and a German version of the same song are three standalone recordings, each with its own identifier, its own naming and its own accounting.

Anyone who separates these three levels cleanly avoids the classic downstream problems: rejected submissions, displays that differ across platforms, and royalties landing in the wrong account. The next sections show what this looks like in detail. The strategic background of why multilingual distribution is worthwhile at all is covered in the article on content distribution.

ISRC: Structure, Assignment and Rules for Language Versions

The ISRC is an ISO standard for the identification of sound and music video recordings; the third edition was published in 2019 as ISO 3901:2019, and the IFPI has recommended its use to its members since 1988.[2] The code consists of twelve alphanumeric characters: a five-character Prefix Code (two letters plus three alphanumeric characters), a two-digit Year of Reference, i.e. the last two digits of the year in which the code is assigned, and a five-character Designation Code.[2] For display to humans there is an extended format with the ISRC prefix and hyphens, such as ISRC AA-6Q7-20-00047, while the code itself consists only of the twelve characters.

The core rule of assignment knows no exceptions: Every standalone recording receives exactly one ISRC, and an ISRC once assigned remains associated with the recording for its entire lifetime, even if the rights change owner.[3] A recording that has undergone a material change since the code was assigned must not continue to run under the old ISRC, but receives a new code. According to the IFPI, such changes include, among others, differing versions with a different running time, other mixes and edits, a new surround mix made from existing stems, and restorations of historical recordings with creative intervention.[4] Reusing an already assigned ISRC for a different recording is under no circumstances permitted.[3]

For multilingual catalogs it follows that: Every language version of a song is its own recording and needs its own ISRC, because different recordings must always be identified with different, unique codes according to the IFPI.[3] This allows platforms and royalty systems to keep the versions cleanly apart and assign usage correctly. How a language version is technically created without losing the original voice is covered in the article on translating songs with AI.

In addition to the code itself, every ISRC comes with reference metadata that the registrant should store permanently. Without this record, it is no longer possible later to prove which recording lies behind which code:

Title of the recording

Version title, such as Radio Edit or Live

Main artist or band name

Running time of the recording

Type, i.e. sound recording or music video

Year of first release

Multilingual Titles and Localizations at DSPs

The major DSPs treat language not as a single field but as several, and it is precisely this separation that is often violated in international releases. Apple distinguishes, at the album level, the Metadata Language from the Track Audio Language at the track level. The language code of the metadata must match the language of the metadata, not the language of the vocals, so that accents and special characters appear correctly.[5] The Audio Language, on the other hand, must match the sung or spoken language of the track; if a file contains no spoken words, the code zxx for "no linguistic content" is used.[6]

For display in different markets, Apple has further clear requirements:[5]

Provide Localizations for all available languages, unless the metadata is to appear in the primary language in all territories.

Never write side-by-side translations into one field: Exactly one language applies per entry or Localization.

The Native Field contains the title in the original script; the transliteration is delivered as its own Localization, for example Hebrew in the Native Field and the Latin transcription as an English Localization.

No emojis in titles, artist names or any other metadata.

The consequence for international catalogs is obvious: a German-English catalog with titles like "Über den Wolken" needs the original script in the native field and the linguistically correct localization next to it – not both in one field. This is exactly where it pays off to define the catalog's target languages from the start and maintain them per language, rather than patching fields afterwards. If you translate songs into additional languages, you will find the technical foundations in the article on AI audio dubbing.

Naming rules of the major DSPs compared

Apple Music, Spotify, Deezer and YouTube Music each have their own style guides, but the core rules largely overlap. The most important common denominators can be summarized compactly:

Rule	Requirement	Example
Version suffix	Always as title (version) in parentheses after the main title, e.g. Live, Radio Edit or Sped Up Version	Song Title (Live Version)
Featuring	feat. lowercase, in English, not localized, in parentheses; the featured artist is maintained as a separate role with its own field, not just in the title	Song Title (feat. Name)
Prohibited content	No advertising copy, emojis, URLs or decorative characters in metadata	No "Out now" in the title
Capitalization	Follows the rules of the respective title language, no artificial capitalization	German titles with capitalized nouns

Two rules apply to the artist name, identical across all platforms. First: the spelling remains consistent from release to release, including punctuation and abbreviations; SEO terms such as Christmas Hits or Sleep Music as an artist name are not allowed.[1] Second: even on YouTube, the channel name should exactly match the spelling of the official releases, including capitalization and spacing.[7] An artist name spelled differently on each platform later fragments profiles and playlist histories.

The DSP submission: mandatory fields, roles and DDEX delivery

Between the finished master and the platform lies a process with fixed mandatory fields. The roles must be specified at song and release level: main artist, featuring, remixer, composer, lyricist and producer, and for classical content additionally conductor and orchestra.[1] Apple requires complete and accurate credits already at delivery, across all credit categories, i.e.[5] performance, production and composition.

In addition to the roles, four fields are crucial for the submission timeline:

Release date with lead time: Spotify recommends setting the live date at least 7 days in the future, among other things so that there is enough time to pitch the unreleased song for playlists.[1]

Country availability: The territories are specified per release or released worldwide.[1]

Explicit marking: Explicit tracks are marked as such and receive an E icon; that symbol does not belong in the title.[1]

Identifiers: UPC for the release, ISRC for each track, plus complete track information and territory details.[8]

Technically, all of this is transported as a DDEX ERN message. The Electronic Release Notification Message Suite transfers releases and resources, including ISRC, UPC and deal terms, from the record company or distributor to the DSP.[9] The industry is currently migrating between ERN 3.8.2 and the 4.x family, and DDEX strongly recommends the latest version, currently ERN 4.3.x.[9] Deezer, for example, continues to accept DDEX 3.x as well as 4.1 and 4.3, but prefers 3.8 and 4.3 respectively within these families.[8] Which standard applies to which DSP is decided by the distributor per platform.

Common mistakes and their consequences: rejection, correction, royalties

Sloppy metadata has concrete, measurable consequences. Apple reviews every delivery through its Quality Assurance team and files tickets for violations that require immediate attention and can disrupt linked marketing campaigns.[10] The most common rejection reasons include incorrect capitalization, promotional copy in metadata, and misplaced version descriptors that are not formatted as Title (Version) in parentheses.[5]

Not every error leads to a ticket. DSPs also make silent corrections or suppress individual fields, and then the display diverges across platforms: the title appears with a descriptor on one service and without it on another, the credits are incomplete. To the listener this looks like two different songs; to the algorithms, like two different artists.

Errors in identifiers are especially costly. Duplicate or incorrect ISRCs violate the fundamental rule that every recording carries exactly one, permanently valid code, and thus lead to misallocated royalties and problems when switching distributors, because the history no longer cleanly maps to the recordings.[3] And inconsistent artist names fragment profiles and streaming histories, because the platforms can no longer attribute the releases to the same artist.[1] Both can only be corrected afterwards via the distributor, field by field, release by release.

Checklist for Multilingual Releases

Before every delivery, it is worth running a compact check along the four sources of error covered in this article. The following checklist summarizes the points that have proven most critical in practice:

Check the ISRC per recording variant: Every language version, every remix and every edit has its own code, no code is reused, and the reference metadata with title, version, main artist, duration, type and first-release year is documented.

Create the title per language as its own localization: original script in the Native Field, transliteration as a localization, version descriptor in parentheses, no side-by-side translations in a single field.

Set language codes correctly: Metadata Language at album level to the metadata language, Track Audio Language to the sung language, non-lyrical content as zxx.

Capture roles and credits completely: main artist, featuring, remixer, composer, lyricist and producer at song and release level, artist name consistent across all releases, no promotional copy, no emojis, no URLs.

Plan the delivery date with a buffer: live date at least 7 days in the future, country availability and explicit flag checked, then compare the DSP displays across platforms.

For catalogs with many language variants, it pays to maintain these fields centrally and consistently rather than in scattered spreadsheets. A structured editorial system like ContentHub Studio helps manage titles, localizations and language codes per language in one place and reuse them for every new release. If you are looking to get started with multilingual content production, the article on content localization for creators is a good starting point.

Frequently asked questions

Does every language version of a song need its own ISRC?

Yes. The ISRC identifies the specific recording, not the work. As soon as a recording is materially altered – for example as a remix, edit, live version or new language version – a new ISRC must be assigned; the IFPI explicitly cites differing runtimes, alternative mixes and edits as material changes. The unaltered recording, by contrast, keeps its code permanently, even after a label change or re-release.

How is an ISRC structured?

An ISRC consists of 12 characters: a five-character Prefix Code, a two-digit year (the year of assignment, not necessarily the year of recording) and a five-character Designation Code. For humans it is written with hyphens, e.g. ISRC AA-6Q7-20-00047. The standard is codified as ISO 3901:2019, and the IFPI has recommended it since 1988.

Am I allowed to write a track's title in two languages in one field?

No. Apple Music explicitly prohibits side-by-side translations in metadata fields. Each field contains exactly one language; for additional languages you supply separate Localizations. The Native Field carries the original script, such as Hebrew or Arabic characters, while the English transliteration runs as a separate Localization.

Why is my release rejected by Apple Music even though the audio and cover are correct?

The most common reasons for rejection lie in the metadata: incorrect capitalisation for the title's language, promotional text such as Official or New Single, URLs, emojis, or version descriptors in the wrong position. Apple checks every delivery through a quality assurance team and raises tickets for violations, which delay the release.

Does the feat. credit have to appear in the song title?

No, quite the opposite. Featured artists are delivered as their own role in the Contributor field; Apple Music and Spotify add the display automatically. If feat. does appear in the title, it must be lowercase, in English, not localised and in parentheses at Apple, e.g. Track Name (feat. Artist).

What is the deal with Metadata Language and Track Audio Language?

Apple Music requires the language of the metadata itself at album level, so that accents and special characters are displayed correctly, and the sung or spoken language of the audio at track level. Non-linguistic content such as instrumentals is marked with the code zxx. Both codes must match the actual language in each case.

How are metadata technically delivered to the DSPs?

The standard route is a DDEX ERN message: it describes tracks, artists, roles, identifiers such as ISRC and UPC, cover art, territories and terms. The industry is currently migrating from ERN 3.8.2 to ERN 4.x; which distributor speaks which version to which DSP determines whether a delivery is clean. Sales and usage data come back as DSR reports.