pathToTestFile vs runRecognitionOnWave

Home Forums OpenEars pathToTestFile vs runRecognitionOnWave

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

  • Author
    Posts
  • #1024011
    davestrand
    Participant

    I am attempting to port my Push-To-Talk microphone into Version 2.0 but having a little difficulty.

    Am I reading correctly that runRecognitionOnWavFileAtPath is replaced in version 2.0 with
    [OEPocketsphinxController sharedInstance].pathToTestFile = [[NSBundle mainBundle] pathForResource:@”sound” ofType:@”wav”];?

    Or should I be able to continue to use runRecognitionOnWav?

    #1024012
    davestrand
    Participant

    p.s. I did read the text below quite a few times… but I can’t seem to get the audio file to trigger the recognition.

    In contrast with using the method runRecognitionOnWavFileAtPath to receive a single recognition from a file, with this approach the audio file will have its buffers injected directly into the audio driver circular buffer for maximum fidelity to the goal of testing the entire codebase that is in use when doing a live recognition, including the whole driver and the listening loop including all of its features. This is for creating tests for yourself and for sharing automatically replicable issue reports with Politepix.

    #1024013
    Halle Winkler
    Politepix

    Hi Dave,

    No API changes to either of those methods in 2.0.

    the pathToTestFile property is for doing automated testing or replicating an issue with the complete continuous listening context, and was introduced in mid-2013 and continues to be available: https://www.politepix.com/2013/08/26/openears-1-5/. You may have seen me recently mention it in a discussion about how to replicate a recognition issue in 2.0, but the discussion wasn’t about pathToTestFile itself or changes to it.

    runRecognitionOnWavFileAtPath:usingLanguageModelAtPath:dictionaryAtPath:acousticModelAtPath:languageModelIsJSGF: is a convenience method for running recognition once on a complete WAV (although I don’t really recommend using it in a UI – it was made available as an early test method and has been kept around as a way of seeing whether the continuous driver is introducing issues since its results can be compared with pathToTestFile which uses the driver, since it doesn’t use the driver) and has been there since 2012 and continues to be available.

    They are both intended as testing tools, and as a testing tool pathToTestFile is greatly preferred since it tests the entire continuous listening context. If you are using either for something else, it makes sense to just use the one which you find simpler to use or is more semantically related to your task (that would seem to be runRecognitionOnWavFileAtPath:usingLanguageModelAtPath:dictionaryAtPath:acousticModelAtPath:languageModelIsJSGF:).

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