August 2008 Archives

Japanese text in mp3 tags to musictracker

| 1 Comment

Since my friend Kacey gave me a nice J-Pop mp3 with some japanese text in the tag, I've been able to do some testing to see if these characters can get passed from the player into musictracker and hence to the status message....

jon@clairmont $ mid3v2 10\ 世界はこの手の中に.mp3
IDv2 tag info for 10 世界はこの手の中に.mp3:
TPE1=相川七瀬
APIC= (PNG, 105828 bytes)
TYER=2000
TIT2=世界はこの手の中に
TENC=iTunes v7.7.1
TRCK=10/13
TPOS=1/1
TALB=FOXTROT
TCON=Pop

This all seems to work swimmingly on various players under Linux, but under Windows it's more complex...

  • GetWindowText() on the foobar2000 window just returns a load of "?" characters, presumably because they don't exist in the local codepage (unlike accented characters like ö which survive this translation intact). Using GetWindowTextW() to retrieve the title in wide-character form then converting it to UTF-8 seems to work fine.
  • Winamp makes an utter hash of returning these characters via the (legacy) IPC_GET_EXTENDED_FILE_INFO interface we are using. Updating to use IPC_GET_EXTENDED_FILE_INFOW fixes this. We also need to use GetWindowTextW() as above for looking at the window title (which we use for stream information)
  • The mysterious wmp9.dll seems incapable of returning these correctly from Windows Media Player.... yet another reason to replace this code with something else....
  • This all works fine with iTunes, but it doesn't seem possible to actually display the song title correctly in iTunes, since it uses a fixed font (Lucida Grande?) which you can't seem to change and which doesn't have the glyphs. Later: turning on East Asian language support in Windows XP fixes this, presumably as it lets Windows do it's font linking thing to find the glyphs in another font...

So now I know more about this windows wide character nonsense than I ever wanted to. Oh, and I'm now one of the top listeners to Nanase Aikawa on last.fm :-)

pidgin monotone crosscompile for win32

| No Comments

Some notes on cross-compiling current monotone pidgin for win32. Don't do this if you have even less of an idea about what you are doing than me :-)

  • You'll need a i686-mingw32 toolchain, obviously :-)
  • run ./autogen.sh to use autotools to prepare the monotone sources for building
  • BuildingWinPidgin has most of the steps, but a few things didn't quite work for me
  • windres: icon file `some path' does not contain icon data
  • windres doesn't seem to do string literal concatentation after preprocessing, so the paths for various pixmaps aren't merged with the filename. Work around by editing the .rc file to have the correct full pathname (this is a bug in my version of windres)
  • makensis doesn't seem to like command switches introduced with "/", so change the Makefile.mingw to use "-"
  • makensis fails "Error: no branding image found in chosen UI!"
  • Workaround: comment out the line "!define MUI_HEADERIMAGE" in the .nsi file (this is a bug in my version of makensis)
  • makensis fails "Invalid command: System::Call"
  • gcc can't build the System plug-in properly. Workaround is to copy over Plugins\System.dll from a Windows install of nsis
  • Relative paths to gtk_installer in seem to have one too many "..\"
  • The msnp9 protocol plugin is the one built by default for windows at the moment, not the shiny new msnp15 protocol plugin (the opposite way around to the linux build). Since this is the thing I wanted to test with, change to match :-)

pidgin-musictracker has one additional dependency, libpcre, so you'll need to place a static library of that into win32-dev to link with as well...

About this Archive

This page is an archive of entries from August 2008 listed from newest to oldest.

July 2008 is the previous archive.

September 2008 is the next archive.

Find recent content on the main index or look in the archives to find all content.