I've been writing software for a living for 23 years and programming for well over 30. Murble started as my way of learning about large language models, and I picked the most awkward place I could think of to run them: a phone, offline, with no data center behind it. I also wanted to stop handing more and more of my life to the cloud, and a voice notes app hears a lot of a life.
I didn't think it would work
Short voice memos, maybe. But a meeting that runs for an hour or more, summarized by a model small enough to share a phone with your photos? How much of it would the model actually keep, and how often would it fill the gaps with fiction? Would offline transcription be good enough to build on? Could it tell who said what when several people share one microphone? My private expectation was a very slow machine for producing confident nonsense, which would at least teach me a lot along the way.
I didn't train any models. I picked existing ones, Apple's own model where the phone has it and a few small open models, and spent a long time on prompts and on the code that checks their work. Memory was the wall I kept walking into. iOS closes an app that takes too much, so how much of a meeting a model can read at once depends on how much RAM the phone has.
Enter Springfield
My first test cases were synthetic: short meetings written in seven languages, with known facts. A meeting written to have known answers is polite and makes sense, and even so the smallest models kept losing track of who was supposed to do what. I needed real meetings, preferably public ones.
That's how I ended up spending a lot of time with the Rural Municipality of Springfield, in Manitoba. It publishes years of audio from its council, committee and planning meetings, and they make close to perfect test material: real procedure, real votes, several voices on one PA system, the odd joke, and sessions that go on for hours. The municipality has no connection to Murble. It simply publishes its meetings, which is a fine civic habit, and I've been grateful for it ever since.
"Armistrowing Field"
Springfield started by teaching me humility. Whisper, the speech model, had clearly never heard of the place. The municipality came out as "Army Springfield", then "swing field", and once, gloriously, "Armistrowing Field". "Adjourn" became "a journey", and one summary solemnly reported that council had "approved a journey to join the German meeting".
Whisper also learned a lot from subtitles, and sometimes it shows. A silent test recording of 17 seconds came back with "[Fansubs by @Fansubs]", stamped twelve seconds after the audio had ended. Cleaning out that kind of noise was the easy part. Misheard names were not, and a summary can't be more accurate than the transcript underneath it.
The soccer ball
The models had their own ways of getting things wrong. In one meeting, someone suggested that council support for a soccer championship should come with a condition: a ball signed by the team. Six seconds later came the correction:
"That won't be part of the condition."
The summary reported the condition as added. The correction was right there in the recording. For a while the local model also filed these council sessions under "ideas" or "personal", which is a generous way to describe a hearing on zoning variances. At this point my private expectation was holding up nicely.
Some of it was me
It would be convenient to blame the models for everything, but some of the worst results were my own doing. A small model can't take in a long meeting in one go, so Murble has to compress it first, and my first version compressed so hard that a planning meeting of 37 minutes reached the final step as a handful of sentences. Then I wondered why its summary felt thin.
My favourite own goal was the "Try again" button for reports. The local models were set up to give the same output for the same input, which is lovely for testing. It also meant that a failed report, retried, failed again in exactly the same way, and sometimes the retry gave the model less room than the first attempt. It was, strictly speaking, a replay button.
Murble also writes longer reports, closer to meeting minutes, and rewording their prompts was a lottery. One extra line took a recording from one contradiction to five. So I stopped trusting my instincts and started measuring: changes had to hold up on the same set of real recordings, several runs each, scored against facts I had checked by hand.
Then the numbers started moving
Once I fixed my own mistakes, the results began to climb, and I started opening each new run out of curiosity. In test runs on a Mac, reports on one meeting of just under half an hour went from 36% of the facts I check for to 82%. Apple's model was even more dramatic. Across 18 test runs on six recordings, its reports initially completed only twice. After I rebuilt them from smaller, checked parts, all 18 completed. Completed doesn't mean perfect, but it's a long way from 2.
I also tightened the instructions about suggestions and decisions, and added checks that catch more of the soccer ball kind of mistake. They still miss things.
Four and a half hours
That left the boss level: a planning meeting four and a half hours long, with a large part of the evening spent on a proposed data center. For an app built to keep your notes out of data centers, I tried not to take that personally.
The first attempts were humbling. The summary from one of the smaller models said a rezoning was denied and, a few lines later, approved unanimously. The transcript didn't help (late in the night, "I'm opposed" had become "I'm a post"). One report condensed the entire evening into an overview of exactly one sentence, which told me who the mayor was.
Then the fixes added up. With Apple's model, long notes now come back as chapters, each with its own title and time range, so four and a half hours read like a document instead of a wall. And I asked the question that actually matters: what did council decide about the bylaw? The answer is buried at 4:19:14, in four words: "It is so denied." In my test runs on a Mac, Apple's model and both local models I tried found it and answered correctly that council had rejected the amendment, the smaller local one in about two seconds. That was the moment I surprised myself.
Better than I expected
I started this project expecting confident nonsense. What I have now is an app I'm genuinely happy to hand a long meeting. You record or import audio, and Murble gives you a transcript, a summary, and the tasks it finds. If you want more, it writes a report that reads like minutes, and you can ask the recording questions like "what did we decide?" or "who owns what?" and get answers from what was actually said. All of it runs on your device, offline, once the models are downloaded.
It still makes mistakes, and several in my tests started with a joke, a vote or a misheard name. But Murble can now sit through an evening of municipal planning and tell you how it ended, and when I started, I would not have bet on that.
Murble runs on iPhone, iPad, Mac and Android. Recording, transcription, summaries and tasks are free, with no monthly cap. Reports and chat are part of Pro. There's no account, Murble has no analytics of its own, and syncing to your own iCloud or Google Drive is optional.
Somewhere in Manitoba there is a council with no reason to know any of this exists. Its meetings did more for my summaries than most of the prompts I wrote.
If you have meetings you'd rather not upload anywhere: getmurble.com