[vorbis-dev] Specification change requests

[Tor-Einar Jarnbjo]

Tirsdag, 15 oktober 2002, skrev du:

>Sorry for taking a few hours, I was running my 'what the fuck was I
>thinking' filter set to 'high' just to make sure...  Naturally folks
>will want to verify the corrections.  They've been propogated to the
>online docs as well.

I appreciate, that you spent some time to check them out. 

>> It also does not make sense to use the expensive function render_line
>> to set all remaining elements in the vector to the same value, so 
>> a better algorithm for this might be something like:
>> 
>> if ( [hx] is less than [n] ) {
>>    iterate [i] over the range [hx] + 1 ... [n] - 1 {
>>       set vector [floor1_final_Y]' element [i] to [hy]
>>    }
>> )
>
>In this case it's more important to be clear than fast.

But is the current specification "draw a line from hx, hy to n-1,
hy" really easier to understand and more consistent than "set the 
elements from hx to n-1 to the value hy"? In my suggestion, the iteration 
should of course start with hx and not hx+1.

>> 13) if ( [hx] is greater than [n] ) {
>>   14) truncate vector [floor] to [n] elements
>> }
>
>It does not make sense, but it's important to be well defined.  An
>ecoder may be cofused, or the stream may be malicious and looking to
>create an intentional overrun.

And this reminds me of another point I forgot to mention. The specification 
does not at any point specify the vector length. Wouldn't it make 
sense to do so? I assume that any reasonable implementation needs 
to know the needed length before setting the values, and although 
the vector length in most cases is pretty obvious, there are a few 
points in the specification where it is not, like when reading the 
x-list when decoding a floor 1 entry in the header.

>> ###############
>> #2002-10-15-001
>[...]
>> If the flag is false, the value of vorbis_mapping_coupling_steps 
>> and the length and content of the two vectors are left unspecified,
>> although they are referenced anyway in the audio packet decode 
section under 
>> "nonzero vector propagate".
>
>You're correct, the default value of vorbis_mapping_coupling_steps
>should be zero.  Fixed.

And this is also a point where I think it would make sense to specify,
that the vector length should be 0. When implementing the specification,
I interpreted this part as if the vectors would not be used later 
when the bit is unset, and ran into accessing a null reference since 
no array was allocated. I don't know how the part is implemented 
in libvorbis, but in Java it sure makes a difference having no array 
at all as compared to an array with 0 elements.

<p>Tor

<p><p><p>===================================================================
EASY and FREE access to your email anywhere: http://Mailreader.com/
===================================================================

<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 'vorbis-dev-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.