[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ARSCLIST] .wav file content information
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" <ArcLists@xxxxxxxxxxxxxxx>
> 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: richard@xxxxxxxxxxxxxxx
Vignettes
Media web: http://www.richardhess.com/tape/
Aurora, Ontario, Canada (905) 713 6733 1-877-TAPE-FIX