Thoughts on the restrictive formatting.

[AverageHoarder]

As someone who has downloaded thousands of synced lyrics files from many different sources and synced hundreds manually over the last two decades, I'm a bit astounded how restrictive the formatting in lrcget is.

Example lyrics how they end up when I sync them manually:

[ar:Shirley Bassey]
[al:Moonraker (Original Motion Picture Soundtrack)]
[ti:Main Title - Moonraker]
[length:03:07]
[00:21.806]Where are you
[00:26.736]Why do you hide
[00:31.831]Where is that moonlight trail that leads to your side
[00:39.206]Just like the moonraker goes
[00:45.279]in search of his dream of gold
[00:50.898]I search for love
[00:55.346]for someone to have and hold

[01:00.622]I've seen your smile
[01:04.945]in a thousand dreams
[01:10.404]felt your touch
[01:14.901]and it always seems
[01:19.919]You love me
[01:25.481]You love me
[01:39.390]
[01:41.185]Where are you
[01:46.251]When will we meet
[01:51.303]Take my unfinished life and make it complete
[01:58.509]Just like the moonraker knows
[02:04.381]his dream will come true someday
[02:10.061]I know that you
[02:14.202]are only a kiss away

[02:19.054]I've seen your smile
[02:23.630]in a thousand dreams
[02:29.256]felt your touch
[02:33.595]and it always seems
[02:38.559]You love me
[02:43.968]You love me
[02:55.695]

Timestamp formatting

[mm:ss:xx] text is only one of many ways to format synced lyrics.

When syncing a track in MusicBee for example, the format is:
[mm:ss:xxx]text which I prefer since it has the same character length, no unnecessary space between the timestamp and the text and a higher precision (which admittedly does not matter a lot for lyrics).

When syncing a track in SubtitleEdit you can choose between:
[mm:ss:xx] text and [mm:ss:xxx]text as formats when saving lyrics.

Lyric Show Panel v3 in foobar 2000 for example also formats lyrics as
[mm:ss:xx]text with no space separating timestamp and text.

OpenLyricsPanel in foobar 2000 also formats them as:
[mm:ss:xx]text with no space.

I'd like to contribute to lrcget by sharing the lyrics I've synced over the years (which often do not exist online at all) but I have no desire to reformat them to a format I deem inferior.

Empty lines

Which brings me to the next point: Why are empty lines within the lyrics deemed "Unnecessary"?
Personally I like to keep them to retain the verse structure of the lyrics and all players that I use (MusicBee, lms, Symfonium) support properly displaying them by skipping over them to the next timestamp.

Multi-line lyrics:

A more rare case but multi-line lyrics are quite useful when there are two singers at the same time and also to display the original language as well as a translation at the same time, below each other.

Example for 2 singers:

[0:43.848]Tell her to make me a cambric shirt:
(On the side of a hill in the deep forest green,)
[0:51.288]Parsley, sage, rosemary and thyme;
(Tracing a sparrow on snow-crested ground,)
[1:00.048]Without no seams nor needlework,
(Blankets and bedclothes, a child of the mountains)
[1:07.788]Then she'll be a true love of mine.
(Sleeps unaware of the clarion call)

Example for original + translation:

[0:00.000]Haritsumeta yumi no
The stretching bow
[0:06.696]Furueru tsuru yo
Of its trembling string 
[0:11.988]Tsuki no hikari ni zawameku
Disturbed in the moonlight
[0:18.276]Omae no kokoro
Is your heart

These are also supported by MusicBee, lms and Symfonium and quite useful in the rare cases when they apply.

I like your tool but currently I only use it to download lyrics since the editor issues (having tags at the start for example or empty lines leads to the wrong line being highlighted, which is annoying) and the publishing format restrictions prevent me from contributing.

[tranxuanthang]

First and foremost, I want to assure you that I am fully open to listening and making necessary changes about lyrics formatting. There is a lot to consider, so I will address your points one by one:

Timestamp formatting

In my opinion, it does not matter much whether there is or is not space, and no format is superior or inferior than the other. It is similar to developers war about whether to use tabs or spaces for source code indentation, which will just be a never ending discussion. Instead, I think what we should care about is consistency, and there are 2 things to consider:

• Enforcing a space after timestamp can help prevent mixing 2 formats (with and without a space) within the same lyrics.
• Ensuring consistency with the majority of the lyrics already present in lrclib.net database (which are mostly formatted as having a space after timestamp).

For these reasons, I still prefer to keep a space after timestamp. However, I do think there is still room to improve. For example, we could implement a feature to automatically reformat and fix the lyrics according to LRCGET opinionated convention. There is already an open issue for this (#32).

Empty lines and Multi-line lyrics

I will take some time to think more about these and do some more tests when I have some spare time and provide an update later.

[tranxuanthang]

Timestamp precision

For the precision (timestamp format [mm:ss.xx] versus [mm:ss.xxx]), you might be a bit disappointed to find out that the polling rate of track progress is a bit imprecise currently (40ms + IPC overhead), but there is a lot to improve on this in the future:

lrcget/src-tauri/src/main.rs

Line 716 in 9f04d9b

let mut interval = tokio::time::interval(std::time::Duration::from_millis(40));

Majority of lyrics records on lrclib.net are using the [mm:ss.xx] format, but as far as I know there is not a strict validation rule for this, so you are free to use either format!

[AverageHoarder]

Thanks for getting back to me on this!

Timestamp formatting

I only meant that from a logical standpoint, a format that stores more information in the same number of characters is inherently "better". For lyrics it's pretty inconsequential if you have 10ms or 1ms precision and it's not like they take up a lot of space either way.

I also fully agree on consistency, but that should not mean forcing everyone into one format.
Feel free to check out the logic I used in lyrict, especially for --standardize. That allows to either only fix broken timestamps (leaving inconsistencies of [mm:ss], [mm:ss.xx], [mm:ss.xxx] etc.) or enforcing either [mm:ss.xx] or [mm:ss.xxx] for all timestamps to let the user choose which format they prefer while also enforcing a consistent result. Since I prefer not having a space separating the timestamp and the text, it also ensures that there isn't one (which could be easily changed to leave exactly one in line 781).
If you want to try it out, you can enforce a format for all lyrics recursively by running
lyrict.py -m tag_external -p --standardize force.xx
or
lyrict.py -m tag_external -p --standardize force.xxx
This also tags them with info retrieved from linked mp3s/flacs, which you can ignore.

Imho a good solution for consistency would be to let the user choose a format for saving lyrics locally and automatically "fix" them when uploading to lrclib.
So [01:02.03] Some line could be saved locally as [01:02.03]Some line
while [01:02.03]Some line would be turned into [01:02.03] Some line when uploading to lrclib.
I still think allowing ms precision would be an improvement tho as no information is lost when adding/removing a space, but reducing [mm:ss.xxx] to [mm:ss.xx] does lose information.

Timestamp precision

As I did not sync the lyrics in lrcget, the polling rate precision issue does not apply to me, but it's good to know.
When I tried to publish the example lyrics from my initial post, the publish button was greyed out and presented me with these:

If you want to improve the syncing functionality in lrcget, I'd take inspiration from SubtitleEdit, which I currently find the best way to sync.
Thanks to the wavebar that it extracts via ffmpeg, syncing is quicker and more precise than in any other program I've used over the years.

Seeing where the singing starts speeds things up immensely and the advanced features (like applying a global offset to all lines or all lines after the current line) make syncing a breeze.