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 304758 - [PATCH] Seeking in pipelines with mad mp3 decoder introduces noise in the audio
[PATCH] Seeking in pipelines with mad mp3 decoder introduces noise in the audio
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
git master
Other Linux
: High normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-05-19 12:36 UTC by Wouter Paesen
Modified: 2008-05-06 12:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Testcase for this problem. (1.42 KB, application/gzip)
2005-05-19 12:37 UTC, Wouter Paesen
  Details
Proposal for avoiding this behaviour (8.66 KB, patch)
2005-05-19 14:21 UTC, Wouter Paesen
none Details | Review
Same patch but this one applies on gst-plugins-0.8.9 release (9.14 KB, patch)
2005-05-30 09:05 UTC, Wouter Paesen
needs-work Details | Review
cleaned up the code (9.03 KB, patch)
2005-06-14 09:33 UTC, Wouter Paesen
reviewed Details | Review

Description Wouter Paesen 2005-05-19 12:36:29 UTC
Testcase will be attached.
Comment 1 Wouter Paesen 2005-05-19 12:37:31 UTC
Created attachment 46636 [details]
Testcase for this problem.  

Use make to generate an mp3 file to test the program on.
Comment 2 Wouter Paesen 2005-05-19 14:21:08 UTC
Created attachment 46641 [details] [review]
Proposal for avoiding this behaviour

While this is probably considered as a dirty hack, it add's sample accurate
seeking with mad.  It add's a sync-timeout parameter which defines a sync
timeframe.  When doing a normal seek, we actually seek to seek_time -
sync-timeout and set the segment_start.  In the chain function we check if the
newly decoded data timestamp and duration agains the segment_start and discard,
cut or just pass the decoded data.
Comment 3 Wouter Paesen 2005-05-30 09:05:56 UTC
Created attachment 47020 [details] [review]
Same patch but this one applies on gst-plugins-0.8.9 release
Comment 4 Ronald Bultje 2005-06-09 17:22:20 UTC
You duplicate a lot of code by doing this. Can you do that nicer by refactoring
that part into its own function?
Comment 5 Christian Kirbach 2005-06-09 21:01:52 UTC
Thanks for sending in.
Raising priority to make maintainers aware of patch.
Comment 6 Wouter Paesen 2005-06-14 09:33:00 UTC
Created attachment 47746 [details] [review]
cleaned up the code 

Cleaned up the code as suggested
Comment 7 Andy Wingo 2006-01-13 16:48:14 UTC
Hi Wouter,

Thanks for the patches. A few comments:

1) Try to avoid whitespace changes

2) New code should be in GStreamer style (see the faq)

3) 0.8 is unmaintained now; could you take a look at 0.10 and see what needs to be done?

Thanks!
Comment 8 Jan Schmidt 2006-01-31 23:56:49 UTC
I suspect that the noise you're experiencing actually stems from MAD synchronising  on a false synch-sequence in the mp3 data. 

I know I had some trouble making the Fluendo mp3 plugin synch detection robust enough to avoid this problem. The seeking output there is considerably different.

There's some sample output seeking around on the sample sine wave mp3 from the testcase here, to compare the output from mad and flump3dec: http://noraisin.net/~jan/gst/mad_seek_problem/ 
Comment 9 André Klapper 2006-10-01 14:22:38 UTC
Wouter, can you please try to answer Andy's comment?
Comment 10 Wouter Paesen 2006-10-02 12:26:39 UTC
I lost track of this bug completely.  

Currently I'm looking into what needs to be done, but my spare time is scarce as is my knowledge of 0.10.  I'm not sure on how to transform the seek in the segment philosophy of 0.10.  I would appreciate any input on this.
Comment 11 Sebastian Dröge (slomo) 2008-05-06 12:14:25 UTC
This bug should be fixed by mp3parse in gst-plugins-ugly 0.10.7. It supports accurate seeking and correctly resyncs on mp3 frames in almost every case.

If you believe that this bug is still valid please reopen :)