Bug#266052: jack: utf8 support: still not displayed right, falls over trying to id3 tag
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2005-07-08 17:59]: > [I don't know whether you want to handle this by reopening the > bug report or treating this as a fresh one.] That's fine. My apologies for not seeing your new message before, though. > 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. Yes, the problem is that there are currently no ncurses bindings for Python which support UTF-8. I've had a fairly long discussion about this with various people (see #279000) and someone might create such bindings in the near future. Once this will happen, I'll switch jack over to use it. (And yes, there is one minor cosmetic error related to double-width chars that I'm aware of; I've fixed some already but at least one more is there. I'll fix that eventually.) > Also, once ripping is complete it tries and fails to tag them: > 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) OK, that's a real bug. > 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. MP3 has (at least) two different type of tags, version 1 and version 2. Version 2 supports UTF8 and when you look at your file you should see that it has been tagged properly. jack can also add version 1 tags and this is what broke in your case. I'll make it more robust. Also, I think we should turn version 1 tags off by default. Anyway, you can use the patch below or wait a for days for a new package: --- jack_tag.py~2005-07-26 21:49:15.567452736 +0100 +++ jack_tag.py 2005-07-26 21:49:55.100442808 +0100 @@ -138,7 +138,10 @@ tag.setGenre("(%d)" % (cf['_id3_genre'])) if cf['_id3_year'] != -1: tag.setDate(cf['_id3_year']) -tag.update() +try: +tag.update() +except UnicodeEncodeError: +pass mp3file.close() elif jack_helpers.helpers[cf['_encoder']]['target'] == "ogg": vf = ogg.vorbis.VorbisFile(mp3name) -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#266052: jack: utf8 support: still not displayed right, falls over trying to id3 tag
* Martin Michlmayr <[EMAIL PROTECTED]> [2005-07-26 21:50]: > MP3 has (at least) two different type of tags, version 1 and version > 2. Version 2 supports UTF8 and when you look at your file you should > see that it has been tagged properly. jack can also add version 1 > tags and this is what broke in your case. I'll make it more robust. > Also, I think we should turn version 1 tags off by default. > > Anyway, you can use the patch below or wait a for days for a new > package: Arne, please use this patch instead. It will also print a warning when we're only adding v1 tags but they fail. diff -urN jack-3.1.1~/jack_tag.py jack-3.1.1/jack_tag.py --- jack-3.1.1~/jack_tag.py 2005-07-27 13:53:36.293534312 +0100 +++ jack-3.1.1/jack_tag.py 2005-07-27 13:54:18.856063824 +0100 @@ -138,7 +138,12 @@ tag.setGenre("(%d)" % (cf['_id3_genre'])) if cf['_id3_year'] != -1: tag.setDate(cf['_id3_year']) -tag.update() +try: +tag.update() +except UnicodeEncodeError: +if not cf['_write_id3v2']: +print +print "Track %02d contains data not supported by id3v1; please use --write-id3v2" % i[NUM] mp3file.close() elif jack_helpers.helpers[cf['_encoder']]['target'] == "ogg": vf = ogg.vorbis.VorbisFile(mp3name) -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#266052: jack: utf8 support: still not displayed right, falls over trying to id3 tag
[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]