-
-
Thumbnail
-
-
-
-
-
-
Inspiration
“The words are right. So why doesn’t the speech feel right?”
That question is the starting point for Delivery. Listening back to a rehearsal can reveal that something feels off, but identifying the exact passage—and understanding what changed—is harder.
We wanted feedback that gives speakers somewhere useful to begin: specific words, an audible comparison, and measurements they can inspect.
What it does
Delivery is a speech review studio that connects audio with the words being spoken.
Upload a recording or capture a take, provide its transcript, and review timestamped findings covering pace, pitch variation, pauses, and energy.
When the transcript matches a text in the reference library, Delivery compares corresponding passages against a reference recording. Other text uses calibrated ranges, with findings marked as lower confidence.
The review brings together:
- Word-aligned transcript navigation.
- Recording and reference playback.
- Acoustic charts and timestamped findings.
- Adjustable scoring weights.
- Exportable reports and persistent run history.
Delivery evaluates delivery—not the quality of the speaker’s ideas. A finding is a measurable difference to investigate, not a verdict on someone’s speaking style.
How we built it
The pipeline combines audio and text: the transcript identifies the words, while the recording reveals how they were delivered.
A Python backend uses PyTorch and torchaudio for MMS forced alignment, alongside acoustic analysis libraries for signal measurements. Word alignment connects these measurements to passages in the transcript.
For reference comparisons, pitch is normalized relative to each speaker’s median, and energy relative to their speech-frame energy. This helps focus comparisons on delivery changes rather than raw voice pitch or recording gain.
FastAPI serves the analysis workflow to a React and TypeScript interface. The dashboard connects transcript navigation, audio playback, charts, and findings. A local SQLite journal preserves reports, parameters, and processing activity.
The project includes Docker setup, optional CUDA acceleration, and a public benchmark containing 186 recordings across six texts.
Challenges we ran into
The hardest problem was deciding which differences deserve feedback.
A slower passage can be intentional. Different readers can deliver the same sentence effectively in different ways. Alignment errors can also affect downstream measurements.
We built controlled examples and evaluation tools to investigate these problems rather than treating a successful analysis as proof of accuracy. Detection recall and false positives across natural readers remain important limitations.
Another challenge was making the results understandable. A chart alone is not enough: speakers need to connect the measurement to words they recognize and audio they can hear.
Accomplishments that we're proud of
We built an end-to-end workflow from real audio input to an inspectable review.
In a saved native-CUDA validation run, the controlled dragging-pace example completed the full pipeline and produced two dragging-pace findings. This demonstrates that workflow on a specific example, rather than establishing general detection accuracy.
We also published a reproducible dataset with provenance and controlled delivery changes, and built run history that preserves the settings and evidence behind each analysis.
Most importantly, the interface lets a speaker move from a finding to the affected words and recording.
What we learned
Useful speech feedback needs more than a score.
Audio and text provide complementary evidence: the transcript tells us where we are, while acoustic measurements describe what happened there.
We also learned to separate three questions: Did the system run successfully? Did it detect the expected change? Does it generalize to other readers? Each needs its own evidence.
What's next for Delivery
Our next priorities are broader reader calibration, additional held-out human recordings, better detection recall, and fewer false positives.
We also want to strengthen microphone-workflow validation and make repeated rehearsals easier to compare.
The goal remains simple: feedback you can hear, inspect, and use in your next rehearsal.
Log in or sign up for Devpost to join the conversation.