v2.6.0

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. The label was chosen before anything looked at the audio, so a recording copied through untouched was announced the same way as one being re-encoded and downmixed. It now says what is actually happening.
• A repaired recording, and an exported one, no longer said which channel they came from. Quick Stream Fix rebuilds the file, and the rebuild wrote a default service name in place of the broadcaster's; exports lost both the name and the service number. Advert detection keys what it learns on those, so this mattered more than it looks.
• The audio repair and the verification step now show progress rather than an indeterminate bar. The repair also reports itself as Repairing audio rather than Recoding, which it never was.
• Save Video remembers whether you want only your favourites.

🇩🇪 German

Everything new here is fully translated, and the German user guide gains the same Recordings on a network share section as the English one.

📺 HDR and 4K

Unchanged, 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 introduced in 2.4.0 has been measured only on 1080p H.264; its cost on 4K HEVC is unknown.

If you record HDR or 4K off a PVR and can share a sample, that would be genuinely useful.

What has been tested

The audio work was verified on the Channel 4 HD recording that prompted it — .ts, .mkv and .mp4 all in sync, both audio tracks present and correct. Beyond that, five recordings covering Channel 4 HD, ITV1 HD, two SD channels and the mixed-configuration film were each exported to all three containers, and every output came out at the correct duration with the correct track count, order and language.

Recordings from two different PVRs were used throughout, which matters more than it sounds: they preserve different halves of a recording's channel identity, and several of the fixes here depend on that.

---

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.