CodecDelay states "This timestamp value MUST be subtracted from each frame timestamp in order to get the timestamp that will be actually played."

CueTime just says "Absolute timestamp of the seek point." But "absolute timestamp" can be interpreted in different ways. The interaction of these two elements is unclear and underspecified. Questions:

1. Should CueTime's absolute timestamp value be Cluster.Timestamp + Block.Timestamp, or should it be Cluster.Timestamp + Block.Timestamp - CodecDelay? If the latter, should it also account for any potential DiscardPadding in a block group?
2. Should the duration of the cue account for CodecDelay? If so, should it also account for any potential DiscardPadding in a block group?

In my experience cues have not accounted for CodecDelay or any DiscardPadding. Assuming this is correct, it may also be worth calling out that applications should account for CodecDelay (and DiscardPadding if feasible, though that's harder) when using CueTimes because it's pretty easy to accidentally skip it.

For example, let's say an Opus track is saved with 5 segments with each being 10 seconds long (ignoring any codec delay or padding) with CueTimes of 0s, 10s, 20s, 30s, and 40s. It would be technically incorrect for the application to blindly take these CueTimes and use them or present them to the user. The actual media times for these segments are be [0, 9.9935] for the first segment, [9.9935, 19.9935] for the second segment, etc. until [39.9935, 49.9935] for the final segment.