Audio over 100MB use case scenario

This is more of a use case scenario than a specific feature request.

I have built a song book app (Android only) using Reading App Builder containing over 200 songs - and it is great, but we have a couple of problems.

  1. We can’t distribute the app with audio on Google Play because it is well over 100MB. Play store expansion packages are probably not a viable solution as already discussed (It won’t let me link to the discussion because I’m a new user). I’ve also tried compressing the audio with a variety of codecs and encoding settings to no avail.

  2. Downloading the songs on demand is not suitable, since most users are in remote areas and won’t have Internet access when they are using the app. Typically someone will download the app while visiting a town, and then share it with many others directly from phone to phone in remote areas.

Ideally we would like the app to:

  • Be downloadable via Google Play (i.e. without audio included)
  • Be able to download all songs at once for offline use (would be nice if this happened automatically when the app is first opened, perhaps first informing users how much data will be downloaded and asking for confirmation)
  • Have the ability to share these downloaded songs when sharing the app directly from phone to phone

It would also be important for this functionality to work with updates - so updated songs can be downloaded in one go, and then easily shared from phone to phone.

I understand that this is beyond Reading App Builder’s current capabilities (correct me if I’m wrong) and that a Download Manager feature is on the roadmap already - hopefully this usage scenario is helpful for your design & planning.

For now I believe out best option is probably to distribute the app outside of Google Play so that we can bundle the audio even though it exceeds 100MB and it can be easily shared from phone to phone, although this has obvious drawbacks. Please let me know if I’m missing any other solutions.

try using ffmpeg for compression “ffmpeg -q:a 7” or 8 or 9 if you want to compress alot. Off the top of my head, you could make 2 or three apps and divide the songs between them. Not an ideal solution though.

Thanks Jim,

I had been using ffmpeg already and I just tried your suggestion but I still couldn’t get under 100MB for MP3 even with -q:a 9.

However, you inspired me to dig deeper into ffmpeg and discovered that I couldn’t get it to encode MP3s at any less than 32kbps no matter what options I gave. So instead I used the lame command directly and was able to go down to 24kbps which gets us under 100MB. Audio quality is poor but acceptable given the constraints. So we have a workable solution now - hooray!

I should also mention I experimented quite extensively with AAC and Opus codecs. AAC at 24kbps only provided marginally better audio quality, and the app had issues playing these files - the progress bar would jump around erratically, and songs would sometimes fail to play at all (and this was not predictable - the same file would work sometimes and not at other times).

The Opus codec is amazing - audio quality at 24kbps was far better than both MP3 and AAC. But the app couldn’t play these files at all. Android 5.0.0 supports Opus according to http://developer.android.com/guide/topics/media/media-formats.html. I was testing using Android 8.0.0. It would be fantastic to have Opus support one day.

Cheers,

James

Hey James,

I’ve recently been looking into the lame encoder to find the sweet spot between file size and audio quality. I’ve ran a batch job that converts various lame settings and I’ve found this to be my favorite. lame --vbr-old -V 9.0 -mm -q 0
the -V setting goes all the way up to 9.9, and the vbr-old setting reduces my file sizes by about 25% as compared with the vbr-new.

If anyone is interested in the batch job that I made to convert a whole directory of wav files to various qualities, let me know and I can post it!

1 Like

If you want to have better audio quality for low bit rates, then you need a codec that is designed for low bit rates. MP3 is not designed for very low bit rates. AAC is not designed for low bit rates either. I don’t know about the Opus codec but a brief read sounds good. 3GP is designed for low bit rates. Though it is really a video codec that includes AMR-WB for the audio.

SAB currently only supports two audio extensions: mp3 and 3gp. Though I know of someone who encoded in Ogg and put a mp3 extension on the end and it worked in the app. Though Ogg by default is VBR variable bit rate and syncing at least with MP3 works better with CBR constant bit rate. I tried creating and using an Opus codec file and it did not work. I believe you can use Opus codec in an Ogg container but I have not tested that.

Thanks Ian for the heads up on 3gp files. I was able to convert my audio to 3gp with ffmpeg (ffmpeg -i input.wav -ac 1 -ar 16000 -b:a 12.65k -strict normal -acodec libvo_amrwbenc output.3gp) and I’ve cut my app size in half with acceptable audio quality. I hope this info helps other people trying to fit lots of audio in this app!

1 Like

Hello, I realize this post is old but there is some pertinent information in the documentation. in Reading-App-Builder-02-Building-Apps.pdf, in section 5.3, “How do I distribute the audio files with the app?”, on page 17, it gives several options. The app can check first for the audio in the device, and then if it doesn’t find it, download it from the internet. If your team doesn’t have its own webspace, it also lists some free options for online hosting.

This is how I plan to release my Hymnal app.