Sounds great! What did you create this for?

By the way, from metadata:

Artist=동영 김

Album=동영 김의 앨범

Hmm. An encoding mystery? The data qubodup posted is this in hexadecimal:

(artist) EB8F99 EC9881 20 EAB980
(album) EB8F99 EC9881 20 EAB980 EC9D98 20 EC95A8 EBB294

It's encoded UTF-8 for the Unicode code points U+B3D9, U+C601, space, and U+AE40. Those are all in the range U+AC00 to U+D7A3 which is the precomposed Hangul syllables block, so I don't really see a problem with that text itself. A couple of UTF-8 verifiers I tried reject it as invalid for some odd reason; can't figure out why. Checking a conversion table, they appear to be right. I even looked at the binary values and it appears both structurally and semantically legitimate.

So there's only one remaining question, and that's whether the data in the file actually matches what was posted. It's not identical bytes, but I can explain why. Take a look:

(artist) D9B3 01C6 2000 40AE
(album) D9B3 01C6 2000 40AE 58C7 2000 68C5 94BC

At first glance it's very different. There are two reasons: (1) the encoding here is UTF-16 instead of UTF-8, and (2) the data is little-endian and needs to be byte-swapped to "make sense" (be in the usual order).

After byte-swapping we have:

(artist) B3D9 C601 0020 AE40
(album) B3D9 C601 0020 AE40 C758 0020 C568 BC94

This matches exactly with the Unicode code points, since there's no surrogate pairs involved in this text (that, in turn, is because the characters are all in the basic multilingual plane). We could encode to UTF-8 to show that this matches the other data above identically. It must have been encoded, probably invisibly, between the time it was extracted from the tags and posted to the web.

My conclusion is therefore no problem with the tag data. That kind of surprises me, because East Asian text is often improperly encoded in ID3 tags. It needs to be UTF-16 or UTF-8, since the ID3v2 specification doesn't identify any other usable encodings (despite having an encoding byte on the text fields for that sort of purpose). UTF-16 is preferred because UTF-8 was only added as an option in a late stage update to the specification. In this case it was UTF-16 and thus correct.

For those who cannot see these characters correctly, it's very probably due to the lack of an appropriate font. It needs to support the full Hangul characters range, including the huge precomposed Hangul block (U+AC00 to U+D7A3). Most fonts, even those that claim to support Korean, do not actually fill that entire block. They're mostly limited to the Hangul Jamo block (U+1100 to U+11FF) that contains the most frequently used characters. When a character exists in both blocks, it's better to use the Jamo one for higher compatibility. I'm not familiar enough with Korean to know whether these characters are actually in both blocks.

I used it for my game Banana Bagger:

https://play.google.com/store/apps/details?id=krosylum.ro.bananabagger

(Available on iOS soon!)

Thanks! 

yes

SUPER !!! THANK YOU !!!

Thx for sharing, Ill use it for my game twitter post in 21st of december, Ill share when I have the twitter link.

https://x.com/SoulPassageGame