Music Release Metadata: The Complete Technical Reference

With a full treatment of Arabic, Persian and Urdu script.

Why metadata matters more than people think

Metadata is not paperwork attached to your music. It is the music, as far as every system downstream is concerned. A streaming service never hears your record; it reads your delivery. The fields you type decide which artist page the track lands on, whether your streams accumulate under one identity or scatter across three, which royalty pool the publishing side pays from, whether the release is findable in its listeners' language, and whether it is accepted at all. A recording with a flawless master and broken metadata behaves, commercially, like one that was never released: it exists, it plays, and nothing accrues to the right person. The damage is asymmetric in time — cheap to prevent in the ten minutes before delivery, slow and often impossible to correct afterwards, because dozens of systems have already copied the mistake. Metadata is the only part of a release that every platform reads and no listener sees, which is exactly why it fails silently.

1. The fields that actually exist, and what each one controls

A release is not one object but a hierarchy: a release (the product) contains recordings (the tracks), each embodying one or more works (the compositions). Each layer has its own identifier — UPC/EAN, ISRC, ISWC — and its own money. Nearly every expensive metadata mistake is a fact filed at the wrong layer. The transport is standardised: DDEX's Electronic Release Notification Message Suite (ERN) is how a release and its metadata reach a service.

Primary artist. The billing name of the act. This field, and only this field, determines which artist page the recording lands on and which artist accrues listener counts, followers and algorithmic history. Spotify's public guidance is explicit: "List each artist's name in a separate field."

Featured artist. A separate role on the same recording: it credits the featured act and links to their page without giving them primary billing. Apple's style guide requires featured artists at track level with the Featuring or With role, "not as Primary."

Remixer. Also a role. Apple: "Remix tracks...must list the original artist as Primary with the remixer assigned the remixer role." Filing a remixer as primary artist is how remix catalogues pollute an artist's page.

Composer and lyricist. The songwriting credits. They describe the work, not the recording, and are the fields from which publishing and mechanical royalties are traced.

Producer. A contributor role: a credit, not a page and not a recording-side payment.

Version / subtitle. The parenthetical distinguishing one recording of a title from another: Live, Instrumental, Radio Edit (section 4).

Explicit flag. A boolean, not a word. Apple: "Explicit content must be flagged Explicit with a parental advisory tag. Terms like (Explicit)...must not be used for album...or track titles." Spotify: "you shouldn't add it to your track title." Music Biz prohibits the reverse too: never write "Clean" or "Non-explicit" into a title.

Language of the work (what is sung) and language of the title (the language and script of the title string) are different fields and legitimately differ — an instrumental with a Persian title has no lyric language but a Persian title language. Title language tells a store how to sort, index and render your text: one of the most consequential fields in non-Latin delivery.

P-line: year plus owner of the sound recording, the year being that recording's first publication, not your upload date. C-line: year plus owner of the artwork and packaging. Not interchangeable, and routinely copy-pasted into each other.

Genre. A routing signal, not a description of your taste; it shapes which editorial and algorithmic contexts a release is eligible for.

Release date is when this product goes live; original release date is when the recording was first published anywhere. Filing a 2016 recording with a 2026 original release date tells every downstream system it is new. An ISRC identifies the recording, so a re-release needs no new ISRC and the code stays with the recording when you change distributor — but a remix, edit, live version or instrumental is a materially different recording and requires its own. A remaster is the narrow case: the ISRC Handbook (§A.10.1) requires a new code only where the re-mastering processes "involve the application of creative input to the recording itself," and explicitly excludes simple level change, invariant EQ or compression, de-noising, de-clicking, speed or pitch correction, sample-rate change and dithering. The safe practical rider is that if the remaster is sold as a separate track alongside the original, it is a separate product and needs its own code.

Identifiers, precisely. An ISRC is twelve characters: two country, three registrant, two year-of-reference, five designation. Hyphens are a display convention, not part of the code, and there is no check digit in an ISRC. A UPC-A is twelve digits and an EAN-13 thirteen; prefixing a zero turns one into the other and the check digit does not change. If you cannot say which layer a fact belongs to — release, recording, or work — you cannot yet file it correctly.

2. Artist name consistency: the most expensive small mistake

An artist name is not text to a store. It is a key. When a delivery arrives with a primary artist string that does not exactly match an existing identity, the matching logic either attaches it to that artist or creates a new one; anything that reduces confidence — a different spelling, diacritic, space, script, or byte sequence for the same glyph — pushes it toward a new one.

So one artist becomes two. The catalogue splits, the streams split, and the follower base does not follow the second identity, so that identity starts with no algorithmic history at all. Royalties still pay, but against two accrual histories, and anything measured at catalogue level — editorial consideration, analytics, verification — is now measured on half a career.

Both major style references agree. Music Biz: "Artist name spelling should remain consistent for all content for an artist, where possible." Spotify: keep spelling and formatting consistent release to release, "including any punctuation, abbreviations, or acronyms."

The failure modes are mundane: inconsistent diacritics — the Music Biz guide's own example is "Beyoncé vs. Beyoncè" — a trailing space, "DJ" versus "Dj", an ampersand in one release and "and" in the next, two Unicode representations of the same accented letter (section 5.8), and in Arabic-script names an invisible difference no proofreader can see.

Fixing it afterwards is not an edit but a merge request: your distributor asks each store to merge two identities, each store handles it separately with its own queue and evidence requirements, and some resolve it quickly while others never do. A split artist page is not a bug you fix; it is a claim you file, store by store, and hope.

The defence is to write the canonical name down once and paste it into every delivery thereafter. Retyping is where variants are born.

3. Featured artists: why the title field is the wrong place

The most common damaging entry in independent distribution is typing Artist A ft. Artist B into the title field while leaving the featured artist role empty. The title field is a display string; it carries no identity. So the featured artist gets no credit link, no appearance on their own page, no discovery path back to your record and nothing in their analytics — while the store may treat "ft. Artist B" as part of the song's name, so the track is called Song Name ft. Artist B forever, producing the duplicated "Song Name (feat. X) — Artist A, X" that marks an amateur delivery on sight.

The stores say so plainly. Spotify: "You shouldn't include any artists' names in your track or release titles," and, in provider documentation, "Spotify strongly recommends against including additional information, such as references to 'Featured Artists' in track and product titles." Music Biz advises crediting featured artists "at the Artist role level and not add this data to the track or album release title."

Where a contract requires the billing in the title, the conventions are consistent. Music Biz, on "feat." and "with": "when included in the title are generally lowercase and in English." Apple: "Formatting of 'feat.' and 'with' must be lowercase, in English, not localized, and in parentheses or brackets." That "not localized" instruction matters enormously here: do not translate "feat." into Arabic, Persian, Urdu, Turkish or Indonesian in a title field — it is a machine-readable token, not a word.

The correct structure: the title field holds the song's name and nothing else, and each act goes in its own role field — the store then generates every display, including the "(feat. X)" you wanted, from the roles you filed. Roles are identity; titles are display, and putting identity in a display field destroys the identity and corrupts the display.

4. Version and subtitle handling

The version field exists to distinguish two recordings that share a title. That is its entire job, and the test for whether to fill it in. The vocabulary is stable: Radio Edit, Extended Mix, Live, Acoustic, Instrumental, Single Version, Alternate Take, Demo, Remastered, and named remixes as Artist Name Remix. Apple: "To differentiate multiple versions of the same track title, use terms in parentheses or brackets such as: Alternate Take...Live, Instrumental, Single Version, Radio Edit." On punctuation, Music Biz directs you to use parentheses first and brackets for any further detail: I Will Possess Your Heart (Originally Performed by Death Cab for Cutie) [Karaoke Instrumental Version].

"Radio Edit" is not a synonym for "the clean one." Music Biz reserves it for a version genuinely prepared for broadcast and directs you to "Edited Version" for a non-explicit edit. A Radio Edit is normally a length edit; an Edited Version is a content edit.

"Original Mix" is not universally safe, and this is a real divergence between stores. Apple's published guide disallows it: "The standard, original version of an album, track, or music video must not include any additional information in the title unless it is needed to identify the content," listing among disallowed terms "Exclusive, Limited Edition, Album Version, Original Mix, Tone, Alert Tone...Dolby Atmos, lossless, high-resolution audio." Spotify's publicly available metadata guidance publishes no rule naming "Original Mix"; its published position is the general one that titles should not carry additional information. Meanwhile the label remains entrenched convention in electronic-music retail, where an original ships alongside named remixes.

Apple's published guide names "Original Mix" as disallowed; other services publish no rule naming it either way, and treatment varies by store and by your distributor's own pre-validation. If the original is the only version on the release, leave the field empty — correct everywhere. If you are shipping an original plus remixes, expect at least one destination to strip or reject the label. And wherever a version field exists, use it rather than hand-typing the version into the title; stores that build their own display strings will otherwise produce Song (Radio Edit) (Radio Edit).

5. Non-Latin script: Arabic, Persian and Urdu

This is the section with no good equivalent in any language, including English. Almost every artist working in Arabic script has hit one of these problems and been told nothing about why. Note at the outset: we know of no published measurement of Arabic-script metadata error rates anywhere in the industry — the problem is universally experienced and entirely unquantified.

5.1 Logical order versus visual order

Unicode stores text in logical order — the order you say it, type it and read it aloud. Display order is computed from that at render time by the Unicode Bidirectional Algorithm, Unicode Standard Annex #9 (UAX #9), which states: "The Unicode Standard prescribes a memory representation order known as logical order," and "When working with bidirectional text, the characters are still interpreted in logical order—only the display is affected."

This explains the phenomenon that makes Arabic-script artists believe their metadata is haunted: the stored string can be perfectly correct while the display is wrong, and it can be visually correct while the stored bytes are wrong — and on screen the two failures look identical.

5.2 Why a Latin token inside an Arabic string moves

UAX #9 gives every character a bidirectional type: Arabic, Persian and Urdu letters are AL, Latin letters L, ASCII digits EN (European Number), Arabic-Indic digits AN (Arabic Number), and spaces and most punctuation are neutral.

Two rules do the damage. Paragraph direction: rules P2–P3 scan for the first strong directional character and set the base direction from it, so a title beginning with a Latin word gets left-to-right base direction even if the rest is Persian. Neutral resolution: rule N1 — "A sequence of [neutrals] takes the direction of the surrounding strong text if the text on both sides has the same direction" — and rule N2, where neutrals with no consensus take the paragraph direction. Rule L2 then reorders for display: "reverse any contiguous sequence of characters that are at that level or higher."

So a Latin token — a remixer's name, "feat.", "Vol. 2" — sits at a different embedding level than the Arabic around it, the neutrals on its boundaries resolve to whichever side wins, and the punctuation jumps to the wrong end of the phrase. Your carefully typed نام آهنگ (Nima Remix) renders with the bracket detached and flipped. Nothing is corrupted; the bytes are what you typed. The store's page, with a left-to-right base direction, simply resolved the neutrals differently than your right-to-left editor did. Base direction is context, not content, and the store's context is not yours.

Mitigations: use separate fields instead of mixed-direction strings wherever the model offers them; keep any unavoidable Latin token out of first position; avoid decorative punctuation at direction boundaries. Never "fix" the display by typing words backwards — that yields a string wrong in logical order, right in exactly one rendering context, and broken everywhere else including search. UAX #9 defines isolate characters for this (LRI, RLI, FSI, PDI, and the marks LRM, RLM, ALM), but many pipelines strip invisible formatting characters.

5.3 Digits: Arabic-Indic versus Persian

Three digit sets are in play: ASCII 0–9; Arabic-Indic digits U+0660–U+0669 (٠١٢٣٤٥٦٧٨٩) used in Arabic; and extended Arabic-Indic digits U+06F0–U+06F9 (۰۱۲۳۴۵۶۷۸۹) used in Persian and Urdu, where ۴ ۵ ۶ look different from Arabic ٤ ٥ ٦.

These are not stylistic variants but different code points, and per the Unicode Character Database they do not even share a bidirectional class: Arabic-Indic digits are AN, extended Arabic-Indic digits EN. (UAX #9 rule W2 re-types a European number to an Arabic number when the nearest preceding strong character is an Arabic letter, so inside Persian text the two may behave alike at display time — but never in sorting, search or string comparison, because they are different characters.)

A listener searching "آلبوم ۲" will therefore not match a title stored as "آلبوم 2" unless that store's search layer folds digits, which no destination guarantees. Pick one digit set for a catalogue and never mix them; for machine-read fields such as volume and part numbers, ASCII is the safest default.

5.4 Persian ی and ک versus Arabic ي and ك

Arabic uses U+064A ARABIC LETTER YEH (ي) and U+0643 ARABIC LETTER KAF (ك). Persian uses U+06CC ARABIC LETTER FARSI YEH (ی) and U+06A9 ARABIC LETTER KEHEH (ک). In final and isolated position the two yehs are near-identical in many fonts, and kaf and keheh differ by a stroke that many typefaces flatten.

Both are correct; neither is a typo. But they are different code points, so a name typed on an Arabic keyboard layout and the same name typed on a Persian layout are different strings to every matching and sorting system on earth, while being indistinguishable to the eye. That is the mechanism behind a large share of split Persian and Urdu artist pages: the artist registers on a Persian keyboard, someone retypes the name on an Arabic layout for release two, the store creates a second artist, and nobody finds it by looking, because there is nothing to see.

The same class covers the Urdu inventory — U+06C1 HEH GOAL (ہ) versus U+0647 HEH (ه), U+06BE HEH DOACHASHMEE (ھ), U+06BA NOON GHUNNA (ں) versus U+0646 NOON (ن), U+06D2 YEH BARREE (ے), and retroflex letters such as U+0679 TTEH (ٹ). In Arabic itself the recurring pair is U+0629 TEH MARBUTA (ة) versus U+0647 HEH (ه) at word end: a real orthographic choice in some spellings, and a silent catalogue-splitter when applied inconsistently.

The fix is procedural, not technical: decide the exact code points of the artist name once, store that string in a file, and paste it — never retype it — into every field of every release forever.

5.5 Zero-width non-joiner (U+200C)

Persian orthography requires the zero-width non-joiner to separate parts of a compound without a space: می‌روم, کتاب‌ها, نیم‌فاصله. It is a real character (U+200C, bidirectional class BN) and it changes the shaping of the letters on either side.

It is also invisible. Copy-paste through systems that sanitise "invisible" or "control" characters deletes it silently; some form fields strip it; some pipelines replace it with a space, which is worse, because it changes the word. A name delivered once with the ZWNJ and once without is two different strings and potentially two different artists. Check for it explicitly rather than by eye.

5.6 Tatweel / kashida (U+0640)

The tatweel (kashida), U+0640, stretches a word for justification or decoration: مـــحـــمـــد instead of محمد. In a metadata field it is pure liability. It is part of the string, it carries no meaning so nobody searching the name will type it, and — the part most people get wrong — no Unicode normalisation form removes tatweel: U+0640 has no canonical or compatibility decomposition, so NFC, NFD, NFKC and NFKD all leave it exactly where it is. It has to be removed deliberately, by you, before delivery.

5.7 Diacritics and tashkeel

Short vowel marks — fatha, damma, kasra, sukun, shadda and the tanween forms, U+064B–U+0652 — are combining marks (class NSM), essential in Qur'anic text and poetry, almost always absent from names.

For metadata: omit tashkeel from artist names and titles unless the vowelling is genuinely part of the work's identity, and if you include it, include it identically every time. The reason is search: a listener types the unvowelled form, and if your title is stored vowelled and the store does not strip marks before indexing, the two never meet. Partial vowelling matches neither query. For Latin-script diacritics the opposite applies — keep them, consistently, per the Beyoncé/Beyoncè example.

5.8 Hamza, composition, and normalisation (NFC vs NFD)

Unicode Standard Annex #15 (Unicode Normalization Forms) defines four forms; the two that matter here are NFC (precomposed) and NFD (base letter plus separate combining marks). Canonical equivalence covers characters that, per UAX #15, "when correctly displayed should always have the same visual appearance."

This is the second invisible splitter, and it hits Arabic script hard because several common letters are compositions: ئ U+0626 decomposes under NFD to U+064A + U+0654; ۂ U+06C2 (Urdu) to U+06C1 + U+0654; ۓ U+06D3 (Urdu) to U+06D2 + U+0654. One glyph on screen; one code point or two in memory, depending on which software produced the string. Different byte lengths, different comparison results, identical appearance. The same visible name can be two different byte strings, and no font, zoom level or proofreader will show you the difference.

UAX #15 warns against the compatibility forms as a cure-all: NFKC "erase[s] many formatting distinctions" and "may remove distinctions that are important to the semantics." Normalise to NFC, uniformly — but remember 5.6: normalisation is not a cleaner. It will not remove a tatweel, restore a stripped ZWNJ, or turn an Arabic yeh into a Persian one.

5.9 Transliteration: choose one romanisation and never change it

An Arabic-script artist has two names in the world's systems — native script and romanisation — and both must be single-valued. Romanisation is not standardised in practice: محمد can be Mohamed, Mohammed, Muhammad, Mohammad or Muhammed. Every one is defensible; every one is a different artist to a matching system.

When an artist does not fix one, the native-script releases collect on one page while the romanised releases split across two or three more, and search returns a set of partial catalogues. The artist experiences this as "my streams are lower than they should be" and never finds the cause, because each page looks fine alone.

How to choose, in priority order: whatever the artist already uses publicly — handle, domain, printed release — since consistency with the existing footprint beats linguistic correctness; failing that, whatever is on the largest existing release; then what a listener in the target market would actually type, because common beats scholarly and academic diacritics (Muḥammad) are correct and unfindable; and one fixed choice per ambiguous digraph — kh/x, gh/q, ou/u, ee/i.

Where the data model supports it, the native script belongs in the primary field and the romanisation in the localisation or phonetic field — exactly what Apple prescribes for Cyrillic: "Content in languages that use the Cyrillic alphabet should not be submitted with transliterated titles. Use Cyrillic in the native title field, English in the English localization field, and transliteration in the available phonetic field." That is the model these fields were designed for; where your distributor does not expose them, pick the script your audience searches in and stay with it. A romanisation is a second artist name, and an artist who has not chosen one has already chosen several.

For checking: mazufa.com hosts a free metadata checker that runs entirely on your own device and flags several of the invisible cases above — mixed digit sets, tatweel, stray or missing ZWNJ, Arabic-versus-Persian yeh and kaf, and non-NFC strings.

6. Credits and splits: where publishing money is won or lost

The recording and the composition are two separate rights with two separate income streams. Your distributor collects on the recording; the publishing side — mechanical and performance royalties on the work — is traced through the composer and lyricist fields and the registrations that follow them. They are the weakest link in independent releases for a structural reason: they never appear on the store front end, so nothing in the listening experience tells you they are wrong. A release with an empty composer field looks perfect and streams normally while its publishing royalties sit unmatched.

• Composer and lyricist take legal names, not stage names. Rights societies match on the writer's registered name; "DJ Karim" is not a writer, the person behind it is.
• Every writer must be listed, including whoever wrote one line. A missing writer is not a missing credit but an unmatched share.
• Splits must total 100% and be agreed in writing before release. The metadata expresses an agreement; with no agreement it is a guess that gets disputed later.
• Arrangements of public-domain works still have a writer — the arranger. Filing them as "Traditional" forfeits that income.
• A remix does not change the composition. The original writers remain the writers unless the remix adds new composition, which is a negotiated split, not an assumption.

Recording royalties fail loudly and publishing royalties fail silently: a broken artist page is visible within a day, an unmatched work can go unnoticed for years.

7. What actually gets a release rejected — and how to pre-empt it

1. Artist names inside title fields — "ft.", "feat.", "with", or a remixer's name typed into the title while the role field sits empty (section 3).
2. Explicit or clean words in titles — "(Explicit)", "(Clean)", "(Non-explicit)". Use the flag; Apple and Music Biz prohibit the text form.
3. Promotional or descriptive text in titles — "Exclusive", "Limited Edition", "Album Version", "Original Mix", or format claims such as "Dolby Atmos" and "lossless", all named in Apple's guide.
4. Casing violations — all caps, all lowercase or random casing, unless it is a genuine and consistent artistic choice. Music Biz sets the title-case rules, including the lowercase list ("a, an, and, as, but, for, from, nor, of, or, so, the, to, yet" plus prepositions of four letters or fewer).
5. Metadata that does not match the artwork — title, artist and version on the cover must match the fields.
6. Wrong or missing language fields, particularly title language on non-Latin releases.
7. Missing composer or lyricist, which some destinations reject outright.
8. Prohibited characters — emoji, decorative symbols, doubled spaces, stray invisible characters; tatweel belongs here too.
9. Wrong identifiers — a reused ISRC on a materially different recording, or a UPC that fails its check digit.
10. An artist name inconsistent with the existing catalogue — which often does not reject at all, which is why it is the most damaging item on this list.

A pre-delivery routine that removes most of it: paste the canonical artist string instead of typing it; confirm every title field holds only the song's name; confirm every role has a field and every field has a role; normalise to NFC; strip tatweel and settle your digit set; check the ZWNJ; set both language fields; check the P-line and C-line; set the original release date if this is not a first release; and compare the artwork against the fields character by character. Every rejection you receive is cheap; the errors that pass validation are the expensive ones.

8. Summary

• Metadata is filed at three layers — release, recording, work — and most costly errors are facts filed at the wrong layer. The artist name is a key, not a label; roles are identity and titles are display.
• In Arabic script the byte string and the display fail independently and the eye can audit neither: yeh and kaf variants, ZWNJ, tatweel, digit sets, tashkeel and NFC/NFD each split one artist into two, invisibly. Choose one romanisation and treat it as a second legal name.
• Composer and lyricist are where publishing money is traced, and they fail without symptoms.

Mazufa distributes for free, deducts 5% of royalties received, and gives every complete application a human review.

Sources

• Unicode Standard Annex #9, Unicode Bidirectional Algorithm (Revision 51, Unicode 17.0.0, 2025-08-13) — https://www.unicode.org/reports/tr9/
• Unicode Standard Annex #15, Unicode Normalization Forms (Version 57, Unicode 17.0.0, 2025-07-30) — https://www.unicode.org/reports/tr15/
• Unicode Character Database — character properties: bidirectional class, decomposition mappings — https://www.unicode.org/ucd/
• Music Business Association, Music Metadata Style Guide v2.1 — https://www.musicbiz.org/wp-content/uploads/2016/04/MusicMetadataStyleGuide_V2.1.pdf
• Apple Music Style Guide — https://help.apple.com/itc/musicstyleguide/en.lproj/static.html
• Spotify for Artists, Music metadata guidelines — https://support.spotify.com/us/artists/article/metadata-formatting-guidelines/
• Spotify Provider Support, Featured artist in a product or track title — https://providersupport.spotify.com/article/featured-artist-in-a-product-or-track-title
• DDEX, Standards (including the Electronic Release Notification Message Suite, ERN) — https://ddex.net/standards/
• IFPI, International Standard Recording Code (ISRC) Handbook (§A.10.1, re-mastering and creative input) — https://www.ifpi.org/wp-content/uploads/2021/02/ISRC_Handbook.pdf

On the limits of what is published. Every store rule stated here is quoted from that store's own public documentation. Three things artists are routinely told as fact are not published by any service and are not asserted here: the thresholds and evidence required for artist-page merges; the internal matching logic that decides whether a delivery joins an existing artist or creates a new one; and, beyond Apple's named prohibition, each store's treatment of "Original Mix".