citrinet_asr produces garbled output (subword salad) on CUDA at e74a290 and 3b4aed9

[5uck1ess]

Citrinet ASR transcription is unusable on this fork at both e74a290 and current main (3b4aed9), while qwen3_asr works correctly on the same server/build.

Repro (RTX 3090, linux-cuda-release build via scripts/build_linux.sh --backend cuda):

1. Install weights with the same commit's own tooling: tools/model_manager.py install citrinet_asr --models-root models (NGC stt_en_citrinet_256.nemo → safetensors conversion, completes cleanly).
2. Serve: audiocpp_server with a task:asr entry, family citrinet_asr.
3. POST /v1/audio/transcriptions with clean 16kHz mono PCM WAV (tested both synthetic TTS speech and a real human recording).

Expected: normal English transcription (faster-whisper transcribes the same files perfectly; qwen3_asr on the same audiocpp_server gets them mostly right).
Actual: subword salad, e.g. 'reer de e he canrin read wouldtlo si veryum know love had fa...' — fragments look like valid subword tokens glued in the wrong order, suggesting a tokenizer/vocab mapping or feature-extraction (mel config/normalization) mismatch in the conversion or inference path rather than a broken download (identical result with weights converted independently at both commits).

Latency is excellent (~150ms for 8.5s audio, CUDA) — this model is the framework's best shot at beating CTranslate2-class ASR for short utterances, which is why the fix matters. Happy to run diagnostics on this box if useful.

[5uck1ess]

Root-caused. Not CUDA — the CPU backend reproduces the exact same output byte-for-byte, so the "on CUDA" framing was a red herring (CUDA was just the only backend tried).

The bug: the runtime decodes CTC ids against the sidecar vocab.txt copied verbatim from the NeMo archive. That file is NeMo's WordPiece-compat vocab and omits <unk> (id 0), so every line is shifted one position from the true SentencePiece ids — every token decodes to the wrong piece, hence subwords that look valid but assemble into nonsense. The vocab_size check never caught it because the line loader counts a phantom empty entry for the trailing newline (1023 lines pass as 1024).

Fix submitted upstream: 0xShug0/audio.cpp#49 — decode through tokenizer.model (already exported by the converter) via the framework's own SentencePiece support, drop the vocab.txt dependency. Verified on this box: the same clip that produced salad now transcribes exactly right on both CUDA and CPU, with the existing converted model directory untouched. Latency unchanged (~150ms class), so the "best shot at beating CTranslate2 for short utterances" motivation stands.

[5uck1ess]

Resolved on this box: the fix (decode CTC ids through tokenizer.model via the framework's SentencePiece support) is deployed on the fork branch fix/citrinet-tokenizer-decode of 5uck1ess/audio.cpp-fork, now rebased onto upstream Release 0.3. Verified: the repro clip transcribes correctly on both CUDA and CPU with the existing converted model directory untouched. Upstream fix pending review at 0xShug0/audio.cpp#49.