What Is A DDR (1995)?

Many companies have claimed to have created a Digital Disk Recorder, or DDR, yet the term remains largely undefined. Drastic Technologies has been working with and creating nonlinear VTR and animation solutions for over ten years. Drastic's background in single frame animation, broadcast VTR control, MIDI systems and automation, audio post editing and traditional video editing systems have culminated in the design and implementation of the Titan Series DDRs. The following description serves as a guide to Drastic's interpretation of what constitutes a DDR. This synopsis is based on Drastic's experience in the markets it has been serving.

The Basics

  • The DDR must provide the highest possible quality when storing audio and video information.
  • The DDR must operate with the minimum amount of user intervention, but allow enough flexibility to be customized by the user for special applications.
  • The DDR must operate as a standalone unit as well as integrate into a standard production environment easily and completely. No concessions to its performance may be made simply because it is a DDR.


Instantaneous Video/Audio Access

  • All video and audio data on the DDR must be instantaneously accessible at any time.
  • The video and audio data must exist within a framework that makes that instantaneous data access easily available to users.
  • The DDR cannot introduce any layer of confusion, delay or inaccuracy to the data it stores.


Nonlinear Playback And Digital Slow Motion

  • The DDR must be able to access timebased data in a nonlinear fashion.
  • Within the limits of the medium, the DDR must be able to replay data in different timebases than it was originally recorded. As the media is digital, the only limitation should be that of the incoming source.
  • The nonlinear and motion control features must be available to the user without the need for changes in current control technologies or the need to use 'extended' protocols and controls.


Video Production Integration

  • The DDR must integrate into the traditional production environment for which it is intended, be that video, audio, audio for video post, slow motion playback or spot playback.
  • The DDR must support the current protocols and procedures in use for operating in those environments, as well as provide extensions for fuller use of its capabilities.
  • The DDR should not complicate the user's working structure. Changes that will ultimately improve work flow must be implemented in harmony with the work flow already in place.


Complete VTR Emulation

  • Since one of the goals of a DDR is to replace a broadcast editing VTR, it must provide a complete emulation of a VTR's operation, command protocols and capabilities.
  • The DDR must respond accurately to the commands that would normally be used with a VTR. Some aspects of the editing/playback process such as seeks may be altered, but the essence of production must remain.
  • If necessary, the controller should be unable to tell that it is connected to a DDR and not connected to the VTR that disk recorder is emulating.


VTR Control Extensions

  • Protocol and control extensions must fit within the framework of the current control protocols to be easily implemented and gain acceptance. Entirely new protocols, or obscure protocols are useless if they are not supported.
  • Other protocols (such as MIDI, LaserDisc and Hardware Controllers) must be supported as required by the intended application of the DDR. For instance, to operate effectively as an Audio for Video Post DDR, Sony/SMPTE 422, MIDI and LTC control would be required as a minimum.


Frame Accurate Editing and Preview

  • To operate effectively as a standalone or integrated peripheral, a DDR must be frame accurate.
    To make use of its frame accuracy, and other capabilities, the DDR must support full editing functions as well previews of those edits.



  • The DDR must conform to operating standards expected by editing professionals
  • The connections to and from the DDR must be industry standard and easily available. The DDR must be able to be integrated as any other piece of equipment would be in the environment it is intended for.
  • The construction should be such that it is resilient in operation in its intended environment.
  • The control and alignment system should correspond and integrate into its intended environment

Following is a description of Drastic's first DDR, released in 1996.


VVCR Description


Digital Access

The most important aspect of VVCR's handling of audio and video is its ability to instantaneously access any recorded video or audio at any time. Because of Drastic's Fast File System (DFFS) and specialized memory buffer handling, the VVCR is fully capable of completely nonlinear playback within a traditional RS-422 control situation. Using the VDR Sony extensions or Drastic's custom S2 command set, this random access may be further enhanced with preloaded video segments (areas of timecode) and special effects. The nonlinear nature and design of VVCR's underlying structure is also the basis for Drastic's coming 'S2 Extensions' for converting traditional edit suites to nonlinear with the addition of just one VVCR (see below).

Extremely High Quality

System throughput (how much data can be moved from video to hard drive per unit of time ) is the most critical aspect of any DDR, as motion JPEG compression is inherently lossy. The lower the overall throughput the greater the number of compression errors that will be visible. By working directly with the SCSI disks and controllers, and through the use of the Drastic Fast File System (DFFS), the VVCR is able to achieve the highest possible throughput. The available throughput is as follows:

Megabyte per SecondMegabits per SecondCompression RatioMinutes per Gigabyte
20.0 160.00 1:1 00:51
13.3 106.40 1.5:1 01:17
10.0 80.00 2:1 01:42
8.0 64.00 2.5:1 02:08
6.6 52.80 3:1 02:33
5.7 45.60 3.5:1 02:59
5.0 40.00 4:1 03:24
4.4 35.20 4.5:1 03:50
4.0 32.00 5:1 04:15
3.3 26.40 6:1 05:06
2.9 23.20 7:1 05:57
2.5 20.00 8:1 06:48
2.2 17.60 9:1 07:39
2.0 16.00 10:1 08:30
1.3 10.40 15:1 12:45
1.0 8.00 20:1 17:00
0.7 5.60 30:1 25:30
0.5 4.00 40:1 34:00

The above table translates between various standards for describing system throughput. The table is based on 4:2:2 encoding of a 720x486 image at 30 frames (60 fields) per second.

Complete VTR Emulation

Unlike many digital disk recorders, VVCR is designed to replace a VTR without requiring special editing software, changes in editing work flow or limited functionality in editing, spot playback, slow motion control and nonlinear playback. Two of the major issues that VVCR addresses to smoothly integrate into production environments are audio and video handling and RS-422 emulation. VVCR's video and audio handling allows for simple setup and standard VTR input and output connections. VVCR responds to hardware and software controller in exact emulation of a VTR, making it simple to integrate into any production environment.

To properly emulate a VTR, the following are required:

  • Proper edit previewing,
  • Frame accurate insert editing,
  • Sensible and accurate timecode representation,
  • Fine speed control for synchronization.


Proper Edit Preview

One of the most important and powerful editing concepts in use today is the 'insert edit'. An insert edit is simply the ability to add or overwrite particular audio or video tracks to composite a completed production consisting of diverse elements. To achieve this end effectively, a DDR must be able to insert any track (video, audio or in combination) anywhere on its disk sub-system and it must have a system of previewing the proposed changes before they are actually recorded. Currently, the VVCR is the only system that meets both of these requirements. VVCR uses the Sony/SMPTE standard selected edit and preview commands to preview an edit containing any combination of pre-recorded and new tracks. This method is compatible with all editors that support preview.

Frame Accurate Editing

Most digital disk recorders do not provide frame accurate editing because they use simple file based or fixed field size management for creating, editing and displaying audio and video. These systems do not translate well when using video editing equipment. Generally, these systems require a pre-allocation, or striping of disk areas. They cannot support separate audio and video insert editing. They also may create false divisions between timecode areas that would normally be contiguous. To compound these problems, most digital disk recorders are inaccurate when recording. They may or may not record the correct length of video at the correct starting time, and do not allow for standard bump editing to obtain synchronization between themselves and other devices.

VVCR however, operates in the same way a VTR does. It has a single timecode space, ranging from 00:00:00:00 to 23:59:59:29 (NTSC). Video and audio may be edited from source tape to any position in this range. Drive space will be used only as necessary for the video and audio actually recorded. The video and audio can also be split during editing, allowing for audio and video edit overlap as well as separate audio or video dubbing over currently existing material. This standard method of editing is not available in any other DDR.

Full Insert Editing

To create a final production in an editing environment, and often even to generate source material for a spot playback environment, the ability to create an insert edit is required of any video recording devices. All 'recorder' VTRs offer this feature, but currently VVCR is the only digital disk recorder to incorporate this basic function. Because VVCR supports insert editing and preview, it may be used as both a player and a recorder in an editing situation. Instead of pre-editing all the necessary material on an expensive recorder VTR, and then adding a generation of loss before moving to the DDR for playback, VVCR can be used to edit to directly. As well as saving time and cost, this decreases the amount of production required to generate material on VVCR. As VVCR is fully frame accurate, this also provides a full source VTR emulation for storing segments from VVCR to video tape for storage or distribution. Recording to or from VVCR is as simple as an insert edit.

Efficient Storage

VVCR's data storage can be thought of as a blackened videotape, with timecode but lacking audio and video. As timecoded audio and video segments are added, the black areas between those sections are maintained. This allows VVCR to act like a standard VTR in respect to timecode handling. For example:

  • A VA1 (video-audio channel 1) segment is recorded at 00:01:00:00 for ten seconds.
  • A second AA (audio channels 1 and 2) segment is recorded at 00:01:30:00 for five seconds.
  • The area between 00:01:10:00 and 00:01:30:00 still exists as far as the controller is concerned.
  • If the controller seeks to 00:01:11:00 and then sends a play command, VVCR will play black video for nineteen seconds before the AA edit is played.

This allows for preroll when editing using traditional video equipment. The black video and silent audio do not take up any space on the disk. To create the same effect on other DDRs (to allow for preroll or consistent playback timing), the area between the two edits would have to be filled by recording black onto the DDR.

Sensible Timecode Management

The concept of 'virtual timecode' seems natural to an editor using a digital disk recorder because of its similarity to tape. Video editing equipment is designed to operate with contiguous timecode. Some DDR systems use a file-based data storage model. Some DDRs create timecode space that is broken up into files or 'Movies'. While this simplifies the management of the video and audio for the DDR, it complicates the use of these devices in remote control applications. Because neither SMPTE nor Sony RS-422 protocol has any concept of file management, there is no way to provide access to more than one of these files from a standard RS-422 controller. While some control systems may eventually support a particular manufacturer's specific extensions for file-based management, normal video control and production tools will never be fully functional on these systems.

Accurate Timecode Representation

With VVCR, every frame represents a single timecode location. This may sound obvious, but with some DDR systems, the video or audio frame is only represented as timecode in relation to its actual, physical position on the hard disk. By pre-allocating timecode 'slots' (a specific number of sectors per field) on the hard disk, there is no system for accommodating compressed frames that are too large or too small. For example:

  • A five second segment is recorded at 00:01:00:00.
  • A second five second segment is recorded at 00:01:05:00.
  • If the frames are larger than the pre-allocated slots on the drive, then the second clip will not start at 00:01:05:00. There will be missing timecode values in the ten second playback. Although the segments will last about 10 seconds, their total timecode duration (ending timecode minus starting timecode) will be greater than 10 seconds.

Apart from being confusing to the end user, this inaccuracy plays havoc with editing and cable automation systems.

VTR Emulation and Fine Speed Control

VVCR allows for extremely fine control of play speeds. It also returns all types of RS-422 protocol: VITC (Vertical Interval Timecode), LTC (Longitudinal Timecode) and CTL (Control Track) information, including offset or presetting the CTL timer. This is extremely important when working with a variety of controllers, all of which expect VVCR to respond to a wide range of commands. In other DDR protocol implementations, accurate editing is impossible. This is due to the lack of proper 'bump' commands (fine adjustment to play speed required to accurately synchronize VTRs), the inability to handle standard editing commands, and improper timecode handling. Most DDRs do not even support the basic EDIT ON and EDIT OFF commands (common to SMPTE and SONY 422 protocol). Those that do, do not use the RS-422 edit type command (describing which channels to edit: Video or Audio 1 or 2) nor do they have the internal accuracy to properly place the recorded video on the DDR's disk.

Video Compression Math

There has been a lot of confusion in marketing literature concerning video compression. Most of the confusion stems from a misunderstanding of the math and the terms involved in compression calculations. What follows is a reasonably accurate method for correlating various ways of describing video compression. NOTE: This method may not allow accurate comparison with some manufacturer's hardware specifications, as their calculations have been found to be inaccurate by up to twenty five percent.

Aside from the basic math problems involved with compression calculations, the situation is further complicated by the different encoding methods used by various manufacturers. The following formulas are based on the broadcast specification known as the CC1R 601 recommendation. If the compression engine in question uses 4:1:1 or R170A as the basis for encoding, it then becomes far more difficult to make a comparison between that engine and true broadcast-quality compression engines. Essentially, that kind of compression engine doesn't encode video at a high enough bandwidth to make it worthwhile.

What Is A Meg, What is a Gig . . .

For solving simple calculations, a megabyte (MB) and a megabit (Mb) are usually assumed to be one million bytes or one million bits respectively. This is not the case. Because the lowest level a computer's digital logic operates on is base 2 (On or Off) basis, a megabyte is actually 220 bytes and a megabit is actually 220 bits. 220 may be calculated as:
2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 = 1,048,576 (decimal)

1 megabyte = 1,048,576 Bytes (assuming 8 bits per byte, the following is also true) 1 megabyte = 8,388,608 Bits

Because of the 48,576 discrepancy between one million and one meg, the preceding values must be used when calculating compression factors, drive usage and data throughput.

Since a megabyte is 220 , a gigabyte is 1024 times a megabyte or 230. This may be calculated as above giving the result:

1 gigabyte = 1,073,741,824 Bytes(assuming 8 bits per byte, the following is also true)1 gigabyte = 8,589,934,592 Bits

If this is the case, the error between one billion and one gig is 73,741,824 making it important to use the actual value of a gig when solving compression equations.

CCIR 601 Uncompressed Video (Method One)


Resolution - 720 x 486 x 29.97 frames per second (Fps) (720 x 243 x 59.94 fields per second - fps)

Sample Size - 8 bits per byte data representation

Sampling - 4:2:2 (or every two horizontal pixels = 2 Y : 1 Cr : 1 Cb)

Frame Rate - 29.97 Frames Per Second


Luminance (Y) 720 x 486 x 29.97 Fps = 10,487,102.4 bytes per second

x 8 bits per byte = 83,896,819.2 bits per second

Chrominance R (Cr) 360 x 486 x 29.97 Fps = 5,243,551.2 bytes per second

x 8 bits per byte = 41,948,409.6 bits per second

Chrominance B (Cb) 360 x 486 x 29.97 Fps = 5,243,551.2 bytes per second

x 8 bits per byte = 41,948,409.6 bits per second

Total = 20,974,204.8 bytes per second

= 167,793,638.4 bits per second

To convert these values into megabytes and megabits, divide them by 220 (1,048,576):

CCIR 601 Megabytes/second 20,974,205 / 1,048,576 = 20.00256062 (Roughly 20 MB/s)

CCIR 601 Megabits/second 167,793,638 / 1,048,576 = 160.020483 (Roughly 160 Mb/s)

CCIR 601 Uncompressed Video (Method Two)


One Line 720 pixels (Y) + 360 pixels (R-Y) = 1440 samples (bytes) per line

One Frame 486 lines per frame x 1440 bytes per line = 699,840 bytes per frame

One Second 699,840 x 29.97 Fps = 20,974,204.8 bytes per second

8 bits per Byte 20974,204.8 x 8 = 167,793,638.4 bits per second

To convert these values into megabytes and megabits, divide them by 220 (1,048,576):

CCIR 601 Megabytes/Second 20,974,205 / 1,048,576 = 20.00256062 (Roughly 20 MB/s)

CCIR 601 Megabits/Second 167,793,638 / 1,048,576 = 160.020483 (Roughly 160 Mb/s)

As you can see, both methods resolve to the same values. For the remainder of this addendum, the following will be true:

Video Data Rate In Bytes = 20 MB/s = 20.00256062 bytes per second

Video Data Rate In Bits = 160 Mb/s = 160.020483 bits per second

Video Ratio = 1:1 = 20 MB/s : 20 MB/s = 20/20


CCIR Uncompressed Video For PAL


Note: The calculations above will be valid for PAL video with the following changes:

PAL Video Rate is 25 Frames Per Second (50 fields) instead of 29.97

PAL Horizontal Resolution is 576 lines per frame instead of 486

One Line 720 pixels (Y) + 360 pixels (R-Y) + 306 pixels (B-Y) = 1440 samples (bytes) per line

One Frame 576 lines per frame x 1440 bytes per line = 829,440 bytes per frame

One Second 829,440 x 25 Fps = 20,736,000 bytes per second

8 Bits Per Byte 20,736,000 x 8 = 165,888,000 bits per second

To convert these values into megabytes and megabits, divide them by 220 (1,048,576):

CCIR 601 Megabytes/second 20,736,000 / 1,048,576 = 19.7753063 (Roughly 20 MB/s)

CCIR 601 Megabits/second 165,888,000 / 1,048,576 = 158.203125 (Roughly 158 Mb/s)


CD Quality Uncompressed Audio

Sample Size - 16 bit (2 byte) data representation

Channels - 2 channels
Sampling Rate - 44,100 Samples Per Second

One Channel - 2 bytes per sample x 44,100 samples per second = 88,200 bytes per second

Total Data Rate - 88,200 bytes per second x 2 channels = 176,400 bytes per second
Total Bit Rate - 176,400 bytes per second x 8 bits per byte = 1,411,200 bits per sample

For the remainder of this addendum, the following will be true:

Audio Data Rate In Bytes = 0.17 MB/s = 176,400 bytes per second

Audio Data Rate In Bits = 1.41 Mb/s =1,411,200 bits per second

Audio Ratio = 1:1=0.17 MB/s : 0.17 MB/S= 0.17/0.17

Total Audio and Video Data Rate


The total data rate or throughput is simply the audio throughput plus the video throughput. For the remainder of this addendum one video channel and two audio channels are assumed and the following will be true for uncompressed data:

Total Data Rate in Bytes = 20 MB/s + 0.17 MB/s = 20.2 MB/s (21,150,605 bytes/second)

Total Data Rate in Bits = 160 Mb/s + 1.41 Mb/s = 161 Mb/s (169,204,838 bits/second)

Total Ratio = 1:1 = 20.2 Mb/S: 20.2 Mb/S = 20.2 / 20.2

Compression As Megs Per Second

When compression is described as megabytes or megabits per second it can be difficult to correlate between different compression vendor's math methods. Assuming the throughput is calculated as above (which is a very large assumption in most cases), the following formulae may be used to convert between descriptions.

Megabyte <=> Megabit

1 megabyte = 8 megabits (most current compression technologies work with 8 bit samples)

e.g. 6 megabytes per second == 48 megabits per second

Megabyte =>Compression Ratio

The ratio of a megabyte or megabit throughput can be calculated by dividing the appropriate value for uncompressed video by the specified data rate.

e.g. 8 megabytes per second = 8,388,608 bytes per second

Uncompressed Video = 20,974,205 bytes per second

The Ratio is 20,974,205 / 8,388.608 = 2.500320077

The Ratio is 2.5:1

Megabyte per second => Minutes Per Gig

To convert megabytes per second to minutes per gigabyte, express the date rate as megabytes per minute, then divide 1024 megabytes/gigabyte by the data rate in megabytes per minute.
e.g. convert 20 MB/s to minute per gigabyte (no audio)

20 MB per second x 60 seconds per minute = 1200 MB per minute

1024 MB per gigabyte / 1200 MB per minute = 0.853 minutes per gigabyte

e.g. convert 20.2 MB/s to minute per gigabyte (plus audio)

20.2 MB per second x 60 seconds per minute = 1212 MB per minute

1024 MB per gigabyte / 12120 MB per minute = 0.845 minutes per gigabyte


Compression As a Ratio

When a manufacturer specifies a compression ratio without any other supporting data, you should be wary. Depending on how the manufacturer calculated the size of uncompressed video, how the numbers were rounded, and how the compressed stream was measured, the ratio may be anywhere from fairly accurate to completely absurd. Whenever possible, find out the data rate in megabytes per second and calculate the ratio yourself. If the data rate is unavailable, make sure it was calculated based on 4:2:2 CCIR 601 encoding practices and that the frame/field size and rate match the above.

Ratio => Megabytes Per Second

The data rate in megabytes per second can be calculated by dividing the uncompressed video data rate value by the compression ratio.

e.g. 9:1 compression

Uncompressed Video data rate = 20,974,205 bytes per second

20,974,205 bytes per second / 9 = 2,330,468 bytes per second

2,330,468 / 1,048,576 = 2.2 megabytes per second

For Megabits per second, use the formula below

2,330,468 x 8 / 1,048,576 = 17.8 Megabits per second

Ratio => Minutes Per Gigabyte (No Audio)

To convert a ratio to the amount of time that can be recorded per gigabyte of hard drive space, simply use the total amount of time available for uncompressed video per gigabyte, and multiply by the ratio. To calculate the time for uncompressed video per gig:

One gigabyte = 1,073,741,824 Bytes

Uncompressed video = 20,974,205 Bytes per second

1,073,741,824 Bytes per Gig / 20,974,205 B/s = 51.19344566 seconds per Gig

51.19344566 / 60 seconds per minute = 0.85 minutes per Gig

e.g. 6:1 compression = 6 times the storage of uncompressed

6 x 51.19344566 seconds per Gig = 307.160674 seconds per Gig

307.160674 / 60 seconds per minute = 5.1 minutes per Gig


Compression As Minutes Per Gigabyte (storage)

This calculation is normally accurate because once you buy the system it is easily checked. Simply set the hardware to its highest quality and record until you fill the drive, then divide the total number of seconds recorded by the drive's size in gigabytes and compare it to the specified number. This specification may also be used to compare overall throughput with other compression systems.

Minutes Per Gigabyte => Megabytes Per Second

To calculate the data rate in megabytes per second from minutes per gigabyte, simply convert minutes per Gigabyte to seconds per Megabyte

e.g. 4 minutes per Gigabyte * 60 seconds per minute = 240 Seconds per Gigabyte

1024 Megabytes per Gigabyte / 240 seconds per Gigabyte = 4.27 Megabyte per second

Minutes Per Gigabyte => Ratio

To calculate the compression ratio given the number of minutes per gigabyte, simply use the number of uncompressed minutes that can be stored in a gigabyte and divide that into the number specified.

One gigabyte = 1,073,741,824 Bytes

Uncompressed Video = 20,974,205 Bytes per second

1,073,741,824 / 20,974,205 = 51.19344566 seconds per Gig

51.19344566 / 60 seconds per minute = 0.85322409 minutes per Gig

e.g. 7 Minutes Per Gig = 420 seconds per Gig

420 / 51.19344566 = 8.204175253


7 / 0 .85322409 = 8.204175253

The ratio is 8.2:1