Convertir LRC en JSON
Ou collez le texte d'un sous-titre
Options
Utilisée quand la source n'a pas d'heures de fin (texte brut, LRC). La chronologie de la sortie est ici générée plutôt que convertie : c'est donc ce nombre que vous obtiendrez.
Ce que cette conversion change
1 élément perdu ou à décider
- Minutage
les heures de fin des blocs — la source ne les enregistre pas, celles de la sortie seront donc générées plutôt que converties
Ce rapport de pertes vient de la matrice de capacités de ces deux formats, pas du fichier particulier que vous avez chargé. Un fichier précis peut perdre davantage s'il utilise des fonctionnalités que le format autorise mais que la matrice ne modélise pas.
Cette page convertit un fichier LRC en JSON structuré : un objet de version 1, un titre facultatif repris de [ti:], puis un tableau cues dont chaque entrée porte start, end et lines. Les temps sont des millisecondes entières, jamais des chaînes horaires, ce qui évite toute ambiguïté de séparateur décimal.
Le LRC ne contient que des débuts : la fin de chaque bloc est déduite de l’horodatage suivant et la dernière ligne reçoit 2 000 ms. Le champ lines contient une chaîne par ligne affichée, donc un bloc bilingue partageant [00:15.30] devient une seule entrée à deux lignes plutôt que deux entrées au même instant.
Les métadonnées autres que le titre, comme [ar:], [length:] ou [offset:], ne sont pas inventées dans la sortie. Le JSON peut décrire des styles et des positions, mais le LRC n’en contient aucun : aucune balise n’est donc générée. Tout le traitement reste local et accepte les lots.
Exemples
Un fichier LRC typique, converti en JSON
Entrée
[ti:Sample Song]
[ar:Some Artist]
[length:00:41.00]
[offset:+250]
[00:12.00]First line of the song.
[00:15.30]Second line.
[00:15.30]Second line, translated.
[00:18.00]
[00:21.50]Final line.Sortie
{
"version": 1,
"title": "Sample Song",
"cues": [
{
"start": 12000,
"end": 15300,
"lines": [
"First line of the song."
]
},
{
"start": 15300,
"end": 18000,
"lines": [
"Second line.",
"Second line, translated."
]
},
{
"start": 18000,
"end": 21500,
"lines": [
""
]
},
{
"start": 21500,
"end": 23500,
"lines": [
"Final line."
]
}
]
}
Le titre [ti:] devient le champ title ; chaque bloc expose start et end en millisecondes et les lignes restent séparées dans le tableau lines.
La même conversion sur une entrée abîmée
Entrée
[ar:Some Artist]
[0:05.5]Leading zero omitted, one decimal.
[00:07]Second with no centiseconds.
[00:03.00]Out of order.
[00:07.00][00:09.00]Repeated chorus line.
[00:12.00]Sortie
{
"version": 1,
"cues": [
{
"start": 3000,
"end": 5500,
"lines": [
"Out of order."
]
},
{
"start": 5500,
"end": 7000,
"lines": [
"Leading zero omitted, one decimal."
]
},
{
"start": 7000,
"end": 9000,
"lines": [
"Second with no centiseconds.",
"Repeated chorus line."
]
},
{
"start": 9000,
"end": 12000,
"lines": [
"Repeated chorus line."
]
},
{
"start": 12000,
"end": 14000,
"lines": [
""
]
}
]
}
Les horodatages incomplets et le BOM sont acceptés, l’ordre est rétabli et le bloc sans texte sort avec une ligne vide dans lines.
Questions fréquentes
À quoi servent les champs start et end du JSON ?
start reprend l’horodatage LRC converti en millisecondes, par exemple [00:12.00] devient 12000. end est calculé à partir du début suivant ; pour la dernière ligne, faute de successeur, il vaut start plus 2 000 ms. Les deux valeurs sont des entiers, pas des chaînes.
Le titre de la chanson est-il présent dans le JSON ?
Oui, [ti:Sample Song] devient title: "Sample Song" à la racine de l’objet. L’artiste [ar:] et la durée [length:] n’ont pas de clé correspondante dans ce schéma ; ils ne sont donc pas recopiés sous une forme détournée.
Une ligne LRC sans texte produit-elle un bloc JSON ?
Oui, avec start, end et lines contenant une chaîne vide. Le bloc reste dans le tableau pour que les temps restent contigus et que le nombre de blocs corresponde au fichier d’origine ; c’est au consommateur du JSON de décider d’ignorer une ligne vide.
Les heures du JSON sont-elles arrondies ?
Non. Le LRC exprime les centièmes de seconde, et un centième vaut exactement 10 ms : [00:15.30] devient 15300 sans arrondi ni perte. Un horodatage qui n’aurait pas cette résolution ne peut pas venir d’un LRC valide.
Le JSON peut-il conserver un style ou une position ?
Le schéma en est capable, mais le LRC n’en transporte ni l’un ni l’autre : son contenu se limite à des horodatages et du texte. Aucun tag ni champ de position n’apparaît donc dans la sortie, et le rapport de pertes ne mentionne que la fin de bloc déduite.
Le tag [offset:] du LRC est-il appliqué dans le JSON ?
Non, il est conservé comme information du fichier source mais n’est pas ajouté aux temps. Un offset de +250 ms est un ordre de lecture destiné au lecteur, pas une correction à écrire dans les données ; les valeurs du JSON correspondent donc aux horodatages littéraux du LRC.