v2.7.0

Snipwright 2.7.0

Another bug fix release, and one that matters most if you are on Windows: automatic advert detection has never worked there. Not "worked badly" — never ran at all. Every attempt failed before it read a single frame, and reported the failure as though there were something wrong with your recording.

There is a good deal more besides. The Joiner was throwing away audio description tracks and subtitles on every join. Advert detection could remove almost your entire programme on some recordings; it could mistake an advert's own logo for the channel's; and it could refuse to learn a logo that was plainly visible on screen. All of that is fixed.

Nothing here adds a feature. If you are on Linux and detection has been working for you, most of this is refinement — but the detector has had a hard look at it this time, measured against thirty hand-corrected recordings, and several things it was quietly getting wrong are now right.

🪟 Advert detection on Windows

It never worked. This is worth saying plainly because the symptom pointed somewhere else entirely.

Snipwright asks ffmpeg to write out the scene changes it finds, and tells it where to put that file as part of a longer instruction. Inside such an instruction a colon separates one option from the next, and a backslash changes the meaning of whatever follows it. Every Windows temporary path begins C:\. So ffmpeg read the instruction as nonsense and refused to start.

No frames were analysed, and Snipwright reported the result as "no logo clear enough to remember" — a statement about your recording, when nothing had been looked at. Two separate investigations went looking at recordings and logos before the real cause turned up.

It now hands ffmpeg a plain filename with no drive letter or folder separators in it, so there is nothing left to misread. Linux and macOS were never affected.

If you are on Windows and had given up on advert detection, it is worth another try.

✂️ Detection could remove the programme

On a recording where the detector misread which corner held the channel logo, it proposed a single "break" running from the start of the recording to two thirds of the way through — and reported it.

The length limit that exists to catch exactly this did not apply, because a break touching the very start or end of a recording is allowed to be longer. That allowance is right: the padding your PVR records either side of a programme often runs to ten minutes or more. What was missing was any upper bound on it. A break at the start or end can now no longer take more than half the recording.

Measured on a 43-minute recording that lost all 25 minutes of programme and kept only the padding. The same test across thirty recordings showed no change to anything else, including the nine legitimate 10-13 minute padding trims the allowance was added for.

🎯 An advert's logo mistaken for the channel's

The cause of the above, and interesting in its own right.

Snipwright works out where a channel puts its logo by looking for something that stays in one corner, assuming that something is present during the programme and absent during the breaks. Things like advert logos and QR codes are the exact opposite — an advert parks its own artwork in a corner and leaves it there, so it is present through the advert and absent through the programme, and gets read as a channel logo that had been missing for the entire show.

Corners are now judged on how much of the recording they are actually present for, and one that only appears for a minority of it can no longer outrank a real logo. Expect more of these: corner artwork in adverts is routine now, and nothing about this was specific to one channel or one kind of graphic.

Related, and on a different channel: on recordings that change picture shape for the adverts, an advert's own logo sitting in the same corner as the channel's could be mistaken for it, and each such moment cut one break into two. On the Talking Pictures recordings this was measured on, a single break contained seven of them. One recording went from finding half its breaks with four false ones to finding both with a single false one.

🔎 Learning a logo

A logo could not be learned from a visually busy programme. Snipwright finds the logo by looking for pixels that are edgier during the programme than during the adverts — which assumes a logo is the only thing that can raise a pixel. A programme full of detail, stone walls and rubble and foliage, measured as edgier than its own smooth advert graphics across the whole picture, and the shape that came out covered almost the entire frame instead of a corner. Snipwright rejected it as too large and learned nothing, with the logo plainly visible all the while.

Each pixel is now measured against the rest of the frame rather than against zero, so a whole-picture difference cancels out and only what genuinely stands out is kept.

The log now says why a logo could not be learned. It used to record only that nothing was learned, which names the outcome and none of the evidence. It now writes what it measured for each kind of logo it looked for: the strongest contrast it found, the contrast it needed, and which test refused the result. It also records how long the pass took against the length of the recording, and how much of the recording it managed to analyse — which is what finally exposed the Windows fault above.

Saving a second project while a logo was being learned threw the second one away. Learning reads the whole recording, so only one runs at a time — but instead of waiting its turn, anything saved while one was in progress was silently discarded. If you worked through several recordings in a sitting, only the first taught Snipwright anything. Saves are now queued and worked through in order.

You can now see when it is happening. The message saying a logo was being learned disappeared after fifteen seconds, while the work itself runs for minutes — so for nearly all of that time nothing on screen said anything was in progress, and closing Snipwright cancels it. The status bar now keeps a message until the work is genuinely done, and says how many recordings are waiting behind it.

🔗 The Joiner and the progress bar

The Joiner threw away every audio track but the first, and the subtitles. A join is meant to be lossless, and the picture always was — but the finished video came out with a single audio track however many the scenes had. An audio description track, or a second language, went silently. So did the subtitles. Each scene was rendered correctly with everything in it; the loss happened at the moment the scenes were joined together, which is why nothing looked wrong until you played the result.

Snipwright now also compares the finished join against the scenes it was built from, and says so in the log if anything is missing. That check is the part that should have existed all along: the fault could hide for as long as it did because nothing was counting.

One limit remains, and it is worth knowing before you hit it: joining scenes that do not share a format — different codecs, sizes or frame rates — still produces a single audio track. Those have to be re-encoded through a path that can only carry one, and widening it is a larger change than this release should carry.

The Joiner did not record its finished video in the log. It wrote a full completion summary for every scene it rendered on the way to the join, and then nothing at all for the file it actually produced — so the one set of figures worth keeping was the one missing. The finished join now writes the same summary a normal export does, and the per-scene entries have been reduced to a single line each: they are intermediate pieces, not finished videos, and giving each one the full block made a five-scene join read as six separate videos.

The progress bar stalled at half way when writing an MKV. The audio check that runs at the end reserved the upper half of the bar for a second comparison pass that only happens when the first finds a problem — which is the minority of exports. On a clean file the bar filled to 50% and then jumped to the end. It now uses the whole bar.

🖼️ The editor

Cut boundaries are easier to see in the thumbnail strip. A frame inside a kept scene was marked by a one-pixel border, which is a losing proposition against arbitrary picture content — it was reported as hard to see twice, once against a dark scene and once on a bright one where the picture and the border were a similar colour. Each such frame now carries a band along its top edge, so the boundary is where the band stops between two adjacent thumbnails. It is drawn over the picture rather than above it, so it costs no height.

With the band doing that job the yellow border has gone, which also frees the blue marker on the frame you are actually on — it was being squeezed between two yellows, and has moved back out to the edge of the thumbnail where it used to sit.

The thumbnail strip is now dark in light mode too. It was the one editor bar without a background of its own, so in light mode the gaps around the thumbnails came out the same near-white as the rest of the window. A yellow cut marker has far less to separate it against a bright surround than a dark one, so the cut marks were noticeably harder to see in light mode for no reason anyone chose.

Checking for updates could crash the editor a few seconds after launch. Fixed.

The Watcher screenshot in the user guide was out of date — it still showed an older window. Replaced.

What is not covered

HDR and 4K remain untested. Nothing in Snipwright is known to be wrong with either, but no HDR or 4K recording has been through it — there is no UK Freeview source for them here, and shipping a claim that has never been checked is worse than saying nothing. If you use Snipwright on that material, reports are welcome.

Advert detection is still imperfect on some channels. Talking Pictures TV in particular still produces false breaks that have nothing to do with the fixes above; that work is ongoing. As always, look at what the detector proposes before exporting — it is a starting point, not a decision.

🧪 What was tested

For those interested — there is more measurement behind this release than usual, so it seemed worth setting out.

The detector was measured against a corpus of thirty hand-corrected recordings, run four times over the course of this work, so every change here is a before-and-after on the same material rather than an impression. Two of the changes were tried, measured, and reverted when the numbers said they cost more than they bought.

For the export side: MPEG-2 SD, H.264 1080i, and a 5.1 recording with an audio description track and subtitles, each exported to .ts, .mkv and .mp4, and every output checked for duration, track count and subtitles. The Joiner was tested separately on a multi-scene join, which is how the missing audio tracks came to light. The Windows fault was confirmed on a Windows 10 install both before and after the fix — nothing analysed beforehand, the whole recording analysed after.

Bug reports are welcome, especially with a sample recording — a short clip cut with ffmpeg -ss … -t 60 -i recording.ts -c copy sample.ts is usually enough. If an export comes out with audio missing or out of sync, the log from that run is the single most useful thing you can attach. The full changelog is in CHANGELOG.md.