Created attachment 214027 [details]
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