I have recently thought to use the Negative squared characters when tagging my music. I have yet to find a music player which supports adding this character to denote explicit tracks when playing local files the same way many streaming platforms do.
🅲 🅴 🅸
I have been utilizing to denote Clean, Explicit, & Instrumental Tracks respectively by placing them at the beginning of the artist field.
My android device and media player support these characters.
MP3Tag has no problem handling these characters except when creating a playlist.
When I create a playlist these characters become something like "xEDxA0xBCxEDxB5xB"
Ironically when I copy that "code" & paste it it automatically becomes a character like 🅲. (I'm looking at playlist files in notepad++)
Is this a windows issue or does MP3Tag convert these characters to some sort of code for parsing. With the code above the playlists don't import properly. but if I run a find & replace on those codes the playlist works as per usual.
I did finally find a workaround but I was wondering if this is something that could be fixed in MP3Tag or is this an issues arising from elsewhere
Have you tried to create an UTF8 playlist?
MP3tag will do so if you create them as m3u8 instead of m3u.
Yes. Even with m3u8 playlists I am getting the same issue. I did notice in notepad++ the file reads as "UTF-8-BOM" encoding although altering the encoding does not change the characters in question.
I have experimented a bit - but I see a problem with MP3tag.
What I have done:
I created an M3u8 playlist with the function from the File menu - this produces the unreadable characters.
I created an export with UTF-8 encoding with the format of a playlist - this produces the unreadable characters.
I created an export with UTF-16 encoding with the format of a playlist - here the characters were OK.
BUT: such a playlist could not be read by any player.
If I put such a UTF-16-playlist into the plain editor and save it as UTF-8 then I get a playlist with the OK characters.
I saved a playlist also in Foobar - and there the result was OK with the first attempt.
So I would think that the UTF-8 translation is somehow off in MP3tag.
Hopefully its an easy fix. When i try to use find & replace in notepad i cant "find" the character using the "code"
I have to do a find & replace like this
Find "🅴" Replace with: "🅴" then the "xEDxA0xBCxEDxB5xB2" is replaced with the actual character so Mp3Tag is wrong & right at the same time.
I ended up posting about this because I exported a playlist from my android phone & these characters showed correctly in the m3u files that my media player exports which honestly left me more confused as I had originally thought my idea to use these unorthodox characters simply must not be supported by m3u8 let alone m3u
Currently, the workaround would be to create an export in the format of a playlist but with UTF-16 enconding, then load that into the ordinary windows text editor and save it there as UTF-8.
Here is an example of such a simple export
$loop(1)#EXTINF:%_length_seconds%,%artist% - %title%
Thank you for reporting this issue. I've moved this to Bug Reports. I'll attempt a fix next week and will keep you posted.
I've reworked the writing of UTF-8 encoded characters to properly support Unicode characters that require 4 bytes to be encoded.
I have just released Mp3tag v3.24a, which should fix the issue. Thanks again for reporting!
No problem, thank you for the speedy response & fix!