• Aucun résultat trouvé

Reconnaissance automatique du locuteur embarquée dans un téléphone portable

N/A
N/A
Protected

Academic year: 2021

Partager "Reconnaissance automatique du locuteur embarquée dans un téléphone portable"

Copied!
5
0
0

Texte intégral

(1)

HAL Id: hal-01317705

https://hal.archives-ouvertes.fr/hal-01317705

Submitted on 19 Nov 2018

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Reconnaissance automatique du locuteur embarquée dans un téléphone portable

Anthony Larcher, Christophe Lévy, Driss Matrouf, Jean-François Bonastre

To cite this version:

Anthony Larcher, Christophe Lévy, Driss Matrouf, Jean-François Bonastre. Reconnaissance automa-

tique du locuteur embarquée dans un téléphone portable. JEP, May 2010, Mons, Belgique. �hal-

01317705�

(2)

Reconnaissance automatique du locuteur embarqu´ ee dans un t´ el´ ephone portable

Anthony Larcher, Christophe L´ evy, Driss Matrouf, Jean-Fran¸ cois Bonastre

Universit´ e d’Avignon et des Pays de Vaucluse, Laboratoire Informatique d’Avignon (UPRES 931),

F-84018 Avignon, France

{anthony.larcher, christophe.levy, driss.matrouf, jean-francois.bonastre}@univ-avignon.fr

ABSTRACT

Embedded speaker recognition in mobile devices in- volves a limited amount of computing resources. Ho- wever, the performance of state-of-the-art systems are usually evaluated without any limitation of material resources. In this paper, we evaluate several downsca- led configurations of the LIA UBM/GMM speaker ve- rification system. The impact of scalability is evalua- ted in terms of memory resources and computational time. We propose two downscale configurations which allow a good compromise between resource consump- tion and performance degradation. Experiments per- formed on the Banca database show that the me- mory allocation and the computational time decrease of about 70% and 88% when the error rate raises from 3, 48% to 4, 77% or still comparable to the baseline.

Keywords: speaker recognition, scalability, embed- ded systems

1. Introduction

Au regard des derni` eres campagnes d’´ evaluation in- ternationales organis´ ees par le NIST [7], la Recon- naissance Automatique du Locuteur (RAL) a r´ ealis´ e de r´ eels progr` es ces derni` eres ann´ ees. Ces derniers sont dus ` a l’introduction de nouvelles m´ ethodes telles que le Factor Analysis ([5], [6]) ou la Nuisance Attribut Projection ([8]) qui ont notamment permis de com- penser les d´ egradations induites par l’usage de diff´ e- rents microphones et/ou de diff´ erentes liaisons t´ el´ e- phoniques, ou encore de limiter l’influence de la va- riabilit´ e due ` a l’environnement acoustique dans lequel est utilis´ e le syst` eme. Ces avanc´ ees, ainsi que la matu- rit´ e atteinte par les syst` emes actuels, rendent envisa- geable le d´ eveloppement d’applications grand-public s´ ecuris´ ees par la biom´ etrie vocale.

La multiplication des syst` emes embarqu´ es, observ´ ee ces derni` eres ann´ ees (t´ el´ ephones portable, GPS, PDA, . . .), a ouvert de nouveaux march´ es. Cependant, le d´ e- veloppement du mat´ eriel et des r´ eseaux s’est accom- pagn´ e d’une croissance ´ equivalente du nombre d’ap- plications disponibles sur ces terminaux. Aussi, les contraintes mat´ erielles induites par ces clients l´ egers constituent une probl´ ematique majeure pour l’int´ e- gration des technologies de reconnaissance du locu- teur.

Cet article propose une ´ etude des performances d’un syst` eme ´ etat-de-l’art dans un contexte de ressources mat´ erielles limit´ ees. Nous consid´ erons l’influence des principaux param` etres scalables qui peuvent ˆ etre mo- difi´ es afin de satisfaire aux ressources restreintes d’un

syst` eme embarqu´ e. Diff´ erentes configurations du sys- t` eme UBM/GMM d´ evelopp´ e ` a partir de la plateforme Mistral (´ evalu´ e lors des principales ´ evaluations inter- nationales de v´ erification du locuteur [2]) sont com- par´ ees en fonction de leurs performances, mais ´ ega- lement en fonction des ressources qu’elles n´ ecessitent tant en termes de temps CPU que d’occupation m´ e- moire.

Dans un premier temps, nous donnons un exemple de la capacit´ e des t´ el´ ephones portables actuels. En- suite, le syst` eme de reconnaissance d´ evelopp´ e ` a par- tir de la plateforme biom´ etrique MISTRAL

1

[3] est pr´ esent´ e dans la section 3. La partie 4 contient les d´ etails concernant le protocole exp´ erimental utilis´ e.

Les param` etres scalables du syst` eme ainsi que les per- formances obtenues sont comment´ es dans la partie 5. De cette analyse, deux configurations particuli` eres du syst` eme de v´ erification du locuteur ont ´ et´ e s´ elec- tionn´ ees : une solution n´ ecessitant le moins de res- sources possibles mais qui a des performances non op- timales et une configuration repr´ esentant le meilleur compromis. Enfin, la derni` ere partie pr´ esente quelques conclusions issues de ce travail.

2. Exemple de ressources

Cette ´ etude se situe dans le contexte du projet euro- p´ een MOBIO

2

au cours duquel un syst` eme de v´ erifi- cation du locuteur doit ˆ etre impl´ ement´ e sur un t´ el´ e- phone portable. Le portable choisi pour cette int´ egra- tion est le Nokia c N900.

vendor id ARM model name Cortex-A8

CPU MHz 600

RAM 256 MB

CPU cores 2

Tab. 1: Caract´ eristiques du t´ el´ ephone Nokia c N900 sur lequel doit ˆ etre int´ egr´ e le syst` eme de v´ erification du locuteur dans le projet europ´ een MOBIO.

Les ressources pr´ esent´ ees dans le tableau 1 corres- pondent ` a celles disponibles pour l’ensemble des ap- plications actives sur le t´ el´ ephone ` a un instant donn´ e et non pas aux ressources disponibles pour la seule application de v´ erification du locuteur.

3. Description du syst` eme

Les diff´ erentes configurations du syst` eme UBM/GMM pr´ esent´ ees par la suite sont bas´ ees

1http://mistral.univ-avignon.fr/

2http://www.mobioproject.org/

(3)

sur le syst` eme d´ evelopp´ e au sein du Laboratoire Informatique d’Avignon (LIA) ` a partir de la plate- forme biom´ etrique MISTRAL [3]. Les performances de ce syst` eme, ´ evalu´ ees lors des derni` eres campagnes internationales de v´ erification du locuteur NIST-SRE [2], le placent au niveau des syst` emes ´ etat-de-l’art.

Ce syst` eme est bas´ e sur le paradigme UBM/GMM associ´ e au Latent Factor Analysis [6] ; ce qui per- met de prendre en compte la variabilit´ e session intra- locuteur. Les param` etres acoustiques utilis´ es sont is- sus d’une analyse cepstrale en banc de filtres (obtenus avec SPRO [4]). Les vecteurs de param` etres utilis´ es sont compos´ es des 19 coefficients statiques (c), des 19 coefficients d´ eriv´ es du premier ordre (∆c), de 11 coef- ficients d´ eriv´ es du second ordre ainsi que du coefficient d´ eriv´ e (du premier ordre) de l’´ energie (∆E). Une s´ e- lection des trames de plus haute ´ energie est appliqu´ ee de fa¸ con standard (pour s´ eparer les trames parole des trames non-parole) avant d’appliquer une normalisa- tion (soustraction de la moyenne et normalisation de la variance) au niveau de chaque fichier.

Le mod` ele du monde (UBM) comprend 512 distri- butions Gaussiennes et la matrice de covariance est suppos´ ee diagonale. Chaque mod` ele de locuteur est d´ eriv´ e de l’UBM par une adaptation bas´ ee sur le cri- t` ere du Maximum A Posteriori (MAP). Il faut enfin noter qu’en raison du contexte (RAL embarqu´ ee), le choix a ´ et´ e fait de ne pas normaliser les scores. En ef- fet, les normalisations classiques, type ZTNorm, sont consommatrices de temps CPU et d’espace m´ emoire.

4. Protocole exp´ erimental

Les diff´ erentes configurations pr´ esent´ ees dans ce pa- pier ont ´ et´ e ´ evalu´ ees sur la base de donn´ ees Banca [1].

Cette base comprend les enregistrements vid´ eo de 52 personnes r´ eparties en deux sous-groupes G1 et G2 contenant chacun 13 hommes et 13 femmes.

Chaque locuteur pr´ esent dans la base BANCA a par- ticip´ e ` a 12 sessions d’enregistrement dans diff´ erentes conditions avec diff´ erentes cam´ eras. Les quatre pre- mi` eres sessions sont enregistr´ ees avec une luminosit´ e et un environnement sonore contrˆ ol´ es. Les sessions 5 ` a 8 et 9 ` a 12 correspondent respectivement ` a des condi- tions « d´ egrad´ ees » et « adverses » . Ces diff´ erentes conditions d’enregistrement permettent d’obtenir une plus grande variabilit´ e au niveau de l’arri` ere plan so- nore.

Cette ´ etude, pr´ ealable ` a l’impl´ ementation du syst` eme de reconnaissance du locuteur au sein du t´ el´ ephone portable, a ´ et´ e r´ ealis´ ee sur un ordinateur et non sur le t´ el´ ephone

3

. Son but n’est pas seulement d’´ evaluer les taux d’erreurs du syst` eme de RAL, mais bien de les rapprocher de l’occupation m´ emoire et du temps de calcul consomm´ es. Les caract´ eristiques du PC utilis´ e sont pr´ esent´ ees dans le tableau 2.

Le temps de calcul ´ evalu´ e avec la commande syst` eme time a permis de d´ eduire le temps CPU n´ ecessaire ` a l’ex´ ecution du processus (le chargement des diff´ erents

3Le Nokia cN900 n’est pas encore sur le march´e `a l’heure actuelle, mais de premiers essais ont pu ˆetre r´ealis´es par l’int´e- grateur partenaire du projet.

vendor id GenuineIntel

model name Intel(R) Core(TM)2 Quad CPU Q9300

CPU MHz 2000

cache size 3072 KB

CPU cores 4 (1 seul est utilis´ e)

bogomips 4987.44

Tab. 2: Caract´ eristiques du PC sur lequel ont ´ et´ e effectu´ es les tests pr´ esent´ es dans cet article.

mod` eles et des donn´ ees est inclus dans le temps me- sur´ e). La quantit´ e de m´ emoire n´ ecessaire a ´ et´ e estim´ ee en utilisant le profileur Valgrind qui permet de mesu- rer le pic de m´ emoire allou´ ee. Dans le cadre d’une impl´ ementation sur syst` eme embarqu´ e, la notion de maximum de m´ emoire allou´ ee ` a un instant t est plus importante que la taille totale allou´ ee. Enfin, l’estima- tion des ressources n´ ecessaires a ´ et´ e r´ ealis´ ee ` a partir d’un sous-ensemble repr´ esentatif des tests de la base de donn´ ees BANCA (les taux d’erreurs, eux, sont don- n´ es pour l’ensemble du corpus).

5. Param` etres scalables

Cette partie pr´ esente l’influence de trois param` etres scalables sur les performances du syst` eme :

• le nombre de distributions Gaussiennes des GMM ;

• la taille des vecteurs acoustiques ;

• la proportion d’´ echantillons trait´ es en phase de test.

Ces trois param` etres, choisis car ils impactent forte- ment les besoins du syst` eme en termes de m´ emoire et de temps de calcul, influent sur deux facteurs direc- tement li´ es aux ressources utilis´ ees :

• le nombre de param` etres ` a stocker pour chaque mo- d` ele, exprim´ e par :

nb

param

= nb

gauss

× (2 × tailleV ectAc + 1) (1) o` u nb

param

correspond au nombre de param` etres ` a stocker pour chaque mod` ele GMM (UBM + locu- teurs), nb

gauss

est le nombre de composantes Gaus- siennes du mod` ele et tailleV ectAc est la taille des vecteurs de param` etres utilis´ es ;

• le nombre de fonctions de log-vraisemblance (qui constituent l’essentiel du coˆ ut de calcul), donn´ e par :

nb

log−vrais

= 2 × nb

gauss

× tailleV ectAc ×nb

trames

(2) o` u nb

log−vrais

est le nombre de fonctions de log- vraisemblance ` a calculer et nb

trames

correspond au nombre de trames trait´ ees de la s´ equence de test.

5.1. Nombre de composantes du mod` ele du monde

Au regard des ´ equations 1 et 2, le nombre de compo- santes Gaussiennes du mod` ele du monde d´ etermine de fa¸ con explicite la m´ emoire n´ ecessaire au stockage des mod` eles de locuteurs. Le tableau 3 pr´ esente les r´ e- sultats obtenus pour des mod` eles comprenant de 512

`

a 32 distributions Gaussiennes.

La r´ eduction du nombre de distributions des mod` eles

entraˆıne une augmentation du taux d’´ egales erreurs

(EER) mais permet de r´ eduire significativement le

temps de calcul et la m´ emoire n´ ecessaire. L’utilisation

de mod` eles ` a 128 Gaussiennes permet par exemple,

de conserver des performances comparables ` a celles

(4)

du syst` eme de r´ ef´ erence, tout en divisant par 3 la m´ emoire allou´ ee par le syst` eme et par 4 le temps de calcul. Le syst` eme avec 32 Gaussiennes permet, lui, de r´ eduire le temps de calcul par un facteur 14 et les allocations m´ emoire par 5 tout en conservant un taux d’erreurs compris entre 4% et 5%.

# distributions 512 256 128 64 32 G1 (EER %) 3,48 2,19 3,86 4,23 5,15 G2 (EER %) 2,94 3,32 3,32 2,19 3,85 mem. (MB) 7,84 4,29 2,70 1,90 1,50

mem. rel. (%) 100 57 36 25 20

temps CPU (s) 2,06 1,07 0,53 0,27 0,15

temps rel. (%) 100 52 25 13 7

Tab. 3: Evolution des performances (EER) et des res- ´ sources (temps CPU et m´ emoire) utilis´ ees en fonction du nombre de composantes du mod` ele. La consomma- tion des ressources est donn´ ee de mani` ere relative par rapport au syst` eme de base.

5.2. Taille du vecteur acoustique

La dimension des vecteurs acoustiques utilis´ es est en lien direct avec l’espace m´ emoire et le temps de calcul n´ ecessaires puisqu’elle apparaˆıt dans les ´ equations 1 et 2. Diff´ erentes dimensions de vecteurs acoustiques ont

´

et´ e test´ ees. Ces configurations diff` erent ´ egalement par la nature des coefficients utilis´ es (c, ∆c, ∆∆c ou ∆E).

Consid´ erant le nombre tr` es important des combinai- sons possibles, nous avons choisi de ne retenir que quatre configurations (en plus de celle de r´ ef´ erence), d´ etaill´ ees dans le tableau 4. Ce tableau pr´ esente les performances du syst` eme de v´ erification du locuteur utilisant ces diff´ erentes param´ etrisations compar´ ees au syst` eme de r´ ef´ erence.

# param` etres 50 41 30 25 20

# c 19 15 10 15 10

# ∆c 19 15 10 10 10

# ∆∆c 11 11 10

# ∆E 1

G1 (EER %) 3,48 4,77 3,48 5,52 5,15 G2 (EER %) 2,94 3,85 4,23 3,85 4,23 mem. (MB) 7,84 6,60 5,48 4,99 4,46

mem. rel. (%) 100 88 73 67 60

temps CPU (s) 2,06 1,92 1,80 1,79 1,71 temps rel. (%) 100 95 87 86 83 Tab. 4: Evolution des performances (EER) et des ´ ressources (temps CPU et m´ emoire) utilis´ ees en fonc- tion de la taille du vecteur acoustique (512 distribu- tions par GMM). La consommation des ressources est donn´ ee de mani` ere relative par rapport au syst` eme de base.

La r´ eduction de la dimension des vecteurs acoustiques r´ eduit de mani` ere significative l’espace m´ emoire uti- lis´ e ainsi que le temps de calcul n´ ecessaire ` a la v´ e- rification du locuteur. ` A nombre de param` etres ´ equi- valent, il semble que la suppression des coefficients dy- namiques ∆∆c entraˆıne une d´ egradation importante du taux d’´ egales erreurs ; en effet le taux d’erreurs moyen (sur G1 et G2) passe de 3,85% pour le sys- t` eme 30 coefficients (10c + 10∆c + 10∆∆c) ` a 4,65%

pour le syst` eme 25 coefficients (15c+10∆c), ce qui re- pr´ esente une augmentation relative du taux d’erreurs de plus de 20%.

5.3. S´ election de trames

Les param` etres acoustiques fournis au syst` eme de re- connaissance du locuteur sont extraits de fa¸ con clas- sique ` a la fr´ equence d’une trame toutes les 10ms. Dans cette sous-partie, la r´ eduction est op´ er´ ee sur la pro- portion de vecteurs acoustiques qui sont trait´ es par le syst` eme pour le calcul de la vraisemblance. Il est important de noter que mˆ eme si tous les vecteurs ne sont pas utilis´ es pour calculer le score du test, tous ces vecteurs doivent ˆ etre extraits. En effet, un sous-

´ echantillonnage r´ ealis´ e durant la phase d’extraction des param` etres ne permettrait plus de calculer les pa- ram` etres dynamiques (∆c et ∆∆c).

% de trames trait´ ees 100 50 25

G1 (EER %) 3,48 3,86 4,23

G2 (EER %) 2,94 3,48 4,60

mem. (MB) 7,84 7,84 7,84

mem. rel. (%) 100 100 100

temps CPU (s) 2,06 1,20 0,68

temps rel. (%) 100 58 33

Tab. 5: Evolution des performances (EER) en fonc- ´ tion du nombre de trames utilis´ ees pour la calcul de la vraisemblance du mod` ele de locuteur. La consom- mation des ressources (temps CPU et m´ emoire) est donn´ ee de mani` ere relative par rapport au syst` eme de base.

Les r´ esultats pr´ esent´ es dans le tableau 5 sont obtenus en ne traitant qu’une trame sur deux ou une trame sur quatre. Le traitement d’une trame sur n permet de r´ eduire le temps de calcul de fa¸ con consid´ erable.

Cependant, les performances du syst` eme sont forte- ment d´ egrad´ ees si le ratio entre les trames re¸ cues et les trames trait´ ees atteint 0,25. Dans ce cas, le taux d’erreurs moyen sur G1 et G2 passe de 3,21% (avec 100% des trames trait´ ees) ` a 4,41% (avec un quart des trames trait´ ees) soit une augmentation relative de pr` es de 40%.

Toutefois, la s´ election ici op´ er´ ee consiste en un sous-

´ echantillonnage r´ egulier et pourrait sans doute ˆ etre am´ elior´ ee par l’utilisation de crit` eres de s´ election plus pertinents. Une s´ election p´ eriodique pr´ esente, n´ ean- moins, l’avantage de ne n´ ecessiter aucune analyse des vecteurs de param` etres ` a traiter.

5.4. Conclusion

Dans les trois sous-parties pr´ ec´ edentes, nous avons

´ etudi´ e l’influence qu’avait, ind´ ependamment les uns des autres, trois param` etres : le nombre de compo- santes des mod` eles GMM, la taille du vecteur acous- tique et le nombre de trames acoustiques trait´ ees.

Deux configurations, correspondant ` a 2 situations dis- tinctes, sont d´ etaill´ ees ci-apr` es :

syst` eme minimal cette solution correspond ` a celle qui n´ ecessiterait le moins de ressources ;

meilleur compromis cette configuration est celle qui repr´ esente le meilleur compromis entre les ressources mat´ erielles et les performances.

Les performances relatives ` a chaque configuration

sont pr´ esent´ ees dans le tableau 6.

(5)

% Syst` emes ref. minimal compromis

G1 (EER %) 3,48 7,72 4,77

G2 (EER %) 2,94 7,34 2,94

mem. (MB) 7,84 1,37 2,19

mem. rel. (%) 100 17 28

temps CPU (s) 2,06 0,04 0,24

temps rel. (%) 100 1,7 11,7

Tab. 6: Comparaison des performances obtenues par le syst` eme LIA de r´ ef´ erence, sa configuration mini- male et le meilleur compromis. La consommation des ressources (temps CPU et m´ emoire) est donn´ ee de mani` ere relative par rapport au syst` eme de base.

Syst` eme minimal Le syst` eme minimal correspond

`

a celui pour lequel les valeurs minimales de chaque param` etre ont ´ et´ e choisies, i.e. les mod` eles GMM comprennent 32 gaussiennes, les vecteurs acoustiques contiennent 20 coefficients (20c et 20∆c) et la vrai- semblance est estim´ ee en utilisant une trame sur quatre. Dans cette configuration, le syst` eme a des performances nettement en de¸ c` a du syst` eme de r´ ef´ e- rence. Nous pouvons noter une augmentation relative du taux d’erreurs moyen de 130% ; cependant le taux d’erreurs reste proche de 7% ce qui en fonction de l’ap- plication finale choisie peut s’av´ erer suffisant. Dans le mˆ eme temps, cette solution n´ ecessite beaucoup moins de ressources. En effet, le temps CPU est divis´ e par 60 et le pic m´ emoire passe de 7,84Mo ` a 1,37Mo soit une baisse relative de 83%.

Meilleur compromis Pour le projet MoBio, l’in- t´ egration est pr´ evue dans le t´ el´ ephone Nokia c N900, pour lequel les ressources disponibles sont sup´ erieures

`

a celles requises par le syst` eme minimal. Un compro- mis entre les 3 param` etres a donc ´ et´ e choisi afin d’ob- tenir un syst` eme ayant de meilleures performances que le syst` eme minimal tout en n´ ecessitant moins de ressources. Dans cette configuration, les mod` eles GMM contiennent 128 composantes Gaussiennes, les vecteurs acoustiques sont compos´ es de 30 coefficients (10 statiques, 10 dynamiques de premier ordre et 10 dynamiques de second ordre) et la vraisemblance est estim´ ee en utilisant une trame sur deux. Ce syst` eme obtient des performances satisfaisantes. En effet, le taux d’erreurs moyen passe de 3,21% ` a 3,84%, soit une hausse relative de 20% alors que dans le mˆ eme temps les ressources requises sont nettement diminu´ ees : le temps CPU est divis´ e par 10 et le pic m´ emoire est divis´ e par 4.

6. Conclusion et perspectives

Au cours de ces derni` eres ann´ ees, les syst` emes de re- connaissance automatique du locuteur ont fait des progr` es significatifs, ` a tel point que des applica- tions grand-public deviennent envisageables. Ces ap- plications soul` event, dans le contexte de l’embarqu´ e, de nouvelles probl´ ematiques jusqu’alors peu consid´ e- r´ ees dans les approches classiques (o` u les ressources ne sont g´ en´ eralement pas limit´ ees). Dans ce travail, nous avons propos´ e deux configurations du syst` eme UBM/GMM de v´ erification du locuteur d´ evelopp´ e au LIA. Ces configurations, faisant varier trois des pa- ram` etres majeurs des syst` emes de reconnaissance du locuteur, sont adapt´ ees au contexte embarqu´ e et par-

ticuli` erement aux ressources restreintes.

La premi` ere configuration propos´ ee n´ ecessite unique- ment 28% de l’espace m´ emoire et 12% du temps CPU utilis´ es par le syst` eme ´ etat de l’art du LIA (reposant sur la plateforme Mistral) alors que le taux d’erreurs n’augmente que de 20% (restant sous le seuil des 4%).

Une seconde solution, plus « extrˆ eme » , a ´ et´ e propos´ ee pour des applications moins s´ ecuris´ ees. Cette configu- ration obtient un taux d’erreurs inf´ erieur ` a 8% mais ne n´ ecessite que 17% de l’espace m´ emoire et 1,7% du temps CPU requis par le syst` eme de r´ ef´ erence.

De futurs travaux viseront ` a d´ evelopper un syst` eme scalable dynamique, s’adaptant aux ressources dispo- nibles sur le t´ el´ ephone portable ` a un instant donn´ e tout en garantissant les meilleures performances pos- sibles.

Remerciements

Cette ´ etude a ´ et´ e en partie financ´ ee par le projet euro- p´ een MoBio

4

. Ce projet a pour objectif le d´ eveloppe- ment d’une solution pour la biom´ etrie multi-modale embarqu´ ee sur un t´ el´ ephone portable.

R´ ef´ erences

[1] E. Bailly-Bailliere, S. Bengio, F. Bimbot, M. Ha- mouz, J. Kittler, J. Mariethoz, J. Matas, K. Mes- ser, V. Popovici, F. Poree, et al. The BANCA da- tabase and evaluation protocol. Lecture Notes in Computer Science (LNCS), 2688 :625–638, 2003.

[2] Jean-Fran¸ cois Bonastre, Nicolas Scheffer, Driss Matrouf, Corinne Fredouille, Anthony Larcher, Alexandre Preti, Gilles Pouchoulin, Nicholas Evans, Benoˆıt Fauve, and John S.D. Mason.

ALIZE/SpkDet : a state-of-the-art open source software for speaker recognition. In Speaker and Language Recognition Workshop (IEEE Odyssey), 2008. http ://mistral.univ-avignon.fr/.

[3] Eric Charton, Anthony Larcher, Christophe L´ evy, and Jean-Francois Bonastre. Mistral : open source biometric platform. In Symposium on Applied Computing (ACM), Sierre (Switzerland), march 2010.

[4] G. Gravier. SPro : speech signal processing tool- kit. Software available at http ://gforge. inria.

fr/projects/spro.

[5] Patrick Kenny, G. Boulianne, P. Ouellet, and P. Dumouchel. Factor analysis simplified. In IEEE International Conference on Acoustics, Speech, and Signal Processing, ICASSP, volume 1, 2005.

[6] Driss Matrouf, Nicolas Scheffer, Benoit Fauve, and Jean-Francois Bonastre. A straightforward and ef- ficient implementation of the factor analysis model for speaker verification. In International Confe- rence on Speech Communication and Technology, 2007.

[7] M. Przybocki and A.F. Martin. NIST speaker re- cognition evaluation chronicles. In Speaker and Language Recognition Workshop (IEEE Odyssey).

ISCA, 2004.

[8] A. Solomonoff, W.M. Campbell, and I. Boardman.

Advances in channel compensation for svm spea- ker recognition. In IEEE International Confe- rence on Acoustics, Speech, and Signal Processing, ICASSP, volume 1, pages 629–632, 18-23, 2005.

4http://www.mobioproject.org/

Références

Documents relatifs

Il ne faut pas confondre les m´ ethodes de classification avec les m´ ethodes explicatives de discrimination dont l’objectif est d’expliquer une partition connue ` a priori, c’est `

“` a la main” pour vous montrer au moins une fois dans ce cours comment on applique les formules math´ ematiques qui sont donn´ ees dans ce cours. Les donn´ ees pr´ esent´ ees

Je vais traiter cet exemple sans me servir du logiciel R ou presque et faire tous les calculs « ` a la main » pour vous montrer au moins une fois dans ce cours comment nous

Pour améliorer les performances d'un système de reconnaissance automatique du locuteur à travers le canal AWGN dans un environnement bruité, dans ce chapitre, nous

Pour montrer une courbe plus jolie qu’un dessin au tableau, et être sûr de les montrer dans fin de leçon au sprint, on peut aussi projeter cette courbe pour différentes valeurs de

Nous avons ainsi défini quatre masques (un pour chaque bord) (Fig. Le fonc- tionnement du détecteur est expliqué pour le bord gauche, l’extension aux autres bords étant immédiate.

Perdre ses photos de vacances : ¸ca n’a pas de

Interrogeons nous maintenant sur la fa¸con dont sont construits ces tests multidimensionnels, autrement dit sur la fa¸con dont sont obtenues les matrices E pour les erreurs du