Skip to content

English · Español

02 — Modelos de Audio: log-mel, Whisper, HuBERT, wav2vec 2.0

🇪🇸 El audio no es texto ni imagen. Es una señal 1-D continua que primero hay que convertir en una representación 2-D imagen-like (el espectrograma log-mel) y solo entonces un transformer puede operar sobre ella. Esta sección deriva la cadena: 16 kHz → ventana 25 ms / salto 10 ms → 80-mel × 3000 frames → conv-downsampling → 1500 tokens. Después: Whisper, HuBERT, wav2vec 2.0.

Este fichero responde: ¿cómo se convierte una forma de onda de audio en una secuencia de tokens lista para transformer, y cuáles son los tres paradigmas principales de entrenamiento para modelos de audio?

Referencias: - Radford et al., Robust Speech Recognition via Large-Scale Weak Supervision (Whisper), 2022. (arXiv:2212.04356) - Hsu et al., HuBERT, IEEE/ACM TASLP 2021. (arXiv:2106.07447) - Baevski et al., wav2vec 2.0, NeurIPS 2020. (arXiv:2006.11477)


Por qué el audio necesita un frontend

Una señal de audio cruda al sample rate estándar de reconocimiento de habla de 16 kHz es un tensor 1-D de valores de amplitud float32. 30 segundos de audio = \(16\,000 \cdot 30 = 480\,000\) muestras.

No puedes soltar 480\,000 muestras directamente en un transformer. Razones:

  1. Longitud de secuencia. La atención es \(O(T^2)\). \(T = 480{,}000\) da \(\sim 2 \cdot 10^{11}\) operaciones por capa solo para el softmax. Ni siquiera FlashAttention puede hacer esto tratable.
  2. Densidad de información. La mayoría de las muestras están altamente correlacionadas con sus vecinas (la señal es de banda limitada). Muestras adyacentes llevan casi la misma información. Un modelo con granularidad de token a nivel de muestra desperdicia capacidad aprendiendo suavidad trivial.
  3. Invarianza de fase. Dos grabaciones de la misma palabra con un shift de 1-ms en el tiempo de inicio producen formas de onda muy diferentes a nivel de muestra (coseno ↔ −coseno sobre un período de medio kHz) pero los humanos las oyen como idénticas. Los modelos a nivel de muestra tienen que aprender la invarianza de fase — un presupuesto desperdiciado.

La solución: convertir la forma de onda en un espectrograma log-mel — una representación 2-D imagen-like donde un eje es el tiempo (a resolución mucho más gruesa) y el otro es la frecuencia (perceptualmente deformada). Todos los modelos de habla principales desde 2018 usan este frontend.


Espectrograma log-mel, derivado

La cadena tiene cuatro pasos. Quema cada uno en la memoria.

Paso 1 — enmarcar la forma de onda

Elige una longitud de ventana y una longitud de salto. Whisper usa:

  • Ventana: 25 ms = \(0.025 \cdot 16{,}000 = 400\) muestras.
  • Salto: 10 ms = \(0.010 \cdot 16{,}000 = 160\) muestras.

Para 30 s de audio (= \(480{,}000\) muestras):

\[ T_{\text{frames}} = \left\lfloor \frac{480{,}000 - 400}{160} \right\rfloor + 1 = 2998 + 1 \approx 3000. \]

(Whisper hace padding hasta exactamente 3000 frames como buffer de tamaño fijo.)

Así pasamos de 480 k muestras a 3 k frames — una compresión de 160× en el eje temporal, fijada por la longitud de salto.

Paso 2 — FFT con ventana

Para cada frame, aplica una ventana de Hann (suaviza discontinuidades en los bordes del frame; reduce el spectral leakage), después toma la transformada discreta de Fourier. Con tamaño de ventana 400, la salida FFT son 201 valores complejos (tamaño FFT = siguiente potencia de 2 = 512; espectro de un lado = 257; Whisper usa 201 poniendo a cero la cola).

La magnitud al cuadrado \(|X[f]|^2\) es el espectro de potencia de ese frame — energía en cada bin de frecuencia.

Tras el paso 2: un tensor 2-D de forma \((3000, 201)\) — potencia en cada celda (tiempo, frecuencia).

Paso 3 — proyección a la escala mel

Los 201 bins de frecuencia lineal son perceptualmente redundantes en la región de alta frecuencia (los humanos no distinguen 8 kHz de 8.1 kHz; sí distinguimos 100 Hz de 200 Hz). Proyectamos a una escala mel: 80 bandas perceptualmente espaciadas, densas a baja frecuencia, dispersas a alta frecuencia.

Concretamente: una matriz de proyección fija (no aprendida) \(\mathbf{M} \in \mathbb{R}^{201 \times 80}\) con pesos triangulares solapados. La salida es:

\[ \mathbf{S}_{\text{mel}} = \mathbf{S}_{\text{power}} \cdot \mathbf{M} \in \mathbb{R}^{3000 \times 80}. \]

Paso 4 — compresión logarítmica

La energía de audio cubre muchos órdenes de magnitud (pausa silenciosa vs. vocal alta). Toma \(\log(\mathbf{S}_{\text{mel}} + \epsilon)\). Recorta valores extremos.

Salida final: un espectrograma log-mel \(80 \times 3000\), tratado como una "imagen" de un solo canal. Esto es lo que el encoder de Whisper ingiere.

Por qué estos números específicos

  • Sample rate de 16 kHz captura hasta 8 kHz (Nyquist). El habla humana es ~80–8000 Hz; 16 kHz es el suelo para habla inteligible. (La música necesita 44.1 kHz; el habla telefónica es 8 kHz.)
  • Ventana de 25 ms es suficientemente larga para contener ~1 período de pitch completo de voz masculina (fundamental ~100 Hz, período 10 ms; voces femeninas ~200 Hz). 25 ms da un espectro estable.
  • Salto de 10 ms es más corto que la duración típica de un fonema (~50 ms), así que cada fonema cubre ~5 frames — resolución temporal adecuada.
  • 80 bandas mel es estándar desde DeepSpeech (2014). Más alto (128, 256) ayuda marginalmente; más bajo (40) duele; 80 es el consenso.

Arquitectura de Whisper

Whisper (OpenAI, 2022) es un transformer encoder-decoder sobre entrada log-mel, entrenado end-to-end para reconocimiento de habla multi-tarea + traducción + ID de idioma + timestamping. La arquitectura:

log-mel (80, 3000) input
2 × Conv1D (stride 1 then stride 2) → downsamples to (d_model, 1500)
+ sinusoidal position embedding (fixed, not learned — for the audio side)
N × Transformer encoder block (no causal mask)
audio embeddings (1500 tokens × d_model)
  └──── cross-attention key/value for decoder ──┐
  text tokens (BPE, 51865 vocab) ── M × Transformer decoder block ── next-token logits
                                  learned position embedding (text)

Tamaños (del paper, tabla 1):

Modelo params d_model enc layers dec layers heads
tiny 39M 384 4 4 6
base 74M 512 6 6 8
small 244M 768 12 12 12
medium 769M 1024 24 24 16
large-v3 1550M 1280 32 32 20

El lab 02 usa tiny.en (variante English-only, 39 M params). En una CPU como la i5-8250U, la transcripción de 30 s de audio es de ~5–10 s — utilizable para inspección offline.

Por qué conv-downsample a 1500

La entrada mel completa es 3000 frames. Tras dos convoluciones con stride (stride 1 luego stride 2), el eje temporal se reduce a la mitad a 1500. La motivación:

  • Cómputo. La atención es \(O(T^2)\). Reducir \(T\) a la mitad cuartea el cómputo de atención. Para 30 s de audio, \(T = 3000\) es grande; \(T = 1500\) es más tratable mientras aún preserva resolución a nivel de fonema (un token por ~20 ms).
  • Bias inductivo. Las convoluciones son la herramienta correcta para extracción de features locales tiempo-frecuencia en la capa de entrada. Aprenden cosas como "aumento de energía espectral a lo largo de 30 ms" que a un transformer le llevaría muchas capas descubrir.

Tokens multi-tarea

Whisper hace múltiples tareas en un solo decoder. El truco: tokens especiales prepended a la entrada del decoder que seleccionan la tarea.

<|startoftranscript|> <|en|> <|transcribe|> <|notimestamps|> [text tokens] <|endoftext|>

vs.

<|startoftranscript|> <|en|> <|translate|> <|notimestamps|> [text tokens] <|endoftext|>

vs. con timestamps:

<|startoftranscript|> <|en|> <|transcribe|> <|0.00|> the quick brown fox <|2.12|> ... <|endoftext|>

Los tokens de timestamp son 1500 tokens especiales codificando 0.00, 0.02, 0.04, ..., 29.98 segundos — un token por 20 ms, casando con la secuencia de 1500 tokens de audio. El modelo está entrenado para emitirlos inline con el texto. Esto hace de Whisper un sistema ASR streaming-ready (bueno, batch-streaming) de fábrica.

El lab 02 inspecciona exactamente esto: para un clip de 5 segundos de alguien diciendo una conjugación verbal, miramos: 1. Qué tokens de timestamp emite el modelo y en qué posiciones. 2. El patrón de cross-attention desde las posiciones de los tokens de texto hacia los 1500 tokens de audio — verificar que la cross-attention se concentra en la región de audio que matchea la palabra hablada.


HuBERT y wav2vec 2.0: pretraining auto-supervisado de audio

Whisper entrena supervisado: 680k horas de audio con transcripciones de texto (web-scraped, débilmente supervisado). Para tareas donde el audio transcrito es escaso (idiomas de bajo recurso, audio específico de dominio), el pretraining auto-supervisado es la respuesta.

wav2vec 2.0 (Facebook, 2020)

Arquitectura:

raw waveform (1-D, 16 kHz)
CNN feature encoder (7 convolutional blocks) → (T', 512)
quantization codebook → discrete tokens (used as targets only)
Transformer encoder (with span-masking on inputs) → (T', d)
Contrastive loss: predict the quantized token at masked positions

La pérdida es contrastiva: en un time-step enmascarado, el modelo debe seleccionar la representación cuantizada correcta de un pool de "distractores". Esto es directamente análogo al masked-language-modeling de BERT, pero a nivel de frame de audio con un puente continuo-a-discreto vía codebook.

Después del pretraining: fine-tune con pérdida CTC sobre audio transcrito para ASR. Solo 100 horas de datos etiquetados son suficientes para superar baselines totalmente supervisados entrenados sobre 1000 horas.

HuBERT (Facebook, 2021)

Un refinamiento de wav2vec 2.0. En vez de un cuantizador aprendido, HuBERT usa clustering k-means sobre features MFCC (y luego re-clusteriza iterativamente sobre las propias representaciones ocultas del modelo) para producir pseudo-etiquetas discretas. La tarea de pretraining se convierte en: predecir el ID de cluster de cada frame enmascarado.

Por qué esto es mejor: el cuantizador en wav2vec 2.0 está entrenado conjuntamente con el modelo, que es un blanco móvil. Los targets k-means de HuBERT son estables (offline), lo que hace el entrenamiento más fiable.

HuBERT es la base de muchos modelos de habla en producción (MMS de Meta, modelos de AssemblyAI, etc.).


Caveats de streaming

Whisper, HuBERT y wav2vec 2.0 son todos modelos batch — esperan el audio completo (hasta 30 s para Whisper) antes de producir salida. ASR de streaming (emitir transcripciones parciales conforme entra el audio) requiere una arquitectura diferente:

  • Encoder causal. Reemplaza la atención bidireccional del encoder por causal — el bloque encoder en el tiempo \(t\) solo ve frames de audio \(\le t\). Cuesta unos pocos % de WER (word error rate).
  • Atención chunked. El bloque encoder ve una ventana deslizante de tamaño fijo de frames. Intercambia latencia por precisión.
  • Conformer-Transducer (Google). Usa un encoder transformer aumentado con CNN (Conformer) + un decoder RNN-T (Recurrent Neural Network Transducer). Estándar para ASR de streaming en producción.

Whisper en sí no es streaming. La gente construye wrappers de streaming alrededor (chunkea audio en bloques de 5-s, transcribe cada uno, cose con solapamiento) pero el modelo subyacente es batch.

Por qué importa para el tutor de gramática (Fase 32): si el usuario habla una frase completa y espera feedback, Whisper batch sirve. Si quieres corrección en vivo mientras el usuario habla, necesitas un modelo de streaming. Los labs de X2 no abordan streaming.


Resumen del lado de audio

  • El audio crudo (480 k muestras a 16 kHz para 30 s) no puede entrar directamente en un transformer.
  • El frontend log-mel comprime a 3000 frames × 80 bandas-mel. Esta es la representación universal de entrada de audio.
  • Whisper es un transformer encoder-decoder que ingiere log-mel, hace conv-downsampling a 1500 tokens de audio, y decodifica texto + timestamps. 39 M a 1.5 B params.
  • wav2vec 2.0 / HuBERT son auto-supervisados, contrastivos sobre targets cuantizados de frame. Lo mejor cuando el audio transcrito es escaso.
  • El streaming requiere cambios arquitectónicos explícitos (causal / chunked / RNN-T); los modelos X2 son todos batch.

Siguiente: theory/03-fusion-strategies.md muestra cómo se combinan visión y audio (y texto) en un único modelo multimodal.