Sumário do artigo
- 1. Por que estimar tempo de pronúncia de números?
- 2. O problema, formalizado
- 3. Política R1 — a gramática do extenso em português
- 4. Contagem em O(log N) — onde a matemática começa a brilhar
- 5. Microduração por sílaba — o modelo lognormal
- 6. Pausas prosódicas — a parte que dá realismo à estimativa
- 7. Juntando tudo — esperança, variância e intervalo de confiança
- 8. Validação — como ter certeza de que está certo
- 9. O que o PTEF não é — e isso também é importante
- 10. Open Science, na prática
- 11. O que esse projeto representa para o DataDriks
- 12. Próximos passos
- Exemplo em Python
- Exemplo em R
- Como citar
- 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:
- A duração das sílabas pronunciadas.
- 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:
- Pausas fracas — entre conectivos
"e". Probabilidade ~0,3, duração ~0,1s. - Pausas fortes — após
"mil","milhão","milhões". Probabilidade ~0,1, duração ~0,3s. - 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_structuralEsse é 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:
- Contagem direta: itera 1 → N, gera o extenso, conta tokens e sílabas. Lento, mas inequívoco.
- Contagem rápida (O(log N)): usa decomposição em blocos.
- 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
Nsempre 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.mdno 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:
- Defina o problema antes do estimulante — antes de "qual algoritmo usar", o que é exatamente o que queremos medir.
- Modele com humildade — assuma premissas explícitas, documente limites, deixe o modelo refutável.
- 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
ptefno 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.
Links de referência
- Repositório: github.com/MagnaSoluto/PTEF
- Publicação Zenodo (DOI): doi.org/10.5281/zenodo.17090324
- Documentação técnica: github.com/MagnaSoluto/PTEF/tree/main/docs
- Artigo no LinkedIn: linkedin.com/pulse/publica%C3%A7%C3%A3o-cient%C3%ADfica-ptef
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.