Choosing speech API features
James makes a good point that limiting API features to known examples of applications potentially lowers the ceiling on how well an API can adapt to unanticipated needs. I think he's right. But it's only one factor. When multiple new features are competing for a slot in the development schedule, another important factor will always be the relative demand for that feature. So it's always good to understand what scenarios a feature will enable, whether demand already exists, and, as James mentions, the strategic value of widening the API and enabling new innovation. (as well as other things, like cost, completeness, etc).
Comments
- Anonymous
February 24, 2005
not to be a punk ... but it feels like i've been waiting so long for a new version of SAPI ... that i dont mind waiting longer for more features.
i also think phoneme segmentation would provide more visibility into the 'magic' behind speech technologies. if this allowed more people to understand the 'magic' ... then i think it would bring more developers into the speech reco field.
it would also be good if i had an API that i could provide the word as text, and then get the phonemes for that word returned. not sure if you'd make that public, but it could be useful as well. - Anonymous
February 24, 2005
The comment has been removed - Anonymous
February 26, 2005
James: i'm familiar with CMUDICT ...
http://www.brains-N-brawn.com/ttSpeech/