Version: 1.4.5 (using KDE KDE 3.5.6) Installed from: NetBSD pkgsrc Compiler: gcc version 3.3.3 (NetBSD nb3 20040520) OS: NetBSD v1 tags are written and updated; but there's a problem with multibyte characters -- they are truncated. How to repeat: - Create empty mp3 file. - Find this file using Files sidebar. - Using "Edit track information" dialog, set track title to "стёрто" (copy/paste should work, if you cannot input Cyrillic). dump tags (I used mp3check.py from py-Tagger): zero.mp3 : Found ID3v2 tag ver: 2.4 frames: 1 zero.mp3 : TIT2 (utf_8) [u'\u0441\u0442\u0451\u0440\u0442\u043e'] zero.mp3 : ID3v1 tag found zero.mp3 : song: ABQ@B> zero.mp3 : artist: Notice that track title in v1 tag is "ABQ@B>". I believe this is caused by TagLib bug 99149 (there's a workaround, see comment 9).
We won't do any encoding change ourselves. It's up to taglib to handle that, sorry. We've messed with id3v1 encoding in the past, and all we had was a great ammount of bugs here and there. SI'll mark this as a dup of the other bug. Consider this WON'TFIX as far as Amarok itself is concerned. *** This bug has been marked as a duplicate of 99149 ***
amarok could strip v1 tag altogether in this case, no?
... like taglib author says (http://ktown.kde.org/~wheeler/taglib/api/classTagLib_1_1ID3v1_1_1StringHandler.html): "It is recommended that you not override this method, but instead do not write an ID3v1 tag in the case that the data is not ISO-8859-1."
This has been recently fixed in taglib (SVN revision 768597)
Great, thanks for the info.
Still, released versions of taglib have the bug. Shouldn't amarok work around it?