Lecture automatique TTS

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


Le contenu sonore du lecteur audio ci-dessous a été généré par SPEAKER (voir plus bas).

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 à visi­bi­lité 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, voire 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, tant que celle-ci n’est pas trop artificielle…

De plus en plus fréquem­ment, des auteurs de blogs anglo­phones 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 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.

Grâce à cette tech­no­lo­gie rendue possible par l’ar­ri­vée de plate­formes infor­ma­tiques puis­santes (en rapi­dité et en mémoire), et surtout 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 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 de lecture
  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 nette­ment moins bon.

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, ou une pronon­cia­tion incom­pré­hen­sible, si l’on s’obs­tine à faire de trop longues phrases. Utiliser une ponc­tua­tion géné­reuse, et 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 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 (pattern repla­ce­ments, 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 un 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.

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 locales (textuelles et sonores).

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://​lebon​heu​rest​pos​sible​.org/​w​p​-​c​o​n​t​e​n​t​/​u​p​l​o​a​d​s​/​s​p​e​a​k​e​r​/​p​o​s​t​-​3​5​8​0​7​.​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 est collé au bas de la fenêtre, en lieu et place du lecteur stan­dard. Dans ce cas, les lecteurs SPEAKER peuvent être suppri­més. Voir par exemple un article de ce site

Noter que le lecteur MEKS auto­rise des sauts en avant et en arrière de 15 secondes, comme on l’avait vu sur celui de Trinity Audio. Ses seuls défauts actuels sont la hauteur exces­sive et le nombre réduit de para­mètres pour 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 (repla­ce­ment patterns) 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() sous PHP, ou encore pour gérer la redi­rec­tion de connexions dans les fichiers htac­cess de 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 des 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. Un 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 groupées ».

➡ Attention toute­fois au risque d’ex­plo­sion de la facture Google Cloud !

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 sur cette page.

Une équipe très sympa

J’ai entre­tenu 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 (version 3.4.2) 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.

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, faute d’un tuto­riel détaillé.

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.

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, afin 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 devrait être placé le plus haut possible, mais toujours après le deuxième paragraphe.

Des lecteurs « flot­tant » comme celui de Trinity Audio, ou « collant » (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 à inscrire 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 3.4.2).

En premier lieu, l’af­fi­chage du lecteur : le correc­teur remplace certains guille­mets droits par des guille­mets typo­gra­phiques, avec inser­tion de symboles invi­sibles de césure (soft hyphens) qui brouillent le code, ce qui peut empê­cher un affi­chage correct du lecteur.

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.

Attention aux titres !

Le plugin, dans sa version 1.4.2, récu­père le titre de la page pour l’in­sé­rer dans le code de l’élé­ment « audio ». Le problème est que certains titres (comme celui de la présente page) contiennent des balises HTML :

Lecture automatique <span class="caps">TTS</span>

Ce titre s’in­sère mal dans le code :

aria-label="Audio of Lecture automatique etc."

Soit on évite les sigles, italiques et tout autre forma­tage dans le titre, soit on modi­fie le plugin pour rempla­cer la variable $title par :

preg_replace("/<\/?[^>]*?>/u",'',$title)

C’est ce que j’avais fait (patch n°5) dans ma version corri­gée de /wp-content/plugins/speaker/src/Merkulove/Speaker/SpeakerCaster.php. À ma demande, l’équipe tech­nique de SPEAKER a placé un filtre sur les noms de fichiers, qui devrait faire dispa­raître ce problème.

Suivi du processus

J’ai été souvent confronté à l’im­pres­sion désa­gréable que des règles de réécri­ture (repla­ce­ment patterns) 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

Dans la version 1.4.2, 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.

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 (repla­ce­ment pattern). 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 (repla­ce­ment patterns) s’écrivent sur deux lignes. L’oubli ou l’ajout d’une ligne (même vide) fait échouer tota­le­ment le proces­sus, et bien souvent vous n’en serez pas 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.

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 ici que le $1 capture le « s » du pluriel éven­tuel, ce qui permet d’ef­fec­tuer la liai­son si nécessaire.

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

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

É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. Dans cette règle, on voit 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 « Français(es) ».

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­ment 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 (repla­ce­ment patterns) 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 repla­ce­ment patterns :

/&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 ! 😣😣😣

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

Le trai­te­ment des liai­sons en fran­çais 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 ».

La méthode est en fait plus compli­quée, car ces règles 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 en fait 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.

Titres et légendes

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

/<h1>/u
<p>… …</p>Titre de niveau 1… …
/<h2>/u
<p>… …</p>Titre de niveau 2… …
/<\/h1>/u
… …
/<\/h2>/u
… …

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éminin :

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

Un avan­tage est qu’il suffira de modi­fier une seule de ces règles si l’on choi­sit une autre voix, sans modi­fier 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 (3.4.3) 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="male-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 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