[F] Pasting Lyrics into the UNSYNCEDLYRICS tag, gets cut of when there is a Pipe Symbol somehere in the text

Hi,

When pasting Lyrics into the UNSYNCEDLYRICS tag, it gets cut of.

The Lyrics what I try to paste are:

blah blah blah
blah blah blah|
Oh, yeah

What happens after a save is that only the following remains:

eng||
Oh, yeah

And the reason being that before "Oh, Yeah", there is a Pipe Symbol

Is this a bug or ?

Thanks
Mike

This depends on the perspective.
the conventions for the lyrics require a language indicator as first entry, separated by TWO pipe letters.
MP3tag automatically inserts "eng||" if you have forgotten an entry as otherwise you won't see any lyrics in any player.
So, coming back to your case, I must say that you did not follow the conventions for lyrics as you omitted the second pipe letter. So in a way your entry was illegal.
It is now a more philosophical discussion what ranks higher: the required syntax or the data input by the user.

It would be nice, if you could check your data again and insert a "eng||" first and then the lyrics with that single pipe and the way MP3tag behaves then.

Hi,

if I insert,

eng||blah blah blah
blah blah blah|
Oh, yeah

and hit save,

what stays is
eng||blah blah blah
blah blah blah

so the text after the last pipe symbol gets cut off

Mike

Another example:
Write ...
eng||1|2|3|
4|5|
6|7|
#

... save and review ...
eng||1

And even more ...
Write ...
eng|descriptordescriptordescriptordescriptordescriptordescriptor12345|text text text text
... and it will be accepted although the length of the descriptor is greater than max. 64 characters.

DD.20110221.0410.CET

Just came across this behaviour myself. Thought I should bump it as it doesn't have a response as yet. e.g. [C] or [X]

I am importing from a text file with Text File->Tag. The preview shows the full lyric will be imported but everything after the first pipe is cut off.

I think the behaviour has been described thoroughly enough.
I still wonder what the effect of a pipe symbol in an ordinary text should be. How do you sing or say a pipe symbol?
Perhaps the original idea was: let us look for a character that is not used in ordinary speech and use that for the metadata.
So I would assume that the pipe symbol has been added (or left out) deliberately which is a violation of the syntax rules.

I'm going to bump this one again, as I believe it is a bug.

Why can't the lyrics contain | characters? The docs don't say anything about lyrics having restricted characters.

UNSYNCEDLYRICS

Syntax: xxx||Lyrics
Note: xxx = Language of the lyrics, abbreviated by 3 characters according to ISO-639-2.

Nasty side effect of this behavior:

If a lyrics field contains e.g. lyrics line 1|lyrics line 2|lyrics line 3| (obviously someone who doesn't use Mp3tag has foolishly done this)

If I open this file in Mp3tag and unwittingly edit the tag, I will lose the last 2 lines of the lyrics and not even know about that!

I hope that with age there comes wisdom.
I just fell into that trap because I dumped information about a radio play ("Hörspiel") in UNSYNCEDLYRICS - it is the only field that WMP displays in a decent fashion and has (almost) no limitation in respect to text length. So while you listen to such a piece of audio entertainment, you can read some more details about it. Quite nice, in my opinion.
Anyway: some radio stations equip their descriptions with text like

"Lost in Praha

WDR 3 Hörspiel | 11.03.2018 | 53:02 Min.

WDR 3 Hörspiel: In Prag soll alles besser werden. Tomas, Mitte 30, ist deprimiert. Er hat genug von seinem frustrierenden Leben als Lehrer in Berlin. Kurzerhand bricht er alle Brücken ab, um in der "Goldenen Stadt" neu anzufangen. // Von Martin Becker und Jaroslav Rudis / Musik: KAFKA / Technische Realisation: Benno Müller-vom Hofe / Regie: Thomas Wolfertz / Redaktion: Natalie Szallies / Produktion: WDR 2008 /"

and everything after "Hörspiel" gets cut off. As the cutting off happens immediately on saving, it is not possible to run some kind of action to remove the extra pipe symbols. And to be quite honest: the pipe symbols are fairly hard to spot.
So meanwhile I would appreciate a less rigid behaviour for UNSNYCEDLYRICS.

Once you know, that the tag-field UNSYNCEDLYRICS needs a proper syntax, you should not fill this tag-field with an invalid formed data structure.
Better you fill a helper tag-field, e. g. USLT_TEMP, with the text to import. Then you apply some fitting modification to the imported text, to make it safe and follow the needed syntax.
Afterwards copy the modified text into a new tag-field UNSYNCEDLYRICS.
Then remove the helper tag-field.

See also: http://id3.org/id3v2.3.0
4.21. Linked information
4.9. Unsychronised lyrics/text transcription

DD.20180313.1033.CET

MP3tag applies "automatisms" to this field:
If you enter just the plain text then MP3tag adds a language id (usually "eng", can be set) and also the two pipe characters.
Here MP3tag saves you from entering an invalid language.
But where it is overdone (IMHO) is when MP3tag cuts away further text even though the format with introducing language id plus bar characters is already correct (in respect to header).
When MP3tag generates filenames with data from tags, it removes invalid characters but MP3tag does not discard everything following the first syntax breaking character.
I would like to see MP3tag to handle user inputs in UNSYNCEDLYRICS with just as much care as in the filename and remove only that what obviously collides with syntax rules.
In this case it is just the superfluous pipe character but not that plus the following text.
Admittedly, what you describe is a workaround but I see it as a real awkward one.

I saw that Mp3tag removes text from the left edge until the first pipe symbol, but not any following text.

DD.20180313.1117.CET

I've removed some of the magic here :slight_smile:

The implementation with the latest Development Build Mp3tag v2.86f should fix the issue. Thanks for reporting and the overall patience.

Kind regards
— Florian

1 Like

Thank you Florian! :pray: :grin:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.