Total time value of recorded voice message initially not displayed correctly by some media players

[gerryfrancis]

• Android version: Android 11.

• Device: Fairphone FP2 (Lineage OS 18.1 build RQ3A.210705.001 from 2022-04-01).

• Delta Chat version: 1.29.0.

• Expected behavior: Voice messages recorded on Android are reported/displayed with correct total time (duration) in Delta Chat for Desktop.

• Actual behavior: Voice messages recorded on Android are not reported/displayed with correct total time (duration) in Delta Chat for Desktop until played to their end. The duration is specified with ~10 percent less, e.g. a voice message lasts 50 seconds, but only 45 seconds are displayed. When played to the end, the time increases second by second until playback has been finished.

• Steps to reproduce the problem: -- Either have a multi-device setup with one Android and one Desktop client of Delta Chat, or receive a voice message that was recorded with Delta Chat for Android in the Desktop app. -- Start playback and do not stop until finished. (Result: The initial total time value will increase during playback.) -- Alternatively export the audio file to disk and start playback with a different media player, the result should be comparable...

• Screenshots: N/A.

• Logs: N/A.

• Remarks: The reason why I am opening this issue in the Android repository of Delta Chat is because I believe that there might be a problem with AAC encoding of voice messages in the Android app. The following values for sample and bit rates are stored in the file "AudioCodec.java": https://github.com/deltachat/deltachat-android/blob/20ab00d30261f8c39c9252c67cdf08a390da7cd9/src/org/thoughtcrime/securesms/audio/AudioCodec.java#L26-L30 According to chapter 1.6.3.4 "samplingFrequencyIndex" of "ISO/IEC 14496-3:2009(E)" ("Information technology - Coding of audio-visual objects - Part 3: Audio"), each of these frequency values represent specific ranges used for variable bit rate encoding. In this case, AAC total time is estimated by the app which decodes and plays the AAC audio file. To my understanding, the correct index value according to the respective frequency range must be written to the AAC file header. Currently, we seem to apply index value 4 (0x4, reserved for the range around 44100 Hz) to each frequency range we may address, which, I believe, could have a negative impact on total time calculation. (E.g. index value 5 (0x5) should be used for 32000 Hz ("BIT_RATE_BALANCED"), and 6 (0x6) for 24000 Hz ("BIT_RATE_WORSE").) Further tests done with "Google Chrome" (on Linux) and "VLC media player" as well as with "Windows Media Player" (on Windows) show similar behavior and are not able to calculate the total time value properly.

[gerryfrancis]

Maybe related: https://github.com/deltachat/deltachat-ios/issues/1923

[r10s]

Currently, we seem to apply index value 4 (0x4, reserved for the range around 44100 Hz) to each frequency range we may address, which, I believe, could have a negative impact on total time calculation. (E.g. index value 5 (0x5) should be used for 32000 Hz ("BIT_RATE_BALANCED"), and 6 (0x6) for 24000 Hz ("BIT_RATE_WORSE").)

we are always using a sample rate of 44100 Hz, so the samplingFrequencyIndex of always "4" is correct.

what we're modifying is only the bit rate, and that is unrelated to the sample rate.

(you can think of the sample rate as the number of samples taking per second - the bitrate then says how much that has to be compressed by some algorithm)

[adbenitez]

this code comes from the Signal source code and the issue is also present there, here is a sample voice message recorded with Signal app, if you send it in delta chat desktop, MPV or VLC the times are different than on the signal app

signal-2023-09-26-14-11-26-774.tar.gz

I recommend to open an issue for this in the upstream project, then when it is fixed there we can port the fix back, that is if we don't switch to something nicer like ogg for voice messages at some point