Displaying 2 results from an estimated 2 matches for "dist_h".
Did you mean:
disk_h
2008 Nov 14
0
[Schrodinger-devel] ogg dirac granulepos in oggz tools
...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
> Dirac packets...
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
>