Version: 1.2.1 (using KDE KDE 3.3.0) Installed from: SuSE RPMs OS: Linux When updating the Meta Information on mp3-files with international characters in the filename, the changes are not saved. There's no errormessage, but the old data remains even after pressing "Save & Close" button. Examples are filenames with special Norwegian characters æ, ø and å (as in file "Bjørn Eidsvåg - Eg Ser.mp3" and also on the Spanish é and ñ etc... The current workaround is to rename the file to English characters only, update the Meta Information, and then rename back (ie. rename to "Bjorn Eidsvag - Eg Ser.mp3") PS. Sorry I have not had a chance to try this in 1.2.2 released today (I'm on 1.2.1). However, this bug was not listed anywhere in the changelog or on open bugs, so I wanted to bring it to your attention. Thank you for listening!
On Tuesday 15 March 2005 10:03, Halim I wrote: [bugs.kde.org quoted mail] I am successfully able to write in Hebrew - and that is a totally different character set
To reproduce, please try to rename an MP3 file to "Bjørn Eidsvåg" (copy paste, as you probably don't have ø and å on your hebrew keyboard ;) ) and then update the Meta Information within to let's say change Genre from Pop to Rock and see whether or not it "sticks"... I have done this on 2 different machines with the same result.
Upgraded to 1.2.2 and the problem went away. Tried with Norwegian and Arabic charecters without problems. Closing this Bug.
I'm running 1.2.3 on a Debian unstable system, and I'm seeing this problem too. There are actually two problems: 1. If the filenames contain invalid unicode, the tags are not updated at all (common with downloaded files... I use utf-8 in my filesystem). But that's ok, I must rename my files anyway. 2. If a file name contains international characters (åäöéè in my case), any editing is not displayed in the Collection, but the file is actually edited. Manually choosing Tools->rescan results in a correct display. This bug should be reopened, but I can't do it.
Alright. Some things with this that I've noticed. So we have: Rinôçérôse - Installation Sonore - 05 - 323 Secondes de Musique Répétitive Avec Guitare Espagnole as our [artist] - [album] - [track] - [title], in foobar2000-written utf-16 (no endian-ness specified). Before doing anything, I check it with eyeD3 (a program that is very useful for finding information about id3 tags in files) - and we see that it is id3 v 2.3. This is important. Continuing, Say I want to change it slightly, maybe add a comment "test"; for the sake of example. I try to change it. Now, if I were to change the title instead, I won't see it changed in the list as I would have expected - this point included for the sake of verbosity. But since I added a comment, I want to check that it's there. I open the tag editor again in amarok - nothing in the comment field. I then look at it with the KDE "meta-data" tab in the file's properties window, it looks fine, with added comment. Then I rescan the music database within amarok. The comment appears as normal. Then, I check the id3 tag with eyeD3 again - it is now id3 v 2.4, instead of 2.3. (IMPORTANT!) So, what we can gather from this is that one thing that might be causing our problems is in the id3 version 2.3/2.4 differences, being that 2.3 doesn't support UTF-8. I do some more tests, here are the results: utf16-BE id3v2.3: displays correctly, edit causes corruption and changes id3 to v 2.4 utf16-LE id3v2.3: displays correctly, edit does not cause corruption and changes id3 to v 2.4 utf16-BE id3v2.4: displays correctly, edit causes corruption utf16-LE id3v2.4: displays correctly, edit does not cause corruption NOTE THAT ID3v2.3 DOES NOT SUPPORT UTF-8 utf-8 id3v2.4: displays correctly, edit does not cause corruption So what we have here that's causing the problem is editing a tag with UTF-16 Big Endian encoding. Now here's the real strange thing. `id3tag <file>` will repair any corruption that amarok does. It probably realizes that whatever program wrote the tag specified the wrong endian-ness. And yet, when executed on files that amarok _can_ read, it changes them somehow to the point where amarok doesn't show _any_ trace of that music file in the database, not even under a corrupted name. KDE's 'metadata' tab still displays most of the thing correctly, except for the international characters are blocks now (whereas the corruption that amarok makes is _really_ corrupted) I think this is a major problem with the whole id3 lib in general. Both taglib and id3lib. There's work to be done on this...
I must ammend the end of that comment. It only appears to fix it because it must remove the invalid id3v2 tag altogether. The song is cut to 30 chars meaning it's now reading the id3v1 tag. so id3tag does not have the ability to fix the corruption after all, just remove or invalidate bad tags.
Using amaroK 1.3-beta2, this problem still exists. The metadata dialog accepts all characters without any erro message, but saving mp3 tags doesn't work if the filename contains international (West European) characters. Mass tagging files via the collection browser (i.e. changing wrong genre tags) works fine for all files except those with international characters. Changing tags in the playlist ('Edit genre tag') and copying tags (Set genre tag for selected) works, though.