Jeff,
Some follow through on your thoughts below:
John
John Spencer
www.bridgemediasolutions.com
On Jun 9, 2005, at 9:56 PM, Jeffrey Kane wrote:
> I specifically was referring to DAT. As an amateur, I only have
> very limited
> experience with ADAT and none with DTRS or DASH. I have personal
> experience
> with DAT, LTO, AIT and DLT used for data archival. The principle
> applies to
> all of the above unless my understanding is mistaken.
>
> As an example; say a track is archived to both DASH and LTO. After six
> years, both are pulled out to restore the material (remastering,
> what have
> you). For whatever reason (environmental problems, magnetic field
> exposure,
> handling damage, oxide shedding, etc) both tapes are damaged and 5
> feet of
> tape is rendered useless. In the case of the DASH reel, only the
> material
> contained in that segment of tape will be lost, the rest can be
> recovered.
> In the case of the LTO tape, whatever file that section of tape
> contained is
> lost in it's entirety. Were the LTO tape to contain separate files
> representing the tracks on the DASH master, one entire track would
> be lost
> as that file written to the area now damaged cannot easily be
> reconstructed
> (or not at all if the material were compressed, encrypted, or
> both). Were
> the LTO to contain one large file containing the separate tracks
> (say a Pro
> Tools Macintosh Stuffit archive, necessary to preserve resource
> forks), the
> entire project would be lost.
OK, a few issues with this comparison.
1. 6 years from now, i have very little faith that I will find a
DASH machine. I trust that I would have migrated my LTO tape, and
have made a second one as well. The difference in the price of tape
alone would have allowed me to make (10) LTO tapes as opposed to my
(1) DASH reel.
2. While DASH was supposed to support razor-blade editing, that
won't be a "noiseless" edit.
3. One would not use Stuffit to write a data archive, or any
application that uses compression.
4. One should not be writing TAR archives of files that have
resource forks (I guess you are referring to Mac OS9 files?), as you
can lose the resource fork as the archive is being written. That's
not the data storage tape's fault, it's the operator's.
5. It is commonly accepted that you should be saving wav files or BWF.
>
> Obviously exceptions exist. I maintain that data archiving methods
> offer
> greater data resilience; digital audio storage methods suffer less
> data loss
> when damage results in unrecoverable errors.
>
Isn't "when damage results in unrecoverable errors" more of an
exception than a well thought out methodology of data migration?
I'll place my bets on data storage tapes over digital audio tapes
anytime, and I can think of a number of institutions that migrated
analog reels to R-DAT who will bet with me.
Obviously, exceptions exist everywhere, but to focus on catastrophic
situations blurs what can be a manageable problem.
>
>
> -----Original Message-----
> From: Association for Recorded Sound Discussion List
> [mailto:[log in to unmask]] On Behalf Of John Spencer
> Sent: Thursday, June 09, 2005 8:08 PM
> To: [log in to unmask]
> Subject: Re: [ARSCLIST] Longevity of data tape?--
>
> Jeff,
>
> I was curious if you could elaborate further on your initial post:
>
> "With digital audio tape the error only affects that portion of the
> recording"
>
> Which format of digital audio tape are you referring to? R-DAT/
> DASH/ PD?
>
> Were you stating that you prefer digital audio tape formats to
> Enterprise-class data storage tapes?
>
> John
> John Spencer
> www.bridgemediasolutions.com
>
>
> On Jun 9, 2005, at 4:52 PM, Jeffrey Kane wrote:
>
>
>> I don't believe I explained myself properly. Most backup
>> applications will
>> skip a bad block (or even several blocks) of data and continue the
>> restore.
>> What I describe arises when the corruption exceeds the ability of the
>> software to recover from errors. In that case, an entire file (or
>> several if
>> not the whole tape depending on the location of the error) will be
>> rendered
>> unrecoverable. The validation of the archive/backup at the time
>> only ensures
>> the initial process succeded. The problematic variable is between
>> archival
>> and retrieval. With digital audio recordings, such errors will only
>> render
>> that portion of the recording unrecoverable.
>>
>> As for error correction, that is a function of the format (AIT/LTO/
>> DLT/etc)
>> and software used for backup/archival. On 'trusting' a datatape to be
>> readable 25-30 years from now; I completely agree. That is the
>> figure I
>> recall being used when discussing longevity. In my case, I re-archive
>> critical material every three years. Data on tape IMO is far too
>> susceptible
>> to corruption to be relied upon for a longer timeframe than that.
>>
>> Jeff
>>
>>
>>
>>> -----Original Message-----
>>> From: Association for Recorded Sound Discussion List
>>> [mailto:[log in to unmask]] On Behalf Of John Spencer
>>> Sent: Thursday, June 09, 2005 2:47 PM
>>> To: [log in to unmask]
>>> Subject: Re: [ARSCLIST] Longevity of data tape?--
>>>
>>> This is an incorrect statement. There are various backup
>>> applications that will skip a bad block of data and continue
>>> the restore process, as well as applications that will report
>>> on the quality of the data archive as it is being written.
>>> Error correction is not a function of the data storage tape itself.
>>>
>>> And I would never trust a data storage tape to be readable
>>> 25-30 years from now.
>>>
>>> John
>>> John Spencer
>>> www.bridgemediasolutions.com
>>>
>>>
>>> On Jun 9, 2005, at 2:36 PM, Jeffrey Kane wrote:
>>>
>>>
>>>
>>>> I've seen the figure 25-30 years bandied about for data tape. Data
>>>> backups are a double edge sword. They have better error
>>>>
>>>>
>>> correction so
>>>
>>>
>>>> the data is more resilient. However, if there's an
>>>>
>>>>
>>> unrecoverable error
>>>
>>>
>>>> it renders ALL data for that particular file (and if it's in the
>>>> directory area, all data on the tape) unrecoverable. With digital
>>>> audio tape the error only affects that portion of the recording.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
|