Repository navigation
SmartCut v0.8.41
スマートレンダリング対応のカットツールです。**カット点にかかる部分 GOP だけを再エンコードし、残りはビット単位でそのままコピーします。**放送録画（MPEG-2 TS）から CM を落とす用途を主眼に置いています。
0.8.41 では、SteveYu000 さんの #13 を取り込みました。可変フレームレートの録画を、元の録画の時計のまま切ります。単体で書き出す .m2ts の到着時刻も直しました。こちらは同じ方が #10 で報告してくださったものです。あわせて、45 回目の点検で見つかった不具合を直しています。
索引（.scix）の形式が変わりました。0.8.40 で作った索引は、最初に開いたときに 1 度だけ作り直します。音声波形、CM 検出、黒白・無音検出の結果は索引とは別に保存しているので、そのまま使います。
前回の点検で見つかった重大な不具合は 1 件でした。今回は 3 件です。うち 2 件は #13 で入ったコードにあったもので、公開前に直したため、どの版にも入っていません。残る 1 件は 0.8.40 にもあった編集画面の不具合です（「直した不具合」の表の先頭）。1.0 は、重大な不具合の無い点検が 2 回続いたら出すと決めています。今回も数え直しになったので、1.0 までにはそうした点検があと 2 回必要です。
修正を終えたソースでは、検査付きのビルドでテストスイート 34 本がすべて通り、パニックもありませんでした。#13 で加わった時計のスイートは 95 項目すべてが通っています。GUI を操作するテストは、379 項目すべてが通りました。
ダウンロード
| ファイル | 対象 |
|---|---|
SmartCut_0.8.41_amd64.AppImage |
Linux x64。glibc 2.35 以上（Ubuntu 22.04 / Debian 12 / Fedora 36 以降）。FUSE が必要です |
SmartCut-0.8.41-linux-x86_64.tar.gz |
Linux x64 可搬版（193.4 MB）。展開して ./smartcut を実行します。中身は AppImage と同じ一式で、FUSE は不要です |
smartcut_0.8.41_amd64.deb |
Ubuntu 22.04 以降 / Debian 13 以降（29.8 MB）。GUI を smartcut、コマンドライン版を smartcut-cli としてインストールします |
SmartCut_0.8.41_x64-setup.exe |
Windows x64 インストーラ。WebView2 ランタイムが必要です。コマンドライン版の smartcut-cli.exe も同じフォルダーに入ります |
smartcut-portable-x64-0.8.41.zip |
Windows x64 可搬版。展開して smartcut.exe を実行します。コマンドライン版は smartcut-cli.exe です |
どの配布物にも FFmpeg を同梱しています。別途インストールは不要です。
可変フレームレートの録画と時計
**0.8.41 は、可変フレームレートの録画を元の録画の時計のまま書きます。**SteveYu000 さんの #13 によるものです。対象は、TS 以外のコンテナに入ったプログレッシブの録画です。0.8.40 は、基準のレートを細かく割った格子にフレームを置いていました。固定フレームレートの録画は、これまでどおり公称のレートの格子に置きます。
可変かどうかの判定も変わりました。0.8.40 の判定に加えて、静止が繰り返し現れる録画も可変として扱います。間隔が 40・40・80 ms と並ぶ試験用ファイルは、0.8.40 では固定と判定されていました。切ると、最後のフレームが 53 ms で終わっていました。0.8.41 では元の録画どおり 80 ms です。
範囲の終わりも見直しました（.mkv・.mp4・.mov）。最後の範囲の最後のフレームが、範囲の終わりを越えて残らなくなりました。0.8.40 では、平均のフレーム 1 枚分の長さだけはみ出していました。
| 試験用の録画 | 0.8.40 | 0.8.41 |
|---|---|---|
| 平均 1.19 fps の画面録画、18.2 秒の範囲を .mkv に | 約 18.98 秒まで最後のフレームが残る | 18.201 秒 |
| B ピクチャを含む平均 5 fps の録画、2.9 秒の範囲を .mkv・.mp4 に | 3.033 秒（133 ms 長い） | 範囲の終わりまで（.mkv は 5 ms 以内） |
これで、0.8.40 の「残っている問題」に挙げた .mkv の末尾の件は解消しました。
単体で書き出す .m2ts の到着時刻
.m2ts の各パケットには、先頭に 4 バイトの到着時刻が付きます。0.8.40 は、FFmpeg が書いた値をそのまま残していました。この値はほぼすべてのパケットで前のパケットより戻っています。放送録画を 2 か所残して切った試験では、779,470 パケットのうち 776,511 が前より早い時刻でした。戻り幅は最大 14.4 秒です。
**0.8.41 は、書き終えた .m2ts の到着時刻を PCR から付け直します。**PCR を含むパケットはその PCR の時刻に、あいだのパケットは等間隔に置きます。188 バイトのパケットの中身は変わりません。
| 書き方 | 0.8.41 の動作 |
|---|---|
| カットや音声のみの出力で書く .m2ts | PCR から付け直します |
--bdav、GUI の「BDAV 出力」タブ |
ディスクを書くときにこれまでどおり付けます。出力は 0.8.40 と変わりません |
BDAV/STREAM の中に名前を直接指定した .m2ts |
ディスク出力ではないので、付け直します |
| PCR が無いか、途中で戻るストリーム | 書いたまま残し、メッセージを出します |
| 付け直しの途中で読み書きに失敗したとき | メッセージを出しますが、カットは失敗扱いにしません。到着時刻は書いたまま、または途中まで付け直した状態で残ります。188 バイトのパケットは変わらないので、再生はできます |
直した不具合
| 対象 | 以前の症状 |
|---|---|
| カット編集（可変フレームレートの録画） | 先頭近くのフレームに IN を置いて「✂ カット」を押すと、IN より前のフレームも消していました。画面には IN の位置に [ が出たままなので、見ただけでは気づけません。平均 1.19 fps の試験用の画面録画では、2〜9 枚目のどれに IN を置いても同じでした。最後から 2 枚目のフレームに置いた OUT も、末尾として扱っていました |
| 「継ぎ目の編集」ウィンドウ（基準クリップを指定したとき） | 前のクリップのレートでプレビューしていました。試験では、平均 9 fps の画面録画のあとに 29.97 fps の .ts を基準クリップとしてつなぎました。このときプレビューは 1 フレームで 0.11 秒進みました。出力は元から基準クリップのレートです |
| 可変フレームレートのクリップにかかる黒・白のフェード（フェードイン・フェードアウト） | クリップのフレームが音声から約 1 フレームずれていました。番号入りの 30 fps の試験用ファイルを、フレームの間隔を不規則にして試しました。ずれは 0.8.40 で 42 ms、0.8.41 で 1〜2 ms です。フェードアウトでは、次のクリップの位置も後ろへずれていました |
--sound-only の出力の説明行 |
字幕やテーブルも書くかのように表示していました。0.8.41 では音声 1 本だけと表示します |
| 拡大表示（可変フレームレートの録画） | → で次のフレームへ進んでも、拡大表示が前のフレームのまま変わらないことがありました。フレームの間隔が平均より短いところで起きていました |
カット結果が 0.8.40 と変わる場合
公開するビルドと 0.8.40 のビルドで、同じ入力を切り比べました。Linux と Windows（wine 上）の両方で試しています。試したのは、放送録画のカット、2 か所を残すカット、結合です。ほかに .mp4・.mkv へのコンテナの移し替えと、レコーダーで録った .m2ts のカットも試しました。.ts と .mp4 はバイト単位で同じ、.mkv はパケット単位で同じでした（framemd5 で比較）。.m2ts は 188 バイトのパケットがすべて同じで、変わったのは到着時刻だけです。0.8.40 の出力では到着時刻が 587,240 回前へ戻っていましたが、0.8.41 では 1 回もありません。
| 入力・操作 | 変わる点 |
|---|---|
| TS 以外の可変フレームレートの録画（プログレッシブ） | フレームの時刻が元の録画どおりになります。0.8.40 が固定と判定していた一部の録画も、可変として扱います |
| B ピクチャを含み、フレームが落ちている .mp4 | 0.8.40 が落としていたピクチャ 1 枚も残ります。ファイル全体を読むので、開くのに時間がかかります |
| 単体で書き出す .m2ts | 各パケットの到着時刻 4 バイトだけが変わります |
| 可変フレームレートの録画を .mkv・.mp4・.mov に切ったときの末尾 | 最後のフレームが、範囲の終わりを越えて残らなくなります |
| 可変フレームレートのクリップにかかる黒・白のフェード（フェードイン・フェードアウト） | フェードのフレームの長さと、そのあとのフレームの位置が変わります |
これ以外のカットでは、コピーした部分は 0.8.40 とバイト単位で同じです。再エンコードした継ぎ目も、フレームの時刻と、前後にコピーしたパケットが同じでした。すべてコピーで済む出力と --bdav のフォルダー出力は、ファイル全体がバイト単位で同じです（.mkv はパケット単位）。
残っている問題
| 対象 | 症状 |
|---|---|
| 映像より音声が長い録画 | 正しく切れていても、--verify が OFF と表示します |
| 可変フレームレートの録画 | 隣り合うフレームで続けて k を押しても、印が 1 つにまとまることがあります |
| 時間単位が 10 MHz で B ピクチャの階層が深い、可変フレームレートの .mp4 | 正しく切れていても、--verify が MISMATCH と表示することがあります |
| 大きな .m2ts | 到着時刻を付け直すあいだ、進行表示が止まって見えます |
ドキュメント
English
SmartCut is a smart-rendering cutter: only the partial GOPs at each cut point are re-encoded; everything else is copied bit for bit. It is built mainly for cutting the adverts out of broadcast recordings (MPEG-2 TS).
0.8.41 brings in #13 by SteveYu000, which cuts variable-frame-rate recordings on their own clock. It also gives a .m2ts written on its own proper arrival times, a problem the same contributor reported in #10, and it carries the fixes from the forty-fifth review pass.
The seek index (.scix) format has changed, so an index made by 0.8.40 is made again, once, the first time the recording is opened. Waveforms, CM results and black/white and quiet detections are kept apart from the index and are all kept.
The pass before this one found one serious bug. This one found three. Two were in #13's code and were fixed before release, so no release ever had them. The third was already in 0.8.40: the editor bug at the top of Bugs fixed. The rule agreed for 1.0 is two passes in a row with no serious bug, so the count starts again: 1.0 still needs two more such passes.
The final tree passed all 34 test suites on a checked build, with no panics, including all 95 checks of the source-clock suite that came with #13. The GUI suite passed all 379 of its checks.
Downloads
| File | For |
|---|---|
SmartCut_0.8.41_amd64.AppImage |
Linux x64, glibc 2.35 or newer (Ubuntu 22.04 / Debian 12 / Fedora 36 and later). Needs FUSE |
SmartCut-0.8.41-linux-x86_64.tar.gz |
Linux x64, portable (193.4 MB). Unpack and run ./smartcut. Same contents as the AppImage, no FUSE needed |
smartcut_0.8.41_amd64.deb |
Ubuntu 22.04 and later / Debian 13 and later (29.8 MB). Installs the GUI as smartcut and the command-line tool as smartcut-cli |
SmartCut_0.8.41_x64-setup.exe |
Windows x64 installer. Needs the WebView2 runtime. The command-line tool, smartcut-cli.exe, goes into the same folder |
smartcut-portable-x64-0.8.41.zip |
Windows x64, portable. Unzip and run smartcut.exe; the command-line tool is smartcut-cli.exe |
Every download bundles FFmpeg; nothing else needs installing.
Variable-frame-rate recordings keep their own clock
With SteveYu000's #13, a variable-frame-rate recording is written on the recording's own clock. This covers progressive recordings in anything but a transport stream. 0.8.40 laid their pictures on a grid cut finely from a base rate. Constant-rate recordings stay on their nominal grid, as before.
Deciding what is variable has changed too: on top of 0.8.40's test, a recording that keeps coming to a hold now counts as variable. A test file whose pictures come 40, 40 and 80 ms apart was taken for constant by 0.8.40, and a cut of it ended its last picture at 53 ms; 0.8.41 keeps the source's 80.
The end of a range has been looked at as well (.mkv, .mp4, .mov). The last picture of the last range no longer stays up past the end of the range; 0.8.40 let it run on for the length of an average frame.
| Test recording | 0.8.40 | 0.8.41 |
|---|---|---|
| Screen recording averaging 1.19 fps, an 18.2 s range to .mkv | Last picture still up at about 18.98 s | 18.201 s |
| B pictures, averaging 5 fps, a 2.9 s range to .mkv or .mp4 | 3.033 s, 133 ms too long | Ends with the range (.mkv within 5 ms) |
That settles the .mkv item in 0.8.40's known issues.
Arrival times in a .m2ts written on its own
Every packet in a .m2ts carries a four-byte arrival time in front of it. 0.8.40 left the values FFmpeg wrote, and those step backwards on almost every packet: in a two-range cut of a broadcast, 776,511 of 779,470 packets arrived before the one in front of them, by as much as 14.4 s.
0.8.41 restamps a finished .m2ts from its PCRs. A packet carrying a PCR arrives at it, and the packets in between are spread evenly. The 188-byte packets themselves are untouched.
| How the file is written | What 0.8.41 does |
|---|---|
A .m2ts from a cut or from --sound-only |
Restamped from the PCRs |
--bdav, or the GUI's BDAV disc tab |
Stamped when the disc is written, as before; the output is the same as 0.8.40's |
A .m2ts named by hand inside a BDAV/STREAM folder |
Not a disc write, so restamped |
| A stream with no PCR, or one whose PCRs step back | Left as written, with a note |
| A read or write error during the restamp | A note, and the cut does not fail. The arrival times are left as written, or rewritten only part of the way; the 188-byte packets are untouched, so the file still plays |
Bugs fixed
| Where | What happened |
|---|---|
| The cut editor, on a variable-frame-rate recording | ✂ Cut with IN on one of the first few pictures also removed the pictures before IN, while the editor still drew [ where IN was put. On a test screen recording averaging 1.19 fps this happened with IN on any of pictures 2 to 9. OUT on the last picture but one was likewise taken for the end |
| The “Between the clips” window, with a master clip named | Previewed at the rate of the clip before the seam. A screen recording averaging 9 fps followed by a 29.97 fps .ts as the master stepped 0.11 s a frame. The output was always at the master's rate |
| Fades to black or white on a variable-frame-rate clip, in or out | The clip's pictures were about a frame off its sound: on a numbered 30 fps test file with jitter added, 42 ms in 0.8.40, 1 to 2 ms in 0.8.41. Fading out also pushed the next clip later |
--sound-only's summary line |
Read as if captions and tables were written too. It now says one sound track and nothing else |
| The magnifier, on a variable-frame-rate recording | → to the next picture could leave the magnifier on the one before. It happened where pictures come closer together than the recording's average |
When a cut differs from 0.8.40
We cut the same inputs with the release builds of 0.8.41 and 0.8.40, on Linux and on Windows (under wine): a broadcast cut, a keep of two ranges, a join, rewraps to .mp4 and .mkv, and a cut of a recorder's .m2ts. The .ts and .mp4 outputs were byte-identical, and the .mkv packet-identical (compared with framemd5). The .m2ts kept every 188-byte packet and changed only its arrival times, which no longer step back: 587,240 backward steps in 0.8.40's file, none in 0.8.41's.
| Input or operation | What changes |
|---|---|
| A progressive variable-frame-rate recording, not in a transport stream | Pictures sit at the source's own times. Some recordings 0.8.40 took for constant are now treated as variable |
| An .mp4 with B pictures and dropped frames | The picture 0.8.40 lost is kept. The whole file is read to open it, so opening takes longer |
| A .m2ts written on its own | Only the four-byte arrival time of each packet |
| The end of a variable-frame-rate cut to .mkv, .mp4 or .mov | The last picture no longer runs past the end of the range |
| A fade to black or white on a variable-frame-rate clip, in or out | The lengths of the fade's pictures, and where the pictures after it sit |
In every other cut, the copied parts are byte-identical to 0.8.40, and the re-encoded seams match it in their timing and in the packets copied around them. A cut that is copy throughout, and a --bdav folder, is byte-identical as a whole (.mkv packet-identical).
Known issues
| Where | What happens |
|---|---|
| A recording whose sound outlasts its pictures | --verify says OFF even on a correct cut |
| A variable-frame-rate recording | k pressed on two neighbouring pictures can leave a single mark |
| A variable-frame-rate .mp4 with a 10 MHz timescale and a deep B-picture pyramid | --verify can say MISMATCH even when the cut is right |
| A large .m2ts | The progress display stands still while the arrival times are rewritten |