Quando você realmente precisa de um ISRC novo — e quando uma remasterização não precisa

A maioria dos problemas com identificadores não é difícil. Eles apenas são repetidos errado até que todo mundo acredite. O que sai mais caro é a afirmação de que uma remasterização sempre precisa de um ISRC novo. O IFPI ISRC Handbook diz o contrário com todas as letras, e seguir o conselho corrente é como um catálogo acaba dividido em dois códigos, com contagem de streams e royalties repartidos entre eles.

Isto é sobre os três identificadores que ficam num lançamento, o que cada um de fato nomeia, e como verificar o código de barras que você recebeu sem acreditar na palavra de ninguém.

O ISRC tem 12 caracteres, e os hifens não fazem parte dele

Um ISRC tem 12 caracteres, em quatro campos:

Escrito com separadores, fica QZ-NWX-26-00147. Escrito como é de fato armazenado, fica QZNWX2600147.

Os hifens são apenas uma convenção de exibição. Eles não fazem parte do código. Uma especificação de entrega que pede doze caracteres quer doze caracteres, e colar a forma hifenizada num campo que os conta é uma das maneiras mais banais de falhar na validação. Guarde a forma sem hifens em todo lugar e acrescente os hifens só quando um ser humano for ler.

A segunda coisa a saber é o que um ISRC não tem: não existe dígito verificador em um ISRC. Nada no código valida o código. Se você digitar um caractere errado, o resultado continua sendo um ISRC estruturalmente válido — ele apenas passa a apontar para outra gravação, ou para nada. Códigos de barras têm autoverificação. ISRCs não têm. Vale internalizar essa assimetria, porque é ela que decide quanto cuidado cada um exige quando é copiado à mão.

Três identificadores, três coisas diferentes

Eles são usados de forma intercambiável nas conversas e não são nem um pouco intercambiáveis.

• ISRC identifica a gravação. Uma execução fixa específica, tal como captada.
• ISWC identifica a canção — a composição subjacente, aquilo que um autor escreveu.
• UPC identifica o lançamento — o produto que você coloca à venda.

Então uma canção tem um ISWC e pode ter vinte ISRCs, um para cada gravação dela. Uma única gravação carrega um ISRC e pode aparecer num single, num álbum e numa coletânea — três UPCs, um ISRC, inalterado nos três lugares.

A consequência prática: se os seus streams ou os seus royalties estão caindo no lugar errado, a primeira pergunta é qual dos três identificadores está errado, porque cada um é lido por uma parte diferente da cadeia.

O que realmente exige um ISRC novo

Um ISRC novo é exigido quando a gravação é materialmente diferente. Ou seja:

• um remix
• uma edição
• uma versão ao vivo
• uma versão instrumental

Qualquer uma delas é uma gravação diferente e precisa do próprio código.

Um ISRC novo não é exigido para um relançamento da mesma gravação. Mesmo áudio, nova data de lançamento, nova capa, novo selo, nova distribuidora — a gravação não mudou, então o identificador não muda.

Esse último ponto tem consequência comercial direta. Um ISRC fica com a gravação quando você troca de distribuidora. Ele não é propriedade da distribuidora e não expira quando a sua relação com ela expira. Se você se mudar, o código se muda com a gravação, e registrá-lo de novo sob um código novo é uma forma de perder o histórico ligado ao antigo, não um passo de organização.

A regra da remasterização, como ela está de fato escrita

Aqui está a parte que a maioria dos guias erra.

O IFPI ISRC Handbook, em §A.10.1, afirma que "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".

Repare no "if and only if". O teste é aporte criativo à gravação em si. Não esforço, não custo, não o fato de um engenheiro ter estado envolvido, não o fato de o arquivo ficar diferente depois.

O Handbook então vai além e nomeia o que não conta. Ele exclui explicitamente:

• mudança simples de nível
• EQ invariante
• compressão invariante
• redução de ruído
• remoção de cliques
• correção de velocidade e afinação
• mudança de taxa de amostragem
• dithering

E diz isso diretamente: "A new ISRC shall not be assigned in the context of essentially invariant or technological adjustment processes".

Essa lista cobre a maior parte do que se faz com um catálogo antigo quando ele é preparado para streaming. Baixar uma masterização de 2011 por causa de normalização de loudness, limpar cliques de uma transferência de fita, reamostrar para outra taxa, aplicar dithering a caminho de um formato de entrega — nada disso é aporte criativo sob a §A.10.1. Então não escreva, e não acredite, que uma remasterização sempre precisa de um ISRC novo. Na maior parte das vezes, não precisa.

A palavra que faz o trabalho nessa lista é invariante. Uma curva de EQ aplicada uniformemente ao longo da gravação é um ajuste tecnológico. Alguém tomando decisões dentro da gravação — tratando trechos de forma diferente, reequilibrando elementos por julgamento — está do outro lado da linha. Se você consegue descrever o que foi feito como um ajuste de parâmetro em vez de uma série de escolhas, é quase certo que é invariante.

A única ressalva prática segura

Há um caso em que você deve atribuir um ISRC novo mesmo que o processamento em si pareça invariante, e é um caso comercial, não técnico.

Se a remasterização é vendida como uma faixa separada ao lado da original, ela é um produto separado e precisa do próprio código.

Essa é a ressalva, e é seguro afirmá-la. Se um ouvinte consegue ver as duas versões na mesma loja e escolher entre elas, são duas coisas sendo vendidas, e duas coisas sendo vendidas precisam ser distinguidas pelos sistemas que as contam. Se a remasterização simplesmente substitui a original — mesma vaga de catálogo, versão antiga retirada —, então a §A.10.1 governa e, na ausência de aporte criativo, o código permanece.

Tudo além dessa ressalva é julgamento, e a resposta honesta é que o teste do Handbook é o teste. Na dúvida, escreva numa frase o que foi de fato feito com o áudio. Se essa frase contiver apenas itens da lista de exclusões, você já tem a sua resposta.

UPC e EAN: 12 dígitos, 13 dígitos, um dígito verificador

O código de barras de um lançamento identifica o lançamento — o produto — e não a gravação.

O UPC-A tem 12 dígitos. O EAN-13 tem 13. Não são dois sistemas de numeração diferentes que precisam de conversão. Um UPC-A vira um EAN-13 com o acréscimo de um zero à frente, e o dígito verificador não muda.

Vale dizer isso duas vezes, porque é fonte de muita ansiedade desnecessária. Se o formulário de uma distribuidora pede um EAN de 13 dígitos e você tem um UPC de 12, você põe um zero na frente. Você não recalcula nada. O último dígito que você já tem continua correto.

O motivo pelo qual o dígito verificador sobrevive fica visível quando se conhece o algoritmo, que vem a seguir.

Conferindo o seu código de barras à mão

A regra: da direita para a esquerda, alterne ×3 e ×1 nos dígitos anteriores ao verificador, some tudo, e o dígito verificador é o que leva o total ao múltiplo de 10 seguinte.

Pegue um corpo de 11 dígitos e descubra qual deve ser o décimo segundo dígito. Corpo:

8 5 9 7 5 1 2 3 4 0 1

Comece pela ponta direita desse corpo — o 1 — e alterne, começando por ×3:

Os dígitos ×3 são 1, 4, 2, 5, 9 e 8. Somam 29, e 29 × 3 = 87.

Os dígitos ×1 são 0, 3, 1, 7 e 5. Somam 16.

Total: 87 + 16 = 103.

O múltiplo de 10 seguinte acima de 103 é 110. Então o dígito verificador é 110 − 103 = 7, e o UPC-A completo é:

859751234017

Agora acrescente o zero à frente para formar o EAN-13:

0859751234017

Reconte. A alternância ainda começa no mesmo ponto — o dígito imediatamente à esquerda do verificador continua sendo ×3 —, então cada dígito original mantém o peso que tinha, e o novo zero à frente cai numa posição ×1, onde contribui com 0. O total continua sendo 103. O dígito verificador continua sendo 7. É essa toda a razão de a conversão ser gratuita.

Duas coisas decorrem disso e são úteis na prática.

Se o total que você calculou já é um múltiplo exato de 10, o dígito verificador é 0 — não 10, e não o múltiplo seguinte. E se você conferir um código de barras que recebeu e a conta não bater com o dígito impresso, o número está errado em algum ponto. Um único dígito digitado errado quase sempre quebra a soma. Um par de dígitos adjacentes trocados às vezes não quebra, porque eles podem cair em pesos que se cancelam, de modo que uma verificação aprovada é boa evidência e não prova.

Cinco minutos com uma caneta lhe dizem se o código do seu lançamento é real. É um uso melhor do tempo do que mandar e-mail perguntando a alguém.

O que fazer com isso

Três coisas, nesta ordem.

1. Guarde os seus ISRCs sem hifens, num único lugar que você controle, junto da informação de qual gravação cada um nomeia. Não no painel de uma distribuidora — no seu próprio arquivo. Os códigos são seus e acompanham as gravações.
2. Antes de atribuir um ISRC novo a uma remasterização, escreva uma frase descrevendo o que foi feito com o áudio. Se for nível, EQ invariante, compressão invariante, redução de ruído, remoção de cliques, correção de velocidade ou afinação, mudança de taxa de amostragem ou dithering, a §A.10.1 manda manter o código. Se a remasterização vai à venda ao lado da original, dê um código novo de qualquer forma.
3. Rode o dígito verificador do seu código de barras uma vez. Leva cinco minutos e é o único dos três identificadores que vai lhe dizer sozinho se está errado.

Lançar pela Mazufa é grátis e a comissão é de 0% — nenhuma porcentagem dos royalties, repasse integral — e ela é por convite, com uma pessoa lendo cada inscrição completa. Nossas ferramentas rodam inteiramente no seu navegador; nenhum áudio é enviado. Mas nada disso muda os identificadores das suas gravações. Eles pertencem às gravações, e ficam com elas para onde quer que você vá.

Fontes

• IFPI ISRC Handbook, §A.10.1 — verificado em 2026-09-07. (Nenhuma URL está registrada no nosso corpus de referência para este documento; o número da seção é dado para que você possa conferir diretamente no Handbook.)