[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SpeechIO-52] perl_festival_client / speech.irc nolonger needs catspeech



Hi,

I haven't been following the disscussion for too long... but I found something
that may be of interest...

http://www.cstr.ed.ac.uk/projects/sable.html
festival supports v.02 of the sable text markup language. (at least festival
1.3 and up)
sable has tags for emphasis, pauses, breaks, and a lot of other things for use
in the tts system. They've also got one labled as "ENGINE"
>taken from the sable_spec2.html page:

ENGINE

Description: Substitute the DATA for the contained text if the system happens
to be using the engine specified by ENGINE
Attributes:
ID	Identifier for the specific TTS engine.
DATA	Any character string to be substituted for the contained text
Properties: 
	Container element
	Nestable
The ENGINE tag allows one to select a specific text to be substituted for the
contained text for a given synthesizer, if one happens to be using that
synthesizer to read the given SABLE document. It also serves as a way to pass
engine-specific controls to a given engine: this can be implemented by using
teh ENGINE tag to enclose empty text, and having the DATA be teh control
string. Engines other than teh one specified by ID are free to ignore this tag,
or may apttempt to interpret it if they think they are able to.
Example:
"The <ENGINE ID="acme synth" DATA="wonderful, fantastic acme synthesizer"> Acme
synthesizer</ENGINE>."
On an Acme system it says "wonderful, fantastic acme systesizer". On other
systems, it says just "Acme systhesizer".


I'm not at home right not, so I'm not able to try this out at all... but it
sounds like a good solution to replacing strings like d/l with download and
such, as well as having the pottentical to really beef up the features. It
would probably be best as a module type thing, or just implemented in the
client add-ons on a per client basis.
...I'm just now realizing that this doesn't really solve the problem though....
groups of letters could still be pulled out of words and messed up (like the
imo example), however, implementing a sort of STML rendering engine to handle
this would have a lot of other extendable benifits

If nothing else.. seems like it would be worth taking a look at.

--

Josh I.