At 3:28 AM +0000 4/22/10, Steve Pelikan wrote:
>
>Yes Rob, I agree 100% that it'd be nice to have all this
>extraction/consolidation/im/exporting of data done automatically.
I'm having a hard time making myself clear. In no way would any
unique details be done "automatically." The date, the gear used, the
location and weather simplifications can be added using global
editing just like it would be in a tag editor, just with the option
to add them in the consolidation app as well.
I used the phrase, "automatic archiving," to try and emphasize that
the normal steps one takes to mark points of interest in the files,
detail species and contexts, save exported regions, include pictures
etc etc, _can_ result in an archive. If you put some extra work into
it, a dern good one, but it can also reside on your computer and
serve you and go to the landfill.
>My point was that even with that nifty technology available we still
>need to get people to record important data.
No argument here, but having the consolidation app ask ask me when I
drop a set of files in to provide a recording date would get the
right synapses fired up. Maybe, "nifty," but also very basic.
> 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.
To thine own self be true? Its a text so personality counts!
>
>Also as you say, there's also no doubt (say we develop a great
>template for 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 spread sheet functionality.
They probably wouldn't if they had a chance to see the difference.
>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.
Thankfully, the one thing I did start employing early on is elaborate
file naming. _I_ can find some stuff, laboriously.
The only "conflict" between, "devising my own system to do what I
need (today)" and creating a collection of recordings that someone
else can easily access years from now is accepting that I have to use
a couple of new software apps.
>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 breaks the link between accession data and specimen
>makes the specimen essentially worthless.
Every item is ID'd; has to be. Think about this stage though, doesn't
it make more sense for the datbase app to assign ID's and write the
tags onto the files as they go into the database?
> 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.
Somehow, sometime, a more encompassing set of tools will come
together that everyone will have the option to use. :-) Rob D.
>Best!
>
>Steve P
>
>--- In
><naturerecordists%40yahoogroups.com>=
m,
>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
>> >
>> >
>>
>>
>> --
>>
>>
>>
>
>
--
|