Lecture automatique TTS

Home » <span title="Lecture automatique TTS"> Lecture automatique TTS


Le contenu sonore du lecteur audio ci-dessous est une trans­crip­tion vocale réali­sée à l’aide du plugin SPEAKER (voir plus bas). Vous pouvez écou­ter cette même page avec un lecteur MEKS (cliquer ce lien).

Source : OER Services

Cette page présente mon choix d’un logi­ciel de lecture auto­ma­tique — en anglais text-to-speech, d’où le sigle « TTS ».

J’ai installé ce dispo­si­tif pour faci­li­ter l’ac­cès de ce site aux personnes à vision réduite, mais aussi aux lectrices et lecteurs qui le fréquentent via une tablette ou un smart­phone, plutôt qu’un ordi­na­teur de bureau. Les statis­tiques révèlent que ce mode d’ac­cès est celui de presque la moitié des visiteurs.

Avec un smart­phone, surtout si l’on est occupé à d’autres acti­vi­tés — marcher, conduire un véhi­cule, faire la cuisine, etc. — il est diffi­cile, si ce n’est impos­sible, de lire un long texte en entier. Or, de nombreuses personnes (c’est mon cas) sont habi­tuées à l’écoute de podcasts d’émis­sions radio­pho­niques dont la durée peut dépas­ser une heure. Elles peuvent donc consa­crer le même temps à écou­ter une trans­crip­tion orale, pourvu que celle-ci ne soit pas trop artificielle…

De plus en plus fréquem­ment, des auteurs de blogs disposent au sommet de chaque article un lecteur audio qui permet d’en écou­ter le contenu. Toutefois, contrai­re­ment à eux, je n’ai pas du tout l’in­ten­tion de m’en­re­gis­trer en train de lire mes écrits, ce qui m’obli­ge­rait à recom­men­cer la lecture après chaque modi­fi­ca­tion ! Ce site est en perpé­tuelle mise à jour, certai­ne­ment une de ses prin­ci­pales quali­tés… J’ai donc choisi d’es­sayer la trans­crip­tion orale auto­ma­tique, le fameux TTS qu’on peut (re)lancer d’un simple clic après un travail d’édition.

J’avais une autre moti­va­tion à m’in­ves­tir dans ce projet. Pendant une ving­taine d’an­nées, j’ai travaillé au CNRS dans un centre de recherches en sciences de la parole — le Laboratoire Parole et Langage — et plus parti­cu­liè­re­ment avec l’équipe Prosodie de la parole diri­gée par Daniel Hirst. À l’époque, nous rêvions de logi­ciels TTS qui synthé­ti­se­raient au mieux la voix humaine, autant dans ses dimen­sions phoné­tique et arti­cu­la­toire que dans la construc­tion de la proso­die : rythme, inten­sité, into­na­tion. Les méthodes clas­siques « à partir de règles » ne donnaient satis­fac­tion que dans des domaines limi­tés. Or notre rêve est en partie devenu réalité — à vous d’en juger ! — grâce aux tech­niques d’ap­pren­tis­sage auto­ma­tique qu’au­jourd’­hui les ingé­nieurs dési­gnent par Big Data, et les « commu­ni­cants » Artificial Intelligence

En réalité, il n’y a aucune intel­li­gence dans cette approche… On se contente de fabri­quer des « boîtes noires » qui feront le travail, après un fasti­dieux entraî­ne­ment sur de grandes masses de données. Mais ces boîtes noires ne peuvent pas — et ne pour­ront jamais — révé­ler leurs « secrets ». Pas plus qu’un enfant de cinq ans ne pour­rait énon­cer les règles auxquelles il obéit intui­ti­ve­ment pour commu­ni­quer dans sa langue maternelle.

Cette tech­no­lo­gie a été rendue possible par l’ar­ri­vée de plate­formes infor­ma­tiques puis­santes — en rapi­dité, en mémoire et en espace de stockage — et surtout par l’im­mense masse de données (textuelles et orales) collec­tées par les géants du Net (Google, Amazon, etc.). Des dispo­si­tifs text-to-speech sont aujourd’­hui dispo­nibles pour un grand nombre de langues, avec des voix de plus en plus proches de celles de locu­teurs humains — voir la liste de Google et faire un essai.

J’ai donc décidé de tenter l’ex­pé­rience, tout en gardant en tête l’idée que ce dispo­si­tif n’est pas supposé rempla­cer une lecture humaine, mais simple­ment offrir un nouveau mode d’ac­cès au contenu de ce site. Le défi étant que, plus la trans­crip­tion se rapproche de la lecture humaine, plus on en repère les défauts !

Le pari était risqué, mais il s’est avéré judi­cieux : en un mois, la fréquen­ta­tion du site et le nombre d’ar­ticles consul­tés ont été multi­pliés par quatre.

Surtout, j’ai décou­vert qu’il était facile d’amé­lio­rer le rendu vocal des trans­crip­tions en program­mant des règles (voir ci-dessous). Retour, donc, à la vieille école des gram­maires formelles ! 😀

Seule ombre au tableau : l’ab­sence d’ac­cents régio­naux, ou plutôt la domi­na­tion de celui des sujets dont les paroles ont été incluses au corpus d’ap­pren­tis­sage — voir article. Navré pour mes collègues socio­lin­guistes ! Le seul accent fran­çais « diffé­rent » sur Google Cloud est celui, unifor­misé lui aussi, de locu­teurs du « fran­çais cana­dien » (fr-CA). On constate d’ailleurs que, dans notre monde globa­lisé, la notion d’ac­cent se réduit à la seule combi­nai­son d’une langue et d’un pays…

La suite de cette page s’adresse aux éditeurs de sites WordPress fran­co­phones qui souhaitent se lancer dans la même aven­ture. J’y partage mon expé­rience afin de leur faci­li­ter la tâche.

Sommaire

Premiers essais de plugins TTS 

J’avais pris connais­sance de quelques logi­ciels TTS sur des articles compa­ra­tifs (en anglais). Leurs descrip­tions en étaient malheu­reu­se­ment super­fi­cielles, visi­ble­ment rédi­gées par des infor­ma­ti­ciens qui n’avaient pas pris le temps de les évaluer sur des données réelles.

Il faut savoir que la trans­crip­tion orale, propre­ment dite, est presque toujours effec­tuée sur les grandes plate­formes : Google Cloud, Amazon Web Services, Microsoft Azure, et peut-être d’autres. Le résul­tat sera donc quasi­ment iden­tique quel que soit le plugin installé sur le site WordPress. Seuls quatre critères permettent d’exer­cer un choix adapté aux besoins (et au budget) :

  1. Le prix du plugin
  2. L’interface d’édi­tion
  3. L’interface du lecteur audio
  4. Le pré-traitement des données textuelles

Je ne décri­rai que des plugins couplés à Google Cloud. La bonne nouvelle est que la trans­crip­tion orale via Google Cloud est gratuite dans des quan­ti­tés raison­nables — voir tarif. Avec un simple compte Google Cloud, on peut trans­crire chaque mois, sans rien dépen­ser, un nombre appré­ciable de caractères.

J’utilise de préfé­rence les voix les plus raffi­nées : celles des caté­go­ries « Neural2″ et « Wavenet », pour lesquelles la plate­forme traite gratui­te­ment jusqu’à 1 million de carac­tères par mois. Au-delà de ce quota, comp­ter 16 dollars par tranche supplé­men­taire de 1 million de carac­tères. Ce surcoût est quatre fois moins élevé pour les voix stan­dard, mais leur rendu sonore (en fran­çais) est fran­che­ment moins bon. Les tarifs sont quasi­ment iden­tiques sur Amazon Polly.

Les plate­formes proposent aussi, moyen­nant finances, de créer une brand voice, autre­ment dit une voix ayant toutes les carac­té­ris­tiques d’une voix exis­tante prise pour modèle. Il est à craindre que les imper­fec­tions soient encore plus audibles dans ce cas !

Quelle que soit la voix choi­sie, le contour proso­dique est médiocre sur les phrases très longues. Il peut même conduire à un esca­mo­tage de syllabes, voire une pronon­cia­tion incom­pré­hen­sible si l’on s’obs­tine à faire de trop longues phrases. Utiliser une ponc­tua­tion abon­dante : ne pas écono­mi­ser les virgules, ne pas essayer de lire du Proust ! 😀

Le véri­table critère à prendre en compte pour la viabi­lité d’un TTS est le prix du plugin. Soit le vendeur demande un règle­ment une fois pour toutes, soit il faut passer par un abon­ne­ment mensuel ou annuel, auquel cas le plugin peut aussi limi­ter le nombre de textes ou de carac­tères transcrits.

Pour ne pas vous faire plus attendre, je peux révé­ler que j’ai dépensé, en tout et pour tout, 29 euros pour la mise en place du plugin SPEAKER sur ce site (en décembre 2022). Bien entendu, la facture de Google Cloud est en propor­tion du volume de texte converti, étant donnés les innom­brables essais qu’il m’a fallu faire pour en affi­ner les règles… Il est donc prudent, surtout au début, de garder un œil sur la factu­ra­tion (billing) de son compte Google Cloud.

Voici pour commen­cer les deux plugins que j’ai essayés en situa­tion réelle, mais pas adop­tés. Ils peuvent s’avé­rer préfé­ren­tiels dans d’autres environnements.

Trinity Audio

Ce plugin (voir télé­char­ge­ment) fonc­tionne en version gratuite, mais avec une contrainte sévère sur le nombre d’ar­ticles ou pages conver­ties chaque mois : seule­ment 5 (voir les prix des diffé­rentes offres). Cette version gratuite ne sert prati­que­ment qu’à titre d’essai.

Je suis donc immé­dia­te­ment passé à l’offre BASIC factu­rée 15 dollars par mois. Mauvaise surprise : l’in­ter­face (fin 2022) ne permet­tait pas un verse­ment mensuel. J’ai donc dû m’ac­quit­ter de 189 dollars pour un abon­ne­ment annuel. Somme qui m’a heureu­se­ment été rembour­sée sans diffi­culté quand j’ai renoncé à cette solu­tion — par appli­ca­tion de la garan­tie de rembour­se­ment à 30 jours.

Avec l’offre BASIC, j’ai pu conver­tir un plus grand nombre d’ar­ticles, la limite étant de 30 par mois. Toutefois, après 5 modi­fi­ca­tions, toute modi­fi­ca­tion de l’ar­ticle est comp­tée comme un nouvel article. Autrement dit, pour un même article sur lequel j’avais effec­tué 9 modi­fi­ca­tions, j’étais taxé de « 5 articles ». On comprend ici que même l’offre BASIC ne convient pas aux sites dont les conte­nus sont régu­liè­re­ment mis à jour. Chaque fois que je relis un de mes textes, j’ai tendance à en corri­ger le contenu — car je suis un médiocre rédac­teur. Pour un bon rendu sonore, des correc­tions signi­fi­ca­tives peuvent se limi­ter à ajou­ter une virgule à un endroit parti­cu­lier, afin de déli­mi­ter les unités de souffle qui gouvernent le contour prosodique.

L’offre BASIC donne accès à un autre dispo­si­tif appelé « lexique » (lexi­con). Ce sont de simples règles de réécri­ture appli­quées à des mots ou des expres­sions. Un très grand avan­tage du lexique de Trinity Audio est la possi­bi­lité d’en­trer des carac­tères phoné­tiques (alpha­bet IPA) et d’af­fi­ner ainsi la pronon­cia­tion de mots étran­gers sans chan­ger de langue. Toutefois, ce lexique étant limité à 5 mots sur l’offre BASIC, ce n’est rien d’autre qu’un produit d’ap­pel pour l’offre (appe­lée STANDARD) qui coûte 849 dollars par an… À ce prix, l’uti­li­sa­tion du lexique est illi­mi­tée, mais la contrainte reste de 200 articles (ou modi­fi­ca­tions) par mois.

Le lecteur de Trinity Audio. C’est une simple image !

Un avan­tage de Trinity Audio sur les autres solu­tions décrites ci-dessous est le design de son lecteur — voir image ci-dessus. Il comprend (en haut à droite) deux boutons qui permettent d’avan­cer ou de recu­ler de 10 secondes. D’autre part, on peut en option ajou­ter un lecteur « flot­tant » qui reste posi­tionné dans la marge gauche de la page, même pendant son défi­le­ment. Cette solu­tion est idéale pour la lecture sur les petits écrans des smart­phones, et globa­le­ment bien adap­tée à une lecture de texte (plutôt qu’une écoute musicale).

Noter aussi, en haut à droite (à peine visible) un bouton qui permet le choix de la vitesse de lecture. Cette fonc­tion très utile existe sur tous les dispo­si­tifs TTS.

Par contre, le posi­tion­ne­ment sur la page du lecteur audio n’est pas facile : soit au sommet, soit au bas de l’ar­ticle, soit encore l’op­tion d’un lecteur javas­cript qui néces­site de copier un code dans les champs person­na­li­sés (custo­mi­zed fields) de l’ar­ticle, puis de placer un short­code dans un bloc HTML à l’emplacement du lecteur. Sur un site WordPress, cette solu­tion ne fonc­tionne qu’a­vec une exten­sion (par exemple Code Embed) permet­tant d’in­sé­rer du javas­cript dans le contenu textuel des articles… Tout cela est labo­rieux à mettre en œuvre, et peut-être même une porte ouverte à des failles de sécurité.

Nonobstant les limi­ta­tions que j’ai expo­sées, Trinity Audio est une bonne solu­tion si le budget l’au­to­rise. J’ai longue­ment dialo­gué avec leur équipe tech­nique qui s’est montrée aussi effi­cace que bien­veillante, m’au­to­ri­sant même des dépas­se­ments de quotas pour effec­tuer des essais. Localisée en Ukraine, cette équipe mérite d’être soute­nue pour la pour­suite de ses acti­vi­tés dans des condi­tions parti­cu­liè­re­ment difficiles. 

BeyondWords

Cette solu­tion (voir télé­char­ge­ment) se présente sous trois tarifs : le plan PILOT (gratuit), le plan PRO (89 dollars par mois) et le plan ENTERPRISE (tarif non précisé). Je n’ai essayé que la version gratuite qui auto­rise 10 000 carac­tères par mois, ce qui peut paraître limité, sauf que les modi­fi­ca­tions ne sont pas déduites du quota tant que le nombre de para­graphes de l’ar­ticle n’est pas augmenté. Ce plan gratuit est donc viable sous réserve de désac­ti­ver la mise à jour auto­ma­tique de la conver­sion pendant qu’on édite le texte.

Le lecteur de BeyondWords. C’est une simple image !

Le lecteur audio (voir image ci-dessus) est très facile à posi­tion­ner n’im­porte où sur la page. Il peut être large­ment modi­fié en utili­sant les codes CSS. (Je l’avais ici colo­rié en jaune.) Un point qui me paraît inté­res­sant est sa très faible hauteur. Il comprend aussi (à peine visible, en bas à gauche) un bouton pour le choix de la vitesse de lecture.

Dès la solu­tion gratuite, BeyondWords donne accès à une sorte de lexique (aliases) illi­mité. Par exemple, j’ai programmé le rempla­ce­ment auto­ma­tique de « et al » par « et collègues », car c’est ainsi qu’un lecteur averti inter­prè­te­rait cette expres­sion. Par contre, ces alias ne recon­naissent pas l’al­pha­bet phoné­tique. Pour pronon­cer « American Stroke Association », par exemple, il faut brico­ler un alias du style « American Stroke Associeysheun » au lieu de « əˈmɛrəkən stroʊk əˌsoʊ­siˈeɪʃən » en IPA (voir le conver­tis­seur)…

On peut, par défaut, choi­sir une voix pour lire les titres et une autre pour les para­graphes ordi­naires. Toutes ces voix sont dési­gnées par des prénoms.

Une option carac­té­ris­tique de BeyondWords consiste à déso­li­da­ri­ser (désyn­chro­ni­ser) le texte d’ori­gine de celui qui doit être lu, ce qui permet des correc­tions de pronon­cia­tion (en plus de celles des alias) mais aussi l’édi­tion d’un texte lu aussi diffé­rent qu’on le souhaite du texte écrit. C’est actuel­le­ment le seul moyen, en fran­çais, de corri­ger les liai­sons. Bien entendu, toute modi­fi­ca­tion du texte écrit devra être repro­duite (manuel­le­ment) sur le texte lu.

Le nombre de voix (et de langues) est impres­sion­nant, puisque ce logi­ciel permet d’ac­cé­der aux ressources des trois plate­formes Google Cloud, Amazon Web Services, Microsoft Azure, ainsi qu’à des voix (unique­ment en anglais) spéci­fi­que­ment déve­lop­pées par BeyondWords.

J’ai corres­pondu avec l’équipe très sympa­thique de BeyondWords pour leur suggé­rer quelques correc­tions et amélio­ra­tions. Ils m’ont notam­ment signalé qu’ils allaient révi­ser le design de leur lecteur audio pour répondre à des besoins tels que la version « flot­tante » que j’avais beau­coup appré­ciée sur Trinity Audio.

L’équipe de BeyondWords comprend des ingé­nieurs et des linguistes infor­ma­ti­ciens de Google, d’Apple et du Centre de recherche sur les tech­no­lo­gies de la parole d’Edimbourg au Royaume-Uni.

Même dans sa version gratuite, BeyondWords est une solu­tion qui permet d’ob­te­nir un bon rendu vocal sans faire appel à des mani­pu­la­tions infor­ma­tiques complexes. Cependant, comme Trinity Audio, elle n’est opti­mi­sée que pour la publi­ca­tion et la trans­crip­tion orale de textes qui ne sont pas desti­nés à rece­voir de fréquentes modifications.

Remarque

Je n’ai pas conservé les instal­la­tions de Trinity Audio et BeyondWords, ce qui fait que certains aména­ge­ments que j’ai effec­tués sur SPEAKER (voir ci-dessous) auraient pu aussi résoudre quelques problèmes sur ces solu­tions. Merci de me faire part de votre expérience !

SPEAKER

Ma moti­va­tion prin­ci­pale pour essayer (puis adop­ter) SPEAKERvoir télé­char­ge­ment et descrip­tion détaillée en anglais — était que c’est le seul dispo­si­tif à ce jour (début 2023) qui gère (une partie du) bali­sage SSML (Speech Synthesis Markup Language). Le codage de ces balises par SPEAKER est (incom­plè­te­ment) présenté sur cette page.

Plateforme de conversion TTS

SPEAKER utilise la plate­forme Google Cloud pour créer les fichiers audio. À l’in­verse de ses concur­rents, il n’im­pose aucune limi­ta­tion au nombre de textes conver­tis. Concrètement, l’uti­li­sa­teur (le webmas­ter) doit utili­ser son propre compte Google Cloud et s’ac­quit­ter direc­te­ment sur ce compte, le cas échéant, des frais de dépas­se­ment du quota mensuel.

L’installation de SPEAKER néces­site le règle­ment, une fois pour toutes, d’un droit d’uti­li­sa­tion (29 euros fin 2022) à la société CodeCanyon. C’est donc de loin la solu­tion la plus écono­mique, et proba­ble­ment — nous allons le montrer — la plus puis­sante pour un informaticien.

La partie labo­rieuse de cette instal­la­tion est la mise en connexion du plugin SPEAKER avec le compte Google Cloud qui sera utilisé pour les conver­sions. Les habi­tués de Google s’y retrou­ve­ront mieux que moi ! Tout est docu­menté en détail — en anglais, ça commence ici et ça conti­nue ici.

Le traitement

Schématiquement, le trai­te­ment se résume ainsi : quand on clique le bouton Create audio (ou Re-create audio), SPEAKER lit le contenu de la page ou de l’ar­ticle tels qu’ils appa­raissent à l’af­fi­chage — détail impor­tant, comme nous le verrons ci-dessous.

SPEAKER applique ensuite des règles de réécri­ture (voir ci-dessous) program­mées (en option) par l’uti­li­sa­teur. Il découpe enfin le texte en frag­ments (maxi­mum 4500 carac­tères) envoyés à Google Cloud pour la conver­sion sonore. Cette taille un peu supé­rieure à 4500 carac­tères est une limite incon­tour­nable du service Google Cloud.

Les fichiers sonores (au format MP3) retour­nés par Google sont alors stockés dans un réper­toire appro­prié. En fin de conver­sion, le plugin colle ensemble ces fichiers tempo­raires pour fabri­quer un seul fichier MP3 qui sera utilisé à l’audition.

Stockage des fichiers sonores

Plusieurs options sont propo­sées pour le stockage des fichiers MP3 : soit dans un réper­toire du site WordPress /wp-content/uploads/speaker/, soit dans un espace de Google Cloud. La seconde solu­tion (que je n’ai pas su implé­men­ter) peut entraî­ner une factu­ra­tion supplé­men­taire. Elle a peut-être comme avan­tage un accès plus rapide aux fichiers lors de la lecture (à vérifier).

Lorsqu’on opte pour l’hé­ber­ge­ment des fichiers MP3 sur le site WordPress, on peut deman­der d’af­fi­cher les fichiers sonores dans le dossier « médias », ce qui peut être utile si l’on utilise un plugin diffé­rent pour affi­cher le lecteur audio — bien que la construc­tion de ces URL soit très facile.

Dans tous les cas, aucun service n’est facturé pour la lecture des fichiers sonores. Cette lecture n’im­plique pas Google Cloud. Autrement dit, le prix de la sono­ri­sa­tion du site ne dépend pas de sa fréquen­ta­tion. C’est un point à véri­fier avant de se lancer dans toute autre solution.

Les lecteurs audio

Le posi­tion­ne­ment du lecteur n’im­porte où sur la page (avec l’op­tion de design « short­code ») est simple, puis­qu’il se résume à inscrire le short­code [@speaker] dans un bloc HTML person­na­lisé (sous WordPress). Supprimer le carac­tère ‘@’ utilisé ici pour empê­cher l’af­fi­chage du lecteur sur cette page…

➡ Je n’ai pas essayé les options de posi­tion « before title », « top fixed » etc. car en sélec­tion­nant « before title » le site s’est bloqué (error 503), ce qui m’a obligé à désac­ti­ver bruta­le­ment SPEAKER via un accès FTP !

Plusieurs options sont propo­sées pour le design du lecteur audio : soit un lecteur Chrome, soit le lecteur spéci­fique du navi­ga­teur, soit le lecteur par défaut de WordPress, soit enfin des lecteurs « rond », « arrondi » ou « rectan­gu­laire ». On peut ensuite en amélio­rer l’as­pect en jouant sur les classes CSS, et insé­rer du code HTML avant ou après le lecteur. Le lecteur Chrome est celui qui appa­raît en haut de cette page, quel que soit votre navigateur.

Dans le short­code, on peut utili­ser une syntaxe plus complète : [@speaker id=nnnn] (toujours sans le carac­tère ‘@’) dans laquelle « nnnn » est le numéro de la page ou de l’ar­ticle concerné. Ce qui permet d’af­fi­cher sur une page un lecteur lisant le texte d’une page diffé­rente. Très pratique si l’on envi­sage d’édi­ter un texte pour la lecture distinct de sa version écrite, comme avec BeyondWords. Dans ce cas, le texte destiné à la lecture pourra être édité sur une page privée, invi­sible sur le site, et rendue publique unique­ment le temps de géné­rer sa trans­crip­tion orale. Cette solu­tion est meilleure que celle précé­dem­ment mention­née pour BeyondWords, car elle ne repose que sur des ressources (textuelles et sonores) locales.

Rien n’in­ter­dit d’édi­ter par la suite le fichier sonore en lui ajou­tant, par exemple, de la musique.

De manière géné­rale, si les fichiers sont stockés dans le réper­toire /wp-content/uploads/speaker/, un simple lien suffit pour accé­der au contenu sonore. Par exemple, le lien https://lebonheurestpossible.org/wp-content/uploads/speaker/post-35807.mp3 permet d’écou­ter la trans­crip­tion de cette page (iden­ti­fiant 35807). Ce même lien permet d’in­sé­rer un lecteur audio stan­dard HTML 5 donnant le même accès :

Lecteur audio au format HTML5 (par défaut sur ce navigateur)

De plus, il est possible d’uti­li­ser des lecteurs plus sophis­ti­qués, géné­rés par des plugins de WordPress, puisque le seul para­mètre à intro­duire est l’URL du fichier sonore, facile à déter­mi­ner pour n’im­porte quel article ou page. J’ai trouvé (et adopté) un lecteur « collant » (sticky) avec l’ex­ten­sion gratuite Meks Audio Player (voir télé­char­ge­ment) qui se posi­tionne auto­ma­ti­que­ment au bas de la fenêtre. Dans ce cas, les lecteurs SPEAKER peuvent être suppri­més. Voir par exemple un article de ce site, ou écouter cette page avec le lecteur MEKS.

On appré­ciera que le lecteur MEKS auto­rise des sauts en avant, et en arrière, de 15 secondes, comme c’était le cas de celui de Trinity Audio. Ses seuls défauts actuels sont sa hauteur exces­sive, et le nombre réduit de para­mètres permet­tant de modi­fier son aspect.

Pré-traitement du texte

Des short­codes sont propo­sés par SPEAKER pour rendre inau­dibles certains passages du texte, comme par exemple des légendes de figures ou des réfé­rences biblio­gra­phiques en fin d’ar­ticle. Les mêmes effets peuvent être produits, et donc auto­ma­ti­sés, par les règles de réécriture.

SPEAKER n’uti­lise pas un lexique ni des alias, mais il permet d’in­tro­duire un nombre illi­mité de règles (RegEx repla­ce­ments) obéis­sant à une syntaxe (expres­sions régu­lières) que les program­meurs utilisent couram­ment dans des fonc­tions comme preg_replace() du langage de program­ma­tion PHP, ou encore pour gérer la redi­rec­tion de connexions dans les fichiers htac­cess des serveurs HTTP Apache.

L’utilisation effi­cace de SPEAKER exige donc une parfaite maîtrise de la syntaxe des expres­sions régu­lières. Il suffit qu’une règle soit mal formée pour que la conver­sion échoue, avec une redou­table alerte : « error 3 » !

Par exemple, les voix fran­co­phones de SPEAKER prononcent incor­rec­te­ment le nom de « Jeanne Calment » en disant « Calmin ». Pour corri­ger ce défaut, on peut intro­duire la règle suivante :

/Calment/
calmant

Un mot, ou une suite de mots, peuvent aussi être recon­nus et rempla­cés par d’autres suites de mots, par exemple :

/TLF/
dictionnaire « trésor de la langue française »

/整体/
terme japonais

/\s=>\s/
&nbsp;implique&nbsp;

Des règles plus complexes et leurs astuces tech­niques sont expli­quées ci-dessous.

Traitement par lot

Le trai­te­ment par lot (en anglais batch proces­sing) est une fonc­tion très puis­sante de SPEAKER. Une fois que les règles de réécri­ture ont été complé­tées et corri­gées, il peut être néces­saire de relan­cer la conver­sion de tous les articles (ou d’une sélec­tion d’ar­ticles) du site, sans devoir les ouvrir un par un en mode édition…

Pour cela, il suffit d’af­fi­cher la liste des pages ou articles, de sélec­tion­ner lesquels doivent être trai­tés, puis de sélec­tion­ner « Create audio » dans « Actions grou­pées ».

Attention toute­fois au risque d’ex­plo­sion de la facture Google Cloud ! Pour cette raison, les trans­crip­tions vocales de ce site ne sont pas toutes mises à jour après chaque modi­fi­ca­tion des règles ou des paramètres.

Gabarits (templates)

Les gaba­rits (templates) servent, dans SPEAKER, à exploi­ter les Custom Post Types des récentes versions de WordPress. Ce déve­lop­pe­ment est en accord avec les plus récentes méthodes de construc­tion des sites. Suivre les instruc­tions de cette page.

Une équipe très sympa

J’entretiens une corres­pon­dance régu­lière avec l’équipe tech­nique de SPEAKER — elle aussi loca­li­sée à Kiev — tantôt via leur forum d’en­traide, tantôt par messa­ge­rie électronique.

J’ai modi­fié leur plugin (versions 3.4.2 à 4.0.13) pour contour­ner quelques problèmes expli­qués ci-dessous, puis je leur ai envoyé une liste de sugges­tions (voir copie). Leurs réponses ont été cordiales et construc­tives, parfois avec quelques jours de retard, étant donnée la situation.

Je suis sur le point d’ins­tal­ler la version suivante (4.0.4) et mettrai à jour cette page en conséquence.

Pour les geeks…

Ce qui suit est destiné aux webmas­ters souhai­tant instal­ler la solu­tion SPEAKER sur un site WordPress fran­co­phone. Loin de couvrir toutes les options, je m’en tiens aux points dont la compré­hen­sion m’a demandé quelques jour­nées de travail, en l’ab­sence d’une docu­men­ta­tion détaillée.

Les lecteurs anglo­phones habi­tués à l’in­for­ma­tique peuvent consul­ter le rapport que j’ai fait parve­nir à l’équipe tech­nique en janvier 2023. En fin de rapport, les annonces encou­ra­geantes de l’équipe.

Choix d’une voix ou d’une langue

Sur SPEAKER, on choi­sit une voix et une langue par défaut. Il est ensuite possible d’en chan­ger au cours de l’ar­ticle ou de la page, en utili­sant des instruc­tions SSML (voir ci-dessous). Voir, par exemple, un chan­ge­ment de voix dans l’ar­ticle Mon magnifique mari.

En fran­çais, surtout pour les voix mascu­lines, il est préfé­rable d’uti­li­ser celles de la série Neural2 , ou en second choix Wavenet. Pour des raisons inex­pli­quées, la trans­crip­tion vocale d’un texte avec une voix Neural2 peut échouer (« error 3 »). Dans ce cas, il suffit de se rabattre sur une voix Wavenet. Dans ce cas, je préfère une voix féminine.

Les voix que j’ai adop­tées en stan­dard sur ce site sont :

  • Voix par défaut (mascu­line) : fr-FR-Neural2‑D réglée à la vitesse 1.2
  • Citations (fémi­nine) : fr-FR-Wavenet‑C à vitesse normale
  • Voix lorsque « error 3 » (fémi­nine) : fr-FR-Wavenet‑E
  • Voix lorsque « error 3 » (mascu­line) : fr-FR-Wavenet‑D

Les voix en d’autres langues sont listées ci-dessous.

Bien entendu, ces choix pour­ront être révi­sés lorsque de nouvelles voix seront dispo­nibles sur Google Cloud.

Pour chaque voix, on peut choi­sir un Audio Profile qui permet d’op­ti­mi­ser le rendu en fonc­tion des condi­tions d’écoute : montre connec­tée, télé­phone portable, casque audio, petit haut-parleur, grand haut-parleur, chaîne HiFi, haut-parleur d’au­to­mo­bile, inter­ac­tive voice response (?). J’ai opté pour « télé­phone portable » sur ce site.

Positionnement du lecteur audio SPEAKER

Le thème utilisé sur le présent site impose quelques contraintes si l’on utilise un lecteur audio (player) posi­tionné dans le texte, comme c’est le cas avec celui de SPEAKER. Notamment, pour que l’image mise en exergue soit correc­te­ment posi­tion­née sur la plupart des articles, on ne doit pas dispo­ser le lecteur audio plus haut qu’un certain nombre de para­graphes. Par contre, le lecteur pour smart­phone doit être placé le plus haut possible, mais toujours après le deuxième paragraphe.

Des lecteurs « flot­tants » comme celui de Trinity Audio, ou « collants » (sticky) comme celui de MEKS, sont donc bien mieux adap­tés à la lecture sur smart­phone. Ce qui suit ne concerne que les lecteurs posi­tion­nés dans le texte.

Pour assu­rer un posi­tion­ne­ment distinct de deux lecteurs, il suffit d’uti­li­ser des classes CSS, par exemple :

.desktop {
	display: initial;
	}
.mobile {
	display: none;
	}

@media only screen and (hover: none) and (pointer: coarse) {
.desktop {
	display: none !important;
	}
.mobile {
	display: initial !important;
	}
}

Puis on inscrit chaque lecteur dans un « div » atta­ché à la classe corres­pon­dants, par exemple :

<div class="desktop">[@speaker]</div>

<div class="mobile">[@speaker]</div>

(Supprimer les caractères ‘@’)

Utilisation de wp-Typography

Cet excellent correc­teur de typo­gra­phie (voir télé­char­ge­ment) produit des codes qui affectent à plusieurs niveaux le fonc­tion­ne­ment de SPEAKER (version 4.0.13).

En premier lieu, l’af­fi­chage du lecteur : le correc­teur remplace les guille­mets droits par des guille­mets typo­gra­phiques, il ajoute des espaces insé­cables avant certains signes de ponc­tua­tion, et il insère des symboles invi­sibles de césure (soft hyphens) qui brouillent le code.

En ce qui concerne l’af­fi­chage des lecteurs, une solu­tion effi­cace consiste à exclure la classe CSS « mdp-speaker-wrapper » du trai­te­ment par wp-Typography. Pour cela, dans les réglages géné­raux de wp-Typography, inscrire « mdp-speaker-wrapper » dans le champ Ignorer les classes CSS.

D’autres problèmes liés à wp-Typography condi­tionnent la program­ma­tion des règles de réécri­ture — voir ci-dessous.

Suivi du processus

J’ai souvent été confronté à l’im­pres­sion désa­gréable que des règles de réécri­ture (RegEx repla­ce­ments) ne fonc­tion­naient pas, ou encore que la trans­crip­tion orale échouait pour une raison inconnue.

Il est possible de suivre globa­le­ment la proces­sus en se connec­tant sous FTP au réper­toire /wp-content/uploads/speaker/. Pendant la trans­for­ma­tion, on voit appa­raître les fichiers MP3 en prove­nance de Google Cloud, par exemple :

tmp-f6g4ssr3q-post-35807.mp3
tmp-qz9j23mnk-post-35807.mp3
etc.

pour un article ou une page dont l’iden­ti­fiant serait « 35807 ».

Si le proces­sus arrive à son terme, ces fichiers tempo­raires dispa­raissent et sont rempla­cés par un unique fichier : post-35807.mp3.

Ce qui est invi­sible, c’est la séquence de textes envoyés à Google Cloud ainsi que, en amont, les textes juste après leur trans­for­ma­tion par les règles de réécri­ture. J’ai donc ajouté des instruc­tions dans SpeakerCaster.php pour créer un fichier post-35807.html qui contient ces frag­ments de textes. Suivre cc lien pour affi­cher la trace de la trans­crip­tion vocale de cette page :
https://lebonheurestpossible.org/wp-content/uploads/speaker/post-35807.html

Une autre instruc­tion détruit tous les tmp-*.* avant le lance­ment d’une nouvelle conversion.

Cette trace m’a permis en premier lieu de véri­fier les réécri­tures. Par exemple, de m’aper­ce­voir que la règle (voir ci-dessus) corri­geant la pronon­cia­tion de « Calment » n’était jamais appli­quée. La raison est que le mot soumis aux règles de réécri­ture n’était pas « Calment » mais « Cal&shy ;ment », car il a été coupé par un soft hyphen. La règle était donc devenue :

/Cal.{0,5}ment/
calmant

Il faut bien connaître les expres­sions régu­lières pour comprendre que « .{0,5} » repré­sente une séquence arbi­traire de carac­tères de longueur 0 à 5, couvrant les deux cas : avec ou sans « &shy ; ».

Cette solu­tion est un très mauvais brico­lage, car la séquence « .{0,5} » peut conte­nir n’im­porte quoi. Je montre plus loin comment élimi­ner les soft hyphens une fois pour toutes.

De manière géné­rale, l’in­té­rêt du fichier post-*.html est de faire appa­raître le texte tel qu’il sera inter­prété par le conver­tis­seur text-to-speech.

Si le proces­sus s’ar­rête — ce qui est géné­ra­le­ment signalé par une énig­ma­tique « erreur 3 » — on peut voir à la fin de ce fichier quel frag­ment de texte a provo­qué cette erreur, et souvent la corriger.

Erreur 503

Le plugin émet une énig­ma­tique alerte « error 503 » après envi­ron une minute de trai­te­ment. Celle-ci appa­raît sur des textes rela­ti­ve­ment longs mais ne corres­pond à rien de signi­fi­ca­tif : le proces­sus conti­nue même si on ne clique pas le bouton « OK ». Je l’ai donc signa­lée comme un bug.

Time-out

Comme indi­qué dans ma note, il semble que la session d’échanges entre le site (via SPEAKER) et Google Cloud soit limi­tée à envi­ron 3 minutes. Pour cette raison, le proces­sus n’est pas achevé si les fichiers MP3 sont trop nombreux. J’ai demandé aux tech­ni­ciens que cet échec soit, au mini­mum, signalé à l’uti­li­sa­teur, et suggéré de lancer d’autres sessions jusqu’à la conver­sion inté­grale du texte.

Il arrive même que le plugin fusionne les fichiers tmp-*-post-*.mp3 alors que la liste est incom­plète, Google Cloud ayant aban­donné la partie. Dans ce cas, le fichier post-*.mp3 ne couvre pas la tota­lité du texte. On s’en aper­çoit en surveillant sous FTP le réper­toire /wp-content/uploads/speaker/, mais il serait utile que cette erreur soit rendue visible sur l’in­ter­face — il suffi­rait pour cela de détec­ter la présence de fichiers tmp-*-post-*.mp3.

Parfois, il suffit de relan­cer la conver­sion pour que le time-out ne se produise pas. Un facteur influant sur le résul­tat est donc certai­ne­ment la vitesse des connexions et la dispo­ni­bi­lité des serveurs.

➡ Actuellement, le time-out empêche la trans­crip­tion vocale d’ar­ticles parti­cu­liè­re­ment longs sur ce site.

Utilisation du SSML

C’est un vaste sujet. La docu­men­ta­tion de SPEAKER (voir page) est incom­plète, et celle décri­vant le SSML (voir page) couvre des cas qui ne sont pas pris en charge dans SPEAKER.

Prenons comme exemple l’in­ser­tion de pauses pour laquelle SPEAKER four­nit un opcode qui peut être placé (mais reste invi­sible) sur la page WordPress, par exemple :

[@speaker-break time="2s" strength="none"]
(Supprimer le caractère ‘@’)

Ce format opcode fonc­tionne, mais il ne peut pas être utilisé dans une règle de réécri­ture (RegEx repla­ce­ment). La raison est que SPEAKER inter­prète ses opcodes avant d’ap­pli­quer les règles. La docu­men­ta­tion ne four­nit pas l’ex­pres­sion, après inter­pré­ta­tion, qui est un pur tag SSML :

<break time="2s" strength="none"></break>

Il n’est pas utile de commen­ter ici le para­mètre « strength » qui agit sur le contour prosodique.

La règle géné­rale concer­nant SSML est donc que tout opcode utilisé par SPEAKER est trans­formé en une expres­sion de syntaxe SSML, que le TTS de Google Cloud est capable de trai­ter. Plutôt qu’un opcode, on peut donc entrer direc­te­ment cette expres­sion sur la page web, mais il faut en tout cas le faire chaque fois qu’on utilise une règle de réécriture.

Les pauses permettent de corri­ger le rythme de la phrase, mais aussi d’empêcher une liai­son mal-t‑à propos. Par exemple, cette règle inter­dira à Google Cloud de dire « un nari­cot » ou « les zari­cots » :

/(haricots?)/
<break time=".05s" strength="none"></break> $1

Les paren­thèses (en rouge) servent à captu­rer le mot, avec ou sans ‘s’, qui est repro­duit dans la variable « $1 ». La pause de 50 milli­se­condes insé­rée avant « hari­cot » est inau­dible, mais elle empêche le TTS de faire la liai­son. Il est possible qu’une voix Google Cloud bien entraî­née (à parler de hari­cots) ne fasse pas cette mauvaise liai­son, mais la règle apporte une précau­tion supplé­men­taire, qui s’avère néces­saire avec des mots inhabituels.

Une autre fonc­tion TTS très utile est le chan­ge­ment de voix et/ou de langue. Je l’ai auto­ma­ti­sée, sur ce site, pour chan­ger de voix à la lecture de cita­tions (voir ci-dessous). Un opcode de chan­ge­ment de voix est par exemple :

[@speaker-voice name="en-GB-Wavenet-A"] Hello! [/speaker-voice]
(Supprimer le caractère ‘@’)

Il se traduit ainsi en SSML :

<voice name="en-GB-Wavenet-A"> Hello! </voice>

C’est sous cette dernière forme qu’on l’uti­lise dans une règle de réécriture.

La fonc­tion « say-as » est très utile pour faire dire les dates en entier. Voici par exemple un opcode qui fera dire « deux février deux-mille vingt-trois » au lieu de « deux sur zéro deux sur deux-mille vingt-trois » :

[@speaker-say‑as interpret-as="date" format="ddmmyyyy" detail="1"] 2/02/2023 [/speaker-say‑as]
(Supprimer le caractère ‘@’)

Ce format accepte que les jours et les mois soient indi­qués par un seul chiffre. Il accepte d’autre part divers sépa­ra­teurs : « / », « – », etc.

On peut program­mer une règle pour que toute expres­sion ressem­blant à une date en fran­çais soit lue (dans la langue choi­sie) comme une date :

/([0-9]{1,2})\/([0-9]{1,2})\/([0-9]{4})\)\.?/
<say-as interpret-as="date" format="ddmmyyyy">$1/$2/$3</say-as>

Pour les novices des expres­sions régu­lières, « [0–9]{1,2} » repré­sente une suite de 1 ou 2 chiffres. Les paren­thèses (en rouge) sur la première ligne servent à captu­rer les expres­sions qui sont ensuite affec­tées aux variables $1, $2 et $3.

Une fonc­tion SSML qui n’est actuel­le­ment pas gérée par SPEAKER est la phoné­tique (selon l’al­pha­bet IPA). Par exemple, l’expression :

Le <phoneme alphabet="ipa" ph="ˈhændbʊk ɒv njuːˈtrɪʃᵊnᵊl ˈvæljuː ɒv fuːdz ɪn ˈkɒmən ˈjuːnɪts">Handbook of Nutritional Value of Foods in Common Units</phoneme>

est simple­ment trans­crite comme « Le Handbook of Nutritional Value of Foods in Common Units » qui est bien sûr mal prononcé par le TTS fran­co­phone. On peut ici contour­ner le problème en chan­geant de voix/langue :

Le <voice name="en-GB-Wavenet-A"> Handbook of Nutritional Value of Foods in Common Units </voice>

Cela sonne très chic, mais les chan­ge­ments de voix/langue peuvent poser d’autres problèmes, voir ci-dessous.

Programmation des règles de réécriture

Si vous n’êtes pas habitué·e à la syntaxe ésoté­rique (bien que parfai­te­ment logique) des expres­sions régu­lières, vous en serez devenu expert·e une fois achevé le bon réglage d’un TTS en français ! 😀

Dans l’in­ter­face de SPEAKER, les règles (RegEx repla­ce­ments) s’écrivent sur deux lignes. L’oubli ou l’ajout d’une ligne (même vide) fait échouer tota­le­ment le proces­sus, bien souvent sans que vous en soyez averti·e. Même désastre si une seule règle contient la moindre erreur de syntaxe… Il serait bien­venu de dispo­ser d’un véri­fi­ca­teur de syntaxe de l’en­semble des règles dans un script PHP séparé ou sur un service en ligne, when time permits !

Voici, pour commen­cer, une règle qui détecte le début du texte (le symbole « ^ ») afin d’in­sé­rer une phrase au début de la lecture :

/^/
Bonjour ! Cette transcription vocale a été réalisée automatiquement. Merci de m'en signaler les erreurs de prononciation ! <break time="1s" strength="none"></break>

Attention : ce sont seule­ment deux lignes. On recon­naît l’uti­li­sa­tion d’une pause de 1 seconde, en fin de phrase, pour la sépa­rer de la lecture propre­ment dite.

De nombreuses règles servent à lire une abré­via­tion, comme le ferait un lecteur bien éduqué. Par exemple, l’ex­pres­sion « et al. » devrait être lue « et collègues ». Voici la règle :

/([^A-Z^a-z])et\s+al\./
$1et collègues

On déclare sur la première ligne que « et » ne doit pas être précédé d’une autre lettre (« [^A‑Z^a‑z] ») et qu’il doit être suivi d’au moins une espace (« \s+ »). Le point de « al. » est repré­senté précédé d’un carac­tère d’échap­pe­ment : « \. ». Le carac­tère non-alphabétique capturé entre les paren­thèses (en rouge) est repro­duit par la variable $1.

Pour les infor­ma­ti­ciens : la règle qui précède est exécu­tée par SPEAKER en appe­lant la fonc­tion preg_replace() en PHP :

$text = preg_replace("/([^A-Z^a-z])et\s+al\./", "$1et collègues", $text);

Voici d’autres exemples de règles :

/([^A-Z^a-z])[Ee]\.g\.\s/
$1par exemple 

pour inter­pré­ter « e.g. » ou « E.g. » = exem­pli gratia. L’expression « [Ee] » recon­naît « E » ou « e ». Cette règle ne fonc­tionne pas si une espace est présente, comme dans « e. g. ».

/TLF[Ii]?/
dictionnaire « Trésor de la langue française »

/([^A-Z^a-z])M\.D\./
$1docteur en médecine

Ne pas oublier le « $1 » au début, qui a capturé le carac­tère précé­dant « M », quel qu’il soit…

/整体/u
terme japonais

Ici, on ne demande pas au TTS de lire le mot « seitai » en japo­nais, car il est déjà dit dans la phrase « … le seitai (整体)… », mais simple­ment de préci­ser que c’est un terme japo­nais. Noter l’op­tion « /u » qui veut dire que la cible doit être lue comme de l’Unicode. Il est prudent d’ajou­ter cette option « /u » à toutes les règles.

Et, pour­quoi pas, décli­ner les sigles fran­çais interminables :

/ANSES/
Agence nationale de sécurité sanitaire de l’alimentation de l’environnement et du travail

ou des abré­via­tions fréquentes dans les publi­ca­tions médicales :

/<span\sclass=\"caps\">RR<\/span>/
risk reysho 
/<span\sclass=\"caps\">OR<\/span>/
odd reysho 
/<span\sclass=\"caps\">IC<\/span>/
intervalle de confiance a

On doit écrire « reysho » pour pronon­cer « ratio » à peu près comme en anglais… Ou, si l’on préfère, chan­ger de langue :

/<span\sclass=\"caps\">RR<\/span>/
<voice name="en-GB-Wavenet-A">risk ratio</voice> 

On commence à voir ici que l’in­ter­pré­ta­tion, grâce aux règles de réécri­ture, peut s’ap­pro­cher autant que souhaité d’un lecteur humain.

Corriger le français

De nombreuses règles appa­raissent à l’usage (en écou­tant les trans­crip­tions vocales sur des pages entires), qui tiennent aux « trous dans la raquette » de l’ap­pren­tis­sage automatique.

Par exemple, si un mot ne figure pas dans le diction­naire fran­çais, et si par contre il existe en anglais, le robot le pronon­cera à l’an­glaise. C’est gênant pour certains mots qui ont migré de l’an­glais vers le fran­çais et dont on a adapté la pronon­cia­tion. Par exemple, « occur­rence », qui n’est pas correct en fran­çais, bien que fréquem­ment employé aujourd’­hui, est prononcé à l’an­glaise… Pour s’en prému­nir, il faut en modi­fier l’or­tho­graphe jusqu’à ce qu’une pronon­cia­tion correcte soit réali­sée. La solu­tion est simple :

/occurence/
occurance

De même :

/urgents?/u
ûr jean

À l’in­verse, le nom du jour­nal « The Lancet » est prononcé de manière incom­pré­hen­sible (si on ne bascule pas la langue vers l’an­glais). Une solu­tion est :

/The\sLancet/u
ze lent sept

On remarque ici qu’il faut toujours essayer de « donner à manger » des mots fran­çais pour qu’ils soient prononcé sans hési­ta­tion. Peu importe que le texte n’ait pas de sens : le TTS actuel n’ana­lyse pas du tout le sens du texte — contrai­re­ment aux excel­lents traduc­teurs automatiques.

Certains mots se prononcent diffé­rem­ment selon le contexte, que le TTS fran­çais ne sait pas toujours iden­ti­fier. C’est le cas de « fier » dont le ‘r’ ne doit pas être prononcé s’il s’agit d’un verbe à l’in­fi­ni­tif. La règle suivante permet d’y remédier :

/([mts]e\s+)fier(\s+[aà])/u
$1fié$2
/([y]\s+)fier([^\p{L}])/u
$1fié$2

Avec cette règle, le ‘r’ est prononcé ou inhibé correc­te­ment dans une expres­sion comme : « On ne peut se fier à lui, se fier au temps, ne pas s’y fier, un fier à bras, ce fier à bras. »

Syllabes oubliées ou déformées

Dans certains cas, heureu­se­ment rares, le TTS fran­co­phone esca­mote des syllabes ou même des mots très courts à la fin d’une unité de souffle. Par exemple, « migrantes » suivi d’une virgule sera prononcé « migrants ». Pour éviter cela, on a besoin de règles spéci­fiques, par exemple :

/ante(s?)([^a-z])/u
anthe$1$2

Noter que le $1 capture le « s » du pluriel éven­tuel, ce qui permet d’ef­fec­tuer la liai­son si nécessaire.

Un autre défaut constaté est l’es­ca­mo­tage (occa­sion­nel) de la dernière syllabe de mots tels que « nécrose », « cétose », etc. Il semble qu’il ait surtout lieu avec des mots d’au moins deux syllabes, ce qui exclut « chose ». La règle suivante permet d’y remédier :

/(\pL{3})ose([^\pL])/u
$1oze$2

La règle suivante empêche le TTS de pronon­cer à l’an­glaise le verbe « perfuse » :

/([^a-z])perfuse([^a-z])/u
$1pairfûse$2

Sigles

Dans sa version actuelle, le TTS fran­co­phone gère assez bien la pronon­cia­tion de sigles courants, somme « UNESCO » qui est prononcé « unèsko », ou « CIA » qui est épelé au lieu d’être prononcé « scia ». Mais l’au­to­mate prononce par exemple « ops » pour « OPS » au lieu de l’épe­ler. On a donc besoin, dans ce cas, de la règle :

/([^\p{L}])OPS([^\p{L}])/u
$1o p s$2

On voit ici appa­raître l’ex­pres­sion « \pL » (ou « \p{L} ») qui désigne n’im­porte quel carac­tère Unicode repré­sen­tant une lettre (majus­cule ou minus­cule). En effet, l’ex­pres­sion « [A‑Za‑z] » ne recon­naît pas des carac­tères comme le « é » de « nécrose ». L’expression « ^ \p{L} » désigne donc ici n’im­porte quel carac­tère autre qu’alphabétique.

Autre exemple de pronon­cia­tion à corri­ger : le sigle « CRISPR » que la machine a tendance à épeler.

/CRISPR/u
crisp r

Bien entendu, certaines règles devien­dront inutiles lorsque les auto­mates TTS auront amélioré leur entraî­ne­ment. Mais nous essuyons les plâtres !

Écriture inclusive

J’ai averti que les TTS ne savaient pas lire l’écri­ture inclu­sive. Toutefois, s’en tire pas trop mal si l’in­ter­pré­ta­tion se résume à suppri­mer le point qui figure dans un mot, et que j’écris systé­ma­ti­que­ment « · » (option-majuscule‑f sur un clavier Mac) :

/·/u
 

Attention : la deuxième ligne est vide ! Avec cette règle, le mot « intelligent·e·s » sera lu comme « intel­li­gentes ». Le fémi­nin l’emporte, qui s’en plaindrait ? 😀

Une forme plus ancienne d’écri­ture inclu­sive est l’usage de paren­thèses, par exemple dans l’ex­pres­sion « Tou(te)s les Français(es) ». Elle sera lue « Toutes ou tous les Françaises ou Français » en appli­quant la règle suivante :

/([\s\[>“])(\pL+?)\((\pL+?)\)(\pL*?)([\.,\?!:;\s<”\)\]])/u
$1$2$3 ou $1$3$4

Les paren­thèses (souli­gnées ici en rouge) servent à captu­rer les chaînes repro­duites dans $1, $2, $3, $4 et $5.

Noter par exemple l’ex­pres­sion « [\s\[>“] » captu­rée dans $1 : ce sont tous les carac­tères qui peuvent précé­der le premier mot. Il s’agit de l’es­pace, du crochet « [« , du signe « > » ou du guille­met anglais « “ ». Le signe « > » peut appa­raître à la suite d’un élément « <em> », « <strong> », etc. Cette liste n’in­clut pas le guille­met ouvrant fran­çais, car wp-Typography le conver­tit en ”&bsp ;”, donc suivi d’une espace.

Autre usage de parenthèses

La règle précé­dente ne permet pas de lire une expres­sion comme « se (re)mettre au travail ». Alors qu’on avait accordé la primauté au fémi­nin, donc la forme la plus longue, dans la règle précé­dente, il faut cette fois lire en second le contenu de la paren­thèse, ce qui donne « se mettre ou remettre au travail ». On ajoute donc cette règle :

/([\s\[>“])\((\pL+?)\)(\pL+?)([\.,\?!:;\s<”\)\]])/u
$1$3 ou $2$3$4

Conversions code HTML vers Unicode

Pour que les exemples précé­dents fonc­tionnent, il faut au préa­lable avoir converti le « ç » et d’autres carac­tères étran­gers à l’al­pha­bet anglais, à partir de leur code HTML :

/&ccedil;/u
ç

Même néces­sité pour toutes les autres lettres sujettes à un enco­dage HTML spécial :

/&agrave;/u
à
/&acirc;/u
â

etc.

/&ldquo;/u
“
/&rdquo;/u
”

etc.

Une fois ces conver­sions termi­nées, si l’on veut recon­naître toutes les lettres minus­cules du fran­çais, on pourra utili­ser l’ex­pres­sion « [a‑zàâçéèêëîïôûùüÿñæœ] ».

Signes non-alphabétiques

Des émoti­cônes figurent dans l’al­pha­bet Unicode au sens large… On peut écrire quelques règles en les utili­sant directement :

/⏱/u
 … image d'horloge —

Noter l’op­tion « /u » qui est ici obligatoire.

Mais cela ne fonc­tionne jamais avec certains carac­tères, comme par exemple le rond bleu « 🔵 ». Dans ce cas, il faudra aller cher­cher la valeur de ce carac­tère en déci­mal : 128309.

Puis on programme une règle avec cette valeur :

/&#128309;/u
… c'est un rond bleu …

Les règles (RegEx repla­ce­ments) sont appli­quées une seule fois de haut en bas. Ce qui permet d’af­fi­ner certaines inter­pré­ta­tions. Par exemple, on aime­rait que le sigle «  » (marque commer­ciale, codé « &trade ; ») ne soit pas lu quand il figure à la fin d’un mot, mais qu’il soit expli­cité dans tout autre contexte. Deux règles suffisent à cela :

/([a-z])&trade/u
$1
/&trade/u
 signe de marque commerciale 

Sur ce site, j’uti­lise un rond blanc pour marquer le début et la fin d’un extrait. Les règles suivantes le rendent expli­cite à la lecture :

/<p>\s*⚪️/u
 … Début d'extrait … 
/⚪️\s*<\/p>/u
 … Fin d'extrait … 

Ou, en utili­sant les codes HTML numériques :

/<p>\s*&#9898;&#65039;/u
 … Début d'extrait … 
/&#9898;&#65039;\s*<\/p>/u
 … Fin d'extrait … 

J’en viens à la règle très impor­tante qui permet d’ef­fa­cer tous les soft hyphens « &shy ; », à placer au sommet des RegEx repla­ce­ments :

/&shy;/u
 

(La deuxième ligne est vide.)

Où peut-on trou­ver les codes HTML numé­riques de ces carac­tères non-alphabétiques ? Tout simple­ment dans le fichier de trace fabri­qué par (mon patch de) SPEAKER !

Un visage mécon­tent « 😣 » y appa­raît par exemple comme « &#128547 ; » qui permet de le placer dans la règle :

/&#128547;/u
… (visage mécontent)… 

Si l’on utili­sait direc­te­ment le carac­tère « 😣 » dans cette règle, l’en­semble des réécri­tures se plan­te­rait, ainsi que la conver­sion TTS… Sans qu’on en soit averti ! 😣😣😣

Corrections de typographie

Sans correc­tion, une expres­sion comme « […] avec l’Agence euro­péenne du médi­ca­ment […] » n’est pas pronon­cée correc­te­ment car les italiques sont rempla­cés par des chevrons avec espaces, ce qui donne :

[…] avec l'« Agence européenne du médicament » […]

Dans ce cas, la liai­son entre « l’ » et « Agence » n’est pas pronon­cée, et on entend « elle agence »… Pour corri­ger ce défaut il suffit d’ajou­ter la règle :

/([A-Za-z])'&laquo;\s*/u
&laquo; $1'

ce qui donne :

[…] avec « l'Agence européenne du médicament » […]

Unités de mesure

Il est impor­tant, pour lire des textes scien­ti­fiques, d’énon­cer correc­te­ment les unités de mesure. Si le TTS fran­co­phone de Google Cloud traduit correc­te­ment « g/l » par « grammes par litre », il ne fonc­tionne pas avec toutes les combi­nai­sons d’uni­tés, comme par exemple « µg/dl » qui doit être lu « micro­grammes par déci­litre ». Le mieux est donc d’ins­tal­ler deux ensembles de règles, les premières pour les numé­ra­teurs et les secondes pour les déno­mi­na­teurs. En voici un extrait.

Règles de numérateurs :

/\s+g\//u
 gramme/
/\s+dg\//u
 décigramme/
/\s+cg\//u
 centigramme/

Noter qu’on a bien préservé le « / » qui va servir de contexte aux règles de dénominateurs :

/\/[Kk]g([\.,\?!:;\s<\)\]\/])/u
 par kilogramme$1
/\/g([\.,\?!:;\s<\)\]\/])/u
 par gramme$1
/\/m[Ll]([\.,\?!:;\s<\)\]\/])/u
 par millilitre$1
/\/c[Ll]([\.,\?!:;\s<\)\]\/])/u
 par centilitre$1
/\/d[Ll]([\.,\?!:;\s<\)\]\/])/u
 par décilitre$1

À noter, l’ex­pres­sion « [\.,\?!:;\s<\)\]\/] » qui repré­sente n’im­porte quel carac­tère pouvant appa­raître après une unité de mesure.

Pour le symbole du litre, on a admis ici que les deux abré­via­tions « l » et « L » sont accep­tables, d’où l’ex­pres­sion « [Ll] ».

Il faut aussi tenir compte des expo­sants, par exemple dans « 9.81 m/s2. Pour cela, la règle du déno­mi­na­teur sera :

/\/s<sup>2<\/sup>/u
 par seconde au carré

Meme chose pour les autres puissances.

Cette méthode fonc­tionne avec des unités plus complexes, par exemple pour dire « 15 mg/kg/h ».

De nombreux brico­lages avec les chiffres sont possibles. On souhaite par exemple que « 15h25 » soit lu « quinze heures vingt-cinq » plutôt que « quinze hache vingt-cinq », mais que « 17h00 » soit simple­ment lu « dix-sept heures » Les règles suivantes sont suffisantes :

/([0-9]{1,2})h00/u
$1 heure 
/([0-9]{1,2})h([0-9]{0,2})/u
$1 heure $2 

Liaisons

Actuellement (début 2023), les voix fran­çaises sot peu fiables au niveau des liai­sons. Plus préci­sé­ment, elles oublient des liai­sons qui seraient forte­ment recom­man­dées dans un style d’élo­cu­tion « acadé­mique »… Il est donc néces­saire de les programmer.

Le trai­te­ment de ces liai­sons oblige à passer par des variables inter­mé­diaires. J’utilise ZZ’, TT’, NN’ et PP’ pour marquer une liai­son, avec des règles finales qui les remplacent par des carac­tères fami­liers au TTS :

/ZZ'/u
z'
/NN'/u
n'
/PP'/u
p'
/TT'/u
t'

Par exemple, pour lire « les beaux arbres », la règle suivante a été appliquée :

/([eau]xz)\s+([aàeéèêiîouyh])/u
$1 ZZ'$2

ce qui donnera dans un premier temps « les beaux ZZ’arbres », puis en fin de trai­te­ment « les beaux z’arbres ».

Cet exemple n’est pas forcé­ment perti­nent, car la plupart des voix produisent déjà la liai­son correcte. Il faut éviter de créer des liai­sons là où elles auraient été créées auto­ma­ti­que­ment, car l’ajout de code (exemple « ils z’avaient ») altère parfois le profil proso­dique de la phrase, créant des accen­tua­tions peu réalistes.

La méthode est donc plus compli­quée, car les règles de liai­son sont contex­tuelles, et les excep­tions nombreuses. Pour les mettre au point, il faut écou­ter les versions orales d’à peu près toutes les pages et articles du site. Pour éviter une factu­ra­tion exces­sive de TTS, on peut rassem­bler les points liti­gieux dans un petit texte « bac à sable » sur lequel on véri­fie le bon fonc­tion­ne­ment de la trans­crip­tion orale. 

Par exemple, les expres­sions « nous z’avons », « vous z’avez » ou « les z’ans » ont un très mauvais rendu en TTS. Il faut donc ajou­ter des règles comme :

/ZZ'avez/u
zavés
/ZZ'avons/u
zavons
/ZZ'an/u
zan

Le « s » de « zavés » est indis­pen­sable car le TTS pronon­ce­rait « z’avé » comme « z a vé é accent aigu » ! Il a tendance à épeler les mots courts qui ne sont pas dans son diction­naire — ou plutôt, le diction­naire invi­sible qu’il a construit dans ses « neurones ». Le plus simple est peut-être de s’ins­pi­rer du langage SMS

Les apos­trophes produites par les règles de liai­sons peuvent aussi défor­mer de manière insa­tis­fai­sante le contour proso­dique. C’est pour­quoi « zavons » est d’un meilleur rendu que « z’avons ».

Il faut forcer la liai­son dans des expres­sions comme « prêt-à-penser » ou « prêt‑à porter » qui sont mal lues par le TTS. Cette règle corrige l’erreur :

/prêt\-à/u
prêt ta

On a aussi besoin de règles d’ef­fa­ce­ment. Par exemple, pour éviter d’en­tendre « des z’hau­teurs » ou « des z’hau­bans », on ajoute la règle :

/ZZ'hau/u
hau

On peut enfin, par sécu­rité, effa­cer toutes les liai­sons produites acci­den­tel­le­ment par d’autres règles mal configurées :

/TT'([bcdfgjklmnpqrstvwxz])/u
$1
/NN'([bcdfgjklmnpqrstvwxz])/u
$1
/ZZ'([bcdfgjklmnpqrstvwxz])/u
$1
/PP'([bcdfgjklmnpqrstvwxz])/u
$1
/TT'([\d\.,\?!:;\s<\)\]])/u
$1
/NN'([\d\.,\?!:;\s<\)\]])/u
$1
/ZZ'([\d\.,\?!:;\s<\)\]])/u
$1
/PP'([\d\.,\?!:;\s<\)\]])/u
$1

Le symbole « \d » repré­sente ici un chiffre. Il est équi­valent à « [0–9] » que j’ai tendance à préfé­rer car il est plus explicite.

Les liai­sons contraintes par des règles peuvent entraî­ner la mauvaise pronon­cia­tion de mots courts dont la pronon­cia­tion est alors, soit emprun­tée à l’an­glais, soit simple­ment épelée. Par exemple, la conver­sion de « vous avez eu » en « vous z’avez z’eu » ne donne pas un son correct. Le résul­tat est obtenu avec « vous zavés z’û ». On a appli­qué ici la séquence de règles (plus géné­rales) suivantes :

/([eau]xz)\s+([aàeéèêiîouyh])/u (appliquée 2 fois)
$1 ZZ'$2
/ZZ'avez/u (appliquée 1 fois)
zavés
/([\s'])eue?s?([\.,\?!:;\s<\)\]])/u (appliquée 1 fois)
$1û$2
/ZZ'/u (appliquée 2 fois)
z'

On devine ici que l’ordre des règles (RegEx repla­ce­ments) est critique dans cette gram­maire formelle. On le corrige en écou­tant de nombreux exemples…

Titres et légendes

Pour annon­cer les titres, on peut utili­ser des règles du style :

/<h1[^>]*>/u
<break time="1s" strength="none"></break>Titre de niveau 1… …
/<h2[^>]*>/u
<break time="1s" strength="none"></break>Titre de niveau 2… …
/<\/h1>/u
… … <break time="1s" strength="none"></break>
/<\/h2>/u
… … <break time="1s" strength="none"></break>

La ques­tion des légendes de figures est plus déli­cate. Il est utile de lire les légendes et de les décla­rer comme légendes, sauf si elles sont vides. D’autre part, une légende comme « Source : … » n’est pas utile en lecture. Les règles que j’uti­lise, et que les experts de RegEx compren­dront sans diffi­culté, sont les suivantes : 

/<img\s[^\/]*?\/>/u

/<img\s.*?>/u

/<iframe\s[^<]+?<\/iframe>/u

/<span\sclass=\"caption\-text\">(.*?)<\/span>/u
$1
/<figure\s[^>]*?>(.*?)<\/figure>/u
$1
/<figcaption[^>]*?>\s*Source.+?<\/figcaption>/u

/<figcaption[^>]*?>\s*?<\/figcaption>/u

/<figcaption[^>]*?>(.+?)<\/figcaption>/u
… Image avec légende « $1 » (fin de légende)… <p>…</p>

La séquence « <p>…</p> » sur la dernière règle est un autre moyen de ména­ger une courte pause sans affec­ter le contour prosodique.

Ces règles sont compa­tibles, sur ce site, avec l’uti­li­sa­tion des plugins wp-Typography pour les textes et Optimole pour les images. Pour les adap­ter à d’autres confi­gu­ra­tions, il faut analy­ser avec soin le rendu de la page, en mode « code » sur le navi­ga­teur, qui est plus détaillé que le mode « code » dans l’édi­teur de WordPress, car il intègre des anno­ta­tions typographiques.

Changement de voix ou de langue

Pour la traduc­tion de phrases ou d’ex­pres­sions en d’autres langues, je ne recom­mande pas d’in­sé­rer chaque fois l’ex­pres­sion SSML complète. Non seule­ment c’est fasti­dieux, avec un risque d’er­reur, mais par ailleurs on peut souhai­ter par la suite choi­sir une voix nouvelle pour la langue concernée.

Le plus simple est de décla­rer la langue (et le genre) dans une classe CSS. Par exemple :

Le <em class="male-en">Handbook of Nutritional Value of Foods in Common Units</em>

si l’ex­pres­sion est en italiques, ou simple­ment, sans les italiques :

Le <span class="male-en">Handbook of Nutritional Value of Foods in Common Units</span>

On utilise ensuite les règles suivantes, par exemple pour l’an­glais, l’al­le­mand, l’ita­lien et l’es­pa­gnol au mascu­lin et au fémi­nin. Ces règles modi­fient la voix/langue tout en ajus­tant la vitesse d’élo­cu­tion pour compen­ser la modi­fi­ca­tion globale program­mée dans la langue prin­ci­pale. Pour le fran­çais, on a choisi d’aug­men­ter de 20 % la vitesse. Par consé­quent, pour les langues étran­gères on la dimi­nue de 20 %, ce qui donne :

/<[^\s]+?\s+class=\"male\-en\"\s*>(.+?)<\/[^>]+?>/u
<voice name="en-GB-News-J"><prosody rate="80%">$1</prosody></voice>
/<[^\s]+?\s+class=\"female\-en\"\s*>(.+?)<\/[^>]+?>/u
<voice name="en-GB-News-I"><prosody rate="80%">$1</prosody></voice>
/<[^\s]+?\s+class=\"male\-de\"\s*>(.+?)<\/[^>]+?>/u
<voice name="de-DE-Wavenet-B"><prosody rate="80%">$1</prosody></voice>
/<[^\s]+?\s+class=\"female\-de\"\s*>(.+?)<\/[^>]+?>/u
<voice name="de-DE-Wavenet-C"><prosody rate="80%">$1</prosody></voice>
/<[^\s]+?\s+class=\"male\-it\"\s*>(.+?)<\/[^>]+?>/u
<voice name="it-IT-Standard-D"><prosody rate="80%">$1</prosody></voice>
/<[^\s]+?\s+class=\"female\-it"\s*>(.+?)<\/[^>]+?>/u
<voice name="it-IT-Standard-B"><prosody rate="80%">$1</prosody></voice>
/<[^\s]+?\s+class=\"male\-es\"\s*>(.+?)<\/[^>]+?>/u
<voice name="es-ES-Neural2-F"><prosody rate="80%">$1</prosody></voice>
/<[^\s]+?\s+class=\"female\-es"\s*>(.+?)<\/[^>]+?>/u
<voice name="es-ES-Neural2-E"><prosody rate="80%">$1</prosody></voice>

Les chan­ge­ments de vitesse d’élo­cu­tion n’ont pas encore été appli­qués à tous les articles du site.

Un avan­tage de dispo­ser de deux règles uniques (mâle-femelle) pour chaque langue est qu’il suffira de modi­fier une seule de ces règles si l’on choi­sit une autre voix, sans avoir à corri­ger les textes des pages ou articles concernés.

Attention : cette méthode ne fonc­tionne que si la classe (« male-en » etc.) est attri­buée à l’élé­ment HTML le plus proche du texte. Concrètement, elle ne fonc­tion­ne­rait pas ici :

Le <em class="male-en"><strong>Handbook of Nutritional Value of Foods in Common Units</strong></em>

Il faudrait corri­ger le texte ainsi :

Le <em><strong class="male-en">Handbook of Nutritional Value of Foods in Common Units</strong></em>

Un incon­vé­nient de la version actuelle de SPEAKER (4.0.13) est que le même ensemble de règles s’ap­plique à toutes les langues utili­sées sur une page ou un article, de sorte que des liai­sons dange­reuses pour­raient être impo­sées aux textes en langues étran­gères… On peut partiel­le­ment les neutra­li­ser, je ne l’ex­pli­que­rai pas ici. J’ai signalé ce problème dans mon rapport, et l’équipe tech­nique a annoncé qu’elle prévoyait dans une prochaine version la gestion de règles spéci­fiques aux voix/langues.

Citations

J’ai programmé des règles pour que les conte­nus de cita­tions soient lus avec une voix diffé­rente de celle du texte principal :

/<blockquote[^>]*>/u
<voice name="fr-FR-Wavenet-C"> … Début de citation…
/<\/blockquote>/u
</voice> Fin de citation… 

Ça fonc­tionne tant que SPEAKER ne trouve pas un élément « </p> » dans la cita­tion. En effet, il peut utili­ser cet élément pour frag­men­ter le texte (dans la limite de 4500 carac­tères), auquel cas les frag­ments suivants reviennent à la voix/langue par défaut.

La solu­tion la plus simple est de suppri­mer les « </p><p> » dans les cita­tions, ce qui n’est appa­rem­ment pas faisable auto­ma­ti­que­ment, mais qui impose de rempla­cer les marques de para­graphes par de simples sauts de ligne dans chaque citation.

Regardons pour cela la page WordPress en mode « code ». Au lieu d’écrire :

<!-- wp:quote {"extUtilities":[]} -->
<blockquote class="wp-block-quote"><!-- wp:paragraph -->
<p>Blah blah 1</p>
<!-- /wp:paragraph -->
<!-- wp:paragraph -->
<p>Blah blah 2</p>
<!-- /wp:paragraph --></blockquote>
<!-- /wp:quote -->

on écrira :

<!-- wp:quote {"extUtilities":[]} -->
<blockquote class="wp-block-quote"><!-- wp:paragraph -->
<p>Blah blah 1<br><br>Blah blah 2</p>
<!-- /wp:paragraph --></blockquote>
<!-- /wp:quote -->

Cette solu­tion fonc­tionne bien, sauf qu’elle peut produire des frag­ments de texte supé­rieurs aux 4500 carac­tères auto­ri­sés par Google Cloud. Ma version patchée de SPEAKER aver­tit l’uti­li­sa­teur : à lui/elle de s’ar­ran­ger pour scin­der la cita­tion en plusieurs morceaux si elle est trop longue.

Un autre défaut de cette méthode de chan­ge­ment de voix dans les cita­tions appa­raît lors­qu’une expres­sion en langue étran­gère figure dans une cita­tion. Le chan­ge­ment de voix/langue se fera correc­te­ment pour l’énon­cer, mais ensuite le système revien­dra à la voix d’ori­gine, au lieu de celle prévue pour les cita­tions. Ce problème est résolu en ajou­tant une expres­sion (invi­sible) qui force le retour à la voix de cita­tion, par exemple :

Le <em class="female-en"><strong>Handbook of Nutritional Value of Foods in Common Units</strong></em><span class="citation"></span>

La correc­tion de voix sera assu­rée par la règle :

/<span\s+class=\"citation\">[^<]*?<\/span>/u
<voice name="fr-FR-Wavenet-C">

On note ici qu’il n’est pas gênant de ne pas avoir d’élé­ment « </voice> » à la fin d’un frag­ment de texte. SPEAKER se débar­rasse en fait des éléments « <voice> » en les rempla­çant par des para­mètres trans­mis à Google Cloud avec chaque frag­ment de texte.

Conclusion

Tot ce qui précède s’ap­plique à l’uti­li­sa­tion de voix fran­co­phones Google Cloud au stade de déve­lop­pe­ment de début 2023. Il est raison­nable d’es­pé­rer que des voix plus entraî­nées verront le jour, qui permet­tront de se passer d’un grand nombre de règles — notam­ment pour les liai­sons en français.

Recommander