Beurteilung der häufigsten Datei-/Videoformate und Datenträger
Für eine möglichst hohe Langlebigkeit von Dokumenten sind das Dateiformat und der Datenträger von grosser Bedeutung. Die im Folgenden aufgeführte Bewertung von Dateiformaten, Videoformaten und Trägerformaten wurde von der bereichsübergreifenden Arbeitsgruppe von Memoriav erarbeitet und vom Memoriav Kompetenznetzwerk Video begutachtet. Sie wurden hinsichtlich der Archivfähigkeit bzw. Eignung zur langfristigen Aufbewahrung vorgenommen und beziehen sich daher nur auf Archivkopien, nicht auf Kopien für die Benutzung oder andere Funktionen; letztere haben andere Anforderungen zu erfüllen als Archivkopien.
Die Bewertung basiert auf den Kriterien des NESTOR-Kompetenznetzwerks Langzeitarchivierung und Langzeitverfügbarkeit digitaler Ressourcen in seinem Handbuch: Eine kleine Enzyklopädie der digitalen Langzeitarchivierung (Neuroth et al., S. 147f). Die dort angegebenen Anforderungen gelten nicht nur für die Digitalisate, sondern auch für digital vorliegende oder digitalisierte Dokumentationen und die Metadaten.
Bei den in dieser Tabelle erwähnten Codecs handelt es sich um solche, die in Gedächtnisinstitutionen bereits Anwendung finden. Auf andere Codecs, die ebenfalls verlustfrei komprimieren, aber in der Schweiz wenig bis gar nicht verbreitet sind, wird hier nicht weiter eingegangen (z. B. HuffYUV, Lagarith, usw.). Die Bewertung wird in drei Stufen ausgedrückt:
Empfohlen: Basierend auf den Kriterien von NESTOR ohne Einschränkung zukünftiger Nutzung langfristig erhaltbar.
Bedingt empfohlen: Unterbindet gewisse Möglichkeiten der zukünftigen Nutzung, ist jedoch aus den jeweils angegebenen Gründen bedingt empfehlenswert.
Nicht empfohlen: Unterbindet wichtige Möglichkeiten der zukünftigen Nutzung und Migration, konkret: verlustbehaftet komprimiert, proprietär, nicht standardisiert, mögliche Obsoleszenz, Träger ungeeignet.
|
Kategorie: Einzelbilder (nur Film) |
|||
|
Formate |
Arbeitsbereich |
Archivtauglichkeit |
Kommentar |
|
TIFF unkomprimiert (16 bit lin) |
Aufnahme, Postproduktion, Archiv |
Empfohlen (Ohne Layer) |
Weit verbreitet, normiert, unkomprimiert; TIFF in 8 bit lin bietet keine genügende Auflösung der Farbtiefe und ist heute angesichts der Verarbeitungs- und Speicherkapazitäten kein empfehlenswerter Kompromiss mehr |
|
TIFF LZW-Kompression |
Aufnahme, Postproduktion |
Bedingt empfohlen |
Komprimiert, Kompatibilitätsprobleme zwischen verschiedenen Software-Versionen möglich |
|
DPX (10bit, 12bit, 16bit) |
Aufnahme, Postproduktion |
Empfohlen |
Weit verbreitet, unkomprimiert. Es existieren zahlreiche Varianten/Unterkategorien. |
|
JPEG 2000 |
Postproduktion, Distribution, Archiv |
Bedingt empfohlen |
Rechenintensiv, nicht vollständig lizenzfrei |
|
JPEG (skalierbare intraframe Kompression) |
Aufnahme, Postproduktion |
Nicht empfohlen |
Verlustbehaftete Komprimierung |
|
Kategorie: Videocodecs |
|||
|
Formate / Bitrate |
Arbeitsbereiche |
Archivtauglichkeit |
Kommentar |
|
DV (nur SD) / 25 Mbit/s |
Aufnahme, Postproduktion |
Bedingt empfohlen |
Bedingte Empfehlung aufgrund der grossen Verbreitung als Produktionsformat im Amateur- und im semiprofessionellen Bereich |
|
MPEG IMX, (MPEG-2, nur SD) / 50 Mbit/s |
Aufnahme, Postproduktion |
Bedingt empfohlen |
Bedingte Empfehlung aufgrund der grossen Verbreitung im Bereich TV |
|
DVCPro50 (nur SD) / 50 Mbit/s |
Aufnahme, Postproduktion |
Bedingt empfohlen |
Geringe Verbreitung, proprietäres Format (nur von Panasonic unterstützt) |
|
DVCPro100 (nur HD) / 100 Mbit/s |
Aufnahme, Postproduktion |
Bedingt empfohlen |
Geringe Verbreitung, proprietäres Format (nur von Panasonic unterstützt) |
|
10 bit-4:2:2-uncompressed (z. B. v210) / SD: 207 Mbit/s HD: 1,04 Gbit/s |
Postproduktion, selten Distribution, Archiv |
Empfohlen |
Trotz erheblicher Datenreduktion durch Farbunterabtastung geringe Auswirkung auf visuelle Qualität [Link zu Kap. 3.2.3.2], Verbreitung vor allem im musealen Kontext. v210 ist ein Apple-Codec, der je nach Container nicht absolut verlustfrei ist (QuickTime verwendet z. B. das erste Bit für die Synchronisierung) |
|
10 bit-4:4:4-uncompressed (z. B. v410, nur HD) / 1,56 Gbit/s |
Postproduktion, selten Distribution, Archiv |
Empfohlen |
Analog zu HDCam SR |
|
8 bit-4:2:2-uncompressed (z. B. YUY2 oder 2yuy) / SD: 165 Mbit/s HD: 830 Mbit/s |
Postproduktion, selten Distribution, Archiv |
Empfohlen |
Trotz erheblicher Datenreduktion durch Farbunterabtastung geringe Auswirkung auf visuelle Qualität [Link zu Kap. 3.2.3.2], Verbreitung v. a. im musealen Kontext |
|
H.264 / AVC (Advanced Video Coding) / variabel |
Produktion, Distribution |
Nicht empfohlen |
Kein einheitlicher Standard; siehe ergänzende Hinweise unten! |
|
H.265 / HEVC (High Efficiency Video Coding) / variabel |
Distribution |
Nicht empfohlen |
Standard existiert, viel effizientere Kompression als H.264 |
|
Apple ProRes / SD: 30–62 Mbit/s HD: 100–250 Mbit/s |
Postproduktion |
Bedingt empfohlen |
Varianten in qualitativ absteigender Reihenfolge: 4444 XQ, 422 HQ, 422 Standard, 422 LT und 422 Proxy), proprietäres Format der Firma Apple, Bitstream und Angaben zur Dekodierung von SMPTE offengelegt; bedingte Empfehlung nur für native ProRes-Dateien |
|
Apple ProRes RAW / variabel |
Aufnahme |
Bedingt empfohlen |
In Kameras sowie in Filmscannern eingesetzt. Bedingte Empfehlung nur für native ProRes-Dateien |
|
CineForm RAW / variabel |
Aufnahme |
Bedingt empfohlen |
In Kameras sowie in Filmscannern eingesetzt. Bedingte Empfehlung nur für native Cine-Form RAW-Dateien |
|
XDCam HD (MPEG-2) / 50 Mbit/s |
Aufnahme, Postproduktion |
Bedingt empfohlen |
Bedingt empfohlen, weil als Aufnahmeformat bei TV-Stationen ein Standard und daher stark verbreitet |
|
FFV1 (ab Version 3) / variabel |
Archiv |
Empfohlen |
Explizit für Archivzwecke entwickelter, verlustfrei komprimierender Codec |
|
Avid-Codecs (DNxHD) / SD: 146–186 Mbit/s |
Postproduktion |
Nicht empfohlen |
Kein einheitlicher Standard, unterschiedliche Avid-Codecs vorhanden, proprietäres Format der Firma Avid |
|
REDCODE RAW Familie, eng an JPEG 2000 angelehnt (nur HD) / HD: 224–336 Mbit/s |
Aufnahme |
Nicht empfohlen |
Langzeitkompatibilität ungewiss |
|
Kategorie: Container (Video) |
|||
|
Formate |
Arbeitsbereiche |
Archivtauglichkeit |
Kommentar |
|
Motion JPEG 2000 |
Archiv |
Nicht empfohlen |
Explizit für Archivzwecke entwickelt, wird jedoch kaum verwendet, und es existieren nur wenige und teure Implementierungen, gewisse Teile sind proprietär, eine sehr hohe Rechenleistung für das Erstellen und Lesen des dafür vorgesehenen Codecs JPEG 2000 ist erforderlich |
|
MP4 |
Distribution |
Bedingt empfohlen |
Sehr verbreiteter Container, für H.264 konzipiert, kann aber auch andere Video und Audio-Codecs (AAC, MP3, MP2, MP1) aufnehmen; ISO-normiert |
|
IMF (Interoperable Master Format) |
Postproduktion / Distribution |
Bedingt empfohlen |
Sehr flexibler und vielversprechender Container, aber weder im Archiv- noch in anderen Bereichen der Filmproduktion und Auswertung stark verbreitet; er hat aber Potential, falls die Industrie es portiert und eine Archivsubvariante definiert und standardisiert wird |
|
MKV (Matroska) |
Archiv |
Empfohlen |
Ist Open Source und wurde explizit für Archivzwecke entwickelt; wird heute in Kombination mit FFV1 sehr aktiv von einer internationalen Fachgemeinschaft genutzt und weiterentwickelt, u. a. wird dessen Standardisierung vorbereitet |
|
MOV (QuickTime File Format) |
Postproduktion / Distribution |
Bedingt empfohlen |
Sehr verbreiteter, proprietärer Container von Apple, der verschiedene Codecs aufnehmen kann; Vorbehalte, weil Apple das Format im Lauf der Zeit wesentlich verändert hat (jüngere Versionen lehnen sich z. B. an MP4 an) und den spezifischen Quicktime-Player für Windows-Betriebssysteme nicht weiter unterstützt |
|
AVI (Audio Video Interleave) |
Postproduktion / Distribution |
Bedingt empfohlen |
Sehr verbreiteter, proprietärer (Microsoft) Container, der verschiedene Codecs aufnehmen kann; Vorbehalte, weil beim Rewrapping von anderen Containern in AVI Metadaten wie z. B. das ursprüngliche Erstellungsdatum, Timecode verloren gehen können |
|
MXF (Material Exchange Format) |
Postproduktion / Distribution / Archiv |
Empfohlen |
Ein flexibler Standard im Broadcastbereich, kann z. B. auch Text- oder XML-Dateien mit Metadaten mit verpacken, ist aber gleichzeitig komplex und etwas schwieriger handhabbar als andere Container; die Spezifikation AS-7 wurde von staatlichen amerikanischen Archivinstitutionen entwickelt, ist etwas schwerfällig und erfordert rel. teure Software, kann aber als einzige konkrete Archiv-Spezifikation in Kombination mit JPEG 2000 nützlich sein |
|
DCP (Digital Cinema Package) |
Postproduktion / Distribution |
Bedingt empfohlen |
Kein eigentlicher Container, sondern eine definierte Folderstruktur, die die Medien in einem MXF-Container enthält; die Spezifikationen geben eine starke, verlustbehaftete Kompression vor und oft wird eine Verschlüsselung verwendet, welche die Handhabung bei der Archivierung wesentlich erschwert; bedingte Empfehlung nur für bereits vorliegende DCPs |
|
Kategorie Streamingformate |
||||
|
Formate |
Bitrate |
Arbeitsbereiche |
Archivtauglichkeit |
Kommentar |
|
|
|
|
|
Sind reine Distributionsformate, die mit proprietären, verlustbehafteten Kompressionen arbeiten (z. B. Flash, WebM, MP4); als Archivkopien ungeeignet |
|
Kategorie Videokassetten Kommentar für alle: Physische Videobänder können heute als obsolet betrachtet und als Archivformat grundsätzlich nicht mehr empfohlen werden. In Ausnahmefällen (bestehende Workflows und Infrastruktur etc.) können die unten aufgeführten Bandformate noch verwendet werden, auf das Umkopieren auf Bänder abgestützte Erhaltungskonzepte müssen aber so rasch als möglich abgelöst werden |
|||
|
Formate / Bitrate |
Arbeitsbereiche |
Archivtauglichkeit |
Kommentar |
|
DVCam / 25 Mbit/s |
Aufnahme, Postproduktion |
Siehe oben |
Bedingte Empfehlung aufgrund der grossen Verbreitung als Produktionsformat im Amateur- und im semiprofessionellen Bereich |
|
Digital Betacam (nur SD) / 126 Mbit/s |
Aufnahme, Postproduktion, Archiv |
Siehe oben |
Empfehlung als Übergangslösung in Alternative zu 10 bit-4:2:2-uncompressed Dateien in SD, wenn Gedächtnisinstitutionen Infrastruktur und Know-how für die Langzeiterhaltung von Dateien fehlen. Immer noch grosse Verbreitung, aber Dauer der Unterstützung gemäss Ankündigung des Herstellers Sony nur noch bis 2023 |
|
HDCam SR (nur HD) / 440/880 Mbit/s |
Aufnahme, Postproduktion |
Siehe oben |
Empfehlung im Aufzeichnungsmodus mit 4:4:4-Abtastung als Übergangslösung in Alternative zu 10bit-4:4:4-uncompressed HD Dateien, wenn Gedächtnisinstitutionen Infrastruktur und Know-How für die Langzeiterhaltung von Dateien fehlen. Dauer der Unterstützung durch Hersteller Sony nur noch bis 2023 |
|
Optische Datenträger für Video |
|||
|
Formate / Bitrate |
Arbeitsbereiche |
Archivtauglichkeit |
Kommentar |
|
DVD / 4–9 Mbit/s |
Distribution |
Nicht empfohlen |
Datenträger eignen sich nicht für die Archivierung |
|
BluRay / ca. 36 Mbit/s |
Distribution |
Nicht empfohlen |
Datenträger eignen sich nicht für die Archivierung |
|
XDCam
|
Aufnahme |
Nicht empfohlen |
Datenträger eignen sich nicht für die Archivierung |
|
Unspezifische Speichermedien |
|||
|
Formate |
Arbeitsbereiche |
Archivtauglichkeit |
Kommentar |
|
M-DISC |
Archiv |
Nicht empfohlen |
Medien aufgrund der Datendichte und Speicherkapazität nicht für AV geeignet; Zukunft der Produktion von Lesegeräten uns |
|
ODA |
Archiv |
Nicht empfohlen |
Proprietäres Format von Sony, keine Erfahrungen aus dem Archivbereich bekannt |
|
HDD |
|
Bedingt empfohlen |
Voraussetzungen: Mehrfachkopien an unterschiedlichen Standorten, Auswahl geeigneter Schnittstellen; erwartete Lebensdauer von 3 Jahren |
|
RAID |
|
Empfohlen |
Empfohlen unter der Voraussetzung, dass es weitere Sicherungskopien auf anderen Systemen gibt |
|
SSD |
|
Nicht empfohlen |
SSD-Speicher hängt von extrem kleinen Materialstrukturen ab, welche sowohl im Normalbetrieb wie auch durch äussere Einflüsse verhältnismässig rasch an die Grenze der Belastbarkeit gebracht wird und entsprechend schlecht altern; daher für langfristige Speicherung ungeeignet |
|
LTO (7 und 8) |
|
Empfohlen |
Format von Konsortium unterstützt, ab LTO-5 LTFS als Standard für das Beschreiben möglich. LTO-5 bis LTO-6 sollte zeitnah migriert werden, LTO-1 bis LTO-4 sollten unverzüglich migriert werden |
|
DLT |
|
Nicht empfohlen |
Veraltet |
Ergänzende Hinweise zu MPEG-4
Der Container MP4 und der Codec H.264 werden oft mit stark (verlustbehaftet) komprimierten Dateien in Verbindung gebracht, die für das Internet optimiert sind. MPEG-4/H.264 kann aber nicht nur sogenannt «visually lossless»-komprimierte und die am häufigsten eingesetzten, sogenannt «lossy»-komprimierten Daten enthalten, sondern auch nicht komprimiertes Y′CBCR 4:2:2. Letzteres wird allerdings nur in seltenen Fällen gemacht, wäre aber in dieser Konfiguration durchaus als Archivformat tauglich.
Ergänzende Hinweise zu JPEG 2000, Motion JPEG 2000 und FFV1
Der im Kern Open Source Codec JPEG 2000 (J2K) wurde im Jahr 2000 eingeführt und ist auf Einzelbilder ausgelegt. Es handelt sich um ein komprimiertes Dateiformat mit Intraframe-Kompression, basierend auf der Wavelet-Kompressionstechnik. Die Wavelet-Kompression liefert bei gleicher Verringerung der Datenmenge visuell bessere Resultate als die herkömmliche räumliche JPEG-Kompression und kann wahlweise unkomprimiert, verlustfrei komprimiert oder verlustbehaftet komprimiert angewendet werden. Die verlustfreie Kompression verringert die Dateigrössen um durchschnittlich die Hälfte. Dies ist eine vergleichsweise mässige Verringerung. Gleichzeitig ist die nötige Rechenleistung zur Durchführung der Kompression und zum Abspielen der komprimierten Dateien sehr hoch. Diese Tatsache und das Fehlen von anwenderorientierten Applikationen haben die Verbreitung des Codecs bis anhin behindert. Auch die standardisierte Implementierung (und damit die Kompatibilität zwischen verschiedenen Applikationen) ist mindestens in Frage gestellt. Es ist daher bis dato nicht klar, ob sich dieses Dateiformat in Gedächtnisinstitutionen wirklich durchsetzen wird (siehe Abb. 1).
Der J2K-Codec wird dagegen bei der Erstellung von Projektionselementen für das Kino nach dem internationalen Standard ISO/IEC 15444-1 mit verlustbehafteter Kompression verwendet. Projektionselemente werden als sogenannte Digital Cinema Packages (DCPs) ausgeliefert. Da diese Elemente heutzutage Archiven oft als einziges Archivelement angeboten werden, zwingt sich eine Auseinandersetzung mit dem Codec in dieser Form auf. Es ist wichtig festzuhalten, dass DCPs eigentlich nicht archivtauglich sind. Die angewendete J2K-Komprimierung ist wie erwähnt verlustbehaftet, es fehlen wichtige Metadaten und DCPs sind im Allgemeinen mit einem digitalen Sicherheitsschlüssel versehen, um Urheber- und Nutzungsrechte zu kontrollieren (DRM, Digital Rights Management). Verfügt man nicht über den Schlüssel oder läuft dieser nach einer gewissen Zeit ab, so sind die Daten selbst in tadellosem Zustand nur unter erschwerten Bedingungen nutzbar. J2K mit verlustfreier Kompression wird heute in Kombination mit einem MXF-Container von wichtigen Archivinstitutionen zur digitalen Archivierung von Einzelbildern (z. B. aus der Filmdigitalisierung) verwendet (z.B. Library of Congress, FADGI).
Motion JPEG 2000 wurde durch den später eingeführten Part 3 der ISO-Spezifikationen definiert. Es handelt sich um ein Containerformat, das Serien von J2K-Dateien sowie die zugehörige Tondatei aufnimmt und als Bewegtbild zur Verfügung stellt. Das Erstellen und auch das Abspielen von Motion JPEG 2000 Dateien ist ein äusserst rechenaufwendiger Prozess, was sich als wichtiges Hindernis in der Implementierung und Verbreitung des Formats herausgestellt hat. Bis heute steht nach wie vor kaum Software zur Erzeugung und Wiedergabe des Dateiformats zur Verfügung. Entsprechend ist es in Gedächtnisinstitutionen kaum anzutreffen.
Die wichtigste Alternative zu JPEG 2000 für die Archivierung von Bewegtbildern mit verlustfreier Kompression ist der für die Archivierung entwickelte und zunehmend in Gedächtnisinstitutionen eingesetzte Codec FFV1. Dieser Open-Source-Codec eignet sich bestens zur Archivierung von Videodateien, Ingests ab digitalen Kassettenformaten und Digital Born Dateien. Videos werden meist als einzelne grosse Dateien abgespeichert, die den Bilderstream enthalten. Filme, die oft als Serien von Einzelbildern digitalisiert werden [Link zu Kap. 5.4.2 Speicherung als Serien von Einzelbildern], können auch ohne Informationsverlust in einen FFV1-Stream umcodiert und mit Ton, Untertitel usw. in einem Matroska-Container verpackt werden. Man erhält so eine MKV-Datei mit einem Videostream und standardmässig eingebaute Prüfsummen, welche die automatisierte Kontrolle der Integrität jedes einzelnen Bildes (bzw. von Bildteilen oder sog. «slices») erlaubt. Diese Art der Speicherung vereinfacht die Bespielung von LTO-Bändern wie auch jeden anderen Kopiervorgang und Übertragungen im Vergleich zur Speicherung von Einzelbildern.
Die Verwendung von FFV1/MKV kann für Archive besonders auch deshalb interessant sein, weil damit Film und Video in der gleichen Form digital archiviert werden können. Ausserdem erleichtert diese Vorgehensweise auch die Herstellung von Benutzungskopien von Filmdokumenten, weil bereits ein Stream besteht, der schneller als Einzelbilder in geeignete Benutzungsformate transcodiert werden kann. Mit der Verwendung von FFV1/MKV für die Archivierung von Film reduziert man ausserdem die Datenmenge um einen bis zwei Drittel und muss im Gegensatz zur Erhaltung als Einzelbilder nur einen Bruchteil der Anzahl Dateien pflegen. Dadurch gewinnt man sehr viel Zeit beim Lesen (Öffnen) und Schreiben (Speichern) derselben.
Bei der Weiterverarbeitung kann sich FFV1/MKV als sperrig erweisen, da der native Import von FFV1/MKV in kommerzielle, professionelle Postproduktions-Software bisher nicht unterstützt wird. Für die Bearbeitung in kommerzieller Software müssen die Dateien transcodiert werden, um den Videostream zu bearbeiten. Es gibt dagegen Open Source Tools, welche die direkte Weiterverarbeitung als FFV1/MKV erlauben.
Gewisse Mängel von FFV1, die für die digitale Archivierung relevant sind, sind der Entwicklergemeinschaft bekannt und es wird an Versionen von FFV1 ohne diese Mängel gearbeitet. Da es sich um Open-Source-Entwicklung handelt, können spezifische Ansprüche auch in Form von Aufträgen an die Community angegangen werden.
Oft verhindert das Fehlen anwenderfreundlicher Implementierungen die weitere Verbreitung der Verwendung dieser Art von Codecs, was wiederum eine Empfehlung für die Anwendung in der Archivierung einschränkt. Entweder sind dafür vertiefte IT-Kenntnisse erforderlich, oder die Industrie nimmt diese Codecs und Formate in ihre Produktepalette auf. Ob sich auf die Archivierung ausgerichtete Formate auf diese Weise durchsetzen, hängt auch davon ab, ob sich wichtige und genügend Gedächtnisinstitutionen für deren Verwendung entscheiden.
J2K in MXF wird in folgenden bedeutenden Gedächtnisinstitutionen eingesetzt: Library of Congress, Washington; Cinematheque Royal, Brüssel; Institut national de l›audiovisuel (INA), Bry-sur-Marne.
Folgende (Gedächtnis-)Institutionen haben sich für FFV1 entschieden: Cinémathèque Française, Paris; Österreichische Mediathek, Wien; Stadtarchiv Lausanne; Archiv für Zeitgeschichte, Zürich; Swiss Archive for the Performing Arts (SAPA), Zürich; Museum für Kommunikation, Bern; weitere Institutionen weltweit sind in Wikipedia aufgelistet (Wikipedia, FFV1).
Mit unkomprimierten Dateiformaten arbeitet z. B. die Tate, London.
Diese Liste ist nur beispielhaft und bei weitem nicht vollständig.
Speicherung als Serien von Einzelbildern
35-mm-Langfilme sind durch die beschränkte Länge von Filmrollen in Akte unterteilt. Die maximale Länge einer Rolle für die Projektion betrug in der Frühzeit des Kinos bis zu 305 m, was bei einer Abspielgeschwindigkeit von 24 Bildern pro Sekunde einer Laufzeit von ca. 10 Minuten und ca. 16 000 Bildern entspricht. Ab den frühen 1930er-Jahren wurden grössere Rollen von bis zu 610 m eingeführt, was ca. 32 000 Bildern entspricht. Nach der Digitalisierung behält man grundsätzlich die gegebene Unterteilung in Akte als Serien von Einzelbildern in Dateiordnern bei und erhält pro Film je nach Gesamtlänge eine Serie von Dateiordnern, die diesen Akten bzw. den Filmrollen entspricht. Prüfsummen können entweder pro Ordner oder pro Einzelbild erstellt werden. In beiden Fällen empfiehlt sich eine automatisierte Erstellung. Die Speicherung von Bewegtbildern als Serien von Einzelbildern bietet gewisse Vorteile, aber auch Nachteile gegenüber der Speicherung als einzelne Datei [Link zu Kap. 4.3.8 und 5.2.2]. Sie wird im Allgemeinen für hochauflösende und Sonderformate angewendet. Bei einem Zugriff auf die einzelnen Bilder ist kein sofortiges Abspielen möglich. Dies ist jedoch je nach Dateigrösse bzw. Kompression auch bei Mediadateien nicht möglich. Statt mit wenigen sehr grossen Einzeldateien hat man es mit sehr vielen kleineren Dateien zu tun. Wird eine einzelne Datei fatal beschädigt, so ist der Datenverlust viel kleiner, besser eingrenzbar und einfacher zu reparieren bzw. wiederherzustellen als bei einem Defekt einer sehr grossen Videodatei. Dagegen ist die Handhabung weniger grosser Dateien ( insbesondere das Auslesen sowie die Datenübertragung z. B. für die Speicherung auf LTO) wesentlich einfacher bzw. mit weniger Zeit-, Rechenaufwand und Risiko von Übertragungsfehlern verbunden.
Bei der Speicherung von Serien von Einzelbildern ist Folgendes zu empfehlen:
-
Es muss gesichert sein, dass die Information der Abspielgeschwindigkeit nicht verloren geht.
-
Der Ton muss separat und unkomprimiert oder verlustfrei komprimiert gespeichert werden (ausgelegt auf die Abspielgeschwindigkeit). Visuelle und Audiomarker für die Synchronisierung müssen vorhanden sein.
-
Ein Chaos aufgrund der hohen Zahl der Einzelbilder muss vermieden werden. Namenskonventionen sind besonders wichtig, und je nach Anzahl müssen die Bilder in Ordneraufgeteilt werden.
Bibliographie und Links
-
FFV1, Wikipedia-Artikel (englisch). Online , Stand: 22.2.2022
-
Neuroth, H.; Oßwald, A.; Scheffel, R.; Strathmann; K. Huth, K. (Hg.): nestor Handbuch: Eine kleine Enzyklopädie der digitalen Langzeitarchivierung. Online , Stand: 22.2.2022
-
Library of Congress FADGI MXF AS-07. Online , Stand: 22.2.2022
Letzte Anpassung: November 2019