Embed Size (px)
Citation preview
UNIVERSIDADE REGIONAL DO ALTO URUGUAI E DAS MISSÕES
URI – CAMPUS DE SANTO ÂNGELO
DEPARTAMENTO DE ENGENHARIAS E CIÊNCIA DA COMPUTAÇÃO
CURSO DE CIÊNCIA DA COMPUTAÇÃO
MARCELO RUARO
SRM: Framework para Reconhecimento de
Som em Dispositivos Móveis
Trabalho de Graduação.
Prof. M. Sc. Denilson Rodrigues da Silva
Orientador
Santo Ângelo, dezembro de 2010.
UNIVERSIDADE REGIONAL DO ALTO URUGUAI E DAS MISSÕES – URI
Campus de Santo Ângelo
Reitor: Luiz Mario Silveira Spinelli
Pró-Reitor de Ensino: Rosane Vontobel Rodrigues
Diretor Geral: Maurílio Miguel Tiecker
Diretora Acadêmica: Neusa Maria John Scheid
Diretor Administrativo: Gilberto Pacheco
Cordenador do Departamento de Engenharia e Ciência da Computação: Márcio Antonio
Vendrusculo
Cordenador do Curso de Ciência da Computação: Denílson Rodrigues da Silva
AGRADECIMENTOS
Primeiramente quero agradecer aos meus pais Silvio e Marinês Ruaro que são
minhas referências de vida, e juntamente com minha família me ensinaram uma
filosofia de vida a qual me orgulho de seguir, tomando decisões responsáveis, mesmo
nos momento de incerteza. Também quero agradece-los pela compreensão e pelo apoio
durante esta minha jornada na faculdade.
Sou grato a minha namorada pela inacreditável paciência mostrada nas noites de
teste de reconhecimento, sei que ela passou muito sono por causa disso, e é por isso e
por tantos outros motivos que a amo.
Agradeço ao meu orientador e professor Denílson pelas orientações e pelo incentivo
na minha pesquisa, pelas discussões e ensinamentos que certamente guardarei comigo
em minha carreira acadêmica e em minha vida. Também quero agradece-lo por se
dedicar intensamente a suas tarefas profissionais, fazendo com que o curso de Ciência
da Computação se destaque cada vez mais.
Quero agradecer a todos os meus amigos e colegas, pelos intervalos passados
bebendo refrigerante, pelos jogos de futebol, e por todos outros momentos de
descontração que implicitamente contribuíram para a realização deste trabalho.
Também quero agradecer ao Ph.D. Roshan G. Rangel e a Isuru Herath da
Universidade de Peradeniya do Sri Lanka e ao Dr. Adriano Petry do INPE pelo auxilio
no esclarecimento por e-mail de algumas duvidas referente ao processamento digital de
sinal no contexto do reconhecimento de som.
Quero agradecer também ao professor Paulo R. B. Betencourt pelas conversas e
conselhos sobre aviação que me motivaram a iniciar meu curso de piloto privado de
avião. E agradecer a todos os outros professores do Curso de Ciência da Computação do
URI-Santo Ângelo pelo auxilio e compreensão no esclarecimento de certas duvidas que
contribuíram em muito para minha formação.
SUMÁRIO
LISTA ABREVIATURAS E SIGLAS .................................................................. 7
LISTA DE FIGURAS .......................................................................................... 8
LISTA DE TABELAS ....................................................................................... 10
RESUMO.......................................................................................................... 11
ABSTRACT ...................................................................................................... 12
1 INTRODUÇÃO ............................................................................................ 13
1.1 Considerações Iniciais ......................................................................................... 15 1.2 Organização do Trabalho ................................................................................... 15
2 SISTEMAS DE RECONHECIMENTO DE SOM PARA DISPOSITIVOS MÓVEIS ........................................................................................................... 16
2.1 O Som .................................................................................................................... 16
2.2 Estado da Arte ...................................................................................................... 17
2.3 Modalidades de Reconhecimento de Voz em Dispositivos Móveis .................. 17 2.3.1 Reconhecimento de Voz em Rede (Network Speech Recognition) .................... 17 2.3.2 Reconhecimento de Voz em Terminal (Terminal Speech Recognition) ............. 18 2.3.3 Reconhecimento de Voz Distribuído (Distribuided Speech Recognition) ......... 18
2.4 Sistemas Contínuo/Discretos ............................................................................... 18 2.5 Tamanho do Vocabulário .................................................................................... 19 2.6 Sistemas Dependente/Independente de Locutor ............................................... 19
2.7 Fatores que Interferem no Desempenho ............................................................ 19
3 CAPTURA E ARMAZENAMENTO DE ÁUDIO .......................................... 21
3.1 Digitalização do Sinal Analógico de Áudio ........................................................ 21 3.1.1 Filtro Anti-Aliasing ............................................................................................. 22 3.1.2 Amostragem ........................................................................................................ 22
3.1.3 Quantização ........................................................................................................ 24 3.1.4 Codificação ......................................................................................................... 24
3.1.5 Pulse Code Modulation (PCM) .......................................................................... 25
3.2 Wave File Format ................................................................................................. 26 3.3 MMAPI ................................................................................................................. 27 3.3.1 MMAPI, JSR 135 ............................................................................................... 27 3.3.2 MMAPI e PCM ................................................................................................... 28
3.4 RMS ....................................................................................................................... 28
4 EXTRAÇÃO DE INFORMAÇÃO ................................................................ 30
4.1 Pré-Processamento ............................................................................................... 31
5
4.1.1 Detecção de Extremos ........................................................................................ 31 4.1.2 Inversão de Sinal ................................................................................................. 31
4.1.3 Pré-Ênfase ........................................................................................................... 31 4.1.4 Janelamento ........................................................................................................ 32
4.2 Análise Espectral .................................................................................................. 34 4.2.1 Transformada Rápida de Fourier (FFT) ............................................................. 35 4.2.2 Espectro de Potências ......................................................................................... 37
4.3 Extração dos Parâmetros .................................................................................... 37 4.3.1 Coeficientes Mel-Cepstrais (MFCC) .................................................................. 37
5 RECONHECIMENTO .................................................................................. 42
5.1 Dinamic Time Warping (DTW) ........................................................................... 42 5.1.1 Coeficientes de Seletividade de Reconhecimento .............................................. 44
5.2 Distância Euclidiana ............................................................................................ 46
5.3 Coeficiente de Correlação de Pearson................................................................ 46
6 O FRAMEWORK SRM ............................................................................... 47
6.1 Capacidades .......................................................................................................... 47 6.1.1 Reconhecimento de palavras isoladas dependente de locutor ............................ 47 6.1.2 Reconhecimento de som ..................................................................................... 47
6.1.3 Vocabulário pequeno .......................................................................................... 47 6.1.4 Reconhecimento em Terminal ............................................................................ 48
6.2 Requisitos Mínimos .............................................................................................. 49 6.2.1 Estrutura do Framework ..................................................................................... 49
6.3 Descrição da Implementação .............................................................................. 50 6.3.1 Técnicas Propostas .............................................................................................. 51
6.3.2 Front-End ............................................................................................................ 55
6.3.3 Back-End ............................................................................................................ 58
6.4 Diagrama de Classes ............................................................................................ 59 6.4.1 Classe GraphicWave ........................................................................................... 60 6.4.2 Pacote sound ....................................................................................................... 61 6.4.3 Pacote frontEnd ................................................................................................... 61 6.4.4 Pacote backEnd ................................................................................................... 63
6.5 Diagrama de Sequência ....................................................................................... 65 6.6 Reconhecimento em Tempo Real ....................................................................... 66 6.7 Treinamento ......................................................................................................... 67
7 TESTES E RESULTADOS ......................................................................... 68
7.1 Testes no emulador SDK 3.0 ............................................................................... 69 7.1.1 Ajuste das Janelas de Hamming .......................................................................... 69 7.1.2 Ajuste do Banco de Filtros .................................................................................. 71
7.1.3 Ajuste dos MFCCs .............................................................................................. 73
7.2 Testes em Dispositivos Móveis ............................................................................ 74 7.2.1 Desempenho para Extração de Informação ........................................................ 74 7.2.2 Desempenho para Reconhecimento .................................................................... 75 7.2.3 Resultados Gerais ............................................................................................... 76
7.3 Comparativo do uso da técnica de IS ................................................................. 78
8 ESTUDO DE CASO .................................................................................... 79
9 CONCLUSÃO ............................................................................................. 83
6
9.1 Contribuições ....................................................................................................... 84
9.2 Trabalhos Futuros ............................................................................................... 85
REFERÊNCIAS ................................................................................................ 86
ANEXO A - APLICATIVO CALLDICTATION .................................................. 89
7
LISTA ABREVIATURAS E SIGLAS
A/D Analógico/Digital
AMR Adaptative Multi-Rate
API Aplication Programming Interface
CDC Connected Device Configuration
CLDC Connected Limited Device Configuration
DFT Discrete Fourier Transform
DTW Dinamic Time Warping
FFT Fast Fourier Transform
Hz Hertz
ID Identidade
KHz Kilohertz
JSR Java Specification Requestes
HMM Hidden Markov Model
ME Micro Edition
MFCC Mel Frequency Cepstrum Coeficient
MIDP Mobile Information Device Profile
MMAPI Multimedia API
PCM Pulse Code Modulation
RIFF Resource Interchange File Format
RMS Record Management Store
SRM Sound Recognizer ME
SDK Sun Developement Kit
LISTA DE FIGURAS
Figura 2.1: Representação de um sinal analógico de som .............................................. 16
Figura 3.1: Filtragem e digitalização do sinal analógico ................................................ 22
Figura 3.2: Exemplo do processo de amostragem do sinal contínuo ............................. 23
Figura 3.3: Sinal analógico digitalizado e quantizado. ................................................... 24 Figura 3.4: Processo de codificação PCM. ..................................................................... 25 Figura 3.5: Formato Wave. ............................................................................................. 26 Figura 3.6 - Processo de Funcionamento da MMAPI .................................................... 28
Figura 3.7: Interface Java ME RMS ............................................................................... 29 Figura 4.1: Etapas que compõe a extração de informação do sinal de som ................... 30
Figura 4.2: Etapas do pré-processamento ....................................................................... 31 Figura 4.3: Espectro de frequências sem e com pré-ênfase ............................................ 32 Figura 4.4: Janela de Hamming ...................................................................................... 33
Figura 4.5: Janelas de Hamming com sobreposição de 50% .......................................... 33 Figura 4.6: Análise espectral .......................................................................................... 34
Figura 4.7: Desempenho da FFT em relação ao aumento de pontos .............................. 36
Figura 4.8: Esquema de saída da FFT e a aplicação de sua inversa ............................... 36
Figura 4.9 - Variação logarítmica da escala Mel em relação a Hz ................................. 38 Figura 4.10: Etapas da extração dos parâmetros ............................................................ 39
Figura 4.11: Exemplo de banco de 20 filtros triangulares espaçados de acordo com a
escala Mel. ...................................................................................................................... 39 Figura 4.12: Energia de saída do banco de filtros .......................................................... 41
Figura 5.1: Exemplo de diferença temporal ................................................................... 43 Figura 5.2: Alinhamento não-linear gerado pela DTW .................................................. 43 Figura 5.3: Plano temporal dos padrões R e T ................................................................ 44
Figura 5.4 - Exemplo de erro de reconhecimento utilizando somente as distâncias
mínimas da DTW ........................................................................................................... 45
Figura 6.1: Tempo de processamento para o reconhecimento em relação ao número de
padrões ............................................................................................................................ 48
Figura 6.2: Estrutura geral do SRM................................................................................ 50 Figura 6.3: Trecho da palavra “teste” antes e depois da inversão de sinal ..................... 52 Figura 6.4: Linha imaginária de limite de silêncio ......................................................... 53
Figura 6.5: Etapas implementadas no bloco front-end caracterizando a extração de
informação ...................................................................................................................... 55
Figura 6.6: Processo de remoção do cabeçalho Wave .................................................... 56 Figura 6.7: Etapas implementadas no bloco back-end caracterizando o reconheciment.
........................................................................................................................................ 58 Figura 6.8: Diagrama de classe do Framework SRM .................................................... 59 Figura 6.9: Telas exemplos da classe GraphicWave contendo a representação de um
sinal PCM no formato Wave com 8 bits por amostra ..................................................... 60
9
Figura 6.10: Classe GraphicWave .................................................................................. 60 Figura 6.11: Diagrama de classes do pacote sound ........................................................ 61
Figura 6.12: Diagrama de classes do pacote frontEnd ................................................... 62 Figura 6.13: Diagrama de classes do pacote backEnd.................................................... 63 Figura 6.14: Diagrama de Sequencia .............................................................................. 65 Figura 6.15: Fluxograma do modo listening .................................................................. 66 Figura 7.1: Sel1 gerado sobre o ajuste quanto largura da Janela de Hamming ............... 70
Figura 7.2: Sel1 para as variações de sobreposição entre as janelas de Hamming ......... 71 Figura 7.3: Comparação de Sel1 entre o número de filtros ............................................. 72 Figura 7.4: Comparativo de Sel1 alternado a quantidade de MFCCs ............................. 73 Figura 7.5: Desempenho de extração de informação em relação a frequência do
processamento ................................................................................................................ 75
Figura 7.6: Gráfico comparativo de tempos para reconhecimento entre os processadores
testados ........................................................................................................................... 76
Figura 8.1: Configuração básica do SRM ...................................................................... 79 Figura 8.2: Gravação e definição como padrão de uma amostra de som ....................... 80 Figura 8.3: Verificação do tamanho do banco ................................................................ 80 Figura 8.4: Utilização da função "isListening" ............................................................... 81
LISTA DE TABELAS
Tabela 2.1: Classificação quanto ao vocabulário ........................................................... 19
Tabela 3.1: Taxa de erros em relação à frequência de amostragem ............................... 23
Tabela 3.2: Codificação do sinal em uma sequência numérica de base binária. ............ 25
Tabela 6.1: Tempos de recorte em milissegundos do algoritmo de detecção de extremos
e o tempo de processamento obtido no teste elaborado no emulador SDK 3.0 ............. 54 Tabela 7.1: Ajuste quanto ao tamanho das janelas de Hamming ................................... 70 Tabela 7.2: Porcentagem de Sobreposição entre as Janelas de Hamming...................... 71
Tabela 7.3: Número de Filtros ........................................................................................ 72 Tabela 7.4: Ajuste de MFCCs ........................................................................................ 73
Tabela 7.5: Tempo gasto em segundos para extração de informação nos três dispositivos
testados ........................................................................................................................... 74 Tabela 7.6: Tempo gasto em segundos para o reconhecimento nos três dispositivos
testados ........................................................................................................................... 75 Tabela 7.7: Configuração geral do framework SRM ...................................................... 76
Tabela 7.8: Precisão de reconhecimento do framework SRM........................................ 77
Tabela 7.9: Inversão de Sinal ......................................................................................... 78
RESUMO
Com uma maior acessibilidade ao desenvolvimento de aplicativos para dispositivos
móveis, surgem novas possibilidades de fornecer uma maior interação homem/máquina.
Uma dessas formas de interação que objetiva reconhecer um meio de comunicação e
percepção espacial muito comum para os seres humanos é o reconhecimento de som.
Este trabalho consiste no desenvolvimento de um Framework escrito na linguagem Java
Micro Edition, para o reconhecimento de sons abstratos e de palavras isoladas
dependentes de locutor em dispositivos móveis. Onde alcançou-se excelentes resultados
de reconhecimento, chegando a atingir – no melhor caso – uma precisão de acertos de
94%. Através deste framework, desenvolvedores de aplicações móveis poderão utilizar
e também trabalhar de um modo geral com o reconhecimento de som em diversos
cenários. Na realização dessa proposta foi abordada a API MMAPI para a captura e
execução do áudio na codificação PCM, já na fase de extração de informações do sinal
foi utilizada a extração dos coeficientes Mel-Cepstrais (MFCC) derivados da
Transformada Rápida de Fourier (FFT), e para o reconhecimento foi empregada a
comparação através da Dinamic Time Warping (DTW). Neste trabalho foram propostas
duas técnicas de processamento de sinal de som: a primeira denominada Inversão de
Sinal (IS), e a segunda correspondente a um algoritmo de baixo custo de detecção de
extremos responsável pela detecção de inicio e fim de uma elocução. E também foi
proposta e integrada uma funcionalidade que permite a representação gráfica do
espectro de áudio em telas de dispositivos móveis.
Palavras-Chave: Reconhecimento, som, dispositivos móveis, extração de informação,
padrões.
SRM: Framework for Sound Recognition on Mobile Devices
ABSTRACT
With greater accessibility to developing applications for mobile devices, new
opportunities arise to provide greater interaction man/machine. One of these forms of
interaction that aims to recognize a means of communication and spatial perception very
common to humans is the recognition of sound. This work consists in developing a
framework written in Java Micro Edition, for the recognition of abstract sounds and
isolated words announcer dependent on mobile devices. Where was reached excellent
recognition results, reaching – in the best case – an accuracy hits 94%. Through this
framework, developers can use mobile applications and also work generally sound
recognition in various scenarios. In making this proposal was discussed the MMAPI
API to capture and execution of PCM audio encoding, already in phase of signal
information extraction was used to extract the Mel-Cepstrais coefficients (MFCC)
derived from the Fast Fourier Transform (FFT), and for the recognition was employed
through comparison of Dinamic Time Warping (DTW). In this work were proposed two
techniques of sound signal processing: the first called signal Inversion (IS), and the
second corresponds to a low-cost algorithm for detecting extremes responsible for
detection of beginning and end of an utterance. And also was proposed and integrated
functionality that allows graphical representation of the audio spectrum on screens of
mobile devices.
Keywords: Sound recognition, mobile devices, information extraction, patterns.
1 INTRODUÇÃO
Na ciência da computação, cada vez mais surgem novas tecnologias que permitem
uma maior interação e consequentemente uma maior produtividade entre o ser humano
e o computador. Entre estas tecnologias uma que tem grande destaque por reconhecer
um meio de interação muito comum aos seres humanos, é o reconhecimento de som.
O reconhecimento de som de um modo geral é a capacidade de um sistema
computacional extrair e interpretar corretamente as variáveis contidas em um sinal de
som (RABINER e JUANG, 1978). O uso do reconhecimento de som em determinado
cenário flexibiliza a interação homem/máquina automatizando certas tarefas que
geralmente requisitam uma maior quantidade de interações físicas. Em um ambiente
móvel esta flexibilidade operacional provida pelo reconhecimento alia-se a mobilidade
nativa dos sistemas embarcados expandindo ainda mais a aplicabilidade do
reconhecimento de som.
Contudo, para se desenvolver um sistema de reconhecimento de som enfrentam-se
algumas dificuldades, entre as principais destaca-se a natureza interdisciplinar
requisitada no desenvolvimento destes sistemas, podendo-se citar entre as áreas
envolvidas o processamento de sinais digitais, linguagens de programação,
reconhecimento de padrões, inteligência artificial, linguística, teoria das comunicações
(SILVA, 2009), entre outras, variando de acordo com a complexidade do
reconhecimento (PETRY, ZANUT e BARONE, 2000) (TAFNER, 1996). Por isso,
desenvolver um sistema desse gênero demanda – além de um amplo conhecimento – um
grande esforço de tempo, o que faz com que esta capacidade deixe de ser integrada
pelos desenvolvedores de software de uma maneira mais ocasional principalmente em
aplicações móveis. Outra dificuldade encontrada no desenvolvimento do
reconhecimento de som em ambientes embarcados é a limitação de hardware, que
atualmente ainda impõe barreiras para a elaboração de um reconhecimento mais
complexo.
A grande maioria dos dispositivos móveis encontrados no mercado atual incorpora
algum sistema de reconhecimento de som (principalmente o reconhecimento de voz),
muitos destes sistemas são eficientes alcançando excelentes níveis de precisão com
relativo baixo custo computacional. Porém estes sistemas geralmente são privados e/ou
não permitem sua integração a outras aplicações (na forma de API ou framework).
No cenário atual de desenvolvimento móvel, mais especificamente no contexto da
linguagem Java ME, encontra-se poucas ferramentas de reconhecimento de som
integráveis a alguma aplicação. A principal delas é a API Java Speech que em sua
versão 2.0 provê suporte a linguagem Java ME, contudo esta API é licenciada apenas
para empresas privadas (ORACLE, 2010). Outra indisponibilidade é quanto a
capacidade dos motores de reconhecimento elaborarem seus processamentos
14
inteiramente no dispositivo portátil em que são instalados, dispensando uma conexão
sem fio a um servidor para um processamento normalmente mais robusto.
Ciente destes fatores, este trabalho propôs o desenvolvimento e implementação de
um framework chamado Sound Recognizer ME (SRM) escrito na linguagem Java Micro
Editon para dispositivos móveis objetivando o reconhecimento de som englobando
também o reconhecimento de voz, que mais especificamente é caracterizado neste
trabalho pelo reconhecimento de palavras isoladas dependente de locutor. Através deste
framework desenvolvedores poderão integrar o reconhecimento disponibilizado, em
aplicações móveis de uma maneira simples e abstraída. Já a escolha pelo
reconhecimento principalmente de palavras isoladas dependente de locutor, apresenta-se
como uma base ideal para se iniciar os estudos de propostas mais complexas na área de
reconhecimento de voz como o reconhecimento de fala contínua independente de
locutor, além de ampliar o reconhecimento de som para o contexto de voz, o que
estende a aplicabilidade desta proposta.
Para o desenvolvimento do SRM, foram utilizados pacotes da linguagem Java ME
que permitem abstrair certas funcionalidades essenciais para o apoio em um caráter de
infraestrutura no desenvolvimento do reconhecimento de som. Estas funcionalidades
são o controle multimídia através da API MMAPI que permite a captura e execução de
som no dispositivo, o RMS que fornece o suporte ao armazenamento persistente, e as
bibliotecas Math e MathC para o cálculos de funções matemáticas.
Na etapa de extração de informação do sinal também conhecida como front-end, foi
utilizada a extração dos coeficientes Mel-Cepstrais (MFCC) derivados da Transformada
Rápida de Fourier e da analise por meio de um banco de filtros de escala Mel seguindo
a metodologia proposta por Rabiner (RABINER e JUANG, 1978). Os coeficientes
MFCC segundo Davis et al (1980) apresentam robustas característica para o
reconhecimento de voz, e segundo Chen et al (2005) é talvez a técnica de front-end
mais utilizada por sistemas estado da arte de reconhecimento de voz.
Também foi desenvolvida uma técnica de pré-processamento de sinais de áudio
chamada Inversão de Sinal (IS), que demostrou uma melhor parametrização dos
coeficientes MFCC sobre o sinal de som, e se mostrou extremamente útil no algoritmo
de detecção de inicio e fim de uma elocução (detecção de extremos), que também foi
uma proposta deste trabalho.
Já para o reconhecimento dos coeficientes MFCC extraídos em relação a um banco
de padrões, foi utilizada a Dynamic Time Warping (DTW), ou também conhecida como
Modelagem Determinística. A DTW além da vantagem do baixo custo computacional
possibilita o reconhecimento de elocuções que apresentam variações de velocidade em
sua composição. Conforme visto em Yoma (YOMA, 1993), a DTW se encaixa
perfeitamente no contexto de reconhecimento de palavras isoladas dependente de
locutor.
E juntamente com a oferta de reconhecimento de som proposta pelo SRM, foi
desenvolvida e incorporada ao framework uma funcionalidade que permite a
representação gráfica do espectro de sinais digitais de áudio em telas de dispositivos
móveis, esta capacidade apoiou e impulsionou o desenvolvimento do SRM sendo muito
útil nas fases de estudo e análise do comportamento do sinal, e por isso foi mantida e
disponibilizada para ser utilizada como objeto de estudo e desenvolvimento em futuras
pesquisas.
15
Também foi elaborada e disponibilizada implicitamente a este framework uma API
para o cálculo da Transformada Rápida de Fourier na linguagem Java ME, permitindo a
obtenção do espectro de magnitudes, e também foi disponibilizada uma função
contendo uma formula baseada na obra de (HERATH e RAGEL, 2007), para a obtenção
da frequência do espectro de magnitudes de saída da FFT.
Por fim, como produto final obteve-se um motor de reconhecimento de fácil
integração a aplicações móveis Java ME e que se mostrou eficaz no reconhecimento dos
gêneros de som envolvidos, apresentando uma precisão, no melhor caso de 94% e no
pior caso de 86% de acertos nos testes em dispositivos móveis. Outra característica
apresentada pelo SRM foi um consumo de processamento aquém do esperado, se
caracterizando como um sistema de baixo custo, levando-se em consideração a
complexidade das técnicas abordadas sobre o contexto de processamento embarcado
atual.
1.1 Considerações Iniciais
Neste trabalho foi abordado o termo: “reconhecimento de som”, pois como
mencionado anteriormente o reconhecimento nesta proposta se encaixa em categorias
do reconhecimento de voz, e também o reconhecimento de outros sons que não
caracterizam uma palavra, chamados a partir deste momento de: “sons abstratos”.
Porém, ao longo do trabalho, principalmente na parte de fundamentação teórica, é
encontrado o conceito: “reconhecimento de voz”, isso ocorre porque este termo estava
especificamente associado às ideias extraídas das obras referenciadas, e portanto
resolveu-se não distorce-lo.
Contudo, neste trabalho, acaba sendo implicitamente proposta a absorção de
conceitos típicos de reconhecimento de voz ao reconhecimento de sons abstratos. Sendo
que para seguir esta linha metodológica estudou-se a definição de som, apresentada pela
seção 2.1.
1.2 Organização do Trabalho
A organização dos capítulos neste trabalho ocorre da seguinte maneira:
O próximo capitulo (capítulo 2) é destinado à contextualização dos sistemas de
reconhecimento de som em dispositivos móveis. O capitulo 3 expõe as técnicas
utilizadas para a captura e armazenamento dos arquivos de áudio no dispositivo. No
capítulo 4 é descrito o processo realizado para a extração de informação do sinal. No
capitulo 5 é descrito a etapa de reconhecimento. Já no capitulo 6 é caracterizado o
framework SRM como um todo. O capitulo 7 apresenta os testes e resultados obtidos.
No capitulo 8 é apresentado um estudo de caso utilizando o SRM. E o capitulo 9 encerra
apresentado as conclusões.
16
2 SISTEMAS DE RECONHECIMENTO DE SOM PARA
DISPOSITIVOS MÓVEIS
Este capítulo é dedicado à contextualização de sistemas de reconhecimento de som
em dispositivos móveis, descrevendo suas principais características.
2.1 O Som
Som é um sinal analógico definido por vibrações ocasionadas pelas diferenças de
pressões sofridas pela matéria em que será transmitido, normalmente representado
através de curvas sinusoidais que caracterizam suas variáveis possuindo uma
determinada frequência, amplitude e fase (TAFNER, 1996) – ver figura 2.1.
Complementado esta definição anterior, pode-se ainda acrescentar conforme a
Associação Brasileira de Normas Técnicas (1959) que “som é toda e qualquer vibração
ou onda mecânica em um meio elástico dentro da faixa de áudio frequência”.
Figura 2.1: Representação de um sinal analógico de som (ROLIM, 2010)
Sendo a onda sonora composta por três características básicas (HAYKIN e VEEN,
2001):
Amplitude: valor em um determinado momento do nível de sinal;
Frequência: quantidade de vezes por unidade de tempo em que a forma de
onda do sinal se repete.
Fase: ângulo em que o sinal se apresenta.
Com base nestes conceitos pode-se definir mais claramente o conceito de voz, que
segundo o dicionário Aurélio Online (2010), é um som originado das cordas vocais.
Logo ela apresenta as mesmas características físicas descritas acima, e conclui-se que
técnicas utilizadas (neste trabalho) para o reconhecimento de voz, podem ser absorvidas
pelo reconhecimento de som.
17
2.2 Estado da Arte
O desenvolvimento de sistemas de reconhecimento voz em dispositivos móveis é
amplamente motivado pelo mercado da telefonia. Existem muitos sistemas de
reconhecimento embarcados privados atualmente: Nuance’s VoCom (Nuance Vocon),
IBM’s ViaVoice ( IBM Embedded ViaVoice), Asahi Kasei’s VORERO (Asahi Kasei
VORERO), entre outros. Esses sistemas são softwares baseados em soluções que rodam
em uma gama variada de dispositivos, suportando vocabulários grandes que são
somente limitados pela memória do dispositivo (MIRANDA, 2008)
Na extração de informação do sinal ou front-end, uma característica fundamental
que aumenta consideravelmente o desempenho do reconhecimento é realizar o
processamento utilizando variáveis ponto-flutuante. Porém, em um ambiente móvel
trabalhar com estes tipos de variáveis requer um maior esforço computacional.
Entretanto sem o uso de variáveis ponto-flutuante ficaria impraticável aplicar técnicas
robustas atualmente de extração de informações como os coeficientes MFCC (DAVIS e
MERMELSTEIN, 1980)(CHEN, PALIWAL, et al., 2005). Outra implicação de se
utilizar técnicas deste porte é a complexidade de operações aritméticas envolvidas,
incorporadas por funções especiais tal como a Transformada Rápida de Fourier.
Já para o reconhecimento o grande desafio é encontrar meios de não sobrecarregar o
sistema com um acréscimo no número de padrões envolvidos. Outra implicação é a
quantidade de armazenamento disponibilizada pelo dispositivo móvel, que se muito
limitada, inviabiliza todo o processo.
No reconhecimento de palavras isoladas dependente de locutor – não
necessariamente no contexto móvel – uma técnica que se mostra ideal para este
contexto de reconhecimento (YOMA, 1993) (FURTUNĂ, 2008) e é tradicionalmente
utilizada é a DTW, que entre outros benefícios possui a vantagem de apresentar um
baixo custo computacional, fator este indispensável em um ambiente móvel.
Para maiores informações sobre o estado da arte em dispositivos móveis consultar
Miranda (2008).
2.3 Modalidades de Reconhecimento de Voz em Dispositivos Móveis
Huerta (2000) define três principais modalidades de reconhecimento de voz em
dispositivos móveis: (1) reconhecimento de voz em rede, (2) reconhecimento de voz em
terminal, e (3) reconhecimento de voz distribuído. A seguir são descritas estas três
modalidades:
2.3.1 Reconhecimento de Voz em Rede (Network Speech Recognition)
Nesta modalidade, o reconhecimento é implementado remotamente do ponto de
vista do usuário, pois o sinal de voz é transmitido do dispositivo para um servidor
realizar o reconhecimento através de uma rede sem fio. As principais implicações desta
técnica são no momento da transmissão sem fio entre o cliente e o servidor. Neste caso,
para o envio, deve-se ter uma conexão rápida e confiável, e os dados devem ser
comprimidos. Contudo esta modalidade apresenta um reconhecimento mais sofisticado
para aplicações em dispositivo móveis, permitindo a integração de técnicas de
reconhecimento mais robustas.
18
2.3.2 Reconhecimento de Voz em Terminal (Terminal Speech Recognition)
Nesta modalidade, o reconhecimento é feito no dispositivo do usuário. Neste
caso, o sinal de voz não é transmitido através de uma rede sem fio, por isso
não é afetado pelo canal de transmissão e de algoritmos de compressão. Entretanto o
desempenho do sistema neste tipo de modalidade deve ser cuidadosamente avaliado,
devido a sensibilidade do dispositivo em relação ao consumo de memória e
processamento. Huerta (2000) também afirma que só é possível construir sistemas de
reconhecimento relativamente simples (por exemplo, discagem por voz, comando e
controle de aplicações, etc.).
2.3.3 Reconhecimento de Voz Distribuído (Distribuided Speech Recognition)
Nesta modalidade o sistema de reconhecimento de voz é separado em duas partes:
cliente e servidor. A diferença entre esta modalidade e a de reconhecimento em rede, é
que, neste caso, a extração de informação do sinal de voz é realizada no próprio
dispositivo e após são enviados os resultados no formato de dados através de um canal
protegido de erros usando uma rede especifica para o reconhecimento (SUK, JUNG, et
al., 2004) (HUERTA, 2000) (MIRANDA, 2008). Isso permite o reconhecimento não
dependente de um sinal que pode ter sido afetado pela compressão e codificação da rede
sem fio. A principal desvantagem desta abordagem é a dependência de um padrão front-
end que é realizado no próprio dispositivo. Estabelecer e padronizar este front-end
envolve problemas difíceis de serem resolvidos como a característica permitir o
reconhecimento de alta precisão em ambientes silenciosos e ruidosos. Um sistema deste
tipo pode se beneficiar das vantagens das duas modalidades já descritas: sistemas
sofisticados podem ser implementados (como no reconhecimento de rede), enquanto a
informação do sinal é extraída no dispositivo (como no reconhecimento de terminal).
Há também outras características e fatores citados em (MIRANDA, 2008)
(CIPRIANO, 2001) (LIMA, 2000) (OLIVEIRA, 2002) (SILVA, 2009) que classificam
os sistemas de reconhecimento e que devem ser determinados na elaboração de um
reconhecedor de som. Escolher que tipo de características o reconhecimento irá
abranger, implica diretamente em alterar toda uma metodologia de elaboração em
comparação a um sistema diferente. A seguir são descritas estas características.
2.4 Sistemas Contínuo/Discretos
Em sistemas de fala isolada ou discreta tem-se uma pausa identificável entre cada
palavra, também pode-se implementar sistemas assim através da captura de uma única
palavra por arquivo de áudio. Já a fala contínua ocorre de uma maneira mais comum aos
seres humanos, onde os limites das palavras não são facilmente distinguíveis, pois a fala
não precisa ser pausada e ocorre espontaneamente. Obviamente sistemas de fala discreta
tem uma precisão geralmente maior em relação aos sistemas de fala contínua que por
sua vez, possuem uma maior complexidade (MIRANDA, 2008).
19
2.5 Tamanho do Vocabulário
O tamanho do vocabulário é a quantidade máxima de elocuções que podem ser
definidas como padrão para o reconhecimento (RABINER e JUANG, 1978).
O tamanho do vocabulário utilizado irá afetar diretamente a precisão e o
desempenho do sistema, principalmente em ambientes móveis onde o espaço disponível
para o armazenamento de informações persistentes é limitado, na tabela 2.1 a seguir
pode-se verificar a classificação quanto ao tamanho de vocabulário (RABINER e
JUANG, 1978).
Tabela 2.1: Classificação quanto ao vocabulário
Vocabulário Nº. Palavras
Pequeno Até 20
Médio Entre 20 e 100
Grande Entre 100 e 1000
Muito Grande Mais de 1000
Quando se fala em precisão, um grande vocabulário atrapalha no momento de
avaliar se o reconhecimento obteve alto índice de exatidão, pois se houver um número
grande de padrões, estes podem apresentar um índice de reconhecimento semelhante a
outros padrões, resultando em um estado de reconhecimento incerto e atrapalhando por
vezes um reconhecimento que poderia estar correto.
2.6 Sistemas Dependente/Independente de Locutor
Nos sistemas dependente de locutor há o reconhecimento dos locutores cujas vozes
foram utilizadas para treinar o sistema ou definir os padrões. Os sistemas dependentes
de locutor tem boa precisão, mas requerem um treinamento diferente para cada usuário.
Para aplicações como editores de texto, a dependência do locutor pode ser muito
benéfica (OLIVEIRA, 2002), pois diminui bastante a taxa de erros.
Quando o sistema é independente de locutor o mesmo deve reconhecer a voz de
qualquer pessoa sem haver um treinamento antes. Neste caso é necessário realizar o
treino geral do sistema com uma base que inclua diferentes pessoas com diferentes
idades, sexo, sotaques, timbres de som, etc., para definir um padrão de características
predominantes para cada elocução.
2.7 Fatores que Interferem no Desempenho
Além das características citadas acima, há outros fatores que afetam o desempenho
de um sistema de reconhecimento de som:
Variações para um mesmo locutor: Um locutor, ou seja, a pessoa que está
pronunciando a elocução varia constantemente e involuntariamente em sua
pronuncia. Isso ocorre frequentemente e deve ser levado em conta na fase de
reconhecimento, através de técnicas que sejam capazes, de identificar a
mesma elocução dita mais lentamente ou mais rapidamente, por exemplo.
20
Ausência de Treinamento: Em sistemas que dispensam um treinamento
para cada padrão de palavra, o desempenho de reconhecimento geralmente é
menor, pois se define como padrão uma amostra capturada aleatoriamente, e
esta pode conter características anormais de uma pronunciação padrão para
uma determinada elocução.
Condições do ambiente: Ambientes ruidosos atrapalham muito um
reconhecimento preciso, mesmo os mais exatos reconhecedores têm seus
desempenhos prejudicados com a adição de ruído, causando frequências
indesejáveis no sinal analisado.
Microfone: Este fator é um dos mais importantes, pois um microfone de
baixa qualidade resultará em um nível de transdução ruidoso e às vezes não
representativo o bastante para ser reconhecido.
Frequência de Amostragem e níveis de Quantização: Estes fatores são
extremamente importantes na qualidade do áudio capturado e serão
explicados mais detalhadamente no capítulo 3. Definir configurações muito
baixas implica em diminuir os dados digitalizados que representam o sinal de
áudio em sua forma contínua. O mínimo utilizado atualmente para sistemas
de reconhecimento de voz, são a frequência de amostragem de 8 KHz e 8 bits
por amostra, resultando em 256 níveis diferentes de representação por
amostra.
21
3 CAPTURA E ARMAZENAMENTO DE ÁUDIO
Para se obter os arquivos de áudio necessários para o reconhecimento, é essencial
incorporar técnicas que permitem sua captura e armazenamento em um contexto móvel.
Inicialmente para a captura do sinal analógico e subsequentemente sua conversão
para o formato digital emprega-se técnicas de digitalização de sinais, estas técnicas são
descritas na seção 3.1 a seguir, e são fundamentais para a aquisição do sinal de áudio em
seu formato digital. Já na seção 3.2 é contextualizada a API MMAPI utilizada para o
controle e configuração da captura do sinal. Na seção 3.3 é então descrita a relação entre
a MMAPI e a codificação PCM que é representada pelo formato Wave descrito na seção
3.4. E por fim a seção 3.5 refere-se a técnica de armazenamento persistente RMS,
utilizada para armazenar a informação pertinente ao reconhecimento.
3.1 Digitalização do Sinal Analógico de Áudio
Qualquer tipo de sinal analógico que requisite ser armazenado em um sistema
computacional ou transmitido em um canal de transmissão digital necessita passar por
um tratamento de sinal, ou seja, um processo chamado de digitalização (HAYKIN e
VEEN, 2001). A digitalização tem o objetivo de representar um sinal analógico em
níveis de representação discretos no tempo que correspondem aproximadamente às
variações contínuas no tempo presentes no sinal a ser digitalizado.
Para digitalizar um sinal analógico, são necessárias no mínimo quatro etapas:
1. Filtragem Anti-Aliasing;
2. Amostragem;
3. Quantização;
4. Codificação.
Contudo, antes de iniciar a descrição dos processos de digitalização é conveniente
lembrar o Teorema de Amostragem de Nyquist.
A frequência de amostragem de um sinal analógico, para que possa
posteriormente ser reconstituído com o mínimo de perda de informação, deve
ser igual ou maior a duas vezes a maior frequência do espectro desse sinal.
Em outras palavras, a quantidade de amostras por unidade de tempo de um sinal,
chamada taxa ou frequência de amostragem, deve ser maior que o dobro da maior
frequência contida no sinal a ser amostrado, para que possa ser reproduzido
integralmente.
22
A metade da frequência de amostragem é chamada frequência de Nyquist e
corresponde ao limite máximo de frequência do sinal que pode ser reproduzido.
3.1.1 Filtro Anti-Aliasing
Em Petry (2002), é visto que um sinal de voz muitas vezes não possui uma limitação
constante em frequência e pode possuir componentes de frequência em uma faixa de
amplitudes bastante larga. Então como não é possível garantir que o sinal não contenha
frequências acima da frequência de Nyquist (distorções, interferências, ruídos, etc.), é
necessário filtrar o sinal com um filtro passa-baixas chamado filtro Anti-Aliasing com
frequência de corte igual (ou menor) a frequência de Nyquist objetivando suprimir as
componentes de frequência do sinal analógico superior à frequência de Nyquist.
Figura 3.1: Filtragem e digitalização do sinal analógico (CIPRIANO, 2001)
Na figura 3.1 acima pode-se ter uma visão mais clara do contexto do filtro Anti-
Aliasing no processo de digitalização do sinal. Onde primeiramente o sinal analógico é
filtrado e convertido em sinal digital para então ser aplicado a algum processamento
digital.
Após a aplicação do filtro Anti-Aliasing é iniciado o processo de conversão A/D
(RABINER e JUANG, 1978) composto pelas fases de amostragem, quantização e
codificação que serão brevemente detalhadas a seguir.
3.1.2 Amostragem
O som se propaga no espaço na forma de onda, essa onda por ser um sinal analógico
possui infinitas variações através do tempo. Para tornar possível a medição dessas
variações, se faz necessário utilizar técnicas que captam amostras regulares do sinal
analógico e os codifique em um conjunto sequencial que expressam a informação da
onda sonora de uma forma simplificada, mas os mesmo tempo sem perder a essência de
sua informação. De acordo com Castro (2006), o processo de amostragem é “o processo
através do qual o sinal contínuo no tempo é transformado em um sinal discreto no
tempo”, segundo Filho (2006), “a amostragem é o processo que consiste em caracterizar
a forma analógica da onda como uma sequência de números tomados a intervalos
regulares, onde cada um indica um valor para a amplitude de um sinal em um
determinado instante” – ver figura 3.2.
23
Figura 3.2: Exemplo do processo de amostragem do sinal contínuo (FILHO, 2006)
Na amostragem é definida uma frequência de amostragem que representa o número
de amostras registradas por segundo, os valores mais comuns para gravação de áudio
são de 8 KHz, 11 KHz, 16 KHz, etc. Quanto maior for a frequência de amostragem
maior será a qualidade do áudio digitalizado, e consequentemente menor a possibilidade
do reconhecimento resultar em erros. Há um índice comparativo descrevendo a redução
da taxa de erros de reconhecimento conforme o aumento da frequência de amostragem
expressa pela tabela 3.1 (HUANG, ACERO e HON, 2001).
Tabela 3.1: Taxa de erros em relação à frequência de amostragem
FREQ. DE AMOSTRAGEM REDUÇÃO RELATICA DA TAXA DE ERROS
8000 Hz Limite Mínimo
11000 Hz +10%
16000 Hz +10%
22000 Hz Sem Redução
Na tabela 3.1 percebe-se uma diminuição significativa na taxa de erros conforme o
aumento da frequência de amostragem o que comprova a sua importância ao
reconhecimento, contudo essa redução sessa ao se alcançar o patamar de 22 KHz onde a
partir daí, não há aumento significativo na qualidade do áudio.
É importante comentar que, na amostragem, pode ocorrer um efeito negativo
chamado aliasing e isso é evitado utilizando previamente o filtro Anti-Aliasing descrito
anteriormente.
Porém somente o processo de amostragem não é suficiente para caracterizar o sinal
captado, pois não oferece parâmetros próximos o suficiente da correta representação da
onda analógica. Para resolver esse fato emprega-se a quantização.
24
3.1.3 Quantização
Processo que transforma um sinal discreto (resultado da amostragem), nos
sinais digitais que são filtrados pelo processador. Tanto a amostragem quanto
a quantização são realizadas por um conversor analógico digital, sendo a
quantização um processo descrito em nível de bits, e.g., um CD de áudio é
amostrado a uma freqüência de 44.100 Hz e quantizado com 16 bits.[...].
Embora ocorram perdas na representação do sinal, o processo de quantização
gera uma aproximação bastante satisfatória e mais facilmente tratável em
sistemas computacionais (FILHO, 2006).
Complementando, Castro (2006) sustenta que quantização é o “processo através do
qual um sinal contínuo em amplitude é transformado em um sinal discreto em
amplitude”.
Figura 3.3: Sinal analógico digitalizado e quantizado (FILHO, 2006).
A Figura 3.3(a) mostra um sinal digitalizado, e a figura 3.3(b), o mesmo sinal
quantizado. Em 3.3(a) o sinal contínuo é transformado em sinal digital, utilizando um
conjunto de possíveis valores discretos, através do processo de amostragem. Em 3.3(b)
o sinal é quantizado para obter uma aproximação maior do sinal original.
Quanto maior for o nível de quantização maior será a qualidade do sinal digital, por
exemplo, se for utilizada uma conversão de 8 bits, obtém-se 256 níveis de quantização
(TAFNER, 1996), e com uma possiblidade maior de variações, maior será a semelhança
entre o sinal analógico capturado e sua respectiva representação no formato digital.
3.1.4 Codificação
O processo de codificação é expresso num formato sequencial binário dos resultados
obtido e refinados nos processos de amostragem e quantização (CASTRO, 2006).
25
Tabela 3.2: Codificação do sinal em uma sequência numérica de base binária
(CASTRO, 2006).
Na codificação expressa pela tabela 3.2, cada amostra é mapeada em uma sequência
com valores associados a um número representado por N bits. Cada número representa
um valor, que depende do mapeamento do código adotado.
3.1.5 Pulse Code Modulation (PCM)
Como visto na seção anterior os valores quantizados precisam ser codificados em
sequências de bits. Para realizar esta codificação pode-se utilizar o PCM que é um tipo
de codificador de forma de onda simples, cujo objetivo é reproduzir o sinal analógico
amostra por amostra através dos processos de amostragem, quantização e codificação
(ELIAS, 2006) (KUTWAK, 1999).
No PCM cada pulso amostrado de amplitude variável é transformado em uma
sequência de bits com amplitude fixa e valores binários, com um código tal que
representa o valor do pulso amostrado original, arredondado pelo erro de quantização
(ELIAS, 2006).
Figura 3.4: Processo de codificação PCM (ZURMELY, 2010).
26
Pode-se notar na figura 3.4, que nos instantes de amostragem, os sinais são
amostrados usando como parâmetro sinalizações ao longo do tempo, já na quantização
os sinais são adicionalmente parametrizados ao longo de sua amplitude, em seguida
estes parâmetros são codificados em um formato binário.
A principal vantagem da Codificação PCM é a pouca complexidade e a alta
qualidade obtida na digitalização do sinal, sua desvantagem é relativa alta taxa de
transmissão (KUTWAK, 1999).
3.2 Wave File Format
O arquivo PCM normalmente é armazenado em um formato de arquivo de áudio
Wave. O Wave é um subconjunto da especificação RIFF da Microsoft para o
armazenamento de arquivos multimídia (WILSON, 2003).
Um arquivo RIFF começa com um cabeçalho do arquivo seguido por uma sequencia
de blocos de dados, conforme pode ser visto na figura 3.6.
Figura 3.5: Formato Wave (WILSON, 2003).
A área de dados do arquivo Wave é armazenada num vetor de bytes que contém
todos os pontos amostrados. Cada elemento do vetor corresponde a uma amostra de 1
byte, correspondendo a valores decimais de +127 a -128 que representam os pulsos
quantizados de amplitude.
Neste trabalho o bloco do cabeçalho utilizado foi o “Subchunck2Size” que é
resultado do cálculo: NumSamples*NumChannels*BitsPerSample/8 (WILSON, 2003).
Nele está contido um número em bytes representando o tamanho do bloco data, que
27
contém os dados amostrados. O número de amostras reais do arquivo Wave pode ser
extraído pela seguinte equação:
Onde Na representa o número real de amostras e Wl representa o tamanho total do
vetor de bytes Wave.
3.3 MMAPI
A Mobile Media API (MMAPI) oferece um grande apoio pra se trabalhar com
mídias em dispositivos móveis. Com ela cria-se uma liberdade e um acessibilidade aos
serviços de multimídia nativos em determinados dispositivos móveis, permitindo a
reprodução de vídeo, áudio, captura de som e imagens, utilizando o Java ME
(ORACLE, 2010). Também a MMAPI disponibiliza uma flexibilidade na configuração
usada para a captura onde o desenvolvedor pode escolher a codificação e suas
características de conversão A/D (taxa de amostragem, bits por amostra, etc.).
3.3.1 MMAPI, JSR 135
Segundo o autor do livro “Pro Java ME MMAPI Mobile Media API for Java Micro
Edition” Goyal (2006) a MMAPI, é uma API opcional que prove suporte a recursos
multimídia, como reprodução, edição e captura de áudio e vídeo a partir de diversas
fontes. A MMAPI atualmente se encontra na versão 1.1 e já é suportada pela maioria
dos dispositivos que suportam MIDP 2.0. A JSR 135 que define a MMAPI, não
depende de protocolos ou formatos de arquivos, esse suporte a diferentes formatos é de
responsabilidade do fabricante do dispositivo. Essa flexibilidade permite a possibilidade
de reprodução de qualquer formato de arquivo especificado pelo fabricante.
Embora a ênfase principal da MMAPI seja sobre os dispositivos que implementam
perfis com base em CLDC, seu projeto também visa apoiar os dispositivos que
implementam perfis com base no CDC.
A MMAPI é integrada nesse trabalho, pela vantagem de permitir acesso fácil e
rápido para captura e execução de áudio em dispositivos móveis. Somado ao fato de que
não há outra API de suporte multimídia semelhante à MMAPI no momento (ORACLE,
2010).
Funcionamento
O processo de funcionamento da MMAPI pode ser dividido em duas fases:
Protocol handling – cuja responsabilidade é a captura da mídia, tal como a
captura de áudio.
Content handing – tem a função de processar os dados recebidos, ou seja,
decodificar e renderizar enviando para os dispositivos de saída como o alto-
falante.
28
Figura 3.6 - Processo de Funcionamento da MMAPI (GOYAL, 2006).
Arquitetura
Na JSR 135 são utilizados dois tipos de objetos de alto nível: DataSource que
recebe a mídia e faz um encapsulamento do processo de controle do protocolo Player,
que controla o conteúdo fornecido por DataSource e, além disso, processa e envia para
o dispositivo de saída adequado, que pode ser um display ou alto-falante (GOYAL,
2006).
3.3.2 MMAPI e PCM
A MMAPI dispõe de duas configurações extremas (mínimo/máximo) para a
codificação PCM do sinal de áudio capturado pelo dispositivo móvel (GOYAL, 2006):
Mínimo: PCM com uma taxa de frequência de 8000 Hz, e 8 bits por amostra
e um único canal (mono);
Máximo: PCM a uma taxa de frequência de 22050 Hz, 16 bits por amostra, e
dois canais (estéreo).
Configurações intermediárias podem ser livremente escolhidas, desde que
suportadas pelo dispositivo.
Para se descobrir as capacidades e as propriedades de codificação de áudio
suportadas por determinado dispositivo móvel basta utilizar a função genuína do Java
ME: System.getProperty(“audio.encodigns”), onde será retornado um vetor do tipo
String contendo o formato das codificações suportadas (GOYAL, 2006). Esta
verificação de formato pode ser obtida em Goyal (2006), na pagina 128 do seu livro, na
forma de um aplicativo que exibe na tela do dispositivo as codificações suportadas.
No framework SRM o áudio capturado encontra-se em uma configuração PCM fixa
de 8 bits por amostra, entretanto permitindo a flexibilização da frequência de
amostragem.
3.4 RMS
O Record Management Store (RMS), flexibiliza as aplicações em dispositivos
móveis através do recurso de persistência de dados.
29
No RMS é possível armazenar as informações manipuladas nas aplicações dos
dispositivos de uma maneira persistente, sem que elas sejam perdidas quando o
dispositivo for desligado.
[...] cada record store pode ser visualizado como uma coleção de registros,
que continuarão a ser persistente em várias invocações do MIDlet. A
plataforma de dispositivo é responsável por fazer o seu melhor esforço para
manter a integridade dos record stores do MIDlet durante o uso normal da
plataforma, incluindo reinicializações, mudanças de bateria, etc [...] (SUN,
2006).
Figura 3.7: Interface Java ME RMS (SUN, 2008)
Segundo o site Java Tips (SUN, 2008) um record store é a única forma de
armazenamento persistente que um dispositivo CLDC é obrigado a suportar . O record
store é um conjunto de elementos de dados não formatado, cada um identificado por um
número inteiro único, também chamado de ID.
“Esse sistema é implementado através da classe javax.
microedition.rms.RecordStore, que fornece o acesso de abertura, fechamento, escrita e
leitura de dados no vetor de bytes que o consiste” (COSTA e GRAZZIOTIN, 2007).
Nesse trabalho o RMS será usado para armazenar informações importantes ao
reconhecimento e ao funcionamento do framework.
30
4 EXTRAÇÃO DE INFORMAÇÃO
A extração da informação útil do sinal digital de som visa gerar um conjunto de
características que diferenciam de maneira reconhecível os eventos de cada elocução
representada digitalmente (PETRY, ZANUT e BARONE, 2000) (CIPRIANO, 2001).
A metodologia para a extração de informação do sinal seguida por este trabalho é
baseada em diversas obras da literatura moderna tais como (PETRY, 2002),
(CUADROS, 2007), (SILVA, 2009) (PETRY, ZANUT e BARONE, 2000), entre
outros. Também é adicionada a esta metodologia a técnica de pré-processamento
chamada Inversão de Sinal proposta por este trabalho e descrita na subseção 6.4.1.
Na figura 4.1 a seguir pode-se observar todas as etapas presentes na extração da
informação do sinal no contexto deste trabalho destacando a parte que é implementada
pelo framework SRM.
Figura 4.1: Etapas que compõe a extração de informação do sinal de som
Abaixo então, são detalhados os processos que compõe a fase de extração de
informação. A seção 4.1 descreve a etapa de pré-processamento. Na seção 4.2 é
31
apresentada a analise espectral. E na seção 4.3 o processo de extração dos coeficientes
MFCC.
4.1 Pré-Processamento
O pré-processamento visa preparar o sinal para a análise espectral, auxiliando no
processo de parametrização enfatizando os eventos contidos em cada sinal. Sua
aplicação ao sinal é dividida em etapas de acordo com a figura 4.2.
Figura 4.2: Etapas do pré-processamento
Abaixo são descritas suas etapas conforme a figura 4.2.
4.1.1 Detecção de Extremos
A detecção de extremos visa recortar o sinal de som de modo a obter somente o
segmento do sinal contendo a elocução, eliminando os períodos considerados como
silêncio. Esta técnica permite aumentar a distinção das informações presente em
diferentes sinais (LIMA, 2000).
4.1.2 Inversão de Sinal
Como a Inversão de Sinal é um proposta deste trabalho, a mesma não pode ser
caracterizada neste capítulo referente à fundamentação teórica, e juntamente com o
algoritmo de detecção de extremos proposto, é explicada na subseção 6.4.1.
4.1.3 Pré-Ênfase
Normalmente o sinal depois de filtrado pelo filtro Anti-Aliasing e digitalizado pelo
conversor A/D é em seguida aplicado a um filtro de pré-ênfase (PETRY, ZANUT e
BARONE, 2000) (RABINER e JUANG, 1978) (SILVA, 2009), objetivando nivelar seu
espectro compensando a atenuação de 6dB/oitava nas altas frequências. Esta atenuação
espectral é decorrente de características fisiológicas do trato vocal que podem ser
removida através da aplicação deste filtro (PETRY, 2002), O filtro pré-ênfase é aplicado
ao sinal através da equação abaixo:
[ ] [ ] [ ]
Onde y é o sinal pré-enfatizado, s é o sinal de som amostrado, n é a quantidade de
amostras e é o coeficiente de pré-ênfase com o valor entre 0.9 e 1 (RABINER e
JUANG, 1978). Na figura 4.3 pode-se perceber a mudança no espectro de frequências
antes e depois da aplicação de pré-ênfase.
32
Figura 4.3: Espectro de frequências sem e com pré-ênfase (PETRY, 2002)
O filtro pré-ênfase também é usado para equalizar o espectro de som e melhorar o
desempenho da análise espectral atenuando sinais de baixa frequência e fazendo com
que sinais agudos sejam destacados (CIPRIANO, 2001).
Neste trabalho o filtro pré-enfase é aplicado logo após o sinal passar pelo processo
de Inversão de Sinal.
4.1.4 Janelamento
Em todas as aplicações práticas de processamento de sinais, é necessário se trabalhar
com pequenas porções ou frames do sinal. O janelamento consiste em segmentar o sinal
pré-enfatizado através da divisão do sinal em janelas a fim de obter estas pequenas
porções. Pois se considera que os parâmetros do trato vocal variam lentamente no
decorrer do tempo. Assim para intervalos de 10 à aproximadamente 30 milissegundos
assume-se que as variações no modelo do trato vocal não se alteram, podendo ser
consideradas estacionárias (RABINER e JUANG, 1978) (CIPRIANO, 2001) (LIMA,
2000) (PETRY, ZANUT e BARONE, 2000) (PETRY, 2002) (SILVA, 2009).
Uma boa analogia para entender a divisão em janelas do sinal, seria comparar as
janelas a frames em um vídeo, os mesmos representam estaticamente algum momento
de imagem, e seu conjunto corresponde a um vídeo em si.
Entre as janelas existentes (Retangular, Bartlett, Blackman, Hanning, Welch), a que
é tipicamente utilizada por autores de reconhecimento de voz, e consequentemente a
que se mostra mais interessante é a janela de Hamming ou do inglês Hamming Window.
A janela de Hamming pode usada para realizar a segmentação do sinal, ou pode ser
aplicada a um sinal já segmentado. Sua função é suavizar as bordas de cada segmento
que por consequência da segmentação podem conter variações abruptas do sinal. Essa
suavização é realizada pelo próprio aspecto da janela e também pela sobreposição entre
janelas. Na figura 4.4 se pode compreender o aspecto teórico (a), e prático (aplicado a
um sinal qualquer) (b), de uma janela de Hamming:
33
Figura 4.4: Janela de Hamming
E sua função de aplicação ao sinal é dada pela seguinte equação:
[ ] { (
)
Aplicar uma janela a um sinal no domínio de tempo corresponde a multiplicar o
sinal pela função que representa a janela. Uma vez que a multiplicação no domínio de
tempo equivale a convolução no domínio de frequência, a aplicação da janela no
domínio de tempo altera a forma do sinal também no domínio de frequência (RABINER
e JUANG, 1978) (ANDRADE e SOARES, 2005).
A sobreposição das janelas pode ser disposta conforme a figura 4.5.
Figura 4.5: Janelas de Hamming com sobreposição de 50%
A sobreposição das janelas pode variar de 0% a 70%. A figura 4.5 exemplifica uma
aplicação de janelas de Hamming com sobreposição de 50%. Uma sobreposição alta
permite uma transição mais suave dos parâmetros extraídos, porém, estimativas
amplamente suavizadas podem ocultar variações reais do sinal (CIPRIANO, 2001).
34
Caso a última janela ultrapassar os limites do sinal, deve-se completar com zeros até o
final da janela, como mostrado na janela 5 da figura 4.5.
Como explicado, o janelamento permite a fragmentação do sinal de som em quadros
onde o sinal pode ser considerado estacionário. Essa característica é útil para aplicação
em seguida da Transformada Rápida de Fourier (FFT). Escolher o tipo, tamanho e
sobreposição de uma janela, é muito importante para resultados otimizados de
reconhecimento e também de performance de processamento, fator este fundamental no
contexto móvel.
Outra janela utilizada no processamento de sinal de voz é a janela retangular. Ela é a
mais simples de ser aplicada, pois na pratica aplicar uma janela retangular significa não
aplicar janela nenhuma, e somente dividir o sinal em segmentos, mantendo seu valor de
magnitude anterior (ANDRADE e SOARES, 2005). Esta janela pode ser útil em
algoritmos de detecção de extremos.
Após o processo de janelamento o sinal está pronto para ser modificado quanto a sua
representação pela análise espectral, nela é realizado o processo para converter sua
representação do domínio de tempo para o domínio de frequências. Isso se torna útil,
pois um sinal no domínio de frequência fornece informações mais convenientes ao
reconhecimento sobre suas características.
4.2 Análise Espectral
A função da análise espectral é representar os parâmetros mais úteis do sinal no
domínio de frequências ao invés do domínio do tempo permitindo uma distinção mais
detalhada da composição fonética do sinal de som (SILVA, 2009). Essa característica é
principalmente utilizada no reconhecimento de voz, onde a principal diferença entre as
palavras se dá num domínio de frequências. Contudo, neste trabalho também é aplicada
ao reconhecimento de sons.
Figura 4.6: Análise espectral
Na figura 4.6, pode-se entender onde a análise espectral se encaixa na extração de
informação, também é possível perceber que o sinal ao passar pela analise espectral tem
seu domínio de representação alterado para o domínio de frequências.
35
A seguir são descritas as etapas que compõe a análise espectral presentes na figura
4.6.
4.2.1 Transformada Rápida de Fourier (FFT)
A transformada rápida de Fourier (FFT) do inglês Fast Fourier Transform consiste
em uma família de algoritmos para calcular de uma forma mais eficiente a
Transformada Discreta de Fourier (DFT) e sua inversa. A DFT é um membro da família
de técnicas matemáticas usadas para realizar a análise de Fourier. A DFT permite
representar um sinal discreto no domínio tempo e transformar esse sinal para uma
representação discreta no domínio de frequências (GONÇALVES, 2004) (CERNA e
HARVEY, 2000).
Considerando–se N amostras do sinal no domínio de tempo, denotadas f[k],
k=0,1,2,...,N-1, a DFT é data por um conjunto de N amostras do sinal no domínio de
frequência, denotadas por F[n], n = 0,1,2,...,N-1 e definidas pela equação:
[ ] ∑ [ ]
e sua inversa
[ ]
∑ [ ]
Porém o cálculo de uma transformada discreta de Fourier exige muito
processamento computacional (envolvendo um número considerável de somatórios,
integrações e substituições) e se torna inviável para o processo de análise espectral de
um sinal de som. Em virtude desta complexidade, algoritmos de resolução da
transformada discreta de Fourier foram desenvolvidos e aperfeiçoados no decorrer do
tempo. O algoritmo mais conhecido de resolução desta transformada é o FFT. Com o
FFT foi possível calcular uma DFT com seu algoritmo de ordem de complexidade n²,
com um algoritmo de ordem de complexidade igual n.log2.n (CERNA e HARVEY,
2000).
Desta maneira a FFT reduz expressivamente os cálculos matemáticos usados para
realizar a análise de Fourier. Para fins explicativos, abaixo é apresentado, através da
figura 4.7, um gráfico com o tempo de processamento que a FFT consumiu conforme o
aumento de pontos numa escala de potencia de 2, em um teste realizado no emulador
SDK 3.0, utilizado variáveis ponto-flutuantes do tipo float.
36
Figura 4.7: Desempenho da FFT em relação ao aumento de pontos
É importante lembrar que a FFT não é um tipo diferente de transformada e sim uma
técnica que possibilita calcular a DFT de forma muito mais rápida e econômica.
Existem vários algoritmos usados para computar a FFT, entre eles podem ser citados
o radix-2, radix-8, Split-radix, e prime-factor. O mais conhecido destes é o radix-2, que
foi utilizado neste trabalho embora não seja o mais rápido. Devido a características do
algoritmo radix-2, o cálculo da FFT requisita um tamanho de vetor de entrada igual a
uma potencia de 2 (128, 256), o que reduz o custo computacional do algoritmo
diminuindo consideravelmente o número de operações (YOMA, 1993). Caso o tamanho
do vetor de entrada não seja uma potencia de 2 emprega-se a técnica de Zero Padding
nas janelas que simplesmente complementa o tamanho inicial do vetor para um tamanho
igual a uma potencia de 2 através da atribuição de zeros no final do vetor.
Uma vez que a transformada de Fourier é executada como saída tem-se a parte real
e a imaginária que correspondem as funções base utilizadas na FFT chamadas funções
cosseno e seno – ver figura 4.8.
Figura 4.8: Esquema de saída da FFT e a aplicação de sua inversa (JNECZKO, 2010)
Com estes vetores de saída da FFT pode-se calcular o espectro de magnitude, que
representa os valores de amplitude de toda componente de frequência, e um espectro de
fase que fornece o valor inicial da fase de cada componente de frequência ao longo da
0
20
40
60
80
100
120
140
128 256 512 1024 2048 4096 8192
Tem
po
(m
s)
Número de pontos de entrada
37
duração do sinal. O espectro de magnitudes pode ser obtido através da seguinte equação
(CERNA e HARVEY, 2000):
[ ] √ [ ] [ ]
e o espectro de fase:
[ ] ( [ ]
[ ])
Onde P é o espectro de fase, M é o espectro de magnitude, real é a parte real de
saída da FFT, imag é a parte imaginária de saída da FFT e n é o número de pontos de cada
janela imposta à da FFT.
4.2.2 Espectro de Potências
Cada índice do espectro de magnitude de saída da FFT representa uma frequência
com uma determinada amplitude. Contudo a primeira metade da magnitude é simétrica
em relação a sua segunda metade. Então descarta-se a segunda metade (CUADROS,
2007), resultando em um vetor de tamanho N/2.
O espectro de potências da FFT pode ser obtido simplesmente elevando o módulo da
magnitude ao quadrado:
[ ] | [ ]|
Onde Pw é o espectro de potências e M é o espectro de magnitude. O espectro de
potências terá então um tamanho N/2 devido à simetria do vetor de magnitude, onde N é
o tamanho inicial da janela aplicada a FFT, ou seja, o número de pontos da FFT.
4.3 Extração dos Parâmetros
Esta é a ultima etapa da extração de informação (SPHINX-4, 2008). Após a
realização de uma análise espectral do sinal de som, é preciso determinar um conjunto
de parâmetros capazes de diferenciar cada evento (CIPRIANO, 2001). A ideia básica da
extração de parâmetros é a de uma redução no volume de dados de forma a gerar apenas
um conjunto pequeno de parâmetros, porém contendo informações suficientes para a
caracterização do sinal. Para isso os parâmetros extraídos no processo de análise
espectral devem ser o máximo invariante de interferências externas, como ruído de
fundo, transdutor e locutor, reduzindo as taxas computacionais sem muita perda de
informação (CIPRIANO, 2001).
Neste trabalho foi utilizada a extração de parâmetros através dos coeficientes Mel-
Cepstrais (MFCC do inglês Mel-Frequency Cepstral Coefficients).
4.3.1 Coeficientes Mel-Cepstrais (MFCC)
De acordo com Petry (2002), Mel é “uma unidade de frequência ou picos percebidos
de um som”, amplamente utilizada no reconhecimento de voz e que procura aproximar-
se da sensitividade de frequências do ouvido humano.
38
A ideia da escala Mel surgiu em 1940, através de um experimento realizado por
Volkman e Stevens. Neste experimento foi arbitrado que 1000 Hz seriam iguais a 1000
Mels, e foi se alterando a frequência de um determinado sinal e perguntando as pessoas
que contribuíam para os testes quanto de aumento elas notavam na frequência (LIMA,
2000). Terminada esta pesquisa, foi comprovado então que a percepção do ouvido
humano para as frequências sonoras não segue uma escala linear (SILVA, 2009). Isso
pode ser melhor observado através da figura 4.9. Onde as escalas de frequência em Hz e
as em Mel são comparadas.
Figura 4.9 - Variação logarítmica da escala Mel em relação a Hz (LIMA, 2000)
Na escala Mel cada frequência linear medida em Hz associa-se um valor computado
por essa escala medido em Mels, ou seja, uma representação de frequência na escala
Mel. Seja f uma frequência física linear medida em Hz, pode-se calcular a representação
Mel denotado por m desta frequência pela equação abaixo:
(
)
E para transformar uma frequência Mel em uma frequência linear (Hz), aplica-se:
( (
) )
A técnica de extração de parâmetros MFCC baseia-se no uso do espectro de som
alterado segundo a escala Mel (SILVA, 2009). As etapas necessárias segundo a
metodologia descrita por Rabiner et al (1978), para a se adquirir os coeficientes MFCC
podem ser observadas através da figura 4.10.
39
Figura 4.10: Etapas da extração dos parâmetros
Para obtenção dos coeficientes MFCC, filtra-se cada janela de espectro de potencias
por um banco de filtros triangulares na escala Mel. Geralmente usa-se 20 filtros passa-
banda igualmente espaçados. Sendo 10 filtros uniformemente espaçados no eixo da
frequência até 1000 Hz e acima de 1000 Hz as faixas são distribuídas segundo uma
escala logarítmica (RABINER e JUANG, 1978) (PETRY, 2002) (LIMA, 2000) – ver
figura 4.11.
Figura 4.11: Exemplo de banco de 20 filtros triangulares espaçados de acordo com a
escala Mel (LIMA, 2000).
A aplicação do banco de filtros objetiva reduzir o espectro de potencias para uma
sequencia acumulada de valores de potencia, em bandas de frequência diferentes. Além
disso, aplicar os filtros também diminui a dimensão do vetor do espectro de potências
para um tamanho igual ao número de filtros adotado. Os elementos de um segmento que
passam por um mesmo filtro são somados para originar um único elemento para cada
filtro naquele segmento (RABINER e JUANG, 1978) (SPHINX-4, 2008).
As constantes que definem um banco de filtros são o número de filtros, a frequência
mínima, e a frequência máxima. A frequência mínima e a máxima determinam a faixa
de frequência abrangida pelo filtro. Essas frequências dependem do canal e a frequência
de amostragem que se esta usando (SPHINX-4, 2008). Para telefonia, uma vez que o
canal telefônico corresponde a um filtro passa-banda com frequências de corte de cerca
de 300Hz e 3700Hz, limites de uso mais amplo do que estes seriam resíduos de largura
de banda. Já para voz, a freqüência mínima de interresse geralmente é maior do que
100Hz, já que não há informação de som abaixo desta frequência (SPHINX-4, 2008).
40
Para a construção dos filtros Mel, considera-se que sejam distribuídos k filtros na
frequência de Nyquist sobre o espectro linear (espectro de potencias) P. As frequências
centrais fc destes filtros, distribuídas linearmente na escala Mel são calculadas segundo
as etapas a seguir (BOERSMA e WEENINK, 2001):
1. Cálculo da largura de banda de Nyquist na escala Mel:
(
)
2. Cálculo das frequências centrais dos filtros MFC:
( (
) )
3. Cálculo da função de transferência (H):
As funções do filtro passa-banda em escala mel são usadas de forma
triangular sobre uma escala de frequência linear f. A função do filtro depende
de três parâmetros: a fl que correspondente a menor freqüência, a frequência
fc que é a frequencia central e fh que é a maior frequência. Em uma escala
Mel, as distâncias fc-fl e fh-fc são as mesmas para cada filtro, sendo iguais
para a distância entre fc de filtros sucessivos. A função do filtro é expressa
pela seguinte equação (ZHOU e HAN, 2009) (BOERSMA e WEENINK,
2001):
[ ]
{
Onde k é o número de filtros e f é o índice correspondendo a frequência
proporcional abrangida pelo filtro sobre o espectro de potências.
4. Cálculo do valor acumulado de potencia no k-ésimo filtro:
O espectro de potencias P é multiplicado pelo banco de filtros Mel e
convertido para o espectro Mel. Onde o valor de energia acumulado para
cada filtro é dado por (ZHOU e HAN, 2009):
[ ] ∑ [ ] [ ]
Onde X[k] é a energia de saída do k-ésimo filtro triangular, P é o espectro de
potencias e N é o número de pontos da FFT.
41
Após estes procedimentos obtém-se um vetor contendo a energia de saída de
cada filtro em relação ao espectro de potências, representado pela figura 4.12
abaixo.
Figura 4.12: Energia de saída do banco de filtros
De posse da energia de saída de cada filtro triangular, calcula-se o logaritmo na base
10 (ln) da sequencia obtida através da equação abaixo objetivando obter os coeficientes
cepestros (ZHOU e HAN, 2009)(YOMA, 1993) (PETRY, 2002) (RABINER e JUANG,
1978).
[ ] [ ]
Então, aplica-se a transformada discreta do cosseno ou DCT (do inglês Discrete
Cossine Transform) sobre estes valores para gerar os coeficientes MFCC, pois foi
provado, que para uma sequencia de números reais a DCT é equivalente ao cálculo da
FFT inversa (SPHINX-4, 2008). A equação para efetuar a DCT é apresentada a seguir
(RABINER e JUANG, 1978) (LIMA, 2000):
[ ] ∑ [ ] (
)
Onde n representa o índice do coeficiente MFCC, k o índice do filtro, M o número
total de filtros e L o logaritmo da energia de saída k-ésimo filtro do banco.
Obtendo desta maneira os coeficientes MFCC. Normalmente como processo
adicional e observado em (SPHINX-4, 2008)(CUADROS, 2007) (CHEN, PALIWAL,
et al., 2005) é descartado o primeiro coeficiente MFCC obtido, pois este geralmente
pode carregar muita informação do meio de transmissão, desnecessária para o
reconhecimento.
42
5 RECONHECIMENTO
O sinal de som, após passar pela fase de extração de informação, é expresso em um
conjunto de parâmetros que representam informações deste mesmo sinal. A partir disso,
pode-se iniciar a etapa de reconhecimento utilizando alguma técnica capaz de
reconhecer os parâmetros gerados e definidos como padrões em relação a um conjuntos
de parâmetros MFCC representado o sinal a ser reconhecido.
Neste trabalho entende-se por padrão um conjunto de coeficientes MFCC extraídos
do processo de extração de informação de um sinal de som que se deseja definir como
padrão.
Uma questão chave no reconhecimento de som é como comparar os padrões de som
pela sua similaridade (ou equivalência, a distância entre os padrões). Dependendo do
tipo de sistema de reconhecimento, a comparação de padrões pode ter uma grande gama
de variações (RABINER e JUANG, 1978).
O desempenho dos sistemas de reconhecimento gira em torno do número de padrões
estabelecidos para comparação. Quanto maior for o número de padrões a serem
comparados, maior será a requisição de processamento pelo sistema e
consequentemente maior será o tempo de reconhecimento (OLIVEIRA, 2002). Em
dispositivos portáteis este problema se agrava, principalmente o de processamento (já
que a capacidade de armazenamento está mais flexível atualmente), então torna-se
necessário contornar este problema com técnicas que ofereçam baixo custo
computacional mas também permitem um reconhecimento confiável.
Com base nos fatores citados acima, este trabalho adotou para o reconhecimento, a
Dinamic Time Warping (DTW), cujo principal objetivo é determinar distâncias (através
do uso em seu algoritmo da distância Euclidiana) dos padrões armazenados. Sua
principal vantagem é o baixo custo computacional e a capacidade de eliminar variações
temporais entre as elocuções. Conforme visto em Yoma (YOMA, 1993), a DTW se
encaixa perfeitamente no contexto de reconhecimento de palavras isoladas dependente
de locutor.
5.1 Dinamic Time Warping (DTW)
A Dynamic Time Warping (DTW), ou Modelagem Determinística é um algoritmo
para calcular o caminho ótimo entre duas séries temporais (FURTUNĂ, 2008). O
algoritmo da DTW é introduzido para contornar o problema causado pelas variações de
velocidade de pronunciação de palavras como pode ser observado na figura 5.1
(YOMA, 1993). Em sua versão “solo” a DTW surgiu no final da década de 70, sendo
que também é utilizado hoje em dia nos HMM (Modelos Ocultos de Markov), onde é
mais conhecido como algoritmo de decodificação de Viterbi.
43
Figura 5.1: Exemplo de diferença temporal
Esta modelagem utiliza os parâmetros do sinal de voz como padrões de teste e
referencia, junto com alguma métrica apropriada para a comparação dos mesmos, tendo
baixo custo (CIPRIANO, 2001). Uma frequente métrica utilizada para comparação é o
calculo de distância vetorial entre os padrões (FURTUNĂ, 2008). Existem algumas
técnicas para o cálculo de distância vetorial, tais como a distância de Malahanobis
(PETRY, ZANUT e BARONE, 2000), a distância de Bhattacharyya (PETRY, 2002) e a
distância Euclidiana (FURTUNĂ, 2008), esta última, é a mais comumente usada no
reconhecimento de voz devido ao seu baixo custo computacional e simplicidade de
implementação.
Considerando-se dois padrões de som R e T com N e M quadros de coeficientes
MFCC cada, correspondendo ao padrão de referencia e ao padrão de teste,
respectivamente. Os padrões R e T podem ser representados, depois de uma adequada
extração de informação, por sequencias espectrais, da seguinte maneira:
onde e , n = 1,...,N e m = 1,...M, são os vetores de parâmetros de características
acústicas (CIPRIANO, 2001). Aplicando o DTW as sequencias R e T são comprimidas
ao longo do eixo temporal resultante para se obter um alinhamento não-linear
eliminando a diferença temporal. Esse processo pode ser observado de forma abstraída
pela figura 5.2.
Figura 5.2: Alinhamento não-linear gerado pela DTW (CIPRIANO, 2001).
44
Para este processo os quadros R e T são representados em um plano n-m, esboçados
na figura 5.3, e as distâncias temporais são descritas por uma sequencia de pontos
representados em uma matriz de distâncias mínima (CIPRIANO, 2001).
Figura 5.3: Plano temporal dos padrões R e T (CIPRIANO, 2001).
O objetivo do DTW então é encontrar o menor caminho ou caminho ótimo através
da menor distância da matriz de distâncias mínimas (FURTUNĂ, 2008). As distâncias
então são somadas e obtém-se uma distância mínima geral.
Após a aquisição das distâncias entre o padrão de teste e todos os padrões de
referência, como visto em (YOMA, 1993) pode-se calcular os coeficientes de
seletividade de reconhecimento, para verificar se o reconhecimento foi bem sucedido ou
não.
5.1.1 Coeficientes de Seletividade de Reconhecimento
Yoma (1993) descreve detalhadamente em seu trabalho os coeficientes de
seletividade de reconhecimento obtidos das distâncias da DTW. Estes coeficientes
servem para quantificar e qualificar uma determinada distância em relação às outras
distâncias obtidas e assim classificar se o reconhecimento pode ser considerado correto
ou não.
De modo geral a menor distância encontrada tende a ser a palavra reconhecida,
porém, quando a palavra de teste pronunciada não corresponde a nenhuma palavra
contida no banco de padrões, mesmo a menor distância não pode ser considerada, pois
estaria errada.
Este problema pode ser observado na figura 5.4.
45
Figura 5.4 - Exemplo de erro de reconhecimento utilizando somente as distâncias
mínimas da DTW
Como exposto na figura 5.4, este exemplo acarretaria no reconhecimento da palavra
“um”, ou mesmo se a elocução de teste no lugar de “cinco” fosse, por exemplo, “zero”,
mas pronunciado de uma maneira não muito clara, mesmo assim, poderia acarretar erros
de reconhecimento devido às condições acústicas da palavra de teste. Baseado em
Yoma (1993) este trabalho adota então uma solução para analisar a qualidade do
reconhecimento através dos coeficientes de seletividade definidos por:
C1 = menor distância entre a elocução de teste e as elocuções de referência;
C2= diferença entre a segunda menor distância e C1;
C3 = diferença entre as médias das distâncias e a menor distância entre a
elocução de teste e as de referência que não pertencem a mesma palavra da
elocução de teste ou que não pertença ao padrão que resultou na menor
distância geralmente sendo associada a segunda menor distância.
Sendo assim, quanto menor for C1 melhor a qualidade do reconhecimento e quanto
maior forem C2 e C3 maior a qualidade do reconhecimento. Em Yoma (YOMA, 1993)
também são definidos outros dois coeficientes de seletividade: Sel1 e Sel2, pois as
parametrizações geradas por aquele trabalho geraram coeficientes numericamente
diferentes, dado que a distância final da DTW era a soma das distâncias entre os
quadros ao longo do caminho ótimo de comparação.
Esta característica encontra em Yoma (YOMA, 1993), é a mesma presente neste
trabalho, ou seja, as distâncias resultantes da aplicação da DTW em vez de
caracterizarem um número maior que 0 e menor que 9, são resultado da soma das
distâncias do caminho ótimo, resultando em valores fora deste padrão. Então adota-se a
mesma abordagem encontrada em Yoma (YOMA, 1993) definindo dois novos
coeficientes:
Dado que a DTW determina a distância entre duas elocuções por meio da soma das
distâncias entre quadros ao longo do caminho ótimo de comparação, e que esta soma é
46
normalizada em relação à duração dos padrões de teste e de referencia, é muito razoável
supor que os coeficientes acima são uma boa mediada da qualidade de parametrização.
Isto porque a normalização C2 e C3 em relação a C1 na determinação de Sel1 e Sel2
elimina as diferenças numéricas entre as diferentes parametrizações e permite a
comparação direta dos diferentes procedimentos de extração de parâmetros. Da maneira
em que Sel1 e Sel2 foram definidos quanto maiores eles forem melhor será a qualidade
ou seletividade do reconhecimento.
5.2 Distância Euclidiana
A distância euclidiana é uma métrica para computar a semelhança através da
distância entre duas distribuições vetoriais. Quanto menor for a distância calculada,
mais semelhantes são os padrões comparados. A distância euclidiana pode ser obtida
para duas sequencias através da seguinte equação:
∑| [ ] [ ]|
Onde x e y são duas sequencias de mesmo tamanho N.
Embora a distância euclidiana não seja usada diretamente neste trabalho ela é
aplicada internamente no algoritmo de DTW.
5.3 Coeficiente de Correlação de Pearson
O coeficiente de correlação de Pearson é uma medida do grau de relação linear entre
duas variáveis quantitativas. Este coeficiente varia entre os valores -1 e 1. O valor 0
(zero) significa que não há relação linear, o valor 1 indica uma relação linear perfeita e
o valor -1 também indica uma relação linear perfeita mas inversa, ou seja quando uma
das variáveis aumenta a outra diminui. Quanto mais próximo estiver de 1 ou -1, mais
forte é a associação linear entre as duas variáveis (MEDSTATWEB, 2009).
O coeficiente de correlação de Pearson é normalmente representado pela letra r e a
sua fórmula de cálculo é a apresentada abaixo (MEDSTATWEB, 2009):
∑ ̅ ̅
√ ∑ ̅ ∑ ̅
Neste trabalho o coeficiente de correlação de Pearson é utilizado somente para o
processo de treinamento de amostras (descrito na seção 6.8) que poderão ser definidas
como padrão, pois tem a vantagem de apresentar um baixo custo, e aliado à analise da
duração de tempo entre as elocuções tornou-se uma ferramenta útil no processo de
treinamento.
47
6 O FRAMEWORK SRM
De um modo geral o SRM (Sound Recognizer ME) é um Framework para
reconhecimento de sons em dispositivos móveis. Mais especificamente, o SRM permite
dois tipos de reconhecimento, o reconhecimento de palavras isoladas dependente de
locutor e o reconhecimento de sons abstratos.
6.1 Capacidades
Nas subseções a seguir são descritas as capacidades disponibilizadas por este
framework
6.1.1 Reconhecimento de palavras isoladas dependente de locutor
Este tipo de reconhecimento habilita aplicações ao reconhecimento de palavras
isoladas dependentes de locutor. Esta capacidade foi definida principalmente devido a
limitações impostas atualmente pelos dispositivos móveis. Pois no reconhecimento
independente de locutor, se faz necessário um banco de amostras que são utilizadas para
um prévio treinamento para cada padrão (palavra) do sistema de reconhecimento, estas
amostras caracterizam-se normalmente pela diferenciação entre idade e sexo para a
mesma palavra, o que requisita um maior processamento e um maior espaço para o
armazenamento destas respectivas amostras.
Outro fator muito importante na escolha quanto à dependência de locutor do SRM
aborda um contexto mais pessoal, pois como este framework é voltado para dispositivos
móveis, o reconhecimento geralmente se aplicará sobre ações que são geradas por
eventos mais pessoais correspondentes a cada usuário do dispositivo. Este fator pode ser
inconveniente caso o reconhecimento independente de locutor seja utilizado, sendo que
nestas circunstancias o usuário não deseje que elocuções de outras pessoas sejam
reconhecidas em seu dispositivo móvel.
6.1.2 Reconhecimento de som
Outra característica do SRM é integrar ao reconhecimento sons abstratos que não
caracterizam uma palavra em si. Entre estes sons pode-se exemplificar um estalar de
dedos, campainha tocando, entre outros sons.
6.1.3 Vocabulário pequeno
Com base em resultados obtidos nos testes, o SRM abrange um reconhecimento
sobre um vocabulário pequeno (menor ou igual a 20 padrões para reconhecimento).
Contudo este fator não limita a utilização do framework para um reconhecimento
envolvendo mais que 20 padrões, entretanto os desempenhos de reconhecimento nestas
48
circunstancias não receberam uma atenção rigorosa nos testes e podem apresentar
resultados desconhecidos.
Evidentemente quanto maior for o vocabulário menor também será a precisão e
maior o consumo de recursos computacionais. Através da figura 6.1 pode-se verificar os
tempo de processamento conforme o aumento do vocabulário.
Figura 6.1: Tempo de processamento para o reconhecimento em relação ao número de
padrões
Através da figura 6.1 pode-se analisar o crescimento real e o linear de um teste
simples de 1 a 20 padrões realizado em um dispositivo móvel com processador
operando a frequência de 434 MHz. Onde incialmente, com um padrão no banco de
padrões, o sistema leva em média 400 milissegundos para efetuar todos os processos
para o reconhecimento e chega a 800 milissegundos com 20 padrões. Estes resultados
remetem a um crescimento em média de 2,5% no tempo de reconhecimento para cada
padrão adicionado no banco.
6.1.4 Reconhecimento em Terminal
O SRM é um framework desenvolvido com o intuito de possibilitar o
reconhecimento de palavras e de sons inteiramente em um terminal móvel, sem a
necessidade de se comunicar com um servidor para efetuar algum processamento de
sinal ou reconhecimento.
Porém outras modalidades de reconhecimento (distribuído, em rede) podem ser
futuramente desenvolvidas com base no SRM permitindo o uso de técnicas que
permitam outros tipos reconhecimento, tais como, o reconhecimento independente de
locutor, uma inclusão de uma metodologia de treinamento mais robusta, entre outros.
0
100
200
300
400
500
600
700
800
900
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Te
mp
o (
mili
sse
gun
do
s)
Padrões
49
6.2 Requisitos Mínimos
Os requisitos mínimos para utilização do SRM em um dispositivo móvel são:
CLDC 1.1;
MIDP 2.0;
Suporte a codificação PCM (encoding PCM);
Processador com uma frequência acima de 300 MHz.
Espaço em memória persistente de 1,5 Megabytes
Os primeiros dois requisitos mínimos apresentados acima (CLDC 1.1 e MIDP 2.0 )
dizem respeito a configuração Java ME presente no dispositivo, atualmente esta
configuração apresenta-se amplamente difundida entre a maioria dos dispositivos
móveis não se tornando uma limitação inconveniente. Já o requisito sobre o suporte a
codificação PCM é referente ao tipo de codificação de áudio suportado pelo dispositivo,
este requisito apresenta certas limitações pois alguns dispositivos atualmente utilizam o
formato AMR para seus arquivos de áudio, sendo necessária uma atenção maior sobre
este requisito no desenvolvimento de aplicações. O requisito sobre processamento foi
definido através dos testes, onde se definiu a frequência de 300 MHz, como sendo a
mínima de processamento móvel tolerável para se poder trabalhar com tempos de
reconhecimento aceitáveis.
Já a limitação quanto a memória apresenta-se de uma forma mais dinâmica, pois
varia de acordo com o tempo de cada gravação e a quantidade de padrões, sendo assim,
foi estabelecido um requisito mínimo com base no tamanho requisitado para sua
incorporação a algum aplicativo, e a partir deste valor somou-se mais 300 Kilobyte
correspondendo ao tamanho máximo cujo suporte é obrigatório pela especificação
Mobile Service Architecture (DOEDERLEIN, 2007), e mais 1 Megabyte
correspondendo a um espaço seguro para o armazenamento de um único padrão,
totalizando em um requisito mínimo de 1,5 Megabytes .
6.2.1 Estrutura do Framework
De um modo geral SRM utiliza diretamente as funcionalidades da MMAPI, as
técnicas que compões o RMS, processamento digital de sinais de áudio e
reconhecimento de padrões. A figura 6.2 expõe esta estrutura.
50
Figura 6.2: Estrutura geral do SRM
Conforme a estrutura do SRM apresentada acima é possível identificar as principais
áreas envolvidas para a composição do framework SRM. É importante registrar que as
técnicas de reconhecimento de voz apresentadas, são técnicas conceituais que foram
implementadas e abstraídas neste trabalho, já o uso da MMAPI e do RMS são
funcionalidades que se encontram prontas e foram integradas a este desenvolvimento.
6.3 Descrição da Implementação
A implementação do SRM é dividida em dois grandes blocos, o front-end e back-
end. No front-end ocorre todo o processamento do sinal de som, implementado a
extração de informação descrita no capitulo 4, já o back-end, responsável pelo
reconhecimento em si, implementa o reconhecimento por meio das técnicas expostas no
capítulo 5. Esta estruturação pode ser
Na subseção 6.4.1 são detalhadas as técnicas de pré-processamento propostas por
este trabalho. E nas subseções restantes é exposta a descrição sequencial e gradativa dos
blocos de front-end e back-end descrevendo detalhadamente os parâmetros utilizados no
desenvolvimento do SRM.
51
6.3.1 Técnicas Propostas
No desenvolvimento deste trabalho foi necessário desenvolver duas técnicas
adicionais para o pré-processamento do sinal de áudio capturado. Estas técnicas se
encaixam no contexto dos dispositivos móveis pois permitem elaborar soluções que
auxiliam na diminuição do custo computacional envolvido para todo o processo de
reconhecimento, além de se apresentarem eficientes para um acréscimo na qualidade de
parametrização da fase de extração de informação.
A primeira técnica chamada Inversão de Sinal é originalmente uma proposta deste
trabalho para a representação do sinal Wave. E a segunda técnica é baseada em técnicas
já existentes de recorte e foi desenvolvida visando diminuir o consumo de recursos
presente no processo de detecção de extremos.
6.3.1.1 Inversão de Sinal (IS)
Como pode ser entendido no capítulo 2, o sinal de 8 bits por amostra, após ser
digitalizado, encontra-se representado com valores de -128 a +127, caracterizando 256
níveis de representação. Porém o sinal de saída do conversor A/D apresentava
representações bruscas de amplitude mesmo em condições de silêncio, impedindo, por
exemplo, o estabelecimento das linhas de silêncio (descritas na detecção de extremos)
ao sinal e assim identificar o inicio e fim de uma elocução. Então surgiu a necessidade
de desenvolver uma técnica que objetivasse regular os pulsos contidos no arquivo Wave.
A Inversão de Sinal é uma proposta deste trabalho e consiste na aplicação de alguns
cálculos que permitem trabalhar com o sinal em uma representação de amplitude mais
clara e estável. A Inversão de Sinal pode ser aplicada a um sinal através da seguinte
equação
[ ] { [ ] [ ]
[ ] [ ]
[ ] ( [ ] )
Onde Is é o resultado da inversão de sinal, s é o sinal de som removido o seu ciclo
negativo (TAFNER, 1996), e n é o número de amostras.
A lógica por traz da inversão de sinal é muito simples e consiste em tornar um pulso
muito alto ou muito baixo de amplitude em um valor próximo a zero, os pulsos
intermediários, que realmente contém a informação do sinal de som, são então
superestimados, e assim se destacam na representação do sinal como poder ser
observado na figura 6.3.
52
Figura 6.3: Trecho da palavra “teste” antes e depois da inversão de sinal
Na figura 6.3, observa-se a representação gráfica antes e depois da Inversão de
Sinal, e pode-se concluir claramente que o sinal está representado em um aspecto mais
constante e estável em nível de amplitude, maximizando as variações reais do sinal.
Esta técnica se mostrou eficaz no processo de detecção de extremos (descrito
abaixo), e no processo de extração de parâmetros, onde a Inversão de Sinal é empregada
no processo convencional de extração dos coeficientes MFCC. Para se verificar mais
precisamente os resultados obtidos nos testes comparativos sobre a Inversão de Sinal
pode-se consultar o capitulo 7.
6.3.1.2 Algoritmo de Detecção de Extremos
Em um sinal de som, a identificação dos extremos do som, ou seja, seu começo e
fim são fundamentais para um reconhecimento mais preciso e principalmente para
ganhos de desempenho.
Em Lima (2000), são apresentadas três técnicas de recorte que correspondem a
técnicas tradicionais de identificação de extremos. O algoritmo 1 descrito em Lima e
proposto por Rabiner e Sambur (1975) consiste em detectar onde se inicia e termina a
elocução utilizando a taxa de cruzamento por zero, energia e estatísticas em ruído
ambiente. Este algoritmo é um dos mais utilizados e simples de serem compreendidos, e
os autores também afirmam que ele é simples, fácil e preciso. No segundo algoritmo
também proposto com a autoria parcial de Rabiner foi proposto ao se verificar que o
algoritmo 1 se mostrava pouco eficiente para baixas frequências de amostragem, então
este algoritmo utiliza somente a energia computada em cada janela retangular, e através
de um processo um pouco mais refinado encontra-se o inicio e o fim da elocução. O
algoritmo 3 proposto por Andrade et al (1999), utiliza o método k-médias modificado
para realizar a detecção dos extremos das palavras, e Lima ainda propõe um quarto
algoritmo baseando nos conceitos utilizados pelos algoritmos 2 e 3.
De fato, para o contexto móvel, o primeiro algoritmo se mostra mais interessante,
pois é o mais rápido dos três, contudo como dito anteriormente, não se apresenta
53
eficiente em baixas taxas de amostragem. Os três outros algoritmos apresentam
propostas interessantes para o problema em questão, mas ambos ainda requisitam um
número de cálculos considerável para um processamento móvel. Então após um estudo
destes quatro algoritmos foi decidido que seria necessário desenvolver um quinto
algoritmo para a detecção não só de palavras, mas de sons. Este algoritmo deveria ser
rápido e confiável, e não deveria confundir um som, por exemplo, um estalar de dedos,
como ruído, problema este que poderia ser causado utilizando algum dos quatros
algoritmos descrito, pois ambos têm a intenção de remover os “clicks” (estalar da língua
ou dos lábios) do sinal (LIMA, 2000), isso afeta diretamente no reconhecimento de som,
pois o algoritmo poderia confundir um estalar de dedos como sendo um click e o
eliminaria.
A ideia do algoritmo proposto é - juntamente com a técnica de Inversão de Sinal –
estabelecer limites de amplitude para detectar o inicio e fim do som como mostrado na
figura 6.4. Contudo esta amplitude como é transformada pelo processo de Inversão de
Sinal, permite uma interpretação mais clara e constante do sinal.
Uma vantagem computacional em relação aos outros algoritmos é a ausência da
aplicação prévia de janelas retangulares ao sinal.
Figura 6.4: Linha imaginária de limite de silêncio
Na figura 6.4, pode-se ver uma linha imaginária definindo os limites de silêncio
sobre as amplitudes resultantes da aplicação da IS, esse processo também ocorre
reversamente para detectar o final do som.
Abaixo pode ser observado o pseudo-algoritmo para detecção de som (palavras e
sons abstratos) proposto neste trabalho:
1) Aplicar a técnica de inversão de sinal;
2) Definir o limite de silencio.
3) Percorrer o sinal procurando por variações de magnitude:
54
a) Em ordem crescente, caso um par de amplitudes encontra-se acima do limite
de silêncio: início do som.
b) Em ordem decrescente, caso um par de amplitudes encontra-se acima do
limite de silêncio: fim do som.
4) Caso não houver inicio do som, retornar [0];
5) Caso contrário:
a) Diminuir o início de som em 37.5 milissegundos;
b) Aumentar o fim do som em 100 milissegundos
c) Recortar do som original uma janela com os índices de inicio e fim de som.
d) Retornar o som recortado.
O limite de silêncio é definido com base em um número inteiro passado como
parâmetro para a função de remoção de silencio, este número pode variar de 1 a 4 e
segue a escala de níveis de sensibilidade. Normalmente usa-se um valor de sensibilidade
entre 2 e 3, mas estes valores podem ser alterados conforme a escala de sensibilidade a
seguir proposta neste trabalho.
1 – Ambiente ruidoso, sensibilidade muito baixa;
2 – Ambiente normal, sensibilidade média;
3 – Ambiente normal, sensibilidade alta;
4 – Ambiente silencioso, sensibilidade muito alta;
O decréscimo de 37.5 milissegundos e o acréscimo de 100 milissegundos no inicio e
fim do som respectivamente, foi definido com base em testes onde se constatou que
algumas palavras (da língua portuguesa) são pronunciadas com um começo ou fim
“mudo”, e esta margem permite que o algoritmo faça um recorte mais suave, não
contendo um início ou fim brusco da palavra ou som.
O algoritmo de detecção de extremos de um modo geral mostrou-se eficiente no
recorte dos sons, a seguir pode-se analisar um comparativo utilizando algumas palavras
e sons como o tempo do recorte feito e o tempo de processamento requisitado em
milissegundos pelo algoritmo.
Tabela 6.1: Tempos de recorte em milissegundos do algoritmo de detecção de extremos
e o tempo de processamento obtido no teste elaborado no emulador SDK 3.0
Palavras Tempo Palavra(ms) Tempo Process.(ms)
Teste 636.7 11
Um 419 11
Primeiro 837.7 12
Calculadora 1144.1 10
Mesa 673.5 11
Televisão 918.3 10
Estalar de dedo 143.8 11
Assovio 452.5 12
55
Neste comparativo pode-se observar a duração do tempo de cada palavra após passar
pelo algoritmo de remoção de silêncio, pela Inversão de Sinal e pela remoção do
cabeçalho Wave para uma gravação de 2 segundos.
Os tempos das palavras e sons estão claramente diferenciados e estes tempos são
diretamente proporcionais ao tempo consumido pela extração de informação. Já o tempo
de processamento fica em média em 11 milissegundos, pois é analisado todo o sinal na
detecção de extremos, as pequenas variações mostradas neste comparativo ocorrem
devido a tomada ou não de decisões por condições impostas pela equação do algoritmo
de Inversão de Sinal.
6.3.2 Front-End
Nesta subseção será descrita a implementação de forma gradativa e sequencial da
extração de informação do sinal. Esta sequencia pode ser observada na figura 6.5
abaixo:
Figura 6.5: Etapas implementadas no bloco front-end caracterizando a extração de
informação
Inicialmente a captura do áudio no dispositivo é realizada pela função recordSound,
nela são implementadas funcionalidades da MMAPI. Para a execução do áudio é
implementada a função playSound. Lembrando que para a execução de áudio, o mesmo
deve conter o cabeçalho Wave.
Para se descobrir quais os tipos de arquivo suportados pelo dispositivo utiliza-se a
função whatSupport, nela será mostrado na saída do compilador utilizado, os tipos de
extensões que o dispositivo suporta, por exemplo: vídeo/mpeg, audio/x-wav, etc. Por
praticidade esta funcionalidade já foi incorporada ao método playSound.
Após a captura do som obtém-se um arquivo de áudio no formato Wave. Este
arquivo contém um cabeçalho que não tem utilidade no processo de extração de
informação do sinal, e se presente pode provocar erros de reconhecimento devido ao
fato de se estar analisando dados que não representam um sinal de som propriamente.
Então é conveniente sua remoção que pode ser feita criando um novo vetor de bytes
e atribuindo a ele o vetor original Wave iniciando do índice calculado através da
formula: . A figura 6.6 esclarece esse processo.
56
Figura 6.6: Processo de remoção do cabeçalho Wave
A remoção do cabeçalho pode ser feita utilizando a função removeHeader, ou para
agilizar o processo o mesmo foi inserido juntamente com a função que implementa o
algoritmo de detecção de extremos removeHeaderAndSilence, pois concluiu-se que toda
vez que fosse necessário identificar um som em um arquivo de áudio o mesmo
obrigatoriamente deveria estar isento do seu cabeçalho caso contrário iria acarretar erros
na detecção do inicio do som.
Após a detecção de extremos a representação do sinal é modificada através da
aplicação do processo de Inversão de Sinal.
Então, após o sinal de som passar pelos processos descritos anteriormente aplica-se a
ele o filtro pré-ênfase através da função preEnfase. O coeficiente de pré-ênfase utilizado
neste Framework é fixado em 0.95, com base em diversas obras publicadas na área de
reconhecimento de voz, tais como (SILVA, 2009) (PETRY, 2002), onde foi utilizado o
mesmo valor para este coeficiente e obteve-se índices satisfatórios de reconhecimento.
Com o sinal já pré-enfatizado o próximo passo consiste na aplicação das janelas de
Hamming. Para aplicar o janelamento cria-se um nova instância da classe
HammingWindow, e em seguida usa-se a função desta classe chamada
getHammingWindow. Também pode-se obter o número de janelas resultantes para certo
sinal pelo método getNumWindows.
A etapa seguinte – já de posse das janelas de Hamming do sinal – é aplicar a cada
janela a Transformada Rápida de Fourier. No SRM a FFT pode ser aplicada ao sinal
através da instanciação da classe FastFourierTransform que computa a FFT através do
algoritmo radix-2. O radix-2 é representado por uma função que recebe a parte real e
imaginária de cada janela. Como até o momento não se tem a parte imaginária é passada
somente a parte real, que corresponde ao sinal em si, e a parte imaginária recebe zero
(OLIVEIRA, 2002).
Após a aplicação da FFT pode-se obter o espectro de magnitude de cada janela
através do método getMagn. Como resultado obtém-se um vetor no domínio de
frequências onde cada elemento corresponde a uma amplitude de frequência. Como o
vetor de magnitudes tem sua metade simétrica em relação a sua segunda metade, é
automaticamente (na função getMagn), descartada a segunda parte deste vetor
resultando em um vetor com tamanho N/2 onde N é o número de amostras de cada
janela.
De posse do vetor de magnitudes é possível identificar a frequência através da
procura pela maior amplitude do vetor, e como se está em um domínio de frequências
57
cada índice do vetor representa uma frequência, logo para transformar o índice em uma
frequência do sinal, foi utilizada a seguinte equação (HERATH e RAGEL, 2007):
(
)
Onde f é a frequência, s é a taxa de amostragem, i é o índice que contém a maior
amplitude do vetor de magnitudes e N é o número de pontos da FFT, logo N é o mesmo
que o número de amostras por janela. Neste framework a equação acima pode ser
calculada através da função getFrequency presente na classe FastFourierTransform.
Com aplicação das janelas de Hamming e FFT é possível distinguir a frequência
predominante em cada quadro e deste modo criar um vetor de frequências para todo
sinal. Neste trabalho foi experimentado um reconhecimento comparando os vetores de
frequências de cada sinal com o sinal de teste. Embora esta técnica permita capturar a
frequência para cada quadro de som, podendo ser aplicada em afinadores musicais
eletrônicos (HERATH e RAGEL, 2007), ela apresentou um baixo índice de acertos no
reconhecimento de palavras não superando 65% de acertos.
Então, de posse do vetor de magnitudes pode-se obter espectro de potências
calculado através da função getPowerSpectrum. Com o espectro de potências calculado
pode-se iniciar a extração dos coeficientes MFCC que neste trabalho baseia-se de
extração dos coeficientes MFCC descrita por Rabiner (RABINER e JUANG, 1978).
Para a obtenção dos coeficientes MFCC primeiramente constrói-se um banco de
filtros triangulares em escala Mel. Para a construção de tal banco de filtros, deve-se
utilizar a função buildFilterBank informando a configuração desejada dos filtros, e
como retorno, obtém-se um vetor do tipo MelFilter, onde cada elemento corresponde a
um filtro. Para a aplicação do espectro de potencias aos filtros basta multiplicar cada
filtro por um quadro de espectro de potencias, esse procedimento pode ser obtido
através da função filterOutput passado como parâmetro o espectro de potências. Neste
momento obtêm-se como retorno as energias de saída de cada filtro sobre o espectro de
potencias, denominadas a partir deste momento de MFFO (Mel Frequency Filter
Output).
A extração dos coeficientes MFCC pode ser obtida passando os coeficientes MFFO,
como referencia para a função calculateMFCC. Nesta função é aplicado o logaritmo na
base 10 (ln) aos coeficientes MFFO, em seguida estes coeficientes são submetidos ao
cálculo da DCT, para a obtenção enfim dos coeficientes Mel-Cepstrais.
A implementação do banco de filtros em escala Mel e do cálculo da DCT neste
trabalho foram baseadas nas classes MelFrequencyFilterBank, MelFilter e
DiscreteCosineTransform, ambas pertencentes ao Framework Sphinx-4 da Universidade
de Carnegie Mellon (2002-2008). O Framework Sphinx-4 é um sistema estado da arte
de reconhecimento de voz escrito inteiramente na linguagem de programação Java SE e
não é destinado a aplicação em ambientes móveis por meio da linguagem Java ME. O
Sphinx-4 foi criado através de uma colaboração conjunta entre o grupo Sphinx da
Carnegie Mellon University, Sun Microsystems Laboratories, Mitsubishi Electric
Research Labs (MERL), e Hewlett Packard (HP), com contribuições da Universidade
58
da Califórnia em Santa Cruz (UCSC) e o Massachusetts Institute of Technology (MIT)
(SPHINX-4, 2008).
6.3.3 Back-End
Nesta subseção será descrita a implementação de forma gradativa do
reconhecimento implementado. A figura 6.7 expõe esta implementação definindo o
bloco back-end:
Figura 6.7: Etapas implementadas no bloco back-end caracterizando o reconhecimento
Ao se definir uma amostra como padrão (utilizando o método toPattern),
primeiramente é feito o processo de extração da informação do sinal obtendo os
coeficientes MFCC por meio da classe ExtractInformation que em seguida – ainda
internamente na função toPattern – são armazenados na memória do dispositivo em um
formato linear, ou seja, em vez de armazenado os coeficientes MFCC separadamente
para cada janela em um formato matricial, estes são armazenados por meio de um vetor
unidimensional do tipo float que conterá um ID de record store.
Toda vez que é efetuado um reconhecimento através da classe Recognizer com uma
elocução de teste, esta passa inicialmente pelo processo de extração de informação e em
seguida é imposta ao reconhecimento através da comparação com os MFCCs do banco
de padrões.
Os coeficientes armazenados linearmente no banco são então reconvertidos em um
formato matricial, onde cada linha da matriz contém os coeficientes de cada janela do
som/padrão. Em seguida estes coeficientes são impostos para comparação com a
elocução de teste através da DTW por meio do método dinamicTimeWarp que contém o
algoritmo da DTW baseado na implementação de Fortunã (FURTUNĂ, 2008).
A saída da DTW corresponde a uma distância que nada mais é que a diferença entre
as duas séries temporais: a de teste e a padrão. Então de posse de todas as distâncias
entre a elocução de teste e todas as elocuções padrão, estas distâncias são utilizadas para
59
se obter os coeficientes de seletividade de reconhecimento através da função
isValidRecognize. Para a obtenção dos coeficientes de seletividade primeiramente
ordena-se todas as distância obtidas através da função insertionSort que utiliza o
algoritmo de ordenação de mesmo nome. Então já com as distâncias ordenadas são
definidos os coeficientes C1, C2 e C3 e em seguida são calculados os coeficientes Sel1 e
Sel2 descritos na seção 4.1.1. Em seguida ainda dentro da função isValidRecognize são
definidos valores limites (descritos no capitulo 7) para Sel1 e Sel2, caso estes coeficientes
atendam estes valores, há o reconhecimento retornando verdadeiro e em seguida a
função startRecognizer que abriga todo o processo de reconhecimento inclusive a
chamada da função isValidRecognize, retorna o ID do padrão reconhecido, caso
contrário é retornado falso e a função startRecognizer retorna um estado de não
reconhecimento através do valor “-1”.
6.4 Diagrama de Classes
A figura 6.8 apresentada abaixo expõe o diagrama de classes completo do SRM,
juntamente com a divisão por pacotes.
Figura 6.8: Diagrama de classe do Framework SRM
O framework SRM contém 11 classes divididas em 3 pacotes mais a classe
GraphicWave. Como apresentado na figura 6.8 além do diagrama de classes pode-se
observar a presença da biblioteca MathC. Esta biblioteca foi utilizada para a realização
de funções matemáticas que não são implementadas pela biblioteca Math genuína do
Java ME.
A seguir serão detalhados cada pacote e classe do SRM juntamente com seu
diagrama de classes.
60
6.4.1 Classe GraphicWave
A classe GraphicWave foi um proposta e uma consequência do desenvolvimento
deste framework, ela estende a classe Canvas para prover uma representação gráfica do
sinal de som no formato Wave. Esta classe foi de extrema utilidade na elaboração do
SRM e por isso foi incorporada ao produto final para facilitar a compreensão e também
servir como apoio ao desenvolvimento de futuros trabalhos e aplicações que integram o
SRM. Na figura 6.9 pode-se ver duas telas retiradas do emulador SDK 3.0 do netbeans
geradas por esta classe.
Figura 6.9: Telas exemplos da classe GraphicWave contendo a representação de um
sinal PCM no formato Wave com 8 bits por amostra
A representação gráfica disponibilizada na classe GraphicWave como observado na
figura 6.9 exibe os 256 níveis de quantização padrão de 8 bits do SRM. O sinal no
exemplo da figura 6.9 já passou pela etapa de Inversão de Sinal, mas pode ser
representado graficamente em sua forma original como ilustrado na figura 6.3, e
também em outras variações que permitem uma visualização e entendimento do
comportamento do sinal digital de áudio.
A figura 6.10 exibe o conteúdo da classe GraphicWave.
Figura 6.10: Classe GraphicWave
A classe GraphicWave não foi concebida para utilização diretamente ao
reconhecimento, mas como ela se mostrou muito útil no desenvolvimento do trabalho
foi mantida e integrada ao framework.
61
6.4.2 Pacote sound
O pacote sound é responsável pela aquisição e execução do som, pela capacidade de
se definir uma amostra como padrão e também contém métodos de processamento do
sinal incluindo a IS e a detecção de extremos. A figura 6.11 define o conteúdo deste
pacote.
Figura 6.11: Diagrama de classes do pacote sound
Sound: A classe Sound é uma classe abstrata, estendida pela classe Sample. A
classe Sound disponibiliza a captura e execução de som, e também possui
métodos de processamento digital de sinal que são uteis para a extração de
informação e também para sua representação gráfica na classe GraphicWave.
Sample: A classe Sample é instanciada toda vez que se deseja gravar uma
nova amostra (sample) de áudio, e contém os métodos responsáveis por
definir uma amostra como padrão. Além disso, esta classe contem métodos
que possibilitam relacionar um padrão com seu respectivo som ou palavra.
6.4.3 Pacote frontEnd
Este pacote contém todas as classes para realizar a extração de informação do sinal,
caracterizando a fase de front-end. Seu diagrama de classes é apresentado na figura 6.12
abaixo.
62
Figura 6.12: Diagrama de classes do pacote frontEnd
HammingWindow: Classe responsável pelo janelamento do sinal através das
janelas de Hamming.
FFT: Classe responsável pelo cálculo da Transformada Rápida de Fourier.
MelFrequencyFilterBank: Classe que constrói o banco de filtros na escala
Mel.
MelFilter: Classe que caracteriza um filtro triangular Mel e também
responsável por aplicar os filtros ao espectro de potências.
DCT: Classe responsável pelo calculo da Transformada Discreta do Cosseno.
Este pacote contém ainda a classe ExtractInformation. A classe ExtractInformation é
uma das classes mais importantes do SRM, nela acontece a extração de informação do
sinal integrando todas as classes deste pacote e outras técnicas de processamento de
sinal inclusas no pacote sound. O produto final desta classe são os coeficientes MFCC.
Como primeiro parâmetro em seu construtor esta classe recebe uma amostra original
de áudio no formato Wave do tipo Sample para a extração de informação. Como
segundo parâmetro em seu método construtor a classe recebe uma instância da classe
RecognitionProperty que possibilita obter a configuração utilizada para o processo de
extração de informação.
A classe ExtractInformation possui variáveis declaradas em seu construtor que
configuram a extração de informação, tais como:
windowWidth: valor inteiro correspondente a largura das janelas de Hamming
aplicadas ao sinal, este valor nada mais é do que o número de amostras que
cada janela comportará, caracterizando uma fração que pode ser considerada
como estacionária (padrão= 256=32 milissegundos);
63
numFILTER: corresponde ao número de filtros mel construídos no banco de
filtros (padrão=15);
numMFCC: valor inteiro correspondente ao número de coeficientes MFCC
que serão extraídos. Contudo o número real de coeficientes extraídos será
decrescido de 1, pois o primeiro coeficiente MFCC é descartados (padrão=
11).
overlap: valor inteiro correspondentes a sobreposição entre as janelas de
Hamming (padrão=40).
minFreq: frequência mínima de corte no banco de filtros Mel (padrão = 100)
maxFreq: frequência máxima de corte no banco de filtros Mel, este valor
deve ser no mínimo a metade da frequência de amostragem(padrão = 3700).
Por padrão estas variáveis não podem ser alteradas externamente. Essa definição foi
tomada, pois estes valores possuem informações técnicas fundamentais para o
desempenho do reconhecimento, e recomenda-se um certo nível de conhecimento na
área de reconhecimento de som, para altera-los.
Toda vez que é a classe ExtractInformation é instanciada ocorre em seu construtor o
processo de extração de informação do sinal, atribuíndo ao vetor coef (que é um vetor
tipo float) os coeficientes extraídos e já linearizados. Estes coeficientes podem ser
obtidos externamente pelo método getMFFC.
Esta classe ainda possui a variável inteira numWindow, que contém o número de
janelas resultantes da extração de informação do sinal. A variável numWindow é útil
para avaliar o tempo aproximado de cada elocução baseando-se no número de janelas
geradas.
6.4.4 Pacote backEnd
Neste pacote é elaborado o processo de reconhecimento em si, caracterizando a fase
de back-end. A figura 6.13 expõe seu diagrama de classes.
Figura 6.13: Diagrama de classes do pacote backEnd
64
RecognitionProperty: A classe RecognitionProperty é a classe que contém as
propriedades de configuração do SRM servindo de referencia para as demais
classes do SRM obterem a configuração necessária para seus respectivos
funcionamentos. Esta classe recebe três parâmetros, um no formato String e
dois no formato int, e verifica se este parâmetros estão com uma sintaxe ou
um valor correto, caso contrário é lançada uma exceção informando os erros
cometidos.
Os parâmetros que podem ser informados são:
o namePatternBack: caracterizando o nome do banco de padrões onde
as amostras de referencia se encontram, este banco contém os
coeficientes extraídos de cada amostra definida como padrão.
o sampleRate: caracteriza a frequência de amostragem utilizada para a
digitalização do sinal analógico, esta taxa não deve ser menor que
8000 Hz.
o sensibility: este valor inteiro que pode variar de 1 a 4, e indica o nível
de sensibilidade que o SRM deve trabalhar para reconhecer de uma
maneira mais precisa as elocuções, este valor é regulamentado de
acordo com a escala definida no item 6.4.1.2.
A classe RecognizerProperty, ainda conta com um método para
desabilitar a IS na extração de informação chamado disable. Este método
foi criado para fins comparativos ou caso se deseje seguir a metodologia
tradicional de extração dos coeficientes MFCC, e deve ser utilizado logo
após a instanciação da classe no construtor da aplicação.
RecognizerUtil: Esta classe abstrata contém os algoritmos de DTW,
coeficientes de correlação de Pearson, distância euclidiana e outras formulas
úteis ao reconhecimento.
Já a classe Recognizer integra direta ou indiretamente todas as técnicas descritas
neste trabalho para realizar o reconhecimento de fato.
O construtor desta classe recebe um parâmetro que corresponde a amostra de som do
tipo Sample para ser reconhecida, e uma instância da classe RecognitionProperty que
contem informações úteis ao reconhecimento.
Para iniciar propriamente um reconhecimento deve-se chamar o método
starRecognizer. De um modo geral, a primeira tarefa deste método é extrair a
informação da amostra imposta ao reconhecimento, e gerar seus coeficientes MFCC.
Após, estes coeficientes são comparados com os coeficientes obtidos do banco de
padrões por meio da DTW, e são gerados os coeficientes de seletividade onde o
reconhecimento é avaliado. Caso o reconhecimento não atingir um nível mínimo
aceitável é retornado o valor “-1”, indicando que não houve reconhecimento, caso
contrário é retornado o ID do padrão reconhecido.
65
6.5 Diagrama de Sequência
Abaixo a figura 6.14 exibe um diagrama de sequência, que descreve um processo
simples de reconhecimento.
Figura 6.14: Diagrama de Sequencia
Um objeto Sample é criado toda vez que se deseja adquirir um novo som utilizando
recordSound. Quando se quiser definir uma amostra como padrão o método toPattern
irá efetuar este processo e retornará o ID do banco de padrões. Para iniciar um
reconhecimento, primeiro grava-se um novo som, e então este som é referenciado para o
método starRecognizer que retornará o ID do padrão, caso reconhecido.
66
6.6 Reconhecimento em Tempo Real
Embora este tipo de reconhecimento não foi definido no projeto deste trabalho como
requisito mínimo, foi possível realizar uma implementação que permitisse que o sistema
ficasse “ouvindo” o ambiente em intervalos de tempo pré-definidos. O framework SRM
então, conta com o método isListening presente na classe Recognizer destinado ao
reconhecimento em tempo real.
O fluxograma do algoritmo implementado pelo método isListening é apresentado a
seguir.
Figura 6.15: Fluxograma do modo listening
Seu funcionamento é relativamente simples: dentro de um loop infinito grava-se
amostras por um tempo pré-definido e em seguida é verificado se a amostra gravada
contém som ou não, caso não, continua-se a gravação de amostras, caso contiver som, a
amostra é inserida ao reconhecimento através do método starRecognizer, caso o
reconhecimento retornar como válido o loop é terminado através do retorno do método
starRecognizer que conterá o ID do padrão reconhecido.
Sua aplicação é voltada a reconhecimentos simples, por exemplo, comandos
direcionais, discagem de dígitos por voz, comandos com múltiplas escolhas, decisões
através das elocuções: “sim” e “não”, entre outas. Sua desvantagem é em relação a
gravação de tempos em tempos. Pois no momento em que se pronuncia uma elocução,
a janela de captura pode se encerrar e automaticamente inicia-se outra captura, podendo
acarretar em erros de reconhecimento. Mesmo assim se corretamente definidos os
tempos de gravação de acordo com o cenário de utilização, esta técnica se mostra útil.
Os resultados obtidos nos teste deste reconhecimento podem ser observados no capitulo
7.
67
6.7 Treinamento
O que se entende por treinamento no SRM consiste em requisitar – toda vez que se
definir uma amostra como padrão – uma segunda pronuncia da elocução, objetivando
definir um parametrização contendo características mais fiéis a sua pronuncia comum.
Este treinamento também é utilizado para garantir que ruídos indesejáveis e prejudiciais
ao reconhecimento não sejam considerados como padrão juntamente com a real
informação da elocução. Como resposta a funcionalidade de treinamento retorna se as
amostras podem ser consideradas semelhantes e consequentemente definidas como
padrão.
Este módulo de treinamento neste framework recebe então duas amostras e verifica
através do coeficiente de correlação de Pearson se estas amostras têm um índice
aceitável de correlação, que baseado em testes foi definido em 0.8, ou seja, se a
correlação entre as duas amostras apresentar um índice maior que 0.8 e ambas forem no
mínimo 60% iguais quanto ao tempo de recorte, o treinamento é concluído. A função
training então retorna verdadeiro caso as amostras sejam consideradas correlacionadas,
e falso caso contrario.
68
7 TESTES E RESULTADOS
Foram realizados diversos tipos de testes durante todo o desenvolvimento do
framework objetivando avaliar as reais capacidades de reconhecimento e consumo
computacional. A seguir são relatadas as experiências obtidas com os testes que
contribuíram para o ajuste de reconhecimento final do SRM.
Toda vez que alguma palavra ou som é submetido ao reconhecimento obtém-se os
coeficientes de seletividade. No decorrer do desenvolvimento do trabalho, conjugado a
testes rotineiros, observou-se que o coeficiente de seletividade Sel1 apresentava valores
mais decisivos e constantes quanto à qualidade do reconhecimento, já Sel2 apresentava
valores mais variantes, mas que também contribuíam para o julgamento da qualidade de
reconhecimento.
Concluiu-se então que para valores menores que 0,25 para Sel1 define-se um estado
de não reconhecimento, ou seja, não se pode afirmar com certeza que o reconhecimento
foi bem sucedido. Então foi definido o limite de tolerância de 0,25 para Sel1, e 0,8 para
Sel2 se, Sel1 for maior que 0,25.
Para a realização dos testes foi construído um aplicativo especificamente para este
fim, com o intuito de permitir a definição de padrões, e o reconhecimento de um som
abstrato ou palavra entre todos os padrões definidos e armazenados. Este aplicativo
também apresentava a característica de permitir o reconhecimento da mesma elocução
com diferentes configurações do framework, por exemplo, para testar o número de
filtros, a aplicação efetuava n reconhecimentos utilizando diferentes números de filtros
cada, e eram então analisados os coeficientes de seletividade para cada configuração,
podendo assim compará-las igualmente.
Também é importante mencionar que os testes expostos aqui são uma representação
dos diversos testes realizados durantes todo o desenvolvimento do framework SRM.
A fim de se manter um padrão para os testes, foram escolhidas as palavras
correspondendo aos dígitos de zero a nove, utilizado por grande parte dos autores como
em (YOMA, 1993) (SILVA, 2009) (OLIVEIRA, 2002), entre outros, e palavras como:
“ok”, ”sair”, totalizando um banco de padrões com 12 padrões. Estas palavras foram
pronunciadas em uma sala silenciosa de uma maneira firme e declarativa por locutores
do sexo masculino e feminino. Já nos testes envolvendo o reconhecimento de sons
abstratos, foram utilizados sons que são do cotidiano e que forneçam uma significante
analise dos resultados por meio das suas características acústicas.
Na seção 7.1 serão expostos os testes e resultados obtidos utilizando o emulador
SDK 3.0, incluso na IDE Netbeans 6.9 utilizada para o desenvolvimento deste
framework, nestes testes não será priorizada a exposição do tempo gasto em
processamento, pois o emulador geralmente não apresenta resultados merecidamente
69
comparáveis aos de um dispositivo móvel real, sendo somente apresentados os índices
de qualidade de reconhecimento para cada configuração testada. Já na seção 7.2,
destinado a testes realizados em dispositivos móveis, serão apresentados além dos
resultados gerais, os tempos gastos com a extração de informação e o reconhecimento
nos dispositivos testados, pois são estes tempos que servem como parâmetros reais para
utilizações do SRM.
7.1 Testes no emulador SDK 3.0
Nos testes realizados no emulador SDK 3.0 encontra-se os testes referentes a fase de
configuração ou calibração da extração de informação. Estes testes geralmente não
apresentam os resultados finais de reconhecimento obtidos, mas têm o intuito de
explicar o processo de escolha dos parâmetros utilizados em certas técnicas.
Como já explicado, cada reconhecimento retorna dois coeficientes de seletividade:
Sel1 e Sel2. Como os testes apresentados nesta seção tem o objetivo de ajuste, tem-se
uma comparação destes coeficientes de seletividade de reconhecimento (principalmente
Sel1), como o que interessa é verificar qual ajuste obtém o melhor resultado, ou seja os
melhores coeficientes de seletividade em comparação a outros ajustes, resolveu-se
quantificar os valores do coeficiente Sel1, para valores de comparação 1, 2 e 3. Caso o
teste apresentado abaixo contiver dois parâmetros somente, ou seja, dois tipos de
configuração, serão associados aos coeficientes Sel1 gerados de cada configuração os
valores 1 e 2, associando 2 a configuração que obteve um Sel1 superior, e 1 a
configuração com Sel1 inferior. Caso o teste contiver três configurações envolvidas,
adiciona-se o valor 3 e segue-se a mesma lógica. Caso os valores das configurações
envolvidas forem iguais então será atribuído 1 para ambos. Caso não houver
reconhecimento para certo parâmetro então será inserido na tabela o caractere “X”.
7.1.1 Ajuste das Janelas de Hamming
Após atingir um nível constante de reconhecimento o primeiro parâmetro de
configuração que se pôde testar foi o tamanho da Janela de Hamming utilizado.
Lembrando que como esta janela após sua geração é inserida imediatamente na FFT,
este tamanho deve ser uma potência de dois. Por exemplo, para uma taxa de
amostragem de 8 KHz normalmente usa-se 128 ou 256 amostras (YOMA, 1993)
(PETRY, 2002), resultando em janelas de 16 e 32 milissegundos respetivamente.
Valores acima disso irão resultar em janelas muito grandes não atendendo ao conceito
de sinal estacionário.
Um tamanho de janela menor que 128 ou maior que 256 para uma frequência de
amostragem de 8 KHz, como proposto pela literatura (YOMA, 1993) (PETRY, 2002),
não é adequado para a análise espectral, pois gera janelas com tamanho respectivamente
muito pequeno e muito grande.
Outra consideração que se deve observar é a porcentagem de sobreposição, pois
quando utilizada janelas maiores, uma taxa de sobreposição igual a uma janela menor
poderá ocultar uma maior quantidade de informações, já com janelas menores esse
problema é suprimido.
Levando em consideração as características descritas nos dois parágrafos acima e
também o trabalho de Yoma (YOMA, 1993), que para uma frequência de amostragem
de 8 KHz foi utilizado 128 amostras por janela, realizou-se então uma série de testes
70
que abaixo podem ser representados expondo somente a comparação sobre o
coeficientes Sel1 gerado para cada ajuste.
Tabela 7.1: Ajuste quanto ao tamanho das janelas de Hamming
PALAVRA 128 256
ESQUERDA 1 1
DIREITA 1 2
FRENTE 1 2
TRAZ 1 2
TESTE 1 1
CASA 1 2
CAIXA 1 2
PAI 1 2
PÉ 1 2
PAPEL 1 2
SIM 1 2
NÃO 1 2
TOTAL 12 22
E na figura 7.1 abaixo pode-se observar os valores reais gerados em Sel1.
Figura 7.1: Sel1 gerado sobre o ajuste quanto largura da Janela de Hamming
Neste teste envolvendo os tamanhos de amostras 128 e 256 pode-se ver a clara
superioridade nos valores de Sel1 utilizando 256 amostras em comparação a uma
configuração utilizando 128 amostras, e além desta superioridade em reconhecimento, o
tamanho 256 ainda apresenta um tempo de processamento menor se comparado a 128,
pois o número de janelas geradas com 256 é a metade. Também foi experimentado
utilizar tamanhos que não são potência de 2 nas janelas (200, 220, etc.), mas este
experimento além de apresentar resultados muito semelhantes tem a desvantagem de
requisitar o processo de Zero Padding antes de ser inserido na FFT.
Em seguida, definido o número de amostras em 256 por janela foram iniciados os
testes envolvendo a sobreposição entre as janelas de Hamming.
A porcentagem mínima testada foi de 10% e máxima de 60%, mas os testes
representados abaixo correspondem a porcentagens de 20% a 50%, visto que as
porcentagens de 10% e 60% logo apresentaram baixos índices de acertos.
0
0,5
1
1,5
2
Val
roe
s d
e Sel
1
Palavras Testadas
128
256
71
Tabela 7.2: Porcentagem de Sobreposição entre as Janelas de Hamming
E na figura 7.2 abaixo pode-se observar os valores reais gerados em Sel1 no teste 3:
Figura 7.2: Sel1 para as variações de sobreposição entre as janelas de Hamming
Nos três testes apresentado pela tabela 7.2 e pela figura 7.2 envolvendo a
sobreposição entre as janelas de Hamming, pode-se perceber no primeiro teste que há
uma pequena tendência de um melhor desempenho para 30% então realizou-se o
segundo teste centralizando 30% e este mostrou uma tendência para 40%, então como
decisão foi elaborado o terceiro teste e pode-se verificar que os valores se mantiveram
estáveis em 40%, que foi a porcentagem escolhida.
Além disso, o que favoreceu a escolha de uma sobreposição de 40%, foi um menor
consumo de recursos, pois aumentando a sobreposição entre as janelas aumenta-se o
número de janelas inseridas ao cálculo da FFT e em técnicas seguintes.
7.1.2 Ajuste do Banco de Filtros
Este foi um dos principais ajustes do SRM e envolveu dois parâmetros: o número de
filtros e a configuração da faixa de frequência de interesse.
O ajuste quanto ao número de filtros está diretamente relacionado ao desempenho
geral do reconhecimento. No Sphix-4 (2008) define-se como padrão 31 filtros para uma
frequência de amostragem de 8000 Hz, já em Cuadros (2007) é observado que para a
0
0,5
1
1,5
2
2,5
3
3,5
Val
ore
s d
e Sel
1
Palavras testadas
35%
40%
45%
72
faixa de frequência de interesse de 300 Hz à 3400 Hz, utilizam-se 24 filtros Em
comparação Yoma (1993) utiliza 15 filtros e uma faixa de frequência de 200 Hz à 3700
Hz.
Neste trabalho decidiu-se, com base nas literaturas descritas anteriormente e em
outras obras, utilizar uma faixa de frequência de 100 Hz à 3700Hz, além disso, estas
frequências também foram as que apresentaram os melhores resultados em
reconhecimento.
Já a quantidade de filtros foi um parâmetro que foi amplamente testado, objetivando
buscar o melhor custo/beneficio, pois aumentando o número de filtros aumenta-se o
tempo gasto no processo de extração de informações do sinal.
Os testes para estes parâmetros encontram-se expostos a seguir.
Tabela 7.3: Número de Filtros
PALAVRA 15 20 25
ZERO 3 1 2
UM 3 1 2
DOIS 3 2 1
TRES 2 3 1
QUATRO 3 2 2
CINCO 2 2 1
SEIS 2 3 2
SETE 3 2 1
OITO 1 1 1
NOVE 2 2 1
OK 3 2 1
SAIR 2 2 1
TOTAL 29 23 16
E na figura 7.3 abaixo pode-se observar os valores reais gerados em Sel1
Figura 7.3: Comparação de Sel1 entre o número de filtros
Na tabela 7.3 referente ao número de filtros, pode-se verificar que os melhores
resultados são obtidos utilizando 15 ou 20 filtros, na figura 7.3 é apresentado o gráfico
contendo a diferença obtida para Sel1 entre as três configurações. Então com base nos
testes realizados e também com base em Yoma (1993), onde o mesmo utilizou o menor
0
0,5
1
1,5
2
Val
ore
s d
e Sel
1
Palavras testadas
15
20
25
73
número de filtros em relação a todas as outras obras literárias pesquisadas, e também
devido ao fato que um menor número de filtros diminui o custo computacional, adotou-
se 15, como o número de filtros triangulares na escala mel utilizados.
7.1.3 Ajuste dos MFCCs
Geralmente a quantidade de coeficientes MFCC é menor em comparação ao número
de filtros, objetivando diminuir o número de informação sobre cada quadro sem perder
informação significativa sobre o sinal, além de permitir um melhor desempenho de
processamento.
Na literatura é comum encontrar valores que variam de 10 a 16 coeficientes MFCC,
no framework Sphinx-4 (SPHINX-4, 2008) adota-se como padrão 13 coeficientes, em
Yoma (YOMA, 1993) 10, e em Cuadros (CUADROS, 2007) 15. Então, esta foi a base
de partida para se definir a quantidade de MFCCs a ser utilizada, também foram
testadas quantidades de MFCCs que extrapolam esta faixa de valores, mas não se obteve
melhores resultados.
Abaixo é apresentado o teste para escolha quanto ao número de coeficientes MFCC.
Lembrando que como o primeiro coeficiente MFCC é descartado, estes valores de
coeficientes MFCC apresentados abaixo, no processo final, são decrescidos de 1.
Tabela 7.4: Ajuste de MFCCs
PALAVRA 11 14 16
ZERO 3 2 1
UM 3 2 1
DOIS 3 2 1
TRES 3 2 1
QUATRO 3 2 1
CINCO 3 1 2
SEIS 3 1 2
SETE 1 2 3
OITO 1 1 1
NOVE 1 2 3
OK 3 2 1
SAIR 3 2 1
TOTAL 30 21 18
E na figura 7.4 abaixo pode-se observar os valores reais gerados em Sel1
Figura 7.4: Comparativo de Sel1 alternado a quantidade de MFCCs
0
0,5
1
1,5
2
2,5
3
3,5
Val
ore
s d
e Sel
1
Palavras testadas
11
13
16
74
Com base nos testes apresentados pode-se perceber a vantagem do uso de 11
coeficientes em relação aos demais, outros valores também foram testados mas não
apresentaram melhores resultados.
Então definiu-se como padrão 11 coeficientes, totalizando 10 coeficientes MFCC,
esta quantidade apresenta também uma enorme otimização no tempo de reconhecimento
pois os coeficientes MFCC são parâmetros diretos para a DTW e se extraídos em uma
quantidade mais reduzida o tempo para reconhecimento diminui expressivamente.
7.2 Testes em Dispositivos Móveis
Nos testes aplicados em dispositivos móveis o framework SRM já estava
devidamente configurado através dos ajustes no emulador, então os testes apresentados
nesta sessão refletem o real desempenho, tanto em precisão quanto em tempo gasto
necessário para o processo de reconhecimento como um todo nos dispositivos testados.
É importante registrar que o aplicativo - que foi construído especificamente para os
testes – citado anteriormente, foi instalado na memória do dispositivo a fim de diminuir
o tempo de acesso em relação a sua instalação em um cartão de memória.
Como padrão adotou-se 3 dispositivos caracterizando 3 diferentes tipos de
processador, estes dispositivos serão a partir de agora chamados de dispositivo 1, 2 e 3,
com processadores operando a frequência de 434 MHz, 369 MHz e 332 MHz
respectivamente.
7.2.1 Desempenho para Extração de Informação
O desempenho para extração de informação corresponde ao tempo gasto para
adquirir os coeficientes MFCC, representando a parte de front-end implementada.
Na tabela 7.5 seguir é apresentado o consumo de processamento medido em
segundos para realizar o processo de extração de informação nos 3 dispositivos testados.
Tabela 7.5: Tempo gasto em segundos para extração de informação nos três dispositivos
testados
PALAVRA 1 2 3
ZERO 0,46 0,78 1,03
UM 0,25 0,6 0,72
DOIS 0,29 0,56 0,73
TRES 0,32 0,66 0,76
QUATRO 0,42 0,74 1
CINCO 0,45 0,98 1,15
SEIS 0,32 0,61 0,77
SETE 0,48 0,76 1,11
OITO 0,6 0,82 1,37
NOVE 0,41 0,88 1,16
OK 0,45 0,83 1,19
SAIR 0,46 0,75 1,15
MÉDIA 0,435 0,755 1,07
75
Com base nestes resultados expostos pela tabela 7.5 pode-se construir um gráfico
contendo o crescimento relativo conforme o declínio de frequência de processamento no
dispositivo.
Figura 7.5: Desempenho de extração de informação em relação a frequência do
processamento
Conforme resultados apresentados pela figura 7.5 acima pode-se perceber a relativa
diferença entre os três processadores, onde o crescimento do tempo consumido para a
extração de informação cresce em uma escala linear. E conclui-se que os tempos
apresentados são extremamente satisfatório levando-se em considerações as diversas
técnicas de processamento de sinais implementadas nesta etapa.
7.2.2 Desempenho para Reconhecimento
O desempenho de reconhecimento corresponde ao tempo gasto para o
reconhecimento entre todos os 12 padrões definidos nos testes, representando a parte de
back-end. E importante comentar que este teste difere do apresentado pela figura 6.1,
pois neste teste da tabela 7.6, o reconhecimento foi testado sobre um banco de padrões
completo, e no apresentado pelo gráfico da figura 6.1, o tempo para reconhecimento foi
avaliado conforme ocorria a inserção de um padrão ao banco de padrões.
Tabela 7.6: Tempo gasto em segundos para o reconhecimento nos três dispositivos
testados
PALAVRA 1 2 3
ZERO 0,89 1,32 2,14
UM 0,57 1,09 1,16
DOIS 0,69 1,08 1,73
TRES 0,69 1,19 1,75
QUATRO 0,89 1,3 2,22
CINCO 0,86 1,22 2,22
SEIS 0,66 1,14 1,74
SETE 0,85 1,28 2,17
OITO 0,95 1,5 2,4
NOVE 0,86 1,51 2,2
OK 0,87 1,45 2,15
SAIR 0,79 1,34 1,82
MÉDIA 0,855 1,29 2,145
E na figura 7.6 abaixo pode-se observar o gráfico comparativo entre as diferentes
frequências de processamento.
0
0,2
0,4
0,6
0,8
1
1,2
434 MHz 369 MHz 332 MHz
Tem
po
(s)
Frequência de processamento
76
Figura 7.6: Gráfico comparativo de tempos para reconhecimento entre os processadores
testados
Nos resultados apresentados pela tabela 7.6, pode-se concluir que o SRM apresenta
um baixo tempo para o reconhecimento, se baseando nos processadores dos dispositivos
testados e nas técnicas utilizadas. Um fato muito importante no processo de
reconhecimento, é que toda vez que ele é realizado, também é feita a extração de
informação da amostra que esta sendo reconhecida, demandando um maior tempo geral
ao processo de reconhecimento, pois esta amostra precisa ser representada através dos
seus coeficientes MFCC para poder ser comparada pela DTW com os demais padrões
que também estão representados pelos coeficientes MFCC. Este tempo adicional de
extração de informação esta incluso nos resultados acima correspondendo ao
reconhecimento.
7.2.3 Resultados Gerais
Nesta seção serão apresentados os resultados de reconhecimento representados pelas
taxas de acertos obtidas nos testes do framework SRM. Os testes realizados englobam
os contextos de reconhecimento de palavras isoladas dependente de locutor e de sons
abstratos. A configuração utilizada no framework, tanto na parte de front-end quanto
para o back-end é definida na tabela 7.7 abaixo.
Tabela 7.7: Configuração geral do framework SRM
Parâmetro Valor
Frequência de amostragem 8 KHz
Bits por amostra 8
Inversão de Sinal Sim
Largura da Janela de Hamming 256 = 32 ms
Sobreposição entre as janelas 40%
Número de filtros Mel 15
Frequência mínima do banco de filtros Mel 100 Hz
Frequência máxima do banco de filtros Mel 3700 Hz
Número de coeficientes MFCC extraídos 11-1 = 10
Limite de seletividade do coeficiente Sel1 0,2
Limite de seletividade do coeficiente Sel2 0,8
0
0,5
1
1,5
2
2,5
434 MHz 369 MHz 332 MHz
Tem
po
(s)
Frequência de processamento
77
Os resultados apresentados a seguir refletem o reconhecimento para cada tipo de
som. As duas colunas representam os tipos de reconhecimento já descritos, e este
reconhecimento ainda é dividido em reconhecimento em tempo real e reconhecimento
estacionário. No reconhecimento em tempo real captura-se o som em intervalos pré-
definidos (para os testes foi considerado o tempo de 1,5 segundos), e então verifica-se
se o som capturado corresponde a algum padrão armazenado. No reconhecimento
estacionário, há uma opção na aplicação desenvolvida para os testes, em que constitui
um botão de reconhecimento, este botão ao clicado inicia a captura do som por 2
segundos e em seguida realiza-se o reconhecimento.
É importante registrar que as condições de realização dos testes representados pela
tabela, foram em ambientes silenciosos, e as palavras e sons emitidos tanto para a
definição dos padrões quanto para o reconhecimento foram emanados de forma clara e
inteligível.
A porcentagem de acertos exposta na tabela 7.8 abaixo caracteriza o desempenho
final do SRM para palavras e sons abstratos.
Tabela 7.8: Precisão de reconhecimento do framework SRM
Palavras Isoladas Sons Abstratos
Estacionário 92% 94%
Tempo Real 88% 87%
Com base nestes resultados pode-se concluir que framework SRM apresentou um
bom desempenho, levando-se em consideração a frequência de amostragem de 8 KHz, a
qualidade do microfone do dispositivo, e o fato das elocuções serem pronunciadas a
uma distância razoável do microfone interno do dispositivo. Para um desempenho
constante recomenda-se que as palavras sejam pronunciadas com a boca próxima ao
microfone (aprox. 10 cm) e que não sejam misturados no reconhecimento sons abstratos
com palavras. Outra consideração, é que o reconhecimento apresentou certas confusões
ao reconhecer palavras muito semelhantes, como por exemplo: “casa”, “asa”, “testa”,
“festa”, “e”, ”d”. Este problema é ocasionado principalmente devido a baixa frequência
de amostragem utilizada (8 KHz). Para suprimir este problema recomenda-se aumentar
a frequência de amostragem (caso suportada pelo dispositivo) e/ou definir um banco de
padrões mais reduzido, pois com isso, aumenta-se a porcentagem de acertos.
Outro fator importante que se pode observar é em relação a um desempenho
superior no reconhecimento de forma estacionária, pois no reconhecimento estacionário
há o momento delimitado para que elocução seja pronunciada e a captura desta se faz de
uma forma completa, o que avalia realmente a precisão de reconhecimento do SRM. Já
no reconhecimento em tempo real, como se captura sons de intervalos de tempo pré-
definidos, como já explicado, algumas vezes o som a ser reconhecido pode estar
incompleto.
78
7.3 Comparativo do uso da técnica de IS
A técnica de Inversão de Sinal se mostrou eficiente para o reconhecimento de som e
palavras isoladas dependente de locutor, fato este que fez com que a Inversão de Sinal
fosse aplicada diretamente ao sinal na etapa de extração de informação, melhorando
significativamente o reconhecimento conforme pode ser observado abaixo.
Tabela 7.9: Inversão de Sinal
PALAVRA COM IS SEM IS PALAVRA COM IS SEM IS
ZERO 90% 90% DUAS PALMAS 90% 70%
UM 100% 100% UMA PALMA 100% 100%
DOIS 100% 100% ASSOVIO 100% 100%
TRES 100% 100% UMA BAT. MESA 100% 100%
QUATRO 100% 90% DUAS BAT. MESA 90% 80%
CINCO 90% 70% ASSOVIO 2 80% 100%
SEIS 100% 100% TEL TOCANDO 100% 100%
SETE 100% 80% CRIANCA CHOR. 80% 80%
OITO 100% 70% CACHORRO LAT 100% 100%
NOVE 100% 80% CAMPAINHA 100% 100%
OK 100% 90% TOTAL 94% 93%
SAIR 100% 100%
TOTAL 98% 89%
No teste exposto pela tabela 7.9 onde foi pronunciado 10 vezes cada palavra ou som
abstrato para o reconhecimento estacionário, pode-se observar a clara otimização do
reconhecimento utilizado a Inversão de Sinal. Que possibilitou um aumento no índice
de reconhecimento em aproximadamente 8%.
Contudo para sons, o reconhecimento não sofreu perceptíveis melhorias, isso pode
ser explicado devido ao fato de que sons podem conter um nível de frequência mais
constante e menos invariante de acordo com o tempo em relação a uma palavra. Mesmo
assim, uma das particularidades do uso da Inversão de Sinal foi a melhor caracterização
entre sons iguais, mas emitidos com diferentes repetições (exemplo: uma palma e duas
palmas), onde utilizando a Inversão de Sinal notou-se que devido a sua propriedade de
definir a representação do sinal de uma maneira mais clara, estas características foram
mais facilmente identificadas no reconhecimento.
79
8 ESTUDO DE CASO
Depois de concluída a fase de testes e calibração do SRM foi construída uma
aplicação para a validação do framework.
Esta aplicação foi denominada CallDictation e permite o ditado de dígitos de zero a
nove e mais os comandos para “discar”, “apagar” e “limpar”, correspondendo a
capacidade de efetuar uma chamada através do ditado em tempo real de dígitos. O
aplicativo então reconhece automaticamente os dígitos falados e para iniciar a chamada
o usuário pode falar o comando “discar”, por exemplo, ou pode ser qualquer outro
comando desde que tenha sido gravado no ID 11. O código completo do aplicativo
CallDictation pode ser encontrado no anexo 1.
A partir de agora, serão descritos trechos da implementação do CallDictation a fim
de explicar suas principais características envolvendo o uso do framework SRM. Não
serão explicados trechos do código responsáveis com a interface ao usuário.
Inicialmente foi criado um objeto de classe na aplicação do tipo
RecognitionProperty. Nesta instância configura-se (de preferência no construtor da
aplicação), as principais características e flexibilidades do SRM, que são o nome do
banco de padrões, a sensibilidade de reconhecimento, e a frequência de amostragem. A
seguir, a figura 8.1 descreve um exemplo desta sintaxe:
Figura 8.1: Configuração básica do SRM
No exemplo da figura 8.1 o nome do banco de padrões é “digitos”, o nível de
sensibilidade de reconhecimento é 2, e a taxa de amostragem é 8000 Hz.
Originalmente a aplicação pede que o usuário informe 13 comandos (10 dígitos mais
3 comandos de ação), que irão compor o banco de padrões que neste caso possuirá um
vocabulário igual a 13 padrões. Então para gravar os padrões foi criado um comando
chamado “recordPattern” na interface da aplicação, que se acionado irá gravar uma
amostra e defini-la como padrão através da função toPattern implementada pela classe
Sample, como pode ser observado pela figura 8.2 a seguir:
80
Figura 8.2: Gravação e definição como padrão de uma amostra de som
O procedimento da figura 8.2 é realizado até que banco de padrões esteja composto
com 13 padrões, isso é verificado através do seguinte código definido pela figura 8.3.
Figura 8.3: Verificação do tamanho do banco
Então é disponibilizado na tela da aplicação o comando “listening”, que como o
próprio nome diz, inicia o modo de escuta através do reconhecimento em tempo real.
Para se trabalhar com o reconhecimento em tempo real, há certas particularidade que
não puderam ser abstraídas pelo SRM, pois estas, interferiam na flexibilidade do uso do
framework. A principal é o uso de uma thread, que deve abrigar um loop infinito
chamando o método isListening em seu escopo. Esse procedimento pode ser observado
conforme a figura 8.4.
81
Figura 8.4: Utilização da função "isListening"
Pode-se perceber que na figura 8.4 a variável id, é associada ao retorno do método
isListening, esse retorno somente acontecerá quanto o ciclo de reconhecimento em
tempo real descrito na seção 6.7 for encerrado. A partir disso, pode-se associar ações
conforme o valor contido em id, que neste caso de uso, são os valores 11, 12 e 13, as
ações de “discar”, “apagar”, e “limpar” respectivamente. Ainda explorando o exemplo
da figura 8.4, como última opção, caso o id retornado não seja relacionado a nenhuma
condição, é inserido o número reconhecido, ao campo de texto contendo o número do
telefone a discar, através da função Sample.getSampleWord que contém um banco de
dígitos no formato de texto, com seus ids paralelos ao banco de padrões de coeficientes
MFCC.
Através deste estudo de caso foi possível efetuar chamadas apenas com um toque de
dedo referente a confirmação do dispositivo quanto a intenção de se realizar a chamada
por meio da aplicação, também foi possível comprovar a fácil integração do SRM a uma
aplicação móvel, sendo neste caso desnecessário a criação de uma classe voltada
especificamente para funções de reconhecimento.
O SRM ainda se inclui em diversos outros cenários de uso, abaixo são descritos
alguns exemplos:
Reconhecedor de eventos sonoros: Um exemplo deste caso seria definir dois
padrões como: “celular tocando” e “apito de micro-ondas”, etc. Estes
comandos então poderiam ser associados a mensagens para avisar ao usuário
o que ocorreu, ou mesmo já tomar ações, por exemplo, se comunicando com
algum outro termina por meio de uma rede bluetooth.
82
Reconhecedor de comandos: o SRM pode ser integrado a uma aplicação
voltada ao reconhecimento de comando simples, como por exemplo:
“mensagem”, “agenda”, “configurações”, “jogos”, etc. Também podem ser
associados comandos de discagem por digitos ou de chamada por voz. Ou
também pode ser integrado a uma aplicação que captura imagens, e então
através de comandos de som o usuário poderia escolher entre focalizar a
imagem ou tirar a foto.
Tradutor de palavras: Pode-se desenvolver um pequeno tradutor de palavras
para certo idioma, quanto o usuário falasse uma palavra a aplicação
reconheceria a palavra e retornava sua respectiva tradução.
Babá eletrônica: O SRM também se mostrou eficiente para identificar sons
distintos, como por exemplo, um bebe chorando: toda vez que fosse
identificado o choro a aplicação enviaria um mensagem aos pais.
83
9 CONCLUSÃO
Este trabalho apresentou a proposta de um framework para reconhecimento de sons
e palavras isoladas dependente de locutor para dispositivos móveis inteiramente
desenvolvido na linguagem Java ME. Onde se obteve significativos índices de
reconhecimento chegando a 94% de acertos no melhor caso.
Através desde desenvolvimento pode-se concluir que somente o espectro resultante
da FFT não é suficiente para o reconhecimento, sendo necessária a extração dos
coeficientes MFCC, onde pode-se obter um índice de reconhecimento aceitável, mesmo
para uma baixa frequência de amostragem e níveis de representação por amostra.
Já o coeficiente de correlação de Pearson mostrou-se útil no processo de
reconhecimento de sons abstratos, gerando resultados satisfatórios, porém esta técnica
falha no que é justamente o ponto forte da Modelagem Determinística (DTW), que são
o reconhecimento de elocuções com variações temporais diferentes, mas sua vantagem é
um menor custo computacional, vantagem esta que se mostrou útil no processo de
treinamento, justificando seu uso.
Concluiu-se também que para uma largura de Janela de Hamming maior, neste caso
próxima a 32 milissegundos, a taxa de sobreposição entre as janelas se diminuída
apresenta um melhor resultado em comparação a um taxa de sobreposição maior. Isso
ocorre, pois se constatou que ao aumentar a largura das janelas, a quantidade de
variação acústica presente neste janelamento também aumenta, e ao sobrepor estas
janelas com um índice maior, a quantidade de informação perdida também se eleva
ocasionando muitas vezes em confusões no reconhecimento.
Sobre a técnica de Inversão de Sinal proposta neste trabalho conclui-se que a mesma
contribuiu significativamente no índice de acertos do reconhecimento, obtendo uma
melhora em média de 8%, principalmente para o reconhecimento de palavras. E esta
técnica apresenta dois aspectos inversos. O primeiro é benéfico, pois a inversão de sinal
evidencia as informações que carregam a grande parte da caracterização da elocução. O
segundo que é uma desvantagem desta técnica é a de se reduzir pela metade o índice de
representação do sinal.
Sobre a técnica de detecção de extremos desenvolvida se pode concluir que esta
permitiu a correta identificação do inicio e fim dos sons, apresentando um baixo custo.
Esta técnica tem a vantagem além da baixa requisição de processamento, a capacidade
de configuração conforme o nível de ruído do ambiente, podendo descartar
automaticamente ruídos caso a configuração utilizada for a adequada para tal caso.
Porém esta técnica apresentou a desvantagem que em parte é devido a baixa frequência
de amostragem, de omitir os finais de certas elocuções que são palavras, pois verificou-
se que para o idioma português uma grande parte das palavras tem seu final “mudo”,
84
ocasionando um recorte antecipado em relação ao final da palavras. Este problema só
pode ser eliminado, através de uma pronuncia clara e inteligível.
Sobre a energia de saída do banco de filtros pode-se concluir assim como em
Moraes (MORAES, 2007) que esta possui informação suficiente para o reconhecimento
de pequenos comandos sendo dispensável a aplicação da DCT, porém, neste trabalho
constatou-se que (citando um exemplo claro), para dígitos numéricos a utilização
somente da energia para o reconhecimento acarretava em erros principalmente entre os
dígitos “três” e “seis” e “cinco” e “oito”, problema que foi eliminado utilizando os
MFCC juntamente com a Inversão de Sinal.
Agora abordando mais sobre conclusões no contexto de dispositivos móveis, o
desempenho computacional apresentado por estes na execução de aplicativos que
utilizassem o SRM foi aceitável chegando a média 0,4 segundos para o front-end e 0,8
segundos para o reconhecimento com 20 padrões em um dispositivo com processador
de 434 MHz, utilizando em todo o framework somente variáveis do tipo float.
Outra conclusão que pode chegar neste mesmo contexto é que o índice de precisão
de reconhecimento nos dispositivos testados foi significativamente afetado pelo fato da
baixa qualidade de transdução dos microfones presentes nos mesmos, mas mesmo assim
obteve-se um bom desempenho tanto em processamento quanto em reconhecimento.
9.1 Contribuições
Abaixo são citadas em forma de itens as principais contribuições.
Desenvolvimento e implementação de um framework para reconhecimento de
sons em Java ME;
Proposta de reconhecimento de sons abstratos utilizando técnicas típicas de
reconhecimento de voz.
Implementação de técnicas robustas de extração de informação de sinais
digitais de voz (MFCC), na linguagem Java ME e consequentemente
proporcionando sua inserção e análise por meio de testes no ambiente de
processamento móvel.
Implementação da DTW na linguagem Java ME e consequentemente a
análise do seu desempenho no contexto de processamento móvel.
Análise implícita por meio das diversas técnicas envolvidas no
reconhecimento de som proposto, da performance do uso de variáveis tipo
float não somente proporcionando contribuições para conclusões em
ambientes móveis mas também no contexto geral de reconhecimento de som .
Desenvolvimento e implementação de uma técnica para processamento
digital do sinal PCM no formato Wave, chamada Inversão de Sinal,
apresentando uma melhora no reconhecimento de em média 8%,
principalmente para palavras isoladas dependente de locutor;
Desenvolvimento e implementação de um algoritmo de detecção de extremos
para o contexto de dispositivos móveis e de baixo custo;
85
A abstração e disponibilização através da implementação de uma API para o
cálculo da Transformada Rápida de Fourier (algoritmo Radix-2), na
linguagem Java ME;
O desenvolvimento e disponibilização de uma classe responsável pela
representação gráfica de sinais de áudio no formato Wave com 8 bits por
amostra em telas de dispositivos móveis;
A desenvolvimento e implementação do cálculo da frequência isolada para
determinado sons com base no espectro de magnitudes resultante da FFT,
possibilitando o desenvolvimento, por exemplo, de um afinador musical (esta
contribuição está agregada à classe da FFT).
E como contribuição implícita a possiblidade de futuros desenvolvedores
poderem utilizar as técnicas de processamento de sinais e reconhecimento
desenvolvidas e agregadas a este framework, em futuras propostas de
reconhecimento na linguagem Java ME e também Java SE.
9.2 Trabalhos Futuros
Nos itens a seguir são elencadas algumas possibilidades de trabalhos futuros.
Permitir a configuração do framework para trabalhar com mais de 8 bits por
amostra;
Integrar a etapa de extração de informações a extração dos coeficientes delta
e delta-delta ambos derivados dos coeficientes MFCC extraídos.
Utilizar a proposta de espectro de potencias apresentada por Chen et al
(CHEN, PALIWAL, et al., 2005) na extração de informação.
Utilizar outras técnicas de reconhecimento, como os Modelos Ocultos de
Markov, ou a Quantização Vetorial sobre os coeficientes MFCC extraídos;
Expandir as capacidades do SRM possibilitando o reconhecimento
independente de locutor.
Permitir outro tipo de formato de arquivo de áudio para manipulação, como o
formato AMR, muito comum em dispositivos mais simples.
Utilizar algoritmos para o cálculo da FFT de menores custos, tal como o
algoritmo Split-radix.
E como trabalho futuro que não seja especificamente relacionado com este
Framework, é apresentada a ideia de se desenvolver um sistema capaz de
efetuar métricas em reconhecedores de voz, capaz de suportar diversos tipos
de reconhecimento (fala continua, isolada, independência de locutor,
dependência de locutor, etc.) e que de maneira bem documentada forneça
qualificações para os sistemas de reconhecimento avaliados.
86
REFERÊNCIAS
ABNT. Associação Brasileira de Normas Técnicas. [S.l.]. 1959.
ANDARADE, M. R. D. S.; FILHO, S. B. M. Determinação de Pontos Terminais ('end-
points') baseada no método médias-k modificado. Anais do XVII Simpósio Brasileiro
de Telecomunicações, 1999. 111-114.
ANDRADE, A. O.; SOARES, A. B. Técnicas de Janelamento de Sinais. Universidade
Federal de Uberlândia- Faculdade de Engenharia Elétrica, Uberlândia, 2005. 3.
AURÉLIO, D. Dicionário Aurélio, 2010. Disponivel em:
<http://www.dicionariodoaurelio.com/Som>. Acesso em: 19 Novembro 2010.
BOERSMA, P.; WEENINK, D. Sound: To Mel Filter. Praat: doing phonetics by
computer, 2001. Disponivel em:
<http://www.fon.hum.uva.nl/praat/manual/Sound__To_MelFilter___.html>. Acesso
em: 15 Outubro 2010.
CASTRO, M. C. F. D. Redes de Comunicação Sem Fio - Capitulo 2, Codificação de
Fonte. PUCRS – FENG – Engenharia da Computação, II Semestre 2006. 43.
CERNA, M.; HARVEY, A. F. The Fundamentals of FFT-Based Signal Analysis and
Measurement. National Instruments, Junho 2000.
CHEN, J. et al. Robust MFCCs Derived from Differentiated Power Spectrum. ATR
Spoken Language Translation Research Laboratories; g School of Microelectronic
Engineering, Griffith University , kyoto; Brisbane, 2005.
CIPRIANO, J. L. G. Desenvolvimento de Arquitetura para Sistemas de
Reconhecimento Automático de Voz Baseados em Modelos Ocultos de Markov.
URGS, Porto Alegre, Novembro 2001. 125.
COSTA, A. S.; GRAZZIOTIN, F. Z. Controle de dispositivo utilizando mensagens
SMS. PUCRS, Porto Alegre, 3 Dezembro 2007. 13. Disponivel em:
http://www.inf.pucrs.br/~eduardob/disciplinas/ProgPerif/sem07.2/trabalhos/tp2/g4/Relat
orio.pdf.
CUADROS, C. D. R. RECONHECIMENTO DE VOZ E DE LOCUTOR EM
AMBIENTES RUIDOSOS: COMPARACÃO DAS TÉCNICAS MFCC E ZCPA.
Escola de Engenharia da Universidade Federal Fluminense, Niterói, 2007.
DAVIS, S. B.; MERMELSTEIN, P. Comparison of Parametric Representations for
Monosyllabic Word Recognition in Continuously Spoken Sentences. IEEE
Transactions on Acoustics, Speech, and Signal Processing, 1980.
ELIAS, F. G. D. M. Codificação de fala PCM & ADPCM. Universidade Federal do
Paraná - Engenharia Elétrica, Novembro 2006. 8.
87
FILHO, M. D. C. S. Classificação Automática de Gêneros de Áudio Digital. Escola
Politécnica de Pernambuco - Departamento de Sistemas Computacionais,
Novembro 2006. 60.
FURTUNĂ, T. F. Dynamic Programming Algorithms in Speech Recognition. Revista
Informatica Economică nr. 2(46)/2008, Academy of Economic Studies, Bucharest,
2008.
GONÇALVES, L. A. Um Estudo sobre a Transformada Rápida de Fourier e seu uso em
Processamento de Imagens. URGS - Instituto de Matemática, Porto Alegre, Junho
2004.
GOYAL, V. Pro Java ME MMAPI Mobile Media API for Java Micro Edition. New
York: apress, 2006.
HAYKIN, S.; VEEN, B. V. Sinais e Sistemas. [S.l.]: Bookman, 2001.
HERATH, I.; RAGEL, R. G. Implementation of an Electronic Tuner in J2ME using
Fast Fourier Transform. Peradeniya University Research Sessions, Sri Lanka,
Vol.12, Part II, Peradeniya, 30 Novembro 2007.
HUANG, X.; ACERO, A.; HON, H.-W. Spoken Language Processing - A Guide to
Theory, Algorithm, and System Development. New Jersey: Prentice Hall PTR, 2001.
HUERTA, J. M. Speech Recognition in Mobile Environments. Department of
Electrical and Computer Engineering, Carnegie Mellon University, Abril 2000.
157.
JNECZKO, C. TRANSFORMADA DE FOURIER DISCRETA. Universidade
Tecnológica Federal do Paraná. Paraná, p. 14. 2010.
KUTWAK, A. B. Análise da Codificação LPC para Sinais de Fala. Universidade
Federal do Rio de Janeiro. Escola de Engenharia - Departamento de Eletrônica,
Abril 1999.
LIMA, A. A. D. Análises Comparativas em Sistemas de Reconhecimento de Voz.
UFRJ, Rio de Janeiro, Setembro 2000. 102.
LIMA, A. A. D. Análises Comparativas em Sistemas de Reconhecimento de Voz.
Universidade Regional do Rio de Janeiro, Rio de Janeiro, Setembro 2000.
MEDSTATWEB. Coeficiente de correlação de Pearson. Medstatweb - Faculdade de
Medicina da Universidade do Porto, 2009. Disponivel em:
<http://stat2.med.up.pt/cursop/glossario/correlacao_Pearson.html>. Acesso em: 27
Setembro 2010.
MIRANDA, J. T. R. D. S. Speech Recognition system for mobile devices. Institudo
Superior Técnico, Universidade Técnica de Lisboa, Lisboa, Outubro 2008.
MORAES, A. L. K. D. Projeto de um Equipamento de Reconhecimento de Comandos
de Voz. Universidade de Brasilia - Faculdade de Tecnologia , Brasilia, Julho 2007.
OLIVEIRA, K. M. D. Reconhecimento de Voz Através do Reconhecimento de Padrões.
Universidade Católica de Salvador - UCSAL, Salvador, Dezembro 2002.
ORACLE. Community Developement of Java Technology Specifications. JSR 113:
Java Speech API 2.0, 2010. Disponivel em: <http://jcp.org/en/jsr/detail?id=113>.
Acesso em: 19 Novembro 2010.
88
ORACLE, C. Mobile Media API (MMAPI); JSR 135 Overview. Oracle, 2010.
Disponivel em: <http://java.sun.com/products/mmapi/overview.html>. Acesso em: 8
Maio 2010.
PETRY, A. Reconhecimento Automático de Locutor Utilizando Medidas de Invariantes
Dinâmicas Não-Lineares. URGS, Instituto de Informática, Porto Alegre, Agosto
2002.
PETRY, A.; ZANUT, A.; BARONE, D. A. C. Reconhecimento Automático de Pessoas
pela Voz através de Técnicas de Processamento Digital de Sinais. Instituto de
Informática - Universidade Federal do Rio Grande do Sul, 2000.
RABINER, L.; JUANG, B.-H. Fundamentals of Speech Recognition. New Jersey:
Englewood Cliffs: Prentice Hall, 1978.
ROLIM, C. O. Redes Camada Física. Universidade Regional Integrada do Alto
Uruguai e das Missões - URI Campus Santo Angelo. Santo Ângelo, p. 56. 2010.
SAMBUR, M. R.; RABINER, L. R. An Algorithm for Determining the Endpoints
for Isolated Utterances. The Bell System Technical Journal, Vol. 54, No. 2, Feb. [S.l.]:
[s.n.]. 1975. p. 23.
SILVA, A. G. D. Reconhecimento de Voz para Palavras Isoladas. Universidade
Federal de Pernanbuco, Dezembro 2009.
SPHINX-4. Framework Sphinx-4. A speech recognizer written entirely in the
JavaTM programming language, 2008. Disponivel em:
<http://cmusphinx.sourceforge.net/sphinx4/>. Acesso em: 1 out. 2010.
SUK, S.-Y. et al. Distributed Speech Recognition System for PDA in Wireless Network
Environment. Conference Speech and Computer, St. Petersburg, Russia, 20-22
Setembro 2004. 4.
SUN, M. Class RecordStore, 2006. Disponivel em:
<http://java.sun.com/javame/reference/apis/jsr037/javax/microedition/rms/RecordStore.
html>. Acesso em: 8 Maio 2010.
SUN, M. What is a Recors Store. Java Tips, 2008.
TAFNER, M. A. Reconhecimento de Palavras Faladas Isoladas Usando redes Neurais
Artificiais. Universidade Federal de Santa Catarina , Janeiro 1996.
WILSON, S. WAVE PCM soundfile format, 2003. Disponivel em:
<https://ccrma.stanford.edu/courses/422/projects/WaveFormat/>. Acesso em: 22
Setembro 2010.
YOMA, N. B. Reconhecimento Automático de Palavras Isoladas: Estudo e aplicação
dos métodos Determinísticos e Estoásticos. Departamento de Comunicações da
Faculdade de Engenharia Elétrica - UNICAMP, Campinas, Outubro 1993.
ZHOU, H.; HAN, X. Design and Implementation of Speech Recognition System Based
on Field Programmable Gate Array. Modern Applied Science, Tianjin, August 2009.
ZURMELY, R. M. Digitalização de sinais Analógicos, Sete Lagoas, Minas Gerais, 19
Setembro 2010. Disponivel em: <http://www.qsl.net/py4zbz/teoria/quantiz.htm>.
Acesso em: 22 Setembro 2010.
89
ANEXO A - APLICATIVO CALLDICTATION
import javax.microedition.lcdui.*;
import javax.microedition.midlet.*;
import java.net.srm.backEnd.*;
import java.net.srm.sound.Sample;
import java.net.srm.sound.Sound;
import javax.microedition.io.ConnectionNotFoundException;
import javax.microedition.lcdui.TextField;
/**
* @author Marcelo Ruaro
*/
public class CallDictation extends MIDlet implements CommandListener {
private Display display;
private Form form;
private Command recordPattern, listening, clear, exit;
private StringItem message;
private TextField tx;
private RecognitionProperty property;
public CallDictation() {
display = Display.getDisplay(this);
property = new RecognitionProperty("digitos", 2, 8000);
}
public void startApp() {
message = new StringItem("", "");
recordPattern = new Command("RecordPat", Command.SCREEN, 1);
listening = new Command("Listening", Command.SCREEN, 1);
clear = new Command("Clear Bank", Command.SCREEN, 1);
exit = new Command("Exit", Command.SCREEN, 1);
tx = new TextField("Telefone", "", 20, TextField.DECIMAL);
form = new Form("CallDictation");
form.append(message);
form.append(tx);
if (Sample.getNumPattern(property) < 13) {
90
message.setText("Primeiro grave os 13 padrões!");
form.addCommand(recordPattern);
} else {
message.setText("Clik em Listening para ditar!");
form.addCommand(listening);
}
form.addCommand(clear);
form.addCommand(exit);
form.setCommandListener(this);
display.setCurrent(form);
}
public void pauseApp() {
}
public void destroyApp(boolean unconditional) {
this.notifyDestroyed();
}
public void commandAction(Command c, Displayable d) {
if (c == recordPattern) {
if (tx.getString().length() < 1 && Sample.getNumPattern(property) <= 9) {
message.setText("Para gravar informe um digito!");
} else {
//Grava novo som
Sample sample = new Sample(Sound.recordSound(2000,
property.getSampleRate()));
//Define como padrão
int id = Sample.toPattern(sample, property);
//Executa o trecho do som que foi recortado
Sound.playOnlyElocution(sample.getRecordedSoundArray());
//Armazena o número digitado
Sample.addSampleWord(tx.getString(), "numeros");
message.setText("Padrão gravado no ID: " + id);
tx.setString("");
if (Sample.getNumPattern(property) == 13) {
form.removeCommand(recordPattern);
message.setText("Clik em Listening para ditar!");
form.addCommand(listening);
}
91
}
} else if (c == listening) {
new Thread(new Runnable() {
public void run() {
while (true) {
//chama o método "isListening"
int id = Recognizer.isListening(property, 1700);
//Define ações conforme o tipo de ID
if (id == 11) {//discar
chamar(tx.getString());
break;
} else if (id == 12){//apagar
String aux = tx.getString();
tx.setString(aux.substring(0, (aux.length() - 1)));
} else if (id == 13) {//limpar
tx.setString("");
} else {
tx.setString(tx.getString() +
Sample.getSampleWord(id, "numeros"));
}
}
}
}).start();
} else if (c == clear) {
Sample.clearPatterns(property.getNamePatternBank());
Sample.clearPatterns("numeros");
tx.setString("");
form.addCommand(recordPattern);
form.removeCommand(listening);
} else if (c == exit) {
this.destroyApp(true);
}
}
private void chamar(String numero) {
try {
platformRequest("tel:" + numero);
} catch (ConnectionNotFoundException ex) {
System.out.println(ex.getMessage());
}
}
}
![FRAMEWORK PARA APLICAÇÕES EM …lvelho.impa.br/hp/files/Hallison-Monografia.pdfem dispositivos móveis. O framework será implementado para a plataforma iOS [22], utilizada pelos](https://img.document.onl/doc/110x75/5f6297184d062e47541336e4/framework-para-aplicaes-em-em-dispositivos-mveis-o-framework-ser-implementado.jpg)
