Vidéo et sous-titres · Boîte à outils de sous-titres
Comment un navigateur analyse un fichier SRT : blocs, index, codes temporels et texte
· Comment ça marche
sous-titres srt formats de fichiers
SRT semble trivial jusqu'à ce que vous rencontriez de vrais fichiers. Cet article explique comment un analyseur divise les blocs, lit les index et les timecodes, gère le texte multiligne et récupère les blocs mal formés que contiennent les fichiers du monde réel.
Le fichier "a l'air bien", mais la moitié des indices manquent : comment un format d'apparence indulgente cache des attentes strictes
SRT n'a pas de corps de spécification, pas d'enregistrement MIME et pas de validateur livré avec les joueurs. Ce qui existe à la place est une forme sur laquelle la plupart des logiciels s'accordent : un nombre, une ligne de timecode, une ou plusieurs lignes de texte, puis une ligne vierge. Étant donné que la forme est conventionnelle plutôt que spécifiée, deux fichiers peuvent tous deux sembler corrects dans un éditeur de texte alors qu'un seul d'entre eux se charge, et l'échec est généralement silencieux. Un joueur qui ne peut pas lire une réplique a tendance à la sauter plutôt que de la signaler, donc un fichier avec un bloc cassé est joué avec un espace au lieu d'une erreur.
Un analyseur a donc deux tâches qui tirent dans des directions opposées. Il doit accepter les variations que contiennent les fichiers réels, car les fichiers sont produits par des services de transcription, d’édition manuelle et de convertisseurs de format qui font chacun des hypothèses différentes. Il doit également refuser les lectures qui donneraient un signal au mauvais moment, car un horodatage silencieusement erroné est pire qu'un échec signalé.
Division en blocs - lignes vides comme séparateurs et problèmes avec les espaces parasites et CRLF
Le fractionnement se produit sur les lignes vides, pas sur les numéros d'index. L'analyseur normalise d'abord les fins de ligne, en remplaçant à la fois la paire CRLF et un seul CR par une seule nouvelle ligne, car un fichier créé sous Windows et édité sous Unix peut contenir les deux. Il se divise ensuite en une série de deux nouvelles lignes ou plus, coupe chaque bloc résultant et supprime les blocs vides. Cet ordre est important : le fractionnement avant la normalisation laisserait un retour chariot parasite à la fin d'une ligne de timecode, et le timecode ne correspondrait alors pas.
Une marque d'ordre d'octet est supprimée avant tout cela. Une nomenclature UTF-8 au début d'un fichier correspond à trois octets qu'un analyseur naïf voit comme faisant partie du premier numéro d'index, ce qui est suffisant pour rendre le premier signal illisible pendant que chaque signal ultérieur est analysé. Les espaces de fin sur une ligne de séparation par ailleurs vide sont gérés par le trim, de sorte qu'un fichier dont les lignes vides contiennent un espace est toujours divisé correctement.
La ligne d'index : pourquoi les nombres sont souvent erronés, dupliqués ou manquants et pourquoi les analyseurs ne devraient pas leur faire confiance
Le numéro d'index est lu puis ignoré. Les fichiers réels numérotent à partir de zéro, redémarrez la numérotation après une fusion, dupliquez un numéro après une modification manuelle ou omettez entièrement la ligne lorsqu'un convertisseur écrit le fichier. Faire confiance à ces nombres signifie hériter de chacune de ces erreurs, donc l'analyseur attribue à la place son propre numéro séquentiel, en comptant les indices qu'il a construits avec succès jusqu'à présent.
Ce choix explique également pourquoi l'analyseur n'exige jamais que la ligne d'index soit présente. Il localise la ligne du timecode en recherchant dans le bloc la première ligne contenant la flèche, plutôt que de supposer que le timecode est la deuxième ligne. Un bloc sans ligne d'index est analysé normalement, et un bloc avec deux lignes parasites avant le timecode est toujours analysé, car la position n'est pas ce qui identifie le timecode.
La ligne du timecode — HH:MM:SS,mmm --> HH:MM:SS,mmm, les variations tolérées et celles qui cassent les joueurs
La ligne de timecode est comparée à une seule expression régulière et les tolérances qu'elle contient sont délibérées. Les heures sont facultatives, car WebVTT permet une lecture à deux champs et les convertisseurs l'émettent. Une virgule ou un point est accepté comme séparateur en millisecondes, quel que soit le format que le fichier prétend être, car les séparateurs mixtes sont suffisamment courants pour que leur rejet entraîne l'échec de plus de bons fichiers que de mauvais. Les chiffres fractionnaires sont complétés à droite, de sorte qu'un signal se terminant par un seul chiffre est lu en centaines de millisecondes plutôt qu'en unités.
Deux lectures sont refusées. Un champ de minutes ou de secondes supérieur à cinquante-neuf est rejeté plutôt que retenu, car quatre-vingt-dix secondes ne constituent pas une lecture d'horloge et indiquent généralement un fichier corrompu ou mal converti ; le normaliser silencieusement déplacerait le signal. Une ligne dont le début ou la fin ne parvient pas à être analysée produit un problème enregistré nommant le texte incriminé et la forme attendue, et le bloc est ignoré plutôt que deviné.
Lignes de texte – indices multilignes, balises de formatage et où se termine réellement un bloc
Tout ce qui se trouve après la ligne de timecode est le texte de repère, réuni par des nouvelles lignes. Il n'y a pas de limite de lignes ni de tentative de redistribution, donc une réplique à trois lignes survit sous la forme de trois lignes. C'est la raison pour laquelle la ligne vide est porteuse : c'est la seule chose qui indique à l'analyseur que le texte est terminé, c'est pourquoi une mémoire dont le propre texte contient une ligne vide sera lue comme deux blocs et la seconde moitié sera signalée comme n'ayant pas de timecode.
Les paramètres de repère sont séparés de l'horodatage de fin par une série de deux espaces ou plus. WebVTT permet aux directives de positionnement telles que l'alignement et le placement de ligne de suivre l'heure de fin sur la même ligne, de sorte que l'analyseur les divise avant que l'horodatage ne soit analysé et les conserve à côté du signal. Un seul espace n'est pas un séparateur, ce qui empêche une ligne de timecode simplement désordonnée de perdre son heure de fin.
Exemple concret : analyse d'un fichier de cinq signaux avec deux erreurs délibérées – ce qu'un analyseur robuste récupère et ce qu'il signale
Prenez un fichier de cinq blocs dans lequel le bloc trois a vu sa ligne de code temporel endommagée pour lire 00:01:75,000 --> 00:01:78,000, et le bloc quatre a entièrement perdu sa ligne de code temporel lors d'un copier-coller. L'analyseur lit normalement les blocs un et deux et les numérote un et deux. Le bloc trois correspond à la forme d'un timecode mais comporte un champ de secondes de soixante-quinze, il est donc refusé et enregistré comme un mauvais horodatage nommant la ligne qu'il n'a pas pu lire.
Le bloc quatre ne contient aucune flèche, il est donc enregistré comme n'ayant pas d'horodatage, citant les quarante premiers caractères du bloc afin que la ligne puisse être trouvée dans le fichier d'origine. Bloquez cinq analyses et devient le signal trois, et non le signal cinq, car la numérotation compte les signaux réussis. Le résultat est trois indices utilisables et deux plaintes spécifiques et localisées, plutôt qu'une exception sur le premier défaut et aucune information sur le second.
Ce que cela ne couvre pas – ASS/SSA style, codes de positionnement et texte sans sous-titres transférés dans SRT
Ceci décrit SRT et les parties de WebVTT qui partagent sa forme de repère. Il ne couvre pas ASS et SSA, qui comportent un en-tête de script, des définitions de style et des références de style par événement, et qui ne peuvent pas être lus en les divisant sur des lignes vides. Le timing du karaoké, les commandes de dessin et les balises de remplacement en ligne utilisées par ces formats sont en dehors de ce que modélise un analyseur de repères et de timecode.
Il ne répare pas non plus le texte. Une transcription collée dans un fichier sans timecode produit une liste de blocs sans horodatage, qui est rapportée avec précision mais ne peut pas être transformée en sous-titres sans informations de synchronisation qui ne sont pas présentes. Les erreurs d'encodage sont une autre préoccupation : un fichier décodé avec le mauvais jeu de caractères est analysé en signaux parfaitement valides dont le texte est erroné, et aucune vérification structurelle ne le détectera.
À retenir : analysez avec indulgence, écrivez strictement - comment la boîte à outils de sous-titres lit un SRT désordonné et en réécrit un propre
La règle de travail est d'analyser avec indulgence et d'écrire strictement. À l'arrivée, acceptez les heures facultatives, soit les séparateurs, les lignes d'index manquantes, les fins de ligne mixtes et une marque d'ordre des octets de début, et enregistrez chaque erreur en tant que problème localisé au lieu de lancer le premier, afin qu'un fichier puisse être corrigé en un seul passage. À la sortie, émettez une forme canonique.
C'est ce que fait le Subtitle Toolkit lors de la conversion. Les signaux sont renumérotés de un et maintenus contigus, les horodatages sont réémis avec une virgule pour SRT et un point pour WebVTT, et le fichier qui revient est la forme attendue par les joueurs, quelle que soit l'irrégularité de l'entrée. Collez un fichier rejeté par un lecteur dans le convertisseur et lisez d'abord les problèmes signalés ; ils nomment le signal et citent la ligne, ce qui suffit généralement à trouver la faute dans l'original.