Why StoryFolder 0.4 is faster: native builds, GPU acceleration and a rebuilt interface
StoryFolder —
Part of: StoryFolder 0.4: AI Autofill, local transcription, and an assistant that can see your library
Last updated: 2 September 2026.
StoryFolder 0.4 is faster, and the interface is significantly more responsive. The app draws through your graphics hardware instead of compositing in software, the shot board draws only the cards your screen can show, the heavy work runs in a separate process so the window never waits on it, and on Apple silicon the app, that process and the speech engines are all native builds. The features riding on top of this are in the StoryFolder 0.4 release notes. This page is about what changed underneath them.
What makes the interface more responsive?
Hardware acceleration is on, so blur, transforms and animation are composited by the GPU instead of being redrawn by the processor every frame. Anything that moves in front of a modal or a scrim is now the graphics card's job.
The shot board is the other half of it. The board measures its own grid, works out which cells your viewport can show, and draws those. Scrolling a board of several hundred shots costs about what scrolling a board of twelve costs, and a card's thumbnail and fields are resolved as that card is drawn. Following the playhead, jumping to a search result and dragging a marquee are all computed against the scroll position, so they reach shots that are not currently drawn.
The library list got the same treatment from the other direction. A video row carries a word count for its transcript rather than the transcript itself, so scrolling a large library no longer reads every segment of every transcript to show you a number. That is what makes search across folders, collections and quick filters something you can type into at full speed.
Is there a native Apple silicon build?
Yes. On an Apple silicon Mac, the app, the background worker and the speech engines are all arm64 builds, with nothing running under translation. Intel Macs and Windows x64 each get their own build.
They have to be separate builds, because the parts that are not JavaScript cannot be cross-built. The speech recogniser, the speaker engine and the database binding are per-architecture artifacts, and each one is produced on a machine of that architecture and refuses to build if the wrong one is present. That is why the install page hands you a specific download for your machine, and why the site works out which Mac you are on before it offers you a link.
One thing worth knowing if you have been running StoryFolder on an M-series Mac for a while: an installation that was set up as the Intel build keeps updating as the Intel build. The updater is deliberate about this, because handing an Intel installation arm64 code under the same filename would be silent, unrecoverable breakage. Moving to the native build is one download.
Does the GPU do any of the transcription work?
On Apple silicon, yes. The whisper.cpp build we ship for that architecture has Metal compiled into it, so the graphics hardware does the work of transcribing.
The Intel and Windows builds are compiled to a conservative instruction-set baseline instead, with no AVX or AVX2. That costs real transcription speed and buys something worth more than the speed: the same binary runs on an older processor, and on an Apple silicon Mac still running the Intel app through translation, without failing on an instruction the machine cannot execute. Correctness over speed is the right trade for a feature you cannot debug from where you are sitting.
What is in the speech stack, and where does the audio go?
All of it runs on your machine, on audio pulled from the file already on your drive. Nothing is uploaded to be transcribed.
Transcription is whisper.cpp 1.9.2, spawned as its own process, with eight models across four sizes and a multilingual small as the default. Speaker identification is sherpa-onnx running pyannote's segmentation 3.0 model alongside a speaker embedder, natively in C++, with no Python, no PyTorch and no GPU required. In front of both sits Silero voice activity detection, which keeps the recogniser from running inference over stretches with no speech in them. That is the mechanism that stops a music passage coming back as invented dialogue.
We chose these three for the balance they strike between accuracy, speed on a laptop, and audio that never leaves the machine. The engines and models download once, and every file is checked against its published length and SHA-256 digest before anything uses it. A file that does not match never reaches its final path, so a corrupted download cannot become a permanently wrong transcript.
Transcription covers the models, the languages and how to correct what comes back. The one AI feature that is not local is AI Autofill, which sends a frame per shot to a hosted vision model and says so on its own page. The privacy page is the authority on which is which.
What happens to a long job if you quit the app?
It is written down, so the worker picks it up again when you come back. Import, transcription, export and AI Autofill are each a row in the worker's own database with a status on it, rather than a promise held by whichever window started the job.
When the worker starts, it resumes what was interrupted. A job that stops making progress is noticed and requeued, so nothing sits there forever, and the error you get says whether it stalled or was interrupted, because those need different things from you. An Autofill run records how far it got, shot by shot and field by field, so resuming does not pay again for work already done.
Transcription sits deliberately outside the import's critical path. It is queued once the import reports Complete, and queueing it cannot throw, so a transcription that fails or finds no engine installed cannot fail an import or leave a video stuck part-way.
What stops one failure from taking the whole app down?
The heavy work runs in a separate process from the window, and that process is supervised. Video decoding, thumbnailing, transcription and export happen over there, which is why the interface stays interactive while a long job runs.
That process has crash handlers whose one rule is that they never throw, guarded call by call, because an exception inside a crash handler is what turns a recoverable fault into a dead worker. If it dies anyway, the app restarts it and issues a fresh access token for the new one; the window reads the current token per request, so a restart is usually something you do not notice. That local connection is bound to loopback and requires the token, published for each launch before anything is listening, so nothing else on your machine can read your library by guessing a port.
Above that, every edit gesture takes a restore point before it writes, one per gesture rather than one per shot, so a change written across forty shots is one entry and one undo. Version history covers what it captures. Mac builds are signed, notarized and run under the hardened runtime, and crash and error reporting is opt-in with an opt-out in the account pane.
How is a release tested before it reaches you?
With 234 test files covering the interface, the state layer, the worker's API and the assistant connector, run on the same machine that builds each artifact. A release build compiles the app and the worker, runs the suite, and only publishes if it passes, on all three release machines.
Two more layers sit above that, and both treat the app as a black box. One launches the installed, signed and notarized build itself and drives the real interface through import, export, library search, metadata edits, transcript correction, plan gating and the assistant's tools. The other provisions a disposable machine, installs the real package on it, and walks cold launch, sign-in, import, export and auto-update, which are the parts no test running inside the app can reach: installers, the operating system's own security prompts, the hand-back from browser sign-in, and an update that quits and relaunches the process being tested.
FAQ
Is StoryFolder 0.4 faster? Yes. The interface composites on the GPU, the shot board draws only the cards on screen, and on Apple silicon the app, the worker and the speech engines are all native builds.
Does StoryFolder run natively on Apple silicon? Yes. The app, the background worker and the speech engines all ship as arm64 builds, and none of them runs under translation.
Will an existing install switch itself to the native Apple silicon build? No. An installation set up as the Intel build keeps updating as the Intel build, on purpose. Download once from the install page to move to the native one.
Does transcription use the GPU? On Apple silicon, yes: that build of whisper.cpp has Metal compiled in. The Intel and Windows builds run on the processor at a conservative instruction-set baseline so they work on older machines.
Is any audio uploaded for transcription or speaker identification? No. whisper.cpp, sherpa-onnx and the Silero voice-activity model all run on your machine. AI Autofill is the feature that makes a cloud call, and it sends frames rather than audio.
What happens to an export if I quit the app halfway through? It is a row in the worker's database with a status, so the worker resumes it at startup. A job that stops making progress is requeued rather than left running.
Which machines does StoryFolder 0.4 run on? macOS on Apple silicon, macOS on Intel, and Windows x64. Each gets its own build of the app, the worker and the speech engines.
Can something else on my computer reach StoryFolder's local API? No. It binds to loopback and requires an access token that is issued fresh for each launch of the worker, including after a restart.