Use length of utterance for rejection?

Home Forums OpenEars Use length of utterance for rejection?

Viewing 5 posts - 1 through 5 (of 5 total)

  • Author
    Posts
  • #1018895
    morchella
    Participant

    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?)

    #1018896
    Halle Winkler
    Politepix

    Welcome 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.

    #1018902
    morchella
    Participant

    Halle, 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. :)

    #1018904
    Halle Winkler
    Politepix

    Thank 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.

    #1019148
    Halle Winkler
    Politepix

    In 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.

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.