I went the route of handling epub first (really, anything pandoc can convert to epub) on ebookaloud, and it took quite a few iterations to get consistent parsing across a wide corpus of test documents.
My experience is that gathering and testing with that corpus was about 30% of the overall effort. I have not yet gathered the motivation to tackle pdf: it’s more of a layout format than a text format. Not just tables but multi-column layouts and similar oddities leave a pile of imperfect heuristics in their wake.
Multi-lingual support is even worse. I was working with arabic script in pdf years ago and they don’t even capture the encoded text, just rendering instructions due to the high number of ligatures. I don’t know if things have improved since then.
Thanks! Currently, I'm using Gemini TTS and Kokoro TTS as a free option. Kokoro is fast and I can run it on my own server, but I'm not using it as a standard yet because Gemini supports more languages and has more voices available. But text-to-speech processing is the biggest bottleneck at the moment.
There are two parts to the processing. The processing of the document itself is done on your OpenAI/Codex subscription. Additionally, you have to submit an API key for the text-to-speech processing. There you can use a Gemini key or an OpenAI key.
reply