All,
After consulting with a few friends (thanks Paul, Bill & John) I have
come up with the following analysis of how the Mac Finder works with
audio files.
On my iMac running OSX 10.4.11, I transferred WAV files from a Sound
Devices recorder using a USB card reader, and also a firewire
connection. Checking these WAV files on my computer, the Finder
invariably shows the creation date as 01-01-1904. The modified date
gives the date-time the recording was made (assuming I don't edit the
file). However, during the summer months the iMac decides that I
should be using daylight saving time, and adds exactly one hour to
the time that had shown on the screen of the SD recorder when I made
the recording. When I look at this same WAV file in Wave Agent
application, the original date-time shows up accurately.
I emailed a short WAV file to John Tudor who has OSX 10.5.8.
Creation and modification dates were shown in his Finder, but showed
the time that John received and opened the WAV file, not the true
creation date.
So I am left wondering, if I ever upgraded my OS, would I be likely
to lose the modification dates of hundreds of files already
transferred to computer and hard drive? I do rely on the mod dates
when I am transcribing my recordings. I am able to transfer WAV
files to an external hard drive, and back to the computer again, and
the mod dates are unchanged.
I also sent a short WAV to Bill Rankin who has a PC. Looking in his
PC File Information, Wave Properties, EBU extensions, the creation
date showed up correctly. Bill then edited and saved the file. The
creation date still showed up correctly. Bill sent the file to me.
My Finder information had been changed, but the creation date still
showed up correctly in Wave Agent.
Wave Agent does not give correct date-time for WAV files that I have
recorded on the Olympus LS-10. So I need to hang on to those Finder
modification dates as sometimes that is all I have to guide me as to
original time and date of a recording.
I tried using Ditto-Script (per suggestion by Paul) but this was
unsuccessful in retaining correct dates-times.
Moral: When recording always verbally give date and time, at least at
start and end of any batch of recordings! Don't rely solely on what
your computer tells you!
cheers,
Vicki
On 24/04/2010, at 2:04 PM, Paul Jacobson wrote:
> Hi All,
>
> I came across a page which neatly summarises the issues of
> creation date handling on Win2K, Mac OSX, and Linux from an
> archival perspective. It's worthwhile (perhaps even compulsory)
> reading for anyone who is relying on creation dates as the primary
> time stamp on their files.
>
> http://thomas.kiehnefamily.us/whats_in_a_creation_date
>
> "Each of these experiments shows how the assumptions of the
> software makers dictates the behavior of what seem to be common
> sense concepts, thus threatening the validity of assumptions we
> make while using them. In the case of Windows, the assumption is
> that any copy operation creates a new file and is treated as a new
> object, but leaves behind a paradoxical situation where the
> modification date precedes creation. In Macintosh, every copy of a
> file, so long as it is made on a compatible volume, can be traced
> back to the original object by creation date -- in essence, every
> copy of a Macintosh file is simply a new version, not a new object.
> Linux, on the other hand, repairs the Windows dichotomy by bringing
> the modification date forward with each new object instance.
> At the surface, we may want to proclaim that filesystem metadata
> cannot be trusted and debate the merits of ignoring it completely.
> This is understandable, but perhaps a bit hasty. It might be better
> to consider filesystem metadata as helpful to the extent that it
> has been properly maintained during the record's lifetime. Since
> creation and modification dates support authenticity it only seems
> fitting that our treatment of their apparent flaws should derive
> from similar concepts. In other words, the lessons of this
> experiment should not only guide the handling of digital objects in
> a repository setting, but in assessing the reliability of
> filesystem metadata as generated in the originating environment. If
> the recordkeeping systems that generated the digital objects,
> including policies and documented procedures outside the systems,
> if any, can be assessed, then the metadata accompanying the objects
> may be salvageable. Without such knowledge, though, it is wise to
> treat any and
> all filesystem metadata with prejudice."
>
> cheers
> Paul
>
>
>
|