Forums

/

Specific example of "the MP3 seeking bug"

23 replies [Last post]

I believe these are all the same bug:

http://www.jeroenwijering.com/?thread=12001
http://www.jeroenwijering.com/?thread=11842
http://www.jeroenwijering.com/?thread=11646
http://www.jeroenwijering.com/?thread=11028

There seemed to be some misinformation floating about on those threads that somehow the MP3 file was to blame. But this is definitely not the case. Here is an example page of the same MP3 file being played with two different players:

http://mollyrocket.com/player/test.html

On the top is JW Player. Hit play on it, wait for it to load the whole file, and then try to slide the play-cursor around. You will see that you cannot move past the half-way point.

On the bottom is another Flash-based MP3 player. Hit play on it, wait for the loading bar to complete, and then slide the cursor around. Everything works perfectly.

Now, if you play around with the JW Player's seeking behavior, you can see exactly what is happening: clicking in the first half of the bar seeks to _twice the location you click_. So if you click a quarter of the way across the bar, you actually seek to the midpoint of the MP3. This produces another really strange behavior, which is that if you let the MP3 play to completion from where you seeked, it will still play the rest of the file correctly, but the play cursor will constantly be in the wrong place proportional to how close to the beginning you started. This is because the play cursor still _moves_ at the correct rate.

Truly bizarre! I'm guessing there must be some divide-by-two error somewhere in the seek code?

- Casey

Thanks for the clear demo! I took a look at this, and found something strange.

There is indeed a bug in here. The Sound API from Flash sometimes indeed stops and sends COMPLETE calls to the player, even though the sound isn't done yet. This is with a combination of:

1. actionscript3 (that's why the other player works - it is in AS2).
2. a certain version of the plugin > 9.0.28.0 (I don't know the exact version, but the bug IS there in 0.115 and 0.124).

I tried a couple of workarounds, e.g. ignoring the COMPLETE calls when I'm sure the sound has not ended yet. No luck though, since the Sound API simply drops.

Anybody has some additional insights? Else it seems to be time to file a bug with Adobe...

Thanks Jeroen for quickly figuring this out!

I can also confirm this seek problem. In my case a 6:14 long mp3 can only be seeked until ~1:06. Trying to seek beyond that point will jump back to 0:00.

Sad, since I have just licensed the player just to use it for mp3 playback.

Jeroen, what do you suggest? Do you have a workaround, that would get mp3 playback up and running with seek functionality? E.g. Older version? Which one?

UPDATE: I have tried v3.16 and it works like a charm. :)

I have the same problem with one 90' long MP3 file.

With version 3.14 or 3.16 the problem is fixed in Firefox but not in IE6 and IE7 where the MP3 is played too fast and is inaudible.

I hope you get this fix pretty quickly :)

UPDATE 1 : In thread=12478 I got a hint to fix the IE pb

UPDATE 2 : workaround for version 4.0
To fix the problem in version 4.0 (both Firefox and IE) I converted my MP3 file from 24kbps to 128kbps,
its 6 times bigger, but the bug disapeared

I think this bug is also appearing with specific bitrates (so 24000 for sure, but probably also other non 64/96/128 ones), perhaps only variable bitrates? Also please check the sample frequency. Perhaps 48kHz or other non 22/33/44 frequencies are nonworking.

Hello Jeroen,

I tried on the same MP3 piece of 90 minutes the following bitrates :
16/24/32/48/64/96/128/192kbps at 44 100 Hz sampling frequency, Mono mode
and the ones which causes no problem with player version 4.0 are : 64 - 96 - 128 and 192kbps
the ones that do cause the seeking bug : 16 - 24 - 32 - 48kbps

I could not generate the 22/33/44 ones with my MP3 Lame encoder

> Anybody has some additional insights? Else it seems to be time to file a bug with Adobe...

But it can't be an insurmountable bug in Flash, because the other Flash player plays and seeks just fine. So it has to be something that you're doing differently in your player that could at least be worked around even if it is a bug that Adobe needs to fix in the future, yeah?

- Casey

Mmm... something we should probably do as well, is test a number of other players and see if there are any ActionScript3-only players that don't have the problem:

http://blog.forret.com/2005/01/playing-mp3-with-an-embedded-flash-player/

etc., etc.

- Casey

Also, here is the source page for that other player - maybe there is an ActionScript 3 version now that we can test? I don't actually know how to determine if something is ActionScript 2 or 3.

http://wpaudioplayer.com/

- Casey

I do suspect this is AS3, since the AS2 version of the JW Playyer also didn't have this issue.

http://wpaudioplayer.com/ is an AS2 player. Take a look at the source code to check:

http://tools.assembla.com/1pixelout/browser/audio-player/trunk/source/classes/Application.as

I was doing some research into this bug, and I found a workable solution. The problem mp3 files I was working with were encoded at 48000 Hz. When I re-encoded them to 44100 Hz, the bug went away for all of the bitrates I used.

Actually, I had the same issue with a constant bitrate (64kbps) MP3 @ 22.050kHz. After converting to 44.1 the problem was solved. Seems like the AS3 MP3 playback is a little buggy, so please stick to 44.1

Seems that i have the same problem. If i play recording that's "10:14" in length, i can only seek to 1:48 (after which end of file is played, so it's some weird scaling), however listening it straight from beginning to end is normal (and seek bar goes til end).

I have to play large amounts of 8kHz files (phone recordings), and transcoding them to higher bitrates would be a waste of CPU and bandwith. JW Player is the only one that seems to understand them (numerous of other players will just sound as "chipmunks").

Sacrificing IE would probably be acceptible to me, so is there a place where i can download 3.16 version?

Actually, the 3.16 player will probably chipmunk, like all other Actionscript2 players. So the choice is either chipmunking or not allowing users to seek.

anyone figure this one out yet! i just had me confused for a couple of hours.. i would really like to build a stable workaround.

should have been ? and not ! ..

It's not a fix in the player, it is an issue of Actionscript (the Flash plugin). Adobe has to fix it.

I have noticed similar problems, for my application I need an MP3 file that uses a playlist and has 5 index points

Intro, Safe Harbor, Presentation, Q and A, Closing

I have tested this with the following:

32 kbps / 44100 Hz
64 kbps / 44100 Hz
128 kbps / 44100 Hz

with a playlist in multiple formats on multiple browsers / OS

and have found the following:

1 - playlists didnt matter (xspf, asx, smil, rss) all reacted the same

2- on a PC it didnt matter the encoding (32,64,128) they all worked on both IE and Firefox

3 - On a MAC only the 128 encoding worked, but only on an internal test server, as it took too long to load across the internet

4 - On Linux same results as MAC

I have tried to split the files into the 5 parts and make a playlist, however the playlist always stops after the first file, even though I have:

<script type='text/javascript'>
var s1 = new SWFObject('player.swf','ply','220','40','9');
s1.addParam('allowfullscreen','false');
s1.addParam('allowscriptaccess','always');
s1.addParam('repeat','true');
s1.addParam('shuffle','false');
s1.addParam('wmode','opaque');
s1.addParam('flashvars','&title=Q3 Earnings Call&durarion=1090&controlbar=bottom&playlist=over&frontcolor=#FFFFFF&backcolor=#000000&screencolor=#000000&file=file-64.xspf&autostart=true');
s1.write('preview');
</script>

repeat set to true and shuffle set to false

it moves correctly through the individual files when clicking to the next item, but stopson whichever item you are on.

The xspf file lookes like:

<playlist version="1" xmlns="http://xspf.org/ns/0/">
<title>Ashworth Inc. Q3 Earnings Call</title>
<tracklist>
<track>
<title>Intro</title>
<image>viavid-text-intro.gif</image>
<creator>ViaVid Communications</creator>
<location>ashworth1.mp3</location>
</track>
<track>
<title>Safe Harbor</title>
<image>viavid-text-safeharbor.gif</image>
<creator>ViaVid Communications</creator>
<location>ashworth2.mp3</location>
</track>
<track>
<title>Presentation</title>
<image>viavid-text-presentation.gif</image>
<creator>ViaVid Communications</creator>
<location>ashworth3.mp3</location>
</track>
<track>
<title>QA</title>
<image>viavid-text-qa.gif</image>
<creator>ViaVid Communications</creator>
<location>ashworth4.mp3</location>
</track>
<track>
<title>Closing</title>
<image>viavid-text-closing.gif</image>
<creator>ViaVid Communications</creator>
<location>ashworth5.mp3</location>
</track>
</tracklist>
</playlist>

if you want to listen / try these they are on the internet at:

http://irpage.net/test/jw-32-xspf.html
http://irpage.net/test/jw-64-xspf.html
http://irpage.net/test/jw-128-xspf.html
http://irpage.net/test/jw-ind-xspf.html

Any suggestions on a work around until adobe fixes it ?

Perhaps you just need to review the v4.x player supported flashvars here: http://developer.longtailvideo.com/trac/wiki/FlashVars then fix up your code:

<script type='text/javascript'>
  var s1 = new SWFObject('player.swf', 'ply', '220', '40', '9');
      s1.addParam('allowfullscreen',   'false');
      s1.addParam('allowscriptaccess', 'always');
      s1.addParam('wmode',             'opaque');
      [s]s1.addParam('repeat',            'true');[/s]
      <strong>s1.addVariable('repeat',         'list');</strong>
      [s]s1.addParam('shuffle',           'false');[/s]
      <strong>s1.addVariable('shuffle',        'false');</strong>
      [s]s1.addVariable('title',          'Q3 Earnings Call');[/s]
      [s]s1.addVariable('durarion',       '1090');[/s]
      [s]s1.addVariable('<strong>duration</strong>',       '1090');[/s]
      s1.addVariable('controlbar',     'bottom');
      s1.addVariable('playlist',       'over');
      [s]s1.addVariable('frontcolor',     '#FFFFFF');[/s]
      [s]s1.addVariable('backcolor',      '#000000');[/s]
      [s]s1.addVariable('screencolor',    '#000000');[/s]
      <strong>s1.addVariable('frontcolor',     'FFFFFF');</strong>
      <strong>s1.addVariable('backcolor',      '000000');</strong>
      <strong>s1.addVariable('screencolor',    '000000');</strong>
      s1.addVariable('file',           'file-64.xspf');
      s1.addVariable('autostart',      'true');
      s1.write('preview');
</script>

Well, it needed quite a bit of fixing, so I did most of it for you.

If you are using a playlist, the duration has to be placed in each track like this:

<duration>1090</duration>

or like this:

<meta rel='duration'>1090</meta>

The Title also goes in each track as you have it, not in the player code.

Converting the mp3 to 44.1 kHz did the trick for a few mp3's but the problem remains for others. Any suggestions other than downgrade?

This just saved my life
Couldn't figure out why my code wasn't working :-/

And it wasn't even my fault :D

@Fuzzy: are you sure the files that still don't work are at 44.1? Perhaps they are still the old ones that are in your browser cache?

If not, can you find other differences between the files that do and don't work? Variable vs constant bitrate? Different bitrates? Stereo or joint stereo?

Sorry about that, I guess I'm not so good with audio compression. 44.1 seems to work I just wasn't able to export it at anything lower than 128 kbps from audacity. So even though I was telling it to export at 44.1 it was down sampling to 16k for some reason...

Sorry!

Was there a "fix" for this?

I can play mp3 files in both IE7 and Firefox just fine, but the IE browser will not seek past the halfway point. Firefox works on all files.

I'm using Fleximusic Wave Editor which calls LAME to encode the mp3 files. The output bitrate is 48kbps, is this the same as the 44.1 kHz mentioned above?

The LAME output screen notes the following:
Encoding as 22.05 kHz 48kbps j-stereo MPEG-2 Layer III <14.7x> qval-3

I have a test playlist up, it is at:
http://www.amazinggracecc.com/webroot/amazing_grace_sermons_recent_new.htm

Any help you can lend me will be appreciated!

mark