I made a little audio speed calculator

evanhahn.com2025年12月03日 00:00

I was recently listening to an 8-hour-and-51-minute audiobook, and wanted to know how much time I’d save if I listened to it on 1.5× speed.

This math is easy enough; divide 8 hours and 51 minutes by 1.5 to get the new duration: 5 hours and 54 minutes. But I also wanted to:

  1. See the final duration along with the time I’d save (with some simple subtraction).
  2. Compare different speeds. How much more time would I save with 1.6× speed, for example?
  3. Enter the time in plain English: “8 hours 51 minutes” instead of “531 minutes”.

So I built a little web tool to do this: the playback speed calculator. You enter a time in English, and you get a big table showing the duration and savings for 1.1× speed, 1.2× speed, and so on.

Did LLMs help?

This is the kind of software modern LLMs can “one-shot”. You give them a description in plain English, and they produce all the code. And indeed, this was how I built the first version! I prompted an LLM with the app I wanted, and it mostly worked. I had to make a few tiny tweaks to fix a few tiny errors, but it was totally usable in this version, and significantly quicker than scaffolding it myself.

But I wanted to turn this prototype into something I could share with others. I didn’t want it to be a buggy mess! Unfortunately, there were a number of things the LLM failed to do in the first version:

  • It made a basic accessibility mistake, failing to associate the <input> with any label.
  • The code for parsing inputs had a number of inefficiencies.
  • It had very simplistic handling of error cases.
  • The tool had a very generic generated-by-LLM look. I don’t know exactly how to describe it, but it had the vibe that it was not human-made.
  • No dark mode support.
  • No thought for users who have JavaScript disabled.
  • A number of other little things needed fixing, such as using the “×” symbol (&times;) instead of the letter X.

The LLM also made a number of decisions I wouldn’t have made that weren’t necessarily errors. For example, it showed milliseconds instead of rounding seconds, and it added hover states I wouldn’t have. I can’t fault it for that—I wasn’t explicit about what I wanted in the instructions—but there were a lot of things I went back and corrected.

In fact, I changed almost all the significant code the LLM wrote. For example, the code that parses “4 minutes 20 seconds” looks very different. I kept bits and pieces of the LLM’s approach, but it’s pretty substantially different in my version—enough to say I completely rewrote it. This was true for almost all of the LLM’s work.

Did the LLM make me more effective? It was definitely faster to build the prototype. I’m not sure it was faster for me overall, though, because I spent a lot of time correcting the code—either due to unambiguous errors or due to my persnickety preferences.

A little app for me

This was a nice reminder that it’s fun to build software just for yourself.

I didn’t have to worry that I was disappointing my users, because it’s just for me! I knew exactly what I wanted and I built it.

I also thought about how long it took to turn the prototype into something I considered finished. If I wanted it to be usable with a few rough edges, this could have been done and deployed in under 10 minutes. But I wound up spending a few hours on this simple tool! This is partly because “productionizing” usually takes the longest, and partly because I was particular.

When I’m developing software in a professional context, I try to relax my perfectionism most of the time because that attitude clashes with deadlines. But it’s fun to try to do it “the right way” sometimes…at least by my personal definition.

If you’re listening to a long audiobook and want to know whether you should listen on 1.2× or 1.3× speed, I hope you’ll give my little app a try.