getDuration() return wrong value on audio mp3 since 2.9.3

[SteMora]

Issue description

Since the 2.9.3 update version, values returning from exoPlayer.getDuration() method are no more the exact value of the track when playing audio mp3.

Reproduction steps

With the demo app, play the two samples in the added section "Issues".
The duration display next to the progressBar is not correct (also is the current position and the end).
(Durations are correct in 2.9.2 version of exoPlayer)

• media.exolist.json file :
  [ { "name": "Issues", "samples": [ { "name": "Issue on track duration (should be 55:46)", "uri": "https://media.radiofrance-podcast.net/podcast09/13940-26.06.2019-ITEMA_22098306-0.mp3" }, { "name": "Issue on track duration (should be 54:36)", "uri": "https://media.radiofrance-podcast.net/podcast09/13940-26.07.2019-ITEMA_22115625-0.mp3" }, { "name": "Google Play (MP3 Audio)", "uri": "https://storage.googleapis.com/exoplayer-test-media-0/play.mp3" } ] } ]

Bug report captured from the device

bugreport-CPH1917EEA-PKQ1.190101.001-2019-07-29-12-22-34.zip

Version of ExoPlayer being used

All versions since 2.9.3 contains the issue

Device(s) and version(s) of Android being used

Samsung s10e / Android 9
Oppo Reno / Android 9
But all devices seem to be impacted.

[google-oss-bot]

This issue does not seem to follow the issue template. Make sure you provide all the required information.

[umangsaini]

For these files Mp3Extractor calculates the duration based on Bitrate.

For MpegAudioHeader, Exoplayer estimates the bitrate based on Sample Rate and Samples per frame. Here instead of bitrate 128,000 bps, it is setting the value to 127,706 bps. This is causing the total duration shown for the files to be different.

bitrate = 8 * frameSize * sampleRate / samplesPerFrame;

Link to above snippet.
Sample Rate = 44,100, Frame Size 417, Samples per frame 1152 for the MP3 files in the playlist.

[SteMora]

Thanks for the answer.

While debugging at running time, the frameSize seems to be inconsistent du to a padding switching from 1 to 0 value.

padding        : 0
frameSize      : 417
sampleRate     : 44100
samplesPerFrame: 1152
bitrate        : 127706

padding        : 1
frameSize      : 418
sampleRate     : 44100
samplesPerFrame: 1152
bitrate        : 128012

With the google sample file, the problem seems to also happened in the same way.

The error happens mostly on the playing start, then it stabilises on correct values.

[ojw28]

We've reverted the change that introduced the bad behavior. This will be picked up in the 2.10.4 release.

[SteMora]

Thanks for doing this so fast !
works great on 2.10.4