Bug 228215
| Summary: | MP3 decoder ignoring XIPH header related to encoder delay and padding information | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Jean-Yves Avenard [:jya] <jean-yves.avenard> |
| Component: | Web Audio | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | cdumez, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Jean-Yves Avenard [:jya]
Consider the following case:
STR:
1- Open https://jyavenard.github.io/htmltests/tests/webaudio/decodeAudioData.html
2- Select half-a-second-48000.mp3 at the bottom of the list
3- Click on play
Safari will show 26496 frames 0.552s.
This file is exactly .5s long and made of 24000 frames.
It contains a XIPH header that provides the encoder delay and padding information.
Chrome and Firefox properly parse those MP3 which results in a continuous audio stream when looping. On Safari you can here the incorrectly generated blank frames.
The ability the produce frame-exact content is important for web audio applications.
WebKit uses ExtAudioFileRead to demux and decode this file and it returns too many frames.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/80998793>
Jean-Yves Avenard [:jya]
this got fixed on macOS Monterey.