Hello, John,
I think the initial programming project was to provide a manual interface
to the BWF metadata chunk, so that presented with a BWF file, the operator
could read and modify the metadata.
It was my suggestion to add the import/export utility and to make it easily
accessible by standard Microsoft/Open Office tools.
I do think that there is a place for this. If entity A provides a bunch of
BWF files to entity B, they could stand on their own w/o having the
separate metadata files.
Also, putting metadata into the BWF on the data tape or storage system is
the perfect long-term backup to the main data store. I did not see this as
a search tool, but as part of an archive strategy and an interchange strategy.
Cheers,
Richard
At 12:01 PM 3/23/2005, John Spencer wrote:
>I'm not quite sure what purpose a metadata loader/ extractor will serve.
>
>At the NDIIPP website you will find the Version 0.2 Technical specification:
>
>http://www.digitalpreservation.gov/index.php?nav=3&subnav=12
>
>If you read pages 4 and 5 there is a reference to how "metadata evolves over
>time". Additionally, there is precious little space in the BWF header,
>certainly not enough to incorporate every piece of metadata collected.
>
>Beyond that, as I have mentioned before, some DAW apps may overwrite the
>stored information if the file is opened. In our commercial digital
>migration business, most (if not all) of the BWF files end up on data
>storage tapes - the metadata collected would not be very accessible if you
>wanted to search individual fields.
>
>If someone is to build something like this, I would assume that they are
>using the SMPTE metadata dictionary (RP210v8) as a baseline?
>
>XML would be the preferred way to go.
>
> > From: "Richard L. Hess" <[log in to unmask]>
> > Date: Wed, 23 Mar 2005 11:31:01 -0500
> >
> > At the top of my list is a way of both loading or extracting the metadata
> > from across multiple BWF files to a database structure.
> >
> > If fields can be long then CSV would not work, but dbf would. I guess XML
> > would be the modern choice, but then we'd need a parser from XML to
> > office-type apps.
> >
Richard L. Hess email: [log in to unmask]
Vignettes
Media web: http://www.richardhess.com/tape/
Aurora, Ontario, Canada (905) 713 6733 1-877-TAPE-FIX
|