DAT Recorder

Back in 1997 I needed some recorder for non-stop audio recording of long sessions at a reasonable quality. Instead of buying a “natural” DAT recorder I decided to build my own based on an off-the-shelf DAT streamer, an audio codec, and some other hardware in between both.
The prototype of the first revision of the hardware is still working fine now and it is still used from time to time.

For latest news on this project see at the end of this page!

Hardware

The hardware consists of the following components:

  • Analog Devices AD1848KP Stereo Audio Codec for 16-Bit AD/DA conversion
  • WDC 65C816, 16-Bit CPU for general purpose control and compression software
  • WDC 65C22 VIA for several IO stuff
  • 128kB local RAM + 128kB local Flash ROM for CPU code
  • Real Time Clock
  • AMD Am53C96 SCSI controller
  • 512kB buffer memory for audio data (1/4 for non-compressed data, 3/4 for compressed data)
  • 3 Lattice ispLSIs (1 ispLSI2032, 2 ispLSI2096) for general control, DMA function and bridging stuff
  • 2 line / 16 charachters per line LC-Display and some keys
  • Sony SDT-5200 DAT Drive (DDS2, 4GB without compression)

The DAT drive is controlled via standard read/write block operations. The block size is 64kB. Filemarks are used to handle different recording sessions.

The Board

The PCB is a 4-layer, 13x10cm sized board and mounted on both sides mainly with surface mounted devices (SMD).


Top Side

Bottom Side

The board is designed with Eagle from CadSoft. The PCB is manufactured by Beta Layout and the chips are mounted by my hands.

Software

The system is running with a small Real-Time Multitasking Operation System that basically evolved from the OS I developed for a board computer used in a model boat. There are three main deamons running:

  • Playback/Capture Daemon
  • Decompress/Compress Daemon
  • Read/Write Block Daemon

All daemons are coupled via elastic buffers (organized as ringbuffers). This means that the Decompress/Compress Daemon tries to fill/remove data to/from the Playback/Capture Daemons buffer.
The Read/Write Block Daemon reads/writes data from/to the DAT drive whenever there is free buffer space or a new block in the decompress/compress buffer available.

Compression Algorithm

Since the 65C816 CPU is a relative simple processor and performs about 3MIPS at 12.5MHz, there is not a lot of calculation power available. Therefore things like frequency analysis as used in MiniDisk systems are impossible to do. The used compression method is a very simple one based on the difference between the last and the current sample. If the difference can be represented using only 8 bits, then only the difference is written to the tape, otherwise the whole sample is written. In reality, the used algorithm differs a bit from that, but that’s the principle.

Although the AD1848 offers 16-bit wide samples, I use only 12 bits of one 16-bit sample. I started with 16-bit samples, but tests showed that there is no difference when comparing with 16 bits (in any case my ears can’t differ between them). In contrast to MiniDisk, no data is lost during compression (except the four least significant sample bits).
Another aspect that relaxes the situation a little bit is the fact that the recorder is primarily used to record radio sessions. And the signal received through am FM receiver is anyways not from a very high quality.

The maximum achievable compression rate is 2:1. Reality shows a typical compression rate of 1.5:1. With a sample rate of about 41kHz one 120m DDS2 DAT cartridge can take up about 10 hours of stereo sound.

Problems

There are several problems originating from the used DAT technologie and the DAT drive itself.

  • Every time the cartridge is removed out of the drive it is rewind.

    This is necessary because the drive has to read an identification when the tape is inserted again. This identification is placed at the beginning of the tape.
  • When data is recorded, older data written to the tape is lost, although it is not overwritten. Thus only one block written to the beginning of the tape practically deletes all former data.
  • Real Time violations at the DAT drive

    The DAT drive has a sustained throughput of 366kB/s and a buffer size of 1MB. The design requires in worst case about 170kB/s. But sometimes the drive is unable to accept or deliver data for short times (max. 3 seconds). Normally, the large 1MB buffer should compensate these effects, but it seems that the drive uses a buffer handling different to that used at the rest of my system. On reads, it doesn’t fill the buffer when there is space for a new block, but only when the whole buffer is empty. Similar for writes.

To Do

Especially the handling of the system is not very user friendly yet. Further there are some things to be added to the software like a correct detection of media changes and filemarks (currently, the system hangs up when a filemark is reached during playback 🙁

In case of the hardware there is nothing to do expecting a possible upgrade of the buffer memory to 1 or 2MB. This is necessary to compensate the above described problems with the DAT drive. But this is is not so urgent since the problem only occurs about every 15 to 30 minutes.

Latest News

Several improvements were made in last time:

  • A mono-recording feature was implemented. This effectively doubles the recording time.
  • The Sony SDT-5200 DDS2 DAT drive was replaced by a Sony SDT-10000 DDS4 DAT drive. This new drive is capable to store 20GB of data (uncompressed). This capacity equals five time the 4GB of the DDS2 drive. Stereo recording time should be between 55 and 60 hours with a DDS4 cartridge (not tested yet).
    Also the new drive eliminates the real time problems which occured with the older one. This is achieved by the higher sustained throughput (more than 2MB/s) as well as by the large 10MB data buffer included in the drive.

Planned work for the future:

In the next time a total revision of the hardware is planned. To get more processing power, a 32Bit SHARC DSP from Analog Devices will be used. Probably, it would also be interesting to use an MPEG-3 encoding/decoding chip for compression purposes.
However, it is questionable whether a new revision will be built. Currently there’s no more a big demand for long-term audio recording, and meanwhile there are many consumer solutions available that can do the job as well.

For questions and comments send your emails to Mario.Trams@digital-force.net