LRCX file format specification

[porg]

Sample File

Dynamite - BTS.lrcx as discussed and linked from here

Excerpt

[00:09.017]Shoes on get up in the morn'
[00:09.017][tr:zh-Hans]早起穿上鞋
[00:09.017][tt]<0,0><202,6><913,9><1066,13><1219,16><1421,19><1573,23><1776,28>
[00:10.793]Cup of milk let's rock and roll
[00:10.793][tr:zh-Hans]醇香牛奶搭配激情摇滚乐
[00:10.793][tt]<0,0><153,4><305,7><509,12><661,18><863,23><1116,27><1626,31>

Please provide a specification

• So far I have only assumptions from my observation.
• I'd appreciate an official documentation of your LRCX file format.
  • LRC is seemingly a subset of LRCX.
  • LRCX has a few extensions beyond LRC.
• Also which other data types (e.g. time axis) from what other source formats (e.g. Kugou KRC format as mentioned in Chinese in 有些歌词无法逐字滚动（主要是英文歌），请问是否可以手动添加逐字滚动 ddddxxx/LyricsX#521 (comment)) you transform into LRCX.

Assumptions

1. After the timestamp at the line start, the language as sung/audible in the song is there verbatim, without any other markup.
2. A translation line has the same timestamp as its corresponding line above.

• The translation line starts with [tr: followed by a language code, e.g. zh-Hans, and the tag getting closed with ].
• What conventions are used for the language code?
  • 2 letter, 3 letter?
  • Also regional versions and dialects?
  • Only the English code, e.g. "ger" as in "German"? Or also the sometimes available native language abbreviation? e.g. "deu" as in "Deutsch", being the word “German” in German itself.

3. The precision timecode line: Same timecode as the corresponding line above, followed by [tt], and then followed by numbers in angled brackets <n,n>.
   • The TT line has one more timecode than the corresponding original language line has words.
   • So the timecodes are:
     • word-1-start
     • word-1-end which is equivalent to word-2-start
     • word-2-end which is equivalent to word-3-start
     • ...
     • word-x-end
   • The word timecodes are relative to the line timestamp start.
     • Line-timecode + word-timecode = Absolute timecode of a word within the song.
       • The renderer anyhow works line by line, so to always start with 0 within the available time to render the line, makes absolutely sense for efficiency, and as another benefit also improves human readability and understanding.
     • Even more easy to read and grasp would probably be the format
       • word-1-duration word-2-duration word-3-duration ... word-X-duration
       • e.g. 709.10 862.15 1065.18 1218.21
       • The current word-1-start at <0,0> is somehow redundant.
         • Only advantage of start/stop times as opposed to durations would be the possibility to start the word delayed.
         • While there's music only and yet no voice, a line can potentially already be moved into place, but the highlighting of the first word then only starts when the voice starts.
         • I don't know whether any existing formats make use of this. Not that I know.
         • Hence it's probably best to just drop that redundant 0.
         • And go with durations, which are far easier to grasp for a human, as in word1 takes 220ms, word2 187ms, etc.
         • Much easier to edit manually. Just edit the one duration which is not optimal and you are done!
         • Whereas if you edit one start or end time then you need to shift all other start/stop times after it! That more less makes you dependent on a computer solution. Whereas durations only are easily fixable by hand without any extra software. Only the total of all word durations must not exceed the total duration of the line. So you may need to Substract time from one later word. But not necessarily from all later words as is the case with start/stop times.
         • And for the computation/performance nowadays it does almost not matter whether to provide start/stop times or consecutive durations.