We have 4 teams currently working to record Luke 1-5 in Gabon. This has been a learning experience for them (translation learning experience) as they have identified spots where the translation was not natural (they had a hard time reading it and getting a smooth recording without pauses) and where the punctuation did not aid in the smooth reading of the text. This led to them making changes in their text and punctionation overnight based on what they learned. Returning to the work on HearThis the next day, they found that what they had recorded previously was all “out of sync.” Changing one comma to a period for example threw all the segment numbers off by 1. I have no expectation that you can solve this problem. But something in a simple Help/hint file or the Getting Started doc that alerts people to this issue ahead of time could be helpful. So we’re finding that it is better to be sure of your text and punctuation before recording with HearThis. But on the other hand we are finding that it was a useful tool for translators to discover places the text needed improvement that were not simply found in the consultant check or in having the translators just read a section out loud after checking it. (Something about the actual recording process that scares up the problems.) But when that happens and you make changes, it almost necessitates re-recording the whole chapter.
The original premise of HearThis was that re-recording was relatively cheap, so if the text changed, you could redo it. But we have attempted to go down a few paths to try to make this scenario less of a hassle. So far, we haven’t found a good, fool-proof and simple way to handle the common kinds of cases. We have an issue in Jira where were have wrestled with this deeply.
Thanks, Tom. I get that. I notice that if a team was pretty happy with their recording of a chapter, and just made one or two changes to punctuation that changed the segment counts, it looks like you could rename the audio segments in ProgramData – a bit tedious but maybe preferable to re-recording the whole chapter.
Try using teleprompter software on PC (open source) to read text rather than paper.
Shhh… We are especially anxious to have people try to move those files around by hand. I know that a careful and technically savvy person can probably do it and get it right 95% of the time, but it would be easy enough to make a mistake. While the move is really easy for the program to do, unfortunately it’s not very easy to present the problem in a graphical way so that the user can tell HearThis which pieces need to move where.
Thanks, Ron for this topic. We have had many issues just as you described. And yes, it is a headache to re-organize the Wav files after editing the text. This can get very confusing fast especially if you are dealing with a language that you cannot read or understand. The only way to do so is within ProgramData that the developers don’t want you go to. You have to re-number the files one by one until you have a gap where you can insert the new block of audio. It really is the only way to fix the issue other than have the person re-record a large amount of blocks which isn’t necessary. Only 1 block changed so why go through the unnecessary time to re-record the whole chapter (in some cases)? In our case, our readers/speakers aren’t very fluent so 1 block can take upwards of 5 minutes to record.
I have raised this topic before with the HT developers and other topics that deal with this kind of issues. We continue to hope that the developers will hear our pleas and requests. We do aspire for a day when they will have a fool-proof and simply way of handling these cases.
The developers (i.e., me 
) have definitely heard your plea. Over a year ago I spent several days working on a solution, but it proved more difficult than I had hoped, and it got shot down (or at least pushed to the the back burner for further analysis) on review. The very simplest cases are pretty easy, but things get pretty complex pretty fast and it’s not as trivial as it might seem to distinguish between the cases. And it’s not that we don’t want people to muck with the files in Program Data. If they can do it perfectly and fix their problems, that’s awesome. We just don’t have the capacity to provide support for people who do it and make a mess. Experience has taught us that file management is one of the most difficult things for people to do well, so most SIL software (and throughout the industry really) in recent years has attempted to minimize the amount of contact users have with the file system. I sincerely hope we will be able to find or free up the resources soon to take another shot at addressing your urgent needs in this area. Please pray with us to that end.
As of version 2.0.137, there is 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.