Version: 0.9.1-CVS (using KDE 3.2.1, (testing/unstable)) Compiler: gcc version 3.3.3 (Debian) OS: Linux (i686) release 2.4.23 1. When I drag directory containing files with non-latin1 names amarok does nothing, so I need to enter into directory and add all files (it works). 2. If file contains tag with non-latin1 symbols, amarok displays it wrong (using latin-1). Because, mp3 doesn't provide charset information, I suggest to let user to choose font charset.
Will try to fix, but I haven't a clue when it comes to unicode/charsets and all that jazz.
I got to know amarok today, and I should say, it rocks ;) it managed my mp3 pretty good and fast(I have over 9k mp3, around 30G total). And, here is the patch for displaying non-latin1 id3 tag. Hope it wouldn't break other things.. diff -ruN amarok.orig/amarok/metabundle.h amarok/amarok/metabundle.h --- amarok.orig/amarok/metabundle.h 2004-03-05 13:15:10.000000000 -0800 +++ amarok/amarok/metabundle.h 2004-03-25 21:53:47.706294056 -0800 @@ -86,11 +86,11 @@ MetaBundle( const KURL &url, TagLib::Tag *tag, TagLib::AudioProperties *ap = 0 ) : m_url( url ) - , m_title( TStringToQString( tag->title() ).stripWhiteSpace() ) - , m_artist( TStringToQString( tag->artist() ).stripWhiteSpace() ) - , m_album( TStringToQString( tag->album() ).stripWhiteSpace() ) + , m_title( QString::fromLocal8Bit(TStringToQString( tag->title() ).latin1()).stripWhiteSpace() ) + , m_artist( QString::fromLocal8Bit(TStringToQString( tag->artist() ).latin1()).stripWhiteSpace() ) + , m_album( QString::fromLocal8Bit(TStringToQString( tag->album() ).latin1()).stripWhiteSpace() ) , m_year( tag->year() ? QString::number( tag->year() ) : QString() ) - , m_comment( TStringToQString( tag->comment() ).stripWhiteSpace() ) + , m_comment( QString::fromLocal8Bit(TStringToQString( tag->comment() ).latin1()).stripWhiteSpace() ) , m_genre( TStringToQString( tag->genre() ).stripWhiteSpace() ) , m_track( tag->track() ? QString::number( tag->track() ) : QString() ) { diff -ruN amarok.orig/amarok/threadweaver.cpp amarok/amarok/threadweaver.cpp --- amarok.orig/amarok/threadweaver.cpp 2004-03-05 13:15:11.000000000 -0800 +++ amarok/amarok/threadweaver.cpp 2004-03-25 21:46:24.298702256 -0800 @@ -14,6 +14,7 @@ #include <taglib/tag.h> #include <taglib/tstring.h> +#define MyQStringToTString(s) TagLib::String(s.local8Bit().data(), TagLib::String::Latin1) ThreadWeaver::ThreadWeaver( QWidget *w ) : m_parent( w ) @@ -256,7 +257,7 @@ if( !f.isNull() ) { TagLib::Tag *t = f.tag(); - TagLib::String s = QStringToTString( m_tagString ); + TagLib::String s = MyQStringToTString( m_tagString ); switch( m_tagType ) { case 1:
Created attachment 5401 [details] display ID3 in CJK chars correctly Hope it works..
Created attachment 5402 [details] handle files in non-latin1 path correctly Hope it wouldn't break other things..
I guess it will break some stuff, but we'll take a look. Thanks leo, stay tuned.
*** Bug 76399 has been marked as a duplicate of this bug. ***
CVS commit by mhowell: * Fix non-latin1 locale problems with tags and directory loading. * Patch courtesy of leo zhu. None of us knew what exactly to do to fix this and so we were waiting for someone to step up and help, Leo was our man! Many thanks. * I made some ammendments to the playlistloader.cpp mods to try and reduce the amount of QCStrings being created. Leo, could you check it still will work? I would but I have no non-latin1 stuff (that I know of). * Split MetaBundle into a cpp file too as should have been done a long time ago. * Use some of Zack Rusin's tips as featured on the dot, notably the one where you cache the iterator from a QValueList::end() operation in a loop. CCMAIL: 78200-done@bugs.kde.org A amarok/metabundle.cpp 1.1 [UNKNOWN] M +5 -4 ChangeLog 1.142 M +1 -0 amarok/Makefile.am 1.82 M +26 -136 amarok/metabundle.h 1.20 M +30 -20 amarok/playlistloader.cpp 1.62 M +1 -1 amarok/playlistloader.h 1.34 M +11 -4 amarok/threadweaver.cpp 1.9
Will check the new cvs later, however, I just noticed this: http://bugs.kde.org/show_bug.cgi?id=76399 My patch wouldn't work for utf8 locales. The problem is, QT really lacks a mechanism for detecting the encoding of the chars. During tag reading, we get the original tags(char*), then we'll try to convert them to QString by QString::fromUtf8 or QString::fromLocal8Bit, the same goes for path/filename. But we don't know exactly which constructor to use. Things is much better in gtk2(with g_utf8_validate, g_filename_to_utf8). Anyway, my patch wouldn't break the latin1 tags/filename handling ;)
A complete solution is, use a dialog, so the user could choose the correspoding locales, then call QTextCodec::codecForName("localename")->toUnicode(s)) and QTextCodec::codecForName("localename")->fromUnicode(str)) to do the convert. All the possible value of "localename" can be found at http://doc.trolltech.com/3.2/qtextcodec.html This doesn't need much work, but a very careful test is required. The locale handing in QT is really a mess. :( btw, where is the cvs server? I can't find any info on the website.
KDE CVS, module: kdeextragear-1
The rest of KDE seems to get along fine without a dialog. There must be an easy solution. And anyway, I'm now confused. What's the bug we're trying to fix?
> The rest of KDE seems to get along fine without a dialog. so why cant we simply look how it is done in other software? the dialog (or configuration option) should be created for selecting id3tag encoding
Leo you can look here: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdeextragear-1/amarok/amarok/playlistloader.cpp?rev=1.62&content-type=text/x-cvsweb-markup Also will QLocale::system() not give the system locale? Then we can convert to that? Is the issue here that id3 tags have no locale support? Sorry for my ignorance on this topic, I do want to solve the problems however. Although I preferably don't want to read a manual about encoding.
For id3v1, it could be encoded in user's locale(most cases) or utf8(so it may works better with players written in gtk2), and there is no explicit info regarding this. For id3v2, there is a language field which is used to describe the language the tag using(but this field might missing). Amarok, as well as JUK, are now using TagLib to read the id3 tags, so it would better to leave this part(id3 handling) untouched and let TagLib to fix it(and we can say, it's not the fault of amarok). For filename/path handling, we could use QTextCodec::codecForLocale() to do the work(I will submit a patch later, hope this would work on non-latin1 as well as utf8 locales). About QLocale..I got to know it today, and it's a new class in QT3.3, but I'm still running qt 3.2.3 ;) CJK(as well as utf8) support, is one of the most important things many ppl concern when rating a media player. That's why xmms are still living and popular. btw, KDE also has problem in reading mp3's tag ;)
Just compiled the new cvs, it works fine. About the patch, I read the QT api again, it says: QCString QString::local8Bit () const Returns the string encoded in a locale-specific format. On X11, this is the QTextCodec::codecForLocale(). On Windows, it is a system-defined encoding. On Mac OS X, this always uses UTF-8 as the encoding. See QTextCodec for more diverse coding/decoding of Unicode strings. But there is also an QString::utf8()...I have no experience with UTF8 locales, will QString::local8Bit() returns the same thing as QString::utf8() on a utf8 system? Also, I noticed that amarok has already used lots of local8Bit() to handle the filename(before I patched it, that's why it can accept non-latin1 file). I hope the local8Bit() would works fine in CJK as well as utf8 locales(on filename handling). Some user feedback is definitely necessary, but now, mark the bug as "closed" should be ok.
I'm kind of losing track of all these filename handling bugs, but with amarok 1.2.3 and KDE 3.3.2, it's failing to properly handle playlists saved by JuK which have files with UTF8 chars in their filenames. File is found in collection and an entry is made in playlist, but metadata is not retrieved from the file as it is trying to retrieve the wrong file. When examining the file from the collection browser, metadata can be loaded but path is still displayed incorrectly in the "View/Edit Metainformation" dialog.