Warning: Don't sync MP3s that have a variable bit rate!

Scripture App Builder
1

I was rather bummed to discover that fine-tunings performed on variable bit-rate (VBR) do not actually align with the true timings. But this did explain why Aeneas seemed to get further and further off-track the longer my recording went.

Aeneas actually generated much better timings than I realized, but because my MP3 used VBR, it seemed to go significantly off track by the end, advancing the highlighting too slowly. This was the case everywhere: in Export to HTML, in the Fine Tuning tool, and even in the app I built. So for a number of books, Iā€™ve used Fine-Tuning to get it just right: I click on every phrase and it starts with exactly that. But now I realize that these timing files do not actually correspond to the true timings. For example, using the Fine Tuning tool, it seemed that the final verse started at right at 7:12, not 7:13 as Aeneas had set. But if I opened the MP3 file in Audacity, I found that 7:12 was in fact in the previous verse.

By experimenting a bit, I found that if the MP3 uses a constant bit rate, the timings align with the true timings. A VBR-encoded version of the same recording goes off-track. (Quality did not seem to make any difference.)

Iā€™m a bit uneasy that in some situations (certain devices? certain platforms?) the timing files Iā€™ve created may actually get applied literally. (e.g. Jumping the highlighting to the last verse prematurely at 7:12 instead of 7:13.) Is that something I need to be concerned with?

If so, is there any way to convert my timing files (made with VBR MP3s) to the true timings? Then I could use those with constant bit rate MP3s and be safe from such situations. For some of them I could probably just redo them with Aeneas and it would be good without fine-tuning. Others took manual messing around because Aeneas went off track when it encountered \s2 section headings, which are not in the recording while \s section headings are. (SAB provides only a single checkbox to include or exclude all section headings.)

If anyone is curious to experiment with this, I have a demo project: Click here.

It contains just two chapters that are identical. Each chapter contains 100 verses. Each verse looks like this:

\p
\v 4 Number 4 reason that I love scripture app builder is that it enables us to make God's Word available on mobile devices to people who do not have access to it otherwise.

where the number corresponds to the verse number.

I generated an audio file of these 100 ā€œversesā€. From this I generated two MP3s: The first with VBR and the second with CBR. I added these to the SAB project, associating the VBR file with chapter 1 and the CBR file with chapter 2. (Surprisingly, SAB shows that the length of the CBR file is 18:30, while it shows the VBR as 18:29. Both are actually exactly 18:29.000 in length.)

I ran Aeneas on both files, and it produced identical timing files. But clicking on verses in the VBR chapter would play increasingly more from the end of the prior verse. Clicking on verses in the CBR chapter was spot on.

I guess one implication is that users should be encouraged only to use constant-bit-rate MP3s, never VBR, but thatā€™s a bummer because you canā€™t get the same audio quality with CBR for the same file size.

I guess Iā€™ll convert my not-yet-synced audio files to CBR (so that Aeneas will get me further) and leave the books Iā€™ve already done with VBR alone (unless thatā€™s risky for those timing files getting applied literally somewhere).

Your thoughts?

2

Good detective work @Dan_Em.

It is really an Aeneas issue not detecting the VBR and adjusting for that.

3

No, itā€™s not Aeneas. Aeneas will produce the same timing file regardless of whether the MP3 is VBR or CBR. And youā€™d run into this problem even if you didnā€™t use Aeneas but manually set labels in Audacity.

The problem is that both in the browser and in the app, those timings are misinterpreted. So if you use the Fine Tuning tool to ā€œfixā€ the timings on a VBR file, your timing file numbers will be wrong (in terms of actual times), but these seem to be the right numbers to make the app advance highlighting at the times you intend (hopefully on all platforms/devices, but how would we know?).

4

@Dan_Em

We also faced a similar issue. I heard that SAB 5.0 (released today) will fix the duration calculation for newly added files. To update the current audio files in app projects, select files in Audio Files table and type ā€˜rā€™ to refresh.

5

Prior to 5.0, the duration of the audio was being determined by a library that would just calculate it assuming fixed bit rate. In 5.0, we are using a new library that pulls the duration from MP3 tags (still canā€™t handle 3GP files). If you run into problems with the new mechanism, please let us know.

Chris

6

I just repeated this with SAB 5.0. The only difference I can see is that where SAB displays the duration of the audio clip, both the VBR and CBR are now correct. But the real issue ā€” jumping to a specified time-point in the file is off-track with VBR files ā€” remains the same. This can be easily demonstrated with the demo project I linked to in my original post.

This problem is not a show-stopper, because you can simply go with CBR MP3s. It just means larger downloads or lower quality. But users should be aware of the problem of using VBR.

7

Oh man!! I read this thread back in January and then forgot about it. Now for several days over the last week Iā€™ve been struggling to get some audio files to sync with text. Yes, I can see now that it is the VBR MP3 files that are the problem. When using VBR files in an app project (or in the fine-tuning browser interface), I have noticed that if I start the audio playing at the beginning of a chapter, the synchronization will stay on track from beginning to end of the audio file. It is only when I click on various verses to see if the sync is correct, that the sync will be way off. (@Dan_Em, have you tried complete playback of an audio file? Do the VBR files you have fine-tuned stay on track from chapter beginning to end?)

It seems that the audio playback tool/plug-in built into SAB (and browsers) is imprecise at starting playback at the correct location for VBR files.

If this is an issue that cannot be fixed in SAB, it would be great when importing audio files into an SAB project, that either:

  • SAB would reject the VBR files, or
  • a popup would appear, saying that VBR encoding on MP3 files is not supported.

If there isnā€™t something done, Iā€™m sure there are going to be lots more people who run into this issue and lose time over it.

Just want to give a thanks to all the SAB developers and support people for all the work youā€™ve done to make SAB great! I really love the software.

1 Like