Oh, cool! Yeah that seems like a good application.
The current Storyteller alignment algorithm actually does do just that! We use Whisper to transcribe the audio to text, and then use error-align[1] to align on the text.
There are a few disadvantages to this approach:
1. Whisper only supports ~25 languages, and only about 10 of those very well. We want to support more languages, and Massively Multilingual Speech supports "1000+"
2. Whisper's timing outputs are not very good. We want to do word-level highlighting, like in the demo at the top of the post, but in order for that to be a good user experience, those timings need to be very precise. Much easier to do that with CTC!
CTC Viterbi is the tried and true forced alignment algorithm for good reason. It's not really that it's heavier duty than running Whisper and aligning on the output. Rather, it's like you stop Whisper early, before it does the final step of actually producing text, and step in and say: take the data you just calculated and use it to produce _this_ text, specifically. And then, since it produced _your_ text, you don't have to do anything else, you just use the timestamps directly.
The only reason Storyteller never used it in the past is because I couldn't come up with a good way to do the boundary search I describe in this post! This is super important for books in a way that it may not be for your oral reading transcript use case, because chapters can be (and often are) out of order between the ebook and audiobook. But once I worked out the n-gram RANSAC approach, it became much more tenable.
Thanks for the reply and explanation. It is very helpful. Our app is old, started well prior to whisper. But we have updated it regularly as useful tech came along. I will check out CTC Viterbi and error-align !
slightly tangential but the podcast app Snipd has a lot of text to speach re-sync alignment to recover from inserted advertisements so it might be worth exploring if they have published any details
Viterbi and Needleman-Wunsch are essentially the same algorithm, developed in parallel for two different domains! The Viterbi formulation of the algorithm is the one usually applied to signal decoding, since that's what it was originally designed for.
Well, first of all, lots of people specifically do use this because they have print disabilities or neurodivergence that makes it challenging to read long stretches of text.
Also, disability isn't binary? Some people have an easier time reading text than others — is your argument that books should remain less accessible to those people for whom it's harder because you don't personally feel like they should need it?
And then there are _lots_ of people that just enjoy reading this way. Audiobook production is its own art form, and many people like experiencing the text and the audio together. For some people it helps them focus in a noisy environment, for some people they find they can read faster with the narration, and some people just enjoy it.
Every single time I post about Storyteller, there are multiple people in the comments insisting that this shouldn't exist because no one should ever consume books differently from how they do. I don't understand it, honestly. If you don't want to read books this way, that's totally fine! You can even still use Storyteller — it works great with plain EPUBs. Why the need to make others feel bad for the way they engage with stories? The world is a better place if more people read more books — discouraging people from reading books in the way that feels pleasant and accessible to them makes the world worse.
I think if you feel compelled to instruct people you don't know to "stop their current habits" because you don't personally understand their needs or wants, perhaps you should reconsider your current habits, yourself.
My guess is, like many accessibility tools, it will vary by person! The Storyteller apps don't actually support this multi-level granularity demostrated in the demo here — until this iteration of the alignment algorithm, the timing wasn't good enough for word-level highlighting. So currently we only do sentence-level highlighting.
When we do roll out multi-level granularity, it will indeed be something that you can configure yourself, including how each level is indicated (e.g., you might want to set a background color on the sentence and underling the word) and whether a each level is indicated at all!
The "spread out" highlighting is a really neat idea, I don't think I've heard that suggestion before!
Sure! Some people have print disabilities like dyslexia and neurodivergence that makes reading text for an entire novel-length book challenging. Other people are perfectly competent print readers, but find that they enjoy having their book read to them. Audiobooks are their own art form, and it's nice to be able to enjoy them alongside text.
"Immersive reading" seems to be the industry term for this feature — I used it here because I though it was most likely to be recognized by a wide audience. Personally, and within the Storyteller ecosystem, I call it "readaloud," which I think is at least a little bit more useful of a phrase.
Hm, I don't know what you're referring to. Is the text too small for you? I wrote the blog post on FF for Linux and FF for Android, and I didn't need to zoom in to review it, though some of the graphics do definitely end up with pretty small text on mobile.
It is a small font within a small column which wastes like 60+% space of a screen, and I use tabs, eh? Tabs are not windows, I will not resize my browser just because of one single tab.
This is a horizontal 24" 1920x1200, not a fucking phone.
so I respectfully plead for you and everyone else to forget those ridiculous horizontal margins.
Almost everyone who uses the readaloud features in Storyteller speeds up the audio playback quite a bit, often 2-3x, so that it matches their reading speed better. The Storyteller apps let you set different playback speeds for pure audio playback vs readaloud, since being able to see the text usually makes it easier to listen faster!
I supposed I should add: it's also, obviously, fine if this just isn't for you! Lots of people get a lot of value out of audiobooks (e.g., I really like to listen to audiobooks in the car or while running), but like to switch to reading when it's an option. And lots of people find readaloud super valuable, whether because they have a print disability or neurodivergence that makes reading challenging, or just because they like the experience of being read to. But lots of people are in neither of those groups!
That is actually the exact use case that I originally built Storyteller for! I wanted to listen to my books on long runs, and then switch to reading when I got back.
The Storyteller mobile apps have great support for this, I think. They have fully fledged audiobook players and ebook readers, and you can switch between the two with one tap. And then of course you can also double tap on a sentence and start playing from there, with the app highlighting the currently read sentence.
I took a week of from work recently to reimplement Storyteller's forced alignment algorithm. Storyteller[1] is an open source, self hosted platform for creating, managing, and reading/listening to "readaloud" books — books that have audiobook narration built in and can highlight each sentence (and/or word, with this new algorithm!) as it's read aloud. Forced alignment is the process of determining where each piece of text starts and ends in the audiobook.
Anyway, I am really pleased with how the new algorithm turned out! Hopefully someone else finds it interesting as well.
Wow I didn't even think about just using on device AI.
I'm going to set this one up and try it with kokoro which has the most natural for small size that I've seen. Wonder if the paperwhite 12th Gen can handle it.
And also setup the main repo for when I have the real audio book. Thanks!
I tried running Kokoro on my iPhone XS (several years old), and it was slower than real-time. So, i wouldn’t expect it to be usable on a Kindle. But if you find a solution, please let me know.
This is excellent! I wanted this. I had noticed that Kindle had limited feature like this for certain books that support audiobooks. I had tried this style of reading with audiobook and ebook without a any automated sync, but hadn't pursued it. This looks cool. :)
Thanks! We're improving it all the time — we're working on big new releases ("v3") for the web app and mobile apps. There's a Discord server linked in the docs if you ever need any help out want to chat!
Any plans to offer a way to generate audio books on demand. like if i set kokoro, a book auto imports, it can make the file for me for the whole book after some time of local gpu work?
The current Storyteller alignment algorithm actually does do just that! We use Whisper to transcribe the audio to text, and then use error-align[1] to align on the text.
There are a few disadvantages to this approach:
1. Whisper only supports ~25 languages, and only about 10 of those very well. We want to support more languages, and Massively Multilingual Speech supports "1000+" 2. Whisper's timing outputs are not very good. We want to do word-level highlighting, like in the demo at the top of the post, but in order for that to be a good user experience, those timings need to be very precise. Much easier to do that with CTC!
CTC Viterbi is the tried and true forced alignment algorithm for good reason. It's not really that it's heavier duty than running Whisper and aligning on the output. Rather, it's like you stop Whisper early, before it does the final step of actually producing text, and step in and say: take the data you just calculated and use it to produce _this_ text, specifically. And then, since it produced _your_ text, you don't have to do anything else, you just use the timestamps directly.
The only reason Storyteller never used it in the past is because I couldn't come up with a good way to do the boundary search I describe in this post! This is super important for books in a way that it may not be for your oral reading transcript use case, because chapters can be (and often are) out of order between the ebook and audiobook. But once I worked out the n-gram RANSAC approach, it became much more tenable.
[1]: https://github.com/corticph/error-align