Timestamps

startMs and endMs on transcript.final and translation.final are millisecond offsets into this stream's audio, measured from the first byte you sent. With store: true they are positions in the recording you can download.

json

{  "type": "transcript.final",  "segmentId": "gw_8f3a_2",  "text": "the quantization step near zero is about eight",  "startMs": 118400,     // 1:58.400 into this stream's audio  "endMs":   122900}

Recognisers report timing relative to their own upstream connection, and that connection re-establishes mid-session without telling you. When it does, the clock resets to zero and click-to-play starts jumping backwards. Short tests never reconnect, so this surfaces in production.

// The recogniser's upstream connection re-establishes at 1:15.// Its own timing restarts from zero — unusable for seeking:0        42000    75000    0        31000// LecSync measures the same segments on the audio byte clock:0        42000    75000    118400   149400   // monotonic, maps onto the recording

Timestamps come from a byte clock over the audio you sent, not from the recogniser's own clock, so they stay monotonic across upstream reconnects. A small number of segments may arrive without timestamps when the recogniser does not supply token-level timing.

With store: true, one connection produces one recording. If your network drops mid-session you get multiple files — order them by creation time.