Forum Replies Created
-
AuthorPosts
-
lookbadgersParticipant
I’ve created a new recording in mono but still the same problem.
Thank you for the suggestion about testing RapidEars I will have to try that at some point.
lookbadgersParticipantThat is correct pocketsphinxDidReceiveHypothesis is never called.
I assume you can’t use RapidEars with SaveTheWave? Which might make the test I’m working on irrelevant.
lookbadgersParticipantSorry that was a typo when writing out the error, the typo did not exist in the code. Anyway that is now working and I can record wav files.
I’m calling the method runRecognitionOnWavFileAtPath but nothing happens.
I give the languageModel and dictionary paths generated by Rejecto.
I recorded the wav file outside of the app in the end, I was wondering if the problem is it’s not the right format?
16-bit PCM
16000Hz
StereolookbadgersParticipantJust trying to get this up and running. I can get SaveTheWave to work in the sample app. However in my test application I get undefined symbols for architecture armv7
“_OBJC_CLASS_$_SaevTheWaveController”, referenced from:
objc-class-ref in…
ld: symbol(s) not found for architecture armv7
clang error: link command failed with exit code 1I have checked “Other Linker Flags” have the linker flag “-ObjC”:
lookbadgersParticipantThank you, I will give that a try. I was just hoping the question may have already been answered. I will try and post my findings when I get time to test.
lookbadgersParticipantThank you for the reply. I now understand why it’s not an exact probability for all apps but instead a formula based on number of words in a sentence.
With that in mind does a previous utterance have any impact on the next?
For example the pause between “THE QUICK” and “BROWN”. Or is the second utterance “BROWN” treated as a 1-gram and the previous 2-gram “THE QUICK” disregarded.
I’ve noticed sometime users have been hesitating between words in expected phrases and I am trying to find out if this has been reducing the quality of the perceived hypothesis after the pause.
May 10, 2013 at 11:48 am in reply to: [Resolved] Bad recognition for words with apostrophes #1017193lookbadgersParticipantI can also confirm I have experienced this. When would you estimate you could get a fix released?
Thanks
lookbadgersParticipantExcellent, thank you for the very complete answers.
lookbadgersParticipantThank you, you are correct. I’ve just added the flag to debug as well, I was certain I put it for both. The app is no longer sad :)
lookbadgersParticipantI think for clarity I would prefer it, at first I thought I was doing something wrong.
I’ve zipped everything up, both frameworks are included by reference though so I’m not sure if this will have everything you need.
lookbadgersParticipantThose lines are included, here’s a screenshot that shows them and the RapidEarsDemo.framework included.
http://imageshack.us/photo/my-images/688/screenshot20120718at171.png/What I mean is it doesn’t mention changing following part of the method call.
dictionaryAtPath:self.pathToDictionaryToStartAppWith languageModelIsJSGF:FALSE
to
andDictionaryAtPath:self.pathToDictionaryToStartAppWith
lookbadgersParticipantHi,
No problem I assume it’s probably something simple I’ve missed at my end.
The log is here: https://pastebin.com/dcefjGdw
I replaced
[self.pocketsphinxController startListeningWithLanguageModelAtPath:self.pathToGrammarToStartAppWith dictionaryAtPath:self.pathToDictionaryToStartAppWith languageModelIsJSGF:FALSE];With the following:
[self.pocketsphinxController startRealtimeListeningWithLanguageModelAtPath:self.pathToGrammarToStartAppWith andDictionaryAtPath:self.pathToDictionaryToStartAppWith];I downloaded a new version of OpenEars from https://www.politepix.com/openears/ so I assume that is compatible and avoids the issue of upgrading.
Thanks
lookbadgersParticipantOk thank you for the quick reply. Time to get the mic out!
-
AuthorPosts