Windows 7, Mp3tag 2.73.
Steps to reproduce:
- Add UNSYNCEDLYRICS to Tag Panel (multiline tag).
- Open any .m4a file.
- Write multiple lines of any lyrics. (I've actually copied the lyrics from a file with proper Windows line-endings.)
- Open the same file in foobar2000, check in Properties, and see that all lines are displayed as a single one.
- Opening the file in a hex-editor shows that line-endings are written as a single '\r' (0D), instead of a proper "\r\n" (0D 0A).
The same lyrics written to a .flac file (with a mapping UNSYNCEDLYRICS -> LYRICS for VorbisComment) are saved properly.
It turns out that iTunes also writes Lyrics with '\r' line-endings, but I didn't find any information confirming that it's a standardized way to store multiline tags in an .m4a. Most Windows software cannot handle such multiline text. Since Mp3tag is mainly for Windows, it would make a lot more sense to use line-endings native to that platform, especially because other platforms handle Windows line-endings well.
Although I find your description accurate and the issue reproduceable, I am still not sure that this is a bug:
The ID3-standard (http://id3.org/id3v2.3.0) tells us in section
"4.9. Unsychronised lyrics/text transcription
This frame contains the lyrics of the song or a text transcription of other vocal activities. The head includes an encoding descriptor and a content descriptor. The body consists of the actual text. The 'Content descriptor' is a terminated string. If no descriptor is entered, 'Content descriptor' is $00 (00) only. Newline characters are allowed in the text. There may be more than one 'Unsynchronised lyrics/text transcription' frame in each tag, but only one with the same language and content descriptor. "
Please note that it says "Newline character" - not "carriage return + newline characters".
In this respect, I would say that the found behaviour is up to standard.
MP4 has nothing to do with ID3. ID3 is a separate standard for metadata, which is used by and large with MP3 only. MP4 uses its own tags, lyrics is stored in @lyr atom for example. I haven't found any standards regarding the structure of @lyr, and I don't think they matter:
- m4a files I've encountered contained any kind of newlines (win, nix, mac).
- Windows CR+LF works well everywhere. Other variants don't work on Windows.
Representation of “newline character” depends on the platform. Windows standard is to use carriage return + line feed. Currently Mp3tag writes MP4 files using lonely carriage return as a newline character, which is old Mac standard.
P.S. I checked MP3 files, which do use ID3. In MP3, newlines are stored as CR+LF, as it supposed to be.
I've changed this with Mp3tag v2.74.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.