search for: gph

David Flynn has proposed a new Ogg Dirac mapping. The draft is here: http://davidf.woaf.net/dirac-mapping-ogg.pdf This is a much bigger break from other codecs than my draft (at http://wiki.xiph.org/index.php/OggDirac). We talked a bit about it on IRC today. Below is my summary; hopefully David can correct anything I got wrong or misleading. Comments? There are two main differences

Dear R-Users, I am doing a research on Time Series, especially on the estimation of the fractional exponent in long memory time series (for those who know). However there are three estimators already built-in the fracdiff package (GPH, Sperio, MLE) I was wondering if there is someone who had used an estimation introduced by P.M. Robinson (related paper: "Log-Periodogram regression of time series with long range dependence", 1995, The Annals of Statistics, Vol. 23, p. 1048 - 1072) The estimator is similar to GPH and Spe...

i am trying to replicate the following graph using xyplot : attach(x) plot ( jitter(type), mortality, pch=16, xlim = c(0.25, 3.75)) lines ( c(1-0.375,1.375) , c ( median(mortality[type==1]), median(mortality[type==1])), lwd=5,col=2) lines ( c(2-0.375,2.375) , c ( median(mortality[type==2]), median(mortality[type==2])), lwd=5,col=2) lines ( c(3-0.375,3.375) , c ( median(mortality[type==3]),

...#39;t handle without breaking the numerically non-decreasing granulepos rule. That's an argument for David's granulepos mapping, especially since the open gop stuff in my mapping is hacky. My thinking now is that the non-decreasing numeric encoding (the stop-the-presses version) is better. GPH+GPL=frame works for theora, but doesn't do any better with naive seeking than 'find this numerical granulepos' and doesn't simplify frame-accurate seeking if you relax the one-page-per-packet rule, which I think we must. On Wed, Aug 13, 2008 at 1:08 PM, David Flynn <davidf+nntp...

...dirac mapping maintains the property that GP64 (the raw granule_position) is always increasing. This value is related to dt. In order to get the presentation time of the dirac picture, you split the GP64 value at the granuleshift point yeilding high & low; these are then summed. (i call this GPH+L) Dirac is an out-of-order codec, the presentation time therefor jumps around. What you are seeing is correct. This also raises a few important points. When multiplexing streams together, it is important to use the time related to the GP64 (dt) value and not the GPH+L. Multiplexing based on d...

...- sort_and_interleave (all logical_streams) using x.muxing_time That would work for say dirac and vorbis i think and end up with a reasonable ordering. Unfortunately, that doesn't work for the theora granule-shift method, since mapping GP64<->time is nonlinear. (GP64 = granule pos 64) (GPH+L = (GP64 >> granule_shift) + (GP64 - ((GP64 >> granule_shift) << granule_shift)) NB, May also be written: GPH+L = (GP64 >> granule_shift) + (GP64 & ((1 << granule_shift) - 1)) [1] Mostly with regard to a hypothetical 'timeline' -- but these...

2008/11/15 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote: >> It seems oggz chop, merge and sort will need some attention to deal >> with the Dirac granulepos and dependency ordering, so let's leave them >> for the next release. > > ok. -- may be worth having them 'warn' if they are operating

Hi, 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. A couple of days ago David Schleef mentioned there were some problems. David, is that currently true (ie. since David Flynn's recent updates to support Dirac), and if so could you please explain what the problems are, or point me

...ume it is the higher word, i believe the granulerate would >> need to be 2*(1<<9)*fps_n/fps_d; in order to allow dumb tools to get things >> vaguely right. > > a granule is a frame, field, sample etc., and granulerate is framerate, > samplerate etc. Err, yes -- just that GPH+L + 1 doesn't advance time by one picture > Yeah; I've been thinking we should at least add a field to skeleton to > accomodate the Dirac mapping. agree. > The main thing is to identify which algorithm to use for converting > granulepos to time. agree. > The way the cur...

...hemselves inconsistent with par(fig=...) are obviously disallowed.] I am wondering whether there are caveats of which I and others should be aware, or whether there is a risk that the ongoing development of R's graphics abilities will render such a cohabitation unworkably fractious. Example: gph <- bwplot(voice.part ~ height, data=singer) print(gph, position=c(0, 0.5, 1, 1)) # x0, y0, x1, y1 par(fig=c(0, 1, 0,0.5), new=TRUE) # x0, x1, y0, y1 boxplot(height ~ voice.part, data=singer, horiz=TRUE) John Maindonald email: john.maindonald at anu.edu.au phone : +61 2 (6125)3473...

...d :-) > [2] http://wiki.xiph.org/index.php/Ogg_Skeleton says: > """ > allowing to map a granule position to time by calculating > "granulepos / granulerate" > """ > But that doesn't seem to be what happened in liboggz -- it used GPH+L. thanks for pointing that out, the wiki page is incorrect. Please refer to: http://svn.annodex.net/standards/draft-pfeiffer-oggskeleton-current.txt cheers, Conrad.

...dency order, not display order >> -- then how should oggz-validate be modified to handle this properly? > > It should check that DT (GP64) doesn't decrease ("Granulepos decreasing > within track") > > It should not check for 'out of order' packets based on GPH+L for a > dirac stream, since by definition they are. Ok, so the GP64 check remains. I modified the packet ordering check to not take the timestamp of Dirac packets into account (changeset:3782). So effectively, the GP64 check ensures that the ordering within the Dirac track is ok, but the ti...

...why that granulepos looks so wrong: 00:02:36.077: -362377 -> (pt:7484,dt:0,dist:65399,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 clear...

Hello I m a student in PARIS X university (France).I m preparing a working paper dealing with the presence of long memory in finantial markets. I have programs computing the hurst exponent by the rescaled range method and the GPH method (Geweke Porter-Hudak). I want to apply the modified rescaled range method proposed by A.Lo (1991). AS i m beggining with RATS i couldn't do the progam . can you send me the program (for RATS ) computing the hurst exponent with the modified rescaled range method or tell me where can i fin...

hello all I need to generate a subkey in gpg in order to sign my emails. I already have a main key. how do I generate the subkey I need to encrypt emails? I have already run gpg --gen-key thanks -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

Hi, attached there is a serie of patches that completes the work on making virt-builder use .conf files, shipped in XDG directories, to configure all the available sources of indexes used. This also removes the hardcoded default location, replaced now with a configuration file (which may be not used at all). Thanks, Pino Toscano (8): builder: allow "no key" as key in Sigchecker

...!(}%dfLFRu;HJ-yvz6(CJD*<nMrEUP(HgR zArL{qLCI>|*#L^Bg^g~87rbC~)~s{PG0jS#vkU_yfyRKkvA!d~bW>=zB%8i at ue<aC zc`5TYVt*O%F&&zg8d3X*?U at v}o{cKZ0C}aS8dA<lQf4QNm9UMRdAs!X=HjiTHlQFh z^fXfD#O9W0D at fCkd0zYJb4&qA`Fxm7<TX>{g{+E!%;5TtVAf3l&HDGDvFh0nfAYEW zcL#$V4f6PvJ^r_!xgGph%+ud~=4CZsVOjt7Qiy|d&(cpq#2nUiQxw;u`jk$rEk~&< zWIsZ|WE_AikF&ul|3osoho%sT;Omp24tsbo!G0N2=}982v9pb_ZXok6U{!e*99?Y} z$;xsf$U at A)R5!j1<n9JgfpSNl^9Vtk-J1I~uaBRLB(P0a#g`4*i%79u9LT=%0T2Ew zL>zhG7w4{^;b-S=ZuqrnLQSm53tmbtPi3mN%VQ5_y`4|S)@1Zkd&g#<QmBI5Wp|?^ zt8E+8Ak0V*mhVztX!r`jn...