GNOME Bugzilla – Bug 548711
id3demux can't parse id3v2 tags on PPC
Last modified: 2008-08-21 01:45:14 UTC
Please describe the problem: On PPC, id3demux cannot parse any id3v2 tags out of an MP3 file. Instead, it defaults to parsing id3v1 tags, which results in a lower quality of information. This problem does not appear to affect x86. (Possible endianness bug?) Steps to reproduce: 1. Tag a file with an id3v2 tag. 2. Use gstreamer to parse it. 3. Gape in horror. Actual results: Gstreamer fails to interpret id3v2 tags. Expected results: Gstreamer should interpret id3v2 tags. Does this happen every time? Darn tootin'. Other information: [alex@localhost tmp]$ id3v2 -l id3v2_test.mp3 id3v1 tag info for id3v2_test.mp3: Title : This is a really, really long Artist: Some Artist Album : Whatever Year: , Genre: Unknown (255) Comment: Track: 0 id3v2 tag info for id3v2_test.mp3: TIT2 (Title/songname/content description): This is a really, really long title which can only be represented properly in id3v2. TPE1 (Lead performer(s)/Soloist(s)): Some Artist TALB (Album/Movie/Show title): Whatever [alex@localhost tmp]$ gst-launch-0.10 -t playbin uri=file:///tmp/id3v2_test.mp3 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". title: This is a really, really long artist: Some Artist album: Whatever track number: 0 FOUND TAG : found by element "mpegaudioparse0". audio codec: MPEG 1 Audio, Layer 3 (MP3) FOUND TAG : found by element "mpegaudioparse0". bitrate: 64000 has crc: FALSE channel mode: mono FOUND TAG : found by element "mad0". layer: 3 mode: mono emphasis: none bitrate: 64000 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstAudioSinkClock Got EOS from element "playbin0". Execution ended after 15144406000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... [alex@localhost tmp]$
Sorry, same question as in the WAV bug ;) What's your distribution and your glib version? Also what's G_BYTE_ORDER in /usr/include/glib-2.0/glib/gtypes.h (or wherever your glib is installed)? I'm guessing that you are using glib 2.16.4 or used that version for compiling gst-plugins-good as it had a endianness bug on big endian machines.
A legitimate question. (But, the same question calls for the same answer.) Here's the relevant info: [root@localhost tmp]# uname -a Linux localhost.localdomain 2.6.25.14-108.fc9.ppc #1 Mon Aug 4 13:39:44 EDT 2008 ppc ppc ppc GNU/Linux [root@localhost tmp]# cat /usr/lib/glib-2.0/include/glibconfig.h | grep -i G_BYTE_ORDER #define G_BYTE_ORDER G_BIG_ENDIAN [root@localhost tmp]# rpm --query glib2 glib2-2.16.5-1.fc9.ppc [root@localhost tmp]# So the currently-installed Glib appears to be configured properly. However, I'm using my distro's GStreamer packages, so GStreamer wasn't necessarily compiled with this same glib setup. (#gstreamer at irc.freenode.net suggested I report with you guys {instead of,in addition} to with the fedora team.) I'm quite willing to compile and test to verify that it's actually a bug in GStreamer. (Although I would prefer to do my testing without disrupting my existing packages.) Any pointers?
I just built and tested CVS HEAD on my PPC, and verified that it doesn't appear to be a GStreamer bug. (Or, if it was, it's not there now.) I'm guessing my problems are due to faulty fedora packaging, so I'll take my reports to them. Thanks for your time, and sorry for any confusion.