(Courriels de diversion: <programmais@remplirons-rassasiez.com> <enregistrerait@entierete-dialectique.com> <coloniserons@soupconnee-rurale.com> <periclita@budgetisation-bloques.com> <inspiree@annexees-avilis.com> <depose@encrant-secretait.com> <ambree@reexaminant-regretteriez.com> <fusionniez@gauchi-ravisse.com> <crecelle@surestimeriez-repercuter.com> <oisons@descendante-homogeneisant.com> )
Le jeu 04/12/2003 à 17:02, Roger.Mampey a écrit : > Bonjour, > > Mon objectif principal est de revenir à FranFest, c'est-à-dire utiliser les > données rassemblées par Frédéric Béchet pour remplacer le lexique de 6Mo > actuellement indispensable à FranFest. Ca ne signifie pas abandonner Llia_Phon > mais je rappelle que FranFest avait seulement été mis en sommeil. Rappel : FranFest = Festival en français http://www.CULTe.org/projets/install/lao/festival.shtml > > On s'était également entendu sur le fait que la version actuelle de LLia_Phon > était caractérisée par le fait qu'on ne touchait pas à la structure des fichiers > de données de Frédéric. Jusqu'ici, on a seulement éliminé le passage par > certains fichiers dérivés (précompilés) mais la logique des évolutions sur > Llia_Phon nous conduit à faire un peu plus pour les fichiers de données > statistiques. Comme tous ces fichiers de données doivent être conçus comme > variables au cours du temps (ajout/retrait d'entrées dans les lexiques, de > règles dans les catalogues, modification des données statistiques), il vaut > mieux spécifier une bonne fois le contenu de ces fichiers, les liens qu'ils ont > entre eux (lexiques et données statistiques) ainsi que les opérations de > pré-compilation indispensables si une modification doit être faite. > > Même si la structure superficielle des fichiers n'est pas la même pour FranFest > et pour Llia_Phon, ce travail de spécification est identique dans les 2 cas. > > Ca donne en gros, et dans cet ordre : > > 1/ Blocage des évolutions sur la version courante de Llia_Phon, ce qui ne > signifie pas qu'il n'y a plus rien à y faire, j'en parle plus bas. > > 2/ Création d'une nouvelle version de FranFest. Ce qui nécessite de voir de plus > près comment la version courante a été intégrée dans Oralux par Pierre Lorenzon. Précision : P. Lorenzon travaille sur EFM qui est un patch d'Emacspeak pour FranFest ... ensuite repris par la distribution Oralux de Gilles Casse. Il semble d'ailleurs qu'il y ait actuellement un problème d'accès à l'hébergement d'EFM. Au fait, Roger, as-tu installé le lexique français complet de FranFest chez TuxFamily ??? > > 3/ Création d'une nouvelle version de Llia_Phon. Outre la redéfinition des > fichiers de données, il faudrait peut-être aussi étudier de plus près la > possibilité de passer à une structuration client/serveur. > > En ce qui concerne le point 1/ il y a, à mon sens, 2 choses à faire avant de > considérer la version courante comme intéressante à "porter" sous Windows ou > Apple ou Sun ou ... > > a/ Fournir une autre prosodie et donner à l'utilisateur la possibilité de les > paramétrer (j'ai vu la vitesse que Nath et David estiment raisonnable alors > qu'elle n'est pas modifiable dans la version courante). On n'aura pas une > prosodie satisfaisante avant un bout de temps si un linguiste (prosodiste de > surcroit) ne nous rejoint pas, mais on peut faire mieux que ce qu'on a. > Je vise fin janvier au plus tard sur ce point. La vitesse d'élocution et la hauteur de la voix Mbrola sont réglables a posteriori après génération du fichier phonétisé par LLiaPhon. Il suffit de placer un en-tête : ;; F= (pour modifier la fréquence/pitch) ;; T= (pour la vitesse/time) ParleMax ou un autre serveur vocal sauront faire cela. > > b/ Faire la chasse aux sources d'erreurs dans le code. Il y en a au moins 3 qui > vont demander un certain travail, vous allez sans doute en trouver d'autres. > > */ Eliminer tous les appels aux fonctions de gestion des chaines ascii qui > ignorent les lettres accentuées (isupper, tolower, ...). Remplacer par les > fonctions fr_ introduites récemment dans util.c > > */ Eliminer toutes les lectures de fichier qui présupposent une organisation > binaire particulière en mémoire (suite à la remarque de Franz à l'Oxford). Après > enquête, il en reste pas mal dans l'étiquetage grammatical. > > */ Eliminer tous les risques de débordements de tableau et de pointeurs non > définis. Ca, c'est un gros boulot, il y a des réservations à la louche un peu > partout dans le code et il y a déjà eu au moins un bug de débordement corrigé de > façon complétement supercielle. > Pour l'instant, je vise aussi fin janvier sur ce point (avec l'aide de Phil > évidemment). C'est noté pour moi. Mais ne soyons pas restrictifs. Des nouveaux peuvent entrer dans le sujet en chassant les (quelques) bugs. Merci, Roger, d'avoir inventorié ces perspectives. A+ -- Phil