LORE · Voice engine
Synthetic narration rarely fails by being unintelligible. It fails by being flat — even stress on every word, emphasis in the wrong place, sentences that don’t seem to know what the paragraph is about. Listeners can’t always name it, but they stop paying attention, and in training that is the whole ballgame.
So LORE narrates with voices built from two broadcast professionals who agreed to teach with us — trained on them performing to an audience, and rendered on hardware we run.
Know the tradeoff
ElevenLabs and the rest of that category solved short-form synthesis extremely well. Nothing below is a knock on the technology — it is a list of the places where hours of instruction and a thirty-second creative read pull in opposite directions.
| Hosted voice API | LORE | |
|---|---|---|
| Who the voice is | A stock voice from a shared library, or a clone you upload. Your learners may have heard it selling software last week. | Craig and Randi. Professional broadcast announcers, named, who agreed to teach this material in their voices. |
| Consent and provenance | Depends entirely on what the customer uploaded. The platform cannot vouch for a voice you cloned. | Talent consent on file for every voice, with the reference recordings and the render provenance kept alongside the course. |
| What it learned from | Largely read-aloud corpora — audiobooks and studio reads. The model learns what reading sounds like. | Broadcast voice-tracking: working announcers performing to an audience. The model learns what talking sounds like. |
| Inflection and emphasis | Tuned per request, sentence by sentence. Stress lands where the model guesses, usually mid-sentence. | Trained on long segments, so phrasing carries across a paragraph — the emphasis falls on the word the sentence is about. |
| Consistency across a course | Short-segment training is what makes a narrator drift from sentence to sentence, and separate calls drift further. | One model, one reference, one batch. The bundle is loudness-matched and verified lesson by lesson before anything attaches. |
| Where the narration is made | On the vendor’s servers. Your lesson scripts go with it. | On a GPU we control, against our own model weights. Approved scripts are narrated here, and finished audio stays on infrastructure we run. |
| What you get back | An audio file. Everything after that — hosting, lessons, checks, records — is your problem. | A published course: narration attached to lessons, questions tied to the source, corrections, progress and certificates. |
Why it matters
01
People sit with an instructor for hours. A recognisable, consistent narrator is the difference between a course and a screen reader — and a named, consenting person is the only defensible answer when a safety officer asks whose voice that is.
02
Most open voice models learn from read-aloud audiobooks, and they sound like it. Ours learned from broadcast voice-tracking — professionals performing to an audience, with the energy, variation and conversational cadence that implies. It is the structural reason the output sounds like a person talking rather than a person reading.
03
An audio file is the easy part. LORE carries the whole path: extract the source, draft lessons and questions against it, hold everything at a human review gate, narrate, publish, and record who finished.
04
A manual is often the thing an organisation is least willing to hand to another vendor. Narration runs on our own hardware against our own weights, and the finished audio stays on infrastructure we run. Course writing uses an outside AI model today; running it entirely on our own or the customer’s hardware is in development.
05
Training prose is long, technical and full of citations, units and acronyms. The scripts are written to be heard — and every rendered lesson is checked against its script before it is allowed near a learner.
Side by side
Two lessons LORE built from OSHA 3404, Laboratory Safety Guidance — a public-domain federal document. The script is LORE’s; the voices are Craig’s and Randi’s. Neither clip was touched after it came off the renderer.
“A short task still needs the controls identified in its approved procedure.” Lesson script · drafted from the source, approved by a human
“The booking calendar finds empty equipment; it does not assess hazards.” Lesson script · drafted from the source, approved by a human
Source: OSHA 3404-11R (2011), public domain · professional voice talent · rendered on our own GPU
How it runs
Nothing is narrated until a person has read it, and nothing is published until the audio has been checked.
LORE drafts lessons and questions from the source document and holds them at a review gate. Your instructors read, edit and approve. No audio exists yet, because narrating a draft is how a mistake gets baked in.
Approved lessons queue as render jobs. A worker on our GPU claims them one at a time and synthesises each lesson against the reference recording for that voice — same model, same settings, whole course in one sitting, so lesson sixteen sounds like lesson one.
The bundle is checked lesson by lesson — length against the script, loudness matched across the set, provenance recorded — and only then attached to the published course. A render that fails the check does not quietly ship.
When a standard changes, the affected lessons are re-drafted, re-approved and re-rendered the same day. Nobody has to be brought back into a studio, so keeping narration current is a decision about accuracy and nothing else.
Send the manual you’d start with. A pilot is one document, a small group of learners, and a few weeks.
