Projekte		Broschüre

EINFÜHRUNG IN DIE GRUNDLAGEN
DES SMPTE/EBU-TIMECODES

Vorwort

Die vorliegende "Einführung in die Grundlagen des SMPTE/EBU-Timecodes" beabsichtigt nicht, die von EBU und SMPTE herausgegebenen Normblätter zu ersetzen. Vielmehr wird anhand von Beispielen aus der Praxis versucht, Aufbau und Bedeutung des Timecodes zu erklären.

Unsere "Einführung" wendet sich zunächst an den "Einsteiger", der die vielen mit Timecode verbundenen Begriffe wie Color-Framing, User-Bits, etc. in einen Zusammenhang gestellt bekommt. Dem Profi mögen die Auszüge aus den Normenvorschriften, z.B. Codeaufbau und Signalformen, eine Ergänzung seiner Unterlagen sein.

Die "Einführung" wurde 1984 geschrieben. Seitdem hat sich die Studiotechnik erheblich gewandelt, aber in vielen Bereichen spielen LTC und VITC immer noch eine Rolle, sei es als DVITC oder als LTC-Daten in den Ancillary Data eines Digitalvideos. Insofern hat die "Einführung" durchaus noch Ihre Berechtigung, auch wenn es einige der im Text aufgeführten Videoformate und Timecode-Produkte längst nicht mehr gibt.

Wir würden uns über Anregungen oder Kritik von Ihrer Seite freuen und hoffen, daß Ihnen mit dieser Einführung in den Timecode Ihr persönlicher Einstieg in diese Technik erleichtert wird.

Die Geschäftsleitung der

ALPERMANN + VELTE
Electronic Engineering GmbH

Bernd Velte
Matthias Wehr

Inhaltsverzeichnis

• Entwicklungsgeschichte des Timecodes
• SMPTE und EBU, LTC und VITC
• Was ist Timecode?
• Die Userbits
• Tapetime und Realtime
• Die Kontrollbits
• Farbverkopplung
• Farbverkopplung in der Praxis
• Die Videosynchronisation
• Das LTC-Format
• Modulation und Aufzeichnung
• Decoding Delay
• Jam-Sync
• Warum noch VITC-Code?
• VITC-Code
• Das VITC-Codeformat
• VITC-Aufzeichnung
• Timecode für Film und Ton
• Synchronisation von Ton- und Video-Bandmaschinen
• VITC oder LTC?
• Alpermann + Velte Zukunftstechnologie im Einsatz für Timecode

Entwicklungsgeschichte des Timecodes

Mit der Entwicklung des ersten Videorecorders durch die Firma Ampex im Jahre 1956 begann die Ära der Videoaufzeichnung auf Magnetband. Es begannen aber such die Probleme, die mit der Nachbearbeitung von Videofilmen zusammenhängen. Für die automatische Schnittbearbeitung mußte ein Verfahren entwickelt werden, mit dem man exakt die Bandstellen des Schnitteinstiegs- und Ausstiegspunktes anfahren konnte. Bis dato hatte man ja nur mit Film gearbeitet. Die Transportlöcher des Films sind exakt zu zählen, so daß Schnittpunkte eindeutig bestimmt waren.



Zunächst wurde auch beim Videoband ein mechanisches Bandzählwerk eingesetzt, das die Umdrehungen der Antriebswelle zählte. Die Nachteile dieses Verfahrens sind bekannt:
Durch mechanische Unzulänglichkeiten - z.B. Bandschlupf - ist das exakte Auffinden eines Schnittpunktes Glückssache.

Das Band muß nach dem Einlegen in den Videorecorder erst einmal an den Anfang gefahren werden, damit der Bandzähler justiert werden kann. Im Normalfall wird der Zähler dann auf den Wert Null gesetzt.

1963 begann man, auf einer Audiospur des Videobandes Pulse aufzuzeichnen (CTL-Pulse), also das Band gleichsam mit "elektronischen Transportlöchern" zu versehen. Dadurch konnten die mechanischen Zähler gegen elektronische Zähler ausgetauscht werden. Aber auch dieses Verfahren erwies sich als ungenau:
Durch Dropouts oder schlechten Band-Kopf-Kontakt beim Start und Umspulen des Bandes wird das Zählergebnis ungenau. Zur Justage des Zählers muß auch hier erst einmal der Referenzpunkt (Nullpunkt) angefahren werden. Auch heutzutage sind diese Probleme wohlbekannt, weil immer noch Systeme mit diesem Verfahren arbeiten.

Die genannten Probleme stellten sich dann nicht mehr bei einem Verfahren, das 1967 eingeführt wurde und 1972 im SMPTE- und EBU-Standard genormt wurde. Hierbei wird parallel zu jedem Videobild eine Bildnummer aufgezeichnet.

SMPTE und EBU, LTC und VITC

EBU ist die Abkürzung für die European Broadcast Union und SMPTE die der amerikanischen Organisation Society of Motion Picture and Television Engineers. Wegen der in Amerika und Europa unterschiedlichen Fernsehnormen - NTSC und PAL - ist der Timecode in einigen Punkten unterschiedlich ausgelegt. Für NTSC hat SMPTE die Timecode-Norm formuliert, die EBU hat diese Norm soweit wie möglich übernommen und in der EBU-Norm festgelegt. In der Bundesrepublik besteht für en Timecode eine DIN-Norm, die mit der EBU-Norm identisch ist.

Bis vor wenigen Jahren wurde der Timecode parallel zum Videobild auf einer Audiospur oder einer speziellen Audiospur für den Timecode, der Timecode-Track, aufgezeichnet. Diese Längs- (=Longitudinal-) aufzeichnung hatte den Namen Longitudinal-Timecode, abgekürzt LTC.

Einige Probleme mit dem LTC in der Videonachbearbeitung führten zur Entwicklung des Vertical Intervall Timecodes, abgekürzt VITC. VITC setzt den Code in eine der Datenzeilen des Videosignals. Das VITC-Format wurde dann für die digitale Videoaufzeichnung in DVITC übernommen.

Für Tonaufzeichnungen steht der "Bildtakt" nicht zur Verfügung, hier wird mit Zeittakt gearbeitet. Dadurch wird ein Tonband kontinuierlich in kleine Abschnitte unterteilt, die einen "Ort" auf dem Tonband markieren und auffindbar machen. LTC und MIDI sind die Timecodes des Tonbereiches.

Was ist Timecode?

Timecode bedeutet zunächst, daß parallel zu jedem Bild eines Videobandes eine Bildnummer aufgezeichnet wird. Beim Abspielen des Videobandes kann diese Bildnummer ausgelesen und dargestellt werden. Jedes Videobild ist eindeutig adressiert und exakt aufzufinden. Zusätzlich zur Bildnummer können weitere Informationen wie z.B. Datum, Filmnummer, usw. aufgezeichnet werden.

Die Information, die unter jedem Bild steht, hat vier Blöcke:

• Eine Zeit in Stunden, Minuten, Sekunden und Frames.
• Die Userbits
• Die Kontrollbits
• Das Synchronwort

Die Zeit ist im ursprünglichen Sinne die Bildzahl. Je nach Norm müssen in einer Sekunde 24 (Film), 25 (PAL-Video) oder 30 (NTSC-Video) Bilder gezählt werden. In den Frames wird also angegeben, um das wievielte Bild es sich innerhalb einer Sekunde handelt.

Daß die Bandnummer nicht einfach als z.B. vierstellige Zahl gewählt wurde, sondern als achtstellige Zeit, hat simple Gründe. Die Adresse des Bildes kann die aktuelle Zeit angeben, was wichtig ist, wenn Aufnahmen chronologisch dokumentiert werden sollen, etwa bei der Aufzeichnung eines Fußballspiels. Des weiteren kann die Dauer der Szene oder des Programms durch einfache Berechnung mit den Timecodewerten ermittelt werden. Einzelne Takes eines Bandes von einander zu unterscheiden, gelingt mit einem kleinen Trick, indem die Takenummer in den Stunden angegeben wird (Scene 7 beginnt mit der Zeit 07:00:00:00).

Die Userbits

Zusätzlich zur Zeit werden im Timecode bei jedem Bild auch die Userbits aufgezeichnet. Die Userbits umfassen zweiunddreißig Bits, womit sich entweder eine achtstellige Zahl oder vier ASCII-Zeichen darstellen lassen. Welche Zahlen das sind und was sie bedeuten, ist vom Anwender frei u bestimmen. Es können dort das Datum oder eine Produktionsnummer o.ä. beliebig eingesetzt werden:



Mit ASCII ist ein Zeichensatz beschrieben, der die Zeichen einer Standard-Schreibmaschinentastatur umfaßt, also alle Buchstaben, Zahlen und Sonderzeichen. Vier dieser Zeichen können jeweils unter einem Bild aufgezeichnet werden. Im Prinzip sind damit per Computer ganze Texte in den Timecode einzulagern. Das Wort "Timecode-Inf" würde also drei Bilder belegen:



Damit nun ASCII-Zeichen nicht als Zahlen ausgelesen werden und umgekehrt, hat der Timecode zwei Kontrollbits (Bit 27 und Bit 43), die angeben, wie die Userbits zu interpretieren sind. Gerade die Userbits machen den Einsatz des Timecodes in Bereichen interessant, wo mehr als ein "Elektronisches Bandzählwerk" gebraucht wird. Die Identifikation von Aufnahmen mit geschlüsselten Zahlen ist zum Beispiel bei Archiven wichtig, wenn per EDV auf bestimmte Bilder zugegriffen werden soll:



Bei video-orientiertem Filmschnitt werden von den Filmnegativen Videokopien gezogen. Um welchen Film und welche Rolle des Films es sich bei einem Videoband handelt, kann z.B. in den Userbits angegeben werden.

Tapetime und Realtime

Mit Realtime (Echtzeit) ist die aktuelle Tageszeit gemeint. Tapetime gibt die Länge des Bandes wieder. Ein fünfzehn langes Band hat in Tapetime z.B. die Werte 10:00:00:00 für den Anfang und 10:15:00:00, für das Ende unabhängig davon, wieviel Zeit für die Aufnahme gebraucht wurde.

Ein Schnittsystem reagiert mitunter ungünstig auf Timecodesprünge - also diskontinuierlichen Timecode - wie sie auftreten, wenn ertwa die ersten und die letzten fünf Minuten eines Fußballspiels aufgezeichnet werden und die Zeitinformation des Timecode die Echtzeit beinhaltet. Das Problem liegt darin, daß das Schnittsystem die Zeitinformation des Timecodes ja als Bandzählwerk benutzt.

Der Anfang der ersten Szene sei um 15:00:00:00 und das Ende der zweiten um 16:30:00:00. Auf dem Band sind die beiden Punkte zehn Minuten bzw. 15000 Frames voneinander entfernt, wenn die jeweils fünf Minuten langen Szenen nacheinander aufgenommen wurden. Ein Schnitt mit den beiden Punkten wird von einem Schnittsystem logischerweise mit einer Länge von 1,5 Stunden bzw. 135000 Frames berechnet. Nicht jedes Schnittsystem korrigiert das sinnvoll.

Es kann in den Userbits eine zweite Zeitinformation eingelegt werden. Wenn in den Userbits die Echtzeit (aktuelle Tageszeit) eingelegt wird und die "Zeit" des Timecode Tapetime beinhaltet, dann kann man weiterhin aus dem Timecode ermitteln, wann z.B. das Tor gefallen ist, und vermeidet trotz Echtzeit Problem mit dem Schnittsystem.

Die Kontrollbits

Zwei der Kontrollbits dienen dazu, die Userinformation zu kennzeichnen. Ein weiteres Bit trägt die Drop-frame-Kennung. Diese kennung ist nur für NTSC-Video. Die framerate des NTSC-Video ist exakt 29,97 Bilder/Sekunde, der Timecode zählt aber 30Frames. Ein vom Video gesteuerter Timecodegenerator würde nach einiger Zeit nicht mehr mit der Uhrzeit (Echtzeit) synchron laufen. Nun kann man zur Korrektur in bestimmten Abständen - nach Norm - Framezahlen überspringen. Wenn diese verfahren bei NTSC eingesetzt wird, muß die Drop-Frame-Kennung in Timecode gesetzt werden.

Das vierte Kontrollbit trägt die Color-Frame-Kennung. Es sind im Timecode noch weitere Bits frei, die zur Zeit noch keine weitere Bedeutung haben und damit der Weiterentwicklung des Timecodes Raum geben.

Farbverkopplung

Die Color-Frame-Kennung im Timecode ist ein Bit, das gesetzt wird, wenn der Timecode farbverkoppelt ist. Bei PAL-Video unterscheidet man die 4-Field und die 8-Field-Verkopplung (Field=Halbbild).

Die 4-Field Sequenz bezieht sich auf die Burstphasenlage. Von Zeile zu Zeile wird bei PAL die Burstphasenlage um 180 Grad gedreht (PAL=Phase Alternating Line). In einer geraden zahl von Zeilen ist die Burstphasenlage gleich. Ungleich ist die Burstphasenlage nach den 625 Zeilen eines Bildes. Nach zwei Bildern (=vier Halbbildern), also der geraden zahl von 1250 Zeilen, ist sie gleich. An dieser Stelle kann ohne Farbverlust geschnitten werden.

Die 8-Field-Sequenz bezieht sich auf die Phase des Farbträgers. Alle vier Zeilen ist die Phase gleich, nach acht Halbbildern beginnt das Bild mit der gleichen Phase. Ein störungsfreier Schnittpunkt ist also alle vier Bilder bzw. acht Halbbilder möglich.



Das Color Frame Bit (Color-Frame-Flag) sagt nur, daß eine Farbverkopplung des Timecodes vorgenommen wurde. Die Lage des Bildes in der 4er- oder 8er-Sequenz wird in den Zahlen der Zeit selber ausgedrückt. Bestimmte Bits der Zeitzahlen müssen zueinander im bestimmten Verhältnis stehen. Eine ausführliche Beschreibung dieser Codierung würde den Rahmen dieser Einführung sprengen. Die Information ist jedoch per Augenschein im Timecode nicht zu entdecken, hat also einen Sinn nur im Zusammenhang mit automatischen Schnittsystemen.

Farbverkopplung in der Praxis

Unser portabler Timecode-Generator AV TC 20 hat keine Farbverkopplung, bei unserem Studio-Timecode-Generator ist die Farbverkopplung eine Option. Und das hat gute Gründe. Erste Voraussetzung für die Farbverkopplung ist nämlich, daß der Videokanal des Recorders eine so hohe Qualität hat, daß ein dekodierbar starrer Zusammenhang zwischen Bild- und Farbinformation auch nach der Aufzeichnung bestehen bleibt. Dies ist aber bei allen VHS- und den meisten Umatic-Recordern zumindest für die 8-Field-Sequenz nicht der Fall, eine Farbverkopplung ist also sinnlos.

Zweite Voraussetzung ist, daß das Schnittsystem die Farbverkopplung aus dem Zeitcode ableitet. Das macht kein VHS-Schnittplatz und die allerwenigsten für Umatic. Typisch für Umatic-Schnittplätze - und auch solche, die mit Timecode arbeiten - ist, daß der farbrichtige Einstieg unter Recorder und Player direkt ausgeglichen wird.

Drittens werden fertige Produktionen oft über einen Timebase-Korrektor generiert den Farbträger und die Synchronsignale des Videos. E besteht hinter dem Timebase-Korrektor kein Zusammenhang mehr mit dem Farbträger der Ursprungsaufnahme. Alle vorher vorgenommen Farbverkopplungen des Timecodes waren sinnlos!

Man kann das Ergebnis auch positiv ausdrücken. Hinter dem Timebase-Korrektor lohnt sich die Farbverkopplung dann, wenn anschließend auf einen entsprechenden hochwertigen Recorder aufgezeichnet und das Band einer weiteren Schnittbearbeitung mit einem entsprechenden Schnittplatz zugeführt wird.

Und: Für die 1- und 2-Zoll-Maschinen ist eine Farbverkopplung immer sinnvoll, wenn das ugehörige Schnittsystem die Farbverkopplung des Timecodes aufwertet.

Die Videosynchronisation

Jedes Frame des LTC-Timecodes beginnt zugleich mit der vertikalen Austastlücke des ersten Halbbildes und ist genauso lang wie das Bild. Unter jedem Bild liegt dann genau ein Timecode-Frame! Voraussetzung für die eindeutige Zuordnung einer Timecode-Information zu einem Bild ist die Video-Synchronisation. Die Norm gibt ein Toleranzfeld für das Timecode-Frame bezogen auf die Austastlücke an:

Das LTC-Format

Ein Timecode-Frame umfaßt achtzig Bit. Die Grafik zeigt, wie diese Bits organisiert sind, um alle Informationen aufzunehmen:


Bitte anklicken für grössere Auflösung

Sechzehn Bits des Timecode-Frames sind für das Synchronwort vorgesehen. Das Synchronwort ist eine willkürliche Bitkombination, die aber so gewählt wurde, daß an sonst keiner Stelle des Codes die gleiche Kombination auftreten kann.

Beim Auslesen des Timecodes "sagt" das Synchronwort dem Timecode-Leser, daß nunmehr eine komplette Information eingelesen worden ist und ausgewertet bzw. angezeigt werden kann. Außerdem ist anhand von Synchronworten die Bandlaufrichtung zu ermitteln.

Modulation und Aufzeichnung

Bei der Aufzeichnung des Timecodes wird nacheinander Bit für Bit auf die Audiospur "geschoben". Um die Information bei der Wiedergabe mit verschiedenen Geschwindigkeiten auslesen zu können, werden die Bits vorher noch moduliert. ("Bi-Phase-Mark"-Modulation). Zu Beginn jedes Bits erfolgt ein Polaritätswechsel. Wenn ein gesetztes Bit (H-Level, 1-Wertigkeit) vorliegt, erfolgt in der Mitte der Bitübertragung ein weiterer Polaritätswechsel.



Bit 59 ist in der Grafik des LTC-Formats als nicht belegtes Bit bezeichnet. In der DIN-Norm wird die Nutzung dieses Bits als Phasenbit vorgeschlagen. Damit soll erreicht werden, daß die erste Flanke eines neuen Timecode-Frames immer aufsteigend ist. Ohne Phasenbit ist die Flanke mal aufsteigend und mal absteigend, abhängig von dem sich "zufällig" durch die Modulation ergebenden Wert. Zur Korrektur wird Bit 59 entsprechend auf H- oder L-Level gesetzt.

Vorteil des Phasenbits ist, daß sehr leicht mit Hilfe eines Oszilloskops die Synchronisation des Timecodes mit einem Videosignal oder einem zweiten Timecode zu beobachten ist. In der Praxis gibt es einen Haken:
Einige Hersteller von Timecode-Equipment sind davon ausgegangen, daß dieses Bit nicht belegt ist und haben Bit 59 für eigene Zwecke benutzt oder mindestens ignoriert. Dadurch wird der mit Phasenbit generierte Timecode mit solchen Geräten schlecht oder nicht mehr ausgelesen.

Obwohl nach Norm gar nicht möglich, ist in der Praxis die Kompatibilität des Timecodes aufgehoben. Timecode-Generatoren von Alpermann + Velte belegen Bit 59 daher nicht, die Funktion kann aber jederzeit auf Kundenwunsch eingefügt werden.

Digitale Signale sind wegen ihrer Steilflankigkeit denkbar ungeeignet für die Aufzeichnung auf Audiospuren. Die Folgen der steilen Flanken, Übersprechen und Übersteuerung des Audiokanals mit hohen Frequenzen, treten bei Normsignal nicht so krass auf:



Ein Videobild ist bei PAL (25 Frames/Sekunde) vierzig Millisekunden lang. In dieser Zeit werden achtzig Bit übertragen, ein Bit ist also 0,5 Millisekunden lang. Das entspricht einer Bildfrequenz von zwei Kilohertz. Wären alle Bits gesetzt (H-Level), dann würde die Aufzeichnung mit zwei kHz erfolgen, weil ja in der Mitte jedes Bits noch mal die Polarität gewechselt wird. Das ist der theoretische obere Grenzwert der Aufzeichnungsfrequenz. Ein nahezu rechteckartiges Signal mit einer Maximalfrequenz von zwei kHz muß ein Timecode-Audiokanal verarbeiten können.

Decoding Delay

Eine kleine Tücke des LTC birgt das sogenannte decording delay, nämlich der Versatz von einem Frame zwischen Generator- und Leserzeit. Am Beginn z.B. des Frames Fünf wird die entsprechende Zahl im Display angezeigt und dann während der nächsten vierzig Millisekunden (Framedauer) die codierte Information aufgezeichnet. Dann steht das nächste Frame an, das Display zeigt die Zahl des sechsten Frames an.

Beim Auslesen muß aber erst die gesamte unter dem Frame Fünf stehende Information gelesen werden, ehe der Leser die Zahl des Frames Fünf im Display anzeigen kann. Zu diesem Zeitpunkt zeigt der Generator schon Frame Sechs an. Wenn Generator und Leser die gleiche Zeit anzeigen sollen, das empfehlen EBU und SMPTE, dann muß der Leser ein Frame zu dem ausgelesenen Wert hinzuaddieren.

Jam-Sync

Bei Assembleschnitten werden alle Signale neu aufgezeichnet. So eingestartet, wären Sprünge im Timecode unvermeidlich. Deren Folgen sind schon bei der Echtzeit aufgezeichnet worden.

Um das zu vermeiden, liest der Timecodeleser in der Prerollphase den Timecode ein und gibt die Werte an den Generator weiter. Wird der Schnittpunkt überfahren, so werden die Frames entsprechend weiter gezählt. Der Timecode wird damit kontinuierlich über den Assembleschnitt geführt. Dieses Verfahren nennt sich Jam-Sync.

Ein ähnliches Verfahren wird eingesetzt, um Timecode zu kopieren. Der Timecode der Zuspielmaschine wird kontinuierlich ausgelesen und die Werte werden an den Generator übergeben. Der Generator gibt diese Werte dann an die Aufnahmemaschine. Die Signalform des Timecodes ist damit registriert. Das wird mit Continuous Jam-Sync bezeichnet.

Warum noch VITC-Code?

Der LTC-Timecode hat zwei wesentliche Probleme. Zum einen kann der Code beim Standbild und bei kleinen Bandgeschwindigkeiten nicht ausgelesen werden. Und zum anderen ist der Code so gut wie nicht kopierfähig. Bereits nach der ersten Kopie ist das für Audiokanal schwierige Signal unter Umständen so verzerrt, daß kaum noch ein einwandfreies Auslesen möglich ist.

Dieses Problem kennt der VITC nicht. Weil der Code im Videosignal eingelagert ist, kann er im Standbild ausgelesen werden und immer, wenn die Videokopie gut ist, dann ist auch der VITC sauber kopiert.

VITC-Code

Im VITC-Code werden ebenso wie im LTC-Code sie Zeit- und die Userinformation übertragen. Es gibt auch die für LTC besprochenen Kontrollbits. Die Aussagen für die Farbverkopplung gelten auch hier. Damit hören dann auch die Gemeinsamkeiten von LTc und VITC auf.

Die VITC-Information wird direkt in eine Zeile des Videos eingesetzt. Das Video hat nach der vertikalen Austastlücke einen Bereich von Leerzeilen, die seit einiger Zeit als Träger zusätzlicher Informationen benutzt werden. In diesen Zeilen wird z.B. auch Videotext übertragen. Weil diese zusätzlichen Nutzungen erst nach und nach entwickelt werden, konnte dem VITC nicht eine bestimmte Zeile zugewiesen werden. Die Norm aus, daß eine der Zeilen von Zeile sechs bis Zeile zweiundzwanzig den VITC beinhalten soll. Dem VITC-Generator muß also "gesagt" werden, in welche Zeile der VITC einzusetzen ist.

Die VITC-Information wird in jedem Halbbild einmal eingesetzt. Ein neues Kontrollbit unterscheidet das erste und zweite Halbbild. Damit werden nunmehr auch halbbildgenaue Schnitte möglich. Neu und wesentlich ist im VITC eine acht Bit breite Information, die eine Fehlererkennung beim Auslesen des Timecodes ermöglicht. Nach einem vorgegebenen Verfahren, dem CRC-Check, werden aus allen sonstigen Bits eines VITC-Frames diese acht Bit generiert. Beim Auslesen werden dann alle ausgelesenen Bits ebenfalls dem CRC-Check zugeführt. Die daraus erzeugten acht Bits müssen gleich den vom Generator erzeugten acht Bits sein. Auf diese Weise können Fehler beim Auslesen mit mehr als 95%-iger Sicherheit erkannt werden.

Das VITC-Codeformat

Ein VITC-Frame hat neunzig Bits. Achtzehn Bits davon sind Synchronisations-Bits. Zweien im Wert festgelegten folgen dann jeweils acht Bits der Zahleninformation. Die Codierung zeigt die Grafik:


Bitte anklicken für grössere Auflösung

VITC-Aufzeichnung

Der Spannungswert (Level) eines Bits im Videosignal korrespondiert beim VITC mit dem der digitalen Information. Eine Änderung des Spannungswertes erfolgt nur, wenn sich auch die digitale Information ändert. Dieses Verfahren wird als NRZ-Format benannt (non return to zero level).

Die VITC-Norm gibt die Position der Information in einer Zeile an und schreibt die Signalform vor:

Timecode für Film und Ton

Timecode wird natürlich auch für Film- und Tonaufnahmen eingesetzt. Leider ist es beim Film nicht einfach, den Timecode aufzubringen und auszulesen. Es sind dafür verschiedene verfahren entwickelt worden, die alle Vor- und Nachteile haben, aber bisher konnte sich noch kein Verfahren letztendlich durchsetzten. Daher können wir hier nicht weiter darauf eingehen.

Für Tonbandmaschinen kommt natürlich nur der LTC in Frage. Erst bei der digitalen Tonaufzeichnung mit Videomaschinen kann VITC wieder eingesetzt werden. Color-Frame-Kennung macht hier keinen Sinn und eine Videosynchronisation des Timecodes kann nur bei einer parallelen Aufzeichnung von Bild und Ton vorliegen. Im Normalfall muß daher der Timecode-Generator von einer eingebauten Zeitreferenz gesteuert werden, sei es nun ein Quarztakt oder die Netzfrequenz. Gleichwohl wird für den Ton die EBU/SMPTE-Norm eingesetzt, obwohl ja Frames im Ton nicht gezählt werden können. Der bei Video und Ton gleiche Timecode ist für eine weitere Hauptanwendung des Timecodes äußerst wichtig.

Synchronisation von Ton- und Video-Bandmaschinen

Die Audiokanäle der Video-Maschinen genügen im Allgemeinen nicht den Anforderungen der professionellen Tontechnik. Deshalb ist es gängige Praxis, den zum Video gehörigen Ton auf einer Tonbandmaschine aufzuzeichnen. Bei der Nachbearbeitung der Aufnahmen müssen dann Video- und Tonmaschine parallel fahren. Durch Vergleich der Timecodeinformationen beider (oder auch mehrerer) Maschinen läßt sich schon mal eine framegenaue Synchronität von Ton und Bild realisieren. Die Lage der Synchronworte und auch der einzelnen Bits des Timecodes zueinander lassen eine weitere Feinsteuerung zu, so daß Maschinen durchaus auf ca. fünfzig Mikrosekunden genau parallel gefahren werden können.

VITC oder LTC?

Logisch wäre der Einsatz von LTC auf Tonbandmaschinen und VITC auf Videomaschinen. Daß auf Videomaschinen noch lange Zeit mit LTC gearbeitet wird, liegt u.a. daran, daß die Verwendung beider Codes Doppelanschaffungen nötig macht (LTC- und VITC-Generator), und das meiste Equipment, insbesondere die Synchronizer, bisher nur mit dem LTC arbeiten. Allgemein ist das VITC-Equipment erheblich teurer als das für LTC. Selbst bei Einsatz von VITC wird daher in der Praxis LTC mit aufgezeichnet.

Alpermann + Velte Zukunftstechnologie im Einsatz für Timecode

AV ist eine Gruppe von Ingenieuren, Physikern und Technikern. Sie bilden ein innovatives Team mit dem erklärten Ziel, die kreativen Kräfte mit der state-of-the-art-Technologie in eine richtungsweisende Entwicklungsschiene umzusetzen.

AV entwickelt und produziert komplexe Timecode-Systeme auf der soliden Grundlage einer hoch angesetzten Qualitätsanforderung. Darüber hinaus bereitet AV der technologischen Evolution im eigenen Hause den Weg. Modernste CAD/CAM/CAE-Anlagen und aufwendige Meß- und Prüftechnik helfen bei der Entwicklung von Chips, Mikroprozessor-Software und Schaltungen, die ihrerseits die Option auf zukunftssichere Kompatibillität der AV-Systemlösungen sichern.

© Alpermann+Velte Electronic Engineering, 3.1.1984 - 2003, Abdruck mit Quellenangabe erlaubt