Second Public Beta Discussion Area

[Scott Stoneback]

Originally Posted by Lance Librandi

Hello Dan and fellow NanoFlash users,
Please disregard my previous post 66 I contacted a local friend who also now has a NanoFlash and conducted the same test. He found that the last the last 10 sec of the recording is not missing and he is using a PC.
Well that got me thinking what is going on so I played the MXF file back from the NanoFlash via the SDI to my monitor and sure enough everything is there and nothing is missing.
Conlusion:
I am using FCP on my Mac Pro 10.6 Snow Leopard and it would appear that during that when importing the file Quicktime X is clipping the end of the file.

My humble apologies to all.

Hey Lance, April fools day was several days ago... !

*EDIT*
As far as the settings I have been using... I have a client from France that needed the 50Hz settings. Normally, I will be using the 60Hz settings for all jobs in North America.

The PC I was using to transfer files to a hard drive was definitely too slow to handle full res HD footage. It is a Centrino based laptop with likely 1 or 2Gb of RAM. Plus, it is reading through the USB ports (either from the external drive - Western Digital Passport Essential - or from the USB CF reader). Both of those have their limitations. I never expected to see clean playback on the PC, but I did not expect the audio to be out of sync. I expected skipping/jitters/etc, but it all to be in sync.

The Nano is really a great tool but the stress of using this is adding up! The learning curve is steep for the early adopters amongst us. Once this sound issue gets sorted, I am going to move on to learning the in's and out's of time lapse... more reading of manuals to come.

[Mike Schell]

Originally Posted by Scott Stoneback

Hey Lance, April fools day was several days ago... !

*EDIT*
As far as the settings I have been using... I have a client from France that needed the 50Hz settings. Normally, I will be using the 60Hz settings for all jobs in North America.

The PC I was using to transfer files to a hard drive was definitely too slow to handle full res HD footage. It is a Centrino based laptop with likely 1 or 2Gb of RAM. Plus, it is reading through the USB ports (either from the external drive - Western Digital Passport Essential - or from the USB CF reader). Both of those have their limitations. I never expected to see clean playback on the PC, but I did not expect the audio to be out of sync. I expected skipping/jitters/etc, but it all to be in sync.

The Nano is really a great tool but the stress of using this is adding up! The learning curve is steep for the early adopters amongst us. Once this sound issue gets sorted, I am going to move on to learning the in's and out's of time lapse... more reading of manuals to come.

Hi Scott-
We will double check the audio sync tomorrow using 60Hz and 50Hz rates. However, I could easily imagine A/V sync problems when using a slow computer. If you PC dropped video frames, but not audio frames, for example, you would immediately run into a sync issue.

We will double check tomorrow and try to report back quickly.

Best-

[Mark Job]

Hi Mike & Dan:
Can us XDR users expect the 2nd public beta for us any time soon ?

[Dan Keaton]

Dear Mark,

To the best of my knowledge, yes.

Stay tuned today.

[Luben Izov]

As per Tommy

"Hello,

After further testing, the nanoFlash beta release 1.5.126 is now a formal release for recording Quicktime (.MOV) or MXF files.
For recording .MPG files, due to small remaining bugs (only) in the .MPG file format please stay tuned for a near term release
with improved .MPG support.

If you are recording Quicktime or MXF files and have not already installed 1.5.126 (the formal release is the exact same as the beta release),
please do so at your convenience:

http://69.15.88.17/downloads/nanoFla...sh_1.5.126.zip


We will also be posting an updated version of the FileConverter tool (version 1.5) in the coming days to add support for 4 and 8 audio conversion."

Thank you CD
Luben

[Barry J. Weckesser]

Originally Posted by Dan Keaton

Dear Piotr,

I can assure you that we will not withdraw support for the PhotoFast cards.

The Second Public Beta has many improvements in how we work with CompactFlash cards.

Previously, we saw SlotDpc:0003 errors and some DMA errors.

One of the reasons that it took us so long between our First Public Beta and our Second Public Beta was to investigate these errors, determine the cause, fix the problem, then test the solution. We were able to duplicate the SlotDpc:0003 errors in our lab. Then, after we found and fixed the problem, we thoroughly tested the solution and we never saw the error again.

In other words, we have confidence in our solution to the problem.

We determined that some of these problems occured when coming out of Power Save mode.

Both the SlotDpc:0003 and DMA errors have been fixed.


If your two PhotoFast CompactFlassh cards are working with the Second Public Beta, then you are good.

The PhotoFast cards were removed for our list of qualified cards, temporarily, since there were a bad batch of cards. These were DOA cards.

As you may imagine, it reflects poorly on us if we recommend a card, then a customer gets cards just in time for his shoot, and they turn out to be DOA.

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?

[Dan Keaton]

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.

[Mark Job]

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 ?

[Dan Keaton]

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 -

[Mark Job]

Originally Posted by Dan Keaton

Dear Mark,
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.

[Mark Job]

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)

[Dan Keaton]

Dear Mark,

We will be looking into the Jam-Sync.

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

[Mark Job]

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.

[Dan Keaton]

Dear Mark,

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

[Mark Job]

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