After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 676044 - MP3: Seeking within an MP3 file results in sample being missed
MP3: Seeking within an MP3 file results in sample being missed
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
0.10.30
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-05-14 19:36 UTC by Dinesh Iyer
Modified: 2013-07-17 16:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
MP3 Audio Stereo 44.1 KHz (330.82 KB, audio/mp3)
2012-05-14 19:36 UTC, Dinesh Iyer
Details

Description Dinesh Iyer 2012-05-14 19:36:13 UTC
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
Comment 1 Tim-Philipp Müller 2012-11-25 16:24:53 UTC
Could you provide a test program please?

And a GST_DEBUG=*:5 log? (*:6 for 1.0.x)
Comment 2 Edward Hervey 2013-07-17 15:55:39 UTC
Dinesh ? could you reply to tim's question ?
Comment 3 Sebastian Dröge (slomo) 2013-07-17 16:13:03 UTC
Closing as there was no reply to the question since more than half a year. Please reopen if this is still a problem with 1.0 and provide the requested information.