Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

TDT beam search fails above ~40-90s of audio: "zero-duration expansion did not reduce score" (greedy on the same audio is fine)

オープン
#61 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
58/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
cpp

調査の方向性

提供された 16 kHz モノラル PCM ケースを使用し、parakeet_capi_transcribe_pcm_nbest_json を通じて失敗を再現し、その後 greedy のエントリポイントおよび切り詰めた音声と比較します。報告された不変条件「zero-duration expansion did not reduce score」を中心に TDT beam-search の経路と、tdt-0.6b-v3 モデルの挙動を追跡します。完了条件は、既存の greedy および短い入力の挙動を維持したまま、長い入力の N-best デコードで中断しなくなることです。

索引モデルが issue の本文から書いたものです。

説明

parakeet_capi_transcribe_pcm_nbest_json aborts on longer inputs with

tdt_beam_search: zero-duration expansion did not reduce score

while greedy decoding of the same audio with the same model succeeds. It reads like an internal invariant that long inputs violate, rather than a bad-input case.

Environment

  • parakeet.cpp v0.5.0, released lib-macos-metal-arm64 bundle (ABI 6)
  • macOS arm64, Metal backend
  • Model: mudler/parakeet-cpp-gguf → tdt-0.6b-v3-q4_k.gguf
  • Audio: 16 kHz mono float PCM, AMI meeting recordings (~100s each)

What fails

22 of 23 AMI clips (~100s each) fail. One succeeded, and only at beam 4.

It is not a beam-width interaction — beam 1 fails identically to beam 8:

beam_size=1  FAIL   beam_size=2  FAIL   beam_size=4  FAIL   beam_size=8  FAIL

What succeeds on the identical audio

  • parakeet_capi_transcribe_pcm (greedy) — 242 words, no error
  • parakeet_capi_transcribe_pcm_batch_json (greedy + timestamps) — 242 words, 242 word records
  • The same N-best call on the first 30s or 40s of that same file

So the encoder, the model and the audio are all fine; it is specific to the beam search path at length.

Threshold varies with content, not a fixed limit

Truncating each file to N seconds and decoding at beam 4:

file length 30s 40s 50s 60s 70s 80s 90s
ES2004a_FEE013 100.6s ok ok ok fail fail fail fail
EN2002c_MEE071 100.0s ok ok ok ok ok ok fail
ES2004b_MEO015 105.7s ok ok fail fail fail fail fail

All three pass at 30s and 40s and fail before 100s, at different points — consistent with something accumulating over frames rather than a hard cap.

Possibly model-specific

The same 100.6s clip decodes fine at beam 2, 4 and 8 with tdt_ctc-1.1b-q4_k.gguf. Only tdt-0.6b-v3 failed here, so it may be an interaction between that checkpoint's duration predictions and the expansion check.

Minimal reproduction

# ctypes against libparakeet.dylib from the v0.5.0 release
ptr = lib.parakeet_capi_transcribe_pcm_nbest_json(
    ctx, samples_p, len(samples), 16000, 4, 1, 1, None)
# ptr is NULL; parakeet_capi_last_error(ctx) reports the message above.
# Truncating `samples` to 40s makes the same call succeed.

Possibly related to #55 (error above 5 min), though the threshold here is far lower and the message differs.

Not blocking for us — we moved to transcribe_pcm_batch_json, which gives greedy output with per-word timestamps and no beam search. Reporting because the failure is silent-until-it-isn't for anyone relying on N-best over long audio.

主要言語
C++
スター
796
フォーク
97
平均マージ
9日 19時間
マージ済み PR(30日)
4

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

mudler/parakeet.cpp のほかの issue

mudler/parakeet.cpp の issue をすべて見る

似ている issue

C++ の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。