lrclib
lrclib copied to clipboard
tranxuanthang
Feature Request: Other formats of LRC
Can we expect the enhanced LRC format in LRC Lib? I know I'm asking for something that's time-consuming but just curious about it.
or Walaoke extension would be sick too! Just a feature request
About Enhanced LRC About Walaoke Extension
Isn't it possible to have like enhancedSynced just like seen with synced Boolean value in json? As we return a plainLyrics whenever there is no synced? But yea this requires alot of work.
Would even make sense to have JSON (with timed words, multiple singers, and colors) or a custom format since it feels to me like both extensions are needed to not lose data from some external providers.
I think having Enhanced LRC support is good because then other people will implement it, and so more people will want better lyrics. It will also help current / existing projects (like Beautiful Lyrics, for Spicetify, which adds word-by-word lyrics, although not everywhere, and it only uses its dataset, which means some songs won't even have lyrics at all)
Also, I don't really think of the Walaoke Extension being useful, if anyone can elaborate why having colors for lines sung by males, females, or both helps. Anyways, I can implement it, I'd create a new key in a lyrics object and have an enum for the extension used determining its format, it would be one of the values from the enum, or if we want multiple extension support, we can make it an array of values from the enum. Whenever a new request to upload / publish lyrics is made, we find what the format is with the following procedure:
- do one of the lyrics start with "F:" "M:" or "D:"? (then it's using the Walaoke Extension)
- do one of the words in the lyrics have text in the format of
<HH:MM.SS>before a word separated by spaces? (then it's using the [Enhanced LRC](https://en.wikipedia.org/wiki/LRC_(file_format)#A2_extension_(Enhanced_LRC_format) extension) - if not, it's using plain LRC. Then, whenever we get a request to search or get the lyrics, the key is in there, so API consumers can detect what features to enable. For compatibility reasons, the unsynced lyrics and synced lyrics won't have these, there will be a object with a diff to use for applying those extension-specific features. (you could just pass the result but that's boring, pro gamer 1234 save 1 kB of extra data!!) If you can't apply the diff because your diff applying library is bad or you can't find one, you have a Skill Issue:tm:.
Can we expect the enhanced LRC format in LRC Lib? I know I'm asking for something that's time-consuming but just curious about it.
or Walaoke extension would be sick too! Just a feature request
About Enhanced LRC About Walaoke Extension
also, it isn't time consuming, at least from a high level perspective.
Having Enhanced LRC support in LRCLib would elevate the lyrics experience to a new level. It would make things a lot more flexible. This upgrade isn't just about keeping up; it's about leading the way and would highlight LRCLib's capabilities. While drive more interest and adoption. Like in Beautiful Lyrics other media players! I would like to see that this feature
Also, I don't really think of the Walaoke Extension being useful, if anyone can elaborate why having colors for lines sung by males, females, or both helps.
Bit late of a response but I didn't see anyone address it. I've been looking around since I read Chronograph added support for editing elrc.
It's only really useful for duets (and only male-female ones at that) as you're probably aware. It's a nice enough feature and it would get used but I think it's too narrow in its use case. As long as people stick to only using it in duets and don't try to shoehorn it into other songs then it's unlikely to cause issues. I also don't think it'll be massively missed compared to elrc.
I'd rather there was some more generic solution that expanded on Walaoke personally. Expanding to other songs with multiple singers (L for Lead and B for backing etc. something like that).
In regards to elrc I wonder if a metadata tag could be added like #56. Or leaving it up to clients to parse makes sense as well.
This might be a good time to think of a new solution. Enhanced/Walaoke extensions makes plaintext lrc almost unreadable and harder to edit. Will be harder to add features after. In those cases as @JerwuQu said json might be better. Before stepping in to that direction we could have a future proof/extensible plaintext format with similar simplicity and aspects of Original LRC. Here is my rough sketch of a new lrc file standard™️.
-------------------------
Plain Lyrics Section
Just stores plain lyrics that can be read by any text based editors like notepad or anything else. There may be cases where mapping timestamps is harder.
-------------------------
Line By Line Time Stamps
List of timestamps are just separated by comma.
-------------------------
Word by word time stamps
This could be stored as animation curves or simple list of timestamps.
-------------------------
Singer Time Stamps
In case of plural singers Walaoke extension simply isn't always enough, instead we could read from list of singer and assign them an index and timestamp ranges.
----------------------------
List of singers
we could re-use LRC format metadata for this or something like below
[singers: A, B, C]
Resulting a file that is easier to read while also used for storing animation data at the end of it.
Verse 1:
When the stars begin to shine
I feel your hand in mine
Chorus:
Together we light up the sky
Hearts in rhythm, you and I
[line-time:00:00.500,00:10.200,00:20.500,00:30.100]
[word-time:<-.3,.4,>,<-.3,-.5,.2,-0.1>] //css like animation graph for each line
[singers-time:<1,2>:00:00:139-00:05.200,<1>:00:00:139-00:05.200,<2>:00:00:139-00:05.200, ]
[singers: Bob, Alice]
This could be built in a way so that different apps can read and write to the same file without affecting other apps implementations. Pros:
- Easy to read by software and users
- Smaller db size because we may no longer need the plaintext column.
- Cleaner than json.
Cons:
- Another standard to implement by apps. We could provide a implementation for easy migration.
- Harder to edit timestamps without extra help from software.
There is still concern for parallel timestamps where multiple words are within same timestamps. Since we would be creating a new format we should be able to store parallel word animation.
Alternative
Keep the original lrc format but we add extra animation data at the end just like before. That way existing apps can parse data by skipping extra data at the end.
I think that eLRC and Walaoke would be a good feature to implement right now, and the extended features of them can be parsed out( e.g. eLRC can have all the <timestamps>) removed. They are not supported by many clients at all but this could help push them, as lrclib is the only(often preferred) alternative to musixmatch for FOSS devs.
Let's say we agree with a mix of eLRC + Walaoke + Our fix of those shortcomings
[00:00.00] <D: 00:00.04> When <D: 00:00.16> the <D: 00:00.82> truth <D: 00:01.29> is <D: 00:01.63> ....
Its starting to look familiar..... HTML 😅?
Storing in JSON may not be bad after all.
What happens if someone in the future tries to add timestamps to the words itself?
- Extra character shows up for those app that didn't get updated. What about the songs that have 3 or more singers singing together?
- Right now Musixmatch has timestamps for lines, sentences, words and even singers.
- Apple music can highlight words in parallel(when singers are singing in the background).
Do we want to limit ourselves to eLRCs limitations? or can we guarantee we can implement all these features without any breaking changes?
At the end this is lrclib. In respect to the core LRC this was my suggestion for LRC 2.0. Adding eLRC/ Walaoke implementation might be quicker but as I said before, they will quickly become insufficient. Then there will always be a friction for parsing/skipping complex lrc files.
Anyways, I am inspired from strudel live coder. With evolution the file will become a animation programming language for word animation. All the data is stored as index based mapping to immutable plain lyrics texts. I am thinking from a preserving aspect where new features/data can be added without breaking existing apps (after everyone migrates to it).
We are separating text and data so there will be no breaking changes to the storage format.
[key: hh:mm:ss.mss,hh:mm:ss.mss]
[key: <index, index>:hh:mm:ss.mss,<index, index>:hh:mm:ss.mss]
[key: <index. index>:hh:mm:ss.mss-hh:mm:ss.mss,<index. index>:hh:mm:ss.mss-hh:mm:ss.mss,]
keys become a way to indicate versions. like keyV1,keyV2 etc. So upgrading will not lead to parsing/editing existing data.
<,> for elements active in parallel. lines, singers.
<.> indicates hierarchy. like line:columns.
<...>:data stores data based on the "type" like time ranges, timestamps, floats.
This will break all existing apps only once. Then every apps choose their own implementation and complexity.
I think your format proposal is good but eLRC/Walaoke support right now would be an immediate solution that apps already support, and these files can be easily converted to your format.
The same thing can be said the other way too. We can go JSON route immediately since every language supports it and provide API that converts the JSON to LRC/eLRC/Walaoke. Storing eLRC directly will break existing apps and inflate the db. It's also not clear if the author wants it or there is a a good source of data that is available in eLRC.
