Notes: 
- .wav, .flac, .m4a/.aac files do not exhibit this problem, and are decoded correctly

- .ogg seems to be the only affected format

- Ignore the correlation.png file in the attached test case. After testing on more files, there doesn't seem to be a correlation between the file size and the error in decoded buffer length.

I see that the files all have different lengths (Linux, Chromium ToT today):

metronome: 265536 (6.0212 sec)
clave:     264896 (6.0067 sec)
drum:      264768 (6.0038 sec)

WebAudio decodes the entire file, without using the estimated duration.  I see from avprobe each of the files is 6.00 sec long (264600 frames at 44.1 kHz).

+chcunningham who works with chrome's ffmpeg (I think)

Eh, we clamp based on duration for aac, but I'd be wary of doing that for ogg too since I generally feel that format isn't as precise -- though that may be a reason _to_ clamp actually.

I'm not sure what you mean by ogg being less precise. Unlike mp3, ogg (vorbis) was designed to be capable of sample-perfect looping. So being able to reconstruct the file exactly is possible and necessary.

Any other commercial software that supports loading of oggs (audacity, wavosaur, ocen, protools) will and does (I just tested) show the test files having exactly 264600 samples.

!!! Somewhat good news. I just tested the conversion with ffmpeg itself, and it also decodes the files incorrectly, with the same sample lengths as listed by "rtoy" above. So the source of the bug is in ffmpeg.

I'll file this issue through the appropriate channels at ffmpeg.

I don't disagree that's the intention. In this case ffmpeg's decoder is spitting out more samples. Why that's the case, I don't know. It seems like a bug worth reporting to them upstream.

Even relying on the tagged packet duration appears to be insufficient in this case. We could clamp to the reported file duration 6s, but I'd worry this breaks more files than it helps.

decodeAudioData used to trust the reported file duration but in many cases, the duration was sometimes shorter (sometimes very, very much shorter) than the actual duration and we would end up not decoding the rest of the file.  

And for aac files, there were cases where the estimated duration of a very short file would be so short that the pre-roll frames were all that were included because we couldn't remove the pre-roll frames ahead of time. (No metadata indicating if the pre-roll were included or not.)

So we switched to decoding everything in the file, ignoring the duration.

Oh, and I vaguely remember cases where the estimated duration was huge (more than 4GB) and we would fail to decode the file, even though the actual data was pretty small. (This might have been an Android problem, before we switched to using ffmpeg on Android.)

Marking as ExternalDependency since ffmpeg also produces different lengths.

Link to bug report in ffmpeg for anyone who wishes to follow the resolution of this issue:

https://trac.ffmpeg.org/ticket/7447

Apologies. Apparently this is a duplicate issue in both Chromium and FFmpeg (even though I did do a quite thorough search and couldn't find them):

https://trac.ffmpeg.org/ticket/6367
https://bugs.chromium.org/p/chromium/issues/detail?id=456252