Audio encoder delay
Encoder delay and end padding are extra decoded frames introduced by codec processing and block alignment that need correct timing and trim information.
An audio encoder does not always turn the first input sample into the first sample that a decoder returns. Analysis windows, filter history, lookahead and resampling can introduce priming before the intended programme. A block-based codec may also need to fill its final block, producing padding after the intended end.
The file therefore needs enough information to distinguish the decoded representation from the original programme interval. Otherwise, a player can add a pause between tracks or place the start of audio at the wrong time.
Stored duration and intended duration
For an illustrative codec that returns 1,024 PCM sample frames per block, suppose the intended programme contains 10,000 frames and its signaled leading trim is 1,024 frames.
The combined length so far is 11,024. Eleven complete blocks contain 11,264 frames, so the final block needs another 240 frames of padding.
decoded total = priming + intended programme + end padding
11,264 = 1,024 + 10,000 + 240
At 48 kHz, the intended programme lasts 208.333 ms. The full decoded representation lasts 234.667 ms. The difference is codec-related framing, not additional music.
The actual priming count must come from the codec and file's timing information. A block length of 1,024 does not prove that a real AAC encoder's delay is 1,024; an implementation can introduce a different count, including one that is not a whole number of blocks.
Formats describe trimming differently
CAF's packet-table information can record valid, priming and remainder frame counts. These explicitly identify the programme interval within the decoded result.
Ogg Opus uses a pre-skip value at the beginning of the stream and granule-position rules for the ending. Its time count uses a 48 kHz clock per channel, regardless of the original input rate stored in the header. A pre-skip value of 312, for example, represents 6.5 ms on that clock. It is an example value, not a rule that all Opus streams use 312.
The player decodes the required initial material and discards the pre-skip output. It also respects the declared final position. Stereo does not double the time count: 312 simultaneous left/right sample frames still occupy 6.5 ms.
Trim information can be carried by a container, codec-specific fields or associated metadata. A decoder's block count alone cannot determine the intended end if the final block is partly padding. Detecting runs of zeros is also unreliable: useful audio can contain silence, and priming output can contain nonzero values.
Start trimming, seeking and device latency
At a seek point, some codecs need earlier data to rebuild state before producing accurate samples at the requested time. Ogg Opus specifies pre-roll for this purpose. It is distinct from the stream's initial pre-skip. Reapplying the original leading trim at every arbitrary seek would confuse two different positions in the programme.
Device latency comes later. Output buffers, a Bluetooth link and a DAC can delay when valid samples become audible. Removing codec priming does not remove those buffers. Conversely, changing an audio/video offset does not tell a player which trailing samples belong to the programme.
For a converted Emby stream, timing and duration need to reflect the new encoder's representation. Copying an old delay value into a differently encoded result can trim real audio or expose new padding. In gapless playback, correct trim counts define the boundary; preparation and output scheduling then make that boundary continuous.