One person, one record
The same person across separately stored collections and separate drives.
Timeprint DB catalogs large private media collections on Windows. Tag a person once and see everything you've tagged with them, across every collection and every drive. Your tags stay attached when files are renamed, moved or re-copied, and a changed drive letter costs one relocate step.
It never moves, renames or copies your files on its own. It reads; your folders stay exactly as you arranged them.
Drive 2 unplugged. Its four items are still listed, greyed out, with their tags and people.
Demo library. The person is AI-generated.
A machine rebuild renumbers your drive letters. Or you finally consolidate onto a bigger disk. Then the catalog starts reporting duplicates that aren't duplicates, and missing files that are sitting right there.
Years of hand-made tags come loose from the files they described. You re-tag four thousand items by hand over three weekends. After that you stop reorganising your storage. The layout isn't right; touching it just costs too much.
The one part of a collection you can't re-download is the part you made yourself. It shouldn't depend on where the bytes happen to sit.
Sounds familiar? I'd like to hear how it happened to you →The same person across separately stored collections and separate drives.
Tags, people and timepoints stay with the file. No re-tagging, no phantom duplicates.
Disconnecting an external drive doesn't wipe or corrupt the catalog.
Your folders stay as they are. ZIP photo sets stay zipped, where they are.
A collection is a .vdb file plus its cache folder. Copy both to another drive or machine.
Environments: home libraries in one, work in another, or one per client. Each has its own collections, recent files, people and settings, so presenting one shows none of the others' collections, files or people. Out of sight, not locked.
The limit, stated plainly: identity comes from file content, so a rename or a move is invisible to it — but re-encoding a file makes it a new file.
→ A file is recognised by what it is, not where it sits, so identity survives storage changes.
→ Each item stores an absolute and a root-relative path. A new drive letter costs one relocate step.
→ One person record linked into every collection: the person axis across drives.
.vdb file + cache folder→ The catalog moves machines. The cache holds thumbnails, cast photos and scripts, so copy both.
→ The catalog keeps up with the disk, and indexing costs no extra disk space.
→ Find the gaps in your own curation, automate the rest, and let an AI assistant help (below).
People are records, not filter chips: each one has a page with everything you've tagged with them. Cast portraits come from any frame, through a built-in editor with crop, rotate, exposure, shadows, highlights and clarity.
Mark an instant or span a whole scene. Each timepoint has a title, a note, tags and its own thumbnail, drawn as markers under the scrubber, so a three-hour file reads at a glance. They're searchable and taggable like any other item.
A JavaScript API over videos, photosets, cast, global cast, tags and raw SQL, with an editor and live log.
The built-in MCP server lets an AI assistant work on the whole catalog through that API: query it, tag it, link people, tidy it up. Use the assistant you already have, or an open-source model running on your own machine. The server is off by default and listens only on this PC; each assistant gets its own key and limits, and its writes wait for your OK unless you mark that key trusted. With a hosted model, the catalog data it reads goes to that provider; with a local model, nothing leaves the PC.
const hits = db.videos.search({ untagged: true, maxDuration: 60 }); for (const v of hits) db.tags.assign(v.id, 'shorts');
They import, rename to a hash, restructure your folders. Your tags survive. The library you spent years arranging does not.
They respect your folders — until a path changes. Then the catalog and the files quietly drift apart.
It respects everything and outlives every tool, but it can't give you a person axis: the filename is the metadata.
Timeprint DB uses identity derived from file content, kept up to date through every way a file's path can change, while the files stay where they are.
.vdb is a plain SQLite database; any SQLite tool opens it. Exports are keyed by content fingerprint, so your tags can be re-attached to the same files. You're not holding a file only my software can read.You reorganise your drives on a Tuesday afternoon, just because you felt like it. Then you open the catalog and everything is where you left it: still tagged, still linked to the right people.
The archive stops being something you have to be careful around.
If chapter 01 sounded familiar, I want to hear your version. Timeprint DB is built by one person, and so far it's been shaped by one person's collection. Now I need yours: how it's organised, what you can't find, and where the app gets in your way.
Timeprint DB · Windows x64 · one download, no account, and the app sends no telemetry.
v0.2.0 beta · Windows 10/11 x64 · ~203 MB
SHA-256
Choose one you know well — a few hundred items is plenty.
Add a person under Cast and tag them on a few items.
Everything you tagged, from every folder and drive, in one view. Got a second drive? Add a folder from it and watch the page fill in from both.
Free while it's in development. A paid tier later would be a one-off licence, never a subscription — and your .vdb always opens in any SQLite tool.