Tsuzuri: Building Another Subtitle Editor in the AI Era — Is It Reinventing the Wheel?

contact@aotoki.me (Aotokitsuruya) — Wed, 30 Sep 2026 00:00:00 +0800

The subtitle tool that has impressed me most recently is What’Sub, built by the YouTuber 壹加壹. In most situations, whenever someone needs to work on video subtitles, I simply recommend it.

However, about half a year ago, when a friend asked me “Is there a way to make transcripts?” and “Can we translate those transcripts?,” there was always one precondition: “no cloud services.” That ruled out most of the options on the market.

One great thing about this era is that AI lets anyone customize tools for their own needs, and Tsuzuri was born against exactly this background.

Privacy First

My friend first brought up this need because his girlfriend is studying in a psychology-related department. Most of what she has to handle contains personal information, and in the past, transcribing that much audio was not easy.

But in the AI era, we also have access to “open-weight” models, which gives us many different choices. For example, MediaTek’s Breeze-ASR-25 recognizes Taiwanese speech and accents very well, and many projects already use it.

At first, I found some open-source GUI tools for my friend, but they were not convenient to use. Since I use MacWhisper myself, I never had this problem, so we eventually settled on the command-line tool of Whisper.cpp. Fortunately, my friend had no major difficulty using this kind of tool.

The later translation need came from the same situation. I’m not sure why, but academic topics at school also require English translation. I started with LM Studio plus a simple Python script, trying to move the whole process from fully manual to semi-automatic.

The hardest part of doing all this completely offline is that my friend only has a laptop with an RTX 3050 4G VRAM graphics card. Most language models on the market are simply out of reach for his laptop, and this is probably much closer to the real-world situation.

It Actually Helps

Tsuzuri was born last week. My friend told me he wanted to write a tutorial to teach people around him how to use the solution I had given him, because quite a few people at school and among students have similar needs.

My immediate reaction was “Are you seriously going to teach everyone to use a Command Line tool?” I also reminded him that when I built the translation tool, I had told him “This is just a proof of concept; if it works well, I’ll make a version with a graphical interface.”

When he told me he wanted to share it with others, my instinct said I could no longer put the “desktop version” option on hold. Anthropic happened to offer a usage reset and $250 in cloud credits, and together with the Mid-Autumn Festival long weekend, it was the perfect time to build it.

The real challenge is that with my friend’s laptop, I already know the hardware well and can help troubleshoot online directly, but once it spreads to more people, the problem becomes much harder.

You Are the Minority

Having an AI subscription, a decent graphics card, and so on varies from person to person, but among engineers and in tech-related industries, we may take these for granted — a feeling that “everyone has roughly the same setup.”

When you widen your view to more fields and industries, there are indeed a few people trying to do something with AI, but many more have barely used it, or work only with free plans and whatever devices they already have. Once you factor in all these real-world constraints, what can be done is often harder than expected.

Take a $20 subscription: based on Taiwan’s 2027 minimum wage, it costs about 2% of a monthly salary. A $100 subscription takes around 10%, which is not necessarily a “necessity” for most people. If you want to be fully offline, graphics cards have also become much more expensive because of AI, which makes them hard to consider as an option.

That’s why I took on the development of Tsuzuri, while my friend handled the actual usage and validation. We used about three days of the Mid-Autumn Festival holiday to build a tool that cuts my friend’s subtitle processing time in half.

In the design, we had to consider complex issues such as CUDA being hard to install and GitHub Actions needing to precompile CUDA. If a user has an AMD graphics card or no graphics card at all, can they still use it properly? All of these factors have to be built into the software design.

Whether it was the past “bookkeeping app frenzy” or “input method frenzy,” I think AI is a great tool for solving personal problems. But once you expand to more users, the problems and aspects to consider become very different. This is one of the values of professional engineers in the AI era. I’ve previously shared why I don’t think expertise will be replaced — building for one person and building for a thousand people require different ways of thinking.

Defining “Easy to Use”

Most of the time, I just put the tools I use myself on GitHub, and there are rarely real users. This time I was handling my friend’s needs, so my feature baseline was “whether my friend finds it smooth,” and I didn’t plan to accept requests from anyone else.

In the AI era, modifying and adjusting software is easy, but handling “requirements” is still hard. Take our Mid-Autumn holiday as an example: on the first day, I delivered a version with the basic features and made several changes so the software could start editing subtitles. The next day, I received about 30 requirements from different scenarios, all real and all affecting usability.

If we let every user submit requests, we would quickly end up with A finding it easy to use while B finds it hard. Finding the intersection among a broad user base’s needs is a common challenge in software development. Great software products usually get there by relying on the taste of a few key users, or through careful adjustment and coordination. This is why I don’t think AI will let homemade tools replace commercial software services — something that one person finds easy to use and something most people find smooth are different concepts.

Over these few days, my friend and I dealt entirely with “how to make the workflow smooth,” and many of those problems probably come from historical baggage.

Taken for Granted

Much of the design of subtitle editors comes from a time when technologies like speech recognition (ASR, Automatic Speech Recognition) did not exist. They were designed for humans to “listen” and then “type,” so many parts don’t flow well with the way subtitles are edited today, and different software hasn’t learned from each other’s strengths.

Because our starting point is “speech recognition,” our subtitles mostly don’t exist beforehand; they are generated directly from video or audio files. So a subtitle editor’s “auto-pause playback” may not be that useful. The subtitles already exist, and the task shifts from “input” to “review,” so these mechanisms need some adjustment.

Since the goal is review, there is usually more than one version of the subtitles, structured like this:

(Draft) Speech recognition version
(Backup) First revision
(Current) Version in progress

Subtitle software doesn’t have a “compare” design, but in Tsuzuri it’s a default capability. After each edit, it shows the difference from the previous version, which makes “review” more effective without going back and forth to check the previous progress. Re-translating a block or re-running speech recognition on a time range serves a similar purpose.

Beyond that, there was another requirement I found very interesting.

When editing subtitles, there is usually a video preview alongside. According to my friend, subtitle software can’t “detach” the preview outside the window. But most people now likely have multiple monitors, so being able to detach it actually enlarges the subtitle editing space, while letting the preview sit on a separate monitor for a better view of how it looks.

There are many other design adjustments based on editing habits that I won’t list here, but it’s precisely because of AI that we could build such a tool so quickly.

Rethinking

I think this was a very interesting development experience. In the past, it was hard to imagine this “build it whenever I need it” approach — an engineer’s time at that cost was simply not worth it, but the AI era made it happen.

I remember that I started keeping more careful accounts because the scripts for bookkeeping took a lot of time to handle, but with AI I could get them usable very quickly, so I started bookkeeping seriously — those “almost there” small things finally had a low-cost way to be solved.

For Tsuzuri, the tokens spent over about three days of development, converted at API prices, might come to several thousand US dollars. But as a one-time cost in exchange for my friend processing subtitles twice as fast (based on the current real-world subtitle testing), it’s well worth it in the long run. It also means my friend has more time, or can spend that time on something more useful, which is very meaningful.

This is how we always hope new technology develops. Even though AI still can’t work reliably in many places where humans “hope” to automate, at least we can see that future, and I think it’s well worth looking forward to. The most at risk are actually those who still hold the mindset of “doing repetitive work by hand,” because the reason we want new technology is to let everyone move toward more creative tasks; holding onto that mindset makes it easy to be replaced by new technology.

Likewise, being able to create our own tools in the AI era doesn’t necessarily mean we’re always reinventing the wheel; instead, we can make finer distinctions for different situations.

Writing code by hand doesn’t necessarily mean doing repetitive work. Although this project was developed entirely with Claude Code, the knowledge I gained from noticing subtle differences every time I wrote code by hand was applied well throughout the development. It’s precisely because I’ve tried many different approaches that I can rethink which design fits best when new problems arise.