Sync/Unsynced Lyrics: SYLT/USLT (id3v2) / LYRICS/UNSYNCEDLYRICS (flac)

[muja]

Reproducer

No response

Summary

Synchronized Lyrics should map to SYLT in mp3. Currently, ItemKey::Lyrics maps to USLT (unsynchronized lyrics). There is no corresponding ItemKey for SYLT.

On the other hand, for vorbis comments / FLAC, the tag for synchronized lyrics is LYRICS, which ItemKey::Lyrics maps to. However, UNSYNCEDLYRICS is currently parsed as ItemKey::Unknown(_).

So, to summarize:

flac -> lofty	id3v2 -> lofty
LYRICS -> ItemKey::Lyrics	SYLT -> None
UNSYNCEDLYRICS -> None	USLT -> ItemKey::Lyrics

I couldn't find a specification on the LYRICS/UNSYNCEDLYRICS file but it is widely used by apps like Jellyfin or LrcGet:

As for id3v2, the specification is very clear on this: https://id3.org/d3v2.3.0 section 4.9 and 4.10

Could probably be a breaking change.

Expected behavior

No response

Assets

No response

[Serial-ATA]

Synchronized Lyrics should map to SYLT in mp3. Currently, ItemKey::Lyrics maps to USLT (unsynchronized lyrics). There is no corresponding ItemKey for SYLT.

ItemKey::Lyrics is intended to be unsynced lyrics. ID3v2 is the only format that has a specified synchronized lyrics field, so there's no generic way to edit those, you must use Id3v2Tag.

On the other hand, for vorbis comments / FLAC, the tag for synchronized lyrics is LYRICS, which ItemKey::Lyrics maps to. However, UNSYNCEDLYRICS is currently parsed as ItemKey::Unknown(_).

I've never seen UNSYNCEDLYRICS in Vorbis Comments, but LYRICS as far as I can tell has always been used for unsynced lyrics: https://picard-docs.musicbrainz.org/en/appendices/tag_mapping.html#lyrics-4. Unfortunately, the LYRICS field isn't specified, so I guess people started overloading it with synchronized lyrics instead of making a new field?

It wouldn't make sense to change the behavior of ItemKey::Lyrics for Vorbis Comments, since that would break it for people that are using it "properly" (as far as I can tell).

I think the real solution is to just treat both LYRICS and UNSYNCEDLYRICS as ItemKey::Lyrics, and let the ambiguity fall on the caller. Some popular music players already treat both fields as potentially synchronized: https://forum.powerampapp.com/topic/25888-display-lyrics-from-unsyncedlyrics-tag-instead-of-vorbis-lyrics-tag/#findComment-120178

[muja]

Since this library has already decided on Lyrics == id3v2::USLT == vorbis::LYRICS, and does not support the mp3 tag SYLT (not sure if you're ever planning to), seems like this is out of scope then?

I think the real solution is to just treat both LYRICS and UNSYNCEDLYRICS as ItemKey::Lyrics

If you're gonna conflate the two -- what would they be saved as? Seems destructive if not well thought out.

If you want I can close this issue

[Serial-ATA]

and does not support the mp3 tag SYLT (not sure if you're ever planning to)

To be clear, SYLT is supported, but only through Id3v2Tag, not Tag.

If you're gonna conflate the two -- what would they be saved as? Seems destructive if not well thought out.

They'd be saved as LYRICS. They're already conflated in the wild unfortunately, so I doubt it'd make any real difference. UNSYNCEDLYRICS serves the purpose that LYRICS is/was intended to serve, anyway.

The workflow would be:

• Check ItemKey::Lyrics (could be LYRICS or UNSYNCEDLYRICS)
• Try and parse it as synced lyrics
• Otherwise, treat it as unsynced

Which is what I imagine most apps are already doing, since LYRICS was never guaranteed to be synced anyway. And I'd also imagine more apps recognize LYRICS than UNSYNCEDLYRICS.

In any case, apps that need to deal with these kinds of format-specific problems should be using concrete tag types like VorbisComments. Tag isn't built for these things, its purpose is to abstract away the tag format entirely.

[muja]

Possibly there is no guarantee when reading. However I'm writing an app that is writing these tags and for me it's important to write both LYRICS and UNSYNCEDLYRICS distinctly. LYRICS is used by apps and the non-standard UNSYNCEDLYRICS is home for the lyrics in TXT format which I need for apps that do not support synced lyrics or when I want to store them for archival. Unfortunately the removal of ItemKey::Unknown on master makes conflating the two a showstopper. I could rewrite everything to use VorbisComments to make it still work (possibly, haven't checked?), but I'd rather not, and at that point this awesome library is starting to severely limit the user's options.

[Serial-ATA]

Actually, this is similar to #334 (integer vs float BPM ambiguity). So I wouldn't be opposed to adding an ItemKey::UnsyncLyrics that's guaranteed to be unsync, and then keep ItemKey::Lyrics and just document that it's ambiguous. So your app could just work with those two ItemKeys. How does that sound?

Sorry, completely forgot that this has been a problem before.

[muja]

Nice, yeah that would be perfect and I agree with what the contributor said that it should be up to the client to decide -- after all the library should make our life easier while preventing wrong usage -- for id3v2 (and possibly other formats) they would both map to the same value then right? USLT for id3v2 -- it'd be important to clarify the ambiguity in the docs with a note that Lyrics maps to USLT because having both ItemKeys may otherwise lead to confusion.

To summarize:

• id3v2 is the only tag type that has an explicit tag for "synced lyrics"
• vorbis has LYRICS which is not formally specified to be sync or unsync, but most apps in the wild will recognize LRC format and fall back to TXT
• UNSYNCEDLYRICS is not official but has some mentions and is used in some apps, though scarcely.

Maybe useful, additional info, seems .m4a/alac or at least Apple Music v1.5.6.11 does not support synced lyrics. I converted a .flac with both LYRICS and UNSYNCEDLYRICS to .m4a using ffmpeg -i in.flac -c:v copy -c:a alac out.m4a and ffmpeg did not include UNSYNCEDLYRICS, and Apple Music is showing the LRC lyrics as raw text.

Finally, for completeness, since ItemKey::Unknown is removed, maybe it should be added to the release notes that an issue/PR should be filed for adding tags with their motivation

[Serial-ATA]

for id3v2 (and possibly other formats) they would both map to the same value then right? USLT for id3v2

The formats that support ItemKey::Lyrics are APE, Vorbis Comments, ID3v2, and Ilst.

APE and VorbisComments mostly copy each others keys, so they could both use LYRICS and UNSYNCEDLYRICS.

For ID3v2 and Ilst, though, ItemKey::Lyrics and ItemKey::UnsyncLyrics could just map to the same thing (USLT and ©lyr respectively).

Finally, for completeness, since ItemKey::Unknown is removed, maybe it should be added to the release notes that an issue/PR should be filed for adding tags with their motivation

Yeah, that's true. I'll add a note