mp3 files with invalid VBR header show incorrect length in audio player
Categories
(Core :: Audio/Video, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox152 | --- | fixed |
People
(Reporter: art0007i, Assigned: kinetik)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:135.0) Gecko/20100101 Firefox/135.0
Steps to reproduce:
I was recording mp3 stereo audio using ffmpeg and the ffmpeg process was force-killed. then I put the mp3 file inside of the audio html element.
Actual results:
The audio element showed the wrong length (expected 6-7 seconds, actual 10 or 14 seconds).
Expected results:
The audio element shows the correct length (6-7 seconds)
Comment 1•10 months ago
|
||
Can confirm the 14s time in Firefox. Chrome shows the correct time of 6s.
If you save the file and then open it from your local machine, time shown is 10s.
Comment 2•10 months ago
|
||
14 s as well here.
I think there may have been a misunderstanding. If you are seeing 14 seconds, then you are experiencing a bug. The correct time is ~6.9 seconds, which might display as 6 or 7 depending on if the timer rounds up or down. If you see anything else than that then it's incorrect and should be fixed.
Comment 4•9 months ago
|
||
The severity field is not set for this bug.
:jimm, could you have a look please?
For more information, please visit BugBot documentation.
Updated•6 months ago
|
Updated•6 months ago
|
Comment 5•23 days ago
|
||
I have a similar issue with this page, which reports that the audio length is Infinite for certain MP3 files (and seemingly, only some of them, either using certain types of encoders or MP3 downloader programs such as Mediahuman YouTube to MP3 Converter)
The source code of the page where the bug can be reproduced
The same page works just fine on Chrome (Microsoft Edge included) and shows the correct length of the file as reported by other apps.
App info: Firefox Version 147.0.1, Build ID 20260116091309.
Since I can't attach the files here, here's the info for the affected files as reported by ffmpeg:
Input #0, mp3, from 'Never Gonna Give You Up.mp3':
Metadata:
artist : Rick Astley
title : Never Gonna Give You Up
TLEN : 000000060040
major_brand : mp42
minor_version : 0
compatible_brands: isommp42
author : RickAstleyVEVO
comment : www.mediahuman.com
Duration: 00:01:00.08, start: 0.000000, bitrate: 199 kb/s
Stream #0:0: Audio: mp3 (mp3float), 44100 Hz, stereo, fltp, 192 kb/s
Stream #0:1: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/unknown), 1282x720 [SAR 96:96 DAR 641:360], 90k tbr, 90k tbn (attached pic)
And another one that shows the same incorrect behavior:
Input #0, mp3, from 'Title.mp3':
Metadata:
encoder : Lavf52.54.0
artist : Matt Uelmen
title : Title
genre : Game
album : Torchlight - Soundtrack
track : 13
ID3v1 : www.gog.com
date : 2009
Duration: 00:02:21.59, start: 0.000000, bitrate: 201 kb/s
Stream #0:0: Audio: mp3 (mp3float), 44100 Hz, stereo, fltp, 192 kb/s
However, the problem does not appear on this file:
Input #0, mp3, from 'To Stir The Sea.mp3':
Metadata:
album : Of Breath and Bone
artist : Be'lakor
album_artist : Be'lakor
disc : 1/1
genre : Atmospheric Melodic Death Metal
title : To Stir the Sea
track : 5/8
date : 2012
Duration: 00:01:28.99, start: 0.025056, bitrate: 321 kb/s
Stream #0:0: Audio: mp3 (mp3float), 44100 Hz, stereo, fltp, 320 kb/s, start 0.025057
Metadata:
encoder : LAME3.93
Stream #0:1: Video: mjpeg (Progressive), yuvj420p(pc, bt470bg/unknown/unknown), 300x300 [SAR 1:1 DAR 1:1], 90k tbr, 90k tbn, start 0.025056 (attached pic)
Metadata:
comment : Cover (front)
I would like to see this bug resolved since it's also causing some other sites to fail loading the MP3 file, saying that it is corrupted and can't be loaded.
| Assignee | ||
Updated•23 days ago
|
| Assignee | ||
Comment 6•23 days ago
|
||
(In reply to Dongil Kim from comment #5)
I have a similar issue with this page, which reports that the audio length is
Infinitefor certain MP3 files (and seemingly, only some of them, either using certain types of encoders or MP3 downloader programs such as Mediahuman YouTube to MP3 Converter)
Infinite durations are not related to the original issue this bug was filed about. Your issue is likely related to the use of non-HTTP transport types (like data URLs) and MP3s lacking info (duration) headers. Please file a new bug and CC me, I'll take a look separately.
| Assignee | ||
Comment 7•20 days ago
|
||
When ffmpeg or another encoder is killed mid-encode, the Xing/LAME
header it wrote at the start of the file retains its placeholder
NumFrames=0 and NumBytes=0 fields. MP3TrackDemuxer::Duration() saw the
header as valid and so skipped the bitrate-based fallback, falling
through to AverageFrameLength(). At Init time only the Xing frame
itself has been counted - and at minimum bitrate (e.g. 64 kbps for
MPEG1 Layer III stereo) it is roughly half the size of the real audio
frames - so size / averageFrameLength roughly doubled the reported
duration (the bug's bad.mp3 reported ~14 s for 6.86 s of audio).
Switch the condition to !IsComplete() so a Xing header that has not
been finalized takes the bitrate path. ffmpeg's libavformat/mp3dec.c
handles this case the same way and explicitly logs "Estimating
duration from bitrate, this may be inaccurate".
The bitrate currently parsed by mParser may be from the lower-bitrate
Xing frame when it gets re-demuxed as a sample, so capture the bitrate
of the first real audio frame in UpdateState() (mirroring how
mSamplesPerFrame and friends are captured) and use that cached value.
Comment 9•19 days ago
|
||
| bugherder | ||
Description
•