Closed Bug 1975822 Opened 10 months ago Closed 19 days ago

mp3 files with invalid VBR header show incorrect length in audio player

Categories

(Core :: Audio/Video, defect, P3)

Firefox 140
defect

Tracking

()

RESOLVED FIXED
152 Branch
Tracking Status
firefox152 --- fixed

People

(Reporter: art0007i, Assigned: kinetik)

Details

Attachments

(2 files)

Attached file bad_mp3.html

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)

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.

Status: UNCONFIRMED → NEW
Ever confirmed: true

14 s as well here.

Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → WORKSFORME

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.

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(jmathies)
Flags: needinfo?(jmathies)
Severity: -- → S3
Flags: needinfo?(kinetik)
Priority: -- → P3

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: nobody → kinetik
Status: REOPENED → ASSIGNED
Flags: needinfo?(kinetik)
Summary: mp3 file shows incorrect length in audio player → mp3 files with invalid VBR header show incorrect length in audio player

(In reply to Dongil Kim from comment #5)

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

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.

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.

Pushed by mgregan@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/f38a01ea530e https://hg.mozilla.org/integration/autoland/rev/323829c993b9 Use bitrate fallback for MP3 with placeholder Xing header r=alwu,media-playback-reviewers
Status: ASSIGNED → RESOLVED
Closed: 10 months ago19 days ago
Resolution: --- → FIXED
Target Milestone: --- → 152 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: