[Bug 676044] New: MP3: Seeking within an MP3 file results in sample being missed

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=676044
  GStreamer | gst-plugins-ugly | 0.10.30

           Summary: MP3: Seeking within an MP3 file results in sample
                    being missed
    Classification: Platform
           Product: GStreamer
           Version: 0.10.30
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-ugly
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: dsi.maillist at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=214027)
 --> (https://bugzilla.gnome.org/attachment.cgi?id=214027)
MP3 Audio Stereo 44.1 KHz

Hello,
I am developing an application that allows user's to read a portion of audio
data from MP3 files. However, I am running into an issue when doing so. I am
using playbin2 to read the file. The "audio-sink" property of playbin2 is
attached to an appsink from which the data is retrieved. I am attaching a
sample MP3 file that reproduces this issue. The audio data in the file has a
sample rate of 44100 Hz. I was able to reproduce the exact behavior described
below for a few additional MP3 files with sample rate of 44100 Hz.

Let completeData represent all samples in the audio file. 

The values below are from channel 1 for samples 13844 to 13854:
 0.316376682370901
 0.303280074149370
 0.285844162106514
 0.269042219966650
 0.253066271543503
 0.234786733984947
 0.220207855105400
 0.209734652191401
 0.199726730585098
 0.191084932535887
 0.181985512375832

Let partialData48, represent all samples in the audio file starting at sample
#13848 until the end of the file. The values below are from channel 1 for the
first 10 values in this matrix.
 0.253066271543503
 0.234786733984947
 0.220207855105400
 0.209734652191401
 0.199726730585098
 0.191084932535887
 0.181985512375832
 0.168748367577791
 0.153032332658768
 0.137647841125727

Let partialData49, represent all samples in the audio file starting at sample
#13849 until the end of the file. The values below are from channel 1 for the
first 10 values in this matrix.
 0.234786733984947
 0.220207855105400
 0.209734652191401
 0.199726730585098
 0.191084932535887
 0.181985512375832
 0.168748367577791
 0.153032332658768
 0.137647841125727
 0.120082158595324

Let partialData50, represent all samples in the audio file starting at sample
#13850 until the end of the file. The values below are from channel 1 for the
first 10 values in this matrix.
 0.209734652191401
 0.199726730585098
 0.191084932535887
 0.181985512375832
 0.168748367577791
 0.153032332658768
 0.137647841125727
 0.120082158595324
 0.097348991781473
 0.072948530316353

Let partialData51, represent all samples in the audio file starting at sample
#13851 until the end of the file. The values below are from channel 1 for the
first 10 values in this matrix.
 0.199726730585098
 0.191084932535887
 0.181985512375832
 0.168748367577791
 0.153032332658768
 0.137647841125727
 0.120082158595324
 0.097348991781473
 0.072948530316353
 0.053289752453566

Looking at the values shown above, the last 9 shown values of partialData48
match the first 9 shown values of partialData49. This is expected. 

However, when comparing partialData49 and partialData50, it can be seen that
the value 0.220207855105400 (second shown value in partialData49) which is
expected to be the first value in partialData50 is skipped. This seems to
indicate that sample #13850 is skipped.

Additionally, when seeking to any sample index greater than 13849 (for example:
170000), the data is offset by 1 sample. This offset is a result of sample
number 13850 being skipped during seeking/reading.

I am doing the seek programmatically using gst_element_seek_simple. 

Is this a known issue? Are there any workarounds for this?

Regards,
Dinesh

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.