Yes Rob, I agree 100% that it'd be nice to have all this extraction/consoli=
dation/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 p=
roblem 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 hi=
storical 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 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 spre=
ad sheet functionality.
I also agree with you that there isn't tremendous day-to-day need for the m=
etadata 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 au=
dio 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 essenti=
ally worthless. So from the perspective of long term value and archiving fo=
r other's eventual use, if I had a choice, I'd say add an extra block to th=
e bwav/riff/whatever/ files and put the data there.
Best!
Steve P
--- In 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
> >
> >
>
>
> --
>
>
>
|