Raw text has the problem that it cannot always easily be rendered as speech in the way the author wishes. Sable offers a well-defined way of marking up text so that the synthesizer may render it appropriately.

Festival XML Mark-UP: SSML and HTML

(From XML/SGML mark-up)

NOTE In my Ubuntu distributions, examples are found in directory /usr/share/doc/festival/examples/. Two are provided here: example1.sable and example2.sable. In these examples I have commented out or ammended those elements that result in segmentation fault or go unrecognized. Generally, festival's SGML is is document type SABEL.

The ideas of a general, synthesizer system nonspecific, mark-up language for labelling text has been under discussion for some time. Festival has supported an SGML based markup language through multiple versions most recently STML (sproat97). This is based on the earlier SSML (Speech Synthesis Markup Language) which was supported by previous versions of Festival (taylor96). With this version of Festival we support Sable a similar mark-up language devised by a consortium from Bell Labls, Sub Microsystems, AT&T and Edinburgh, sable98.

Unlike the previous versions, which were SGML based, the implementation of Sable in Festival is now XML based. To the user the difference is negligable but using XML makes processing of files easier and more standardized. Also Festival now includes an XML, parser thus reducing the dependencies in processing Sable text.

The definition of Sable is by no means settled and is still in development. In this release Festival offers people working on Sable and other XML (and SGML) based markup languages a chance to quickly experiment with prototypes by providing a DTD (document type descriptions) and the mapping of the elements in the DTD to Festival functions. Although we have not yet (personally) investigated facilities like cascading style sheets and generalized SGML specification languages like DSSSL, we believe the facilities offer by Festival allow rapid prototyping of speech output markup languages.

Primarily we see Sable markup text as a language that will be generated by other programs, e.g. text generation systems, dialog managers etc. therefore a standard, easy to parse, format is required, even if it seems overly verbose for human writers.

An example of Sable with descriptions

Here is a simple example of Sable marked up text:

<?xml version="1.0"?>
<!DOCTYPE SABLE PUBLIC "-//SABLE//DTD SABLE speech mark up//EN"
      "Sable.v0_2.dtd"
[]>
<SABLE>
<SPEAKER NAME="male1">

The boy saw the girl in the park <BREAK/> with the telescope.
The boy saw the girl <BREAK/> in the park with the telescope.

Good morning <BREAK /> My name is Stuart, which is spelled
<RATE SPEED="-40%">
<SAYAS MODE="literal">stuart</SAYAS> </RATE>
though some people pronounce it
<PRON SUB="stoo art">stuart</PRON>.  My telephone number
is <SAYAS MODE="literal">2787</SAYAS>.

I used to work in <PRON SUB="Buckloo">Buccleuch</PRON> Place,
but no one can pronounce that.

By the way, my telephone number is actually
<AUDIO SRC="http://www.cstr.ed.ac.uk/~awb/sounds/touchtone.2.au"/>
<AUDIO SRC="http://www.cstr.ed.ac.uk/~awb/sounds/touchtone.7.au"/>
<AUDIO SRC="http://www.cstr.ed.ac.uk/~awb/sounds/touchtone.8.au"/>
<AUDIO SRC="http://www.cstr.ed.ac.uk/~awb/sounds/touchtone.7.au"/>.
</SPEAKER>
</SABLE>

After the initial definition of the SABLE tags, through the file Sable.v0_2.dtd, which is distributed as part of Festival, the body is given. There are tags for identifying the language and the voice. Explicit boundary markers may be given in text. Also duration and intonation control can be explicit specified as can new pronunciations of words. The last sentence specifies some external filenames to play at that point.


      


      

        
Currently supported Sable tags

        
There is not yet a definitive set of tags but hopefully such a list will form over the next few months. As adding support for new tags is often trivial the problem lies much more in defining what tags there should be than in actually implementing them. The following are based on version 0.2 of Sable as described in http://www.cstr.ed.ac.uk/projects/sable_spec2.html, though some aspects are not currently supported in this implementation. Further updates will be announces through the Sable mailing list.

        

          
LANGUAGE

          

            
Allows the specification of the language through the ID attribute. Valid values in Festival are, english, en1, spanish, en, and others depending on your particular installation. For example

            
<LANGUAGE id="english"> ... </LANGUAGE>

            
If the language isn't supported by the particualr installation of Festival Some text in .. is said instead and the section is ommitted.

          

          
SPEAKER

          

            
Select a voice. Accepts a parameter NAME which takes values male1, male2, female1, etc. There is currently no definition about what happens when a voice is selected which the synthesizer doesn't support. An example is

            
<SPEAKER name="male1"> ... </SPEAKER>

          

          
AUDIO

          

            
This allows the specification of an external waveform that is to be included. There are attributes for specifying volume and whether the waveform is to be played in the background of the following text or not. Festival as yet only supports insertion.

            
My telephone number is
    <AUDIO SRC="http://www.cstr.ed.ac.uk/~awb/sounds/touchtone.2.au"/>
    <AUDIO SRC="http://www.cstr.ed.ac.uk/~awb/sounds/touchtone.7.au"/>
    <AUDIO SRC="http://www.cstr.ed.ac.uk/~awb/sounds/touchtone.8.au"/>
    <AUDIO SRC="http://www.cstr.ed.ac.uk/~awb/sounds/touchtone.7.au"/>

          

          
MARKER

          

            
This allows Festival to mark when a particular part of the text has been reached. At present simply the value of the MARK attribute is printed. This is done when that piece of text is analyzed, not when it is played. To use this in any real application would require changes to this tags implementation.

            
Move the <MARKER MARK="mouse" /> mouse to the top.

          

          
BREAK

          

            
Specifies a boundary at some LEVEL. Strength may be values Large, Medium, Small or a number. Note that this is an empty tag and must include the closing part within itself.

            
<BREAK LEVEL="LARGE"/>

          

          
DIV

          

            
This signals an division. In Festival this causes an utterance break. A TYPE attribute may be specified but it is ignored by Festival.

            

          

          
PRON

          

            
Allows pronunciation of enclosed text to be explcitily given. It supports the attributes IPA for an IPA specification (not currently supported by Festival); SUB text to be substituted which can be in some form of phonetic spelling, and ORIGIN where the linguistic origin of the enclosed text may be identified to assist in etymologically sensitive letter to sound rules.

            
<PRON SUB="toe maa toe">tomato</PRON>

          

          
SAYAS

          

            
Allows identification of the enclosed tokens/text. The attribute MODE can take any of the following a values: literal, date, time, phone, net, postal, currency, math, fraction, measure, ordinal, cardinal, or name. Further specification of type for dates (MDY, DMY etc) may be speficied through the MODETYPE attribute.

            
As a test of marked-up numbers. Here we have:


    a year <SAYAS MODE="date">1998</SAYAS>,
    an ordinal <SAYAS MODE="ordinal">1998</SAYAS>,
    a cardinal <SAYAS MODE="cardinal">1998</SAYAS>,
    a literal <SAYAS MODE="literal">1998</SAYAS>,
    and phone number <SAYAS MODE="phone">1998</SAYAS>.

          

          
EMPH

          

            
To specify enclose text should be emphasized, a LEVEL attribute may be specified but its value is currently ignored by Festival (besides the emphasis Festival generates isn't very good anyway).

            
The leaders of <EMPH>Denmark</EMPH> and <EMPH>India</EMPH>
            meet on Friday.

          

          
PITCH

          

            
Allows the specification of pitch range, mid and base points.

            
Without his penguin, <PITCH BASE="-20%"> which he left at home, </PITCH>
he could not enter the restaurant.

          

          
RATE

          

            
Allows the specification of speaking rate

            
The address is <RATE SPEED="-40%"> 10 Main Street </RATE>.

          

          
VOLUME

          

            
Allows the specification of volume. Note in festival this causes an utterance break before and after this tag.


    Please speak more <VOLUME LEVEL="loud">loudly</VOLUME>, except
    when I ask you to speak <VOLUME LEVEL="quiet">in a quiet voice</VOLUME>.

          

          
ENGINE

          

            
This allows specification of engine specific commands

            
An example is <ENGINE ID="festival" DATA="our own festival speech
synthesizer"> the festival speech synthesizer</ENGINE> or
the Bell Labs speech synthesizer.

          

        

        
These tags may change in name but they cover the aspects of speech mark up that we wish to express. Later additions and changes to these are expected.

        
See the files festival/examples/example.sable and festival/examples/example2.sable for working examples.

        
Note the definition of Sable is on-going and there are likely to be later more complete implementations of sable for Festival as independent releases. Consult url://www.cstr.ed.ac.uk/projects/sable.html for the most recent updates.

      


      

        
Adding new Sable tags*

      


      

        
XML Software environment requirements*

      


      

        
Using Sable

        
Support in Festival for Sable is as a text mode. In the command mode use the following to process a Sable file

        
(tts "file.sable" 'sable)

        
Also the automatic selection of mode based on file type has been set up such that files ending .sable will be automatically synthesized in this mode. Thus

        
festival --tts fred.sable

        
will render fred.sable as speech in Sable mode.

        

        
Another way of using Sable is through the Emacs interface. The say-buffer command will send the Emacs buffer mode to Festival as its tts-mode. If the Emacs mode is stml or sgml, the file is treated as a sable file.

        

        
Many people experimenting with Sable (and TTS in general) often want all the waveform output to be saved to be played at a later date. The simplest way to do this is using the text2wave script, It respects the audo mode selection:

        
text2wave fred.sable -o fred.wav

        
Note: this renders the file as a single waveform (done by concatenating the waveforms for each utterance in the Sable file).

        
If you wish the waveform for each utterance in a file saved you can cause the tts process to save the waveforms during synthesis:

        
festival> (save_waves_during_tts)

        
Any future call to tts will cause the waveforms to be saved in a file tts_file_xxx.wav, where xxx is a number. A call to (save_waves_during_tts_STOP) will stop saving the waves. A message is printed when the waveform is saved otherwise people forget about this and wonder why their disk has filled up.

        
This is done by inserting a function in tts_hooks, which saves the wave. To do other things to each utterances during TTS (such as saving the utterance structure), try redefining the function save_tts_output (see festival/lib/tts.scm).

      


      

        
Rendering Sable files as speech*