Most identifier problems are not hard. They are just repeated wrongly until everyone believes them. The one that costs the most is the claim that a remaster always needs a fresh ISRC. The IFPI ISRC Handbook says the opposite in plain language, and following the common advice instead is how a catalogue ends up split across two codes with its stream counts and royalties divided between them.
This is about the three identifiers that sit on a release, what each one actually names, and how to verify the barcode you were given without trusting anybody's word for it.
The ISRC is 12 characters, and the hyphens are not part of it
An ISRC is 12 characters, in four fields:
| Field | Length | Example |
|---|---|---|
| Country | 2 | QZ |
| Registrant | 3 | NWX |
| Year of reference | 2 | 26 |
| Designation | 5 | 00147 |
Written out with separators that is QZ-NWX-26-00147. Written as it is actually stored, it is QZNWX2600147.
The hyphens are a display convention only. They are not part of the code. A delivery spec that wants twelve characters wants twelve characters, and pasting the hyphenated form into a field that counts them is one of the more boring ways to fail validation. Store the unhyphenated form everywhere and add the hyphens only when a human is going to read it.
The second thing to know is what an ISRC does not have: there is no check digit in an ISRC. Nothing in the code validates the code. If you mistype one character, the result is still a structurally valid ISRC — it simply now points at a different recording, or at nothing at all. Barcodes have a self-check. ISRCs do not. That asymmetry is worth internalising, because it decides how much care each one needs when it is copied by hand.
Three identifiers, three different things
These get used interchangeably in conversation and they are not interchangeable at all.
- ISRC identifies the recording. One specific fixed performance, as captured.
- ISWC identifies the song — the underlying composition, the thing a writer wrote.
- UPC identifies the release — the product you put on sale.
So a song has one ISWC and can have twenty ISRCs, one for each recording of it. A single recording carries one ISRC and can appear on a single, an album and a compilation — three UPCs, one ISRC, unchanged in all three places.
The practical consequence: if your streams or your royalties are landing in the wrong place, the first question is which of the three identifiers is wrong, because each one is read by a different part of the chain.
What genuinely requires a new ISRC
A new ISRC is required when the recording is materially different. That means:
- a remix
- an edit
- a live version
- an instrumental
Any of those is a different recording, and it needs its own code.
A new ISRC is not required for a re-release of the same recording. Same audio, new release date, new artwork, new label, new distributor — the recording did not change, so the identifier does not change.
That last point has a direct commercial consequence. An ISRC stays with the recording when you change distributor. It is not the distributor's property and it does not expire when your relationship with them does. If you move, the code moves with the recording, and re-registering it under a new code is a way to lose the history attached to the old one, not a housekeeping step.
The remaster rule, as it is actually written
Here is the part most guides get wrong.
The IFPI ISRC Handbook, at §A.10.1, states that "A new ISRC shall be assigned if (and only if) the processes applied to a recording during re-mastering involve the application of creative input to the recording itself."
Read the "if and only if". The test is creative input to the recording itself. Not effort, not cost, not the fact that an engineer was involved, not the fact that the file is different afterwards.
The Handbook then goes further and names what does not count. It explicitly excludes:
- simple level change
- invariant EQ
- invariant compression
- de-noising
- de-clicking
- speed and pitch correction
- sample-rate change
- dithering
And it says so directly: "A new ISRC shall not be assigned in the context of essentially invariant or technological adjustment processes."
That list covers most of what is done to a back catalogue when it is prepared for streaming. Pulling a 2011 master down for loudness normalisation, cleaning up clicks from a tape transfer, resampling to a different rate, dithering on the way to a delivery format — none of that is creative input under §A.10.1. So do not write, and do not believe, that a remaster always needs a new ISRC. Most of the time it does not.
The word doing the work in that list is invariant. An EQ curve applied uniformly across the recording is a technological adjustment. Someone making decisions inside the recording — treating sections differently, rebalancing elements by judgement — is on the other side of the line. If you can describe what was done as a setting rather than as a series of choices, it is almost certainly invariant.
The one safe practical rider
There is a case where you should assign a new ISRC even though the processing itself might look invariant, and it is a commercial case rather than a technical one.
If the remaster is sold as a separate track alongside the original, it is a separate product and needs its own code.
That is the rider, and it is safe to state. If a listener can see both versions in the same store and choose between them, they are two things being sold, and two things being sold need to be told apart by the systems that count them. If the remaster simply replaces the original — same catalogue slot, old version withdrawn — then §A.10.1 governs and, absent creative input, the code stays.
Everything beyond that rider is judgement, and the honest answer is that the Handbook's test is the test. When in doubt, write down in one sentence what was actually done to the audio. If that sentence contains only items from the exclusion list, you have your answer.
UPC and EAN: 12 digits, 13 digits, one check digit
The barcode on a release identifies the release — the product — and not the recording.
UPC-A is 12 digits. EAN-13 is 13. They are not two different numbering systems that need converting between. A UPC-A becomes an EAN-13 by prefixing a zero, and the check digit does not change.
That is worth stating twice because it is the source of a lot of unnecessary anxiety. If a distributor's form asks for a 13-digit EAN and you hold a 12-digit UPC, you put a zero in front of it. You do not recalculate anything. The last digit you already have is still correct.
The reason the check digit survives is visible once you know the algorithm, which is next.
Checking your own barcode by hand
The rule: from the right, alternate ×3 and ×1 across the digits before the check digit, sum them, and the check digit is whatever brings the total to the next multiple of 10.
Take an 11-digit body and work out what its twelfth digit must be. Body:
8 5 9 7 5 1 2 3 4 0 1Start from the right-hand end of that body — the 1 — and alternate, ×3 first:
| Digit (from the right) | 1 | 0 | 4 | 3 | 2 | 1 | 5 | 7 | 9 | 5 | 8 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Weight | ×3 | ×1 | ×3 | ×1 | ×3 | ×1 | ×3 | ×1 | ×3 | ×1 | ×3 |
The ×3 digits are 1, 4, 2, 5, 9 and 8. They sum to 29, and 29 × 3 = 87.
The ×1 digits are 0, 3, 1, 7 and 5. They sum to 16.
Total: 87 + 16 = 103.
The next multiple of 10 above 103 is 110. So the check digit is 110 − 103 = 7, and the full UPC-A is:
859751234017Now prefix the zero to make the EAN-13:
0859751234017Recount. The alternation still starts from the same place — the digit immediately left of the check digit is still ×3 — so every original digit keeps the weight it had, and the new leading zero lands on a ×1 position where it contributes 0. The total is still 103. The check digit is still 7. That is the whole reason the conversion is free.
Two things fall out of this that are useful in practice.
If your computed total is already an exact multiple of 10, the check digit is 0 — not 10, and not the next multiple up. And if you check a barcode you were given and the arithmetic does not land on the printed digit, the number is wrong somewhere. A single mistyped digit almost always breaks the sum. A pair of adjacent digits swapped sometimes does not, because they may sit on weights that happen to cancel, so a passing check is good evidence and not proof.
Five minutes with a pen tells you whether the code on your release is real. That is a better use of the time than emailing someone to ask.
What to do with this
Three things, in order.
- Store your ISRCs unhyphenated, in one place you control, alongside which recording each one names. Not in a distributor's dashboard — in your own file. The codes are yours and they follow the recordings.
- Before assigning a new ISRC to a remaster, write one sentence describing what was done to the audio. If it is level, invariant EQ, invariant compression, de-noising, de-clicking, speed or pitch correction, sample-rate change or dithering, §A.10.1 says keep the code. If the remaster is going on sale next to the original, give it a new one regardless.
- Run the check digit on your barcode once. It takes five minutes and it is the only one of the three identifiers that will tell you itself whether it is wrong.
Mazufa is free to release and takes 0% commission — no percentage of royalties, passed through in full — and it is invite-only, with a human reading every complete application. Our tools run entirely in your browser; no audio is uploaded. But none of that changes the identifiers on your recordings. Those belong to the recordings, and they stay with them wherever you go next.
Sources
- IFPI ISRC Handbook, §A.10.1 — verified 2026-09-07. (No URL is recorded in our reference corpus for this document; the section number is given so you can check it in the Handbook directly.)