<style>
.mc-pipeline {
  display: grid; grid-template-columns: repeat(5, 1fr); gap: .35rem;
  margin: 1.5rem 0 2rem; align-items: stretch;
}
.mc-pipeline .step {
  background: var(--card-bg); border: 1px solid var(--border); border-radius: var(--radius);
  padding: .85rem .8rem; font-size: .82rem; line-height: 1.35; position: relative;
  display: flex; flex-direction: column; justify-content: center; min-height: 6rem;
}
.mc-pipeline .step .n {
  font-family: var(--font-mono); font-size: .66rem; color: var(--accent);
  margin-bottom: .3rem; letter-spacing: .03em;
}
.mc-pipeline .step::after {
  content: "→"; position: absolute; right: -1.05rem; top: 50%; transform: translateY(-50%);
  color: var(--muted); font-size: 1rem;
}
.mc-pipeline .step:last-child::after { content: ""; }
@media (max-width: 720px) {
  .mc-pipeline { grid-template-columns: 1fr; gap: .6rem; }
  .mc-pipeline .step::after { content: "↓"; right: auto; left: 50%; top: auto; bottom: -1rem; transform: translateX(-50%); }
  .mc-pipeline .step:last-child::after { content: ""; }
}
ol.mc-steps { list-style: none; margin: 0 0 1rem; padding: 0; counter-reset: mcstep; }
ol.mc-steps li {
  counter-increment: mcstep; position: relative; padding-inline-start: 2.6rem;
  margin-bottom: 1rem; line-height: 1.55;
}
ol.mc-steps li::before {
  content: counter(mcstep); position: absolute; left: 0; top: -.05rem;
  width: 1.7rem; height: 1.7rem; border-radius: 50%;
  background: var(--card-bg); border: 1px solid var(--border); color: var(--accent);
  font-family: var(--font-mono); font-size: .78rem; font-weight: 600;
  display: flex; align-items: center; justify-content: center;
}
.mc-limits { display: grid; gap: .9rem; margin: 0 0 1rem; }
.mc-limit {
  background: var(--card-bg); border: 1px solid var(--border); border-radius: var(--radius);
  padding: 1.1rem 1.3rem;
}
.mc-limit .tag {
  font-family: var(--font-mono); font-size: .72rem; letter-spacing: .06em; text-transform: uppercase;
  color: var(--accent); margin-bottom: .4rem; display: block;
}
.mc-limit p { margin: 0; }
.mc-screens { display: grid; grid-template-columns: repeat(3, 1fr); gap: .8rem; margin: 1.3rem 0; }
.mc-screen {
  border: 1px solid var(--border); border-radius: var(--radius); padding: 1rem;
  background: var(--card-bg);
}
.mc-screen .num { font-family: var(--font-mono); color: var(--muted); font-size: .75rem; }
.mc-screen .name { font-weight: 600; margin-top: .25rem; }
@media (max-width: 640px) { .mc-screens { grid-template-columns: 1fr; } }
</style>

# An archive where you can find any performance

Digercules sorts through archives that grow faster than anyone has time to watch them — recordings, photos, files nobody's gotten around to organizing. If a venue hosts shows regularly, this is usually what its footage looks like.

Most venues we haven't worked with yet already have a backlog of old recordings sitting somewhere — a few drives, a cloud folder, files named things like `IMG_4021.MOV`. Every new show adds to it: audio straight off the mixing desk, video from whoever in the crowd had a camera out, photos from the door. Finding one specific set means someone has to remember which night it was and rewatch hours of footage by hand.

We sort out what's already piled up, then keep the archive in a state where nobody has to be the one who remembers.

<div class="mc-pipeline">
  <div class="step"><span class="n">input</span>Camera video, board audio, photos — however they already come in</div>
  <div class="step"><span class="n">first the backlog, then only new</span>One pass through everything on hand, then a nightly check for new files</div>
  <div class="step"><span class="n">cpu</span>Whisper-turbo: audio → timestamped text</div>
  <div class="step"><span class="n">index</span>Table: file → event</div>
  <div class="step"><span class="n">to the venue</span>A file list per night — ready for YouTube, performers, or an editor</div>
</div>

## How it works

The first pass goes through everything that already exists — drives, folders, cloud storage — and sorts all of it: what's where, what duplicates what, which night each file belongs to. That's a one-time pass through the whole backlog, and it answers the main question: what's actually in this pile of files.

After that, the program comes back to the same folder every night and checks what's new since yesterday. Only the difference gets processed — anything already sorted doesn't get touched again. An archive sorted once doesn't drift back into an unlabeled pile a month later; it stays current on its own.

## What happens every night

<ol class="mc-steps">
<li>Scan the storage — check against the index table, only new files go through processing.</li>
<li>Audio — from the desk or pulled out of video — gets recognized into timestamped text via Whisper-turbo, entirely locally, no GPU.</li>
<li>Video gets marked at real scene changes, not frame by frame, so what happened on stage is clear within a minute, without rewatching the whole recording.</li>
<li>Files from one night — video, audio, photos — get grouped into a single event by when they were shot or recorded.</li>
<li>The index table fills in: which event, which files, what was performed and when.</li>
</ol>

## The song database gets sharper every time

We've already built a database of song lyrics across genres: before transcribing, the program tells the model which song is probably playing, so it handles unusual words and names far better than plain speech recognition would. That database grows with every archive we process — including a venue's own: the more nights we process, the sharper recognition gets specifically for its regular repertoire and its regular performers.

## What you get

For any event — a concert, a set, a night — it's immediately clear which videos, recordings, and photos belong to it, and what was performed at which minute. From there you can:

- cut a specific song by timestamp and post it to YouTube;
- hand a performer their own set without rewatching the whole night;
- send footage to an editor with the timing already marked;
- pull up every recording and photo featuring one performer across the venue's whole history — not just one night.

## Performers: confirm once, found automatically after that

The same logic that works for voice works for a face on camera — in video or in a photo: confirm someone's identity once, and the system recognizes them on its own in every recording after that, with no repeat questions. It keeps several reference images per person rather than one averaged portrait, so recognition doesn't break down years later, under different lighting, or with a different haircut.

In practice: if a performer has played ten nights over two years, one confirmation is enough for the system to surface all ten — no manually rewatching the archive every time someone needs their own footage.

The decision is always a person's: the system only proposes a match with a similarity score, and whoever's reviewing the archive confirms or rejects it. The mechanism is already proven on 20 TB of real concert footage; what we haven't measured yet is its speed on a venue's own hardware — the same open question as the speech recognition below.

## What we're honest about not having tested yet

<div class="mc-limits">

<div class="mc-limit">
<span class="tag">Whisper-turbo on CPU</span>
<p>We've run it on GPUs many times and know a CPU-only version exists and works in principle — but we haven't tested it on the exact processor inside a venue's own computer. The first few days of any pilot, including that exact workload, will show the real number: how many minutes of processing one hour of recording actually takes on that specific machine.</p>
</div>

<div class="mc-limit">
<span class="tag">Only the fast pass</span>
<p>Whisper-turbo is the quick, rough-draft recognition mode; the slower, more accurate pass — fine-tuned to specific voices — usually needs a GPU and isn't included here. Turbo-level accuracy is enough for search, timestamps, and sorting by event. If word-for-word text is needed later — published captions, for example — that's a separate, heavier step that can be added on top.</p>
</div>

<div class="mc-limit">
<span class="tag">No Ollama</span>
<p>This configuration deliberately skips the local language model that usually writes document summaries and genuinely describes photos. But what it does hand over — timestamped text and a file-to-event index — is exactly the kind of compact, pre-processed material any general-purpose online AI (ChatGPT, Claude, Gemini, whatever's already in use) can work with on its own, no fine-tuning required. Summarizing a night, searching by meaning, answering questions about the archive all stay possible — that work just happens through an online tool at the last step, not our local one.</p>
</div>

<div class="mc-limit">
<span class="tag">Describing what's in a photo</span>
<p>Without Ollama, the system doesn't write a text description of a photo's content — it won't say what the mood in the room was or what's in the background. It already recognizes performers by face and groups photos into events by when they were taken, which is enough to find the right night and the right person, not enough to get a written account of the shot.</p>
</div>

</div>

## A separate, lighter interface

For a venue, this runs as its own standalone build — a narrow tool for one job, without the extra settings and modes of the full product. The interface is its own too, across three screens:

<div class="mc-screens">
  <div class="mc-screen"><div class="num">01</div><div class="name">New today</div></div>
  <div class="mc-screen"><div class="num">02</div><div class="name">Events and files</div></div>
  <div class="mc-screen"><div class="num">03</div><div class="name">Player with transcript</div></div>
</div>

Click a line of text in the third screen, and playback jumps to that minute.

## Next

A pilot works best directly on a venue's own computer: sort part of what's already piled up, then plug in a few upcoming nights live. That shows both the real size of the backlog and the real processing speed on that exact hardware.
