[I don't know whether you want to handle this by reopening the bug report or treating this as a fresh one.]
I've just had a chance to upgrade to the new version of jack which is supposed to fix this bug and add UTF8 support. It correctly queries the server and gets a UTF8 freedb file back. However, the during-ripping display mangles the UTF8 track names rather, giving mojibake, and also doesn't cope with the fact that some characters are double-width. This is a screenshot of what jack looks like: http://www.chiark.greenend.org.uk/~pmaydell/misc/jack-screendump.png For comparison, here's a cat of the freedb file to show what the track names ought to look like: http://www.chiark.greenend.org.uk/~pmaydell/misc/cat-screendump.png Also, once ripping is complete it tries and fails to tag them: This is jack 3.1.1 (C)2004 Arne Zellentin <[EMAIL PROTECTED]> *info* querying... Tagging..Traceback (most recent call last): File "/usr/bin/jack", line 260, in ? jack_tag.tag(freedb_rename) File "/usr/lib/python2.3/site-packages/jack_tag.py", line 141, in tag tag.update() File "/usr/lib/python2.3/site-packages/eyeD3/tag.py", line 502, in update self.__saveV1Tag(version); File "/usr/lib/python2.3/site-packages/eyeD3/tag.py", line 941, in __saveV1Tag tag += self._fixToWidth(self.getTitle().encode("latin_1"), 30); UnicodeEncodeError: 'latin-1' codec can't encode characters in position 0-6: ordinal not in range(256) It should ideally tag them properly in UTF8 (if such a thing is possible); failing that, it should catch and report the error in a more user friendly way than a python backtrace. I'm using a UTF8 locale. Filenames are written to disk correctly, so (assuming you're happy to live without id3 tags) it's just a cosmetic issue. Peter Maydell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
