| Re: Peace! Was:Re: nouveau wav, c'est mieux! Re: [CBLX] Re: Cicero |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/carrefourblinux Archives
]
OK Nicolas, le seul point qui "fâche" est cette histoire de
temps de réponse et je suis bien obligé d'avouer
qu'objectivement c'est un problème de festival. Aujourd'hui je
"vis dans le luxe" je m'y vautre avec complaisance ! J'ai une
machine ultrarapide et festival réagit ici comme tu le
souaites. Evidemment je confesse aussitot que c'est un très
très mauvais argument. Cela dit je me permets aussi de faire un
peu d'histoire. Quand Roger Mampey a commencé à développé
franfest l'idée était de le mettre au point de manière
extensive pour l'inserrer ensuite dans flite qui comme chacun
sait est la version light de festival et qui répond donc
beaucoup plus vite. C'était peut-être un projet trop ambitieux
en tout cas en regard des moyens dont on disposait.
Pierre
From: Nicolas Pitre <nico@xxxxxxx>
Subject: Re: Peace! Was:Re: nouveau wav, c'est mieux! Re: [CBLX] Re: Cicero
Date: Tue, 10 Feb 2009 00:08:14 -0500 (EST)
> On Sat, 7 Feb 2009, Pierre Lorenzon wrote:
>
> > Y a au moins une chose sur laquelle on est d'accord c'est que la voix
> > de mbrola et quand-même à peu près ce dont on peut disposer de
> > meilleur. La question et celle du préprocesseur et même peut-être même
> > de l'implémentation du préprocesseur. En effet, moi je ne vois aucun
> > inconvénient à vous communiqer le code de mes lexiques et même à vous
> > donner un coup de main pour les interfacer avec votre système.
>
> C'est pas compliqué: Cicero est en fait environ 700 règles de
> substitution utilisant des "regular expressions". Rien de très sorcier
> là dedans. Il ne fait même pas d'analyse grammaticale. On peut donc
> dire que Cicero est une merde qui fonctionne extrèmement bien.
>
> Voici quelques exemples de règles pour situer la simplicité du système:
>
> f [[ ai ]] sV -> @ ## faisons faisan
> [[ a ]] il(l|s?T) -> a ## paille bail
> [[ aie ]] me -> E ## paiement
> [[ ai ]] -> E ## aile
> [[ am ]] [bp] -> a~ ## camp chambre
> [[ am ]] m -> a ## programmation
> [[ am ]] n -> a m ## amnistie
> [[ a ]] nn -> a ## manne
> [[ an ]] (C|T) -> a~ ## ancien
>
> Etc. Les lettres entre [[ et ]] représentent la cible. Les lettres hors
> de la cible quand il y en a doivent correspondre aussi, mais elles ne
> font pas partie de la substitution. Les lettres majuscules représentent
> des ensembles (voyelles, consonnes, séparateurs de mots, etc) et la
> substitution phonétique se trouve à la droite de la flèche "->". Le #
> et tout ce qui suit est ignoré par le système et est utilisé pour
> dénoter des exemples. Voilà en gros le coeur de Cicero. C'est à mon
> avis cette simplicité qui rend le tout si attrayant.
>
> > Donnant donnant, moi si je me décide un jour à programmer un module
> > d'intonation de franfest j'irai faire mon petit état de l'art et si
> > Nicolas Pitre a été malin et a implémenté des algorithmes raisonnables
> > dans cicero je pomperai sans même le début d'un scrupule quitte à
> > mettre une note en disant que je lui ai pompé les algos d'intonations.
>
> En fait, l'intonation de Cicero est encore une fois plus que simple: un
> pattern est appliqué à chaque mot en fonction du nombre de phonèmes
> correspondant à des voyelles (approximation du nombre de syllabes),
> ainsi qu'à la ponctuation suivant ce mot (un espace étant une
> ponctuation neutre). C'est tout. Les bons observateurs ont peut-être
> remarqué déjà que Cicero reproduit en fait la même prosodie que la
> vénérable Télévox. Et ça fait toute la différence entre une synthèse qui
> sonne comme un cadavre et une synthèse plus agréable à écouter.
>
> Voici encore quelques exemples de règles de prosodie, soit celles qui
> s'appliquent aux mots suivi d'une virgule et d'un point:
>
> PROSO_SPEED , -20, 10
> PROSO_PITCH , [1] {"100 135"}
> PROSO_PITCH , [2] {"100 115", "100 135"}
> PROSO_PITCH , [3] {"0 110", "100 115", "100 135"}
> PROSO_PITCH , [4] {"0 120", "100 110", "100 130", "100 135"}
>
> PROSO_SPEED . -30, 10
> PROSO_PITCH . [1] {"100 70"}
> PROSO_PITCH . [2] {"100 110", "100 70"}
> PROSO_PITCH . [3] {"0 120", "100 100", "100 70"}
> PROSO_PITCH . [4] {"0 110", "100 120", "100 100", "100 70"}
>
> ou encore celles ayant trait au point d'exclammation qui sont les plus
> élaborées de toutes:
>
> PROSO_SPEED ! -200, 10
> PROSO_PITCH ! [1] {"0 110 30 180 100 110"}
> PROSO_PITCH ! [2] {"100 130", "20 180 100 110"}
> PROSO_PITCH ! [3] {"100 120", "100 130", "20 180 100 110"}
> PROSO_PITCH ! [4] {"0 120", "100 110", "100 130", "30 180 100 110"}
>
> Et ainsi de suite pour toutes les ponctuations. Si quelqu'un préfère
> une voix plus ennuyeuse, suffit de changer le deuxième nombre de chaque
> tuples.
>
> > De toute façon ne nous voilons pas la face sur ce sujet si ont veut
> > quelque chose de vraiement clean il faut jeter un coup d'oeil aux
> > traités de linguistiqu ad hoc, et implémenter des méthodes et des
> > règles connues depuis la nuit des temps.
>
> En effet, et celà représente une complexité de traitement titanesque
> puisqu'une simple substitution de groupes de lettres par des phonèmes à
> la Cicero ne suffit plus. Et le résultat ne sera pas 20 fois meilleur
> malgré que l'investissement de travail requis soit au moins 20 fois
> celui de l'algo décrit ci-haut. Encore une fois, Cicero est une merde
> mais qui produit des résultats étonnants et plus qu'acceptables. C'est
> une question de rentabilité.
>
> > Pour conclure, Aldo, ma conviction profonde est que
> > l'environnement de développement de franfest par sa modularité,
> > sa souplesse, et par le fait qu'il est partagé par une vaste
> > communauté offfre des possibilités de développement plu vastes
>
> Là je ne suis pas tout à fait d'accord. Oh c'est vrai que Festival a le
> potentiel pour pouvoir générer une meilleure prononciation que ce que
> Cicero ne pourra jamais produire. Mais Cicero est déjà plus
> qu'acceptable à mon avis, et écrire des moteurs de synthèse n'est pas
> mon passe-temps premier. Encore une fois c'est une question de
> rentabilité.
>
> Parcontre, il y a un point sur lequel je ne peux et n'accepterai jamais
> aucun compromis: le temps de réponse. Lorsque je veux que la synthèse
> se ferme la gueule, celà doit se produire dans le miliseconde suivant ma
> commande. Lorsque je veux que la synthèse démarre, celà doit paraître
> instantané. Si je mitraille la flèche bas du clavier, je veux que la
> synthèse redémarre sur la nouvelle ligne sans aucun délai. Et même si
> je peux taper relativement vite, je veux que la synthèse soit capable
> d'énoncer chaque frappe avant que je tape la suivante. Et lorsque la
> lecture se fait en mode continu, je veux que le terminal braille soit
> constamment synchronisé avec la voix au mot près. Et Cicero fait tout
> ça car il a été écrit dans ce but. Et quand il ne le fait pas
> suffisamment bien à mon goût, je n'ai que 1400 lignes de code source à
> considérer pour rémédier au problème. C'est quelque chose que jamais
> Festival ne pourra m'offrir.
>
> > Bref, la question se situe à plusieurs niveaux vis-à-vis
> > desquels ma position est la suivante :
> >
> > - s'il s'agit d'écrire une ligne de python pour cicero : ne
> > comptez pas sur moi je ne connais pas ce langage et n'ai pas
> > envie de l'apprendre.
>
> Comme illustré ci-haut, les règles de prononciation de Cicero sont
> indépendantes du language. En fait, quelqu'un semble avoir
> réimplémenter Cicero en C++ tout en utilisant les mêmes règles.
>
> > - S'il s'agit de partager des algorithmes ou de les améliorer
> > pleinement d'accord;
>
> Tout à fait.
>
>
> Nicolas
---
--
CarrefourBLinuX MailingListe
Pour obtenir de l'aide, envoyez le sujet help à:
carrefourblinux-request@xxxxxxxxxxxxxxxxxxx
Archives:
http://listengine.tuxfamily.org/lists.tuxfamily.org/carrefourblinux