Re: DAT playback issue- refresher course needed

Steve Maki <steve@xxxxxxxxxx> wrote:
On 10 Jul 2008 09:30:57 -0400, kludge@xxxxxxxxx (Scott Dorsey) wrote:

The SV-3700 has one of the best transports built. However, the converters
are just godawful, and the interfaces are nonstandard and do not actually
meet AES/EBU specifications. They will usually work with most AES/EBU devices
but not always.

If you needed a reliable DAT player for the simple task of getting material
off of hours and hours of tapes (recorded on many different machines), what
would you look for? There seems to be no shortage of models to choose from
on ebay.

Get something, then get it aligned and gone over by a good tech, then use it.

I am personally very partial to the Tascam DA-20 and the Fostex D-5 (basically
the same machine although the D-5 allows error reporting). They feel very
cheap, but they are actually extremely rugged and seem outlast the competition.
If they are properly set up, they are better at reading misaligned tapes than
most machines too.

Eddie Cilletti prefers the Sony PCM-R500, which is also one of the last
generation of machines made. It's also pretty solid.

I ran across a Roger Nichols rant http://www.rogernichols.com/EQ/EQ_91-12.html
which convinces me that digital transfers to/from DAT can be a can of worms, so
I'd like a machine that had good analog out in addition to (relatively)
standard digital I/O and a reliable transport. Oh, and not one of the machines
still commanding $2000 type prices.

There's nothing wrong with digital transfers, and you will never have a bit
of problems with them as long as you avoid Panasonic machines. Panasonic
refused to obey the AES/EBU standard in several ways, opting instead to send
their representatives to the standards committee meetings where they demanded
the standard be changed. Do not use the SV-3700.

For the most part, SCMS is a non-issue in the modern world, although it
can be an issue if you want to make DAT-DAT dubs.

Nichols also makes a point about the 32 ksamp/sec standards... there are
two of them, and if you actually have tapes that use them, you need to make
sure you have a machine to play them that obeys the same standard. I have
never actually encountered this problem in the real world because the
32 ksamp/sec standards both sounded pretty awful and nobody in their right
mind ever used them.

His comment about the consumer format always having incorrect checksum is
also totally incorrect... the consumer format has no checksum at all, and
it uses those bits for other functions. This also is a non-issue... if
you have an interface that meets the standards (ie. not Panasonic) it all
works seamlessly.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
.

Relevant Pages

  • Re: Accessing Apps through RWW
    ... It is Standard with 2 nics. ... When I setup the machines using the connect ... computer wizard I got a message stating that I am not authorized to view this ...
    (microsoft.public.windows.server.sbs)
  • Re: LSE64 in standard Forth
    ... complement machines for ages, so it's simply the same thing as with C: ... two's complement unless you are on a really exotic piece of hardware. ... But in Standard Forth it's not well defined, not because of the two's complement issue, but because of the size. ... Three of the four C implementations listed in K&R edition 1 are 8/16/32 bit machines. ...
    (comp.lang.forth)
  • Re: #define BITS_PER(x) (8 * sizeof(x))
    ... People are allowed to present hypothetical machines to make a point. ... (Committee oversight is not an adequate answer; ... needs to evolve, let it evolve.) ... Put in a request for it to be added to the standard. ...
    (comp.lang.c)
  • Re: Questions, please
    ... But the standard itself is a human construct. ... So why does the standard specify that -1, of all things, must cast to ... on these machines the cast ...
    (comp.lang.c)