Does SongKong support special characters?

[PJ4301]

Hello!

It has been long time annoying me that my SongKong does not support special characters for example those in German, Swedish etc. I am now running latest ver 7.2 but it has been a problem ever since my first time using SongKong. I have to re-edit those truncated characters via Mp3tag.

Below is an example: in auto matching report it shows perfectly:

Whilst in Mp3tag and it shows:

Does anyone share same issue and is there possible solution?

Thanks

[paultaylor]

Hi, I wasn’t aware of such an issue its never been reported before, however how do you know the problem is with SongKong rather than with Mp3Tag. Can you try viewing the songs in another application and see what it shows.

Mps’s can store the metadata using ID3v23 or ID3v24, if using ID3v23 it can only store data using IS08859-1 or UTF-16, these characters would require UTF16, maybe there is a fault in either how MP3Tag reads UTF16 or how SongKong is writing them. However if you use ID3v24 then can write them as UTF8.

Try settings Mp3 Metatag Version to V24, this will force any existing V23 tags to be written as V24 to see if that resolves the issue.

[PJ4301]

Hi Paul,

Thanks for so swift response. I tried your suggestion to change to v24:

But seems the problem remains when viewing from Mp3tag:

And I don’t think it’s with Mp3tag, since when I view from Windows Explorer (which supposed to be popped out by MinimServer installed on my Melco) it’s like below:

[paultaylor]

The Windows Explorer issue is not relevant because there you are showing me the name of the folder not the metadata within the file, and Windows Explorer does have limitation in charcter support for filenames.

Okay, there are plenty of things we can do to get tho the bottom of it:

1. From SongKong run Create Support Files then I can check logs/reports etc
2. Email support@jthink.net just one problem mp3 file for testing
3. Try viewing in another app (such as Winamp) to resolve my first query

[PJ4301]

Thanks Paul. Have just sent a sample file.

It looks fine when viewing from SongKong manual edit module, and when viewing from MConnect HD control point on iPhone, but truncated in Mp3Tag (and Windows Explorerer):

If do nothing in Mp3Tag (i.e. without saving anything and exit) and go back to SongKong manual edit module, it still looks unchanged and fine:

But if save anything in Mp3Tag and go back to SongKong it’s got truncated:

Thanks.

[paultaylor]

Hi, it does seem to me that since you can see the data okay in MConnect HD the problem is with Mp3Tag, it would certainly be an idea to post on their forum as well. But I am happy to look into this further but I don’t seem to have received your test files, did it send okay, perhaps yo could use dropbox or similar instead.

[PJ4301]

Hi Paul, just resent the sample file with sample attached. Thanks.

[paultaylor]

Thanks, have it now

Okay if I just open the file with Mp3Tag 3.05 it displays fine, actually note that the ö in Sjökvist is actually encodable in ISO-8859-1 it doesn’t even need UTF-8/16 so it shouldn’t be a problem at all.

So I don’t understand why it doesn’t display correctly when you just open in MP3Tag before doing anything?

[PJ4301]

Finally, I guess the problem is with Win10 Chinese encoding. My primary regional setting is China, and after I changed Win10 regional setting to English (US) Mp3Tag can correctly show these fonts. I may take more experiments to test more.

Thank you Paul.

[paultaylor]

Okay so I think what is happening here is that these characters can be stored in the default 8-bit (i.e one byte per character) ISO-8859-1 charset used by ID3, there is no need to UTF-8 (multiple bytes for some chars) or UTF-16 (2 bytes) so this is what SongKong is using.

I think Mp3Tag is trying to be clever by assuming that if you are using Windows Chinese then you are not using ISO-8859-1 charset, but an 8-bit encoding version more suitable for chinese such as GB_18030 . This seems wrong as the ID3 standard does not provide support for using these different charsets.

I do have a workaround, but it would require to use Jaikoz to resave the files. In Jaikoz if you set Write V2 Tag Version to v24 to force all files to be saved using ID3v24 format and you set Default Text Encoding to use when writing ID3v24 tags to UTF-8 that will ensure it uses UTF-8 all the time instead of just when it is required. Then if you read the files with Mp3Tag it should use UTF-8 regardless of the encoding used by Windows.

You can try out Jaikoz and save changes for a limited number of files to test without needing to purchase a license