That is true - TTS is currently given the reading only; since the TTS engine ignores pitch markings it will read it quite flat. The advantage is that it will read all readings. If the TTS engine was given only the kanji, then it would read just the first reading.
Perhaps if I let the TTS to read the kanji first, then the readings, that would do the trick? Not sure here, perhaps it will confuse the user even more.
Perhaps the best idea is to allow the user to choose what will be sent to the TTS engine - either kanji, or reading.
I think it's okay to get the kanji part read first, but personally I think it might sound good to get to choose? It's rare, but 執行 （しっこう, etc.）for example has four readings and the output seems like a good demonstration of why being to choose might be great :)
I think I remember now: when I introduced TTS, the engines back then were way simpler and couldn't handle reading kanjis. However it seems that the situation has been improved now. I'll thus add support for the picker on what to read.
Selection dialog implemented in Aedict 3.41. It seems that the TTS still have some issues, at least the default Google one, since it reads 喰べる as something like 'kviberu' ;) Anyways, at least now you can choose what the TTS will read.
Don't trust the TTS too much - albeit the speech synthesis made huge progress, it is still just an automatized tool which may make mistakes.
Would be great if it read the Kanji directly as I think (I think) pitch is automatically taken into account with TTS. Currently the popular Hashi (箸 and 橋) are pronounced the same.
The text was updated successfully, but these errors were encountered: