The 9/11 Forum

OneWhiteEye wrote:Notice how no one has even mentioned PM'ing the principal to come here and argue the point?

I sourced the video link from him directly, so he knows I'm doing the tracing I'm sure...

femr2 wrote:...gives us/me a "live" example to test the trace methods on, and given the issues that have arisen, can't fail to increase understanding and correct application of 'em.

So true. I appreciate your note above about WTC7. Sometimes it is acceptable and even necessary to draw the line on certain activities and follow the higher guiding principles - sometimes peril IS the outcome of a perilous adventure. But it's wrong to evolve a universal maxim about motion analysis from (even YT) video being wholly unreliable, as many naysayers have. Results from decent video and context cannot be lumped in with results from shit as input.

This raises a peripheral issue which comes up again and again. All highly credible objections to the physical possibility of what is claimed aside, just deriving acceleration under these conditions would at the least require the level of effort you've put in to establish any confidence in the result. You put the effort in and still don't have confidence. If this were a non-controversial claim, such as variance from a=0 to a=0.6g, would the process undergo as much scrutiny?

The answer is it should. That's one lesson to take away.

Make the claim VERY controversial, then what sort of diligence is required? Technically, no more, but practically much more. There is no way this is a propulsive phenomena. A casual look at information available in Chandler's video wasn't conclusive, so I ran with it as far as his 'input' would allow. After looking at the excerpt gifs, other angles, multiple measurements, and after investigating the mechanics - no way. This tells me that Chandler's process is transparently what it appears to be, a superficial and shoddily conducted analysis skewed by personal bias and presented with overweening attitude.

I sourced the video link from him directly, so he knows I'm doing the tracing I'm sure...

I suppose he doesn't care. I would. It could be said that you've corroborated an anomaly, to some degree, but that includes the process as a whole.

The first comment at 911Blogger:

Jon Cole wrote:
Well done David!

Objects falling faster than freefall are yet another physical impossibility with the official story.

Of course we can expect the debunkers to say: "Well if you average the downward motion of that 4 ton segment starting from the time when the tower was first built to Sept 11 2001, its downward acceleration is hardly noticeable and certainly not even close to freefall!"

Not to pick on Jon Cole, not at all, but this underscores how personal credibility works with an audience. Jon Cole uncritically accepts analysis from Chandler because Chandler is credible to him. I uncritically rejected it (ah, but before I first posted here from a more open-minded position) because of low credibility from prior analyses.

Example of past experience: Violation of Newton's 3rd law? No. Time- or distance-averaged structural resistive force is expected to be well under static load in the best of circumstances. It was not the best of circumstances. Plastic deformation attenuates jolts - period. Chandler's measurements to do this? Crude and obsolete at inception due to much better measurements already in the public domain. His conclusion? An example of very bad physics.

What's happened here? My previous assessment of credibility reinforced. As well as Jon Cole's!

OneWhiteEye wrote:It could be said that you've corroborated an anomaly, to some degree, but that includes the process as a whole.

I think it's that "human element" I mentioned earlier.

Because of the nature of "the blob" (in that is not a fixed shape, like a building corner) it cannot be traced correctly by automated methods. For trace such as those for WTC7, I place the start point, and the software tracks it. Simple as that. Chuck 2 hours of 3GHz processing time at a 10x10 pixel region and it's possible to verify that sub-pixel inter-frame positional accuracy is being maintained. Much better than me moving a cross-hair around going...yeah, that looks about right, no matter how far I'm zoomed in..

In this instance the blob changes from a small dark dot, to a white one (as lighting changes and dust trail begins in earnest) to a black end of a rotating line. No automated tracing. Subjective manual placement.

Not surprising that errors have arisen in that process. Couple of pixels out and the resultant acceleration spike can be huge, especially if that error is sustained. I think there's a point where, rather than actually following point A on the object, I end up (however dilligently I try not to) shifting to a slightly different location on the same object due to human interpretation of the visual info.


What a load of waffle, but you get what I mean.

The fallback is to realise that and throw out techniques which are suceptible to amplifying that human error so much.

I'm comfortable with the 3rd order poly fit to be honest.

Under-g.

Drinkin' time

OK. Well put and understood. Cheers!

femr2 wrote:I'm comfortable with the 3rd order poly fit to be honest.

Under-g.

Drinkin' time

LOL!

Femr2: btw you did indeed clarify it for me a little bit, thanks.

If I inject another sceptics view here....

Disclaimer - I would not expect anything Chandler claimed to be based on valid physics - so I am agin him to start.

As I see the situation femr2 has probably done as good as anyone in this trade could do and cannot "prove" over G. (I think that is slightly on the conservative side for safety.) Put that back into the context as one of two options.

1) Not "over G" raises no contentious issues.

2) Alternatively positing "over G" raises multiple hard to answer issues - bordering on the impossible.

Therefore "not over G" remains the hypothesis until somebody rebuts it???

Satisfies me. It's not an argument I would put into certain other forums despite the fact that it goes the way the 9/11 debunkers would want it to go.....which is why I wouldn't try deploying the argument there.

Hi guys,
my first post here, I'll simply restate some thoughts I already wrote over at JREF (Yep, that's where I hail from *duck*):

femr2 wrote:...
Here's the raw time(s)/drop(ft) data...

Code: Select all

   
0   0
0.016650017   -0.800169957
0.033300033   -3.037856652
0.04995005   -4.066957082
0.066600067   -4.950621459
0.083250083   -5.954365665
0.0999001   -8.82903691
0.116550117   -10.46252103
0.133200133   -12.03062232
0.14985015   -14.93916223
0.166500167   -16.7602824
0.183150183   -19.22671845
0.1998002   -20.08430215
0.216450216   -20.86074592
0.233100233   -23.85730815
0.24975025   -24.81178884
0.266400266   -28.0744103
0.283050283   -28.96622489
0.2997003   -33.14402489
0.316350316   -34.58932961
0.333000333   -35.48476652
0.34965035   -35.94407639
0.366300366   -38.54272704
0.382950383   -40.54604979
0.3996004   -42.95796996
0.416250416   -47.35437682
0.432900433   -48.04080601
0.44955045   -49.13710043
0.466200466   -51.78229785
0.482850483   -52.98056052
0.4995005   -53.90461373
0.516150516   -54.68757768
0.532800533   -57.90944807
0.549450549   -60.37135622
0.566100566   -61.94778884
0.582750583   -63.77724034
0.599400599   -65.85608841
0.616050616   -68.48733991
0.632700633   -71.25696395
0.649350649   -73.5511588
0.666000666   -74.59420515
0.682650683   -76.57452618
0.699300699   -78.25383262
0.715950716   -81.01856652
0.732600733   -81.2782867
0.749250749   -84.19189785
0.765900766   -87.13647983
0.782550783   -88.87863348
0.799200799   -91.24599914
0.815850816   -94.18442318
0.832500833   -96.64759914
0.849150849   -98.56923863
0.865800866   -100.6428343
0.882450882   -103.1279253
0.899100899   -105.7421519
0.915750916   -106.486176
0.932400932   -110.2349124
0.949050949   -113.1809433
0.965700966   -112.3340455
0.982350982   -112.0433545
0.999000999   -115.7730738
1.015651016   -117.8560876
1.032301032   -118.3838592
1.048951049   -122.367503
1.065601066   -122.6513116
1.082251082   -125.1282524
1.098901099   -128.4437597
1.115551116   -130.6146146
1.132201132   -132.6967227
1.148851149   -133.9554781
1.165501166   -136.8542378
1.182151182   -140.2229931
1.198801199   -141.95917
1.215451215   -142.8652927
1.232101232   -144.986703
1.248751249   -147.5485871
1.265401265   -148.4606867
1.282051282   -151.554327
1.298701299   -152.906176
1.315351315   -155.6623974
1.332001332   -157.7629794
1.348651349   -160.2667253
1.365301365   -162.1847425
1.381951382   -165.1021571
1.398601399   -168.3573528
1.415251415   -169.5012807
1.431901432   -171.3796335
1.448551449   -173.8786704
1.465201465   -176.1951425
1.481851482   -179.6705751
1.498501499   -183.0672223
1.515151515   -184.8073837
1.531801532   -187.1037519
1.548451548   -189.7038515
1.565101565   -191.8658318
1.581751582   -193.7101348
1.598401598   -195.4071906
1.615051615   -197.7394197
1.631701632   -199.5627133
1.648351648   -201.4019451
1.665001665   -204.6768824
1.681651682   -206.5208232
1.698301698   -213.4916112
1.714951715   -215.0066455
1.731601732   -216.2308077
1.748251748   -220.4290738
1.764901765   -221.5816953
1.781551782   -224.5043622
1.798201798   -227.8100893
1.814851815   -231.3568815
1.831501832   -232.1309708
1.848151848   -233.9290893
1.864801865   -234.8261562
1.881451881   -241.4615176
1.898101898   -243.3090807
1.914751915   -245.9367099
1.931401931   -246.7486524
1.948051948   -249.6068421
1.964701965   -252.7848824
1.981351981   -256.0886172
1.998001998   -259.0370026
2.014652015   -259.8634343
2.031302031   -262.4874412
2.047952048   -266.6549176
2.064602065   -267.190115
2.081252081   -268.6160403
2.097902098   -270.7609957
2.114552115   -274.067085
2.131202131   -276.5925648
2.147852148   -280.6057305
2.164502165   -282.747788
2.181152181   -285.1131614
2.197802198   -287.3729442
2.214452214   -292.077067
2.231102231   -292.8433682
2.247752248   -295.2543828
2.264402264   -299.2338609
2.281052281   -301.6068412
2.297702298   -304.9640052
2.314352314   -307.9218086
2.331002331   -309.7813253
2.347652348   -312.639515
2.364302364   -314.8174335
2.380952381   -319.2397399
2.397602398   -321.8657391
2.414252414   -323.7913631
2.430902431   -327.0762618
2.447552448   -327.6931425
2.464202464   -331.762273
2.480852481   -334.2283468
2.497502498   -339.1057974
2.514152514   -343.5474833
2.530802531   -344.5030506
2.547452547   -345.6275991
2.564102564   -347.1297742
2.580752581   -349.5221339
2.597402597   -352.4661725
2.614052614   -356.2822841
2.630702631   -357.0904232
2.647352647   -361.3486386
2.664002664   -364.139091
2.680652681   -367.3770807
2.697302697   -369.3967039
2.713952714   -374.056091
2.730602731   -376.1684455
2.747252747   -378.7545991
2.763902764   -381.4376498
2.780552781   -384.7446446
2.797202797   -386.5460232
2.813852814   -390.1096592
2.830502831   -393.8104
2.847152847   -395.6436549
2.863802864   -399.780885
2.88045288   -401.4681605
2.897102897   -406.7565631
2.913752914   -408.8517116
2.93040293   -411.9312249
2.947052947   -414.9828464
2.963702964   -418.2302541
2.98035298   -422.0595871
2.997002997   -424.060012
3.013653014   -426.4121639
3.03030303   -430.9445888
3.046953047   -434.9722438
3.063603064   -437.5035193
3.08025308   -439.8504189
3.096903097   -442.8391931
3.113553114   -445.7247313
3.13020313   -449.3207871
3.146853147   -452.4953863
3.163503164   -455.6587562
3.18015318   -458.5669339


If you plot it you'll see fair bit of noise that needs smoothing out before you go anywhere else.

It's also not far off linear so wild acceleration just seems like something is introducing a consistent error.

Ooh ya, pretty noisy! I have been playing around with this table a bit now, trying to compute local velocities, and average velocities and accelerations over various intervals, and it looks chaotic wherever I put my finger.
There seems to be an over-g period (on average) between roughly 1.42s and 2.0s. But it's hard to say if this is due to an effect that acted for several tenths of a second; I have a hunch that there may have been some discontinuity at 1.70s. Maybe a glitch in the video, maybe the object broke apart while rotating...

femr2 wrote:...
Ramping that up to a 3rd order poly fit and deriving to acceleration obviously gives a linear result, but interesting range...

...24.8ft/s^2 increasing to 27.5ft/s^2.

With an original displacement fit R2 of 0.99989974483148.

What to trust eh

You are not going to conclude from this that acceleration was <g throughout, right?
After all, as you hint, 3rd order poly will give a liner acceleration curve which maxes either at the beginning or the end of the period and would by design mask any real maximum in between. I'd think a 4th-order poly would give us a better idea of how acceleration changed.
I would NOT trust that ANY poly would give us a useful curve from which to deduct conclusions. We would miss discontinuities.


Also, I'd like for someone to estimate the possible effect of unknown parameters of the 3D-trajectory - mainly the initial distance from the tower wall, and the horizontal velocity towards the camera. I would not expect the latter to be constant.

Greetings Oystein.

Welcome, Oystein.

Oystein wrote:Hi guys,
my first post here, I'll simply restate some thoughts I already wrote over at JREF (Yep, that's where I hail from *duck*):

No worries, your only immediate concern is the heartworm, and that's relatively painless.

I have a hunch that there may have been some discontinuity at 1.70s. Maybe a glitch in the video, maybe the object broke apart while rotating...

femr2 mentions some discontinuities a bit earlier, and it does indeed look that way. The video is a hot mess, for sure.

You are not going to conclude from this that acceleration was <g throughout, right?

I know you're asking femr2, but as for me - no.

After all, as you hint, 3rd order poly will give a liner acceleration curve which maxes either at the beginning or the end of the period and would by design mask any real maximum in between. I'd think a 4th-order poly would give us a better idea of how acceleration changed.

Agreed. Maybe I'd rephrase that to say a better idea of how the apparent acceleration changed, something I'm sure you're aware of but an important distinction.

I would NOT trust that ANY poly would give us a useful curve from which to deduct conclusions. We would miss discontinuities.

If the discontinuities are artifact of some kind, which I believe they must surely be, the earlier interpolation from femr2 depicts them, or one version of them:



The low order polys were to try to tame the *$@^!, but your point is taken.

Also, I'd like for someone to estimate the possible effect of unknown parameters of the 3D-trajectory - mainly the initial distance from the tower wall, and the horizontal velocity towards the camera. I would not expect the latter to be constant.

Reasonable (to add to the list). So far, we've got human factors, time-varying orientation, lousy video, changing visual attributes and drift. There are a lot of things to make the two point constant scaling to standard length units go awry.

However, I'd ask you to consider that, among those factors, drift in the horizontal plane (or alternately towards/away from the camera along the optical axis) in isolation is not likely to exhibit the quasi-periodicity of the graph above. Not without some 'falling leaf' back and forth kind of motion. At least it seems that way to me. Change in aspect and reflectivity from rotation would seem to be chief suspect in a physically based artifact of this sort.

It might be best to drop back to the pixel domain for a universal error quantification in terms of angular measure.

Or do nothing!

(That was the mood, I think, by now. Sow's ears, unsurprisingly, make sow's ear purses.)

OneWhiteEye wrote:Or do nothing!

(That was the mood, I think, by now. Sow's ears, unsurprisingly, make sow's ear purses.)

Even better may be to dig up three year old work. Positional error from quick and dirty two point scaling versus real scaling. This is one specific example (a WTC7 video) of how a part of the process chain can introduce weirdness in the data. In this case, it puts a hump in the position data. As the post concludes, a rather insignificant hump in the position-time domain. Differentiate twice? Ah, that would be a hump. Geometry would dictate the magnitude and phase of the hump relative to the measurement interval, it needn't be like the WTC7 example.

That's one thing. Not saying it's a factor in this case, but of all the things at play, there's bound to be some mischief.

Oystein wrote:Ooh ya, pretty noisy! I have been playing around with this table a bit now, trying to compute local velocities, and average velocities and accelerations over various intervals, and it looks chaotic wherever I put my finger.

For sure. Heavy-handed smoothing is a must. I used up to 59 sample window Savitzky Golay smoothing at each derivation step, which resulted in the extreme acceleration in the early graph. So poly fitting was checked to look at the more general picture.

There seems to be an over-g period (on average) between roughly 1.42s and 2.0s. But it's hard to say if this is due to an effect that acted for several tenths of a second;

And it could easily be bad data. Manually tracking the blob is very awkward for several reasons. Will be trying to improve it, but...

I have a hunch that there may have been some discontinuity at 1.70s. Maybe a glitch in the video, maybe the object broke apart while rotating...

Not a video glitch. Not break up of the object.

You are not going to conclude from this that acceleration was <g throughout, right?

Right, but presenting the displacement graph and the closeness of fit to a simple low order poly indicates a fairly "ordinary" descent. A "real" sudden 1g increase in acceleration would show up. It doesn't, which suggests that the big spike in the early graph is erronious.

See discussion about "fudging" the data. To be done.

After all, as you hint, 3rd order poly will give a liner acceleration curve which maxes either at the beginning or the end of the period and would by design mask any real maximum in between.

Sure.

I'd think a 4th-order poly would give us a better idea of how acceleration changed.
I would NOT trust that ANY poly would give us a useful curve from which to deduct conclusions. We would miss discontinuities.

I can try up to order 16 in equation form, and up to order 50 in numerical form.

Also, I'd like for someone to estimate the possible effect of unknown parameters of the 3D-trajectory - mainly the initial distance from the tower wall, and the horizontal velocity towards the camera. I would not expect the latter to be constant.

Might look for a video from the East which might help...