Deltachat-android: audio message UI

Created on 13 Dec 2018  路  11Comments  路  Source: deltachat/deltachat-android

  • Platform (android/blackberry/anbox): Android
  • Device: Honor 8
  • Delta Chat Version: 0.90.0

img_20181211_115031

The recieved audio messages (from telegram-android) don't show a play button, but can be played if you know where to click.

on dragging the reel bar, there is not a circle painted (cut on top and bottom); I don't know if this is the desired behaviour

Both of them are probably a problem of which UI elements are paintet in the front or in the back.

If you need further information I can try to provide debug logs and other things

bug

Most helpful comment

@violoncelloch i think this needs some dev skills first, we will target this sooner or later, however, it's not the most pressing issue currently imho.

but in general, it is of interest _which_ format is supported by most android versions - and can also be played by the chromium browser (electron) and ios without problems.
i'd like to avoid adding additional libraries for encoding/decoding - there are already enough problems with the existing dependencies.
also, afaik aac ist not the most free format.
might be mp3 in the end.

All 11 comments

@violoncelloch thanks for bringing up this issue.

telegram-ui uses ogg-files with a more or less special codec while the new interface uses aac-files.

however, even if android-dev cannot play the file as such, it should render it as a document so that it can be opened by an app that can potentially play it.

otoh, it might only be a problem of the mime type, we had a similar issue with videos.

needs some research :)

Anything I can do to help? Test?

@violoncelloch i think this needs some dev skills first, we will target this sooner or later, however, it's not the most pressing issue currently imho.

but in general, it is of interest _which_ format is supported by most android versions - and can also be played by the chromium browser (electron) and ios without problems.
i'd like to avoid adding additional libraries for encoding/decoding - there are already enough problems with the existing dependencies.
also, afaik aac ist not the most free format.
might be mp3 in the end.

wrt formats supported by android: https://developer.android.com/guide/topics/media/media-formats

the f-droid verison creates ogg-opus which is not supported by stock android.

but we could maybe go to mkv-opus - i am pretty sure, electron can play this, however, not sure about ios.

seems as if neither ogg nor mkv are playable nativly by osx - not totally sure about ios, but i feat it is the same: https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/CoreAudioOverview/SupportedAudioFormatsMacOSX/SupportedAudioFormatsMacOSX.html

sending a voice message from the dev version to v0.20 works as expected (shows the audio attachment) this is a bug on the dev version

android-dev just does not support the codes used in the f-droid-version (ogg-opus); and it is questionable if we add support to ogg-opus to android-dev at all.
of course, this would result in an incompatibility between 0.20 and 0.97, however, after users have upgraded it will be fixed.

On Thu, Jan 03, 2019 at 08:45 -0800, bj枚rn petersen wrote:

android-dev just does not support the codes used in the f-droid-version (ogg-opus); and it is questionable if we add support to ogg-opus to android-dev at all.
of course, this would result in an incompatibility between 0.20 and 0.97, however, after users have upgraded it will be fixed.

wouldn't this mean that after the f-droid upgrade, older audio messages
could not be played anymore? This could disrupt ongoing chats
(the upgrade comes anytime in between, triggered from f-droid).

wouldn't this mean that after the f-droid upgrade, older audio messages could not be played anymore?

yes, unfortunately, this may happen.

ogg-opus would then be forwarded just to an "app that can play the data" - which may be none. the data as such are not gone, of course.

i think, however, for a beta-version, this is arguable.

however, before a final decision, i would like to profile the file sizes of ogg-opus a bit - compared esp. with lower-bitrate-mp3.

if the difference is "too large", i think we should stay with ogg-opus, otherwise, i would vote for having a bunch of dependencies fewer (ffmpeg just to mention one; also for ios this would make things harder)

some information about file sizes for a one-minute voice-message:

  • 0.20 tg-f-droid-version using ogg-opus: 150K
  • 0.97 android-dev-version using aac-opus: 260K
  • mp3@16kbps: 130K (estimated)
  • mp3@32kbps: 260K (estimated)

the quality for voice in mp3@16kbps is not _that_ bad, here is a 33 second example, the mid part is mp3@16kbps:
https://en.m.wikipedia.org/wiki/File:Test_mp3_opus_16kbps.wav

maybe using mp3@32kpbs is a reasonable approach. also as it is easier for non-delta-clients to play the files - mp3 can be played virtually everywhere, using mp3 as voice-message-format was also a user-request here and there.

wrt to compatibility to tg-f-droid-version: https://en.m.wikipedia.org/wiki/Opus_%28audio_format%29 says at least Android 6 and android 7 can play ogg-opus, will check this out.

The problem isn't that v0.97 is incompatible with the ogg format but that there are a bug in 0.97, the audio should be shown as a file attachment that users can tap to play with other app since 0.97 don't support it, currently a buggy empty message is shown, if user tap in the left part of the empty message the audio is played, so seems like 0.97 actually can play it it just fail to show the audio with a player or with a file icon as shown in the image shared by violoncelloCH

r10s if the quality for voice in mp3@16kbps is "not that bad" +1 to mp3@16kbps, on slow/paid connections small size is really appreciated :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

r10s picture r10s  路  4Comments

r10s picture r10s  路  4Comments

travisfw picture travisfw  路  5Comments

adbenitez picture adbenitez  路  4Comments

angelo-fuchs picture angelo-fuchs  路  4Comments