Audio duration almost always 268435.453125 (74:33:55) when src is data base64 encoded, but it plays normally
Categories
(Core :: Audio/Video: Playback, defect, P3)
Tracking
()
People
(Reporter: frane, Unassigned)
References
Details
Updated•8 years ago
|
Comment 2•8 years ago
|
||
I met this too. here is the test case https://musicinformationretrieval.com/ipython_audio.html#Playing-Audio
Windows 10, Firefox 68.0.1 x64
Microsoft Edge show correct duration
Can the developers still see this bug report?
Updated•3 years ago
|
I’ve encountered the same behavior when using Base64-encoded audio sources in HTML5.
The playback works correctly, but the reported duration value (via audio.duration) is often extremely large (for example, 268435.453125), especially when the Data URI is long.
From my testing, this seems to happen because the audio metadata parser fails to correctly compute the duration when the entire file is embedded inline as a Base64 Data URI rather than fetched via a Blob or external URL. The decoder can still read and play the audio stream correctly, which is why playback works even though the duration value is invalid.
To reproduce or debug this more easily, you can generate Base64-encoded audio Data URIs directly in the browser here:
👉 https://www.base64converter.online
This makes it easier to test multiple encoding lengths and verify how browsers interpret duration depending on the Data URI size and type.
It looks like the issue might be in how duration is estimated before metadata parsing finishes, particularly for inline-encoded audio sources.
Description
•