Thanks Ralph.
On the minor note, I had not realized those were already relevant
parameters. Anyone using this can reasonably be expected to know that,
so it is not a big deal. Given that it would only take one sentence, it
might be nice to add the statement anyway.
Yours,
Joel
On 1/15/16 6:41 PM, Ralph Giles wrote:
On 15/01/16 02:26 PM, Joel M. Halpern wrote:
Minor issues:
While I do not completely understand ogg lacing values, there
appears to be an internal inconsistency in the text in section 3:
1) "if the previous page with packet data does not end in a continued
packet (i.e., did not end with a lacing value of 255)"
2) "a packet that continues onto a subsequent page (i.e., when the page
ends with a lacing value of 255)"
The first quote says that continued packets end with a lacing value
of 255, and the second quote says that continued packets end with a
lacing value of less than 255. At the very least, these need to be
clarified.
Thanks for taking time to review the draft. You're right that the logic is
inverted in the last section. I've corrected the i.e. clause in the last
paragraph.
is there some way to indicate that the ogg encoding constraints
(e.g. 48kHz granule and 2.5 ms timing) are sufficiently broad to cover
all needed cases?
Hmm. RFC 6716 sec 2.1.3 and 2.1.4 give 48 kHz and 2.5 ms as the maximum sample
rate and minumum packet duration, respectively. I suppose sec. 4 of the draft
assumes these constraints.
It does indicate that 2.5 ms is the minimum packet duration, but we could add a
reference, or a statement that 48 kHz is the effective maximum sample rate of
the codec if it's cause for concern.
-r