Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for writing a JSON file containing call metadata #380

Closed
chenxiaolong opened this issue Jul 19, 2023 · 5 comments · Fixed by #382
Closed

Add support for writing a JSON file containing call metadata #380

chenxiaolong opened this issue Jul 19, 2023 · 5 comments · Fixed by #382
Assignees
Labels
enhancement New feature or request

Comments

@chenxiaolong
Copy link
Owner

(Idea from #135 (comment))

The metadata would be stored in a .json file next to the audio file and would look something like this:

{
    // Raw timestamp as the number of milliseconds since the Unix epoch
    "timestamp_unix_ms": 1689806425000,

    // Timestamp in RFC3339/ISO8601-compatible format
    "timestamp": "2023-07-19 18:40:25-04:00",

    // Call direction: in, out, or conference. (null if unknown or Android <10)
    "direction": "in",

    // SIM slot (null if Android <11 or phone permission is denied)
    // Numbering starts from 1, not 0
    "sim_slot": 1,

    // Display name of the call, as shown in the dialer's call log
    // (This may include the business' name for dialers that perform reverse lookups, like Google Dialer)
    "call_log_name": "John Doe",

    // (Contains multiple items if it's a conference call)
    "calls": [
        {
            // Raw phone number as reported by Android (null for private calls)
            // For outgoing calls, this is usually what the user typed.
            // For incoming calls, this is usually E.164 formatted.
            "phone_number": "+11234567890",

            // Phone number in the country-specific format (null for private calls, unknown country, or if Android can't parse the phone number)
            "phone_number_formatted": "+1 (123) 456-7890",

            // Contact name (null if contact does not exist or contacts permission is denied)
            "contact_name": "John Doe",

            // Caller name (Caller ID) (null if unavailable)
            "caller_name": "John Doe"
        }
    ]
}
@chenxiaolong chenxiaolong added the enhancement New feature or request label Jul 19, 2023
@chenxiaolong chenxiaolong self-assigned this Jul 19, 2023
chenxiaolong added a commit that referenced this issue Jul 20, 2023
The JSON file contains all of the metadata known to BCR (which roughly
matches the information that can be used in the filename templates).
This feature is disabled by default.

The majority of this commit is splitting the call metadata collection
out of OutputFilenameGenerator. This is something that should've been
done anyway.

The notification delete button logic has also been reworked so that the
metadata file is also deleted. If debug mode is enabled, the log file
will now also be deleted.

Closes: #380

Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
@nicorac
Copy link
Contributor

nicorac commented Jul 20, 2023

This is a great idea, thanks for it!
I'm ready to build a POC app once this will be available (or at least testable)...

@chenxiaolong
Copy link
Owner Author

This has been released in version 1.48!

@nicorac
Copy link
Contributor

nicorac commented Jul 21, 2023

This has been released in version 1.48!

Great, I'll work on a "companion-app" 😉.
Should it be possible, in the future, to also have a "call duration" field in JSON?
It's surely be easier for you to add this info than for me to "extract" length from each file...

chenxiaolong added a commit that referenced this issue Jul 21, 2023
Issue: #380

Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
@chenxiaolong
Copy link
Owner Author

Should it be possible, in the future, to also have a "call duration" field in JSON?

Sure! I've created #387, which will add a bunch of info about the output format and encoding process to the metadata file (which includes the duration in the duration_secs_encoded field).

chenxiaolong added a commit that referenced this issue Jul 21, 2023
Issue: #380

Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
chenxiaolong added a commit that referenced this issue Jul 21, 2023
Issue: #380

Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
chenxiaolong added a commit that referenced this issue Jul 21, 2023
Issue: #380

Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
chenxiaolong added a commit that referenced this issue Jul 21, 2023
Issue: #380

Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
@nicorac
Copy link
Contributor

nicorac commented Aug 8, 2023

Great, I'll work on a "companion-app" 😉.
Should it be possible, in the future, to also have a "call duration" field in JSON?
It's surely be easier for you to add this info than for me to "extract" length from each file...

Sure! I've created #387, which will add a bunch of info about the output format and encoding process to the metadata file (which includes the duration in the duration_secs_encoded field).

As promised... I did it 😉

I've called my app BCR-GUI, to clearly show that it depends on BCR (which is actually doing the "hard work").
(if you don't like its name, or think it's misused, please let me know)

It basically shows recordings in a list; call details are shown for each recording and user can listen audio within the app (no external player needed). Next versions will have edit, share, delete, ... and other features (can't actually imagine others).

Please check it out and share your thoughts.
It's still in early development stage, but already usable and working (at least basic features).

I don't want to further spam here 😂; if you think it worths being mentioned in your readme... feel free to do it (or contact me).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants