Version: (using KDE KDE 3.2.1) Installed from: SuSE RPMs OS: Linux I experienced a pretty serious bug in JuK when I use JuK, followed by XMMS. The song titles get completely messed up in XMMS. Copying the mp3 files to another dir did not change anything. The only conclusion I can draw is that JuK has altered mp3 tags. Even worse is that I have not found a way to alter the resulting garbage back to readable. Scott Wheeler already told me that XMMS has a serious bug that it does not handle unicode properly, and I guess that he is right. However, I think that if Juk would not have altered mp3 file information at all, XMMS would still happily display the titles. I suggest that JuK leaves the mp3 files untouched, unless explicitly allowed.
Guess who gets these bug reports. ;-) JuK doesn't edit files unless you change the information in them. If you change the tag content, of course it writes that back to the file. XMMS's ID3v2 parser has a bug in it that causes it to not parse unicode data properly -- I thought I made that pretty clear...
I knew you would get the bug reports, but you advised me to report this as a new bug :S Sorry for being so persistent. What I did was the following (forgive me if some translations are not right, I use a Dutch version): 1) first I decided to only show the fields Track - Artist - Length. 2) Then I noticed that some of the songse were displayed incorrectly. 3) I selected all, right-clicked the songs and chose "Guess Tag info" -> From filename. That is all I did. I did not change song/track/etc. names at all (because the file names were right ;) ). Then I noticed that the sound did not work as well with JuK as it used to in XMMS. So I decided to go back to XMMS (sound quality is more important than looks). I appeared to have turned 51 song titles into unreadable crap. The problem in XMMS is so serious that I can only display file names, and I have not found a way to remove the messed up text any other way (e.g. with "view file info"). Remember: Even when playing songs that I got from others in XMMS, I NEVER had a problem displaying the song titles. Even if it is a XMMS bug, this all points to a JuK problem. So, moral of the story is: Juk somehow has changed things in the mp3 files, without a warning. Juk looks great, but is not the only mp3 player in the world. So, I strongly recommend that this issue will be addressed. For fairness, I will also report the bug to XMMS. Cheers Scott Wheeler wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=79589 > wheeler kde org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |RESOLVED > Resolution| |INVALID > > > > ------- Additional Comments From wheeler kde org 2004-04-14 00:13 ------- > Guess who gets these bug reports. ;-) > > JuK doesn't edit files unless you change the information in them. If you change the tag content, of course it writes that back to the file. XMMS's ID3v2 parser has a bug in it that causes it to not parse unicode data properly -- I thought I made that pretty clear... >
"Guess Tag Information", well, guesses the tag information. I'm really not sure what you expected it to do. It then -- since you asked it to -- writes a perfectly valid tag to the file. XMMS then does not handle this perfectly valid tag properly. Again, this is not a bug in JuK. ;-) Of course it's not the only music player in the world, but it's not a JuK bug that it doesn't work around bugs in other players. Just to be a bit more specific: The bug is in lines 165-168 of Input/mpg123/id3_frame_text.c in the XMMS sources: if (*(guint8 *) frame->fr_data == ID3_ENCODING_ISO_8859_1) return g_strdup((char *) frame->fr_data + 1); else return id3_utf16_to_ascii(((char *) frame->fr_data + 1)); There it assumes that anything that is not ISO-8859-1 is UTF16. However if you look at section "4.2 - Text information frames" of http://www.id3.org/id3v2.4.0-frames.txt and section "4. ID3v2 frame overview" of http://www.id3.org/id3v2.4.0-structure.txt it clearly says: Frames that allow different types of text encoding contains a text encoding description byte. Possible encodings: $00 ISO-8859-1 [ISO-8859-1]. Terminated with $00. $01 UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All strings in the same frame SHALL have the same byteorder. Terminated with $00 00. $02 UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM. Terminated with $00 00. $03 UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00. Please report this to the XMMS developers. Even paste this in if you'd like. I can't be more explicit than this. ;-)
Thanks Scott, I opened a bug report in XMMS, and I will add your comments. I expected that only the way JuK displays file info would be changed, but apparently it does update that info in the mp3 file itself. Hopefully the XMMS guys will solve the problem. Thanks again.