From: Lang Elliott <>
>
> Let's talk about file naming conventions.
>
> There are so many different options. The big collections such as MLNS (La=
b
> or Ornithology) and BLB (Borror Lab of Bioacoutics) simply give each
> recording a number based on when the recording was archived. That number =
is
> tied to a relational database. Numbers can generally reflect when a
> recording was made (=3D low numbers were made in the beginning of one's
> recording career, while the highest numbers are more recent recordings).
> The advantage of using a simple numerical system is that filenames will
> always be quite short. Who among us would ever exceed 99999 recordings in
> their collection?
>
> One can also name recordings by date. For instance, "950612_1" could mean
> this is the first recording made in 1995 on May 12. The reason to place t=
he
> 95 first is that if all recordings were stored in one place, they'd all l=
ine
> up by date, which could be useful.
I do use the year, but don't get into the exact date. I start year, then
a letter that indicates what it is (A=3Daudio, P=3Dphoto etc.) followed by,=
in the case of audio a disk number and track number. I'm a optimist and
my system will allow for up to 999 disks per year with up to 999 tracks
each. I do add the 3 letter suffix, mostly because it looks like the OS
folks will never learn to handle that without messing up the filename.
The Mac OS could handle that, the OSX imitation mac cannot get it right.
My names, therefore, track in order.
The simple index number would be ok by me, but it takes little filename
space to do a name that provides more info.
> In cases where one's recordings may end up in another collection, it migh=
t
> be important to add a recordist identifier at the end, such as the follow=
ing
> for Lang Elliott: "950612_1_LE". But now we're running well beyond the
> 8-digit limit mentioned by Marty. But is the 8-digit limit important thes=
e
> days?
The 8-digit limit is essentially obsolete. I'd not worry about staying
within it. That said, I find the use of long descriptive filenames
shortsighted. Disk and folder contents displays really can't handle
those well. It's better to stick to reasonable lengths that will fit in
standard contents displays given in a readable font size.
It's one of my pet peeves that when windows folks were freed from the
8.3 convention that they started naming things with whole paragraph long
names.
> Not worrying about the length of a file's name allows for an animals
> complete common name to be used: "scarlet tanager_1". But this gets a lit=
tle
> unweildy at times: "Greater Angle-winged Katydid_1". The nice thing about
> using a common name (or a scientific name) is that content is immediately
> apparent from the file name itself.
>
> But then what does one do with soundscapes, or mixed choruses? Maybe "mix=
ed
> chorus_1" or "soundscape_1".
It works poorly, particularly with frogs, where I might have 8 different
species calling, plus a few birds and lots of insects. And, even after
I've named the file might discover another call in the recording.
Also when you use very long names and the file display truncates them,
it typically cuts off the end data, which is often critical. Say you
have a hundred Greater Angle-winged Katydid recordings and the file
display gives you Greater Angle-winged Katy...
Walt
________________________________________________________________________
________________________________________________________________________
|