About the Language Code for Comment and Unsynced Lyrics

So, according to the ID3v2 standard, both the Comment frame (COMM) and the the Unsynced Lyrics frame (USLT) require a language code (e.g. "eng" for English).

So when editing the Unsynced Lyrics frame (USLT), the language code (e.g. "eng||") is automatically added (e.g. "eng||") and displayed,
but when editing Comment frame (COMM), the language code isn't showing in the editor.

I'm feeling like this is a bit inconsistent (as both frames require the language code), is there a way to hide the "eng||" from displaying for the Unsynced Lyrics frame (USLT) for a cleaner look? (perhaps this could be a suggested feature too)

True, yet it is not the same.
Comment gets the code added to a separate section in the field definition - that is why you can set it on the options.
This thread and post shows a hex dump of a comment fields with the added language token

The unsynced lyrics have the language token as part of the field data (only MP3) which is visible for programs that show the raw data (like MP3tag) - as it would be the task of the user to add the appropriate language token manually.

"Hiding" would be one possibile solution.

Another would be: Let the user fill this field as any other tag or frame. Not everyone want to have "eng" as general standard (or because the own windows machine give this value back).

The option to set the language code different from that of the windows machine is already there.
My setting there is xxx.

I think the memory hook here is: whereas the language token in COMMENT is not visible, it is set in options, invisible during input.
The language token for UNSYNCEDLYRICS can be entered as visible data and MP3tag only adds that setting from the options if the language token has been forgotten. But then it is visible again (in MP3s).
Just as a reminder: the default setting "eng" is owed to iTunes that expects English COMMENTs.

Yes I know, thanks anyway :wink:

I would prefer something more reachable like a field configurable for the tag panel.
It would be helpful to set it lyrics by lyrics or an entire album at once - without going to the settings every time.

And as @ohrenkino already mentioned: The same should be possible for COMM too.

Comment gets the code added to a separate section in the field definition - that is why you can set it on the options.

The unsynced lyrics have the language token as part of the field data (only MP3) which is visible for programs that show the raw data (like MP3tag) - as it would be the task of the user to add the appropriate language token manually.

So I tested the unsynced lyrics frame in Mp3tag: when saving the tag, it automatically adds the language code part (e.g. "eng||") as set in "Tools->Options->Tags->Advanced" (same place for setting option for the comment) to the lyrics frame when you don't already include it.

If you look at the ID3v2 standards for both Comments and Unsynced Lyrics, their structures are identical, it's just that they're handled differently in Mp3tag's GUI (which was why I felt like it's inconsistent). If I'm not mistaken, Mp3tag parses the "eng||" part in unsynced lyrics field into "eng" (the "$xx xx xx" part in both two ID3v2 links above) and a null terminator (the "$00 (00)" part in both two ID3v2 links above), so the resulting structure of unsynced lyrics frame would be technically the same as the comment.

That's why I think both frames' language codes should be handled the same way (either hides both or display both, so that it's consistent), as their frames' structures in ID3v2 standard are identical.

On the other side it does not care about the language code in UNSYNCEDLYRICS.

Florian changed the behavior in 2.86f to hiding the language code.
Not least because of my intervention, he changed it back with 2.86h.
With that solution the behavior was different for default and not default language codes.

I don't work with different language codes in UNSYNCEDLYRICS, but for someone who does, the best solution would be to offer a pseudo-tag for the language code in UNSYCEDLYRICS and that tag would have to be idependend from the language code for COMMENT.

1 Like

I see, but now the behavior is also different/inconsistent for Comments and Unsynced Lyrics, which have identical frame structure (as can be seen in both two referenced hyperlinks for ID3v2 standard).
I'm imagining perhaps a toggle-able option would make everyone happy? I will reply to the post you referenced in more detail.

So we have field that gets only displayed if the displaying application is satisfied with the found language token (=COMMENT).
Then we have a field that displays text in a certain language (could even be a mixture of several languages) for which it is not quite clear what the language token should transport: the source (here: the language of the lyrics) or the target: for an audience that understands a particular language. Or is it the language of the artist.
And now, I know this is not quite the original topic anymore, we also have LANGUAGE as tag field - and I wonder what the purpose of that field could be.

So far, LANGUAGE showed the language of the TITLE and, if present, that of the LYRICS or UNSYNCEDLYRICS.
COMMENT got the token for the target application
and UNSYNCEDLYRICS got the xxx|| as it can hardly think of any application where the text of the lyrics for the same TITLE is different, depending on the audience - I would assume that real lyrics for a track are always just the one language that one can hear - and that can be represented by words, also written in that language.
A language token for the actual lyrics is superfluous, IMHO, but it is there, nevertheless.
But this just my impression and I am eager to learn use cases where there are lyrics in several simultaneous languages needed for a single file.

So, a default setting for COMMENT is already there, it also applies to UNSYNCEDLYRICS where it can be editted manually for whatever reason and the wish is there to set a different standard language for UNSYNCEDLYRICS (in MP3s - MP4s, I think, to not have that. So I wonder which language is set for MP4s).
Taking the code from LANGUAGE is not feasible as this would require LANGUAGE to be filled (and saved) prior to editing UNSYNCEDLYRICS.
I think the whole language handling in MP3s looks like a make-shift thing. And this not just in MP3tag but mainly in the players.

I can only speak for my self:
Every song text (aka "Lyrics") consists of one or more languages.
An english song text can also include the line "Voulez-vous coucher avec moi ce soir?".
For me, it remains an english song text and becomes the "eng" language descriptor. A song text in pure German or Spanish becomes "deu" or "spa".

On a sampler with 20 songs you will find the situation where several different languages should be used, accordingly to the lyrics content.

I'm assuming you're refering to the language frame (TLAN), yeah I agree that the TLAN frame is barely used by any platform out there. Instead I plan to use the Genre frame to list the music's language (e.g. English, Mandarin, Japanese, etc.), because Genre is a widely supported frame (and you can have multiple genres in ID3v2.4 too).

I'm kinda curious to learn what you're using different language codes in lyrics (USLT frame) for?
Do music players (if any) display them? (unfortunately, none of the music players I've tried can display the language code of lyrics, but over the years I've only tried about 20+ players on Windows and Android)

I'm using my own media library who is capable to let me choose "german" or "spanish" Lyrics as one of the search criterias. In combination with other criterias like Genre (i.e. "Hip-Hop", "Hard Rock") or Artist I can listen to music for my current mood :wink:

But you are right, I don't know of any known software other then Mp3tag that can also read and select ("filter") this information.
Maybe there are some plugins for other media player software like KODI, PLEX, EMBY?

I see, so you're using your own software. But still, wouldn't it make more sense to use the Language(s) frame (TLAN) instead? (the thing that ohrenkino just talked about)

From the ID3v2 standards:

The 'Language(s)' frame should contain the languages of the text or lyrics spoken or sung in the audio. The language is represented with three characters according to ISO-639-2. If more than one language is used in the text their language codes should follow according to their usage.

Also, you can only have one language code for each lyrics entry, but you can have multiple language codes for the Language(s) frame (TLAN), which is pretty useful for songs that contain more than 1 language.

In my case, there is only a small difference between reading the USLT lyrics frame including the lyrics language descriptor and reading the separate TLAN frame.

If you find a music player supporting TLAN, it would be the better solution.

And the support for TLAN, miracle of miracles, can be found in the Windows Media Player.
Yet, this player does not care about any language token in the lyrics if you set the options to simply "Show if present". But even with a dedicated language set, I always saw only the contents of the first lyrics field ... oh, well.