symbolic voice-types versus synthesis voices

[Andrei Kholodnyi]

> But does this diversity matter? ?If these diverse names are exposed to the 
> end user, I
> think it is still better than exposing nicely aligned symbolic names, which 
> carry no
> information (except for the gender). ?The client can also expose voice 
> properties to the
> user if this is implemented (and available).

each synth has its own convention for the voices naming, e.g.
espeak:
                     NAME                 LANGUAGE                  VARIANT
                  default                       en                     none
              en-scottish                       en                       sc
                  english                       en                       uk
               lancashire                       en                 uk-north
               english_rp                       en                    uk-rp
            english_wmids                       en                 uk-wmids
               english-us                       en                       us
            en-westindies                       en                       wi

pico:
                 samantha                       en                    en-US
                   serena                       en                    en-GB

as you can see VARIANT differs between them, e.g. you have
                 english-us                       en                       us
                 samantha                       en                    en-US
which is the same variant, but written differently.
It means if apps want to search for "US English" you don't know what
to search for.

LANGUAGE is also different, you might have e.g. 3 letters
            greek-ancient                      grc                     none

Now my question is do we want to introduce a consistent voice naming
convention for SD?
we could leave e.g. language names as is /however there is a name
clash probability between synths/

but IMO it would be good to "normalize" LANGUAGE and VARIANT at least.
it will allow to search properly.

> So if a had to choose between the two methods, I'd choose synthesis voices + 
> voice
> params, since this allows greater flexibility. ?It also allows symbolic voice 
> names to
> be implemented client side, while it is not possible the other way round 
> (implement
> synthesis voices client side if the server only supports symbolic voice 
> types).

I just thought that we might probably map names to something like
"spd-voice-NN" or "male-en-NN",
which is not much worser than e.g. "english-us" :D,
But we could of cause stay with "native" synth names and add name
mapping later on if we need it.