voices/libri_male_6209.json is now voices/daniel.json. The model repo keeps the
LibriTTS-R reader ids โ renaming there would break every client pinned to the
published bundle โ so the catalog carries both: `remote` is what is fetched,
`file` is what it is called on disk.
The old stems are retired so they are deleted rather than discovered a second
time as "Libri Male 6209", and aliased so a caller that pinned one still
resolves to the voice it named.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0138DB6F6YxWtYWy7WNaLAsU
Dropping the catalog entry only stops new installs from fetching it: every
deployment that already ran keeps voices/female.json on disk, and
discover_voices names whatever it finds, so Maya would have come straight back
as "Female". Retired stems are therefore deleted at startup and skipped if the
delete cannot happen (read-only layer, mounted volume).
The default voice becomes Noa, and "Female" from a v2 client now errors with
the current names instead of resolving to a withdrawn speaker.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0138DB6F6YxWtYWy7WNaLAsU
Ignore sparse nikud, and split partial nikud between front endsโ
Phonikud spells a Hebrew word out of its points, so a word handed to it
without them comes back as consonant soup: ืฉืืืฉ -> สหlส. The Hebrew branch
routed the whole segment through it whenever *any* mark was present, so one
shuruk dot in ืืฉืืืึผืช was enough to mangle a paragraph that Renikud would
have read correctly.
A word now counts as vocalized only if it carries a vowel point and more
than one mark overall โ short words excepted, since ืึนื is fully specified
by its one vowel. Everything else is stripped and goes to Renikud. When
both kinds are present the text is split into runs so a properly pointed
word keeps its reading while its neighbours keep Renikud.
Also ship Russian in the serverless image. RUAccent/RUPhon go in before the
serverless set so onnxruntime-gpu still wins the wheel collision, torch
comes from the CPU index (the front end runs on CPU anyway), and the ~1 GB
of weights is warmed at build time rather than on a cold worker's first job.
Co-Authored-By: Claude Opus โฆ
Install onnxruntime last so the GPU wheel is not clobberedโ
The Space logs said "onnxruntime has no CUDA provider", which is why the
probe kept reporting cpu on ZeroGPU hardware. renikud-plus depends on
`onnxruntime` (the CPU build) and we ask for `onnxruntime-gpu`; both wheels
install into the same onnxruntime/ directory, so whichever pip writes last
wins. With the GPU wheel first in the file, renikud-plus's CPU wheel
overwrote it and CUDAExecutionProvider disappeared.
Confirmed in a clean linux/amd64 container:
gpu installed last -> [Tensorrt, CUDA, CPU]
cpu installed last -> [Azure, CPU]
Move onnxruntime to the end of every requirements file. The Docker image
happened to land the right way round already, so this is a no-op there โ
which is exactly the problem, so the build now asserts the provider
survived rather than printing it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0138DB6F6YxWtYWy7WNaLAsU
