Bug 7642 - (int-152311) Playback of MP3 files might be cut-off at the end after seeking in file
(int-152311)
: Playback of MP3 files might be cut-off at the end after seeking in file
Status: REOPENED
Product: Multimedia
gstreamer
: 5.0:(10.2010.19-1)
: N900 Maemo
: Low normal (vote)
: ---
Assigned To: unassigned
: gstreamer-bugs
: https://bugzilla.gnome.org/show_bug.c...
: upstream
:
:
  Show dependency tree
 
Reported: 2010-01-04 17:34 UTC by Michael Hunold
Modified: 2010-06-24 16:08 UTC (History)
1 user (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Michael Hunold (reporter) 2010-01-04 17:34:18 UTC
SOFTWARE VERSION:
1.2009.42-11

EXACT STEPS LEADING TO PROBLEM: 
1. Download http://www.mihu.de//mrec_vbr_192max.mp3 This is a MP3 file where
the numbers from one to ten are spoken exactly every second.
2. Start playback of MP3 file
3. Seek towards the end of the file, for example around 19:00
4. Let the playback continue until the end

EXPECTED OUTCOME:
The playback continues until the end of the file.

ACTUAL OUTCOME:
The playback does not continue until the end of the file and is cut off several
seconds before.

REPRODUCIBILITY:
always

EXTRA SOFTWARE INSTALLED:
should not matter

OTHER COMMENTS:
There is a bug in gst-plugins-ugly with regard to playback of files being cut
off at the end.

The reason is that seeking in MP3 files is inaccurate and becomes more and more
inaccurate to the end of very long MP3 files. If you seek towards the end of
such a long MP3 file and then let the playback run, several seconds worth of
audio data might be cut off at the end of the playback.

This bug was initially found on the N900, but could be reproduced on a desktop
installation of gstreamer as well.

The bug was reported to the gstreamer developers here:
https://bugzilla.gnome.org/show_bug.cgi?id=603695

It can be reproduced easily on a N900.

Of course it would be nice to fix seeking in MP3 files, but I understand that
there are technical limitations of the file format that make accurate seeking a
costly operation.

Nevertheless, even if seeking is inaccurate, the playback should continue until
the very end of the file.

As you can read in the gstreamer bug report, a fix will be included in
gst-plugins-ugly 0.10.14, so it would be nice if N900 developers pick up this
fix as well.

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6)
Gecko/20091215 Ubuntu/9.10 (karmic) Firefox/3.5.6
Comment 1 Andre Klapper maemo.org 2010-02-09 18:12:00 UTC
This seems to work fine in the internal release version 10.2010.03-0

A future public update will include the fix. (This is not always already the
next public update.)

To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Comment 2 Andre Klapper maemo.org 2010-03-15 20:55:48 UTC
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).
Comment 3 Michael Hunold (reporter) 2010-03-29 11:59:40 UTC
(In reply to comment #1)
> This seems to work fine in the internal release version 10.2010.03-0
> 
> A future public update will include the fix. (This is not always already the
> next public update.)

I'll leave the test file on my web site, so people can try if this works
correctly when then new version comes out.
Comment 4 Michael Hunold (reporter) 2010-06-14 12:29:10 UTC
(In reply to comment #1)
> This seems to work fine in the internal release version 10.2010.03-0

I'm sorry, but it is not fixed in PR1.2.

If you look at my original bug report to the GStreamer developers (link
mentioned above) the problem was found to be in the mp3parse element in
gst-plugins-ugly.

On my N900 with PR1.2, however, gst-plugins-ugly is not present (any more), so
parsing of the MP3 file is done by some other element.

"gst-launch-0.10 -v playbin2 uri=file:///home/user/MyDocs/mrec_vbr_192max.mp3"
shows thats probably GstNokiaMP3Dec is involved here.

Perhaps the bug fix with regard to mp3parse was ported to this element, but
this is pure speculation and way out of my scope.

Anyway, the problem is not fixed. As described above, the numbers 1 to 10 are
spoken throughout the file.

If you start playback of the file and jump to 19:45 for example, then you'll
hear that it's off-sync with regard to the time displayed. That's fine. But
when it reaches 20:00 the playback will be cancelled, although there are a few
seconds of playback left.

That's bad.
Comment 5 Andre Klapper maemo.org 2010-06-24 16:08:33 UTC
True.
Interesting that Totem 2.28.3 (GNOME default media player using gstreamer) also
still has the inaccurate seeking, however it at least plays the file until the
end (and displays 00:20:03 in the end for the file that is 00:20:00 long).