Nanoflash

[Piotr Wozniacki]

..and some link, please?

;)

[John Mitchell]

Hi Dan

Originally Posted by Dan Keaton

1. Each clip stands alone and there is no directory structure or associated files to deal with.
If one wants a individual file, it s easily used...

2. Having smaller files is sometimes a great bonus if there is every a bit-error or corruption in any one small file. The rest of the files are still very useable. I was in a meeting of NBC Executives and they pointed out that this fact is very important to them..

There seems to be a certain lack of knowledge here on how the BPAV structure works. Sony still splits files into 2GB in an identical fashion to the Nanoflash and of course you can still access the individual clips in exactly the same way as you can access the individual clips on the CD cards - just another 2 folders down. It just uses an XML database and a folder heirarchy so that the editing program or XDCam browser can display contiguous clips as one large clip - eg a 2 hour continuous shoot like a conference or concert is actually stored on the SD card, SxS Card or optical disk as a bunch of individual 2GB clips, but the BPAV folder structure allows the editing program to present it as one seamless clip to the editor - this is done "on the fly", no copying or concatenating or any other silly stuff required.

Originally Posted by Dan Keaton

We have the following tools available right now:
We can combine individual MOV clips into one large MOV clip during the transfer process.
We can combine individual MXF clips into one large MOV clip during the transfer process.
We just, at this time, cannot combine individual MXF clips into one large MXF clip.

I don't think anyone would dispute that using a bunch of third party tools (one that uses quite an expensive plug in) that require processing, re-wrapping and copying all the media manually is a better solution than the plug and play BPAV folder structure which is cross platform and compatible with all the major NLE's. Moreover you get XDCam browser free which is quite powerful for metadata tagging and combining clips of different cards into one folder.

The MediaPro.xml file contains the information on all the clips recorded and how they stitch together while the xml files within the CLPR folder contains the relevant information on the clips themselves which also reside there (each in their own subfolder).

I'm just wondering if your engineers ever even looked at this as an option?

Originally Posted by Dan Keaton

And we will be adding, in an upcoming firmware release, a new feature.
One will be able to assign a "Tag", which can included letters and numbers), to each clip.
Then one will be able to shoot various clips and our software will be able to combine them together, by searching for all clips with the same tag.
And of course, we will make it easy to switch from one tag to another before recording a clip.
For example, for a news gathering organization:
A news crew goes out in New York city and shoots clips around the city.
And while there are out, they shoot clips for another news segment interspersed among the clips for the first segment.
If they assign a tag to all of the clips for the first segment and a separate tag for the second segment, then our software will combine all of the clips of the first segment into one clip and the same for the second segment.
Then the network can load the complete segments into their editing system.

The tagging sounds very interesting and a cool feature. As usual well done when we see this feature pop up.

I love the Nano - it's great especially with consumer cameras with decent chips but no decent recording option but I still wish it had better workflow options :) It isn't really a problem except when it doesn't work as in my current issue with LongGOP media 100Mbs on Avid breaking the AMA plug.

http://www.dvinfo.net/forum/converge...es-errors.html

No way around it that I've worked out so far. I tried converting all the mxf clips to mov using Sorenson and that would have worked except it broke timecode.

Hope all that clears up a few misconceptions - cheers Dan

John

[Dan Keaton]

Dear Piotr,

We do not have a link up for this software at this time.

I will ask our team to put up a link as soon as practical.

[Dan Keaton]

Dear John,

Thank you for your suggestions.

I will discuss this with our engineers.

[Ron Aerts]

Originally Posted by Dan Keaton

Dear Ian,

Yes, we are working on a new firmware release.

There will be multiple new features.

Here are two:

1. Ability to extract timecode from the HDMI Input for the Sony FS100 and FS700 cameras.

2. The ability to detect the HD-SDI Record Packet.

Certain cameras, such as the Sony F3, Canon C300 and other cameras put out a signal in the HD-SDI steam that indicates every time the camera record button is pressed.

We will detect that signal and start/stop the nanoFlash accordingly.

This is a great new feature as one can use continuously running timecode as opposed to using Record Run timecode to start the nanoFlash.

And other features will be added.

Dear Mr. Keaton. We are 5 months further. When will these functions be implemented?
Thanks, Ron

[Ian Thomas]

Don't know what you all think but are you getting a funny feeling that alls not well? Dan use to be on here like a flash if someone had a prob or needed support and now hardly comes on here and no news of the upgrades to the nano that were promised!!

Hope Iam wrong because they were a first class company

[Gints Klimanis]

Nanoflash with CF cards was/is great, but it's done. They're probably on to making a new compact 4K recording system with SSDs. If they made some smaller ones for POV cameras for < $1k, I'd be in for a few.

[Jack Zhang]

My only gripe was the lack of BPAV file structure, meaning that (at least for Sony Vegas) you have to manually stitch together on your timeline any spanned files.

CD has not (and by now, will not) make a MXF to MXF stitcher and a fix for the illegal black record kill switch on HDMI might never see the light of day.

[Seth Bloombaum]

Originally Posted by Jack Zhang

...and a fix for the illegal black record kill switch on HDMI might never see the light of day.

I'm fairly new to nanoflash. Jack, would you mind explaining just what "illegal black record kill" is? Are there cams that generate an illegal black that kicks the NF out of record? Yes, I'm using HDMI. Thanks in advance.

I am getting the message that many people have moved on, or would like to, or are mad at CD for not supporting/extending/updating the NF, but for me, it is still a pretty good life-extender for my HDV camera, and I look forward to seeing how it works on a Canon C100, too.

***edit***
Never mind. I did finally search on the right terms and found this thread: http://www.dvinfo.net/forum/converge...ions-nano.html , which explains the issues Jack has experienced using the Nanoflash as a screen recorder.

[Jack Zhang]

Some POV cameras also output illegal blacks when the camera is covered. This causes the Nanoflash to completely stop recording.

[Samer Aslan]

Originally Posted by dan keaton

dear ian,

yes, we are working on a new firmware release.

There will be multiple new features.

Here are two:

1. Ability to extract timecode from the hdmi input for the sony fs100 and fs700 cameras.

2. The ability to detect the hd-sdi record packet.

Certain cameras, such as the sony f3, canon c300 and other cameras put out a signal in the hd-sdi steam that indicates every time the camera record button is pressed.

We will detect that signal and start/stop the nanoflash accordingly.

This is a great new feature as one can use continuously running timecode as opposed to using record run timecode to start the nanoflash.

And other features will be added.

when will that happen?????

[Ronald Jackson]

Just got my regular e-mail from Convergent Design re yet another firmware update for their "Gemini"but not a dicky bird , again, about the "nanoFlash".

Seems us nano owners are now ancient history.


Ron

[David Rogers]

You should be a Flash XDR owner!!

[Jack Zhang]

Speaking of that, since the XDR has been completely abandoned, how about open sourcing that device's firmware code? an OpenXDR firmware initiative would mean newer bugs would be fixable.