[QUOTE=Aaron Newsome;1528076]
Then there's also the problem with pruning bad takes from your CF cards. Again, no way to do this with a Mac either. If you want to delete a file from your card, you'll need to connect the CF card to a PC. The Mac is unable to delete these locked files from Nano/XDR CF cards.

Sorry Guy's the way I read it sounds like editing the card on location.

Dan I do remember that there was mention that CD were looking at implementing the deletion of the last file on the cards is that feature still listed for implementation.

Dear Lance,

Yes, we will have "Delete Last Clip".

If you record a clip, then want to delete it, you can.

If you power down the nanoFlash, or remove the CompactFlash card, then you can no longer delete the last clip.

We can delete the last clip since we do it in such a way to prevent any possibility of file system fragmentation.

Nope, that does not work. I mean you can do it, but then you can no longer use the card in the nF without reformating it. Which really makes the entire nF much less useful as that means you need to carry a number of spare cards on you everywhere you go.

They claim that if they allowed it, it would slow the writing process down. I am not buying into that, except if you did it numerous times. Other cameras allow you to delete files in the middle just fine. It makes me think the nF does not have enough memory available.

Dear Adam,

When one deletes a file, it leaves an empty space.

In order to be able to write high bit-rate video to the card, we need to write very large blocks of data at one time. We do not have time to determine where the empty areas are on the CompactFlash card.

The way we do it, to make this all work, is that from the last file on the card, to the end of the card, is always free. Thus, we can delete the last file (clip), since this just makes this one big empty area (free space) bigger. It does not create two empty spaces, one in the middle and one at the end.

It is always best to degragment your computer files for maximum performance.

What we do, is keep our file system (the CompactFlash card), defragmented at all times.

For a stills camera, it is not a big deal to write a single, or a few images to the available space on the card, whereever that might be.

It is something else entirely to write high bit-rate data, for a long period of time, where one can not afford any wasted time.

Adam, we have a tremendous amount of memory in the nanoFlash. We use quite a lot of it to buffer the writes to the CompactFlash cards. This large buffer allows us to stop writing to one file (when we approach our file size limit), then open another file, then go back a close the previous file, writing out a very large index of every frame in that file, all the while we are writing the new data that is coming in to the new file.

Adam, the only reason I brought this up is because the last time I had to "hand off cards to the producer", I was left a little bit frustrated that I could not "clean the garbage shots off the card".

The producer got my cards,.. well actually, their cards since they now own them. They really don't care that they can't be played back in the nano but I cared that they have files where I accidentally recorded 20 seconds of the floor and my feet.

If I would have had a PC on the set where I could delete this stuff off the cards, I definitely would have.

Yes, I see what you mean. Makes perfect sense. I am glad for you (and other Mac users) that they are unlocking the files in the next firmware revision.

Make File Unlocking An Option
 

Hi Aaron:
I am a little concerned exactly *how CD will implement this. I hope they implement this feature as a feature (Read - Option in the menu) as opposed to it's either this way/or the other way, but not *and.

I've had some thoughts on this subject but I wanted to mull this over as there are a lot of concerns to be addressed that go well beyond the personal needs or desires of the camera operator.

In short I believe Convergent Design did the right thing given the history and protocol around the treatment of source "footage" coming off a camera. At present, we have had about a generation of use with solid state media in the industry with the most prevalent being P2 media or at least the one which paved the way. Prior to that it was tape and film as the predominant medium. The viewpoint of source media is that it is RAW and you are not supposed to mess with it. Insuring productions has been based around this premise and protocols in workflow have been created to ensure the integrity of source material. What some are asking for is a deviation away from this standard which is fine but you are referring to it as a flaw. It isn't if you buy into the history on the matter. I can see why people want an option to be able to mess with the source material but you are asking to do it on the transport medium.

Convergent Design has it's own requirements for people not messing with the cards but in terms of the actual argument about messing with source files has a great deal of precedent. I do buy into the idea that a shooter may want to clean up his/her footage before releasing it to the client, like shooting your foot (we've all done it) but with tape and film you can't do that, all of your sins were enshrined on the source medium. Convergent Design has made it very clear to us on the forum (and in the user manual) that the cards, the transport medium should be handled and manipulated only by the unit. You transfer the files to your nexto or your computer and eject the card without doing anything to it save a simple copy. Following this procedure allows them to push the abilities of the media to it's limits with us being the beneficiaries of this "bleeding edge" technology.

I would hope that Convergent Design implements this feature, as Mark suggests, so it is an option and it will satisfy the insurance companies that have been reluctant to get in the business of insuring "footage" that comes from a solid state medium. This matter goes way beyond personal needs.

Dear Friends,

We have listened to the points and requests on both sides.

We have decided to implement "File Locking" as an menu option in a future release.

Today, we released our latest code to our Quality Control tester. The next release is thus in test at this moment. This next release, most likely, will have "File Locking" turned off, without a menu option.

As soon as humanly possible, but without delaying the release of our next firmware, we will be adding "File Locking" as a menu option.

We have a great many features and internal improvements in this next release and we do not want to delay it. We hope everyone understands.

The Real Culprit is Final Cut Pro !!!
 

.....No it isn't, but the principal reason I understood why Aaron was requesting a lock turned off option was to suit the editorial eccentricities of Final Cut Pro's Auxiliary Time Code logging function. If CF Card media is locked, then FCP doesn't write Auxiliary Time Code to the proper file, so when you re-open your FCP Project this information vanishes ! You may absolutely require the Source Auxiliary Time Code from your XDR or Nano recorded video files to re-sync your double system audio. I know Aaron is shooting with his Viper camera, which doesn't possess any internal recording VTR, so he's either shooting double system sound or capturing dialogue audio on his XDR directly.

.....Yes, there is a direct *Legal implication here. The way the laws are written in Canada and particularly in the US, it's litigation city on CD from insurance companies (Read Film Guarantors) if an XDR or Nano has this option turned off ! If CD implements it as a fully visible menu option, then they are covered in a court of law because the end user has to make a *CHOICE* to implement it ;-) This is how the law would view this issue.

Dear Mark,

Our only concern is satisfying our customers.

Customers
 

Dear Dan:
I'm sure. I was referring to how insurance companies often sue back money they have to pay out. It was in response to Andrew Stone's post. I'm not lying awake at night wondering who's going to take legal action against CD. What about making money ?

Dan,

Thanks for this most welcome development. You guys are the best in the industry at listening to your customers... and doing something about it. This is just one in a very long list of examples. I respect your wishes to keep the menu options down to a minimum but in this instance, this is a good and balanced decision. And I am good with waiting for it until it can be pragmatically worked into your development flow.

Be well...

Hi Mark,

I don't think our view differs that much on either the approach to source files or the insurance/film guarantor matter. But if I do get this straight (I may misunderstand this) Aaron wants to be able to stripe the auxilliary time code to the source files on the Compact Flash card?! As I said inferred earlier, going into the compact flash cards and adding stuff after the fact is adding significant risk (not to mention the issues of media fragmentation brought up by the CD individuals). But hey, viva le difference! Seems to me it should be done at an intermediary step, on a hard drive, after copying the source files has taken place.

If there is a prevailing reason to do this I would like to know other than simply a shortcut or to save on hard drive space.

I am also willing to bet, if someone posted on the LAFCPUG forum that an editor forgot or didn't unlock the files a huge forum style pile on would occur and they certainly wouldn't advocate working off the camera cards.

FCP Post Issue Clarification
 

....Hey Andrew: No, fundamentally we are in agreement, only, there is a misunderstanding with why he wants it unlocked from source recorder media. I will leave it to Aaron himself to clarify, but I understood from his earlier post in this thread (Read back to the first one and then down a bit - sorry forgot post number) - he was referring to a peculiarity in the way the FCP application handles source TC from the XDR/Nano recorded CF card media. Apparently, both Aaron and his editor were experiencing a general failure in FCP to write Auxiliary TC data to file in an editing project due to the *locked status* of the source CF card media out of the recorder. Aaron was pointing out that if he could have unlocked XDR or Nano recorded CF cards out of the unit, then he could save an enormous amount of time preserving the Source TC data within the Auxiliary TC data save in FCP. Does this make sense ? This is what I understood (Aaron please correct me if I got this wrong). In any case, no worries Andrew :-) All is well :-)

P.S. Let's be totally fair to Convergent Design by stating this is not due to a specific deficiency within their Flash XDR or Nano Flash recorders, this seems to be related more to a specific peculiarity within FCP, *which may be circumvented by CD adding an unlock menu option within a future firmware release.