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).