Normalização de pico contra normalização de intensidade sonora, e o alvo que não se alcança

Pico e intensidade sonora respondem a duas perguntas diferentes

A normalização de pico faz uma pergunta: qual é a amostra mais forte deste ficheiro, e por que constante multiplico tudo para que ela aterre exatamente num teto escolhido? É uma medição e uma multiplicação. É rápida, exata e quase inútil para fazer duas gravações soarem igualmente fortes, porque o instante mais forte de um áudio nada diz sobre a força percebida. Uma gravação esparsa de uma voz com uma porta a bater, e um muro de música densa, podem culminar exatamente no mesmo valor de amostra enquanto uma soa várias vezes mais forte do que a outra.

A normalização de intensidade sonora faz a outra pergunta: que força transmite este programa inteiro, e quanto é preciso movê-lo para que transmita a mesma que tudo o resto? Respondê-la exige um modelo da audição, e existe um: a ITU-R BS.1770 define um filtro que aproxima a resposta em frequência do ouvido, soma os canais com pesos fixos e — sobretudo — descarta as passagens calmas para que um longo silêncio final não puxe o número para baixo. O resultado é uma intensidade em LUFS, e dois ficheiros que medem o mesmo em LUFS soam de facto quase igualmente fortes. A EBU R 128 é a prática construída sobre essa medição, e é de lá que vêm os alvos.

Esta ferramenta só faz a segunda. Não há botão de normalização de pico, e essa é a escolha certa: a normalização de pico é o que significava a caixa «normalizar» dos gestores de ficheiros de outrora, e quase nunca fazia o que as pessoas queriam. O que a ferramenta guarda do mundo dos picos é um teto — um limite de pico real, em −1 dBTP por omissão — e esse teto revela-se o controlo mais consequente da página, por razões que a terceira secção aborda.

Duas passagens, e porque uma não chega

Um normalizador de intensidade de uma passagem tem uma tarefa impossível: tem de decidir a cada instante quanto ganho aplicar sabendo apenas o que já ouviu. Perante uma abertura calma, sobe-a, e depois chega um refrão forte que tem de voltar a baixar. O resultado é uma gravação cujo equilíbrio interno foi reorganizado por um algoritmo que adivinha o futuro — isso é um compressor, não um normalizador, e não é o que tinha em mente quem pedia normalização.

A forma em duas passagens elimina a adivinhação. A primeira lê todo o programa e imprime as suas medições: intensidade integrada, pico real, amplitude de intensidade e o limiar de porta que usou. Esses quatro números, mais um desvio do alvo, são devolvidos à segunda passagem, que já conhece a resposta antes de começar e pode aplicar um ganho constante do princípio ao fim. Nada é reorganizado; a gravação é simplesmente deslocada. É isso que significa normalização linear, e é o que a ferramenta pede com linear=true.

Quando há margem, isto funciona exatamente como anunciado. Um tom de teste estável medido a −29,75 LUFS com picos bem baixos, a −26,02 dBTP, a quem se pede o alvo de difusão de −23 LUFS, saiu a −23,05 LUFS: cinco centésimos de decibel do alvo, o que na prática é o alvo. A conceção é sólida. O problema é o que acontece quando não há margem.

O alvo que pede nem sempre é o alvo que obtém

linear=true não é uma instrução, é uma preferência. O loudnorm do ffmpeg aplica um ganho constante apenas se isso mantiver o pico real abaixo do teto que definiu. Se o ganho constante que as medições implicam fosse ultrapassar esse teto, o filtro abandona em silêncio o modo linear e recai no seu algoritmo dinâmico — que respeita o teto e, ao fazê-lo, não consegue atingir o seu alvo de intensidade. Nada no registo anuncia a mudança. A ferramenta imprimia o número pedido e chamava à diferença «correção aplicada»; agora volta a passar o ficheiro produzido pelo mesmo medidor e imprime o que de lá vem, pelo que o número no ecrã é um número medido e não um número pedido.

Eis o que isso custa em material perfeitamente corrente. Tome um programa medido a −16,06 LUFS cujos picos estão a −0,09 dBTP — um perfil totalmente normal para o que quer que tenha sido masterizado nos últimos vinte anos, já que quase tudo é empurrado para perto da escala plena. Peça o alvo de streaming por omissão de −14 LUFS com o teto por omissão de −1 dBTP. Um ganho linear de cerca de dois decibéis levaria esses picos a uns +1,9 dBTP, portanto o modo linear é recusado. O ficheiro resultante mede −15,59 LUFS: o ganho real foi de meio decibel, não dos dois que o painel anuncia. O painel mostrava «Medido: −16,1 LUFS → −14,0 LUFS · Correção aplicada: +2,1 LU», e cada palavra disso era uma suposição disfarçada de medição. Agora mostra −15,59, porque a saída é medida antes de se mostrar seja o que for — e quando o valor atingido se afasta meia unidade ou mais do alvo, o alvo é impresso ao lado para que veja que o filtro recusou.

A distância aumenta em material com ampla amplitude de intensidade. Um programa a −13,15 LUFS com um único transitório em escala plena, a quem se pede −14 LUFS, saiu a −26,71 LUFS — quase treze decibéis abaixo do alvo, e audivelmente fraco. O mesmo ficheiro passado por um loudnorm simples de uma passagem, aquilo contra o qual a própria nota da ferramenta avisa, acabou em −14,75 LUFS. Não é um argumento contra as duas passagens; duas passagens são o certo para a grande maioria dos ficheiros. É um argumento para desconfiar de um número que nunca foi medido. Se o resultado soa mal, pode estar mal, e a forma de saber é medir a saída você mesmo em vez de ler o painel.

Que alvo, e porque mais forte não é melhor

Três predefinições cobrem quase tudo. −23 LUFS é o alvo de difusão europeu, inscrito na EBU R 128 e esperado pela televisão. −16 LUFS é prática corrente para podcasts falados, não uma norma que alguém publique. −14 LUFS é mais ou menos onde os grandes serviços de streaming normalizam a reprodução, e é o valor por omissão aqui. A pista da predefinição agrupa Spotify, YouTube e Apple Music em −14; os números publicados para esses serviços mexeram-se ao longo dos anos e não são todos iguais, portanto tome −14 como uma vizinhança e não como uma especificação, e use o cursor à medida se lhe deram um número a atingir.

O que convém interiorizar é que numa plataforma que normaliza, entregar mais forte do que o alvo não rende nada. A plataforma baixa a sua faixa para a sua própria referência a caminho do ouvinte. O que não volta é tudo o que sacrificou para soar forte — os transitórios que achatou, a dinâmica que apertou. Chega ao mesmo volume de reprodução que toda a gente, com menos coisas dentro da gravação. Normalizar à partida, para o número que o destino usa, é assim que se guarda a dinâmica e ainda assim se aterra no volume certo.

Normalizar não desfaz o corte que já lá está

O corte acontece quando se pediu a um sinal que ultrapassasse o valor máximo que uma amostra pode conter, e o que sobrava foi simplesmente cortado. Fica um topo plano onde havia uma curva, e o som que produz é aquela aresta dura a que chamamos distorção. A informação que estava acima do teto não está atenuada nem escondida: não existe no ficheiro. Nenhum processamento posterior a pode trazer de volta, porque nada registou o que ela era.

Passar uma origem cortada por esta ferramenta demonstra-o com limpeza. Um ficheiro de teste deliberadamente cortado media −1,55 LUFS com um pico real de +0,10 dBTP — acima da escala plena, que é precisamente para o que serve um medidor de pico real: reconstrói o que acontece entre amostras e encontra os excessos que um medidor de pico de amostra perde. Normalizado a −14 LUFS saiu a −14,35 LUFS com um pico real de −12,67 dBTP. O nível já está correto e o teto é respeitado com folga. Os topos planos continuam planos. Baixar uma distorção dá uma distorção mais discreta.

O que sai — e o ficheiro que não consegue meter

Dê-lhe um vídeo e a imagem é copiada com -c:v copy, intacta, enquanto o som é substituído por uma faixa AAC nova a 192 kbit/s — Opus ao mesmo débito para um contentor WebM, já que o WebM não pode transportar AAC. Dê-lhe áudio e escolhe a saída: MP3 a 192 kbit/s por omissão, ou WAV em PCM de 16 bits, M4A em AAC, OGG em Vorbis a qualidade 5, ou FLAC. Não há cópia de fluxo, e é inevitável — as amostras mudaram, portanto têm de ser escritas de novo. Se a sua origem é sem perdas, escolha FLAC ou WAV; deixar o MP3 por omissão transforma um master sem perdas num com perdas, como efeito secundário de acertar o volume.

Uma coisa travava alguns leitores antes sequer de começarem. Embora a ferramenta tenha o nome do áudio, ofereça cinco formatos de saída de áudio e imprima «Escolher um ficheiro de áudio ou vídeo» por cima da zona de largada, o seu seletor de ficheiros estava configurado só para vídeo: a lista aceite tinha MP4, MOV, WebM, MKV, AVI e M4V e nenhum tipo de áudio, pelo que largar um MP3 era recusado como tipo errado e todo o ramo de áudio — os botões de formato, as saídas MP3 e FLAC — ficava inalcançável pelo seletor. Passa agora a aceitar ambos, e a etiqueta descreve finalmente o que a ferramenta faz. Vale a pena perceber porque é que uma falha destas sobrevive: tudo a jusante do seletor funcionava na perfeição, portanto nada falhava, nada era testado, nada era registado. A funcionalidade estava simplesmente atrás de uma porta que ninguém conseguia abrir.

Perguntas frequentes

Esta ferramenta faz também normalização de pico?

Não. Só faz normalização de intensidade sonora, através do filtro loudnorm do ffmpeg, que mede em LUFS pelo método ITU-R BS.1770. O que guarda do mundo dos picos é um teto de pico real, que é um limite e não um alvo: diz até onde o resultado pode aproximar-se da escala plena, não com que força deve soar. Se quisesse mesmo normalização de pico — cada ficheiro escalado para que a sua amostra mais forte fique no mesmo valor — verificaria que dois clipes continuam a soar muito diferentes, e é por isso que quase ninguém a quer depois de ouvir a alternativa.

O painel diz que atingiu o meu alvo. Posso fiar-me nesse número?

Só da primeira metade. O número «Medido» é real — vem da primeira passagem, que analisou mesmo o seu ficheiro. O segundo não é uma medição de todo: é o alvo que escolheu, devolvido ao ecrã, e a correção mostrada é apenas a diferença aritmética entre os dois. Se o ffmpeg recusou o ganho linear por ele ir romper o teto de pico real, a saída está noutro sítio e nada na página lho dirá. O sinal de alerta: uma origem que já atinge quase a escala plena e é mais fraca do que o seu alvo. Essa combinação não pode ser satisfeita, e o resultado vai ficar aquém.

Em quanto ponho o teto de pico real?

Deixe-o em −1 dBTP para tudo o que vá ser codificado de novo depois de si, ou seja quase tudo. Um codificador com perdas não reproduz as suas amostras com exatidão; reconstrói uma aproximação, e essa aproximação pode ultrapassar ligeiramente onde as suas amostras estavam. Deixar um decibel de espaço dá a esse excesso para onde ir em vez de cortar no leitor do ouvinte. Subir o teto na direção de zero compra-lhe um pouco mais de força e gasta a sua margem de segurança, e também não torna menos provável a recusa do modo linear descrita acima.

Normalizar pode reparar uma gravação já distorcida?

Não, e vale a pena dizê-lo sem rodeios. Se a gravação cortou no momento da captura, os picos acima do máximo foram descartados nesse instante; o ficheiro contém topos planos onde havia formas de onda, e não há registo em lado nenhum de como eram as partes em falta. Normalizar muda o nível, portanto a distorção fica mais discreta, mas a forma permanece. Um ficheiro de teste cortado com um pico real de +0,10 dBTP saiu da ferramenta a −14,35 LUFS, com os picos bem arrumados a −12,67 dBTP e os topos planos inteiramente intactos. Se puder regravar, regrave. Se não, há programas especializados de recuperação de corte que adivinham a curva em falta, com resultados desiguais.

Para que serve o cursor de amplitude de intensidade, e devo mexer-lhe?

Descreve quanto o nível pode mexer-se ao longo do programa, medido em unidades de intensidade, e vale 11 LU por omissão. Importa quando o loudnorm trabalha em dinâmico e não em linear: um valor baixo achata mais a diferença entre as partes calmas e as fortes, um valor alto deixa-as mais afastadas. Quando se segue a via linear — o caso normal, quando há margem — todo o programa é deslocado por uma constante e a amplitude não é tocada, portanto o cursor não muda nada. Deixe-o onde está a não ser que alguém lhe tenha especificado uma amplitude, e se se der a baixá-lo para tornar audível uma fala ténue, o que quer mesmo é um compressor, não um normalizador.