[Found Something Interesting] A Few more voices

[lbk2907]

Hi @gexgd0419.
I not sure if these voices is work offline or online. I found this from the NVDA Russian comunity. They make an NVDA Add-On for this and it works well. Maybe you can take a look of this and add the support to this adapter.

https://nvda.ru/sintezatory-rechi-microsoft-neural-voices-dlja-nvda

Voices can be download from this page as well.

[lbk2907]

[Generated By Claude Code].

Update: I got these voices working with this adapter. They're Microsoft's offline/embedded neural voices (the same models the NVDA "NeuralVoices" add-on uses). Details in case it's useful:

Environment: Windows 11 25H2 (build 26200), adapter v0.2.9 (x64), test voice = en-GB Sonia — a newer voice (Tokens.xml has LicenseVersion="1").

Symptom: the voice loads and shows up in SAPI, but speaking fails with 0x24 (SPXERR_EXTENSION_LIBRARY_NOT_FOUND).

Root cause: the Microsoft.CognitiveServices.Speech DLLs bundled in v0.2.9 are 1.41.1, which is too old to load these newer voices. The NeuralVoices add-on ships 1.50.0.

Fix (both parts needed):

1. Replaced the adapter's x64 Microsoft.CognitiveServices.Speech* DLLs (core, embedded.tts, onnxruntime, audio.sys, kws) with the 1.50.0 versions, plus a matching newer VC/UCRT runtime. That cleared SPXERR_EXTENSION_LIBRARY_NOT_FOUND.
2. Supplied the voice's own license: these LicenseVersion=1 voices ship a SynthModel.license file and don't authenticate with the built-in MS_TTS_KEY. Putting that license text into the voice's registry token as a "License" value (instead of "Key") makes it speak.

Confirmed working in TtsApplication.exe and in NVDA (SAPI5) after the above.

Possible enhancements:

• Bump the bundled Speech SDK (I know there are CRT-compat concerns — but 1.50.0 runs fine in-process inside NVDA, which is a SAPI-style host).
• During local-voice folder enumeration, optionally read a per-voice SynthModel.license / SynthModel.key file and emit License/Key accordingly, instead of always using MS_TTS_KEY.

@gexgd0419

I have test it by myself and it works.

[lbk2907]

@gexgd0419

I notice that some of the voices have different key. Like for example NeuralVoices-voice-Benjamin-RUS-English-United-States.

As stated, the license key for each voices can be found in the SynthModel.license or SynthModel.key file.

[lbk2907]

[Generated By AI]

@gexgd0419
Feel free to make any changes if you have more better approach.

Follow-up: how the newer (LicenseVersion=1) voices can be supported built-in

I got the newer natural voices (e.g. en-GB Sonia) working with the adapter. It took two changes — sharing the mechanism in case it's useful. No license text is needed anywhere in the project (see below).

1. Speech SDK version. On stock v0.2.9 (SDK 1.41.1) these newer voices load in SAPI but fail on speak with 0x24 SPXERR_EXTENSION_LIBRARY_NOT_FOUND. Updating the bundled Microsoft.CognitiveServices.Speech* DLLs to 1.50.0 (the version the NVDA NeuralVoices add-on ships) fixes it.

2. Per-voice license. These voices ship their own SynthModel.license and won't authenticate with the built-in MS_TTS_KEY. InitLocalVoice already accepts a License value — the only gap is that MakeLocalVoiceToken always writes MS_TTS_KEY.

Since every voice carries its own license file, the enumerator can read it per-voice from the voice folder (right next to Tokens.xml, inside the Local voice path):

<Local voice path>\en-GB-SoniaNeural\Tokens.xml
<Local voice path>\en-GB-SoniaNeural\SynthModel.license   <-- read this per voice

Add a resolver (needs #include <fstream>):

static std::wstring ReadCredentialFile(const std::wstring& path)
{
    std::ifstream f(path, std::ios::binary);
    if (!f) return {};
    std::string s{ std::istreambuf_iterator<char>(f), std::istreambuf_iterator<char>() };
    while (!s.empty() && (s.back()=='\r'||s.back()=='\n'||s.back()==' '||s.back()=='\t'))
        s.pop_back();
    return s.empty() ? std::wstring{} : UTF8ToWString(s);
}

// Each voice supplies its own credential file next to Tokens.xml.
// Falls back to the built-in key for Store voices that ship none.
static std::pair<std::wstring, std::wstring> ResolveVoiceCredential(const std::wstring& voiceFolder)
{
    if (auto lic = ReadCredentialFile(voiceFolder + L"\\SynthModel.license"); !lic.empty())
        return { L"License", std::move(lic) };
    if (auto key = ReadCredentialFile(voiceFolder + L"\\SynthModel.key"); !key.empty())
        return { L"Key", std::move(key) };
    return { L"Key", MS_TTS_KEY };
}

Then in MakeLocalVoiceToken, replace the hardcoded { L"Key", MS_TTS_KEY } (read path before it's moved):

auto [credName, credValue] = ResolveVoiceCredential(path);
// ...inside the NaturalVoiceConfig .values list:
    { L"Path", std::move(path) },
    { std::move(credName), std::move(credValue) }

Why this keeps license text out of the project entirely: the adapter never stores or bundles any license. Each SynthModel.license rides inside the voice the user downloads and is read at runtime. Old key-based and Store voices are unaffected (they fall back to MS_TTS_KEY).

User workflow then becomes: drop the voice folder (with its SynthModel.license) into the Local voice path — done, no manual registry editing.

Tested on: Windows 11 25H2 (26200), adapter v0.2.9 x64, voice = en-GB Sonia (LicenseVersion=1). Confirmed working in TtsApplication.exe and NVDA (SAPI5).

[why668866-coder]

@lbk2907 你好，

我已经成功在我的分支中实现您提到的功能，我对此非常感兴趣（支持较新的离线神经网络语音，如 MicrosoftWindows.Voice.zh-CN.YunyiHD.1_1.0.1.0_x64__cw5n1h2txyewy，以及动态读取语音专属的许可证文件），你可以查看我的代码实现：https://github.com/why668866-coder/NaturalVoiceSAPIAdapter

已实现的修改：

1. 动态读取许可证：按照讨论中的思路，在代码中添加了 ReadCredentialFile 和 ResolveVoiceCredential。现在程序会在枚举本地语音文件夹时，自动查找并读取同级目录下的 SynthModel.license 或 SynthModel.key 文件，不再全局硬编码 MS_TTS_KEY。这使得 LicenseVersion=1 的新版语音可以完美支持且无需手动修改注册表。
2. 升级 Speech SDK：将捆绑的 Microsoft.CognitiveServices.Speech 相关 DLL 升级到了 1.50.0 版本，解决了旧版 SDK (1.41.1) 加载新版语音时出现的 0x24 (SPXERR_EXTENSION_LIBRARY_NOT_FOUND) 报错问题。

遇到的新问题（32位程序兼容性）：

在实际测试中我发现了一个阻碍：升级到 1.50.0 版本的 SDK 后，新版本无法在 32 位 (x86) 的宿主程序上运行。

• 在 64 位程序（如 64位的 TtsApplication）中一切正常，语音可以完美发声。
• 但是，当 32 位的程序调用 SAPI 接口时无法正常工作（推测可能是新版 1.50.0 SDK 的 x86 依赖库、CRT 兼容性或 32 位 DLL 本身存在问题）。

想请教一下你对这个 32 位兼容性问题有什么看法或更好的解决思路？比如：

• 是否有办法修复或配置让 1.50.0 的 x86 DLL 在 32 位宿主中正常工作？
• 或者是否需要做架构区分（例如 32 位环境继续降级使用旧版 SDK，仅 64 位环境使用新版 SDK）？

期待你的建议！

[lbk2907]

@why668866-coder
我觉得1.5.0的版本不支持x86.
@gexgd0419
Maybe you can take a look on this.

[gexgd0419]

可以另开一个进程用于加载语音DLL，把SAPI5 DLL改成和该进程通信以交换语音数据/事件。

目前的纯进程内方案是有缺陷的，可能会因为Azure Speech SDK依赖的CRT与客户端进程已经加载的不兼容，而导致问题。