 |
 |
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