[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Common Database for Abbreviations, Acronyms, etc.
From: |
Tomáš Cerha |
Subject: |
Common Database for Abbreviations, Acronyms, etc. |
Date: |
Wed, 26 Sep 2012 12:12:59 +0200 |
Dne 24.9.2012 13:12, Peter Grasch wrote:
> but I'd really like to hear from all of you: Would you be interested in
> helping to build such a library? If such a library would exist, would
> you consider using it instead of your current implementation?
I believe such common library would definitely be a step in the right
direction. The
question is, however, at which level of the stack should this library be used.
As this
is actualy a text to speech conversion, so a simple answer is, that it belongs
to the
TTS layer. The TTS layer is part of every speech synthesizer, so it belongs to
the
speech synthesizer. This would be bossible with espeak or Festival, but we get
into
troubles if we want the same functionality with proprietary speech synthesizers.
A similar discussion arises on this list from time to time. One group says
that is is
simply technically incorrect to implement such functionality anwhere else than
in the
TTS layer. The argument is very valid, because there are clear techical
problems when
TTS processing is duplicated at two differnt layers. The other group, on the
other
hand, thinks less about the technical aspects and concerns more on the end
result. The
ideal layer where this processing should take place seems to be the Speech
Dispatcher
for this group. It would provide the functionality translarently and centrally
for all
applications that use speech output and the results would be consistent across
all
speech synthesizers. It seems very reasonable, the only remaining problem is
to solve
those ?technical problems?.
Does anyone want to jump into this discussion again? Do we have any new light
on the
matter or any new ideas?
Sorry, Peter, for not giving a clear answer to your question. A reasonable
short term
solution might be creating such a library and using it from Orca and Simon.
This is
still better than duplication and quite ok as Orca now does this processing
anyway. The
correct long term solution would then be to move it from Orca to some lower
layers.
Best regards
Tomas