Open GoogleCodeExporter opened 8 years ago
Let me know if my JSON needs some fixing please!
Original comment by jbjor...@gmail.com
on 5 Jun 2013 at 7:51
It looks fine. But honestly, Google's Speech API is very good at this stuff.
Have you found any situations where it mispronounces things?
Original comment by aeharding
on 6 Jun 2013 at 3:00
Yes, usually speech engines are very good at this, but they are consistent when
they mangle a word. I have also found that different SAPI 5 voices can have
different peculiarities (meaning that the JSON file might be somewhat voice
specific). Often the mangled words are proper nouns, for example EZ Access
should be read as "EE ZEE Access" rather than "ehz Access."
Hopefully the JSON file will usually be short.
This is a lower priority than getting the DOM parsing and navigating overhaul
done.
Original comment by jbjor...@gmail.com
on 6 Jun 2013 at 2:05
I've found that the default Chrome voice pronounces 'EZ Access' better than 'ee
zee access'
The voice changes the synthesis, but isn't it consistent where if the engine
recognizes 'EZ' as ee zee it will be the same across voices (not ehz)?
Original comment by aeharding
on 6 Jun 2013 at 4:04
At least on Windows with SAPI 5 voices, it seems like the voice has some "say"
over how something is read. For example, the default Windows 7 voice says "vee"
if the highlight is on 'V', whereas a voice called Neospeech Paul says "five"
if the highlight is on 'V'.
The word pronunciation file could be used as a "global find and say instead"
function for particular words (and especially proper nouns). It might depend on
the voice in some cases.
You are right though, 'EZ Access' seems to be read correctly at least with the
few voices I have tried. It might be good to include a different example word
in the pronunciation lookup file... any ideas?
Maybe?
"json": "jay sawn"
Original comment by jbjor...@gmail.com
on 6 Jun 2013 at 5:46
json is also pronounced correctly (as jay sawn) in my testing.
I can see this useful for Roman Numerals, but that's all right now. If we find
things poorly pronounced, we can always add other find-and-replace rules after
the roman numeral rules.
It is a good idea to allow this flexibility for designers.
Original comment by aeharding
on 6 Jun 2013 at 6:12
I talked to DK who does our EZ Access coding in toolbook and he said that he
has a global search-replace-and-say function. It is only used for a few words
at a time.
I wrote up a function for this in r161. It needs to integrated in the speech
process yet. Also a dictionary file should be created and referenced (simpler
than the ones I uploaded earlier).
Original comment by jbjor...@gmail.com
on 6 Jun 2013 at 8:29
Oops, Bern, I missed in your JSON file, you included a comma after the last
item. This is a common mistake. Sorry I didn't call it out before.
Check out JSONlint.com to check JSON code.
Also, r162 makes much progress on integrating it all. Check ci comment for what
I did (lmk if you want different) and there's also a little potential problem
with your search-and-replace function that you might want to look into;
otherwise I can.
Original comment by aeharding
on 7 Jun 2013 at 6:15
Thanks for fixing the JSON issue.
If you wouldn't mind looking at the search-and-replace function to find the
problem. I did some basic testing myself, but haven't used a JSON file for
testing (I just put the dictionary inline before the function's code).
You may wish to check that words separated by punctuation (and not spaces) are
replaced correctly. The code also should only replace whole words, so key=foo
does not match "foobar" or "foos".
Original comment by jbjor...@gmail.com
on 7 Jun 2013 at 3:18
They are replacing properly with punctuation
For foo = testing:
Hello foo ==> Hello testing
Hello "foo". ==> Hello "testing".
Hellofoo ==> Hellofoo
The only thing not working is capitalization.
Original comment by aeharding
on 7 Jun 2013 at 5:40
Anything remaining on this, Bern? I don't remember if the capitalization thing
was ever fixed. Should look into that. Forgot how the whole dictionary works,
heh.
Original comment by aeharding
on 27 Aug 2013 at 5:40
I think this can be closed after testing. The capitalization of the output
shouldn't matter because it is being sent to the speech engine and not
displayed. I think that the dictionary search-and-replace should be case
insensitive if that is easy to do.
The pronunciation JSON files can be removed from the project, except whatever
you are using.
Original comment by jbjor...@gmail.com
on 27 Aug 2013 at 7:27
Original issue reported on code.google.com by
jbjor...@gmail.com
on 5 Jun 2013 at 7:24Attachments: