I use a similar associated .rtfd document arrangement so that I can
include photos of the location, logging notes and "screen shots" of
info that is easier to capture with that method. The text in such
documents searches extremely efficiently. Simply including a text
reference to a whole set of photos or other relevant recordings with
corresponding file names is easy and powerful.
It would likely create quite a debate to try and agree on all of the
categories to include in a standardized "record," but we might be
able to settle on the the first 25 items (or so) and assign the next
25 as individual user defined. These would increase datdbase
abilities. The programming could even include the ability to instruct
the database application to display only user defined info in
creating the archive on-line pages with personal preferences/touches.
This ability would not have to interfere with the data base use of
other "required" fields.
I suspect one, early step is to determine the database application to
use on the server that will read the associated docs added to the
archive, compile the info into master record (for play listing and
sorting) and produce the individual web display pages for each
recording (and a page of for a _group_ of recordings I imagine in
some cases). I'm sure there would interest in using the same
database application for one's own personal archive so the
application we use should be cross-platform and free. For people who
are currently using a tabbed index system, like Filemaker or Excel, a
conversion program can probably be made to automatically translate
those records.
Can anyone on this list direct us to someone, or perhaps IS the
someone with sever database programming skills? If not, I can start
looking for such a person. As for the entries that should be
required with each sound/recording upload, maybe another group could
start working on that? With simple directives from that group,
perhaps we could start uploading excel sheets (or ?) along-side mp3's
with 5? or so required fields to create a pool of test files the
programmers could use to develop the programming. I think GoogleMaps
can convert a place into coordinates.
What I'm suggesting is the resource we are planning might best be
reversed-design from a very smart, future-looking automated on-line
resource. The whole archive, even individual files could be as
accessible or as protected as one prefers. Rob D.
At 9:28 AM +0200 5/7/07, Gianni Pavan wrote:
>Hi all,
> I'll like a lot to have a recorder able to log all possible
>info about the recording... at present, when I record on a laptop or
>on a tablet (very soon I'll test a Samsung Q1 for field recording) I
>use my own software that logs date, time, gps position (if a gps is
>connected) and technical info I set at the beginning of the
>recording. For maximum safety I embed in the filename as much
>information I can, including sample rate, bit depth and number of
>channels. This is useful in case something goes wrong and the header
>results corrupted. With all that data in a filename (that can be
>corrupted too) and in a txt logfile, I normally can restore the
>corrupted files (if it happens...). Moreover, all that info in the
>filename helps a lot when I browse through thousands of files, or
>when I give a copy to someone.
>
>Gianni
>
>
>At 06.32 07/05/2007, you wrote:
>
>>Walt, you wrote,
>>
>> >The majority have no or little scientific value. The detailed habitat
>> >and site documentation is not there. Often there is no precise locatio=
n,
>> >no weather data and so on. For bioacoustics, the equipment is unreliab=
ly
>> >calibrated if it's calibrated at all. There is no detailed protocol
>> >statement. That does not make them of no value, just seriously wounds
>> >any scientific value. It especially makes elaborate analysis of the
>> >sonograms and so on of poor value. Unpublishable, the pros can't use i=
t.
>>
>>I'm painfully aware that much of that applies to my efforts. I think
> >the only solution will be to make the collection of most of that data
>>automatic. Again, if the lowly .jpg carries with it the camera and
> >exposure data, why not the lowly .wav carrying mic id, recorder type
>>and settings, location and time...with an easy way to note additional
>>stuff while recording.
>>
> >-Dan Dugan
>>
>
|