免費有聲書創作工具：我如何打造能朗讀任何公有領域書籍的工具

You click a book. Two seconds later a voice starts reading it to you — page one, chapter one, start to finish. No signup, no payment, no download. I built that this month, and this post is the engineering story: where the books come from, why the first version read the wrong ones, and the three bugs that made it lie to people.

Where the books actually come from

The app searches two free sources in order. First Project Gutenberg (via the Gutendex API) — real, complete, proofread public-domain books. If nothing matches, it falls back to OpenLibrary’s full-text scan archive (the Internet Archive’s scanned copies). All public domain, all free, all legal.

That means classics: Frankenstein, Dracula, Alice in Wonderland, War and Peace. It does not mean Percy Jackson or Harry Potter — those are copyrighted, no free copy exists anywhere, and no honest program can read them. More on that in a second, because it broke my search results badly.

Bug 1: the search that returned 12 lies

My first version worked like this: query the APIs, take the first 12 results, show them. For famous books, fine. Then I searched “long way down” and got back 12 completely unrelated titles — books that merely had the word “down” somewhere. The API (OpenLibrary) returns loosely-related matches when strict matches are missing, and my code just… displayed whatever came back.

The fix was scoring: every result gets a match score computed from how many of the query’s words appear in the title and author, and anything scoring zero gets thrown out. “Long way down” now returns exactly one book — the only thing the free archives actually have for that title — instead of a page of junk.

Bug 2: the book that wasn’t a book

Next fun failure: for that same query, the only full-text “scan” the Internet Archive had was a 2,498-character poem — “It’s a Long Way Down to the Soup Line” by Joe Hill (the labor organizer, not the horror writer). My reader happily narrated all 38 sentences like it was a novel, then stopped.

Now the app measures what it downloaded before it starts. Under 5,000 characters means it’s a poem or a pamphlet, not a book — so it tells you that in plain words and auto-tries the next edition instead of a silent stop. If the short piece is genuinely all that exists, it says exactly that. A program that can’t be honest about limits isn’t smart, it’s just confident.

Bug 3: half of War and Peace

The worst one was invisible. My reader had a length cap — 900,000 characters, silently truncating anything longer. You never got an error. You just listened to half of War and Peace and the ending never came. Doubling the cap and surfacing the numbers (“reading all 315,342 words, ~590 pages”) fixed it: the app states what it’s reading and how long it is.

The audio: human narrators first, machine second

For classics there’s a treat: LibriVox volunteers have already recorded most of them, and those human-narrated audiobooks live on the Internet Archive. The app finds those first — real human voices, chapter by chapter, with auto-advance.

Here’s where I learned that “official APIs die silently.” LibriVox’s search API started returning 404 for every single title — not rate limiting, just dead. Everything that used it fell back to a slow AI-planner path that took ten seconds of nothing before reading started. The fix: search the archive.org librivoxaudio collection directly, rank by exact title match, and keep the slow planner only as a last resort. A click now starts narration in about two seconds.

When no human recording exists, a machine voice reads the text — chunked into parts, with the next part synthesized in the background while the current one plays, so a whole novel reads cover to finish without gaps.

What I’d tell anyone building this

• Never display API results unfiltered — score them or you’re shipping someone else’s garbage.
• Measure the artifact before you serve it. Size, word count, anything. Silent truncation is a bug your users will never report, because they’ll never know.
• Assume every third-party API will die. Have the fallback built before the funeral.
• Tell the truth in your UI. “The archives only have this short piece” beats a confident wrong answer every time.

Try it free at emreguzel.ca — search a classic, click, listen. And if you’re building something similar, I’d genuinely like to hear how you handled the thin-scan problem; leave a comment.

Originally published on my blog. I post new C, Python and AI-agent guides there regularly.