Description of problem: I had this problem before in FC4 ~ 18 months ago. The problem went away in FC5 and now I see it again in FC6. I do not know whether the problem happened from the 1st day I ran FC6. I only noticed it today. BTW truncations are occuring with english language tracks so no invalid encoding with utf-8 problem.... This bug was filed with livna https://bugzilla.livna.org/show_bug.cgi?id=1468 Original bug above has a link to a file exhibiting the problem which will be removed late next week. Status of Livna bug resolved as "Invalid" because reading of mp3 tags is not patented and hence part of Fedora Core. Amarok shows the tags correctly (no truncation) for the same tracks exhibiting problems. It looks like the same problem as in FC4 whereby the component reading tags gives precedence to shorter version 1 tags over version 2 tags which must be shorter? Title tag truncated with 31 chars (string picked up from properties in rhythmbox): echo "Once Upon a Time in America: M" | wc 1 7 31 All tracks created in grip using "external" lame with switches --preset standard --ta %A --tl %d --tt %n --tn %t --ty %y --tg %g %w %m I have the same music collection at work on an FC5 box and the title of the same tracks exhibiting these problems on FC6 are not truncated. Version-Release number of selected component (if applicable): rpm -qa | egrep "(gstreamer|rhythm|totem|xine|id3|amarok)" gstreamer-plugins-good-0.10.4-3.fc6 gstreamer-plugins-ugly-0.10.5-1.lvn6 xine-lib-1.1.4-3.fc6 gstreamer-plugins-base-0.10.10-1.fc6 libid3tag-0.15.1b-3.fc6 gstreamer08-0.8.12-8.fc6 rhythmbox-0.9.7-1.fc6 kid3-0.8.1-1.fc6 xine-lib-extras-nonfree-1.1.4-1.lvn6 amarok-extras-nonfree-1.4.4-1.lvn6 gstreamer-0.10.10-2.fc6 xine-0.99.4-10.lvn6 id3lib-3.8.3-15.fc6 totem-xine-2.16.4-1.lvn6 amarok-visualisation-1.4.5-4.fc6 gstreamer-tools-0.10.10-2.fc6 xine-lib-devel-1.1.4-3.fc6 amarok-1.4.5-4.fc6 totem-xine-mozplugin-2.16.4-1.lvn6 How reproducible: For a given track with long strings: Always. Does not happen with all mp3 having long tracks/titles. Steps to Reproduce: 1. Run rhythmbox on mp3 file 2. Some longer track/album titles truncated Actual results: "Once Upon a Time in America: M" Expected results: "Once Upon a Time in America: Main Theme" Additional info:
Running the same test as done by the livna maintainer.. so it is not id3demux which is causing the problem: gst-launch-0.10 filesrc location= ~/mp3/soundtracks/ennio_morricone/ennio_morricone-yoyo_ma_plays_ennio_morricone-10-once_upon_a_time_in_america_main_theme.mp3 ! id3demux ! fakesink -t Setting pipeline to PAUSED ... Pipeline is PREROLLING ... TAG DECOUVERT : decouvert par l'element "id3demux0". titre: Once Upon a Time in America: Main Theme artiste: Ennio Morricone album: Yo-Yo Ma Plays Ennio Morricone date: 2004-01-01 commentaire: Created by Grip numéro de piste: 10 genre: Soundtrack encoder: LAME v3.96.1 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 5109000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ...
Some more info, I did the initial investigation of this at livna, you should be able to reproduce this without any livna stuff. I did an "rpm -e gstreamer-ffmpeg gstreamer-plugins-bad gstreamer-plugins-ugly" and I could still reproduce this. I could no longer hear the actual music of the file the livna BZ ticket points to, but in totem (which displays the same behaviour) the title still was shortened to: "Once Upon a Time in America: M" instead of: "Once Upon a Time in America: Main Theme", notice how it is cut off at exactly 32 chars.
What's the output of: gst-launch-0.10 -t filesrc location=~/mp3/soundtracks/ennio_morricone/ennio_morricone-yoyo_ma_plays_ennio_morricone-10-once_upon_a_time_in_america_main_theme.mp3 ! decodebin ! fakesink ?
Here it is: gst-launch-0.10 -t filesrc location=~/mp3/soundtracks/ennio_morricone/ennio_morricone-yoyo_ma_plays_ennio_morricone-10-once_upon_a_time_in_america_main_theme.mp3 ! decodebin ! fakesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... TAG DECOUVERT : decouvert par l'element "id3demux0". titre: Once Upon a Time in America: Main Theme artiste: Ennio Morricone album: Yo-Yo Ma Plays Ennio Morricone date: 2004-01-01 commentaire: Created by Grip numéro de piste: 10 genre: Soundtrack encoder: LAME v3.96.1 TAG DECOUVERT : decouvert par l'element "id3demux1". titre: Once Upon a Time in America: M artiste: Ennio Morricone album: Yo-Yo Ma Plays Ennio Morricone date: 2004-01-01 numéro de piste: 10 genre: Soundtrack TAG DECOUVERT : decouvert par l'element "mad0". durée: 108000000000 bitrate: 227311 TAG DECOUVERT : decouvert par l'element "mad0". layer: 3 mode: joint emphasis: none audio codec: MPEG-1 layer 3 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 2729418000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ...
The problem is LAME's, though similar problems happen with easytag for example (see bug 200507), when multiple tag sets are in one file. See also the upstream bugs: http://bugzilla.gnome.org/show_bug.cgi?id=424629 http://bugzilla.gnome.org/show_bug.cgi?id=362876 I'll leave this as assigned as Rhythmbox could be trying to ignore truncated tags.
Created attachment 152154 [details] rb-shorter-duplicate-tags.patch Something like that should help.
Filed upstream as http://bugzilla.gnome.org/show_bug.cgi?id=428276
Am I thinking about this the right way ? From the Appendix in http://www.id3.org/id3v2-00 which talks about v1 tags A.2. ID3v1 Implementation The Information is stored in the last 128 bytes of an MP3. The Tag has got the following fields, and the offsets given here, are from 0-127. Field Length Offsets Tag 3 0-2 Songname 30 3-32 Artist 30 33-62 Album 30 63-92 Year 4 93-96 Comment 30 97-126 Genre 1 127 Does it make sense to have v1 tags for backwards compatibility for players that can not read longer tags? The standard for v2 does not explicitly say that both types of tags can co exist. I suspect that you think that having both types is an abuse of the v2 standard? It is tough to argue against you in this regard!