[Table of Contents]


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ARSCLIST] .wav file content information



Hello Richard,

All good points, so let me clarify my earlier statements by commenting to
your reply.  Also, we've built these tools for our internal use, it's
certainly not that hard.

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

How do you control the operator's authority to modify?  Should it be
controlled?  Will certain DAW applications overwrite the existing metadata
when the file is opened?

> It was my suggestion to add the import/export utility and to make it easily
> accessible by standard Microsoft/Open Office tools.

Agreed.  I think that is why you see a large "dose" of XML baked into the
latest Office flavors.

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

If entity A has 500GB of files and entity B would like to research them,
wouldn't a 500K database be an easier start?

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

Agreed.  I was merely pointing out that if you have many data tapes, it is a
logistical nightmare to try and reload those tapes to update (1) common
field across all of the audio files.

John
--
John Spencer
http://www.bridgemediasolutions.com/


> From: "Richard L. Hess" <ArcLists@xxxxxxxxxxxxxxx>
> Reply-To: Association for Recorded Sound Discussion List <ARSCLIST@xxxxxxx>
> Date: Wed, 23 Mar 2005 12:24:48 -0500
> To: ARSCLIST@xxxxxxxxxxxx
> Subject: 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.


[Subject index] [Index for current month] [Table of Contents]