prathoshap/vagdhenu: Sanskrit chant by routing the text through Kannada

The text goes through Kannada script to reach the model

The most consequential design decision is a piece of routing. The backbone is a flow-matching diffusion transformer doing mel infilling, around 337 million parameters, with no native duration head and no native pitch head. Its training data does not contain Sanskrit. So the text frontend converts input before the model sees it: Devanagari to a transliteration scheme to Kannada script, with the stated reason that Devanagari triggers a schwa-deletion rule that belongs to Hindi and misrepresents how Sanskrit is pronounced. The frontend also applies internal visarga sandhi across four named categories, resolves homorganic nasalisation, handles vocalic liquids, applies rules for sentence-final punctuation, and detects metre by counting syllables into long and short groups. The author describes this frontend, in a file named for text preparation, as the most reusable piece of the system, which is the right thing to single out. You drive it with a shard file listing identifiers, metres, verse lists, seeds and output names, and the shipped sample renders a verse named for the metre it detected:

bash scripts/setup.sh    # torch+cu121, deps, BigVGAN, and downloads weights -> models/
# render a Devanagari verse (+ meter) to a chanted wav:
python src/render.py --shard examples/sample_shard.json --results /tmp/res.json --outdir out
# -> out/sample_anushtubh.wav

Because each item carries its own metre and its own seed, the batch is reproducible per item rather than only as a whole.

The stock vocoder fails on long vowels, so it was replaced

The vocoder is documented as a mandatory substitution rather than an upgrade, and the reason is a specific failure rather than a quality comparison. The audio decoder is a recent version of a neural vocoder from a hardware vendor, fine-tuned on the mel features produced by an earlier vocoder family. The original vocoder, the documentation says, shivers on long vowels. That is the precise failure that matters here, because Vedic chant is built on sustained vowels, so a decoder that wobbles on long ones would undermine the entire premise regardless of how good the acoustic model was. The mel features are still produced by the original family, which is why that package remains a pinned dependency even though it is no longer the thing making the sound. It is a small example of a negative result being documented precisely enough to be useful to anyone else building a decoder for a similar language.

Prosody is not designable, so the levers are a clip and a fine-tune

The system is candid that it does not control what it most needs to control. The acoustic model's content fidelity is described as beyond question, while its prosody is called text-driven rather than designable, meaning the model infers melody and pacing from the text instead of taking instructions about them. Two working levers are named. The first is the reference clip, which carries voice, ornament and pace together, applied through something called the half-reference rule. The second is a voice-steering fine-tune of the model. What the visible page does not do is define the half-reference rule, which is left to a section of a technical report described elsewhere in the file as scrubbed. The author labels this the central architectural finding of the project, and then defers it, which is a reasonable choice for length and an unhelpful one for a reader trying to reproduce the result.

The layout block omits the training directory

The documentation gives a six-line tree of the repository with a one-line gloss for each: source for the frontend, meter detection, inference and a post-gate, a pipeline directory for data preparation and quality control, a demo, documentation, examples and setup scripts. The actual repository has more than that. There is a training directory, which is the single most important omission on the page given that the project describes a data-prep path of cutting, pairing and training and a case study of tens of thousands of rendered verses. There is also a requirements file at the root, which the tree does not mention. The documentation directory is described as holding a scrubbed technical report, so the word is doing honest work: whatever was removed before publication is not recoverable from this repository.

A dependency is pinned to a commit hash because the published package crashes

The requirements file is commented like a lab notebook, and the most valuable line explains that the core text-to-speech package is not installed from a package index at all. It is a fork of a model, and it is installed from a source host at one exact commit, with the reason given inline: the published package of the same name is different code and its inference entry point crashes. Two consequences follow. Building requires a version control client and network access to that host at build time, so the environment is reproducible only as long as that commit is reachable. And the comment that the torch packages are installed separately by the setup script, with the validated versions recorded in a comment rather than in the dependency list, means the single command most people will try does not produce a working environment on its own. A second, separate dependency file exists inside the demo directory, which is consistent with a hosted GPU space needing different pins and is documented nowhere.

The quality claims rest on one listener and absolute wording

The evidence section is a single figure: a mean opinion score of about 4.6, attributed to an expert listener. One rater, one system, no comparison set, no test protocol described. Next to it sits a stronger claim, that conjuncts including retroflex aspirates render correctly in every case, and that this is the class earlier architectures could not handle. Given that the rendered output listed includes sixteen thousand verses of a major scripture, the claim is plausible on its face, but the page offers no measurement behind the word completely, and no error count. The citation section is a promise rather than a citation, stating that a BibTeX entry was added alongside an arXiv report, and no arXiv identifier appears on the page. There are no tagged releases either, so there is no version to cite even informally. For a system with released weights on a model hub, that is the one gap worth closing first.

One speaker, one voice, and three licences in one distribution

The intended-use statement is short and deserves to be read in full rather than skimmed. This is single-speaker synthesis of sacred recitation, for chanting, study and accessibility, the voice is the author's own, and the request is not to impersonate. For a voice model that produces religious recitation, that is the correct framing and it is stated plainly rather than buried in a model card. Licensing is more layered. The project's own code is under Apache-2.0, matching both the repository metadata and the licence file. The framework it builds on is under MIT. The vocoder weights are redistributed under the hardware vendor's terms. So there are three licences in one downloadable artefact, and only the first is the project's; anyone redistributing the weights needs to satisfy the other two separately. The text of one scripture is separately acknowledged to a named institution in the city where the work was done.

Editorial conclusion

This fits someone producing Sanskrit recitation for study or accessibility who already has a CUDA machine and is willing to run a setup script. The routing trick is the part worth understanding before anything else, because it explains both why the system works and where it will not generalise. Two things to check before you rely on it: the dependency on a pinned fork commit means the build needs network access to a source host and will not float, and the evaluation evidence is a single expert listener's rating rather than a corpus measurement, so treat the quality claim as a demonstration rather than a benchmark.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. prathoshap/vagdhenu on GitHub
4. README