Mehrsprachige Musik-Metadaten: ISRC, DSP-Einreichung, Benennung

Kurz gefasst

Mehrsprachige Musik-Releases scheitern selten am Audio, sondern an den Metadaten: falsche ISRC-Vergabe, Regelverstöße bei Titel und Credits, unklare Sprachkennzeichnung. Dieser Leitfaden bündelt die offiziellen Regeln von IFPI, Apple Music und Spotify für ISRC, DSP-Einreichung und Benennung.

Inhaltsverzeichnis

• Warum Metadaten über Sichtbarkeit und Auszahlung entscheiden
• ISRC: Aufbau, Vergabe und Regeln für Sprachversionen
• Mehrsprachige Titel und Localizations bei DSPs
• Benennungsregeln der großen DSPs im Vergleich
• Die DSP-Einreichung: Pflichtfelder, Rollen und DDEX-Lieferung
• Häufige Fehler und ihre Folgen: Ablehnung, Korrektur, Tantiemen
• Checkliste für mehrsprachige Releases
• Häufige Fragen
• Quellen

Das Wichtigste

• Jede Aufnahmevariante (Remix, Edit, Live, Sprachfassung) braucht einen eigenen ISRC; ein bereits vergebener Code darf nicht wiederverwendet werden.
• Apple verlangt die Metadaten-Sprache auf Album-Ebene und die Audio-Sprache auf Track-Ebene; Side-by-Side-Übersetzungen in einem Feld werden abgelehnt.
• Versionszusätze gehören bei allen großen DSPs in Klammern hinter den Titel, feat./with klein und auf Englisch, Featured-Künstler als eigene Rolle.
• Spotify zeigt Musik exakt wie geliefert an und empfiehlt ein Release-Datum mindestens 7 Tage in der Zukunft; Korrekturen laufen nur über den Distributor.
• Falsches Casing, Werbetext und falsch platzierte Versionszusätze sind die häufigsten Ablehnungsursachen bei Apple Music.

Warum Metadaten über Sichtbarkeit und Auszahlung entscheiden

Jedes Musik-Release durchläuft dieselbe Kette: Vom Studio zum Distributor, vom Distributor zum DSP. Die Metadaten, die dabei übertragen werden, steuern drei Dinge zugleich: wie ein Track in der App aussieht, wem die Credits zugeordnet werden und welche Auszahlung am Ende bei wem landet. Spotify zeigt Musik exakt so an, wie sie geliefert wird; Korrekturen laufen ausschließlich über den Distributor, der ein Update an die Plattform senden muss[1]. Der Distributor ist damit die einzige Korrekturschleife im System, und jede Korrektur kostet Zeit, die eine Release-Kampagne selten hat.

Der ISRC ist dabei der Schlüssel für die Stream-Zuordnung. Fast jedes System, das Geld verteilt, nutzt den Code, um festzustellen, welche konkrete Aufnahme einen Stream, einen Download oder eine Sync-Nutzung erzeugt hat. Fehlt der Identifier oder ist er falsch, läuft die Nutzungsmeldung ins Leere und die Zuordnung muss manuell nachgezogen werden. Genau deshalb sind Metadaten kein Formular-Kram am Rande, sondern Infrastruktur.

Mehrsprachige Kataloge erhöhen die Fehleranfälligkeit deutlich, und zwar an drei Stellen:

• Umlaute und Sonderzeichen: Deutsche, französische oder nordische Titel brauchen korrekt gesetzte Sprachcodes, sonst erscheinen Akzente und Sonderzeichen fehlerhaft.
• Schriftsysteme: Kataloge mit arabischen, hebräischen, kyrillischen oder asiatischen Titeln müssen zwischen Originalschrift und Transliteration trennen.
• Sprachvarianten desselben Werks: Eine englische, eine spanische und eine deutsche Fassung desselben Songs sind drei eigenständige Aufnahmen mit eigener Kennung, eigener Benennung und eigener Abrechnung.

Wer diese drei Ebenen sauber trennt, vermeidet die klassischen Folgeprobleme: abgelehnte Einreichungen, plattformübergreifend abweichende Anzeigen und Tantiemen, die auf dem falschen Konto landen. Wie das im Detail aussieht, zeigen die nächsten Abschnitte. Der strategische Hintergrund, warum sich mehrsprachiger Vertrieb überhaupt lohnt, ist Thema des Artikels zu Content-Distribution.

ISRC: Aufbau, Vergabe und Regeln für Sprachversionen

Der ISRC ist ein ISO-Standard zur Identifikation von Ton- und Musikvideo-Aufnahmen; die dritte Ausgabe erschien 2019 als ISO 3901:2019, und die IFPI empfiehlt ihren Mitgliedern die Nutzung seit 1988[2]. Der Code besteht aus zwölf alphanumerischen Zeichen: einem fünfstelligen Prefix Code (zwei Buchstaben plus drei alphanumerische Zeichen), einem zweistelligen Year of Reference, also den letzten zwei Stellen des Jahres, in dem der Code vergeben wird, und einem fünfstelligen Designation Code. Für die Anzeige gegenüber Menschen gibt es ein erweitertes Format mit dem Präfix ISRC und Bindestrichen, etwa ISRC AA-6Q7-20-00047, während der Code selbst nur aus den zwölf Zeichen besteht[2].

Die Kernregel der Vergabe kennt keine Ausnahmen: Jede eigenständige Aufnahme erhält genau einen ISRC, und ein einmal vergebener ISRC bleibt der Aufnahme über ihre gesamte Lebensdauer zugeordnet, auch wenn die Rechte den Besitzer wechseln[3]. Eine Aufnahme, die seit der Codevergabe eine materielle Änderung erfahren hat, darf nicht unter dem alten ISRC laufen, sondern bekommt einen neuen Code. Als solche Änderungen gelten laut IFPI unter anderem abweichende Versionen mit anderer Laufzeit, andere Mixe und Edits, ein neuer Surround-Mix aus vorhandenen Stems sowie Restaurierungen historischer Aufnahmen mit kreativem Eingriff[4]. Die Wiederverwendung eines bereits vergebenen ISRC für eine andere Aufnahme ist unter keinen Umständen erlaubt[3].

Für mehrsprachige Kataloge folgt daraus: Jede Sprachversion eines Songs ist eine eigene Aufnahme und braucht ihren eigenen ISRC, denn verschiedene Aufnahmen müssen laut IFPI immer mit unterschiedlichen, eindeutigen Codes identifiziert werden[3]. So können Plattformen und Tantiemen-Systeme die Fassungen sauber auseinanderhalten und die Nutzung korrekt zuordnen. Wie eine Sprachfassung technisch entsteht, ohne die Originalstimme zu verlieren, behandelt der Artikel zum Lied übersetzen mit KI.

Neben dem Code selbst gehören zu jedem ISRC Referenz-Metadaten, die der Registrant dauerhaft speichern sollte. Ohne diesen Datensatz lässt sich später nicht mehr belegen, welche Aufnahme hinter welchem Code steht:

• Titel der Aufnahme
• Versionstitel, etwa Radio Edit oder Live
• Hauptkünstler oder Bandname
• Laufzeit der Aufnahme
• Typ, also Tonaufnahme oder Musikvideo
• Jahr der Erstveröffentlichung

Mehrsprachige Titel und Localizations bei DSPs

Die großen DSPs behandeln Sprache nicht als ein Feld, sondern als mehrere, und genau diese Trennung wird bei internationalen Releases oft verletzt. Apple unterscheidet auf Album-Ebene die Metadata Language von der Track Audio Language auf Track-Ebene. Der Sprachcode der Metadaten muss zur Sprache der Metadaten passen, nicht zur Sprache des Gesangs, damit Akzente und Sonderzeichen korrekt erscheinen[5]. Die Audio Language dagegen muss zur gesungenen oder gesprochenen Sprache des Tracks passen; enthält eine Datei keine gesprochenen Worte, wird der Code zxx für „no linguistic content“ verwendet[6].

Für die Anzeige in verschiedenen Märkten gelten bei Apple weitere klare Vorgaben[5]:

• Localizations für alle verfügbaren Sprachen liefern, sofern die Metadaten nicht in allen Territorien in der Primärsprache erscheinen sollen.
• Nie Side-by-Side-Übersetzungen in ein Feld schreiben: Pro Eintrag oder Localization gilt genau eine Sprache.
• Im Native Field steht der Titel in der Originalschrift, die Transliteration wird als eigene Localization geliefert, etwa Hebräisch im Native Field und die lateinische Umschrift als englische Localization.
• Keine Emojis in Titeln, Künstlernamen oder sonstigen Metadaten.

Die Konsequenz für internationale Kataloge liegt auf der Hand: Ein deutsch-englischer Katalog mit Titeln wie „Über den Wolken“ braucht die Originalschrift im Native Field und die sprachlich korrekte Localization daneben, nicht beides in einem Feld. Genau an dieser Stelle lohnt es sich, die Zielsprachen des Katalogs von Anfang an festzuhalten und pro Sprache zu pflegen, statt Felder nachträglich zu flicken. Wer Songs erst in weitere Sprachen übersetzt, findet die technischen Grundlagen im Artikel zur Audio-Vertonung mit KI.

Benennungsregeln der großen DSPs im Vergleich

Apple Music, Spotify, Deezer und YouTube Music haben jeweils eigene Style Guides, aber die Kernregeln decken sich weitgehend. Die wichtigsten gemeinsamen Nenner lassen sich kompakt zusammenfassen:

Regel	Vorgabe	Beispiel
Versionszusatz	Immer als Titel (Version) in Klammern hinter dem Haupttitel, etwa Live, Radio Edit oder Sped Up Version	Songtitel (Live Version)
Featuring	feat. klein, auf Englisch, nicht lokalisiert, in Klammern; der Featured Artist wird als eigene Rolle mit eigenem Feld gepflegt, nicht nur im Titel	Songtitel (feat. Name)
Verbotene Inhalte	Keine Werbetexte, Emojis, URLs oder dekorative Zeichen in Metadaten	Kein „Out now“ im Titel
Groß-/Kleinschreibung	Folgt den Regeln der jeweiligen Titelsprache, keine künstliche Kapitalisierung	Deutsche Titel mit Großschreibung der Substantive

Beim Künstlernamen gelten zwei Regeln, die über alle Plattformen hinweg identisch sind. Erstens: Die Schreibweise bleibt von Release zu Release konsistent, einschließlich Zeichensetzung und Abkürzungen; SEO-Begriffe wie Christmas Hits oder Sleep Music als Künstlername sind nicht erlaubt[1]. Zweitens: Auch auf YouTube sollte der Kanalname exakt der Schreibweise der offiziellen Releases entsprechen, inklusive Groß- und Kleinschreibung und Leerzeichen[7]. Ein Künstlername, der je Plattform anders geschrieben steht, zersplittert später Profile und Playlisten-Historien.

Die DSP-Einreichung: Pflichtfelder, Rollen und DDEX-Lieferung

Vom fertigen Master bis zur Plattform liegt ein Prozess mit festen Pflichtfeldern. Die Rollen müssen auf Song- und Release-Ebene angegeben werden: Hauptkünstler, Featuring, Remixer, Komponist, Texter und Produzent, bei klassischem Content zusätzlich Dirigent und Orchester[1]. Apple verlangt vollständige und genaue Credits bereits bei der Lieferung, über alle Kreditkategorien hinweg, also Performer, Produktion und Komposition[5].

Neben den Rollen sind vier Felder für den Einreichungszeitpunkt entscheidend:

• Veröffentlichungsdatum mit Vorlauf: Spotify empfiehlt, das Live-Datum mindestens 7 Tage in der Zukunft zu setzen, unter anderem damit genug Zeit bleibt, den unveröffentlichten Song für Playlists zu pitchen[1].
• Länderverfügbarkeit: Die Territorien werden pro Release angegeben oder weltweit freigegeben[1].
• Explicit-Markierung: Explizite Tracks werden als solche markiert und erhalten ein E-Icon, das Zeichen gehört nicht in den Titel[1].
• Identifikatoren: UPC für das Release, ISRC für jeden Track, dazu vollständige Track-Informationen und Territory-Angaben[8].

Technisch transportiert wird all das als DDEX-ERN-Nachricht. Das Electronic Release Notification Message Suite überträgt Releases und Ressourcen samt ISRC, UPC und Deal-Terms vom Record Company oder Distributor an den DSP[9]. Die Branche migriert derzeit zwischen ERN 3.8.2 und der 4.x-Familie, und DDEX empfiehlt dringend die neueste Version, aktuell ERN 4.3.x[9]. Deezer etwa akzeptiert weiterhin DDEX 3.x sowie 4.1 und 4.3, bevorzugt aber innerhalb dieser Familien jeweils 3.8 und 4.3[8]. Welcher Standard für welchen DSP gilt, entscheidet der Distributor je Plattform.

Häufige Fehler und ihre Folgen: Ablehnung, Korrektur, Tantiemen

Schlampige Metadaten haben konkrete, messbare Folgen. Apple prüft jede Lieferung über das Quality-Assurance-Team und stellt bei Verstößen Tickets, die sofortige Aufmerksamkeit erfordern und verknüpfte Marketingmaßnahmen stören können[10]. Zu den häufigsten Ablehnungsursachen gehören falsche Groß- und Kleinschreibung, Werbetexte in Metadaten und falsch platzierte Versionszusätze, die nicht als Titel (Version) in Klammern stehen[5].

Nicht jeder Fehler führt zu einem Ticket. DSPs führen auch stille Korrekturen durch oder unterdrücken einzelne Felder, und dann weicht die Anzeige plattformübergreifend ab: Der Titel steht bei einem Dienst mit Zusatz, beim anderen ohne, die Credits sind unvollständig. Für den Hörer sieht das nach zwei verschiedenen Songs aus, für die Algorithmen nach zwei verschiedenen Künstlern.

Besonders teuer sind Fehler bei den Identifikatoren. Doppelte oder falsche ISRCs verletzen die Grundregel, dass jede Aufnahme genau einen, dauerhaft gültigen Code trägt[3], und führen so zu falsch zugeordneten Tantiemen und Problemen beim Distributorwechsel, weil die Historie nicht mehr sauber auf die Aufnahmen verweist. Und inkonsistente Künstlernamen zersplittern Profile und Stream-Historien, weil die Plattformen die Releases nicht mehr demselben Künstler zuordnen können[1]. Beides lässt sich nachträglich nur über den Distributor korrigieren, Feld für Feld, Release für Release.

Checkliste für mehrsprachige Releases

Vor jeder Abgabe lohnt eine kompakte Prüfung entlang der vier Fehlerquellen aus diesem Artikel. Die folgende Checkliste fasst die Punkte zusammen, die sich in der Praxis als die kritischsten erwiesen haben:

1. ISRC pro Aufnahmevariante prüfen: Jede Sprachfassung, jeder Remix und jeder Edit hat einen eigenen Code, kein Code wird wiederverwendet, und die Referenz-Metadaten mit Titel, Version, Hauptkünstler, Laufzeit, Typ und Erstveröffentlichungsjahr sind dokumentiert.
2. Titel je Sprache als eigene Localization anlegen: Originalschrift im Native Field, Transliteration als Localization, Versionszusatz in Klammern, keine Side-by-Side-Übersetzungen in einem Feld.
3. Sprachcodes korrekt setzen: Metadata Language auf Album-Ebene zur Metadatensprache, Track Audio Language zur Gesangssprache, nichtsprachlicher Inhalt als zxx.
4. Rollen und Credits vollständig erfassen: Hauptkünstler, Featuring, Remixer, Komponist, Texter und Produzent auf Song- und Release-Ebene, Künstlername konsistent über alle Releases, kein Werbetext, keine Emojis, keine URLs.
5. Lieferdatum mit Puffer planen: Live-Datum mindestens 7 Tage in der Zukunft, Länderverfügbarkeit und Explicit-Markierung geprüft, danach die DSP-Anzeigen plattformübergreifend abgleichen.

Bei Katalogen mit vielen Sprachvarianten lohnt es sich, diese Felder nicht in verteilten Tabellen, sondern zentral und konsistent zu pflegen. Ein strukturiertes Redaktionssystem wie ContentHub Studio hilft dabei, Titel, Localizations und Sprachcodes pro Sprache an einem Ort zu verwalten und für jedes neue Release wiederzuverwenden. Wer den Einstieg in die mehrsprachige Content-Produktion sucht, findet ihn im Artikel zur Content-Lokalisierung für Creator.

Häufige Fragen

Braucht jede Sprachversion eines Songs einen eigenen ISRC?

Ja. Der ISRC identifiziert die konkrete Aufnahme, nicht das Werk. Sobald eine Aufnahme materiell verändert wird, etwa als Remix, Edit, Live-Version oder neue Sprachfassung, muss ein neuer ISRC vergeben werden; die IFPI nennt als materielle Änderung ausdrücklich abweichende Laufzeiten, andere Mixe und Edits. Die unveränderte Aufnahme behält ihren Code dagegen dauerhaft, auch bei Labelwechsel oder Neuveröffentlichung.

Wie ist ein ISRC aufgebaut?

Ein ISRC besteht aus 12 Zeichen: einem fünfstelligen Prefix Code, einer zweistelligen Jahresangabe (Jahr der Vergabe, nicht zwingend des Aufnahmejahres) und einem fünfstelligen Designation Code. Für Menschen wird er mit Bindestrichen geschrieben, etwa ISRC AA-6Q7-20-00047. Der Standard ist als ISO 3901:2019 normiert, die IFPI empfiehlt ihn seit 1988.

Darf ich den Titel eines Tracks in zwei Sprachen in ein Feld schreiben?

Nein. Apple Music verbietet Side-by-Side-Übersetzungen in Metadaten-Feldern ausdrücklich. Jedes Feld enthält genau eine Sprache; für weitere Sprachen liefert man eigene Localizations. Das Native Field trägt die Originalschrift, etwa hebräische oder arabische Zeichen, die englische Transliteration läuft als separate Localization.

Warum wird mein Release von Apple Music abgelehnt, obwohl Audio und Cover korrekt sind?

Die häufigsten Ablehnungsursachen liegen in den Metadaten: falsche Groß-/Kleinschreibung für die Titelsprache, Werbetext wie Official oder New Single, URLs, Emojis oder Versionszusätze an falscher Position. Apple prüft jede Lieferung über ein Quality-Assurance-Team und stellt bei Verstößen Tickets, die die Veröffentlichung verzögern.

Muss der feat.-Hinweis im Songtitel stehen?

Nein, im Gegenteil. Featured-Künstler werden als eigene Rolle im Contributor-Feld geliefert; Apple Music und Spotify fügen die Anzeige automatisch hinzu. Wenn feat. doch im Titel steht, muss es bei Apple klein, auf Englisch, nicht lokalisiert und in Klammern erscheinen, etwa Track Name (feat. Artist).

Was hat es mit Metadata Language und Track Audio Language auf sich?

Apple Music verlangt auf Album-Ebene die Sprache der Metadaten selbst, damit Akzente und Sonderzeichen korrekt dargestellt werden, und auf Track-Ebene die gesungene oder gesprochene Sprache des Audios. Nichtsprachlicher Inhalt wie Instrumentals wird mit dem Code zxx gekennzeichnet. Beide Codes müssen jeweils zur tatsächlichen Sprache passen.

Wie werden Metadaten technisch an die DSPs geliefert?

Der Standardweg ist eine DDEX-ERN-Nachricht: Sie beschreibt Tracks, Künstler, Rollen, Identifikatoren wie ISRC und UPC, Cover, Territorien und Konditionen. Die Branche migriert derzeit von ERN 3.8.2 zu ERN 4.x; welcher Distributor welche Version je DSP spricht, entscheidet über eine saubere Lieferung. Rückläufige Abrechnungsdaten kommen als DSR-Meldungen zurück.

Quellen

1. support.spotify.com
2. ifpi.org
3. isrc.ifpi.org
4. isrc.ifpi.org
5. help.apple.com
6. help.apple.com
7. artists.youtube
8. creatorsupport.deezer.com
9. kb.ddex.net
10. itunespartner.apple.com