Hi,
I suggest adding these two sections to the OggOpus draft, one that
describes how to handle chaining and one that has recommendations for
encoders. I'm sure there's still more things an encoder can do that I
haven't listed.
Jean-Marc
diff --git a/doc/draft-terriberry-oggopus.xml b/doc/draft-terriberry-oggopus.xml
index 14f962a..6abe788 100644
--- a/doc/draft-terriberry-oggopus.xml
+++ b/doc/draft-terriberry-oggopus.xml
@@ -951,6 +951,47 @@ An implementation could reasonably choose any of these numbers for its internal
</t>
</section>
+<section anchor="chaining" title="Chaining">
+<t>
+Like all Ogg streams, Opus streams can be "chained", i.e. contatenated
+together. Although it is possible to simply decode the streams
+independently and concatenate the resulting audio, this results in a
+discontinuity in the audio, which may be audible. Such discontinuity can be
+avoided by obtaining more audio from the stream before the boundary, and
+"cross-fading" that audio with the new stream. The extra audio can be
+obtained in two ways:
+<list style="numbers">
+<t>If there are sufficient usable "trimmed" samples past the end of the audio and those trimmed
+samples represent the actual audio past the end of the file, then these samples
+can be used. These trimmed samples may come from the a</t>
+<t>If trimmed samples cannot be used, use linear prediction on the end of the first
+stream to predict about 2.5 ms of audio at the beginning of the second stream.</t>
+</list>
+
+Opus streams do not explicitly contain sufficient information to tell case 1
+from case 2. One way of deciding whether to use the trimmed samples or
+extrapolated samples is to evaluate the mean squared error between the trimmed
+samples and the first samples of the second stream. This error can be compared
+either to a fixed percentage of the signal's mean square, or to the mean squared
+error between the extrapolated signal and the beginning of the second stream.
+</t>
+</section>
+
+<section anchor="encoder" title="Encoder Recommendations">
+<t>
+This section makes a few recommendations for encoders to produce optimal Ogg
+Opus files. To make gapless files possible, it is RECOMMENDED that encoders
+use linear extrapolation for a duration of at least 2.5 ms at the beginning
+of the file (which can be trimmed using the preskip field). For the end of the
+file, the RECOMMENDED extrapolation duration is at
+least equal to the encoder's look-ahead at the end of the file (7 ms for the
+reference encoder), plus 2.5 ms to facilitate chaining.
+To make the extrapolated samples at the end usable to all decoders, it is
+RECOMMENDED that these samples be part of the same packet as the last
+non-trimmed samples (possibly by merging multiple frames in a single packet).
+</t>
+</section>
+
<section anchor="security" title="Security Considerations">
<t>
Implementations of the Opus codec need to take appropriate security
_______________________________________________
codec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/codec
