Skip to main content
$12256 / $11500
About
Rules
Blog
FAQ
Style
Forum
dance music 1
dance music 1
Author:
dogchicken
Wednesday, December 5, 2012 - 20:09
Art Type:
Music
Tags:
dance
Battle
drums
ancient
fast
fighting
fight
Action
martial
ninja
samurai
cool
awesome
speed
Race
racing
tribal
hero
heroic
young
heroine
Prince
princes
jungle
warm
License(s):
CC-BY 3.0
Collections:
Music - Platform
Favorites:
31
Share Icons:
Preview:
Work with garage band.
Enjoy ^^
File(s):
s6.mp3
1 Mb
[
1486
download(s)]
Log in
or
register
to post comments
Comments
Sounds great! What did you create this for?
By the way, from metadata:
Artist=동영 김
Album=동영 김의 앨범
Thank you.
I just want to make cheerful music.
Oh, That is my name in Korean.
Artist = 동영 김 = Dong-Young Kim
Album = 동영 김의 앨범 = Dong-Young Kim's 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 !!!