DEV Community: WgeorgeAssistantIA

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!

An Auto-Editor Alternative With No Command Line (for People Who Don't Code)

WgeorgeAssistantIA — Sat, 04 Jul 2026 14:02:32 +0000

Long interviews, webinars and full sessions crash browser tools and choke on upload. Here's how to trim silence from large, multi-hour audio files without hitting size limits.

Trimming silence from a three-minute clip is easy — almost any tool handles it. The pain starts when the file is big: a two-hour interview, a full-day workshop recording, a webinar, a long-form podcast in lossless WAV. That's where most silence removers fall apart, and where the choice of tool actually matters.

Why large files break most silence removers

The majority of popular silence-removal tools are browser-based or cloud-based. That's fine for short clips, but with large files it creates real friction:

Upload limits — many web tools cap uploads at 100–500 MB, well under a multi-hour lossless recording.
Slow, fragile uploads — sending a 2–4 GB file over your connection can take ages, and a dropped connection means starting over.
Browser memory limits — loading a huge waveform into a browser tab can freeze or crash it.
Privacy exposure — a confidential interview or client recording leaves your machine and sits on someone else's server.

The fix: process large files locally

A desktop app that runs on your own machine sidesteps every one of those problems. There's no upload — the file never leaves your computer — so file size is limited by your disk and RAM, not by someone's server quota. Processing reads the file directly, which is far faster than streaming gigabytes to the cloud and back, and your audio stays completely private.

What to look for when files are big

Runs locally / offline — no upload step, no size cap tied to a server.
Handles multi-gigabyte files without choking — headroom for multi-hour lossless recordings.
Batch processing — so you can queue a whole folder of long recordings and walk away.
A preview before you commit — you don't want to reprocess a 3 GB file because the threshold was off.
Lossless format support (WAV, FLAC) — long recordings are often captured uncompressed.

Doing it with VoxCut

VoxCut is a desktop app for Windows and Linux built for exactly this. It runs 100% locally — your audio never leaves your computer — and handles files up to 5 GB, which comfortably covers multi-hour interviews, webinars and full-length episodes in WAV or FLAC. You set a sensitivity threshold, see a before/after waveform (blue for voice, grey for silence) so you know what will be cut before you export, and batch-process a whole folder of long recordings in one go. It's a one-time purchase, no subscription.

Tips for long recordings

Preview first on the waveform — a small threshold error is annoying on a 3-minute clip and expensive on a 2-hour one.
Keep a 400–600 ms minimum silence so natural pauses survive across a long conversation.
Batch overnight — queue the whole folder and let it run while you do something else.
Always keep the original — trimming is destructive to timing, so archive the source file.

Big files shouldn't mean big headaches. Once you stop fighting upload limits and process long recordings locally, trimming silence from a multi-hour session becomes just as quick as a short clip — and your recordings stay private the whole time.

How to Automatically Remove Silences From a Podcast (Without Manual Editing)

WgeorgeAssistantIA — Wed, 17 Jun 2026 11:02:48 +0000

If you record podcasts, interviews, or voiceovers, you already know the truth: the recording is the easy part — the editing is where the hours disappear. And a huge chunk of that editing time goes into one tedious, repetitive task: cutting out silences, pauses, and dead air.

The good news? You don't have to do it by hand anymore. Here's how to remove silences from your audio automatically, and why it makes such a difference.

Why silences matter more than you think

A few seconds of dead air feels harmless while you're recording. But across a 45-minute episode, those pauses add up — often to 10–20% of the total runtime. That's:

Longer episodes that feel slower and lose listeners
More file size to host and deliver
A less professional, less "tight" listening experience

Removing silences makes your content punchier, shorter, and noticeably more polished — without changing a single word you said.

The slow way: cutting silences manually

The traditional approach is to open your recording in an editor (Audacity, Audition, Premiere…), scrub through the waveform, find each gap, select it, and delete it. Repeat a few hundred times per episode.

It works, but it's mind-numbing — and it's the single biggest reason editing a podcast can take 2–3× longer than the recording itself.

The fast way: automatic silence detection

Modern tools can analyze your audio, detect every silent passage based on a volume threshold, and trim them in one pass. Instead of hunting for gaps manually, you:

Load your audio file (MP3, WAV, etc.)
Set the sensitivity — how quiet and how long a passage must be before it counts as "silence"
Let the tool detect and trim every silent section automatically
Export your cleaned-up file

What used to take an hour now takes a couple of minutes.

A simple tool for this: VoxCut

I build a small Windows app called VoxCut that does exactly this. You drop in a recording, and it shows you a before/after waveform — blue for voice, grey for silence — so you can see precisely what's being removed before you commit. One click, and the dead air is gone.

It's designed to do one job well rather than be a full DAW: adjustable sensitivity, fast processing, and a clean interface with no learning curve. There's a free version to try it, and a one-time Pro upgrade (no subscription).

(Full disclosure: I'm the developer of VoxCut, so I'm obviously biased. But the workflow above works with any silence-detection tool — the point is to stop doing this by hand.)

Tips for the best results

Don't over-trim. Leaving a small natural pause (150–300 ms) between sentences keeps speech sounding human. Cutting every millisecond makes it feel rushed and robotic.
Tune the threshold to your recording. A noisy room needs a higher silence threshold than a treated studio, or background hiss gets mistaken for speech.
Always keep your original file. Trim a copy, so you can re-do it if you cut too aggressively.
Do silence removal first, then your other edits (EQ, leveling, music) on the tightened file.

The bottom line

Manually cutting silences is one of those tasks that adds zero creativity and eats enormous amounts of time. Automating it is one of the highest-leverage changes you can make to your editing workflow — you get shorter, tighter, more professional episodes, and you get your evenings back.

If you want to try it on Windows, you can grab VoxCut at voxcutpro.com.