Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
Message-Id:	<5.1.0.14.0.20010605165410.026d7a28@civil.ubc.ca>
X-Sender:	bwalker AT civil DOT ubc DOT ca
X-Mailer:	QUALCOMM Windows Eudora Version 5.1
Date:	Wed, 06 Jun 2001 10:36:42 -0700
To:	cygwin AT cygwin DOT com
From:	Brian Walker <bwalker AT civil DOT ubc DOT ca>
Subject:	DDS audio tape drives with Cygwin
Mime-Version:	1.0

Hi,

I just joined the group and it looks like a wonderful resource - I'm not 
too sure on the protocol here so someone kindly let me know if I'm outta 
line.......

I recently purchased a DDS2 tape drive capable of reading my audio DAT's 
and have been looking for software that can extract audio from the drive in 
Windows (Win2k).  The drive is a Conner Archive 4mm 4/8 GB tape unit with 
firmware capable of reading DAT.

While searching for other software I came across the program called 
"read_dat" for the *nix environment.  I grabbed the source code and managed 
to compile the program to work under Windows using Cygwin.  I also managed 
to mount the drive in Cygwin's bash shell as /dev/st0.  My problem is that 
the WAV files output from the DDS drive through read_dat are problematic - 
they sound like very loud static.  I've tried to mount the drive in binary 
and textmode and got the same results both ways.

I had a look through these archives and found some info issues relating to 
different block size in Linux and Windows.  I'm not sure if that is my 
problem given that "data on an audio DAT tape is laid out in 5822 byte 
frames. The first 5760 bytes of each frame are used for sound. The last 62 
bytes of the frame, i.e. frame[5760..5821] contain information about the 
recording rather than sound"  So I thought that the program would deal with 
block size based on the DAT standard - is that an erroneous assumption?

One of the "known bugs"  for read_dat is that its "untested on big-endian 
machines" . Is this a factor for me in under Windows?

Does anyone have any idea what the problem might be and if there is an easy 
fix?  Thanks much for any input!
Cheers
Brian


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

- Raw text -