There are three options associated with the grammar compiler:
By default, grammars are compiled with what is known as the uniform probability computation, which means that all words out of a given state are equally likely. The non-uniform probably option enables the developer to turn the uniform probability computation off.
The recognition performance differences between the two options is strongly grammar dependent. An extreme example is:
<Number> = "point" <digit> | <digit> <digit> = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9The first word that can be spoken is "point" or a digit. With the uniform probability computation, all initial words have probability 1/11. Without the uniform probability computation, "point" has a probability of 0.5, while each digit has a probability of only 0.05.
Without the uniform probability computation, language model probabilities are assigned to be locally uniform for each production rule in the BNF file. Take the following example:
<A> = <a1> | <a2> <a1> = "West Palm" <a2> = "Hawthorne" | "Yorktown"
Without a uniform probability computation, <a1> and <a2> each get probability 0.5. <a1> expands to a single terminal, "West Palm," which has probability 0.5 x 1 or 0.5. Since <a2> expands to two terminals, which are considered equally likely, "Hawthorne" and "Yorktown" each get probability 0.5 x 0.5 or 0.25. Consequently, "West Palm" has twice the probability of the other alternative phrases. This allows an application developer the opportunity to bias word probabilities, where they are known or where they make sense to use.
If <A> were rewritten as:
<A> = "West Palm" | "Hawthorne" | "Yorktown"then all possibilities are equally likely. This is what the uniform probability computation will generate, independent of how the rules are expressed in the BNF file.
To be independent of rule construction in BNF files, most application developers would likely want to keep the default; that is, they should use the uniform probability computation.
Use this option to generate an FSG file that handles cases where the end user injects mumbling or other non-speech noise while speaking. For example, in a grammar with the following construct:
<rule> = open <program>the user might say "uhm...open Lotus Notes" instead of "open Lotus Notes." Specifying the mumble words option causes the speech engine to ignore any speech that is not defined as valid by the BNF grammar.
You can also tell the speech engine to return the non-speech noise text back to the application, along with the word or phrase that was recognized. A mumble is flagged as an SM_WORD with an empty spelling ("") in an SM_RECOGNIZED_PHRASE message. Flag settings for mumble on a run-time SmDefineGrammar call override the flags compiled into the FSG.
Use this option to generate an FSG file that handles cases where the end user pauses briefly while speaking a command. For example, in a grammar with the following construct:
<rule> = open <program>the user might say "open <pause> Lotus Notes" instead of "open Lotus Notes." Specifying this option causes the speech engine to ignore any silence within an utterance.
SMAPI treats silence similarly to mumbles. Silence is allowed within a phrase, and is returned as an SM_WORD with a spelling of "<silence>." As with the mumble words option, flag settings for silence on a run-time SmDefineGrammar call override the flags compiled into the FSG.
vtbnfc [-n] [-m | -m- | -m+] [-s | -s- | -s+] [-o outfile] grammarfileThe available options are: