Communitygithub.com

remotion-sfx (音效管线)

Remotion 项目的音效装配执行 skill:选源、试听板、入库、cue 挂载、定量验收。触发词:音效、SFX、whoosh、音效库、试听。

remotion-sfx (音效管线) とは?

这是一个专为 Remotion 项目设计的音效装配 skill,提供从选源、试听、入库到 cue 挂载和定量验收的完整自动化管线。它基于用户定制的音效库和严格的 A-G 配声语法(映射画面事件到具体音色),确保音效质感一致、音量克制、不喧宾夺主。Skill 支持 macOS 环境,主要通过 Node.js 脚本(`beat-to-cues.mjs`)和 ffmpeg 命令实现闭环,用户仅在一次性定库和段终审时介入。核心价值在于通过试听板(用户听觉判断)替代 AI 对音色的猜测,杜绝「凭猜配声」的失误,并将全片音效密度、单音色占比、音量基准等规则固化,大幅减少后期返工。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/jincheng2026/jc-remotion-skills/tree/main/skills/remotion-sfx

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

配音效(可执行管线)

定位:実務用スキル。ルールの真のソースは remotion-assembly/references/audio.md(ラウドネスチェーン / マスタリング / ポーズ / BGM 判定)で、矛盾はそちらを優先。 血涙史(繰り返すな):ffmpeg ホワイトノイズ合成 → 却下(安っぽいザラつき);参考映像の音声トラックをサンプリング → 却下(ボーカル除去後が薄い)。正解=プロフェッショナル音効ライブラリ+ユーザー試聴選択(誤題 #21)。

0. まず確定ライブラリを確認(大半はここで完了)

public/sfx/ 現役10音色(2026-07-16 試聴確定ライブラリ + 2026-07-21 承認プールから正規化/差し替え、番号/差し替え履歴は audio.md ルール8参照;括弧内は §4 イベント位置): glass 証拠カード出現(A) / pop chip 軽いタップ(B、差し替え済 fav20 明るくシャープな tick、旧作の「カシャッ」という嫌われた音を交代) / tick2(B 変種、fav33——同一セグメント内で B 位置を連続使用時の重複感防止) / pop2 名札着地 柔らかいポップ(G、差し替え済 fav14 鈍くてボリューム感のあるポップ) / stamp スタンプ重い打撃(D、全編 ≤1) / rise 数字スクロール連続回転(C、fav29 リメイク、BASE_VOL 個別に 0.1 に圧縮) / whoosh クリアスイープ(F) / shutter 写真撮影専用 / bright ハイライト線用(fav02 明るいディング——基準映像全スペクトルで唯一の明るい系統の専用音) / lowthud 物理的衝突・落下位置(fav13 低周波長鳴、侵入ビート専用、重くなりやすいのでセグメント最終審査で調整)。旧 pop/pop2 は spare/prev-* に保存。trans、ding は 2026-07-20 ユーザー試聴判定により廃止(E 位置はデフォルトで空白、正式な補完ソースは §1-2 へ)。予備品は public/sfx/spare/。承認プール public/sfx/jy-fav/(2026-07-21 ユーザーが剪映で収集した 42 セグメント試聴ボードから 19 件を使用可能と判定):fav 番号+ハッシュ+帯域グループはディレクトリ内 SOURCES.md 参照、全てユーザー耳通過済——B/G/A/E 位置のソース差し替え・補完は優先的にこのプールから取得、役割の割り当てはセグメント最終審査で完了;同一映像の現役音色は A-G テーブルに従い抑制(ユーザー校正:よく使う音色は十数個程度、効果音が主役になってはいけない)。 映像を変えてもこのライブラリをそのまま流用;新しいキャラクターや質感が必要な場合のみ手順 1-3 を実行。

1. ソース選択(新しい効果音が必要な場合)

優先順位:a. 剪映ローカルキャッシュディスクライブラリ(ユーザー指定の優先パス:~/Library/Containers/com.lemon.lvpro/Data/Movies/JianyingPro/User Data/Cache/music/ などのディレクトリに効果音ライブラリのダウンロードキャッシュあり、find ... -iname "*.mp3" + ffprobe 長さ ≤5s で効果音を抽出 + md5 重複除去;ファイルはハッシュ命名でタイトルなし、試聴ボードで確認。プール拡張:ユーザーが剪映で気に入った効果音をタップするだけでキャッシュに落ち、ディスクスキャンスクリプトを再実行すればよい——これが「ユーザー拡張ライブラリ」の標準動作)→ b. @remotion/sfx(d.ts が直接リンクリスト;使用可能:whip/whoosh/switch/mouse-click/page-turn/ding/shutter-modern)→ c. Mixkit 無料商用(カテゴリページで assets.mixkit.co/active_storage/sfx/<id>/<id>-preview.mp3 を grep)→ d. Pixabay / kenney.nl CC0 → e. 商用パック(Artlist/Epidemic)。 著作権注意:剪映素材の利用規約は名目上剪映内での使用に限定されるが、国内クリエイターエコシステムの慣行としてユーザー自身の裁量に委ねる;対外商業配布時は優先的に b-e を使用。

2. 試聴ボード(新しい効果音を映像に載せる前に必ず実施、スキップ不可)

効果音の質感を AI が判断することは不可能で、スペクトルのハード的な問題をスクリーニングできるのみ。手順:候補を一律 -3dB に正規化 → 各音声に黒背景の番号・名称カード(drawtext)を付けて短いセグメントにレンダリング → concat で 1 本の試聴動画に結合してユーザーに提出 → ユーザーが番号を報告して初めて映像に載せることを許可。 結合の鉄則(2026-07-16 の落とし穴):① 各セグメントの長さを厳密に等しく——音声は apad=whole_dur=2.1,atrim=0:2.1、動画は -t 2.1、-shortest は禁止(aac プライミングにより各セグメントの長さが微妙に変わる);② 結合には**-c copy は禁止**、全体を再エンコードする必要あり——さもないと音ズレが累積し、後半になるほど番号と声音が一致しなくなる(ユーザーが 40+ 番号で実際に全滅、ユーザーの報告した番号が全て無効になってやり直し)。③ 納品前にセグメントごとに音声を検証(0715-02 事故:4/8 番号の無音ボードをユーザーに検出器として渡してしまった):結合済みボードの各セグメントを ffmpeg -ss <セグメント開始> -t <セグメント長> -af volumedetect で max_volume を検証、いずれかのセグメントが <-60dB なら無音——最初に volumedetect で該当ソースファイルを検証(ライブラリ内の不良品、例:rise.wav -91dB)、その後結合コマンドを確認、修正して再結合;無音ボードをユーザーに渡すこと禁止。

音色の割り当ては必ず試聴ボードに依存、AI の推測に頼らない(0715-02 最終審査で確定):映像イベントにどの音色を割り当てるかは、ユーザーが試聴ボードを確認して指定する——AI は音色を全く判断できない。0715-02 で AI が推測で誤った音色を 2 回割り当て、最終的に試聴ボードで stamp にたどり着いた。新しい映像、新しい組み合わせ、または既存ライブラリの音色が新しい映像イベントと合わない場合、まず試聴ボードを出力してユーザーに割り当ててもらう。AI が直接音色を映像に割り当てることを禁止。

3. 加工とライブラリ登録

  • ピークを一律 -3dBFS(volumedetect で max を測定 → volume=(-3-max)dB)、48k モノラル。
  • 長い素材は頭をカット:インパクト系は先頭 1.0-1.6s + afade out。
  • 連続回転合成(数字スクロール / バッチ点灯):選択した tick を 40ms にカット + -stream_loop 29 + 音量ランプ volume='0.35+0.65*t/1.2':eval=frame——基準映像の「スクロール音」は本質的に tick の連打であり、音程の riser ではない。
  • 新しいキャラクター:sfx-<映像名>.ts の SfxName 共用体型 + SfxTrack BASE_VOL を同時に追加。

4. cue テーブルマウント:A-G 音声マッピング構文(2026-07-16 スペクトル解析で 11 アンカーポイント確定 + 2026-07-21 2 映像全量統計アップグレード〔221 実測イベント〕;真のソース=本節 A-G テーブル + audio.md ルール8、確定根拠:assembly/0715-01/分段工坊/音效設計譜.md + docs/基準片配声譜v2.md)

映像イベント → 音色対応表(ビートごとにこの表を参照して音を選ぶ、自由な発想は禁止):

イベント音色ライブラリファイル
A 証拠カード/スクリーンショット出現ガラスのようなサウンド(短い、ピッチがある、UI 感;基準映像実測では出現音はやや鈍い bright -13.5——最も明るい帯域は選ばない、明るいディングは fav02/25/19 を映像に載せる前に明るさを校正する必要あり)glass.wav(剪映 J08、試聴ボード 106 番)
B chip/小物の登場、ドットマトリックス逐次点灯短く明るい tick;バッチ時は 0.15-0.3s 間隔で連続発音pop.wav(2026-07-21 に fav20 に差し替え済);同一セグメント内で連続使用する場合は tick2.wav に切り替えて重複感を防止
C 数字スクロールtick の連打スクロール期間全体をカバー;停止時に重い打撃は付けない(基準映像構文)rise.wav(1.5s 版)
D スタンプ/判決の落下短くこもった打撃、しっかりしていて轟音ではないstamp.wav(重いと感じたら spare/1143 に交換)
E チャプター遷移/接管の進入長い空気 riser、章レベルのみtrans.wav 2026-07-20 廃止;基準映像実測では章遷移/接管 20 箇所すべて短く切り替わる音(減衰 ≤0.1s、空気 riser なし)——補完ソースは <0.2s の短い音を選択、riser 禁止;デフォルトは空白を維持(0715-02 確定実践、このスタイルはユーザー裁定);必要な場合は whoosh の軽い帯域で代用(vol≤0.5、F 実用値はさらに低い帯域を取って「退出は進入より軽く」を保証)、正式な補完ソースは §1-2 試聴へ
F クリア/退出減衰する柔らかいスイープ、入場より一段軽く(vol ≤0.5;「一段軽く」はこのスタイルの抑制裁定——基準映像実測では退出は入場より軽くなく、違いは減衰テールがやや長いこと、選択は「減衰テールがあること」を音量の低さより重視)whoosh.wav
G 名札/バッジ/chip 着地柔らかい poppop2.wav(2026-07-21 に fav14 鈍いポップに差し替え済)または spare/interface-1109

拡張イベント位置(2026-07-18 汎化負荷テストで補完、近いグループにまとめて新たな音源は追加しない):hero 大文字/結論ロックアップ着地 → D 軽い帯域(vol ≤0.5、Stamp 重い打撃枠を使用しない);タイムラインカード/チャートコンテナ登場 → A;タイムラインノード点灯、データバー成長、線の draw-on → B(バッチは連打ルールに従う);判決小注釈/ZeroTag 着地 → B;ハイライト線/重要箇所指摘 → bright.wav(専用の明るいディング、基準映像全スペクトルで唯一の明るい系統 +3.0);物理的衝突/落下/押し出し → lowthud.wav(軽い帯域は vol 適宜減らす、重くなりやすい);punch-in ズーム → 中程度の強さの短い音(D 軽い帯域または lowthud 軽い帯域);micro 章は帯域を下げる——ページ分割で切り出した <8s の小節では、E 遷移はグループ全体の最初と最後のみ各 1 回、節間は B で代用(遷移音の連発で飽きるのを防止;E 位置は現在暫定的に whoosh 使用、§0 参照)。

承認プール対応表(2026-07-21 特徴実測でグループ分け;主選択は同日に正規化・ライブラリ登録済、§0 参照;最終的な聴感修正はセグメント最終審査で実施):正規化済——pop←fav20、pop2←fav14、tick2←fav33、brignt←fav02、lowthud←fav13。プール内で予備:B 予備 fav27/24、G 予備 fav11/06、A 予備 fav25/19(明るいディング、bright が明るすぎる場合に帯域を下げて使用)、F 予備 fav16(気音極軽)、D 軽い帯域予備 fav05、物理予備 fav08、E 位置候補 fav17/00(デフォルトは空白維持)。セグメント最終審査で気に入らなければ交換、1 分でプールに戻してソース変更。完全な特徴表は jy-fav/SOURCES.md。

音を選ぶ前に意味ファミリーを問う(2026-07-21 確定、「どれが聞こえやすいか」で選ばないように):明るいディング=重要箇所指摘/強調、観客はここを見るべき(基準映像実測で唯一の明るい系統はハイライト線 +3.0;証拠カード出現音は実測で鈍い -13.5、鈍く短いグループに分類、glass 中程度の帯域を使用);乾いたタップ=小物の配置/逐次点灯(推進感);柔らかいポップ=身分/結論の確定(重み感);低周波=物理動作の衝突/落下/押し出し(因果感);気音=離脱(片付け感)。映像イベントがどの意味ファミリーに属するか、そのファミリーから音を取る——ファミリーが合わなければ鳴らさないほうがまし。

三つのメタルール(音色よりも重要、v6 失敗の根本原因):① 音色はセットで揃える——全編を通じて同一系統の UI サウンド、撮影系/オフィス系/大作系の混在は禁止;② 音量は控えめに——人の声をかき消すものは一つもない、ラウドネスではなく密度で勝負(基準映像 2 本の実測では全編 4-5s/発;「2-3s/発」は密集区間のテンポであり全編平均ではない、配声譜v2 参照);③ 一事一声——二重音は重ねない、同じビートで二つのイベントは ≥0.1s ずらす。

hook / オープニング音声付与の原則(問い⑩「オープニングに効果音を付けるか」の答え):オープニングは「音声を付けるかどうか」の特例ではなく、やはり「主要素に音声を付ける + A-G テーブル参照」の原則に従う——hook メインビジュアルは出すべきところで出す:タイプライター大文字=逐字 tick(B)、hook 重い数字=C スクロール、証拠カード出現=A、章頭/接管進入=E。却下されるのは「視覚的アンカーのない装飾的な開始音」のみ(whoosh/サーというオープニング、雰囲気を盛り上げるためだけに付ける無拍の音)——これらはいずれの映像イベントにも対応せず、メタルール①②の外の純粋なノイズ。判定基準:オープニングの各発音は、着地しつつある主要素に紐づいていなければならない;紐づかないなら付けない、「最初に音がない」からといって無理に詰め込まない。

既却下:オープニング whoosh サーッ(装飾的な開始音、上記原則による)、数字着地の重い打撃、重い打撃全編(旧ルール ≤2 箇所/編、2026-07-21 よりカシャッ系は全編 ≤1 に厳格化、ハードラインは §4.4;基準映像 2 本の実測ではスタンプ 1/2 箇所、音色画像=全スペクトルで最も鈍い bright -18.4 + 最も重い rise 30dB、「こもっていて轟音ではない」確証)、BGM(基準映像実測ではあり:連続低周波ベッド、頭中尾一定、推定人声比 ≤-15dB——BGM なしはユーザー裁定によるこのスタイルの差異であり基準映像の構文ではない、覆す場合の起点は -15dB 一定のベース)、trans 章 riser と ding エンディング(2026-07-20 試聴裁定で廃止、§0 参照)。

4.4 全編効果音監査ゲート(0715-02 最終審査で確定:cue マウント後に必ず実行、ライン超過は修正して再レンダリング)

  • 密度:ハード下限 全編 ≥2.5s/発(事故:1.95s/発が最終審査で「うるさい」と却下);目標帯域 3.5-5s/発(基準映像 2 本実測 v5=5.0/v6=4.0;0715-02 で 3.05s に削ってもまだやや密集、終点ではない)。空白も文法:連続 20-30s cue なしは正常(実測最大空白 28.7s)、口頭説明部分に無理に音を詰めて密度を上げない;密度は 30s ウィンドウで比較して波打たせる(密集ウィンドウ 9-14 発 vs 疎ウィンドウ 2-3 発)、均等に敷き詰めない。カバレッジ判定は密度平均より優先(2026-07-21 0721-01 最終審査):確定稿 42 発 3.02s/発(旧目標帯域下限以下)でもユーザーは「MG に効果音が足りない」と指摘——密度平均が基準を満たしていてもカバレッジが基準を満たしているとは限らない;監査は「各 MG 主要素が着地時に音が出ている、または明示的な空白理由(純粋な口頭説明/接管進入/意味ファミリーが合わない)」を基準とし、目標帯域 3.5-5 はうるささ防止の参考線とし、カバレッジの必要から 3.5 を下回っても戻さない(0721-01 時点で現役 7 音色がカバレッジ上限の主因;拡張ライブラリは既に完了、下記テンションルール参照)。
  • 単音色占有率 ≤35%(事故:pop 114/220=52%、聴感「シャッター連写」——短い tick 系の連発がカシャッという感覚の源)。基準映像乾いたタップ族実測ではちょうど 35%(78/221)、このラインは実測と一致し、ハードラインは緩和しない。
  • バッチ点灯はデフォルトで「グループ全体で最初の 1 発だけカウント」;0.15-0.3s 連発は ≤4 個の意味的ずらしにのみ使用、§4 B 位置の旧「バッチ連発」デフォルトを上書き。
  • BASE_VOL 基準 ≈0.25(0.2-0.3)、重い打撃上限 0.55——ユーザー 2026-07-21 裁定「効果音の基本音量はすべて -15dB 程度」:ライブラリ登録時ピーク -3dBFS × 0.25 ≈ 実効ピーク -15dBFS(2026-07-20 の 0.3-0.55 を上書き;さらに前の 0.8-1.0 は「大きすぎる」と裁定された旧バージョン、戻さないこと)。
  • stamp は慎重に使用(0715-02 最終審査で確定):ユーザーは密集した stamp を「写真のカシャッ」と聞き取る——判決/型名/緑スタンプのすべてに stamp を付ける必要はなく、視覚的空白で代用;全編 stamp(重い打撃含む)は 1 桁以下 を推奨。これは「重い打撃 ≤2 箇所/編」と重なる:重い打撃は stamp の中の強いサブセット、最初に重い打撃 ≤2、次に stamp 音色総数 ≤1 桁。
  • カシャッ系音色は全編 ≤1(ユーザー 2026-07-21 0721-01 裁定、上記 stamp≤1 桁を厳格化):ユーザーはカシャッ(stamp/shutter)の聴感に非常に敏感、密集した判決カシャッ=写真連写、耳障り;全編で最も盛り上がる 1 箇所だけ重い stamp、他の判決/結論確定は柔らかい音色(pop2 柔らかいポップ / rise 成長音)に変更、すべての判決にスタンプを押さない。
  • 象徴的音色(rise 成長音)も同様に抑制し、局所的な集中を防ぐ(0721-01 の教訓):rise 全編 ≤4-5 箇所かつ 30s ウィンドウ内で ≥2 発禁止(0721-01 初版 rise 10 箇所、111-122s に 4 個集中、ユーザーから「同じ効果音が何度も出てくる」と判定——単音色 22% で 35% ラインは超えていないがそれでも多すぎとされ、局所的集中は全編占有率より致命的);隣接する成長アニメーションは最も象徴的な 1 拍だけ rise を割り当て、残りは空白または pop に変更。
  • 連続 tick 系音色(rise)BASE_VOL は個別にさらに低く設定:rise は ~1.2s の連続 tick、累積ラウドネスは単発の pop/pop2 よりはるかに高く、ピークが同じ -3dB でも聴感は「より大きい」;0721-01 ユーザー裁定で rise は個別に 0.1 に抑える(通常の 0.25 より一段低い)——連続/持続系音色は一律に単発帯域よりさらに一段低く。
  • MG 音声カバレッジ vs 音色ライブラリサイズのテンション(0721-01 未解決、ライブラリ拡張待ち):ユーザーは「すべての MG に音が欲しい」がライブラリは 7 音色のみ、無理にカバレッジを補おうとすると同じ音色を何度も使うことになる → うるさくて繰り返しになる(まさにカシャッ/rise が嫌われた原因)。カバレッジと「うるさくなく繰り返さない」は小規模ライブラリでは矛盾する;根本的解決=ライブラリ拡張。2026-07-21 完了済:承認プールから 3 つの新キャラクター(tick2/bright/lowthud)+ B/G の差し替え、現役10音色(§0);それでも単調ならプールから引き出す(19 件は既にユーザー耳通過、SOURCES.md 対応表)またはユーザーがさらに収集してプール拡張。
  • 監査アクション:grep -c で cue 総数と音色別分布をカウント、いずれかがライン超過ならまずバッチ位置を削減、次に占有率を圧縮;stamp 音色は別途カウントし、1 桁を超えたら修正。

4.5 自動化クローズドループ(ユーザー裁定:今後はバージョンごとに音量調整はしない)

ユーザーは以下の 2 点のみ介入し、他は全自動:

  1. 一度限りのライブラリ確定(進行中):ディスクスキャン/ソース選択 → 試聴トータルボード → ユーザーが番号を報告 → A-G 構文に従い役割を割り当て → public/sfx/ 永久ライブラリ確定。以降映像を変えても効果音の選択は不要。
  2. セグメント最終審査:セグメントの完成品を通して聴き、時刻を指定して交換(ライブラリ/spare からソースを変更、1 分で新版が出力される)。セグメント最終審査の完成品は常に効果音付きで納品——cue は自動マウントされ、視覚先行で確定稿を作ってから再レンダリングする必要はない(0715-02 の教訓:3 セグメントを 2 回レンダリングして 1 ラウンド無駄にした)。 中間に人間の作業は不要:アセンブリの各セグメントで「コンポーネントタイプ → イベントタイプ → A-G テーブル参照」で自動 cue 割り当て——Chip/ドットマトリックスグリッド=B、QuoteDoc/ShotCard 出現=A、Stamp=D、BigNumber スクロール=C、Takeover/章頭=E、Exit クリア=F、名札/バッジ=G;cue の at は要素の enterAt を直接取得して秒に換算。cue ドラフトは既にスクリプト化:node scripts/beat-to-cues.mjs <映像名> でアセンブリ計画テーブルから sfx-<映像名>.ts ドラフトを機械生成(§4.4 事前検査レポート内蔵、ライン超過は赤表示で自動削除はしない)、音響担当者は校正のみで編集しない;スクリプト内のマッピングテーブルは本節の転記であり、ルール変更はこの SKILL が優先。禁止:単一セグメントのために一時的に新しい効果音を探す(キャラクター不足の場合のみ §1-2 手順でライブラリ補完)。

5. 定量的検収(セグメントレンダリング後に必ず実行)

  • 各 cue ポイントで ffmpeg -ss <t> -t 0.5 -af volumedetect の全周波数帯域ピークが、隣接する純粋な音声ウィンドウよりも有意に高いこと;明るい質感の部品はさらに highpass=f=8000 を測定:≥ 音声歯擦音ベースライン +6dB(この閾値は 2026-07-20 以降再校正待ち——BASE_VOL を下げた後は cue ごとに聞こえて区別できること + ユーザー最終審査を基準とし、dB を合わせるために音量を戻さない、audio.md ルール1 参照)。
  • 可聴イベントカウント:highpass=f=12000,silencedetect=noise=-25dB のイベント数 ≈ cue 数。
  • 廃ピーク対照:音声破裂音と BGM ドラムビートもピークになり得る(2 本の解析で 360 候補から 39% 廃棄)、指パッチンや手拍子などの身体収録音は rise で 40dB に達する——cue ポイント検収はまず身体収録音を排除し、効果音と比較しないこと。
  • 最終判定 = ユーザーの耳:セグメント完成品をユーザーに聴かせ、時刻を指定されたら試聴ボード/予備品からソース変更、1 分で新版を出力。

Individual skills in this repo

This repo contains 5 individual skills — each has its own dedicated page.

関連スキル