Normalización de pico frente a normalización de sonoridad, y el objetivo inalcanzable

Pico y sonoridad responden a dos preguntas distintas

La normalización de pico plantea una pregunta: ¿cuál es la muestra más fuerte de este archivo y por qué constante multiplico todo para que aterrice exactamente en un techo elegido? Es una medición y una multiplicación. Es rápida, exacta y casi inútil para que dos grabaciones suenen igual de fuertes, porque el instante más fuerte de un audio no dice nada de lo fuerte que se percibe. Una grabación escasa de una voz con un portazo, y un muro de música densa, pueden alcanzar exactamente el mismo valor de muestra mientras una suena varias veces más fuerte que la otra.

La normalización de sonoridad plantea la otra pregunta: ¿qué fuerza transmite este programa entero, y cuánto hay que moverlo para que transmita la misma que todo lo demás? Responderla exige un modelo del oído, y existe uno: la ITU-R BS.1770 define un filtro que aproxima la respuesta en frecuencia del oído, suma los canales con pesos fijos y — sobre todo — descarta los pasajes silenciosos para que un largo silencio final no arrastre la cifra hacia abajo. El resultado es una sonoridad en LUFS, y dos archivos que miden lo mismo en LUFS suenan de verdad casi igual de fuertes. La EBU R 128 es la práctica construida sobre esa medición, y de ahí salen los objetivos.

Esta herramienta solo hace la segunda. No hay botón de normalización de pico, y esa es la decisión correcta: la normalización de pico es lo que significaba la casilla «normalizar» de los gestores de archivos de antaño, y casi nunca hacía lo que la gente quería. Lo que la herramienta conserva del mundo de los picos es un techo — un límite de pico real, en −1 dBTP por defecto — y ese techo resulta ser el control más trascendente de la página, por razones que aborda la tercera sección.

Dos pasadas, y por qué una no basta

Un normalizador de sonoridad de una pasada tiene una tarea imposible: debe decidir en cada momento cuánta ganancia aplicar sabiendo solo lo que ya ha oído. Ante una apertura suave la sube, y luego llega un estribillo fuerte que tiene que volver a bajar. El resultado es una grabación cuyo equilibrio interno ha sido reordenado por un algoritmo que adivina el futuro — eso es un compresor, no un normalizador, y no es lo que tenía en mente quien pedía normalizar.

La forma en dos pasadas elimina la adivinación. La primera lee todo el programa e imprime sus mediciones: sonoridad integrada, pico real, rango de sonoridad y el umbral de puerta que usó. Esos cuatro números, más un desplazamiento del objetivo, se devuelven a la segunda pasada, que ya conoce la respuesta antes de empezar y puede aplicar una ganancia constante de principio a fin. Nada se reordena; la grabación simplemente se mueve. Eso es la normalización lineal, y es lo que la herramienta pide con linear=true.

Cuando hay margen, esto funciona exactamente como se anuncia. Un tono de prueba estable medido en −29,75 LUFS con picos muy abajo, en −26,02 dBTP, al que se pide el objetivo de difusión de −23 LUFS, salió en −23,05 LUFS: cinco centésimas de decibelio del blanco, que a efectos prácticos es el blanco. El diseño es sólido. El problema es lo que pasa cuando no hay margen.

El objetivo que pides no siempre es el que consigues

linear=true no es una instrucción, es una preferencia. El loudnorm de ffmpeg aplica una ganancia constante solo si con ello el pico real se mantiene bajo el techo que has fijado. Si la ganancia constante que implican las mediciones fuera a superar ese techo, el filtro abandona en silencio el modo lineal y recae en su algoritmo dinámico — que respeta el techo y, al hacerlo, no puede alcanzar tu objetivo de sonoridad. Nada en el registro anuncia el cambio. La herramienta imprimía la cifra pedida y llamaba a la diferencia «corrección aplicada»; ahora vuelve a pasar el archivo producido por el mismo medidor e imprime lo que sale, de modo que la cifra en pantalla es una cifra medida y no una cifra pedida.

Esto es lo que cuesta con material perfectamente corriente. Toma un programa medido en −16,06 LUFS cuyos picos están en −0,09 dBTP — un perfil totalmente normal para cualquier cosa masterizada en los últimos veinte años, ya que casi todo se empuja cerca de la escala completa. Pide el objetivo de streaming por defecto de −14 LUFS con el techo por defecto de −1 dBTP. Una ganancia lineal de unos dos decibelios llevaría esos picos a alrededor de +1,9 dBTP, así que el modo lineal se rechaza. El archivo resultante mide −15,59 LUFS: la ganancia real fue de medio decibelio, no de los dos que anuncia el panel. El panel mostraba «Medido: −16,1 LUFS → −14,0 LUFS · Corrección aplicada: +2,1 LU», y cada palabra de eso era una suposición disfrazada de medición. Ahora muestra −15,59, porque la salida se mide antes de enseñar nada — y cuando la cifra alcanzada se aparta media unidad o más del objetivo, el objetivo se imprime al lado para que veas que el filtro se negó.

La brecha se ensancha con material de rango de sonoridad amplio. Un programa a −13,15 LUFS con un único transitorio a plena escala, al que se pide −14 LUFS, salió a −26,71 LUFS — casi trece decibelios por debajo del objetivo, y audiblemente flojo. El mismo archivo pasado por un loudnorm simple de una pasada, aquello contra lo que advierte la propia nota de la herramienta, acabó en −14,75 LUFS. No es un argumento contra las dos pasadas; dos pasadas son lo correcto para la gran mayoría de archivos. Es un argumento para desconfiar de una cifra que nunca se midió. Si el resultado suena mal, puede que esté mal, y la forma de saberlo es medir la salida tú mismo en lugar de leer el panel.

Qué objetivo, y por qué más fuerte no es mejor

Tres preajustes cubren casi todo. −23 LUFS es el objetivo de difusión europeo, inscrito en la EBU R 128 y esperado por la televisión. −16 LUFS es práctica habitual para pódcast hablados, no una norma que nadie publique. −14 LUFS es aproximadamente donde los grandes servicios de streaming normalizan la reproducción, y es el valor por defecto aquí. La pista del preajuste agrupa Spotify, YouTube y Apple Music en −14; las cifras publicadas para esos servicios se han movido con los años y no son todas iguales, así que toma −14 como un vecindario y no como una especificación, y usa el deslizador a medida si te han dado una cifra concreta.

Lo que conviene interiorizar es que en una plataforma que normaliza, entregar más fuerte que el objetivo no aporta nada. La plataforma baja tu pista a su propia referencia camino del oyente. Lo que no vuelve es todo lo que sacrificaste para sonar fuerte — los transitorios que aplanaste, la dinámica que apretaste. Llegas al mismo volumen de reproducción que todos, con menos cosas dentro de la grabación. Normalizar de antemano, a la cifra que usa el destino, es como se conserva la dinámica y aun así se aterriza al volumen correcto.

Normalizar no deshace el recorte que ya está grabado

El recorte ocurre cuando a una señal se le pidió superar el valor máximo que puede contener una muestra, y lo que sobresalía se cortó sin más. Queda una cima plana donde había una curva, y el sonido que produce es ese filo áspero que llamamos distorsión. La información que estaba por encima del techo no está atenuada ni escondida: no existe en el archivo. Ningún procesado posterior puede devolverla, porque nada registró lo que era.

Pasar una fuente recortada por esta herramienta lo demuestra con limpieza. Un archivo de prueba recortado a propósito medía −1,55 LUFS con un pico real de +0,10 dBTP — por encima de la escala completa, que es justo para lo que sirve un medidor de pico real: reconstruye lo que pasa entre muestras y encuentra los excesos que un medidor de pico de muestra se pierde. Normalizado a −14 LUFS salió a −14,35 LUFS con un pico real de −12,67 dBTP. El nivel ya es correcto y el techo se respeta con holgura. Las cimas planas siguen planas. Bajar una distorsión da una distorsión más discreta.

Lo que sale — y el archivo que no puedes meter

Dale un vídeo y la imagen se copia con -c:v copy, intacta, mientras el sonido se sustituye por una pista AAC nueva a 192 kbit/s — Opus a la misma tasa para un contenedor WebM, ya que WebM no puede llevar AAC. Dale audio y eliges la salida: MP3 a 192 kbit/s por defecto, o WAV como PCM de 16 bits, M4A como AAC, OGG como Vorbis a calidad 5, o FLAC. No hay copia de flujo, y es inevitable — las muestras han cambiado, así que hay que escribirlas de nuevo. Si tu fuente es sin pérdida, elige FLAC o WAV; dejar el MP3 por defecto convierte un máster sin pérdida en uno con pérdida como efecto secundario de ajustar su volumen.

Una cosa detenía a algunos lectores antes de empezar. Aunque la herramienta lleva el nombre del audio, ofrece cinco formatos de salida de audio e imprime «Elegir un archivo de audio o vídeo» sobre su zona de arrastre, su selector de archivos estaba configurado solo para vídeo: la lista aceptada tenía MP4, MOV, WebM, MKV, AVI y M4V y ningún tipo de audio, así que soltar un MP3 se rechazaba como tipo equivocado y toda la rama de audio — los botones de formato, las salidas MP3 y FLAC — quedaba inalcanzable a través del selector. Ahora acepta ambos, y la etiqueta por fin describe lo que la herramienta hace. Vale la pena entender por qué sobrevive un fallo así: todo lo que había aguas abajo del selector funcionaba perfectamente, así que nada fallaba, nada se probaba, nada se registraba. La función estaba simplemente detrás de una puerta que nadie podía abrir.

Preguntas frecuentes

¿Esta herramienta hace también normalización de pico?

No. Solo hace normalización de sonoridad, mediante el filtro loudnorm de ffmpeg, que mide en LUFS con el método ITU-R BS.1770. Lo que conserva del mundo de los picos es un techo de pico real, que es un límite y no un objetivo: dice hasta dónde puede acercarse el resultado a la escala completa, no lo fuerte que debe sonar. Si de verdad quisieras normalización de pico — cada archivo escalado para que su muestra más fuerte quede en el mismo valor — comprobarías que dos clips siguen sonando muy distintos, y por eso casi nadie la quiere una vez ha oído la alternativa.

El panel dice que alcanzó mi objetivo. ¿Me puedo fiar de esa cifra?

Solo de la primera mitad. La cifra «Medido» es real — sale de la primera pasada, que analizó de verdad tu archivo. La segunda no es una medición en absoluto: es el objetivo que elegiste, devuelto en pantalla, y la corrección mostrada es solo la diferencia aritmética entre ambas. Si ffmpeg rechazó la ganancia lineal porque habría roto el techo de pico real, la salida está en otro sitio y nada en la página te lo dirá. La señal de alarma: una fuente que ya alcanza casi la escala completa y es más floja que tu objetivo. Esa combinación no se puede satisfacer, y el resultado se quedará corto.

¿En cuánto pongo el techo de pico real?

Déjalo en −1 dBTP para todo lo que vaya a codificarse otra vez después de ti, que es casi todo. Un codificador con pérdida no reproduce tus muestras exactamente; reconstruye una aproximación, y esa aproximación puede sobrepasar ligeramente donde estaban tus muestras. Dejar un decibelio de sitio le da a ese exceso adónde ir en vez de recortar en el reproductor del oyente. Subir el techo hacia cero te compra un poco más de fuerza y gasta tu margen de seguridad, y tampoco hace menos probable el rechazo del modo lineal descrito arriba.

¿Puede normalizar reparar una grabación ya distorsionada?

No, y conviene decirlo sin rodeos. Si la grabación recortó al hacerse, los picos por encima del máximo se descartaron en ese momento; el archivo contiene cimas planas donde había formas de onda, y no hay registro en ninguna parte de cómo eran las partes que faltan. Normalizar cambia el nivel, así que la distorsión se vuelve más discreta, pero la forma se queda. Un archivo de prueba recortado con un pico real de +0,10 dBTP salió de la herramienta a −14,35 LUFS, con sus picos a salvo en −12,67 dBTP y sus cimas planas enteramente intactas. Si puedes volver a grabar, vuelve a grabar. Si no, hay programas especializados de recuperación de recorte que adivinan la curva ausente, con resultados desiguales.

¿Para qué sirve el deslizador de rango de sonoridad, y debo tocarlo?

Describe cuánto puede moverse el nivel a lo largo del programa, medido en unidades de sonoridad, y por defecto vale 11 LU. Importa cuando loudnorm trabaja en modo dinámico y no lineal: un valor bajo aplana más la diferencia entre las partes suaves y las fuertes, uno alto las deja más separadas. Cuando se toma la vía lineal — el caso normal, cuando hay margen — todo el programa se desplaza una constante y el rango no se toca, así que el deslizador no cambia nada. Déjalo donde está salvo que alguien te haya especificado un rango, y si te descubres bajándolo para hacer audible un habla tenue, lo que realmente quieres es un compresor, no un normalizador.