← 2026-03-18 の一覧へ戻るホーム
クローム拡張機能は、話者のスピードに応じて動画再生速度を自動調整します。

2026/03/13 15:18

クローム拡張機能は、話者のスピードに応じて動画再生速度を自動調整します。

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

機能概要
このChrome拡張機能は、話者の音節レートを推定して動画再生速度を自動的に正規化します。最大 

<video>
要素から 
captureStream()
でオーディオを取得し、Web Audio API グラフ（300–3000 Hz バンドパスフィルタ、約33 Hzでポーリングされる AnalyserNode）を通じて処理します。その後、エネルギー包絡モジュレーション解析を用いて4秒のスライディングウィンドウ内で1秒あたりの音節数をカウントします。

動作原理
検出された音節レートはターゲット再生速度にマッピングされます（

minSpeed
と 
maxSpeed
の間にクリップ）。非常に速い話者では約1.12×、極端に遅い話者では最大3.5×までのデフォルトマッピングが使用されます。指数移動平均スムージング（α≈0.25）で変化を滑らかにし、連続した静寂時間が ≥3 秒になると速度は徐々に1×へ戻ります。

インストールと UI

chrome://extensions
から未圧縮拡張機能を読み込むことでインストールします。設定は 
chrome.storage.local
に保存されます。診断オーバーレイには現在の速度、自然な音節レート、静寂状態、リアルタイムエネルギーバー、および速度へのマッピング履歴が表示されます。

既知の制限と今後の課題
DRM 保護されたコンテンツは 

captureStream()
をブロックします。音楽や効果音は誤ったカウントを引き起こす可能性があります。複数話者は合算され、SPA ナビゲーションでは短時間のギャップが発生する場合があります。計画中の改善点には、Silero VAD を用いた音声活動検出、相関解析によるより正確なレート推定、話者別のデアライゼーション、およびキーボードショートカットでの切替が含まれます。拡張機能は MIT ライセンスです。

要約（元の文言を好む場合）

この記事では、動画再生速度を話者の音節レートに合わせて自動的に調整し、一貫した再生速度を保つChrome拡張機能について説明しています。 ...

(オリジナルの要約は有効ですが、上記の欠落情報で補完できます。)

本文

Chrome拡張 – 動的動画再生速度調整

ページ上の全ての話者が快適に聞けるよう、（≈ 9音節/秒）に合わせて動画の再生速度を自動で調整する Chrome 拡張機能です。
スロートークは速めに、ファストトークはゆっくりに設定し、急速なパッセージでも可聴性を損なわずに動画コンテンツの消費速度を上げます。

動作概要

音声取得

拡張機能のコンテントスクリプトは次の手順で音声を取り込みます：

  1. ページ内で最大サイズの 
    <video>
    要素を検索します。
  2. HTMLMediaElement.captureStream()
    を呼び出し、通常再生を妨げずに 
    MediaStream
    を取得します。
  3. そのストリームを Web‑Audio グラフへ送ります：
video.captureStream()
  → MediaStreamSource
    → BiquadFilter (highpass 300 Hz)
      → BiquadFilter (lowpass 3000 Hz)
        → AnalyserNode   （約33 Hzでポーリング）

バンドパスは母音フォルマント領域（300–3000 Hz）を切り離し、音節エネルギーが集中する帯域を抽出します。

音節率検知

3 通りのアルゴリズムを試行しました。現在採用しているバージョン（v3）は エネルギー包絡調整解析 です：

  1. 2048 サンプルウィンドウ（約21 ms、96 kHz）で RMS エネルギーを計算します。
  2. 最初の一次 IIR ローパス (
    α = 0.3
    ) で包絡線を平滑化し、無音検出に使用します。
  3. 原始 RMS をハイパスフィルタして、音節率（≈ 2–10 Hz）だけを残します：
filtered[n] = α * (filtered[n-1] + rms[n] - rms[n-1])   // α = 0.9

  1. filtered
    の正方向ゼロ交差数をカウント。
  2. 交差間の最小インターバルを 70 ms に制限 → 最大検出可能率 ≈ 14音節/秒。
  3. スライディングウィンドウ（デフォルト 4000 ms）で 1 秒あたりの交差数から音節率を算出。

再生速度マッピング

検出した音節率は再生速度へ変換されます：

naturalRate = measuredRate / currentPlaybackSpeed
targetSpeed = targetSyllableRate / naturalRate
targetSpeed = clamp(targetSpeed, minSpeed, maxSpeed)
currentSpeed += smoothingAlpha * (targetSpeed - currentSpeed)


measuredRate / currentPlaybackSpeed
は 
captureStream()
が実際の再生速度を反映しているために必要です。
デフォルトターゲットは 9音節/秒 です。

話者ペース自然率再生速度
非常に遅い~2.5 syl/s3.50×（上限）
遅め~3.0 syl/s3.00×
普通~4.5 syl/s2.00×
速め~6.0 syl/s1.50×
非常に速い~8.0 syl/s1.12×

無音が 3 秒 を超えると速度は 1× に戻ります。

スムージング

指数移動平均（

α = 0.25
、約33 Hz 更新）で時間定数 ≈ 1 秒を実現。
話者の変化には十分速く、短い停止時に振れが生じないように設計されています。

インストール手順

  1. リポジトリをクローンまたはダウンロードします。
  2. chrome://extensions
    を開き Developer mode を有効化。
  3. Load unpacked → 
    speech-speed
    ディレクトリを選択。
  4. 動画があるページへ移動し、拡張アイコンをクリックして ON に切り替えます。

ファイル構成

ファイル用途
manifest.json
拡張機能設定（Manifest V3）
content.js
音声取得、音節検知、速度制御、診断オーバーレイのコアロジック
popup.html/js/css
ポップアップ UI：トグルと設定スライダー
syllable-worklet.js
v2 のレガシー AudioWorklet（未使用）

設定

ポップアップには 3 本のスライダーがあります：

  1. ターゲット率 – 4 – 14音節/秒、デフォルト 9。
  2. 最小速度 – 1 – 2×、デフォルト 1.0。
  3. 最大速度 – 1.5 – 5×、デフォルト 3.5。

設定は 

chrome.storage.local
に永続化されます。

診断オーバーレイ

有効にすると右上にダークパネルが表示されます：

  • Speed（大きな緑色の数値） – 現在の倍率。
  • syl/s（大きな青色の数値） – 推定自然音節率。
  • State – SPEAKING か SILENCE とその持続時間。
  • Energy bar – リアルタイム音量レベル。
  • History log – 秒ごとの速度と音節率のマッピング（最新が太字）。
  • Stats – ゼロ交差数、ポーリング回数、パイプライン段階。

チューニングガイド

すべての調整可能パラメータは 

content.js
にあります。

検知パラメータ

パラメータデフォルト役割調整方法
hpAlpha
0.9ハイパス係数 – カットオフを下げると低周波モジュレーションが多く通過。音楽/環境音が誤検出する場合は 0.8 に、非常に遅い話者（< 2 syl/s）では 0.95 に。
minCrossingInterval
70 ms音節とみなす最小時間間隔。音楽で誤カウントする場合は 100 ms、速い話者（>10 syl/s）の過少検出なら 50 ms に。
minEnergy
0.003無音ゲートのエネルギーフロア。背景ノイズが誤検出する場合は上げる、静かな話し声が逃す場合は下げる（「Energy」表示を確認）。
envelopeAlpha
0.3包絡線平滑化係数。変更頻度は低い。大きくすると無音検出が速くなる、逆に遅くなる。
windowSize
4000 ms音節率計算のスライディングウィンドウ。短め（2000 ms）で応答性を上げるとノイズ増大、長め（6000 ms）は滑らかだが遅延。

速度制御パラメータ

パラメータデフォルト役割調整方法
targetRate
9 syl/s目標音節率。主な操作：7＝中程度、9＝積極的、12＝非常に積極的。
smoothing
0.25スピード変化のEMA係数。低め（0.1）で遅い切り替え、高め（0.4）で速くても振れが増える。
silenceHoldSec
3 s無音時に 1× に戻るまでの秒数。自然な休止中に速度リセットされるなら上げ、停止後長時間残るなら下げる。
minSpeed / maxSpeed
1.0 / 3.5再生速度のクリップ範囲。タレントが 4×以上耐えられる場合は上げ、2×程度で止めたい場合は下げる。

バンドパスフィルタ

  • Highpass：300 Hz → 400–500 Hz に上げてベースノイズを減少させる。
  • Lowpass：3000 Hz → 4000 Hz で高音域話者に対応、2500 Hz 以下に下げると「s」「sh」のようなシビランが音節として数えられなくなる。

ポーリングレート

setupAudio()
の 
setInterval
は約30 ms（≈33 Hz）で実行。

  • 50 ms にすると CPU 消費は抑えられるが最大検出率が低下。
  • 15 ms に上げても実質的なメリットはほぼない。

現在の制約

問題影響
DRM 保護コンテンツ（Netflix, Disney+ 等）
captureStream()
がブロックされ、拡張機能が動作しません。
音楽・効果音ビートを音節と誤認する可能性があります。バンドパスフィルタと無音ゲーティングである程度対策しますが完璧ではありません。VAD（Voice Activity Detection）モデルの導入で改善できるでしょう。
同時に複数話者全体の率を合算してしまい、個別調整は難しいです。
背景音楽の多いポッドキャスト音節率検出が不正確になります。
SPA ナビゲーション（YouTube 等）ページ遷移時に 1–2 秒程度のギャップが生じ、拡張機能が再接続されます。

今後の改善案

  • Silero VAD 統合：音声活動を確認して検出器をゲートし、音楽や環境ノイズによる誤検出を減らします。
  • 自己相関ベースの率推定：ゼロ交差ではなく主なモジュレーション周波数を直接算出すると、より滑らかな推定が可能です。
  • 話者別適応：ディアリゼーションで個々の話者の率を保持し、活発な話者に即座に速度を切り替えます。
  • キーボードショートカット：
    chrome.commands
    を利用してポップアップを開かずに ON/OFF 切替できます。

ライセンス

MIT です。

同じ日のほかのニュース

一覧に戻る →

2026/03/18 3:59

**スラグの十年**

## 日本語訳 --- ## 要約 Slug アルゴリズムのライブラリは十周年を迎え、パブリックドメインに移行しました。これにより開発者はライセンス費用から解放され、強力な GPU‑direct テキストレンダリングが提供されます。2016 年秋に開発され、2017 年中頃に *JCGT* に論文が掲載され、その直後に Slug ライブラリのバージョン 1.0 が公開されました。 **主要な技術的進歩** - **ダイナミック拡張（Dynamic Dilation）**：MVP 行列とビューポート寸法を用いて頂点シェーダで半ピクセル外側に自動拡張を計算します（式 \(d = \frac{s^3t + s^2\sqrt{u^2+v^2}}{u^2+v^2-s^2t^2}\)）。これにより不要なパディングが排除され、エッジは鮮明に保たれます。 - **バンド分割最適化の削除**：ピクセルシェーダを簡素化し、バンドデータサイズを 4 つの 16‑bit コンポーネントから 2 に半減します。 - **アダプティブスーパーサンプリングの廃止**：ダイナミック拡張がエイリアシングを処理するため、追加コードはほぼ読み取り可能な文字だけに効果がありました。 - **絵文字レンダリングの簡素化**：レイヤーごとのループから独立したグリフレイヤリングへ切り替え、頂点数オーバーヘッドを削減しました。 これらの変更は、2016 年代のコンソールでの頑健性と高速化、高品質なアンチエイリアス出力（任意のスケールやパースペクティブ）を実現し、新しい GPU への保守性も向上させることを目的としていました。 **業界採用** Slug は C4 Engine のテキストエンジン、後に Radical Pie 方程式エディタで活用されました。Activision、Blizzard、id Software、2K Games、Ubisoft、Warner Brothers、Insomniac、Zenimax などの主要ゲームスタジオや、Adobe などの非ゲーム企業もライブラリを使用しています。 **パブリックドメイン状態** 特許 #10 373 352（2019 年に付与）は 2026 年 3 月 17 日からパブリックドメインへ譲渡されました。USPTO に Form SB/43 が提出され、料金が支払われたため、すべてのコードが自由に利用可能です。参照用頂点シェーダとピクセルシェーダは GitHub 上で MIT ライセンスされています。 **影響** 開発者は Slug の GPU‑direct レンダリングとダイナミック拡張を、ゲーム、アプリケーション、あるいは任意のグラフィックスソフトウェアにライセンス料なしで統合できます。簡素化されたシェーダは開発時間とリソース消費を削減し、パブリックドメイン公開によりコミュニティによる貢献が促進され、技術のさらなる洗練が期待されます。 ---

2026/03/18 5:23

**仕事を成し遂げる：メタプロンプティング・コンテキストエンジニアリング・スペック駆動型開発システム**

## 日本語訳: **GSD（“Get Shit Done”）** は、Claude Code、OpenCode、Gemini CLI、Codex、Copilot、および Antigravity など複数の AI コーディングランタイムを統合する軽量メタプロンプトフレームワークであり、コンテキストロット（文脈劣化）を緩和し、信頼性の高いコード生成を実現します。 インストールは `npx get-shit-done-cc@latest` で行い、ランタイムごとにグローバルまたはローカル設定（例：`--claude --global`、`--opencode --local` 等）を選択します。 コアワークフローは一連のコマンドによって駆動されます: - `/gsd:new-project` （プロジェクトスケルトン作成） - `/gsd:discuss-phase`、`/gsd:plan‑phase`、`/gsd:execute‑phase`、`/gsd:verify‑work`、`/gsd:complete‑milestone`、`/gsd:new‑milestone` - `/gsd:quick`（アドホックタスク）でオプションフラグ `--discuss`、`--research`、`--full` を付与可能。 各フェーズは構造化ファイル（`PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md`、`STATE.md`）と XML 形式の計画を生成し、Git に対してアトミックにコミットします。コミットは `feat(08‑02): add email confirmation flow` のようなパターンに従い、正確な bisect と明瞭な履歴が保証されます。 GSD は研究者・計画者・実行者・検証者という 4 人のエージェントを調整し、メインコンテキストウィンドウ（≈30–40 %）を新鮮に保ちつつ数千行のコードを生成します。 設定は `.planning/config.json` に格納され、ユーザーは `mode`、`granularity`、`workflow.research`、`git.branching_strategy` およびモデルプロファイル（`quality`、`balanced`、`budget`）を指定できます。また、`.env` やシークレット・キー等の機密ファイルを保護する deny リストも用意されています。 本プロジェクトは MIT ライセンスで公開されており、OpenCode、Gemini CLI、および Codex 用のコミュニティポートが存在します。Amazon、Google、Shopify、Webflow のエンジニアに信頼されており、最小限の “ロールプレイ” オーバーヘッドを重視しています―数個のシンプルなコマンドで複雑なワークフロー管理を抽象化します。 今後のアップデートではエージェントオーケストレーションの拡張、クイックモードフラグの洗練、および設定オプションの強化を目指しています。ワークフローを簡素化しツールング・オーバーヘッドを削減することで、GSD は個人開発者および企業にとって開発サイクルの高速化とコード品質の向上を実現できます。

2026/03/18 3:37

Python 3.15 のJIT（Just‑In‑Timeコンパイラ）が再び順調に進んでいます。

## Japanese Translation: (すべての主要ポイントを取り入れています):** CPython 3.15/3.16 JIT プロジェクトは、初期段階でパフォーマンスマイルストーンを達成しました。macOS AArch64 上では、JIT が tail‑calling インタプリタより約11〜12 %高速であり、x86_64 Linux では標準インタプリタを約5〜6 %上回っています。また、パフォーマンステストは幅広い結果を示しています。`unpack_sequence` マイクロベンチマークを除けば、約20 %の遅延から100 %以上の速度向上まであります。 主な技術的進歩には次が含まれます： - **トレース記録**：単一の「tracing」命令とデュアルディスパッチテーブルを使用し、インタプリタの肥大化を削減。Linux 上では約6 %遅延から約1〜2 %高速に改善しました。 - **参照カウントの除去**：分岐除去最適化で、命令ごとのオーバーヘッドを削減し、貢献者にとって有益な学習機会を提供します。 JIT チームは 2025 年に主要スポンサーを失いましたが、コミュニティの監督によって努力が継続しています。コア貢献者には Savannah Ostrowski、Mark Shannon、Diego Russo、Brandt Bucher、Hai Zhu、Zheaoli、Tomas Roun、Reiden Ong、および Donghee Na が含まれます。中間レベルの貢献者数は 2 人から 4 人に増加しました。 Savannah の 4 台のマシンで毎日 JIT を実行し、パフォーマンスフィードバックを提供し、回帰を検出し、新しい最適化を検証します。スプリント計画（Cambridge コア スプリント）は、CPython 3.15 で 5 %高速な JIT、3.16 では 10 %、フリースレッディングサポートの追加、および JIT の各段階で活躍するメンテナーを 2 人ずつ確保することを目指しています。 これらの進歩により CPython は競争力を維持し、より広いコミュニティ参加を促進し、フリースレッディングなど将来の機能への土台を築いています。