La plus grande partie du délai d’une traduction en direct est une attente : celle du flux, du mot suivant, de la phrase. La seule part que vous contrôlez est le mode de latence : moins de délai, ou moins de révisions.
Un auditeur qui lit une traduction en direct voit chaque ligne apparaître quelques secondes après que l’orateur l’a prononcée. Cet écart n’est pas un délai unique mais plusieurs, qui s’additionnent le long d’une chaîne, et la plupart relèvent d’une forme d’attente. Savoir quelle attente correspond à quel délai rend le choix du mode de latence évident, et indique à un développeur qui crée un lecteur ce qu’il doit afficher, et à quel moment.
Un repère utile avant les chiffres : un interprète simultané humain accuse généralement deux à quatre secondes de retard sur l’orateur. Les interprètes appellent cet écart le ear-voice span. Pour les langues à verbe final, ils n’attendent pas le verbe, ils l’anticipent, ou découpent la phrase en morceaux pouvant tenir seuls. Une ou deux secondes de délai ne sont pas un défaut du logiciel ; c’est à peu près ce que fait un très bon interprète humain.
Chaque transcription en direct sur VocalStack passe par les mêmes étapes, dans le même ordre, et chacune attend la précédente.
Le texte dans la langue d’origine parvient au lecteur presque au moment où il est prononcé. La traduction suit une seconde ou deux plus tard, et la phrase parlée arrive après sa traduction, ce qui explique pourquoi un extrait vocal arrive toujours en dernier. Le premier effet visible de la chaîne, cependant, se produit bien avant toute voix : le texte lui-même bouge.
La première chose que l’on remarque dans une transcription en direct, c’est que les derniers mots bougent. Une expression apparaît, change, puis se fixe. C’est l’étape du brouillon à l’œuvre, et elle existe pour une raison qui vaut pour tout moteur de reconnaissance vocale.
Un moteur de reconnaissance fixe un mot en regardant ce qui vient après lui. « Ver », « verre » et « vert » sont identiques à l’oral, et seul le mot suivant permet de trancher. Tant qu’il n’y a pas d’audio à droite d’un mot, son orthographe est une supposition. Les mots les plus récents d’une transcription en direct sont donc toujours les moins sûrs. Un brouillon n’est rien d’autre que cette supposition, montrée tôt plutôt que cachée.
Chaque brouillon remplace entièrement la fin en direct : les mots entendus depuis la dernière validation, qui changent encore. Une validation est définitive. Elle ne change jamais, elle porte des horodatages mot par mot, et les validations sont numérotées sans trou afin qu’un lecteur puisse voir s’il en a manqué une.
Pour un développeur, c’est la seule règle qu’impose l’API temps réel : afficher chaque segment validé, puis le dernier brouillon qui le suit, et vider le brouillon à l’arrivée d’une validation. Ajouter les brouillons au lieu de les remplacer produit un texte dupliqué et scintillant ; la validation consomme simplement la fin. Le tutoriel WebSocket construit un lecteur précisément autour de ce principe.
Pour l’hôte, faire bouger le texte est le prix d’un faible délai. Montrer des mots avant que la phrase soit terminée est ce qui donne à la transcription son caractère vivant. La traduction, en revanche, ne peut pas se permettre ce procédé : un mot peut être deviné à partir d’une demi-phrase, mais une traduction, elle, ne le peut pas.
L’ordre des mots explique pourquoi la traduction ne peut pas suivre le rythme du brouillon. En allemand, le verbe peut se trouver en fin de proposition, et en japonais le verbe vient toujours en dernier. Tout traducteur a besoin de la proposition entière pour la rendre fidèlement. Traduire mot à mot livrerait à l’auditeur des fragments qu’il devrait reconstituer une fois la proposition close. Les interprètes attendent le verbe allemand depuis bien avant que les logiciels s’y essaient.
VocalStack traduit donc des phrases, et non des segments. Les phrases sont activées par défaut ; dans ce cas, le serveur assemble les validations en une phrase et traduit la phrase entière. Tant que la phrase est ouverte, sa traduction est provisoire ; une fois la phrase fermée, la traduction est définitive. Le lecteur conserve une entrée par phrase et la remplace au fil des mises à jour.
La parole attend encore davantage. Seule une phrase fermée est prononcée, car une phrase encore en évolution serait resynthétisée à chaque révision. Une longue phrase est lue par morceaux, afin que le premier puisse être joué pendant que les suivants sont produits.
Avec les phrases désactivées, chaque validation reçoit en revanche sa propre trame de traduction. Ce mode n’attend rien, mais des phrases entières se lisent bien mieux.
Toutes ces attentes sont mesurées à partir du moment où l’audio atteint VocalStack. Pour beaucoup de diffusions, l’audio était déjà en retard à son arrivée.
Lorsque la source est un flux plutôt qu’un micro, l’audio a déjà du retard avant toute transcription. Il est en retard sur le direct, c’est-à-dire sur le moment le plus récent que le flux a publié.
Un flux audio HTTP classique, celui que publient la plupart des radios sur Internet, accuse généralement une à trois secondes de retard. Le serveur conserve une mémoire tampon de rafale : quelques secondes d’audio récent, envoyées d’un coup pour qu’un nouveau lecteur puisse démarrer sans à-coups. Tous les auditeurs, VocalStack compris, se connectent avec ce décalage. HLS est pire : ses listes de lecture font démarrer un client trois segments en arrière du direct, soit en pratique plusieurs secondes à une demi-minute selon la durée des segments. Le DASH standard se situe en général dans la même fourchette que HLS ; seule sa variante à faible latence descend nettement en dessous. Le flux « en direct » d’une station peut être en direct au même titre qu’une lettre peut être d’actualité.
Ces chiffres sont approximatifs, et ils concernent le flux, non la transcription : aucun réglage côté VocalStack ne peut les rattraper. Si ces secondes comptent pour un événement, faites entrer l’audio depuis un micro ou un encodeur plutôt que depuis un flux public. Le délai du flux est fixé avant que VocalStack n’entende le moindre mot ; le mode de latence est la seule chose sur laquelle vous pouvez réellement agir.
Le mode de latence ne fait qu’une chose : il règle l’équilibre entre délai et précision. Ce réglage se trouve sous Advanced lors de la création d’une transcription en direct, et dans l’onglet Speed pendant son exécution. Là, la puce affiche AUTO, SPEED ou ACCURACY (Fast apparaît sous le nom SPEED). Via l’API, session.update le modifie en cours de flux.
Le compromis est celui qu’annoncent les noms. Fast fait sortir le texte plus tôt, mais le révise davantage ; Accuracy prend un peu plus de temps et révise moins. Un public assis qui lit des sous-titres traduits remarque rarement une seconde de plus, mais il remarque des mots qui n’arrêtent pas de changer. Accuracy est donc souvent le réglage le plus confortable, tant que le graphique du délai reste plat. Auto ne cache pas ce qu’il fait : une ligne qu’il a accélérée pour combler un retard porte un badge FAST MODE dans la transcription de l’hôte, avec une note indiquant que la précision peut y être moindre.
Quel que soit le mode, la transcription doit être prête avant le premier mot, et cette préparation est le seul délai que la chaîne ne paie qu’une fois.
Sur certaines formules, une transcription en direct met quelques secondes à démarrer. La durée dépend de la formule : la ligne Start-up speed de la page Tarifs va d’un démarrage à froid de 15 secondes au plus en Paiement à l’usage, jusqu’à un système toujours actif sur Enterprise.
Via l’API, l’attente se traduit par des trames session.loading pendant le démarrage, puis un session.ready ; le client n’envoie l’audio qu’après celui-ci. Un auditeur qui ouvre le lien entre-temps voit « Live. The first line appears in a moment. » Une fois la transcription lancée, ce délai est derrière vous, et il ne reste plus qu’à savoir quelle part du délai restant vous portez.
Pendant qu’une transcription en direct tourne, l’onglet Speed de l’hôte montre le total de tout cela : l’écart actuel entre l’orateur et le texte, avec la puce du mode à côté, et un graphique de cet écart sur tout l’enregistrement, avec sa moyenne et son pic. Dans la transcription elle-même, une ligne arrivée tardivement chez les auditeurs porte un badge indiquant le nombre de secondes écoulées entre le moment où elle a été prononcée et celui où elle est arrivée.
Un graphique bas et plat signifie que le mode convient à l’audio. Un graphique qui grimpe signifie que la chaîne prend du retard. En mode Accuracy, c’est peut-être le moment de passer en Auto, qui sacrifie un peu de précision contre de la vitesse jusqu’à ce que l’écart se résorbe.
Les développeurs disposent à la place d’un seul chiffre. Lorsqu’une session temps réel se termine, session.done contient stats.realtimeFactor, c’est-à-dire la durée d’audio transcrite divisée par le temps passé à la transcrire. Attention à une convention : dans la littérature sur la reconnaissance vocale, le facteur temps réel désigne en général l’inverse, le temps de traitement sur la durée de l’audio, où plus la valeur est basse, mieux c’est. VocalStack le donne dans l’autre sens : ici, plus la valeur est haute, mieux c’est. Une session en direct se situe donc près de 1, et une valeur inférieure à 1 signifie que l’audio est arrivé plus vite que la chaîne ne pouvait le transcrire.
Rien de tout cela n’est mystérieux. Certaines secondes appartiennent au flux, d’autres à un mot qui attend le suivant, d’autres à la phrase dont une traduction a besoin, et le reste au mode de latence que vous avez choisi. La référence de l’API détaille trame par trame, et la démonstration sur la page d’accueil montre la chaîne en fonctionnement.
