Beginne mit dem Komplexen: Archivieren von digital-born Musikkompositionen von Apple-Systemen aus dem letzten Jahrhundert

Vorgeschichte

Ein Musikarchiv hat vor rund zehn Jahren den Nachlass eines Komponisten übernommen, der bereits in den 1980er Jahren begonnen hat, mit digitalen Mitteln zu komponieren. Das Ergebnis ist beeindruckend: Auf nicht weniger als 700 Datenträgern wurde das Werk des Komponisten dem Archiv übergeben, darunter 660 Floppy Discs, 26 SyQuest Träger und einige wenige Datenträger aus den Familien von Iomega Jaz, Iomega Zip, CD-ROM und Harddisk. Der Komponist hat bei seiner Arbeit Apple-Systeme und proprietäre Spezialsoftware (Notensatz- und Sequencer-Software) eingesetzt. Das Musikarchiv ist bislang eher traditionell analog ausgerichtet. Zur Sicherung der digitalen Daten wurden aber vor einigen Jahren bereits Images der Datenträger erstellt und separat gespeichert – sofern die Datenträger noch lesbar waren. Der Anlass für eine spätere, tiefere Auseinandersetzung mit dem Nachlass im Jahr 2018 war der Forschungsaufenthalt einer Forscherin aus dem Ausland. Anhand einiger digital entstandener Werke wollte sie den Schaffensprozess und die Arbeitsweise des Komponisten in dieser digitalen Umgebung untersuchen. Die Zugänglichmachung der Daten gestaltete sich schwierig: Laufwerke zu den Datenträgern sowie die benötigte Software zum Lesen der Files war an den modernen Arbeitsstationen nicht vorhanden. Daher wurden alte Rechner und Laufwerke aus den Privatbeständen von Archivmitarbeiter*innen sowie aus dem Nachlass selbst wieder hergerichtet. Die benötigte proprietäre Software und die dazugehörigen Lizenzen waren glücklicherweise ebenfalls im privaten Fundus eines Archivmitarbeiters vorhanden. Die Forscherin konnte so einen Teil der Daten auf den alten Geräten während ihres Aufenthaltes zwar untersuchen, jedoch waren nicht mehr alle Datenträger lesbar, beziehungsweise die Dateitypen und die Zuordnung zur passenden Software konnte nicht immer erkannt werden. Die Erfahrungen aus diesem Forschungsaufenthalt trieben das Archiv dazu, für künftige Anfragen zu digitalen Archivbeständen eine langfristig sichere Archivierungs- und Nutzungsmöglichkeit zu finden. Der vorliegende Nachlass diente dafür als willkommenes Pilotprojekt, nicht nur für das Archiv selbst. Da inhouse kein Know-How und nicht ausreichend Kapazitäten vorhanden waren, fand sich eine Kollaboration mit der Universitätsbibliothek Basel, die zu diesem Zeitpunkt ebenfalls an verschiedenen forschungsnahen Use Cases interessiert war, die sich zur Erfahrungsgewinnung im Bereich der digitalen Langzeitarchivierung eigneten.

Die Hardware: Datenträger, Schnittstellen, Systeme

Die Problematik der teilweise nicht mehr lesbaren Datenträger war dem Musikarchiv bereits bekannt und wir entsprechend darauf vorbereitet. Das volle Ausmass zeigte sich jedoch erst beim Versuch der “Datenablösung” bzw. der Image-Erstellung. Während die vorhandenen Iomega Zip, Iomega Jaz und SyQuest 44MB Datenträger und die einzelne externe Festplatte durchaus mit mehr oder weniger überschaubarem Aufwand bearbeitet werden können (wenn auch nicht durchwegs alle lesbar sind), spielten die rund 660 Floppy Disks 3,5’’ ihre Eigenheiten voll aus. Neben den neuesten Typen HD/DS (High Density / Double Sided) lagen auch viele Double Density sowie einige wenige Single Sided vor. Nicht wenige der Träger waren spezifisch für den Gebrauch mit Synthesizer-Geräten vorgesehen bzw. formatiert und mit klassischen Laufwerken nicht zu lesen. Andere wiederum zeigten ob des Alters Disk Errors. Ohne den Bestand abgeschlossen zu haben, kann bereits ausgesagt werden, dass ein grösseres Paket Arbeit auf einen professionellen Datenforensiker wartet. Da wir von Grund auf die Infrastruktur für die digitale Langzeitarchivierung neu aufbauten und von älterem Equipment im Hause kaum noch etwas vorhanden war, musste vieles neu beschafft werden. Innert eines Jahres sammelten sich dadurch mehrere Arbeitsstationen an (Windows, Ubuntu mit BitCurator und Mac OS). Spezifisch für den hier beschriebenen Fall wurden für Mac-Problemstellungen aller Art neben einem modernen MacBook Air von 2014 aus unserem persönlichen Fundus auch zwei ältere Macintosh PowerBooks – G3 Wallstreet Series II von 1998 und 1400c von 1996 – über Ebay beschafft. Bei der Auswahl der Typen liessen wir uns von einem exzellenten Blog-Artikel von Porter Olsen zum Thema der sogenannten “Rosetta Computer” leiten (auch lesenswert: die Erläuterungen auf siber-sonic.com zum selben Thema). Diese beiden Geräte erlauben eine möglichst breite (aber nicht umfassende) Lesbarkeit alter Floppy Disks (unabhängig von Typ oder Formatierung). Beide Maschinen sind funktionstüchtig und passenderweise mit Wechsellaufwerken für Floppy und Iomega Zip ausgerüstet, was einen einfachen Datentransfer nach der Image-Erstellung auf eine moderne Arbeitsstation ermöglicht. Des Weiteren kamen mehrere externe CD/DVD/BluRay-Laufwerke sowie ein externes Laufwerk für Floppy Disks und eines für Iomega ZIP Datenträger bis 750MB hinzu. Um Datenträgern wie SyQuest EzDrive und 44MB etwas entgegensetzen zu können, konnten wir dankenswerterweise auf Dauerleihgaben des Archivs (teilweise sogar aus dem hier beschriebenen Archivbestand) zurückgreifen. Wie wir die Verbindung und die Workflows von den alten (teilweise internen) Laufwerken mit SCSI-Schnittstelle zu den modernen Arbeitsstationen und damit letztendlich zu unserem Digitalen Archiv bewerkstelligen, wird uns in den kommenden Monaten noch beschäftigen.

Unser Equipment (zumindest ein Teil davon)!

Die Software: Betriebssystem, Eigenheiten, Dateien

Auf die Hardware folgt die Software: Die im Nachlass vorhandenen Floppy Disks waren zur Zeit der späten 1980er und der 1990er-Jahre in Gebrauch – einer Zeit, in der sich die Welt von Mac OS im Fluss befand und mit einem Systembruch beim Wechsel von sogenannten Old World ROMs auf New World ROMs für die eine oder andere Software-Inkompatibilität sorgte. Mit den drei vorhandenen Apple-Geräten werden aktuell die Betriebssysteme 7.5.3, 8.1 (beide Old World) und 10.14 Mojave (New World) abgedeckt.

Quelle: https://en.wikipedia.org/wiki/Macintosh_operating_systems

Eine Ebene tiefer finden sich auf den Datenträgern neben den klassischen Archivalien wie Korrespondenz und Textdokumenten aller Art (Skizzen, Kalendereinträge, Notizen …) auch unzählige Spezialfiles für Programme zur Notensetzung und Musiksequenzierung wie Digital Performer (bzw. dessen Vorgänger Performer), Professional Composer oder Finale. Auch hier spielt der oben beschriebene Systembruch teilweise eine wichtige Rolle. So wurde Performer für OS X völlig neu konzipiert (und als Digital Performer released) oder die Weiterentwicklung von Mosaic, dem Nachfolger von Professional Composer, gleich ganz eingestellt. Ein weiterer Glücksfall half uns hier: Sowohl im Archivbestand selbst als auch im Fundus des Musikarchivs befanden sich nicht nur Installationsdisks der verwendeten Software, sondern teilweise auch Lizenzen.

Eine weitere technische Ebene später, als die Workflows für den Pre-Ingest bis zu einer gewissen Stufe funktionierten, zeigten sich weitere Feinheiten, die es zu lösen galt. Ein Beispiel: Interessanterweise war es in den späten 1980er und 1990er-Jahren möglich, Filebenennungen mit Sonderzeichen zu nutzen. So finden sich Fragezeichen oder Schrägstriche, aber auch Leerschläge und sogar Zeilenumschläge am Ende eines Dateinamens. Ein Umstand, mit dem die heutigen Systeme nicht unbedingt umgehen können. Schwierig ist auch, dass die klassischen Programme zur Dateiidentifikation und -validierung wie JHOVE oder DROID bei diesen Files nicht unbedingt weiterhelfen, da sie sie schlicht nicht identifizieren können.

Inhaltliche Aspekte: Redundanz, Versionierung, Bewertung

Auf der inhaltlichen Ebene hat der Komponist selbst Backups seiner Arbeit auf verschiedenen Datenträgern angelegt, teilweise auch im Entstehungsprozess eines Werkes. Zudem hat er mit einem der Programme, mit denen er gearbeitet hat, im Schaffensprozess im Zehn-Minuten-Takt Sicherungen vorgenommen. Diese systematische Versionsgeschichte aus dem Entstehungsprozess der Werke ist für die Forschung zwar interessant, verursacht aber auch eine erhebliche Daten-Potenzierung und Unübersichtlichkeit, zumal automatisierte Sicherungen auch erstellt wurden, wenn das Programm zwar geöffnet war, aber nicht aktiv an einem Werk gearbeitet wurde. In diesen Fällen könnte allenfalls ein Prüfsummen-Vergleich identische File-Versionen identifizieren und bei der Bewertung unterstützen. Dies könnte zur Reduktion der zu archivierenden Datenmenge und zu mehr Übersichtlichkeit führen, erfordert aber auch eine inhaltliche Analyse, wofür wir eher wenige Kapazitäten haben.

Eine inhaltliche Bewertung und Auswahl der Daten ist auch in anderen Fällen erforderlich. Beim Erstellen der Backups wurden auch Systemdateien und Software auf die Datenträger geschrieben. Dies ist hilfreich für die Interpretation von Dateien, deren Dateityp nicht erkannt werden kann oder wenn Spezialsoftware, die heute nicht mehr ohne weiteres verfügbar ist, für Emulationen benötigt wird. Jedoch würde es genügen, diese Systemdateien einmalig zu archivieren. Hier müsste ein Abgleich über alle Datenträger erfolgen und eine Auswahl getroffen werden, welche Systemdateien sinnvollerweise archiviert werden und welche nicht. Zudem ist zu hinterfragen, ob man alle Backups archiviert, die der Komponist angelegt hat. Teilweise sind die sich darin befindenden Daten identisch.

Doch wann und durch wen soll diese Bewertung vorgenommen und nach welchen Kriterien soll vorgegangen werden? Was geschieht mit Dateien und Datenträgern, die auch mittels Datenforensik nicht mehr lesbar sind? Bestenfalls findet eine Bewertung nach dem “Ablösen“ der Daten vom Datenträger durch Fachpersonen des Archivs statt. Die Bewertung sollte jedoch stets durch mehrere Personen erfolgen. Gestützt auf ähnliche Richtlinien, die wir bereits für die Bewertung von audiovisuellen Dokumenten erarbeitet haben, sehen wir primär folgende Oberbegriffe als Kriterien:

  • Informationsgehalt und Aussagekraft
  • Erhaltungszustand und Lesbarkeit
  • Vorhandensein von Dubletten
  • Heute oder künftig vorhandenes Interesse von Benutzenden und Forschenden

Die für nicht aufbewahrungswürdig befundenen oder unbrauchbar gewordenen Dateien werden idealerweise kassiert. Im zusätzlich archivierten Image wären die Dateien für allfällige künftige Bedürfnisse dennoch gesichert. Zudem sollte jeder Bewertungsvorgang und jede Löschung aus Gründen der Authentizitäts- und Integritätserhaltung dokumentiert werden.

Keine Archivierung ohne Nachnutzung

Aufgrund der geschilderten Problematiken und vieler, nicht ohne grösseren Analyseaufwand erkennbaren Dateiformaten wird eine Migration mit unserer Standardlösung im Digitalen Archiv schwierig: Was sind die Zielformate? Mit welchen Tools migrieren wir? Sind unsere Vorstellungen überhaupt auf einem windows- bzw. linuxbasierten Ingestsystem realisierbar? Bei Tests mit der Forscherin wurde klar: Eine Migration ohne spürbaren Informations- und Funktionalitätsverlust ist vielfach nicht möglich, zumindest bei Dateien, die über einfache Textdokumente hinausgehen. Eine Anekdote hierzu: Als die bereits erwähnte Forscherin den Transfer von Kompositions- und Sequenzerfiles auf neuere Systeme prüfte, fehlte die direkte Verbindungsmöglichkeit zwischen den Systemen (Hardware/Schnittstellen und Software). In wenigen Fällen gelang der Transfer durch schrittweises Umkopieren und Migrieren, was jedoch mit erheblichem Aufwand verbunden und nicht ohne Informationsverlust möglich war. Die vielfältigen Funktionalitäten der Software konnten nicht 1:1 in neueren Versionen und alternativen Programmen abgebildet werden. Die Forscherin unternahm daher den Versuch, die dynamischen bzw. interaktiven Bedienelemente der Software beim Abspielen einer Komposition vom Bildschirm abzufilmen. Leider waren die vorhandenen Bildschirme allesamt zu klein, um alle Bedienelemente gleichzeitig öffnen und nebeneinander darstellen zu können. Daher hatten wir von Beginn an eine sinnvolle, aber pragmatische Nachnutzung im Blick. Letztlich landeten wir für diesen spezifischen Fall immer wieder beim Projekt EaaSI (Emulation-as-a-Service Infrastructure). Eine browserbasierte Emulation, die die Nutzung ohne grossen Aufwand möglich macht – authentisch im damaligen System mit der originalen Software – scheint uns ideal. Eine Testanwendung, bereitgestellt durch das Unternehmen OpenSLX bzw. Klaus Rechert durften wir bereits ausprobieren, weitere Abklärungen sind geplant.

Fazit

Ohne die Arbeit bereits abgeschlossen zu haben, lässt sich bereits ein erstes Fazit ziehen, dass der hier vorgestellte Archivbestand ein sehr anspruchsvoller Use Case mit komplexen Problemstellungen für den Aufbau einer Digitalen Langzeitarchivierung ist. Der Erkenntnisgewinn und die Lernkurve in der kurzen bisherigen Projektlaufzeit war enorm. Interessant waren vor allem die Aspekte der Bewertung und der signifikanten Merkmale, die an diesem Bestand neu durchdacht werden müssen. Auch der Mut zum Pragmatismus ist absolut zwingend. Sehr hilfreich war, dass wir mit diesem Archiv jemanden an der Seite haben, der den Bestand und die damalige Technologie gut kennt und auch Equipment beisteuern kann. Dieser Use Case stellt gewiss kein Regelfall für unser Digitales Archiv dar. Die beim hier beschriebenen Fall für Analyse und Pre-Ingest eingesetzte Zeit war daher überproportional hoch. Während die breite Masse sonst relativ einfach ingestiert und nachgenutzt werden kann, war hier das Auskundschaften alternativer Wege erforderlich.

Was dieser Use Case sehr gut verdeutlicht – was wir aber auch bei anderen Use Cases, mit denen wir uns auseinandergesetzt haben, festgestellt haben -, ist die Tatsache, dass wir stets versuchen, über die reine Aufbewahrung der Daten hinaus zu denken und die Nachnutzbarkeit von Beginn an mitzudenken. Ausschlaggebend für die Nachnutzbarkeit kann dabei auch der Erhalt von Funktionalitäten sein, die nicht mit den Daten, sondern mit der verwendeten Software verbunden sind. Die Lösungen für diesen Ansatz unterscheiden sich mitunter sehr vom reinen Erhalt der Daten.

beat.mattmann@unibas.ch und iris.lindemann@unibas.ch

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.