GNOME Bugzilla – Bug 603695
Innaccurate seeking in MP3 files results in cut off playback
Last modified: 2010-01-04 19:05:16 UTC
Summary: I have the problem that seeking in MP3 files is not reliable, which results in playback getting cut at the end of a file. How I discovered the problem: I have some radio dramas as MP3 files. Each episode is about 20 minutes long. I used Totem on my Ubuntu 9.10 installation for my tests. When I start to play one of these episodes and let it run until the end, everything is fine, the playback is exactly as long as I expect it. But when I start to playback and then seek to the middle and then let it play until the end, I noticed that a few seconds are cut off at the end of the playback. How I tried to create an artifical test: In order to further analyse this, I recorded an audio file where I count from 0 to 59. Then I used an audio editor to exactly align the spoken words to the exact second they represent. Next I encoded it to MP3 and did the test again with this artifical data. Outcome of test: I noticed that when seeking in Totem, the playback can be off by 4 seconds. That means, the display in totem is at 47 seconds, but from the loudspeaker you hear the spoken "43". With my 20 minute testfile, the seeking is more off towards the end of the file. Just try to seek to around 18 minutes. Now when you let the file play until the end, Totem will stop the playback when the 20 minutes are reached. But the playback is only at 19:56, which means that the last 4 seconds of the playback are cut off. Other tests: When I encode the audio file to OGG or WAV, then seeking is accurate and the playback won't be cut at the end. I tried different bitrates for MP3 and CBR and VBR as well, but the problem remains. Wrap-up: I think there is a bug with regard to seeking in MP3 files somewhere. Test files: I put the test file on my web page, because it's too big for an attachment. The MP3 is 20 minutes long and the size is about 15Mb. You can download it here: http://www.mihu.de//mrec_vbr_192max.mp3
Probably the application isn't doing accurate seeks. Normally that's good, because accurate seeks in mp3 are _sloooow_ since it has to scan the entire file. But we shouldn't be giving a segment end time in this case, so it should just go until it runs out of data. I wonder what's regressed there?
It seems that mp3parse timestamps and reports times ahead of what they should be. Thus the position reporting in totem is wrong and the time end of the segment ends earlier, causing some element to return UNEXPECTED and an EOS to happen.
Right - but mp3parse shouldn't be specifying a segment end time in this case at all.
What happens here is that mp3parse maps the seek it receives (with stop-time=-1) to bytes and pushes it upstream, then filesrc processes it and sends new-segments downstream containing a stop-time (which is the length of the file instead of -1), then mp3parse maps it to the time format and results in the 20secs limit.
Created attachment 149379 [details] [review] Do not overwrite stop-time for seeks
I can confirm that the patch by Thiago Sousa Santos modifies the behaviour in the following way: the seeks are not accurate, but the playback will continue until the end of the file. In Totem, the file is played back until the very end. Due to the inaccurate seek, however, the playback time becomes bigger than the total file playback time, ie. towards the end it shows "20:02 / 20:00" and counting. For me this is acceptable and only a cosmetic problem. I vote to push this fix upstream.
Module: gst-plugins-ugly Branch: master Commit: 5e3f07b6a1b259cd3c73fa7fe6e3a3110ae3e3ce URL: http://cgit.freedesktop.org/gstreamer/gst-plugins-ugly/commit/?id=5e3f07b6a1b259cd3c73fa7fe6e3a3110ae3e3ce Author: Thiago Santos <thiago.sousa.santos@collabora.co.uk> Date: Tue Dec 8 19:55:04 2009 -0300 mp3parse: conserve stop time for non-accurate seek Use the same strategy as accurate seeks to store pending non-accurate seeks to avoid overwriting non-definite stop times. When doing non-accurate seeks our position reporting might drift off by some secs and the stream can end up before it should. Fixes #603695