Please provide the original pcm sample.  An shorter example would be nice too.

Finally, what is the context sampleRate?

chcunningham@ since it may be mp3 issues.

bupaev@, can you upload a short repro mp3 file?

Ok, I've attached shorter examples with variable bitrate*
Sample rate always 44100.

*mp3 file was created by Sound Forge 11.

Deleted: DFTM-10_48_VBR_44100.mp3 10.3 KB

DFTM-10_48_VBR_44100.mp3 10.3 KB Download

Deleted: DFTM-10_48_VBR_44100.wav 180 KB

DFTM-10_48_VBR_44100.wav 180 KB Download

Thanks for the examples.  I loaded both of these with decodeAudioData on Chrome 49 beta on linux.

The resulting buffers have exactly the same length (46080).  The mp3 files seems to be missing the first 12 samples or so.  Otherwise they seem identical (from a quick inspection of a few samples).

avprobe says the wav file is 1.04 sec long and the mp3 file is 1.07 sec. I think avprobe only produces an estimate of the duration for the mp3 file.

Please describe exactly what you see.

Same result with decodeAudioData on Windows - 46080 samples after decoding.
But Audacity shows that original mp3 contains 47232 samples. 
Also I've compared mp3 and wav in Garage Band, result is different: duration for both files is the same, but decoded sound is shifted, it looks like sound was cut at the start.

Deleted: Compare_Audacity.png 66.9 KB

	Compare_Audacity.png 66.9 KB View Download

Deleted: Compare_GarageBand.png 152 KB

	Compare_GarageBand.png 152 KB View Download

The difference in lengths is 1152, which is about the size of the encoding delay that mp3 encoders introduce at the beginning of the file.  (See http://lame.sourceforge.net/tech-FAQ.txt).

Recent (last couple of years?) versions of ffmpeg will remove this delay under certain conditions such as if the metadata says it's there or if the encoder was LAME.  I think. mp3 encoders also append a bunch of zeroes; ffmpeg doesn't currently remove those, I think.

There are other issues with decodeAudioData, but in this case I think decodeAudioData is doing what it's intended to do.

dale, can you take a look?

=> wolenetz to look at during next ffmpeg roll.

Ok, but how can I predict the behavior of decodeAudioData for various kinds of files? For some files decodeAudioData cuts beginning, for some doesn't. 
For my task a preservation of the sample accuracy is critical.

Renaming Blink>Audio to Blink>Media>Audio for better characterization

@bupaev: I think fundamentally you can't predict unless you carefully control how the files are encoded and the browser you're running on.  For compressed audio, ogg files come closest to consistency that I've seen, but not all browsers support Ogg.  AFAIK, the only consistent and portable format is (uncompressed) WAV.

Possibly related issue: https://bugs.chromium.org/p/chromium/issues/detail?id=689334

Hmm. This one's been around for quite a while. Dale, can you take a look during your M-64 FFmpeg roll?

->rtoy@ to make the judgement call here. Both this and  issue 689334  I think should be marked as WontFix. We've long since decided that if the track has a Xing/Info header we will strip encoder delays.

There should be no complaints about this, the encoder delay is not present in the source audio it's injected by the encoder to deal with DCT warmup. Both MP3/AAC transforms depend on previous input so the injected silence ensures the decoded result is always the same. As an experiment try not feeding the first two packets to any decoder and observe that you get different results than with the silence injected.

Closing as WontFix (WAI).

Now that we decode the entire file without using the estimated duration, we do not want to add any additional further heuristics on what to do.  Heuristics will surely be wrong for someone's example.  We want to use whatever ffmpeg returns.

If you find another example that you think is wrong, please file a new bug.