This question of errors is what seems to me attractive about the DDS
approach - there can be no concealment in the retrieval of a data file, or
your spreadsheet goes on the fritz. If we have something which only repairs
correctable errors, then we know that the file retieval is as accurate as
the mechanism allows, and we can set about repairing the damage. Where
concealment is implemented, we never quite know whether what we are getting
back is what we put in. I remember Tony Griffiths of Decca expounding this
with his usual enthusiasm - "we don't put concealment in our machines -
either it works or it's broken, and if it's broken we fix it!"
----- Original Message -----
From: "Tom Fine" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Wednesday, January 20, 2010 10:50 PM
Subject: Re: [ARSCLIST] DAT ripping
> 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
>>> First, Dave, that information is very helpful.
>>> That said, I didn't ask because I'm worried about the theory. I was
>>> 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.
>>> 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
>>> 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
>>> I'm still extremely interested in this situation, and after having had
>>> 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,
>>> I might do, but that's a can of worms, and there's other things to be
>>> by having a collaborator in these tests.
>>> 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.,
>>>> would be willing to transfer a few DATs for me. I'm interested in this
>>>> 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
>>>> me at [log in to unmask] or through this gmail address.
>>>> Thank you,
>>>> Jim Sam
>>>> Audio Specialist
>>>> Hoover Institution Archives