>> It is possible to run an Opus decoder at other sampling rates, but >> a sampling rate of 48 kHz is sufficient to capture the full audio >> bandwidth of any Opus packet. Therefore, the value in the granule >> position field always counts samples assuming a 48 kHz decoding rate >> ... > > > I think this loses the important property that the other sample rates evenly > divide 48 kHz. That property implies that a 48 kHz rate is sufficient to > capture sample-accurate timing information without having to introduce > specific rules around propagation of rounding errors, etc., regardless of > the sample rate used at either endpoint. That is why we chose 48 kHz instead > of say, 40 kHz (which would also have been sufficient to capture the full > audio bandwidth, but would have made sample-accurate operations quite > cumbersome). > > Would you be satisfied with saying, "It is possible to run the decoder in > the Opus reference implementation at other sampling rates..." instead? >
The request that led to the additional text was a request to clarify that a fixed 48 kHz rate for the granule position is sufficiently broad to cover all needed cases. I'm not sure that an explanation based solely on the decoding rates supported by a particular implementation addresses that. If anything it actually draws attention to the question (without answering it) of whether the chosen fixed rate is sufficiently broad, or is tailored to the needs of that particular implementation. How about this: "It is possible to run an Opus decoder at other sampling rates, but all Opus packets encode samples at a sampling rate that evenly divides 48 kHz. Therefore, the value in the granule position field always counts samples assuming a 48 kHz decoding rate..." - Mark _______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
