DEV Community: carl kevin

Transcript cleanup needs an editing policy, not a global filler-word filter

carl kevin — Mon, 14 Sep 2026 09:04:19 +0000

A text-cleaning step can quietly change what a speaker meant. Consider this invented example:

I sent fifteen—no, fifty invitations. Um, I haven’t received a reply.

Removing an empty “um” may fit a clean-verbatim brief. Deleting the self-correction or “haven’t” changes the statement. Treating every repeated word as noise can also erase emphasis or an answer.

Keep the source and the editing policy

For a transcript-processing workflow, keep the source recording and raw transcript alongside the edited reading copy. Write down what your output may remove, how you mark unclear speech, and whether you preserve false starts. Apply that policy before making blanket substitutions.

A useful review sequence:

Compare names, numbers, negation and corrections with the recording.
Keep speaker turns and meaningful short replies.
Mark uncertainty instead of guessing.
Check that punctuation hasn’t created a new meaning.
Label a summary as a summary; don’t present it as verbatim speech.

Treat cleanup as an editorial transformation

“Clean verbatim” and “full verbatim” are not perfectly universal specifications. Agree on the editing brief for the intended reader. A readable meeting note and an oral-history transcript can require different treatment of hesitation and non-speech events. A global regex cannot decide what an utterance means in context.

Disclosure: I work on Wordtake. The full guide has paired examples, source references and a reusable brief:
Clean Verbatim vs Full Verbatim: What Should You Keep?

The examples are invented. This is an editing workflow, not a measured accuracy benchmark. Prepared with AI assistance.

What a Four-Column Social Comment CSV Can—and Cannot—Tell You

carl kevin — Mon, 14 Sep 2026 07:36:02 +0000

Disclosure: This tutorial and its code were prepared with AI assistance by the CommentTok editorial team, which publishes the exporter discussed below. The sample data is fictional, and the code was tested against the included fixture.

A CSV with author, handle, comment, and likes is enough to inspect a captured discussion and identify questions to review. It is not enough to establish complete coverage, recover reply relationships, or count distinct comments across repeated captures.

That distinction belongs in the code, not just a footnote in a report. This tutorial builds a small Python validator that produces a JSON summary, flags possible repeated records, and deliberately leaves coverage as unknown.

What you'll build: A local, read-only CSV analysis script using Python's standard library. It preserves the input, identifies structural problems, and reports repeated handle/text combinations without deleting them.

Start with the schema's actual meaning

This example follows a real browser exporter whose four columns are fixed. It writes UTF-8 with a byte-order mark, surrounds each value with double quotes, and doubles embedded quote characters. The tutorial data below is entirely fictional: anonymous example labels, invented comments, and invented like counts. It contains no captured user data.

Field	Useful interpretation	Unsupported conclusion
`author`	Display name returned with the record	A stable identity
`handle`	Handle string returned with the record	A verified unique person
`comment`	Text available in this capture	A unique comment identifier
`likes`	Like count reported for this row	A measure of all audience opinion

There is no comment ID, parent ID, posting timestamp, source URL, or capture timestamp in this file. A value visible in a product interface does not necessarily exist in its export schema.

The underlying capture can request replies, but the flat file cannot show which parent a reply belongs to. A successful download also says nothing about how much of the original discussion was accessible. Acquisition limits and schema limits are separate problems; fixing one does not fix the other.

Create a deliberately awkward fixture

Save this as example-comments.csv. The line break in the final comment is intentional. Do not flatten it.

author,handle,comment,likes
"Example A","example_a","Does this come in blue, too?","4"
"Example B","example_b","How do I clean it?","2"
"Example A","example_a","Does this come in blue, too?","5"
"Example C","example_c","The label says ""hand wash"".","1"
"Example D","example_d","First line
second line","0"

These five records exercise three parsing cases: a comma inside text, a quoted phrase, and a multiline field. There is also a repeated handle/text pair with different likes.

Do not parse this with line.split(','). The comma in the first comment is part of the comment. Counting physical lines also gives the wrong number of records because the last record spans two lines.

Python's csv documentation recommends opening CSV files with newline=''. DictReader maps fields to header names and leaves values as strings by default. We will convert only the numeric field we intentionally validate.

Validate first, then summarize

Save the following as analyze_comment_csv.py. It uses no external packages and makes no network requests. A Python 3 installation and a terminal are sufficient.

The script reads the file into memory because this is a small-file tutorial. Its SHA-256 fingerprint covers the exact bytes being parsed. A fingerprint identifies a particular byte sequence; it does not prove who collected the file or whether the content is complete.

"""Validate a small four-column CSV and print a bounded JSON summary.

Usage: python3 analyze_comment_csv.py comments.csv
No network calls, third-party packages, or changes to the input file.
"""
import csv
import hashlib
import io
import json
import re
import sys
from collections import Counter
from pathlib import Path

FIELDS = ["author", "handle", "comment", "likes"]


def analyze(path):
    raw = Path(path).read_bytes()
    stream = io.StringIO(raw.decode("utf-8-sig"), newline="")
    reader = csv.DictReader(stream, strict=True)
    if reader.fieldnames != FIELDS:
        raise ValueError("Expected exactly: author,handle,comment,likes")

    rows = []
    for record_number, row in enumerate(reader, start=1):
        if None in row or any(value is None for value in row.values()):
            raise ValueError(f"Record {record_number}: wrong number of fields")
        if not re.fullmatch(r"[0-9]+", row["likes"]):
            raise ValueError(f"Record {record_number}: likes must be a nonnegative integer")
        rows.append(row)

    candidates = Counter((row["handle"], row["comment"]) for row in rows)
    return {
        "sha256": hashlib.sha256(raw).hexdigest(),
        "rows": len(rows),
        "distinct_nonempty_handle_strings": len({r["handle"] for r in rows if r["handle"]}),
        "blank_handle_rows": sum(not r["handle"] for r in rows),
        "blank_comment_rows": sum(not r["comment"].strip() for r in rows),
        "likes_sum_across_rows": sum(int(r["likes"]) for r in rows),
        "repeated_handle_text_groups": sum(n > 1 for n in candidates.values()),
        "extra_rows_in_repeated_handle_text_groups": sum(n - 1 for n in candidates.values()),
        "deduplication_performed": False,
        "coverage": "unknown",
    }


if __name__ == "__main__":
    if len(sys.argv) != 2:
        raise SystemExit("Usage: python3 analyze_comment_csv.py comments.csv")
    try:
        result = analyze(sys.argv[1])
    except (OSError, UnicodeError, csv.Error, ValueError) as exc:
        raise SystemExit(f"Cannot analyze CSV: {exc}")
    print(json.dumps(result, indent=2))

Three choices are worth keeping when adapting this:

Require the expected header. An unexpected delimiter, renamed field, extra column, or missing file header should not silently produce a convincing summary.
Validate numeric strings. An empty or malformed like count triggers an error instead of becoming a guessed zero. This tutorial's contract accepts nonnegative integer strings only.
Count candidates without removing them. Matching a handle and comment text is a review signal. It is not proof of duplicate identity.

The utf-8-sig decoder accepts ordinary UTF-8 and skips an initial UTF-8 byte-order mark when present. That matters when matching the first header exactly. See Python's encoding documentation.

Run it and interpret the output

python3 analyze_comment_csv.py example-comments.csv

Besides the file fingerprint, the output should contain:

{
  "rows": 5,
  "distinct_nonempty_handle_strings": 4,
  "blank_handle_rows": 0,
  "blank_comment_rows": 0,
  "likes_sum_across_rows": 12,
  "repeated_handle_text_groups": 1,
  "extra_rows_in_repeated_handle_text_groups": 1,
  "deduplication_performed": false,
  "coverage": "unknown"
}

Those values describe only the fictional fixture. The script intentionally says “handle strings” rather than “people” and “likes sum across rows” rather than “total engagement.” If the same comment appears twice, adding its reported counts can double-count activity. Conversely, two identical texts from the same handle could be separate postings.

Consider the first and third rows. There are at least two plausible explanations: one comment was captured twice as its like count changed, or the same account posted the same question twice. Nothing in these four columns resolves that ambiguity. Keeping whichever row has more likes would impose an assumption, not discover the truth.

Even exact matches across all four columns do not solve it. Separate comments can share all four values. The correct action depends on your analysis goal and additional evidence, which is why this script never drops rows automatically.

Add provenance before combining files

Keep the original export unchanged. For each capture, maintain a small companion record with its source video URL, collection time including time zone, file fingerprint, and any status message or limitation noticed during collection.

If you create a combined working table, carry that capture metadata onto each row. Use a local key such as (file_fingerprint, record_number) to find the row again in your saved material. This locates a record in a file; it is not a platform comment ID.

Do not fill a missing collection time with today's time and label it “captured at.” Record it as unknown, or distinguish the time you received the file from the time the original capture occurred. Neither value substitutes for the comment's posting time.

For larger inputs, you could stream records and hash the input while reading. That is a separate engineering improvement; it does not remove the need to define provenance and identity.

Add themes through an explicit review process

For a small set, a human review column can be more useful than immediately adding an automatic sentiment model. Define labels against a concrete question, keep the original text, and include an “unclear” label.

In the fictional fixture, possible themes include “available colours,” “care instructions,” and “needs context.” Decide whether multiple labels are allowed before counting them. If one row can have two labels, the sum of theme counts may exceed the number of rows; that is acceptable when reported clearly.

Avoid a rule that labels every comment containing a question mark as a buying objection. A question can ask for instructions, make a joke, or refer to an absent parent comment. Missing context remains missing even when a classifier produces a confident answer.

Report the unit you actually reviewed: for example, “five rows in this fixture.” Do not silently convert rows into distinct comments, handles into people, or the captured set into the entire audience.

Keep text as data throughout the workflow

The Python script parses strings and prints only aggregate JSON; it never evaluates comment text. This does not certify the original CSV as safe for every downstream application.

If you open unfamiliar comments in a spreadsheet, use an import path that preserves the text fields as literal text instead of allowing formula interpretation. CSV quotation protects field boundaries. It is not the same operation as preventing spreadsheet formulas. This exporter does not claim to sanitize formula-like values.

Before trusting a new file, check that malformed numeric values fail, multiline comments remain single records, and candidate repeats remain in the original. The useful output is a summary whose boundaries are visible enough for the next person to assess.

Written by the CommentTok editorial team. Product affiliation: the team publishes the exporter discussed here. This article and code were prepared with AI assistance. All sample rows and sample metrics are fictional; the code was run against the included fixture. This is a standalone technical tutorial.

SRT to text: preserve spoken numbers, not just clean formatting

carl kevin — Sat, 12 Sep 2026 11:07:45 +0000

A subtitle-to-text export can look clean while silently deleting part of the speech. The risky shortcut is removing every numeric line: a line containing 42 may be a spoken answer, not a cue identifier.

Treat the file as structured cues before deciding what to remove.

What a safe conversion preserves

This invented SRT example contains two cues:

1
00:00:01,000 --> 00:00:03,000
We reviewed 42 applications

2
00:00:03,000 --> 00:00:05,000
before the Friday meeting.

The reading copy becomes:

We reviewed 42 applications before the Friday meeting.

The cue identifiers and timing ranges disappear. The spoken number stays. The sentence boundary comes from the speech, rather than from the blank line between cues.

For a conversion pipeline, keep an untouched source file and make these checks explicit:

Recognize cue boundaries, sequence metadata, and timing lines before extracting text.
Preserve numeric text inside a cue's payload.
Keep speaker labels and meaningful sound descriptions.
Join fragments only when they belong to the same sentence and speaker turn.
Flag repeated passages for review rather than deleting them unconditionally.
Compare the opening, ending, names, and numbers against the recording.

An export from a caption editor is a useful starting point, but the result still needs inspection. A renamed .txt file has not undergone a structural conversion.

WebVTT needs its own handling

A file beginning with WEBVTT is not simply SRT with different punctuation. MDN documents cue identifiers, timing settings, and NOTE, STYLE, and REGION blocks. A timestamp-only replacement can leave those blocks in the transcript. Voice annotations may carry speaker information that should become a readable label.

Use a format-aware parser or export tool, then inspect examples with speaker changes and formatting. See MDN's WebVTT format reference.

Keep a path back to the recording

A reading copy can omit most timestamps. A reference copy can retain an occasional timestamp at a speaker turn or section boundary. Keep the original caption file either way: it makes an uncertain phrase much easier to locate.

W3C WAI also explains that turning captions into a descriptive transcript may require adding visual information. If a presenter says “choose this setting,” check the picture and label the editorial description separately from the spoken words. See WAI's transcript guidance.

Disclosure: I work on Wordtake. The full SRT-to-text workflow and review checklist covers source versions, reading copies, speaker changes, encoding checks, and publication. This is an editing workflow for existing subtitle files; it does not claim the product imports them.

How to Proofread an AI Transcript: A Three-Pass Checklist

carl kevin — Wed, 09 Sep 2026 10:52:08 +0000

An AI transcript can look clean while still being wrong in the places that matter. A missing not, a swapped speaker, or a plausible spelling of the wrong company name may survive an ordinary read because the sentence remains grammatical.

Use three separate passes instead of trying to fix everything at once.

Pass one: structure, speakers, and meaning

Read the complete transcript before polishing sentences. Look for missing sections, duplicated passages, abrupt topic jumps, and timestamp gaps. Confirm speaker changes wherever identity affects meaning.

Replay sentences containing negation, comparison, permission, obligation, or uncertainty. Words such as not, only, before, after, can, and cannot can reverse a decision. Preserve later corrections instead of presenting both versions as equally current.

Pass two: names, numbers, and technical terms

Create a verification list for every person, company, product, place, publication, and event. Check participant lists, slides, official websites, or material supplied by the speaker. Watch for ordinary words that may actually be proper nouns.

Search for every digit and number word. Replay each one and capture the unit, currency, percentage sign, or time period that gives it meaning. If figures do not add up, preserve the spoken wording and add an editorial query instead of inventing a correction.

Collect uncertain technical terms and verify them using documentation, slides, code, product interfaces, or a subject-matter reviewer. Do not expand an acronym unless the recording or an authoritative source supports it in that context.

Pass three: prepare for the destination

Only after factual review should you improve punctuation, paragraph breaks, and obvious verbal clutter. Searchable meeting notes can be concise; a research transcript may need close fidelity; a published quotation must remain traceable to the recording.

For captions, review timing and line breaks in the actual player. For articles and newsletters, retain source timestamps in working notes even if readers will not see them.

Finish with the passages that carry the most consequence: headlines, quotations, decisions, tasks, prices, deadlines, claims, and calls to action. Record who reviewed the transcript, what was checked, and which timestamps remain uncertain.

Read the complete checklist on Wordtake: https://wordtake.app/pages/blog/proofread-ai-transcript-checklist

How to Repurpose a Webinar into a Newsletter and Short Clips

carl kevin — Mon, 07 Sep 2026 23:41:20 +0000

A webinar can produce more than a replay link when its source material is easy to revisit. Keep the original recording, slides, chat export, speaker names, and a complete timestamped transcript together.

Start with a complete, timestamped source

Generate the transcript before choosing highlights. Review names, product terms, dates, prices, URLs, statistics, and specialist vocabulary against the recording.

Choose one audience and one outcome

A newsletter can help attendees remember the main decision; a short clip can introduce one practical idea to people who missed the live session. Give each output a one sentence job before drafting.

Find moments that stand on their own

Search for moments with a clear beginning, explanation, and conclusion. Read each candidate with the surrounding exchange and verify it against the recording.

Edit for context before speed

Create captions from the reviewed transcript and watch the final clip with captions enabled. Check names, numbers, timing, speaker changes, and on screen text.

Keep an asset record

Track asset type, audience, source timestamps, transcript status, owner, channel, approval status, and published URL. Linking every derivative to the recording makes corrections and future reuse faster.

Read the complete workflow on Wordtake: https://wordtake.app/pages/blog/repurpose-webinar-into-newsletter-and-clips

SRT vs VTT: Choosing a Caption Format for Web and Editing Workflows

carl kevin — Sat, 05 Sep 2026 07:02:18 +0000

SRT and VTT both pair spoken words with time ranges, but they solve slightly different delivery problems. The right choice depends on where the file will be consumed.

The short answer

Use SRT for a portable subtitle handoff or a tool that expects numbered cues. Use VTT for a browser-based player or a workflow that needs WebVTT text-track features. If one reviewed recording is going to several destinations, keep one source transcript and export both formats at the end.

SRT: a simple, portable cue list

An SRT file normally contains a sequence number, a time range, and one or more lines of text:

1
00:00:01,000 --> 00:00:03,500
Choose the format from the destination backwards.

The plain structure makes SRT easy to inspect in a text editor and easy for an editor, translator, or client to repair. It is a practical default when the receiving system only needs text and timing. Presentation details such as positioning are usually handled by the video editor or player rather than by the file itself.

VTT: timed text for the web

A WebVTT file begins with a WEBVTT header and uses timed cues:

WEBVTT

00:00.000 --> 00:02.500
Choose the format from the destination backwards.

VTT is designed for web text tracks and can carry optional cue identifiers, cue settings, regions, and limited text markup when the target player supports them. That makes it a natural fit for an HTML5 video or audio player. It also gives you more syntax to validate: the header, blank lines, time format, cue order, and optional settings all matter.

A practical decision guide

Choose SRT when:

an editor or upload form explicitly requests SRT;
people need to review or repair the file in plain text;
the workflow needs a simple, numbered subtitle handoff.

Choose VTT when:

a browser player will load the file as a text track;
you need web-oriented cue settings or regions;
the integration is built around HTML5 video or audio.

Use both when the reviewed recording has multiple destinations. There is little value in forcing one delivery file to serve every system when both derivatives can come from the same source.

Validate before delivery

Format conversion should happen after content review. Listen again to names, numbers, technical terms, negations, and any sentence that carries a claim. Then check timing at the beginning, middle, and end of the recording. Watch for cues that start too early, end too late, flash too quickly, or leave a gap while someone is speaking.

For SRT, inspect cue numbering, time separators, blank lines, and readable line breaks. For VTT, inspect the WEBVTT header, cue order, time syntax, and any settings supported by the destination player. Finally, test the actual file in the editor or browser player that your audience will use.

Keep one source of truth

SRT and VTT are delivery choices, not separate versions of what happened. Keep one reviewed transcript beside the source recording, then generate the format required by each destination. When a correction is made, update the source and regenerate both derivatives so captions, quotes, notes, and translations do not drift apart.

A longer workflow guide, including a pre-upload checklist, is available on Wordtake: https://wordtake.app/pages/blog/srt-vs-vtt-caption-format