speechd-discuss
[Top][All Lists]
Advanced

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

symbolic voice-types versus synthesis voices


From: Andrei Kholodnyi
Subject: symbolic voice-types versus synthesis voices
Date: Sun, 7 Nov 2010 21:11:54 +0100

> Unfortunately, I don't have a very solid proposal. ?I just find it
> slightly confusing that there are two ways to select a voice.

yes, completely agree. I also think we need to stay with one way.

> When I replied to Andrei's message yesterday, I commented that
> it would be nice to do away with the synthesis voice entirely. ?From a
> user's perspective, it is perhaps easier to think about voices in general
> terms, such as male1 and female1.

also agree, it makes sense to have the same look and feel for all
voices regardless any module specifics.
however at the moment we have SPDVoiceType which is restricted to 3
types per gender per module.

Probably it is better to use approach defined in SSML?

gender:      Enumerated values are: "male", "female", "neutral", or
the empty string "".
age:          preferred age in years (since birth) of the voice to
speak the contained text.
variant:      a preferred variant of the other voice characteristics
to speak the contained text. (e.g. the second male child voice).
name:        a processor-specific voice name to speak the contained text.
languages: list of languages the voice is desired to speak.

i.e. having

typedef struct {
    SPDVoiceType gender; /* SPD_VOICE_MALE, SPD_VOICE_FEMALE,
SPD_VOICE_NEUTRAL */
    int age;
    char *name;      /* Name of the voice (id) */
    char *language;  /* 2-letter ISO language code */
    char *variant;   /* a not-well defined string describing dialect etc. */
} SPDVoice;

> On second thought, this classification can be too rigid at times. ?The 
> "synthesis voice" setting
> allows the greatest flexibility.

but it also gives a big diversity in naming, since different synths
name voices differently.
I feel now your proposal is better.



reply via email to

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