24.3 Defining a new voice

As there are a number of voices available for Festival and they may or may not exists in different installations we have tried to make it as simple as possible to add new voices to the system without having to change any of the basic distribution. In fact if the voices use the following standard method for describing themselves it is merely a matter of unpacking them in order for them to be used by the system.

The variable voice-path conatins a list of directories where voices will be automatically searched for. If this is not set it is set automatically by appending /voices/ to all paths in festival load-path. You may add new directories explicitly to this variable in your /etc/festival.scm file or your own .festivalrc as you wish.

Each voice directory is assumed to be of the form

LANGUAGE/VOICENAME/

Within the VOICENAME/ directory itself it is assumed there is a file festvox/VOICENAME.scm which when loaded will define the voice itself. The actual voice function should be called voice_VOICENAME.

For example the voices distributed with the standard Festival distribution all unpack in festival/lib/voices. The Amercan voice ked_diphone unpacks into

festival/lib/voices/english/ked_diphone/

Its actual definition file is in

festival/lib/voices/english/ked_diphone/festvox/ked_diphone.scm

Note the name of the directory and the name of the Scheme definition file must be the same.

Alternative voices using perhaps a different encoding of the database but the same front end may be defined in the same way by using symbolic links in the langauge directoriy to the main directory. For example a PSOLA version of the ked voice may be defined in

festival/lib/voices/english/ked_diphone/festvox/ked_psola.scm

Adding a symbole link in festival/lib/voices/english/ ro ked_diphone called ked_psola will allow that voice to be automatically registered when Festival starts up.

Note that this method doesn’t actually load the voices it finds, that could be prohibitively time consuming to the start up process. It blindly assumes that there is a file VOICENAME/festvox/VOICENAME.scm to load. An autoload definition is given for voice_VOICENAME which when called will load that file and call the real definition if it exists in the file.

This is only a recommended method to make adding new voices easier, it may be ignored if you wish. However we still recommend that even if you use your own convetions for adding new voices you consider the autoload function to define them in, for example, the /etc/festival.scm file or .festivalrc. The autoload function takes three arguments: a function name, a file containing the actual definiton and a comment. For example a definition of voice can be done explicitly by

(autooad voice_f2b  "/home/awb/data/f2b/ducs/f2b_ducs"
     "American English female f2b")))

Of course you can also load the definition file explicitly if you wish.

In order to allow the system to start making intellegent use of voices we recommend that all voice definitions include a call to the function voice_proclaim this allows the system to know some properties about the voice such as language, gender and dialect. The proclaim_voice function taks two arguments a name (e.g. rab_diphone and an assoc list of features and names. Currently we require language, gender, dialect and description. The last being a textual description of the voice itself. An example proclaimation is

(proclaim_voice
 'rab_diphone
 '((language english)
   (gender male)
   (dialect british)
   (description
    "This voice provides a British RP English male voice using a
     residual excited LPC diphone synthesis method.  It uses a
     modified Oxford Advanced Learners' Dictionary for pronunciations.
     Prosodic phrasing is provided by a statistically trained model
     using part of speech and local distribution of breaks.  Intonation
     is provided by a CART tree predicting ToBI accents and an F0
     contour generated from a model trained from natural speech.  The
     duration model is also trained from data using a CART tree.")))

There are functions to access a description. voice.description will return the description for a given voice and will load that voice if it is not already loaded. voice.describe will describe the given given voice by synthesizing the textual description using the current voice. It would be nice to use the voice itself to give a self introduction but unfortunately that introduces of problem of decide which language the description should be in, we are not all as fluent in welsh as we’d like to be.

The function voice.list will list the potential voices in the system. These are the names of voices which have been found in the voice-path. As they have not actaully been loaded they can’t actually be confirmed as usable voices. One solution to this would be to load all voices at start up time which would allow confirmation they exist and to get their full description through proclaim_voice. But start up is already too slow in festival so we have to accept this stat for the time being. Splitting the description of the voice from the actual definition is a possible solution to this problem but we have not yet looked in to this.