Dear ODK users,
My name is Inti and I collaborating with farmers to collect information about natural resources and crop yield. We want to record audio for an open question and I have read the documentation regarding question types (https://docs.getodk.org/form-question-types/) in which 2 apps are mentioned:
Audio Recorder from Sony
We notice the are ads in the RecForge II Free version and we were wondering if there are other options that are free and no adds. If there is any open source app that would be even better. Could you recommend some apps to try? Thank you for your help.
I've been using Google's "Recorder" app recently which is about as close as you can get to a "stock" recorder app on Android. It's not open source but is free and works nicely.
Would be interested to see if others have suggestions as it has always been annoying to have to find apps due to Android not having an actual sound recorder that ships on most devices.
The Sony app has actually been discontinued - a real shame as it was great. I've filed an issue in the docs about this.
Thank you for reply and recommendation.
Today I was talking to a developer to finance a "Simple Open Audio Recorder", it will be open and the code will be available in my github account to start, but we are looking for some organization, maybe it could be of the interesting of ODK collective to host it and maintenance. I will deliver the full code for free. I will like to hear some feedback from ODK developers and community in case there is someone interesting.
The key points of this app are:
- Available on google play and it can be run on Android.
- NO ADDS
- Audio could be recorder in mp3 or wav
- Open source code
Any other simple suggestion or recommendation whom to talk to about it?
@seadowg Is there a good reason why we shouldn't build an inline recorder for Collect?
@yanokwa I think it'd actually make a lot of sense. I use Collet for field recording so have been thinking about this recently. I think as long as Collect also allowed users to use third party apps there would be only really upsides from an enumerator point of view to having recording in the app.
I'd imagine when the original audio widget was built there was more of an assumption Android would, at some stage, adopt a stock audio recorder (like on iOS) but this has never happened and even worse, the ecosystem around audio recorders on Android has never stabilized. How long before Google kill that recorder app?
@Inti_Luna if you're interested in funding development of an audio recorder for Collect (with the key points you've outlined) I think talking to @yanokwa here is your best course of action. I'd love to see this happen and I think there are also some cool options around building in-app recording that can also be distributed as a standalone app but we can hopefully we can talk more about that soon!
Thank you @seadowg and @yanokwa for the comments. For sure, let´s talk about it.
When would be a good time to talk next week? Please contact me at my email: firstname.lastname@example.org so I can coordinate a meeting with the developer / developers that would be helping me. Thanks!
Why only these formats?
I've been involved on qualitative studies where we need to record an interview up to 1 Hour and we struggled with mp3 or wav. The dimension of the final file was huge and it was impossible to manage then to upload the file on the server.
We found an apk that produce amr file that translate to a file less then 5MB.
If collect would have an inline recorder should allow to choose the compression size in a way to deal with long recording.
What do you think @seadowg and @yanokwa ?
Thank you for the comments and great that you mentioned the issue with file size when you have long audio with this format. I am planning to use it sometimes for interviews and I agree with you that we should look for other formats that could be more efficient when handling file size.
Please share more information regarding the apk that you use so we search more about it and check what would be needed to integrate it in the app (or inside odk). I will have to validate with the developer/co-financer if this could be part of the initial scope and if not we would need some help.
The next step seems to be for @Inti_Luna and @yanokwa to talk and I'll share a few thoughts in the mean time.
Really good to know about the Adaptive Multi-Rate audio codec (
amr) which I was not familiar with. Thanks, @aurdipas. I hope at some point I can explore how it compares to
aac in terms of file size and fidelity.
Looking at APK Mirror, it's likely that what @aurdipas used was an early version of the Sony app that we recommended. It's too bad that it has been discontinued. All its APKs are available on APK Mirror. I've successfully downloaded and used the latest but please be aware there is some risk in this approach since APKs may not be as carefully vetted as on the Play Store.
Historically, recording was done through an external app to limit the already large scope of Collect and to let users with external microphones and other specialized needs pick an appropriate tool. It does seem like this has been inconvenient for the common case.
This ties in with @Tino_Kreutzer's rough spec at Create automatic background recording of interview in Collect.
Thanks for tagging me @LN. It's been on my to do list forever to write a post to describe how native recording functionality could look like (UI and specs) so I'm extremely glad @Inti_Luna kicked this off. We have also earmarked funding for this feature, so hopefully we can pool resources do something amazing here.
I agree that AMR is a requirement to keep file size manageable.
I went ahead and created a dedicated thread to help spec out the requirements of native recording functionality.
That sounds great! Really good to hear you have some UI ideas. The big question mark for me is whether it's important to still allow for external apps if we offer codec and bitrate options. I've never worked with a project that used external audio equipment and it would be helpful to hear from one that does.
Doing a little bit more digging, Axet audio recorder seems to be the most widely-used open source Android recorder app. It has many different encoding options and lots of nice features like audio trimming. It's GPLv3 (source code) and actively maintained. We have updated the documentation to refer to it.
I see from Adding native audio recording for `audio` type questions that you have also started a new project, @Inti_Luna. It seems your focus is on being cross-platform so it may fill a different niche.
For researchers doing qualitative research, interviews are a commonly used method.
For some studies then we use for example transcription software like express scribe to transcribe it for analysis.
In other studies we used the recording to validate the study (comparing paper vs EDC) etc etc...
I am not an expert myself, but the interviews will be transcribed, translated (when appropriate if not English), de-identified and coded using dedicated software such NVivo, ATLAS.ti, before being analysed.
@aurdipas @Thalie these are great details. Do you find you need certain audio formats or minimum quality levels for transcribing interviews?
the main problem when you record long interviews (up to an hour), is the file size. In a study in Albania we used amr encoding.
Using this encoding we ended up to a 5 MB file per hour recording.
We tested it with the express scribe software and that worked.
Moreover when we started the study, due to the Covid pandemy, we had to make the interview by phone.
So loud speaker and record from the tablet... and it worked well too
@aurdipas I have just tested the AMR audio-encoded Android package that you suggested and it indeed runs very smoothly with a resulting audio file under 6 MB for ~65 min of recording. I have also noticed the app is simpler than RecForge II, which makes the interactions within the ODK form fairly easy.
I will still benchmark the different options, including the Axet audio recorder LN mentioned and the Opus format mentioned in the thread created by Tino. The main criteria I would focus on at this stage would be the usability (recording with a given compressed format should be as straightforward as possible for the data collector, with as less manipulation as possible), the size of the audio file (for both transfer and storage) and the quality of the audio for transcription, possibly testing in different contexts (we have a walking interview, so possibly a more challenging recording environment).
On a note, the social scientist I am working would indeed like to use external audio equipment, so I may have some information about this once we are there.
Thanks again for all the information available on the forum, this is gold!