DEV Community: WgeorgeAssistantIA

How to Reduce AI Hallucinations When Extracting Information from Videos

WgeorgeAssistantIA — Thu, 05 Nov 2026 12:17:09 +0000

When a language model reads a transcript and returns a list of tools, two kinds of mistakes appear. The first is invention: a tool that was never mentioned. The second is subtler: a real tool paired with the wrong link or the wrong meaning. Both erode trust. This post lists the techniques that helped us reduce them, and the numbers we saw, with the caveat that our samples are small.

Mistake 1: tools that were never said

The cure is to make the model show its evidence and to check it with code.

Require a verbatim quote for every extracted item
Check that the tool's name appears in the transcript, and drop the item if it does not
Check the quote and the timestamp against the transcript too, and remove whichever cannot be found, so nothing unverified is shown as evidence

A caution: a naive check of the form "the tool name must appear in the transcript" can reject real tools when captions split or respell them (a product written as FastAPI may appear as "fast API"). Match names with some tolerance, and log rejections so you can see whether you are throwing away good results.

Mistake 2: real tools, wrong meaning

This one surprised us. In one test run on twenty technical videos, a large share of the official links our resolver returned were wrong. A database called Neon led to a cinema studio. An assistant called Serena led to a tennis player's website. Codex led to a food-safety standard. The model had named the tools correctly; the failure was in resolving ambiguous names with a web search.

What fixed most of it:

Add context to the query: include the category and a short description of the tool, not just its name
Accept canonical repositories: many CLI and open-source tools have no website, only a GitHub repo
Block unreliable sources as official: aggregators, course platforms, forums, social networks
Score and threshold: compute a confidence for each match, and reject anything below a threshold
Return nothing when unsure: an empty field is honest, a wrong link is not

Improve the prompt, then measure

Prompts matter. We rewrote ours with an explicit definition of what counts as a tool, a list of exclusions and an instruction to quote verbatim. On four videos of very different lengths, from 47 minutes to over 7 hours, and labelling the results by hand, precision moved from about 89 to about 96 percent and recall from about 76 to about 93 percent. Those are indicative figures: four videos, one run each, a model with some randomness. Treat them as direction, not proof.

The point is the method: label a small set by hand once, then re-run it after every prompt change, so you notice regressions.

Don't hide partial results

A different kind of hallucination is silent partial coverage. If the transcript is too long and you truncate it, the output looks complete but only reflects the beginning. We hit this: a seven-hour video was analysed on its first twelve minutes. The fix was to process the whole transcript in chunks and to report coverage explicitly, with a warning when an analysis is partial.

A short checklist

Name found in the transcript, quote required, quote verified
Context in link resolution
Confidence threshold, with None as a valid answer
A small labelled set to catch regressions
Honest coverage reporting

Where this led

We applied these rules in VidScope, which lists the tools mentioned in a YouTube video with timestamps and official links, and prefers no link to an uncertain one.

FAQ

Can hallucinations be eliminated?
No, but requiring and verifying evidence reduces them a lot.

Why return nothing instead of a best guess?
A wrong link looks authoritative; an empty field tells the user to check.

How do I measure accuracy on a small project?
Label a few videos by hand and re-run them after every change, while remembering the sample is small.

Audio Crossfading in Python: Eliminating Pops and Clicks at Edit Points

WgeorgeAssistantIA — Mon, 02 Nov 2026 12:15:45 +0000

When you automatically remove silences from speech or podcast recordings, you cut hundreds of audio slices and stitch them back together.

If you do this naively by simply concatenating raw audio arrays:

# Naive concatenation: guaranteed audio artifacts
clean_audio = np.concatenate([segment_a, segment_b])

Your output will be riddled with audible clicks, pops, and ticks. Every single edit point sounds like a tiny vinyl scratch.

Here is why naive concatenation fails, what a linear crossfade fixes (and what it doesn't), how an equal-power crossfade works in NumPy, and what we actually ship in VoxCut.

Why Edit Points Pop: Amplitude Discontinuities

Digital audio is a sequence of samples (e.g. 44,100 per second), each one an amplitude between -1.0 and +1.0.

When you cut audio, you almost never cut at an exact zero-crossing (a sample where the amplitude is 0.0):

Segment A ends at an amplitude of +0.42.
Segment B begins at an amplitude of -0.31.
Concatenating them creates a jump of 0.73 between two consecutive samples (1/44100th of a second apart).

A step like that has energy spread across the whole audible spectrum. The speaker cone is asked to move almost instantly, and you hear it as a click.

Linear Crossfades: The Midpoint Dip

The first instinct is to overlap the two segments for a few milliseconds and apply a linear crossfade:

Segment A fades out linearly from 1.0 to 0.0
Segment B fades in linearly from 0.0 to 1.0

# Linear crossfade weights
t = np.linspace(0, 1, fade_samples)
fade_out = 1.0 - t
fade_in = t

This kills the click: there is no longer a step anywhere. But for two uncorrelated signals (two different moments of speech), what adds up is power, not amplitude:

Power = A^{2} + B^{2}

At the exact midpoint of a linear crossfade (t = 0.5):

Power = (0.5)^{2} + (0.5)^{2} = 0.50 (\approx - 3 dB)

On long fades between two loud signals, that dip can be heard as a small "breathing" in the volume.

The Theory Fix: Constant-Power (Sine/Cosine) Crossfade

To keep the energy constant across uncorrelated material, use trigonometric curves:

Fade Out (t) = cos (\frac{π}{2} t), Fade In (t) = sin (\frac{π}{2} t)

Because $sin^{2} (x) + cos^{2} (x) = 1$ , the summed power stays at 1.0 for every sample of the transition.

A NumPy Implementation

Here is a self-contained function that splices two buffers with an equal-power crossfade:

import numpy as np

def equal_power_crossfade(seg_a: np.ndarray, seg_b: np.ndarray, fade_ms: float = 20.0, sample_rate: int = 44100) -> np.ndarray:
    """
    Crossfades the end of seg_a into the beginning of seg_b using constant-power curves.
    Supports 1D (mono) and 2D (stereo: samples, channels) arrays.
    """
    fade_len = int((fade_ms / 1000.0) * sample_rate)

    # No room for a fade (or fade disabled): plain splice.
    # Note: seg_a[:-0] would return an EMPTY array, hence the fade_len <= 0 check.
    if fade_len <= 0 or len(seg_a) < fade_len or len(seg_b) < fade_len:
        return np.concatenate([seg_a, seg_b])

    # Normalized time vector [0.0, 1.0]
    t = np.linspace(0.0, 1.0, fade_len)

    # Constant-power weights
    w_out = np.cos(0.5 * np.pi * t)
    w_in = np.sin(0.5 * np.pi * t)

    if seg_a.ndim == 2:
        # Broadcast over stereo channels
        w_out = w_out[:, np.newaxis]
        w_in = w_in[:, np.newaxis]

    # Overlapping region
    overlap = (seg_a[-fade_len:] * w_out) + (seg_b[:fade_len] * w_in)

    # Assemble: A (prefix) + overlap + B (suffix)
    return np.concatenate([
        seg_a[:-fade_len],
        overlap,
        seg_b[fade_len:]
    ])

Swap the two weight lines for w_out = 1.0 - t and w_in = t and you have the linear version.

What VoxCut Actually Ships (and Why It's Linear)

Honest disclosure: VoxCut's desktop export does not use the equal-power curve above. It uses a 40 ms linear crossfade (the equivalent of FFmpeg's acrossfade=c1=tri:c2=tri).

Why that's good enough for silence removal:

The edges we join are the quiet tails of speech around a removed pause, not two loud musical passages. A -3 dB dip at the midpoint of a 40 ms fade between two near-silent edges is inaudible in practice.
What matters is removing the step, and a linear ramp does that just as well as a sine curve.
If any kept segment is shorter than two fade lengths (80 ms), the export falls back to plain cuts rather than fading into a sliver of audio.

If you crossfade music, or long fades between two loud signals, equal-power is the safer default.

The Performance Lesson

Our first version built an FFmpeg filter_complex graph: one atrim per segment plus a chain of N acrossfade filters. On a dense podcast (~870 cuts in 2 hours), that graph became the bottleneck: FFmpeg re-read the input for every segment.

The current version does it in a single pass:

One FFmpeg process decodes the file to raw f32le PCM on stdout.
Python reads it in 1-second chunks, skips the silent ranges, and applies the fade ramps in NumPy.
A second FFmpeg process encodes from stdin.

On a 30-minute podcast, this was about 50x faster than the filter graph in our benchmark. The old graph is still there as a fallback if the streaming path fails.

Critical Gotcha: The Cumulative Length Shrink

Each overlap crossfade consumes fade_len samples, because the two segments overlap in time.

If your silence detector finds 600 cuts in a 45-minute episode and you apply a 40 ms crossfade at each join:

600 \times 40 ms = 24 seconds

For an audio-only podcast, nobody cares. But if that audio has to stay in sync with video, you are 24 seconds out of sync by the end. (That's why VoxCut skips the overlap crossfade entirely on video exports.)

The Video-Safe Rule

When timeline sync matters, apply micro-fades at the boundaries without overlapping:

Fade out the last ~5 ms of segment A to zero.
Fade in the first ~5 ms of segment B from zero.
Concatenate without overlapping time indices.

The step disappears (both sides meet at zero), and in speech a 5 ms dip is very hard to notice.

Conclusion

Clicks at edit points are not caused by bad microphones. They come from cutting waveforms that are not at zero.

Never splice raw arrays at arbitrary indices.
A short crossfade removes the click; linear is fine for speech edges, equal-power is better for music and long fades.
Use non-overlapping micro-fades when you must keep the timeline in sync with video.
If you have hundreds of cuts, avoid giant FFmpeg filter graphs: stream PCM through Python instead.

That's the pipeline behind VoxCut's "smooth transitions" option. If you're building your own silence remover, I'd love to hear how you handle edit points.

From YouTube Transcript to Structured Technical Knowledge

WgeorgeAssistantIA — Tue, 20 Oct 2026 13:56:02 +0000

A transcript is a wall of text. A knowledge base is a set of records you can query. This post is about the part in between: designing the data model that turns one into the other, so the result is searchable, checkable and mergeable across videos.

Start from the questions you want to answer

Before choosing a schema, list the questions a user will ask later:

Which tools were mentioned in this video?
Where exactly, so I can listen to it?
Was it recommended, compared or criticised?
What is the official source?
Which videos mention the same tool?

Each question maps to a field. If a field has no question behind it, leave it out.

A minimal record

{
  "name": "Supabase",
  "aliases": ["supabase"],
  "category": "database",
  "role": "backend and authentication",
  "mention": "used",
  "evidence": [
    { "quote": "we use Supabase for auth and the database", "start": 761 }
  ],
  "official_url": "https://supabase.com"
}

Three design choices are worth explaining.

Store seconds, not strings. Keep the timestamp as a number of seconds. Format it for display later (00:12:41) and build deep links from it (?t=761). Strings like "12:41" break as soon as a video passes one hour.

Keep the quote. The quote is your audit trail. It lets a human confirm the claim in five seconds and lets your code reject records whose quote is not actually in the transcript.

Separate name and aliases. Videos say "Postgres", "PostgreSQL" and "Postgres DB". Normalise to one canonical name and keep the variants for matching.

Merging chunks without duplicating

Long transcripts are processed in chunks, so the same tool appears several times. Merge on a normalised key: lower-case the name, strip punctuation and common suffixes, then group. When merging, keep all evidence entries and the earliest start time, and take the most specific category. Rare conflicts, such as two categories for the same name, are worth logging instead of resolving silently.

Validating before you trust

Run a few cheap checks on every record:

The timestamp falls inside the video's duration
The quote appears in the transcript near that timestamp
The name is not on a block list of generic words ("API", "cloud", a channel's own name)
The URL, if present, passes the same validation as the name

Records that fail go to a rejected list with the reason. Looking at the rejected list is the fastest way to improve your prompt.

Making it usable

Once records are clean, the value comes from presentation. Sort by first appearance so the list follows the video. Make every timestamp a link. Group by category. Offer an export, because people will paste the result into their own notes.

Where VidScope fits

Everything above is what we ended up building in VidScope, an experiment in turning technical YouTube videos into structured, timestamped lists of tools. The schema above is simplified, but the principles are the same: seconds not strings, quotes as evidence, and validation before display.

FAQ

Why store timestamps as seconds?
They are unambiguous, sortable and easy to turn into deep links and display formats.

How do I deduplicate tools across chunks?
Normalise names (case, punctuation, suffixes) and merge records while keeping all evidence.

Why keep the quote?
It is the proof: it lets a human check the claim quickly and lets code reject records not present in the transcript.

Committed Memory Above RAM Doesn't Mean Your PC Is Swapping

WgeorgeAssistantIA — Wed, 14 Oct 2026 05:37:47 +0000

One rule in my Windows diagnostic tool said: "Your PC is compensating for missing RAM by using the disk." The condition behind it was one line: committed memory is greater than physical RAM.

On my own machine, that line was true. And my PC was fine.

This post explains why "commit > RAM" proves nothing, and what I measure instead.

What the first version did

The rule read two numbers and compared them:

committed memory (what Windows has promised to processes)
total physical RAM

If the first was larger than the second, it flagged "swap in use" and suggested more RAM or fewer programs.

It sounded reasonable. It was wrong.

Why commit is the wrong signal

Committed memory is memory that has been reserved, not memory that is being used. A process can reserve a lot and touch very little of it. Browsers are the typical example: they reserve large regions up front.

So commit can exceed RAM on a perfectly healthy machine, with no page ever read back from the disk.

There is a second reason. Commit is charged against the commit limit, which is RAM plus the pagefile. A machine with a large pagefile can commit far more than its RAM by design, so commit > RAM was never a pressure signal on its own. (Thanks to Kai for pointing this out in the comments.) In the rule below it is only a precondition: the other two conditions do the real work.

Here is what my own PC showed on September 24:

Committed memory: 22.5 GB
Physical RAM: 15.9 GB
Available RAM: 24 %
Pages read from disk to serve memory: 0.4 per second

Commit was well above RAM. The disk was almost idle. The rule fired anyway.

What actually shows a PC is compensating on disk

The real signal is the hard page fault rate: pages that Windows has to read from disk because the data it needs is no longer in RAM. The counter is Pages Input/sec.

I read it twice, at the start and at the end of my measurement window, and divide the difference by the elapsed time. It is a raw cumulative counter, so one reading alone tells you nothing:

$m1 = Get-CimInstance Win32_PerfRawData_PerfOS_Memory
Start-Sleep -Seconds 8
$m2 = Get-CimInstance Win32_PerfRawData_PerfOS_Memory

$seconds = ($m2.Timestamp_Sys100NS - $m1.Timestamp_Sys100NS) / 1e7
$pagesPerSec = ($m2.PagesInputPersec - $m1.PagesInputPersec) / $seconds

One detail that cost me time: I use the WMI class, not Get-Counter. Counter names are translated according to the language of Windows, so a script that works on an English install can fail silently on a French one. The WMI class property names stay the same.

Two thresholds, and why there are two

The new condition needs three things together:

$SEUIL_PAGES_DISQUE   = 100   # pages/s read from disk for memory
$SEUIL_RAM_DISPO_SWAP = 25    # % of RAM available

if ($commitGb -gt $ramTotalGb -and
    $pctRamAvailable -lt $SEUIL_RAM_DISPO_SWAP -and
    $null -ne $pagesPerSec -and $pagesPerSec -ge $SEUIL_PAGES_DISQUE) {
    # flag it
}

100 pages per second is roughly 400 KB/s of reads, at 4 KB per page. That is a level where the disk is clearly doing the memory's job.

Why not use the page counter alone? Because Pages Input/sec also counts programs being loaded from disk. If the user opens an application during the measurement, the counter jumps even though RAM is fine. Requiring low available RAM as well keeps those reads from being blamed on missing memory.

If the counter cannot be read, the rule says nothing. A false "your PC is compensating" is worse than silence.

What I tested

I ran the real analysis on my machine: the only thing still flagged was a full disk, in 15 seconds. I also have a simulated test bench, where heavy paging triggers the rule. I did not build a separate case for "high commit, idle disk": my own PC on September 24 was that case.

What I have not proved

The thresholds come from one machine, mine, and from reasoning about the counters. I do not know yet how 100 pages/s behaves across very different hardware. That rate is about 400 KB/s: close to free on an NVMe SSD, where a 4 KB random read takes tens of microseconds, but potentially dominant on a spinning disk, where each fault can cost a seek. A raw count only means something once it is weighted by device latency. The next version should read the disk's read latency (or read queue length) next to the fault rate, and flag a problem when the added time is visible, not when a count crosses a fixed number. A field test on about ten PCs is still the next step.

The tool

This is part of Nyctale, a Windows PC diagnostic tool that tries to name the real cause of a slow PC and says so when no software will fix it. This correction shipped in version 1.0.3. The quick diagnostic is free.

If you monitor memory on Windows: which counter do you trust to tell a slow PC from a PC that just reserves a lot?

Four Bugs I Only Found by Driving the Real Window of a PySide6 App

WgeorgeAssistantIA — Mon, 12 Oct 2026 15:28:12 +0000

My app is a desktop tool that traces images into SVG. The tracing engine is vtracer, a Rust extension, and the UI is PySide6. The engine had good unit tests. Then I used the app for real, and four bugs showed up that none of those tests could see.

All four come from the same place: the interaction between Qt, threads and a native extension. If you build a PySide6 or PyQt app that runs work in a QThread, you may hit the same ones.

Bug 1: the app died with no exception

While a trace was running, the user could paint another stroke. The handler for the mask-changed signal put the selection back with canvas.set_mask(...). But set_mask emits the same signal again, so the handler called itself.

That is infinite recursion, but not the kind Python complains about. It went through Qt's C++ signal machinery, so Python's recursion limit never triggered. The process simply died with a native stack overflow (0xC00000FD on Windows). No traceback, no message.

The rule I took from it: never react to a Qt signal by modifying the thing that emitted it. A guard flag fixes it:

self._suspend_mask = True
try:
    self.canvas.clear_mask()      # emits mask_changed
finally:
    self._suspend_mask = False

def _on_mask_changed(self):
    if self._suspend_mask:
        return
    ...

Bug 2: the UI froze forever after a Rust panic

The worker looked like this:

class Worker(QThread):
    done = Signal(object)
    failed = Signal(str)

    def run(self):
        try:
            self.done.emit(self._fn())
        except Exception as e:
            self.failed.emit(str(e))

With a corrupt image, vtracer panicked. pyo3 turns a Rust panic into a Python PanicException, and that class derives from BaseException, not Exception. My except never caught it. failed was never emitted, so the code that re-enables the buttons never ran. Every button stayed greyed out, with no message.

The fix is to catch BaseException in the worker (re-raising KeyboardInterrupt and SystemExit), and to add a safety net: finished is emitted even when run() ends on an uncaught exception, so a handler on it can reset the "busy" state.

If you wrap any native extension, check what its panics or errors derive from.

Bug 3: a second worker silently refused to start

After a click, the app ran one worker, and when it finished it should start a second one. I called the next _run() directly from the done handler. Sometimes nothing happened.

_run() starts with a guard:

if self._worker is not None and self._worker.isRunning():
    return False

The problem: done is emitted from inside run(), that is, from the worker's own thread, before the thread has finished stopping. At that exact moment isRunning() can still return True. The new call was rejected by its own guard, depending on timing. It never showed up when I tested one case alone, only inside the full test suite.

The fix is to let the event loop turn once before chaining:

def _on_selection_done(self, mask):
    QTimer.singleShot(0, lambda: self._apply_selection(mask))

My rule now: chaining one worker from another's done always goes through QTimer.singleShot(0, ...), never a direct call.

A related trap sits in the same area. Each worker removes itself from self._worker on finished. A chain started from done had already installed the next worker, and the previous worker's finished then wiped it out. Nothing blocked two jobs from running on the same session. The fix is to forget a worker only if it is still the current one:

def _forget_worker(self, worker):
    if self._worker is worker:
        self._worker = None

Bug 4: a keyboard shortcut bypassed the greyed-out buttons

I disabled the buttons while a trace was running. But a shortcut like Ctrl+O does not go through a button. Pressing it during a computation opened a new image, which closed the session and deleted its temporary folder under the running thread. The thread then died with "Cannot create output file".

The fix is a single predicate used by every entry point, shortcuts included:

def _idle(self) -> bool:
    return self._worker is None or not self._worker.isRunning()

def open_image(self):
    if not self._idle():
        return
    ...

How I test this now

Engine tests cannot catch these. The failures only exist when the real window, the real event loop and the real thread run together. So I keep a separate file of regression tests that drives the actual MainWindow in Qt's offscreen mode, with modal dialogs disabled (otherwise a test blocks silently on a message box).

Two practical details:

To test "Ctrl+O during a computation", force a slow job (time.sleep(1.5) in the worker). On a small test image a real trace ends in tens of milliseconds, and the test would check nothing.
To test the panic case, raise a custom BaseException subclass in the worker and assert that the buttons are enabled again afterwards.

What I would tell my past self

Qt signals cross threads and C++ code. Python's safety nets do not follow them.
done is not "the thread has stopped".
Every way to start work needs the same guard, not just the buttons.
Test the glue, not just the engine.

The app

This is part of VectoFix, a local Windows tool that traces an image into SVG, measures what the tracing lost compared with the source, and lets you fix a zone with a brush. Everything runs on the user's machine.

Have you hit a thread or signal bug that only appeared with the real UI? I am curious what your regression tests look like.

Windows Event ID 37 Doesn't Mean Your CPU Is Overheating

WgeorgeAssistantIA — Mon, 12 Oct 2026 15:07:57 +0000

I build a small Windows diagnostic tool. One of its rules looked at the System event log, found Kernel-Processor-Power Event ID 37, and told the user: "your cooling system is probably the problem."

Then I ran it on my own PC, which has no cooling problem. It told me my cooling was the problem.

This post is about why Event 37 is a terrible proxy for overheating, and the three filters that fixed the false positive.

What Event 37 actually says

Event ID 37 from Microsoft-Windows-Kernel-Processor-Power reads roughly: the speed of processor N is being limited by system firmware.

Heat is one reason firmware does that. It is not the only one. A power limit, a weak charger, a battery state or an OEM power profile produce the same event. The event tells you a limit was applied. It does not tell you why.

My first version of the rule was simple:

count Event 37 over the last 14 days
ignore the ones right after the latest boot
if three or more remain, flag "physical cooling problem"

It was also compared with the CPU load measured during an 8-second scan, taken while the user is idle by definition. Two things measured at two different times, used as one argument.

The numbers on my machine

Over 14 days my log had 12 Event 37 entries. The old rule kept 11 of them as "not at boot" and concluded the worst.

Looking at them one by one:

8 of the 12 happened within 10 minutes after a boot. Not just the latest boot: any boot in the period.
The other 4 were not heat spikes at all. Each reported a cap lasting 33 to 48 hours. That is a permanent power ceiling, not a thermal event.

Real overheating episodes: zero.

Fix 1: ignore every boot, not just the last one

Firmware often applies a limit while the system starts. Collect every boot in the window with Event 12 from Kernel-General, then drop any Event 37 that lands in the 10 minutes after one.

$boots = Get-WinEvent -FilterHashtable @{
    LogName='System'; ProviderName='Microsoft-Windows-Kernel-General'; Id=12
    StartTime=(Get-Date).AddDays(-15)
} | ForEach-Object { $_.TimeCreated }

foreach ($e in $ev37) {
    $atBoot = $boots | Where-Object {
        $d = ($e.TimeCreated - $_).TotalMinutes; $d -ge 0 -and $d -le 10
    }
    if ($atBoot) { continue }
    # ...next filters
}

Fix 2: only count events on mains power

On battery, limiting the CPU is intended behaviour. Kernel-Power Event 105 records power source changes, and its AcOnline field says whether the machine was plugged in. For each Event 37, take the latest Event 105 before it. If the machine was on battery, it is not evidence of anything.

Fix 3: use the duration, not just the count

Event 37 carries a CapDurationInSeconds field. A thermal throttle comes and goes in minutes. A cap that lasts a day or more is a configuration, not a symptom. I treat anything of an hour or longer as a permanent cap and drop it.

$xml = [xml]$e.ToXml()
$dur = ($xml.Event.EventData.Data | Where-Object Name -eq 'CapDurationInSeconds').'#text'
if ($dur -ge 3600) { continue }

Only what survives all three filters counts as an episode. On my machine: 0. The verdict also changed from a statement ("your cooling is the problem") to a hedged one ("very probably") with a simple test the user can do themselves.

A PowerShell trap I hit on the way

In the same session I broke the translation table. My loop used a variable named $t for the event time. The table of translated strings was called $T. PowerShell variable names are case-insensitive, so $t silently overwrote $T and every string came back empty. If you use single-letter variables in a script that already has one in capitals, rename one of them.

What I have not proved

I recalibrated this on one machine, mine. The three filters remove the false positive I could see, but I do not yet know the false-positive rate across other laptops and desktops. A 10-PC field test is next. If you have Event 37 data from machines with a real cooling fault, I would like to see how the filters behave.

The tool

This is part of Nyctale, a Windows PC diagnostic tool that tries to name the actual cause of a slow or hot PC, and says "no software will fix this" when that is the honest answer. The fixed rule shipped in version 1.0.3. The quick diagnostic is free.

Have you used Event 37 for anything? Did you find other signals that separate real thermal throttling from firmware power limits?

How to Identify Technologies Mentioned in a YouTube Video

WgeorgeAssistantIA — Mon, 12 Oct 2026 14:41:54 +0000

"Which technologies does this video talk about?" sounds like a named-entity task, and it is, with a twist: the entities are product names that are short, ambiguous, constantly new and often misheard. This post covers the three problems you meet, and a practical approach to each.

Problem 1: what counts as a technology?

If you do not decide, the model will. Without a definition you get everything from "JavaScript" to "the cloud" to the presenter's company. Write the definition into the prompt:

Include: named products, frameworks, libraries, languages, services, CLIs and protocols
Exclude: generic words ("API", "database", "framework"), company names that are not products, channel names, people

Then maintain a block list of the noise you actually observe. In our runs, recurring false positives included generic words such as "API" and "Google", and the names of channels.

Problem 2: the same tool, many spellings

Speakers say "Postgres", "PostgreSQL", "Postgres DB". Captions write "Next JS", "next.js" or "Nexjs". Two things help:

Normalise: lower-case, remove spaces and punctuation, strip common suffixes (js, db) to create a matching key
Keep an alias list for the display name and for deduplication

Watch for duplicates that differ by one letter. We saw a tool appear twice because one occurrence was misspelt; a fuzzy match on names within the same video catches it.

Translation can also distort names. If your pipeline summarises in another language, instruct the model to keep product names exactly as spoken. A product name turned into a translated phrase is no longer searchable.

Problem 3: mentioned does not mean recommended

A technology can be:

Used in the demo
Recommended as an alternative
Compared against another
Criticised or dismissed

Classify the mention type, or at least keep the quote so a reader can judge. This is the difference between a useful tool list and a misleading one.

Ambiguous names need context

"Neon", "Serena" and "Phantom" are all valid product names, and all share their name with something unrelated. Give the model the surrounding sentence, and when you look up the official site, pass the category as well. A good result for an ambiguous name needs context at both extraction and resolution.

Test it on real videos

Pick ten videos in your field, run the pipeline and read the list yourself. You will quickly see what kind of noise appears and where the prompt needs a rule. Update the block list and the prompt, run again.

Our implementation

We built these rules into VidScope, which returns the tools mentioned in a YouTube video with a timestamp and an official link, and avoids returning a link when the match is unclear.

FAQ

Is this a named-entity recognition problem?
Yes, with the twist that names are short, ambiguous and often misheard in captions.

How do I stop generic words being returned?
Define what counts as a tool in the prompt and keep a block list of observed noise.

How do I handle different spellings of the same tool?
Normalise names to a matching key and keep an alias list.

How to Extract Tools and Technologies from YouTube Videos Automatically

WgeorgeAssistantIA — Fri, 09 Oct 2026 15:48:12 +0000

If you watch technical YouTube videos for work, you know the problem: a 40-minute walkthrough mentions a dozen tools, a few commands and a couple of versions, and an hour later you cannot remember which ones. This post shows a practical pipeline to extract the tools and technologies mentioned in a video automatically, step by step, and the pitfalls that make the naive version unreliable.

The pipeline in four steps

Get the transcript
Split it into chunks the model can handle
Extract candidate tools with their timestamps
Verify each candidate and attach an official link

Each step has a failure mode. We will go through them in order.

Step 1: get the transcript

Most videos have captions, either written by the author or generated automatically. Libraries such as yt-dlp can fetch them along with timing data. Keep the timing: every segment of text has a start time, and that is what lets you link each tool back to the exact moment of the video later.

Pitfall: automatic captions mangle product names. Words like "Supabase", "Vercel" or "Kubernetes" come out phonetically. Do not clean them yet; the model will need context to recover them.

Step 2: split the transcript into chunks

Long videos do not fit in one prompt, and even when they do, extraction quality drops as the input grows. A simple approach is to cut the transcript into chunks of fixed size, run them in parallel and merge the results.

We found chunk size matters more than expected. In our tests on a transcript of roughly 475,000 characters, small chunks found more tools than large ones: very large chunks returned fewer distinct tools, because the model summarises instead of listing. Smaller chunks cost more calls but give better recall. A middle size of about 30,000 characters gave a good balance between the number of calls and the tools found.

The mistake to avoid is silent truncation. An early version of our pipeline cut the text at a fixed length and analysed only the first minutes of a seven-hour video without telling anyone. If you cap the input, say so in the output.

Step 3: extract candidates with timestamps

Ask the model for structured output, not prose. For each candidate tool, request the name, a short description, a category and a verbatim quote from the transcript with its timestamp:

{
  "tools": [
    {
      "name": "Supabase",
      "category": "database",
      "quote": "we are going to use Supabase for the backend",
      "timestamp": "00:12:41"
    }
  ]
}

Two rules improve the results a lot. First, define what counts as a tool in the prompt, and list exclusions (generic words, channel names, company names that are not products). Second, require a verbatim quote. A candidate whose quote does not appear in the transcript is rejected.

After merging the chunks, deduplicate by normalised name and drop candidates without a valid timestamp.

Step 4: verify and link

This is the step most tutorials skip, and the one that matters most. A name alone is ambiguous: "Neon", "Serena" or "Codex" each match several unrelated things on the web. If you resolve the official website with a naive search, you will get cinema studios and food standards instead of software.

What worked for us:

Build the search query from the tool's category and description, not only its name
Accept canonical open-source repositories when a tool has no website of its own
Block aggregator sites, course platforms, forums and social networks as official sources
Score the match, and return nothing when the confidence is low

The last point is the hardest culture shift: an empty link is better than a wrong one. Users forgive a missing link; they do not forgive a confident wrong one.

Putting it together

A good extraction pipeline is mostly about discipline: keep the timestamps, never truncate silently, require quotes, and prefer no link to a bad link. Models are the easy part. The rest is verification.

If you want to see this applied rather than build it yourself, we built VidScope to explore this problem: paste a YouTube link and it returns the tools mentioned with timestamps and official links.

FAQ

Can I extract tools from any YouTube video?
From any video that has a transcript, though automatic captions can misspell product names.

Why keep timestamps?
They let you check each tool at the moment it was mentioned.

Why not just ask an AI to summarise the video?
A summary tells you the idea; it rarely gives you the exact tools, versions and the evidence for each.

I Built an AI Tool That Extracts Tech Stacks from YouTube Videos

WgeorgeAssistantIA — Sat, 12 Sep 2026 18:57:29 +0000

Every developer has done this: you open a 45-minute "Build a SaaS in a weekend" video, and by minute 12 you're already pausing every 30 seconds to screenshot a terminal command or squint at a VS Code sidebar to figure out which ORM the creator just installed. You rewind three times because you missed the name of the vector database. By the time the video ends, you've spent an hour to extract maybe eight lines of useful information: a framework name, two library names, one hosting provider. I built VidScope because I got tired of doing this manually, and I wanted to share how the extraction pipeline actually works under the hood — and why "AI video summarizer" was the wrong way to think about the problem from the start.

The first mistake I made was treating this as a summarization problem. Early prototypes fed the full YouTube transcript into an LLM and asked for "a summary of the tools used." The results looked plausible and were frequently wrong — the model would infer a database was PostgreSQL because the creator said "SQL," or assume a deployment target was Vercel because the video mentioned Next.js, even when the actual clip named Railway. Summarization models are optimized to sound coherent, not to be strictly grounded in the source. For a tool whose entire value proposition is "tell me exactly what was mentioned," a confidently wrong answer is worse than no answer. That's the core design constraint that shaped everything else: extraction, not interpretation.

The pipeline itself is simpler than people expect. VidScope pulls the video's transcript (falling back to audio transcription when no captions exist), chunks it to stay inside context limits for long-form content — some tutorials and conference talks run past two hours — and runs extraction passes that are explicitly instructed to only output tool, framework, or library names that appear verbatim or near-verbatim in the transcript text. No inference from context, no "this is probably React because they mentioned JSX." If a name isn't in the transcript, it doesn't make it into the report. This is the "0% hallucination" constraint, and it's enforced at the prompt level with strict extraction rules, not just requested politely.

The part that took the most iteration wasn't the extraction — it was verification. A raw list of tool names is only marginally more useful than pausing the video yourself. What makes the report actually save time is that every extracted name gets resolved to its official documentation or homepage link automatically, so a developer can go from "watched half a tutorial" to "have the actual docs open in five tabs" in under 30 seconds. Getting this resolution step accurate meant handling ambiguous names (there are at least four different open-source projects called "Flow"), filtering out generic terms that get mentioned but aren't tools (the model initially flagged "the cloud" and "database" as extracted entities before I tightened the extraction schema), and deduplicating variants of the same tool referenced multiple times under slightly different names across a single video.

Long videos exposed a separate scaling problem: a two-hour conference talk produces a transcript that's tens of thousands of tokens, and naively extracting per-chunk without merging state across chunks produces duplicate or fragmented tool lists — the same framework mentioned in minute 5 and minute 90 shows up twice with slightly different context. The fix was maintaining an extraction state across chunks rather than treating each chunk independently, which also meant the final report generation step needed to be idempotent regardless of how many chunks a video's transcript happened to split into. This is the unglamorous part of building an "AI feature" that nobody talks about: the actual model call is a small fraction of the engineering effort compared to chunking, state management, and making outputs consistent at different video lengths.

None of this matters if the tool doesn't fit into how developers actually work. The workflow I optimized for is: paste a YouTube link, wait 30 seconds, get a clean list of every tool and framework mentioned with verified links, export to Markdown or PDF, move on. No account required to try it, no video re-upload, no watching required at all. It's built for the moment when you find a promising tutorial at 11pm and want to know in thirty seconds whether it's using a stack you actually want to learn, before committing 45 minutes to watching it.

If you've ever kept a messy notes file of "tools mentioned in videos I watched," or rewound a stream three times to catch a package name, that's exactly the problem VidScope solves. You can try it free on two videos, no credit card required, at vidscope.fr.

How I Built a Local Silence Remover That Processes a 5GB Audio File in Under 6 Minutes

WgeorgeAssistantIA — Thu, 10 Sep 2026 09:44:45 +0000

VoxCut is a dedicated silence remover for audio and video: it automatically detects and cuts silent pauses — dead air, long breaths, gaps between takes — from podcasts, interviews and recordings. Unlike full editors that bundle silence removal as one feature among many, it does this one job, entirely on your device.

I want to walk through the actual engineering problem behind it, because "remove silence from audio" sounds trivial until someone hands you a 72-hour, 5GB recording and expects it back in a few minutes.

The naive approach falls over first

The obvious way to build this: load the whole file into memory, scan the waveform, cut the quiet parts, re-encode. That's roughly what most desktop audio editors do — and it's exactly why they choke on anything past a couple of GB. Once you're loading multi-hour recordings, you hit a RAM ceiling that has nothing to do with your CPU.

VoxCut instead runs a local, FFmpeg-based streaming pass over the file rather than materializing the whole thing in memory. That single architectural choice is what lets it handle files "beyond 5GB" without a hard ceiling — the real limit becomes your disk space, not your RAM.

Detection: comparing amplitude against a threshold

The detection logic itself is simple in concept and easy to get wrong in practice: compare each segment's amplitude against a decibel threshold and a minimum pause duration. Too aggressive, and you cut a natural breath mid-sentence. Too conservative, and you leave dead air in.

VoxCut previews exactly what will be cut before anything is removed, so the sensitivity setting is something you tune by ear rather than trust blindly — nothing is deleted until you confirm.

The Turbo Mode trade-off (V2)

The 2.0 release added a Pro-only Turbo Mode that's a good example of an honest trade-off rather than a free performance win. The standard export stitches kept segments together with crossfades, which sounds smoother but costs time on files with hundreds of detected cuts. Turbo mode removes silence in a single pass instead — no crossfades — which is roughly 2x faster on realistic content (podcasts, interviews, meetings).

The cost: sharper cuts instead of smooth transitions. For most spoken-word content that's barely audible; for content that leans on the crossfades to hide the cut points, standard mode is still the default.

On realistic content (not the "silence-only" edge case that inflates marketing numbers), expect roughly 35-50x real-time in standard mode and 70-100x in Turbo, depending on the machine. A 72-hour, 5GB file was processed in under 6 minutes on ordinary consumer hardware.

Going cross-platform: Windows/Linux desktop, then Android

VoxCut started as a Windows/Linux desktop app. Porting the same core logic to Android (shipped as v2.0.2, same week as the 2.0 desktop release) meant a separate app with its own constraints: mobile storage, a different free-tier limit (5 minutes per file vs. 10 minutes on desktop), and Pro features gated differently — AI noise reduction and loudness normalization are Android-Pro-only, priced independently (€14.99 lifetime) from the desktop license.

Keeping "100% local, no upload" true on both platforms was the one non-negotiable constraint across the port — it's the core promise, not a checkbox feature.

What I'd do differently

If I started over, I'd build the streaming-pass architecture from day one instead of retrofitting it — the in-memory prototype worked fine on my own test files and only broke once real users started throwing multi-hour recordings at it. Test with files bigger than you think anyone will use.

VoxCut is free to try (Windows, Linux, Android) — voxcutpro.com. Feedback and questions welcome in the comments, this is my first shipped piece of software and I'm still learning in public.

About VoxCut

VoxCut is a dedicated silence remover for audio and video. It automatically removes silence, pauses and dead air while processing your files locally — with no upload and no subscription.

VoxCut — Silence Remover for Audio & Video · https://voxcutpro.com

Why I built a local-first PNG-to-SVG converter instead of using an online tool

WgeorgeAssistantIA — Fri, 04 Sep 2026 12:58:26 +0000

Most "convert your image to SVG" tools online are the same story: upload your file to a server you don't control, wait, download a result that's either bloated with thousands of tiny paths or stripped of the details that made the image worth vectorizing in the first place. I hit this wall enough times doing client logo work that I built my own converter — VectorPop — and kept it entirely local, no upload, no subscription.

The problem nobody talks about

Vectorizing a raster image well isn't really about tracing pixels — any tool can call a tracing library and spit out an SVG. The actual work is everything that happens before tracing: merging near-identical colors so you don't get 40 shades of "almost the same blue," rebuilding gradients as real <linearGradient> elements instead of dozens of flat color bands, and cleanly separating a subject from its background. Skip that preprocessing and you get technically-valid SVGs that are unusable in a real design workflow — too many paths, wrong colors, gradients turned into stripes.

The technical approach

VectorPop wraps vtracer (the Rust tracing engine) with a Pillow-based preprocessing layer I built specifically to solve those problems: color quantization and merging before tracing, gradient reconstruction that samples the original pixels to estimate a real gradient rather than approximating it geometrically, and an "Optimize" button that tries ~12 setting combinations and keeps whichever one is closest to the source image — no deep learning, just systematic comparison. Background removal works two ways: flat-color removal with a tolerance slider for logos on solid backgrounds, and optional AI segmentation (rembg) for photos — the AI path is opt-in and the app degrades gracefully if the dependency isn't present.

Why local, and why this pricing model

Everything runs on-device: no image ever leaves your machine, which matters if you're vectorizing client logos or anything under NDA, and it also means no per-conversion cost to pass on to the user. That's why VectorPop is free for unlimited vectorization with 3 SVG exports/day, and a one-time €39 for the Pro tier (unlimited exports, PDF/high-res PNG, AI cutout, batch processing) — no subscription, because a desktop tool that runs locally shouldn't need one.

Wrap-up

VectorPop is a Windows app, live on the Microsoft Store, built by a solo dev after getting tired of redoing SVGs by hand in Illustrator for logo and print work. If you've fought with online converters that either paywall basic exports or upload your files to a server, it's worth a look: vectorpop.fr.

Curious what this community thinks of the gradient-reconstruction approach vs. just tracing flat color bands — happy to go into more technical detail in the comments.

Stop Copy-Pasting Your Invoices: The Complete Guide to Local PDF Mail Merge

WgeorgeAssistantIA — Thu, 27 Aug 2026 19:01:59 +0000

If you run a small business, a freelance practice, or a local club, you probably spend more time than you'd like doing administrative chores. One of the worst offenders? Copying and pasting data from a spreadsheet to create individual documents.

Whether it's monthly invoices, employee training certificates, or personalized event badges, doing this manually is a guaranteed way to waste hours and introduce typos.

Enter the PDF Mail Merge.

Mail merge isn't just for sending letters anymore. By using your spreadsheet as a simple database and connecting it to a PDF template, you can automate this entire workflow. But there is a catch.

Many people default to online web tools. While convenient, this means uploading sensitive financial data, client names, and addresses to a third-party server. If you care about data privacy (or GDPR compliance), this is a red flag.

The Local-First Solution

The safest and most efficient way to handle this is locally on your own computer. We developed InOneShot exactly for this purpose.

Here is how a local PDF mail merge works in 3 steps:

Prepare your Data: Keep a clean Excel or CSV file. One row per invoice or person.
Design your Template: Create a beautiful PDF design once. Leave blank spaces for the variable data.
Merge and Generate: Use InOneShot to map your spreadsheet columns to your PDF. As an offline bulk PDF generator, the app runs locally on your machine, generating hundreds of unique, named PDFs in seconds. You get a clean ZIP file of documents. No monthly subscriptions, no data privacy concerns, just hours of your life back.

Automating your admin work doesn't require complex coding or expensive cloud tools. Sometimes, a smart local app is all you need.

👉 Ready to get your time back? Download InOneShot, the ultimate local PDF creator, and start automating your paperwork today!