Digitapes: What is a "tape" ?

Let’s take a moment to look at what’s at the core of digitapes anyway: the tape itself.

A “tape” in digitapes parlance is a collection of media objects and the metadata that describes that media collection. Because we want digitapes to be open and free, it should not require work to be accessed for the owner of that data.

In the simplest case it is just a folder of media files and a json file describing some contents. This should allow total control be given back to the user if anything was to happen to digitapes (in an operational service sense).

Tapes are usually “held” somewhere; either locally on the filesystem, or in the cloud, on a VPS, on a mobile phone, etc. - The device that stores the tape would be referred to as the tape “holder”.

Some of the original marketing for how digitapes works.

Media objects

Digitapes is all about media. A tape’s primary use is to store and group that media together. Media can mean anything, but for the most part it is focused on video, images, and files. Care should be taken by the tape owner that the media always has a way to be decoded, as the tape and tape holder are not responsible for re-encoding or fixing any data that goes to it, (and should have a disclaimer for any media that it is re-encoding).

Digitapes metadata digitape.json

Within all “tapes” there should be a json document that describes the contents with the filename digitape.json. This json document is required to have the following keys:

• title - the title of the tape
• description - the description of what is contained within the tape
• updated_at - the latest time this tape was modified (by adding / removing media)
• media - a list of media objects.

The media object is simply a json object with the keys:

• file - filename reference. The actual data is held by the holder of the tape, which can just be local directories in our simple case.
• crc32 - A check for integrity

Other digitape services (such as 3rd party systems) can provide more metadata, such as descriptions for the media files themselves, or information about when to splice them into a montage, but this is the baseline for what constitutes a digitape.

Building the basic system

With the basics that we’ve got, we have a very simple grouping: a title and description, a time it was made, and some integrity checks for the individual files that are contained within.

With this simplicity, we can easily make a bash script to build simple digitapes for us. Consider a simple file validation tool:

#!/usr/bin/env bash
# Digitapes validation tool. Usage: vaildate.sh digitape.json
function errexit(){
    echo "Not a valid digitape file"
    exit 1
}
trap 'errexit' ERR

jq -e '.title,.description,.updated_at,(.media.[]|(.file,.crc32))' $1 >> /dev/null

echo "Valid!"

This script can be used to validate some digitape files for us by checking that the needed keys exist. Now we can make a script to create them

#!/usr/bin/env bash
# Digitapes creation tool 
# Usage: ./create.sh  title description

if [ "$#" -ne 2 ]; then
    echo "Usage: ./create.sh title description"
    exit 1
fi

title=$1
description=$2
updated_at=$(date +"%Y-%m-%d %H:%M:%S")

# for all files in directory, build a json object
for file in *; do
    if [ -f "$file" ]; then
        media+=$(jq -n --arg file "$file"\
        --arg crc32 "$(crc32 "$file")"\
        '{file: $file, crc32: $crc32}')
    fi
done

echo "${media[@]}" |  jq -s\
    --arg title "$title"\
    --arg description "$description"\
    --arg updated_at "$updated_at"\
    '{title: $title, 
    description: $description, 
    updated_at: $updated_at, 
    media: .}' > digitape.json

This script just puts whatever is in the directory, into a digitapes.json file, which might not be what is wanted in a usability sense but this is a very simple proof of concept for the base underlying system.

Tape holders and file data

A tape holder is the actual location where the media data is stored. In our basic system above, it’s just the directory that the media files are located in. If you export a tape from a service and copy it onto your thumbdrive, that thumbdrive becomes the “holder” of the digitape.

For a service that is offering digitapes, the file key can be used to store a reference to where or what that file is, but if the digitape is to be exported, then any references should be resolved into relative pathnames (relative to the digitapes.json document).

The “Holding” service should have a way to:

• List tapes that are being held
• Create a new tape, or delete an old one
• Add, or edit information on the tape.
• Export or import tapes.

The last point (import/export) is nebulous; What I mean is that there should be an easy way for tapes to be moved around from system to system. It could be seen that a simple zip or tar.gz file archive could be useful in transmitting.

One could easily create a service that has a AWS-S3 backend, or even a google-drive backend. And there should be an easy way to export from one service to import into another.

Goals and observations

To re-iterate the goals of digitapes, this should provide a loose structure and grouping of media files so that, in the event of total collapse, media file data is not locked into any particular system. As far as online holding services are involved, this relies on the import/export capability of the service.

In the basic sense, we will have a collection of media files and some meta data that provides some information about those files. The metadata is in a plaintext format that can provide a flexible amount of information.