Field notes · 2026年8月17日

聴こえた拍で採点する——可聴クロックという考え方

ホワイトペーパーの中心にある考え方を、 数式なしで。ソフトウェアが予定した拍ではなく、プレイヤーに聴こえた拍で採点する理由です。

すべてのリズムゲームは、同じ物理と付き合っています。ソフトウェアが「拍はいま」 と決めた瞬間から、音がスピーカーを出る瞬間までには、パイプラインがある——音声バッファ、 OS のミキサー、ときには Bluetooth のホップ。有線ならおよそ30ミリ秒。Bluetooth なら 300ミリ秒に達することもあります。比べる相手がないから、誰も気づかない。でもプレイは その終端に合わせて行われます。プレイヤーは、聴こえた音に合わせて叩くのです。

ここに罠があります。タップを「予定を立てた時計」で記録すると、正直なタップはすべて、 そのデバイスのパイプラインの長さぶんだけ「遅れて」届く。Bluetooth イヤホンで完璧に 演奏しても、全部の拍を外しうる——演奏がズレていたからではなく、審判がプレイヤーと 違う時計を聴いていたからです。

ダンス審査のたとえ

ビデオ通話越しのダンス審査を想像してください。審査員が、自分の部屋で流れる 音楽を基準に全員を採点したら——回線の速いダンサーは問題ない。回線の遅いダンサーは 全員ズレて見える。一歩一歩が、審査員の音楽よりきっかり一拍遅れて、完璧な一貫性で。 彼らは下手なのでしょうか。もちろん違います。音楽は遅れて届き、彼らは届いた音楽に 合わせて踊った。審査が、たったひとつの公平な問いを立てなかっただけです。 「その人に届いた音楽」のビートに合っていたか?

ビデオ通話を音声パイプラインに置き換えれば、これは多くのタイミング採点が実際に やっていることそのものです——そして特定のハードウェアの持ち主だけが静かに損をする 理由でもあります。

聴こえた拍で採点する

OneDrum の答えは、スケジューリングの時計に時刻を尋ねるのをやめることでした。音声 システム自身が「どのサンプルが、どの瞬間にスピーカーを出ているか」を報告できます—— 「プレイヤーがいま何を聴いているか」の実況です。そこから可聴クロックを 導出します。キューに使った音、として予定された音ではなく、聴こえている音に固定された タイムラインです。

比較の両側を、この時計に載せ替えます。キューの時刻は「キューが聴こえた時刻」。 タップの時刻は、入力イベント自身のタイムスタンプを同じタイムラインに変換したもの。 キューとタップが基準系を共有した瞬間、引き算からパイプラインは完全に消えます。 聴こえた拍に合わせたタップは、音が届くのに30ミリ秒かかろうと300ミリ秒かかろうと、 「ジャスト」と採点されます。

解かないと決めたこと

可聴クロックが取り除くのはデバイスの系統的な遅延です。プレイヤー 自身の遅延——わずかに遅れて応える癖や、タッチパネルの入力遅延——には、意図的に 関与しません。そちらを引き受けるのが「較正ステップのない較正」です。最初の1小節が、 そのまま無音の測定になる(ホワイトペーパー §4)。さらに、 デバイスが報告する遅延がセッション中に動いたときは—— 本番データが Android で実際に捉えた現象—— ドリフト再センタリングが補正を最新に保ちます。そして、このどれにも触れられないのが アンチスプーフのゲートです。較正では動かせない値の上で計算されるため、遅い ハードウェアへの補正が、ボットを審判の前に通す抜け道になることはありません。

考え方はこれだけです。審判とプレイヤーが、ようやく同じ時計を聴く——エンジンの 残りの仕事はすべて、その時計を狂わせないことです。

実際に聴いてみてください。太鼓が呼び、あなたが応える:onedrum.io

数式とフィールドデータを含む全メカニズムは ホワイトペーパー(日本語版)へ。English version of this article. · 記事一覧へ