added data-duration attribute option

[ZARk-be]

Hello

Safari does not support the preload=metadata option. It loads the whole audio file.
Which is complicated if it's a big file.

I've added support for a data-duration attribute on the tag . That way you can specify manually the sound file duration before metadata gets loaded.

Take care :)

[tnbnicer]

Nice one.
It works on Windows when you emulate Safari. data-duration="3599"
No conflicts. Just checking.

[ZARk-be]

Yes it works everywhere.
It's sort of an alternative to preload=metadata.
So the idea is to put preload=none and manually specifying the duration with data-duration. It's display only, it will not affect playback. Once the sound file is loaded the field will be replaced with the metadata from the soundfile.

[tnbnicer]

As far as I know, Mp3s do not include the duration as metadata in a metatag.

An accurate way to retrieve audio, and, I believe, also video duration involves opening and reading the file and converting samples to milliseconds.

11918592 samples = 270263 milliseconds = 04.30 duration.

The trick is being able to get the number of samples without reading-in the file, e.g.: the last sample in the music track. Adobe Audition, for example, does this. It reads the entire file, when you open it, to calculate the duration from samples. It takes a moment or so.

Players take a different route and arrive at a duration which is more approximated, however pretty accurate most of the time. Perhaps – a big perhaps, as I don't claim to know – based on bitrate and file size. Variable bitrate encodings (VBRs) may skew the result, especially on long audios, and very especially on old VBR Mp3s, that are notorious for returning wrong durations. Safari iOS may be unwilling to commit that kind of error.

Conversely, in my experience with Mp3s, the players I use and the relatively short tracks I play, are calculated, I would say, down to a few milliseconds, precisely. That's a guess.

If at the outset you set preload="metadata" for non-Safari and insert data-duration for all other browsers (for Safari – correction), ensure the duration figure you insert is the correct duration in seconds.

260 = 04.20 duration is the wrong duration for 11918592 samples.

The browser (Safari) contradicts 04.20 when it reaches the end of play, assuming the audio plays longer.

I thought I should comment here. IMO, Safari is being cautious. (Too cautious?) Why are the players in other browsers able to approximate duration in advance of playing to the end? How? Trade secret?

[ZARk-be]

Mp3 file duration is indeed calculated using bitrate number of channels etc... Which is skewed with vbr. Which is why most players will mention "estimated" while it parses the file.

But this is not important as you shouldn't use mp3 file format on the Web :)

It's also why the usage of data-duration is interesting. Otherwise your browser will completely load the mp3 file just to get the duration :)

[tnbnicer]

Another skewing factor is the metatag size. Almost all audio formats have or support metatag info. Which is why file size alone gives a wrong duration estimate. In short, metatags increase file size. By how much depends on the metatag (and the information it contains, user-added info, etc.). The assumption is that without loading the metadata, Safari can't even approximate duration.

An additional reason your data-duration attribute is useful. It is a good Html5 method. You can override an attribute, preload in this case, with the data- prefix. I didn't catch on immediately, but yes, it works. (Thumbs up.)

[ZARk-be]

Hello
What do we do with the PR ? Not accepted ?