From jdalton@mpce.mq.edu.au Mon Apr 1 10:24:59 1996 Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!gatech!newsfeed.internetmci.com!news.kei.com!nntp.coast.net!news.mira.net.au!harbinger.cc.monash.edu.au!news.bhp.com.au!mel.dit.csiro.au!actcsiro!news.nsw.CSIRO.AU!metro!metro!sunb.ocs.mq.edu.au!news From: John Dalton Newsgroups: alt.binaries.sounds.d,alt.cd-rom,aus.computers.cdrom,comp.sources.wanted,comp.music.misc,rec.music.makers.synth,sci.music,sci.data.formats Subject: SUMMARY: Transferring Digital Audio Tape to Disk Date: Mon, 01 Apr 1996 15:54:53 +1000 Organization: Macquarie University Lines: 295 Message-ID: <315F6FAD.41C67EA6@mpce.mq.edu.au> Reply-To: jdalton@mpce.mq.edu.au NNTP-Posting-Host: avalanche.mpce.mq.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (X11; I; SunOS 4.1.4 sun4m) To: jdalton@mpce.mq.edu.au, arens@lsil.com, rwi@arcadia.cs.rmit.EDU.AU, corbet@stout.atd.ucar.edu, hoffmeis@enterprise.america.com, Steven.WALLRAF@is.belgacom.be, samvado@ai.net, brayman@aa.washington.edu, Nail.Own@lrz.uni-muenchen.de, kjj@primenet.com Xref: solitaire.cv.nrao.edu alt.cd-rom:57487 comp.sources.wanted:19110 comp.music.misc:1145 rec.music.makers.synth:85940 sci.data.formats:1434 This is a summary of responses to my enquiry titled "Q: Transferring Digital Audio Tape to Disk" *********************** ORIGINAL QUESTION *************************** First, here is a copy of my question, posted on 20th March 1996: > I wish to read songs off a DAT and store them on a hard disk (for > transfer to a CD). As I will be using a DAT drive normally used for > computer data, presumedly I will need software to extract audio > information from the data stream and dump it out in a useful format > (such as .WAV). > > Can anyone recommend software (source/free/shareware preferred) to > do this, please? Better still, does anyone have any software to > convert from DAT to CD-R in a single step? > > Alternatively, could someone provide information on the format of a > DAT recording? A friend has told me that this spec is freely > available. My searching has yielded references to "red books" and > "orange books", but no spec. I am prepared to write software to > interpret the contents of a DAT. This software would be released > under terms similar to GNU software. I do not wish to make money > out of information you provide. > > To avoid cluttering the newsgroup, e-mail (jdalton@mpce.mq.edu.au) > responses are preferred. I will post a summary of responses in a > couple of weeks. (No summary = No responses) > > Thank you in advance for your help > John Dalton ********************** "EXECUTIVE SUMMARY" ************************** At the physical level, audio DAT and the DDS (digial data storage) share a common format called R-DAT. Thus a DDS backup tape drive is able to succesfully read bits off an audio DAT tape. Before you get your hopes up, there is a spanner in the works. There are differences in the way the bits on the tape are interpreted. DDS tapes have a file structure imposed on them. In practice, the user never sees the raw bit stream off the tape as firmware in the drive handles all the low level interpretation. When an audio DAT is read on a DDS drive, the firmware will try to interpret audio data as control information and (presumably, I haven't tested this) signal an error. I can think of two ways around this: 1) Modify the firmware of the DDS drive to recognise audio DAT tapes, or 2) Get the DDS drive into a mode where it presents the user with a raw data stream, directly off the tape. The user can then interpret the information himself. Option 1: Silicon Graphics have released an Indy workstation with a DAT drive which can recognise and read an audio DAT. Hewllet-Packard DAT drives have downloadable firmware. Given the necessary information, it would be possible to write and download new firmware for the drive. This would probably be a lot of work, and getting the necessary programming information may be difficult. Option 2: It appears that a SCSI DDS drive can be put into a mode where it outputs a raw bit stream. Looking though the SCSI command set there appear to be options to turn off such things as error correction. I have also found an ad for a software product which claims to read raw data off a DDS drive. (The program is called TD RAW. See http://www.tapedisk.com/tpd01raw.html). If they can do it, so can I. I would appreciate pointers from any SCSI guru's out there on the command sequence to get raw data off a tape. Doing this will require detailled information of the format of an RDAT tape, and SCSI tape drive commands. I cannot find detailed info on R-DAT format on the web, so I have gotten a few books out of the library on the topic and am putting together a summary. Someday I will release it on the web. (It's a spare time job. Once it appears, it will appear at something like: http://www.mpce.mq.edu.au/~jdalton/rdat/) The most useful book I have found to date is: John Watkinson, "RDAT", Focal Press, 1991 ISBN 0-240-51306-1 The SCSI-2 draft spec is freely available on the web. I am still looking for a book which explains it in plain English. Of course there is a third option. Get an audio DAT player with a digital output and interface it to a computer. This does not suit my purposes. I am doing a favour for a friend by transferring a demo DAT to CD. Thus I do not want to invest large sums of money. I already have access to a DDS drive. I do not have access to an audio DAT player or an interface card. Apart from anything else, I'm looking upon this task as an intellectual challenge. In theory it can be done, so I want to do it. I imagine the results might also be useful to all those people out there who own DDS drives and are interested in experimenting with digital audio. >From the response to my question, I gather quite a number of people would like to read audio DAT tapes on a DDS drive. If you are experimenting with audio in DAT drives, be a little careful. DDS tapes have tighter specs than audio tapes. Thus it is possible that putting an audio tape in a DDS drive may damage it. Also be wary of putting DDS tapes in an audio drive. Standard audio tapes go up to 60m length. DDS tapes can be longer than 60m. I gather these longer tapes are thinner, and so might causes problems for the audio drive. I would think it is safe to use DDS tapes of length up to 60m though. This topic has been discussed at length in some newsgroups and is an independent thread. Please don't restart the thread based on what I have said. What I have said is not gospel, just my impressions. As further info comes to light, I will put it on my web page. Best wishes John 1/4/96 ---------------------------------------------------------------------- John Dalton Phone: +61-2-850-9070 Electronics, Macquarie University FAX: +61-2-850-9128 Sydney 2109, Australia email: jdalton@mpce.mq.edu.au WWW: http://www.mpce.mq.edu.au/~jdalton *************************** RESPONSES ******************************* Here are copies of the responses I got. Thanks to all those who responded I have taken the liberty of editing out any bits (mainly requests for info) which I thought were not particularly relevant. This section is also intended to be a form of acknowledgement. Most of what I said above appears in some form or another below. John Arens (arens@lsil.com) replied via email: # John, # I've worked on a project in which I read the raw data off a CD-ROM and # need the spec. The Red Book and Orange Books are the # specifications. You will need to find out about the format of the data # on the DAT and write a program to read raw records. There raw records # will be in the format discussed in the spec. # # Best of Luck # John Arens Ross Irvine (rwi@arcadia.cs.rmit.edu.au) replied via email: # I am in the same boat. I have audio on DAT that I need to burn to a # CDR, I've asked around uni and the only way I know I can get the # DIGITAL audio info off is to use a SGI Indy Workstation that has a DAT # and software on the indy called humm. dam, I can't think of it now. # It'll read the digital info off the DAT into a WAV. The software comes # standard with the Indy or the DAT one of the other.. # # The problem is reading the information off the DAT digitaly, as it's # easy to get a analog WAV out of it, just connect the line out of a DAT # machine to the line in on a Soundblaster and away you go. # # If you work something out. Please keep me informed. # # Regards.. Jonathan Corbet (corbet@stout.atd.ucar.edu) replied via email: # This will prove harder than you think. Almost no data DAT drives will # handle audio tapes -- they want to see the interrecord gaps there. # Only SGI drives are audio-capable, and I am not sure even they make # them any more. # # What you *can* do is get a PC card which handles the S/PDIF format, # then bring in the data off an ordinary audio DAT deck. A few of those # are available. # # Check out the DAT-Heads web site: # # http://www.atd.ucar.edu/rdp/dat-heads/ # # for more information about DAT, the format, and so on. # # Good luck, # # jon Edward Hoffmeister (hoffmeis@enterprise.america.com) replied via email: # i have no info on dat, but another issue you did not ask (you may or # may not have thought of) is what format do you want the audio in once # you cd-record it? (audio cd, cd+g, enhanced audio cd, or a cd-rom with # the audio in one or several files) and if it is a computer file you # again have many format and QUALITY choices. Steven Wallraf of Belgacom (Steven.Wallraf@is.belgacom.be) replied via email: [snip] # I am dealing with the same problem as you: # # I have to burn CD-R's with audio, which I will receive on audio DAT's. # These DAT's are recorded in a studio. # I have asked a lot of questions over here in Belgium, for example # directly at HP, if this is possible and how to do it. Even HP couldn't # give me an answer. Seems they don't know their own devices very # well :) # [snip] Samvado Gunnar Kossatz (samvado@ai.net) replied via email: [snip] # as much as I know there is no way to play audio DAT tapes on data # date recorders, if you know a way I would be very poleased if you # shared you knowledge with me # # greetings # sam # ---------------------- # http://lightage.com Vladimir Brayman of the University of Washington, (brayman@aa.washington.edu) replied via email: # Hello John, # # Regarding your question posted at alt.binaries.sounds.d newsgroup. A # good place to visit is Multimedia Information Sources home page: # http://viswiz.gmd.de/MultimediaInfo. There are lots of information on # different audio formats etc. [snip] # # Vladimir Brayman Nail Own (Nail.Own@lrz.uni-muenchen.de) replied via email: Nail has asked a question similar to mine and kindly sent me a copy of the responses he got. [snip] # Jim McLaughlin wrote in his manual to CDDA # (a DOS-based CD audio-extractor maybe known to you): # Can I use CDDA to read from DAT drives? # As far as I know there are only a couple of DAT drives out there that # allow reading of digital audio through SCSI. In theory, I could add # that feature to CDDA, but since I dont have one of those drive, and I # dont have the programming manuals either, I seems very unlikely that # this will ever happen. It also seems that these drive vendors have # taken out support for reading DA. Their story is that people were # putting cheap quality audio tapes in the drives and screwing up the # drives. So they took out the feature. My guess is that they were # getting pressure from the record companies. If you really need to do # this then get yourself a Silicon Graphics machine. They make sure # that this feature is available in their package. Dont forget to # mortgage your house to pay for it. # # Another one replied to my newsgroup post, here's his opinion to # my request (not too useful): # > I think this should work because there are programs for # > CD-ROMs to read digital audio through the SCSI-bus. # # That's not very good logic. # # >5 years ago, neither CD-ROM drives nor DAT data drives could # >do this. This requires quite a bit of special firmware # >support. A CD-ROM is different from an audio CD at a fairly # >important level, and similar differences are found in audio # >DAT and DDS. Playing them as music is much easier, since all # >you need is the converter from a portable CD or DAT player. # > # > SGI got a couple of manufacturers to create special drives # >that could do digital audio over SCSI, but it was a long time # >before other companies did this for CD-ROM. # > # >DAT simply hasn't been popular enough to warrant this attention. # >One argument from the manufacturers is that anyone who really # >needs audio DAT capability can get it with a $500-$1000 digital # >I/O card. # > # >When I worked at Sony (Sony makes HP DAT drives), I knew some # >of the engineers who were developing the Sony-HP DAT drives. # >I asked them about digital audio support, and they said that # >while it could be done, it was on the list of "don't"s for # >them. # > # >That doesn't mean it's still true - Sony people also considered # >MIDI a toy back then, and they now have several MIDI devices - # >but I wouldn't hold my breath. # >David Elliott - dce@netcom.com [snip] # Regards, Nail From bljones@baldric.ncsa.uiuc.edu Mon Apr 8 10:16:30 1996 Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!maui.cc.odu.edu!news.larc.nasa.gov!night.primate.wisc.edu!newsspool.doit.wisc.edu!uwm.edu!math.ohio-state.edu!howland.reston.ans.net!vixen.cso.uiuc.edu!bljones From: bljones@baldric.ncsa.uiuc.edu (Barbara Jones ) Newsgroups: sci.data.formats Subject: HDF Newsletter #20 Date: 4 Apr 1996 18:58:32 GMT Organization: University of Illinois at Urbana Lines: 145 Message-ID: <4k164o$qh7@vixen.cso.uiuc.edu> NNTP-Posting-Host: baldric.ncsa.uiuc.edu HDF Newsletter #20 April 2, 1996 HDF4.0r1 patch 01 is on the NCSA ftp server. Changes include: 1. Port to the PowerPC/68k Macintosh using the MetroWerks CodeWarrior(8) C compiler. The Fortran interface is not available yet. In addition, the netCDF interface works but currently you are unable to read old netCDF (XDR) files. You need at least CW8 to use this version of the library as previous versions had problems with the ANSI-C memory allocation routines. Precompiled code and source code can be found on the NCSA ftp server in: /HDF/HDF4.0r1/hqx/. As there was no HDF 4.0r1 release for the Macintosh, please refer to the /HDF/HDF_Current/release_notes/ABOUT_4.0r1 file as well as the /HDF/newsletters/Newsletter19.txt file on the NCSA ftp server, for information on what has changed in this release. 2. Port to Windows NT/95 using Visual C++ 4.0. The Fortran interface is not available yet. Precompiled code and source code can be found on the NCSA ftp server in: /HDF/HDF4.0r1/zip/. As there was no HDF 4.0r1 release for Windows NT/95, please refer to the /HDF/HDF_Current/release_notes/ABOUT_4.0r1 file as well as the /HDF/newsletters/Newsletter19.txt file on the NCSA ftp server for information on what has changed in this release. 3. A bug has been fixed on the SDS interface. Now the record number will be updated for UNLIMITED dimensions when ncsync (ncsnc) is called to write data to hdf files. 4. A bug has been fixed in the UNLIMITED dimension record to improve backward compatibility. 5. An option to generate binary output has been added to dumprig and dumpsds in hdp, the HDF dumper. It is in beta test stage. 6. Parameter 'class' in vffndcls() has been changed to 'vgclass' to avoid conflicts with the C++ reserved word 'class'. 7. All definitions for the names and classes of vdatas and vgroups that are created by the GR or SD interfaces and are used in hdf files have been moved to hdf/src/hlimits.h. These names and classes are reserved by HDF. Users' applications should not name their vdatas/vgroups using these reserved words. Pre-defined attribute names are included in hlimits.h as well. A list of these reserved names (and classes) is attached at the end of this newsletter. 8. Other bug fixes. Patch files are located in /HDF/HDF4.0r1/patches/ For HDF 4.0r1 patch 01, the entire source distribution, including the patch, is located in: /HDF/HDF4.0r1/patches/patchedsrc/ The READMEs in these directories explain how to apply the patch. HDF4.0r1 patch 01 has been tested on the Macintosh PowerPC and 68K, HPUX, IRIX5.3, IRIX6.1_64, IRIX6.1_32, SunOS4.1.4, Solaris 2.5, and Dec Alpha OpenVMS. Precompiled executables for these UNIX (except IRIX6.1_32) and OpenVMS platforms in /HDF/HDF4.0r1/bin/ on the NCSA ftp server, have been updated to HDF4.0r1 patch 01. Due to limited resources we do not plan to update the executables for other platforms. If any user has problems compiling patch 01 on other platforms please contact hdfhelp@ncsa.uiuc.edu. We will try our best to work with you. Known problems: 1. Hdp needs to be upgraded to dump objects created by the GR and AN interfaces. 2. Fortran routines (for example vsfwrit) that have a parameter that may be a character type or numeric type, do not work correctly on some systems, such as VMS and T3D. This problem will be corrected in the next release. 3. Some users indicated that the current limits on the number of accessible files/objects and size of vdata fields restricted their applications. These limits will be extended in future releases and versions. ------------- reserved names and classes ------------------------ By GR interface Vdata/vgroup names and classes: "RIG0.0" -- name of the Vgroup containing all the images in GR "RI0.0" -- name of a Vgroup containing information about one image in GR "RIATTR0.0N" -- name of a Vdata containing an attribute in GR "RIATTR0.0C" -- class of a Vdata containing an attribute Atrribute names: "FillValue" -- name of an attribute containing the fill value By SD interface Vdata/vgroup names and classes: "Attr0.0" -- class of a Vdata containing SD interface attribute "Var0.0" -- class of a Vgroup representing an SD NDG "Dim0.0" -- class of a Vgroup representing an SD dimension "UDim0.0" -- class of a Vgroup representing an SD UNLIMITED dimension "DimVal0.0" -- class of a Vdata containing an SD dimension size and fake values "DimVal0.1" -- class of a Vdata containing an SD dimension size "CDF0.0" -- class of a Vgroup representing all SD SDSs in a file "Data0.0" -- defined but not used yet "VALUES" -- field name of a vdata which contains values of an SD attribute Atrribute names: "_FillValue" -- user defined fill value "long_name" -- data/dimension label string "units" -- data/dimension unit string "format" -- data/dimension format string "coordsys" -- data coordsys string "valid_range" -- valid range of data values "scale_factor" -- data calibration factor "scale_factor_err" -- data calibration factor error "add_offset" -- calibration offset "add_offset_err" -- calibration offset error "calibrated_nt" -- data type of uncalibrated data