Skip
repetitive navigational links
L-Soft  -  Home of  the  LISTSERV  mailing list  manager LISTSERV(R) 14.5
Skip repetitive navigational links
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (March 2005)Back to main ARSCLIST pageJoin or leave ARSCLISTReplyPost a new messageSearchProportional fontNon-proportional fontLog in
Date:         Wed, 23 Mar 2005 11:40:43 -0600
Reply-To:     Association for Recorded Sound Discussion List
              <[log in to unmask]>
Sender:       Association for Recorded Sound Discussion List
              <[log in to unmask]>
From:         John Spencer <[log in to unmask]>
Subject:      Re: .wav file content information
Comments: To: Association for Recorded Sound Discussion List <[log in to unmask]>
In-Reply-To:  <[log in to unmask]>
Content-type: text/plain; charset="US-ASCII"

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" <[log in to unmask]> > Reply-To: Association for Recorded Sound Discussion List <[log in to unmask]> > Date: Wed, 23 Mar 2005 12:24:48 -0500 > To: [log in to unmask] > 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.


Back to: Top of message | Previous page | Main ARSCLIST page

LISTSERV.LOC.GOV CataList email list search Powered by LISTSERV email list manager