Wrong Duration of MP3 displayed

Hi Abhishek,

Can you provide an example MP3 we can test against?

I have uploaded a test mp3 file of actual duration 4.48 mins.

To access it please visit the ftp portal:
-------------------------------------------------------
https://portal.fleishman.com/public/
-------------------------------------------------------

To file resides at the given folder location
-------------------------------------------------------
/Incoming/Test MP3 JW Player
-------------------------------------------------------

When we run this file it sometimes shows the correct duration and sometimes the wrong duration that is 19.13 mins.

Even if you refresh the JW player multiple times the when correct duration is displayed, then also the above problem persists.

I will get back with a sample mp3 with a longer duration(40 mins+).
I

 
Your MP3 file is improperly encoded.

As soon as I saved the file from a high-quality audio editor, the correct duration showed in the player.

Try it here: http://willswonders.myip.org:8074/Rang_Deeni_DEV.mp3

Notice that the original file has NO header!

Size: 1153358 bytes
<strong>Header found at: 0 bytes</strong>
Length: 288 seconds
MPEG 2.5 layer 3
32kbit, 5544 frames
11025Hz Joint Stereo
CRCs: No
Copyrighted: No
Original: No
Emphasis: None

After Saving from CoolEdit2000
==============================

Size: 1156663 bytes
<strong>Header found at: 1714 bytes</strong>
Length: 288 seconds
MPEG 2.5 layer 3
32kbit, 5552 frames
11025Hz Joint Stereo
CRCs: Yes
Copyrighted: No
Original: Yes
Emphasis: None

Hi hobbs , can you just tell me which tool you use to find the header information as you have listed above.

WinAmp

File, View file info

Hi hobbs , from your previous comments that included "the correct duration showed in the player" implies that you were able to reproduce the problem on JW4.5.

But when I played the same file on JW4.3 it worked fine i.e showed the correct duration.Do you have any pointers on this?

Also if possible please let me know the audio editor you used to correct the mp3.

Thanks for your help.

 
I used Cool Edit which is now Adobe Audition.

Hi hobbs, you just missed out on the other question above that:

When I played the same file(improperly encoded) on JW4.3 it worked fine i.e showed the correct duration.
Do you have any pointers on this?

Thanks

Hi Abhishek,

The calculation changed between 4.3 and 4.4, and takes into account the size returned by the HTTP header. If this is incorrect, the duration duration displayed will be incorrect as well.

As a work around, you can set the duration flashvar or set it in the playlist.

@Zach,

Abhishek's MP3 file is 4:48 but the player shows 19:13.

The MP3 file is missing the internal header.

As soon as I added the header, the duration showed correctly as 4:48.

I added the missing header by saving the MP3 file from an audio editor.

Hi Hobbs,

The duration calculation relies upon the total size of the mp3 file in bytes. This information is contained in the mp3 header and since this information is missing the size in bytes evaluates to zero and results in the inflated duration.

In this case you can either fix the header as you did or use the workaround Zach posted.

Hi hobbs/Zach,

Can you please help me how to use the duration flashvar.

I use JW player in my application and use it to play both audio and video files stored in the Database. I stream those files via Java.

Thanks

Hello!

I think, this still (actually in trunk (Rev. 596) is a bug!

in the sound-model the calculated duration (if not set by a flashvar) is only a estimation; just the same way the adobe flash docs propose it in there:
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/index.html

... if the sound data is not fully loaded, the length property of the sound object shows only the size of the sound data that is currently loaded. An estimate of the eventual size of the full sound file is calculated by dividing the value of the current sound object's length by the value of the bytesLoaded property divided by the value of the bytesTotal property.

in the 4.3 version of jw player there was an additional 'loadedHandler' which calculated the duration of the soundModel again, when the file was loaded completly.

wouldn't it be possible to set the duration again (if it wasn't set originally by the flashvar) in the loadHandler method, when the interval is cleared?
Line 103:
item['duration'] = sound.length / 1000;

Hello!?

is anybody reading the bug reports?

greets from a jw-player licencee.

 
I think there must be some place in the code where Flash is reading the ID3V2 metadata and using that for the duration, because I can get the duration of a 35MB 38:16 MP3 file, which has the ID3V2 metadata in the beginning of the file, almost instantly. And it's the correct duration.

the jw player is reading the duration you give to him via metadata (flashvar, playlist-metadata and - @hobbs - not out of id3-tags so far i know). And since 4.4 he respects it, so that you can chapterize longer audio-files by give the jw-player a starting-point and a duration.
i think thats the point where the bug-or-feature-discussion on this thread should stop at station 'feature'.

but there is also a bug in it:
if you do not give any duration-metadata for some audio-item to the player, he estimates the duration for it as long as it hasn't load it entirely. and since 4.4 he doesn't calculate the duration again, when the file is loaded completly (see my post above).

so i think there should be this line inserted after line 102 in http://developer.longtailvideo.com/trac/browser/trunk/as3/com/jeroenwijering/models/SoundModel.as
item['duration'] = sound.length / 1000;

what do you think jw player developers???

greets,
eva

Fixed this in the 4.7 release of the player.

Indeed, the player did this duration estimation when 10% of the file was loaded. Right now, the duration estimation is done continously.

The old process was due to a duration restriction in the JW Player framework. Up until 4.6, one could set a file's duration only once.

I just wanted to try out the fix which Jeroen announced above - it was comitted with Rev. 679.

And my conclusion is, that other problems now came in with it:

- The Firefox 3.5 workaround for Shout/Ice-Cast mp3 Streams to set the duration to a very high value won't work now. So it is practicable not possible anymore to play Shoutcast-Streams with the JW 4.7 trunk version in Firefox 3.5.
For the workaround see amongst others: http://www.longtailvideo.com/support/forum/Bug-Reports/20745/Live-IceCast-stream-stops-playing-in-Fi...

- With the fix it won't be possible anymore to set the duration intentionally shorter than the item actually is. This was great for chapterizing longer items by setting appropriate start and duration values.

Could you please change it so that the duration is calculated correctly only when it is not given by the user?

i.e. check in the load method wether the duration flash var wasn't set

and check that out in the loadHandler:

Would be great!
Thanks

The Adobe Flash Players 9 & 10 have a known problem with MP3 files that are encoded at any sample rates other than 44.1kHz.

So you should only encode at 44.1kHz. You won't lose any quality, because Flash always downsamples 48kHz to 44.1kHz before it is played anyway.

@ethan:
why are you posting this?
how is it related to the duration issues?

Ethan posted that information since having mp3s that are sampled at frequencies other than 44.1kHz will cause the Flash player to return the wrong duration to the JW Player (or any other Flash application interested in that file's duration).

In short, problems with mp3s reporting the wrong duration almost always stem from this sampling issue.

the duration problem of shout-/icecast mp3 streams is not related to the sampling issue of the flash player:
the stream

http://gffstream.ic.llnwd.net/stream/gffstream_w9a

is sampled at 44.1kHz and stops every few seconds when played with the jw-player on firefox 3.5. try it!

the duration issue acknowledged by jeroen above in this thread wasn't related to the sampling issue of the flash player neither. and its fix led to the problem described by me above:

- The Firefox 3.5 workaround for Shout/Ice-Cast mp3 Streams to set the duration to a very high value won't work now. So it is practicable not possible anymore to play Shoutcast-Streams with the JW 4.7 trunk version in Firefox 3.5.
For the workaround see amongst others: http://www.longtailvideo.com/support/forum/Bug-Reports/20745/Live-IceCast-stream-stops-playing-in-Fi...

- With the fix it won't be possible anymore to set the duration intentionally shorter than the item actually is. This was great for chapterizing longer items by setting appropriate start and duration values.

Could you please change it so that the duration is calculated correctly only when it is not given by the user?

i.e. check in the load method wether the duration flash var wasn't set

if (item['duration'] == 0) {
duration_given = false;
} else {
duration_given = true;
}

and check that out in the loadHandler:

if(ldd/ttl > 0.1 && !duration_given) {
item['duration'] = sound.length/1000/ldd*ttl;
}

Would be great!

thanks in advance for your help

Hi Eva,
I believe that this is fixed in JW5

_sound.bytesLoaded / _sound.bytesTotal > 0.1 && _item.duration <= 0

since _item.duration > 0 if it's set manually in the playlist / flashvars