Hi Will--
Some metadata can and probably will be added to the sound and other
mediafiles by the database.
Moving "tracked" files without using the database app to do (like any
media handling app) can reek havoc for sure. One would have to learn
and abide by basic folder "rules--" part of getting the mind
"organized" for the task.
I have a suspicion, though, and I'm NO programmer, that our focus on
"metadata" is not a key factor in maintaining the database's
stability and integrity. And since the DB becomes the tool one finds
stuff by and feel good about maintaining, the DB's needs are the ones
to focus on as we plan, IMO. Its the fields we establish in the
"consolidation" app and that are elaborated upon in the DB that get
really powerful and important for us to understand.
Aside from getting time stamp, possible geo coordinate stuff, what
data do people think is urgent to strip off of b-wavs right now?
re:
>There should be a way to batch edit this metadata and have and external
>application that can read the same metadata into a database
I'm having a hard time explaining how these "tagging" functions
you're thinking of as a separate step get included. There are two
apps in my sketch:
1) Consolidation app -- a full fledged audio editing/mixing app for
importing recordings, extracting meta data from the recording(s),
editing/adding all global information like date, time, place, gear
(Like you can _also_ do with a tag editor**), make excerpts, add
comments, photos. input charted data like species, habitats-- all of
the stuff we talk about and all synchronized to the timeline). All of
the above is done, time permitting, as you "roll through" your
recording(s) time with mandatory tasks of making "excerpts,"
"squeezing" excerpts to save storage space and making quick seamless
edits with cross-fades and other stuff you normally do before you get
really serious about mixing and need to start with a clean time line.
(You do all the "editing" on a lower track leaving the top tracks
intact and the timeline overview preserved)
2) Database app. You open the tabbed doc that you export form the
consolidation app and it creates a beautiful, display page of your
recording foray called a RECORD in a database. You can add stuff in
cells in the DB. You use the DB anytime you want to look at factors
pertaining to a recordng or all of your recordings or any definable
(many) subsets. The search results as a window to not only to play
the files directly, but to open (a copy) in another app and it cam
also show you regions you have ID'd using the consolidation app that
match your seach and open the app and "point" to them. Amd more. but
that the basics.
** Note that one doesn't need a recorder that make b-wavs, one can
add a time stamp to any recording and, hopefully, many shorter
recordings placed on one timeline in the editing app by entering the
start time for each. The excerpts you create get time stamped (and
also show notes you add). If your field recorder doesn't time stamp
and you don't want to bother with verbal slates, then you can divide
the time it took for you to make 20 recordings that day into even
time spans and estimate start times and check the "estimated" box. I,
personally, want apps that favor all users, no matter how much they
have to invest in a sound recorder. Rob D..
At 8:04 AM -0400 4/22/10, Wil Hershberger wrote:
>I would have to say that having the data about the recording IN the metada=
ta
>of the file itself is very important. If the link is broken between the fi=
le
>and the xml file (or whatever external file) then all is lost. If all the
>data is in the metadata of the actual wav file then it can't get lost. The=
re
>should be a way to batch edit this metadata and have and external
>application that can read the same metadata into a database. Results in th=
e
>best of both worlds, all the data is safe in the wav file and there is an
>external database of all the data for quick searching.
>
>There is a great deal of effort in the federal government to standardize t=
he
>fields to be used within the wav file format as well as what xml or iXML
>fields to setup for sidecar files. I will try to find the pertinent links.
>
>Wil Hershberger
><<http://www.natureimagesandsounds.com/>http://www.natureimagesandsounds.c=
om/>
>Nature Images and Sounds, LLC
>Hedgesville, WV
><<http://www.songsofinsects.com/>http://www.songsofinsects.com/> The
>Songs of Insects
><<http://cricketman.blogspot.com/>http://cricketman.blogspot.com/> My Blog
>
>From:
><naturerecordists%40yahoogroups.com>=
m
>[mailto:<naturerecordists%40yahoogroups.com>=
roups.com]
>On Behalf Of Steve Pelikan
>Sent: Wednesday, April 21, 2010 11:29 PM
>To:
><naturerecordists%40yahoogroups.com>=
m
>Subject: Re: [Nature Recordists] from metadata to archiving
>
>Yes Rob, I agree 100% that it'd be nice to have all this
>extraction/consolidation/im/exporting of data done automatically.
>
>My point was that even with that nifty technology available we still need =
to
>get people to record important data. And I think that's a much bigger
>problem than the software issue by far. It is hard and time consuming and =
it
>has to be done with thought and accurately to be worthwhile. All this is
>from the perspective of archiving for someone else's eventual use or for
>historical value of the audio data, not the recordist's convenience.
>
>Also as you say, there's also no doubt (say we develop a great template fo=
r
>data) that it'll end up getting dumped in a data base of some sort --- and
>I'd bet over 90% of people's use of it would be satisfied with a flat spre=
ad
>sheet functionality.
>
>I also agree with you that there isn't tremendous day-to-day need for the
>metadata data to be included in a file with the audio data itself, if that=
's
>what you're saying. Especially if people have been careful about naming
>audio files in a unique way.
>
>But there's a reason that museums insist that all collection data goes on =
a
>label attached directly to a specimen --- otherwise any accident that brea=
ks
>the link between accession data and specimen makes the specimen essentiall=
y
>worthless. So from the perspective of long term value and archiving for
>other's eventual use, if I had a choice, I'd say add an extra block to the
>bwav/riff/whatever/ files and put the data there.
>
>Best!
>
>Steve P
>
>--- In
><naturerecordists%40yahoogroups.com>=
m
><naturerecordists%40yahoogroups.com> , Rob Danielson <>
>wrote:
>>
>> Hi Steve--
>> You're going to be typing high quality data because that's the kind
>> of recordist/guy you are. If your going to have a template to "store"
>> and use, you need a full fledged-database. The template you use for
>> your DB "records" will allow you to discriminate things I'd never
>> think of,.. And you'll build that template out a basic template that
>> we'll have after the interlinked apps are in beta.
>>
>> Question. Would you like being able to add your high quality info for
>> your database at the same time you log, make excerpts and add
>> reliable "automatic" stuff like place, date, basic weather globally?
>> I'm saying use the time stamp from your SD, use the GPS info when
>> that becomes norm but add everything else in the consolidation app.
>> (Those with less sophisticated recorders can add the time stamp in
>> the consolidation app). Your java code/function can go into the
>> database.
>>
>> I'm not seeing a use for data "attached" to a sound file once its
>> extracted by the consolidation app and related to everything else in
>> a database. Help me! I must be overlooking some need that others are
>> seeing. Rob D.
>>
>> =3D =3D =3D =3D =3D
>>
>> At 2:19 AM +0000 4/22/10, Steve Pelikan wrote:
>> >Friends:
>> >
>> >I agree that one could/should construct
>> >free/cross-platform/easy-to-use software for manipulation of
>> >metadata. I'll share all my java library code and python scripts
>> >with anyone who wants to do it.
>> >
>> >But I think the real problem is much closer to what Vicki was saying
>> >a few messages back: people actually need to take the time and
> > >exercise care and understanding to produce good documentation and
>> >metadata. This can't really be done automatically.
>> >
>> >Even high res and high tech fixes won't do, I'm afraid. As an
>> >example, consider something simple like a recording of a single
>> >bird's song: maybe GPS and chronometer data that's automatically
>> >recorded say when and where to milliseconds and meters. But was the
>> >bird identified by sight or could it be a mimic? Was it an adult or
>> >immature? Male or female? What was it doing while making the sounds?
>> >What conspecifics were present? Where thate predators around? Or
>> >prey? etc. etc. None of this could be logged automatically ---
>> >someone has to notice it, know it is significant, and record/enter
>> >it.
>> >
>> >And of course the potential questions to be answered about a
>> >"soundscape" are this multiplied many times over.
>> >
>> >So I think discussing software is fine --- I even wrote some a while
>> >back for my own use --- but the real issue is spreading an
>> >understanding of the importance of such ancillary data and
>> >encouraging each other to make ever better efforts at recording and
>> >preserving it.
>> >
>> >If we were going to do anything high tech at all here I'd propose we
>> >work towards developing a template ( perhaps an XML format (DTD or
>> >schema)) we could all use to record all the significant facts about
>> >a cut. Anyone implementing a metadata manipulation program would
>> >benefit from such a standardization and in the mean time we could
>> >all work towards including all the important data in our
>> >documentation in some "exportable" form.
>> >
>> >--- just my $0.02 worth
>> >
>> >Steve P
>> >
>> >
>>
>>
>> --
>>
>>
>>
>
>
>
--
|