Why this exists
Most ebook libraries are large and underused, because the limiting factor is time to sit and read. Audiobook catalogues cover a fraction of what people already own; they rent access rather than granting it.
What goes wrong when a book is read as a stream
The premise: a book is a structured system
Every one of those failures is the same mistake, so NarrateX starts from the opposite premise. Structure is read on load rather than inferred as it goes.
Validated against real EPUBs, paperback PDFs and multi-book compilation documents rather than against tidy samples.
What works now
A bookshelf shows the folders you choose as a grid of covers, narrowed by genre or search, so a large library is browsed rather than remembered. Everything runs locally; nothing you read is uploaded anywhere. Running on-device costs something worth stating: the voices are not as natural as the large cloud services. That is the trade; for a book listened to over weeks it is usually the right way round.
Architecture you can leave running
A reader you leave running for hours cannot stutter because a UI event reached into the playback core. So that core is a pure domain with no I/O and no framework, inside a four-layer architecture with every dependency pointing inward. Layer boundaries, 100% coverage and a 400-line file limit are enforced by automated architecture tests on every run. That coverage gate covers the whole pure domain, including the chunking, alignment and text-sanitising code that decides how a book is cut up and spoken.
Execution model
Text is processed into structured chunks. Audio is generated and streamed continuously.
Synthesis and playback run concurrently, so narration begins immediately and continues without interruption even in a large book. Everything runs locally, which keeps the system fast, predictable and private.