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
software.
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
resolution.
It's possible, but what about interchange?
Cheers,
Richard
--
Richard L. Hess
http://www.richardhess.com/tape/
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
> itself.
>
> 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.
>
