speechd-discuss
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]