Knowledge work with recordings

Using Transcripts in a Personal Knowledge Base Without Drowning in Them

Transcripts belong in a personal knowledge base as sources, not as notes. Keep each transcript as a plain-text file you can search, then write short notes in your own words, one idea per note, each with a timestamp that points back to the exact moment in the recording. Link those notes to related ideas. The transcript is raw material; the notes are what you will use.

9 min read · Updated

The trap: a folder of transcripts you never read

Transcribing is easy, which is exactly the problem. It takes a few minutes to turn a 90-minute podcast into 15,000 words of text, and no time at all to save it into your notes app. Six months later you have eighty transcripts, a search box that returns thirty hits for every query, and no clearer thinking than before.

A transcript is someone else's words in the order they happened to say them, with digressions, repetitions and filler. Saving it is collecting. Knowledge work begins when you pull out the few ideas worth keeping and write them in a form your future self can use. The method below keeps both: the full transcript for reference and search, and a small number of notes that do the work.

Plain text first

Store transcripts and notes in formats that will outlast any particular app. Plain .txt files and Markdown (plain text with light symbols for headings, lists and links) open in every editor on every operating system, are searchable by every tool, and will still be readable decades from now.

Some note apps, such as Obsidian and Logseq, keep notes as Markdown files in an ordinary folder on your disk, so transcripts can sit in the same folder structure. Others store notes in their own database and import text; that works too, but check how easily you can export everything before committing years of notes to it.

Which transcript formats to keep:

Plain transcript
Readable text for skimming and searching. The main source file.
Timestamped transcript
Each passage with a time label. The file you use to cite moments.
Subtitle files
Short timed fragments made for video players. Useful for captions, awkward for reading, so usually leave them out of your notes folder.

Source notes and idea notes

A two-layer structure prevents the pile-up. The first layer is one source note per recording. The second layer is idea notes, each holding one thought you want to keep.

A source note is short. It records what the recording is, where to find it, and what you took from it:

  • Title, speaker or host, date, and a link to the original or the file name
  • A link to the transcript file in your sources folder
  • Two or three sentences on why you listened and what you thought
  • Links to every idea note you created from it

The transcript itself can live in a sources or attachments folder. Keeping it there means a vault-wide search still finds a half-remembered phrase, but it does not crowd your idea notes. If transcript text floods your search results, many apps let you exclude a folder from search by default and include it when you need it.

One idea per note, in your own words

An idea note holds a single claim, concept, method or question, written so it makes sense on its own a year from now without rereading the source. This approach, sometimes called atomic notes and associated with the Zettelkasten method, has its critics; some people find it too fragmented and prefer longer topic notes. The principle that survives either way is that notes should be in your own words and small enough to reuse.

Writing in your own words is the step that cannot be skipped. Copying a paragraph from a transcript feels productive but leaves you with a quote you have not understood. Read the passage, look away, write what it means and why it matters to you, then check the transcript to make sure you did not distort it.

Quote directly only when the exact wording matters: a memorable line, a definition, a claim you may need to attribute. Mark quotes clearly, and check them against the audio first, because a machine transcript may have a word wrong. If you might use the quote in published work, the conventions in citing video and audio with timestamps are worth following from the start.

Timestamps as source references

Every idea note should point back to the moment it came from. A file name and a time is enough:

  • Source: 2026-04-02_podcast-ep41_interview-nakamura, 23:15
  • Source: product-strategy-talk-2025.mp4, 1:04:30 to 1:06:10

When you come back to the note, the timestamp lets you hear the original in context in under a minute, which matters for checking tone, qualifications and what the speaker said just before. If the recording is online and the platform supports links that start at a set time, store that link as well. Use the time label from the timestamped transcript, then start listening a little earlier so you catch the setup.

This is also what keeps your knowledge base honest. A note without a source becomes, over time, something you "know" but cannot trace. A note with a timestamp can always be checked.

Linking notes so ideas meet

The value of a personal knowledge base grows with the connections between notes, not the number of them. When you write an idea note, ask two questions: what does this remind me of, and where would I want to find it again?

  • Link to existing notes that support, contradict or extend the idea. A short phrase saying why the link exists ("contradicts", "an example of") makes it more useful later.
  • Keep a handful of index notes, sometimes called maps of content, that list links to notes on a broad subject. They are easier to maintain than elaborate folder hierarchies.
  • Use tags sparingly, for status or type (to-check, quote, method) rather than for topics, which links handle better.
  • Link back to the source note so every idea can be traced to its recording.

Linking is where transcripts from different sources start talking to each other. An idea from a podcast interview in April and a remark in a conference talk in October end up next to each other because you linked them, not because you remembered both.

A processing routine that keeps up

The difference between a useful system and a graveyard is a routine with limits.

  1. Transcribe only what you intend to process. If you will not spend twenty minutes with it, do not transcribe it.
  2. Put new transcripts in an inbox folder and create the source note immediately, even if it only holds the title and link.
  3. Skim the transcript within a week, highlighting passages worth a note. Skimming is much faster than listening; the method in reviewing long recordings quickly helps on long episodes.
  4. Write idea notes for the highlights, usually somewhere between two and eight per recording, each with its timestamp.
  5. Link each note to at least one existing note, and list the new notes in the source note.
  6. Move the transcript to the sources folder. If a transcript sits in the inbox for a month, ask honestly whether to delete it.
From a 90-minute podcast to six notes

A hypothetical consultant listens to a 90-minute interview with an operations expert. She transcribes the episode, skims the transcript in fifteen minutes, and highlights five passages. She writes six idea notes, including "Queue length is a better early warning than utilization" with a source line pointing to 37:20, and links it to an older note from a book on lean manufacturing. Three weeks later, preparing a client workshop, she searches her notes for "early warning", finds the note, clicks to the source, and listens to two minutes at 36:50 to get the expert's exact example right.

Pitfalls and limits of transcript-based notes

  • Saving transcripts as notes. They clutter search and give a false sense of having learned something.
  • Summarizing everything. A summary of every episode is another pile. Extract ideas you will reuse, and skip the rest.
  • Trusting the transcript blindly. Names, numbers and technical terms are the most common recognition errors, so check them before they become part of a note.
  • Losing the speaker. Machine transcripts often have no speaker labels. In an interview, note who said each idea when you write it, using the recording to confirm.
  • Building the system instead of using it. Templates, plugins and folder schemes are pleasant to tinker with. A few plain notes with good links beat an elaborate empty structure.
  • Copyright and privacy. Keeping transcripts of public talks for personal study is common practice, but publishing them or sharing transcripts of private conversations is different. Check the rights and get consent where needed.

Students turning lectures into revision material have a more structured need than general note-taking; turning lecture videos into study notes covers that case.

Where mydubly fits in a notes workflow

mydubly makes the transcript files. You choose a video or audio file from your device (common video formats such as MP4, MOV and WebM, and audio such as MP3, M4A and WAV), up to 2 hours long, and download a plain transcript.txt, a timestamped transcript with [m:ss] labels, and SRT and VTT subtitles. Both text files drop straight into a Markdown notes folder. The spoken language is detected automatically, and if the recording is in a language you read less comfortably, you can add a translated transcript in the same job and keep both versions as sources. The video to text page covers video, and audio to text covers podcast and voice-memo files.

mydubly does not summarize, extract ideas, link notes or store anything for you. Results are deleted within 30 minutes of a job finishing, so save them into your sources folder right away. There is no URL import, so you need the file itself, and the browser tab must stay open while a job runs. Transcription costs 1 credit per minute with a 5-credit minimum per file, so a 90-minute episode is 90 credits (9¢).

Next step: process one recording end to end

Pick one recording you already meant to learn from. Transcribe it, create the source note, skim, write no more than five idea notes with timestamps, and link each to something you already have. If you mostly work from podcasts, the podcast transcription use case covers getting episode files into text. Judge the system by whether you use those five notes in the next month, not by how many transcripts you have saved.

Frequently asked questions

Should I paste full transcripts into my notes app?

Keep them, but not as notes. Store each transcript as a file in a sources folder linked from a short source note, and write separate idea notes in your own words. That way search can still reach the full text without burying the notes you actually use.

Which file format suits transcripts in a knowledge base?

Plain text or Markdown. Both open in any editor, are searchable everywhere and do not depend on a single app. Keep the timestamped version as well as the plain one, because the time labels are what let your notes point to exact moments.

How many notes should I make from one recording?

There is no right number, but most recordings yield only a few ideas you will reuse. Writing a note for every point the speaker made recreates the transcript in smaller pieces. If you cannot say why you would want a note again, skip it.

How do I cite a moment in a video in my notes?

Record the file name or title, the date and the time from the timestamped transcript, and a time-coded link if the video is online and the platform supports one. Start listening slightly before the time label when you revisit it, so you hear the context.

Can I use AI summaries instead of reading the transcript?

A summary can help you decide whether a recording is worth processing, but it is not a substitute for writing your own notes. Summaries drop qualifications and can state things the speaker did not say, so check any point you keep against the transcript and the audio. mydubly does not produce summaries.

What about recordings in other languages?

Transcribe them in the original language and, if useful, add a translated transcript in the same mydubly job. Write your idea notes in the language you think in, and keep the original-language transcript as the source for checking quotes, since translation can shift nuance.