Re: [ARSCLIST] .wav file content information

[John Spencer <js@xxxxxxxxxxxxxxxxxxxxxxxx>]

Richard,

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
(R111-2004).

Interchange is a BIG issue and probably will be for a while.

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



> From: "Richard L. Hess" <arclists@xxxxxxxxxxxxxxx>
> Reply-To: Association for Recorded Sound Discussion List <ARSCLIST@xxxxxxx>
> Date: Mon, 14 Mar 2005 22:54:14 -0500
> To: ARSCLIST@xxxxxxxxxxxx
> 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
> 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 <scottp@xxxxxxxxx>:
>
>> 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:ARSCLIST@xxxxxxx] 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.
>>
>