.lrc style guide and submission voting system

[samyarvahid]

In terms of formatting generally, I think it would be a benefit to everyone to have clear guidelines that people can refer to on how to write .lrcs. I was looking earlier today on the site for documentation, but I only found the api spec. Only while reading through issues did I learn about the MXM guidelines being de facto LRCLIB guidelines too.

I'd be happy to contribute some time to make a simple writeup detailing the expected format for LRCLIB .lrcs, but I think we should also take the time to discuss how strictly we want to adhere to MXM spec, if there are alternatives, etc. This not to mention other formats like elrc. Furthermore, there has been discussion of romanization #39, where MXM tells us to stick to the original script. However, there is no mention of stuff like furigana, which someone in that issue thread mentioned. Personally, I think furigana is unnecessary, but MXM offers no guidance on it. One potential solution is a fallback rendering of HTML Ruby text, where the ruby text is put into parenthesis next to the base text:

WWW (World Wide Web)

Generally, I would say furigana generates too much clutter in a plain text lyric file, no matter the implementation, and it's best to save it for the software that actually renders the lyrics with some postprocessing with linguistic Part-of-Speech analysers like mecab, that can disambiguate the characters in question. Plus, beyond writing in native script, adding parenthetical non-content goes against MXM guidelines anyway.

The last thing I'll say about style is that I think the topic warrants some discussion from the LRCLIB community before we write our own style guide.

On to my second point, I think we are starting to see that as this project grows in reach, there are more cases of low-quality submissions with no real way for the community to self-correct, and more broadly no resources on how to format correctly. I think a possible approach to pursue long-term for a robust and healthy database would be a voting system, perhaps tied to an account, a la musicbrainz, etc. This would be a significant investment in development time and project scope that I can understand being undesired and impossible for just the project maintainer alone.

[SloppyPuppy]

adding accounts could discourage participation, but the current proof of work for submitting could be similarly ported for a voting system, it discourages botting and greifing, but encourages anonymous submission and participation, perhaps accounts are in order, but it shouldn't be complicated which requires maintaining additional architecture, simple private public keypairs part of the client side webapp, reputation system based on voted submissions. Dunno the project can go in many directions and that includes a distributed network. I believe we haven't seen stuff like you propose implemented because it creates a huge burden on maintainers, they are kind enough to run a public instance. this requires smart design and a lot of effort.

[wave-dash]

Official furigana is fairly common in Japanese lyrics, there's a lot of existing solutions you could copy. Here's an excerpt from Mizuki Nana's ETERNAL BLAZE, taken from Uta-net, which closely matches the official release:

遥か天空(そら)響いている　祈りは奇跡に

黒天‐真夜中‐の蒼に溶けて流れてく涙の粒
迷いなく包み込む温もりに出逢った
真っ白な雪のようにどこまでも素直なコトバ
鉄の羽根纏った　僕を動かしてく

傷つくたびに　優しくなれる
君のその笑顔だけ守り抜きたい
願いはひとつ

時空(とき)を越え刻まれた悲しみの記憶
まっすぐに受け止める君は光の女神(てんし)
あの日胸に灯った永遠の炎
深い闇解き放って　自由のトビラ開いてく
強く果てない未来へ

天空, 時空, and 女神 have gikun, so furigana in some form is needed. 真夜中 is maybe not technically furigana (maybe you'd just call it ruby), but it serves the same purpose as in the first three: it tells you how the made-up word 黒天 is supposed to be read. Musixmatch replaces 真夜中 with its actual reading, which is sadly less edgy but achieves the same thing:

黒天(まよなか)の 蒼に溶けて

As for a potential voting system, I feel like the complexity isn't necessary when you could just have an admin get rid of obviously bad lyrics, it doesn't seem like there's that many of them.

However, I will say that I REALLY dislike that the current solution to romaji lyrics is to just submit correct lyrics. It's time-consuming and not always easy to do for niche music. I would much rather be able to just have them removed from LRCLIB because I'd rather get no lyrics than romaji lyrics. If LRCLIB provides no lyrics, at least my music player will fall back to another provider that has unsynced lyrics. But if LRCLIB gives me garbage, my system just takes the garbage and stops there.