When attempting to play the MP3 file at http://logs.insanityradio.com/2016-02-13/2016-02-13-18.mp3, Firefox plays a horrible distorted noise and shows the incorrect time of 2:51:15, instead of 59:59 (or 1:00:00 depending on how it is rounded) and playing normally. The MP3 file opens fine in other software (such as Audacity, QuickTime/native, and VLC), so I am not sure why it does not play in Firefox. The MP3 file does not appear to be corrupt, and passes a basic integrity check in VLC.
Could you attach the MP3 file to the bug report (or in the cloud), the website is not reachable.
It's a very large MP3 file, so I put it on another machine (http://126.96.36.199/2016-02-13-18.mp3) The MP3 file itself is 137MB in size, so it seems like it would be a bit inconsiderate to upload it to Mozilla's servers.
I'm not able to play it locally. Maybe bad encoding. General Complete name : 2016-02-13-18.mp3 Format : MPEG Audio File size : 137 MiB Duration : 59mn 59s Overall bit rate mode : Constant Overall bit rate : 320 Kbps Writing library : LAMEªª± Audio Format : MPEG Audio Format version : Version 1 Format profile : Layer 3 Mode : Joint stereo Duration : 59mn 59s Bit rate mode : Constant Bit rate : 320 Kbps Channel(s) : 2 channels Sampling rate : 48.0 KHz Compression mode : Lossy Stream size : 137 MiB (100%) Writing library : LAMEªª±
Anyway the playback regressed. Before 44, the playback was fine on Win 7 even if the total duration displayed was wrong (playback jumped directly from 0:59:59 to 1:10:58). https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c7933be0b031390aaa4e70676124ba28f9cb6278&tochange=ecbe6589d36e490fe8d3c9b5b2d88de394f6918c
Version: unspecified → 44 Branch
The MP3 is probably poorly encoded (it is essentially a real-time stream), but yes, that should not affect playback - other players tested recover/play without issue.
I'm guessing another mp3 that changes sampling rate or something like that
Flags: needinfo?(jyavenard) → needinfo?(esawin)
Yes, looks like another case of oscillating sample rate.
Also, some frames are mono.
The patch from bug 1256590 seems to fix the playback problems. Although I haven't listened to whole of it, the first few minutes play back fine, and seeking to the end of the file works, too. If the sample rate is indeed oscillating at some point, there might be some residual problems (skipped frames, because they won't pass the VerifyFrameConsistency() check) left, though, so I'm not sure whether this bug should closed as a duplicate or not.
Is this issue still reproducible?
Fixed by bug 1256590 and 1264199.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.