Skip to content

Releases: infidelus/snipwright

v2.12.0

Choose a tag to compare

@infidelus infidelus released this 11 Oct 18:41

Snipwright 2.12.0

Advert detection now trims the end of a recording properly, using the channel's own "now and next" listing, and it copes better with adverts that put their own logo where the channel's sits. The VideoReDo Charms bar is back, there's a new View menu, lists can be dragged into order, and the Batch Manager tells you when it has finished.

📺 Advert detection

  • The end of a recording is trimmed much more fully. A padded recording runs on into continuity and the next programme, which carries the channel's logo, so detection used to find where the programme ended and then stop — often leaving seven to ten minutes on the end. Chalkline now also reads the broadcaster's "now and next" listing from the recording and trims everything from the moment the channel says the next programme has started. It never trims earlier than that unless detection has already found the end there, so it cannot cut into the programme. Recordings whose recorder doesn't keep the listing are detected exactly as before.
  • An advert's own logo no longer fools it. When an advert put a small logo of its own exactly where the channel's sits — a white wordmark top-left on ITV2, for instance — detection could take it for the channel's logo and either split a break in two or start it late. Both are now handled: the channel's logo stands on its own while an advert's lettering spreads into the area around it, and a break that begins with the channel's ident is now found from the ident.

Both changes were measured across the whole test set before going in: apart from the recordings they were aimed at, every break found is exactly as before.

🎛️ Charms bar and the View menu

  • The Charms bar, for anyone who misses it from VideoReDo. A column of large buttons down the right-hand edge of the window, switched on from View → Show Charms Bar. Ten slots, each set to any of eighteen functions from the menus with an optional label of your own, under Settings → Charms bar. The buttons have Snipwright's own icons, so the bar looks the same on Linux and Windows and follows the light or dark theme. In an ordinary window it pops out of the right-hand side, widening the window, so nothing already on screen moves. It's off unless you switch it on. Thanks to Bridgyguy for suggesting it.
  • A View menu: show or hide the thumbnail strip, choose where each frame's picture type (I, P or B) is shown, and go full screen with F11.

🗂️ Batch Manager, Joiner and renamers

  • A notification when a batch finishes — when the queue runs out, including any export you handed over with Send to Batch, or when a stop you asked for completes — with how many jobs were done, need review or failed. It arrives even if the Batch Manager window is closed, and can be turned off under Settings → General.
  • Drag to reorder. Jobs in the Batch Manager, entries in the Joiner list and the Charms bar slots each have a grip at the start of the row; drag it and the row follows the pointer, highlighted while you hold it. The Up and Down buttons are still there.
  • Windows that remember their size. The Batch Manager opens tall enough for ten recordings the first time, and it and the TV and Film Renamers then reopen at whatever size you last left them. The renamers also give the new name the room, rather than splitting the width evenly with the current one.
  • Thumbnails always keep the same size instead of stretching with the window.

💬 Subtitles and sound

  • Joining scenes from a DVD rip keeps the subtitles. 2.11.0 brought Blu-ray subtitles through joins; DVD (VobSub) subtitles were still lost from every join. They're now converted to broadcast subtitles from the rip itself, with the disc's own colours and positions.
  • Audio description that starts late no longer forces the soundtrack to be re-encoded — every track is copied exactly as broadcast.
  • No false "output longer than the edit" note when a cut's last subtitle runs past its end.

🧩 Under the bonnet

  • Supporting libraries can take their own bug-fix releases (numpy 2.5.x, PySide6 6.11.x, tqdm 4.x, bitarray 3.x) without waiting for a new Snipwright; nothing newer than what's been tested is accepted.
  • German fixes: the TV Renamer's window title, the Batch Manager's end-of-batch line (which was always English), and a couple of slips of wording.

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, or with a subtitle track missing, the log from that run is the single most useful thing you can attach. The full changelog is in CHANGELOG.md.

v2.11.0

Choose a tag to compare

@infidelus infidelus released this 09 Oct 11:05

Snipwright 2.11.0

Subtitles now come through every join, Blu-ray rips included, and an export always says when a format can't keep them. Audio description stays in step on channels that only send it while the narrator speaks, recordings named .bin can be saved, and Snipwright runs on PyAV 19.

💬 Subtitles

  • Joining scenes from a Blu-ray rip keeps the subtitles. When the scenes share one format, the Joiner copies them rather than re-encoding, and until now a disc's subtitles were lost on the way with nothing said. They are now converted to broadcast (DVB) subtitles from the recording itself — the same words, colours, positions and timings — exactly as a re-encoded join already did.
  • A join saved as .mkv with Match Source is a real Matroska file, with a chapter at each join. Joining .mkv recordings with Match Source wrote an MPEG-TS file under an .mkv name: it played, but it had no chapters. It now follows the file's extension, as a single export always has.
  • A re-encoded join keeps its subtitles when an audio-description track starts late. On some joins the subtitles could not be written and were left out; they now arrive, along with the audio description.
  • An .mp4 says when it leaves subtitles out. MP4 has no room for broadcast or Blu-ray subtitles, which are pictures rather than text. An .mp4 export or join used to say only "Subtitles: None"; it now notes the track it could not carry and suggests .mkv, which keeps it.

🔊 Audio description

  • Narration stays in step on channels that send it only while the narrator speaks. Some channels, such as 5USA, transmit audio description in short bursts with long gaps. An export closed those gaps up, so the narration ran ahead of the picture and then fell silent for most of the programme. It now stays where it belongs in .ts, MKV and MP4 alike.
  • A second export of the same recording keeps the audio description too. On such recordings the first export kept the track and any later one left it out.

📼 Recordings and editing

  • Tvheadend recordings named .bin can be saved. Snipwright opened them, but every save failed. They are now saved as .ts, and .bin files can be dropped onto the window and appear in the Open dialog. Thanks to Paul for reporting it.
  • Holding a skip shortcut keeps skipping. Shift, Ctrl and Ctrl+Shift with the left or right arrow now repeat while held, about ten skips a second, instead of moving once and then only now and again. Also reported by Paul.
  • Opening a file with chapters says how many marks it added. The message was meant to appear in the status bar since 2.4.0, but it was wiped as the first frame was drawn.

🌍 German

  • Exports and joins are in German from start to finish in the German interface: the progress window's steps (Fast Frame Copy, Encoding Frames and the rest), the Joiner's progress lines and time estimate, and the notes and any error in the summary at the end. The log keeps them in English, so a problem report reads the same whoever sends it.

🧩 Under the bonnet

  • PyAV 19 is supported. A new installation now takes PyAV 19.0.1, which brings FFmpeg 9.0.2 for decoding; an existing one can stay on 18.1. Exports are byte-for-byte the same on both, re-encoded cut points included, and advert detection gives identical results across the whole test set.
  • PySide6 6.11.2, numpy 2.5.3, tqdm 4.70.1 and bitarray 3.11.0 — routine updates, tested the same way, changing nothing you will see. The About box now also checks PyAV against the versions it has been tested with.

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, or with a subtitle track missing, the log from that run is the single most useful thing you can attach. The full changelog is in CHANGELOG.md.

v2.10.0

Choose a tag to compare

@infidelus infidelus released this 04 Oct 12:44

Snipwright 2.10.0

Advert detection learns more about each channel and puts programme edges closer to where you'd cut them, subtitles now survive a re-encoded join, and audio description is no longer lost from some HD recordings.

📺 Advert detection

  • Programme starts and ends are placed more closely. Many channels show the same frame just before or after every programme - a sponsor card, a continuity board. Chalkline now learns these from the projects you correct and uses them to pull the start and end of the programme in to the right place. In testing, programme edges within two seconds of the hand-placed cut rose from 25 of 67 to 30, none got worse, and scanning is no slower. It only refines edges Chalkline has already found, and only learns from recordings whose padding you've trimmed.
  • Learning can be switched off per channel. The Remembered logos window has a new Learn column. Untick it for a channel that already detects well: what it has learned is still used, but saving a corrected project no longer starts a learning pass, which could take several minutes on a long recording.
  • Channels without a logo now appear in Remembered logos. A channel recognised only by the ident around its breaks, such as Film4, gets its own row with a picture of that ident, and can be paired and joined like any other - so idents learned from one recorder's recordings work for the other's too. A new Idents column shows how many each channel has learned.
  • Learning messages name the channel, not its service number, once that number is paired with a name.

💬 Subtitles survive a re-encoded join

Joining scenes that don't match - an SD and an HD recording, say - re-encodes them, and until now their broadcast subtitles were dropped. They are now carried into the joined video, each on the right picture. Where a scene's subtitles were drawn for a different picture size, they are redrawn to fit, words and colours unchanged, so they show in every player - including a web browser through Jellyfin. A Blu-ray's subtitles are converted to the same kind, so recordings and disc rips share one subtitle track. Anything that still can't be carried, such as teletext, is named in the summary at the end.

🔊 Audio description kept on more recordings

On some HD channels, BBC Three HD among them, the audio description track gives no clue to its format during the first minutes of a recording, and the export left it out ("1 audio track could not be carried over"). Recordings are now read deeply enough to see such a track properly from the start, so it is kept whole. The last step of a .ts export, which restores the channel name and track labels, no longer fails on these tracks either.

ℹ️ What Snipwright is running on

The About box now lists your system, Python and each library Snipwright uses - including the FFmpeg inside PyAV, which does the decoding - plus the FFmpeg and MKVToolNix programs. A library that isn't the version Snipwright was tested with is shown in amber with the tested version beside it, and "Copy details" puts the whole list on the clipboard for a bug report.

🧹 Uninstallers

src/packaging now has uninstallers for Linux and Windows beside the installers. They remove what the installer set up - menu entries or shortcuts, file types, the Watcher's start-on-login entry and the Python environment - and ask before deleting your settings, so learned channel logos can be kept for a reinstall. They never touch recordings, exported videos, projects or logs.

🐛 Fixes

  • The Linux installer is executable again. In 2.9.1 it had lost its executable permission, so running ./install-linux.sh directly gave "Permission denied". The documented chmod +x step covered it.

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, or with a subtitle track missing, the log from that run is the single most useful thing you can attach. The full changelog is in CHANGELOG.md.

v2.9.1

Choose a tag to compare

@infidelus infidelus released this 01 Oct 10:23

Snipwright 2.9.1

A small release with one job: if you installed Snipwright since 29 September and it fails as soon as you export, this puts it right.

🐛 New installations could not export anything

Snipwright's installers asked for the newest version of each library it uses. On 29 September a new major version of PyAV - the library Snipwright uses to read and write video - was published, and it no longer accepts an option Snipwright passes when opening every recording. So anyone who installed Snipwright from that day on, or reinstalled it, got a copy that failed on every export.

  • Every library is now locked to the exact version Snipwright has been tested with, so a new release of something it depends on can no longer break it overnight. Newer versions will be adopted once they have been tried.
  • If you installed or reinstalled since 29 September, run the installer again. It puts the right versions back, and your settings are untouched. If your copy exports normally, you were not affected, though updating does no harm.

🐍 Python 3.12, 3.13 or 3.14

These are the versions the locked libraries are built for. Linux Mint 22 and later include 3.12, and the Windows installer fetches 3.14 if it doesn't find a suitable Python. Both installers now say plainly when the Python available isn't one of these, rather than stopping on an unhelpful error part-way through. The documentation used to say 3.10; in practice a working installation has needed 3.12 for some time.

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, or with a subtitle track missing, the log from that run is the single most useful thing you can attach. The full changelog is in CHANGELOG.md.

v2.9.0

Choose a tag to compare

@infidelus infidelus released this 30 Sep 18:36

Snipwright 2.9.0

A project format of Snipwright's own, advert detection that can now see Film4, and a good deal of work on keeping subtitles where they belong.

Film4 was the channel Chalkline simply could not read: during a film there is no logo, and the film cuts straight to the adverts with no black frames and no silence. What Film4 does have is the same red ident at the start and the end of every break, and Snipwright now learns that kind of card from your corrections and uses it. Alongside that, the Joiner can hand its work to the batch queue, and on Windows the first start after a reboot can be much quicker if you choose.

📁 A project format of Snipwright's own

A VideoReDo project records each cut as two times and nothing else. That has served well, but it cannot say which recording it belongs to beyond a file path, and times alone go wrong on a broadcast whose clock jumps partway through.

A Snipwright project (.swproj) places every cut on the exact frame you chose, notices when it is opened against a different copy of the recording, finds a recording that has been moved together with its project, and notes whether the cuts came from you or from the advert detector.

  • New installations use it by default. An existing installation stays on .vprj until you change it, under Settings → Files & folders → Project format.
  • VideoReDo cannot open a .swproj, so if you move projects between the two editors, stay on .vprj. Both formats open, save and queue exactly as before.
  • The watcher writes whichever you choose, and the Batch Manager takes either. Double-clicking a .swproj in your file manager opens it in Snipwright, on Linux and Windows.

🎬 Film4, and channels that frame their breaks

Some channels show the same short, full-screen card at the very start and end of every advert break — Film4's red ident is the clearest example. When you save a corrected project, Chalkline now learns that card as well as the logo, but only if it appears at the edges of most of the breaks and never in the programme itself. A card that also turns up in programmes is refused, and on several channels it was.

Once learned, the card does two things:

  • It puts each break's edges on the exact frame. On Film4 films shown letterboxed, the breaks were already found, but their edges came out five to eight seconds adrift — cutting a few seconds of the film at every break and leaving the sponsor card in at the other end. They now land within a fraction of a second of where you would cut. ITV1, ITV4, Rewind TV and Sky Mix turned out to have cards too, and their edges tighten as well.
  • On a channel where nothing else marks the breaks, it finds them. A full-screen Film4 film gives the other techniques nothing at all; now every break is found from the ident alone.

It was checked against recordings whose card was learned from a different film, since that is how it will be used, and it changed nothing on channels without a card. One limit: the card marks advert breaks, not the start and end of a recording, so on a full-screen film the lead-in and the end may still need trimming by hand.

🔗 The Joiner and the batch queue

Joining recordings that do not match means re-encoding the whole thing, which can take a long time — exactly when you would rather it ran in the background.

  • Joiner → Queue Joiner List to Batch, or Queue to batch in the Joiner window, queues the join instead of running it now. It asks the same questions Create Video does, keeps your answers with the job, and uses the Batch Manager's profile and output folder like any other job.
  • A join you have already started can be handed over too. The Joiner now uses the same progress window as an export, with Send to Batch, and the join carries on in the Batch Manager from where it was rather than starting again.

💬 Subtitles

  • Subtitles came on by themselves in every exported .mkv. A broadcast recording does not say whether its subtitles should be on, and the export marked them as the default track, so most players switched them on. They are no longer marked. For files you have already exported, the tools/fix-subtitle-defaults tool clears the flag in place — it shows what it would change before changing anything.
  • The export summary says which subtitles the file kept — "DVB subtitles (eng)", say, or "None" — read from the finished file itself, and the summary in the log says the same, batch exports included.
  • Tools → Show video programme information now lists the subtitle streams: type, language, PID and page.
  • A join that has to be re-encoded cannot carry subtitles, and until now it dropped them without a word. It now says so in the summary and the log. A join of scenes that all match is not re-encoded and keeps them.

🪟 A faster first start on Windows

Windows Defender checks every file Snipwright loads the first time it starts after a reboot, and that roughly doubled the first start. The Windows installer now offers, at the end, to exclude Snipwright's own Python folder from those checks.

It explains the trade-off first — Defender stops scanning that folder altogether — and does nothing unless you say yes. It needs administrator permission for that one step, so Windows will ask. Later starts are quick either way, and Snipwright's log now records how long each start took.

Smaller things

  • A channel could keep switching between logos that were as good as each other, on differences of a fraction of a percent, announcing "a better logo" every time. A logo now has to be clearly better before it takes over.
  • Ticking or unticking Favourites Only in Save Video jumped back to the first profile in the list. It keeps your choice now — or, if the box hides it, the nearest favourite with the same container.
  • Save Project As could ignore the format you chose, and choosing EDL could save a file called name.vprj.edl. The format you choose now decides, and the name follows it.
  • The export summary was mostly English in the German build: only its title was translated. All of it is now.
  • The user guide now says how to open the watcher's window — a left-click on the tray icon — and what the right-click menu offers.

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, or with a subtitle track missing, the log from that run is the single most useful thing you can attach. The full changelog is in CHANGELOG.md.

v2.8.0

Choose a tag to compare

@infidelus infidelus released this 20 Sep 13:53

Snipwright 2.8.0

Mostly about subtitles and about how Snipwright learns a channel's logo, with a good deal of editor tidying alongside it.

Two separate faults were losing subtitles on export, and neither said a word about it. Advert detection has stopped treating the first logo it learns for a channel as the last word on the subject — it keeps several now and works out which is doing the better job, from the corrections you make. And the trim at the end of a recording no longer leaves seven to ten minutes of continuity on the end, at least on the channels where there is something in the picture to go on.

There are also three ways of quietly damaging your own edit that are now refused instead.

💬 Subtitles vanishing on export

Two different faults, found a day apart, both silent.

The first showed up on a broadcast recording exported with a profile that re-encodes the audio. Whenever the export had to rebuild the audio, the rebuilt file was assembled from the video and audio alone — every rebuild step names the streams it wants, and nothing named the subtitles, so they were dropped. Four separate steps had the same gap. They all carry subtitles through now.

The second turned up on a disc rip being re-encoded to save space. A cut bound for .mkv or .mp4 is written to a transport stream first, and a transport stream can only carry broadcast subtitles — so PGS or SubRip subtitles disappeared on the way through. An .mkv export now routes those recordings through a Matroska working file instead and keeps them. A broadcast recording is untouched and follows exactly the path it always did.

Where the format genuinely has nowhere to put them — .ts and .mp4 cannot hold a disc's subtitles — the export now says so in its summary. Dropping a track the source had and saying nothing needed fixing as much as the loss itself.

The disc side was tested on what can be made here: 1080p H.264 with AC-3 audio and PGS subtitles. 10-bit, HDR and 4K sources remain largely untested, and not by choice — UK Freeview broadcasts none of them, so there is nothing off the tuner to test against. If you have such a recording and something goes wrong with it, a short sample would be genuinely useful.

🕐 A recording whose clock jumps

Some broadcasts carry a clock that leaps hours forward partway through a programme, with nothing actually missing. A 45-minute recording can claim to run for over seven hours.

Snipwright showed and cut these correctly, but the export did not: the file came out reported as hours long, every subtitle after the leap was placed hours late in MKV, and the TS route needlessly rebuilt the audio. The leap is now closed as the cut is made, so video, audio and subtitles run on without a gap, the file reports its real length, and chapter marks land where they should. The log says where the leap was, and shows scene times as they play rather than hours out.

Recordings whose timestamps run normally export exactly as before — checked packet by packet against the previous build.

🧠 Snipwright can change its mind about a channel's logo

It used to learn a channel's logo once and keep it. A logo learned from an awkward recording was stuck there, and nothing could tell a good one from a bad one.

A channel now keeps up to four, and every time you save a project you have corrected, the logos it already holds are scored against your own cuts — the logo should be out of sight through the adverts and on screen through the programme. The one that does best is the one used from then on.

Two details matter for that to be fair:

  • A logo learned from the recording you just saved has to prove itself on a later one. It was fitted to that recording, so it would flatter itself there.
  • Two logos are only compared on recordings they have both been measured against, so a logo is never punished for having been tried on a harder recording than its rival.

This only runs if "Learn channel logos from my edits" is ticked in Settings > Advert detection, and a channel whose logo is already settled is left alone when you save a detection exactly as it was proposed.

Alongside it: a learned logo that does not match the recording at all — the channel changed it, or the picture is framed differently — is now left out of that recording rather than used blindly. Joining two remembered logos under one name keeps both, instead of discarding one on a contrast figure that was never comparable between them. And the Remembered Logos list shows how many logos a channel holds, with each one's record when you rest the pointer on its row.

✂️ The end of a recording

A recorded programme ends, an advert break follows, and then comes continuity or the next programme — with the channel's logo back on screen. Snipwright cut the advert break and stopped there, leaving the rest on the end.

Where the picture's shape or aspect changes as the programme finishes and stays changed to the end of the recording, the trim now carries on to the end. The cut still starts exactly where it did before, so nothing is taken off the programme. Across thirty recordings this removed about 24 minutes of continuity that was previously left in, and changed nothing else.

Channels whose picture does not change are unaffected, and the user guide now says so: the trim at the start is reliable, the one at the end depends on the channel, and it is worth a look before you export.

🛑 Three ways to damage your own edit

All three are refused now, with a note in the status bar.

Cutting without marking OUT. The markers stay put after a cut so you can nudge a boundary, which leaves the OUT sitting on the cut you just made. Mark IN for the next break, forget the OUT, press Cut — and the range ran backwards, removing everything between the two marks. That is programme, not adverts.

Adding a scene without marking OUT. The same mistake in Scene Mode, which quietly replaced the two neighbouring scenes with one covering the gap between them.

Running two copies at once. Both shared the batch queue, and whichever saved last erased the other's jobs; removing a job could delete a working copy the other window still needed. The queue is now merged at the moment it is saved, and Snipwright runs as a single instance — opening a project from your file manager brings the window you already have to the front.

🏷️ The TV Renamer and double episodes

A recording named S01E01 S01E02 — the two episodes separated by a space — was read as episode one alone and filed as a single episode. That form is now understood, along with S01E01 & S01E02 and S01E01, S01E02.

Selecting both halves also kept the part marker from the first title, so a file covering two episodes came out numbered as two and titled as part one. The marker is dropped when a file holds more than one episode. A title that merely ends in something marker-shaped — Apollo 13, Catch-22 — is left alone.

🔊 Joining scenes that do not match

Scenes that share a format are joined without re-encoding, and that path kept every audio track. Scenes that do not match have to be re-encoded, and that path carried only the first — so an audio description or second language was lost on those joins. Every track the scenes have in common is now carried, each at its own channel layout and bitrate.

Smaller things

  • Advert detection invents fewer breaks. Where the learned logo and the general corner search disagree, the learned logo wins. It is now held to the same standard itself: a logo that is hard to make out against a busy background used to read as missing for a minute at a time, and that was proposed as a break. Five false breaks gone across the test recordings, with no real break lost.
  • Snipwright could refuse to learn a logo from a perfectly good recording, because it expected your recorder to pad the start and end. Most recorders do not (by default), and the padding was never used for the learning anyway.
  • Adjusting both ends of a cut at once moved only one of them. A marked span overlapping an existing cut now becomes that cut, both ends together.
  • The export summary printed a whole explanation as raw Python data, brackets and all, where a one-line note belonged.
  • "Show tooltips on the transport controls" turned off every tooltip in the program, including ones that carry information nothing else shows. It now does what it says.
  • The user guide understated how far cut marks can drift between Snipwright and VideoReDo: a dozen frames in either direction is closer than "a frame or two".

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, or with a subtitle track missing, the log from that run is the single most useful thing you can attach. The full changelog is in CHANGELOG.md.

v2.7.0

Choose a tag to compare

@infidelus infidelus released this 10 Sep 20:39

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 det...

Read more

v2.6.0

Choose a tag to compare

@infidelus infidelus released this 05 Sep 11:06

Snipwright 2.6.0

A bug fix release, and a substantial one. Channel 4 HD recordings could not be exported at all; 5.1 audio was lost to MKV; audio description tracks were dropped from cuts that began in an advert break; and a cut spanning a break could produce a video with the right length and no sound. All four are fixed.

The Watcher no longer re-detects everything when a network share comes back, the joiner reports what it is doing honestly, and the checks that are supposed to catch a bad export now actually can.

Nothing here adds a feature. If 2.5.0 has been working for you on the recordings you make, most of this will pass you by — but if you record Channel 4 HD, or keep recordings on a NAS, or use the joiner, at least one of these has almost certainly bitten you.

📺 Channel 4 HD, and audio that went missing

Four separate faults on one recording, found while chasing a single report.

The export failed outright. UK broadcast AAC is LATM-framed, and the reader that unpacks it walked off the end of a damaged frame instead of reporting it as unreadable. The exporter is built to skip a frame it cannot parse; this particular failure went straight past that and stopped the export with "index out of range". The same reader was also mis-measuring the configuration header and rejecting frames that were perfectly good.

5.1 audio was lost from MKV exports. The output track was created without a channel layout, so it was built as stereo whatever the recording actually contained. MP4 escaped it because of how that container is written, which is why this looked like an MKV-only fault for a long time. A recording that is 5.1 from beginning to end, with no change anywhere in it, was enough to trigger it.

Audio description tracks were dropped from cuts starting in a break. An AD track carries nothing during continuity announcements and advert breaks, so a cut beginning in one of those gaps has its first AD packet half a minute in. The checks that inspect a cut gave up long before reaching it, read the track as having no channels and no sample rate, and either failed the mux or quietly left the track out.

A cut spanning a break could come out silent. This was the hardest of the four. Broadcast AAC changes its channel configuration at the breaks — Channel 4 HD runs continuity in stereo and the programme in 5.1, thirteen times in a three-hour recording. MPEG-TS carries that configuration with every frame, so a .ts export plays correctly; MKV and MP4 hold one configuration for the whole track, so copying such a cut gave a track with the right length and no audio.

Snipwright now replaces only the minority frames — 83 out of 415,649 on the recording this was found with — and passes everything else through untouched. The 5.1 mix is kept, the repair takes seconds rather than the ten minutes a full re-encode of a feature film costs, and every timestamp in the original is carried across unchanged, so a recording with broadcast dropouts in it stays in sync. A cut that spans no configuration change is left completely alone.

Where a recording changes configuration too widely to patch — more than a twentieth of its frames — the whole track is re-encoded instead, and that now keeps whichever configuration the recording mostly uses rather than collapsing everything to stereo. It also keeps the recording's own bitrate. Wherever Snipwright has to re-encode audio it used to impose a flat 192 kbps whatever the source was; it now follows what the recording has, and says nothing to the encoder at all when that cannot be read rather than substituting a figure.

🔍 Checks that could pass a bad file

Three of them, all quietly wrong.

A good MKV export was thrown away over two damaged frames. The check confirming the audio survived the repackage failed on any decoder complaint at all. Broadcast recordings carry a few frames no decoder can read — 53 out of 500,483 on the recording this was found with — and those are in the source, the intermediate and the finished file alike. Two of them were enough to condemn a perfectly good export: it was rebuilt, saw the same two frames, and re-encoded the whole track. An hour of work and a real loss of quality, to fix nothing.

The MKV audio check sampled six thirty-second windows. The fault it exists to catch is a scattering of bad frames across a long recording, and three minutes of a three-hour film will nearly always miss them, so a repackaged MKV could carry brief glitches at scene starts and still be reported as verified. It now checks the whole recording. That costs about twenty seconds on a three-hour file, on an export that already takes minutes.

Nothing counted the frames. A track that has lost most of its content decodes perfectly — which is exactly why a decode check alone could not catch it, and how a two-and-a-half-hour film once finished with two minutes of audio in it and passed. Both MKV and MP4 now count the audio in the finished file against the cut it was built from. Every track is counted, not just the first: an audio description track is silent for long stretches by design, which makes it the likeliest to fail without anyone noticing, and it is never the first track.

📡 The Watcher and network shares

If your recordings live on a NAS, this is the one to read.

The Watcher keeps a list of the recordings it has already looked at, and dropped any entry whose file it could not see. A recording that has been deleted and a recording on a share that is rebooting look exactly alike to that check — so a server going down for maintenance, or a share being renamed, emptied the whole list at once. Every recording on it was then detected again from scratch when the share came back. A week's recordings is a long evening's work for nothing.

A folder the Watcher cannot read is now left strictly alone: nothing under it is forgotten, however long it stays away, and the log names the folder it could not reach. That check does more than ask whether the folder exists, because a stale mount can leave the folder looking perfectly healthy while every read of it fails.

Anything else that disappears is held for a period set by Keep missing recordings for (hours) under Scanning, a day by default, and only forgotten once it has stayed missing that long. Set it to 0 for the old behaviour of forgetting a recording as soon as it cannot be seen. A recording that genuinely has been deleted still ages out, so re-recording to the same name is still picked up.

The Watcher's settings window also opens at the size its contents need. Several of the number boxes were being squeezed and had their values clipped along the bottom, and the folder list was reserving room for far more entries than anyone watches.

🔗 The joiner

Progress was misleading throughout. The bar ran to 11%, jumped back to zero and up to 11% again, once per scene. Worse, converting the joined file to MP4 — a full re-encode, and the longest part of the run — was squeezed into the last few percent, so the bar sat near the top for minutes with nothing appearing to happen.

A join is really several jobs: cutting each scene, joining them, then writing the result in the requested format. Each now gets the whole bar in turn, the way an ordinary export does. Within a stage it only ever moves forwards, and the line beneath it shows a time estimate once enough of that stage is done to give an honest one.

Cancel did nothing while a join was converting to MP4. The dialog vanished and immediately came back, the conversion carried on to the end, and a second click landed on the video underneath and started it playing. Cancel now stops the conversion, and the dialog stays up and says it is cancelling.

Joining surround recordings flattened them to stereo. When the joiner has to re-encode rather than copy — scenes that do not match, or anything with a fade or a title card — it normalised every scene to stereo before joining. It now joins at the widest layout present, so surround survives and a stereo title card no longer drags the programme down to match it.

It finished with a one-line box where an ordinary export gets the full figures. That was the wrong way round: a join is the operation most likely to have quietly re-encoded and reshaped several recordings into one. It now reports length, size, scenes, frame counts, tracks and bitrate, all measured from the finished file, and says plainly when the scenes had to be re-encoded.

Two smaller ones: the Save Video dialog opened on the wrong profile — it picked the last profile using a given container rather than the first, so anyone with several MKV profiles was handed whichever was at the bottom of the list, and from the joiner this happened every time. And a five-scene join wrote "Export complete" to the log five times before the real one, because each scene is rendered before they are joined.

🐛 Also fixed

  • Removing a batch job left its project file behind. Queue to Batch writes a staging project into the configuration folder for each job, and nothing ever removed one, so the folder grew for as long as the feature was used. Projects you added to the Batch Manager yourself are never touched — only the copies Snipwright staged for itself.
  • A failed audio adjustment crashed the export. Asking for an audio delay, a surround downmix or loudness processing that ffmpeg then could not apply raised an internal error, rather than finishing and saying plainly that the cut was fine but the adjustment had not been applied.
  • Quick Stream Fix could fail when the recording was already open. Where the working copy's name was already taken — the same recording loaded, or a background export still reading it — the code picking an alternative name raised an internal error, and would have put that copy in the system temporary folder rather than the one set in Settings.
  • An export that copied both streams into MP4 said it was recoding. T...
Read more

v2.5.0

Choose a tag to compare

@infidelus infidelus released this 29 Aug 14:43

Snipwright 2.5.0

Finding the adverts no longer needs a second program. Chalkline is built into Snipwright, needs nothing installed or configured, and learns each channel's logo from the edits you make. Comskip is still fully supported and is now a choice rather than a prerequisite.

Alongside it: EDL cut lists can be imported and exported properly, the Quick Stream Fix working folder can be moved off a small system drive, output profiles can drop the audio entirely, and both user guides have been brought up to date in English and German.

🎯 Chalkline, a built-in advert detector

Detecting commercials meant finding, installing and configuring Comskip, then pointing Snipwright at it and tuning an .ini per source. Chalkline is part of Snipwright. There is nothing to install and nothing to set up.

It reads three things from the recording — the channel logo, the shape of the picture, and the aspect ratio the broadcaster declares — and where they disagree it prefers to report nothing rather than guess. That trade is deliberate. A missed break costs you a manual pass through the timeline; an invented one silently removes part of the programme, and that is not recoverable once the video has been saved. So a recording Chalkline says nothing about is one to mark by hand, not one where the adverts were quietly missed.

Which detector runs is chosen in Settings → Advert detection, and the choice applies to both Detect Commercials in the editor and the Watcher's unattended scans — there is no way for the two to disagree. Comskip's program path, its .ini and the per-channel .ini selection have moved onto that page from External tools, so everything to do with finding adverts is now in one place.

Chalkline is a little slower than Comskip — a few per cent over a run of several recordings — because it decodes the recording rather than reading the broadcast's own signalling. On a single programme it is not a difference you would notice.

It learns from your edits

Correct a detection, save the project, and Chalkline remembers what that channel's logo looks like. The next recording from that channel is detected better.

It only ever learns from a project you have edited yourself. The Watcher's output is deliberately excluded — that is the detector's own guess, and learning from it would compound whatever it got wrong. Several other conditions have to hold too, all of them about having trustworthy ground truth: the project has to be a .vprj rather than an EDL, the edit has to keep more than half the recording and contain breaks of a plausible length, and nothing can already be remembered for that channel. A logo that is working is never silently replaced, because one poor edit could otherwise undo a good one with nothing to show it had happened.

Learning decodes the whole recording, so it takes several minutes and finishes well after the save that triggered it. The status line says when it starts and when it finishes; a save that will teach nothing stays silent.

Settings → Advert detection → Remembered logos shows what has been learned, with each mask drawn, its size and contrast, and a Forget button to force a fresh start on a channel that is not working well.

If your recordings come from two different machines

This is worth knowing if you record the same channels on more than one box. Recorders disagree about what they keep: some preserve the channel name, others only the numeric service ID. Neither keeps both, and nothing in a recording connects one to the other — so the same channel recorded two ways is learned twice, and neither entry helps the other.

The Remembered logos dialog lets you pair them up by hand. Fill in the missing half of a row and the logo is used for recordings from both. It is the one thing in there you may actually need to do.

✂️ EDL cut lists can be imported and exported

Snipwright could read the EDL Comskip produces during detection, but there was no way to load one of your own. Choosing an .edl through Import Project gave a syntax error, because the file was being handed to the project reader, which expects XML. Dragging one onto the window did nothing at all, and opening one from a file manager pointed at a File → Import → EDL menu entry that has never existed.

An EDL holds cut times and nothing else — no reference to the recording it describes — so it cannot open a video the way a project can. Import Project now accepts EDLs and applies them to the video already open; if none is, it offers to find the recording the cut list belongs to. Dragging one onto the window and opening one from a file manager both do the same thing.

Cut lists can be written out too, as a second format in Save Project As. An EDL saved this way does not become the current project, so Ctrl+P still saves a full .vprj and cannot quietly replace your work with a copy that has no marks in it.

Because an EDL names no video, nothing normally stops one being applied to the wrong recording — and the result looks plausible rather than broken. Two shapes are now stopped for: a cut list running past the end of the video, which nothing legitimate does, and one covering less than half of it, which usually means the times came from a shorter recording. Neither is certain, so both ask rather than refuse.

💾 The Quick Stream Fix working folder can be moved

Repairing a recording writes a working copy — a full remux, so roughly the size of the original — and the editor cuts that copy. Those copies used to go to the system temporary folder with no way to move them. On Windows that folder sits on the system drive, usually the smallest one on the machine.

Settings → Maintenance now has a folder box above the existing retention setting. Leave it blank and behaviour is exactly as before. If the folder you set goes missing or cannot be written to — a disconnected share, a renamed drive — the system folder is used instead rather than the repair failing.

Deleting old copies, which Snipwright has done since 2.1.0, never helped with this: it does nothing when a single repair needs more room than the drive has. Two different problems, and only one of them had a fix. Raised by PaulWebster, who filled a Windows system drive part-way through a repair.

🔇 Export without audio

Output profiles gain a third audio setting, "No audio (silent)", alongside the lossless copy and the AAC re-encode. Useful for a recording with background noise you would rather lose entirely than keep.

The tracks are never offered to the cutter rather than being stripped afterwards, so nothing is decoded, re-encoded or muxed on their account and the export is quicker. Bitrate, surround and loudness grey out when it is chosen, since there is no longer a track for them to act on. It applies to every track, so audio description and alternative languages go with it.

🇩🇪 German, and the guides

Everything new in this release is fully translated. Four longer-standing German faults are fixed too, none of which any count of untranslated strings could have found — in each case the string was present and marked as translated, and simply never looked up. Every Settings page was showing an English heading above German controls. The file and folder field labels — Comskip's program and .ini, the three Files & folders paths, the log folder, and the mkvmerge, ffmpeg and ffprobe paths — were never marked for translation at all. Two age settings on the Maintenance page read "30 days" and "never" directly below a third reading "7 Tage". And eight strings addressed the reader informally while the rest of the interface used the formal form.

Both user guides now cover everything added since 2.4.0: choosing a detector, how Chalkline works and why it reports nothing rather than guessing, learning channel logos, the Remembered logos dialog, the silent audio option, the configurable working folder, and the Watcher following the editor's detector choice. Comparing the two guides section by section also turned up three places where the German had quietly lost content — a paragraph on the skip distances, a whole note on multi-track audio and DVB subtitles, and two sentences on drag-and-drop opening.

🐛 Also fixed

  • The frame under the playhead no longer hides which scene it belongs to. It was drawn with a blue border instead of the yellow one marking scene membership, so the one frame whose membership matters most was the only one not showing it. Reported by PaulWebster.
  • An audio-description track carrying nothing during the programme is no longer reported as a fault asking for a bug report. Where the dropped track holds nothing within the scenes you kept, it is described as what it is. A track that genuinely holds audio and could not be written is still reported as a fault.
  • Settings pages no longer stretch their controls to fill the window.
  • Project files written by Comskip appear in the file dialog again. The filter matched .vprj and .VPRJ, but Comskip writes .VPrj, which is neither — so the files the dialog is most often pointed at were the ones it could not show.
  • Projects Snipwright writes now carry <SnipwrightVersion> rather than <VideoReDoVersion>. Both are read, so every existing project still opens, and the root element is deliberately unchanged so VideoReDo can still open Snipwright's projects.
  • Save Project As and the project pickers described the format as a "VideoReDo Project". Snipwright writes the same .vprj format and always will, but the dialogue is naming Snipwright's own output, so it now reads "Snipwright Project".

📺 HDR and 4K

Unchanged from 2.4.0, and still worth stating plainly: both are largely untested, because UK Freeview broadcasts neither and there is nothing off the tuner to test against. HDR metadata — mastering display, MaxCLL, MaxFALL, and Dolby Vision — is lost on export, leaving a file tagged BT.2020 and PQ with no static metadata. The single-threaded boundary decode in...

Read more

v2.4.0

Choose a tag to compare

@infidelus infidelus released this 13 Aug 10:18

Snipwright 2.4.0

Most of this release came out of one thread. Chasing why two exports of the same project were not identical turned up a fault in the boundary decoder, and fixing that made a run of older faults visible underneath it — a recording indexed at half its length, exports that needed Quick Stream Fix when nothing was wrong with the recording, and audio description tracks quietly going missing. It also carries the HDR colour and stream-splicing work that was prepared after 2.3.0 but never published.

If you have been running Quick Stream Fix on everything, or have edited a broadcast recording with audio description, this release is worth taking.

🔁 Exporting the same project twice now produces the same file

It did not. Two exports of one project, with a restart between, came out with their re-encoded segments different while every copied segment was byte-identical. The picture was never wrong and nothing was lost — the difference needed a frame-by-frame comparison to see at all — but it meant an export could not be checked against a previous one, so there was no way to tell whether a change to the cutting code had altered the output.

The decoder that feeds the boundary re-encoder was reading with frame threading across every core, and that does not return the same pixels every time when the machine is busy. Across five exports of one Channel 4 HD recording with the application playing in the background, 10 of the 686 frames handed to the encoder decoded differently — every one of them field-coded, and no progressive frame ever varied. One such frame changes every packet to the end of its re-encoded run, so a single frame moved 125 of them.

That decoder now runs on one thread. Only the GOPs at cut points are decoded at all — 833 frames for a five-minute recording — so it costs a few seconds, not a proportional slowdown.

🎨 HDR colour is now kept across every cut

The handful of frames re-encoded at each cut point used to be written with their colour unspecified, while the rest of the file declared BT.2020 and PQ. On one 10-bit HDR10 test cut that was 199 frames carrying their colour and 78 carrying nothing, which on an HDR display shows as a flash at every join. Those frames now carry the source's colour description, and a cut file is tagged the whole way through.

🔢 Spliced streams now carry one coherent picture numbering

Writing that colour into the re-encoded frames turned out to be enough, on its own, to break the join — a lost frame and Duplicate POC in a sequence from the decoder. That was not a colour fault. It was a splicing fault that the missing colour had been hiding.

Every picture in an HEVC stream carries a number identifying it within its sequence. Segments copied from the source keep the source's own numbering, so once segments from different points in a recording sit next to each other, two pictures can claim the same number. Measured on the 10-bit test file: two pictures both claiming 44, twenty-five pictures apart.

It went unnoticed because it was masked. The boundary encoder wrote a slightly different parameter set from the source's, so a decoder re-initialised at every switch between copied and re-encoded material and cleared the earlier picture away before the colliding one arrived. Supplying the colour makes the encoder reproduce the source's parameter set exactly — the stream becomes more correct — the two stop differing, nothing re-initialises, and the collision surfaces. ffmpeg-based players tolerated the old output; a decoder that does not re-initialise the same way need not have.

Each run of pictures in the output is now renumbered so the file carries one coherent sequence: 38 latent collisions to none on the test file, with the decoded picture byte-for-byte identical. Recordings whose keyframes are IDR rather than CRA — many commercial encodes — were never affected and are unchanged. If the renumbering meets something it cannot account for, it turns itself off for the rest of that export, writes the stream exactly as before, and says so in the log.

📏 A recording could be indexed at half its real length

A 2h38m film opened as 01:19:20, with the timeline scale and every reported timing halved to match. Scene markers still landed in the right places, which made it easy to miss until an export went wrong.

Field-coded recordings carry some frames as two field-pictures, and the index merges those back into one. It used to do that by rounding every packet onto a frame grid — but an odd number of half-frame gaps anywhere in the file leaves everything after it sitting exactly half way between slots, and consecutive frames then collapse into the same slot. Frames are now paired locally, so nothing depends on where the timestamps happen to fall.

🩹 Quick Stream Fix is no longer needed for ordinary recordings

Exporting a recording straight off the tuner produced a file with a video track and nothing in it, reported as "no readable video" — so Quick Stream Fix became a routine step before cutting anything.

The recording was fine. A recording that starts part-way through a GOP, which is normal off a tuner, had every GOP's end timestamp shifted one GOP earlier, so no packet fell inside one and nothing was copied. Quick Stream Fix appeared to cure it only because the repaired copy starts on a keyframe.

Confirmed on MPEG-2 SD and on a raw 1080i H.264 film, to .ts, .mkv and .mp4, all without it. Quick Stream Fix remains the right tool for a genuinely damaged recording — a signal dropout, or an interrupted capture.

🔊 Audio description tracks are no longer dropped

A BBC One recording with a working audio description track exported without it, reported as a track that "carries no audio in this recording". It carried plenty: 141,570 packets and audible description throughout.

Whether a track was usable was decided from the channel count and sample rate in the container header. Zeroes there mean the parameters could not be worked out, which is not the same as the track being empty, and some broadcast AD streams simply do not declare them. Probing harder does not help — this one still read as "0 channels, 0 Hz" with a 100 MB probe while decoding its first packets without difficulty. Snipwright now asks the decoder, and keeps the track if it produces audio.

A second fault sat behind that one: the first export of a file walks it and caches the result, and the next export loaded that cache and skipped the walk — which is what determines those parameters in the first place. So the track survived the first export and vanished from the next. Exporting to .ts worked and the .mkv straight afterwards did not.

If you have checked such a track by ear and thought it empty, it is worth another look. UK audio description is often a receiver-mix track carrying only the narration, silent between descriptions, so skipping through one lands in silence most of the time even when it is working perfectly.

🎬 Chapters become marks on the timeline

Opening a file that already has chapters — upscaled or re-encoded material usually keeps them, and Snipwright's own exports write your marks out as chapters — showed an empty timeline. The marks had to be found in another player and re-entered by hand. Chapter starts are now added as scene markers when the file opens, with a note in the status bar saying how many were loaded.

🧩 Interlacing at cut points

The frames re-encoded at each cut are meant to be coded as fields when the source is interlaced, or players skip deinterlacing and show combing on motion. Two things stopped that happening: whether a recording counted as interlaced was decided by decoding a single frame, and the decision was made once per export when each re-encoded run opens its own encoder.

Both are fixed. A run is coded as fields when the frame that opens it is itself interlaced, taking the field order from that frame. One case remains: a run that opens progressive and switches to interlaced part way through is still coded progressive, which is no worse than before but not yet right.

✅ Every export is now checked for its length

The check compared the output's packet count against the number of frames kept. On a field-coded source those count different things, so the check was skipped altogether — which is most UK HD. For those files the only verification was whether the output was completely empty, and the frame count shown afterwards was the number of frames requested rather than the number produced. A partial export looked exactly like a good one.

The finished file's duration is now compared against the length the edit asked for. Anything more than a second out is flagged, and the log records both figures on every export.

A small caveat that is not a fault: the reported length can differ by a few hundredths of a second. That figure is the container's span from the earliest track start to the latest track end, and sound sits on a different grid from video, so a track almost never ends on the same instant. A real frame difference is always a whole number of frames — 0.04s at 25fps — so a drift of 0.03s cannot be a missing frame.

🐛 Also fixed

  • Commercial detection appeared to restart part way through. It was not restarting: Comskip rescans a recording when it cannot settle on a logo, and the percentage genuinely returns to zero. The dialog now says which pass it is on.
  • Every cut segment was attributed to the last scene in the log and the progress dialog on recordings that carry the broadcast clock.
  • Clearing the cache in Settings cleared only one of Snipwright's two caches, so a file that had already been opened kept behaving as it did before.
  • A track lost to an export failure was described as a silent one that cost nothing. It is now reported as a fault.
  • The log claimed MKV audio had been converted to AAC when nothing had been converted, and claimed a...
Read more