We are working on plans to support metadata for the Flash XDR and nanoFlash. Initially, we plan to target Final Cut Pro (QT files) and then expand support for other NLEs (via MXF).

Here's a simple list of initial parameters we are considering:

Data Entered by User:
Program: (Survivor, for example)
Place: (Jamaica, for example)
Scene: (8 alphanumeric characters)
Take: (auto increments with each record session)
Shooter: (8 alphanumeric characters)
Mark: (Good, Better, Best, Reject)

Data Automatically Retrieved From Flash XDR / nanoFlash:
Unit ID
Date
Time
Video Format (1080i59.94)
Bit-Rate (50 Mbps)
CODEC (Long-GOP / I-Frame)
Starting TC
Audio Source (Embedded / Analog)
Temperature
Firmware Version

Initially the data will have to be manually entered into each box. We can automate later via RS-485 master control or by writing a configuration file to a Compact Flash card for upload into each box. But we want to start with a manual entry to debug the program.

All the data entered by the user is stored in nonvolatile memory inside the XDR/nano.

Any recommendations / suggestions?

Best-

I would add three more; Subject, Comments, and Accession.

Subject could be used to list a person's name if one is doing interviews.

Comments could be used for miscellaneous information.

Accession is a number used for filing and retrieval purposes.

http://en.wikipedia.org/wiki/Accession_number_(library_science)

Lens info such as focal distance, aperture, shutter speed ?

Info useful for matching pickup shots or post work; or test shots to help determine what settings worked out best.

This metadata feature as whole will help reduce the boring logging chores. Will also help a lone shooter with keeping control over the shoot without having to stop and do notes and logging.

Way to go C-D!

Thanks for the feedback and recommendation. We have developed an initial set of parameters, which will be implemented in the month of April. The initial data is entered via the keypad on the Flash XDR, but next month we plan to add RS-485 control, so these parameters can be updated via a netbook or laptop.

We do expect to add many new parameters in future firmware releases, but we need to start with a rather simple basic list to iron out all the issues and workflow.

Metadata Entered By User:
Project: [8-alphanumeric characters: Entered Manually into each box from Keypad, saved in local nonvolatile memory]
Location: [8-alphanumeric characters: Entered Manually into each box from Keypad, saved in local nonvolatile memory]
Operator: [8-alphanumeric characters: Entered Manually into each box from Keypad, saved in local nonvolatile memory]
Shoot Day: [3-numeric characters: Entered Manually into each box from Keypad, saved in local nonvolatile memory]
Scene: [8-alphanumeric characters: Entered Manually into each box from Keypad, Function Key access, saved in local nonvolatile memory]
Take: [4-numeric characters: Initializes to zero when Scene number is changed, auto-increments with each record session]
Mark: [3-option selection accessed via function key: Print, Rehearsal, Reject; Note the Mark will be automatically displayed after each recording, operator can easily select appropriate entry using up and down arrow keys]
Comment:[Will be added when RS-485 is enabled]

Date Retrieved from XDR (internally):
Unit ID
Date
Time
Video Format (1080i59.94)
Bit-Rate (50 Mbps)
CODEC (Long-GOP / I-Frame)
Starting TC
Audio Source (Embedded / Analog)
Temperature
Firmware Version

Best-

Fantastic ideas. Would also like to see fields for noting basic camera settings. Comments box could be used to accommodate data on Subject/Contributor.

Jus.

Dear Justin,

How does one field sound for camera settings? This would be free form so you enter the information that is important to you.

Personally, I would prefer this to separate fields for Aperture, Shutter, Filter, Neutral Density Filter Setting, Preset, Color Balance, Gain, etc.

If we use separate fields, then it would to hard to accommodate all of the different cameras.

I endorse Dan's suggestions about including Subject, Comments and Accession as metadata fields.

A national video oral history project I work with is planning to use the XDR recorders in part because of their metadata capabilities – as well as for the promised RAID 1 option for creating simultaneous safety copies of files. Because the project functions as a library, all assets associated with each interview are identified with a unique accession number.

Ultimately the names given to the fields are less important than having a sufficient number of fields that will accomodate character strings of useful length. In one respect, simply labeling the fields as User1, User2, etc. is preferable because it does not imply an intended use that may be different than the actual use in individual cases. In the end, many of us will be re-mapping or further parsing the metadata down the line in any case.

The limitation of eight characters is problematic from the perspective of our project's use of the metadata. Longer common surnames, e.g. Richardson, Williamson, not to mention compound surnames, e.g. Simmons-Walker, cannot be stored in such small fields.

Understandably there may be some consideration for the constraints associated with key pad data entry, but it would still be worth allowing three or four of the fields to accept 16-20 characters. This would not preclude shorter entries and still allow longer strings like the examples above.

The plans for addition RS-485 control or config files for uploading metadata are also much anticipated for the improvements they will allow in our workflow.

Thanks Dan, Mike and everyone at Convergent. The FlashXDR is going to be a great help with the long form, archival quality work that the oral history project does. It will be ideal once the RAID 1 and metadata features are implemented.

Scott

Dear Scott,

It is nice to hear from you.

We will do want we can.