HearThis to SAB sound file misalignment

My team recorded Colossians with HearThis and then used the Export function to export it for SAB. However, the sound files don’t seem to align correctly. There is a chapter number announced at the beginning of the recording (which HearThis prompted the person to record) that isn’t being tagged or read correctly, so SAB thinks the chapter number and section heading are all one. Then everything is off one item for the highlighting. Is there any way to fix this without manually going through and changing every verse number in the timing files?
Thanks.

In HearThis, the settings dialog give you the option to omit chapter numbers. If you check that box, and then re-export the book (for SAB), the chapter number that was recorded will not be included, and the entry in the label file that SAB uses will also be omitted. But SAB does know how to read the timing file with both the chapter (c) and section head (s1) tags and synchronize the highlighted text to the audio, so unless you’re saying that the USFM markup in the Paratext file is incorrect, the timing should work correctly. In SAB, you can use the fine-tuning feature to verify that the timings align properly. Note that SAB has a help file specifically to help you ensure that the settings between HearThis and SAB are correct. (Note especially the section about ensuring that your Audio Synchronization phrase-ending characters are in synch.) If after reviewing that, you are still having trouble, please send me an e-mail (tom_bogle@sil.org) with the following:

  • The mp3 and txt file generated by HearThis for Colossians chapter 1
  • The Standard format file for Colossians 1
  • A screen shot showing the Fine Tune Timings for Colossians 1

You will need to get HearThis and SAB settings compatible if you want to be able to use the HearThis timing files.

If you really want the highlighting to be at the phrase level (broken at commas and semi-colons), then you’ll either have to use Aeneas or change the settings in HearThis to break the recording pieces at commas and semi-colons as well. Recording at the phrase level is generally not recommended, as you tend to get unnatural pauses, intonation, etc. (Also, if you change that setting in HearThis after already recording some material, most of it will need to be re-recorded, since the recordings will no longer correspond to the text and HearThis can’t possibly figure out where to split the recordings.)

If you’re happy with sentence-level highlighting (corresponding to the individual recorded clips in HearThis), then merely remove the comma and semi-colon from the settings in SAB, and you should be good to go, using the HearThis timing files.

Thanks for the tip about removing the comma in SAB’s settings. I hadn’t noticed that before and that will probably help with alignment of the later portions.

However, I am still having the problem with the alignment of the initial bit (chapter number, section heading). They are combined into one chunk and that throws everything else off by one so that the highlighting is always one item too late.

I think I understand the problem now and can see what happened. I can see (or hear) that the chapter announcement is only about 2 seconds long, followed by the section head, which is another 3-4 seconds. I can also see in the timing file generated by HearThis that the chapter © is actually showing as taking the first 5.7 seconds. So that’s obviously a problem. My assessment, therefore, is that when this was recorded in HearThis, the recordist actually read both the chapter number and the section head as one clip. If that is correct, then it looks like she went on to read each subsequent block in the place where the previous one should have been read. (HearThis shows the part to be read in yellow, but also shows the surrounding context in a muted white color. Unfortunately, if a user does not get adequate training – or just forgets – it is possible for them to mistakenly read the muted white text instead of – or in addition to – the yellow text.) At the end there is no v. 29 because she had read that block in place of v. 28.
Assuming my assessment is correct, there is no “easy” fix, but there are three possible ways to fix it:

  1. Re-record the two affected chapters: 1 and 3. (Yes, I know you don’t want to do that.)
  2. Go to the place where HearThis stores its internal files and carefully rename each clip after the first one, increasing its number by one. To avoid collisions, you would need to start with the highest numbered file and work your way backward. Finally, when you get to the very first clip (which contains the chapter and section head), you would either need to delete it and re-record those two blocks as separate clips or use an audio editing program to carefully split the file in two, naming the first part 0.wav and the second part 1.wav.
  3. Manually edit the timing file to bump everything down. (This “hack” would mean that if you ever exported this book again, you would have to edit it again, so it’s not really ideal.)

We have long been aware of various situations that can get users into a place where they want/need to shift the existing clips one way or another to fix a problem like this. I have though about various solutions a lot and have even attempted one solution, but so far we have not come up with a simple automated fix that can safely deal with all the interesting edge cases. One of the guiding principles of HearThis is to keep the user experience simple, and this kind of advanced manual manipulation of files is not simple.
If you are think you are technically capable of doing the file manipulation manually and/or you have a tech support person available to assist you, e-mail me directly and I can provide more specific guidance. In any case, I would strongly encourage you to make a backup of the existing data before attempting this. If needed, I might be able to try to develop a little utility to make it easier to do this, but it could take a few days.

FWIW, I am exploring the possibility of an admin feature in HearThis to make it possible to do some simple clip shifting to deal with these kinds of situations. Not sure whether that will lead to something usable or not…

I checked with the team about what color words they read, and as you suspect, they said they did not read the yellow words, and that when they are finished recording a verse/part, the words turn yellow!
So, apparently either the person who instructed them told them wrong, or else they understood that person incorrectly. Whatever the case, it wasn’t clear to them that the yellow words were the ones they were supposed to read.
So, my fix will just be to use Aeneas this time, since it is a pretty short book (thankfully), and that will give the nicer phrase-by-phrase highlighting anyway.
And then I shouldn’t have to worry about this problem next time since it was user error and I have now instructed them to be sure to read the yellow words.
Thanks for your help. I do think it would be worth exploring an admin feature that could help deal with this kind of situation.

Thanks for checking into this. Makes me wonder if it would make sense to further dim the white text (so it becomes almost invisible) when they push down the button to record.

Hmmm…yeah, that could be a possibility to help it be more intuitive, or at least make people stop and ask if they had understood otherwise when instructed. Another thought I had would be to make some sort of icon next to the yellow words, like a person reading or a speaker or just an arrow or something that might be an extra indication to read those.

As of version 2.0.137, HearThis now dims the context when recording to avoid confusion. There is also now an advanced setting (on the Interface tab) to enable a context menu command which will allow a project administrator to shift recorded clips forward or backward to correctly align them to the blocks. As always, the latest version can be obtained from the Download page on the website.

1 Like

Excellent! Thank you so much!!! :smiley: