View Full Version : Second Public Beta Discussion Area
Luben Izov March 31st, 2010, 09:55 AM Hi Barry,
I haven't try that, but trying to figure it out why that would be the case. Would you be able to post a print out of your settings? Also, a wild question, but could be an issue... Do you use a proper SDI cable or a RCA with BNC connections?
Other thing to try is restore to factory settings, power off and than redo yours ones again
hope that helps you
cheers
David Rogers March 31st, 2010, 08:55 PM Mark, us older timers (flash XDR owners) continue to languish in the midst of all the young upstarts (Nanoflash owners). Oh well.
David
Scott Stoneback March 31st, 2010, 10:39 PM Shot today using the new release. I like the menu changes.
I did have trouble getting the CF Cards to properly format today. I had both cards in, initiated the formatting, but error came up saying CF2 was unknown card (or something like that). Pulled the cards, put Card 2 into CF1, leaving CF2 empty, and still had "CF2 Unknown card" error. Reformatted once more and all seemed fine.
Cards are Delkin 64Gbs and work great. The card originally in CF2 was used to redo the firmware. I had deleted the firmware file from the card, on my pc, before attempting to reformat in Nano.
Dan Keaton April 1st, 2010, 06:45 AM Dear Scott,
If you put your cards in the nanoFlash now, and attempt to format them, do you get the error, or has the problem gone away?
Please feel free to call our office, 720-221-3861, and our Support Manager will be happy to assist. This is a number to our Colorado Springs office.
Mark Job April 1st, 2010, 06:53 AM Mark, us older timers (flash XDR owners) continue to languish in the midst of all the young upstarts (Nanoflash owners). Oh well.
David...Hi David:
Yeah, I feel like an orphan :-( EDIT: That is, an orphan with nothing to test. No 2nd public beta for us :-(
Dan Keaton April 1st, 2010, 07:15 AM Dear David and Mark,
We had built a version, for release, for the Flash XDR and the nanoFlash on the same day.
Just before released both, our quality control testing found a problem with the Flash XDR version. So we did not release it. It could have been the other way around.
We are trying to find the problem then fix it.
Just as our Public Beta testers are testing the nanoFlash version, our quality control testers are testing it in our lab.
Mark Job April 1st, 2010, 07:37 AM Mark, us older timers (flash XDR owners) continue to languish in the midst of all the young upstarts (Nanoflash owners). Oh well.
David
Dear David and Mark,
We had built a version, for release, for the Flash XDR and the nanoFlash on the same day.
Just before released both, our quality control testing found a problem with the Flash XDR version. So we did not release it. It could have been the other way around.Hi Dan: Well, I'm certainly glad you folks at CD found the problem before releasing this beta-As opposed to us finding it instead, as you suggested. I'm hoping 24 F Jam-Sync and .MPG playback works flawlessly in the next beta release. I'm also hoping all general playback works perfectly, like it does on production release ver. 1.1.151. with all .mxf and .MOV files.
Andrew Stone April 1st, 2010, 09:07 AM I came across an odd problem recording in 720/30p on an EX3 the other day. The display on the nanoFlash showed it was recording in 720/60. Fine. I injested the material onto a Mac and dropped the first clip into the sequence in FCP to get the timeline to adjust to the parameters of the nanoFlash clip, as I usually do. Then I dropped in the remaining material, performed the edit, titling, transitions, no colour correction on this job as it was a quicky (but long) event video. Did a final render and then rendered (exported) out a ProRes version of the job to prep for Compressor. Threw the file into Compressor, crunched the material down for web delivery only to discover the video was exactly twice as long as the original video footage (you can see where I am going). Checked back in the timeline/sequence settings and noted that in the XDCAM EX 4:2:2 codec settings that 720/30p is not available.
Should we always be recording in camera at 720/60 when the end result we want is 720/30 and discard the duplicate frames in post or did I simply foul up somewhere?
EDIT:
I think I found some pertinent information on page 16 of the manual but please weigh in if you have some useful thoughts.
Scott Stoneback April 1st, 2010, 06:22 PM Dear Scott,
If you put your cards in the nanoFlash now, and attempt to format them, do you get the error, or has the problem gone away?
Please feel free to call our office, 720-221-3861, and our Support Manager will be happy to assist. This is a number to our Colorado Springs office.
The cards seemed to format fine today. I am guessing the hiccup was related to the card having been used during the firmware update.
Still have audio sync problems... the audio is several frames ahead of the video during playback.
Dan Keaton April 2nd, 2010, 04:40 AM Dear Scott,
As we have documented in our Release Notes for 1.5.126, the audio/video sync is 2 frames off, when playing pack via the nanoFlash, but not the files themselves are ok.
Thus, when you edit the files, the audio/video sync should be ok.
This is a technical hurdle we are trying to overcome. We are working on it.
Scott Stoneback April 3rd, 2010, 04:24 PM I understood that the audio would be off on playback with the Nano. That doesn't concern me so much. However, I am also seeing audio sync problems on playback from the card (and copied files) on the Sony MXF viewing software, running on a PC laptop. That leads me to believe that the audio is not synched at all...
Also, it is definitely more than just two frames. By my estimate, the audio is at least 5 frames ahead of the video.
Unfortunately, I can't test with Final Cut (or Avid). Back home, I am running Final Cut 5 on a Mac, and don't have the codec support on the old version. I am not going to buy the separate codec for viewing on a Mac... (Yes, I know, I need to upgrade FCP but I don't edit on this machine, it hasn't been a problem until I got the Nano!). Besides, I am out of town on a shoot, so that is moot.
I reported this problem in a separate thread:
http://www.dvinfo.net/forum/convergent-design-nanoflash/475867-audio-sync-issue-playback.html
BTW, I am in Ft. Collins... just a bit too far away to stop by your office and pester you in person!
Dan Keaton April 3rd, 2010, 07:08 PM Dear Scott,
We attempt to take all reports of problems seriously.
As far as I know, you are the first to report that the audio, when played back in an editor or the Sony CLip Viewer Software, is out of sync.
Could you please share your setup and your menu settings so we can attempt to duplicate your testing conditions?
Are you using HDMI or HD-SDI?
What camera are you using?
Are you recording Long-GOP or I-Frame Only?
Are you recording MOV, MXF or MPG?
Is Prerecord buffer on?
What is the frame rate in the camera?
What frame rate shows on the front of the nanoFlash.
Is Video|Reocord PSF>Prog checked?
Is Pulldown Removal Checked?
Have you tested with a clapper, or clapping your hands?
Edit: I have found some of the above questions answered in your other thread.
Can you test using 1080i60 (59.94)? I see in your other thread that you are using 1080i50.
Tom Roper April 3rd, 2010, 08:03 PM 1.) Dan, the link below takes you to the free Sony MXF XDCAM viewer.
https://servicesplus.us.sony.biz/sony-software-model-PDZVX10.aspx
2.) It is the best mxf viewer I have used, but really pushes my pc resources. There is a Sony disclaimer about possible playback issues with it, depending on if directx9 is used or the alternative rendering codec, plus your graphics adapter.
3.) I am a relative newbie to the nano, and most of my time has been spent with the 1st public beta. Although I have noted an audio (out of) sync issue with the Sony MXF XDCAM viewer, I have chalked it up to limitation of my pc.
4.) When I edit and render mxf 100 mbps nano files with Sony Vegas for playback on Blu-ray, the audio from the 1st public beta has always been in sync.
5.) I have only today updated to the 2nd public beta so I can't really add anything yet, except I haven't had any issues with the way I was using the 1st public beta except as noted in 2.) and 3.) above.
I know this doesn't help much, except CD should take on the testing with the Sony MXF XDCAM viewer software and perhaps you can take a disclaimer, because I'm not sure I would trust it in the role of being the reliability standard.
If I am wrong, and there really is an audio sync problem in the edited footage, I will be deeply disappointed because that's about as important as it gets. But my limited experience so far with the 1st public beta, has been NO audio sync problem with the edited footage.
I only shoot 100 mbps MXF long GOP, and only 1080/59.94i or 1080/23.98p, E to E audio.
And that just could be the question (and possible issue) for Scott, is the audio the embedded audio or from the analog input?
Also have only used nano with the Sony PMW350.
Scott Stoneback April 3rd, 2010, 10:26 PM Dear Scott,
We attempt to take all reports of problems seriously.
As far as I know, you are the first to report that the audio, when played back in an editor or the Sony CLip Viewer Software, is out of sync.
Could you please share your setup and your menu settings so we can attempt to duplicate your testing conditions?
Can you test using 1080i60 (59.94)? I see in your other thread that you are using 1080i50.
I can't run any tests for a while. Here are the setting I am using:
Panasonic HDX900
HDSDI
1080/50Hz
50fps interlaced
MXF codec
50Mbs
Delkin 64Gb cards
Nano Firmware was 1.1.154 but on day three I switched to 1.5.126 (problem still there)
Tom, you mention that there are disclaimers about the Sony software... I am hoping the problem is with the software, obviously. I suspected that the PC I am using could be at fault but I also figured the clips would just play poorly/jittery (not out of audio sync). By the way, on the PC they do playback jittery but also with poor audio sync.
It could be that I am getting two playback systems that are not working well (the Nano and the Sony Viewer). However, since two systems are giving me equally bad playback, and I can't check on any other system, I am stuck wondering where the problem lies....
Also, Tom, I am using embedded audio out of the HD SDI feed from the camera. I am not using the Nano's cache record, just recording live stream. Also, I do not have the E to E checked, from what I can tell, E to E would not affect recording.
I will say this. If the audio is fine in edit... I will be a happy man! I agree, Tom, the Sony MXF viewer might need a closer look from CD. Your posting that the viewer has issues with playback is the first I have seen.
Dan Keaton April 4th, 2010, 01:28 AM Dear Tom and Scott,
We use and recommend the Sony Clip Viewer software, version 2.30. In fact, we have a link on our website so users can download this software.
While we use the Sony Clip Viewer software, we use other Non-Linear Editors (NLE's), such as Final Cut Pro, Edius, Sony Vegas, and others to check audio/video sync.
To the best of my knowledge, the Sony Clip Viewer does not allow one to see an audio waveform. For sync testing, we find the exact frame that creates the sound, then check the audio waveform. (And we use other techniques).
Tom, we recommend that you use our Second Public Beta.
Great emphasis, and lots have audio/video sync testing, has gone into our Second Public Beta, 1.5.126.
We know that in playback from the nanoFlash, the audio is two frames out. This is noted in our release notes and we are working to resolve this. But this does not affect the actual recording, or playback in a PC or a Mac.
Scott, the only thing that is unusual about your recordings, that may have gotten past our testing, is that you are recording 1080i50 and not 1080i59.94 (frequently called 1080i60)
In our lab, we have one camera that can put out 1080i50 but it does not put out audio.
Our Sony EX3 may also put out 1080i50, but I have not personally researched this.
Thus, we could have a problem with 1080i50 audio/video sync.
Please note that I do not have the list of frame rates, modes, variations, etc. that we have tested. Thus, I can not confirmed that we have, or have not tested this format, which is popular in many parts of the world.
At this moment, I have no other reports of audio/video sync issues. We have quite a few reports that the sync is fine with our 1.5.126 from various parts of the world.
As of last Wednesday, our 1.5.126 had been downloaded over 250 times. We assume that if someone does download the firmware, then they have probably updated their nanoFlash or nanoFlashes. Of these, many have performed serious audio/video sync tests with their setup. We have been seeing an average of about 100 or so downloads of 1.5.126 a day.
Scott, we will run sync tests, in our lab, as soon as possible. It will greatly help us if you can provide us with your exact setup. Please provide us all of the nanoFlash menu settings, so we can duplicate your setup. We do not have an HDX900 in our lab, but this is a very popular camera with out nanoFlash users.
Specifically Video|Record PSF>Prog, Pulldown Removal, whether you are using Embedded Audio or Analog Audio, etc. are important to us so we can duplicate your setup.
From your last post, I feel that you have
Video|Record PSF>Prog unchecked,
Pulldown Removal unchecked,
E to E unchecked
Lance Librandi April 4th, 2010, 05:16 AM Hello Dan,
I have just tested my EX3 with the NanoFlash with the Second Public Beta, 1.5.126. Using a clapper Board recording 1080i/50 Mpg Long Gop /I-frame and MXF audio appears sync. I have noticed that in MXF that the end of the file is constantly Clipped with the last 10 seconds of the recoding missing. I did wait for the card activity light to turn green and then waited a further 5 sec just in case.
Doing the same exercise in Mpg 100 Mbps Long gop and I-frame everything recorded ok and no clipped files. Using a stopwatch I was able to determine that the save process clips the last 10 sec of the recording. This is not an issue for me as I only record in QT.
Dan Keaton April 4th, 2010, 08:10 AM Dear Lance,
Thank you for posting your results.
We spent quite a lot of time ensuring that the audio is in sync.
From your post, it appears that you attempted to duplicate Scott's setup (but using an EX3 as opposed to a HDX900), 1080i50 MXF, and found the audio, in the files, to be in sync.
I will alert our engineers to your findings about the clipping of the last 10 seconds.
I do not know how long it takes us to finish a recording. It may not be obvious, but we have to write an index to all of the frames in the clip for QT and MXF, and this can be up to 2 megabytes of data that we have to write out.
Dave Sperling April 4th, 2010, 11:38 AM Scott,
If you want to do a better sync check of your footage and are using a PC, why don't you download a free demo version of Sony Vegas that runs for 30 days. Even if your processor is slow, vegas allows you to reduce the resolution on your viewing area to give you smooth playback, even on a single core chip.
In my experience, when playing back using MXF player, you may experience problems if your system doesn't meet the minimum requirements for the software - ie processor speed, RAM, HD speed and graphics card- since MXF player attempts to play back at full res. Given a fast machine and full HD monitor, the results coming off the player are stunning. I've found that running MXF Player my current notebook (Vista 32bit, Core2 2.0Ghz, nVidia card, 4GB ram, 2 years old) plays back 35Mb footage perfectly, but starts hiccupping with 50Mb 4:2:2 footage. Of course all available formats look incredible at full 1920/1080 4:2:2 using MXF viewer on my Alienware Windows7/64 desktop, with never a hiccup or lost frame.
Lance Librandi April 4th, 2010, 05:05 PM Hello Dan,
I love to be able to use MPG file format for DVD/Blu-ray production on the NanoFlash but we still have a 4-5 frames audio sync issue. Do you have any idea when this may be addressed.
Many Thanks
Dan Keaton April 4th, 2010, 06:50 PM Dear Lance,
I thought we had achieved audio/video sync with our MPG option.
We will check on this in our lab.
Lance Librandi April 4th, 2010, 08:19 PM Dear Dan,
Thanks very much for that I have been waiting to see if the MPG sync had been fixed in this build my test last night indicated we still have a 4 frames discrepancy. I also tested CD FileConverter V1.1 which now writes to the CF cards ok but the audio on playback is also out of sync by 4 frames leading me to believe that it is a firmware issue in the NanoFlash.
Many thanks
Scott Stoneback April 4th, 2010, 09:12 PM Dear Tom and Scott,
We use and recommend the Sony Clip Viewer software, version 2.30. In fact, we have a link on our website so users can download this software.
While we use the Sony Clip Viewer software, we use other Non-Linear Editors (NLE's), such as Final Cut Pro, Edius, Sony Vegas, and others to check audio/video sync.
To the best of my knowledge, the Sony Clip Viewer does not allow one to see an audio waveform. For sync testing, we find the exact frame that creates the sound, then check the audio waveform. (And we use other techniques).
Tom, we recommend that you use our Second Public Beta.
Great emphasis, and lots have audio/video sync testing, has gone into our Second Public Beta, 1.5.126.
We know that in playback from the nanoFlash, the audio is two frames out. This is noted in our release notes and we are working to resolve this. But this does not affect the actual recording, or playback in a PC or a Mac.
Scott, the only thing that is unusual about your recordings, that may have gotten past our testing, is that you are recording 1080i50 and not 1080i59.94 (frequently called 1080i60)
In our lab, we have one camera that can put out 1080i50 but it does not put out audio.
Our Sony EX3 may also put out 1080i50, but I have not personally researched this.
Thus, we could have a problem with 1080i50 audio/video sync.
Please note that I do not have the list of frame rates, modes, variations, etc. that we have tested. Thus, I can not confirmed that we have, or have not tested this format, which is popular in many parts of the world.
At this moment, I have no other reports of audio/video sync issues. We have quite a few reports that the sync is fine with our 1.5.126 from various parts of the world.
As of last Wednesday, our 1.5.126 had been downloaded over 250 times. We assume that if someone does download the firmware, then they have probably updated their nanoFlash or nanoFlashes. Of these, many have performed serious audio/video sync tests with their setup. We have been seeing an average of about 100 or so downloads of 1.5.126 a day.
Scott, we will run sync tests, in our lab, as soon as possible. It will greatly help us if you can provide us with your exact setup. Please provide us all of the nanoFlash menu settings, so we can duplicate your setup. We do not have an HDX900 in our lab, but this is a very popular camera with out nanoFlash users.
Specifically Video|Record PSF>Prog, Pulldown Removal, whether you are using Embedded Audio or Analog Audio, etc. are important to us so we can duplicate your setup.
From your last post, I feel that you have
Video|Record PSF>Prog unchecked,
Pulldown Removal unchecked,
E to E unchecked
Hi Dan,
Here are the specs I've been using:
Panasonic HDX900
HDSDI
1080/50Hz
50fps interlaced
MXF codec
50Mbs
Delkin 64Gb cards
Nano Firmware was 1.1.154 but on day three I switched to 1.5.126 (problem still there)
Embedded Audio
Video|Record PSF>Prog unchecked,
Pulldown Removal unchecked,
E to E unchecked
Scott Stoneback April 4th, 2010, 09:13 PM Hello Dan,
I have just tested my EX3 with the NanoFlash with the Second Public Beta, 1.5.126. Using a clapper Board recording 1080i/50 Mpg Long Gop /I-frame and MXF audio appears sync. I have noticed that in MXF that the end of the file is constantly Clipped with the last 10 seconds of the recoding missing. I did wait for the card activity light to turn green and then waited a further 5 sec just in case.
Doing the same exercise in Mpg 100 Mbps Long gop and I-frame everything recorded ok and no clipped files. Using a stopwatch I was able to determine that the save process clips the last 10 sec of the recording. This is not an issue for me as I only record in QT.
Holy cr*p! I have to check for that.
Lance Librandi April 5th, 2010, 03:00 AM 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.
Dan Keaton April 5th, 2010, 06:39 AM Dear Lance,
Thanks for the update. We appreciate you letting us know.
Scott Stoneback April 5th, 2010, 10:10 AM 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 April 5th, 2010, 08:20 PM 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 April 5th, 2010, 10:18 PM Hi Mike & Dan:
Can us XDR users expect the 2nd public beta for us any time soon ?
Dan Keaton April 6th, 2010, 04:27 AM Dear Mark,
To the best of my knowledge, yes.
Stay tuned today.
Luben Izov April 6th, 2010, 05:39 PM 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/nanoFlash/nanoFlash_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 April 7th, 2010, 08:03 AM 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 April 7th, 2010, 08:15 AM 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 April 7th, 2010, 07:12 PM 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 April 8th, 2010, 10:26 AM 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-hd-720-1080-acquisition/74873-24p-time-code.html
Some reference material
Digital Cinema Society - (http://www.digitalcinemasociety.org/TechTips.php?item=24p+TC+%26+HD)
Mark Job April 8th, 2010, 11:05 PM Dear Mark,
Are you using Drop Frame or Non-Drop Frame in your XL H1 and Flash XDR?
http://www.dvinfo.net/forum/general-hd-720-1080-acquisition/74873-24p-time-code.html
Some reference material
Digital Cinema Society - (http://www.digitalcinemasociety.org/TechTips.php?item=24p+TC+%26+HD)...Hi Dan. I'm using drop frame TC in both camera and XDR.
Mark Job April 9th, 2010, 10:28 PM 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 April 9th, 2010, 11:39 PM 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 April 10th, 2010, 08:01 PM 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 April 10th, 2010, 08:21 PM Dear Mark,
We appreciate the thorough, independent, testing that you do.
Mark Job April 10th, 2010, 10:04 PM Hi Dan:
Like you, I too want to make the Flash XDR the best product it can possibly be :-)
Mark Job April 11th, 2010, 05:17 PM 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)
Dan Keaton April 12th, 2010, 07:37 AM Dear Mark,
I am very surprised at this.
We will check it out.
Chris Atebr April 13th, 2010, 03:51 AM 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.
Robin Probyn April 13th, 2010, 05:41 AM I think thats what they do??? and then send an email when its for production use .. down loaded off the site..
Bob Griffiths April 13th, 2010, 11:17 AM Is it just me that finds it astonishing that firmware upgrades are released as 'beta' ?
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¢...
|
|