Bit by Ear: Daily Two-Minute Audio Lessons from Your Own Notes

Ibrahim — Sun, 25 Oct 2026 20:34:41 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Bit by Ear turns the notes and PDFs you've been meaning to read into short daily audio episodes. Add a topic, your context, and your sources; adjust and approve the proposed learning plan once. From then on, a background worker prepares each next episode on schedule, and you just press play — two minutes or less, with each episode briefly recalling the previous idea before introducing a new one. It's a private, installable PWA with saved playback position and optional ready-episode notifications. The lazy part: you do the thinking once, then only listen.

Demo

▶ Watch the demo on Streamable
▶ Live

Code

mii9000 / bit-by-ear

Bit by Ear

Small listens. Steady learning.

Explore something you’ve been meaning to learn, one idea at a time. Bit by Ear turns your own notes and documents into connected daily audio stories. Add a topic and context, adjust and approve your learning plan, then listen at your own pace in a private, installable web app. Each episode briefly recalls the previous idea and introduces a new one. Published audio is measured to be two minutes or less; episode-ready notifications are optional.

Run locally

Requirements: Node.js 22.22 or newer in the 22.x line, npm, and Docker Desktop (or Docker Engine with Compose).

npm ci
cp .env.example .env
npm run local:setup
npm run dev

Open http://localhost:5173. Local development uses deterministic mock providers, so the complete learning flow works without provider credentials. Add OpenRouter and ElevenLabs keys to .env and set PROVIDER_MODE=real when you want to try live generation. Keys stay…

View on GitHub

How I Built It

Frontend: React + TypeScript PWA (installable, offline shell, saved playback position, optional Web Push).
Backend: Express/TypeScript API plus a Node worker, sharing PostgreSQL. The server enforces resource limits and rejects episodes whose measured audio exceeds two minutes.
Open-source AI: GLM 5.3 Flash — an open-weight model via OpenRouter — drafts the learning plan and every episode script from the learner's own sources; ElevenLabs narrates each approved script.
Ops: a Render Blueprint (render.yaml) with web service, background worker, and PostgreSQL. Local development uses deterministic mock providers, so the complete flow runs with no API keys and no cost.

Why Does Open Innovation Matter?

The part of the app that actually writes the curriculum is an open-weight model, and it sits behind a single environment variable — OPENROUTER_MODEL. Swapping GLM for any other open-weight model is a config change, not a rewrite, so the project never depends on one vendor's roadmap or pricing for its core intelligence. Because generation is cheap and open, a hobby-scale "daily audio for one learner" app is economically viable, and anyone can fork it and run the whole flow locally on mock providers without signing up for anything. A closed, single-provider API would have made both the price of daily generation and the longevity of the project somebody else's decision.

My Agent Session

The Lazy Payoff

Setup is the only real work: upload sources, tweak the plan, approve. After that the daily cost is pressing play on a two-minute episode — no re-reading, no highlighting, no deciding what to study next. The worker keeps preparing episodes even when the free web service sleeps, and there are no streaks or guilt mechanics; missing a day just means an episode is waiting.

Prize Categories

Best Use of Render — the whole system (web service, background worker, PostgreSQL) deploys from the repo's Render Blueprint.
Best Use of ElevenLabs — every episode is narrated with ElevenLabs multilingual v2 voices.

Auto Generate Client From OpenAPI Specification (Swagger)

Ibrahim — Tue, 06 Apr 2021 16:17:33 +0000

TL;DR - Working script at the end

In a microservices system, one of the mechanism for one service to talk to another is using Http. For example, if Service A wants to invoke an endpoint on Service B it can do something like below:

var client = new HttpClient();
client.BaseAddress = "https://service-b";
var responseMessage = client.PostAsJsonAsync("/some-endpoint", new Payload(...));

The issue here is that the model class Payload was already written in B but then A would have to write it again in order to have typing and whenever there would be a change in specification in B then A would have to be manually changed also. So coupled and duplication.

Now, lets assume another Service C wants to invoke the same endpoint on B so, C would have to duplicate the code like A again.

We can can get rid of this manual and redundant process by auto-generating clients from the services like API SDKs which can then be consumed by another service.

To Dos:

Integrate with Swagger for your web api
Access to auto-generated swagger.json based on your web api
Tool to auto-generate code according to choice of language

1. Integrate with Swagger for your web api

Pretty easy in ASP.NET Core. Use Swashbuckle to integrate swagger into your web api. Getting started tutorial here.

2. Access to auto-generated `swagger.json` based on your web api

When you run your web api app, you can access the swagger.json at http://localhost:<port>/swagger/v1/swagger.json. Now either you can pass the link to swagger.json or make it accessible from file system. If you go the former route then you need to ensure your web api is up somewhere and updated or spin it up locally. I went ahead with downloading the file into file system using Swashbuckle.AspNetCore.Cli which can generate swagger.json from your web api assembly.

3. Tool to auto-generate code according to choice of language

I only found NSwag or swagger-codegen for this and went ahead with the latter because it has more options and configurability. A great feature of this tool is that you can control the generated code through the use of mustache templates documented here. If you want to kickstart your template customization for your preferred language then look here. Now, you can execute a command as simple as swagger-codegen generate -i ./swagger.json -l ruby -o /tmp/test/.

Example script

Below is an example of bash script that is generating a customized C# client in a Linux machine.

#!/bin/bash

swaggerCodeGenCliDownloadLink='https://repo1.maven.org/maven2/io/swagger/codegen/v3/swagger-codegen-cli/3.0.25/swagger-codegen-cli-3.0.25.jar'
swaggerCodeGenCliPath='./swagger-codegen-cli.jar'
finalGeneratedClientPath='./DEV.Client/generated'
swaggerGenOut='./swagger-code-gen-out'
swaggerInputFilePath='./swagger.json' 
swaggerTemplateFolderPath='./swagger-code-gen-templates'
ApiProjectName='DEV.API'
clientProjectName='DEV.Client'

# Color
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[0;33m'
NC='\033[0m' # No Color

function red {
    printf "${RED}$@${NC}\n"
}

function green {
    printf "${GREEN}$@${NC}\n"
}

function yellow {
    printf "${YELLOW}$@${NC}\n"
}

# build api project
dotnet build "$ApiProjectName/$ApiProjectName.csproj"
echo $(green 'Building project done!')

#restore swashbuckle aspnetcore cli tool
dotnet tool restore
echo $(green 'Restored dotnet tools!')

# generate swagger json
dotnet swagger tofile --output swagger.json "$ApiProjectName/bin/Debug/net5.0/$ApiProjectName.dll" v1
echo $(green 'Generating swagger.json done!')

# download swagger code gen cli
if [ ! -f $swaggerCodeGenCliPath ]; then
    echo $(yellow 'Downloading swagger-code-gen cli...')
    curl $swaggerCodeGenCliDownloadLink -o $swaggerCodeGenCliPath
fi

# generate models and apis
java -Dapis -DapiDocs=false -Dmodels -DmodelDocs=false -DapiTests=false -DmodelTests=false -jar $swaggerCodeGenCliPath generate -i $swaggerInputFilePath -l csharp -o $swaggerGenOut -t $swaggerTemplateFolderPath --additional-properties modelPackage=$clientProjectName apiPackage=$clientProjectName packageName=$clientProjectName
echo $(green 'Generating models and apis done!')

# if there was previously generated then delete it
if [ -d $finalGeneratedClientPath ]; then
    echo $(red 'Deleting stale generated folder')
    rm -r $finalGeneratedClientPath
fi

# move the generate code into target client project
mv "$swaggerGenOut/src/$clientProjectName/$clientProjectName/" $finalGeneratedClientPath
echo $(green 'Moving files to client project done!')

# remove temp swagger code generated folder
rm -r $swaggerGenOut
echo $(green 'Removed temp generated directory')

DEV Community: Ibrahim