8 kHz é onde a IA de voz realmente quebra

Atualizado em 14 de agosto de 2026 com a rodada regenerada do Null Test (18 condições) e com um novo experimento de banda estreita de ponta a ponta. Esta atualização retira uma afirmação. Uma versão anterior deste post repetia um relato da comunidade de que o caminho de reamostragem padrão de um framework importante descarta ~16% do áudio de quem liga. Construímos o controle para isso, e a nossa medição não o sustenta. A seção foi reescrita abaixo, em vez de apagada.

Toda demo de IA de voz que você já viu roda a 16 kHz, de um microfone de laptop, por WebRTC. Quase cada dólar de volume de chamadas em produção chega a 8 kHz, de uma linha telefônica que já jogou fora a metade superior do espectro. Esses não são o mesmo problema, e o segundo é onde as implantações falham em silêncio.

A lacuna não é um detalhe de configuração. É uma oitava de sinal ausente, uma cadeia de codecs que ninguém controla, uma camada de plataforma em que — no momento em que escrevemos, e esta é a nossa leitura da documentação dos fornecedores — muitas vezes você simplesmente não pode inserir o seu próprio processamento, e uma prateleira de modelos na qual nada foi de fato construído para o canal.

O que uma linha telefônica realmente remove

PSTN e telefonia SIP são banda estreita de 8 kHz, transportada como G.711 µ-law ou A-law, com uma banda passante de aproximadamente 300 a 3400 Hz. Amostrar a 8 kHz coloca o limite de Nyquist em 4 kHz, e o filtro do canal tira mais 600 Hz do topo. Tudo acima de 3.4 kHz simplesmente não está presente — e é nessa faixa que vive um conjunto específico, e incomumente caro, de pistas de fonemas.

Pista	Onde está a sua energia	Sobrevive a um canal de 300–3400 Hz?
/s/ versus /f/ versus /θ/	a energia das sibilantes tem pico em aproximadamente 4–8 kHz	Não. Esta é a confusão clássica da banda estreita.
Identidade da vogal (F1, F2)	250–2500 Hz	Sim
/r/ e pistas de F3	aproximadamente 2000–3500 Hz	Marginal, bem no corte
Transientes de explosão de plosivas	banda larga, boa parte acima de 4 kHz	Em parte; as explosões saem achatadas
Murmúrio nasal	abaixo de 1 kHz	Sim
Fundamental F0 do locutor	85–255 Hz para a maioria dos adultos	Geralmente abaixo do corte de 300 Hz; reconstruída perceptualmente a partir dos harmônicos

Portanto, os erros de banda estreita não se distribuem uniformemente pela sua transcrição. Eles se concentram exatamente onde os agentes de voz carregam o maior risco de negócio: dígitos ("six" e "fix" perdem o seu discriminador mais confiável), nomes e endereços de e-mail soletrados, códigos de confirmação e plurais que dependem de um /s/ ou /z/ no fim da palavra. Um aumento de 3% na taxa de erro de palavras (WER) agregada pode ser uma taxa de erro de 30% no único campo que a ligação existia para capturar.

A outra metade do problema é o reconhecedor. O Whisper e a maioria dos modelos modernos de STT são treinados com áudio de 16 kHz, então a fala em banda estreita já está fora da distribuição antes de qualquer ruído ser adicionado.

Testamos o imposto de reamostragem, e ele não está lá

Uma versão anterior deste post abria com um aviso da comunidade LiveKit, de 7 de agosto de 2026, relatando que o padrão default de reamostragem do FrameProcessor descarta áudio continuamente — aproximadamente 16% da fala de quem liga, de forma permanente, em toda chamada — com um operador na thread recuperando quase dezoito pontos de acurácia de STT ao corrigi-lo. Nós repetimos isso. Era a coisa mais citável do post.

Então construímos o controle, e a nossa própria medição não o sustenta.

O controle é simples. Pegue o áudio de banda estreita de quem liga, envie-o por 8 kHz → 16 kHz → 8 kHz e meça o SI-SDR do que volta contra o que entrou. Se uma ida e volta de reamostragem destrói uma fração fixa do sinal, esse número é ruim, e é pior para o reamostrador mais desleixado.

8 kHz → 16 kHz → 8 kHz	SI-SDR vs a própria entrada
naive — repetição de amostras na subida, descarte de amostras na descida, nenhuma filtragem	150 dB
linear — interpolação linear, sem filtro anti-aliasing	150 dB
soxr_hq — polifásico/sinc, default da biblioteca	38.45 dB
soxr_vhq — polifásico/sinc, a implementação correta	38.28 dB

Leia isso duas vezes. O reamostrador deliberadamente quebrado marca um nulo perfeito — 150 dB é o teto que o nosso harness reporta quando o sinal de diferença é numericamente zero — e o correto marca 112 dB pior.

Os dois resultados estão certos, e a razão é aritmética, não erro de medição. Em uma razão exata de 2:1, repetir amostras na subida e descartá-las na descida é algebricamente a função identidade — cada amostra original volta bit a bit exata, então não sobra nada para medir. O reamostrador polifásico pontua mais baixo precisamente porque faz o seu trabalho: aplica um filtro anti-aliasing, e um filtro altera o sinal. O SI-SDR de ida e volta, usado ingenuamente, recompensa a implementação quebrada. Essa é a armadilha, e é por isso que aqui era preciso um controle, não uma intuição. (A 44.1 kHz, onde a razão não é inteira, o linear cai para 32.49 dB — a propriedade de identidade é específica do caso 2:1, que é exatamente o que a telefonia atinge.)

Mais adiante, na transcrição, é a mesma história. Sem nenhum modelo no caminho, a escolha do reamostrador vale 0.18 ponto de WER: o soxr_vhq marca 10.96% contra os 11.14% do linear, frente a um controle bruto de 8 kHz de 11.14%. Em 1,140 palavras de referência, isso são duas palavras. É um empate.

E com um modelo no caminho, o resultado se inverte. Em todos os seis pares de modelo e reamostrador que testamos, o reamostrador naive transcreveu melhor — média de −3.0 pontos, todos os pares negativos, de −0.4 (aic-quail com naive) a −5.6 (fastenhancer-b com linear). O mecanismo provável é que um reamostrador polifásico é um estágio extra de filtragem com o qual o modelo nunca treinou, enquanto o vizinho-mais-próximo 2:1 é uma identidade, então o caminho ingênuo entrega ao modelo um sinal menos alterado.

Portanto: não estamos afirmando que a reamostragem destrói o áudio de quem liga, não estamos repetindo o número de 16% como se fosse nosso, e não vamos vender correção de reamostragem como acurácia recuperada. Não sabemos o que a instrumentação do autor do aviso estava medindo — contabilidade de frames dentro de um pipeline específico não é o mesmo experimento que o nosso, e a correção deles claramente ajudou a implantação deles. O que podemos dizer é que a afirmação geral, na forma em que a repetimos, não se reproduz aqui.

Se você for tirar uma única ação deste post, ela continua sendo: grave o áudio que o seu reconhecedor realmente recebe, não o que o seu tronco SIP entrega, e compare as durações. Contabilidade de frames vale a checagem. Só não vale um ponto de WER.

A sobreamostragem que não conserta nada

Mesmo um reamostrador correto não restaura nada. Você reamostra 8 kHz para 16 kHz porque o modelo exige entrada de 16 kHz; isso satisfaz a interface e não adiciona informação nenhuma. A oitava de 4 a 8 kHz continua vazia, porque nunca houve energia ali para interpolar. O que o modelo acústico vê é um espectrograma de 16 kHz com a metade superior morta e um degrau duro em 3.4 kHz — um padrão que aparece nos seus dados de treinamento, quando aparece, principalmente como degradação.

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

Então, na maioria das stacks, "suportamos telefonia" significa "reamostramos e torcemos". A falha interessante não é o reamostrador — acabamos de gastar uma seção estabelecendo isso — é que o modelo do outro lado dele está sendo alimentado com uma distribuição com a qual nunca treinou.

O que medimos: nada na prateleira ajuda na linha telefônica

Rodamos o caminho de telefonia pelo Null Test, o nosso benchmark aberto. Sete das suas dezoito condições são de telefonia: uma ida e volta G.711 µ-law — reamostrar para 8 kHz, codificar, decodificar, reamostrar de volta —, a mesma ida e volta com ruído a 10 dB SNR, e cinco variantes de operadora (A-law, G.722, Opus a 12 kbps e perda de pacotes em rajadas a 3% e 10%).

Procedência, porque esses números valem exatamente o que vale o método deles: um único reconhecedor, faster-whisper base.en (CTranslate2 int8 CPU, greedy), Silero VAD, 10 locutores / 180 clipes / aproximadamente 1406 segundos de áudio, cerca de 190 palavras de referência por condição, 18 condições, 12 backends, Apple M1 Max, onnxruntime 1.28.0 fixado em uma única thread intra-op. Nesse tamanho de amostra, uma palavra vale aproximadamente 0.5 ponto de WER; leia as colunas de delta de acordo.

Backend	G.711	Δ vs bruto	G.711 + ruído 10 dB	Δ vs bruto
Bruto (sem processamento)	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

Nenhum aprimorador de fala (speech enhancer) produziu melhora significativa em áudio de telefonia, e vários causaram degradações grandes — o FastEnhancer-T a +6.8 pontos nas duas condições, o DeepFilterNet3 a +9.5 em ambas.

Seja preciso sobre as duas vitórias aparentes, porque elas são o tipo de coisa que se cita sem a barra de erro. O FastEnhancer-S está -0.5 ponto na linha limpa — a menos de uma palavra de referência de não fazer nada — e 3.7 pior assim que o ruído entra. O Quail VF está -1.1 na linha com ruído e +2.6 na limpa. Nenhum dos dois é vitória, nenhum é derrota. A leitura útil é que o lado positivo tem formato de zero e o lado negativo chega a dez pontos.

As cinco condições de operadora que adicionamos nesta rodada apertam essa leitura, em vez de mudá-la. Em nenhuma delas qualquer engine vence o bruto, e em quatro das cinco o melhor que uma engine consegue é um empate exato:

Condição	Bruto	Melhor engine	Pior engine
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)
Perda em rajadas de 3%	11.1%	11.1% (Quail VF, empate)	24.7% (DeepFilterNet3)
Perda em rajadas de 10%	10.0%	10.5% (Quail L)	35.3% (FastEnhancer-T)

A linha do FastEnhancer-M em A-law merece ser encarada: 49.0% contra uma baseline bruta de 7.4%, puxada por 61 inserções onde o bruto tem 2. Ruído de quantização de companding não é o que esse modelo espera, e ele responde alucinando. Esse é o formato da categoria inteira em uma linha telefônica — o teto é um empate e o chão é uma catástrofe.

O número do DeepFilterNet3 precisa da sua ressalva toda vez: nós o medimos através de um adaptador block-online, porque nenhum export ONNX público carrega os tensores de estado recorrente, então streaming por frame é impossível com os pesos publicados. As linhas dele são um limite inferior de qualidade e um limite superior de custo. As linhas da ai-coustics são uma baseline proprietária rodada através do SDK licenciado — um ponto de referência, nunca um caminho de código que nós colocamos em produção.

O experimento que faltava naquela tabela: 8 kHz de ponta a ponta

A WER bruta na nossa condição G.711 é 5.8%. Essa é uma condição fácil, e todo backend na matriz acima é um modelo de banda larga apontado para um sinal de banda estreita. Ela diz algo específico e limitado — aprimoradores de banda larga não ajudam em um canal de banda estreita e podem atrapalhar muito — e nada sobre se processar nativamente a 8 kHz vence a reamostragem.

Então construímos o experimento que responde a isso. Sessenta clipes, seis condições de banda estreita, 8 kHz de ponta a ponta sem nada reamostrado em lugar nenhum do braço, três modelos genuinamente nativos de 8 kHz, e o reamostrador de ingestão do STT mantido constante em soxr_vhq em todos os braços, incluindo os controles. 1,140 palavras de referência, então uma palavra vale 0.09 ponto de WER — essa razão viaja com cada número abaixo.

Caminho	WER	vs 8 kHz bruto
8 kHz bruto (controle)	11.14%	—
apenas reamostragem, sem modelo, soxr_vhq	10.96%	−0.18
apenas reamostragem, sem 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 sobreamostrado (pesos de 16 kHz), soxr_vhq	11.75%	+0.61
quail-vf sobreamostrado (pesos de 16 kHz), soxr_vhq	12.98%	+1.84
gtcrn sobreamostrado, soxr_vhq	16.58%	+5.44
fastenhancer-b sobreamostrado, soxr_vhq	17.63%	+6.49
fastenhancer-m sobreamostrado, soxr_vhq	21.14%	+10.00
fastenhancer-t sobreamostrado, soxr_vhq	24.82%	+13.68

Dele saem três coisas, e só uma delas é a que fomos buscar.

8 kHz nativo vence, sim, o reamostrar-e-torcer — por 0.7 ponto. Mesmo fornecedor, mesma família de modelo, sendo a única diferença pesos de 8 kHz contra pesos de 16 kHz em um caminho reamostrado: 11.05% contra 11.75%. Até onde conseguimos apurar, essa comparação nunca foi publicada por ninguém. São também cerca de oito palavras em 1,140, o que faz dela um resultado real, direcional e modesto — não uma manchete. É uma razão para construir nativo. Não é uma razão para comprar coisa alguma.

Nada venceu o áudio intocado de quem liga. O melhor caminho da tabela, o quail-l-8khz a 11.05%, fica 0.09 ponto abaixo dos 11.14% do controle bruto — uma palavra. Isso é um empate, não uma vitória. Todos os outros caminhos são piores do que não fazer nada. Em uma chamada telefônica de banda estreita, em agosto de 2026, a hipótese nula segue invicta.

E quase não há o que testar. Veja como a seção nativa é curta. Aqueles três modelos são a população inteira de pesos de aprimoramento genuinamente de banda estreita que conseguimos obter. GTCRN, FastEnhancer e DeepFilterNet3 não têm checkpoint de 8 kHz nenhum — não um pior, nenhum — então em uma chamada telefônica eles só podem rodar através de um invólucro de reamostragem, e é por isso que aparecem nesta tabela exclusivamente como linhas sobreamostradas. Um fornecedor entrega pesos de banda estreita. Ninguém entrega isolamento de locutor (speaker isolation) em banda estreita: todo modelo Voice Focus da ai-coustics e o VAD de locutor primário deles são somente 16 kHz, enquanto o mesmo fornecedor entrega, sim, 8 kHz para o aprimorador geral e para o modelo voltado à escuta humana. A resposta de telefonia da Krisp é uma variante explicitamente posicionada como mais leve que a linha principal.

Esse é o achado real deste post, e levamos um tempo para enxergá-lo porque estávamos ocupados procurando dano. O problema na linha telefônica não é que algo está quebrando o seu áudio. É que a coisa que você gostaria de rodar nela nunca foi construída.

O que a matriz ainda omite se vê melhor contra a cadeia real de sinal abaixo, da qual as nossas condições modelam alguns estágios e outros não.

Ninguém na cadeia está do seu lado

Mesmo antes do limite de banda, o sinal já passou por vários estágios de processamento que você não controla e não pode inspecionar.

Estágio	Processamento típico	Classe de artefato que introduz	Modelado hoje?
Aparelho	codificação AMR-WB ou EVS, supressão de ruído do dispositivo, AGC	fala já suprimida, ruído musical, ganho bombeando	Não
Interconexão da operadora	transcodificação para G.711 µ-law ou A-law, G.722, Opus de baixa taxa; downsample para 8 kHz	limite de banda, ruído de quantização de companding	Sim
Tronco SIP	buffer de jitter, ocultação de perda de pacotes, DTX, ruído de conforto	emendas no domínio do tempo, frames repetidos, piso de ruído sintético	Sim — perda em rajadas de dois estados a 3% e 10%
Caminho de eco	retorno, por híbrida ou viva-voz, do próprio TTS do agente	inserções fluentes e confiantes	Não — a maior lacuna restante
Sua stack	reamostragem para 16 kHz, muitas vezes um segundo passe de supressão	banda superior vazia, supressão em cascata	Em parte

As linhas de operadora e de perda de pacotes passaram de "Não" para "Sim" nesta atualização, e cada uma merece uma nota.

Ocultação de perda de pacotes não é silêncio. Quando um pacote se perde, o buffer de jitter sintetiza um substituto a partir dos frames anteriores: uma forma de onda plausível, sem conteúdo linguístico nenhum, da qual um reconhecedor vai alegremente decodificar palavras. Essas são inserções que nenhum aprimorador consegue consertar, porque o sinal não está degradado — está fabricado. Modelamos isso como apagamento em rajadas de dois estados (Gilbert-Elliott) de frames de 20 ms com ocultação por repetição atenuada, em vez de perda aleatória independente com preenchimento de silêncio: perda independente lisonjeia qualquer decodificador, e preenchimento de silêncio exagera o dano.

O aparelho já suprimiu. O áudio geralmente é suprimido uma vez no dispositivo antes de você encostar nele, então você está cascateando um segundo supressor neural sobre os artefatos de um primeiro. Ninguém caracterizou isso publicamente, nós incluídos — embora os nossos resultados mostrem que um passe de supressão sobre material que não precisa dele é confiavelmente caro; veja O pipeline dividido.

Eco é a linha que ainda falta, e é a que mais queremos. Eco acústico com distorção não linear de alto-falante é a deficiência por trás da metade deste produto que não se conserta com um patch, e ainda não construímos a condição para ele. Até construirmos — e até o Clearline ser uma linha nessas tabelas contra um controle passthrough autorizado a vencê-lo — medimos a prateleira, não a nossa resposta a ela.

A lacuna de plataforma

Há uma razão estrutural para 8 kHz ser mal atendido: no caminho de maior volume, as grandes plataformas não te dão onde pisar. No momento em que escrevemos, e declarado como a nossa leitura da documentação publicada:

• A integração de tronco SIP do LiveKit expõe apenas o cancelamento de ruído padrão da Krisp — não a variante de cancelamento de vozes de fundo disponível em outros caminhos. A perna de telefonia, aquela com o pior áudio, recebe a menos capaz das duas opções embutidas.
• Na Twilio, não há lugar documentado para interceptar a mídia ao lado do <ConversationRelay> — mas isso é inferência nossa, não declaração deles. O <Connect> é documentado como terminal e o socket do ConversationRelay carrega apenas JSON, então a Twilio precisa terminar e reoriginar a mídia. A Twilio não diz que o <Stream> é incompatível, e também não diz que funciona; um grep na referência do <Connect>, na visão geral do ConversationRelay e nas páginas de onboarding não retorna texto nenhum em nenhuma das direções. Afirmamos isso como fato antes de checar, o que foi errado da nossa parte. Isso se resolve com um telefonema, e nós não o fizemos.
• O próprio representante da ai-coustics orienta clientes de telefonia para longe dos modelos de 8 kHz deles, em direção ao de 16 kHz. Lemos isso como uma resposta de engenharia franca, não como um deslize: os modelos de banda estreita não são onde está a qualidade deles.
• Todo modelo de isolamento de locutor no mercado é 16 kHz. A ai-coustics entrega pesos de 8 kHz para o aprimorador geral e para o modelo de escuta humana, mas toda variante Voice Focus e o VAD de locutor primário deles são somente 16 kHz. A entrada de telefonia da Krisp é uma variante posicionada como mais leve que a linha principal. Telefonia é exatamente onde locutores concorrentes estão no seu pior — os salões de contact center, viva-vozes, uma televisão ao fundo — e é o único lugar onde os modelos de isolamento não rodam.
• O DNS Challenge — a principal série de benchmarks de remoção de ruído da área, contra a qual a maioria dos removedores de ruído publicados é ajustada — nunca teve uma trilha de banda estreita. Se o benchmark que define o estado da arte nunca pontuou 8 kHz, o estado da arte nunca foi otimizado para 8 kHz. As nossas linhas de telefonia são o que essa omissão parece vista do lado de quem recebe.

Se qualquer uma dessas leituras estiver errada, ou mudar, corrigiremos este post e anotaremos a data. Já fizemos isso uma vez, lá no topo.

A consequência é que a decisão de qualidade de áudio no seu canal de maior receita é tomada no seu lugar, por um componente embutido que você não escolheu e não pode medir. Cancelamento básico de ruído, a esta altura, é de graça em todo lugar — essa não é a coisa escassa. A coisa escassa é um modelo treinado para o canal real, e evidência sobre se ele ajuda no restante do pipeline.

O que o Clearline é, e o que ele tem que provar

Uma coisa com que ele deliberadamente não abre é extensão de largura de banda. Prever a banda ausente de 4 a 8 kHz é possível, mas é generativo: não recupera o /s/ de quem ligou, sintetiza um plausível. Isso é um ganho real para um ouvinte e um número grande de PESQ, e para um reconhecedor é uma nova maneira de produzir uma substituição confiante — o erro passa de "irrecuperável" para "confiantemente errado". O mesmo desalinhamento de objetivo de todos os outros lugares, no seu ponto mais largo na banda estreita.

O Clearline é um produto de telefonia, não um removedor de ruído genérico. Três compromissos, ordenados por quanto do argumento cada um carrega:

• Isolamento de locutor primário nativo em 8 kHz. A lacuna que a tabela acima expõe. O modelo roda na taxa de amostragem do canal, e mantém a pessoa ao telefone, em vez da sala atrás dela. Ninguém entrega isso a 8 kHz hoje; essa é toda a razão para construí-lo.
• Supressão de eco residual. Uma híbrida ou um viva-voz vaza o próprio TTS do agente de volta para o reconhecedor como inserções fluentes e confiantes. Isso não é ruído ambiente, e um removedor de ruído não conserta. Também ainda não tem uma condição no nosso benchmark, o que consideramos um buraco maior do que qualquer número neste post.
• Reamostragem correta. Contagem de amostras que entra igual à contagem de amostras que sai, verificado em CI. Estamos rebaixando este deliberadamente. Costumávamos chamá-lo de recurso de produto; o controle no início deste post é a razão pela qual agora o chamamos de higiene. Ele é correto porque correção é barata, não porque te compra acurácia.

Onde o modelo em si está. O Clearline treina com dados limpos de licença através de um pipeline inteiramente nosso, e o trabalho de arquitetura e de corpus está ativo agora mesmo — extração de locutor-alvo em banda estreita é um problema mais difícil do que o caso de banda larga sobre o qual a literatura publicada é escrita, e é precisamente por isso que a prateleira está vazia. O Clearline não aparece em nenhuma tabela deste site até merecer a linha, medido nas mesmas condições e contra o mesmo controle que todo o resto aqui. Essa regra é a razão pela qual as tabelas acima valem a leitura.

O número chega quando o Clearline for uma linha no Null Test, em condições de telefonia que incluam eco, contra um controle passthrough autorizado a vencê-lo — um controle que, pela evidência acima, atualmente vence tudo. Se ele não superar esse controle, isso também é publicado. Qualquer outra coisa torna o resto dos números deste site sem valor, e eles é que são o ativo real aqui.

Também em aberto: quanto da WER de banda estreita é artefato de codec versus limite de banda, se a extensão de largura de banda é positiva no líquido para a WER, e se reconhecedores de streaming degradam de forma diferente dos de lote em um canal de banda estreita.

Para onde ir agora

Se você opera tráfego telefônico, o primeiro passo não é comprar nada. Meça o seu próprio caminho de 8 kHz contra um controle passthrough e leia a decomposição dos erros, não o agregado. Inserções agrupadas em torno de silêncio geralmente significam ocultação de perda de pacotes ou retorno de eco. Substituições em sibilantes e dígitos significam o limite de banda. Deleções de palavras funcionais curtas significam que algo rio acima já está suprimindo forte demais.

O harness está aberto em github.com/anecho e a matriz completa — incluindo cada célula em que perdemos — está em /benchmark. Testar o Clearline no seu próprio áudio exige uma chave de API, não uma reunião de vendas: /docs.