Sumário do artigo
  1. 1. Por que estimar tempo de pronúncia de números?
  2. 2. O problema, formalizado
  3. 3. Política R1 — a gramática do extenso em português
  4. 4. Contagem em O(log N) — onde a matemática começa a brilhar
  5. 5. Microduração por sílaba — o modelo lognormal
  6. 6. Pausas prosódicas — a parte que dá realismo à estimativa
  7. 7. Juntando tudo — esperança, variância e intervalo de confiança
  8. 8. Validação — como ter certeza de que está certo
  9. 9. O que o PTEF não é — e isso também é importante
  10. 10. Open Science, na prática
  11. 11. O que esse projeto representa para o DataDriks
  12. 12. Próximos passos
  13. Exemplo em Python
  14. Exemplo em R
  15. Como citar
  16. Links de referência

TL;DR — O PTEF (Pronunciation-Time Estimation Framework) é um framework probabilístico que estima o tempo necessário para pronunciar sequências numéricas em português brasileiro. Combina geração gramatical de texto por extenso, contagem combinatória O(log N) de tokens e sílabas, modelo lognormal de microduração e pausas prosódicas estruturadas. Tudo aberto: GitHub, Zenodo (DOI) e implementações de referência em Python e R.

Tem algumas perguntas que parecem inocentes — até você tentar respondê-las direito. Uma delas é:

"Quanto tempo demora para um falante brasileiro pronunciar todos os números de 1 a N?"

Parece bobagem. Não é. Por trás dessa pergunta tem fonética, prosódia, gramática de extenso, combinatória e estatística. Tem decisão de design em sistemas de TTS (Text-to-Speech), tem acessibilidade, tem linguística forense, tem pesquisa em fala. E tem, principalmente, uma boa desculpa para fazer ciência aberta, reprodutível e útil.

Foi isso que motivou o PTEF — Pronunciation-Time Estimation Framework: um estudo aberto que reúne linguística computacional, matemática aplicada e engenharia de software num pacote testável, documentado e pronto para ser usado, criticado e estendido pela comunidade.

Este artigo é um passeio pelo PTEF: o porquê, o como, e os detalhes técnicos que fazem a coisa funcionar. Se você quiser pular direto para o código, são dois cliques: github.com/MagnaSoluto/PTEF. Se quiser a publicação científica com DOI, está aqui: zenodo.org/records/17090324.


1. Por que estimar tempo de pronúncia de números?

Estimar o tempo de fala de um trecho qualquer é uma necessidade real em vários cenários:

  • TTS / Síntese de fala: para dimensionar áudios, encaixar fala em janelas temporais (URA, leitura de e-mails, GPS, assistentes), e ajustar prosódia sem precisar sintetizar tudo só para saber a duração.
  • Acessibilidade: leitores de tela e dispositivos assistivos precisam estimar quanto tempo um conteúdo numérico vai consumir para decidir cortes, atalhos e leituras alternativas.
  • Linguística forense: comparar tempos esperados com tempos observados em um material auditado.
  • Pesquisa em prosódia: estudar como conectivos, pausas e estrutura silábica afetam a duração total.
  • Design de produto: estimar o tempo de uma chamada automática que precisa ditar valores, contas, datas, códigos.

Em todos esses casos você não quer pagar o custo de chamar um motor TTS real para estimar duração. Quer um modelo fechado, rápido, com incerteza explícita. É exatamente isso que o PTEF entrega.

No PTEF, duração não é um número solto. É uma variável aleatória, com esperança, variância e intervalo de confiança.


2. O problema, formalizado

Dado um inteiro N, considere a leitura, por extenso e em ordem, de todos os números de 1 até N:

um, dois, três, quatro, cinco, ..., mil e um, ..., dois mil e duzentos e trinta e quatro, ...

O tempo total de pronúncia T(N) é a soma de:

  1. A duração das sílabas pronunciadas.
  2. A duração das pausas prosódicas (entre conectivos, marcadores como mil/milhão, e pausas estruturais).

Formalmente:

E[T(N)] = E[T_syllables(N)] + E[T_pauses(N)]
Var[T(N)] = Var[T_syllables(N)] + Var[T_pauses(N)]

O desafio interessante é: como calcular cada componente de forma exata, rápida e escalável, sem iterar de 1 até N quando N for grande (digamos, bilhões)?

A resposta passa por três ingredientes: gramática, combinatória e probabilidade.


3. Política R1 — a gramática do extenso em português

A primeira coisa que o PTEF faz é converter números em palavras seguindo regras estáveis. Essa camada chama-se política gramatical — atualmente o framework implementa a política R1, que segue o padrão do português brasileiro:

  • 1–19: palavras específicas (um, dois, ..., dezenove).
  • 20–99: dezena +e+ unidade (vinte e um, trinta e dois...).
  • 100–999: centena +e+ resto (cento e um, duzentos e trinta...).
  • 1.000–999.999: milhar +e+ resto (mil e um, dois mil, cinco mil e quinhentos...).
  • 1.000.000+: milhão/milhões +e+ resto (um milhão, dois milhões, três milhões e quinhentos...).

O conectivo "e" entra em pontos previsíveis (entre dezena e unidade, centena e resto, milhar e resto, milhão e resto), e isso é importante porque conectivos viram pausas curtas mais à frente.

Decisão consciente: a política R1 não é "a única forma de falar". É um padrão claro, auditável e suficientemente representativo para servir de baseline. Outras políticas (R2, R3...) podem ser adicionadas sem reescrever o framework.


4. Contagem em O(log N) — onde a matemática começa a brilhar

Se você quiser saber quantas sílabas existem ao falar de 1 a N, a abordagem ingênua é iterar de 1 até N, gerar o extenso, contar sílabas e somar. Isso funciona para N = 1.000. Não funciona para N = 10⁹.

O PTEF resolve isso decompondo a contagem em blocos:

  • Bloco base (1–999): contagem direta de todos os tokens e sílabas. Feita uma vez.
  • Blocos de milhares: replicação do bloco base + adição do token "mil".
  • Blocos de milhões: replicação dos blocos anteriores + token "milhão" ou "milhões".
  • E assim por diante.

Com essa decomposição:

  • Complexidade de tempo: O(log N) para contagem de tokens.
  • Complexidade de espaço: O(1) para os acumuladores.
  • Precisão: exata — não é aproximação, é a contagem combinatória correta.
import ptef result = ptef.estimate(N=1_000_000, policy="R1", B=16, return_ci=True)
print(result["details"]["total_syllables"])

A função estimate devolve não só a contagem, mas o tempo esperado, sua variância e o intervalo de confiança 95%. Em milissegundos. Para qualquer N razoável.


5. Microduração por sílaba — o modelo lognormal

Para transformar número de sílabas em duração, o PTEF usa um modelo simples, justificável e bem documentado na literatura de fala: a distribuição lognormal para a duração de cada sílaba.

log(T_syllable) ~ Normal(μ, σ²)

Os parâmetros padrão são:

  • μ ≈ 0,15 — média do log da duração.
  • σ ≈ 0,3 — desvio padrão do log da duração.
  • speaker_effect ≈ 1,0 — multiplicador para acomodar falantes diferentes.
  • fatigue_coeff ≈ 0,0 — coeficiente linear de fadiga conforme a sequência fica longa.

A esperança e a variância da duração de uma sílaba ficam:

E[T_syllable] = exp(μ + σ²/2) × speaker_effect
Var[T_syllable] = exp(2μ + σ²) × (exp(σ²) − 1) × speaker_effect²

E a duração total esperada para n sílabas, considerando fadiga:

E[T_total] = n × E[T_syllable] × (1 + fatigue_coeff × n)
Var[T_total] = n × Var[T_syllable]

O modelo é deliberadamente parcimonioso. Não é a verdade absoluta sobre fala humana, é uma aproximação útil, com parâmetros que você pode reestimar a partir de dados reais. A decisão de design é manter o framework simples, transparente e calibrável.


6. Pausas prosódicas — a parte que dá realismo à estimativa

Falar números não é uma corrente uniforme de sílabas. Tem pausas. E essas pausas pesam no tempo total.

O PTEF modela três tipos:

  1. Pausas fracas — entre conectivos "e". Probabilidade ~0,3, duração ~0,1s.
  2. Pausas fortes — após "mil", "milhão", "milhões". Probabilidade ~0,1, duração ~0,3s.
  3. Pausas estruturais — função do tamanho do bloco B (parâmetro), simulando respirações e quebras prosódicas. Probabilidade ~0,5, duração ~0,2s.

As contagens são calculadas combinatorialmente — você sabe exatamente quantos "e", "mil" e "milhão" aparecem entre 1 e N — e então transformadas em duração esperada:

count_weak = count("e") × p_weak
count_strong = (count("mil") + count("milhão") + count("milhões")) × p_strong
count_structural = (total_tokens / B − 1) × p_structural

Esse é o tipo de detalhe que faz a diferença entre "uma estimativa razoável" e "uma estimativa fiel ao comportamento do falante".


7. Juntando tudo — esperança, variância e intervalo de confiança

O tempo final é uma soma de variáveis aleatórias e o PTEF entrega tudo de forma explícita:

E[T_total] = E[T_syllables] + E[T_pauses]
Var[T_total] = Var[T_syllables] + Var[T_pauses] CI_95% = E[T_total] ± 1,96 × √Var[T_total]

Ou seja: você não recebe só "vai levar tantos segundos". Você recebe um intervalo de confiança calibrado — coisa rara em estimativas de produto.

Exemplo em Python

import ptef result = ptef.estimate(N=1000, policy="R1", B=16, return_ci=True) print(f"Tempo esperado: {result['mean']:.3f} s")
print(f"IC 95%: [{result['ci95']['lower']:.3f}, {result['ci95']['upper']:.3f}] s")
print(f"Total de sílabas: {result['details']['total_syllables']}")

Exemplo em R

library(ptef) result <- estimate(N = 1000, policy = "R1", B = 16, return_ci = TRUE) cat("Tempo esperado:", round(result$mean, 3), "s\n")
cat("IC 95%: [", round(result$ci95$lower, 3), ", ", round(result$ci95$upper, 3), "] s\n")

A mesma matemática, dois ecossistemas. Para quem trabalha com fala, NLP e dados, isso é mais do que conveniência — é portabilidade científica.


8. Validação — como ter certeza de que está certo

Pode parecer contraintuitivo, mas a parte mais difícil de um framework analítico não é fazê-lo funcionar para N = 10⁹. É garantir que para N pequeno ele bate, sílaba por sílaba, com a contagem direta.

O PTEF faz isso de propósito:

  1. Contagem direta: itera 1 → N, gera o extenso, conta tokens e sílabas. Lento, mas inequívoco.
  2. Contagem rápida (O(log N)): usa decomposição em blocos.
  3. Cruzamento: para todo N ≤ 1000, as duas contagens têm que ser idênticas.

Além disso há testes de:

  • Consistência temporal — o mesmo N sempre devolve o mesmo resultado.
  • Consistência de léxico — todo token gerado existe no léxico do PB.
  • Consistência combinatória — algoritmo rápido === contagem direta, em todos os blocos pequenos.

É essa disciplina que separa "um script bacana" de software científico.


9. O que o PTEF não é — e isso também é importante

Boa engenharia científica passa por reconhecer limites. O PTEF é claro sobre o seu escopo atual:

  • Política única: hoje só R1; R2, R3 etc. estão no roadmap.
  • Idioma único: português brasileiro. Espanhol, francês e inglês são extensões plausíveis, mas não estão implementadas.
  • Sílabas independentes: o modelo assume independência, o que é uma simplificação útil mas não absoluta.
  • Pausas com probabilidades fixas: ainda não há um modelo contextual de pausa.
  • Fadiga linear: simples por design; modelagens mais ricas estão na lista.

Esses pontos não são falhas — são escolhas declaradas, com extensões previstas. É assim que ciência aberta avança.


10. Open Science, na prática

Tudo que o PTEF é, é aberto:

  • Repositório: github.com/MagnaSoluto/PTEF — código em Python e R, testes, notebooks, lexicons e workflows de CI.
  • Publicação científica: Zenodo — DOI 10.5281/zenodo.17090324.
  • Documentação: docs/index.md, docs/getting-started.md, docs/methodology.md no próprio repositório, mais o PTEF.pdf com a descrição matemática completa.
  • Licença: MIT, para uso pessoal, acadêmico e comercial.
  • Submissão paralela: o trabalho está sendo encaminhado para o arXiv (cs.CL), reforçando o caráter colaborativo e revisável.

E há também a versão narrativa do estudo no LinkedIn, para quem quer entender a motivação antes de mergulhar no código.

Como citar

@software{ptef2025, title = {PTEF: Pronunciation-Time Estimation Framework for Brazilian Portuguese}, author = {Carvalho dos Santos, Adriano}, year = {2025}, doi = {10.5281/zenodo.17090324}, url = {https://github.com/MagnaSoluto/PTEF}
}

11. O que esse projeto representa para o DataDriks

O DataDriks é um espaço editorial sobre dados com contexto, estratégia e prática. O PTEF é a versão científica dessa ideia: pegar um problema concreto, modelá-lo com rigor, implementá-lo com clareza, validá-lo com disciplina e abrir tudo.

Vale como exemplo de três princípios que tento aplicar em qualquer iniciativa:

  1. Defina o problema antes do estimulante — antes de "qual algoritmo usar", o que é exatamente o que queremos medir.
  2. Modele com humildade — assuma premissas explícitas, documente limites, deixe o modelo refutável.
  3. Publique com responsabilidade — código, dados, fórmulas, testes. Se você é o único que consegue rodar, não é ciência, é mágica.

Dados com contexto, estratégia e prática — também no laboratório.


12. Próximos passos

Algumas frentes onde o PTEF deve evoluir:

  • Mais políticas gramaticais (R2, R3...): variantes regionais, leituras informais, leituras "rápidas" e "completas".
  • Modelos prosódicos contextuais: pausa dependente de contexto, não só de marcador.
  • Validação com TTS reais e datasets de fala etiquetados em português.
  • Pacote ptef no PyPI/CRAN com versionamento estável.
  • Interface web para demonstração interativa do framework.
  • Outros idiomas: começando pelos vizinhos próximos do português brasileiro.

Tudo isso passa por colaboração. Se você trabalha com NLP, fala, TTS, linguística computacional, acessibilidade ou ciência de dados aplicada à linguagem, o convite é direto: leia, teste, abra um issue, mande um PR.


Ciência aberta, feita no Brasil, para a comunidade global.

Antes de ir

Este artigo foi útil?

Curta para registrar e compartilhe com quem precisa tomar decisão com dados.

Continue lendo

Artigos relacionados

Ciência de Dados
Da prancheta ao xG na tela: como os dados do futebol evoluíram — e dá para prever os jogos?
15 min
Inteligência Artificial
O Dia em Que os Criadores da IA Pediram Para Frear a Própria IA
19 min
Inteligência Artificial
O "pensamento" da IA que você lê não é o que ela está fazendo
13 min