#TTS Custom Dictionaries not supporting special characters

1 messages · Page 1 of 1 (latest)

merry cypress
#

Hi Cartesia team,

I’m currently testing Pronunciation Dictionaries for TTS and I’ve run into an issue where some entries are not being applied correctly. It seems that entries containing certain symbols may not be matching when they are in the text pronunciation to replace.

For example, the following entry works as expected:

  "text": "lpa",
  "alias": "<spell>L</spell><spell>P</spell> little <spell>A</spell>",
  "pronunciation": "<spell>L</spell><spell>P</spell> little <spell>A</spell>"
}```

However, a very similar entry does not work:

{
"text": "lp(a)",
"alias": "<spell>L</spell><spell>P</spell> little <spell>A</spell>",
"pronunciation": "<spell>L</spell><spell>P</spell> little <spell>A</spell>"
}```

I’m seeing similar behavior with other entries that include symbols. For example, the following also do not seem to work:

  "text": "≥2%",
  "alias": "at or greater than 2 percent",
  "pronunciation": "at or greater than 2 percent"
}```

or

{
"text": "gd+",
"alias": "<spell>GD</spell> positive",
"pronunciation": "<spell>GD</spell> positive"
}```

tropic pikeBOT
#

Hey @merry cypress,
Thanks for reaching out to Cartesia Support and for flagging!
Currently, this is expected behavior as we sanitized symbols like > and < as malformed SSML tags. I have passed this feedback to the team; however, I would recommend prompting your LLM to convert these symbols into words at the LLM level for now.

merry cypress
#

Thanks for sharing! For some of these words with special characters, we could do extra cleaning beforehand (like >= 2%), but for others, given our combinations of words in our desired dictionary and special characters, having a cleaning step to remove certain symbols is not a possibility.

In that case, would you recommend us to build our own pronunciation dictionary in house to pass the custom pronunciations?

tropic pikeBOT
#

Hey @merry cypress, I have escalated this to the TTS team as this can be resolved via a fix to our normalizers so that symbols aren't sanitized, which is why the pronunciation dictionary isn't working as expected.
In the meantime, yes, building an in-house preprocessing step that applies your custom pronunciations before sending text to our API would be the best workaround. You could do a simple find-and-replace on the text (e.g., replacing "lp(a)" with "LP little A") before it hits our TTS endpoint, which would bypass the dictionary entirely.