MediaPlayer provides incorrect duration in Android 2.3
Closed this issue · 2 comments
getDuration() gives an incorrect duration for samples in android 2.3, namely a lower value. This leads to the skip limit being lower than necessary and thus to samples being cut short while playing.
Possible fixes:
- some forum posts mention using 44.1KHz samples, which we might also do in #2
- embed the skipLimit (or duration) in the application, in for example res/values/associations.xml, instead of dynamically calculating it.
well, option #1 did not seem to fix this (tried the new higher qual. sounds). It could be an issue with the emulator, as I never noticed this problem while testing it on a Galaxy S+ during the Athens week. Need some real world testing with 2.3 device(s).
Did quite a few tests:
- Tested on 2.3 on a real device, issue does exist, it's not just the emulator.
- According to some forum posts it also exists in 3.0
- Using 44.1KHz samples does not help
- Samples in other formats such as MP3 and AAC do report a correct duration, if slightly too long.
I compared the sample duration for all the supported formats and found these results:
| True Duration | Found | diff | MP3 | diff | AAC | diff |
|---|---|---|---|---|---|---|
| 7500 | 4223 | -3277 | 7576 | 76 | 7523 | 23 |
| 7500 | 4525 | -2975 | 7576 | 76 | 7523 | 23 |
| 3750 | 2865 | -885 | 3816 | 66 | 3773 | 23 |
| 7500 | 5711 | -1789 | 7576 | 76 | 7523 | 23 |
| 3750 | 2435 | -1315 | 3816 | 66 | 3773 | 23 |
| 3750 | 2845 | -905 | 3816 | 66 | 3773 | 23 |
| 3750 | 2505 | -1245 | 3816 | 66 | 3773 | 23 |
| 3750 | 2993 | -757 | 3816 | 66 | 3773 | 23 |
| 1875 | 2689 | 814 | 1933 | 58 | 1904 | 29 |
| 1875 | 2244 | 369 | 1933 | 58 | 1904 | 29 |
| 1875 | 2446 | 571 | 1933 | 58 | 1904 | 29 |
| 3750 | 4975 | 1225 | 3814 | 64 | 3785 | 35 |
| 7500 | 6938 | -562 | 7576 | 76 | 7523 | 23 |
| 7500 | 7439 | -61 | 7576 | 76 | 7523 | 23 |
| 7500 | 5360 | -2140 | 7576 | 76 | 7523 | 23 |
| 7500 | 7769 | 269 | 7576 | 76 | 7523 | 23 |
| 7500 | 4913 | -2587 | 7576 | 76 | 7523 | 23 |
| 7500 | 7083 | -417 | 7576 | 76 | 7523 | 23 |
| 7500 | 8144 | 644 | 7576 | 76 | 7523 | 23 |
| 7500 | 7543 | 43 | 7576 | 76 | 7523 | 23 |
| 3750 | 3213 | -537 | 3816 | 66 | 3773 | 23 |
| 3750 | 3279 | -471 | 3816 | 66 | 3773 | 23 |
| 3750 | 3279 | -471 | 3816 | 66 | 3773 | 23 |
| 3750 | 2548 | -1202 | 3816 | 66 | 3773 | 23 |
| 346 | 646 | 300 | 418 | 72 | 372 | 26 |
| 251 | 713 | 462 | 313 | 62 | 279 | 28 |
| 1875 | 1940 | 65 | 1933 | 58 | 1904 | 29 |
| 1875 | 831 | -1044 | 1933 | 58 | 1904 | 29 |
| 1875 | 1629 | -246 | 1933 | 58 | 1904 | 29 |
| 1875 | 1400 | -475 | 1933 | 58 | 1904 | 29 |
| Average: | -620,0 | 67,8 | 25,1 |
The duration reported for MP3s and AAC files is actually correct, the files are a few milliseconds longer after conversion. We can take this into account when creating sounds so we don't get glitches.
To sum up: use samples encoded in AAC (LC) at 64Kbps, but take into account that we lose ~25ms at the end.