Dear Friends,

As we are finishing the testing of the Flash XDR release, I thought it would be helpful for us to post this list of release notes for the upcoming release.

(These notes are subject to change as we may add some more features.
The Release Version and Release Date are not yet finalized.)

Flash XDR Release Notes Release Version 1.5.86 (Oct - 2010 )

o Fixed green frame bug at beginning of long-Gop MXF files when brought into Sony Vegas.

o Added timecode trigger delay (System->Timecode->Trigger Delay), in number of seconds.

When used in combination with “Timecode” trigger or “TC > Last TC” trigger (System->Trigger),
Flash XDR will delay start of record the specified number of seconds in the Trigger Delay.
This feature is beneficial to better match the timecode of some tape-based cameras,
which can shift the camera timecode unexpectedly at the beginning of camera record.

This feature also helps to prevent the Flash XDR from creating very small files in Timecode trigger mode if the camera is shifting it's timecode around while ejecting / inserting media.

o SD Aspect Ratio (Video->SD Aspect Ratio) fixed. In earlier versions, this was not always being applied correctly to files.

o Added lock-out of drop-frame timecode in 720p24 mode. ( In some NLE's, drop-frame timecode is not allowed in 720p24 mode. )

o Fixed timecode bug in 720p24 mode with pulldown removal. Timecode was getting inadvertently doubled in this mode, but is now correct.

o LTC timecode accuracy improved.

o Improved MPG support.

o Added ability to create new file during record by pressing Record button while in Timecode Trigger mode. (This method was previously available only with Record button as the Record trigger (System->Trigger) ).

o Fixed compatibility with newer Delkin CF cards 420x and 450x.

o Avid has added AMA compatibility, “Link to AMA Files”, for Flash XDR MXF files.
Allows access of files within Avid without having to import (copy in) the files.
Requires Avid Patch 5.0.3.2 .

o Added Vertical image flip (Video->Flip V) and Horizontal image flip (Video->Flip H) options for flipping images as desired from camera outputs in which the camera lens produces an inverted image.

o Fixed bug in Crank mode, in which during long records, all files after the 1st file would not use the cranked rate properly.

o Fixed Remote trigger bug introduced in 1.5.249 beta, in which file corruption could occur when using Remote trigger option.

o Corrected errant “Intermittent Source” which appeared on Flash XDR especially in 720p mode from cameras such as the Panasonic HDX900 during record, and would cause some seconds' loss of footage.

o Repaired playback from Flash XDR of Standard Def, timecode and audio are now properly played back.

o Changed menu option to select File Format (in the System menu) : the option is now under “File= “ (also in the System menu. Scroll to the far right (using right arrow) of the “ File= “ menu option to set the file format: .MOV, .MXF, or .MPG . The explicit “File Format” option has been removed.

o Improved reliability in .MPG file format.

o Eliminated rare horizontally shifted video in 1080p25 recordings.

o Fixed audio / video sync during playback from Flash XDR.

o Changed Standard Def IMX (MXF files), number of audio channels from 8 channel 16 bit to 4 channel 24 bit (with only the 1st 2 channels actually used). The IMX specification requires one of the 2 above mentioned options, the 2nd option is now used to support 24 bit audio.

o Fixed bug in 8 channel audio, HD MXF recordings, which improves compatibility with Edius.

o Added Screen Tally option (Video->Screen Tally), which places a red bar on the output to indicate unit is recording.

Video->E to E must be turned on for Screen Tally to work correctly.

o Turned off “Read Only” status for all recorded files.

o Creation Time / Date is now correctly stored in .MXF files.

o Corrected bug which blocked recording after “No Last Clip” message.

o Changed “Unit ID” in System menu to “File=”, which allows user to set the 1st 2 digits / characters of the file name as before (formerly the Unit ID), and additionally the next 3 digits (the clip number). Take care to avoid duplicate file names on the same CF card.

Known issues (1.5.86):

o 720p24 / 25 / 30 playback from the Flash XDR is not supported at this time.

o Pulldown removal from JVC 700 requires turning the Flash XDR on 1st, then the camera, to work properly.

o Avid Media Composer: does not support Long-Gop MXF files 100 Mbit and above.
(All I-Frame files, all bit rates are supported.)

Avid Media Composer Does not support any 720p24/25/30 files at 50 Mbit and above.

Hi Dan:
Good to see many fixes included in this latest update. I have a few questions about other fixes not listed. Such as........

1. Jam-Sync drift error when using 1080 24 F 3:2 pull down removal.
2. Menu character screen size: Enlarging characters including little hour glass at least three sizes larger.
3. Playback glitching in 1080 playback. (Intermittent audio disappearing or screeching and popping) Sometimes you have to press play and stop and play again up to 3 times before normal playback condition resumes.
4. Intermittent Playback Time Code display.

What is the status of these repairs ? Playback from the XDR is a must to show director last take.

Dear Mark,

When producing a new release, one of the hardest things to do is to keep track of all of the fixes, changes, and improvements.

I will check on the items in your list.

Item 1, I do not know the status of this condition.

Item 2, your request, has not been done. You requested this after we had already started testing this release.

I do not see how we can increase the size of the characters and still keep the same number of lines. Maybe you see something that I do not see.

We have not yet discussed your recent request to make the hourglass bigger. I like the idea.

Item 3, I do not think you will find this in this release.

Item 4, Intermittent Timecode display may be linked to us putting out an error message in the same space on the LCD. On the nanoFlash I know that we put out "No Timecode" which does not really have any meaning during playback, as no camera is required to be present.

Hi Dan:
OK. Understood. I was wondering if the larger hour glass thingy and the now present Monitor Record Bar feature would be enough ? I can't really think of any other feature to stuff in the XDR other than the ones I already have constantly harped on ! ;-) Can you ? Maybe hot swopping the cards, but with 4 slots and 64 GB approved CF cards (128 GB on the way soon), I don't see a big need for that, but it would be nice if you have a whole bunch of low capacity cards and want to use them on long interviews and public speakers. Hey can you turn on the Fire Wire socket ? If you could download or Avid AMA your XDR files without having to unplug them from the XDR, then you save big time having all those extra insertions and ejections of the CF media. (less wear and tear on the unit itself and increasing clip downloading in the field versus using the USB 2.0 reader)

Dear Mark,

We had not put out a Flash XDR release for quite some time due to other projects that we were working on.

So, we concentrated on the Flash XDR to get a release ready.

Thus, we started our testing, then tried to get everything perfect. If we found a problem, we fixed it.

During this repetitive process, we were also working on other things. But, we froze the Flash XDR so as to not introduce new problems which would delay the release.

We never planned on using the 4-Pin Firewire socket on the Flash XDR to perform file transfers to a computer.

Hi Dan:
I figured that since it's there, then why not use it ? Is it complicated to turn that socket on ? Does it require some sort of special programming ?

Dear Mark,

Yes, it is a major project to emulate / support all of the commands sent by a computer in the mode that you are requesting.

You are requesting that the Flash XDR emulate four disk drives and handle all of the commands that a Firewire connected disk drive supports.

Hi Dan:
OK. I was just thinking of data download from the CF cards. But I don't know what kind of emulation routines have to run for that. (??) If you folks at CD want to make that a paid upgrade for those Nano/XDR users who might want that, then I don't mind. I would pay to have that.

To add to what Dan says:

1) using jam-sync with pulldown removal is a bit of a messy combination, involving 2 different timebases (29.97 for the original signal, 23.98 for the jam sync), this may not be any better in the new firmware.

4) I believe the intermittent blinking "no timecode" message during playback is fixed.

Tommy

To add to what Dan says:

1) using jam-sync with pulldown removal is a bit of a messy combination, involving 2 different timebases (29.97 for the original signal, 23.98 for the jam sync), this may not be any better in the new firmware......I was wondering about this myself. First, you are asking the on board computer to calculate 3:2 pull down removal in realtime 24 over 59.94i, then you are asking that *corrected* 24p stream to remain in synchronization with a constant TIME CODE reference. I am guessing here that the 3:2 pull down removal process is slowing down the jam-sync ? Is there any way to circumvent this effect ? (If indeed my premise is correct) (??)

4) I believe the intermittent blinking "no timecode" message during playback is fixed.

Tommy ....Oh thank you Tommy :-) ! This blinking TC display was practically giving me seizures !

Are we in for this XDR firmware release this week?

Dear John,

I am sorry, but no.

In our quality control testing, we found some problems.

We made a new build yesterday and it is in test again today.

Thanks Dan.

Better to have it rock solid stable. Thanks for the deep testing.

Dear John,

We greatly appreciate your patience and understanding.

Thanks Dan.

Better to have it rock solid stable. Thanks for the deep testing.....Hi John & Dan:
Yes. I too second this. It is better to wait longer and have *STABILITY* and *RELIABILITY* in a release. I care more about these two aspects than any other feature :-) I am using my XDR on a major paying TV documentary production right now.

Hi Dan & Tommy:
Can I get an update on what's happening with the latest firmware update release please ?

Dear Mark,

We are striving to get you a pre-release, internal beta release of the Flash XDR firmware for your testing.

We feel that the version that we are testing is very good.

At this moment our engineers are making a small change to the menu system, which should be done in an hour or so.

Then as soon as our initial testing of this is performed, we will be sending you a copy of this so you can start independent testing of the Flash XDR release.

If there is anything not right with it, Mark will find it.

Hi Dan:
OK. Good news. Thanks Dan :-) I will thoroughly test whatever you send. I just completed principal photography on Monday afternoon on homeless people documentary using my Flash XDR for 80 % of the shooting (Firmware 1.5.55). I have perfect picture and perfect sound while shooting @ Long GOP 50 Mbps, I was able to obtain very impressive results with my Canon XL H1 camcorder. The 24 bit audio vs only 16 bit obtainable in the camera makes a noticeable-perceptable difference when using the XDR on voice interviews. I find there is also a certain level of headroom when using the analogue balanced MIC inputs on the XDR. I don't know what analogue to digital converter chips are used in the XDR, but I'm surprised at how hot the audio is and how quiet the analogue to MIC connections are. When using the Flash XDR as a simple black box recorder for standard audio and video capture (In my case usually with 3:2 pull down removal to get 24 over 60i for a final 23.98 p) the unit is flawless. Just to have four (4) CF card slots excuses the XDR's larger footprint in terms of our practical every week usage in production. I still hold out hope to have the fire wire I/O enabled for HDD emulation. (Even if that's a paid upgrade) I understand programming the code for HDD emulation is not a small job Tommy ? I want to have 4 large capacity CF cards live in the XDR without the need to fire them half way across the room upon pressing the extraction button :-) (Ha ! Ha ! He ! He !) I actually fired one of my Sandisk Extreme III CF cards out of the window accidentally last week !

Dear Mark,

May i recommend a slightly lighter touch on the Eject Buttons?

Speaking of ejecting CF cards,
Dan, With the nano3D attached to NF I can not have my eject protection unit installed. Any work around for the NF and nano3D when together? Thank you
I didn't wanna open a new Thread..., sorry
Cheers

Dear Luben,

I am sorry, but i do not understand.

What is an "NF I"?

What prevents you from installing two CompactFlash card protectors on each of the nanoFlashes that make up a nano3D?

Are we getting close to firmware that passes testing?

Dear John,

We have kept the same code base for the Flash XDR and the nanoFlash, up until a week or so ago.

However, adding all of the logic to keep the same code base for two rather different hardware platforms became unwieldly when we added 3D to our code base.

Thus, we spent some time to separate the code base into one devoted to the Flash XDR and one for the nanoFlash.

To the best of my knowledge, all of the issues that were preventing us from releasing firmware for the Flash XDR and nanoFlash have been solved. To put it differently, our Quality Control tester is indicating that he is happy with the firmware that he is testing.

I hope and expect that it will not be much longer.