Tempos de intervalos conflitantes
gicraveiro opened this issue · comments
Olá, Cássio! Tudo bem?
Com o processamento de mais alguns pares de arquivos de texto e áudio, encontrei um erro em que o textgrid gerado pelo UFPAlign contém casos em que o tempo de fim do último fonema de uma palavra é diferente do tempo de fim da palavra nas diferentes camadas. Também ocorreram casos de sobreposição dos tempos (em que o tempo de fim de um intervalo era maior que o tempo de início do próximo).
Achei que valia a pena criar a issue reportando o erro caso você queira e possa procurar uma solução. Para a minha aplicação, acabei percorrendo o textgrid resultante, padronizando os tempos para conseguir rodar sem erro de leitura do textgrid. Seguem imagens para exemplificar:
Também anexei o txt desse exemplo mas o formato do áudio não é suportado então posso enviar por e-mail se achar útil. Salvei o textgrid resultante como txt também par anexá-lo aqui.
SP_DID_242_clipped_4.txt
DID_242_clipped_4.txt
Muito obrigada pela disposição e pelo excelente trabalho com o UFPAlign!
Oi,
Acho que consegui reproduzir (nao exatamente, como podes ver pelos indices dos tokens no snippet do textgrid, mas os timestamps sao os mesmos) teu exemplo com o comando a seguir:
$ KALDI_ROOT=$HOME/work/tools/kaldi-asr/kaldi \
bash ufpalign.sh \
--beam 20 --retry-beam 120 --no-syllphones true \
/tmp/SP_DID_242_clipped_4.wav /tmp/SP_DID_242_clipped_4.txt monoTextGrid snippet
$ head -n 37931 ~/work/tools/kaldi-asr/kaldi/egs/UFPAlign/s5/data/tg/DID_242_clipped_4.TextGrid | tail -n 8 intervals[1639]
xmin = 754.02
xmax = 754.33
text = "aquela"
intervals[1640]
xmin = 754.33
xmax = 754.58
text = "coisa"
$ head -n 29209 ~/work/tools/kaldi-asr/kaldi/egs/UFPAlign/s5/data/tg/DID_242_clipped_4.TextGrid | tail -n 40 intervals[7290]
xmin = 754.03
xmax = 754.10
text = "a"
intervals[7291]
xmin = 754.10
xmax = 754.16
text = "k"
intervals[7292]
xmin = 754.16
xmax = 754.19
text = "E"
intervals[7293]
xmin = 754.19
xmax = 754.24
text = "l"
intervals[7294]
xmin = 754.24
xmax = 754.34
text = "a"
intervals[7295]
xmin = 754.34
xmax = 754.38
text = "k"
intervals[7296]
xmin = 754.38
xmax = 754.45
text = "o"
intervals[7297]
xmin = 754.45
xmax = 754.48
text = "j"
intervals[7298]
xmin = 754.48
xmax = 754.52
text = "z"
intervals[7299]
xmin = 754.52
xmax = 754.59
text = "a"
Olhando a saida do Kaldi, parece que temos um probleminha de precisao nos floats que representam os timestamps dos grafemas e dos fonemas. O primeiro tem duas casas decimais e o segundo, tres. Algum dos scripts deve chamar o round() no Python e o mismatch ocorre. Nao cheguei a olhar, mas acredito que o offset seja de 0.01 para todos os casos.
$ egrep '754.3[34]' -B1 ~/work/tools/kaldi-asr/kaldi/egs/UFPAlign/s5/data/ctm_tmp/ctm
SP_DID_242_clipped_4 1 754.020 0.310 aquela
SP_DID_242_clipped_4 1 754.330 0.250 coisa$ egrep '754.3[34]' -B5 -A5 ~/work/tools/kaldi-asr/kaldi/egs/UFPAlign/s5/data/alignme_ali/ali.1.ctm | \
python3 utils/int2sym.py --symtab /opt/UFPAlign/mono/phones.txt
SP_DID_242_clipped_4 1 754.026 0.070 11 -> a_B
SP_DID_242_clipped_4 1 754.096 0.060 73 -> k_I
SP_DID_242_clipped_4 1 754.156 0.030 41 -> E_I
SP_DID_242_clipped_4 1 754.186 0.050 77 -> l_I
SP_DID_242_clipped_4 1 754.236 0.100 12 -> a_E *
SP_DID_242_clipped_4 1 754.336 0.040 71 -> k_B *
SP_DID_242_clipped_4 1 754.376 0.070 93 -> o_I
SP_DID_242_clipped_4 1 754.446 0.030 61 -> j_I
SP_DID_242_clipped_4 1 754.476 0.040 157 -> z_I
SP_DID_242_clipped_4 1 754.516 0.070 12 -> a_E
SP_DID_242_clipped_4 1 754.586 0.050 111 -> R_BObrigado pelo debug inicial, ja me salvou um bom tempo por nao ter que procurar onde estava o erro :)
padronizando os tempos para conseguir rodar sem erro de leitura do textgrid
O problema de mismatch nos timestamps gera erro de leitura no Praat, seria isso? Pelo que entendi, precisas que haja um match exato no comeco e final de cada grafema em diferentes tiers.
Se for o caso, posso escrever um script de pos-processamento que assegura essa condicao, o que resolveria a issue de maneira mais pratica e rapida. Enquanto isso, tento descobrir se consigo ajustar a precisao dos floats que o Kaldi me retorna. Tentei olhar por alto, mas nao tenho certeza se tenho controle sobre, e deve me consumir mais tempo.
Também ocorreram casos de sobreposição dos tempos (em que o tempo de fim de um intervalo era maior que o tempo de início do próximo)
Isso tambem quebra tua aplicacao, certo? Ainda nao achei um exemplo pratico nesse textgrid, mas acredito que a fonte seja tambem o mesmo mismatch de 10ms causado pela precisao em diferentes tiers, e isso tambem deve ser tratavel no mesmo script de pos-processamento que mencionei acima.
Oi,
Se puderes testar a versao do branch https://github.com/falabrasil/ufpalign/tree/bugfix/16_word_phone_timestamp, agradeceria. Acredito que funcione sem precisares mais percorrer e padronizar os tempos manualmente no textgrid.
Aqui, os valores ja aparecem sem o mismatch de 0.01s.
$ egrep -n '754.3[2345]' ~/work/tools/kaldi-asr/kaldi/egs/UFPAlign/s5/data/tg/DID_242_clipped_4.TextGrid
29188: xmax = 754.33
29191: xmin = 754.33
46014: xmax = 754.33
46017: xmin = 754.33
53628: xmax = 754.33
53631: xmin = 754.33Testei a branch e realmente para o caso do timestamp 754.33 parece resolvido!
Porém quando rodei minha aplicação, ela acusou erro por overlap neste outro timestamp:
timestamps 4.81 e 4.8
Obrigado pelo feedback, Giovana.
Se puderes testar de novo, acabei de fazer push de um hot fix pro mesmo branch. Aparentemente, a funcao do ultimo commit que arredonda os floats pra duas casas decimais comecou a causar esses overlaps. Apenas adicionei um
>>> a=4.81
>>> math.floor(a * 100)/100.0
4.8>>> a=4.81 + 1e-5
>>> math.floor(a * 100)/100.0
4.81Fiz um diff antigo vs. novo e a saida parece decente o suficiente. Se ainda tiveres problema, me avisa que testo com mais calma no fim de semana.
Consertado este erro do timestamp 4.81, mas agora há um overlap na camada de fonemas em 276.98, 276.97
Oi Cássio!
Vim aqui para reportar que utilizando a branch nova para gerar o TextGrid de outros inquéritos, tive um problema com o tempo final, que não tive quando gerei o TextGrid usando a main no mesmo inquérito. Ocorreram diferenças da ordem de milésimos em muitos intervalos. O que pensei que pode ter gerado o problema:
-> o tempo de fim do último intervalo de uma camada ficou diferente do tempo de fim indicado para aquela camada, em seu cabeçalho.
-> o tempo de fim do último fonema da última palavra na camada de fonemas ficou diferente do tempo de fim desta palavra na camada de palavras
Particularmente, para a minha aplicação, acredito que o segundo caso seja o causador dos problemas devido à uma comparação específica que faço com tempos de fim de fonemas e palavras.
De toda forma, queria pedir para não dar merge deste bugfix na main ainda, por favor. Obrigada!
Na imagem, o arquivo gerado com a branch main está à esquerda e o arquivo gerado com a branch bugfix/16_word_phone_timestamp está à direita:
Oi,
Sumi porque tudo que tentei nao funcionou, hehe. Fica tranquila que nao vou dar merge ainda, so preciso de mais tempo pra debugar. Pelo que entendi, os commits do novo branch pioraram em relacao a versao do main, certo? Provavelmente vou reverter tudo e comecar de novo (#12).
Em tempo, estas dependendo desse fix pra avancar no teu projeto ou ja conseguiste usar os textgrids na tua aplicacao depois de consertar os timestamps manualmente?
Oi @gicraveiro ,
Podes testar de novo a versao do branch, por favor? Refatorei o ctm2tg.py do zero e aparentemente a lib que mencionaste esta carregando o textgrid que e' gerado:
import tgt
tg = tgt.io.read_textgrid(sys.argv[1])SP_DID_242_clipped_4.TextGrid.txt
cmd:
KALDI_ROOT=$HOME/work/tools/kaldi-asr/kaldi \
bash ufpalign.sh --beam 20 --retry-beam 120 --no-syllphones true \
SP_DID_242_clipped_4.wav SP_DID_242_clipped_4.txt mono
Um ponto de atencao e' que estou usando mais libs externas como pandas e textgrid, as quais devem ser instaladas pelo requirements.txt.
Note to self
Eu acredito que resolvi o problema de mismatch within-tiers manipulando a precisao dos floats dos timestamps, o que parece ser suficiente para carregar o textgrid tanto com a TextGridTools quanto com a texgrid. Porem olhando rapido ainda ha diferenca entre diferentes tiers. O Kaldi nao tem ajudado muito nisso, pois os boundaries dos fones e das palavras sao gerados por dois scripts diferentes (apesar de virem da mesma lattice), e algumas vezes o arredondamento das casas decimais nao e decidido pelo round().
E.g.,:
No caso da palavra "acho", houve um floor forcado de uma casa decimal:
- 781.267 -> 781.260
ao inves de
- 781.267 -> 781.270
Ja no caso da palavra "papa", a regra do round foi seguida ao chamar o ceil:
- 506.387 -> 506.390
SP_DID_242_clipped_4 1 781.267 0.110 a_B
SP_DID_242_clipped_4 1 781.377 0.120 S_I
SP_DID_242_clipped_4 1 781.497 0.030 u_E
SP_DID_242_clipped_4 1 781.260 0.260 acho
SP_DID_242_clipped_4 1 506.387 0.050 p_B
SP_DID_242_clipped_4 1 506.437 0.300 a_I
SP_DID_242_clipped_4 1 506.737 0.050 p_I
SP_DID_242_clipped_4 1 506.787 0.040 a_E
SP_DID_242_clipped_4 1 506.390 0.440 papa
Apparently the last PR from #18 fixes this, and TextGrid lib can now load the output fille successfully. This is so thanks to the function compute_eos_and_ensure_causality which checks current and previous phones' timestamps and fixes inconsistencies.
This issue is 3 months old and will be closed but feel free to re-open if needed.