GNOME Bugzilla – Bug 580318
[tagdemux] drops tag events from upstream
Last modified: 2009-05-31 22:40:45 UTC
Please describe the problem: In an mp3 file, with multiple metadata tags, the first being an apev2 tag containing replaygain values (replaygain-track-gain, replaygain-track-peak), and the second tag containing values like artist, title etc, rgvolume does not work. It doesn't seem to receive the replaygain tag. This holds true if the second tag (artist, title...) is either apev2 or id3. Steps to reproduce: 1. Create a file with one apev2 tag containing title info. gst-launch alsasrc ! taginject tags="title=test" ! audioconvert ! lame ! apev2mux ! filesink location=firstpass.mp3 2. Add a second tag with replaygain information. gst-launch filesrc location=firstpass.mp3 ! taginject tags="replaygain-track-gain=-0.46,replaygain-track-peak=0.856934" ! apev2mux ! filesink location=secondpass.mp3 3. export GST_DEBUG=rgvolume:3 gst-launch -t filesrc location=secondpass.mp3 ! decodebin ! audioconvert ! rgvolume ! fakesink Actual results: rgvolume does not set the result gain to match target. it doesn't see the tag containing replaygain values. Expected results: rgvolume should set the result gain to match target. Does this happen every time? yes. Other information: This bug could be related to this one: http://bugzilla.gnome.org/show_bug.cgi?id=556734
Created attachment 133354 [details] An mp3 file created according to the steps in the report
Created attachment 133355 [details] Debug Log with: GST_DEBUG=2,*rgvolume:5,*tagdemux:5
By printing out the received tags from inside rgvolume (gst_rg_volume_tag_event), it is seen that the tags received are: taglist, title=(string)test; taglist, audio-codec=(string)"MPEG\ 1\ Audio\,\ Layer\ 3\ \(MP3\)"; taglist, bitrate=(guint)128000, has-crc=(boolean)false, channel-mode=(string)joint-stereo; in that order. The taglist containing replaygain values are missing.
I can see the tags: > gst-launch playbin uri=file://$PWD/secondpass.mp3 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "apedemux0". replaygain track gain: -0.460000 replaygain track peak: 0.856934 FOUND TAG : found by element "apedemux1". title: test FOUND TAG : found by element "mpegaudioparse0". audio codec: MPEG 1 Audio, Layer 3 (MP3) FOUND TAG : found by element "mpegaudioparse0". bitrate: 128000 has crc: FALSE channel mode: joint-stereo FOUND TAG : found by element "mad0". layer: 3 mode: joint emphasis: none bitrate: 128000 Its a bit funky that there are two apedemux elements though.
> I can see the tags: That's because you're looking in the wrong place :) Try: gst-launch-0.10 filesrc location=580418-two-ape-tags-in-a-row.mp3 ! decodebin ! fakesink -v 2>&1 | grep taglist /GstPipeline:pipeline0/GstFakeSink:fakesink1: last-message = "event ******* E (type: 118, taglist, title=(string)test;) 0x8c010a0" /GstPipeline:pipeline0/GstFakeSink:fakesink1: last-message = "event ******* E (type: 118, taglist, audio-codec=(string)\"MPEG\\ 1\\ Audio\\,\\ Layer\\ 3\\ \\(MP3\\)\";) 0x8c01118" /GstPipeline:pipeline0/GstFakeSink:fakesink1: last-message = "event ******* E (type: 118, taglist, bitrate=(guint)128000, has-crc=(boolean)false, channel-mode=(string)joint-stereo;) 0x8c01140" It's a bug in tagdemux. Will have a look and make a patch later this evening if no one else is faster.
Created attachment 133444 [details] [review] possible fix: cache incoming events if we haven't sent a newsegment downstream yet
commit 3d33e2a8737577408747c52406e397802b2ae315 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Fri May 1 00:09:15 2009 +0100 tagdemux: cache events from upstream and re-send them once we have a source pad Makes sure tags don't get dropped when we have multiple tag demuxers in a row. Fixes #580318.
*** Bug 556734 has been marked as a duplicate of this bug. ***