SAB 8.5: Ogg Opus / WebM Audio

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:// bit.ly/opus-files (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

@ChrisHubbard

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.
http://openradar.appspot.com/radar?id=4998368908541952

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?

The nox player emulator is android 5. I set SAB at a minimum android platform of 5.0

Have you tried it on real hardware? Do you have a hardware Android 5 device?

I have a phone using android 11. It’s doing the same thing.

FCBH asked me to test if .webm files now download ok. They do! I just needed to change to Fileset ID: NODWBTN1DA-opus16. Their webm files have the -opus16 suffix. They may have made some additional changes.

I also noticed that webm files downloaded from FCBH fastforward and rewind correctly using the single and double arrows. I deleted the webm files I created with latest SAB/FFMEG converter that would not forward or rewind correctly, and substituted the files downloaded from FCBH and they work perfect in the App,

If you need webm and your audio is in FCBH Bible Brain you might try building a new app with the fileset set to “Fileset ID”-opus16 . You can download, stream or package these webm files in your app.

1 Like

Thank you, Roger, BTW for your info.
Has anyone found a solution yet to the FFMPEG conversion to webm in SAB?

I don’t know when FFMEG will work to produce reliable webm. Since FCBH is able to convert the files so they run reliably (I don’t know their process or software), I wrote them and explained the need and they shared the .webm audio they already had of the NT I am developing.

If you can either post your audio to DBL or just send them .wav or HQ mp3, I think they would do this for you. Just write, support@digitalbibleplatform.com -rg

Here is copy of my email,

I am the Northern Thai App developer for SIL. I have found the webm audio files that Scripture App Builder files creates do not forward or reverse correctly in apps, but the .webm audio you have on the -opus16 server do forward and reverse correctly. I was able download the webm audio from DBP for Mark, but I need the remaining New Testament webm files to package with the app. Could you please send me a link to download the webm files for Northern Thai. The file name looks like this:

B01___01_Matthew_____NODWBTN1DA.webm

Thank You, Roger Green

Andrew,

webm files have been causing some crashes in apps built with SAB versions 9.23 and 9.24, on some/most phones using Android 10 and above. The bug is supposed to be fixed in v 9.3, but I have not tested it yet. Be sure to monitor crashalytics in google analytics/firebase if you include webm files by download or embedded. This will tell you if you have frequent crashes caused by webm by your users.

mp3 files do not crash when used in the situation above.

-Roger

Thanks, Roger. I’ve updated the bug database with your findings.

Can someone (@ChrisHubbard?) provide an update on using opus16 format audio? From what I see in the posts above, opus16 audio downloaded from FCBH seems to work OK, even for fast forward and rewind, but the opus16 (webm) audio created by conversion from within SAB does not. Is that still the case?

From above:

Is that only the extension that isn’t supported or is it the opus format itself? The wikipedia link seems to indicate that there is “partial support” for opus in Android 5, 6, 7, through the .webm container.

So if SAB conversions are still not working, is it due to the way the conversion is done? I see a couple of differences in the way FCBH creates their opus 16 audio files, and the way SAB does it. Here is what FCBH does:

Here is the command used by convert audio from within SAB:
ffmpeg" -y -i infile.mp3 -map_metadata 0 -write_xing 0 -b:a 16k -map 0:a -vbr off -application voip outfile.webm

It looks like the main difference is that -c:a libopus is missing, that defines the codec. (Other differences: -map_metadata 0 looks like it just doesn’t copy metadata; I don’t know what -write_xing 0 does as it isn’t listed in the help in ffmpeg 4.2.)

So should the audio conversion in SAB add -c:a libopus to its command line? Would that help with the fast forward/rewind (assuming it’s still a problem)?

I’m not exactly sure how we evolved to this point, but if you use the latest SAB to convert mp3 files to webm/opus16 (there is a convert option if you right-click on an audio file in SAB), it produces audio files that work in the app, i.e. that can fast forward and rewind. From another thread, FCBH supposedly uses this command:

ffmpeg -y -i B01___02_Matthew_____SHUBSCN1DA.mp3 -map 0:a -c:a libopus -b:a 16k -vbr off -application voip B01___02_Matthew_____SHUBSCN1DA.webm

I’ve tried this, but it produces audio files that have the positioning problem. But SAB uses this command:

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

I.e. adds “-map_metadata 0 -write_xing 0” and removes “-c:a libopus”. Audio files produced by this latter conversion work (i.e. position properly). Although, as mentioned the the thread above over a year ago, files created with what I think is the same command weren’t working then. Maybe something changed in the version of ffmpeg that is distributed with SAB, and is used for the conversions? With SAB 10.2, the ffmpeg in the \bin folder is ffmpeg version 5.0.1-essentials_build-www.gyan.dev Copyright (c) 2000-2022 the FFmpeg developers. Does this sound correct @ChrisHubbard?

Anyway, from what I have seen, if you use SAB 10.2 to do the conversion from mp3 to webm, or use the ffmpeg that comes with SAB and the last command above, it will produce audio files that work. In addition, the webm files that are downloaded from FCBH (if you set up your app to download missing audio files) also work.

@jbarndt can you confirm how FCBH is producing the webm files that they distribute? According to this other thread (link below), they are using the first command above, which in my experience produces files that don’t work. Also it would be helpful to know what version of ffmpeg is being used, or what conversion tool. Thanks.