Hi Dave:
This is useful but here's a question -- can the DAT-to-PC software correct and mask errors like a
DAT player can? If the goal is to recover the audio, I'd think the goal would be to have all
correctable errors corrected. My experience with DATs is their downfall is mechanical-digital
recovery errors not correctable by on-board mechanisms. If PC-drive transfers are better at
mitigating this, that's great news. I guess another question is, is "bit-perfect" really possible
with DATs unless you're in a stretch of tape that was recorded mechanically perfectly and plays back
mechanically perfectly?
-- Tom Fine
----- Original Message -----
From: "Dave Rice" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Wednesday, January 20, 2010 5:14 PM
Subject: Re: [ARSCLIST] DAT ripping
Hi Tom,
I think one of the 'better' aspects to the process was not any difference in the audio itself but
the utility of the non-audio data. The ability to report on errors from the tape read is more
accurate that error detection tools which work by audio processing which may result in over- or
under-reporting. DATXtract reports on error like this (when the data isn't read from the tape
accurately):
Including error frame:
Channels: R
Abs: 00:00:21.02 Prog: 00:00:18.02
File start: 00:00:04.30
File end: 00:00:04.31 (1323 samples)
With these reports we could focus our quality control work on areas of audio with known errors
rather than scanning all of the data.
We recently wrote up a article on utilizing error reporting from digital tapes, specifically on DV
audio, at http://www.avpreserve.com/dvanalyzer/audio-errors/, which discusses some of the technical
background, reasoning and methodology in error digital on reformatting of digital tape migration.
Dave Rice
On Jan 20, 2010, at 4:27 PM, Tom Fine wrote:
> Hi Jim:
>
> How could the data be "better" than a direct-digital out from a properly-working player (ie no
> head problems or mechanical issues)? I thought the main advantage of the computer-drive method was
> to save time. Is there more to it?
>
> -- Tom Fine
>
> ----- Original Message ----- From: "Jim Sam" <[log in to unmask]>
> To: <[log in to unmask]>
> Sent: Wednesday, January 20, 2010 12:45 PM
> Subject: Re: [ARSCLIST] DAT ripping
>
>
>> All,
>>
>> First, Dave, that information is very helpful.
>>
>> That said, I didn't ask because I'm worried about the theory. I was asking
>> for a collaborator in testing.
>>
>> The theory's been discussed before on this list, and I'm aware that more
>> than one person/organization has experimented with this to some success. It
>> was also *briefly *discussed at last year's conference in DC. However,
>> every time I've seen a discussion about the topic, it has never come along
>> with what matters to me: testing to make sure what's coming off the DDS
>> drive is the same (or better) data than what would go down the AES/EBU
>> pipeline.
>>
>> I'm still extremely interested in this situation, and after having had to
>> deal with other similar formats, I've got ideas for testing that I'd like to
>> do. But I don't have a working DDS setup here. I could build my own, which
>> I might do, but that's a can of worms, and there's other things to be gained
>> by having a collaborator in these tests.
>>
>> Thanks,
>> Jim
>>
>>
>>
>> On Tue, Jan 19, 2010 at 4:05 PM, Jim Sam <[log in to unmask]> wrote:
>>
>>> I am inquiring if someone that's transferring DATs via DDS, etc., drives
>>> would be willing to transfer a few DATs for me. I'm interested in this to
>>> see how it compares to real-time AES/EBU transfers. Having data from
>>> established setups would be very, very helpful.
>>>
>>> If anyone's interested in this, please contact me off list. You can reach
>>> me at [log in to unmask] or through this gmail address.
>>>
>>> Thank you,
>>>
>>> Jim Sam
>>> Audio Specialist
>>> Hoover Institution Archives
>>>
|