Software Usando Reconhecimento e Síntese de Voz: O Estado da Arte para o Português Brasileiro

Transcrição

1 Software Usando Reconhecimento e Síntese de Voz: O Estado da Arte para o Português Brasileiro Nelson Neto Universidade Federal do Pará UFPA Rua Augusto Correa, Belém, PA, Brasil neto@canal13.com.br Ênio Silva Universidade Federal do Pará UFPA Rua Augusto Correa, Belém, PA, Brasil enio84@yahoo.com.br Erick Sousa Universidade Federal do Pará UFPA Rua Augusto Correa, Belém, PA, Brasil erochasousa@yahoo.com.br ABSTRACT Speech is a natural interface for human-computer interaction. Speech (or voice) technology is a well-developed field when one considers the international community. There is a wide variety of academic and industrial software. The majority of them assumes a recognizer or synthesizer is available, and can be programmed through an API. In contrast, there are few resources in public domain for Brazilian Portuguese. This work discusses some of these issues and compares SAPI and JSAPI, which are APIs promoted by Microsoft and Sun, respectively. We also present two examples: a tic-tac-toe JSAPI-based game using Portuguese digits recognition and a computer-aided language learning (CALL) application using SAPI-based speech recognition in English and synthesis in Portuguese. 1. INTRODUÇÃO A tecnologia de voz possui grande potencial para a criação de aplicativos que possibilitem uma eficaz interação humanocomputador, especialmente no atual contexto de acelerada miniaturização dos sistemas embarcados. Dentre os ramos dessa tecnologia, o reconhecimento e a síntese de voz são os abordados no presente trabalho. Resumidamente, dado um texto (em ASCII, por exemplo), a síntese de voz é o processo de geração de amostras de um sinal digital que deveria soar como se um humano tivesse dito o texto. A síntese de voz (ou TTS, de text-to-speech) não deve ser confundida com a simples digitalização, armazenagem e posterior playback de voz. O reconhecimento de voz (ou ASR, de automatic speech recognition) pode ser visto como o processo inverso, onde o sistema converte voz digitalizada em texto. Dependendo da aplicação, o resultado obtido pelo ASR pode ser repassado para módulos como o de gerenciamento de diálogos, tutores inteligentes, processamento de linguagem natural (PLN) e outros. A tecnologia de processamento de fala (ou voz) encontrase bastante avançada e, em escala mundial, existe vasta disponibilidade de software tanto acadêmico quanto comercial. A maioria dos mesmos assume a disponibilidade de um reconhecedor e/ou sintetizador, conhecidos genericamente na literatura como engines, os quais podem ser programados via uma API. Ao contrário do que acontece para a língua inglesa, por exemplo, não existem atualmente reconhecedores ou sintetizadores de domínio público para o português brasileiro (PB). Essa situação obviamente retarda a disseminação de uma tecnologia dentre os desenvolvedores brasileiros, a qual, segundo estudo feito em 2003 pela Allied Business Intelligence, correspondeu a um mercado de U$677 milhões em 2002, e projetado para U$5,3 bilhões em Uma das aplicações de maior interesse é a relacionada à telefonia, call-centers e similares. No Brasil, grupos como o LINSE (UFSC) e LPDS (UNI- CAMP) detém amplo know-how no desenvolvimento de sistemas TTS e ASR. 1 Outro exemplo é o Instituto Genius, situado em Manaus, o qual disponibiliza tecnologia ASR para aplicações como encaminhamento de ligações telefônicas (auto-attendant) e outras que usem gramática do tipo CFG, a serem discutidas adiante, tais como as baseadas em reconhecimento de palavras isoladas para automação doméstica. Contudo, principalmente por falta de financiamento, não vigoram atualmente esforços para a criação de engines para o PB visando sua disponibilização gratuita para toda a comunidade acadêmica. Um parágrafo extraído de [15], publicado no Simpósio Brasileiro de Computação (SBC) de 2004, ilustra claramente a situação dos pesquisadores nacionais, que são obrigados a usar engines para a língua inglesa: Outros pontos interessantes de serem abordados em trabalhos futuros são: acrescentar ao sistema novos idiomas para a síntese da voz, principalmente o português; e a alternativa de operar com vozes capturadas. Esse último ponto exigirá, no entanto, a integração com ferramentas de reconhecimento de voz.... Na Seção 2, esse trabalho apresenta uma breve revisão das tecnologias TTS e ASR, identificando os esforços para o su- 1 O desenvolvimento desses trabalhos pode ser acompanhado pelas publicações no workshop TIL do SBC e no Simpósio Brasileiro de Telecomunicações (SBT), os quais são atualmente os principais veículos de divulgação da ciência nacional nessa área. CLIHC'05, October 23-26, 2005, Cuernavaca, México. Copyright is held by the author(s). ACM

2 porte ao PB. A Seção 3 compara as relevantes APIs SAPI e JSAPI, promovidas pela Microsoft e Sun, respectivamente. A Seção 4 trata da utilização do software livre Sphinx-4 para a criação de um modelo acústico para o PB com JSAPI, enquanto a Seção 5 concentra-se na SAPI, a mais difundida das duas. Na Seção 6 aborda-se a construção de um aplicativo CALL (computer-assisted language learning) para o ensino da língua inglesa, no qual é usado ASR e TTS em inglês (baseado em SAPI) e TTS em português. 2. ESTADO DA ARTE EM ASR E TTS Nessa seção discute-se ASR e posteriormente TTS. No estado da arte em ASR, o complexo processo de decodificação do sinal realizado pela mente humana é imitado pelo computador com base em modelos probabilísticos. Atualmente, a grande maioria dos sistemas para voz contínua e grandes vocabulários (LVCSR, de large-vocabulary continuous speech recognition) é baseada em cadeias escondidas de Markov (HMMs, de hidden Markov models) [8]. Esses sistemas usam um front end para converter o sinal de voz digitalizado em uma matriz X de parâmetros, e buscam a seqüência de palavras W que maximiza a probabilidade condicional Ŵ = arg max P (W X). W Na prática, usa-se a regra de Bayes para implementar a busca através de: Ŵ = arg max W P (X W )P (W ) P (X) = arg max P (X W )P (W ) W com P (X) sendo desprezado pois não depende de W. Para cada W, os valores de P (X W ) e P (W ) são fornecidos pelos modelos acústico e de linguagem (ou língua [13]), respectivamente. O modelo de linguagem precisa fornecer a probabilidade conjunta P (W ) da seqüência de palavras W = w 1, w 2,..., w n, a qual pode ser decomposta em: P (W ) = P (w 1, w 2,..., w n) = P (w 1 )P (w 1 w 2 )... P (w n w 1, w 2,..., w n 1 ). Na prática, é inviável estimar robustamente as probabilidades P (w i w 1,...w i 1 ) mesmo para valores moderados de i. A solução típica, chamada modelo N-grama é assumir que P (w i w 1,...w i 1) depende apenas das N 1 prévias palavras. Caso N = 3 tem-se um trigrama P (w i w i 2, w i 1 ), enquanto N = 2 e 1 são chamados bigrama P (w i w i 1 ) e unigrama P (w i), respectivamente. Em um LVCSR com vocabulário em torno de 60 mil palavras, é comum o modelo de linguagem ser composto por algo em torno de 40 milhões de trigramas e 20 milhões de bigramas (e 60 mil unigramas). Em contraste com os modelos N-grama, alguns sistemas ASR utilizam um modelo de linguagem não-probabilístico, baseado em gramáticas livres de contexto (CFG, de contextfree grammars). As CFG são mais apropriadas para implementações similares às de comando-e-controle, enquanto as N-grama são úteis em aplicações de ditado (daí serem chamadas dictation grammars), criação automática de legendas (captioning), e outras onde a perplexidade [8] seja relativamente alta. Além do modelo de linguagem, o léxico é um outro recurso importante. O ASR exige que cada palavra do vocabulário tenha sua correspondente transcrição fonética. Se a inclusão de uma nova palavra é feita off-line, um especialista pode mapeá-la nos alofones [8] correspondentes. O processo online, onde o usuário acrescenta uma palavra a partir apenas de sua ortografia, exige um procedimento relativamente sofisticado conhecido como letter-to-sound ou grapheme-tophoneme [3] (o algoritmo responsável é às vezes chamado phoneticizer [14]). Outros recursos presentes em ASR são o modelo acústico e o front end. Do ponto de vista do programador, os mesmos são menos visíveis, mas projetar um modelo acústico é importante quando se deseja dar suporte a uma nova língua, tal como o português brasileiro. Em termos de TTS, o principal desafio é fazer com que a voz sintetizada soe menos robotizada e mais humana. Dentre os fatores que dificultam atingir esse objetivo, encontra-se a modelagem da prosódia, uma das principais responsáveis para que a voz sintetizada carregue o ritmo e emoção que um ser humano empregaria. O melhor exemplo da evolução da tecnologia TTS é o sistema da AT&T [2], o qual atinge uma voz bastante próxima da natural. Os sistemas TTS evoluíram de um paradigma knowledgebased, onde lingüistas e engenheiros trabalhavam muito mais afinados, para uma pragmática abordagem data-driven. Seguindo essa direção, o back end do TTS, às vezes chamado de sintetizador, por ser o módulo responsável pela geração das amostras do sinal digital, evoluiu da técnica conhecida como síntese por formantes [1] para a concatenativa [5], onde segmentos de voz (representando, por exemplo, difones) são armazenados para posterior concatenação. Uma das técnicas em voga é a utilização de HMMs para o treinamento automático de sistemas TTS [7]. 3. COMPARAÇÃO ENTRE SAPI E JSAPI Existe um grande número de empresas no mercado que apresentam soluções para que um desenvolvedor possa incorporar a tecnologia de voz em seus aplicativos. Empresas como a IBM e Microsoft possuem soluções que adotam padrões como VoiceXML e Salt. A maioria dessas empresas adota uma API (application programming interface) para o desenvolvimento de aplicativos. Esse trabalho se discute duas delas, as quais bem representam as opções disponíveis. A primeira é a SAPI (Speech API ) da Microsoft [16] e a segunda a JSAPI (Java T M Speech API ) da Sun [10]. Ambas permitem o emprego das tecnologias de TTS e ASR. A JSAPI deixa a desejar num ponto de extrema importância em TTS, ao não permitir o redirecionamento das amostras de áudio para arquivos e/ou dispositivos além da saída de áudio padrão. Porém, ambas suportam o uso de gramáticas CFG e de ditado (probabilísticas). A SAPI utiliza-se da XML (Extensible Markup Language) para incluir marcas prosódicas (formatar) o texto a ser sintetizado, ou seja, configurar os parâmetros de síntese de voz como velocidade, afinação, timbre e língua. Já com JSAPI, também é possível trabalhar com esses parâmetros tanto através de invocação de procedimentos e/ou métodos, como pela JSML (Java Synthesis Markup Language). 327

3 A escolha de qual interface utilizar depende de vários aspectos, que vão desde critérios técnicos, como o sistema operacional, a critérios bastante subjetivos, como facilidade de uso. A SAPI utiliza COM (Component Object Model) e por isso pode ser utilizada a partir de qualquer linguagem que suporte COM. Nesse trabalho, utilizamos C#. A JSAPI não é uma interface do estilo COM, logo a linguagem empregada no desenvolvimento do sistema deve ser a mesma utilizada para escrever a JSAPI, no caso Java. A JSAPI sugere que o aplicativo se comunique com o engine a partir de Java Events. Assim, a JSAPI pode ser utilizada em qualquer sistema operacional para o qual exista uma máquina virtual Java. Em contraste, a SAPI é restrita a sistemas operacionais Windows. No que diz respeito a engines, existe uma gama de softwares que suportam SAPI e/ou JSAPI. Esse é um ponto importante, pois permite ao desenvolvedor avaliar a qualidade de engines de fabricantes diferentes e escolher o que melhor se aplica às características do seu sistema. A SAPI é adotada pela maioria das empresas do setor, tais como Dragon, IBM, e Lucent. A JSAPI é bem menos difundida, e uma das exceções é o suporte à parte ASR dessa interface no produto ViaVoice da IBM. A próxima seção concentra-se exclusivamente na JSAPI. 4. JSAPI DA SUN A Java T M speech API é uma especificação que permite aos desenvolvedores incorporarem tecnologia de voz aos seus aplicativos escritos em Java. JSAPI especifica uma interface que independe da plataforma de desenvolvimento e suporta sistemas para ditado, reconhecedores e sintetizadores de voz. Apesar da Sun ter lançado a Versão 1.0 da Java T M speech API em 1998, a mesma não comercializou qualquer tipo de implementação em JSAPI. Em vez disso, ela conta com um grupo de companhias que trabalham com ASR e TTS, entre elas a IBM, para desenvolverem aplicações e serviços baseados na especificação JSAPI. Apesar de não existir referência de implementação por parte da Sun, não necessariamente teremos que trabalhar com softwares comerciais, como o Via Voice, para adicionarmos interface de voz à nossas aplicações. Podemos fazer uso de produtos com código livre, disponibilizados sem custo na Internet. O Sphinx-4 (vide [17]), para reconhecimento de voz, é uma das opções existentes. 4.1 Reconhecimento de voz usando Sphinx 4 O Sphinx-4 é um sistema de reconhecimento de voz do estadoda-arte, sendo open-source e escrito inteiramente na linguagem de programação Java T M. Encontra-se disponível no site e se constitui em uma excelente plataforma para pesquisas em reconhecimento de voz. O Sphinx-4 executa reconhecimento em tempo real ou em batch e é capaz de implementar reconhecimento de voz contínua ou discreta. A instalação do Sphinx-4 requer os softwares adicionais, Java 2 SDK, Standard Edition, v1.4 e Ant 1.6.0, ou versões mais recentes. Sua compilação limitase a configuração de arquivos ANT (XML), o que facilita a utilização de seus diversos componentes. O Sphix 4 apresenta como principais características: flexíveis configurações nas arquiteturas dos frontends, modelos de linguagem, gerenciamento da busca (decoding) onde são inclusos suportes para busca breadth first e word pruning, por exemplo, além de uma flexível arquitetura dos modelos acústicos. A seguir descreve-se a construção de um modelo acústico para reconhecimento de dígitos em Português brasileiro, a ser executado no formato Sphinx-4. Os próximos tópicos são a extração de parâmetros, treinamento e conversão dos modelos. 4.2 Extração de Parâmetros Esta etapa visa a extração de parâmetros que melhor caracterizem a voz, os quais são necessários na fase de treinamento. Utilizou-se o frontend baseado nos parâmetros MFCC (Mel-Frequency Cepstrum Coefficients) que é configurado no arquivo frontend.config.xml conforme estrutura mostrada a seguir. <component name="mfcfrontend" type="edu.cmu.sphinx.frontend.frontend"> <propertylist name="pipeline"> <item>streamdatasource </item> <item>preemphasizer</item> <item>windower</item> <item>dft</item> <item>melfilterbank</item> <item>dct</item> <item>batchcmn</item> <item>featureextractor</item> </propertylist> </component> Para especificar as características das vozes de treino, foram feitas alterações nas propriedades da classe StreamData- Source responsável pela digitalização do áudio original. Foi especificada na entrada do filtro a freqüência de amostragem em amostras por segundo e para compatibilizar os formatos Little Endian dos arquivos wavs originais com o Sphinx-4, que como todo programa em Java processa e cria dados no formato Big Endian por default, foi alterada a propriedade bigendiandata : Para os parâmetros MFCCs extraídos com as classes do Sphinx-4 serem utilizados na fase de estimação dos modelos acústicos foi necessário a conversão dos arquivos para o formato HTK (The Hidden Markov Model Toolkit, vide [6]), um software de reconhecimento de voz escrito em linguagem C que possui amplo suporte para o treinamento de modelos acústicos. 4.3 Modelagem Acústica Treinamento - Estimação dos Modelos HMMs Os modelos acústicos foram baseados em HMMs (Hidden Markov Models), treinados com o software HTK e convertidos para o formato Sphinx-4. É necessário que o treinamento das HMMs seja feito usando o HTK, devido ao Sphinx- 4 não possuir ainda suporte para esta tarefa. Outra solução seria utilizar a versão sphinx-3 trainer, porém seu uso seria tão complexo quanto a utilização do HTK, o qual apresenta 328

4 melhor documentação. Nesta etapa do trabalho, Estimou-se HMMs, onde cada modelo representa um fonema, contendo 5 estados e 10 gaussianas. 4.4 Conversão dos HMMs do Formato HTK para Sphinx Ao término do processo de treinamento, concatenou-se cada HMM em um único arquivo chamado hmms.mlf. Na conversão para o formato Sphinx-4, utilizou-se classes que separaram as HMMs em arquivos de médias, variâncias, peso das misturas e matrizes de transição. O resultado desta conversão preliminar são arquivos ASCII com os dados das HMMs, que posteriormente foram convertidos para o formato Binário Little-Endian acrescentando a cada um deles um cabeçalho específico contendo informações como número de Gaussianas, número de estados, números de parâmetros MFCCs, entre outros. A validação dos arquivos binários é feita através do programa printp disponível no Sphinx-3. Usando o Emacs para executar o gdb, e carregar o arquivo printp encontrou-se os valores corretos dos CHECKSUMs dos arquivos binários, os quais eram necessários nos arquivos finais. 4.5 Criação de um Modelo Acústico JAR no Sphinx-4 Para usar modelos acústicos no Sphinx-4, é necessário empacotá-los em um arquivo JAR. A vantagem de se ter um arquivo JAR é que é possível incluí-lo facilmente no classpath e referenciá-lo em um arquivo de configuração para ser usado em aplicações que utilizem o Sphinx-4. Este possui um script build.xml que contém targets ANT que permitem uma fácil conversão dos modelos acústicos para o arquivo JAR. Neste trabalho foi gerado um Modelo Acústico, para reconhecimento de dígitos em português brasileiro, chamado KEENKE. Um diretório com o mesmo nome do modelo deve ser criado no diretório modelsacoustic do Sphinx-4. Basicamente, para a criação do arquivo JAR, são exigidos os arquivos binários das gaussianas que representam os modelos HMMs, um dicionário fonético, um arquivo contendo targets para inicio e fim de frase, bem como o silencio, um arquivo de definição contendo instruções que relacionam as gaussianas binárias com as suas respectivas HMMs dos fonemas e finalmente um arquivo de propriedades (model.props) contendo informações detalhadas do modelo. No arquivo model.props são especificadas diversas propriedades que correspondem ao processo de extração dos parâmetros MFCCs, detalhes como número de pontos da FFT (Fast Fourier Transform), número de filtros e gaussianas, freqüências máxima e mínima e freqüência de amostragem. Estas propriedades devem ser as mesmas do arquivo de configuração no qual o modelo acústico JAR criado será referenciado. Após recompilação do projeto Sphinx-4, o novo modelo acústico KEENKE 10gau 13dCep 16k 40mel 130Hz 6800Hz.jar é criado e pode ser facilmente implementado a um sistema de reconhecimento de voz. Como exemplo, utilizou-se como aplicação o programa TicTacToe.java desenvolvido por Arthur van Hoff, ao qual foi acrescentado o reconhecimento de dígitos isolados. A grande vantagem do uso de JSAPI e Sphinx-4 é que eles têm uma filosofia voltada para o mercado de software livre. Uma outra alternative, importante do ponto de vista comercial, é a utilização da SAPI da Microsoft, a qual será abordada na próxima seção. 5. SAPI DA MICROSOFT A SAPI provê aos programadores acesso aos serviços fornecidos por um engine de ASR e/ou TTS. A Microsoft disponibiliza gratuitamente na Web o kit de desenvolvimento Speech SDK, atualmente na versão 5.1, com DLL s que suportam objetos OLE (Object Linking and Embedding), característica essencial para que possa ser utilizado por linguagens de programação conhecidas como de alto nível. 5.1 Síntese de Voz usando SAPI De acordo com a SAPI, as aplicações controlam o processo de síntese de voz através do objeto ISpVoice. Depois de criar esse objeto, a aplicação precisa apenas chamar o método ISpVoice::Speak para gerar áudio de saída a partir de um texto ou arquivo de entrada. O método ISpVoice::SetVoice permite que a voz padrão do sistema operacional, a qual é selecionada por características como língua, sexo e idade, seja alterada de acordo com a necessidade e finalidade da aplicação. Adicionalmente, as propriedades do processo de síntese, como volume e velocidade da voz de saída, podem ser modificadas através dos métodos ISpVoice::SetVolume e ISpVoice::SetRate, tal como mostrado a seguir. SpVoice Voice = new SpVoice(); Voice.Volume = 50; Voice.Rate = 5; Voice.Speak("Hello", SpeechVoiceSpeakFlags.SVSFlagsAsync); Voice.Speak("C:/Teste.txt", SpeechVoiceSpeakFlags.SVSFIsFilename); Uma das alternativas para formatar o texto a ser sintetizado é via XML. Pausas, ênfases, características da pronúncia, volume e velocidade, são alguns dos parâmetros que podem ser especificados para uma determinada palavra ou frase, sempre com a finalidade de minimizar a falta de naturalidade da voz sintetizada. 5.2 Reconhecimento de voz usando SAPI Para executar ASR, uma gramática precisa ser definida para que o aplicativo saiba que ação executar quando uma determinada palavra lhe for enviada. Assim como o ISpVoice é a principal interface para a síntese de voz, o ISpRecoContext é a principal interface para o reconhecimento de voz. Através desse objeto a aplicação tem controle do conteúdo do que foi reconhecido e das gramáticas de reconhecimento. Ele também tem o poder de parar e reiniciar o reconhecimento. A SAPI dá suporte a ambas gramáticas CFG (também conhecida como command and control) e a probabilística, ou gramática para ditados (dictation). No código abaixo uma CFG (Grammar) contendo uma regra (Ruleone) foi criada, carregada e ativada. Daí, a regra será acionada toda vez que a palavra boy for reconhecida. 329

5 SpSharedRecoContext RecoContext = new SpSharedRecoContext(); RecoContext.State = SpeechRecoContextState.SRCS_Enabled; ISpeechRecoGrammar Grammar; ISpeechGrammarRule Ruleone; objectpropvalue = ""; Grammar = RecoContext.CreateGrammar(0); Ruleone = Grammar.Rules.Add("regraum", SpeechRuleAttributes.SRATopLevel SpeechRuleAttributes.SRADynamic,1); Ruleone.InitialState.AddWordTransition(null, "boy","",speechgrammarwordtype.sglexical, "boy",0,ref PropValue,0f); Grammar.Rules.Commit(); Grammar.CmdSetRuleState("regraum", SpeechRuleState.SGDSActive); Depois da gramática ser definida, a aplicação precisa saber o que foi reconhecido. Para isso, utiliza-se o evento RecoContext.Recognition. No caso de estarmos utilizando a gramática CFG, podemos identificar qual foi a regra acionada através da interface SpeechPhraseProperty. 5.3 Microsoft Agentes Apesar de não ser parte da SAPI, o Microsoft Agent é uma tecnologia diretamente relacionada, pois permite criar personagens e utilizar animações na interface gráfica de programas, além de associá-las aos mecanismos de fala, proporcionando uma interface muito rica (similar à descrita em [15]). O código abaixo é uma aplicação simples do uso de agentes em uma aplicação SAPI com C#. O agente Merlin é carregado e depois mostrado na tela. As duas últimas linhas proporcionam ações por parte do agente: na primeira ele realiza uma breve saudação e, em seguida, utiliza-se da tecnologia de voz para sintetizar o texto Exercise. AxAgent.Characters.Load("Merlin", (object)"c:/windows/msagent/chars/merlin.acs"); Character = AxAgent.Characters.Character("Merlin") Character.Show(null); Character.Play("announce"); Character.Speak("Exercise",null); 6. EXEMPLO DE APLICAÇÃO: CALL Nessa seção discute-se brevemente um software para aprendizado de língua estrangeira com o auxílio de computador. O mesmo apresenta exercícios para o aluno, que deverá pronunciar a palavra que melhor completa a frase, ou mesmo atividades de ditado. O nível de confiabilidade no reconhecimento da voz pode ser ajustado de acordo com a necessidade. O software utiliza agentes animados para tornar mais alegre a interface, podendo-se não apenas mostrar texto na tela do computador, mas também permitir que o aluno ouça a pronúncia correta de uma palavra ou frase. A Figura 1 mostra uma tela do protótipo que está sendo desenvolvido para o ensino da língua inglesa, em função da maior disponibilidade de engines. A avaliação da interface foi considerada boa nos experimentos realizados. Os usuários relataram que a navegação en- Figure 1: Uma das telas do aplicativo para ensino de língua inglesa. tre os menus é de fácil entendimento e que os comandos de voz requeridos em cada etapa da aplicação são bem claros. Contudo, muitos questionaram o fato do programa não solicitar repetição, ou mesmo informar, quando o comando não é reconhecido. A voz sintetizada pelo engine da Microsoft não foi bem aceita. Para melhorar sua naturalidade e clareza, foram inseridos comandos XML para alterar alguns parâmetros da voz, como rate e pitch, e, com isso, o índice de satisfação cresceu bastante. Utilizando-se os engines disponibilizados pela Microsoft para ASR e TTS, pode-se interagir com o usuário através da língua inglesa. Contudo, levando-se em conta que o usuário é muitas vezes uma criança, é importante se poder usar TTS em língua portuguesa para instruções e feedback. Essa situação é compartilhada com outros projetos em desenvolvimento no Brasil (e.g., [15]). Para o presente trabalho, utiliza-se o software do CSLU [4], o qual incorpora suporte ao PB através da voz AGA. Apesar de relativamente precário, o suporte à TTS em PB do CSLU é bastante útil. Em resumo, o processo de geração da voz AGA foi baseado na síntese por difones, um dos métodos mais populares para criação de voz sintética [12]. O difone é a região entre os centros de dois fones adjacentes. O centro de uma realização fonética é a região mais estável da mesma, enquanto que a transição de um fone para outro contém mais variação (efeitos da co-articulação), o que torna difícil a modelagem. Após a seleção do conjunto de fones, os difones são coletados utilizando palavras que possuam o respectivo difone no meio [9]. A coleta foi feita em uma câmara anecóica, com equipamento de gravação de alta-qualidade e um laringógrafo. O laringógrafo é utilizado para garantir a qualidade da gravação e extrair informação sobre o pitch e pulso glotal. Após a coleta, as palavras foram alinhadas temporalmente com os difones e segmentadas posteriormente. Finalmente, os modelos prosódico e léxico são gerados para produzir uma voz o mais natural possível e lexicamente correta. O toolkit do CSLU é uma plataforma para o desenvolvi- 330

6 mento de aplicativos de diálogos. O software provê quatro níveis de interface para o desenvolvimento de aplicativos. No nível mais baixo, os desenvolvedores podem usar código C para acessar todos os componentes, tais como o engine ASR. Não há, contudo, suporte para uma API genérica como a SAPI ou JSAPI. Apesar de não ser a solução ideal, a seguir discute-se a estratégia utilizada para sintetizar em PB usando CSLU. Uma das diretrizes adotadas, foi buscar uma solução simples, a qual não envolvesse modificações no código do CSLU. Assim, optou-se pela utilização de arquivos batch que invocavam o TTS do CSLU, sob o comando do aplicativo. Os passos adotados foram os seguintes ($cslu é a pasta onde o software CSLU foi instalado). Dentro do diretório $cslu/festival/1.4.2/festival/lib, o aplicativo cria um arquivo com o texto que deseja sintetizar. Nesse exemplo, assume-se que o nome desse arquivo é comandos.txt. O comandos.txt possui o seguinte conteúdo: (voice_aga_diphone) (SayText "ENTRE O TEXTO AQUI") Então, no diretório $cslu/toolkit/2.0/bin, criou-se uma cópia do arquivo Festival.bat (chamada aqui de call.bat ), e sua última linha foi alterada para: $CSLU\Festival\1.4.2\bin\ festival.exe --batch "comandos.txt" Após esses passos, basta ao aplicativo criar um arquivo comandos.txt e invocar o arquivo call.bat. Por exemplo, a partir de um programa C, bastaria a chamada: system("$cslu\\toolkit\\2.0\\bin\\call.bat"); Nota-se que a solução apresentada acima é ineficiente no sentido de que o processo de escrita e leitura em disco é lento. Contudo, o mesmo é simples e pode ser usado em situações onde a velocidade e qualidade do TTS não são críticas. 7. CONCLUSÕES Como atualmente são sistemas data-driven, a síntese e o reconhecimento de voz se beneficiam da disponibilidade de corpora com grande volume de dados. Existe uma quantidade razoável de textos para estudos de modelagem de linguagem para a língua inglesa, português europeu e outras (vide [11]). Todavia, há poucos recursos acessíveis quando se trata do PB. Essa lacuna é ainda maior quando se trata de voz digitalizada para treinamento do modelo acústico e desenvolvimento de TTS. A inexistência de uma grande base de dados não só atrasa as pesquisas em ASR, TTS e áreas correlatas, mas também impede que os resultados obtidos por diferentes grupos de pesquisa sejam comparados diretamente. Nesse trabalho foram descritas algumas atividades no desenvolvimento de ASR para PB, mas a construção de um SAPI-compliant engine ainda demandará mais tempo. O presente trabalho discutiu o estado da arte em ASR e TTS, e também avaliou a utilização da SAPI e JSAPI, que são as APIs da Microsoft e Sun, respectivamente. Abordouse a construção de um modelo acústico para reconhecimento de dígitos em Português brasileiro (baseado em JSAPI) e de um aplicativo para o ensino da língua inglesa, no qual é usado ASR e TTS em inglês (baseado em SAPI) e TTS em português (baseado no toolkit do CSLU). 8. ADDITIONAL AUTHORS Autores adicionais: Maria Fonseca (Universidade Federal do Pará, mneiva@ufpa.br), Alessandra de Sousa (Universidade Federal do Pará, Alessandra.Ewerton@vivo. net.br) e Aldebaro Klautau (Universidade Federal do Pará, aldebaro@deec.ufpa.br). 9. REFERENCES [1] J. Allen, M. S. Hunnicutt, D. H. Klatt, R. C. Armstrong, and D. B. Pisoni. From text to speech: The MITalk system. Cambridge University Press, [2] Visited in March, [3] A. Black, K. Lenzo, and V. Pagel. Issues in building general letter to sound rules. In ESCA Synthesis Workshop, Australia 1998, [4] Visited in March, [5] T. Dutoit. An Introduction to Text-To-Speech Synthesis. Kluwer, [6] [7] Visited in March, [8] X. Huang, A. Acero, and H.-W. Hon. Spoken language processing. Prentice-Hall, [9] S. Isard and D. Miller. Diphone synthesis techniques. In Proceedings of the IEE International Conference on Speech Input/Output, pages 77 82, [10] Visited in March, [11] Visited in March, [12] K. A. Lenzo and A. W. Black. Diphone collection and synthesis. In ICSLP, [13] L. Pessoa, F. Violaro, and P. Barbosa. Modelo de língua baseado em gramática gerativa aplicado ao reconhecimento de fala contínua. In XVII Simpósio Brasileiro de Telecomunicações, pages , [14] Patent EP speech recognizer with lexicon updateable by spelled word input, [15] P. L. Rodrigues, B. Feijó, and L. Velho. Expressive talking heads: uma ferramenta de animação com fala e expressão facial sincronizadas para o desenvolvimento de aplicações interativas. In Proceedings of Webmídia. SBC, [16] Visited in March, [17]