Hi,
I’m wondering if I would benefit from your suggestion of recording .WAV
I didn’t recommend this and would not ever do so – that impression is due to a misunderstanding. I didn’t link to the other thread in order to show you advice for your design, I linked to it to explain a specific design that I think should _never_ be done with OpenEars, as a way of explaining to you that I didn’t consider your design to have the same problem. This was directly in response to your statement that you were worried that your design was a mis-fit for the library.
I told the poster in that discussion that the only way it was possible for him to use OpenEars for his design was by recording a WAV file and submitting it to the WAV function, not because it has any advantages or because it is a good idea but because it is otherwise not possible with my support at all. None of this is your problem because you are using OpenEars for continuous listening as it is designed for, just with some kind of eventual end point that is a bit arbitrary, so please consider the question of whether your design is OK to be closed (it is) and please don’t take design advice from that thread.
My current app kinda works, but often misses “bad words” or combines multiple bad words (said in sequence) into a single response (e.g. “DARN BUMMER”, instead of “DARN” and “BUMMER”.
The job of parsing a hypothesis for multiple words you are interested is an implementation issue for your app. If you receive this hypothesis, you can check it against your word list and see if there is more than one word from it in there. Rejecto may help with your false negatives.
if RapidEars is the right choice.
RapidEars will give you hypotheses sooner, but they will contain similar content to the regular hypotheses. Would that be helpful to you?