Von der ISO-DVD zum AVI-Hardsub

Vorwort

Dieser Artikel soll einen Überblick der Arbeitsabläufe beschreiben, die auf dem Weg von einer Original-DVD bis zum fertigen Anime-Fansub anfallen, wobei sich die vorliegende Beschreibung auf die Erzeugung von Hardsubs in AVI-Containern beschränkt.

Der Schwerpunkt der Ausführungen liegt darauf, zu erklären, warum die entsprechenden Schritte erforderlich sind, und ein Verfahren zum Erreichen einer Minimal-Lösung anzubieten, welches mit geringem Aufwand auch von einem unerfahrenen Encoder verwendet werden kann; erfahrene Encoder werden sicherlich in allen Teilaspekten aufwändigere Verfahren einsetzen und damit dann auch bessere Ergebnisse erzielen.

Format einer Video-DVD

Auf handelsüblichen Video-DVDs liegt das Anime-Material im Format MPEG2 vor.

• Bild- und Toninformationen sind dabei (im Gegensatz zu den auf PCs üblichen Video-Containern) nicht in separaten Streams gespeichert, sondern zu einem einzigen, großen Datenstrom vermengt.
• Dieser Datenstrom ist nicht nach Episoden unterteilt, sondern in mehreren, jeweils 1 GB großen Dateien (diese Maximalgröße ist vom DVD-Standard vorgeschrieben) mit der Endung .VOB enthalten, die sich im Verzeichnis VIDEO_TS der DVD befinden. Das Datenvolumen (Bild und Ton) umfasst in dieser Darstellung etwa 1500-2000 MB pro Anime-Episode.
• Das Anime-Material liegt nicht in Form von Bildern, sondern in Form von Halbbildern vor, aus denen die eigentlichen Bilder erst erstellt werden müssen (Deinterlacing).
• Die Bildinformationen sind üblicherweise anamorph gespeichert - das Bildformat des DVD-Videos ist also 720*480px (3:2), während das tatsächliche Seitenverhältnis des Animes jedoch 4:3 bzw. 16:9 sein soll. Handelsübliche Standalone-DVD-Player können solche Videos während des Abspielens (automatisch bzw. per Konfigurationsmenü einstellbar) in das korrekte Seitenverhältnis zerren (das Ziel-Seitenverhältnis ist auf der DVD vermerkt) - der Encoder eines Fansubs wird dies normalerweise selbst erledigen müssen.

Analyse der DVD-Daten

Im ersten Abschnitt der Verarbeitung werden die DVD-Daten so analysiert (und teilweise auch bereits vorverarbeitet), dass sie in einem den Werkzeugen nachgeschalteter Verarbeitungsschritte passenden Format vorliegen.

Markierung einer Anime-Episode innerhalb der DVD-Daten

Dazu werden mit dem Programm DGIndex die VOB-Dateien der DVD geöffnet. Nicht alle VOB-Dateien enthalten tatsächlich Anime-Material (die erste von ihnen enthält z. B. das Steuermenü der DVD, teilweise sind auch Trailer für andere Produkte derselben Firma auf der DVD enthalten); was genau jede dieser Dateien enthält, kann man sich mit diesem Programm ansehen.

Am unteren Rand des Anzeigefensters befindet sich ein Schieberegler, mit dessen Hilfe man mit den Buttons "[" bzw. "]" die Anfangs- und Endmarke des zu bearbeitenden Materials manuell setzen kann - man muss den Umfang einer Episode also selbst auswählen.

Extrahieren der Audio-Daten aus dem MPEG2-Stream

Im Programm DGIndex kann man einstellen, wie man die Audio-Daten des vorliegenden Materials verarbeiten möchte.

Eine DVD kann mehrere Audio-Streams enthalten; diese können in unterschiedlichen Formaten vorliegen:

• Audio-Streams im Format PCM sind verlustlos gespeichert. Da sie demzufolge sehr viel Platz auf der DVD benötigen, ist ihre Verwendung eher unüblich.
• Audio-Streams im verlustbehafteten Format AC3 bieten eine hohe Tonqualität und können insbesondere bis zu sechs (5.1) Tonkanäle enthalten. Ein AC3-Stream mit einer Qualität von 448 kbit/sec für eine Anime-Episode von 23 Minuten Spieldauer belegt etwa 77 MB Speicherplatz im späteren Encoding des Fansubs.
• Audio-Stream im verlustbehafteten Format DTS bieten ebenfalls eine hohe Tonqualität und können bis zu Surround-Sound bis zu 7.1 enthalten. Im Gegensatz zu AC3 ist DTS auf DVDs optional.
• Audio-Streams im verlustbehafteten Format MP2 sind auf maximal zwei Tonkanäle beschränkt, benötigen dafür aber relativ wenig Speicherplatz.

Das Tonformat innerhalb von AVI-Containern bei Verwendung von Hardsubs ist meist ein MP3-Stream mit 128 kbit/sec, während bei Verwendung anderer Container häufig andere Formate wie OGG Vorbis bzw. AAC Verwendung finden.

Während der Vorverarbeitung des Materials kann man die Audio-Daten in separate Dateien (je eine Datei pro Stream) extrahieren lassen (wie wir sie später beim Encoden auch benötigen werden), und zwar wahlweise

• im bereits vorliegenden Format oder
• umgewandelt in das WAV-Format

Vor Beginn der Analyse der DVD-Daten weiß DGIndex nicht, wie viele Audio-Streams die DVD besitzt und welchen Inhalt diese Spuren enthalten (selbst japanische Original-DVDs enthalten manchmal mehrere Audio-Streams, etwa mit Anmerkungen von Regisseur bzw. Seiyuu zu einzelnen Szenen). Der Encoder muss also zunächst einmal sämtliche Audio-Spuren extrahieren und sich dann im Einzelnen ansehen, welche davon er verwenden will.

Zu beachten ist, dass ein Audio-Stream nicht exakt gleichzeitig mit dem Anfang des Video-Streams beginnen muss, sondern einen Delay relativ zu diesem aufweisen kann; um dieses Delay verschoben muss der Audio-Stream später wieder mit dem Video-Stream zusammengefügt werden, damit Bild und Ton synchron bleiben. Ein eventueller Delay wird beim Abspeichern des betreffenden Audio-Streams im Namen der erzeugten Datei vermerkt.

Durchführung des Analyselaufs mit DGIndex

Nachdem die entsprechenden Einstellungen für die Auswahl des Video-Materials und die Extraktion des Audio-Materials vorgenommen wurden, startet man mit Save Project den Analyselauf (der für eine normale Anime-Episode auf einem Pentium-4-PC mit 3 GHz etwa 5 Minuten dauert). Das Ergebnis dieses Verarbeitungslaufes ist keine Video-Datei in einem neuen Format, sondern lediglich eine kleine (ca. 200 kB pro Episode) Projektdatei (mit der Endung .d2v), die Verweise in die DVD-Daten enthält; diese DVD-Daten brauchen wir also zunächst einmal weiterhin als Arbeitsdateien.

Im selben Verzeichnis wie diese Projektdatei werden die extrahierten Audio-Streams gespeichert. Ab diesem Zeitpunkt bleiben Bild- und Toninformationen getrennt und werden erst beim Encoding eines fertigen AVI-Containers wieder zusammengefügt.

In dem während der Verarbeitung geöffneten Dialog wird dabei auch das tatsächliche Seitenverhältnis des Videos angezeigt (welches nicht mit dem Seitenverhältnis übereinstimmt, in dem DGIndex das Video selbst anzeigt!); diese Information sollte man sich ggf. notieren, sie wird später noch benötigt werden.

Bearbeitung der Video-Daten

Im zweiten Abschnitt der Verarbeitung wird nun das mit Hilfe der Projektdatei ansprechbare Videomaterial so bearbeitet, dass eine Datei (das sogenannte Timing Raw) entsteht, mit der die einzelnen Mitglieder des Fansub-Projekts arbeiten können (bisher haben wir die Daten ja nach wie vor im MPEG2-Format vorliegen). Etwaige Verbesserungen der Bildqualität werden ebenfalls in diesem Abschnitt durchgeführt.

Das in diesem Schritt verwendete Werkzeug ist Avisynth, was aus der Sicht des Systems ein Codec ist (eine Bibliotheksfunktion, welche einen Video-Stream in einen anderen Video-Stream umwandelt). Avisynth besitzt keine Benutzeroberfläche; seine Verarbeitung wird vielmehr durch Skriptdateien gesteuert, in welchen der Encoder Anweisungen zur Umwandlung des Videomaterials notiert. Ein solches Skript wird dann von Avisynth interpretiert und auf den eingelesenen Video-Stream angewendet; es gibt einen entsprechend bearbeiteten Video-Stream aus. Diese Ausgabe eines solchen Verarbeitungsgangs kann dann insbesondere wie eine Videodatei mit einem Videoplayer abgespielt werden oder auch als Eingabe für ein Encoding-Tool dienen.

Dieser Abschnitt kann je nach Kenntnissen und persönlichen Vorlieben des Encoders zahlreiche weitere Einzelschritte umfassen; das vorliegende Dokument versucht, sich auf das absolute Minimum zu beschränken.

Zugriff auf die MPEG2-Daten

Die folgende Anweisung des Skripts dient dazu, die MPEG2-Daten der DVD zu lesen:

# MPEG2-Daten direkt aus den VOB-Dateien lesen, nach vorheriger Analyse derselben via DGIndex.exe
  LoadPlugin           (Pfadname der Bibliothek dgdecode.dll)
  DGDecode_Mpeg2Source (Pfadname der Projektdatei)

Diese Funktion wird realisiert durch die (mit DGIndex mitgelieferte) Bibliothek dgdecode.dll, welche entweder durch die Anweisung LoadPlugin dem Skript explizit bekannt gemacht werden oder aber an einem für Avisynth zugänglichen Ort installiert worden sein muss.

Dabei greift das Skript mit Hilfe einer Plugin-Funktion und unter Verwendung der von DGIndex erstellten Projektdatei auf die VOB-Dateien der DVD zu. Das Ergebnis dieses Zugriffs ist ein unkomprimierter Video-Stream, auf welchen die anschließenden Bearbeitungsschritte angewendet werden können.

Zusammenfassung der Halbbilder zu Bildern (Deinterlacing) für eine NTSC-DVD

Japanische Original-DVDs liegen im NTSC-Format vor und verwendet deshalb üblicherweise 59,94 Halbbilder je Sekunde. Diese Anweisung des Skriptes dient dazu, die Halbbilder der MPEG2-Daten zu vollständigen Bildern mit Hilfe des Deinterlacing zusammenzufassen. Das Resultat sind 29,97 (Ganz-)Bilder je Sekunde. Ein mechanisches Zusammenfassen benachbarter Halbbilder reicht dafür nicht aus - dadurch würde es häufig vorkommen, dass Halbbilder zusammengefasst würden, welche nicht zusammengehören, was sich erstens in unschön gestrichelten Linien bemerkbar macht (Kammeffekt) und zweitens das Videomaterial auch noch schlechter komprimierbar macht (also bei gleicher Informationsmenge zu größeren Dateien als Ergebnis des abschließenden Encoding-Durchgangs führt), weil einfarbige Flächen bzw. Striche platzsparender dargestellt werden können als einzelne Punkte mit abwechselnden Farben.

Die folgende Anweisung des Skripts bietet eine einfach zu bedienende Lösung, indem sie den Deinterlacing-Vorgang automatisch durchführt, dabei jedoch das vorliegende Videomaterial statistisch auswertet und dadurch zu sehr ordentlichen Ergebnissen kommt:

# Deinterlacing (intelligentes Verfahren, aus TIVTC)
  LoadPlugin           (Pfadname der Bibliothek tivtc.dll)
  tfm                  (slow=2)

Diese Funktion wird realisiert durch eine im Paket TIVTC enthaltene Bibliothek tivtc.dll, welche entweder durch die Anweisung LoadPlugin dem Skript explizit bekannt gemacht werden oder aber an einem für Avisynth zugänglichen Ort installiert worden sein muss.

Der Parameter slow=2 weist die Funktion an, das langsamste Verfahren anzuwenden, welches zu den qualitativ besten Ergebnissen führt; die Funktion unterstützt eine Reihe weiterer Parameter, welche in der mitgelieferten Dokumentation des TIVTC-Pakets ausführlich beschrieben sind.

Es sei ausdrücklich erwähnt, dass es andere Lösungen für das Deinterlacen gibt, insbesondere die Verwendung des Programms Yatta, mit welchem Video-Puristen das gesamte Video-Material Bild für Bild durchgehen und jeden einzelnen Frame wunschgemäß erzeugen lassen können; dieser Arbeitsgang erzeugt dann ebenfalls (umfangreiche) Anweisungen für das Avisynth-Skript.

ACHTUNG: Ein konkretes Verfahren zum Deinterlacen, angewendet auf ein bestimmtes Videomaterial, erzeugt seine ganz eigene Sequenz von effektiven Bildern; insbesondere an Szenenübergängen ist es völlig normal, dass zwei verschiedene Deinterlacing-Verfahren unterschiedliche Ergebnisse erzeugen, wodurch sich insbesondere ganze Szenen um 1 Frame verschieben können. Die Entscheidung für ein bestimmtes Verfahren, die der Encoder trifft, sollte also nach Möglichkeit endgültig sein - eine nachträgliche Änderung an dieser Stelle kann bewirken, dass sämtliche Zeitangaben von Untertiteln nicht mehr exakt zum Videomaterial passen und deshalb das komplette Timing nachgearbeitet werden muss. (Dies erklärt u. a. entsprechende Verschiebungen des Typesetting um genau 1 Frame in einigen Fansub-Releases.)

Reduzieren der Bildrate (Decimate) für eine NTSC-DVD

Die 29.97 Bilder pro Sekunde müssen nun auf 23.976 Bilder pro Sekunde dezimiert werden, um wieder die Originalfilmrate zu erreichen (die für das Abspielen auf japanischen Geräten im NTSC-Standard künstlich um 25% erhöht werden musste - zudem lassen sich die auf diese Weise entstandenen Videos auch noch schlechter komprimieren). Dies wird dadurch erreicht, dass im Prinzip jedes fünfte Bild des Original-Videos weggelassen wird. (Tatsächlich würde die mechanische Durchführung eines solchen Verfahrens rhythmische Veränderungen am Videomaterial verursachen, die sich in einem spürbaren Ruckeln manifestieren können; die tatsächliche Verarbeitungslogik ist daher etwas komplizierter.)

Die folgende Anweisung des Skripts dient dazu, die Anzahl der im vorherigen Schritt erzeugten vollständigen Bildern auf die gewünschte Framerate zu reduzieren:

# Dezimieren von jeweils 5 auf 4 Frames (29.97 fps => 23.976 fps)
# LoadPlugin           (Pfadname der Bibliothek tivtc.dll)
  tdecimate            (mode=1)

Diese Funktion wird realisiert durch eine im Paket TIVTC enthaltene Bibliothek tivtc.dll, welche entweder durch die Anweisung LoadPlugin dem Skript explizit bekannt gemacht werden oder aber an einem für Avisynth zugänglichen Ort installiert worden sein muss. (Da dies dieselbe Bibliothek ist, die zuvor bereits für das Deinterlacen verwendet wurde, ist die LoadPlugin-Anweisung hier redundant und wurde deshalb auskommentiert.)

Der Parameter mode=1 weist die Funktion an, die zu entfernenden Bilder bevorzugt aus möglichst langen Reihen identischer Bilder zu wählen (von denen ein weggelassenes Bild am leichtesten entbehrlich ist); die Funktion unterstützt eine Reihe weiterer Parameter, welche in der mitgelieferten Dokumentation des TIVTC-Pakets ausführlich beschrieben sind.

Wegschneiden unschöner Bildteile an den Rändern (Cropping)

Von den 720*480px des Bildmaterials der DVD sind manchmal bestimmte Teile nur eingeschränkt verwendbar:

• An einigen Rändern des Bildes sind üblicherweise durchgehend schwarze Balken zu sehen.
• Innerhalb des verbleibenden Bildes liegen in den äußersten Pixel-Reihen bzw. -Spalten manchmal starke Verfärbungen vor, die eine ähnliche optische Wirkung wie schwarze Balken haben.

Da das Videomaterial anschließend ohnehin auf die tatsächliche Größe des endgültigen Videos verzerrt werden muss, bietet es sich an, diese unschönen Teile (die prozentual nur einen kleinen Teil des Bildes ausmachen, deren Weglassen also die Bildproportionen nicht spürbar verändert) bereits vor dieser Skalierung aus dem Bildmaterial wegzuschneiden und auf diese Weise das Zielformat des Videos ausschließlich mit "schönen" Bildinformationen zu füllen. Die konkreten Beträge an wegzulassenden Zeilen bzw. Spalten des Bildes hängen sowohl vom konkreten Videomaterial als auch vom subjektiven Geschmack des Encoders ab.

Die folgende Anweisung des Skripts dient dazu, die angegebene Anzahl von Pixeln des Videomaterials an den vier Seiten des Bildes wegzuschneiden:

# Schwarze Streifen etc. am Rand wegschneiden
  crop                 (links, oben, breite, höhe)

Dabei bedeuten die vier Parameter der Funktion:

1. Linke obere Ecke (Spalte)
2. Linke obere Ecke (Zeile)
3. positiver Wert: Breite des Bildes nach Wegschneiden des Randes;
   negativer Wert: Rechte untere Ecke (Spalte)
4. positiver Wert: Höhe des Bildes nach Wegschneiden des Randes;
   negativer Wert: Rechte untere Ecke (Zeile)

Bei einem Aufruf crop (4,2,-0,-2) würden also links 4 Pixel, rechts 0 Pixel sowie oben und unten jeweils 2 Pixel weggeschnitten (bei Angaben in dieser Notation muss man weniger rechnen ;-).

Diese Funktion gehört zu den Avisynth-Grundfunktionen und muss deshalb nicht separat hinzugeladen werden.

ACHTUNG: Die konkreten Angaben zum Croppen, angewendet auf ein bestimmtes Videomaterial, erzeugen ihre ganz eigene Sequenz von effektiven Bildern; bei anderen Angaben an dieser Stelle wird zwar im Prinzip dieselbe Bildsequenz erzeugt, aber Objekte innerhalb des Bildes befinden sich nicht an derselben Stelle, als wenn ein anderer Betrag an Rand weggeschnitten worden wäre. Die Entscheidung für einen bestimmten Satz an Parameterwerten, die der Encoder trifft, sollte also nach Möglichkeit endgültig sein - eine nachträgliche Änderung an dieser Stelle bewirkt, dass sämtliche Positionen von Untertiteln nicht mehr exakt zum Videomaterial passen und deshalb das komplette Typesetting nachgearbeitet werden muss.

Anpassen der Bildgröße auf das gewünschte Zielformat

Aufgrund der oben erwähnten anamorphen Bilddarstellung auf DVDs liegt das Bildmaterial oftmals nicht in dem tatsächlich darzustellenden Format vor (das eigentlich erwünschte Seitenformat haben wir während der Analyse des DVD-Materials ermittelt). Hinzu kommt, dass wir im vorherigen Arbeitsschritt ggf. an den Rändern bestimmte Bereiche weggeschnitten haben.

Welche Bildgröße wollen wir erreichen? Beide Seitenlängen müssen (bei Verwendung eines MPEG4-Codec) durch 4 teilbar sein und sollten möglichst durch 16 teilbar sein; das in der Größe von 720*480px vorliegende Bildmaterial sollte in keiner der beiden Dimensionen hochskaliert werden, um nicht an Qualität zu verlieren. Das bedeutet konkret:

• Für Videos mit den Seitenverhältnissen 4:3 ist ein Bildformat von 640*480px üblich.
• Bei einem Seitenverhältnis von 16:9 lässt sich eine exakte Teilbarkeit der Höhe durch 16 nur erreichen, wenn die Höhe ein Vielfaches von 9*16 = 144px ist; das größe Format, das die Breite von 720px nicht überschreitet, wäre in diesem Falle dann 512*288px, was jedoch deutlich kleiner wäre als unser Ausgangsmaterial. Gibt man sich jedoch mit einer Teilbarkeit beider Dimensionen durch 4 zufrieden, dann ist die größte verwendbare Auflösung 704*396px; wenn man darüber hinaus bereit ist, eine geringfügige Seitenverzerrung zu akzeptieren, kann man 720*405px anstreben (was exaktes 16:9 wäre) und das Bild dann auf 720*404px verzerren.

Die folgende Anweisung des Skripts dient dazu, die Bildgröße des Video-Streams in Breite und Höhe auf den gewünschten Wert zu skalieren (wobei es irrelevant ist, in welcher Größe das Videomaterial nach den vorherigen Transformationen tatsächlich vorliegt):

# anamorphe DVD-Auflösung korrigieren und Bildformat das gewünschte Zielformat zerren
  LanczosResize (breite, höhe)

Diese Funktion gehört zu den Avisynth-Grundfunktionen und muss deshalb nicht separat hinzugeladen werden.

Auch hier wieder der Hinweis, das es zahlreiche andere Verfahren zur Änderung der Bildgröße gibt, welche sich u. a. in Bezug auf die Behandlung dünner Linien unterscheiden (also ggf. unterschiedlich scharfe bzw. verwaschene Ergebnisse produzieren).

Durch zusätzliche Parameter für die jeweilige Resize-Funktion ist es auch möglich, Cropping und Resizing in einem Arbeitsgang zu erledigen (was die Verarbeitungsgeschwindigkeit minimal erhöht); Einzelheiten sind der Dokumentation der jeweiligen Funktion zu entnehmen.

Filter zur Qualitätsverbesserung

Nachdem nun das Videomaterial im Prinzip im richtigen Format (Vollbilder in der gewünschten Bildschirmauflösung) vorliegt, kann in einem abschließenden Verarbeitungsschritt noch Einfluss auf die Bildqualität genommen werden. Hierfür werden je nach subjektivem Ästhetik-Empfinden des Encoders entsprechende Filter auf das Videomaterial angewendet, um kleine Unsauberkeiten zu entfernen, dünne Linien zu schärfen oder die Auswirkungen bestimmter systematischer Fehler des Bildmaterials zu reduzieren. Grundsätzlich gilt dabei: Die Entfernung von Details verbessert einerseits die spätere Komprimierbarkeit des Videostreams, bewirkt aber gleichzeitig, dass das Bild verwaschener aussieht; je aggressiver die entsprechende Filterfunktion dabei vorgeht (was jeweils durch entsprechende Parameterwerte eingestellt werden kann), umso stärker sind beide Effekte spürbar.

Die folgende Anweisung des Skripts dient dazu, mit einem relativ defensiven Filter kleine Unsauberkeiten des Bildmaterials aufzulösen:

# Defensives Entfernen von Bild-Unsauberkeiten
  RemoveGrain (mode=2)

Der Parameter mode=2 weist die Funktion an, das bezüglich des Einsparungseffekts beste der drei vom Autor als "risikolos" beschriebenen Verfahren anzuwenden; die Funktion unterstützt auch weitaus aggressivere Verfahren (die dann allerdings dünne Linien beschädigen können etc.), welche in der mitgelieferten Dokumentation des TIVTC-Pakets ausführlich beschrieben sind.

Diese Funktion wird realisiert durch eine im Paket RemoveGrain enthaltene Bibliothek (der konkrete Dateiname ist von der CPU des Zielrechners abhängig, siehe Installationsanleitung), welche entweder durch die Anweisung LoadPlugin dem Skript explizit bekannt gemacht werden oder aber an einem für Avisynth zugänglichen Ort installiert worden sein muss.

Das erzeugte Video wird dabei ohne spürbare Einbußen der Qualität um wenige Prozent kleiner.

Beispiel eines vollständigen Avisynth-Skripts zur Verarbeitung der DVD-Daten

Ein vollständiges Avisynth-Skript sieht (nach der Installation aller erforderlichen Bibliotheken im plugins-Verzeichnis von Avisynth, wo sie automatisch gefunden werden) beispielsweise folgendermaßen aus:

# MPEG2-Daten direkt aus den VOB-Dateien lesen, nach vorheriger Analyse derselben via DGIndex.exe
  Mpeg2Source          ("C:\DVD-Analyse\Seikai no Senki III\Volume 1\Seikai no Senki III Volume 1 - Video.d2v")

# Deinterlacing
  tfm                  (slow=2)

# Dezimieren von jeweils 5 auf 4 Frames (29.97 fps => 23.976 fps)
  tdecimate            (mode=1)

# Schwarze Streifen etc. am Rand wegschneiden
  crop                 (4, 2, -0, -2)

# anamorphe DVD-Auflösung korrigieren und Bildformat das gewünschte Zielformat zerren
  LanczosResize        (704, 396)

# Defensives Entfernen von Bild-Unsauberkeiten
  RemoveGrain          (mode=2)

Wenn eine solche Skript-Datei, welche anstelle des Pfadnamens der Projektdatei die Zeichenkette __vid__ enthält, im Analyseprogramm DGIndex als "AVS template" angegeben wurde, dann fügt DGIndex während der Analyse des DVD-Materials diesen Pfadnamen der neu erstellten Projektdatei (ohne Gänsefüßchen) automatisch an der entsprechenden Stelle der Schablone ein und speichert das so dem Projekt angepasste Skript in dasselbe Verzeichnis und mit demselben Basisnamen wie die Projektdatei, aber mit der Endung .avs. Man braucht dieses Skript also nur ein einziges Mal zu erstellen (und z. B. ins Installationsverzeichnis von DGIndex zu speichern) und muss dann bei neuen Projekten nur noch Details darin ändern (Pixel-Angaben zum Cropping und ggf. zum Bildformat, eventuell andere Filter).

Speichern des Verarbeitungs-Ergebnisses

Das Ergebnis der Verarbeitung der DVD-Daten ist ein (zunächst einmal) unkomprimierter Video-Stream, der für eine normale Anime-Episode zwischen 10 und 15 GB an Daten umfasst. Bei Verwendung der angegebenen simplen Filterfunktion dauert das Erstellen der entsprechenden Video-Datei auf einem Pentium-4-PC mit 3 GHz knapp 15 Minuten; falls entsprechend aufwändigere Filter zum Einsatz kommen, kann diese Verarbeitung aber auch wesentlich länger (mehrere Stunden) dauern.

Sobald das Verfahren zu einem Ergebnis geführt hat, welches die Ansprüche des Encoders zu dessen Zufriedenheit erfüllt, möchte dieser das Ergebnis des Skript-Laufes eigentlich bis zum endgültigen Release nicht mehr löschen (um den Filtervorgang nicht wiederholen zu müssen). Eine verlustbehaftete Komprimierung scheidet allerdings aus, da deren Ergebnis nicht mehr die erforderliche Qualität für die spätere Produktion von QC- und Release-Dateien aufweist. Es existieren jedoch Codecs, welche eine verlustfreie Komprimierung des erzeugten Videomaterials ermöglichen (z. B. HuffYUV und Lagarith). Bei einer Speicherung des Video-Materials unter Verwendung eines dieser Verfahren kann das Datenvolumen um etwa 50-60% reduziert werden, sodass pro Episode eine Datei von etwa 5-6 GB Größe anfällt. Sobald sämtliche Episoden der DVD in diesem Format vorliegen, benötigt man die VOB-Dateien dieser DVD nicht mehr auf der Festplatte des Encoding-Rechners.
(ACHTUNG: Sowohl HuffYUF in der Version 2.2.0 als auch Lagarith in der Version 1.3.13 weisen Stabilitätsprobleme auf, die zum Absturz des Komprimierungslaufs führen können; der Verfasser dieses Artikels verwendet deshalb die etwas ältere Version 2.1.1 von HuffYUF.)

Für die Weitergabe des so bearbeiteten Videomaterials an andere Mitglieder der Fansubber-Gruppe (vor allem den Timer und den Typesetter, insbesondere über langsame Internet-Leitungen) ist natürlich eine solche Datei immer noch viel zu groß. Deshalb erzeugt der Encoder zusätzlich eine (mit dem später zu verwendenden Video-Codec und sinnvollerweise auch etwa den später zu verwendenden Einstellungen) komprimierte Variante des Videos, das sogenannte Timing-Raw, dessen Größe sich von derjenigen des späteren Release nur unwesentlich unterscheidet (man kann in der Qualität auch problemlos ein wenig nach unten gehen, um Übertragungsvolumen zu sparen). Dieses Timing-Raw muss dann auch einen Audio-Stream enthalten (der um den entsprechenden Delay zeitlich verschoben eingefügt werden muss) , damit der Timer die passenden Zeitpunkte zum Ein- und Ausblenden der Untertitel exakt festlegen kann. (Bei einem Soloprojekt könnte man die verlustfrei komprimierten Video-Daten, ergänzt um den Audio-Stream, auch gleich als Timing-Raw verwenden.)

Encoding als AVI-Container mit XviD-Videostream

Nach der Erstellung des Timing-Raws wird der Encoder erst wieder tätig, wenn sämtliche Untertiteldateien zur betreffenden Episode bei ihm abgeliefert wurden. Nun brennt er diese als Hardsub fest in den Videostream der Episode ein, wobei er eines von mehreren möglichen Zielen zu verfolgen versucht.

Optimale Ausnutzung eines Zielmediums

Eine einzelne Anime-Episode wird ihrer endgültigen Form ca. 150-250 MB an Speicherplatz belegen (TV-Episoden tendentiell weniger als OVA-Episoden, welche oftmals bis zu 30 Minuten lang sind und ggf. eine aufwändigere Animation besitzen).

Falls solche Dateien auf Datenträgern des Typs CD bzw. DVD gespeichert werden sollen (um sie auf einem Standalone-Player über einen Fernseher abzuspielen, was vom Container- und Codec-Format her ja möglich wäre) und der Encoder die Anzahl der Episoden (und ggf. zugehörigen Specials) der gesamten Serie von vornherein kennt, kann er die Größe der von ihm erzeugten Dateien auf das geplante Ziel-Medium abstimmen:

• Eine handelsübliche CD fasst 703 MB an Daten, also
  • 3 Episoden zu je 234 MB (Videoqualität ca. 1150 kb/sec) bzw.
  • 4 Episoden zu je 175.5 MB (Videoqualität ca. 900 kb/sec).
• Eine Single Layer DVD fasst 4483 MB an Daten, also
  • 24 Episoden zu je 186.5 MB (Videoqualität ca. 1000 kb/sec) bzw.
  • 26 Episoden zu je 172 MB (Videoqualität ca. 850 kb/sec).

Diese Größen werden von vielen Fansubber-Gruppen gezielt produziert, indem im XviD-Codec die Spieldauer (sekundengenau) und Zielgröße der Datei sowie die Qualität des verwendeten Audio-Streams eingegeben wird; XviD kann aus diesen Angaben die maximal zulässige Qualität für den Videostream (gemessen in kbit/sec) berechnen und diese bei Verwendung des 2-Pass-Encoding auch ziemlich exakt erreichen. Damit belegen alle Episoden einer Serie gleich viel Speicherplatz auf dem Zielmedium - unabhängig von der Spieldauer der einzelnen Episode. Bei TV-Serien ist diese Spieldauer üblicherweise konstant, nicht aber bei OVAs - und in solchen Fällen liefert diese Methode unterschiedliche Qualitäten für die verschiedenen Episoden.

Um letzteres zu verhindern, kann man die auf einen Datenträger (etwa eine CD) zu brennenden Episoden von vornherein als zusammengehörig betrachten und ihre Gesamtspieldauer als Berechnungsgrundlage für die obige Methode heranziehen. Bei der Verwendung der so berechneten Durchschnittsqualität dieser CD für jede ihrer Episoden entstehen dann verschieden große Dateien mit gleicher Video-Qualität, während das jeweilige Speichermedium immer noch optimal ausgenutzt wird. Dieser Ansatz wurde beispielsweise beim Encoding der Serie Lamune verfolgt.

Optimale Darstellung der vorliegenden Informationsmenge

Das Encoden von Videomaterial mit einem der üblichen Codecs ist immer eine verlustbehaftete Komprimierung, und der Grad des Verlusts kann vom Encoder im Prinzip frei gewählt werden. Insbesondere ist es durchaus normal, dass in einer Episode einer Serie mit hohem Action-Anteil wesentlich mehr Video-Information vorliegt als in einer anderen Episode derselben Serie, welche von langen Dialogen dominiert wird; werden beide Episoden dennoch auf dieselbe Dateigröße encodiert, dann leidet die Qualität der Action-Episode, während bei der Dialoge-Episode Platz verschwendet wird. Und wenn die fertigen Dateien letzten Endes auf der Festplatte eines Fans landen oder eine Serie mit z. B. nur 13 Episoden auf eine DVD gebrannt werden wird, dann sollte die exakte Größe der Datei gegenüber einer möglichst guten Video-Qualität bei im Mittel dennoch akzeptabler Dateigröße (zwecks schneller Übertragung) nur von untergeordneter Bedeutung sein.

Für das Erreichen der optimalen Videoqualität einer jeden Episode wäre es also ein alternativer Ansatz, es dem Codec selbst zu überlassen, wie groß er die entsprechende Datei erzeugen will. Dazu kann man ihm im Falle von XviD als Zielvorgabe einfach einen Qualitätswert angeben, den er angesichts der vorliegenden Informationsmenge gar nicht erreichen kann (etwa 9999 kbit/sec) und gleichzeitig die resultierende Dateigröße durch einheitliche Vorgaben in der XviD-Konfiguration beeinflussen, wobei diese XviD-Konfiguration dann auf alle Episoden einer Serie gleichermaßen angewendet wird. Dabei entstehen zwar Dateien beliebig unterschiedlicher, aber jeweils der vorliegenden Information angemessener Größe.

Bewährt hat sich dabei insbesondere, in der XviD-Konfiguration unter "Quality Preset - more" / "Quantization" für den "min. P-Frame quantizer" einen Wert von 2 (statt 1) einzutragen, also dem XviD-Codec die Verwendung von P-Frames mit einem Quant von 1 zu verbieten. P-Frames mit einem Quant von 1 belegen innerhalb eines XviD-Streams relativ viel Platz, tragen jedoch eher wenig zur Bildqualität bei; allein durch den Verzicht auf diese Möglichkeit bringt man den XviD-Codec bei guter Qualität des Videomaterial oftmals (wenngleich nicht immer) bereits dazu, trotz ansonsten maximaler Ausschöpfung seiner Möglichkeiten Dateien in einer ungefähren Größe zu produzieren, wie sie aufgrund der Zielsetzung im vorherigen Kapitel ohnehin erwünscht ist.

Gleichzeitig lässt sich bei diesem Ansatz durch den Einsatz etwas aggressiverer Filter bereits bei der Vorverarbeitung des Videomaterials Information aus dem Video-Stream entfernen, solange dieser Eingriff die Videoqualität nicht sichtbar reduziert - bei einer ohnehin angestrebten variablen Datengröße lohnt es sich, zu sparen, wo immer dies mit vertretbarem Qualitätsverlust möglich erscheint. Auf diese Weise können bei einem handlungsarmen Anime wie etwa Koi Kaze insgesamt Dateien mit einer Größe von deutlich unter 150 MB pro 23-min-Episode erzeugt werden, ohne dass deren Qualität auffällig schlecht wäre oder von Episode zu Episode stark schwanken würde.

Links zu weiterführender Literatur

• Encoding allgemein: doom9 (deutsch)
• DVD-Analyse: DGIndex-Benutzerhandbuch
• Deinterlacing: Inverse Telecine (Rückgängigmachen des 3:2-Pull-Down bei NTSC-DVDs)
• Deinterlacing: Homepage zu TIVTC
• XviD: Wissenswertes rund um XviD by Selur (deutsch, zipped PDF)