GNOME Bugzilla – Bug 664433
playbin: wrong track position information when played in gapless mode
Last modified: 2013-08-16 11:28:07 UTC
This was originally reported as a bug in Banshee, but I believe that it is more accurately a bug/shortcoming in GStreamer: https://bugzilla.gnome.org/show_bug.cgi?id=664402 In short, when playing a FLAC file in Banshee with gapless mode, GStreamer reports track position (gst_element_query_position) as the total amount of play time since the last stream start or seek, as opposed to the actual position in the current track. When I play OGG Vorbis files in the same setup, GStreamer reports the correct position. I believe this is because GStreamer has plugins for parsing Vorbis files (ext/vorbis/gstvorbisparse.c) and it does not for FLAC. If this is correct, a parser is needed for FLAC to enable correct position reporting with gapless playback.
> I believe this is because GStreamer has plugins for parsing Vorbis files > (ext/vorbis/gstvorbisparse.c) and it does not for FLAC. If this is correct, a > parser is needed for FLAC to enable correct position reporting with gapless > playback. There is a flac parser, and the vorbis parser is not used in playbin2, so that's unlikely to be the reason. It does sound like it could be a problem in GStreamer, however, assuming "Banshee with gapless mode" is still using playbin2. What's the output of: $ gst-inspect-0.10 playbin2 | grep Version $ gst-inspect-0.10 flacdec | grep Version $ gst-inspect-0.10 flacparse | grep Version
rlange@asar:~$ gst-inspect-0.10 playbin2 | grep Version Version: 0.10.35 rlange@asar:~$ gst-inspect-0.10 flacdec | grep Version Version: 0.10.30 rlange@asar:~$ gst-inspect-0.10 flacparse | grep Version Version: 0.10.30 Any idea how can I tell if Banshee is using playbin2? I can definitely see that it is using a "playbin", but how can I tell if it's playbin2? I found gstflacparse.c in the bad plugins. I hadn't searched for it there before, because I assumed it was part of the good set. Any idea where the position gets reset for Vorbis files? That would help me to track down how to reset it for FLAC. I know nothing about decoding audio, so anything I try will be a pure guess.
There is also a gstflacdec.c in the good plugins. Didn't notice it before because I mistook the base plugins for the good plugins. Still no closer to figuring out where I should expect to find the reset function...
Upon further examination, Banshee does use playbin2.
https://bugzilla.gnome.org/show_bug.cgi?id=584987 The above report may be related to this bug, but I am having a hard time understanding what they are talking about.
It is possible that FLAC element(s) report the wrong time, it's a common enough bug. Does the same issue show up in, say, Totem, for the same files ? If so, it's almost certainly an issue in one of the FLAC elements, and a short test file would be good to have to check any fix.
I used short flac samples from: http://ff123.net/samples.html Specifically, I created a playlist with the following two samples in this order: http://ff123.net/samples/taxman.flac http://ff123.net/samples/queen%20-%20another%20one%20bites%20the%20dust%20(9%20sec.).flac Taxman is 13 seconds long; Queen is 9 seconds long. On VLC and Totem, the time correctly rolled over when switching from Taxman to Queen. On Banshee, when the switch to queen occurred, the time widget went from 0:13/0:13 (seconds) to 0:14 and counted up from there. Clearly, Banshee is not registering the switch-over as far as its time widget is concerned.
So it works in Banshee and Totem for Vorbis, and works in Totem but not in Banshee for FLAC, am I reading that correctly ? Seems odd, as both Banshee and Totem use gstreamer. Banshee and Totem may be using a different way to determine current position.
totem is not using the gapless mode, while banshee does. FLAC files work fine for me with metadata and position reporting now though with latest git master. Can someone still reproduce this?