It looks as though photofast is not mentioned as approved in the final version of the new beta software- version 1.5.126 - is this going to be permanent?

Dear Barry,

We hope that this will not be permanent. It is to our advantage to support as many popular and reliable CompactFlash cards as possible.

If you have PhotoFast cards and they are working fine, then please feel free to continue using them.

One of our premiere dealers received a bad batch of cards. Some were shipped to customers and then had to be shipped back. Others were found by the dealer, since he started testing each and every card to be safe.

XDR 2nd Public Beta: Canon 24 F Jam-Sync Test
 

Hi Tommy,Mike, Dan:
In a 2:45 minute Jam-Sync @ 23.976 (Canon 24 F) run, there is now only a 6 second drift. I think you folks are moving in the Right direction with improving your accuracy. Each time there is less and less of a *drift.* In my test criteria and setup, I have questioned my method of testing, in that there should be 3 clocks, with the third clock acting as the *MASTER* clock, then the XL H1, then the Flash XDR.

In my test setup I am only using 2 clocks with the Canon XL H1 acting as the master from which I am jamming, then the XDR as the so called *Jammed (Time Synced) device. The question which arises for me, is what if the XDR is got a really accurate time code generator and my Canon camera is running too fast. With each test it is my camera which always seems to be the faster clock. Perhaps it is the XDR which runs too slow ??

**Now here's what really cooks my noodle ! If I perform this test running the XDR and Canon XL H1 @ 59.94i, then neither clock drifts ! What the ???

*** If I have truly introduced an unknowable variable by not using a *Master* reference clock, then should I not get a drift in 59.94i as well ?

****Or is it that my XL H1 and XDR clocks are really, really, and truly accurate and its the pull down removal which is at fault ?

Dear Mark,

Yes, unless you have a third, very precise master clock, you can not tell which is more accurate. I would trust an Ambient Timecode Slate, or a Sound Devices 744T or other T model as they have Ambient timecode clocks built in.

Cameras are not known for ultra-precise timekeeping.

It does appear very interesting that the Flash XDR and your XL H1 are still in sync (after an undisclosed amount of time).

If the clock in the XL H1 and Flash XDR are in perfect sync, then either device may be handling timecode improperly in 24p mode.

Common practice with jam-syncing is to jam sync whenever possible.

Are you using Drop Frame or Non-Drop Frame in your XL H1 and Flash XDR?

http://www.dvinfo.net/forum/general-...time-code.html

Some reference material

Digital Cinema Society -

...Hi Dan. I'm using drop frame TC in both camera and XDR.

More XDR 2nd Public Beta Test Results
 

Hi Dan:
Even though I do not have a third TC generator acting as my master, Jam-Synching 59.94i DF yields perfect sync (Read no visually discernible drift between XDR and XL H1 TC readouts.)

* Playback of long form video in .MXF 50 Mbps mode looks sharp, sounds normal, and there is no audio screeches, pops, or clicks. (Moving on to .MOV file recording and playback testing now - will also test .MPG mode for same)

Dear Mark,

We will be looking into the Jam-Sync.

We still have some issues with ".MPG" mode that we will be addressing.

Flash XDR 2nd Pub Beta Test Results: .MOV QT (Long GOP)
 

Hi Dan:
Test results for recording in QT. MOV file format are as follows so far.....

First, I am recording to .MOV using the Long GOP compression codec scheme @ 180 Mbps. The results are smooth with clear playback and no blockiness or blurriness. There is also no audio anomalies detected thus far in my analysis.

*I will now move onto QT .MOV recording using the I-Frame codec scheme setting @ 220 & 280 Mbps to see how playback looks and sounds.

Dear Mark,

We appreciate the thorough, independent, testing that you do.

Thank You :-)
 

Hi Dan:
Like you, I too want to make the Flash XDR the best product it can possibly be :-)

Flash XDR 2nd Public Beta QT.MOV I-Frame Recording Test Results
 

Hi Dan:
Very disappointing results were obtained from the second public XDR beta when I attempted Quicktime .MOV file recording using I-Frame codec scheme instead of Long GOP 180 Mbps. When recording files for QT .MOV using the I-Frame recording scheme @ 220 Mbps the resulting playback yielded.....

A) No Sound ! (I'm testing this further to be sure)
B) Glitchy, unsteady video, which breaks up and turns green !
C) Audio popping, screeching, and clicking !

I can confirm I had good audio during recording with proper VU meter modulation indication within proper limits for good 48 KHz 24 bit audio recording. I will re-test these results once again to confirm wether I can re-produce these anomalies. * CF Card playback via USB 2.0 reader in my iMAC yielded excellent playback picture quality but no audio signal. (Actually a loud hiss could be heard)

Dear Mark,

I am very surprised at this.

We will check it out.

why post beta XDR upgrades
 

Is it just me that finds it astonishing that firmware upgrades are released as 'beta' ?

Beta is industry code for ' we're not sure if it works but give it a go anyway'.
1.5.25 was released with the advise that it was used for 'non production purposes' !!! what on earth else would I use it for?
I'm still on 1.1.151 as this was the last non beta available, sorry guys but I don't know any professional camera operators that will load a beta upgrade and then go out on a job!
May I suggest that if you want to release a beta upgrade then send it to a small group of trusted XDR owners, I'm sure there are some on here who would be willing to put it thorugh its paces and report back, then, and only then should you release it for everyone else.

I think thats what they do??? and then send an email when its for production use .. down loaded off the site..

Chris,

This was done at the request of most of the nano and XDR users. CD has been VERY explicit that the beta releases are just for testing purposes. IMHO, this is a great program and allows users to play with near final versions of the upcoming release to help improve it. CD is extraordinarily responsive to user input and works hard to incorporate their input. It's a great community effort. CD's "customer service" even exceeds the much touted customer service that AJA has... and that's pretty amazing too.

Look above in this post. Mark Job is an XDR user and diligent tester. His efforts help improve the firmware for both XDR and nano users. Sure, CD could just send it out to a small group of testers but that limits the system/camera permutations that might catch a problem.

You are correct... most camera ops would not work with beta software in the field. What I do with my nano is load the beta software, play around with it and then reload the most recent "approved" version back onto the nano when I have a shoot.

My 2¢...