earshot

earshot：エージェントの耳

あなたには音が聞こえません。earshot による分析結果がない限り、音がどのように聞こえるか、あるいは音が「合っている」とは決して言わないでください。報告する際は数値を引用してください（「強い一致、z +3.9；p_real 0.96；-14.2 LUFS」）。earshot は CPU 上でローカルに実行され（オプションの llm コマンドを除き、音声がマシンの外に送信されることはありません）、すべての埋め込みと結果をディスクにキャッシュします。注意点：CLI を呼び出すたびに新しいプロセスが起動し、最初にモデルを読み込みます（負荷の高いノート PC では、キャッシュ済みファイルでも約 20～40 秒かかります）。MCP サーバー内、または 1 つの Python スクリプト内では、モデルの読み込みは 1 回だけで、以降の呼び出しは数秒で完了します。呼び出しが数回を超える場合は、MCP または短いスクリプト（from earshot import api; api.find(...); api.realness(...)）を使用してください。

セットアップ（初回のみ）

pip install -e "/path/to/earshot[mcp,llm]"   # or the repo venv: /path/to/earshot/.venv/bin/python -m earshot ...
earshot doctor                           # packages, ffmpeg, models (pinned revision, cache state); --load times them

同じ機能を使う 2 つの方法：

• CLI：earshot <command> ... [--json] [--out result.json]。テキスト出力は簡潔な概要から始まります。時刻はテキストでは m:ss.ss、JSON では秒単位です。
• MCP（呼び出しの間もモデルが読み込まれたままになります）：claude mcp add earshot --scope user -e EARSHOT_THREADS=3 -- /path/to/earshot/.venv/bin/python -m earshot mcp、または任意のクライアントの .mcp.json に次のように記述します： {"mcpServers": {"earshot": {"command": "/path/to/earshot/.venv/bin/python", "args": ["-m", "earshot", "mcp"], "env": {"EARSHOT_THREADS": "3", "GEMINI_API_KEY": "${GEMINI_API_KEY:-}"}}}}（キーの行が必要なのはオプションの llm ツールのみです。Claude Code はユーザーの環境から値を設定しますが、その他のクライアントでは、起動時の環境にキーを設定する必要がある場合があります。プロジェクトファイルにキーをそのまま記述しないでください）。 ツール：measure、describe、match、rank、find、compare、ab、realness、timeline、sheet、critique、doctor、 llm_critique；サウンドバンク（モデル不要）：sfx_list、sfx_render、kit_render（Loop 5）。絶対パスを指定してください。full=true を指定すると、JSON 全体が返されます。サーバーの応答は数秒以内ですが、起動直後やマシンに負荷がかかっている場合は長くかかります。Claude Code に earshot ツールが表示されない場合は、MCP_TIMEOUT=60000 を指定して起動してください（PowerShell： $env:MCP_TIMEOUT=60000; claude）。earshot mcp --warm を使うと、起動時にモデルを事前読み込みします。 マシンを共有している場合は、EARSHOT_THREADS=2-3（または任意のコマンドで --threads 2）を設定してください。プロセス内で最初にモデルを呼び出すと CLAP + AST が読み込まれます（約 20～60 秒）。同じプロセスでの以降の呼び出しは高速です。ffmpeg で読み込めるファイルであれば使用できます。mp4 の音声も対象です（音声トラックのない動画の場合は、その旨が表示されます）。エラーは stderr に 1 行で出力されます： earshot <command>: error: ...、終了コードは 1 です。

ループ 1：アセットを選ぶ

1. earshot rank "a soft felt mallet hit on a wooden block" downloads/sfx/ --top 5 - フォルダーから候補を絞り込みます。
2. earshot find winner.ogg "a single clean mallet hit" --top 3 - サンプル用に切り出した最適な箇所（開始／終了を秒単位）を見つけます。各セグメントには種類があります。stroke（1回の立ち上がりから減衰するまで）とevent（鍵盤の押下＋解放など、ひとまとまりの立ち上がり）は、アタックの 5 ms 前から始まり、減衰後に終わります。windowは、単発のクエリでは端点が音に合うように調整された区間で、ベッド音ではクロスフェード用の通常の区間です。head／tailは、最初の 5 ms／最後の 10 ms がトリムのピークに対してどれほど大きいかを示します（-30 dB 以下ならクリーンです）。「head cut」または「tail cut」と表示されたトリムは、音の途中から始まるか、音の途中で終わっています。そのまま使わないでください。--kind eventは立ち上がりベースのトリム（ヒット、クリック、足音）のみを返し、--kind textureは通常のウィンドウ（ベッド音）のみを返します。デフォルトではクエリの内容から判定します。
3. earshot describe winner.ogg --start 1.12 --end 1.48 - 実際にどのような音かを確認します。上位タグが必要な音に合っているか、また音の形（アタック／減衰）がイメージに合っているか確認してください。AudioSet のラベルは、約 0.5 秒未満の単発音では信頼性が低く、「tagger unsure」や近いクラス（ヒュッという音に対する Zipper、クリック音に対する Finger snapping）は問題ありません。明らかに異なるクラス（Speech、Music、Engine、Vehicle）のみ注意が必要です。
4. earshot realness winner.ogg --start 1.12 --end 1.48（またはフォルダー全体） - 使用するトリムを判定します。複数テイクを含むファイルの p_real は、すべてのテイクとその間の無音部分の平均です。ユーザーが実音またはプロが制作した音を求めている場合、「likely code-synthesized」のトリムは使わないでください。また、「uncertain」のトリムを使う前に根拠を確認し、採用した理由を記録してください。合成音が目的の場合（プロシージャル音楽、UI 音、earshot forge で作成した音）は、realness は参考情報であり、使用可否の判定基準ではありません。判定しきい値は長さによって異なります（各サマリーに記載されています）。6 s 以下の音にはクリップのしきい値（lo 0.17／hi 0.77）が使われ、それより長いファイルには 4 s ウィンドウの平均と、較正の精度が低いファイル用しきい値（lo 0.40／hi 0.77）が使われます。そのため、長さの異なるファイル間では、生の p_real ではなく判定結果を比較してください。実録音、プロが制作した音楽やサウンドデザインは通常 real と判定されます。ただし realness が判定するのは音の聞こえ方であり、音の出所ではありません。クリーンなプロ制作の合成音（UI 音、チャイム、シンセスタブ）も code-synthesized と判定されます。realness を利用できない場合（モデルが見つからない場合）は、実音か合成音かを確認していないことを明記してください。describe の AudioSet クラス（Sine wave、Beep、Synthesizer）は、根拠としてはより弱いものです。デジタル上の完全なゼロだけでは何も証明できません（このプロジェクトのライセンス済み実録音の 59% には、編集またはフェードによるパディングがあります）。
5. 2 つの候補から選ぶには、earshot ab a.ogg b.ogg --query "a crisp fast air whoosh"を使います。find のトリムには--a-start/--a-end/--b-start/--b-endを指定できます（A と B に同じ複数テイクのファイルを指定してもかまいません）。任意で、1 つの主張を検証するにはearshot match winner.ogg "a deep thocky key press" --alts "a clicky blue switch" "a typewriter key"を使い、パレットに合うか確認するにはearshot compare winner.ogg --refs approved/ [--start --end]を使います。

ループ 2：ミックスまたは映像を確認する

1. earshot timeline film.mp4 --cues cues.json（または soundtrack.wav --video film.mp4）- リスニング用トランスクリプトです： 時刻、レベル、タグ付きのイベント、セクション、ラウドネス曲線、映像カット、カット／キューごとの同期情報を確認できます。--detail low は高速で、high は最大 96 件のイベントにタグを付けます（重要度の高い順。要約にはタグ付けされた件数が記載されるため、タグのないイベントは音が欠けているわけではありません）。同期統計を確認してください：offset_ms は音と映像の差です（負の値 = 音が先）。「chance」の割合は、ランダムな編集点がどの程度のスコアになるかを示します。偶然より良い同期にのみ意味があります。音のヒットが記載されていないカットにも、控えめなシュッという音が含まれている場合があります。音を追加する前にシートで確認してください。
2. earshot sheet film.mp4 -o sheet.png --cues cues.json（--from 10 --to 25 で拡大表示、--detail low で高速化）- 注釈付き PNG です：フレーム、セクション、ラベル付きイベント、スペクトログラム、ラウドネス、ビート、同期に応じて色分けされたキューマーカー（緑 = 1 フレーム以内、琥珀色 = 100 ms 以内、赤 = 音なし）。画像ビューアーで PNG を開いてください。空白、音の集中、マスキング、遅れたヒットがひと目でわかります。
3. earshot critique film.mp4（--fast で AudioSet／リアリティの評価を省略）- プロ向けローンチ映像の測定範囲に基づくスコアカードです：各指標を ok／low／high で示し、重みとタイムスタンプ付きのアクション、および判定（ローンチ品質／あと一歩／要改善／ローンチ品質未満）を表示します。重要な項目から修正し、新しいレンダーで 1～3 を再実行してください。「onset on visual events」の割合は、+-100 ms 以内の新たなアタックのみを数えます（リファレンスでの定義です）。修正とヒントでは、timeline と同じマッチャーを使って、音がまったくないカットを示します。ファイルがプロファイル内のリファレンス映像のいずれかである場合は、その旨を示し、ほかのリファレンスと比較してスコアを付けます。
4. 正確なメーター値（LUFS、true peak dBTP、LRA、ノイズフロア、アタック／ディケイ、明るさ、帯域）をいつでも確認できます： earshot measure mix.wav [--music] または MCP の measure ツール。

ループ 3：変更を A/B 比較する

• earshot ab before.wav after.wav --query "warm punchy kick" または --refs pro_refs/ - どちらがより近いか、また測定された表現で B が A とどう異なるか（より大きい、より明るい、ディケイが長い）を確認できます。長いファイル内のサウンドを比較する場合は、トリミング位置を指定します（--a-start 1.217 --a-end 1.615 --b-start 7.881 --b-end 8.285）。複数テイクを含むファイル全体の A/B 比較では、すべてのテイクとその間の無音部分が比較されます。続いて earshot timeline after.wav を実行し、イベント行と同期統計を以前の実行結果と比較してください。一度に変更するのは 1 つだけにしてください。

ループ 4：コードで音を作る（earshot forge）

ユーザーが音を選ぶのではなく、作ることを望んでいる場合に使います。音を聴き取れる AI が合成コードを書き、音を聴いて、改善します。すべてのサンプルは計算によって生成する必要があります（インパルス応答も含め、録音音声を中に使ってはいけません）。実際の録音は、批評モデルが比較するための参照音に限ります。

1. earshot/forge/recipes/<name>.py にレシピを書き込むか、既存のレシピを選びます。レシピには、SPACE（パラメーター範囲）、DEFAULTS、TARGET、ALTS（現実的な混同対象）、および earshot.forge.dsp（モーダル共鳴器、接触励振、ノイズカラー、時間変化する SVF、計算で生成する部屋、ノイズフロアを持つマイク）から構築した render(params, r) -> 48 kHz array を定義します。参照音で測定した実物の物理現象をモデル化します。何が何に当たり、何が鳴り、どれほどの長さで、どのような部屋で音が響くかを考慮してください。

2. 1 ラウンド実行します：earshot forge <recipe> --refs <real refs> --budget 144 --reps 2 --tone 1.5 --keep 4 --robust 8 --dir <round dir>。または、モデルを一度読み込むラウンドごとの Python スクリプトで実行します： forge(recipe, critic=Critic(target, alts, refs, tone=1.5), reps=2, space={...})。

   • --tone は、モデルに依存しない音色バランスと残響を目的関数に含めます。
   • --reps 2 は、幸運なレンダリングに左右されないよう、各候補を 2 回のレンダリングで評価します。
   • 混雑したノート PC の CPU では、モデルのウォームアップにかかる 30～60 秒を含め、160 回のレンダリングに約 3～5 分かかります。

3. 音の評価結果を確認します。各候補の要約には、たとえば「sounds like: a cork pop, a glass ting（コルクが弾ける音、ガラスがチンと鳴る音のように聞こえる）」、「decay +2.4 outside the refs（減衰が参照音の範囲外に +2.4）」、または「tone 11.2 dB from the refs' median: +16 dB at 500-630 Hz (above every ref)（音色は参照音の中央値から 11.2 dB 離れている：500～630 Hz で +16 dB（すべての参照音を上回る））」と表示されます。その後、次の 4 つの観点から候補を確認します：

   • モデルに依存しない tone の語句：すべての参照音から外れている帯域、エネルギーの割合、残響、長さ（モデルのスコアが高い場合に最も信頼できる指標です）
   • robust：最も都合のよいレンダリングではなく、新しいシードによる平均
   • alt_zs：どの混同対象が最も近いか
   • 参照音と並べたスペクトログラム：ffmpeg -i x.wav -lavfi showspectrumpic=s=900x360:scale=log:legend=0 x.png

   report.json の AudioSet タグは、それを基準に候補を選んだり誘導したりしない限り、評価から除外されています。確認する前に選定ルール（たとえば、頑健な平均）を決め、確認後にタグを報告してください。

4. 問題点（リリース時のクリック音がない、金属的な響きがある、残響が長すぎるなど）に対して、範囲だけでなくレシピの構造を変更します。その後、繰り返します。各ラウンドでの変更点と数値を LOG に記録してください。

5. 同じ批評モデルで評価した実際の参照音（report.json の ref_scores、leave-one-out）と並べて、正直に報告してください。

Goodhart の法則について、率直に述べます：

• 探索で最適化されるのは earshot 自身のモデルです。作成した音がそれらのモデルで実際の録音より高いスコアを得ることはよくあります。つまり、批評モデルが満足したということであり、音がより良くなったという意味ではありません。
• p_real は簡単にだませます：モーダル共鳴器に部屋とマイクのノイズフロアを組み合わせると、「本物らしい」と判定されます。
• 典型性は、参照音の平均になるほど高く評価されます。
• モデルのチェックには飽和があります：探索後は、保留した言い回しや独立した実音データセットを含め、すべてのモデルチェックで、作成した音が実音の範囲内にあると判定されます。それでも違いを見分けられるのは、測定と耳だけです。
• 参照音との測定上の近さで判断してください。音色バランス、すべての参照音から外れている帯域、残響、長さを確認します。頑健性を確かめる再レンダリングとスペクトログラムも使ってください。
• 作成した音が「実物と同等に良い」と判断する前に、人間によるブラインドテスト（順序をランダム化し、音量を一致させ、正解を伏せる）を依頼してください。

最初のテスト（demo/forge-test）では、独立した評価者が、キーを押す音は実際の音の音色バランスから 8～13 dB 外れており、ポップ音は帯域全体に広がり、長くヒス音のような残響があると判定しました。一方、すべてのモデルチェックでは本物だと判定されました。モデルに依存しないチェックを使って誘導しながら作り直したところ、現在は実際の録音の測定範囲内に収まっています。whoosh は、実際に速い音として作り直しました。衝撃音（より暗く、膨らみが主となる音）とクリック音（残響が短い音）は作り直していません。人間はまだ聴いていません。

ループ 5：映画のサウンドキットを作成する（earshot sfx／earshot kit）

コードで作成した映画（シネティックフィルム、あらゆるキューシート）に効果音が必要な場合に使います。シンセ音源を書く代わりに、earshot に同梱されているバンクからレンダリングします。モデルは読み込まれず、キット全体は約 1 分でレンダリングでき、再レンダリングは数秒で完了します。

1. プリセットから始めます：earshot kit init --preset calm -o audio/kit.json（calm はテキスト主体の映画向け、crisp は勢いのある製品紹介映画向け、minimal は演出を施した効果音のみの映画向け、launch は音楽に合わせて編集した映画向けです）。各ロールの note には、そのサウンドを選んだ理由が記されています。calm／crisp／minimal では riser、swell、suck を使いません。明かされる瞬間はひとつの要素で解決し、ロックアップにはクリアなヒットをひとつだけ使います。launch ではセクションの切り替わりに riser または reverse swell をひとつ鳴らし、音楽に合わせた映画向けに作られた 0.4 のサウンドを使用します（下記参照）。
2. 映画に合わせて調整します：earshot sfx list --kind hit（または --category）を実行すると、候補の長さ、ピーク時刻、ノブが表示されます。ロールの sound を変更し、edits（ヒットやドロップを映画のルート音に合わせる pitch、一定の動きを指定する dur／apex）、takes（タイピングでは 12 以上、それ以外では 2～4）、level_db を設定します。候補をひとつ試聴するには、earshot sfx render ID -o x.wav [--pitch E5] [--dur 0.8 --apex 0.32] を実行し、測定された onset／peak／end を確認します。
3. レンダリングします：earshot kit render audio/kit.json --out audio/kit。ミキサーがキューフレームに配置するのは、テイクと kit.lock.json（テイクごとに測定された onset、peak、end、ラウドネス）です。ヒットとタッチでは onset をフレームに、whoosh では peak を頂点に、riser では end をヒットに合わせます（ロールを peak に合わせる場合はピークに配置します。launch の riser と swell がこれに該当し、これらの要素はクライマックスの後に終わります。kit check は end に合わせるものを記録します）。
4. 確認します：earshot kit check audio/kit.json --out audio/kit。レンダリングに使えないもの（サウンドが対応していないノブやピッチ、0 dBFS を超えるレベル、同じファイルを共有することになる 2 つのテイク）は拒否されます。各警告にはテイクと理由が記載されます（クリック音、途切れたテール、コーム状のリンギング、無音、4 半音を超えて上昇するピッチ、2 つのアタックがあるヒットや、その前にビルドがあるヒット、pitch_off：ノブを操作しても音程が合わなかった音符）。警告のあるテイクは残さず、サウンドまたはノブを変更してください。注記も確認します（音のある riser、複合スティングなど）。
5. ループ 2（timeline --cues、sheet）を使って完成した映画を通して聴き、各キューが適切な位置に配置されているか確認します。

0.4 のファミリー（earshot sfx list --category ui_pop など）は、音楽に合わせた launch 映画向けの、柔らかく短い中音域サウンドです：ui_pop（チップ、吹き出し、行の登場に使う丸みのある中音域のポップ音。この種の映画で最もよく使われる効果音）、knock（中音域の木やプラスチックの音）、cut_hit（キックを伴う短いサブヒット、パンチの効いたカットヒット）、mallet（ゲートされたグロッケンシュピール／チェレスタ／マリンバの音、柔らかなプラック音、チャイムの連続音。--pitch で音程を調整できます）、drip（音程が上がる水滴音。監査では泡の上昇を許容します）、shutter（スナップズーム、ウィップカット）、reverse_swell（カットの直後にピークを迎えるサウンド。1 本の映画につき 1 つ）、さらに whoosh_big thump*、riser dark／build／snatch、swish bright／flick、whoosh_fast whip、glitch burst／mid／chirp、notify mid_tine／mid_wood があります。映画を音楽に合わせて編集する場合は、古いカテゴリの明るい 5 ms のブリップ音や長いシネマティックなテールより、こちらを優先してください。

固定値ではなく、音楽に対するレベル（launch、または bed_db を持つロール）。音楽に合わせて編集した映画では、効果音は音楽より 3～10 dB 大きく、タイミングとスペクトルによって聞き取れるようにします。固定の level_db では、音量の大きな部分では埋もれ、静かな部分では突出してしまいます。各キューについて音楽ベッドを測定し、ロックからテイクの値を設定します：

from earshot.forge import kit
lock = kit.render('audio/kit.json', 'audio/kit')                 # takes carry l50_lufs; roles bed_db, offset_ms
role = lock['roles']['pop']; take = role['takes'][i]
bed = kit.bed_level(music, t_cue)                                # the music's median 50 ms level, second before
gain = kit.gain_db(take, role, bed)                              # dB on the take file (never over -1 dBFS peak)
start = kit.place(take, role, t_cue)                             # taps / knocks / clicks lead, whoosh peaks land after
cues = kit.space_run(run_times, role['min_gap_ms'])              # a run keeps its gap (pops 114 ms, keys 87)

ヒット、ドロップ、大きな whoosh、swell の前に 0.3～0.5 秒間、音楽を 6～12 dB 下げ、ヒット時に音量を戻します（ロックの mix.stop_down）。すべての効果音の下で音楽をダッキングしないでください。音楽ベッドのない映画（効果音主体の映画）では level_db が代替値になります。キューの前に音楽が無音の場合（コールドオープンやスコアの間の空白など）、bed_level は None を返し、gain_db は level_db を使用します。設定したゲインと測定した音楽ベッドのレベルを報告してください。 このバンクに何が入っているかを明確に説明します。forgeは、コードで生成されたサウンドです（0.4では、ライセンス済みの非公開参照クリップ群の計測スタイルに合わせて調整され、いずれのクリップに対してもCLAPが最大0.84となるよう、オリジナルのサウンドであることを確認しています）。また、CC0の録音素材をコードでフィッティングした15種類のサウンド（fit/<role>/<name>。それぞれにソースが付属し、プリセットではクリック、チック、キー、タッチ、スナップに使用されています）も含まれています。すべて計測に基づいて選定・確認しており、聴感テストによるものはありません。これらは録音ではありません。録音されたサウンドが必要な依頼には、代わりにskills/real-soundを使用してください。独自のフィットを追加する方法（earshot fit --takes、続いてbank add-fit）については、docs/SFX.md（「独自のフィットを追加する」）を参照してください。

オプション：言葉によるセカンドオピニオン（オーディオLLM）

earshot llm mix.wav --yes-upload [--with-timeline] [--prompt "Is the riser at 0:12 cheap?"]を実行すると、Google Geminiがルーブリックに基づいて批評します（同期、リアリティ、ミックス、ラウドネス、安っぽく聞こえる箇所、修正案とその時刻）。これは、ユーザーがGEMINI_API_KEY（またはGOOGLE_API_KEY）を設定し、かつ音声をGoogleにアップロードすることに明示的に同意した場合にのみ実行されます。必ず最初に確認し、独断で--yes-upload / consent=trueを渡さないでください。送信されるのは音声のみです（モノラル、64 kbps）。タイムスタンプは概算であり、スコアは1つのモデルによる意見です。修正案はすべてtimeline / abで確認してください。

数値の読み方

数値	内容	信頼度
LUFS、dBTP、LRA、dBFS、ms、Hz	計測値（BS.1770メーター、スペクトル、エンベロープ）	正確です。レベルの調整に使用してください
z（match / rank / find / describeのタグ）	同じサウンドに対して採点した数百件の語彙記述の中で、ある記述がどれだけ際立っているか	判定基準：z >= 3は強い、2.5-3は妥当、2-2.5は弱い、< 2は一致なし（バンドごとの保留データによる根拠はeval/semantics/RESULTS.mdを参照）
p_vs_alts	クエリと候補の中から、どれか1つを選ぶ未較正の鋭い強制選択	どの表現が最も合うかを示すだけです。zで判断してください
cosine	生のCLAP類似度	確率として扱わないでください。同じサウンドとクエリの組み合わせでのみ比較してください
AudioSetラベル（0..1）	ASTタグ付けモデルによる、クラスごとに独立した確率	大まかなクラスの判定には有効ですが、8 kHzまでしか聞き取れません
p_real / verdict	小規模なフィッティング済みモデルによる、実録音またはプロ制作音とコード合成音の判定	強い根拠ですが、証明ではありません。根拠の一覧を確認してください。しきい値は短いクリップ（<= 6 s）と長いファイルとで異なります（各サマリーに記載）
digital_silence_frac	完全なゼロ値のサンプルの割合	これだけでは弱い指標です。実録音では編集時の余白やフェードによるパディングがよくあります
typicality z（compare）	参照セットと、その参照音同士のばらつきに対する距離	>= -1はセットに適合、< -2は外れ値
同期 offset_ms、chance	カット／キューごとの音と映像のずれ、およびランダムに編集した場合のスコア	偶然の範囲を大きく上回る場合に信頼できます
critique status	7本のプロ制作ローンチ映像の範囲に対する評価（ラウドネス：ウェブ配信の慣例。マスターではtrue peak <= -1 dBTP、デコード後のAAC / MP3では<= 0 dBTP。後者にはコーデックのオーバーシュートがすでに含まれます）	範囲であり、目標値ではありません。okはプロの制作例の範囲内です
計測値を優先し、次に判定結果／z／確率を参照してください。cosineを確信度として示してはいけません。

クエリの書き方

用途ではなく、サウンドを説明してください。音源＋素材＋動作＋特徴を記述します（「ロゴ用のサウンド」ではなく、「狭い部屋で重い木製のドアがバタンと閉まる音」）。実際に混同されうる候補を挙げてください（トック音かクリック音かタイプライター音か、など）。zが境界付近の場合は、2～3通りの表現を試してください。どの表現でも一貫している判定を信頼してください。

制限事項（該当する場合は明確に伝えてください）

• 音の好みは測定できません。earshot でわかるのは音の種類と測定値であり、美しいか、ストーリーに合っているかではありません。好みはユーザーが判断します。根拠と候補リストを提示してください。
• 音声認識には対応していません（音声があることは判別できますが、何と言っているかはわかりません）。歌詞や言語の判定にも対応していません。
• CLAP の聴取範囲は 50 Hz～14 kHz、AST は最大 8 kHz です。「空気感」やローパスフィルターの問題は、測定値（bandwidth_hz、bands）で確認してください。
• 非常に短い音は 10 s のウィンドウにパディングされます。単発のヒット音は、トリミングしたセグメントに対して find / describe を使うと最も適切に読み取れます。
• attack_ms / decay_ms は平滑化したエンベロープ（5 ms / 10 ms RMS）から算出されます。瞬時のアタックは約 4 ms と表示され、非常に短いクリック音のディケイは約 10～20 ms より短く読み取れません。
• 映像のカットはフレーム差分検出器で検出します。ハードカットと高速なパンは確実に検出できますが、ゆっくりとしたクロスフェードは見逃したり、検出が遅れたりします。また、ショット内の動きはイベントではないため、アニメーションではキューの時刻（--cues）を渡してください。
• 複雑で密度の高い素材ではタグが曖昧になります。ミックス全体ではなく、ステムまたはセグメントを describe してください。
• ライセンス、来歴、クレジット表記は音声に関する事項ではないため、earshot では確認できません。