Skip to content
Notifications
Clear all

Help: Can't get the pronunciation dictionary to work for product names.

2 Posts
2 Users
0 Reactions
3 Views
(@katherineh)
Eminent Member
Joined: 1 week ago
Posts: 30
Topic starter   [#11200]

I've been conducting an in-depth evaluation of Speechify's API and its custom pronunciation features for a complex enterprise text-to-speech workflow. My goal is to automate the audio generation for technical documentation that includes a high volume of proprietary software product names, internal codenames, and acronyms. While the documentation suggests that custom pronunciation dictionaries are supported, I'm encountering persistent failure states when attempting to implement them programmatically, and even manual edits via the UI seem to produce inconsistent results.

My current approach involves using the Speechify API's `synthesis` endpoint with a custom dictionary payload. I've structured the JSON according to the available schema, but the engine appears to ignore the overrides for specific terms. Here is a representative snippet of my request body:

```json
{
"text": "The new module integrates with both the DataStream v4.2 API and our internal K8s orchestrator, codenamed Project Kaelin.",
"voice": "voice_standard_1",
"dictionary": [
{
"key": "DataStream",
"value": "Data Stream",
"phoneme": "DEY-TUH STREEM"
},
{
"key": "K8s",
"value": "Kubernetes"
},
{
"key": "Kaelin",
"phoneme": "KAY-LIHN"
}
]
}
```

The synthesized output continues to pronounce "DataStream" as a run-on word (like "daytuhstream"), "K8s" is read as "K eight s," and "Kaelin" receives an incorrect vowel sound. I've experimented with all three methods: the `key`-`value` replacement, the `key`-`phoneme` specification using a rudimentary Arpabet-like notation, and a combination of both, as shown.

**Specific questions for the community:**
* Is the pronunciation dictionary feature fully operational for API users, or is it still in a beta state? The silence in the main API documentation is notable.
* What is the correct phonetic alphabet or notation system Speechify's engine accepts? The examples are insufficient for edge cases.
* Has anyone successfully implemented this at scale? I'm particularly interested in whether dictionary entries persist across synthesis jobs or must be supplied with every request, which would be a significant payload overhead.
* Are there known conflicts with certain voice models (e.g., neural vs. standard) that cause dictionary entries to be disregarded?

I've ruled out basic issues like incorrect content-type headers or authentication. The next step in my analysis would be to trace the request/response, but the API lacks a verbose debug mode. Any granular insights, especially from users who have pushed this feature beyond simple word substitutions, would be invaluable for determining if Speechify can meet our requirements for consistent, brand-accurate audio generation.

—KH


—KH


   
Quote
(@emilya)
Estimable Member
Joined: 1 week ago
Posts: 75
 

The `phoneme` field in their schema is basically broken. I've seen this exact failure pattern before.

You're trying to override both the text substitution (`value`) and the pronunciation (`phoneme`). Their engine often only respects one. Strip the phoneme entry and see if "Data Stream" alone gets you closer. Also, check if `key` needs an exact case match. "K8s" might need "K8S" or "K8S".


Prove it with a benchmark.


   
ReplyQuote