Release metadata, field by field

40 · 2026-09-08 · 18 min read · Español

A release is delivered as two layers of fields — one set describing the product, one set on every track — and the stores display them exactly as delivered. Each field is read by a different reader downstream: the check at the door, the matching that places the release, the registers that pay on it, and the screen. Which reader a field has decides what a wrong value costs, and two fields have no reader that can ever change them.

• Release metadata is delivered in two layers: fields on the release and fields on each track. The stores display it as delivered and change nothing themselves.
• Every delivery carries one UPC for the release and one ISRC per track. Apple’s specification marks both as fields that cannot be updated; everything else on the form can be, by redelivery.
• Each artist is entered once, in one field, marked primary or not and given a role. The store reads the role, not the title, to decide who is credited and where the release lands.
• Title and version are separate fields; single, EP and album are set by track count and running time; the genre comes from the store’s own list; the language field describes the metadata, not the audio.
• The original release date is the first release on any format, the sales start date is the day it goes live, the P-line and C-line are a year and a name each, and territories default to worldwide.

What is release metadata, and who reads it?

Release metadata is the set of fields your distributor delivers with the audio, and the stores display it exactly as delivered.

Spotify says so in its own artist-facing guidelines, in two sentences that between them explain most of this page: “We display your music exactly as it’s delivered to us”, and “Your metadata is set by your label or distributor before they deliver your music to us.” Nobody at the store reads your fields and improves them. What you typed is what everybody sees.

The fields come in two layers, and every form you have ever filled in is a translation of them. Apple’s delivery specification is built as an album block holding a set of track blocks, and Spotify’s guidelines say roles “need to be set at both track-level and release-level.” Release fields describe the product: the UPC, the title, the label, the dates, the territories. Track fields describe each recording: the ISRC, the title, the artists on it, the flag, the language sung.

Here is the frame the rest of this page runs on. Once a release is delivered, its fields are read by four different readers, and no two of them read the same ones. The first is the check at the door — your distributor measuring the fields against the store guides, which is the rejection and its whole answer key. The second is the matching that decides which artist page the release lands on, and it reads the artist fields. The third is the set of registers that pay on the release, keyed on the identifiers and the ownership lines. The fourth is the screen, which shows the rest. Which reader a field has decides what a wrong value costs: a rejection you can fix, a page you can move, a statement you cannot unpay, or a typo. Four readers, none of them human, none of them looking at the same field. Argus had a hundred eyes, and at least they all belonged to one head.

Which fields identify the release and the recording?

One UPC identifies the release and one ISRC identifies each track, and Apple’s specification marks both as fields that cannot be updated.

Apple’s packaging page states the requirement flat: each product “must have a unique UPC, EAN, or JAN, and ISRC,” and “UPCs cannot be modified or used again.” The specification annotates every field with whether it can be changed after delivery, and these two get the shortest annotation in it. Album UPC: cannot be updated. Track ISRC: required; cannot be updated. The ISRC entry adds the sentence that decides most arguments about versions: “A re-recorded, remixed or otherwise different (no matter how similar) track must have a unique ISRC.” Which versions count as different is a question with about thirty rules attached, and it has its own page.

Three more identifiers ride along, and none of them is yours to worry about at delivery. The ISWC is an optional track field — the specification warns that one day “you may see a warning if the tag is not delivered,” a store telling you the song’s code is coming to the recording’s form. The GRid is a release identifier to remove if your company does not use it, and a vendor identifier is what a distributor generates for its own reporting. Which code is which, and why a song and a recording take different ones, is the C cluster’s pillar and not this one’s.

What matters here is the pairing. The UPC belongs to the product and the ISRC to the recording, so one recording keeps its ISRC on the single and on the album while each of those takes its own UPC — what that split answers, and what it cannot, is a comparison of its own. And because neither field can be updated, a code that shipped wrong is not a metadata correction. It is a procedure with an order, and it is the only field on this page that has one.

Which fields name the people?

Each artist is entered once per field, marked primary or not, and given a role; the store reads the role to decide who is credited where.

Apple’s specification describes the artist block as a name, an Apple identifier or an ISNI, “plus primary status and roles for each artist” — and it spells out the one habit that breaks the block, with its own example: individual artists “should be listed separately and not grouped together (for example, ‘Ella Fitzgerald’, ‘Louis Armstrong’ should be used instead of ‘Ella Fitzgerald and Louis Armstrong’).” Spotify’s Metadata Style Guide gives the consequence rather than the rule: “Each artist field must contain only one artist name,” and where two share a field, “individual artists will not be identified, and content will not appear on the correct artist pages.” The field is what the matcher reads. A name in the wrong field is a release on the wrong page.

Three things sit on every artist entry, and the form usually shows you one of them. The name, which both guides require to be spelled one way across everything you have released — Spotify’s “consistently applied to all content related to that artist” — and five comparisons arrive under one label when that fails. The primary status: Spotify credits the main performing artists as main artist on all content and lists no more than four at product level; Apple marks the main performing artist Primary at both levels and adds that “companies, brands, and record labels are not artists and therefore should not be listed as primary.” And the role, which is where the guides put everyone else.

The roles are a closed vocabulary at both stores, and it is the same vocabulary. Featured guests take Featuring or With at Apple and “must not be marked Primary”; Spotify lists each separately and bans their names from every title and version field — which credit is which, and what each costs, is a page of its own. The writing roles are Composer, Lyrics and Songwriter, with Apple’s tie-break: “if their specific contribution to the work isn’t known, use the Songwriter role.” The production roles are Producer, Recording Engineer and Graphic Designer, never Primary — what each production word is worth has its own page too. Spotify asks for all of it in one sentence: “All applicable artists, both performing and non-performing, must be entered with proper roles, which includes composer/writer information.”

Two fields close the section. The label name is its own required release field — “The name of the label that released the album” — and not an artist field, which is why a label typed as an artist is a rejection and a label typed as a label is not. And the credit you do not know yet has a rule, from Apple’s style guide: “If credits are not yet known or participants are anonymous, omit the credit entirely. Do not submit placeholder credits, such as TBD or Pending.” An empty role is a field you can fill in later. A placeholder is a wrong credit that is already live.

Which fields describe the product: title, version, type, genre and language?

Title and version are two fields, the type follows track count and running time, the genre comes from the store’s list, and the language describes the metadata.

Title and version. Spotify: “Product title must match the original title upon its initial release,” and supplementary information — Remaster, an anniversary edition, bonus tracks — goes in the version field “and must not be included in the Product Title field.” The standard version of a track carries nothing in either. Apple’s specification explains why there are two fields: “when imported, Apple takes the information in the tag and appends it to the album title in parentheses for display.” You supply the parts; the store assembles the string. Which words are banned, how a featured artist is formatted and what counts as a version term are the rejection piece’s subject, and this page names none of them.

Type. Single, EP and album are a count the store makes, not a choice you make. Spotify: three tracks or fewer and thirty minutes or less is a Single, four to six tracks and thirty minutes or less is an EP, unless the artist or label intends the other — and if a product meets the criteria and is not set that way, “Spotify may choose to display the product as Single or EP.” Apple: one to three songs under ten minutes each is a single, and “If ‘- Single’ is not included in the title, we will add it automatically.” Same for “- EP”. The suffix on every Apple Music single was appended by the store.

Genre. Apple’s specification asks for “at least one, but no more than two genres,” from Apple’s own coded list, and the style guide says what the first one does: “Content will only chart in the first primary genre.” Names are translated automatically for each territory. Spotify’s guide opens its genre section with a sentence nobody quotes: “Spotify does not currently use genre information from providers, although it may be ingested and used in the future.” You are being asked to classify your record for a reader that has said, in writing, that it is not reading.

Language. One sentence from each store, and it is the same sentence. Apple: “Language codes must match the language of the metadata, not the audio.” Spotify: “Language code should match the language of the metadata, not the audio.” The audio has its own field, per track, and an instrumental is zxx. Everything past that — casing, scripts, translations — is a rulebook of its own, and it is not this page.

Two track fields close the section because the form shows them here. The parental advisory has three values in the specification — “clean, explicit, or none” — and what any value changes is not a field map’s to say. The track number and volume number order the tracks, and the combination has to be unique across the album; that is all the specification asks of them.

Which fields carry the dates, the ownership lines and the territories?

A release carries an original release date and a sales start date, a P-line and a C-line of a year and a name each, and a territory list.

Two dates, two readers. Apple’s specification defines the original release date as “the first consumer-available physical album release” — “This is not the digital release date, unless this album has not previously been released on any format” — and says outright that it “does not impact the ‘available date’ or ‘street date’.” It is the date the screen shows. Spotify draws the same line: “The original release date can differ from the sales start date,” and the original one “must be the earliest date that the original product was first released regardless of the releasing label, or format type.” A remaster carries the original’s date at both stores. The other date is the one that acts: Apple’s sales start date, “also known as the ‘street date’”; Spotify’s live date, which its artist page recommends setting at least seven days out. And the specification carries the consequence of leaving it empty: “Omitting this tag on an initial upload will make the album available for sale immediately after normal quality assurance processing.” Two dates, and only one of them is a switch.

The two are checked against each other, once, at the door: if the original release date “is more than 90 days later than the earliest sales start date, the package will be rejected.” A record cannot be first released three months after it went on sale. What a reissue’s dates mean beyond that is its own page, and this one does not restate it.

The P-line and the C-line. Two fields, one format, defined by the specification in the same words: the P-line is the “Performance copyright line for the album” and “Must follow the format YYYY copyright info”; the C-line is the copyright line, same format. Both carry an instruction most forms never pass on: “Do not add the ℗ symbol or ‘p’; it will be added automatically,” and likewise the ©. A track has its own P-line, and “if not specified, the copyright line from the album is used.” Both are optional, both can be updated, and neither is read by anything after the door — a year and a name, published as typed. The label name is a separate field: the label released the album; the lines say who holds the rights. Whose name belongs on each line is a question this page does not decide.

Territories. Apple’s field is “The territory in which this album is cleared for sale,” one ISO 3166-1 alpha-2 code each, or “WW” for the world, with a cleared-for-sale flag the specification calls “an exclusion mechanism for regional clearances” — the world minus one country is a WW product plus one product for that country set to false. Spotify’s version is the plain one: “Add the countries you’d like your music to be available to Spotify listeners in, or set worldwide availability.” On Apple the sales start date is a per-territory field, which is why the two sit together on the form.

Which fields can be changed after delivery, and which cannot?

The UPC and the ISRC cannot be changed; nearly everything else can, but only by your distributor redelivering, because the stores change nothing themselves.

Nobody publishes this as a table, so here it is as one. Every cell is the specification’s own annotation, in its own three grades.

Spotify publishes the same fact from the artist’s side, as a list of what a distributor’s update fixes: artist name, release title, artwork, live date and release date, track order, country availability, your role on the music, credits. Then the two sentences that make every row above true: “Your label or distributor needs to send a metadata update to us with the right info,” and “We can’t change this manually on our end because we show music according to the metadata sent to us.”

Three rows deserve their own sentence, because each is a different kind of fix. A deliberate change of artist name is not an edit at either store; it is a request, filed first and redelivered after. A track already on the wrong artist page is a store-side repair, not a metadata update, because the matcher assigned the page and no field did. And a wrong ISRC is the one field with a procedure of its own, because it is the row that cannot be updated at all. Everything else on the form is pencil. Those two codes are the only fields the specification marks permanent from the first delivery. Check them twice before delivery. After it, leave them the hell alone.

What to check before the next delivery

Check the identifiers first, because nothing can change them; then the names and roles, because the matching reads them; then everything the screen shows.

• The UPC and every ISRC, against your own register. One code per release, one per recording, none reused. No redelivery can touch these.
• Every artist in its own field, spelled the one way, with primary status and a role. This is what places the release. A featured name in a title field is a rejection; a second name in an artist field is a wrong page.
• The two dates and the two lines. Original release date on the first format, sales start date on the day you mean, a year and a name on each line with no symbol typed in.
• Title and version as two fields, type left to the count, genre from the list, language from the spelling. Let the store assemble the string.
• The optional fields empty on purpose, not by accident. An empty ISWC, an omitted unknown credit and a blank track P-line are correct values. An empty sales start date is not — that is a release that goes live the moment it clears.

That is the next release. For the catalogue behind it — every form filled in from memory since the first upload — the audit checklist reads the layers back in the order failures propagate, and its identifiers layer is where this page’s two permanent fields get checked against what is actually live.

FAQ

Will the store fix a typo for me?

Do not count on it. Apple’s style guide says Apple Music and iTunes “reserve the right to correct any errors in grammar, spelling, and punctuation,” a right the store keeps and not a promise it makes. Spotify says the opposite in plainer words: it cannot change metadata manually, because it shows music as sent. The fix is a redelivery from your distributor, at both stores.

Does the genre field do anything?

It depends on which store is reading it. Spotify’s guide states that it does not currently use genre information from providers, although it may in future. Apple uses it: content charts only in the first primary genre listed, and genre names are translated automatically for each territory. Set it accurately for the store that reads it, from the store’s own list, most specific genre first.

How many main artists can a release carry?

Up to four at release level on Spotify, and five or more becomes Various Artists at both stores. Spotify’s guide says not to list more than four main artists at product level, and that five or more main artists and remixers make the product-level artist Various Artists. Apple’s threshold is the same, and Various Artists is never a track-level artist at either store.

What do I put in a credit I don’t know yet?

Nothing. Apple’s guide is explicit: if credits are not yet known or participants are anonymous, omit the credit entirely, and do not submit placeholders such as TBD or Pending. Spotify publishes no equivalent rule, so the honest practice is the same at both stores — an empty role field can be filled in later, and a placeholder is a wrong credit that is already live.

Sources

• Apple, Apple Music Specification — the album and track metadata annotations: Album UPC and Track ISRC “cannot be updated”, the ISRC uniqueness sentence, the optional ISWC and GRid, the vendor identifiers; the artist block with primary status and roles and the Ella Fitzgerald / Louis Armstrong example; the label name; title and title version and the parenthesis appended on import; genres, at least one and no more than two; the original release date, its “not the digital release date” clause and the ninety-day rejection; the sales start date as the street date and the consequence of omitting it; the P-line and C-line format with the symbols added automatically and the track fallback to the album’s; territory, WW and cleared for sale; track number, volume number, audio language and the three parental advisory values.
• Apple, Digital packaging (music) — that each product must have a unique UPC, EAN or JAN and an ISRC, and that UPCs cannot be modified or used again.
• Apple, Apple Music Style Guide — §1.3 the reserved right to correct grammar, spelling and punctuation; §1.6 language codes matching the metadata; §2.1 one spelling across all content; §2.6 the Primary performing artist and that labels are not artists; §2.7 Various Artists at five or more; §2.13 Featuring or With, never Primary; §2.15 Composer, Lyrics and Songwriter; §2.16 Producer, Recording Engineer and Graphic Designer; §2.18 omit unknown credits, no placeholders; §3.3 and §3.4 singles and EPs and the automatic suffix; §4 and §4.1 genres from Apple’s list, charting in the first primary genre, names translated per territory.
• Spotify, Metadata Style Guide (v2.3) — §1.3 one spelling; §2.1–2.3 main artists and the four-at-product-level limit; §3.1 Various Artists at five or more; §4.1 performing and non-performing roles; §5.3 no featured names in titles or version fields; §6.2 one name per field and the wrong-page consequence; §7.1 and §7.3 the product title and the version field; §8.4 the standard version carries nothing; §9.2, §9.3 and §9.5 the single and EP thresholds and Spotify’s own display choice; §20.1 and §20.2 original release date against sales start date; §24 language codes matching the metadata; §25 and §25.4 that genre is not currently used and must be in English.
• Spotify for Artists, Music metadata guidelines — that music is displayed exactly as delivered, that metadata is set by the label or distributor, that roles are set at track level and release level, the seven-day live-date recommendation, and country availability or worldwide.
• Spotify for Artists, Fixing problems with music metadata — the list of what a distributor’s metadata update fixes, and that Spotify cannot change metadata manually because it shows music according to what was sent.

Store rules and specifications change, and the ones here are quoted as at the date at the top of this piece; the linked documents are the living versions and all six were read that day. Your distributor’s form presents these fields under its own names and in its own order — the fields underneath are the ones above, and where a distributor asks for less than the specification does, the field still exists and still has a reader.

Keeping the register

The two fields no redelivery can touch are the two a register has to hold before the delivery, not after it. CatalogTracker keeps a release’s UPC and GRid beside its dates, label references, genres, languages, territories, parental advisory and its P-line and C-line, with each track carrying its ISRC, ISWC, version, disc and track numbers and its own P-line, and a completeness meter that reports how many of a release’s fields are actually filled in rather than assumed. The form asks you twenty questions on delivery day. A register is where you answered them last month. In development for iPhone.