Displaying 2 results from an estimated 2 matches for "dist_l".
Did you mean:
dist_
2008 Nov 14
0
[Schrodinger-devel] ogg dirac granulepos in oggz tools
...delay:7484)
the way i calculated dt in oggz is actually redundant. dt is defined
to be: dt=pt-delay; and is contained in the top 32bits of GP64, so
if GP64 is very -ve, why is dt=0?
Answer: because pt="GPH+L">>9 relies on the two zero bits being set
so that any overflow in adding dist_l and dist_h together don't affect
pt.
To summarise, the value of dt calculated in oggz_tools should be
identical to the top 32 bits of GP64. If that fails, The two
protection bits havn't been cleared correctly.
> I modified the packet ordering check to not take the timestamp of
> Di...
2008 Nov 14
6
[Schrodinger-devel] ogg dirac granulepos in oggz tools
2008/11/14 David Flynn <davidf+nntp at woaf.net>:
> On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote:
>> I'm wondering if the Dirac granulepos parsing in liboggz and display
>> in the oggz tools is currently correct, as I'd like to do a release of
>> these soon.
>
> I believe it is -- although if correct support in the rest of the
>