It seems that certain configurations of mp3 files cause problems with the audio-text synchronzation, especially on Android.
The following happened to us:
Audio files were modified in Audacity after the recordings, for example to add some pauses between paragraphs. The files were exported as 64 kbps, Constant Bitrate, Sample Rate 44100 Hz.
So far so good. After adding them to SAB, they were synchronized with Aeneas on phrase level. At first glance, the highlighting worked well. However, when single verses in the text were selected, especially near the end of a chapter, the syncing would be off most of the time. Mostly, it was delayed by about one second or a little less. This was annoying.
We tried various things to figure out what the problem was. In the end, we used the audio converter that is integrated in SAB and re-converted the audio files. We didn’t need to change any of the configuration, we just left them at the same format, same bitrate, same number of channels and ran the converter. Voila, this solved the problem! Now the phrases of the text are perfectly in sync, even when the user taps a single verse near the end of the chapter and starts playing from there.
It is puzzling: what exactly could have been wrong with the audio files at first? They were not flagged as variable bitrate in SAB. Could SAB check for other “configuration problems” in audio files in the future?
Has anyone else had this happening?
I have something very similar happening, and filed a bug on it 1-2 years ago, but no resolution.
This happens ALL THE TIME with our audio files. (We also use Audacity to downgrade our 192kbps audio to 64kbps. So maybe it is Audacity that is messing stuff up?) I just assumed it was a limitation in how well the SAB apps could line up text with audio segments if the use selected text later in a chapter.
But you are saying that there IS a solution! Good News!
Now if I can just figure out what you mean by “we used the audio converter that is integrated in SAB and re-converted the audio files.”
I have no idea where that feature is, nor how to use it if I should find it. (If this MP3 issue is NOT due to Audacity, but is always a problem for any MP3 edited outside of SAB, then maybe SAB should just always automatically convert audio files?)
So, thanks for the heads-up on this! I hope I can figure out how to fix this on our apps, as the timing errors are a bit annoying.
@david_coward You can find the audio converter by navigating to your audio files in SAB, selecting the file(s) you want to convert, then right-clicking to bring up the option to “Convert Audio Files…”
You will then be able to choose from several options: file format, bit rate, and number of channels.
The final step is to specify the folder where you want the new audio files created:
Hope that helps!
David
Yes, that helps greatly. Thank you.
I just ran this “Keep the same” on all my audio files and this is an example of the resulting difference (NEW on the LEFT; OLD on the RIGHT):
And yes, it did make a difference. Our SAB app, without recompiling, but just replacing the updated audio files in the “Music\Alkitab Selaru\Download” folder on the phone, caused the app to now play the audio files correctly synched with the text, if text is selected near the end of a chapter, and we start the audio playing at that point! Woohoo. Thanks.
Still have no clue why SAB should care. Nor why SAB’s converter removed the Year the audio was recorded. But it did add an encoding settings spec, which maybe is what helps the app process the audio? Also the files all got very slightly smaller.
The filesize change might be that you are re-encoding with mp3 (so there might be a slight loss of quality). You might want to redo the conversion from 192kbps to 64kbps using SAB’s convert audio.
FYI, can open the convert-audio.bat (or convert-audio.sh) to see the command-line options passed to FFmpeg. I assume that Audcity is also using FFmpeg to do the conversion?
“/Applications/Scripture App Builder.app/Contents/MacOS/ffmpeg” -y -i “/path/to/input.mp3” -map_metadata 0 -write_xing 0 -b:a 64k “/path/to/App Builder/Scripture Apps/Audio/output.mp3”
Is it possible it has to do with the version of FFmpeg that your copy of Audicity is using?
SAB (on Mac) uses:
$ /Applications/Scripture\ App\ Builder.app/Contents/MacOS/ffmpeg -version
ffmpeg version 5.0.1-tessus static FFmpeg binaries for macOS 64-bit Copyright (c) 2000-2022 the FFmpeg developers
built with Apple clang version 11.0.0 (clang-1100.0.33.17)
configuration: --cc=/usr/bin/clang --prefix=/opt/ffmpeg --extra-version=tessus --enable-avisynth --enable-fontconfig --enable-gpl --enable-libaom --enable-libass --enable-libbluray --enable-libdav1d --enable-libfreetype --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvmaf --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-version3 --pkg-config-flags=–static --disable-ffplay
libavutil 57. 17.100 / 57. 17.100
libavcodec 59. 18.100 / 59. 18.100
libavformat 59. 16.100 / 59. 16.100
libavdevice 59. 4.100 / 59. 4.100
libavfilter 8. 24.100 / 8. 24.100
libswscale 6. 4.100 / 6. 4.100
libswresample 4. 3.100 / 4. 3.100
libpostproc 56. 3.100 / 56. 3.100
Chris
Since version 2.3.2 Audacity has included the LAME MP3 encoder and uses it by default when exporting MP3 audio. The reports in this thread seem to indicate that the LAME MP3 encoder is creating MP3 files which don’t work properly with SAB apps. Audacity is optionally able to use FFmpeg to export audio. You must first install the FFmpeg libraries. and then choose “Custom FFmpeg Export” from the Export Audio dialog box. Alternatively, you could select (external program) and paste in the command from SAB’s convert-audio script to use FFmpeg to do the export from Audacity.
For my own apps I always use iTunes (now Apple Music) to convert the original WAV files to MP3 because I once read that the Fraunhofer MP3 codec included in iTunes produces the highest quality for low bit rate voice recordings. I’ve not attempted to verify this claim but, since iTunes/Apple Music is easily scriptable on macOS, that’s what I’ve been using. The link above says that Windows Media Player also included the Fraunhofer codec but I’ve not tried it myself.
First off THANK YOU @Friedo If not for your post we would have never checked our apps.
Second: We believe the issue is with SAB 11.1.1 only. We think it has to do with the the way it creates timing files. Below is how we came to that conclusion.
We checked out older builds and we discovered this only happens with apps that are built with SAB 11.1.1
All the apps we built with SAB 11.1 were fine.
So we ran several tests on SAB 11.1.1 to make sure using files that were converted with Audition (with the Fraunhofer MP3 codec), Audacity (with LAME), and Tenacity.
All had the same issue.
(@EricP we have been using Audition with Fraunhofer so that might not be the reason).
We then took our SAB 11.1.1 data and ran the same data on a machine with SAB 11.1 and the problem persisted.
But when we deleted the timing files that were created in SAB 11.1.1 and created new timing files in SAB 11.1 the builds did not have issues with going out of sync.
To check the syncing issues we checked the longest chapters (both by number of verses and length) in all 26 books that we have done so far.
(We will run a test on all 324 chapters tomorrow and will update you all on the results).
Thanks @Inquisitive for sharing your insights. Actually, for us it also happens in earlier versions of SAB, I just checked it in a build from last October, it must have been built with 11.0.3 But I’m not sure about SAB 11.1
Like @Friedo, we too have found this timing inconsistency (when clicking on verses later in a chapter and starting the audio there) to have been an issue for many iterations of our SAB apps. I don’t remember exactly when, but this issue started sometime back when SAB was at version 8 maybe? It has been an issue for so long, I just assumed there was nothing anybody could do about it. Hence my shock when the solution was so simple!
And as @EricP stated, maybe the issue just stems from the encoding that Audacity has been using and has nothing to do with SAB at all. So, no clue on my part. But I do export the Mixdown from Studio One v5 directly to MP3 at 192 kbs, and then I reduce the files to 96kbs with Audacity (not 64kbs as stated in an earlier post). So, who knows? Maybe the encoding from Studio One might also be involved in this issue.
Just an FYI, these reduced files are uploaded to the Internet Archive where they are kept (free of charge) and the apps have links to this location, where they are downloaded onto the device for playing. Internet Archive then automatically creates several versions of the audio files in various formats, but SAB only knows to download the MP3 version, as that is how it is link in the settings. (Any suggestions for a better solution are welcome, though this solution is working very well so far.)