Yt-dlp downloads Description doesn't have Line Break

MP3Tag needs carriage return + line feed (CRLF) to display correctly.
yt-dlp uses ffmpeg to embed metadata and it show it correctly


I just copied and pasted the first 2 lines of your post into an MP3tag field:

And that shows the line breaks ...
So I am not sure what has happened to your text.

Line breaks but not when using unix-style LF.

Does that consist only of LineFeed or CarriageReturn?

Then you could try an action of the type "Replace with regular expression"
Search: \r
Search \n
(that depends which one has been used for the line break)
Replace with: \r\n

It is a bug. Mp3Tag should accept both unix and windows style line breaks. someone marked it support please mark it Bug Report.

Can you solve your problem with the replace function?

No. Maybe the charter you told to replace are wrong

Could you supply such a file? So that others can have a look?

I just removed all \r from a field, so that only the \nare left and this is what it look like in the hex editor and what MP3tag shows:

Blank (989.2 KB)

This opus song contains the SYNOPSIS like this (LF only).
Not with CR+LF as you wrote in the 1st post.

I just applied this:

Which leads to a field with proper line breaks.
So I cannot reproduce

I checked with the ID3 standard which says:
"Fields that include more then one line uses [CR][LF] delimiters between lines. "
I do not think that your assumption

is correct in this respect.

  1. Replacing works.

I checked with the ID3 standard which says:
"Fields that include more then one line uses [CR][LF] delimiters between lines. "

Opus uses Vorbis Comments[Unfortunately%20the%20Windows%20cmd%20shell%20provides%20no%20method%20to%20get%20a%20newline%20(CR/LF%20in%20Windows)%20into%20the%20command%20line.%20A%20linefeed%20(LF)%20may%20be%20inserted%20with%20CTRL-T%2C%20but%20I%20have%20found%20no%20way%20to%20insert%20a%20carriage%20return%20(CR).]

Mp3Tag should automatically fix it as per container?

If this is so, it is still no bug but a Feature Request.
As far as the discussion has come so far:
Yes, the OPUS fields have only 0A as end-of-line character and that is not treated as such by MP3tag.
Yet, there is an easy workaround with an action to replace the single control character with the 2 correct ones.

I have to admit that I found a different behaviour with ID3 tags which show line breaks even with only 0A at the end.
And also, I found that pasted text with just 0A as end-of-line character is transformed into 0D0A after saving as long as it is an ID3 tag. Like that the tag data becomes standard compliant for ID3 tags.

It would help to see a similar specification for OPUS tags.

The problem is that the Windows edit control requires CRLF to correctly display linebreaks. I've mostly refrained from auto-translating linebreaks so far, because I always prioritized what is actually stored in the tag fields over convenience of display.

Make MP3Tag use both CRLF & LF.

I think this would most likely address your specific needs, but not necessarily the expectations of all other users — some of which simply expect Mp3tag to not alter the data displayed in the edit field.

I've thought about auto-translating the LF (and single CR, which also exists) and translate it back when saving, but this also prevents users from changing the linebreaks to their desired format.

I think for now you need to resort to the approach suggested in this topic to replace the linebreaks to your desired format. And if you want to have them correctly displayed in Mp3tag this would mean CRLF.