One core, two cores...

I mentioned before that Windows 10 came with two flavors of SAPI, 5.4 proper and OneCore, internally also marked as v.5.4. The System.Speech.Synthesis classes of the .NET library employ the classic SAPI, while the Windows.Media.SpeechSynthesis classes of the UWP library run on top of OneCore. You can see that by the contents of the voice Id values. Native applications that target SAPI directly, via COM, have the option of using either. Why was SAPI forked like that - I'm not sure.

More TTS

Continuing with the Windows speech synthesis (SAPI) theme. The situation with Sayaka is a crying shame, no question there. As for Ayumi and Ichiro, they are perfectly compatible with SAPI 5.4 proper. Move their tokens to HKLM\..\Speech, and they are perfectly willing to talk, too.

Writing to HKLM requires elevation, though. Maybe those apps that would like to register extra voices on startup can do so in HKCU. SAPI has a key there, too.

Who wants to meet Sayaka-san?

And now, for something completely different - speech synthesis in Windows (AKA SAPI).

Windows 10 comes with a built-in speech engine. In fact, it comes with two - SAPI 5.4 proper, and SAPI 5.4 OneCore (four on a 64-bit OS). They all coexist side by side. The data files are largely shared.

My specific interest comes from a desire for spoken Japanese language. One can install the Japanese text-to-speech (TTS) voices in Settings, under Time and Language/Speech. Once you do, there are three Japanese voices in the list - Ayumi, Haruka, and Ichiro. Together with the three English voices, six total.

That's the Windows settings, but what about SAPI applications? Turns out, SAPI 5.4 gets only Haruka, while OneCore get all three. So going forward, my interest was limited to OneCore. The more voices, the merrier.

SAPI stores its voice list in the registry - different keys for SAPI 5.4 proper and 5.4 OneCore. Yet if you look at the registry key HKLM\SOFTWARE\Microsoft\Speech_OneCore\Voices\Tokens, you will see seven subkeys. The seventh one is Microsoft Sayaka. Why isn't she present in the list and why can't applications find her?

A dwarf is sitting under a tree...

I've published a package on PyPI! That's a first for me.

DWARF Explorer (dwex for short) is a cross platform GUI utility in Python for visualizing the debug information in DWARF format. It was initially meant for iOS dSYM bundles and Android unstripped native binaries, but runs under Windows, MacOS, and Linux. For completeness' sake, it takes Windows' PE files, too, with the caveat that the primary format of debug symbols on Windows isn't DWARF, it's PDB.

Select from TFVC

More TFS Azure DevOps schema exploration. This time, source control. Specifically, the classic TFS source control, also known as TFVC. No Git this time, that is a discussion for another day.

So I have an innocent desire to run a report off the content of some files in source control. The question is, how are they stored? There are four tables of interest:

Can your ALM do that?

Support for runtime crash reporting and analysis should be a part of the Application Lifecycle Management (ALM).

Now, my exposure to the ALM landscape out there is limited. TFS/AzDevOps - I know it inside and out. Github (including the corporate edition) - moderate experience. GoCD, TeamCity, Jenkins - I have an idea what do they do.

Literacy is overrated

Imagine a table on a report with a boolean, yes/no column that indicates if the user presented a cookie during their web session. What would be a good column header for it?

Why, this text string, naturally:

🍪