AudioNotes: local FunASR and Ollama transcription with Markdown output

What AudioNotes solves, and who it is built for

The project describes itself as a locally running audio and video transcription and note tool for meetings, interviews, courses and voice memos. The problem it targets is narrow and practical: you have a recording, you want a transcript, and you want the transcript condensed into something readable rather than a wall of raw ASR output. AudioNotes does both in one pipeline and then lets you ask follow-up questions against the recording.

The audience is implied by the constraints rather than stated outright. The README says the Web page only listens on the loopback address, that FunASR performs recognition locally, and that Ollama runs the language model locally. That combination is aimed at someone who has a reason not to upload audio to a third-party API, and who is willing to pay for that in setup time and RAM. It is not aimed at a casual user who wants to record a thought on a phone. There is no mobile client in the repository layout; the interface is a Chainlit web app served on port 15433.

How the FunASR and Ollama pipeline fits together

The data flow visible in the repository is a two-stage chain. FunASR handles speech recognition, and the OpenAI-compatible client talks to Ollama for note generation and question answering. The default pairing is FunAudioLLM/Fun-ASR-Nano-2512 for recognition and qwen3.5:2b for summarisation, and the README explains the choice as a balance between Chinese recognition quality and resource use on an ordinary computer.

The summarisation stage has a chunking mechanism worth noting. The environment variable OLLAMA_SUMMARY_CHUNK_SIZE defaults to 6000, and the comment in .env.example states that a long transcript above that character count is first summarised in segments and then merged, which keeps the input inside the model's context window. That is a real design decision, and it also means very long recordings go through several model calls rather than one, so both latency and the chance of losing a detail across chunk boundaries increase with length.

Persistence is deliberately simple. There is no external database to install. The requirements file lists aiosqlite and sqlalchemy[asyncio], and the README says AudioNotes creates its own local data files. Under Docker, uploads, the FunASR model cache, logs and conversation history live in the audionotes folder you create, with a bind mount from ./storage/uploads to /app/public/uploads because Chainlit reads attachments through the /public route. Ollama models are managed separately by Ollama itself.

Installing AudioNotes with Docker Compose and running a first recording

The README's recommended path is Docker. You need Docker Desktop and Ollama running first, and the README suggests at least 12GB of memory for Docker Desktop, 16GB for longer recordings, plus about 10GB of disk. Pull the default model before starting the stack.

ollama pull qwen3.5:2b

Then create a directory, fetch the Compose file and the environment template, and start the service. The image comes from GHCR by default.

mkdir audionotes
cd audionotes
curl -fsSL https://github.com/harry0703/AudioNotes/raw/main/docker-compose.yml -o docker-compose.yml
curl -fsSL https://github.com/harry0703/AudioNotes/raw/main/.env.example -o .env
docker compose up -d --remove-orphans

Open http://localhost:15433/ and log in with admin and admin. The first recognition downloads roughly 2.15GB of speech model weights, so the first file you process will sit there for a while depending on your connection. After that the model is cached locally.

Once inside, upload an audio or video file or use the browser recorder, wait for recognition and note generation, then read the transcript and the structured note. The chat box below accepts follow-up questions about the recording, and the left sidebar reopens earlier notes. If you would rather run from source, the README requires Python 3.12, ffmpeg and Ollama, and the entry point is Chainlit:

python -m chainlit run main.py --host 127.0.0.1 --port 15433

Memory, model choice and the limits the README admits

The most concrete limitation is memory. The troubleshooting section states that 8GB may be insufficient and recommends 16GB for long audio, and that a page interruption during a long file usually means the Docker Desktop memory quota is too low. That is not a tuning footnote; it is the practical ceiling on how long a recording you can process on a given laptop.

Recognition quality has its own caveats, stated plainly in the README: recording quality, ambient noise, accent and overlapping speakers all affect the output, and important content should be checked against the original audio. The default model covers Chinese, English and Japanese. For more languages you edit ASR_MODEL in .env to FunAudioLLM/Fun-ASR-MLT-Nano-2512 and restart. The README is explicit that the default model does not change automatically and the page cannot switch models while running, so this is a restart-level decision, not a per-file toggle.

Speaker diarisation is off by default. ASR_ENABLE_SPEAKER_DIARIZATION is set to false, and the .env.example comment says to enable it when you need speaker-labelled SRT output rather than a plain text note. Domain hotwords are supported through ASR_HOTWORDS, space-separated, which is the intended fix for names and jargon the recogniser keeps mangling.

Finally, the security defaults are development defaults. USERNAME and PASSWORD are both admin, and CHAINLIT_AUTH_SECRET ships as local-development-secret-change-before-deployment. The Compose file comment states that a production deployment must override the secret through .env. The port binding to 127.0.0.1 keeps the interface off your LAN, but anyone with access to the machine and the default credentials has your notes.

AudioNotes compared with whisper.cpp and other local transcribers

The obvious alternative for the recognition half is whisper.cpp or a faster-whisper server. The difference in approach is architectural. A Whisper-based setup gives you a transcription engine and stops there; you supply your own summarisation step, your own storage, and your own interface. AudioNotes bundles recognition, note structuring, question answering and a web UI into one Compose stack, at the cost of pulling in FunASR, ModelScope, torch, torchaudio and a Chainlit front end.

That bundling cuts both ways. You get a working end-to-end flow from a single docker compose up, and you do not have to wire an LLM to a transcript yourself. You also inherit the project's choices: FunASR rather than Whisper, qwen3.5:2b rather than whatever model you prefer, and a fixed 15433 port. The OLLAMA_MODEL variable is overridable, so the model side is flexible. The ASR side is limited to the two Fun-ASR variants named in the README.

If your workload is batch transcription of many files with no note layer, a dedicated ASR server is the lighter tool. If your workload is a handful of meeting recordings a week that must stay on your hardware, the integrated pipeline is the reason to pick this project.

Upgrades, data ownership and the MIT licence

Upgrading under Docker is two commands, and the README gives them: docker compose pull followed by docker compose up -d --remove-orphans. Because the model cache and storage are bind mounts into the audionotes folder, an image upgrade does not wipe your notes. Backup is a folder copy after stopping the service, and migration to a new machine means copying the same folder, installing Docker and Ollama, pulling the default model, and starting again. Cleanup is deleting the folder once you are sure you no longer need the history.

The cost side is mostly disk and RAM rather than money. The speech model is about 2.15GB on first download, the README suggests around 10GB of disk, and the GPU path pulls a larger CUDA dependency set on first build. There is no subscription and no per-minute API charge, because there is no cloud service in the loop.

The project is MIT licensed, which in practice means you can use, modify and redistribute it, including commercially, provided the licence and copyright notice are preserved. The Dockerfile copies LICENSE into the image, which is consistent with that. This is a description of the licence text, not legal advice; if you plan to redistribute a modified version, read the LICENSE file in the repository yourself.

Editorial conclusion

Adopt AudioNotes if you have a machine with roughly 16GB of Docker memory, you already run Ollama, and the recordings you process cannot leave your hardware. Do not adopt it if you want a phone app, a hosted service, or a per-minute cloud API, because the whole design assumes a local machine you control. Before committing, verify three things: that your hardware can run FunASR and qwen3.5:2b at acceptable speed, that you have replaced CHAINLIT_AUTH_SECRET and the default admin password in .env, and that the 2048MB upload default covers your longest file.

Frequently asked questions

Official sources

1. harry0703/AudioNotes on GitHub
2. Issues
3. License: MIT
4. README