Tagged: keyword spotting, Rejecto
- This topic has 4 replies, 2 voices, and was last updated 10 years, 4 months ago by Halle Winkler.
-
AuthorPosts
-
November 14, 2013 at 1:53 am #1018895morchellaParticipant
I realize that OpenEars is not really intended for keyword spotting, however my app requires mixing of keywords with other speech. My keywords are short (single words); most of the rejected speech is long (sentences).
I have tried Rejecto and still often get single item matches when the utterance was a whole sentence, despite setting weight to 2.0. I’m wondering if there’s any way to use the length of the utterance to rule out full sentences?
(As a side note, I think 2 minutes is too short for demo timeout. I fully respect your need to prevent abuse, but this stuff is complicated and wouldn’t 15min accomplish the goal just as well?)
November 14, 2013 at 8:54 am #1018896Halle WinklerPolitepixWelcome morchella,
OpenEars is fine for use with keyword spotting applications. I think the way I would probably handle this requirement would be to turn on the option of having the Rejecto phonemes returned in your hypothesis, and just reject the hyp if there are too many of them in a single hypothesis.
(As a side note, I think 2 minutes is too short for demo timeout. I fully respect your need to prevent abuse, but this stuff is complicated and wouldn’t 15min accomplish the goal just as well?)
Sorry this is making things more difficult for you; that isn’t the intention and I understand that speech applications are not so simple (that was a big part of the impetus for adding the pathToTestFile which is designed to make it easy for you to replicate issues that you are working on repeatedly). Practically the timeout is more like 2:30, but to give you some background, here is a link to a study including analytics for how long apps are used on average:
http://readwrite.com/2012/01/17/study_average_app_session_lasts_about_1_minute
It found that the average app usage period is about half the length of the Rejecto timeout. The alternatives to having a timeout that is related to the average app usage length would either be the reality of people shipping the demo linked to their app for apps with short usage requirements, or having some kind of much more intrusive network license checking that would time out the demo after a fixed chronological period (like 30-60 days) which IMO would be more disruptive to development since some projects take years to complete. I think this would be worse because it would result in sales from half-finished apps that might never ship, which I’m not comfortable with as a revenue stream.
But I appreciate the feedback and get the reason for it, and I’ve been considering standardizing all of the demos to the same 4:00 length to make things easier and more consistent.
November 14, 2013 at 5:59 pm #1018902morchellaParticipantHalle, thanks! You are awesome for taking the time to respond in detail. I will play around with this some more as you suggest.
Personally, I would never design an app to fail after “average” use time was exceeded, but then I would also never rip off another software developer. :)
November 14, 2013 at 6:28 pm #1018904Halle WinklerPolitepixThank you! I know; I think the majority of developers wouldn’t do that and it’s a drag that we have to deal with copy protection from either side of the equation.
December 12, 2013 at 10:04 pm #1019148Halle WinklerPolitepixIn the current version 1.64, I’ve standardized the time across all plugins to be 3 minutes so it’s more convenient to try out multiple plugins at once.
-
AuthorPosts
- You must be logged in to reply to this topic.