DE19843705A1 - Editieren digitalisierter Audio/Videodaten über ein Netzwerk - Google Patents

Description

Die vorliegende Erfindung betrifft das Feld des Audio/Videoeditierens. Insbesondere bezieht sich die vorliegende Erfindung auf ein Verfahren und eine Vorrichtung zum Editieren von digitalisierten Audio/Videodaten über ein Netzwerk.

Bisher wird das Audio/Videoeditieren meistens gemäß dem in Fig. 1 illustrierten System ausgeführt. Eine Editier-Workstation enthält heute lokale Platten (Disks), auf denen Audio/Videodaten gespeichert sind. Das Editieren kann mittels eines Anzeigeschirms ausgeführt werden, ist jedoch auf die lokal gespeicherten Audio/Videodaten beschränkt. Diese Art von System erfüllt eine unzulängliche Funktionalität zum Editieren einer großen Menge von auf mehreren Workstations gespeicherten Audio/Videodaten.

Insbesondere ist dieses System unzureichend, da bisherige Editier-Workstations den Editiervorgang nicht über die Grenzen der Workstations, über Netzwerke ausführen. Audio/Videodaten auf jeder Workstation müssen separat editiert werden und das Ausgangssignal des Editiervorgangs kann dann einer Mischkonsole eingegeben werden, um das fertige Audio/Video-Ausgangssignal zu erzeugen. Wenn irgendwelche Probleme bei dem fertigen Audio/Videoausgang bestehen, dann muß der mühsame Prozeß des Editierens der verschiedenen Audio/Video-Datenspuren, die auf jeder separaten Workstation vorhanden sind, wiederholt werden. Dieser Prozeß geht weiter, bis das fertige Ausgangssignal zufriedenstellend ist.

Die vorliegende Erfindung beschreibt eine Vorrichtung und ein Verfahren zur Erzeugung einer konfigurierbaren Benutzerschnittstelle für Audio/Video(A/V)-Daten. Bei einem Ausführungsbeispiel ist eine Datenbeschreibungsmaschine mit dem Audio/Video-Datei­ system gekoppelt, das die Audio/Videodaten enthält. Die Art des Benutzers, der die graphische Benutzerschnittstelle (GUI) benutzt, wird identifiziert. Ein Anzeigegenerator greift auf das Audio/Video-Dateisystem zu und erzeugt eine Anzeige der Audio/Video­ daten in Abhängigkeit von der Art des Benutzers. Eine Menü-Erzeugungseinrichtung erzeugt durch den Benutzer wahlbare Optionen und/oder Funktionen zur Anzeige auf der graphischen Benutzerschnittstelle, wobei die Optionen und/oder Funktionen in Abhängigkeit von der Art des Benutzers angezeigt werden. Eine Manipulationsmaschine empfängt Benutzereingaben und bestimmt auszuführende Vorgänge, wobei die Bestimmung auf der Art des Benutzers basiert.

Weitere Aufgaben, Merkmale und Vorteile der vorliegenden Erfindung sind in der folgenden detaillierten Beschreibung und den beiliegenden Zeichnungen erläutert. Die Erfindung wird anhand eines bevorzugten Ausführungsbeispiels unter Bezugnahme auf die Zeichnungen erläutert, in denen gleiche Bezugszeichen gleiche Elemente bezeichnen, und in denen:

Fig. 1 ein bekanntes Audio-Editierverfahren illustriert;

Fig. 2 einen Überblick über ein erfindungsgemäßes Ausführungsbeispiel illustriert;

Fig. 3 Softwaremodule gemäß einem Ausführungsbeispiel der vorliegenden Erfindung im Detail illustriert;

Fig. 4 eine Datenstruktur illustriert, die eine Spur gemäß einem erfindungsgemäßen Ausführungsbeispiel definiert;

Fig. 5A bis 5E verschiedene Editiervorgänge illustrieren, die auf einer Spur von Audiodaten ausgeführt werden;

Fig. 6 ein Beispiel einer graphischen Benutzerschnittstelle illustriert, die zur Ausführung des Editierens verwendet werden kann;

Fig. 7 ein Ausführungsbeispiel eines Systems illustriert, das durch den Benutzer konfigurierbare Schnittstellen in Übereinstimmung mit der Lehre der vorliegenden Erfindung illustriert;

Fig. 8 ein Beispiel einer graphischen Benutzerschnittstelle für eine andere Art von Benutzer illustriert;

Fig. 9 ein alternatives Beispiel einer graphischen Benutzerschnittstelle für einen bestimmten Benutzer illustriert.

Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung zur Erzeugung einer durch den Benutzer konfigurierbaren Schnittstelle. In der folgenden detaillierten Beschreibung werden eine Vielzahl von speziellen Details erläutert, um ein grundlegendes Verständnis der vorliegenden Erfindung zu ermöglichen. Dem Fachmann ist es offensichtlich, daß diese speziellen Details nicht erforderlich sind, um die vorliegende Erfindung auszuführen. Andererseits werden wohlbekannte Strukturen, Schnittstellen und Verfahren nicht im Detail erläutert, um den Blick auf die Erfindung nicht unnötig zu verstellen.

Fig. 2 illustriert einen Überblick eines erfindungsgemäßen Ausführungsbeispiels. Obwohl die folgenden Abschnitte ein Audio-Editierverfahren beschreiben, kann die gleiche Technik erfolgreich auf ein Video-Editierverfahren angewandt werden. Wie illustriert, weist das erfindungsgemäße System wenigstens eine Editierstation auf, die an mehrere entfernte Stationen (entfernte Stationen 1-N) gekoppelt ist. Die entfernten Stationen 1-N enthalten in digitaler Form auf einer oder mehreren Platten gespeicherte Audio/Video­ daten. Gemäß diesem erfindungsgemäßen Ausführungsbeispiel kann ein Toningenieur die in einer beliebigen der entfernten Stationen 1-N vorhandenen Daten von einem einzigen Ort, nämlich der Editierstation 200 editieren. Der Toningenieur kann auch die digitalisierten Daten über entfernte Stationen 1-N, beispielsweise durch Kopieren von Audiodaten von einer Spur auf einer Station und Einfügen der ausgeschnittenen Audiodaten auf eine Spur einer anderen Station editieren. Editiervorgänge über entfernte Stationen werden im folgenden im Detail erläutert.

Die Editierstation 200 kann ein Personal Computer (PC) oder jedes andere System sein, das in der Lage ist, eine graphische Anwendung anzuzeigen, eine Eingabe über die graphische Anwendung akzeptiert, und die Eingabe zu einem entfernten Ort kommuniziert. Die entfernten Stationen 1-N können auch einen PC oder eine herstellerspezifische Audio/Video-Speicher/Editierstation, wie ein Abspiel-Aufzeichnungssystem der Sony- Corporation enthalten. Die entfernten Stationen 1-N können Schlitze für mehrere entfern­ bare Platten, wie Iomega Jaz-Platten enthalten, die die für die entfernten Stationen zur Verfügung stehende Speicherkapazität erhöhen, und es erlauben, daß die gespeicherten Daten leicht von einem entfernten Ort zu einem anderen bewegt werden.

Fig. 3 illustriert die Softwaremodule gemäß einem erfindungsgemäßen Ausführungs­ beispiel. Die Editierstation 200 enthält eine Editieranwendung 302, dynamische Verknüpfungsdateien (DLLs) 304 und einen Fernverarbeitungsruf (Remote Procedure Call, RPC)-Mechanismus 306. Die Editieranwendung 302 erlaubt es dem Toningenieur, Editier­ funktionen über eine graphische Benutzerschnittstelle (GUI) auszuführen. Der RPC- Mechanismus 306 liefert eine Kommunikationsverbindung zwischen der Editierstation und den entfernten Stationen 1-N (s. Fig. 2). Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ist der RPC-Mechanismus 306 ein auf Microsoft® Windows NT basierter RPC-Mechanismus. Andere RPC-Mechanismen oder andere Netzwerk- Mechanismen zur Fernkommunikation können auch verwendet werden.

Fig. 3 illustriert auch ein Beispiel der Softwaremodule einer beispielhaften entfernten Station gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Die beispielhafte entfernte Station weist einen RPC-Mechanismus 308 (entsprechend dem RPC- Mechanismus 306 in der Editierstation 200), DLLs 310 und einen Ansteuer-Mechanismus 312 auf, der mit einem Digitalsignal-Verarbeitungs(DSP)-System 314 wechselwirkt. Ein Toningenieur arbeitet mit den entfernten Stationen 1-N von der Editierstation 200 über eine GUI, wobei die mittels der GUI spezifizierten Funktionen zwischen der Editierstation 200 und den entfernten Stationen 1-N über die RPC-Mechanismen 306 und 308 übertragen werden, wobei die DLLs 310 und das DSP-System 314 alle notwendige Verarbeitungen ausführen, um die bestimmten Funktionen zu implementieren.

Fig. 4 illustriert die Datenstruktur einer Audiospur auf einer beispielhaften entfernten Station gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Eine Audiospur ist eine statische Repräsentation von Audiodaten, die den Ort der Audiodaten auf einer Platte, die organisatorischen Daten, die zur korrekten Wiedergabe der Audiodaten erforderlich sind, sowie eine Mehrzahl anderer Parameter in Verbindung mit den Audiodaten spezifiziert. Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung sind die verschiedenen, den Audiodaten zugehörigen Parameter jeweils in einer Liste spezifiziert.

Die verschiedenen in Fig. 4 illustrierten Listen entsprechen daher einer einzigen Audiospur. Diese Spur wird durch eine Datenstruktur repräsentiert, die alle Listen auf logische Art und Weise verbindet. Durch Verwendung einer einzigen Datenstruktur, um alle Listen zu verbinden, ermöglicht es ein Ausführungsbeispiel der vorliegenden Erfindung, daß alle einer bestimmten Spur von Audiodaten zusammen durch eine gemeinsame Editier-Schnittstelle editiert werden. Wenn so beispielsweise ein Toningenieur entscheidet, einen Abschnitt einer Audiospur zu editieren, können alle zu dem Abschnitt der Audiospur zugehörigen Listen im Gegensatz zu bekannten Systemen, bei denen verschiedene Aspekte der Spur separat editiert werden müssen, gleichzeitig editiert werden.

Der Mechanismus, der ein Editieren über die Datenspurstruktur von Fig. 4 ausführt, enthält verschiedene Komponenten. Gemäß einem Ausführungsbeispiel sind die Komponenten als C++-Klassen implementiert. Die primären Komponenten sind: Spuren, Ereignislisten und Ereignisse. Jede dieser Komponenten ist in Fig. 4 illustriert und wird im folgenden im Detail erläutert. Obwohl die folgende Beschreibung eine C++-Im­ plementierung annimmt, kann die gleiche oder eine ähnliche Funktionalität in anderen Programmierumgebungen implementiert werden.

Eine "Spur" (Track) ist ein öffentliches Objekt, das für Audio-Anwendungen verwendet wird, um statische Folgen von Audio- und anderen zeitbasierten Daten zu repräsentieren.

Eine Spur wird als benanntes Objekt (d. h. mit einem Zeichenkettennamen) implementiert, welches eine Sammlung von (unten beschriebenen) Ereignislisten beibehält. Eine Spur zeigt eine Editier-Schnittstelle, die auf jede Ereignisliste angewandt wird. Gemäß einem Ausführungsbeispiel behält eine Spur wenigstens eine Ereignisliste, nämlich die Tonliste (Sound List; Fig. 4) bei.

"Ereignislisten" sind zweifach verbundene Datenstrukturen, die zwei grundlegende Arten von Ereignissen enthalten. Das Vorgabe-Ereignis wird ein "Stille"-Ereignis genannt und das andere Ereignis wird ein "Nicht-Stille"-Ereignis genannt. Es gibt eine separate Ereignisliste für jede Art von Stille/Nicht-Stille-Ereignis-Kombination. Beispielsweise repräsentieren, wie in Fig. 4 illustriert ist, mit Farbe ausgefüllte Kreise entlang der Audio- Zeit das Auftreten von Ton, während die nicht ausgefüllten Kreise Stille repräsentieren. Andere Listen sind auch möglich. Beispielsweise illustriert die Verstärkungsliste, wie in Fig. 4 gezeigt ist, wieviel Verstärkung auf bestimmte Abschnitte einer Audiospur angewandt wird. Beispielsweise gibt der ausgefüllte Kreis einen bestimmten skalaren Wert der Verstärkung an, der angewandt wird, während der ungefüllte Kreis repräsentiert, daß die Einheitsverstärkung anzuwenden ist. Fig. 4 zeigt auch andere Listen, die, wie dem Fachmann ersichtlich ist, verschiedene Parameter einschließlich Parametern bezüglich Video- oder anderer Editiervorgänge enthalten. Jede Art von Ereignis hat eine in Abtastungen gemessene Minimallänge und andere Daten, die erforderlich sind, um das Ereignis-Verhalten zu definieren. Gemäß einem Ausführungsbeispiel wird beinahe das gesamte Editierverhalten der Ereignislisten in einer C++-Klasse implementiert.

Jede Art von Ereignis enthält zwei wichtige virtuelle Funktionen: Gleit-Anfang (. . .) und Gleit-Ende (. . .). Wenn neue Nicht-Stille-Ereignisse erzeugt werden, muß jedes Ereignis diese Funktionen erneut implementieren. Dies resultiert aus der Tatsache, daß, wenn eine Start- und/oder Endzeit eines Editiervorgangs nicht mit dem Beginn eines Ereignisses übereinstimmt, ein Übergang ("Seam") erzeugt werden muß. Dies wird erreicht durch Kopieren des geeigneten Ereignisses ("Gleiten") des Endes des Quell-Ereignisses und dann "Gleiten" des Beginns des kopierten Ereignisses. Dieser Gleitmechanismus wird später im Detail illustriert (s. Fig. 5C).

Ereignislisten sind zeitbasierte Datenstrukturen, die verbundene Ereignisse enthalten, wobei jedes Ereignis eine in Abtastungen gemessene Minimallänge hat. Die Summe der Längen aller Ereignisse plus der Start-Offset (wird später im Detail erläutert) ist gleich der Länge der Ereignisliste. Durch Vorgabe beginnt das erste Ereignis bei der Absolutzeit Null Abtastungen, solange kein Start-Offset vorhanden ist, in welchem Falle das erste Ereignis bei dem Wert des Start-Offsets beginnt. Die Absolutzeit (gemessen in Abtastungen) am Beginn eines Ereignisses wird gemessen durch Aufaddieren der Längen aller vorangehenden Ereignisse einschließlich des Start-Offsets.

Für die Zwecke dieser Diskussion werden Spuren und Ereignislisten austauschbar verwendet. Spuren repräsentieren mehrere Ereignislisten. Eine Arbeits-Ereignisliste ist eine Liste, die die Ereignisse enthält, die aufgebaut werden, um eine bestimmte Art eines Audio-Verhaltens zu modellieren. Arbeits-Ereignislisten werden ursprünglich mit einem sehr großen Stille-Ereignis erzeugt. Wenn die Arbeits-Ereignisliste einmal erzeugt wurde, können Editiervorgänge auf diese angewendet werden. Einzelne Ereignisse können der Liste durch Aufruf einer geeigneten Addier(. . .)-Funktion hinzugefügt werden. Weiterhin können gemäß einem Ausführungsbeispiel der vorliegenden Erfindung sechs einfache Editiervorgänge angewandt werden. Diese sind:
Löschen ()
Ausschneiden ()
Kopieren ()
Einsetzen ()
Einfügen ()
Einfügen () (Leerraum).

Spuren, Ereignislisten und andere Objekte, die den Editiervorgang modellieren, verwenden die obigen Begriffe zur Definition einer Editier-Schnittstelle. Die Editiervorgänge, die auf die Ereignislisten angewendet werden, werden im folgenden diskutiert und in den Fig. 5A-E illustriert. Gemäß einem alternativen Ausführungsbeispiel der vorliegenden Erfindung können auch andere Editiervorgänge ausgeführt werden.

"Löschen" ersetzt einen Abschnitt von Ereignissen durch Stille, ohne die Zeiten der Ereignisse nach dem Endzeitpunkt zu beeinflussen. Löschen ist effektiv ein Überschreib­ vorgang. Der Löschen-Editiervorgang ist in Fig. 5A illustriert. "Einsetzen" setzt eine Quell-Liste in eine Ziel-Liste ein. Die Start- und Endzeitpunkte der Einfügung werden durch die Quell-Liste bestimmt. Einsetzungsvorgänge überschreiben, da die Zeiten der Ereignisse nach dem Endzeitpunkt unverändert bleiben, wie in Fig. 5B illustriert ist.

"Einfügen"-Vorgänge setzen eine Quell-Liste in eine Ziel-Liste ein. Der Einfügungspunkt wird durch die Startzeit der Quell-Liste bestimmt. Die Zeiten aller Ereignisse während und nach dem Einfügungspunkt werden um die Länge der Quell-Liste verschoben. Dies ist in Fig. 5C gezeigt. "Leerraum einfügen" fügt eine Leerraum-Ereignisliste einer bestimmten Länge anstatt einer Quell-Liste in ein Ziel ein. "Ausschneiden" entfernt einen Abschnitt von Ereignissen von einer Ereignisliste. Alle Ereignisse nach dem Endzeitpunkt werden um die Länge des ausgeschnittenen Stückes nach vorne verschoben, wie in Fig. 5D illustriert ist. Schließlich kopieren "Kopieren"-Vorgänge einen Abschnitt einer Ereignisliste, während die Quell-Liste unbeeinflußt bleibt, wie in Fig. 5E illustriert ist.

Fig. 6 illustriert ein Beispiel eines Schirmes einer graphischen Benutzerschnittstelle (GUI), die durch die Editieranwendung 302 in der Editierstation 200 erzeugt werden kann. Diese GUI-Schirme erlauben es dem Toningenieur, eine Anzahl von auf die Audiodaten anzu­ wendende Editierfunktionen zu spezifizieren. Beispielsweise illustriert der Schirm in Fig. 6 eine Anzeige von sieben separaten Spuren (FXL, FXC, FXR, FXS, FoleyL, FoleyC und FoleyR).

Diese sieben Spuren können in einer einzigen Station oder in separaten Stationen in einem Netzwerk vorliegen. Die Möglichkeit, daß ein Toningenieur auf mehrere Stationen über ein Netzwerk zur simultanen Editierung von einem einzigen entfernten Ort zugreifen kann, repräsentiert eine signifikante Verbesserung gegenüber bekannten Verfahren zur Audio/Videoeditierung. Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung kann der Toningenieur mehrere Editiervorgänge über so viele entfernte Stationen, wie er wünscht, ausführen, wodurch dem Toningenieur die Flexibilität gegeben wird, eine große Menge von Audiodaten sehr einfach zu editieren. So kann ein Toningenieur beispielsweise jede der oben beschriebenen Editiervorgänge auf den hervorgehobenen Abschnitt des Schirms anwenden. Der hervorgehobene Abschnitt entspricht einem Abschnitt von Audiodaten auf mehreren Spuren von Audiodaten, wobei jede Spur mehrere Listen enthält.

Die visuelle Repräsentation der Audiodaten ermöglicht dem Toningenieur eine große Flexibilität, um Editierfunktionen zu spezifizieren. Beispielsweise kann der Toningenieur einen festgelegten Abschnitt auf dem Schirm hervorheben und Editierfunktionen spezifizieren, die auf dem gesamten hervorgehobenen Bereich ausgeführt werden sollen. Dieser hervorgehobene Bereich kann, wie in Fig. 6 illustriert ist, sowohl schattierte als auch nicht-schattierte Abschnitte des Schirmes enthalten. Die schattierten Abschnitte geben die aktiven Audioabschnitte (Nicht-Stille) jeder Spur an, während weiße Bereiche Stille angeben. Wenn der Toningenieur eine Editierfunktion spezifiziert, wird die Funktion über die Spuren angewandt, wodurch es dem Benutzer ermöglicht wird, mehrere Spuren gleichzeitig zu editieren. Insbesondere können diese Spuren auf separaten Geräten über das Netzwerk verteilt gespeichert sein, im Gegensatz zum Stand der Technik, wo eine Editierstation nur Daten editieren kann, die auf einer lokalen Station vorhanden sind.

Die Möglichkeit, digitalisierte Audio/Videodaten von einer einzigen Editierstation über ein Netzwerk auszuführen, liefert weitere bedeutende praktische Vorteile, als das Verfahren nur effizienter zu machen. Bei einer bisherigen Film-Editiereinrichtung können verschiedene Editierstudios jeweils mehrere Editierstationen enthalten, um verschiedene Abschnitte von Audio/Videodaten zu editieren, wobei die Ausgänge aller Editierstationen einer Mischkonsole eingegeben werden. In dem Fall, wenn eine Maschine einem anderen Studio zugeordnet wird, muß die gesamte Editierstation physisch zu dem neuen Ort bewegt werden. Demgegenüber müssen bei einem erfindungsgemäßen Ausführungsbeispiel die physisch entfernten Stationen nicht bewegt werden. Statt dessen können die entfernten Stationen an jedem Ort angeordnet sein, und jedem Studio können einfach eine festgelegte Anzahl von entfernten Stationen zugeordnet werden. Auf diese Weise kann die Anzahl von entfernten Stationen, die einem Studio zugeordnet werden, täglich oder sogar stündlich ohne wesentliche Probleme geändert werden.

Bei einem alternativen Ausführungsbeispiel kann die Datenstruktur verwendet werden, um eine Vielzahl von graphischen Benutzerschnittstellen zu unterstützen, die für verschiedene Arten von Benutzern maßgeschneidert sind. Beispielsweise arbeiten in der Filmindustrie verschiedene Personen an der Tonproduktion, der Musikkomposition, der Musikeditierung und der Toneditierung. Die durch die verschiedenen Personen ausgeführte Arbeit umfaßt teilweisen oder vollständigen Zugriff auf die Datenstruktur, von der ein Beispiel durch Fig. 4 illustriert ist. Jedoch sind diese verschiedenen Personen an unterschiedliche Benutzerschnittstellen gewöhnt. Beispielsweise arbeiten Tonerzeuger und Musikkomponisten mit Balkendiagrammen, Reglern und Takten, um bestimmte Abschnitte zu identifizieren, auf welche sich eine Funktion bezieht. Toningenieure einschließlich Mischern arbeiten mit SMPTE-Code. Wenn Audio für Nicht-Video-Anwendungen bei diesem System verarbeitet wurde, können ähnlich die verschiedenen Audioabschnitte durch einen MIDI-Code identifiziert werden. In diesem alternativen Ausführungsbeispiel enthält das System ferner eine Datenbeschreibungsmaschine, wie in Fig. 7 illustriert ist. Wie in Fig. 7 gezeigt ist, wird die GUI 705, die die A/V-Daten enthält, durch die Daten­ beschreibungsmaschine 710 erzeugt, die auf die A/V-Datenbank 715 zugreift. Die Daten­ beschreibungsmaschine 710 kann durch Software implementiert werden, die auf bestehenden Prozessoren oder anderen Prozessoren läuft. Alternativ kann sie durch ein spezifisches Hardware- oder Softwaresystem implementiert werden. Die erzeugte graphische Benutzerschnittstelle ist abhängig von der Art des Benutzers. Beispielsweise kann der Benutzer zunächst durch die Datenbeschreibungsmaschine aufgefordert werden, die gewünschte Art der GUI, beispielsweise Toneditieren, Tonerzeugung usw. zu identifizieren. Alternativ kann das System eine GUI eines Vorgabetyps basierend auf dem Einloggen oder einer anderen Benutzer-Identifizierung implementieren.

Die Datenbeschreibungsmaschine greift auf die A/V-Datenbank 715 zu und der Anzeige­ generator zeigt die betreffenden Daten in einer Repräsentation an, die auf die Art des Benutzers zugeschnitten ist. Dies ist durch die Fig. 6 und 8 graphisch repräsentiert. Wie vorher erwähnt, ist Fig. 6 eine für einen Toneditierer zugeschnittene GUI-Repräsentation. Fig. 8 ist eine GUI-Repräsentation zum Überspielen. Es sei erwähnt, daß die Daten von unterschiedlichen Spuren graphisch auf verschiedene Art und Weise repräsentiert werden. Beispielsweise wird bezüglich Fig. 6 der Toneditierer mit einer graphischen Repräsentation der Audiodaten (beispielsweise Bereich 655) zusätzlich zur Identifizierung der jeweiligen Audiodaten, auf die gerade zugegriffen wird, und die in jeder der gezeigten Spuren repräsentiert sind, versorgt. Die Überspielanzeige ist auch mit einer Identifizierung 805 der Audiodaten, auf die zugegriffen wird, versehen. Da jedoch keine Editiervorgänge an der Überspielstation ausgeführt werden, wird eine graphische Repräsentation der Audiodaten nicht geliefert. Ähnlich erfordert das Überspielen häufig Offsets, um verschiedene Spuren relativ zueinander zu verschieben (z. B. zum Mischen), während Offsets beim Editiervorgang typischerweise nicht verwendet werden. So sind Offset-Felder in der graphischen Benutzeroberfläche (GUI) von Fig. 8 vorgesehen (beispielsweise 810), jedoch nicht bei der GUI von Fig. 6.

Die Repräsentationen können vorher erzeugt und beispielsweise in der Referenz-Datendatei 735 oder einem anderen Speicher oder Speichermedium gespeichert werden. Die Repräsentation kann als beschreibende Daten oder ausführbarer Code (beispielsweise Java Script oder dergleichen) gespeichert werden. Es sei erwähnt, daß eine gewisse Gemein­ samkeit der Repräsentation vorhanden sein kann. Beispielsweise können die Zeitcodes die Eingangspunkte, Ausgangspunkte usw. repräsentieren (beispielsweise 686-690 und 830- 836) in Abhängigkeit von der Art des Benutzers die gleichen sein.

Zusätzlich erzeugt die Menü-Erzeugungseinrichtung 725 (Fig. 7) die durch den Benutzer auswählbaren Merkmale, Optionen und Funktionen der bestimmten Art der graphischen Benutzerschnittstelle. Wie die Datenrepräsentationen können die Menüs vorher erzeugt und beispielsweise in der Referenz-Datendatei 735 oder einem anderen Speicher oder Speicher­ medium gespeichert werden. Die Repräsentation kann als beschreibende Daten oder ausführbarer Code (beispielsweise Java Script oder dergleichen) gespeichert sein. Beispiele der verschiedenen durch den Benutzer auswählbaren Merkmale, Optionen und Funktionen können wiederum den Fig. 6 und 8 entnommen werden. Bei der Überspiel-GUI gibt es verschiedene Optionen wie "s" Sicherung 812, "R" Aufzeichnung 814, "I" Eingang 816, "S" Solo 818 und "M" Mute 820. Diese werden durch Tasten implementiert, so daß, wenn sie durch Plazieren des Cursors auf den Bereich der Taste und "Anklicken" mit Maus oder Trackball gewählt werden, die Funktion freigegeben wird. Beispielsweise implementiert die Sicherungs-Taste 812 einen Schreibeschutzmechanismus der gesamten Spur. Die Aufzeichnungs-Taste 814 veranlaßt unmittelbar eine Aufzeichnung des Eingangs auf die gewählte Spur.

Die Eingangs-Taste 816 ermöglicht es dem Benutzer zu hören, was am Eingang vorhanden ist (gegenüber demjenigen, was am Ausgang vorhanden ist). Die Mute-Taste 820 schaltet die gewählte Spur stumm und der Solo-Knopf 818 schaltet alle Spuren mit Ausnahme der ausgewählten Spur stumm.

Bei der Editier-GUI von Fig. 6 sind ähnliche Funktionen vorgesehen, wobei manche unter­ schiedlich implementiert sind, um auf verschiedene Benutzer zugeschnitten zu sein. Wie gezeigt, sind Tasten für die Funktionen Solo 678, Mute 680, Eingang 682 und Aufzeichnung 684 vorgesehen. Anders als eine Überspiel-Anwendung implementiert jedoch eine Editier-Anwendung ein bandbasiertes Mehrspurenmodell der Aufzeichnung. Wenn daher ein Benutzer die Aufzeichnungsfunktion auswählt, blinkt die Taste, um einen Wartevorgang zur Auslösung der Aufzeichnung anzugeben und ändert sich in eine feststehende Farbe, um anzugeben, wenn die Aufzeichnung eingeleitet ist, die durch den Benutzer gesteuert wird, der eine Master-Aufzeichnungstaste (beispielsweise Taste 691) auf der Anzeige auswählt. Wenn die Master-Aufzeichnung einmal ausgewählt ist, können zusätzliche Spur-Aufzeichnungstasten ausgewählt und unmittelbar ausgelöst werden. Wenn ferner die Master-Aufzeichnung wiederum ausgewählt wird, um die Master- Aufzeichnungsfunktion auszuschalten, blinken die Spur-Aufzeichnungstasten wieder, um einen Aufzeichnungs-Wartezustand anzugeben.

Identische Funktionen wie die Bandsteuerfunktionen etwa Schnellvorspulen, Rückspulen, Spielen, Stop usw. (690 und 840) und Rollen im Zeitcode (692 und 842) sind auch vorge­ sehen. Zusätzlich sind manche Funktionen nur in bestimmten Arten von graphischen Benutzerschnittstellen vorhanden. Beispielsweise sind die programmierbaren Spur- Auswahltasten 844 und "alle" 845 oder "keine" 846 bei einem Überspiel-Vorgang sehr nützlich, wo der Benutzer viele verschiedene Spuren gleichzeitig manipuliert. Ferner können die Funktionen durch die Menü-Erzeugungseinrichtung definiert unterschiedlich graphisch repräsentiert werden. Beispielsweise wird der Verstärkungswert in der Editier- GUI als Gleitreglersymbol und bei der Überspiel-GUI als numerischer Wert repräsentiert. Die Auswahl der Verstärkungsspalte oder der Symbols bei der geeigneten GUI erzeugt ein Popup-Fenster, wie in Fig. 9 gezeigt ist, das es dem Benutzer ermöglicht, die Verstärkung mittels eines graphischen Gleitreglers einzustellen. Es sei erwähnt, daß Fig. 9 ein alternatives Ausführungsbeispiel einer Überspiel-GUI illustriert, die durch den Benutzer konfigurierbar ist. Bei dieser Illustration werden Spuren, die Eingang und Ausgang separat identifizieren, benutzt, um die angezeigte Information anzuzeigen. Andere Ausführungs­ beispiele sind auch denkbar.

Wenn die Daten und die durch den Benutzer auswählbaren Funktionen einmal angezeigt sind, ist der Benutzer in der Lage, Eingaben an das System zu machen und bestimmte Aufgaben auszuführen. Die Benutzer-Eingabe wird vorzugsweise über die Manipulations­ maschine (730, Fig. 7) verarbeitet, die die Eingabe interpretiert und Befehle erzeugt, die durch das System verstanden werden. Der Vorteil ist, daß der Benutzer die spezifische Nomenklatur oder Sprache benutzen kann, die üblicherweise benutzt wird, und das System versteht, was zu tun ist und die Aufgabe ausführt. So sind manche Funktionen nur für eine bestimmte Art von Benutzer gedacht, und manche sind allgemein, werden jedoch unterschiedlich bezeichnet. Beispielsweise wird bei der Tonerzeugung ein Vorgang als ein "Swap" bezeichnet, während der gleiche Vorgang bei der Musik-Editierung als "Verse" bezeichnet wird und beim Ton-Editieren der gleiche Vorgang als ein "Take" bezeichnet wird. Alle drei beziehen sich auf einen Vorgang eines Zeitprotokolls von einem festgelegten Punkt, um verschiedene Versionen des gleichen Tons aufzuzeichnen. So ist der Vorgang der Aufzeichnung der Daten der gleiche, obwohl er von verschiedenen Arten von Benutzern verschieden bezeichnet wird. Die Manipulationsmaschine kann auf verschiedene Arten implementiert werden. In einem Ausführungsbeispiel wird ein Wörterbuch gebildet und beispielsweise in der Speichereinrichtung 735 gespeichert, das mögliche Benutzerfunktionen und entsprechende interne Funktionen enthält. Die Manipulationsmaschine kann dann das Wörterbuch bezüglich der bestimmten Funktion durchsuchen und die auszuführende interne Funktion bestimmen.

Es wird deutlich, daß die vorliegende Illustration über die Audio-Beispiele auf Video und andere Arten von Audio- und Video-Benutzer erweitert werden kann. So ist es denkbar, daß das gleiche System eine Vielzahl von Benutzern unterstützt, ohne daß spezialisierte Benutzer-Hardware für eine bestimmte Art von Benutzer vorgesehen sein muß.

So wird ein Verfahren und eine Vorrichtung zur Erzeugung einer durch den Benutzer konfigurierbaren graphischen Benutzerschnittstelle beschrieben. Die hier beschriebenen spezifischen Anordnungen und Verfahren sollen lediglich die Prinzipien der Erfindung illustrieren. Der Fachmann kann eine Vielzahl von Modifikationen und Änderungen ausführen, ohne von der Erfindung abzuweichen. Obwohl die Erfindung anhand bevor­ zugter Ausführungsbeispiele erläutert wurde, sind diese Ausführungsbeispiele nicht einschränkend zu verstehen.

Claims (1)

1. Vorrichtung aufweisend:
   eine graphische Benutzerschnittstelle (GUI);
   ein Audio/Video(A/V)-Dateisystem (715) mit A/V-Daten; und
   eine Datenbeschreibungsmaschine (710), die zwischen der graphischen Benutzerschnitt­ stelle und dem Audio/Video-Dateisystem (715) gekoppelt ist, wobei die Datenbeschreibungsmaschine (710) aufweist:
   einen Anzeigegenerator (720), der ausgebildet ist, Audio/Videodaten in einer Form zur Anzeige auf der graphischen Benutzerschnittstelle für eine bestimmte Art eines Benutzers zu liefern,
   eine Menü-Erzeugungsvorrichtung (725), die ausgebildet ist, durch den Benutzer auswählbare Optionen und/oder Funktionen zur Anzeige auf der graphischen Benutzer­ schnittstelle zu erzeugen, wobei die durch den Benutzer auswählbaren Optionen und/oder Funktionen in Abhängigkeit von der bestimmten Art des Benutzers erzeugt werden, und
   eine Manipulationsmaschine (730), die ausgebildet ist, eine Benutzereingabe zu empfangen und einen auszuführenden Vorgang zu bestimmen, wobei die Bestimmung des auszuführenden Vorgangs von der bestimmten Art des Benutzers abhängig ist.