Wav Files to Match Blocks

This request comes from a veteran translator in rural PNG who is using HT for single voice recording in the field. The goal is to record the whole NT plus Genesis and Exodus. The user does not have internet and uses a HF radio for email communication. She has submitted this story and request:

On Monday Din walked three hours one way with his family in the hopes that he could get medicine for his wife and at the same time rerecord 8 blocks in scattered chapters of Genesis and Exodus. Many of the blocks needed to be rerecorded because of minor changes in the text – some of which Din himself had suggested. When Din arrived unexpectedly, I let the translation team continue working on the final read-through of Hebrews while I quickly gave medicine to the sick ones and then set up the recording computer for Din to use sitting outside on a plank under the house – not ideal, but the house was full and he needed a quieter spot. Din struggled more than normal, but he also was not feeling well and had been caring for his brother whom they thought was dying two months ago. He was definitely not as focused as usual, but he was trying hard. Din has had little formal education and using HearThis is his first encounter with using a computer.

When I went down to check on Din, to my horror he had somehow hit something and gone back a block and was recording block 20 over block 19. I could have made him redo both blocks, but I had already listened to 10 attempts or more and he still didn’t have it right. So I told him I had an old copy of block 19 and would fix it and that he should just get 20 corrected – which he did after another 5 attempts or more. At lunchtime I had him come upstairs where I could more carefully supervise what he was doing. He finished the rest of the blocks, I found the appropriate wave file, but of course it wasn’t named file 19, it was 18 because we don’t record section headings. After I found and figured that out, I replaced the corrupted file and then checked it all in Hear This. If the block numbers and wave numbers matched, then correcting these kinds of issues would be much easier.

Another reason I have to mess with files is that we are using Hear This for prepublication editing and recording. Genesis was supposedly finished and just needed a final rubberstamp on the corrections. Unfortunately, the translation team finally decided that they had to change the sentence structure (too complicated and wrong verb) on the phrase for tithing in Hebrews. That unfortunately meant that we had to change a couple of sentences in Genesis 14. So, now I will have to renumber all the wave files in that chapter in order to make space for the additional sentence. Renumbering is a pain, but the pain is especially great because the wave files numbers and the block numbers do not match and depending on how many section headings there are in the chapter, it can get even more complicated. If the wave and block numbers matched, it would be much, much easier.

Hear This is a great tool and the version I have now is much more stable than the previous one. The group I work with are not educated, but even the women doing some of the recording can generally handle it and it gives them a lot of joy that they can participate in this way with the finishing of the Apal scriptures. Thank you for making a good program.

Dr. Martha L. Wade
Translation Consultant
Pioneer Bible Translators
Papua New Guinea


Note from technician: It would seem HT could be programmed that every sentence would be assigned a block including all titles, section headings, verses, etc. If the user decides to omit for example the title and section headings from the recording process, those blocks could simply be ignored. Thus leaving you a series of perhaps non-sequential blocks. Example, if the user omits the title and first section heading of a chapter, the first block to record might be block 9. HT would simply omit blocks 1-8 as selected by the user. The end goal would be each block would match a wav file.

Also as the user noted above, if PT text is changed and a new sentence is added or modified with the end result of multiple new sentences. Then HT would need to be allowed to adjust the blocks and wav files accordingly. Example, there are 90 blocks in a chapter. The user adds a new block therefore you have 91 overall blocks. If the new block added was block 31 then HT would need to move all the corresponding wav files (assuming all 90 blocks have recordings) 1 number greater to allow for a new black wav file and block. This is where the renumbering of wav files frustrates the user as noted above.

This request is a duplicate of existing requests in Jira (also from PNG), going all the way back to 2014. Although the request itself seems fairly simple, our analysis of the actual need suggests that a different solution is warranted. Although some HT projects will have an administrator who is capable of doing complex file manipulation and may be able to solve some problems that way, we’d prefer to solve the problem in a way that is both “safer” and does not require that level of ability. In addition, the process of a mass migration of existing files is not without its pitfalls. See the following issues and documents for more details:
Jira: Automatic and manual clip shifting
Jira: Have save segment files be numbered the same as the on-screen tooltipMake
Jira: Make blocks match wav files
HearThis Maintenance proposal
Pull request for work-in-progress to Alert user to places where the block text at the time of recording != current block text
Document discussing proposed solutions with analyst

Hi. We have similar problems that the audio recording does not match the block after we imported the new revised Paratext. Could you advise how to adjust the recording to allow a new ‘line of words’ to be inserted? Thanks

The only thing HearThis currently supports is re-recording any block that does not match the recorded clip. We have ample feedback at this point to suggest that this is not really acceptable. Until we are able to address this, I am aware that some tech-savvy users are coming up with other workarounds, but I’d be reticent to publish any of these approaches, as they are somewhat error-prone and things can easily go wrong.