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 632277 - Loud noise while seeking through MP3 song
Loud noise while seeking through MP3 song
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
0.10.10
Other Linux
: Normal minor
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-10-16 06:35 UTC by Sam
Modified: 2012-03-08 10:57 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sam 2010-10-16 06:35:16 UTC
When seeking through an MP3 file, once the seek bar has stopped moving there is a blast of noise that lasts for a split second. 

This is only true of MP3s. M4As and lossy WMAs do not display the same behavior, nor do FLAC or Vorbis files.
Comment 1 Sebastian Dröge (slomo) 2010-10-19 14:02:34 UTC
Which version of gstreamer, gst-plugins-base and gst-plugins-ugly do you use? Do you have the Fluendo MP3 decoder plugin installed? Does this happen for all MP3 files?
Comment 2 Sam 2010-10-20 20:44:33 UTC
I'm using Ubuntu 10.04, so all of this stuff is information I have from the packages.

I don't know how to get information about just the gstreamer package. Is there a specific package I should be looking at? 

gstreamer0.10-plugins-base 10.28-1
gstremer0.10-plugins-ugly 10.14-1

I did have fluendo installed when I filed this bug, but having it installed or not doesn't affect the bug. 

It happens for all mp3 files, but some are louder than others, and some occur more frequently, meaning that some will make the noise every time you seek whereas others will make it maybe every other time, or do it quietly. I'm thinking this may depend on the natural loudness of the song, or the bitrate the mp3 is sampled at.

Also: the sound sounds like a needle scratching across a record really super quickly. 

As a sidenote, I'm having to test this all through totem and rhythmbox. They both display the same bug in the same way.
Comment 3 Sebastian Dröge (slomo) 2010-10-25 12:58:53 UTC
If you play the same MP3 files in mplayer, VLC or xine for example, do you get the same behaviour?

You could also try if the updated packages from https://launchpad.net/~gstreamer-developers/+archive/ppa/+packages help with this problem.
Comment 4 Sam 2010-10-26 02:17:25 UTC
Totem, Rhythmbox and MPlayer all exhibit the bug. VLC and Xine do not. Though, with VLC I notice a delay from when you move the slider to when the updated music starts playing -- the same is true of Xine.

What I'm guessing is happening is that when Totem, Rhythmbox and Mplayer seek to a part of a song and it's between MP3 data blocks, the decoder tries to play a portion of the block but because it's only a portion it doesn't read correctly and it outputs noise until it reaches a good block, which is a split second later. That's just a guess, though.
Comment 5 Sam 2010-10-26 02:17:49 UTC
Also, every package is up to date on my 10.04 installation.
Comment 6 Sebastian Dröge (slomo) 2010-10-26 06:02:30 UTC
If it's also happening with mplayer it's not a GStreamer bug but a bug in some lower layer. Please report this bug at your distributions bugtracker
Comment 7 Sam 2010-10-26 20:53:28 UTC
I'm sorry, I was going off of memory when I said Mplayer also did it. No, gnome-mplayer does not exhibit the bug. I'm really sorry for that.
Comment 8 Vincent Penquerc'h 2011-10-07 15:43:56 UTC
Does this still happen ?

Trying here with Totem, as well as the pipeline below, seeks fine, and no loud noise.

gst-launch playbin2 uri=file://<somemp3file> video-sink='navseek ! autovideosink' flags=0x1f
Comment 9 Akhil Laddha 2011-11-18 05:55:53 UTC
Sam, ping, can you please respond to comment#8 ?
Comment 10 Sam 2011-11-19 21:41:45 UTC
Yeah, sure, sorry about that Akhil. Give me a second to check.
Comment 11 Sam 2011-11-19 23:38:23 UTC
Vincent, the code that you copy-pasted doesn't allow the option to seek through the song at all, so which method would you suggest I use to verify behavior?
Comment 12 Vincent Penquerc'h 2011-11-20 00:00:21 UTC
I tried Totem as well, and did not hear anything odd.

On what grounds are you saying you cannot seek ?
Have you tried selecting the window that pops up (there should be one with randomly generated graphics), and pressing the right and left arrows ?

Just tried again (with git gstreamer), and I can seek fine in a mp3 file, no loud noise.
Comment 13 Sam 2011-11-20 00:13:40 UTC
Oh, okay - when I use the code as you described using keyboard arrows, it seeks fine without any noise at all. 

However, when I use the seek slider in Totem by itself, it makes the noise. 

Here's what I'm guessing is happening - when the slider is used to seek to a particular point in the song, GStreamer is fed a block of data that is fragmented, but it still tries to play the data anyway, so for a split second the data is garbage and it comes out as noise. When using arrows, the behavior isn't observed because the arrows automatically "snap" to a whole unfragmented block of MP3 data.

That's just a guess, though.

The noise that I observe now doesn't appear to be as loud as it was when I reported the bug but the actual behavior is still observed, so it's a low priority bug.
Comment 14 Vincent Penquerc'h 2011-11-20 00:44:35 UTC
Trying in Totem again, I don't get noise. I do get fragmented pieces of music, as expected, when I drag the slider continuously, but they don't sound like corrupted data or needle-scratching-something, just like small bits of the song as normal.

Maybe it's been fixed in git since the version you're using, or Totem uses a different pipeline/set of elements, which changes behavior.

Since I can't repro, the best you can do now is to run totem with:
GST_DEBUG=5 totem >& totem.log
Then seek a bit till you get a clear noise, ^C it, compress totem.log, and attach is to this bug. Maybe this will give a clue to what the issue is.
Comment 15 Jan Schmidt 2011-11-21 11:22:14 UTC
This bug will depend on the exact mp3 decoder plugin, and whether mpegaudioparse is present. When you seek with the slider bar, totem is scrubbing and playing snippets of audio as you move the bar. Pressing the arrow keys just jumps 30 seconds or so ahead.

The noise is likely to be the mp3 plugin outputting audio buffers which didn't decode correctly, from frames too early after the seek before the bitbuffer has been properly primed. Those frames should fail to decode and not be output.
Comment 16 Tobias Mueller 2012-03-08 10:57:33 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!