After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 391544 - Incorrect display of UTF8 id tags
Incorrect display of UTF8 id tags
Status: RESOLVED DUPLICATE of bug 424629
Product: rhythmbox
Classification: Other
Component: general
0.9.6
Other All
: Normal minor
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-01-01 15:35 UTC by jipmanvuong
Modified: 2008-06-08 01:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description jipmanvuong 2007-01-01 15:35:38 UTC
Please describe the problem:
When browsing/playing some mp3's with japanese titles some of the id3 tags are incorrectly displayed

Opening the same file in totem or opening the "audio" tab in the file's properties shows correct tag information.





Steps to reproduce:
1. Get an mp3 that has such id3 tag (for example: http://www.yousendit.com/transfer.php?action=download&ufid=065547DC21DB70A4 (hope no one minds) )
2. Open it in totem, rhythmbox and view it's properties
3. Notice the difference/errors in the tags


Actual results:
This is what nautilus says : http://img79.imageshack.us/my.php?image=nautiluspropertiesvh5.png

And totem:
http://img79.imageshack.us/my.php?image=totemmainvw9.png

And finally rhythmbox
http://img92.imageshack.us/my.php?image=rhythmboxmainrs9.png

Also, I can't explain why the artist field in rhythmbox is so weird in comparison to the rest.

Expected results:
Correctly displayed tag information

Does this happen every time?
yes

Other information:
This happens both on my notebook and my desktop.

Locale info:
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
Comment 1 Jonathan Matthew 2007-01-01 21:49:25 UTC
This is probably caused by the ape tags present in the file, which contain different values for the artist and title fields.

gst-launch-0.10 (using CVS HEAD-ish of gstreamer+plugins) says:

FOUND TAG      : found by element "id3demux0".
           title: 君の愛に包まれて痛い
          artist: U-ka Saegusa IN db
           album: U-ka saegusa IN db III
            date: 2006-01-01
    track number: 3
           genre: Jpop
     ID3v2 frame: buffer of 33 bytes, type: application/x-gst-id3v2-tope-frame, version=(int)3
        duration: 196000000000
FOUND TAG      : found by element "apedemux0".
            date: 2006-01-01
          artist: 皉浀狦 IN db
           album: U-ka saegusa IN db III
         comment: www.j-pop.cn
           genre: Pop
    track number: 3
           title: 君愛痛

Currently, rhythmbox takes the last value it receives for each field, so in this case it will use the values from the ape tags rather than the id3 tags.
Comment 2 jipmanvuong 2007-01-02 04:38:46 UTC
I see, but since this can cause confusion, would it not be wise to show the other tag in a tab in properties or at the least show a message that another tag was found?
Comment 3 Jonathan Matthew 2007-01-02 10:34:25 UTC
I don't think there's much to be gained by doing that.  I don't think most people are aware that multiple tag formats exist (many people refer to 'id3 tags' even when they're talking about ogg vorbis files), and there isn't much a user could do with the knowledge that their files contain multiple tag sets anyway.

I think the best thing we can do is silently ignore ape tags when id3v2 tags are found in the same file.
Comment 4 Jonathan Matthew 2008-06-08 01:38:12 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.


*** This bug has been marked as a duplicate of 424629 ***