SAB 8.5: Ogg Opus / WebM Audio

From App Builders development team
We want your feedback!

In SAB 8.5, we added support for audio encoded with the Ogg Opus codec stored in WebM container format. Ogg Opus has better quality at lower bitrates than MP3. The audio files distributed by Faith Comes By Hearing are 64 kbps MP3s. You can encode that audio with Ogg Opus at 16 kbps at 1/3 to 1/4 of the size and it will sound similar in quality.

Ogg Opus in webm container format is supported by Android 5.0 (API 21). [Update: in SAB 9.1, webm is now supported in 4.1+]
Ogg Opus in caf container format is supported by iOS 11. [We made the iOS app support webm and do the minor conversion in the app so you can use the same audio files with both Android and iOS.]

We are working with Faith Comes By Hearing to support their next version of Digital Bible Platform. They are interested in supporting Ogg Opus at 16 kbps some time in the future. So webm files should be able to be downloaded from “FCBH Digital Bible Platform” source in Scripture App Builder.

Here is an example audio file that was converted:
Mark 2 from Zapotec, Guevea de Humboldt
MP3 from FCBH - 64 kbps, 3.5MB
Ogg Opus - 16kbps, 1.0MB

To convert MP3 to Ogg Opus, you can use FFmpeg. This gets installed with Aeneas.

With SAB 8.5, if FFmpeg is installed and can be found, you can do the conversion from the Audio page.

  1. go to the Audio Files tab
  2. select the chapters you would like to convert
  3. right-click and select “Convert Audio Files…”
  4. select File Format = webm, Bit rate = 16 kbps and click Next
  5. click Create Files (the default location is App Builder/Scripture Apps/Audio)
  6. click on the “Add Audio Files…” button in the Audio Files tab and browse to the location of the new files and add them to your project.

If you want to do it on your own from the command-line, here are the parameters that are used:

ffmpeg -y -i input.mp3 -map_metadata 0 -write_xing 0 -b:a 16k -map 0:a -vbr off -application voip output.webm

Please contact me by replying here or by email (chris underscore hubbard at sil dot org) with your feedback on the quality of the audio in 16 kbps Ogg Opus.

For His Great Name,

Chris Hubbard
Lead Mobile Software Developer
SIL Language Technology Development

I’ll be the first to admit that this sort of thing is way above my head, but the audio files I ended up with were actually larger than the ones I started with: a 503KB mp3 went to 580KB as a webm, and a 877KB file went to 1010KB.

Do you know why this would have been?

Can you clarify the bit rate for the MP3 and the bit rate you changed to for the .webm files?

If you did not change the bit rate, that may be an issue.

I experimented with the new .webm audio files in a new app that I’m building. The audio quality seems to be good and the reduced file size is especially helpful. One thing I noticed, though, is that when I used the .webm files instead of mp3, the fast forward and rewind buttons (both by phrase and section) no longer worked. Has anyone else experienced this?


I tested on a version with no section headers. The next/previous phrase buttons did not work, but the larger jump buttons did take me to the next chapter but the audio did not continue playing.

I have written up the bug.

I noticed that a chapter’s audio (Gen 1) was cut short (4:12 instead of 5:30) after converting it to .webm. I can’t think of another explanation of why it was cropped.
In the app, it suddenly jumped to ch2 without being touched so I checked the source files and found the audio was corrupted.
I of course have not listened through every chapter of the Bible but I know that all of Matthew is fine. Users who have made other comments have not complained of this issue so I know it is not very common, perhaps only this one. I reran the Convert Audio and it worked fine so I will replace that in the online source.
Has anyone else experienced this?

Hmm, fast foward and reverse works for me just fine. @mcquayi could you share your test project and audio?

@mcquayi and @David_Fetrow, what Android version did you test it on?

I tried my test project on all my devices (Android 6, 7, 9 & 11). With 6 & 7, the movement was not sluggish, but it still worked.

David shared his project and webm files with me. It worked fine on Android 9 & 11. However, on Android 6 & 7, I noticed that the button presses where accepted and the scroll position would move to the next section, but the play kept on going from the same spot.

@David_Fetrow, I noticed you had Grandroid enabled, but that would only affect phones up through Android 4.3 (so none of my test phones). And WebM only works on Android 5+. So you can turn off that option.

I tried building with the Crosswalk viewer component just to see if it was the browser on Android 6 & 7 but it didn’t make any difference.

I switched the files back to mp3 and it worked fine. I will have to look into this. Thanks for bringing this to our attention.


I did some more testing. WebM files created with the newest FFmpeg 4.3.1 (on my Mac installed with Homebrew) work fine. WebM files created with the FFmpeg that is included in the Windows Aeneas do not work. The Windows installer for Aeneas 1.7.3 includes FFmpeg 3.2.4. There was an updated installer that included FFmpeg 4.2 and Python 3. Neither of these created WebM files that work.

My next step is to try to install the latest FFmpeg using Chocolatey.


I posted this on its own thread earlier but then later thought it might be relevant here.
We released an update of our app last week. Some users are saying that they cannot skip forward or back in the audio, also if you tap on a verse in the middle of a chapter and press play it starts from the beginning of the chapter.
This did not happen in previous versions.
It works fine on my newer Android phone, but when I tried it on an older one (S7 on Android 7.1.2) I found the same problem.
iOS Simulator and PWA also work fine.
The app was made on SAB 8.6 on a Mac.
Any suggestions?
update: same problem with 8.6.3
update: also tried with 8.6.3 on Windows

I just noticed this post in the forum today. I would have posted sooner had I known it was here.

I know that .webm has been incorporated into SAB/RAB because FCBH is using it and it’s an amazing option for compression. However, it seems the only way to do the conversion is via the command-line, or use SAB to do it.

I propose that the developers also include the ability to use .opus files (.opus and .webm are twins, both born of the people who created .ogg and have been working on a better codec for years). You can read about the development of the Opus codec here: LINK REMOVED and read the developer’s FAQ here: LINK REMOVED

I make this proposal, because Audacity now includes the ability to export .opus files (and not .webm). Since Audacity is the “defacto” audio editor around the world and has decided to support .opus I believe it’s here to stay. I did quite a bit of research on it, which you can read here https:// (link modified - as a new user I can’t post links…) In the paper, I have a link to the files I compressed at various settings, so you can download them and listen for yourself to hear what each compression setting does to the audio.

The Opus codec will allow us to shrink the size of NT apps with audio from 700mb down to 100mb while maintaining the quality, without having to use a command-line, which very few people are comfortable with. It will allow us to make any app with audio significantly smaller than what they will be if we use .mp3

Please consider adding the option of .opus for audio files!

Hello @Marty_Lange,

The .opus extension is only supported on Android 10+ while .webm, .mka, and .mkv are supported on Android 5+. That is quite a different in version support. I don’t think it would be wise to cut out that many versions of Android.

See Opus (audio format) - Wikipedia


Sorry, maybe slightly off-topic, but I came across this post Googling for a solution.
I came across to what I think is your StackOverflow post (streaming-ogg-opus-as-mkv-and-caf-with-aws-lambda). I’m looking to remux webm to caf for the same reason. I tested the ffmpeg route, however storing the same data in two containers seems redundant. I read that you succeeded repacking one file (on the iOS) side?
Do you want to share your approach or steps? My goal would be to serve webm as caf files dynamically, so iOS can playback webm encoded audio.

Hello @Kasper,

I added an answer to my StackOverflow post:

I ended up using mobile-ffmpeg-full (pulled in from Cocoapods) to convert the container from webm to caf. We had another need for using mobile-ffmpeg-full. You might be able to use a smaller version of the library if this is the only thing that you are doing.

1 Like

Thanks for your reply and the added answer. I’m looking for a browser-based solution and ffmpeg wasm is pretty heavy. Good to be aware of a client-side scenario that works.

@Kasper, we will need a browser-based solution for our PWA output. For right now, it probably means having double encoding the files and storing both and having the web app serve them based on platform.

I filed a issue through Feedback Assistant.

I documented my submitted issue through Open Radar.

It would help for you do submit an issue through Feedback Assistant documenting your needs.

I did both. I think it won’t help much since Apple is frustrating PWA development for a long time.

I coded a demo using OGV.js as a fallback in Safari, I posted that to the StackOverflow answer, since I’m not allowed to post links here yet as a new user.

The next version of SAB (9.1) will have support for Ogg Opus / WebM back to Android 4.1 and will correctly handle Fast Forward, Rewind, Seeking (e.g. clicking on a verse to play).

I installed SAB 9.1 and thought I’d try using the Ogg Opus/WebM format to reduce file size.
I like the fact that my install file is now much smaller than one using mp3 audio files.
Unfortunately, in doing so, I lost the ability to fast forward, rewind, and seek.
I attempted to resynchronize the webm audio files and the timing files with aeneas, but still can’t seek to a verse. I can use them to go forward to the next or previous chapter.

@Roger_Schley What version of Android are you using?