Closed NetSysFire closed 1 month ago
Can you talk about what kind of device sent those messages with the incorrect duration? It's more about the sender than the receiver, based on what we've seen.
Sender is Android, too. A samsung device, probably A15 or the likes. What exact information do you need?
We've gotten other reports of inaccurate audio durations when Android sends to Desktop. Maybe you could test the other direction, or Desktop <-> Desktop? It's likely that this is the same bug we've seen with Android in the past.
I did some testing and desktop <-> desktop appears fine. However, when I download one of the affected voice messages and resend them from desktop, same issue. It appears that the android version is recording slightly broken files because if I play the aac file with mpv, I get the exact same issue. Test voice message is displayed as 35 seconds long but is actually 38 seconds long. With an added warning from ffmpeg:
[ffmpeg/demuxer] aac: Estimating duration from bitrate, this may be inaccurate
Unfortunately I can not upload the voice message here for privacy reasons but I may be able to supply one tomorrow.
Edit: Signal desktop produces mp3 files when recording a voice message in contrast to aac on Android.
Yeah, I think your best bet is to file the bug on Signal Android with the actual audio file: https://github.com/signalapp/Signal-Android/issues. I'm going to close this.
Using a supported version?
Overall summary
This is pretty much exactly #6908, except that this is a supported signal desktop build. The issue has been present since quite some time but I could never bothered to report this until now. This is a minor issue as the effect is purely cosmetic and does not actually affect how a voice message is played.
Steps to reproduce
Expected result
The timer and progress bar matches the length of the voice message exactly.
Actual result
The progress bar and timer reaches its end too soon. Any voice message is pretty much always a couple of seconds longer than the UI expects. I think this scales with length, the longer the voice message, the higher the inaccuracy.
With a 2 minutes and 18 seconds long voice message I got ~11 seconds of inaccuracy.
Voice message as displayed in signal desktop:
The very same voice message as displayed on my linked Android phone:
The sender of the voice message also uses Android.
Screenshots
No response
Signal version
7.26.0 production
Operating system
Arch Linux
Version of Signal on your phone
7.17.6 (Android)
Link to debug log
In app.log I see the following events spammed after the voice message exceeds the expected length: