Option #3 you listed would certainly require the assistance of an IT person,
but I'm not so sure that it would have to be a full-time position.
As it has been mentioned on this list before, IT skills will become somewhat
of a necessary fact of life in a digital archive.
Regarding multiple tracks in BWF, we made the decision within the NARAS P&E
Wing Committee to use the "1 track = 1 audio file" for both simplicity and
the knowledge that we couldn't control how various software platforms handle
multiple tracks within a single BWF. Kind of an "analog" comparison I
guess. The EBU does have a document regarding multichannel audio files
Interchange is a BIG issue and probably will be for a while.
> From: "Richard L. Hess" <[log in to unmask]>
> Reply-To: Association for Recorded Sound Discussion List <[log in to unmask]>
> Date: Mon, 14 Mar 2005 22:54:14 -0500
> To: [log in to unmask]
> Subject: Re: [ARSCLIST] .wav file content information
> As usual, Scott and John make some very persuasive points.
> But, there is a huge leap from putting metadata in the BWF file to running a
> database. Let's name the database: it's a digital asset management system or
> media asset management system. Buzzword software that delivers less than it
> promises in many iterations, sadly. I'd love to hear good responses about MAM
> In reality, I think there are three levels (perhaps more)
> (1) Essence (to use the SMPTE term) and metadata in one file.
> This is the BWF as well as the MXF and AAF approach. This was, to me
> one of the big paradigm shifts when migrating from dBase III to Microsoft
> Access. Separate files vs. all-in-one.
> (2) Essence and metadata in one folder
> This is perhaps the easiest to deal with, but doesn't scale
> all that well
> (3) Essence in a file system, indexed by a MAM system. The MAM system
> holds all the metadata while it merely points to the essence. Typically,
> the essence file names become totally NON human readable.
> (1) and (2) can be managed by mere mortals. (3) requires an IT department.
> But BWF begs the question. Do you insert the album jacket scans at 450 dpi in
> the file? What happens when there are multiple audio threads? Can you put 24
> tracks in one BWF? I'm not sure. If nothing else, you'll run out of space.
> Some of the BWF specs seem to limit it to 48ks/s. What about higher
> It's possible, but what about interchange?
> Richard L. Hess
> Quoting Scott Phillips <[log in to unmask]>:
>> One would think that the LAST thing anyone would want to do is resave a
>> complete audio archive file simply to add new text data. Why chance any
>> alteration or corruption of the original audio file ? This is
>> particularly true since the 'new' file won't byte for byte match the
>> original, how would one reasonably (I.E. quickly) verify the new file
>> against the original ? I would agree with John, a 'loose coupling'
>> allows for a proper revision history to be kept as well without any risk
>> to the most irreplaceable part of all... the audio. The adding of an ID
>> number when the file is first generated solves that.
>> -----Original Message-----
>> From: Association for Recorded Sound Discussion List
>> [mailto:[log in to unmask]] On Behalf Of John Spencer
>> Regarding the usage of MYSQL or other database applications, remember
>> that the relative size of the metadata "stack" will be MUCH smaller than
>> the resultant audio files. We prefer to link the metadata record with a
>> unique ID in the BWF header that we also record in the metadata
>> database. By "loosely coupling" the two, you can add/ make changes to
>> the individual metadata record without having to load the audio file
>> I would be more concerned that the metadata that I was collecting was
>> structured in a manner that would allow for it to move into other
>> database environments without re-keying the information.