[xiph-cvs] cvs commit: vorbis/doc vorbis-spec-res.html

[Segher Boessenkool]

> +<tt>residue_begin</tt> and <tt>residue_end</tt> select the specific
> +subportion of each vector that is actually coded; it implements akin
> +to a bandpass where, for coding purposes, the vector effectively
> +begins at element <tt>residue_begin</tt> and ends at
> +<tt>residue_end</tt>.  Preceeding and following values in the unpacked
> +vectors are zeroed.  Note that for residue type 2, these values as
> +well as <tt>[residue_partition_size</tt>apply to the interleaved
> +vector, not the individual vectors before interleave.

This is problematic, as the length of the interleaved vector depends on ch.

This doesn't manifest itself with current stereo streams, as ch = 2 always
(it can never be 1, because of channel coupling).  Mono always has ch = 1.

But suppose we have residue_begin = 3, residue_end = 800, *per channel*;
blocksize = 1024, and the residue can have ch = 4 at maximum;
so the actual residue_begin = 12, residue_end = 3200.

Now suppose decode gets passed ch = 2
(because the L/R-back channels were both zero, and the front channels were
non-zero, for example).

The effective _per channel_ residue_begin becomes 6, residue_end becomes 1600.

Now 1600 > 1024, so that might overflow; let's hope the current code is okay
with this ;)

But more importantly, 6 > 3, so the high pass frequency is too high.

<p>I propose never encoding with 0 < ch < max_ch (it has other problems as
well; say partition
size is 18, book dim is 6; now try ch = 4; 4 doesn't divide 18).  This
won't change
current libvorbis' behaviour at all for any current streams, I think.

<p>Cheers,

Segher

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'cvs-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.