New issue
Advanced search Search tips

Issue 610312 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 582898
Owner: ----
Closed: Jun 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

decodeAudioData() fails on valid mp3

Reported by j...@skratchdot.com, May 9 2016

Issue description

Chrome Version:
52.0.2729.0 (Official Build) canary (64-bit)

URLs (if applicable):
https://chinpen.net/decodethis/
https://chinpen.net/decodethis/public/audio/1000-frames-of-noise-encoded-with-lame.mp3

OS version:
OSX 10.11.4 (15E65)

Network (such as Cable/DSL/Dial up etc):
Cable

Audio/Video format (if applicable):
$ mediainfo ./public/audio/1000-frames-of-noise-encoded-with-lame.mp3
General
Complete name                            : ./public/audio/1000-frames-of-noise-encoded-with-lame.mp3
Format                                   : MPEG Audio
File size                                : 5.23 KiB
Duration                                 : 52ms
Overall bit rate mode                    : Variable
Overall bit rate                         : 224 Kbps
Writing library                          : LAME3.99r

Audio
Format                                   : MPEG Audio
Format version                           : Version 1
Format profile                           : Layer 3
Mode                                     : Joint stereo
Mode extension                           : MS Stereo
Duration                                 : 52ms
Bit rate mode                            : Variable
Bit rate                                 : 224 Kbps
Minimum bit rate                         : 32.0 Kbps
Channel(s)                               : 2 channels
Sampling rate                            : 44.1 KHz
Compression mode                         : Lossy
Stream size                              : 1.43 KiB (27%)
Writing library                          : LAME3.99r
Encoding settings                        : -m j -V 0 -q 0 -lowpass 22.1 --vbr-new -b 32

Special chrome flags (if applicable):
N/A

Behavior in Safari (if known):
The file '1000-frames-of-noise-encoded-with-lame' decodes

Behavior in Firefox (if known):
The file '1000-frames-of-noise-encoded-with-lame' decodes

Video issue, Audio issue, both, neither?
From what I am told, it works with Media Source Extensions: "I played a bit with Media Source Extensions today and eventually came across an MP3 file which was not decodeable with decodeAudioData() but was accepted when passed as a SourceBuffer to a MediaSource."

What steps will reproduce the problem?
(1) Visit https://chinpen.net/decodethis/
(2) Search for "1000-frames-of-noise-encoded-with-lame"
(3) Press the "Play" button

What is the expected result?
The file should be decoded successfully with decodeAudioData()

What is the actual result?
The file is not decoded. The error result is populated correctly (as it should when files aren't decoded).  This file should be able to be decoded though.

Any additional information (anything else which may help us debug the
issue)?
Grab the following file data and pass it to decodeAudioData() = https://chinpen.net/decodethis/public/audio/1000-frames-of-noise-encoded-with-lame.mp3


 
Please assign this to the "Blink>WebAudio" component.  I do not have access to do so.  Thanks!
Well, I really screwed this bug up.  I didn't give a useful subject.  If possible, can you please change the subject to:

decodeAudioData() fails on valid mp3
Summary: decodeAudioData() fails on valid mp3 (was: <Replace this with a summary. This form is for audio/video issue (HTML5).>)

Comment 4 by ajha@chromium.org, May 10 2016

Cc: ajha@chromium.org wolenetz@chromium.org
Components: Blink>WebAudio
Labels: -Type-Bug -Pri-3 hasbisect M-52 OS-Linux OS-Mac OS-Windows Pri-1 Type-Bug-Regression
Owner: dalecur...@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this on the latest stable(50.0.2661.94) and the latest canary(52.0.2730.0) on Windows-7, Mac OS 10.11.5 and Linux Ubuntu 14.04.

This is a regression issue broken in M-37:

Last good build: 37.0.2007.0
First bad build: 37.0.2008.0

Changelog:
==========
https://chromium.googlesource.com/chromium/src/+log/37.0.2007.0..37.0.2008.0?pretty=fuller&n=10000

Suspected change: https://codereview.chromium.org/293053005

dalecurtis@: Could you please take a look at this and help in investigating this further.

Note: Unable to provide the tool result as Chromium is invoking all the Bad builds.
Cc: chcunningham@chromium.org
Owner: ----
Status: Available (was: Assigned)
CL is unrelated, likely just a decode issue that ffmpeg needs an update for.
Project Member

Comment 6 by sheriffbot@chromium.org, Jun 1 2016

Labels: -M-52 M-53 MovedFrom-52
Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 7 Deleted

I believe this is related to  issue 482934 : https://bugs.chromium.org/p/chromium/issues/detail?id=482934

Not sure if you want to close as a duplicate, or just log it as a related issue
Mergedinto: 582898
Status: Duplicate (was: Available)
Its not quite the same issue as  issue 482934 , but they are similar. 

Whats happening here is ffmpeg fails to determine the format of the file, and returns an error we try to open for demuxing. decodeAudioData uses ffmpeg to demux the mp3 (much like an <audio src=file.mp3>). 

MSE does its own demuxing separate from ffmpeg (relying entirely on the mimetype to choose the demuxer), so it doesn't use the same codepath.

This bug is duplicate of  issue 582898 . I will explore format probing improvements in that bug. This won't help at all with the root issue for 482934 - to fix that we just need to make the web audio API aware of the OpusAudioDecoder. 

Sign in to add a comment