|
Here I have two Indonesian female voices. However, when I use these voices for dubbing, the resulting voices are male.
|
Replies: 2 comments
|
In your second screenshot, look at the "Designed Voices" panel: Wanita M" shows That As a workaround for now: delete the "Wanita M" profile and recreate it through Voice Design (set gender/age/pitch fresh, then "Save design as profile") rather than however it was originally created (imported, cloned, or hand edited). A freshly saved profile should store identity as a normal string and avoid this. For the maintainer: it'd help to know how "Wanita M" was created (cloned from a sample? Imported as a .ovsvoice bundle? Edited via API?) since that'll narrow down where the object is leaking in instead of being flattened to a string before save. A diagnostic bundle (Settings -> Diagnostics) attached to this issue would also help confirm whether it's a frontend display bug only or whether the bad data is actually what's reaching the TTS engine. |
|
@daveshenal called it exactly right — the What happened: a bug in an older build saved the designed voice's gender/identity data as a raw object instead of the tag string. An early cleanup pass then blanked the corrupted value — which silently threw away your design, so "Wanita M" rendered with the engine's default (male-sounding) voice instead of your female design. Exactly what you saw. This is fixed since v0.3.7 (PR #600, which cites this exact Indonesian-female-voice case): the app now rebuilds the identity from your design's saved category picks at synthesis time — your existing voices heal automatically, no need to re-create them — and corrupted identity data can no longer be saved in the first place. If you're on the latest release (v0.3.10) and a designed voice still renders the wrong gender, that would be new information — please open an issue with the voice's design settings and I'll dig in. Marking this answered; thanks for the clear screenshots, and thanks @daveshenal for the sharp diagnosis. |


@daveshenal called it exactly right — the
[object Object]in the identity tags was the tell. 🎯What happened: a bug in an older build saved the designed voice's gender/identity data as a raw object instead of the tag string. An early cleanup pass then blanked the corrupted value — which silently threw away your design, so "Wanita M" rendered with the engine's default (male-sounding) voice instead of your female design. Exactly what you saw.
This is fixed since v0.3.7 (PR #600, which cites this exact Indonesian-female-voice case): the app now rebuilds the identity from your design's saved category picks at synthesis time — your existing voices heal automatically, no need to re-create them …