Building Dominik’s Radio Times with local AI

A case study for community archivists and professional historians. Begun 24 October; updated 25 October 2026. This report was largely written by GPT-6.1 Sol with edits and additional information by Dominik Lukes

Dominik’s Radio Times began as an attempt to catalogue a collection of audio files representing radio recordings of various programmes Dominik presented between 2007 and 2016 using local models. Early success led to a small project that made it possible to document a significant portion of several radio shows including the interviews, music choices and short features within them across almost 10 years of volunteer broadcasting.

The collection is now a searchable private archive along with a smaller public listening site. Open weights AI models running on a local NVIDIA DGX Spark have done the speech recognition and subsequent bulk language analysis.

The collection

Rediscovering the collection and its paper trail

The starting point was a collection of audio files with mixed labels and uneven metadata, not a prepared dataset. The surviving filenames did not consistently distinguish a complete programme, a podcast edit, an interview extract or a spare recording. Some files had useful dates; others carried misleading names or export information.

The second source was patchy email correspondence spanning the years of Dominik's radio work, with the earliest messages now almost twenty years old. Searches recovered programme proposals, studio arrangements, running orders, interview plans, music choices and production credits. These supplied context that the audio filenames could not. They also documented programmes for which few or no recordings survive.

The correspondence was evidence to reconcile, not a complete transmission log. A plan to interview somebody was kept distinct from a recording of the interview; a proposed slot was not automatically treated as a broadcast date. This initial historical reconstruction explains why file organisation, deduplication and catalogue research are substantial parts of the project rather than preparation that can be ignored in the budget. Private email contents and contact details are not reproduced in the public-facing reports.

What was in the collection

The material includes community radio interviews, music programmes, technology discussions, guest appearances, field recordings and Black History Month features. Programmes include Community Chest, Textures, Roots and Roads, TechTalk and Bohemian After Dark. There are full shows, edited interviews, podcasts, alternative encodes and short extracts.

These describe the available collection which was not fully systematic. Some programmes were presented regularly but have very few recordings left.

The "research team"

The working model was a small research project. Dominik was the principal investigator: defining the questions, supplying knowledge of the collection, setting priorities, judging examples and deciding when a result was useful enough to extend. GPT-6.1 Sol running in the Codex harness acted as the main researcher and coordinator: turning broad requests into bounded work packages, inspecting evidence, building the processing tools and interfaces, selecting local models, designing matched-input experiments, checking samples and recording decisions. Luna and Opus supplied additional source checks and design/process criticism. Earlier specialist review also involved Astra.

The coordinator also handled dependencies: keeping experimental jobs away from an active transcription batch, distinguishing a runtime limitation from a model error, maintaining source hashes and checkpoints, and making completed outputs reviewable by the PI. It translated sample failures into changes in the method—for example, replacing generated quotation text with deterministic source retrieval. It could implement or investigate an idea without turning every routine technical choice into another decision for Dominik.

The role of the human PI was to provide direction and additional context not contained in the sources. For example, Dominik explained that finding a song to fit an interview was part of his presenting style. A request for playlists became a research question about musical connections, personal memories and spoken explanations. He also identified why a sparse collection of surviving broadcasts should not become a career-output chart.

The bulk speech recognition and later transcript enrichment ran locally. The coordinating and reviewing assistants are cloud-based and have inspected selected transcript text and project records; original audio stayed on local machines. The current arrangement gives Gemma the bulk archive-analysis work, with Sol coordinating and checking samples and Luna available for additional checks. Opus contributed an earlier design and process review. The research-assistant framing describes a division of tasks, not professional qualifications or independent responsibility.

For an archivist or historian, the substantive questions remain familiar: who made this item, which version survives, who is speaking, what date does a piece of evidence establish, and how should the item be represented? The models help produce and test descriptions. The PI and subsequent archival reviewers remain responsible for their use.

Tools

Models used

Gemma’s installed Ollama interface advertises text and vision capabilities, not audio transcription. In this workflow it analyses the existing ASR text. Keeping recognition and interpretation separate makes it easier to identify where an error entered the archive.

Hardware and software used

The processing machine was a NVIDIA DGX Spark with a GB10 Grace Blackwell processor. Local inspection confirmed 20 logical CPUs and a 4 TB-class NVMe drive. NVIDIA specifies a 20-core Arm CPU comprising ten Cortex-X925 and ten Cortex-A725 cores, a Blackwell GPU and 128 GB of unified memory. The CPU and GPU share that memory pool. NVIDIA hardware documentation.

The main recognition batch used the GPU. Small comparison and audit jobs used four CPU threads so they could proceed without disturbing that batch. Gemma subsequently used the GPU through the shared Ollama service, with serial requests. Its quantised model download was about 20 GB, plus a roughly 515 MB draft component; these are weight sizes, not measured peak working-memory use.

Original recordings were stored on a Mac mini, with a laptop used for staging, transfer and interaction. Heavy project processing was deliberately kept off the Mac mini. Their detailed hardware configurations were not logged. Purchase cost, power consumption and peak memory were not measured, so the performance results below should not be read as an electricity-cost or hardware-payback calculation.

Measuring local model speed

Gemma runs through the shared Ollama service on the DGX Spark, using quantised weights. The installed model includes a draft component for multi-token prediction. A small experiment tested the draft setting on three real song-story inputs, twice each, excluding warm-ups.

Five was fastest in this small workload. The batch retained the configured setting of three because promotion required an alternative to pass every automated check, and none did: each setting passed four of six measurements. This did not establish a quality advantage for three.

The larger 190-document catalogue run took about eight and a half hours. Saved responses reported approximately 5.19 million prompt tokens and 681,000 generated tokens, at about 31 generated tokens per second. Prompt counts include repeated context and retries. The subsequent recovery of twenty held records required 21 additional local requests and about nine minutes of reported request time.

Speed made the work practical, but evidence handling and recovery determined whether the output was usable. Gemma became the working default after the descriptions proved useful enough to extend the project. After completing the catalogue, Dominik authorised a separate, deliberately smaller model comparison; it does not replace the production catalogue.

The process

Inventory

The first useful work was establishing what each file represented. A recording asset, a programme episode and an interview feature are different things. One episode can contain several interviews; one interview can survive as a raw recording, an edited podcast and an extract inside a complete show.

File hashes established byte-identical copies. Matching transcript arrays identified further duplicate candidates, without proving audio identity. Source paths and competing descriptions were retained. This prevented copies from inflating show counts and made it possible to keep alternative versions available for later listening.

There were also output collisions: files with different audio extensions could produce the same transcript filename when the extension was removed. These were recorded explicitly. Supplemental source-specific processing and an extension-preserving output scheme provided a way forward without overwriting the original results.

Dates needed similar care. A scan found embedded date fields in 89 recordings, but these included generic years, export information and music metadata. File dates could not simply become broadcast dates. Filenames, spoken announcements, presenter briefs, correspondence and podcast information supplied separate pieces of evidence. Contemporary records helped reconcile dates for interviews including Linda Bellos and a sustainable-living feature. Unresolved dates stayed unresolved.

Comparing speech recognisers

A small comparison used 12 speech chunks totalling approximately 187 seconds. Whisper base, Whisper small and Parakeet processed the same reconstructed audio intervals, and their outputs were compared with the existing Qwen transcripts.

The models often agreed on ordinary prose while disagreeing on names, places and products. A technology feature could contain “Picasa” in one output and “Picasso” in another. A guest’s name could vary across every recogniser. These differences mattered because a wrong name can make a recording effectively disappear from search.

The comparison measured disagreement, not accuracy. There was no independently corrected reference transcript from which to calculate a defensible recognition score. It supplied useful review candidates and showed why one model’s confident spelling should not silently overwrite the archive.

Finding a music-filter limitation

The original music classifier received chunks longer than the portion its feature extractor actually retained. It effectively inspected about the first 10.25 seconds of chunks that could be substantially longer. Speech near the end could therefore fall outside the classifier’s view.

A 100-chunk audit compared that behaviour with overlapping windows covering each complete chunk. Effective coverage rose from 68.35% to 100%, and 22 decisions changed. Seven cases became candidates for reviewing possible speech in previously unseen tails. These were coverage and disagreement findings, not measured recognition-error improvements.

A separate revised gate and runner were implemented, preserving the original batch. Full-window classification was audited; the revised runner was not established as a replacement transcription pipeline. This is an example of a useful correction emerging from inspecting the surrounding software, rather than changing the language model.

Making summaries traceable

An early interview-and-show pilot compared Gemma and Qwen on ten interviews and five show recordings. Both produced useful prose, but both struggled with the requirement to copy exact quotations and cite them correctly. Under the source-matching checks, each model ended with only three passing drafts out of fifteen.

The important change was to stop asking the model to reproduce the quotation text. It selected source segment IDs instead. Code then copied the original transcript words and attached their timestamps. Longer recordings were processed in bounded chunks, followed by a synthesis stage that selected from extracted claims.

This made quotation identity checkable. It did not establish that the ASR words were correct or that a named person had spoken them. Those became separate review questions.

The first larger Gemma run covered 190 source documents in 654 chunks. It produced 170 drafts and 20 held records. Recovery omitted whole claims with invalid references and asked local Gemma to synthesise the remaining evidence. The original failures stayed intact. All 190 entries subsequently passed the structural source checks, and summaries were integrated into 141 show pages and 49 additional interview or feature entries.

Sample review still found semantic errors. Most notably, a model assigned Dominik’s memories of participating in the Velvet Revolution to his guest. Another summary turned two ASR spellings of the same guest into two people. These required explicit editorial corrections, preserved separately from the original model output. A valid citation is useful evidence to inspect; it is not a guarantee of correct interpretation. Descriptions record what was discussed; statements made in a broadcast still need historical source criticism.

Recovering playlists and the reasons behind them

A bare artist-and-title list misses much of the value of these programmes. Dominik often chose a song to follow an interview, continue a theme, change the mood or tell a personal story. Sometimes the explanation was simply that he liked it.

The first playlist reconstruction contains twelve selections, spanning jazz, Czech and French music, Russian song, Egyptian pop, Malian blues, Albanian rap and bluegrass. Its spoken links include personal memories and explanations that belong alongside the track list. Some explanations occur after the song, so extraction needs both introductions and back-announcements.

An earlier Gemma song-story batch processed 452 jobs, producing 395 drafts and 57 held results. Hundreds of source-checked reason notes have since been brought into the local listening site. The completed broader pass includes Community Chest and other shows where music accompanies interviews, rather than restricting playlists to dedicated music programmes.

Two distinctions proved especially important:

• A song being discussed is not necessarily a song being played. Historical references, future plans and listener comments about earlier selections need different statuses.
• A description of a song is not necessarily a reason for choosing it. “This song is about…” or a general programme theme does not establish a personal motive. An explicit link such as “I have a song just for that”, following a discussion of the Web 2.0 investment bubble, supplies a stronger basis.

A focused Gemma review now revisits the draft songs with source passages. It checks artist/title separation, distinguishes commentary from selection reasons and looks for retrospective references elsewhere in the same recording. Missing reasons remain empty. The original words and failed attempts stay available for inspection.

One particularly useful failure involved numbers. A real source segment had ID 133 and began at 1982.09 seconds. Gemma cited 1982 as though it were the segment ID. The revised input supplies only segment_id and text; code keeps the timing information and reattaches it afterwards. Held sample chunks were regenerated locally with that simpler representation.

Finding people when the names are patchy

Thordis Fridriksson, also known as Thunderfairy, provides a good test of archive retrieval. She was Dominik’s producer and co-presenter, but her name appears in several ASR forms. A search for one exact spelling would miss material.

The local index now includes a broader name-variant register with 379 candidate segment references across 86 source documents. These include alternative recordings and uncertain matches, so they are not counts of distinct broadcasts or confirmed appearances. Gemma adds contextual role evidence: producer, co-presenter, guest or someone merely mentioned.

This creates a useful browsing route through a collection that was originally organised around filenames and programmes. The same approach can be extended to other people, recurring topics and musical connections.

Final product

Building two ways to use the archive

The full private archive indexes every source segment and retains original recording links. It supports text search, full-recording playback and timestamp seeking. The current index covers 528 transcript files grouped into 508 source documents. Identical segment aliases share records while retaining their source-file associations.

The listening site presents selected material: programme pages, a calendar and yearly agenda, interviews, song lists, notes about musical choices and compact audio previews. The recorded export contains 576 previews in approximately 74 MB, including the interface, structured data and four compressed photographs. The complete Black History Month material is prepared separately, so the main showcase can represent a wider range of radio work.

Design review changed the listening experience as well as the appearance. A repetitive “radio chatter” display became a word cloud, which was then removed when it proved unhelpful. Each show gained its own player and playlist page. A small photographic treatment and factual introduction lead into the player. Spoken segues are preserved through the relevant words, followed by ten seconds of music; a fixed spoken-duration rule had been cutting away the connection the clips were meant to demonstrate.

The complete private collection and the small showcase have different purposes. The listening samples are hosted on Cloudflare at radiotimesof.dominiklukes.net; the complete recordings, source index and processing records remain local. Dominik supplied the hosting update. The Spark's packaging manifest describes a local build rather than an authoritative record of later deployments.

The showcase is a static export: HTML and JavaScript for the interface, JSON for the catalogue, small MP3 excerpts and compressed WebP photographs. Cloudflare delivers the files under the custom domain, while playback, filtering and navigation run in the visitor's browser. A visitor does not trigger a model request. The Spark is used to prepare the material, not to serve every listener, and the full private audio collection is not included in the public package.

Cloudflare lists static-asset requests as free and unlimited on Pages, and its Workers static-asset service likewise separates free asset delivery from billed Worker execution. That architecture can keep the platform charge for this small static showcase at zero; the actual account plan and invoices have not been inspected. Domain registration, any optional paid services and maintenance time are separate. Pages pricing, Workers asset pricing.

Practices worth reusing

1. Establish file identity before counting content. Keep recordings, shows, features and variants as separate records with explicit relationships.
2. Preserve source text and add annotations separately. Corrected display names, summaries and reasons should not erase the raw recognition output.
3. Make models select evidence that code can retrieve. Copy quotation text, timestamps and file references deterministically.
4. Test interpretation as well as structure. Exact quotations can still be misattributed; plausible song notes can still invent a motive.
5. Inspect input representation when citations fail. Removing confusing numeric fields solved a concrete timestamp-versus-ID problem.
6. Use small experiments to decide what to run at scale. Compare identical inputs, record failures and timings, then move on when further comparison is less useful than completing the archive.
7. Make every long run resumable. Save model responses and source hashes, use bounded retries and locks, and commit completed documents. Code and text are versioned; audio stays outside Git.

Could Qwen become the research coordinator

A next experiment could move another layer of work onto the local machine: let Qwen plan and direct the research, calling Gemma and other local tools. Sol, Luna and Opus would then supply an initial brief and independently assess the results. This remains a proposed experiment; the completed Gemma catalogue is kept unchanged as the release baseline.

The installed Qwen 27B service advertises tool support. That establishes an interface capability, not evidence that it can coordinate this project reliably. A test should hold the worker models and source material fixed, and examine whether Qwen can choose useful actions, notice failures, recover, preserve evidence and recognise when to ask the PI.

A six-case pilot could include a clean interview, telephone audio, a mixed Community Chest show, a world-music programme, conflicting dates or versions, and Thordis banter. The PI and an independent reviewer would prepare source-based reference findings before the test. Qwen would receive bounded tools for inventory, transcript search, local recognition, Gemma extraction/review, validation and checkpoints. It would not receive unrestricted publication or file-deletion authority.

The measures should cover supported claims and missed material, correct person/role and date distinctions, exact evidence links, recovery from deliberately introduced tool failures, PI interventions, compute use and elapsed time. A later controlled comparison could test the same tasks with a fixed scripted pipeline and with Sol coordinating the same local workers. It should separate coordinator judgement from worker-model quality and account for the Spark’s shared GPU and memory.

A successful demonstration would show Qwen completing useful research tasks while leaving uncertainty visible and the evidence recoverable. More generated text or fewer questions alone would not establish that result. A separate protocol accompanies this report, along with an outline for “How I was a research project PI for a weekend”.

Counterfactual workloads and costs

What would a small human team have needed

A useful counterfactual is a discovery prototype commissioned around 2022–23, using available speech-recognition, search and audio-editing software. It would require working descriptions, playlists, source links and a browsing interface at roughly the present draft level. It would still have outstanding listening and publication decisions.

The estimate below separates work packages rather than assuming each requires a different employee. It includes web design, frontend construction, audio preparation and hosting setup as well as the historical research. It revises the earlier 245–520 hour outline to expose that work explicitly. These are planning assumptions, not measured hours, a supplier quotation or a claim that every file needs hand inspection.

The first three rows alone represent 64–136 hours before transcription interpretation, clip production or website construction: roughly nine to nineteen seven-hour working days to establish what the collection contains. Computing a hash is quick. Deciding whether two files are exact copies, alternative encodes, edited interviews or different parts of one show—and then relating them to incomplete correspondence—is the larger task. Inventory/deduplication alone is budgeted at 16–32 hours; the other two rows add catalogue structure and historical reconciliation.

The full prototype estimate is about 9–20 person-weeks at 35 hours per week. At an assumed blended £40/hour it is £13,240–£27,360; at £60/hour, £19,860–£41,040. The initial file-catalogue/reconciliation subtotal is £2,560–£5,440 at £40/hour. These are illustrative labour rates, not historical pay claims. Actual professional budgets include employment or freelance on-costs. ARA guidance.

The scenario assumes existing ASR and selective review, not a new human-verified transcript of every recorded minute. Full human transcription is costed separately below as an alternative service. It excludes institutional catalogue migration, preservation-system deployment, complete permissions clearance and maintenance after initial handover. Hosting setup hours pay for somebody doing the work; they are distinct from a monthly Cloudflare bill.

Actual PI time, coordinator subscriptions, hardware depreciation and electricity were not fully logged or allocated. The labour scenario therefore describes work made practical, not a measured net cash saving. Professional source judgement and editorial review remain necessary.

Commercial transcription: what the per-minute bill would have been

The full copied collection contains 20,389 recorded minutes (339.8 hours), including variants and music. The counting corpus contains about 13,400 speech-labelled minutes (223.3 hours), which provides a screened-workload proxy. A real commission should first deduplicate and decide what needs transcribing; the speech proxy comes from a different counting scope and is not a ready-made provider invoice.

The 2019 rate is documented in Rev's contemporary conference sponsor listing; the 2022 rates are from the provider's dated rate card, rather than applying today's prices retrospectively. Figures are nominal US dollars before optional extras, taxes or negotiated discounts. 2019 AHG programme, Rev listing, 2022 rate card, current Rev human pricing.

These are different service standards from raw local ASR: human transcription includes review that this project has not performed across every minute. The comparison explains why making a searchable first draft was previously a substantial commissioning decision. It does not mean an equally verified $40,000 product was delivered for free. Neither transcription service by itself supplies the archive inventory, historical reconciliation, playlists, design or website.

Avoided API charges using Google's current prices

At the introductory rates available on 25 October 2026, Gemini 3.8 Flash text costs $0.75 per million input tokens and $3.75 per million output tokens; batch rates are half. Google's Speech-to-Text V2 lists $0.016 per minute for standard recognition and $0.003 for dynamic batch. The stated Flash standard rates double from 1 January 2027. Gemini pricing, Speech-to-Text pricing.

A deduplicated ledger of saved local responses—including pilots, retries, histories, guest descriptions and the mini experiment—contains 16.54 million input tokens and 2.76 million generated tokens. Pricing the same token volume as Gemini 3.8 Flash gives about $22.74 standard or $11.37 batch. The full Gemma detail pass's current signed records alone correspond to $12.39 standard; it is a subset of that total, not an extra charge.

This is a paid-service counterfactual, not an actual Google bill: one billed audio channel, no credits/volume discounts, no storage or transfer charges, and local token counts used as an approximation. Gemini would tokenize and reason differently and could need different outputs or retries. The ledger does not price cloud-based coordination subscriptions or unlogged work. No paid Gemini or Google recognition calls were made for this comparison.

Local processing avoided those per-use charges and kept original recordings off transcription services. But modern bulk APIs are already inexpensive relative to human transcription or assembling the whole project team. Existing hardware, power, storage and coordinating subscriptions still cost money; the result is not a demonstrated Spark payback calculation. The larger practical gain was being able to investigate, organise, redesign and experiment repeatedly while retaining control of the source collection. The arithmetic record preserves both scopes and assumptions.

What is happening next

The full catalogue and detail run are complete as a discovery baseline. The next model tests should use a few fresh, independently checked excerpts and narrower extraction tasks, with quotations copied by code. Qwen 9B and Gemma 12B are useful candidates for that follow-up. Testing native reasoning/configuration differences, newer compact releases and eventual modest-computer performance can remain separate small experiments rather than trigger another corpus-wide run.

Further work is primarily editorial: checking voices and proper names, listening to selected cuts, resolving remaining dates and choosing what merits a place in the smaller showcase. A deliberately prepared listening reference would also support a proper accuracy evaluation, which the current model-disagreement experiments do not provide.