Output format M4A/AAC corrupt (missing moov header?) #143
Comments
The buffer size of `logcat -d` may not be enough to preserve all of the logs. Issue: #143 Signed-off-by: Andrew Gunnerson <chillermillerlong@hotmail.com>
First attempt at trying to understand why the `moov` atom is not being written on older Android devices. Issue: #143 Signed-off-by: Andrew Gunnerson <chillermillerlong@hotmail.com>
First attempt at trying to understand why the `moov` atom is not being written on older Android devices. Issue: #143 Signed-off-by: Andrew Gunnerson <chillermillerlong@hotmail.com>
|
Glad you're enjoying the app! This is an interesting bug. It looks like in every recording, Android's MediaMuxer is not finalizing the files at all. Several headers are missing (including It's a bit difficult to tell what's going on because Android 9's muxer doesn't have many debug logs and it silently ignores errors in several places. If certain errors occur, Android seems to intentionally skip writing the Can you give this debug build a try and upload the new debug logs? BCR-1.21.r6.g4bc5cdb-debug.zip There are two changes:
Also, how much free space is available in the default output directory? EDIT: This might be a lot harder to troubleshoot than I thought. I took a quick look at the Galaxy S8's |
|
Hi,
Thanks for the quick reply, I'll give it a try!
There's around 6GB in the default output folder, should be enough I guess.
Jeroen
…On Wed, Oct 5, 2022, 18:53 Andrew Gunnerson ***@***.***> wrote:
Glad you're enjoying the app!
This is an interesting bug. It looks like in every recording, Android's
MediaMuxer is not finalizing the files at all. Several headers are missing
(including moov) and the file size header is set to 1061109567 bytes
(which is ???? in ASCII text).
It's a bit difficult to tell what's going on because Android 9's muxer
doesn't have many debug logs and it silently ignores errors in several
places. If certain errors occur, Android seems to intentionally skip
writing the moov header.
Can you give this debug build a try and upload the new debug logs?
BCR-1.21.r6.g4bc5cdb-debug.zip
<https://github.com/chenxiaolong/BCR/files/9717459/BCR-1.21.r6.g4bc5cdb-debug.zip>
There are two changes:
- #145 <#145>, which should
hopefully fix the empty log file issue.
- MediaMuxer stop is called before release. It shouldn't be necessary,
but might help.
Also, how much free space is available in the default output directory?
—
Reply to this email directly, view it on GitHub
<#143 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGC5O7GOZMYSRZHARFWTP3TWBWXB7ANCNFSM6AAAAAAQ5PISUI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Hi,
See attachements for a recording and logfile, using the debug version
you've sent me.
Hope this clears things up a bit.
Thanks!
[debug.zip](https://github.com/chenxiaolong/BCR/files/9719114/debug.zip)
|
|
Thanks for the new recording and log file! Unfortunately, not much new information. Can you give this app a try and upload its output file? MuxMpeg4Test.zip (It's just a regular The test app is BCR, but with all features stripped out. The only thing it does is encode silence into an m4a/aac file. That way, we can test just the encoder without anything else possibly affecting the process. If this output file is also broken, then there's a good chance this is a bug in the Samsung stock Android 9 firmware and you might have to pick a different output format for call recording. |
The buffer size of `logcat -d` may not be enough to preserve all of the logs. Issue: #143 Signed-off-by: Andrew Gunnerson <chillermillerlong@hotmail.com>
|
Thnx for the test APK! Looks like this one is playing well. Thnx! |
|
Hmm, that file does indeed look normal! It has I wonder why BCR doesn't work then. The encoding settings are identical (64Kbps, 48kHz). The only difference is that the audio comes from the call recording "microphone" instead of just being silent. One more test: can you try a longer recording with the test app? (eg. around 45+ seconds to match the initial BCR recordings) |
|
It's playable in VLC.... |
|
I see it's not 45+ sec....but 44. I'll post another |
|
This one is longer |
|
Thanks for the new uploads! Those both look good. Can you give this debug build of BCR a try? BCR-1.21.r5.gac4c3be-debug.zip Please make 2 recordings: once using the default output directory and once using a custom one. |
|
Ok, done.
I did notice a few strange things concerning the logs:
My guess: logfiles are always stored at the default location ? Anyway, these are the recordings. |
Hmm, that's extremely weird. BCR stops logging and closes the file 1 second after the call ends. You might be on to something though. If the files are somehow not being flushed properly, maybe that's what's happening to the audio file too. Android does not write the headers until the very end when closing the file.
BCR always writes the log to the default location first and then moves the file to the custom location when the call is complete. (or at least it's supposed to...) I'll make one more debug build after work today to try a new idea: I'll made BCR record to the internal app directory in |
|
Please give this build a try: BCR-1.21.r9.g559d30a-debug.zip It'll write the audio and log files to EDIT: Forgot to mention, this build has two changes: it writes to the internal app directory and also forces a flush via |
|
Hi, I tried r9, see files: Files were indeed stored at /data/data/com.chiller3.bcr/files, both logfiles and call recording. The logfile was still flushed, until a second call was made. Really stange. |
|
I do see this error in the log: Strange thing is that the encode_test APK does seem to produce a valid recording file. It doesn't produce a logfile, so it's hard to compare. |
|
Thanks for the new upload! One thing I noticed the logs when you make 2 calls is this: It looks like the call is only around 45 seconds, but BCR doesn't stop trying to record the first call until 6 minutes later (at 01:48) when you make the second call. I think either Android is not notifying BCR that the call is complete or if it is notifying, maybe BCR doesn't understand the message. This would explain why the files appear as if they're incomplete and not flushed. EDIT: Please use this new debug build of BCR for the test below: BCR-1.21.r10.g6898f68-debug.zip If you have adb, can you:
I am hoping these logs will show how Android is telling BCR that the call is complete.
Yep, that is perfectly normal. That message is printed right after the |
|
Hi, thanks for your patience! I'll try to make a logcat in the morning (3am here now)... |
|
No problem! We'll find a way to solve it 🙂 |
|
e-mail has been sent, 2 calls + logs, and logcat |
The output files should generally be unique, but that's not guaranteed. Without truncation, the output files may potentially be corrupted due to the presence of old data at the end. Issue: #143 Signed-off-by: Andrew Gunnerson <chillermillerlong@hotmail.com>
The output files should generally be unique, but that's not guaranteed. Without truncation, the output files may potentially be corrupted due to the presence of old data at the end. Issue: #143 Signed-off-by: Andrew Gunnerson <chillermillerlong@hotmail.com>
Call.Callback.onStateChanged() is not guaranteed to be called for STATE_DISCONNECTING or STATE_DISCONNECTED. This is documented behavior that was overlooked. While it worked on firmware with fewer changes on top of AOSP, it does not work on Samsung devices. Issue: #143 Signed-off-by: Andrew Gunnerson <chillermillerlong@hotmail.com>
|
Thanks for the email! Yep, this is a Samsung firmware bug. The Android/Samsung telephony framework is failing to notify apps when calls end. It's not just BCR, it's also failing to notify Samsung's own Knox-related components. Specifically, it's not notifying about any of these 3 events:
However, it does happen to send a |
chenxiaolong
added
the
bug/limitation elsewhere
|
Thanks, that would be great! Then, other Samsung models are likely to experience the same issue ? |
On older Samsung firmware, the telephony framework fails to notify InCallService implementations about call disconnections. This doesn't just happen with BCR. It affects Samsung's own apps too, like Knox's InCallServiceImpl. Due to this bug, none of the following callbacks are called when a call ends: * Call.Callback.onStateChanged with Call.STATE_DISCONNECTING or Call.STATE_DISCONNECTED * Call.Callback.onCallDestroyed * InCallService.onCallRemoved However, it does happen to call Call.Callback.onDetailsChanged when the call state transitions to Call.STATE_DISCONNECTED (which doesn't happen with AOSP). This commit reworks RecorderInCallService to keep track of calls better in the face of these firmware bugs. A call's lifetime begins when InCallService.onCallAdded is called and ends when either InCallService.onCallDestroyed is called or the state is Call.STATE_DISCONNECTING or Call.STATE_DISCONNECTED in any other callback. This should work on both well-behaved firmware, like AOSP, and buggy firmware, like Samsung's OneUI. Issue: #143 Signed-off-by: Andrew Gunnerson <chillermillerlong@hotmail.com>
|
Please give this debug build a try and grab the full logcat: BCR-1.21.r14.gf7ede65-debug.zip Really hope this one does the trick! This build adds a workaround to try and detect the end of calls via
Yep, I think that's likely, at least for other devices running Samsung's Android 9 firmware. I'm not sure if it's fixed in newer Samsung firmware--I would need to see a logcat to know. |
|
Hi, I installed the module twice, but in the app itself the version keeps showing r9, where I expected r14 (as in the file name). |
|
Hmm, that's weird. Can you uninstall the module, run I'm not sure why it wouldn't upgrade. |
|
I've tried adb uninstall, it gave an exception/stack trace... C:\Temp\adb>adb uninstall com.chiller3.bcr Exception occurred while executing: Then, I downloaded the package again, installed as module in Magisk, see logfile. I've tried installing app-debug.apk, but the version stayed 1.21-r9. Hmmm, may we talk about different things?
Am I missing something? |
|
As a test, I installed release 1.20, and the version displayed in the app's page was so 1 |
Ah, I see. I misunderstood what you were saying before. I decompiled the apk and it does look like old code ended in there somehow. I've never seen that happen before. I've rebuilt r14 from scratch. This should no longer include any old code. BCR-1.21.r14.gf7ede65-debug.zip EDIT: Even though the version field said r9, looks like the new code was present. I'm looking through the latest logs you uploaded now. |
On older Samsung firmware, the telephony framework fails to notify InCallService implementations about call disconnections. This doesn't just happen with BCR. It affects Samsung's own apps too, like Knox's InCallServiceImpl. Due to this bug, none of the following callbacks are called when a call ends: * Call.Callback.onStateChanged with Call.STATE_DISCONNECTING or Call.STATE_DISCONNECTED * Call.Callback.onCallDestroyed * InCallService.onCallRemoved However, it does happen to call Call.Callback.onDetailsChanged when the call state transitions to Call.STATE_DISCONNECTED (which doesn't happen with AOSP). This commit reworks RecorderInCallService to keep track of calls better in the face of these firmware bugs. A call's lifetime begins when InCallService.onCallAdded is called and ends when either InCallService.onCallDestroyed is called or the state is Call.STATE_DISCONNECTING or Call.STATE_DISCONNECTED in any other callback. This should work on both well-behaved firmware, like AOSP, and buggy firmware, like Samsung's OneUI. Issue: #143 Signed-off-by: Andrew Gunnerson <chillermillerlong@hotmail.com>
On Samsung devices, when a call ends, AudioRecord.read() blocks until another call becomes active, which prevents recordings from stopping at the correct time. This behavior does not happen in AOSP. To work around this, use non-blocking reads with a sleep interval of the AudioRecord minimum buffer size. This gives the recording loop a chance to check if recording has been cancelled. Issue: #143 Signed-off-by: Andrew Gunnerson <chillermillerlong@hotmail.com>
|
Please give this build a try: BCR-1.21.r16.gdd3cbe7-debug.zip Based on the previous logs, BCR is now able to detect the end of the call, but is not able to cancel the recording. I added a workaround for that in this new build. |
|
Calls5.zip I'll keep this version and try it the next few days Thanks for all the hard work! |
|
Awesome, thanks for being so patient and helping with testing! |
On older Samsung firmware, the telephony framework fails to notify InCallService implementations about call disconnections. This doesn't just happen with BCR. It affects Samsung's own apps too, like Knox's InCallServiceImpl. Due to this bug, none of the following callbacks are called when a call ends: * Call.Callback.onStateChanged with Call.STATE_DISCONNECTING or Call.STATE_DISCONNECTED * Call.Callback.onCallDestroyed * InCallService.onCallRemoved However, it does happen to call Call.Callback.onDetailsChanged when the call state transitions to Call.STATE_DISCONNECTED (which doesn't happen with AOSP). This commit reworks RecorderInCallService to keep track of calls better in the face of these firmware bugs. A call's lifetime begins when InCallService.onCallAdded is called and ends when either InCallService.onCallDestroyed is called or the state is Call.STATE_DISCONNECTING or Call.STATE_DISCONNECTED in any other callback. This should work on both well-behaved firmware, like AOSP, and buggy firmware, like Samsung's OneUI. Issue: #143 Signed-off-by: Andrew Gunnerson <chillermillerlong@hotmail.com>
On older Samsung firmware, the telephony framework fails to notify InCallService implementations about call disconnections. This doesn't just happen with BCR. It affects Samsung's own apps too, like Knox's InCallServiceImpl. Due to this bug, none of the following callbacks are called when a call ends: * Call.Callback.onStateChanged with Call.STATE_DISCONNECTING or Call.STATE_DISCONNECTED * Call.Callback.onCallDestroyed * InCallService.onCallRemoved However, it does happen to call Call.Callback.onDetailsChanged when the call state transitions to Call.STATE_DISCONNECTED (which doesn't happen with AOSP). This commit reworks RecorderInCallService to keep track of calls better in the face of these firmware bugs. A call's lifetime begins when InCallService.onCallAdded is called and ends when either InCallService.onCallRemoved is called or the state is Call.STATE_DISCONNECTING or Call.STATE_DISCONNECTED in any other callback. This should work on both well-behaved firmware, like AOSP, and buggy firmware, like Samsung's OneUI. Issue: #143 Signed-off-by: Andrew Gunnerson <chillermillerlong@hotmail.com>
On Samsung devices, when a call ends, AudioRecord.read() blocks until another call becomes active, which prevents recordings from stopping at the correct time. This behavior does not happen in AOSP. To work around this, use non-blocking reads with a sleep interval of the AudioRecord minimum buffer size. This gives the recording loop a chance to check if recording has been cancelled. Issue: #143 Signed-off-by: Andrew Gunnerson <chillermillerlong@hotmail.com>
On Samsung devices, when a call ends, AudioRecord.read() blocks until another call becomes active, which prevents recordings from stopping at the correct time. This behavior does not happen in AOSP. To work around this, use non-blocking reads with a sleep interval of the AudioRecord minimum buffer size. This gives the recording loop a chance to check if recording has been cancelled. Issue: #143 Signed-off-by: Andrew Gunnerson <chillermillerlong@hotmail.com>
|
Version 1.22 has been released! The code is identical to the debug build you're already running. If you run into any further issues, feel free to create a new issue. |
Used the current release (1.22) for a while and works as expected !! |
Hi,
First of all, I love the simplicity of this app. Keep it that way!
I do noticed that the recorder does record conversations, but the generated m4a/aac files cannot be played correctly.
I tried to fix them with e.g. ffmpeg, but it seems the moov header is missing? Not sure tough, as I'm not familiar with the aac format.
See attached files for a few examples.
calls.zip
Here's one with debuglogging:
with debuglog.zip
I'm using BCR version 1.20 (release + debugmode)
Installed /enabled as Magisk module
On Android 9, running on Samsuing S8 stock firmware (rooted obviously).
Output dir is default (com.chiller3.bcr/file), format is also default (m4a/aac, 64kbps, 48kHz)
App Permissions are Contacts and Microphone
Although I'm not in favor submitting multiple issues at the same time, I also notice that the debug file is often missing, or sometimes has a size of 0 bytes.
Hope you can help,
Thanks!
The text was updated successfully, but these errors were encountered: