AudioRecorder options are iOS / macOS only but in the general namespace

[jasonkneen]

I have searched and made sure there are no existing issues for the issue I am filing

• [X] I have searched the existing issues

URL

https://titaniumsdk.com/api/titanium/media/audiorecorder.html#format

Description

So docs and API related. This page

https://titaniumsdk.com/api/titanium/media/audiorecorder.html#format

has formats and compression options that are iOS and macOS only yet are not in a specific platform namespace

Suggestion

These should me moved to a namespace like

Titanium.Media.iOS.AUDIO_FILEFORMAT_3GP2

or similar -- it's frustrating when trying to work with Android and assuming that these should work.

OR we should provide compression and format options for Android too.

[m1ga]

The Availability shows only iOS and macOS so I don't think it should be moved into the iOS namespace. Making (some of) them parity is the better way: https://github.com/tidev/titanium_mobile/pull/13456

it's a start and adds:

format: Titanium.Media.AUDIO_FORMAT_AAC
format: Titanium.Media.AUDIO_FILEFORMAT_MP4 
format: Titanium.Media.AUDIO_FILEFORMAT_3GPP
format: Titanium.Media.AUDIO_FILEFORMAT_WAVE (default)

current workaround to record other formats: https://github.com/m1ga/AudioRecorder (binary in dist folder).

Result is:

[INFO]  tia6804134970679070179.wav
[INFO]  size: 291308

[INFO]  tia4291767024815221435.mp4
[INFO]  size: 6234

[INFO]  tia7883799336317587400.aac
[INFO]  size: 2900

[INFO]  tia3415434455734300237.3gp
[INFO]  size: 5876

[jquick-axway]

@m1ga , @jasonkneen , there's a reason why Titanium's Android audio recorder is limited to uncompressed WAV/PCM format. It's the only guaranteed format we can implement.

I know about the Android SDK's audio compression format constants... and I've literally seen them all fail to work on various devices. Just because the constant exists in the Android SDK doesn't mean the device supports that audio format. That's the problem. At least in my experience working on Android for about 10 years. 3GP seems to be the most widely supported format... and I've only seen it fail on Barnes & Noble's Nook devices (which is a dead product line).

Anyways, that's my warning to you. It's an ugly problem. WAV is the only guaranteed recording format.

[m1ga]

@jquick-axway thanks for the input! Didn't know that!

I think a better solution would be record to wav and use ffmpeg to convert it to mp3. So you still can send a smaller file. In ffmpeg you can list the codecs and check if its available otherwise send the wave. In my tests I already found some codecs that didn't work on my Pixel phone! Will make a note in the README that you know if it fails you'll have to switch to wave at the end again.

[jquick-axway]

@m1ga , thanks for testing it out. It sounds like it's still a problem to this day. And I don't recall there being any APIs to detect what formats/codecs are supported on the device either (not on Android; Windows has APIs for this). Which means your only option is to "go for it" and check if the recording failed. Kind of sucks.

I think the reason why things are like this is because device manufacturers don't want to pay for royalties/licensing for some of these formats. That's how they keep the device prices low. At least I believe that's the case for cheap tablets like the B&N Nook, Amazon Kindle/Fire, etc.

[jquick-axway]

I wonder if you can use the MediaCodecList.findEncoderForFormat() method to detect if the audio format is supported. Note that you also have to feed it the sample rate and channel count, because the device might only support a format with particular sample rates (I've seen this happen before).

Google does document what encoder formats are supported on different Android OS versions, but this will only be true on devices that follows Google's rules, such as Pixel devices. Android forks tend to do their own thing. Especially in Asia. At least that was my experience. https://developer.android.com/guide/topics/media/media-formats

[hansemannn]

@jasonkneen Is this still an issue for you? I would argue that the parity to add Android would be the better solution, but until then, moving it to .iOS. would only cause additional deprecation / docs work, so I'd prefer to keep it as-is for now.