master thesis report - DIUF

Transcription

master thesis report
Baris Ulucinar1
avril 2007
Department of Informatics - Master Project Report
Département d’Informatique - Departement für Informatik • Université de Fribourg Universität Freiburg • Boulevard de Pérolles 90 • 1700 Fribourg • Switzerland
phone +41 (26) 300 84 65
fax +41 (26) 300 97 31
[email protected]
http://diuf.unifr.ch
Prof. R. Ingold, Dr. J. Hennebert, Andreas Humm and Robert Van Kommer
1
baris.ulucinar{@unifr.ch, @gmail.com}, DIVA group, DIUF, University of Fribourg
Contents
1 Introduction
6
2 Reconnaissance automatique de la parole
2.1 Bref historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Principes de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Pourquoi utiliser des HMM’s pour modéliser des modèles acoustiques?
2.4 Modèle acoustique . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Dictionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6 Grammaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.7 Au moins quatre défis pour la reconnaissance . . . . . . . . . . . . . .
2.8 Types d’erreurs lors de la reconnaissance . . . . . . . . . . . . . . . . .
2.9 Classification des systèmes de reconnaissance automatique de la parole
2.10 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.11 Interface vocale utilisateur . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
8
8
9
9
9
10
10
10
11
13
3 Architecture générale
3.1 Tomcat . . . . . . . . . . . . . . . . . .
3.2 Java Servlet . . . . . . . . . . . . . . . .
3.3 Ant . . . . . . . . . . . . . . . . . . . .
3.4 Velocity . . . . . . . . . . . . . . . . . .
3.5 Sphinx-4 . . . . . . . . . . . . . . . . . .
3.5.1 Architecture . . . . . . . . . . .
3.5.2 Configuration . . . . . . . . . . .
3.5.3 Modèle acoustique et de langage
3.6 Statistical language modeling toolkit . .
3.6.1 Exemple d’utilisation . . . . . . .
3.7 SphinxTrain . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
15
16
16
16
16
17
18
18
19
19
20
4 Entraı̂nement de modèle acoustique sur la base de données BREF
4.1 Base de données BREF . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Procédure d’entraı̂nement . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Préparations des données et fichiers nécessaires . . . . . . . . .
4.3 Lancement de la vérification des fichiers d’entrée . . . . . . . . . . . .
4.4 Lancement de l’entraı̂nement . . . . . . . . . . . . . . . . . . . . . . .
4.4.1 Fichiers de sortie . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
22
22
25
25
27
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Tests de performance
5.1 Tests de performance des modèles acoustiques du LIUM . . . .
5.1.1 Problèmes . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.3 Résultats des tests . . . . . . . . . . . . . . . . . . . . .
5.2 Tests de performance du modèle acoustique ”home made” . . .
5.2.1 Comment utiliser des modèles produits par SphinxTrain
5.2.2 Résultats des tests . . . . . . . . . . . . . . . . . . . . .
5.3 Erreurs typiques . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Comparaison des résultats des tests . . . . . . . . . . . . . . . .
. . .
. . .
. . .
. . .
. . .
dans
. . .
. . .
. . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
Sphinx-4?
. . . . . .
. . . . . .
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
28
29
29
29
30
30
30
32
32
32
6 Interface côté client
6.1 Interface Web . . . . . . . . . . .
6.1.1 Diagramme d’activité . .
6.1.2 Interface utilisateur . . .
6.1.3 Wiki Faq Glossaire . . . .
6.1.4 Ergonomie et accès rapide
6.2 Interface Java Swing . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
34
34
35
35
35
37
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
aux informations
. . . . . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6.2.1
6.2.2
Diagramme d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interface utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
38
7 Améliorations éventuelles
42
8 Conclusion
43
A Annexe
A.1 Structure de l’application Web . . . . . . . . . . . . . . . . . . . . . .
A.2 Comment ajouter une nouvelle grammaire dans le formulaire? . . . . .
A.3 Ajout d’une nouvelle langue d’interaction . . . . . . . . . . . . . . . .
A.4 Ajout d’une nouvelle langue de modles de langage, modles acoustiques
A.5 Quelques restrictions au sujet de l’utilisation de l’application Web. . .
A.6 Idée pour rendre le système plus dynamique? . . . . . . . . . . . . . .
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
45
45
46
46
46
46
List of Figures
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Vue générale de Web WriteIt! . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reconnaissance d’un signal acoustique . . . . . . . . . . . . . . . . . . . . . .
Modèle acoustique pour le phonème W . . . . . . . . . . . . . . . . . . . . . .
HMM pour le mot one . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Classification des systèmes RAP selon la qualité de signal et le CPU . . . . .
Architecture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entrée Sortie de Web WriteIt! . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architecture de Sphinx 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reconnaissance de la parole avec Sphinx-4 . . . . . . . . . . . . . . . . . . . .
Exemple d’utilisation du Statistical Language Model Toolkit . . . . . . . . .
Fichiers d’entrée et de sortie lors de l’entraı̂nement effectué avec SphinxTrain
BatchModeRecognizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Résultats des tests des modèles acoustiques du LIUM . . . . . . . . . . . . .
Résultats des tests des modèles acoustiques ”home made” . . . . . . . . . . .
Résultats des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagramme d’activité: Web/Html pour un fichier de sortie au format html . .
Diagramme d’activité: Web/Xml pour un fichier de sortie au format xml . . .
Entrée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Formulaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aide pour le formulaire: slimbox . . . . . . . . . . . . . . . . . . . . . . . . .
Aide pour le formulaire: tips . . . . . . . . . . . . . . . . . . . . . . . . . . .
Résultat de la reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagramme d’activité: Java Swing/Xml . . . . . . . . . . . . . . . . . . . . .
Entrée pour choisir le fichier audio, interface Java Swing . . . . . . . . . . . .
Formulaire pour lancer la reconnaissance, interface Java Swing . . . . . . . .
Résultat de la reconnaissance, interface Java Swing . . . . . . . . . . . . . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
8
9
9
11
14
15
17
19
21
21
28
30
32
33
34
35
36
37
38
39
39
40
40
41
41
List of Tables
1
2
3
Types de grammaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Domaines d’applications des systèmes RAP . . . . . . . . . . . . . . . . . . . . . .
Comparaison entre les deux modèles acoustiques . . . . . . . . . . . . . . . . . . .
4
9
12
33
Abstract
Le projet de Master Web WriteIt! a été proposé par le groupe DIVA du Département
d’Informatique de l’Université de Fribourg. Le but du projet est de proposer un accès simplifié aux possibilités de reconnaissance de parole de l’outil open source Sphinx. L’interface
proposée utilise des technologies Web dans une architecture client serveur. De façon plus
détaillée, l’application tourne sur un serveur Web Tomcat et permet la transcription d’un
fichier audio qu’un utilisateur aura ’uploadé’ depuis une interface Internet ou depuis tout
autre application. La reconnaissance de la parole continue se fait avec l’aide de Sphinx-4 en
utilisant des modèles acoustiques et des modèles de langages disponibles open source en anglais
et en français. Le projet visait également la création de nos propres modèles acoustiques en
français. Ces derniers ont été entraı̂nés en utilisant la base de donnée Bref de laquelle 56 heures
de parole ont été extraites. Des tests de performance effectués, sur base de ces modèles, ont
démontré que l’entraı̂nement avait convergé vers de bons modèles acoustiques présentant des
taux d’exactitude par mot de 78%. Ce qui correspond à des performances supérieures aux
modèles acoustiques open source utilisés dans la première phase de projet.
Keywords: Web Service, Speech Recognition, Acoustic Model Training, SphinxTrain,
BREF, Sphinx-4, RAP, French Acoustic Model
5
1
Introduction
Web WriteIt! est un projet de Master en Informatique proposé par le groupe de recherche DIVA1
de l’Université de Fribourg en Suisse. Le projet s’inscrit dans un semestre académique dont la
durée couvre une période de six mois de novembre 2006 à avril 2007.
Ce projet vise dans un premier temps à implémenter un service Web. Les utilisateurs pourront
l’utiliser pour recevoir la transcription d’un fichier audio wav grâce à un logiciel de reconnaissance
automatique de la parole. L’interface ergonomique proposera entre autre différents moyens pour
manipuler certains paramètres standard d’un moteur de reconnaissance de la parole automatique
comme le choix de la grammaire, les n hypothèses plausibles, le choix de la langue d’interaction,
etc. L’utilisateur a la possibilité de demander comme fichier de sortie un fichier html ou xml, cf
Figure 1. Puisque l’interface est designée pour un large publique, il est plus qu’essentiel de faire
des tests d’ergonomie et d’utilisation. Cela pour rendre l’interface la plus attrayante possible pour
l’utilisateur alpha.
Dans un second temps, le projet visera également à entraı̂ner des modèles acoustiques en français
en utilisant des outils d’entraı̂nement de modèles acoustiques et la base de donnée de signaux
acoustique BREF. Le but est d’obtenir une qualité équivalentes voire supérieure par rapport aux
modèles acoustiques actuellement disponibles open source. Puisqu’il existe depuis octobre 2006 des
modèles acoustiques français créé par le LIUM, de l’Université du Maine en France, il sera nécessaire
de faire des tests de performance de ces modèles et les comparer avec nos propre modèles.
Donc en résumé, il faut créer une interface d’interaction simple qui permet de réaliser la transcription de fichiers audio, puis entraı̂ner avec les outils adéquats nos propres modèles acoustiques
et les incorporer dans l’application. Et en dernier lieu, il faudra faire des tests de performance des
deux modèles acoustiques, cela pour savoir si les modèles ”home made” qui seront produits lors de
ce travail sont de bonne qualité ou non.
La Section 2 donne un bref historique ainsi qu’une classification des systèmes de reconnaissance
automatique de la parole avec quelques principes de base et domaines d’applications. La Section 3
décrit l’architecture générale du projet en expliquant chaque fois les technologies et outils utilisés.
La Section 4 présente l’entraı̂nement des modèles acoustiques ”home made” sur base de la base de
donnée Bref. Des tests de performance des modèles acoustiques ”home made” et ceux du LIUM
sont effectués dans la Section 5.2. La Section 6 montre plus en détail les interfaces utilisateurs
proposés pour l’interaction avec l’application Web. L’avant-dernière Section 7 expose quelques
améliorations possible pour le futur et la dernière Section 8 présente la conclusion du travail.
Figure 1: Vue générale de Web WriteIt!
1 DIVA
Group at University of Fribourg: http://diuf.unifr.ch/diva/web/
6
2
Reconnaissance automatique de la parole
La reconnaissance automatique de la parole (RAP) est la transformation d’un signal de parole en
une séquence de symboles représentative du contenu du signal. Les prochaines sections montreront
la rapidité de progression des technologies utilisées dans les systèmes de reconnaissance automatique
de la parole à travers quelques principes de base et domaines d’applications contemporaines de ces
systèmes.
2.1
Bref historique
L’historique suivant est un résumé de l’historique présenté dans un article paru dans ”vieartificielle.com”, et qui résume le livre ”Techniques de l’ingénieur, vol,H1 940, p.3”.
La reconnaissance de la parole est une discipline récente, qui a débuté à la moitié du vingtième
siècle. En 1952, Davis, Biddulph et Balashek ont développé dans les laboratoires Bell2 une machine
capable de reconnaı̂tre dix chiffres isolés monolocuteur, cette machine était entièrement câblée.
Dans ce genre de système, la méthode de reconnaissance est basée sur la recherche de paramètres
invariants, cela pour identifier le phonème. Il faut dire que ces systèmes étaient peu efficaces, mais
il ne faut pas oublier qu’ils étaient des pionniers dans ce domaine.
Dans les années soixante, il y eut beaucoup de progression, comme l’utilisation de méthodes
numériques, puis la reconnaissance de phonèmes en parole continue, ensuite la reconnaissance de
mots isolés (500 mots) et en dernier lieu l’utilisation d’informations linguistiques.
Dans les années septante, la programmation dynamique (DTW) a fait son apparition, ce qui
a engendré des systèmes efficaces pour une petite taille de vocabulaire. Malheureusement, ces
systèmes étaient pour la plupart dépendants du locuteur. Pendant ces années, le projet ARPA a
été lancé pour tester la faisabilité de la compréhension automatique de la parole continue. En 1974,
le LIUM a entrepris avec le projet Speech Understanding System la reconnaissance de phonèmes
de manière analytique. Dans le projet ARPA-SUR mené par J. Mariani et al. en 1978, le taux de
reconnaissance des phonèmes dépassait le 85%. C’est en ces années-là que les premiers appareils
commerciaux ont fait leur appartition.
Dans les années quatre-vingt des méthodes statistiques ont fait leur apparition avec l’utilisation
de HMM’s, l’utilisation de ce dernier a fait faire aux systèmes RAP un grand bond en avant.
Cela a permis une amélioration du taux de reconnaissance, de plus la reconnaissance est devenue
indépendante du locuteur, en utilisant des tailles de vocabulaires plus grandes. En juillet 1982, en
France il y eut le premier avion de chasse mondiale intégrant des possibilités de commande vocale,
le projet était dirigé par LIMSI3 en collaboration avec le Crouzet company pour le Research and
Technology Agency [13]. En 1986 a été lancé le projet japonais ATR pour la traduction automatique
par téléphone. Deux années, plus tard, sont apparues des machines à dicter par mots isolés, comme
le projet Voice-Activated typewriter en français.
Dans les années quatre-vingt-dix des méthodes hybrides sont apparues : utilisant des HMM’s et
des MLP (réseaux de neurones). Ce groupe de système est plus robuste (au bruit), plus rapide et
surtout plus performant. Les premières applications de dialogue oral homme-machine ont fait leur
apparition. En 1994, IBM a lancé son premier système de reconnaissance vocale et trois années
plus tard la dictée vocale en continu.
Aujourd’hui la reconnaissance de la parole est un domaine à forte croissance. De nos jours 80%
des gens qui veulent obtenir une information le font par le biais du téléphone et les 20% restant
utilisent internet [2]. Selon C. Becchetti et L. P. Ricotti, de nos jours, la reconnaissance de la
parole est le domaine le plus promettant, pour partir d’un seuil de 500 million de dollars à la fin
des années quatre-vingt-dix à 38 milliard de dollar en 2003 [4]. Les domaines d’applications de nos
jours seront plus détaillées dans la Section 2.10
7
Figure 2: Reconnaissance d’un signal acoustique
2.2
Principes de base
La Figure 2 montre d’une manière assez simple et schématisée le principe de la reconnaissance.
Tout d’abord, le signal acoustique est enregistré et numérisé. Le début et la fin du signal de la
parole sont ensuite détectés, par exemple en enlevant les bruits de respiration, les bruits ambiants
et le silence. Cela donne un signal de parole isolé. Puis a lieu une analyse acoustique, au cours
de laquelle se fait l’extraction des caractéristiques (calcul des paramètres acoustiques ou encore
vecteurs acoustiques). Son but est d’extraire des informations qui permettent de mieux séparer
les sons en utilisant notamment le transformée de Fourier rapide, qui permet de traiter le signal
dans le domaine fréquentiel. Les informations se trouvent alors dans une suite de vecteurs. Ces
vecteurs sont utilisés avec le modèle acoustique, le modèle de langage (aussi appellé grammaire) et
le dictionnaire adéquat pour reconnaı̂tre ce qui a été dit. D’abord il y a une classification de forme
(pattern classification) utilisant comme input la séquence de caractéristiques qui donne comme
output une séquence de modèle. Ensuite il y a lieu le traitement du langage, c’est-à-dire que les
modèles de langage sont utilisés pour donner des mots, ou suites de mots reconnus.
Les modèles acoustiques détectés correspondent généralement aux phonèmes, la séquence de
phonème quand à elle est modélisée par le dictionnaire pour constituer des mots et finalement les
phrases sont modélises par les grammaires qui définissent les séquences de mots probables.
2.3
Pourquoi utiliser des HMM’s pour modéliser des modèles acoustiques?
Un HMM est un graphe libellé avec des noeuds représentant des états acoustiques, et des arcs
orientés pour la probabilité de transition entre ses états [4]. Les Figures 3 et 4 dans la Section 2.4
montre des exemples de HMM’s. Selon Becchetti et Ricotti, ”les Hidden Markov Model’s sont des
chaı̂nes de Markov, où les symboles de sortie ou fonctions de probabilité décrivant les symboles de
sortie sont associées soit à l’état soit aux transitions entre les états” [4].
2 AT&T
Bell Laboratories
laboratoire d’informatique pour la mécanique et les sciences de l’ingénieur. Laboratoire propre du
CNRS, avec des aides financières du GDR-PRC CHM de l’Agence de Coopération Culturelle et Technique et de la
CEE
3 LIMSI:
8
2.4
Modèle acoustique
Le modèle acoustique est généralement un HMM à un état associé à un phonème. Par exemple
le modèle acoustique pour le phonème W peut être modélisé comme montré dans la Figure 3.
Les modèles acoustiques sont strictement liés aux conditions d’entraı̂nement. C’est-à-dire qu’ à
Figure 3: Modèle acoustique pour le phonème W
l’ensemble des données acoustiques utilisées pour l’entraı̂nement et l’environnement où elles ont
été enregistrées conditionent les paramètres du HMM. Un HMM entraı̂né sur des séquences de
digits en qualité téléphonique donnera des résultats optimaux que sur des séquences de digits en
qualité téléphonique. Par exemple le mot ONE(2) qui contient les phonèmes W AH N peut être
représenté par le HMM de la Figure 4.
Figure 4: HMM pour le mot one
2.5
Dictionnaire
Un dictionnaire est une liste de mots, chacun suivi de sa prononciation [12]. Un mot peut avoir
dans le dictionnaire plus d’une prononciation, par exemple le mot ONE a deux prononciations:
ONE
ONE(2)
2.6
HH W AH N
W AH N
Grammaire
Une grammaire ou modèle de langage est un ensemble de phrases et de mots que les utilisateurs
peuvent énoncer pour interagir avec le système. Dans un système à simple commande, la grammaire
est une simple liste de mots, dans un système à dialogues elle est une grammaire à état fini. Et dans
un système à dictée vocale ou audio mining, la grammaire est stochastique. Il existe différents types
de grammaires, comme les grammaires à état fini (finite state grammars) qui sont un ensemble fini
de phrases et de mots et les grammaires stochastiques (n-gram) qui sont eux définies en terme de
probabilités qu’un mot (bigram) ou qu’un ensemble de mots (n-gram) précèdent un autre mot, cf.
la Table 1. Les modèles 2-, 3-gram sont généralement utilisés dans les systèmes de reconnaissance
de la parole continue.
Table 1: Types de grammaire
Taille du vocabulaire
Fichier de Grammaire
Grammaires à état fini
limité
contient les phrases possibles
9
Grammaires stochastiques
beaucoup plus grande
contient la probabilité que plusieurs
mots se suivent
JSGF Le Java Speech Grammar Format est une représentation textuelle de grammaire utilisée
dans la reconnaissance de la parole. Ce langage est platforme-indépendant et vendeur-indépendant.
Les Grammaires sont utilisées pour déterminer ce qui est permis, et reconnu par le moteur de la
reconnaissance de la parole. JSGF adopte le style et convention de Java4 .
Limitations des JSGF Pour le cas particulier de Sphinx, les grammaires contenant des boucles
font arrêter le Recognizer5 . Par exemple la grammaire
#JSGF V1.0
grammar excuse;
public <chiffres> =
(UN* | ZERO*)+;
est équivalent à ()+, et donc ne représente rien. Ce qui peut avoir comme résultat qu’il y ait une
boucle infinie.
2.7
Au moins quatre défis pour la reconnaissance
Il existe au moins quatre défis pour réussir une bonne reconnaissance de la parole, en dehors
du matériel utilisé comme la qualité du microphone par exemple ou le moyen de communication:
bande passante limitée comme le téléphone fixe. Le premier est l’ambiguı̈té, deux phrases différentes
peuvent être prises comme étant très semblables par le système, suivant l’intonation et la fréquence
des mots (rapidité de prononciation de plusieurs mots). En général lorsque la grammaire est grande
cela veut dire que l’ambiguı̈té l’est aussi. Des phrases plus longues peuvent aider à enlever ce
problème. Le deuxième défi est lié au fait que l’information acoustique est limitée, dans le cas par
exemple de mots courts comme le, la: pour remédier à cela des phrases plus longues peuvent être
utilisées. Elles seront reconnues plus facilement, car elles donnent plus d’informations acoustiques.
Le défis suivant est le bruit ou parasite tel que le bruit ambiant, les sons tels que la respiration
et le rire. Comme d’autres sources de problèmes nous pouvons avoir ceux liés à la personne,
simplement son élocution, articulation des mots prononcés, le stress physique ou émotionnel, la
rapidité d’élocution.
2.8
Types d’erreurs lors de la reconnaissance
Il est clair qu’aucun système n’est parfait. Cela veut dire qu’il y a toujours des erreurs de suppression, d’insertion ou de substitution des mots. Ces notions sont utilisés pour classer les différents
systèmes existant dans le marché selon leur Word Accuracy et Word Error Rate. Dans le cas d’une
substitution, ce qui est dit par l’utilisateur est mal reconnu: "c’est" !→ "ces", ceci peut être
dû à une mauvaise prononciation, articulation du mot. Dans celui d’une insertion, par exemple,
l’utilisateur dit "je pense que" et c’est "je ne pense pas que" qui est reconnu, ici les deux
mots ne et pas sont insérés en changeant fondamentalement le sens. Et en dernier pour la notion
de suppression, l’utilisateur dit "je pense que" et c’est "je pense" qui est reconnu, le mot que
est effacé.
2.9
Classification des systèmes de reconnaissance automatique de la parole
Les systèmes de reconnaissance automatique de la parole, ou RAP, sont classés selon plusieurs
critères. Le premier est le nombre de locuteurs qui utilisent le système: dépendant du locuteur
pour un seul utilisateur, multilocuteur pour quelques utilisateurs ou indépendant du locuteur pour
un nombre illimité de personne. En règle général, plus le nombre d’utilisateur augmente, plus la
performance diminue, et vice versa. Le deuxième critère déterminant est le rythme de la parole
ou l’élocution, comme des mots isolés pour un mot à la fois, des mots connectés pour des mots
enchaı̂nés, la parole continue et la conversation. Plus le nombre de mots qui peuvent être dit par
le locuteur augmente plus la performance diminue. Il existe aussi des systèmes de RAP par mots
4 http://java.sun.com/products/java-media/speech/forDevelopers/JSGF/
5 http://cmusphinx.sourceforge.net/sphinx4/javadoc/edu/cmu/sphinx/jsapi/JSGFGrammar.html
10
clés. La taille et complexité du vocabulaire joue aussi un rôle, car le vocabulaire peut aller d’une
dizaine de mots à des dizaines de milliers de mots. La contrainte grammaticale peut aussi être
importante pour classifier ces systèmes, car il est facile d’imaginer des grammaires de quelques
lignes et d’autres de quelques 250M compressées! La qualité de transmission du signal acoustique
et sa qualité d’acquisition sont aussi prises en compte pour la classification. La Figure 5 montre la
classification des systèmes suivant la qualité de signal acoustique et les performances demandées
pour la reconnaissance. Les systèmes utilisant la reconnaissance de la parole sont très exigeants
Figure 5: Classification des systèmes RAP selon la qualité de signal et le CPU
pour le CPU et la RAM. Généralement la diminution de la qualité du signal s’accompagne par
la réduction de la puissance CPU nécessaire. C’est le cas par exemple dans des systèmes de
reconnaissance par mots clés (une douzaine de mots en général) qui peuvent fonctionner dans des
téléphones portables pauvres en ressource. Dans les applications de contrôle comme la navigation
Internet, le système même s’il utilise peu de CPU, a besoin d’une bonne qualité de signal. En
revanche pour des systèmes côté serveur, comme Web WriteIt! même s’il n’y a pas vraiment besoin
d’une bonne qualité, le système utilise beaucoup de CPU et de RAM, à cause du grand nombre
d’utilisateurs qui peuvent utiliser le système en même temps. Pour des applications de dictée, ou
aux buts pédagogiques pour apprendre une nouvelle langue, il faut beaucoup de ressources tant
du CPU que de RAM. En général, une bonne qualité de signal s’accompagne d’un grand besoin de
ressources.
2.10
Applications
Les applications de la reconnaissance de la parole existent là où ils peuvent remplacer/compléter
une interaction déjà existante. Parfois, c’est le seul moyen de communication qui peut exister,
par exemple pour des applications mains-libres (pour téléphones portables, smartphones, etc.). La
Table 2 montre quelques domaines d’applications des systèmes RAP6 .
Dans le domaine de la téléphonie, la reconnaissance de la parole est utilisée:
• ”phone-banking” de UBS 7 pour des opérations bancaires
• ”Directories 1234 - Lisa” de Belgacom 8 pour les annuaires électroniques
• ”Swisscom Vocal Portal” de Swisscom 9 comme portail vocal
• ”Via Suisse 163” de Via Suisse 10 pour savoir l’état du trafic routier en Suisse
6 http://diuf.unifr.ch/diva/wiki/index.php/Seminar
7 http://www.ubs.com/1/f/ebanking/phone
on State-of-the art and new trends of voice interfaces
banking/phone voice.html
8 http://www.1234.be/
9 http://www.swisscom-fixnet.ch/fx/privatkunden/telefonie/dienste/Sprachportal/index.htm?languageId=fr
10 http://www.viasuisse.ch/franz/medien/telefondienste.htm
11
Table 2: Domaines d’applications des systèmes RAP
Domaine
Téléphonie
Embarqué
Multimédia
Médical
Industriel
Applications
Telephony & Banking, Assistance and Services
Automobile, Maison intelligente
Dictée vocale, Logiciels pédagogiques, Jeux vidéos
Aide aux personnes handicapées, rééducation assistée
Biométrie, Contrôle vocal de machines
• ”Europlex Cinema”11 pour des informations sur des films et leurs lieux et heures de projection
• ”BVBmobile für die Linien von 1 bis 55” de Basler Verkehrs-Betriebe 12 pour des informations
sur les horaires des bus à Bâle
Dans le domaine embarqué comme les contrôles mains-libres dans la voiture, téléphone sans fil,
voice dialing:
• ”OnStar” de General Motors 13 pour les appels téléphoniques, la navigation et autres services
• ”UConnect” de DaimlerChrysler 14 pour des appels à mains libres
• ”Lingatronic” de Mercedes 15
• ”NaviDrive” de Citroën 16
Le domaine multimédia est vaste, ce domaine couvre des applications comme:
• ”Dragon Naturally Speaking” de Nuance 17
• ”ViaVoice” de IBM 18
• ”FreeSpeech” et ”Dictaplus” de Dicta Plus 19 pour la dictée vocale
• ”Tell me more online” de Nuance
• ”GlobalEnglish” de Microsoft
• ”RosettaStone”20 comme logiciels à but pédagogique pour apprendre une nouvelle langue ou
pour une meilleure prononciation
• ”AIBO, Voice Activated R2-D2, Smart Cars” comme des applications ludiques telles que des
jeux vidéo ou robot commandé à distance par la voix
Le domaine médical est assez explicite et permet d’aider des personnes ayant des handicaps,
ou à but thérapeutique:
• le composant de ”Opera”21 pour surfer sur Internet avec la voix
• ”Acapela Infovox Desktop Pro” de Acapela Group 22 pour lire ce qui se trouve dans l’écran
de l’ordinateur.
11 http://www.europlexcinemas.ch/
12 http://www.bvb-basel.ch/
13 http://www.onstar.com/us
english/jsp/index.jsp
14 http://www.daimlerchrysler.com/dccom/0-5-470118-1-480351-1-0-0-0-0-0-36-479389-0-0-0-0-0-0-0.html
15 http://www.mercedes-benz.ch/
16 http://www.citroen.com/CWW/en-US/TECHNOLOGIES/COMFORT/NAVIDRIVE/
17 Nuance:
http://www.nuance.com/
18 http://www-306.ibm.com/software/voice/viavoice/fr/
19 Dicta
Plus: http://www.dictaplus.com/index.php?index=624
Stone: http://www.rosettastone.co.uk/en/individuals
21 Opera:voice: http://www.opera.com/voice/
22 Acapela-Group: http://www.acapela-group.com/products/products.asp#shelf
20 Rosetta
12
Le dernier domaine qui est industriel, regroupe l’utilisation de cette technologie pour la biométrie,
pour être sûr que c’est bien la personne qui est censée utiliser le service qui parle:
• ”SECUREvoice” pour identifier des personnes par téléphone
• ”Voicencrypt” pour protéger son ordinateur personnel
• ”Nuance Verifier” de Nuance pour accéder des informations importantes par téléphone
Plusieurs systèmes sont spécialisés dans la reconnaissance automatique de la parole:
• ”Dragon NaturallySpeaking” de Nuance23
• ”IBM ViaVoice”24
• ”CMU Sphinx-4” qui est open source25
2.11
Interface vocale utilisateur
Les interfaces vocales utilisateur, ou VUI, permettent l’interaction d’une personne avec un système
de reconnaissance de la parole en utilisant la voix. Les éléments d’un VUI sont les prompts
(messages du système) et les grammaires qui définissent ce que l’utilisateur peut dire pour interagir
avec le système. Finalement il y a la logique de dialogue qui est l’ensemble d’actions que le système
va prendre pour répondre aux inputs des utilisateurs [12].
Un bon système de VUI doit être conçu pour une large population de non-experts. Par exemple
un message de bienvenue, puis l’utilisation de peu d’éléments dans le dialogue (nombre de sousmenus), et d’earcons. Un earcon est un son spécifique pour représenter un événement, il peut
être considéré comme un équivalent auditif d’un icône. Les earcons sont utilisés pour faciliter la
navigation à travers la logique de dialogue [10].
23 Nuance
Dragon NaturallySpeaking: http://www.nuance.com/naturallyspeaking/
ViaVoice: http://www-306.ibm.com/software/voice/viavoice/
25 http://cmusphinx.sourceforge.net/html/cmusphinx.php
24 IBM
13
3
Architecture générale
L’architecture de Web WriteIt! se base sur une architecture n-tiers comme montré dans la Figure 6.
Web WriteIt! se base plus précisément sur une architecture trois tiers, dans laquelle l’architecture
logique du système est divisée en trois couches:
• la couche présentation
• la couche métier
• la couche accès aux données
La première couche peut prendre beaucoup de formes, telles que navigateur Web, téléphone
portable, une application de bureau etc. Cette couche permet de transmettre les requêtes de
l’utilisateur à la couche métier et représente les informations reçues de cette dernière. La seconde
couche correspond à la logique applicative, c’est la couche métier, c’est ici qu’ont lieu les différents
traitements requis par rapport aux requêtes des utilisateurs distants. Cette couche peut requérir
des données présentes dans des modules de stockages tels que des bases de données MySql, Oracle,
Tamino, etc. Dans la dernière, nous trouvons les données persistantes, qui sont le plus souvent
stockées dans une base de données. Les trois couches sont indépendantes des unes des autres.
Pour des problèmes de performances, la couche de donnée est dans la même machine que celle de
la couche métier, cela à cause de quelques fichiers trop volumineux pour être mis dans une base
de données, ces fichiers sont des fichiers de modèle de langage de quelques 250MB. L’application
Figure 6: Architecture du projet
dans la couche logique applicative et la couche des données est invisible à l’utilisateur, ainsi ces
deux parties peuvent être vues comme un module. Ce module prend en input les entrées suivantes
qui doivent être postée en multipart/form-data via le protocole HTTP. La Figure7 montre les
entrées et sortie de Web WriteIt! Où les termes suivants peuvent être définies comme suit:
file le fichier wave à reconnaı̂tre.
grammar le choix de la grammaire qui doit être de ce genre: fr#french, en#hub4 avec la syntaxe,
01#02, où 01 est le dossier qui définit quelle langue on traite, le 02 est le sous dossier.
nbest pour le nbest, un valeur quelconque pour affirmer que l’utilisateur veut les nbests résultats,
sinon null et le String ”null” pour faux.
wwiout pour l’output voulu: pour l’instant il existe un fichier html pour le navigateur Internet
et un fichier xml pour tout autre usage. Wwiout peut prendre les valeurs html et xml.
Toute application voulant utiliser le service proposé par Web WriteIt! doit lui fournir ces
entrées, sans quoi l’application ne marchera pas. Par exemple dans l’utilisation d’une interface
14
Swing, il est nécessaire de faire une requête http à la Servlet ProcessWaveupload qui enregistrera
le fichier dans le serveur, puis dirigera la requête vers la Servlet ProcessWaveRecognizeToXML, qui
rendra un fichier XML. Donc, en plus de faire un post à ProcessWaveupload il faut faire un get
au Servlet ProcessWaveRecognizeToXML.
Figure 7: Entrée Sortie de Web WriteIt!
3.1
Tomcat
Tomcat Apache est un serveur d’application libre, incluant un serveur http interne créé par la
fondation Apache. Tomcat agit comme un conteneur de Servlets J2EE. La version actuelle est
la 6.0.2, pour des raisons de compatibilité le projet à été développé dans une version antérieure
(4.1.30 et 4.1.34). La version 4.1.30 implémente les spécifications Servlets 2.3, Catalina est son
conteneur de Servlets. Tomcat inclut également différents outils pour la configuration et gestion
des différents modules.
La configuration peut aussi être faite par différents fichiers de configuration en XML : comme
server.xml pour le serveur, tomcat-users.xml pour définir les utilisateurs, leur mot de passe et
différents rôles, catalina.policy pour la police de sécurité.
L’arborescence de Tomcat se compose des dossiers suivants:
• bin : contient différents scriptes et exécutables.
• common : comprend des classes communes
• conf : est le répertoire où se trouvent les différents fichiers de configuration.
• logs : contient les journaux (logs) des applications Web et de Tomcat.
• server : possède les classes utilisées par Tomcat.
• shared : contient des classes partagées.
• webapps : inclut les différentes applications Web, c’est dans ce répertoire que les applications
sont déployées.
• work : est un dossier pour les fichiers et répertoires temporaires.
Tomcat fonctionne en association avec l’Apache HTTP Server, qui est utilisé pour les pages standard, et Tomcat pour les applications Web. Apache envoie les requêtes à Tomcat sur le port
8080.
15
L’application a besoin d’un serveur d’application, pour que le cycle de vie soit pris en charge
par le conteneur, pour que le traitement soit fait dans le serveur et non-plus chez le client, cela pour
permettre l’agrandissement de l’éventail des utilisateurs: smartphones, pda’s, téléphones portables,
applications Java, page Internet, et aussi pour réduire les inconvénients liés à la mise en place d’un
outil complexe tel que Sphinx.
3.2
Java Servlet
Une Servlet Java génère dynamiquement des données, au sein d’un serveur HTTP, présentées
généralement au format HTML mais également XML. La Servlet se trouve dans un conteneur
Web, et maintient son état en utilisant des cookies et des variables de session. L’api décrit les
relations entre le conteneur et les Servlets. Les Servlets étendent HttpServlet et interagissent
avec le serveur HTTP par les objets HttpServletRequest et HttpServletResponse. Le conteneur
de Servlet gère le cycle de vie des Servlets : lorsqu’il reçoit une requête, il sélectionne la Servlet
qui devra traiter cette requête et s’il n’a pas été instancié, le conteneur charge la classe, crée
une instance et l’initialise. Ensuite, le conteneur invoque la méthode en passant par les objets
HttpServletRequest et HttpServletResponse. Lorsque le Servlet n’a plus d’utilité, le conteneur
le détruit avec la méthode destroy. Le choix d’implémentation par des Servlets vise à simplifier le
travail du designer, car une très grande partie du travail est effectuée par le conteneur de Servlet.
3.3
Ant
Apache Ant est un projet open source écrit en Java donc ”cross-plateforme: work anywhere,
everywhere”, dont le but premier est d’automatiser des opérations répétitives de compilation et
de déploiement de logiciel Java ou autre. Il permet entre autre la compilation, génération de
javadoc, archivages, etc, lors du cycle de développement logiciel, ou tout autres opérations telles
que créations de documents, fichiers, images cd à graver. Ant ne souffre pas de limitations de make,
comme par exemple: il est possible d’avoir beaucoup de faute avec make pour cause d’espace mal
positionnée. Avec le fichier de configuration build.xml il est facile de créer ses propres targets,
de plus ce dernier sera plus compréhensible que celui de make qui sont des commandes shells. Ant
permet de travailler indépendamment du systèmes d’exploitations et d’installer une application
rapidement.
3.4
Velocity
Velocity est un moteur de template écrit en Java développé par la fondation Apache. Il permet de
référencer des objets définis dans le code java, et de ce fait facilite l’interaction entre le développeur
et le Web designer. Velocity est une bonne alternative au PHP et JSP, et peut être utilisé de
différentes manières. Par exemple le projet Anakia l’utilise pour générer des fichiers SQL, Postscript
et XML[1]. Dans le projet Web WriteIt!, on utilise Velocity utilise travers différents ”templates”
qui donnent en sortie les résultats html ou xml dans lesquels certaines parties sont dynamiques
comme par exemple les langues ou les résultats de la reconnaissance:
WwiReco.xml pour le fichier de sortie XML.
PrepareShowResults.html pour le fichier de sortie Html.
PrepareWaveUpload.html pour le formulaire.
header.vm et footer.vm pour le haut et le bas de page.
3.5
Sphinx-4
Sphinx-4 est un système de reconnaissance vocale écrit entièrement en Java, donc indépendant
du système d’exploitation. Ce projet est développé conjointement par Carnegie Mellon University, SUN Microsystems Laboratories, Cambridge Research Lab de Hewlett-Packard et Mitsubishi
Electric Research Labs. L’utilisation de Sphinx-4 dans le projet amène, modularité, facilité de
16
développement, et d’intégration. Sphinx-4 utilise des HMM’s continus et fournit une grande flexibilité, exactitude et vitesse. Sphinx-4 est modulaire, flexible, accepte différentes grammaires et
langues. Il faut néanmoins trouver un équilibre entre l’exactitude et la vitesse en jouant sur
les paramètres du fichier de configuration comme le absoluteBeamWidth, relativebeamWidth,
absolutWordBeamWidth, languageWeight, acousticLookahead, etc.
3.5.1
Architecture
Sphinx-4 se compose de trois modules primaires : Le Front-End, le Decoder et le Linguist. Le
Figure 8: Architecture de Sphinx 4
Front-End découpe l’Input pour créer une séquence de vecteurs appelée Features. Ces derniers
sont des objets composés de signaux parametrisés qui seront utilisés par le Decoder[20].
Le Front-End se compose de plusieurs chaı̂nes de DataProcessor en parallèle, cela permet à
Sphinx-4 de pouvoir traiter simultanément le même signal. Sphinx-4 est mieux que le AVCSR
car dans ce dernier la séquence de features en parallèle est limitée, tandis que dans Sphinx-4 ce
nombre est arbitraire [20]. Les DataProcessor’s utilisent un design de type pull: c’est-à-dire qu’ils
demandent l’Input si besoin. Cette manière d’agir permet au Decoder de faire des recherches
Viterbi (frame-synchronous), depth-first et A∗
Le Linguist peut être vu comme une base de connaissances. Il génère un SearchGraph en
utilisant des informations de prononciations du Dictionnaire, du LanguageModel et l’information
structurelle de n AcousticModels.
Le Dictionnary définit les prononciations des mots trouvés dans le LanguageModel en utilisant
l’AcousticModel.
L’AcousticModel représente l’information structurelle et sa topologique. Il existe trois sortes
de modèle de langage: pour les mots isolés, pour les applications basées sur des commandes et le
dernier pour le langage courant. L’AcousticModel est un mapping entre une unité de parole et un
HMM qui donnera un score en utilisant la séquence de features. Les HMM’s dans Sphinx-4 sont
des graphes dirigés d’objets, c’est-à-dire que chaque noeud est un état de l’HMM, chaque arc la
probabilité de passer de cet état à un autre.
Le LanguageModel limite ce qui peut être dit dans un contexte, il en existe deux implémentations:
les ”graph-driven grammars” et les ”stochastic n-Gram” models. Les graph-driven grammars sont
un direct Word graph. Les modèles n-gram ont les probabilités des mots sachant une observation
des n-1 mots. Sphinx-4 supporte plusieurs formats : SimpleWordListGrammar, JSGFGrammar,
LMGrammar, FSTGrammar, SimpleNGramMoel, LargeTrigramModel.
Le FlatLinguist est utilisé pour les context-free grammars, finite-state grammars, finite-state
transducers et de petit modèle de langage n-gram. Il convertit un format de modèle de langage
en une grammaire interne qui n’est rien d’autre qu’un graphe dirigé dont les noeuds sont des mots
et les arcs sont des probabilités que cette transition de mots arrive. Le FlatLinguist génère le
SearchGraph directement depuis la Grammaire interne, et l’enregistre dans la mémoire.
Le DynamicFlatLinguist génère le SearchGraph à la demande, peut donc prendre en charge des
grammaires plus complexes. Le LexTreeLinguist pour les grands vocabulaires utilise des modèles
17
de langage n-gram.
Sphinx-4 utilise le token-passing algorithme, c’est-à-dire qu’à chaque recherche un nouveau
token est créé. Un token est un objet associé à un état et contient le score (acoustique et langage)
à un point bien précis du chemin.
Le Decoder est le coeur de Sphinx-4. Le SearchManager demande au scorer le score de chaque
token se trouvant dans l’ActiveList avec le score reçu (score du feature avec le searchgraph), puis
le pruner enlève les chemins ayant les moins bons scores. Les chemins survivants passent alors
dans un nouvel état. De nouveaux tokens sont ensuite crées. Le processus se répète tant que le
FrontEnd envoie des features. Lorsque l’algorithme se termine c’est le résultat qui a le meilleur
score qui est choisi, et retourné par le Recognizer comme résultat à l’application.
Le Configuration Manager sert à configurer différents paramètres. La configuration peut se
faire de manière dynamique pendant le runtime de l’application.
Sphinx-4 fournit différentes implémentations dans son système sous le répertoire demo/sphinx:
hellodigits utilisant une grammaire au format Java Speech Grammar, et des modèles acoustiques
”TIDIGITS” pour reconnaı̂tre des ”connected digits”.
helloworld reconnaı̂t des phrases simples pour dire ”hello will”, etc. et utilise un JSGF grammaire, avec des modèles acoustiques ”WSJ”.
hellongram utilise un modèle de langage SimpleNGram et le même modèle acoustique ”WSJ”
que le helloworld.
zipcity pour reconnaı̂tre des codes postaux, zipcity est intégré dans une application Java Web
Start pour montrer sur une carte la ville qui est associée au code postaux prononcé par
l’utilisateur. C’est un JSGFGrammar avec le modèle acoustique TIDIGITS qui est utilisé.
wavfile, transcriber montre comment la reconnaissance de nombres connectés depuis un fichier
audio peut se faire. Ils utilisent un JSGFGrammar et le modèle acoustique TIDIGITS.
confidence est un exemple d’implémentation pour montrer comment obtenir des ”confidence
scores” en utilisant Sphinx-4. Avec le modèle de langage 3-gram de 170 mots et le même
modèle acoustique que le hellongram.
3.5.2
Configuration
La configuration se fait à l’aide d’un fichier de configuration Xml. Le fait d’utiliser un fichier Xml
permet d’être extrêmement modulable et configurable.
La propriété absoluteBeamWidth a pour tâche de donner la taille désiré pour la liste active, il
faut lui mettre comme valeur −1 pour ne pas poser de limites de tailles à cette liste. Pour l’exemple
de hellongram, la valeur optimale est de 500. En général, la meilleure valeur est obtenue avec 2000
[19].
La propriété relativeBeamWidth sert à placer relativement les scores minimaux par rapport
aux scores maximaux dans la liste pour le pruning. Selon l’Université de Gothenburg la valeur
optimale est de 1E-80 [19].
La propriété languageWeight définit le poids du langage pour la recherche. La diminution de
cette valeur réduit la contribution du modèle de langage au score final.
3.5.3
Modèle acoustique et de langage
Il existe différentes demos dans le système Sphinx-4, chacunes avec différents modèles acoustiques
et de langage26:
TIDIGITS est un modèle acoustique pour l’anglais entraı̂né pour 11 mots (chiffres de 0 à 9 et
le mot oh), utilisé dans les démos ”hellodigits” et ”zipcity”, ”wavfile” et ”transcriber” avec
différentes grammaires à état fini.
26 http://sourceforge.net/project/showfiles.php?group
id=1904&package id=117949
18
WSJ5K a été entraı̂né en utilisant la base de données Wall Street Journal, il existe le modèle de
langage pour 5000 mots. Les caractéristiques ont été calculées sur de la parole échantillonnée
à 16Khz avec une résolution de 16bitl Les features sont de type cepstra à 13 dimensions
calculées avec 40 filtres mel couvrant l’intervalle de fréquence de 130Hz à 6800Hz. Il est
utilisé dans ”helloworld” et ”hellongram”.
RM1 entraı̂né pour un vocabulaire moyen de 1000 mots.
HUB4 étant le vocabulaire à 64000 mots. Il a été construit de manière semblable au LDC 1999
HUB-4. Le texte utilisé pour produire ce modèle a été extrait de plusieurs sources autorisées,
y compris des nouvelles de quotidiens.
Figure 9: Reconnaissance de la parole avec Sphinx-4
3.6
Statistical language modeling toolkit
Le SLMT est un ensemble d’outils (application UNIX) permettant de modéliser et tester des
modèles de langage statistiques27 . Dans le cas de notre projet, l’outil a été utilisé pour créer une
liste de 5000 mots utilisée dans une grammaire à état fini (doyle grammar). Ce n’est qu’une petite
partie de ce qui peut être fait avec cet outil. En donnant des phrases comme entrées de ces outils,
la fréquence d’apparition des mots, une liste de vocabulaire utilisée, la création de grammaires
n-gram peuvent être calcuées.
3.6.1
Exemple d’utilisation
Cette section explique plus en détail la Figure 10 qui montre une utilisation typique de SLMT.
Tout d’abord il faut conditionner le fichier texte28 qu’il faut donner en input. Des scripts Perl
sont ici utilisés pour enlever les ponctuations, transformer les lettres minuscules en capitales et les
chiffres en mots. Le texte peut contenir du vide, et des tags (cue-tags par exemple <s> et </s>).
...
To Sherlock Holmes she is always THE woman. I have seldom heard him
...
Des tags peuvent êtres ajoutés si besoin.
<s>
...
TO SHERLOCK HOLMES SHE IS ALWAYS THE WOMAN I HAVE SELDOM HEARD HIM
...
</s>
27 http
: //www.speech.cs.cmu.edu/speech/SLM/toolkitdocumentation.html
texte pour créer le grammaire de 5000 mots à été tiré du THE ADVENTURES OF SHERLOCK HOLMES
by SIR ARTHUR CONAN DOYLE
28 le
19
1.
cat fichier.text | text2wfreq > fichier.wfreq
Le fichier wfreq liste les mots et leur fréquence d’apparition dans le texte.
....
IMPASSABLE 1
MAGNIFICENT 2
POCKETS 8
...
2.
cat fichier.wfreq | wfreq2vocab -top 5000 > fichier.vocab
Donne un fichier de vocabulaire de 5000 mots en prenant en input le fichier créé dans le
point 1.
## Vocab generated by v2 of the CMU-Cambridge Statistcal
## Language Modeling toolkit.
##
## Includes 5000 words ##
</s>
A
ABANDONED
ABBOTS
ABERDEEN
ABLE
ABOMINABLE
...
3.
cat fichier.text | text2idngram -vocab fichier.vocab -temp ../tmp > fichier.idngram
Génère le fichier binaire id 3-gram du texte en se basant sur le vocabulaire.
4.
idngram2lm -idngram fichier.idngram -vocab fichier.vocab -binary fichier.binlm
Convertit le fichier idngram dans un format de modèle de langage.
5.
evallm -binary fichier.binlm
Calculons alors la perplexité du modèle en tenant compte d’un fichier texte de test.
evallm -binary fichier.binlm
Reading in language model from file fichier.binlm
Done.
evallm : perplexity -text fichierteste.text
..
3.7
SphinxTrain
SphinxTrain est un outil produit par CMU pour créer et entraı̂ner des modèles acoustiques continus
(modèles acoustiques pour Sphinx-3 et Sphinx-4), et semi-continus (modèles acoustiques pour
Sphinx-2). Pour plus de détails sur l’intégration des modèles acoustiques de Sphinx-3 dans Sphinx4 référez-vous à la Section 5.2. L’utilisation de cet outil pour l’entraı̂nement est détaillée dans la
Section 4.2. La Figure 11 montre les fichiers d’entrée et de sortie standard lors de l’utilisation de
SphinxTrain pour entraı̂ner des modèles acoustiques. L’explication détaillée des différents fichiers
de sortie, constituant les modèles acoustiques se trouve dans la Section 4.4.1.
20
Figure 10: Exemple d’utilisation du Statistical Language Model Toolkit
Figure 11: Fichiers d’entrée et de sortie lors de l’entraı̂nement effectué avec SphinxTrain
21
4
4.1
Entraı̂nement de modèle acoustique sur la base de données
BREF
Base de données BREF
Le corpus BREF a été créé par le LIMSI29 en 1993 pour développer et évaluer des systèmes
de reconnaissance de parole continue, en mode dépendant ou non dépendant du locuteur [20].
Le corpus a été établi à partir d’articles de journaux (Le Monde) lus sans tenir compte de la
ponctuation. Les articles de journaux possèdent des domaines très vastes comme la finance, la
politique, la géographie et la culture.
BREF contient pour 100 heures d’enregistrements de parole. Ceci représente 36 GBytes de
données acoustiques, au format NIST Sphere (échantillonnées à 16kHz et numérisées sur 16 bits,
compressée avec SHORTEN30 avec entête au format SPHERE de 1024 octets), de 120 locuteurs
(55 hommes, 65 femmes) et leur transcription. Les textes ont été choisis pour maximiser le nombre
de contextes phonétiques. La taille du vocabulaire est de 20000 mots contenant 1115 diphones et
17500 triphones ont été collectés qui peuvent être utilisés pour entraı̂ner des modèles phonétiques
indépendants du vocabulaire. Les enregistrements ont été faits avec un microphone Shure SM10
et Crown PCC160 dans une pièce insonorisée.
Afin de pouvoir utiliser les outils d’entraı̂nement Sphinx, un préprocessing des accents a été
nécessaire. D’abord l’apostrophe ” ’ ” est remplacée par le tilde ”˜”. Puis les caractères accentués
sont remplacés par deux caractères. Par exemple le ” é ” est remplacé par ” ’e ”, etc. La liste
complète des correspondances se trouve dans la sous section 4.2.1.
Bref contient des noms propres et quelques termes de finance et de géopolitique datent des
débuts des années 1990. C’est pourquoi il reste beaucoup de mots qui existent et qui ne sont plus
tant utilisés aujourd’hui et vice versa (aucun filtrage n’a été effectué).
4.2
Procédure d’entraı̂nement
Selon la documentation de Sphinx, il faut au minimum entre huit et dix heures de données acoustiques pour faire un entraı̂nement acoustique qui donne des performances raisonnables.Ce nombre peut diminuer si le designer veut seulement adapter et améliorer un modèle acoustique déjà
existant[18]. Pour faire un entraı̂nement poussé, il faudrait plus d’une centaine d’heures de donnée
acoustique. Nous avons pour 8Go de données acoustiques provenant de la base de donnés BREF
dont 7Go vont servir pour l’entraı̂nement de modèles acoustiques et 1Go pour les tester par la suite.
Les onze premiers dossiers seront utilisés pour l’entraı̂nement et les deux derniers pour tester les
modèles acoustiques.
Pour l’entraı̂nement, il faut installer SphinxTrain, qui se trouve sous
http://cmusphinx.sourceforge.net/html/download.php#SphinxTrain.
Pour créer l’environnement de travail et la copie de différents scripts perl, il faut lancer dans
un terminal:
cd SphinxTrain; perl scripts_pl/setup_tutorial.pl bref
Cela va construire l’environnement de travail, c’est-à-dire qu’un dossier bref sera créé et les
différents fichiers qui seront utilisés plus tard y seront copiés.
4.2.1
Préparations des données et fichiers nécessaires
Pour l’entraı̂nement il faut avoir une base de données d’entraı̂nement. Cette dernière est constituée
d’échantillon de signaux de paroles. De plus il faut par l’intermédiaire d’un fichier transcript lui
dire quel échantillon prendre. Dans ce fichier chaque ligne représente un fichier avec le chemin
vers ce dernier et sa transcription. Le ”trainer” prend ensuite le language dictionary, qui ”mappe”
chaque mots en une séquence de phonèmes. Finalement, nous avons besoin du ”filler dictionary”, ce
29 LIMSI:
Laboratoire d’Informatique pour la Mécanique et les Sciences de l’Ingénieur
est un programme de compression écrit par Tony Robinson, Cambridge University, http :
//f r.wikipedia.org/wiki/Shorten
30 SHORTEN
22
dernier contient les mots qui serviront a désigner le silence, la musique, des mots de remplacement
comme euh.. Les fichiers suivants sont nécessaires pour l’entraı̂nement:
• les exécutables de Sphinxtrain et si besoin Sphinx-3
• les échantillons de signaux acoustiques de la base de données BREF
• la liste des échantillons: bref train.fileids
• le fichier de transcription: bref train.transcription
• un ”filler dictionary”: bref.filler
• un ”language dictionary”: bref.dic
• un fichier de liste de phonèmes: bref.phone
Préparation du bref.phone Le script python PhonesCollector.py prend un dictionnaire comme
entrée et rend une liste de phonème, avec un phonème par ligne. Le script CharCollector.py permet
de collecter les différents caractères utilisés dans le dictionnaire. Ce fichier prend un dictionnaire
comme input et renvoie un fichier contenant un caractère par ligne. Ces scripts sont utilisés pour
créer la liste de phonèmes. Le symbole SIL pour le silence est ajouté à ce fichier. Voici le début
du fichier etc/bref.phone:
SIL
aa
ai
an
au
...
Préparation du fichier bref.dic La classe BatchModeRecognizer de Sphinx-4 accepte des
fichiers encodés en ASCII comme entrée. Il faut donc encoder les caractères accentués à la façon
ASCII-7 bit. La convention utilisée pour l’encodage s’inspire de BREF, en y ajoutant la puissance
2
et 3 .
• L’apostrophe ’ est remplacée par un tilde ˜
• Le é accent aigu par ’e
• Le é accent aigu majuscule pas ’E
• Le à accent grave par ‘a
• Le è accent grave par ‘e
• Le ù accent grave par ‘u
• Le ê accent circonflexe par ê
• Le ô accent circonflexe par ô
• Le â accent circonflexe par â
• Le ı̂ accent circonflexe par î
• Le û accent circonflexe par û
• Le ä tréma par :a
• Le ë tréma par :e
• Le ı̈ tréma par :i
23
• Le ö tréma par :o
• Le ü tréma par :u
• Le ç cédille par ,c
• Le ç cédille majuscule par ,C
• Le
2
par ˆ2
• Le
3
par ˆ3
Le dictionnaire de langage utilisé dans le projet s’inspire de celui fournit par le LIUM pour le
français. Le contenu du fichier etc/bref.dic:
...
abandonnez(4) aa bb an dd oo nn ei zz
abandonn’e aa bb an dd oo nn ei
abandonn’ee aa bb an dd oo nn ei
...
Préparation du fichier bref.filer Le fichier bref.filler doit avoir les symboles pour le silence et
d’autres symboles pour les hésitations: euh, rire, etc. Le contenu du fichier etc/bref.filler:
<s> SIL
<sil> SIL
</s> SIL
Préparation du fichier bref train.fileids Dans SphinxTrain, l’extraction des caractéristiques
se fait par l’utilisation d’un fichier (”bref train.fileids”) reprenant la liste des fichiers acoustiques se
trouvant dans le dossier wav. La création de cette liste se fait tout simplement par la commande:
cd wav; find . -name "*.s1" -print > ../etc/bref_train.fileids
qui donne néanmoins une liste de noms contenant des extensions à enlever avec un éditeur texte.
Le contenu du fichier etc/bref train.fileids:
i0mb0841
i0mb0842
i0mb0843
...
Préparation du fichier bref train.transcription Pour le fichier de transcription, il est nécessaire
de ”concatener” les différents fichiers de transcriptions qui se trouvent dans BREF. Cela se fait par
le script python TranscriptFileConcate.py. Cela va donner un fichier bref train.transcription.
Puis il faut lancer BrefToSphinxTrain.py pour avoir bref train.transcription. En résumé,
• les différents fichiers sont ”concatenés”
• les ponctuations sont enlevées
• le contenu des fichiers est mis en minuscule
• ensuite les <s> et </s> sont ajoutés avec le nom des fichiers audio entre parenthèse.
Le contenu du fichier etc/bref train.transcription (chaque transcription est sur une seule ligne)
<s> ces cr’edits seront faiblement utilis’es et les retomb’ees de la manne sur venise
seront modestes </s> (i0mb0841)
<s> seul le consortium venezia nuova aliment’e par ces fonds publics pousse ses gros
travaux qui doivent sauver venise </s> (i0mb0842)
...
24
Préparation des données acoustiques il faut installer deux outils pour l’extraction de caractéristique des fichiers acoustiques de Bref qui sont compressés. Ces outils sont:
w decode (de la distribution des outils Nist Sphere) est une application pour manipuler des
fichiers de parole31 . Puisque les données acoustiques de BREF sont compressées, il faut les
décompresser avec cet outil avec la commande:
nist/bin/w_decode monfichier.sph monfichier.decode.sph
Sox qui est une application pour convertir différents formats de fichiers audio en d’autres formats
audio32 . Un exemple d’utilisation de cette commande peut être:
sox monfichier.decode.sph monfichier.wav
Il faut préparer les données fournies par BREF, pour qu’il n’y ait pas de problème d’incompatibilité
de formats lors de l’entraı̂nement. En utilisant un script qui utilise w decode et sox, les fichiers
sont transformés en fichiers wav. Il faut ensuite faire l’extraction des caractéristiques en lançant
la commande make feats. Dans le code cette commande prend en entrée des fichiers wav, avec
extension *.wav. Pour corriger cela pour qu’il réponde à notre entraı̂nement, un petit changement
est nécessaire à la ligne 77:
system("bin/wave2feat -verbose yes -c \"$ctl\" -mswav yes " .
"-di wav -ei s1.wav -do \"$ST::CFG_FEATFILES_DIR\" " .
"-eo \"$ST::CFG_FEATFILE_EXTENSION\"");
Les fichiers d’entrée sont de type RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit,
mono 16000 Hz, avec l’extension s1.wav.
perl scripts_pl/make_feats.pl -ctl etc/bref_train.fileids
Cette dernière commande permet l’extraction de caractéristique dans le dossier feat.
4.3
Lancement de la vérification des fichiers d’entrée
Avant de pouvoir commencer l’entraı̂nement il faut être sûr que les fichiers nécessaires soient
valables et existent. Un script de vérification valide les fichiers de l’entraı̂nement. Un fichier peut
ne pas être valide pour 2 raisons: si dans le dictionnaire il existe des phonèmes non-existant dans le
fichier de phonèmes; ou un mot manquant dans le dictionnaire. Dans le premier cas, il faut ajouter
le phonème dans la liste de phonème. Dans le second il faut ajouter le mot et sa transcription dans
le dictionnaire de langage. Pour lancer la vérification, il faut exécuter
perl scripts_pl/00.verify/verify_all.pl
Cette dernière commande contrôle le nombre d’heures de données acoustiques, ainsi que la validité
des autres fichiers.
4.4
Lancement de l’entraı̂nement
Le fichier RunAll.pl permet le lancement de différents modules de SphinxTrain afin de réaliser
l’entraı̂nement des modèles acoustiques.
perl scripts_pl/RunAll.pl
Si l’un des modules échoue, le script s’arrête et une erreur est émise. Les différents modules sont:
• perl scripts pl/00.verify/verify all.pl
31 Nist
32 Sox,
Sphere, http://www.nist.gov/speech/tools/index.htm
http://sox.sourceforge.net/
25
– pour vérifier les fichiers d’entrée pour l’entraı̂nement
• perl ./scripts pl/01.vector quantize/slave.VQ.pl
– contrôle si les phonèmes utilisés dans le ”language dictionary” et le ”filler dictionary”
existent dans le fichier de liste de phonèmes.
– contrôle s’il n’y a pas de doublons dans le dictionnaire
– vérifie si les fichiers dans fileids existent et ont le bon format
– vérifie si le nombre de lignes dans le fichier de transcription est égal à celui du fichier
de contrôle (fileids)
– contrôle la quantité de donnée pour l’entraı̂nement
– vérifie que tous les mots dans le fichier de transcription existent dans le dictionnaire
– vérifie que tous les phonèmes dans le fichier de transcription sont dans le fichier de liste
de phonèmes, et que chaque entrée dans la liste est unique
• perl ./scripts pl/02.ci schmm/slave convg.pl
– entraı̂nement des modèles indépendants du contexte
– cela en initialisant (”flat initialization”) les modèles
– lancement de l’algorithme ”Baum welch”
• perl ./scripts pl/03.makeuntiedmdef/make untied mdef.pl
– entraı̂nement des modèles dépendants du contexte
– initialisation et lancement de l’entraı̂nement avec l’algorithme ”Baum welch”
• perl ./scripts pl/04.cd schmm untied/slave convg.pl
– construit les arbres
– traitement de chaque phonème pour chaque état
– prune l’arbre
– tie states
• perl ./scripts pl/05.buildtrees/slave.treebuilder.pl
– entraı̂nement de modèles dépendants du contexte en prenant les données du CI et
l’utilisation comme donnée initiale pour les CD
• perl ./scripts pl/06.prunetree/slave.state-tie-er.pl
• perl ./scripts pl/07.cd-schmm/slave convg.pl
Fichier de log: bref.html Un fichier bref.html est créé dans le répertoire, c’est un fichier
contenant différents messages et erreurs. Les mots en double et les mots qui n’existaient pas dans
le dictionnaire sont annoncés comme erreur.
Rejet de quelques transcriptions Après plusieurs jours de travail qui consistaient à ajouter
de nouveaux mots dans le dictionnaire, il apparut que le temps ne suffirait pas pour créer toutes
les phonétisations requises par les mots utilisés dans Bref (> 20! 000 mots). Pour cette raison, les
phrases contenant des mots inexistant dans le dictionnaires ont été enlevées. Cette tâche a été
effectuée en collectant les mots inconnus par le BatchModeRecognizer de Sphinx-4, cela par un
script simple qui créa le fichier AJOUTEMOIX contenant une liste de mots inconnus et en le donnant à
une classe java qui prenant le fichier de transcription en entrée faisait le tri, c’est-à-dire qu’il créait
un nouveau fichier de transcription, fichier de contrôle fileids contenant les noms des fichiers, et un
autre fichier contenant les mauvais fichiers acoustiques pour les enlever du répertoire. Cette classe
26
s’appelle Annihilate. Après le traitement des informations, et création des différents fichiers, il
restait environ pour 55.62 heures de donnée acoustique.
En relançant la commande qui se trouve dans la Section 4.3 pour faire la vérification et puis
en lançant la commande pour lancer l’entraı̂nement, cf. Section 4.4, il émargea quelques petits
problèmes.
• Des conflits se trouvaient dans le dictionnaire pour le caractère ”?”, qui exprimait des exposants pour des puissances par exemple.
• Des phonèmes qui étaient écrits en majuscule dans la liste de phonèmes et qui ne l’était pas
dans la transcription, cela donnait des erreurs.
• Le dictionnaire contenait des lignes vides à la fin ce qui a causé une erreur lorsque Sphinx
essayait de mettre les mots et leurs transcriptions (séquence de phonèmes) dans un hash
table.
• Les fichiers de sons devaient effectivement être décompressés avant l’entraı̂nement et le teste.
Après avoir corrigé ces problèmes (cf. le paragraphe spécifique dans la Section 4.2.1), l’entraı̂nement
a été effectué avec succès, c’est-à-dire que les différents modules composant le script RunAll.py se
sont déroulés sans générer d’erreurs fatales. Ce traitement a pris plus de dix heures de travail avec
un Macbook Intel Core Duo 2Ghz 2GoRam!
4.4.1
Fichiers de sortie
Plusieurs fichiers ont été produits à la fin de l’entraı̂nement33 :
model_parameters/bref.cd_cont_1000_8/means
ce fichier contient un tableau dans lequel chaque ligne représente un mean vector
model_parameters/bref.cd_cont_1000_8/mixture_weights
chaque ligne contient les poids pour une combinaison de gaussienne
model_parameters/bref.cd_cont_1000_8/transition_matrices
nos modèles acoustiques sont modélisés par des HMM’s. Un HMM’s est un ensemble d’état,
avec des probabilité d’état, et de transition, ce fichier contient la matrice des probabilités de
transition
model_parameters/bref.cd_cont_1000_8/variances
dans lequel chaque ligne représente un variance vector
model_architecture/bref.1000.mdef
c’est le fichier qui lie tout. Le fichier .mdef a une ligne pour chaque phonème qui identifie
d’une manière unique un HMM.
33 Selon
le javadoc de Sphinx 4.
27
5
Tests de performance
WER et Word Accuracy Le but des tests suivants est d’évaluer la qualité des modèles acoustiques en calculant le Word Error Rate (taux d’erreur par mot) ou Accuracy (taux d’exactitude
par mot).
Le ”Word Accuracy” (A) ou exactitude est égale à: A = hj ∗ 100%, avec j pour le nombre de
mots justes et h pour le nombre total de mots.
Le ”Word Error Rate” (W ER) se calcule en enlevant des erreurs de substitution ( la r’evision
de la ⇔ la vision de la), des erreurs d’insertion: (lui accordent ⇔ ne lui accordent que) et les
erreurs de suppression: (lui accordent que ⇔ lui accordent). La formule pour calculer le WER est:
W ER = 1 − h−s−i−d
∗ 100%, avec h pour le nombre total de mots, s pour le nombre d’erreurs de
h
substitution, i pour le nombre d’erreurs d’insertion et d pour le nombre d’erreurs de suppression.
BatchModeRecognizer La classe BatchModeRecognizer de Sphinx-4 permet de lancer des
tests de performance pour avoir des statistiques détaillées. Le lancement des tests se fait par
l’intermédiaire de Ant dans le répertoire de test contenant un fichier de target build.xml, un fichier
de configuration fichier.config.sphinx4.xml Sphinx-4 et un fichier batch batchfile.batch.
Le fichier batch pour les tests contient le chemin vers le fichier à reconnaı̂tre avec sa transcription
:
data/001u2.wav un dossier rouge
data/002u2.wav sur un seul essai
...
Ce dernier fichier batch contient une liste dont chaque ligne représente le chemin vers le fichier à
transcrire et sa transcription. Le fichier de configuration de Sphinx-4 spécifie les modèles acoustiques, modèle de language et dictionnaire devant être utilisés pendant la reconnaissance cf. la
Figure 12.
Figure 12: BatchModeRecognizer
Enregistrements audios Afin de calibrer les performances de nos modèles acoustiques entraı̂nés
sur Bref ainsi que les modèles du LIUM, nous avons enregistré une séquence de fichiers audio. Notre
objectif était d’avoir un set d’évaluation indépendant des conditions d’entraı̂nement des modèles
Bref et LIUM. Les enregistrements ont été effectués dans le laboratoire du groupe Diva occupé par
plusieurs personnes, donc non isolé, avec un Shure-SM94, et le mixer Behringer Eurorack MX1604A
pour amplifier le signal. L’application open source Audacity34 a été utilisé pour enregistrer et
34 Audacity
homepage: http://audacity.sourceforge.net/
28
découper les enregistrements, ce dernier est un logiciel open-source multi-plateformes. Ci-dessous
se trouvent les spécifications du format des fichiers audios enregistrés:
RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 16000 Hz.
Quatre personnes ont prêté leur voix pour enregistrer les phrases, Baris Ulucinar, Jean-Luc Bloechle,
Michel El-betjali et Tony Svenson. Pour une évaluation statistiquement significative, une base
de données contenant plus d’enregistrements ainsi que plus de voix différentes serait nécessaire.
Néanmoins, celle-ci nous permet d’obtenir quelques points de comparaison.
5.1
Tests de performance des modèles acoustiques du LIUM
Dans cette section, des tests de performance sont décrits en utilisant les modèles acoustiques
français de l’Université de Maine, Le Mans en France. Ces modèles ont été développés sur la base
de plusieurs corpus (campagne Ester): un corpus audio avec transcription d’environ 100 heures,
non-transcrit d’environ 2000 heures. Les 100 heures se composent comme suit: 85 heures pour
l’apprentissage, 8 heures pour le développement et enfin 10 heures pour les tests. Les corpus audio
ont été enregistrés depuis plusieurs chaı̂nes de radio. Le modèle de language a été créé à partir de
corpus de texte du journal Le Monde.35
5.1.1
Problèmes
Nous avons rencontrés certains problèmes en phase d’enregistrement, à cause de bruits environnementaux, de saturations du son, ainsi que certaines problèmes de prononciations d’articulation
correctes des mots. En lançant les tests qui ont pris un temps de traitement d’environ 1h30, il
apparut un Word Accuracy de seulement 43, 008% avec un WER de presque 66, 911%! Une analyse des erreurs a révélé un problème dû aux accents. En prenant contact avec les développeurs de
Sphinx et des modèles acoustiques en français, il est devenu clair que la classe utilisée pour les tests
de Sphinx-4 ne prenait en charge que des fichiers de dictionnaire et de transcriptions en ASCII 7
bits.
5.1.2
Solutions
lm convert Cet outil se trouve dans Sphinx-336 , et sera utilisé pour convertir le fichier de grammaire au format DMP ou l’inverse.37 La commande suivante
lm convert -input french3g62K.DMP -inputfmt DMP -output french3g62K.DMP.txt -outputfmt TXT
convertit le fichier binaire en un fichier texte. Avec l’aide d’un outil adéquat, découper le fichier,
à cause de sa taille. Par exemple dans un système de type Unix:
split -l 780000 french3g62K.DMP.txt
cette commande découpe le fichier en des fichiers de 780000 lignes, avec le préfixe commençant
par ”x”: xaa xab xac ... xcc. Maintenant, les changements de codage pour changer le fichier
latin-1 en Ascii 7-bits peuvent être effectuées. Alors la classe Java SubString qui se trouve dans
le package bigfilehandler peut être utilisé pour faire les changements adéquats. En utilisant le
même procédé que le dictionnaire. Après avoir lancé SubString et récupéré les fichiers encodés, il
faut les joindre avec la commande38 :
cat xaa xab xac xad xae > french3g62K.new.DMP.txt
puis les convertir en binaire avec la commande:
lm convert -input french3g62K.DMP.txt -inputfmt TXT -output french3g62K.DMP -outputfmt DMP
qui donne un fichier binaire se nommant french3g62K.DMP.
lm3g2dmp Malheureusement, il apparut par la suite le problème que l’outil lm convert créait
un fichier DMP corrompu, qui n’était pas accepté par Sphinx-4. Car cet outil atteint ses limites
35 Campagne
Ester: http://www.afcp-parole.org/ester/corpus.html
http://cmusphinx.sourceforge.net/html/download.php#sphinx3
37 DMP, format binaire, fichier dump
38 cat est une commande UNIX pour concatener des fichiers.
36 Sphinx-3:
29
lorsque le nombre de mots dépasse 216 . L’outil lm3g2dmp39 permet de convertir un fichier texte en
un fichier binaire (ou l’inverse):
lm3g2dmp french3g62K.DMP.txt outDir
cette commande permet de créer un fichier dump french3g62K.DMP.txt.DMP dans le dossier
outDir.
5.1.3
Résultats des tests
Après avoir fait le changement d’accent tant pour le modèle de langage que celui du dictionnaire,
il apparu que l’accuracy était de 67, 7% et le Word Error Rate de 37%, pour quelques 447 phrases
137 étaient reconnu à 100%. De plus, pour le nombre total de 3299 mots, 2233 étaient reconnus.
Ce qui est un bon résultat, la Figure 13 montre un capture d’écran plus détaillé des statistiques.
Figure 13: Résultats des tests des modèles acoustiques du LIUM
5.2
Tests de performance du modèle acoustique ”home made”
Un des objectifs de ce projet de master était d’entraı̂ner nos propres modèles acoustiques. Pour
contrôler la qualité de ces dernières, il faut les tester en utilisant le BatchModeRecognizer de
Sphinx-4, avec le ”language dictionnary” et les fichiers audios que ceux de la Section 5.1.
5.2.1
Comment utiliser des modèles produits par SphinxTrain dans Sphinx-4?
Cette section applique ce qui est expliqué à la page d’aide se trouvant à l’adresse
http://cmusphinx.sourceforge.net/sphinx4/doc/UsingSphinxTrainModels.html, cette page explique
l’intégration de modèles acoustiques produit par SphinxTrain (Sphinx-3) dans Sphinx-4.
Il existe deux manières d’intégrer les modèles acoustiques produits: la première Méthode A
est de les intégrer dans l’infrastructure de Sphinx-4, ce qui permet de créer un fichier jar, la seconde
Méthode B est d’utiliser les classes Model, ModelLoader et PropertiesDumper qui se trouve dans
le package edu.cmu.sphinx.model.acoustic.sphinx3 pour charger les modèles ”home made”.
Méthode A Pour pouvoir utiliser les modèles, il faut créer un fichier Java archive contenant les
fichiers de définition de modèles, et autres fichiers comme la variance, etc. La création de ce fichier
jar est effectuée par un target Ant qui se trouve dans le fichier build.xml de Sphinx-4.
Il faut en premier lieu créer un dossier bref dans le dossier sphinx4/models/acoustic, et y
copier les fichiers listés dans la Section 4.4.1.
Ensuite, le fichier model.props doit être créé sous sphinx4/models/acoustic/bref/. C’est le
fichier de configuration des modèles acoustiques, le taux de réussite de la reconnaissance dépend
fortement de ce fichier. Le contenu de ce fichier est ci-dessous, les valeurs des différents paramètres
doivent être les mêmes que lors de l’entraı̂nement des modèles.
description = Home Made French acoustic models created using the BREF database ...
modelClass = edu.cmu.sphinx.model.acoustic.BREF_cd_continuous_8gau.Model
modelLoader = edu.cmu.sphinx.model.acoustic.BREF_cd_continuous_8gau.ModelLoader
39 lm3g2dmp:
http://www.speech.cs.cmu.edu/sphinx/download/nightly/
30
dataLocation = model_parameters/bref.cd_cont_1000_8
modelDefinition = model_architecture/bref.1000.mdef
isBinary = true
featureType = 1s_c_d_dd
vectorLength = 39
sparseForm = false
numberFftPoints = 512
numberFilters = 40
gaussians = 8
minimumFrequency = 133.33334
maximumFrequency = 6855.4976
sampleRate = 16000
Puis, il va falloir ajouter notre propre target Ant dans le build.xml de Sphinx-4.
<property name="bref" value="BREF_cd_continuous_8gau"/>
<property name="bref_data_dir" value="models/acoustic/bref"/>
Ajouter l’appel suivant dans le target create all model classes pour créer les ”models classes”.
<antcall target="create_my_model_classes">
<param name="my_model_name" value="${bref_name}"/>
</antcall>
Et ajouter l’appel ci-dessous dans le target ant delete all model classes pour les effacer.
<antcall target="delete_my_model_classes">
</antcall>
Dans le target create all models, il faut ajouter pour créer les modèles.
<antcall target="create_my_model">
<param name="my_model_data_dir" value="${bref_data_dir}"/>
</antcall>
Il faut lancer ant dans le dossier de Sphinx-4 pour tout créer.
Méthode B Le fichier model.props ne contient plus les classes Model et ModelLoader de la
modèle acoustique mais directement celui de Sphinx-3.
description = Home Made French acoustic models created using the BREF database in DIVA, University
isBinary = true
featureType = 1s_c_d_dd
vectorLength = 39
sparseForm = false
numberFftPoints = 512
numberFilters = 40
gaussians = 8
minimumFrequency = 133.33334
maximumFrequency = 6855.4976
sampleRate = 16000.0
Ensuite, des changements seront nécessaire dans le fichier de configuration qui sera utilisé par
Sphinx-4:
...
<property name="properties_file" value="/pathto/model.props" />
<property name="data_location" value="/pathto/model_parameters/bref.cd_cont_1000_8" />
31
<property name="model_definition" value="/pathto/model_architecture/bref.1000.mdef" />
...

<component name="sphinx3Loader" type="edu.cmu.sphinx.model.acoustic.sphinx3.ModelLoader">
<property name="logMath" value="logMath"/>
<property name="unitManager" value="unitManager"/>
<property name="propertiesFile" value="${properties_file}" />
<property name="dataLocation"
value="${data_location}"/>
<property name="modelDefinition" value="${model_definition}" />
</component>
<component name="french" type="edu.cmu.sphinx.model.acoustic.sphinx3.Model">
<property name="loader" value="sphinx3Loader"/>
<property name="unitManager" value="unitManager"/>
</component>
...
Ayant fait ces quelques changements, les modèles acoustiques ”home made” sont utilisable par
Sphinx-4.
5.2.2
Résultats des tests
Le résultat des tests obtenu sur 447 fichiers audio, a donné un Word Accuracy de 77, 933% et un
Word Error Rate de 24, 795%, dont 161 phrases étaient reconnu à 100%. Le nombre total de mots
était de 3299 mots, dont 2571 bien reconnu. Ces taux sont très bons, la Figure 14 montre un
capture d’écran plus détaillé des statistiques.
Figure 14: Résultats des tests des modèles acoustiques ”home made”
5.3
Erreurs typiques
Les erreurs qui se trouvaient dans les deux tests, étaient le plus souvent des erreurs d’homophonie
ou de mots dérivés:
• il voulait ⇔ ils voulaient
• deux ⇔ de
• et ⇔ est
De plus des fichiers étaient très mal reconnus, à cause de la qualité d’enregistrement cela dans les
deux tests. Des erreurs d’insertions étaient aussi fréquentes, ainsi que des erreurs de substitution
pour des mots très semblable.
5.4
Comparaison des résultats des tests
Il faut comparer les modèles acoustiques qui ont été entraı̂nés dans Web WriteIt! pour savoir
connaı̂tre leur qualité, ou tout simplement savoir s’ils sont valables et peuvent être proposés aux
utilisateurs. La Table 3 ci-dessous montre quelques différences entre les tailles des deux modèles.
32
La Figure 15 montre les statistiques obtenues en lançant les tests de performance qui ont été vu
dans les Sections 5.2 et 5.1.
Table 3: Comparaison entre les deux modèles acoustiques
Modèle Acoustique
Lium French F0
Diva ”home made”
Nombre de tied-state triphones
5725
1108
Nombre de HMM’s
82134
99596
La différence entre les deux modèles est déjà en taille, celui du LIUM fait approximativement 38M, tandis le ”home made” fait 2.7M. Un autre point est le Word accuracy: il existe une
différence de 10%, cette marge peut être expliquée par la qualité des données acoustiques utilisées
pour l’entraı̂nement. La base de donnée BREF, contient des données enregistrées dans un studio
insonorisé, avec un bon microphone. Pour plus d’information sur cette base de donnée aller dans
la Section 4.1. Ce microphone est de même marque mais un plus vieux que celui utilisé lors de
l’enregistrement des 500 phrases, tandis que les données acoustiques du LIUM ont été enregistrées
depuis plusieurs chaı̂nes de radio française avec des qualités de micro différentes.
Figure 15: Résultats des tests
33
6
6.1
Interface côté client
Interface Web
L’interface Web, en plus d’intégrer Sphinx-4 doit permettre le choix entre différentes grammaires,
langue d’interaction et format de fichier de sortie. Il faudra veiller à la compatibilité entre le
différents navigateurs Internet en ne sous estimant pas l’ergonomie des différents pages afin de
permettre l’utilisation de l’application par un large public.
6.1.1
Diagramme d’activité
L’utilisateur arrive dans la page de bienvenue, où il peut choisir la langue d’interaction. Il est
alors redirigé vers la Servlet PrepareWaveUpload, qui avec l’aide de Velocity génère PrepareWaveUpload.html. Cette page est un formulaire qui prend le type de fichier de sortie (html cf. la Figure
16 ou xml cf. la Figure 17), la grammaire le choix du nbest. Il envoie ces informations au Servlet
ProcessWaveUpload. Ce dernier contrôle la validité du fichier audio, puis redirige le client vers la
page ProcessWaveRecognize.html. Cette page lance la reconnaissance par un appel au Serveur par
l’appel à la méthode Javascript:
getData(’ProcessWaveRecognize’,’reco’);
qui est appel get au Serveur du Servlet ProcessWaveRecognize, et dont le résultat obtenu
est affiché dans l’élément dont l’attribut ”id” est égale à reco. La Servlet ProcessWaveRecognize
génère avec l’aide de Velocity la page PrepareShowResults.html qui contient les résultats. Dans le
cas où l’utilisateur veut un fichier de sortie au format xml, le Servlet ProcessWaveUpload redirige
l’appel au Servlet ProcessWaveRecognizeToXML. Ce dernier va générer en utilisant le template
WwiReco.xml, une page xml qui sera renvoyée au client.
Figure 16: Diagramme d’activité: Web/Html pour un fichier de sortie au format html
34
Figure 17: Diagramme d’activité: Web/Xml pour un fichier de sortie au format xml
6.1.2
Interface utilisateur
L’utilisateur en arrivant dans la page d’accueil, cf. la Figure 18, choisit la langue en cliquant sur
”Go”, ou sur les drapeaux. Par défaut, la langue d’interaction est l’anglais. La personne est alors
redirigée vers la page, cf. la Figure 19, dans laquelle lui est proposé de choisir un fichier audio et
lancer sa reconnaissance. Ainsi une page présente le résultat de la reconnaissance comme le montre
la Figure 22.
6.1.3
Wiki Faq Glossaire
Le projet Web WriteIt! possède une page dans le Wiki du groupe de recherche DIVA. Cette page
devait permettre de mettre en ligne la description du projet en plus d’être une possible source
d’information pour d’autres personnes. Le Wiki se trouve dans la page du wiki de DIVA:
http://diuf.unifr.ch/diva/web/wiki
qui contient aussi des liens vers le Faq et le Glossaire. La page de Faq contient quelques questions
et réponses au sujet du projet et de son utilisation. Le Glossaire, est une liste de mots associés
à leurs définitions, qui sont centré sur le domaine du traitement de la parole. L’utilisation d’un
Wiki permet de faire la mise-à-jour des informations de manière facile, tout en laissant aux autres
membres du projet: l’assistant et le maı̂tre assistant la possibilité de pouvoir changer son contenu.
6.1.4
Ergonomie et accès rapide aux informations
Web WritetIt! possède une interface Internet pour interagir avec Sphinx 4 pour la reconnaissance de la parole. L’ergonomie doit permettre un utilisateur alpha d’utiliser le service sans gros
problème. Pour prendre cela en compte, plusieurs séances de tests ont été effectuées avec: Jean-Luc
Bloechle, Florian Evéquoz, Michel El-betjali, Dominik Zindel, Tony Svenson, Andreas Humm et
Bruno Dumas. Pendant ces tests, il est devenu clair que l’information présentée était trop élitiste
et confuse. De plus il fallait trop d’étapes d’interaction pour arriver aux résultats de la reconnaissance. Un autre problème était que lorsque l’utilisateur avait choisi le fichier puis avait lancé la
35
Figure 18: Entrée
reconnaissance: la page ne donnait pas d’indication que quelque chose se passait derrière. Plus
d’une fois, l’utilisateur avait rechargé la page, ou simplement relancé l’application, car n’avait pas
connaissance de la charge de calcul et du temps d’attente nécessaire.
Pour corriger ces problèmes, l’utilisation devait être plus simple et plus rapide de plus d’être
dirigé vers un plus vaste publique. En plus de rendre l’interface multilingue avec l’utilisation de
Velocity, il a fallu utiliser d’autre technologie et outils, comme Ajax, Mootools et Slimbox.
Technologie: Ajax est un acronyme de Asynchronous Javascript And XML. Ce dernier est
apparu la première fois dans un article publié par J. J. Garrett dans le page Internet AdaptativePath
[17]. Ajax, loin d’être une nouvelle technologie, est un ensemble de technologie et de technique
combinée déjà existant : Javascript, XML, Xhtml, Css, etc. De plus l’objet XMLHttpRequest crée
par Javascript permet d’envoyer et de recevoir des messages asynchrones au serveur. L’avantage
d’utiliser Ajax dans le projet Web WriteIt ! est de faciliter l’ergonomie d’utilisation et donner un
accès plus rapide et intelligent aux informations.
L’utilisation d’Ajax a permis de faire des appels asynchrones, cela lors de l’upload du fichier
audio dans le serveur et sa reconnaissance. Avant l’utilisateur devait attendre dans la même page
de formulaire, et ne savait pas que l’application travaillait. L’utilisation d’Ajax, et du framework Mootools40 , a permis dans un premier temps d’afficher une image informant l’utilisateur que
quelque chose se passe, pour ensuite y afficher l’information résultant du calcul.
Le seul inconvénient à l’utilisation de Javascript est le problème de son activation chez le
client. Mais puisque l’utilisation de Javascript est devenue standard, cela ne pose pas de problème.
Javascript est désactivé chez 4 à 13 % des utilisateurs, et cette tendance est à la baisse. Par
exemple, selon les statistiques de la page Internet http://www.ulucinar.tk récoltée en 2006,
seulement 1% des personnes avait désactivé Javascript [17].
Outils: Mootools est un framework javascript pour Ajax contenant différents effets d’animation
pour présenter l’information.
L’utilisation de ce framework a permis de créer les informations d’aide tels que ”tip”, lorsque
l’utilisateur passe au-dessus d’un élément. Le navigateur affiche l’information d’aide directement
sous forme de bulle d’aide. Ce genre de support d’information existait bien sûr avant, mais avec ce
framework le designer peut changer le style de l’aide, pour le rendre convivial et attirer l’attention
de l’utilisateur.
Il existe aussi une aide d’utilisation dans la page de formulaire même, lorsque l’utilisateur
clique sur le point d’interrogation qui se trouve en bas à droite, une image avec quelques lignes
40 Mootools
home page: http://mootools.net/
36
Figure 19: Formulaire
d’explications sont affichées. C’est l’outil Slimbox41 utilisant Mootools qui a été utilisé, pour
présenter d’une manière simple et ergonomique l’aide dans la même page.
La disposition des différents éléments du formulaire posait problème. Le bouton lançant la
reconnaissance n’était pas nommé de façon adéquate, de plus l’élément était trop près et collé au
bouton pour choisir le fichier audio, cela prêtaient confusion sur l’utilisation et le fonctionnement
de l’interface. Des corrections ont été effectuées pour changer leur emplacement et label. Des tests
effectués plus tard ont démontré que les utilisateurs étés satisfaits de l’interface.
6.2
Interface Java Swing
Selon Wikipedia, Java Swing (javax.swing.*) est une bibliothèque graphique. Elle donne la possibilité de créer des interfaces graphiques en utilisant le principe de Modèle-Vue-Contrôleur42.
6.2.1
Diagramme d’activité
Dans le cas d’une interface Java Swing cf. la Figure 23, il faut veiller à faire appel directement au
Servlet ProcessWaveUpload, qui va rediriger au Servlet ProcessWaveRecognizeToXML. Ce dernier
va générer en utilisant le template WwiReco.xml, une page xml qui sera renvoyée au client.
41 Slimbox
home page: http://www.digitalia.be/software/slimbox
http://fr.wikipedia.org/wiki/Accueil
42 Wikipedia:
37
Figure 20: Aide pour le formulaire: slimbox
6.2.2
Interface utilisateur
L’idée principale était de montrer qu’une autre technologie, comme une application Java Swing
pouvait utiliser notre application en effectuant une simple requête http au serveur. L’utilisateur
en lançant le Gui cf. la Figure 24, choisit le fichier audio, puis avec l’interface très simplifiée peut
choisir d’autres paramètres et lancer la reconnaissance, cf. la Figure 25. Après ces étapes, s’il n’y
a aucune erreur, un écran illustré à la Figure 26 est affichée. En fait, l’utilisateur reçoit le contenu
de la page WwiReco.xml, qui est affiché pour des raisons de lisibilité dans le textarea de l’interface
Java Swing.
38
Figure 21: Aide pour le formulaire: tips
Figure 22: Résultat de la reconnaissance
39
Figure 23: Diagramme d’activité: Java Swing/Xml
Figure 24: Entrée pour choisir le fichier audio, interface Java Swing
40
Figure 25: Formulaire pour lancer la reconnaissance, interface Java Swing
Figure 26: Résultat de la reconnaissance, interface Java Swing
41
7
Améliorations éventuelles
Nous entendons par ”tuning”, le fait de régler les différents paramètres d’un système de reconnaissance automatique de parole pour lui augmenter sa précision, son exactitude et sa vitesse. Il est
faux de penser que les paramètres que l’utilisateur a spécifié, dans les différents fichiers de configuration pour la reconnaissance automatique de la parole, soient universels. Ils ne peuvent pas être
utilisé pour différents systèmes qui n’auront pas le même besoin de précision et d’utilisation de
ressources matérieles. Un système aura besoin de beaucoup d’exactitude alors qu’un autre devrait
fonctionner rapidement avec un petit temps de calculs. Par exemple il existe une grande différence
entre un système qui doit reconnaı̂tre quelques commandes et un autre pour la transcription de
journaux télévisé. Ce tuning ne peut se faire qu’après de longs tests, essais et contrôle d’erreurs.
C’est pourquoi des améliorations éventuelles seraient dans un premier temps de modifier ces
paramètres pour arriver à un bon rapport exactitude / rapidité de calcul. Par exemple, durant
le décodage, le modèle acoustique et le modèle de langage sont utilisé, pour calculer un score. et
nous pourrions donner une valeur différente pour accentuer l’importance du modèle de langage.
Cette valeur est donnée au paramètre Language Weight et est choisie par essai et erreur : sa valeur
optimale étant entre 6 et 13. Le paramètre de Word Insertion Probability sert pour pénaliser
l’insertion de mots, sa valeur est entre 0.2 et 0.7 [5].
Dans un second temps, il serait préférable d’étudier plus en détails le ”design” du projet pour
permettre une plus grand rapidité de calcul. Par exemple, lors de l’utilisation de fichier de langages
de modèles volumineux, il serait mieux que ce fichier soit déjà chargé en mémoire, ce qui ferait
gagner en rapidité de calcul.
Il serait nécessaire de rendre le projet le plus dynamique possible, c’est-à-dire de laisser peut
être le droit à l’utilisateur de pouvoir ”uploader” sa propre grammaire. L’Annexe A.6 rentre plus
dans les détails et propose un début de solution. Dans ce cas pourquoi ne pas aussi ajouter un
autre formulaire qui permettrait de changer les paramètres de Sphinx-4 pour la reconnaissance.
Finalement, les deux derniers cd de Bref avaient été réservé au début du projet pour des tests
de performances. Il serait envisageable de faire ces tests de la même manière que dans la Section
5, cela pour les modèles acoustiques ”home made” et du LIUM French F0.
42
8
Conclusion
Les systèmes de reconnaissance automatique de la parole (RAP) deviennent chaque année de plus
en plus performants. Ces systèmes et technologies apparaissent dans la vie de tous les jours, dans
nos téléphones portables, utilisant parfois la biométrie pour l’identification par la voix, dans les
jeux tant ludiques qu’éducatifs pour apprendre de nouvelles langues, dans des applications pour
aider des personnes handicapées, dans les portails vocaux ou dans des services d’assistance aux
clients. Depuis quelques années, des outils open source de bonne qualité existent et permettent
de construire de bons systèmes de reconnaissance automatique de la parole, comme le projet
Sphinx-4, et le SphinxTrain et le Statistical Language Modeling Toolkit. Ces outils permettent la
construction d’application de système RAP complet, Sphinx-4 pour la reconnaissance automatique
de la parole, SphinxTrain pour créer des modèles acoustiques et le SLM Toolkit pour produire des
modèles de langage.
Le projet de Master Web WriteIt! a été proposé par le groupe DIVA du Département d’Informatique
de l’Université de Fribourg. Le but du projet est de proposer un accès simplifié aux possibilités de
reconnaissance de parole de l’outil open source Sphinx. L’interface proposée utilise des technologies Web dans une architecture client serveur. De façon plus détaillée, l’application tourne sur un
serveur Web Tomcat et permet la transcription d’un fichier audio qu’un utilisateur aura ’uploadé’
depuis une interface Internet ou depuis tout autre application. La reconnaissance de la parole
continue se fait avec l’aide de Sphinx-4 en utilisant des modèles acoustiques et des modèles de
langages disponibles open source en anglais et en français. Le projet visait également la création
de nos propres modèles acoustiques en français. Ces derniers ont été entraı̂nés en utilisant la
base de donnée Bref de laquelle 56 heures de parole ont été extraites. Des tests de performance
effectués, sur base de ces modèles, ont démontré que l’entraı̂nement avait convergé vers de bons
modèles acoustiques présentant des taux d’exactitude par mot de 78%. Ce qui correspond à des
performances supérieures aux modèles acoustiques open source utilisés dans la première phase de
projet.
Des modèles acoustiques ”home made” pour le français ont été produit avec l’aide de de SphinxTrain sur la base de 55, 62 heures de donnée acoustique provenant de la base de donnée BREF.
Ces modèles continus ont été intégré ensuite dans l’application.
Des tests de performance ont été effectué avec le BatchModeRecognizer de Sphinx-4 sur des 447
fichiers audio enregistrés dans le laboratoire du groupe DIVA et ont démontré que l’entraı̂nement
s’était bien passé. Les statistiques ont donné un Word Accuracy de 77, 9% et un Word Error Rate
de 24, 8%.
C’est un très bon résultat étant donné qu’une reconnaissance en parole continue donne, pour
les systèmes état-de-l’art, des performances similaires. Ceci montre que même des projets et outils
open source offrent la possibilité de créer de bons systèmes de reconnaissance. De plus, ceci tend
à montrer que la base de données BREF, bien que créée il y a quelques dizaines d’années reste
d’actualité.
43
References
[1] Anakia, website, http://velocity.apache.org/anakia/releases/anakia-1.0/.
[2] Bull voice portal: http : //www.bull.com/download/telco/bullvoiceportalf r.pdf , 2006.
[3] Guy Almouzni. Traitement de la parole: http : //www.eisti.f r/ ga/download/tipoly.pdf .
Web, 2007.
[4] C. Becchetti and L. P. Ricotti. Speech recognition. John Wiley and Sons, 1999.
[5] A. Chan, E. Gouvea, R. Singh, R. Mosur, R. Rosenfield, Y. Sun, and D. Huggins-Daines.
Hieroglpyhs: Building speech applications using sphinx and related resources. First Draft,
September 2004.
[6] P. Clarkson and R. Rosenfeld. Statistical language modeling using the cmu-cambridge toolkit.
[7] Computerworld. At & t voicetone, nationwide insurance. The computerworld honors program
case study, 2006.
[8] J.L. Gauvain and L. F. Lamel. Speaker-independent phone recognition using bref. DARPA
Speech and Language Workshop, Arden House, February 1992.
[9] M. Harti H. Satori and N. Chenfour. Système de Reconnaissance Automatique de l’arabe basé
sur CMUSphinx. 2007.
[10] Jean Hennebert.
Traitement de la parole:
06/traitparole/. Web, 2006.
http
:
//diuf.unif r.ch/courses/05 −
[11] P. Lamere, P. Kwok, W. Walker, E. gouvea, R. Singh, B. Raj, and P. Wolf. Design of the cmu
sphinx-4 decoder. 2003.
[12] J. P. Giangola M. H. Cohen and J. Balogh. Voice User Interface Design. Addison-Wesley,
2004.
[13] J. Mariani. Spoken language processing in the framework of human-machine communication
at limsi. Human Language Technology Conference, 1992.
[14] L. Rabiner and B.-H. Juang. Fundamentals of Speech Recognition. Prentice-Hall, 1993.
[15] K Seymore. Sphinx-3 tutorial series: Language modeling. 1998.
[16] I. Hyna T. Oetiker, H. Partl and E. Schlegl. The not so short introduction to latex 2e, 2006.
[17] B. Ulucinar. Ajax etat de l’art d’interface web riche open source. Technical report, Université
de Fribourg, 2006.
[18] Carnegie Mellon University. Sphinxman: http://www.speech.cs.cmu.edu/sphinxman/fr4.html.
[19] A. Wählby and C. Cassia. An oaa agent for sphinx-4. University of Gothenburg, Sweden,
2004.
[20] W. Walker, P. Lamere, P. Kwok, B. Raj, R. Singh, E. Gouvea, P. Wolf, and J. Woelfel.
Sphinx-4: A flexible open source framework for speech recognition. October 2004.
44
A
Annexe
A.1
Structure de l’application Web
Le dossier src contient les dossiers html et java. Le dossier html incluent les pages html, feuille de
style Css, images et template Velocity, les dossiers:
css dossier contenant le feuille de style
data dossier où les fichiers audio sont enregistrés, dans le fichier de police de Catalina, ”catalina.policy”
donnez les droits d’écriture.
images contient les images pour l’interface Internet
lib contient les librairies javascript utilisées
log dossier contenant les ”logs files”, dans le fichier de police de Catalina, ”catalina.policy” donnez
les droits d’écriture.
require contient les fichiers de configuration et de grammaire accessible par l’utilisateur
WEB-INF contient les classes compilées dans le dossier classes, les librairies utilisées dans lib et
un fichier web.xml, pour déclarer au Serveur les différents Servlets.
Pour donnez des droits dans le fichier de police de Tomcat, ajoutez les quelques lignes ci-dessous:
//for the application Web WriteIt! 2007 - DIVA - Baris
grant codeBase "file:/var/lib/tomcat5/webapps/diva-webwriteit/-" {
permission java.security.AllPermission "/var/lib/tomcat5/webapps/diva-webwriteit/WEB-INF/lib/-";
permission java.io.FilePermission "/var/lib/tomcat5/webapps/diva-webwriteit/log/-", "write";
permission java.io.FilePermission "/var/lib/tomcat5/webapps/diva-webwriteit/log", "write";
permission java.io.FilePermission "/var/lib/tomcat5/webapps/diva-webwriteit/data/-", "read, write, delete";
permission java.io.FilePermission "/var/lib/tomcat5/webapps/diva-webwriteit/data", "read, write";
};
// end Web WriteIt!
A.2
Comment ajouter une nouvelle grammaire dans le formulaire?
Cration des fichiers: Il faut pour cela créer tout d’abord un répertoire dans
src/java/diuf/diva/webwriteit/util/, le nom de ce répertoire représente la langue pour laquelle les
modèles acoustiques ont été entraı̂nés. Par exemple le dossier src/java/diuf/diva/webwriteit/util/fr,
qui nous dit que la langue est le français. Ce répertoire doit contenir deux dossiers :
• configfiles pour les fichiers de configuration Sphinx-4 : le répertoire homemade possède le
fichier de configuration spécifique : config.xml
• grammars pour les fichiers de modèles de langage.
Modification du formulaire: Il faut bien sûr ajouter quelques lignes dans le fichier
qui se trouve dans src/html:
PrepareWaveUpload.html
<tr>
<td nowrap="nowrap"><input type="radio" class="radio" name="grammar " value="fr!homemade" />
Home Made</td>
<td class="center">fr</td>
<td>HomeMade, multimedia quality, 
16kHz,
 more info</td>
<td>LargeTrigramModel, stochastic, 
more info </td>
<td class="center"><a href="require/homedata/config/config.xml.txt" target=" blank">config.xml</a></td>
45
</tr>
Le champ radio grammar du formulaire contient la valeur fr!homemade, ce qui veut dire que
Sphinx-4 doit charger le fichier de configuration config.xml se trouvant dans le dossier, package:
diuf.diva.webwriteit.util.fr.homemade. Le lien <a href="require/homedata/config/config.xml.txt"...
permet l’utilisateur de jeter un coup d’oeil au fichier de configuration.
Ajout des informations: L’élément font avec class css toolTipElement sert à donner des informations sur le taux d’échantillonnage, la grammaire et le modèle acoustique, ses informations
doivent être rentrées dans l’attribut title de l’élément.
Les quelques appels ci-dessous sont des appels Velocity, pour aller chercher les valeurs des
champs spéciféis dans la classe diuf.diva.webwriteit.web.servlet.LocaleLanguage.
• $localeLanguage.getSamplerate() pour l’information sur le taux d’échantillonage
• $localeLanguage.getHomeMademod() cherche l’information sur le modèle acoustique
• $localeLanguage.getFrenchgram() pour l’information sur le modèle de langage
Pour ajouter un nouveau champ, il faut tout d’abord l’ajouter dans la classe LocaleLanguage, puis
dans les autres classes : DeLocaleLanguage pour l’allemand, EnLocaleLanguage pour l’anglais et
FrLocaleLanguage pour le français.
A.3
Ajout d’une nouvelle langue d’interaction
S’il y a besoin d’ajouter une nouvelle langue d’interaction pour l’interface Internet, par exemple
pour le Romanche, il faut créer une classe RmLocaleLanguage qui devra tendre la classe LocaleLanguage. Ensuite faire les changements nécessaires dans la classe Language. Pour permettre le changement de la langue d’interaction, il faut ajouter un lien <a href="PrepareWaveUpload?lang=rm"><img
src="images/rm.gif" align="center" border="0" class="flag" alt="rm"></a>
• rm.gif pour le drapeau.
• ?lang=rm pour changer la langue d’interaction en Romanche.
A.4
Ajout d’une nouvelle langue de modles de langage, modles acoustiques
Web WriteIt! propose déjà des modèles acoustiques et de langages open source en anglais, et
en français. Pour ajouter une nouvelle langue, il est nécessaire de faire des changements dans la
méthode WebWriteItSession.setUserChoice(String userChoice). Pour que le système ait consience
de cette nouveauté.
A.5
Quelques restrictions au sujet de l’utilisation de l’application Web.
Un utilisateur peut utiliser le systme 15 fois, cette limite est définie dans la classe PrepareWaveUpload
avec le champ uploadLimit. La taille du fichier audio ne peut pas dépasser les 50MB, cette taille
est définie par le champ maxFileSize.
A.6
Idée pour rendre le système plus dynamique?
Il serait préférable dans la suite du projet de rendre le systme plus ”user friendly”, plus dynamique
et plus performant. Un champ de formulaire ”d’upload” ou simplement un ”textarea” permettrait
l’utilisateur de charger dans le système son propre grammaire. Il serait pensable d’avoir un slider
pour modifier les paramètres de la reconnaissance. Pour rendre cela possible, il sera indispensable
de faire les changements nécessaires dans la couche métier de l’application. En fait, il faudra
tenir compte que l’utilisateur peut envoyer à l’application diffrents types de grammaire: JSGF,
arpa lm, trigram, bigram, DMP. Il serait intelligent pour cela d’utiliser un fichier de configuration
46
générique, ayant du code Velocity pour permettre l’instanciation juste des composants, ou bien
oublier le fichier de configuration et créer une classe réservée qui instantiera selon les besoins, les
diffrents composants. Ceci ne sera possible qu’après avoir étudiés les différents ”design pattern”.
Car malheureusement pour l’instant, chaque ”grammaire” du formulaire possède son propre fichier
de configuration. L’idée d’implmentation un peu plus détaillée serait l’utilisation de la méthode
”edu.cmu.sphinx.util.props.ConfigurationManager.setProperty(composant, proprit, valeur)” pour
changer les propriétés du fichier de configuration Sphinx. Un mini exemple se trouve dans le
package ”bigfilehandler”: MakeChange.java et TestClass.java.
47
# DIVA Web Writeit! University of Fribourg
# baris ulucinar, jean hennebert, andreas humm 2007
# file webwriteit/doc/6.ServerDoc/README
# Web
http://diuflx77-vm04.unifr.ch:8080/diva-webwriteit/index.html
# Connection to the Virtual Machine
ssh diuflx77-vm04.unifr.ch -l ulucinar
the password is tom4dwiwvia07
# Close the connection
exit
# How to be root (needed to go to logs or conf directory)
sudo su
the password is tom4dwiwvia07
# How to change password
$ /usr/bin/passwd
give the old password
give 2x the new password
# Tomcat directory
/var/lib/tomcat5
drwxr-x--- 3 tomcat5
lrwxrwxrwx 1 root
drwxr-xr-x 4 root
drwxr-xr-x 2 tomcat5
drwxr-xr-x 10 tomcat5
lrwxrwxrwx 1 root
adm
root
root
root
root
root
4096
17
4096
4096
4096
19
2007-05-11
2007-05-09
2007-05-09
2007-05-11
2007-05-09
2007-05-09
13:23
12:06
12:06
13:23
17:16
12:06
conf (policy directory)
logs -> ../../log/tomcat5 (log directory)
shared
temp
webapps (where to put Web WriteIt!)
work -> ../../cache/tomcat5
# catalina.policy
the file only for our Web application is
/etc/tomcat5/policy.d/98_diuf.policy
//for the application Web WriteIt! 2007 - DIVA - Baris
grant codeBase "file:/var/lib/tomcat5/webapps/diva-webwriteit/-" {
permission java.io.FilePermission "/var/lib/tomcat5/webapps/diva-webwriteit/WEB-INF/classes/diuf/diva/web\\
writeit/util/-";
permission java.security.AllPermission "/var/lib/tomcat5/webapps/diva-webwriteit/WEB-INF/lib/-";
permission java.io.FilePermission "/var/lib/tomcat5/webapps/diva-webwriteit/log/-", "write";
permission java.io.FilePermission "/var/lib/tomcat5/webapps/diva-webwriteit/log", "write";
permission java.io.FilePermission "/var/lib/tomcat5/webapps/diva-webwriteit/data/-", "read, write, delete";
permission java.io.FilePermission "/var/lib/tomcat5/webapps/diva-webwriteit/data", "read, write";
};
// end Web WriteIt!
# Java VM parameters
the file is
/etc/init.d/tomcat5
CATALINA_OPTS="-Djava.awt.headless=true -Xmx1024M -Xms256M"
# start | restart | stop the server
(the server starts automatically with the machine)
sudo /etc/init.d/tomcat5 start
sudo /etc/init.d/tomcat5 restart
sudo /etc/init.d/tomcat5 stop
(possible parameters: forcereload reload
restart
48
start
status
stop)

master thesis report - DIUF

Transcription

Documents pareils

1 La société GIR 2 La solution proposée

Fiche système dàssainissement 2014 CREON DÀRMAGNAC

Fiche système dàssainissement 2014 CREON DÀRMAGNAC

Isolation acoustique intégrée pour Pergo Uniq et Pergo Practiq

Fiche syst`eme d`assainissement 2014 CREON Réseau de type Mixte

Fiche syst`eme d`assainissement 2014 CREON (Hameau de Baudin

Anti-forensic - Actes du SSTIC

Travaux Dirigés - Fautes Byzantines Master II ISRI - 2015-16

Sommaire Juin 2016 - Global Retail News

VoIP interconnect Form