SRT contre VTT : quel format de sous-titres choisir ?

Réponse courte : utilisez WebVTT si la vidéo se joue dans un navigateur, et SubRip si elle se joue ailleurs. L’élément <track> de HTML5 n’accepte que le VTT, et presque tous les autres lecteurs sur terre acceptent le SRT.

Les deux formats sont des proches cousins — VTT a été conçu comme une évolution native du web à partir de SRT, dont il a gardé la forme — si bien que la conversion est triviale et le choix rarement irréversible. Voici ce qui diffère réellement, et quand la différence compte.

SubRip (.srt)#

Le format de sous-titres le plus ancien et le plus largement supporté, et à peu près aussi simple qu’un format de fichier peut l’être : une liste numérotée de cues, chacune avec une heure de début, une heure de fin, et une ou plusieurs lignes de texte.

1
00:00:00,580 --> 00:00:04,270
In the last video, we showed
that if you had a line, which

2
00:00:04,270 --> 00:00:09,020
we'll call a directrix--
we draw the directrix.

• Numéros de séquence, à partir de 1
• Codes temporels au format HH:MM:SS,mmm --> HH:MM:SS,mmm — notez la virgule avant les millisecondes
• Texte sur les lignes suivantes, qui peut être réparti sur plusieurs lignes
• Une ligne vide entre chaque entrée

Il n’existe aucune spécification officielle. SRT est défini par ce que SubRip a écrit et ce que chaque lecteur depuis a accepté, ce qui explique que les variations tolérées — balises <i> et <b> en ligne, coordonnées de positionnement occasionnelles, numéros de séquence manquants — varient selon le lecteur.

WebVTT (.vtt)#

Un format W3C conçu pour la vidéo HTML5. Même principe de liste de cues, avec un en-tête et une véritable spécification derrière.

WEBVTT

STYLE
::cue {
  background-color: transparent;
  color: white;
}

NOTE Keep this under two lines for the mobile player

intro
00:00:00.000 --> 00:00:04.000 position:50% align:center
Welcome to this video tutorial

00:00:04.000 --> 00:00:08.500 line:90%
In this section, we'll explore
the key concepts you need to know

• Une première ligne WEBVTT obligatoire
• Codes temporels avec un point avant les millisecondes
• Identifiants de cue optionnels (intro ci-dessus) à la place des numéros de séquence, ou en plus
• Réglages de cue après le code temporel pour la position, l’alignement et le placement de ligne
• Blocs STYLE portant du CSS qui s’applique via le pseudo-élément ::cue
• Blocs REGION définissant des zones défilantes, utilisées pour les sous-titres à défilement (roll-up)
• Blocs NOTE — des commentaires qui ne s’affichent jamais

Les différences qui comptent#

Deux lignes portent l’essentiel du poids pratique.

Encodage. SRT n’a pas d’encodage déclaré, si bien que les fichiers arrivent en Windows-1252, Latin-1, Shift-JIS ou UTF-8 sans aucun moyen de le savoir autrement qu’en devinant. C’est l’origine du charabia que vous avez déjà vu dans des sous-titres téléchargés. WebVTT impose l’UTF-8, et cette seule contrainte élimine toute une catégorie de problèmes d’un pipeline de localisation.

Commentaires. Les blocs NOTE sont le seul endroit, dans l’un ou l’autre format, où laisser une instruction pour un traducteur — c’est un nom de marque, ne pas traduire, ou rester sous 40 caractères, ça déborde sur le tiers inférieur. SRT n’a nulle part où mettre ça, si bien que la consigne finit dans un e-mail, puis nulle part.

Convertir du SRT vers du VTT#

Deux modifications mécaniques :

1. Ajouter WEBVTT suivi d’une ligne vide au début.
2. Remplacer la virgule avant les millisecondes par un point, uniquement sur les lignes de code temporel.

Les numéros de séquence peuvent rester — VTT les lit comme des identifiants de cue.

# Prepend the header, then fix the timecode separator
{ printf 'WEBVTT\n\n'; sed -E 's/([0-9]{2}:[0-9]{2}:[0-9]{2}),([0-9]{3})/\1.\2/g' input.srt; } > output.vtt

Faire l’inverse fait perdre davantage, car tout ce que VTT ajoute doit être abandonné : styles, régions, réglages de cue et blocs NOTE n’ont aucun équivalent en SRT. Ne convertissez du VTT vers du SRT que lorsqu’un lecteur vous y oblige, et gardez le VTT comme source de vérité.

Ce qui se passe mal en pratique#

Aucun des deux formats n’a une grande surface, si bien que les modes d’échec sont peu nombreux et se répètent.

Marqueurs d’ordre des octets (BOM). Un SRT enregistré depuis le Bloc-notes ou exporté par certains outils Windows commence par un BOM UTF-8. De nombreux lecteurs traitent le BOM comme faisant partie du numéro de séquence de la première cue, et la cue 1 ne s’affiche alors jamais, en silence. En VTT, ce même BOM casse la vérification de l’en-tête WEBVTT et le fichier entier est rejeté.

Cues qui se chevauchent ou sont dans le désordre. Les deux formats supposent que les cues sont dans l’ordre chronologique croissant et, sur la plupart des lecteurs, ne se chevauchent pas. Les outils d’édition qui permettent de glisser des cues produiront volontiers un fichier où la cue 12 commence avant que la cue 11 ne se termine. Les lecteurs ne s’accordent pas sur quoi faire — certains affichent les deux, certains en abandonnent une, certains arrêtent complètement de rendre le fichier.

Fins de ligne. Le séparateur d’entrées de SRT est une ligne vide, si bien qu’un fichier mêlant des fins de ligne \r\n et \n peut produire une « ligne vide » qui n’en est pas une. C’est le symptôme classique d’un fichier passé par un éditeur Windows puis par un pipeline Unix.

La flèche -->. Ce sont exactement deux traits d’union et un signe supérieur, avec une espace de chaque côté. Un éditeur au style « guillemets intelligents » qui convertit le double trait d’union en tiret cadratin produit un fichier qu’aucun parseur ne lira, et le dégât est invisible dans une police à espacement proportionnel.

Chiffres du code temporel. SRT veut des heures à deux chiffres (00:01:02,500) ; VTT permet d’omettre entièrement l’heure (01:02.500). Un convertisseur qui suppose l’une des conventions en entrée alors que le fichier utilise l’autre produira des cues décalées d’une heure.

La plupart de ces cas valent la peine d’être détectés par une étape de parsing en CI plutôt qu’en relecture, car chacun d’entre eux a l’air correct à la lecture humaine du fichier.

Que choisir#

Choisissez WebVTT si la vidéo se joue dans un navigateur (c’est la seule option), que vous avez besoin de sous-titres positionnés ailleurs qu’au centre-bas par défaut, que vous voulez un contrôle CSS sur l’apparence, que vous livrez des chapitres ou des cues de métadonnées, ou que vous voulez transporter des instructions pour le traducteur directement dans le fichier.

Choisissez SubRip si vous ciblez des lecteurs matériels, des lecteurs de bureau plus anciens, ou des plateformes qui n’acceptent que des envois SRT ; si vous avez besoin de la compatibilité la plus large possible avec le moins de réflexion possible ; ou si les sous-titres sont un artefact d’échange entre outils plutôt qu’un format de livraison.

Ne choisissez ni l’un ni l’autre si vous livrez à la diffusion ou à une grande plateforme de streaming. Ce monde tourne sur TTML/DFXP, qui est basé sur XML et porte les métadonnées de style et de timing que ces workflows exigent.

En pratique, de nombreuses équipes conservent un master SRT parce que c’est le plus simple à éditer et à relire, et génèrent du VTT au moment du build pour le lecteur web. C’est un pipeline raisonnable, tant que le sens du flux reste à sens unique.

Traduire l’un ou l’autre#

Le texte est brut, non échappé et non structuré dans les deux formats, ce qui les rend faciles à traduire et faciles à casser. Trois points de vigilance :

Les timings ne bougent pas. Une cue traduite doit rentrer dans la fenêtre de temps d’origine. L’allemand et le finnois sont généralement 20 à 30 % plus longs que l’anglais ; le traducteur doit compresser plutôt que traduire littéralement, et doit le savoir dès le départ. C’est un problème de briefing, pas d’outillage.

Les retours à la ligne sont du contenu. Une cue de deux lignes qui en devient trois débordera de la zone de sécurité sur certains lecteurs. L’endroit où tombe le retour à la ligne affecte aussi la lisibilité — couper à une frontière de syntagme se lit bien mieux que couper à la limite de largeur.

La vitesse de lecture est une contrainte. Environ 15 à 20 caractères par seconde est le plafond de confort habituel pour un spectateur adulte. Une cue affichée deux secondes a de la place pour environ 35 caractères, quoi que le traducteur préférerait dire.

WebTranslateIt lit et écrit les deux formats, n’exposant comme segments traduisibles que le texte des sous-titres, tandis que les codes temporels, identifiants de cue, styles et régions font l’aller-retour intacts. Les blocs NOTE de VTT sont transmis comme des commentaires de développeur, si bien qu’une note écrite pour le traducteur lui parvient dans l’éditeur au lieu de se perdre dans le fichier. Côté SRT, le compteur de caractères et les limites de caractères sont l’outil pratique pour la contrainte de vitesse de lecture : définissez une limite par segment et l’éditeur la fait respecter pendant que le traducteur tape.