Date:         Thu, 24 Mar 2005 10:22:46 -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:         Scott Phillips <[log in to unmask]>
Subject:      Re: .wav file content information
Comments: To: Association for Recorded Sound Discussion List <[log in to unmask]>
Content-Type: text/plain; charset="us-ascii"

Thanks !! I'll pass this on to the interested developers as well... 

-----Original Message-----
From: Association for Recorded Sound Discussion List
[mailto:[log in to unmask]] On Behalf Of Damien Moody
Sent: Thursday, March 24, 2005 10:01 AM
To: [log in to unmask]
Subject: Re: [ARSCLIST] .wav file content information

If you're really interested, you can get a project started and posted on
SourceForge (www.sourceforge.net) for an open-source multi-media
metadata/archival project. Interested developers can contribute as they
have time and resources to do so. 

Damien J. Moody
Information Technology Services
Library of Congress

>>> [log in to unmask] 03/23/05 1:31 PM >>>

IMHO, in the end databases are absolutely the way to go. However, by
having both a file naming scheme to use with databases and perhaps
'pointer' information in the metadata, the both the files themselves and
the database information would be more useful. I'll pass any/all
comments on to the developers that have volunteering to look into this
for us. Needs to be K.I.S.S. for sure if we don't want to kill the goose
that lays the eggs though.

My thinking was just to suck a few good software developers in and make
a few simple tools available for general use at no / low cost. There
seems, if I read the posts here right, to be a real need for them. Yes,
they aren't hard to write, but fact is, no one is doing and releasing
them for folks outside their organizations to use. It would be a start.

Ultimately, I hope they (the developers) may see that there is an
unfilled need for commercial software to address the needs of the
archiving community, database driven but fully scaleable. The money
available and the size of the archives dictates that for such software
to see general use, it would need to work with several databases (Say,
Access, MySQL, Oracle) Access is cheap and available, but has issues,
particularly with 2+ Gb databases. Oracle is good for huge databases,
but expensive as heck. If a product could be written that allows for
common GUI and data formats in/out, but allowed different database
underpinnings, that would be great. 

-----Original Message-----
From: Association for Recorded Sound Discussion List
[mailto:[log in to unmask]] On Behalf Of John Spencer
Sent: Wednesday, March 23, 2005 11:41 AM
To: [log in to unmask]
Subject: 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" <[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.