Model name
parakeet-tdt-0.6b-v3
Command run
None. Found by code inspection of swift/Sources/CoreAISpeech/SpeechRecognitionModel.swift at commit 82a0e5e5. If the field refuses to be empty, paste exactly that sentence.
macOS / iOS target
macOS 27.0 beta (build 26A5406e)
Xcode version
Xcode 27.0 beta (build 27A5194q)
Python / uv version
Python 3.13.14
Full error output
None. Found by code inspection of swift/Sources/CoreAISpeech/SpeechRecognitionModel.swift at commit 82a0e5e5.
Anything else?
What happens. In swift/Sources/CoreAISpeech/SpeechRecognitionModel.swift (lines 254 to 269 at commit 82a0e5e), validEncoderFrames is computed as a proportional estimate, round(validMelFrames / totalMelFrames * tEnc) clamped to [1, tEnc], and the doc comment notes a possible one-frame error. That estimated value then caps the TDT decode loop in ParakeetTDTDecoder.swift (line 139), and SpeechParityTest.swift (lines 132 to 146) has to tolerate a one-frame drift against the reference before failing, which slightly weakens the parity harness.
Why it can be exact. The FastConformer front end reduces time resolution through three stride-2 subsampling stages, each computing T = (T - 1) / 2 + 1 in integer arithmetic. Applying that formula three times to validMelFrames gives the exact number of encoder frames that correspond to real audio, with no proportionality assumption. The subsampling factor is already surfaced in the export metadata (encoder.subsampling_factor), so the runtime has what it needs to compute this deterministically, or the export could carry the per-stage formula explicitly if you prefer not to hard-code the stage count.
Impact. The decode cap can land one frame early or late around real audio boundaries, which occasionally clips or admits a trailing token, and the parity test's one-frame tolerance exists only to absorb this estimate. Replacing the estimate with the exact arithmetic tightens both, and would let the parity harness compare the full valid region without slack.
Model name
parakeet-tdt-0.6b-v3
Command run
macOS / iOS target
macOS 27.0 beta (build 26A5406e)
Xcode version
Xcode 27.0 beta (build 27A5194q)
Python / uv version
Python 3.13.14
Full error output
Anything else?
What happens. In
swift/Sources/CoreAISpeech/SpeechRecognitionModel.swift(lines 254 to 269 at commit 82a0e5e),validEncoderFramesis computed as a proportional estimate,round(validMelFrames / totalMelFrames * tEnc)clamped to[1, tEnc], and the doc comment notes a possible one-frame error. That estimated value then caps the TDT decode loop inParakeetTDTDecoder.swift(line 139), andSpeechParityTest.swift(lines 132 to 146) has to tolerate a one-frame drift against the reference before failing, which slightly weakens the parity harness.Why it can be exact. The FastConformer front end reduces time resolution through three stride-2 subsampling stages, each computing
T = (T - 1) / 2 + 1in integer arithmetic. Applying that formula three times tovalidMelFramesgives the exact number of encoder frames that correspond to real audio, with no proportionality assumption. The subsampling factor is already surfaced in the export metadata (encoder.subsampling_factor), so the runtime has what it needs to compute this deterministically, or the export could carry the per-stage formula explicitly if you prefer not to hard-code the stage count.Impact. The decode cap can land one frame early or late around real audio boundaries, which occasionally clips or admits a trailing token, and the parity test's one-frame tolerance exists only to absorb this estimate. Replacing the estimate with the exact arithmetic tightens both, and would let the parity harness compare the full valid region without slack.