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]
