April 3, 2016 at 8:08 pm #1029916
We are using openears with rapid ear and rejecto.
And there are several parameters that we can adjust like
‘withWeight’ in ‘generateRejectingLanguageModelFromArray’ which decide what level they reject the words.
‘setSecondsOfSilenceToDetect’ which decides things like its name said.(when i use rapid ear, this one does not matter a lot i guess)
and ‘setLatencyTuning’ for rapid ear decides the level that how fast rapid ear recognize word.
So my question is do you think there exist a setting combination of these 3 parameters(or are there other more parameters we can set?) to get the most accuracy?
Thanks.April 4, 2016 at 10:25 am #1029919Halle WinklerPolitepix
Sure, I’d be happy to help out. Can you go into more detail about the specific accuracy-related issue you’re having and how you’d like it to improve? For instance, is too little speech being recognized overall, or are too many noises being recognized as if they were speech, or are known words being substituted for other known words, or is it something else? Most helpful would be examples of what is said (or what environmental sound is heard) and what the results are, compared with your ideal outcome for that situation.
In your email you also mentioned scheduledTimerWithTimeInterval (this is an Objective-C API rather than an OpenEars API), so I also wanted to make sure you aren’t arbitrarily timing out recognition periods, which will negatively affect accuracy, or using scoring to arbitrarily reject speech, which is another common way that accuracy can be harmed.April 9, 2016 at 4:06 am #1030004
It was kind of accurate now, we just want to see if there is a way to make it more accurate.
Like in our list there are two words got similar pronunciation, for example defense and definable. sometimes it made wrong recognition between this kind of words.
And in noise situation, sometimes it just didn’t recognize anything(maybe rejecto reject them or too noisy that can’t hear my voice?)
ThanksApril 9, 2016 at 4:12 am #1030005
btw about the guy sent you email, we are in a group but not the same person,
so scheduledTimerWithTimeInterval he mentioned is not about timing out recognition periods and we also did not use score, i saw you mentioned this in many threads, so i total know what that score means.April 9, 2016 at 10:26 am #1030009Halle WinklerPolitepix
Super, I just wanted to check to make sure those weren’t potential issues. OK, since you mentioned two issues that are sort of general issues rather than a single acute issue, I can give some general advice about the order of applying the different tools.
1. Turn off Rejecto temporarily. Create a few test cases which demonstrate environments that users will experience, and find the most-optimal vadThreshold setting that seems to get you the closest to a good balance between rejection and recognition across these cases (the highest priority is that it doesn’t reject speech that you want to recognize, and a lower priority is that it can reject some of the incidental noise or speech that you do not want to recognize without rejecting speech you want).
2. Next, add Rejecto back in. If it rejects speech you want to keep, turn the weight down. If it doesn’t reject incidental speech or noise you think it should reject, turn the weight up. Change the weight in small intervals and retest so you can see your results.
3. RapidEars CPU settings don’t affect accuracy, they just affect polling rate, so you can set them to the lowest setting that feels “fast enough” for your UX and save some energy, or set it to the highest if nothing is more important than hypothesis speed. None of them are energy hogs, but of course it’s better to use the least CPU overhead you can get away with in your interface.
Let me know if this helps.April 12, 2016 at 6:30 pm #1030040
sure, kind of busy this time, will try that later and let you know, and thanks for the advice.
- You must be logged in to reply to this topic.