v0.3.4

スマートレンダリング対応のカットツールです。**カット点にかかる部分 GOP だけを再エンコードし、残りはビット単位でそのままコピーします。**放送録画（MPEG-2 TS）から CM を落とす用途を主眼に置いています。

0.3.4 では、出力する音の形を選べるようにしました。カットは録画自身の音声フレームをコピーするので、放送のカットは 48 kHz の AAC のまま出てきます。それが正しい答えなのは、そのファイルに行き先がないあいだだけです。AC-3 を求めるアンプ、サラウンドを持て余す再生環境、2 世代目の非可逆を渡されたくない編集者。コーデック・サンプリング周波数・量子化ビット数の 3 つがそれに答え、書けない組み合わせは書き出しの最後ではなくその場で灰色になります。

ダウンロード

ファイル	対象
SmartCut_0.3.4_amd64.AppImage	Linux x64。glibc 2.39 以上（Ubuntu 24.04 / Debian 13 / Fedora 40 以降）。FUSE が必要です
SmartCut-0.3.4-linux-x86_64.tar.gz	Linux x64 可搬版。解凍して ./smartcut。中身は AppImage と同じ一式で、FUSE は不要です
smartcut_0.3.4_amd64.deb	Debian 13 / Ubuntu 25.04 以降。3.0MB。GUI を smartcut、コマンドライン版を smartcut-cli として入れます
SmartCut_0.3.4_x64-setup.exe	Windows x64 インストーラ。WebView2 ランタイムが必要です
smartcut-portable-x64-0.3.4.zip	Windows x64 可搬版。解凍して smartcut.exe を実行します

FFmpeg を別途入れる必要があるのは deb だけです。ほかの配布物には同梱しています。

0.3.3 からの変更

出力する音声コーデックを選べます

--audio-codec source|aac|lpcm|ac3|dts です。AAC は放送が運んできたもので、どの携帯電話でも受け取れます。AC-3 はディスクプレイヤーが期待し、アンプが問い返さずにデコードするものです。DTS はアンプが対応しているもう 1 つです。リニア PCM はコーデックですらなく、サンプルをそのまま書き下ろしたものです。

書けるようにするのに 3 つ片付ける必要がありました。libavcodec の DTS エンコーダーは実験的と印が付いていて、それを承知していると伝えないかぎり開きません。6 チャンネルは 1 つの配置ではなく複数あり、並べていない配置を渡されたエンコーダーもやはり開かないので、配置は決め打ちせずエンコーダー自身に問い合わせます（サンプル形式も同じです）。そしてリニア PCM がトランスポートストリームで読めるのは、そのストリームが HDMV として登録されているときだけです。登録せずに同じバイト列を書くと、どの読み取り側もそのトラックを bin_data と呼んでデコードしません。MP4 には Blu-ray LPCM を格納する箱が無いので、そこでは同じサンプルがビッグエンディアンの素の PCM として入ります。

コーデックを変えるとコピーできるフレームが無くなるので、--audio-mode が何であれ全編を焼き直し、その旨を通り道で明示します。

サンプリング周波数と量子化ビット数

--audio-samplerate 48k と --audio-bits 16|24 です。リサンプラは swresample のもので、ダウンミックスと同じですが、あちらがフレームごとに走るのに対しこちらはトラック全体で 1 つのコンテキストです。リサンプラはフィルタなので、出力の格子が入力の格子に乗らず、常に一部のサンプルが呼び出しのあいだに保持されます。フレームごとに作り直せば、それが毎回落ちてしまいます。

量子化ビット数が意味を持つのはリニア PCM を書くときだけです。ほかのコーデックは音そのものではなく音の記述を書くので、幅の置き場所がありません。非圧縮トラックの大きさは算術で決まる（チャンネル数 × ビット数 × サンプリング周波数）ので、画面はビットレートの代わりにその値を出します。

書けない組み合わせは、その場で灰色になります

5 つの設定の組み合わせが、どれもファイルになるわけではありません。Blu-ray の LPCM は 48・96・192 kHz だけで、そのあいだがありません。**DTS はモノラル・ステレオ・クアッド・5.0・5.1 でしか書けません。**しかも 1 フレームは決まった数のサンプルを運びながら、その中の全チャンネルを記述できる長さを要求します。そのためビットレートに下限があります。下限はチャンネル数とサンプリング周波数で動きます。5.1ch の 48 kHz は 768 kbit/s から、同じトラックでも 32 kHz ならもっと下で書けます。

どれも書き出しの終わりに気付くようなことではありませんし、ウィンドウ側に表を持つようなことでもありません。答えはこのビルドがリンクした FFmpeg のものであり、表にすれば静かに古くなります。そこでエンジンがエンコーダーを実際に開いて確かめます（audio::opens_at）。出力設定画面は自分が並べている候補をエンジンに送り、そのうちカットが受け取れるものを返してもらいます（cut::writable_sound）。リストごとに、ほかの答えをそのままにして、一覧のすべてのトラックが揃って書けるものだけを返します。

書けない候補は消さずに灰色で残します。理由を示さずに短くなった一覧は、何が無いのかを示せないためです。どれが灰色になるかはほかの設定と一緒に動きます。44.1 kHz を選べば リニア PCM が灰色になり、コンテナを MP4 に変えればまた選べるようになります。そこではレートを選ばない素の PCM になるためです。

保持している設定自体が書けないとき（下限を把握していなかった頃のプロジェクトなど）は、**ビットレートから順に、コーデックを最後にして手放していきます。**そうしないとどのリストも空で返ってきて、選ぶものが無くなります。

カットの側は、より寛容に扱います。画面を通らない呼び出しのために、エンコーダーが開けないビットレートでカットを止めることはせず、そのコーデックが通常運ばれる値まで上げたうえでその旨を伝えます。コーデックが扱えないレートを最も近いレートに直すのと同じ形の答えです。

素材より大きい値は出しません

チャンネル数・サンプリング周波数・量子化ビット数は、焼き直しなら素材より大きい値でも書けてしまいます。ただし書けることと情報が増えることは別です。2ch から作った 6ch は 2ch 分の音を 6 本に広げたもの、44.1 kHz から作った 48 kHz は同じ波形を多い点で描き直したもの、16 bit から作った 24 bit は下位 8 bit が 0 のままの同じ数値で、増えるのはファイルの大きさだけです。そのためこの 3 行は素材の値とそれ以下だけを出します。

一覧に対する「素材の値」は、その中で最も小さいものです。設定は一覧のすべてのクリップに適用されるので、ステレオの録画と 5.1ch の録画が並んでいれば上限は 2ch になります。新しく選べるようになった 96 kHz もこの規則の下にあり、LPCM やロスレス音声を 96 kHz で収めた Blu-ray でだけ選べて、48 kHz で標本化された放送では灰色になります。これは画面の規則であって、エンジンの規則ではありません。コマンドラインは、そう指定されればいまも素材より上へリサンプルします。

出力設定の 5 行は、必要なモードのときだけ現れます

音声コーデック・音声チャンネル・サンプリング周波数・量子化ビット数・音声ビットレートは、モードが すべて再エンコード のときだけ画面に出ます。どれもエンコードの内容を指定するもので、ほかの 2 つのモードは全編のエンコードを行わないためです。項目が増えてきたので、用の無いモードの下に 5 行が灰色で居座るのはやめました。値は消さずにしまってあるだけなので、モードを戻せばそのまま使えます。しまわれているあいだ、その値はカットには渡りません。

ウィンドウの修正 2 つ

• エディタの情報行が、残す最初のトラックを見るようになりました。 libavformat は最も広いトラックを主トラックと呼ぶので、プレスされたディスクではそれが日本語ステレオの隣に座る英語 5.1 になります。2 本目だけを残して開いた録画が 5.1ch と表示されていました。
• どちらのウィンドウでも、画像がネイティブのドラッグを開始しなくなりました。 ドラッグされた <img> はページのドラッグではなくシステムのもので、WebKit はそれをコンポジタへ渡し、そこから画面上のすべてのウィンドウへ差し出されます。Wayland 上の KDE ではフィルムストリップを押して動かすと通り道のものが反応し、ポインタの下にあった VirtualBox のウィンドウがファイルを落とされたかのように答えていました。SmartCut のドラッグはすべて素のマウスイベントで運んでいるので、ネイティブのドラッグを断っても何も失いません。

一覧のサムネイルが、解析を待たずに出ます

この 1 項目だけは公開の後に足したもので、配布物は 2026-09-06 に建て直して差し替えてあります。タグ v0.3.4 も新しいコミットを指しています。

一覧の行の画像は、その録画を読むパスが作っていました。パケットをたどってアクセスポイントを拾い、キーピクチャをデコードしてサムネイルの帯にし、その帯の 1 割の位置から取ります。それが正しい画像であり、カットが入ればカットに合わせて取り直せるのも帯があるからですが、同時にそのパスが最後に出すものでもあります。それまで行は斜線の矩形のままで、パスは短くありません。1440x1080 の MPEG-2 で 30 分あたり約 10 秒、しかも一覧は 1 本ずつ読むので、一晩分の録画を放り込めば最後の行は数分のあいだ空欄で待ちます。落としたものが、まさにウィンドウに映りません。

ポスターは厳密なフレームである必要がありません。その録画を代表していればよく、だいたいその辺りの画像ならどれでもかまいません。パスが答えている問いより、ずっと軽い問いです。preview::glance はそちらを参照します。libavformat に割合を時刻として渡して自分でシークさせ、着地の後に最初にデコードできた画像をそのまま返します。シーク 1 回と GOP 1 つで、手元の素材では 3GB の放送録画まで含めて 10〜50 ms です。そのため行は追加された時点で問い合わせられ、処理がどこまで進んでいようと、落とした直後に一覧のすべてに画像が載ります。

注意点が 2 つあります。トランスポートストリームのシークはバイト位置なのでエントリーポイントの上ではなく近くに着きます。そのため、キーパケットが来るまでデコーダーには何も渡しません。そのうえでなお、最初に出てくる画像はシークが跨いだピクチャを参照していることがあり、それは灰色の面になります。最初の I ピクチャが答えで、その前に出たものは、ピクチャに型の付かない録画のための最後の手段としてだけ取ってあります。

そしてこの画像は、行が持ち得る 3 枚のうちの最後のものです。カットに合わせて取った画像があればそれ、無ければ索引パスが作った画像、どちらも無いあいだだけこれを使います。パスが終われば本物に入れ替わりますが、どちらも 1 割の位置から取るので、入れ替わりは目に付きません。

ドキュメント

音声の扱い（English）に「何が書けるのかを、書く前に確かめる」を足しました。ユーザーガイドの出力設定の表と README もこれに合わせています。

テスト

tests/run_audio_codec_tests.sh・tests/run_bd_audio_tests.sh・tests/run_audio_format_tests.sh の 3 スイートが新しく入りました。音声コーデックのスイートは、4 つのコーデックそれぞれを 4 種類のコンテナへ書き出し、3 つのことを確かめます。指定どおりのコーデックになっているか、5.1ch の各チャンネルが入れたときの音を保っているか、トランスポートストリームのマップが中身どおりのコーデックを宣言しているかです。加えて、下限を下回る 5.1ch DTS の 384 kbit/s と、DTS に配置の無い 3 チャンネルも要求します。前者は書いたうえでその旨を伝え、後者はチャンネル数に触れた一文で受け付けません。フォーマットのスイートはレートを 3 箇所すべてから読み、幅は出力ファイルの大きさから測り、リサンプルを通した A/V 同期を最悪 0.02 ms（全編再エンコードの基準は 1 ms）で確認します。

開発 VM で 16 スイート・246 チェックが 0 失敗です。tests/run_proxy_tests.sh だけは数えていません。あのマシンの /tmp tmpfs より広い作業領域を必要とするためで、docs/developers/building.md にもそう書いてあります。Linux と Windows の配布物はこのツリーから作られています。