8 kHz es donde la IA de voz se rompe de verdad

Actualizado el 14 de agosto de 2026 con la ejecución regenerada de Null Test (18 condiciones) y con un nuevo experimento de banda estrecha de extremo a extremo. Esta actualización se retracta de una afirmación. Una versión anterior de este post repetía un informe de la comunidad según el cual la ruta de remuestreo por defecto de un framework importante descarta ~16% del audio del llamante. Construimos el control para comprobarlo, y nuestra medición no lo respalda. La sección está reescrita más abajo, no borrada.

Todas las demos de IA de voz que has visto corren a 16 kHz desde el micrófono de un portátil sobre WebRTC. Casi cada dólar de volumen de llamadas en producción llega a 8 kHz desde una línea telefónica que ya ha tirado la mitad superior del espectro. No son el mismo problema, y el segundo es donde los despliegues fallan en silencio.

La brecha no es un detalle de configuración. Es una octava de señal ausente, una cadena de códecs que nadie controla, una capa de plataforma donde — a fecha de escritura, y esta es nuestra lectura de la documentación de los proveedores — a menudo no puedes insertar tu propio procesamiento en absoluto, y un estante de modelos en el que nada está construido realmente para el canal.

Lo que una línea telefónica elimina de verdad

La telefonía PSTN y SIP es banda estrecha a 8 kHz, transportada como G.711 µ-law o A-law, con una banda de paso de aproximadamente 300 a 3400 Hz. Muestrear a 8 kHz sitúa el límite de Nyquist en 4 kHz, y el filtro del canal recorta otros 600 Hz por arriba. Todo lo que está por encima de 3.4 kHz simplemente no está presente — y en esa banda vive un conjunto específico y especialmente costoso de pistas fonéticas.

Pista	Dónde está su energía	¿Sobrevive a un canal de 300–3400 Hz?
/s/ frente a /f/ frente a /θ/	la energía sibilante alcanza su pico aproximadamente entre 4–8 kHz	No. Esta es la confusión clásica de banda estrecha.
Identidad vocálica (F1, F2)	250–2500 Hz	Sí
/r/ y las pistas de F3	aproximadamente 2000–3500 Hz	Marginal, justo en el corte
Transitorios de explosión de las oclusivas	banda ancha, gran parte por encima de 4 kHz	En parte; las explosiones quedan aplanadas
Murmullo nasal	por debajo de 1 kHz	Sí
Fundamental F0 del hablante	85–255 Hz para la mayoría de adultos	Normalmente por debajo del corte de 300 Hz; se reconstruye perceptualmente a partir de los armónicos

Así que los errores de banda estrecha no se distribuyen uniformemente por tu transcripción. Se agrupan exactamente donde los agentes de voz cargan con el mayor riesgo de negocio: dígitos («six» y «fix» pierden su discriminador más fiable), nombres y direcciones de correo deletreados, códigos de confirmación, y plurales que dependen de una /s/ o una /z/ al final de la palabra. Una subida de 3% en la tasa de error de palabras (WER) agregada puede ser una tasa de error de 30% en el único campo que la llamada existía para capturar.

La otra mitad del problema es el reconocedor. Whisper y la mayoría de los modelos modernos de STT se entrenan con audio de 16 kHz, así que el habla de banda estrecha está fuera de distribución antes de que se añada ruido alguno.

Pusimos a prueba el impuesto de remuestreo (resample tax), y no está ahí

Una versión anterior de este post abría con un aviso de la comunidad de LiveKit del 7 de agosto de 2026 que informaba de que el patrón de remuestreo por defecto con FrameProcessor descarta audio de forma continua — aproximadamente el 16% del habla del llamante, de forma permanente, en cada llamada — con un operador en el hilo recuperando casi dieciocho puntos de precisión de STT al corregirlo. Nosotros lo repetimos. Era lo más citable del post.

Luego construimos el control, y nuestra propia medición no lo respalda.

El control es simple. Toma el audio de banda estrecha del llamante, envíalo 8 kHz → 16 kHz → 8 kHz, y mide el SI-SDR de lo que vuelve contra lo que entró. Si una ida y vuelta de remuestreo destruye una fracción fija de la señal, ese número sale malo, y sale peor para el remuestreador más descuidado.

8 kHz → 16 kHz → 8 kHz	SI-SDR vs. su propia entrada
naive — repetición de muestras al subir, descarte de muestras al bajar, sin ningún filtrado	150 dB
linear — interpolación lineal, sin filtro anti-alias	150 dB
soxr_hq — polifásico/sinc, valor por defecto de la biblioteca	38.45 dB
soxr_vhq — polifásico/sinc, la implementación correcta	38.28 dB

Léelo dos veces. El remuestreador deliberadamente roto obtiene un nulo perfecto — 150 dB es el techo que reporta nuestro arnés cuando la señal diferencia es numéricamente cero — y el correcto puntúa 112 dB peor.

Ambos resultados son correctos, y la razón es aritmética, no un error de medición. En una relación exacta de 2:1, repetir muestras y luego descartarlas es algebraicamente la función identidad — cada muestra original vuelve bit a bit exacta, así que no queda nada que medir. El remuestreador polifásico puntúa más bajo precisamente porque hace su trabajo: aplica un filtro anti-alias, y un filtro cambia la señal. El SI-SDR de ida y vuelta, usado ingenuamente, premia la implementación rota. Esa es la trampa, y es la razón por la que esto necesitaba un control y no una intuición. (A 44.1 kHz, donde la relación no es entera, linear cae a 32.49 dB — la propiedad de identidad es específica del caso 2:1 que la telefonía realmente usa.)

Aguas abajo, en la transcripción, es la misma historia. Sin ningún modelo en la ruta, la elección de remuestreador vale 0.18 puntos de WER: soxr_vhq puntúa 10.96% frente al 11.14% de linear, contra un control de 8 kHz sin procesar de 11.14%. Sobre 1,140 palabras de referencia eso son dos palabras. Es un empate.

Y con un modelo en la ruta, el resultado se invierte. En los seis pares de modelo y remuestreador que probamos, el remuestreador naive transcribió mejor — una media de −3.0 puntos, todos y cada uno de los pares en negativo, desde −0.4 (aic-quail con naive) hasta −5.6 (fastenhancer-b con linear). El mecanismo probable es que un remuestreador polifásico es una etapa de filtrado adicional con la que el modelo nunca se entrenó, mientras que el vecino más cercano a 2:1 es una identidad, así que la ruta naive le entrega al modelo una señal menos alterada.

Así que: no afirmamos que el remuestreo destruya el audio del llamante, no repetimos la cifra del 16% como si fuera nuestra, y no venderemos la corrección del remuestreo como precisión recuperada. No sabemos qué estaba midiendo la instrumentación del autor del aviso — la contabilidad de frames dentro de un pipeline concreto no es el mismo experimento que el nuestro, y su arreglo claramente ayudó a su despliegue. Lo que sí podemos decir es que la afirmación general, en la forma en que la repetimos, no se reproduce aquí.

Si te llevas una sola acción de este post, sigue siendo esta: graba el audio que tu reconocedor realmente recibe, no el que entrega tu troncal SIP, y compara sus duraciones. La contabilidad de frames merece comprobarse. Solo que no vale un punto de WER.

El sobremuestreo que no arregla nada

Incluso un remuestreador correcto no restaura nada. Remuestreas 8 kHz a 16 kHz porque el modelo exige entrada de 16 kHz; eso satisface la interfaz y no añade información. La octava de 4 a 8 kHz sigue vacía, porque nunca hubo energía ahí que interpolar. Lo que ve el modelo acústico es un espectrograma de 16 kHz con la mitad superior muerta y un escalón duro en 3.4 kHz — un patrón que aparece en sus datos de entrenamiento sobre todo como una degradación, si es que aparece.

16 kHz mic capture            8 kHz PSTN, upsampled to 16 kHz

8k ┤▓▓▒▒░░ fricatives           8k ┤              (nothing)
6k ┤▓▓▓▒▒░                      6k ┤              (nothing)
4k ┤▓▓▓▓▒▒                      4k ┤──────────── hard shelf
2k ┤████▓▓  formants            2k ┤████▓▓  formants
0  ┤█████▓                      0  ┤ ███▓▓  (HPF at ~300 Hz)
   └──────── time                  └──────── time

Así que «soportamos telefonía» en la mayoría de los stacks significa «remuestreamos y cruzamos los dedos». El fallo interesante no es el remuestreador — acabamos de dedicarle una sección a establecerlo — sino que el modelo al otro lado está recibiendo una distribución con la que nunca se entrenó.

Lo que medimos: nada en el estante ayuda en la línea telefónica

Pasamos la ruta de telefonía por Null Test, nuestro benchmark abierto. Siete de sus dieciocho condiciones son telefonía: una ida y vuelta G.711 µ-law — remuestrear a 8 kHz, codificar, decodificar, remuestrear de vuelta —, la misma ida y vuelta con ruido a 10 dB SNR, y cinco variantes de transporte (A-law, G.722, Opus a 12 kbps, y pérdida de paquetes a ráfagas de 3% y 10%).

Procedencia, porque estos números valen exactamente lo que vale su método: un solo reconocedor, faster-whisper base.en (CTranslate2 int8 CPU, greedy), Silero VAD, 10 hablantes / 180 clips / aproximadamente 1406 segundos de audio, unas 190 palabras de referencia por condición, 18 condiciones, 12 backends, Apple M1 Max, onnxruntime 1.28.0 fijado a un hilo intra-op. Con ese tamaño de muestra una palabra vale aproximadamente 0.5 puntos de WER; lee las columnas de deltas en consecuencia.

Backend	G.711	Δ vs. sin procesar	G.711 + ruido 10 dB	Δ vs. sin procesar
Sin procesar (raw)	5.8%	—	10.5%	—
FastEnhancer-S (MIT)	5.3%	-0.5	14.2%	+3.7
FastEnhancer-M (MIT)	5.8%	0.0	12.1%	+1.6
ai-coustics Quail L	7.4%	+1.6	12.1%	+1.6
ai-coustics Quail VF 2.2 L	8.4%	+2.6	9.5%	-1.1
GTCRN (MIT)	8.9%	+3.2	11.1%	+0.5
FastEnhancer-T (MIT)	12.6%	+6.8	17.4%	+6.8
DeepFilterNet3	15.3%	+9.5	20.0%	+9.5

Ningún modelo de mejora de voz (speech enhancement) produjo una mejora significativa sobre audio de telefonía, y varios causaron degradaciones grandes — FastEnhancer-T con +6.8 puntos en ambas condiciones, DeepFilterNet3 con +9.5 en ambas.

Sé preciso con las dos victorias aparentes, porque son el tipo de cosa que se cita sin su barra de error. FastEnhancer-S queda a -0.5 puntos en la fila limpia — a menos de una palabra de referencia de no hacer nada — y 3.7 peor en cuanto se añade ruido. Quail VF queda a -1.1 en la fila con ruido y a +2.6 en la limpia. Ninguna es una victoria, ninguna es una derrota. La lectura útil es que el lado bueno tiene forma de cero y el lado malo llega a los diez puntos.

Las cinco condiciones de transporte que añadimos en esta ejecución estrechan esa lectura en lugar de cambiarla. En ninguna de ellas ningún motor supera al audio sin procesar, y en cuatro de las cinco lo mejor que consigue un motor es un empate exacto:

Condición	Sin procesar	Mejor motor	Peor motor
A-law	7.4%	7.4% (Quail L, empate)	49.0% (FastEnhancer-M)
G.722	5.3%	5.3% (FastEnhancer-B, empate)	6.8% (FastEnhancer-M)
Opus 12 kbps	6.8%	6.8% (FastEnhancer-S, empate)	12.1% (GTCRN)
Pérdida a ráfagas de 3%	11.1%	11.1% (Quail VF, empate)	24.7% (DeepFilterNet3)
Pérdida a ráfagas de 10%	10.0%	10.5% (Quail L)	35.3% (FastEnhancer-T)

La fila de FastEnhancer-M en A-law merece mirarse fijamente: 49.0% contra una línea base sin procesar de 7.4%, impulsada por 61 inserciones donde el audio sin procesar tiene 2. El ruido de cuantización por compansión no es lo que ese modelo espera, y responde alucinando. Esta es la forma de toda la categoría en una línea telefónica — el techo es un empate y el suelo es una catástrofe.

El número de DeepFilterNet3 necesita su salvedad cada vez: lo medimos a través de un adaptador block-online, porque ningún export público de ONNX lleva los tensores de estado recurrente, así que el streaming por frame es imposible con los pesos publicados. Sus filas son una cota inferior de calidad y una cota superior de coste. Las filas de ai-coustics son una línea base propietaria ejecutada a través del SDK con licencia — un punto de referencia, nunca una ruta de código que nosotros vayamos a desplegar.

El experimento que le faltaba a esa tabla: 8 kHz de extremo a extremo

La WER sin procesar en nuestra condición G.711 es 5.8%. Esa es una condición fácil, y cada backend de la matriz de arriba es un modelo de banda ancha apuntado a una señal de banda estrecha. Dice algo específico y limitado — los modelos de mejora de banda ancha no ayudan en un canal de banda estrecha y pueden hacer mucho daño — y nada sobre si procesar nativamente a 8 kHz supera al remuestreo.

Así que construimos el experimento que responde a eso. Sesenta clips, seis condiciones de banda estrecha, 8 kHz de extremo a extremo sin nada remuestreado en ningún punto del brazo, tres modelos genuinamente nativos de 8 kHz, y el remuestreador de ingesta del STT fijado en soxr_vhq en todos los brazos, controles incluidos. 1,140 palabras de referencia, así que una palabra vale 0.09 puntos de WER — esa proporción viaja con cada número de abajo.

Ruta	WER	vs. 8 kHz sin procesar
8 kHz sin procesar (control)	11.14%	—
solo remuestreo, sin modelo, soxr_vhq	10.96%	−0.18
solo remuestreo, sin modelo, linear	11.14%	0.00
8 kHz nativo quail-l-8khz	11.05%	−0.09
8 kHz nativo quail-s-8khz	11.32%	+0.18
8 kHz nativo rook-l-8khz	12.46%	+1.32
quail sobremuestreado (pesos de 16 kHz), soxr_vhq	11.75%	+0.61
quail-vf sobremuestreado (pesos de 16 kHz), soxr_vhq	12.98%	+1.84
gtcrn sobremuestreado, soxr_vhq	16.58%	+5.44
fastenhancer-b sobremuestreado, soxr_vhq	17.63%	+6.49
fastenhancer-m sobremuestreado, soxr_vhq	21.14%	+10.00
fastenhancer-t sobremuestreado, soxr_vhq	24.82%	+13.68

De ahí salen tres cosas, y solo una de ellas es la que fuimos a buscar.

El 8 kHz nativo sí supera a remuestrear y cruzar los dedos — por 0.7 puntos. Mismo proveedor, misma familia de modelos, con la única diferencia de pesos de 8 kHz contra pesos de 16 kHz sobre una ruta remuestreada: 11.05% contra 11.75%. Hasta donde hemos podido encontrar, nadie ha publicado nunca esa comparación. También son unas ocho palabras sobre 1,140, lo que lo convierte en un resultado real, direccional y modesto, no en un titular. Es una razón para construir nativo. No es una razón para comprar nada.

Nada superó al audio del llamante sin tocar. La mejor ruta de la tabla, quail-l-8khz con 11.05%, queda 0.09 puntos por debajo del 11.14% del control sin procesar — una palabra. Eso es un empate, no una victoria. Todas las demás rutas son peores que no hacer nada. En una llamada de banda estrecha, en agosto de 2026, la hipótesis nula sigue invicta.

Y apenas hay nada que probar. Mira lo corta que es la sección nativa. Esos tres modelos son la población entera de pesos de mejora genuinamente de banda estrecha que pudimos obtener. GTCRN, FastEnhancer y DeepFilterNet3 no tienen ningún checkpoint de 8 kHz — no uno peor: ninguno — así que en una llamada telefónica solo pueden ejecutarse a través de un envoltorio de remuestreo, y por eso aparecen en esta tabla exclusivamente como filas sobremuestreadas. Un proveedor publica pesos de banda estrecha. Nadie publica aislamiento del hablante (speaker isolation) de banda estrecha: todos los modelos Voice Focus de ai-coustics y su detección de actividad de voz (VAD) de hablante principal son solo de 16 kHz, mientras que el mismo proveedor sí publica 8 kHz para su mejorador general y para su modelo de escucha humana. La respuesta de Krisp para telefonía es una variante posicionada explícitamente como más ligera que su línea principal.

Ese es el hallazgo real de este post, y nos llevó un tiempo verlo porque estábamos ocupados buscando daños. El problema en la línea telefónica no es que algo esté rompiendo tu audio. Es que lo que querrías ejecutar sobre ella nunca se construyó.

Lo que la matriz todavía omite se ve mejor contra la cadena de señal real de abajo, de la que nuestras condiciones modelan algunas etapas y otras no.

Nadie en la cadena está de tu lado

Incluso antes del límite de banda, la señal ya ha pasado por varias etapas de procesamiento que no controlas y no puedes inspeccionar.

Etapa	Procesamiento típico	Clase de artefacto que introduce	¿Modelada ya?
Terminal (handset)	codificación AMR-WB o EVS, supresión de ruido del dispositivo, AGC	habla ya suprimida, ruido musical, ganancia con bombeo	No
Interconexión del operador	transcodificación a G.711 µ-law o A-law, G.722, Opus de bajo bitrate; submuestreo a 8 kHz	límite de banda, ruido de cuantización por compansión	Sí
Troncal SIP	buffer de jitter, ocultación de pérdida de paquetes, DTX, ruido de confort	empalmes en el dominio del tiempo, frames repetidos, suelo de ruido sintético	Sí — pérdida a ráfagas de dos estados a 3% y 10%
Ruta de eco	retorno del propio TTS del agente por una híbrida o un altavoz	inserciones fluidas y seguras de sí mismas	No — la mayor brecha restante
Tu stack	remuestreo a 16 kHz, a menudo una segunda pasada de supresión	banda superior vacía, supresión en cascada	En parte

Las filas del operador y de la pérdida de paquetes pasaron de «No» a «Sí» en esta actualización, y cada una merece una nota.

La ocultación de pérdida de paquetes no es silencio. Cuando se pierde un paquete, el buffer de jitter sintetiza un reemplazo a partir de frames anteriores: una forma de onda plausible sin contenido lingüístico, de la que un reconocedor decodificará palabras con mucho gusto. Son inserciones que ningún modelo de mejora puede arreglar, porque la señal no está degradada — está fabricada. Lo modelamos como borrado a ráfagas de dos estados (Gilbert-Elliott) de frames de 20 ms con ocultación por repetición atenuada, en lugar de pérdida aleatoria independiente con relleno de silencio: la pérdida independiente favorece a todos los decodificadores y el relleno de silencio exagera el daño.

El terminal ya suprimió. El audio normalmente ya viene suprimido una vez en el dispositivo antes de que tú lo toques, así que estás poniendo en cascada un segundo supresor neuronal sobre los artefactos de un primero. Nadie ha caracterizado eso públicamente, nosotros incluidos — aunque nuestros resultados sí muestran que una pasada de supresión sobre material que no la necesita es fiablemente cara; ver El pipeline dividido.

El eco es la fila que sigue faltando, y es la que más queremos. El eco acústico con distorsión no lineal del altavoz es el deterioro que hay detrás de la mitad de este producto que no se puede arreglar con un parche, y todavía no hemos construido la condición para medirlo. Hasta que lo hagamos — y hasta que Clearline sea una fila en estas tablas contra un control passthrough al que se le permite ganarle — hemos medido el estante, no nuestra respuesta a él.

La brecha de plataforma

Hay una razón estructural por la que los 8 kHz están desatendidos: en la ruta de mayor volumen, las grandes plataformas no te dan dónde apoyarte. A fecha de escritura, y dicho como nuestra lectura de la documentación publicada:

• La integración de troncales SIP de LiveKit expone solo la cancelación de ruido estándar de Krisp — no la variante de cancelación de voces de fondo disponible en otras rutas. La pata de telefonía, la que tiene el peor audio, recibe la menos capaz de las dos opciones incluidas.
• En Twilio no hay un lugar documentado para interceptar el medio junto a <ConversationRelay> — pero esto es inferencia nuestra, no una afirmación suya. <Connect> está documentado como terminal y el socket de ConversationRelay transporta solo JSON, así que Twilio tiene que terminar y reoriginar el medio. Twilio no dice que <Stream> sea incompatible, y tampoco dice que funcione; un grep de la referencia de <Connect>, de la vista general de ConversationRelay y de las páginas de onboarding no devuelve texto en ningún sentido. Nosotros afirmamos esto como un hecho antes de comprobarlo, y eso estuvo mal por nuestra parte. Se resuelve con una llamada telefónica y no la hemos hecho.
• El propio representante de ai-coustics aleja a los clientes de telefonía de sus modelos de 8 kHz y los dirige hacia el de 16 kHz. Lo leemos como una respuesta franca de ingeniería y no como un desliz: los modelos de banda estrecha no son donde está su calidad.
• Todos los modelos de aislamiento del hablante del mercado son de 16 kHz. ai-coustics publica pesos de 8 kHz para su mejorador general y para su modelo de escucha humana, pero cada variante de Voice Focus y su VAD de hablante principal son solo de 16 kHz. La entrada de telefonía de Krisp es una variante posicionada como más ligera que su línea principal. La telefonía es exactamente donde los hablantes que compiten con el llamante son peores — salas de contact center, altavoces, una televisión de fondo — y es el único lugar donde los modelos de aislamiento no pueden ejecutarse.
• El DNS Challenge — la principal serie de benchmarks de eliminación de ruido del campo, contra la que se afinan la mayoría de los supresores publicados — nunca tuvo una pista de banda estrecha. Si el benchmark que define el estado del arte nunca puntuó a 8 kHz, el estado del arte nunca se optimizó para 8 kHz. Nuestras filas de telefonía son el aspecto que tiene esa omisión desde el extremo receptor.

Si alguna de esas lecturas es errónea, o cambia, corregiremos este post y anotaremos la fecha. Ya lo hemos hecho una vez, arriba del todo.

La consecuencia es que la decisión sobre la calidad de audio en tu canal de mayores ingresos la toma por ti un componente empaquetado que no elegiste y no puedes medir. La cancelación básica de ruido ya es gratis en todas partes — eso no es lo escaso. Lo escaso es un modelo entrenado para el canal real, y evidencia sobre si ayuda aguas abajo.

Qué es Clearline, y qué tiene que demostrar

Una cosa con la que deliberadamente no abre es la extensión de ancho de banda. Predecir la banda ausente de 4 a 8 kHz es posible, pero es generativo: no recupera la /s/ del llamante, sintetiza una plausible. Eso es una ganancia real para un oyente y un número de PESQ grande, y para un reconocedor es una nueva manera de producir una sustitución segura de sí misma — el error pasa de «irrecuperable» a «equivocado con confianza». El mismo desajuste de objetivos que en todas partes, en su punto más ancho en banda estrecha.

Clearline es un producto de telefonía, no un supresor de ruido general. Tres compromisos, ordenados por cuánta parte del argumento carga cada uno:

• Aislamiento nativo del hablante principal a 8 kHz. La brecha que expone la tabla de arriba. El modelo corre a la frecuencia de muestreo del canal, y conserva a la persona al teléfono en lugar de la sala que tiene detrás. Nadie entrega esto a 8 kHz hoy; esa es toda la razón para construirlo.
• Supresión de eco residual. Una híbrida o un altavoz filtran el propio TTS del agente de vuelta al reconocedor como inserciones fluidas y seguras de sí mismas. Eso no es ruido ambiente y un supresor de ruido no lo arregla. Tampoco tiene todavía una condición en nuestro benchmark, lo que consideramos un agujero más grande que cualquier número de este post.
• Remuestreo correcto. Tantas muestras entran como salen, verificado en CI. Degradamos este punto deliberadamente. Solíamos llamarlo una característica del producto; el control de más arriba en este post es la razón por la que ahora lo llamamos higiene. Es correcto porque la corrección es barata, no porque te compre precisión.

Dónde está el modelo en sí. Clearline se entrena con datos limpios en cuanto a licencias a través de un pipeline que es completamente nuestro, y el trabajo de arquitectura y de corpus está activo ahora mismo — la extracción del hablante objetivo en banda estrecha es un problema más difícil que el caso de banda ancha sobre el que está escrita la literatura publicada, que es precisamente la razón de que el estante esté vacío. Clearline no aparece en ninguna tabla de este sitio hasta que se gane la fila, medido en las mismas condiciones y contra el mismo control que todo lo demás aquí. Esa regla es la razón de que las tablas de arriba merezcan leerse.

El número llegará cuando Clearline sea una fila en Null Test, en condiciones de telefonía que incluyan eco, contra un control passthrough al que se le permite ganarle — un control que, con la evidencia de arriba, actualmente le gana a todo. Si no supera ese control, eso también se publica. Cualquier otra cosa haría que el resto de los números de este sitio no valieran nada, y esos números son el verdadero activo aquí.

También sin responder: cuánta de la WER de banda estrecha son artefactos de códec frente a límite de banda, si la extensión de ancho de banda es neta positiva para la WER, y si los reconocedores de streaming se degradan de forma distinta que los de lote en un canal de banda estrecha.

Adónde ir desde aquí

Si operas tráfico telefónico, el primer paso no es comprar nada. Mide tu propia ruta de 8 kHz contra un control passthrough y lee la descomposición de errores en lugar del agregado. Inserciones agrupadas alrededor del silencio normalmente significan ocultación de pérdida de paquetes o retorno de eco. Sustituciones en sibilantes y dígitos significan el límite de banda. Eliminaciones de palabras funcionales cortas significan que algo aguas arriba ya está suprimiendo demasiado fuerte.

El arnés está abierto en github.com/anecho y la matriz completa — incluida cada celda donde perdemos — está en /benchmark. Probar Clearline con tu propio audio requiere una clave de API, no una llamada de ventas: /docs.