From your post I don't see anything particular new about this. Voice recognition has been done based on phonems for a long time. I did research on it 12 years ago.
The problem is that most of use do not pronouce ever phoneme in ever word and we certainly don't hear every single one. Our brains take what does get across and fill in the rest.
Take a common phrase like "did you eat?" Which me and my friends said about every day as we met after work or school. "did" has 3 phonemes. but a lot of poeple skip the last "d" sound. We shorted it almost "di gi eat" (notice how different the "you" becomes)
Also some phonemes are very similar like m and n. Although these sound are produced very differently m is by the lips and n with the tounge. But someone says monday you can distinguish m and n because there is no such word as nomday. So even with phoneme recoginition you still have to do word based matching and even sentence based matching to get high rates.
Another problem with phoneme is that the sounds are changed based on what phonemes some directly before and directly after. Doing speach therapy is hard because it very to demonstrate some sounds without adding a second phoneme. Most people unconsciencely but an "a" sound after a "p" sound when they try to show a child how to say "p", which gets confused with "b". This is hard for recoginition because the "p" in "pa" is slightly different then the "p" in "pi".
I manage a team that changed over our code base from RW to STL. The main driving force was that STL would be supported going forward were as we were using an unsupport version of RW on an unsupport platform.
The change over did induce some bugs as expected.
Code bloat, unreadable errors and other template issues are the same for STL as they are for RW so you shouldn't see any downside for items that are caused by templates.
In general RW had a fuller API set so you might find things that were easy in RW aren't quite so easy in STL. We generally wrote a wrapper function that added the RW functionality we lost then unit tested the wrapper fairly throughly.
One thing to watch out for in RW the sentinal position is at the begining of the collection and in STL it is at the end.
You do have to choose which STL to use. We are using the SGI version but will switch to the SCO/unixware native verion soon.
Get a good book I recommend "STL from the ground up" by schiltz.
Slashdot Mirror
From your post I don't see anything particular new about this. Voice recognition has been done based on phonems for a long time. I did research on it 12 years ago.
The problem is that most of use do not pronouce ever phoneme in ever word and we certainly don't
hear every single one. Our brains take what does get across and fill in the rest.
Take a common phrase like
"did you eat?"
Which me and my friends said about every day as
we met after work or school. "did" has 3 phonemes.
but a lot of poeple skip the last "d" sound.
We shorted it almost "di gi eat" (notice how
different the "you" becomes)
Also some phonemes are very similar like m and n. Although these sound are produced very differently
m is by the lips and n with the tounge. But someone says monday you can distinguish m and n
because there is no such word as nomday. So even
with phoneme recoginition you still have to do word based matching and even sentence based matching to get high rates.
Another problem with phoneme is that the sounds are changed based on what phonemes some directly before and directly after. Doing speach therapy is hard because it very to demonstrate some sounds without adding a second phoneme. Most
people unconsciencely but an "a" sound after
a "p" sound when they try to show a child how
to say "p", which gets confused with "b". This
is hard for recoginition because the "p" in
"pa" is slightly different then the "p" in "pi".
Now that they have hit 1.0 are versions
without talkback going to be availible.
Have they or will they remove debug information?
The pacakage is still ~10megs for windows. I was
hoping to see some reduction for 1.0 since I
still use a lowly 56K Modem.
I manage a team that changed over our code base from RW to STL. The main driving force was that STL would be supported going forward were as we were using an unsupport version of RW on an unsupport platform.
The change over did induce some bugs as expected.
Code bloat, unreadable errors and other template issues are the same for STL as they are for RW so you shouldn't see any downside for items that are caused by templates.
In general RW had a fuller API set so you might find things that were easy in RW aren't quite so easy in STL. We generally wrote a wrapper function that added the RW functionality we lost then unit tested the wrapper fairly throughly.
One thing to watch out for in RW the sentinal position is at the begining of the collection and in STL it is at the end.
You do have to choose which STL to use. We are using the SGI version but will switch to the SCO/unixware native verion soon.
Get a good book I recommend "STL from the ground up" by schiltz.