Here's a tool, make it work!

In the last post you may have already noticed it. To analyze the hits of DROID signatures I wrote a small Perl script which converts Droid signatures into Perl Regular Expressions and writes the matches into tag files of the hex editor wxHexEdit so that you can see which signatures were used where in a file.

From this small script a bigger Perl module called "File::FormatIdentification::Pronom" was created. It should not replace Droid, Fido or Siegfried. It only serves to analyze which patterns can be optimized and gives statistics about how to improve the Pronom database in the future.
In the following a statistic of the current Droid signature is shown, so that you get a feeling, what is possible.

perl -I lib/ bin/pronom_statistics.pl ../DROID_SignatureFile_V94.xml
Statistics of file ../DROID_SignatureFile_V94.xml
=======================================

Countings
---------------------------------------
Count of PUIDs:                        1670
         internal IDs:                 1441
         regular expressions:          1730
         file endings:                 1167
         PUIDs with file endings only: 503
         (56,76,167,168,169,194,195,212,594,681,682,683,684,691,717,760,780,879,996,1435)
         orphaned internal IDs:        20
         (56,76,167,168,169,194,195,212,594,681,682,683,684,691,717,760,780,879,996,1435)

Quality of internal IDs
---------------------------------------
1-best quality internal ID (PUID, name):       110 (fmt/75, Drawing Interchange File Format (ASCII)) -> 4.882;3.135
        combined regex: (?=((\x0A)|(\x0D\x0A)(0))SECTION((\x0A)|(\x0D\x0A)(\x20\x202)((\x0A)|(\x0D\x0A)(HEADER)((\x0A)|(\x0D\x0A))))((\x0A)|(\x0D\x0A)(9))\$ACADVER((\x0A)|(\x0D\x0A)(\x20\x201)((\x0A)|(\x0D\x0A)(AC1009)((\x0A)|(\x0D\x0A))))((\x0A)|(\x0D\x0A)(0))ENDSEC((\x0A)|(\x0D\x0A)))(?=(((\x0A)|(\x0D\x0A)(0))EOF((\x0A)|(\x0D\x0A)))\Z)
2-best quality internal ID (PUID, name):       105 (fmt/70, Drawing Interchange File Format (ASCII)) -> 4.736;2.833
        combined regex: (?=0\x0D\x0ASECTION\x0D\x0A\x20\x202\x0D\x0AHEADER\x0D\x0A9\x0D\x0A\x24ACADVER\x0D\x0A\x20\x201\x0D\x0AAC((1001)|(2\x2E21)|(2\x2E22)(\x0D\x0A))0
ENDSEC
)(?=(0\x0D\x0AEOF\x0D\x0A)\Z)
3-best quality internal ID (PUID, name):       104 (fmt/69, Drawing Interchange File Format (ASCII)) -> 4.644;2.833
        combined regex: (?=0\x0D\x0ASECTION\x0D\x0A\x20\x202\x0D\x0AHEADER\x0D\x0A9\x0D\x0A\x24ACADVER\x0D\x0A\x20\x201\x0D\x0AAC2\x2E10\x0D\x0A0\x0D\x0AENDSEC\x0D\x0A)(?=(0\x0D\x0AEOF\x0D\x0A)\Z)
4-best quality internal ID (PUID, name):       103 (fmt/68, Drawing Interchange File Format (ASCII)) -> 4.644;2.833
        combined regex: (?=0\x0D\x0ASECTION\x0D\x0A\x20\x202\x0D\x0AHEADER\x0D\x0A9\x0D\x0A\x24ACADVER\x0D\x0A\x20\x201\x0D\x0AAC1\x2E50\x0D\x0A0\x0D\x0AENDSEC\x0D\x0A)(?=(0\x0D\x0AEOF\x0D\x0A)\Z)
5-best quality internal ID (PUID, name):       102 (fmt/67, Drawing Interchange File Format (ASCII)) -> 4.644;2.833
        combined regex: (?=0\x0D\x0ASECTION\x0D\x0A\x20\x202\x0D\x0AHEADER\x0D\x0A9\x0D\x0A\x24ACADVER\x0D\x0A\x20\x201\x0D\x0AAC1\x2E40\x0D\x0A0\x0D\x0AENDSEC\x0D\x0A)(?=(0\x0D\x0AEOF\x0D\x0A)\Z)

1-worst quality internal ID (PUID, name):       1299 (fmt/950, MIME Email) -> -1.993;-2.91;-2.776;-2.776;-2.29
        combined regex: (?=\A.{0,16384}(((V)|(v)(\x2D)((IME)|(ime)(M)))ersion: 1\.0))(?=\A.{0,16384}(To\x3A\x20))(?=\A.{0,16384}(From\x3A\x20))(?=\A.{0,16384}(Date\x3A\x20))(?=\A.{0,16384}(Content\x2DType\x3A\x20))
2-worst quality internal ID (PUID, name):       527 (fmt/358, Internet Data Query File) -> -2.806;-2.743;-2.629;-2.981
        combined regex: (?=\A.{0,3424}(\x5BQuery\x5D).*(((S)|(s)(i)((C)|(c)))cope=))(?=\A.{0,3424}(\x5BQuery\x5D).*(((C)|(c)(i)((C)|(c)))olumns=))(?=\A.{0,3424}(\x5BQuery\x5D).*(((T)|(t)(i)((C)|(c)))emplate=\/))(?=\A.{0,3424}(\x5BQuery\x5D).*(((R)|(r)(i)((C)|(c)))estriction=.?(\x25)))
3-worst quality internal ID (PUID, name):       532 (fmt/363, SEG Y Data Exchange Format) -> -3.351;-4.196
        combined regex: (?=\A.{0,320}(\x40{22}))(?:(?=\A.{3200}(\x00\x00.{15}([^\x00])|(?=\A.{3600}(\x00\x00.{15}([^\x00])).{3}([^\x00])(.{2}(\x00[\x01-\x08])|.{2}(\x01\x00))))
4-worst quality internal ID (PUID, name):       533 (fmt/363, SEG Y Data Exchange Format) -> -3.351;-4.196
        combined regex: (?=\A.{0,320}(\x40{22}))(?:(?=\A.{3200}(\x00\x00.{15}([^\x00])|(?=\A.{3600}(\x00\x00.{15}([^\x00])).{3}([^\x00])(.{2}(\x00[\x01-\x08])|.{2}(\x01\x00))))
5-worst quality internal ID (PUID, name):       835 (fmt/532, Drawing Interchange File Format (ASCII)) -> -3.614;-3.842
        combined regex: (?=\A.{1,3}((0).{1,2}SECTION.{1,2}(\x20\x202).{1,2}(HEADER)).+((9).{1,2}\$ACADVER.{1,2}(\x20\x201).{1,2}(AC1027)).+((0).{1,2}ENDSEC))(?=((0).{1,2}EOF).{1,3}\Z)


Regular expressions
---------------------------------------
Count of multiple used regular expressions: 67
         common regex group no 0:
            regex='(((\x0A)|(\x0D)|(\x0D\x0A)(0))EOF).{0,2}\Z'
            internal IDs: 111,112,113

[…]

I would be pleased about feedback. The code is available under http://andreas-romeyke.de/software.html#_file_formatidentification_pronom .

Have fun!

A file is a TIFF is a MP3 is a…

In den letzten Tagen sind uns einige Dateien aufgefallen, die in der Formatidentifizierung hängengeblieben sind. Diese wurden von Droid als TIFF (fmt/353) und als MP3 (fmt/134) erkannt.

Die Frage, die sich uns stellte: Lag ein Fehler vor, oder handelt es sich tatsächlich um Dateien, die man anhand der Pronom-Signaturen sowohl als TIFF als auch als MP3 interpretieren könnte?

Um diese genauer zu untersuchen, haben wir uns ein Perl-Script¹ geschrieben. welches die Muster aus der Droid-Signaturen Datei verwendet und die entsprechenden Treffer im HexEditor sichtbar macht. Hier ein Screenshot:

wxHexeditor, Screenshot mit spezieller Tags-Datei

Wie man sieht, treffen mehrere Muster. Zum einen das Muster für TIFF-Dateien, indem am Anfang der Magicbyte-String "0x4949" vorkommt. Zum anderen auch eines der Rezepte, die einen MP3-Datenstrom beschreiben.

Bei Wikipedia findet man unter XXX folgende Darstellung eines MP3-Frames. Das Muster in der Droid-Signatur trifft, da 8 Frames hintereinander vorkommen:

MP3-Struktur, Quelle: Wikipedia, sh. https://commons.wikimedia.org/wiki/File:Mp3filestructure.svg (CC-BY/GFDL)

Diese Datei ist ein gutes Beispiel dafür, daß nicht die Muster in der Pronom-Datenbank das Problem sind, sondern dateiformat-spezifische Eigenschaften es notwendig machen, den Ingest-Prozess so zu gestalten, dass dieser mit mehreren Treffern in der Formatidentifikation umgehen kann.

Siehe hierzu auch unser Beitrag "Formatidentifikation vs. Formatvalidierung - Wem glauben wir eigentlich?" unter https://kulturreste.blogspot.com/2016/06/formatidentifikation-vs.html


--
¹ Das Perlscript stellen wir demnächst zur Verfügung

Bibtag - und 'ne Kleinigkeit gelernt

Heute hatte ich einen Abstecher zum Bibliothekartag 2017 nach Frankfurt am Main gemacht. Zum einen, um etliche Ex-Kommilitonen zu treffen, zum anderen war ich am Workshop von Yvonne Tunnat von der ZBW zur Formatidentifikation interessiert.

Yvonne hat eine wunderbare, pragmatische Art komplizierte Sachverhalte zu erklären. Wer sie kennenlernen möchte, der nestor-Praktikertag 2017 zur Formatvalidierung hat noch Plätze frei.

Zwei Dinge, die ich mitnehme. Zum einen kannte ich das Werkzeug peepdf noch nicht. Es handelt sich um ein CLI-Programm um eine PDF-Datei zu sezieren und kommt ursprünglich aus der Forensik-Ecke.

Zum anderen gibt es mit Bad Peggy ein Validierungstool um JPEGs zu analysieren.

Eine Diskussion, die immer wieder auftaucht ist die, wie man mit unbekannten Dateiformaten umgeht. IMHO sind diese nicht archivfähig, und wie Binärmüll zu betrachten. Dazu bedarf es aber mal eines längeren Beitrags und einer genaueren Analyse, ob und unter welchen Bedingungen solche Dateien vernachlässigbar sind, oder der long-tail zuschlägt.

BTW., wer am Mittwoch noch auf dem Bibtag ist, schaue mal beim Vortrag unserer Kollegin Sabine zu den Ergebnissen der PDF/A Validierung vorbei.

Formatidentifikation vs. Formatvalidierung - Wem glauben wir eigentlich?

Deutsch (english version below)

Wer in der Lage sein will, die Daten in seinem digitalen Langzeitarchiv auch in Zukunft noch durch Migrationen verfügbar zu halten, muss schon beim Ingest darauf achten, dass die eingelieferten Dateien auch den einschlägigen Standards und Spezifikationen entsprechen.

Bisher fährt man dafür einen zweistufigen Ansatz. Zuerst identifiziert man den Dateityp einer Datei (z. B. anhand der Dateiendung oder einer Signatur) mit einem Werkzeug wie DROID, dann prüft man sie mit einem Formatvalidator. Dieser Ansatz stellt den Anwender aber vor ein fundamentales Problem: was passiert, wenn eine Datei die Formatvalidierung nicht besteht? Wer hat Recht? Hat nicht gerade die Formatidentifizierung ergeben, dass man eine Datei eines bestimmten Formates vor sich hat? Warum widerspricht der Validator dann? Momentan speichert das Archivsystem das erkannte Format in den Metadaten ab, selbst wenn die Datei die Formatvalidierung nicht besteht.

Man kann also nur dann davon ausgehen, dass man z. B. eine TIFF-Datei vor sich hat, wenn der Aufbau der Datei auch der TIFF-Spezifikation entspricht. Ist das nicht der Fall, dann hat man auch kein TIFF vor sich, denn der innere Aufbau ist ja sehr eindeutig spezifiziert. Man hat also etwas vor sich, das nur ungefähr so aussieht wie eine TIFF-Datei, aber keine echte TIFF-Datei.

Eigentlich richtig wäre deshalb der restriktivere Ansatz. Die Formatidentifikation darf hier nur ein Hilfsmittel sein, um das richtige Validierungswerkzeug auszuwählen. Nur wenn die Validierung erfolgreich ist, darf auch das erkannte Dateiformat in den Metadaten festgehalten werden; die verbindliche Formatidentifikation findet also implizit bei der Formatvalidierung mit statt. Ist die Validierung nicht erfolgreich, dann könnte man noch das Formatidentifizierungswerkzeug befragen, ob evtl. eine ähnliche Signatur für einen anderen Dateityp hinterlegt ist, und dann die Validierung wiederholen. Ist das nicht der Fall, dann muss man von einem unbekannten Dateityp ausgehen und ggf. die Datei beim Ingest zurückweisen.

Zusatz für ganz Unerschrockene: viele Formate haben eingebettete Formate, Unterformate oder sind selbst Container für andere Formate. Genau genommen müsste man nicht nur das äußerste Format prüfen, sondern auch die korrekte Einbettung der Unterformate und deren eigene Validität. In das Langzeitarchiv dürften die Dateien nur dann aufgenommen werden, wenn auch alle ihre eingebetteten Dateien korrekt validiert werden können. Was das für TIFF (eingebettete ICC-Profile, XMP- & IPTC-Metadaten, ...), OpenOffice Dokumente (XML und Bilder in ZIP eingebettet), PDF (alle möglichen eingebetteten Dateiformate und Codeschnipsel, dazu Links zu externen Quellen), das Webarchivformat WARC (buchstäblich alle Formate, die auf Webseiten vorkommen können) und viele andere Formate bedeutet, mag sich jeder selbst in seinen Alpträumen von der Formathölle ausmalen. Klar ist: im Moment tun wir auch in Ermangelung geeigneter Werkzeuge viel zu wenig um sicherzustellen, dass nur valide Dateien in unsere Langzeitarchive gelangen.

Dateiformat-Explosion

Vorwort

Zum Bibliothekartag 2014 gab es im Nachtrag zu unserem Vortragsblock eine rege Diskussion darüber, ob es sinnvoll ist, erst einmal alle Dateien in ein Langzeitarchiv aufzunehmen und sich später Gedanken darüber zu machen, wie man deren Langzeitverfügbarkeit z. B. durch Formatmigration sicherstellt.

Ich habe viel recherchiert, aber wenig belastbare Zahlen gefunden. Ein guter Indikator könnten die Signaturen für DROID sein, einem Programm zur Ermittlung des Datenformates unbekannter Dateien.

Auf Pronom findet man 77 Versionen von 08-2005 bis 07-2014, von ehedem 766 bis heute 1.459 von DROID unterstützten Signaturen.

Alternativ könnte man die Datenbanken des Unix-Befehls file (http://www.darwinsys.com/file/) heranziehen. Auf ftp://ftp.astron.com/pub/file/ findet man Versionen von 08-2008 bis 06-2014.

Eine andere Möglichkeit wäre, die bei der IANA registrierten MIME-Types (zur Zeit 1.087 verschiedene Signaturen) heranzuziehen: http://www.iana.org/assignments/media-types/media-types.xhtml

Außerdem wurde ich noch auf http://fileformats.archiveteam.org/wiki/Main_Page aufmerksam gemacht.

Leider gibt es zu den letzten beiden Links keine auswertbare Timeline.

Was uns 'file' verrät

Wir können annehmen, dass sowohl bei 'file' als auch bei DROID, die Signaturen in gewisser Weise die Dateiformate enthalten, die auch weit verbreitet sind. Wie stark wissen wir nicht, aber wenn sie total unbedeutend wären, hätte sich keiner die Mühe gemacht, für diese Signaturen zu erstellen.

Wir können ferner annehmen, dass nach einer gewissen Einschwingzeit die Zahl der Dateiformate in diesen Signatur-Datenbanken der Anzahl der tatsächlich verbreiteten Dateiformate entspricht.

Im Folgenden das Diagramm der Entwicklung der Dateiformate basierend auf der file Magic Bytes Datenbank von Ende 1999 bis Mitte 2014.

Count of different fileformats based on magic bytes database of file, 08/2014, Andreas Romeyke

Als Grundlage für das Diagramm diente das GIT-Repository von file, genauer das Verzeichnis 'magic/Magdir'. Über die Tags extrahierte ich alle Versionen des Verzeichnisses und ließ das folgende Script die dem Diagramm zugrunde liegende CSV-Datei erstellen:

#!/bin/bash
echo "#version, date, group, count"
for version in *;do
  for sub in $version/magic/Magdir/* ; do
    group=$(basename $sub); 
    count=$(cat $sub | grep "^0" | wc -l);
    date=$(cd $version; git log --name-status --date=raw \
    --pretty='format:commit,%ae,%ai,%ce'| cut -d "," -f 3| head -n 1|\
    cut -d " " -f 1)
    echo "$version, $date, $group, $count"; 
  done ;
done

Sehr überraschend für uns war der nahezu lineare Verlauf der Formatvielfalt. Um auszuschließen, dass dies andere Ursachen hat, war es notwendig, eine zweite, von file unabhängige Quelle heranzuziehen.

DROID/Pronom als Quelle

Die Entwickler von DROID haben, wie oben bereits angedeutet, ihre Signaturfiles von Version 1 bis zur aktuellen Version 77 online angeboten.

Pronom hat als Projekt das Ziel, für Langzeitarchive eine verlässliche Quelle für Dateiformate, Signaturen und zugeordnete Programme bereitzustellen. DROID übernimmt als Programm die Aufgabe der Identifikation unbekannter Formate.

Durch den strukturierten Aufbau der Signaturdateien ist eine automatische Auswertung möglich.

Im Folgenden ist die Anzahl der verschiedenen Dateiformate über die Zeit zu sehen:

Count of different fileformats based on DROID signatures, 08/2014, Andreas Romeyke

Auch hier ergibt sich ein nahezu linearer Zuwachs, spätestens ab Mitte 2010.

Da erst in späteren Signaturen ab ca. 2009 auch MIME-Types hinterlegt wurden, sieht die Entwicklung der einzelnen Kategorien im folgenden Diagramm etwas anders aus:

Count of different fileformats per category, based on DROID signatures, 08/2014, Andreas Romeyke

Hier noch das Shell-Script:

#!/bin/bash
echo "#version, date, application, text, images, audio, video"
for i in droid/DROID_SignatureFile_V*.xml; do
  version=$(echo $i |sed -e "s/.*_V\([^.]\+\).*/\1/" );
  date=$(cat $i | grep -m 1 "DateCreated=" |\

  sed -e "s/.*DateCreated=\"\(....-..-..\).*/\1/" );
  echo -n "$version, $date,"
  for category in application text image audio video; do
    count=$(xmlstarlet sel -t -v\

    "//_:FileFormat[contains(@MIMEType, \"$category/\")]/@Name" $i| \

    sort | uniq | wc -l)
    echo -n "$count,"
  done;
  echo
done | sort -n 

Wenn pro Jahr also 90 neue Dateiformate…

Die Anzahl der  Dateiformate wächst nahezu linear. Pro Jahr kommen im Schnitt 90 neue Dateiformate hinzu, die immerhin eine solche Verbreitung erfahren, dass sie in den Signatur-Datenbanken Widerhall finden.

Wenn wir in Zeiträumen von 50 Jahren denken, haben wir knapp 5000 Formate zu behandeln.

Wer alles in sein Langzeitarchiv hineinkippt, was ihm seine Nutzer anbieten, wird daher in Zukunft kaum die Ressourcen haben, Spreu und Weizen zu trennen und eine Langzeitverfügbarkeit sicherzustellen.

Die Entwicklung zeigt, dass dringend eine Spezialisierung der Langzeitarchive notwendig ist, um Wissen über Formate aufzubauen und sich gegenseitig zu unterstützen.

Es zeigt auch weiterhin, dass Nutzer der Archive über die Problematik aufgeklärt werden müssen.