claude
fabc3bc274
PCMFromWAV found the data chunk by scanning forward byte by byte from offset 36 for the literal data. A LIST or INFO chunk between fmt and data is common, both arecord and ffmpeg write one, and its payload is free text that can contain that word. So the parser could take a comment for a chunk header and read it as samples. It walks chunk headers with word alignment now, and a new test builds exactly that file. Three smaller things. WAVHeader named a different function in its error, which matters because internal/capture calls it directly twice. The tts stub wrote 16000 three times and now reads the rate and the sample width off audio.PCM16kMono. PCMFromWAV returns a subslice of the caller's buffer, which is the right trade for a long recording and was undocumented. The agent refuted three of the brief's premises. The lexicon two-pass loop is correct for any run length, because the first pass takes every other name and frees both boundaries of the ones it skipped, measured at runs of three, four and five. There is no duration-to-byte truncation here, since every length is a float64 in seconds. There is no resampler and no subprocess in these four packages. The offload contract is not touched here. stt.Remote and tts.Remote are plain worker clients, and the workstation preference lives in modelSeam and the phraser. (V-581)