DE60125061T2

DE60125061T2 - Kodierung von audiosignalen

Info

Publication number: DE60125061T2
Application number: DE60125061T
Authority: DE
Inventors: Anthony Richard Ipswich LEANING; Richard James Ipswich WHITING
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 2000-12-15
Filing date: 2001-11-19
Publication date: 2007-06-06
Anticipated expiration: 2021-11-20
Also published as: JP4270868B2; ATE347729T1; AU2002215122B2; KR100838052B1; EP1215663A1; US7222068B2; CN1481547A; KR20030060984A; EP1342231B1; ES2277954T3; EP1342231A1; JP2004516505A; DE60125061D1; CA2429735C; WO2002049008A1; CA2429735A1; US20040030547A1; CN1217317C; AU1512202A

Description

Die vorliegende Erfindung betrifft die Zustellung digital kodierten Materials über eine Telekommunikationsverbindung zur Darbietung bei einem Benutzer.
Insbesondere betrifft die vorliegende Erfindung die Audiokodierung unter Verwendung alternativer Kodieralgorithmen und Umschalten zwischen diesen. Probleme können auftreten, wenn die Algorithmen unterschiedliche Rahmengrößen verwenden.
Gemäß der nach Anspruch 1 definierten Erfindung ist ein Verfahren zum Kodieren eingehender Audiosignale vorgesehen, das umfasst: Kodieren mit einem ersten Kodieralgorithmus zum Erzeugen einer ersten Kodiersequenz, wobei der erste Kodieralgorithmus eine erste Rahmenlänge für jeden der fortlaufenden ersten Zeitabschnitte des Eingangssignals aufweist, dessen Abschnitte einem ganzzahligen Vielfachen der ersten Rahmenlänge entsprechen und entweder aneinander grenzen oder sich überlappen; Kodieren mit einem zweiten Kodieralgorithmus zum Erzeugen einer zweiten Kodiersequenz, wobei der zweite Kodieralgorithmus eine zweite Rahmenlänge für jeden der fortlaufenden zweiten Zeitabschnitte des Eingangssignals aufweist, dessen Abschnitte einem ganzzahligen Vielfachen der zweiten Rahmenlänge, nicht jedoch einem ganzzahligen Vielfachen der ersten Rahmenlänge entsprechen, und die sich dergestalt überlappen, dass jeder Überlappungsbereich der zweiten Kodiersequenz zumindest eine Grenze zwischen Abschnitten der ersten Kodiersequenz umfasst, wobei weiterhin das Zuführen einer Kodiersequenz an eine Ausgabe und, in Reaktion auf eine Schaltanweisung, ein Umschalten der Ausgabe auf eine Versorgung mit der anderen Kodiersequenz beinhaltet ist, und wobei das Umschalten an der Grenze zwischen einem kodierten Zeitabschnitt und dem nächsten erfolgt.
Andere fakultative Aspekte der Erfindung sind in den Unteransprüchen dargelegt.
Es wird darauf hingewiesen, dass die folgende Beschreibung und die folgenden Zeichnungen mit denen der anhängigen internationalen Patentanmeldung WO 02/49343 identisch sind.
Einige Ausführungsformen der vorliegenden Erfindung werden im Folgenden unter Bezugnahme auf die beigefügten Zeichnungen beschrieben, worin:
1 eine Darstellung zur Veranschaulichung der Gesamtarchitektur des zu beschreibenden Systems ist;
2 ein Blockschaltbild eines in einem derartigen System verwendbaren Endgeräts ist;
3 den Inhalt einer typischen Indexdatei zeigt;
4 ein Zeitdiagramm zur Veranschaulichung eines modifizierten Verfahrens zum Erzeugen von Unterdateien ist; und
5 eine Darstellung zur Veranschaulichung einer modifizierten Architektur ist.
Aufgabe des in 1 gezeigten Systems ist die Zustellung digitaler kodierter Audiosignale (zum Beispiel aufgezeichnete Musik oder Sprache) über ein Telekommunikationsnetzwerk zu einem Benutzerendgerät und an einen Benutzer, wobei die entsprechenden Tonsignale von dem Benutzer wiedergegeben werden können. Das System kann, wie weiter unten genauer erläutert werden wird, jedoch stattdessen oder zusätzlich zu den Audiosignalen auch zum Übertragen von Videosignalen verwendet werden. Gebildet wird das Netzwerk in dem dargestellten Beispiel von dem Internet oder einem anderen paketorientierten Netzwerk, das gemäß dem Hypertext Transfer Protocol (bezüglich Einzelheiten siehe RFCs 1945/2068) betrieben wird, wobei prinzipiell auch andere digitale Verbindungen oder Netzwerke verwendet werden können. Es wird auch angenommen, dass die Audiosignale unter Verwendung der ISO MPEG-1 Layer III-Norm ("MP3-Norm") in komprimierter Form aufgezeichnet wurden; die Verwendung dieses speziellen Formats ist jedoch nicht unbedingt notwendig. Es ist auch nicht nötig, eine Komprimierung zu verwenden, wenngleich diese natürlich höchst wünschenswert ist, insbesondere wenn die verfügbare Bitrate beschränkt oder der Speicherplatz begrenzt ist. In der 1 ist ein Server 1 über das Internet 2 mit Benutzerendgeräten 3, von denen nur eines dargestellt ist, verbunden. Die Aufgabe des Servers 1 ist das Speichern von Dateien, das Empfangen einer Anforderung von einem Benutzerendgerät bezüglich der Zustellung einer gewünschten Datei und, in Erwiderung auf eine solche Anforderung, das Übersenden der Datei an das Benutzerendgerät über das Netzwerk. Eine solche Anforderung besitzt üblicherweise einen ersten Teil, der den Zustellungsmechanismus des Netzwerks angibt (z.B. http:// oder file:// für das Hypertext-Transferprotokoll bzw. das File-Transferprotokoll), gefolgt von einer Netz werkadresse des Servers (z. B. www.server1.com), an die der Name der angeforderten Datei angehängt wird. Es sei darauf hingewiesen, dass in den angegebenen Beispielen "//" in derartigen Namen aus typographischen Gründen durch "\\" ersetzt dargestellt wird.
In diesen Beispielen wird die Verwendung des Hypertext-Transferprotokolls unterstellt; das ist nicht unumgänglich, aber es gestattet auf vorteilhafte Weise die von diesem Protokoll zur Verfügung gestellten Authentifizierungs- und Sicherheitseinrichtungen (wie zum Beispiel den Secure Sockets Layer) zu verwenden.
Ein Server zum Bezug von MP3-Dateien ist üblicherweise als ein so genannter Streamer ausgebildet, der Betriebseinrichtungen zur dynamischen Steuerung der Datenübermittlungsrate in Abhängigkeit der Wiedergabeerfordernisse an der Benutzerstation einschließt, um Fehler aufgrund von Paketverlusten zu überspielen, und, falls ein Benutzerdialog zugelassen ist, auch die Steuerung des Datenflusses zwischen dem Server und dem Client. Server 1 besitzt vorliegend allerdings keine derartigen Einrichtungen. Er stellt somit nur einen gewöhnlichen "Web-Server" dar.
Im Folgenden wird das Verfahren zum Speichern der Dateien auf dem Server 1 erläutert. Es wird angenommen, dass eine Datei im MP3-Format erzeugt wurde und auf dem Server gespeichert werden soll. Es wird weiterhin angenommen, dass es sich um eine Aufzeichnung von J. S. Bach's Toccata und Fuge in D-Mol (BWV565) handelt, die typischerweise eine Wiedergabezeit von 9 Minuten aufweist. Ursprünglich würde diese als einzelne Datei erzeugt werden und auf einem herkömmlicher Streamer als diese Einzeldatei gespeichert werden. Hier wird die Datei jedoch in kleinere Dateien unterteilt, be vor sie auf dem Server 1 gespeichert wird. Vorzugsweise entspricht die Größe einer jeder dieser kleineren Dateien einer festen Wiedergabezeit, beispielsweise vier Sekunden. Bei einem komprimierten Dateiformat wie beispielsweise MP3 kann dies bedeuten, dass sich die Dateigrößen hinsichtlich der tatsächlich in ihnen enthaltenen Anzahl von Bits unterscheiden. Die 9 Minuten lange Bachdatei würde somit in 135 kleinere Dateien aufgeteilt, von denen jede einer Wiedergabezeit von vier Sekunden entspricht. In diesem Fall sind es zugeteilte Dateinamen, die eine Seriennummer zur Angabe ihrer Reihenposition in der Originaldatei aufweisen:
000000.bin
000001.bin
000002.bin
000003.bin
.
.
000134.bin
Die Aufteilung der Datei in diese kleineren Teildateien kann üblicherweise von der Person vorgenommen werden, die die Datei zum Laden auf den Web-Server 1 vorbereitet. (Der Ausdruck "Teildatei" wird hier als Unterscheidung gegenüber der Originaldatei benutzt, die die vollständige Aufzeichnung enthält. Es sollte jedoch betont werden, dass, insoweit es den Server betrifft, jede Teildatei eine Datei wie jede andere Datei auch ist). Das genaue Verfahren zu ihrem Erstellen wird untenstehend ausführlicher erläutert. Wenn die Teildateien einmal erstellt sind, werden sie, genau so wie auch jede andere Datei auf einen Web-Server geladen wird, in einer herkömmlichen Weise auf den Server transferiert. Selbstverständlich kann der Dateiname auch Zeichen zur Identifikation der jeweiligen Aufnahme enthalten (die Teildatei könnte auch mit zusätzlicher Information "etikettiert" werden – beim Abspielen einer MP3-Datei erhält man dann Informationen über den Autor, das Copyright, usw.), aber in diesem Beispiel werden die Teildateien in einem für die jeweilige Aufzeichnung bestimmten Verzeichnis oder Ordner auf dem Server gespeichert – z. B. mp3_bwv565. Eine entsprechende Teildatei kann, falls erforderlich, in der folgenden Form angefordert werden:
http:\\www.server1.com/mp3_bwv565/000003.bin
worin "www.server1.com" den URL des Servers 1 darstellt.
Für eine Person, die Teildateien für das Laden auf einem Server vorbereitet, ist es außerdem zweckmäßig, eine Anbindungsseite (link page; üblicherweise im HTML-Format) für jede Aufzeichnung zu erstellen, die ebenfalls auf dem Server gespeichert wird (möglicherweise mit dem Dateinamen mp3_bwv565/link.htm) und deren Struktur und Zweck später beschrieben wird.
Zweckdienlich ist auch ein Speichern von einer oder mehreren (HTML-) Menüseiten (z. B. menu.htm) mit einer Liste verfügbarer Aufzeichnungen und mit Hypertext-Links zu den entsprechenden Anbindungsseiten.
Das Endgerät kann typischerweise von einem üblichen Desktop-Computer gebildet werden, jedoch mit Zusatzsoftware zum Abwickeln des erläuterten Empfangs von Audiodateien. Je nach Wunsch kann das Endgerät von einem tragbaren Computer gebildet werden oder auch in einem Mobiltelefon eingebaut sein. So zeigt 2 ein solches Endgerät mit einem zentralen Prozessor 30, einem Speicher 31, einer Speicherplatte 32, einer Tastatur 33, einem Bildschirm 34, einer Kommunikationsschnittstelle 35 und einer Audioschnittstelle ("Soundkarte") 36. Für den Bezug von Videos sollte statt der Karte 36 oder zusätzlich zu dieser eine Videokarte installiert sein. Auf dem Plattenspeicher befinden sich Programme, die zur Ausführung mit dem Prozessor 30 in der üblichen Weise in den Speicher 31 abgerufen werden können. Diese Programme umfassen ein Kommunikationsprogramm 37 zum Aufruf oder zur Anzeige von HTML-Seiten- das heißt ein "Web Browser"-Programm, wie beispielsweise Netscape Navigator oder Microsoft Explorer und ein weiteres Programm 38, das hier als "das Wiedergabeprogramm" bezeichnet wird und die für eine Wiedergabe von Audiodateien gemäß dieser Ausführungsform der Erfindung erforderlichen Funktionalitäten zur Verfügung stellt. Weiterhin ist ein Bereich 39 des Speichers 31 dargestellt, der als Pufferspeicher reserviert ist. Es handelt sich um einen Pufferspeicher mit zur Wiedergabe bereiten dekodierten Audiodaten (die typische Wiedergabekapazität des Pufferspeichers kann 10 Sekunden betragen). Eine herkömmliche Karte kann die Audioschnittstelle oder Soundkarte 36 bilden, die lediglich dem Empfang von PCM Audio und der Umwandlung in ein analoges Audiosignal dient, welches z. B. über einen Lautsprecher wiedergegeben werden kann. Zunächst wird ein kurzer Überblick über die Betriebsweise des Endgeräts für den Bezug und die Wiedergabe der gewünschten Aufzeichnung bei Verwendung von HTTP und einem eingebundenen oder "steckerfertigen" Client gegeben.

1. Der Benutzer verwendet den Browser, um die Menüseite menu.htm vom Server 1 abzurufen und darzustellen.
2. Der Benutzer wählt einen der Hypertext-Links innerhalb der Menüseite, wodurch der Browser veranlasst wird, die Anwendungsseite für die gewünschte Aufzeichnung – in diesem Beispiel die Datei mp3_bwv565_link.htm vom Server abzurufen und darzustellen. Die tatsächliche Darstellung dieser Seite ist nebensächlich (außer, dass sie vielleicht eine Mitteilung enthält, um dem Benutzer zu versichern, dass das System fehlerfrei arbeitet). Maßgeblich an der Seite ist, dass sie eine Anweisung (oder "eingebettete Markierung") für einen Aufruf eines sekundären Prozesses in dem Prozessor 30 enthält, in dem das Wiedergabeprogramm 37 ausgeführt wird. Das Aufrufen eines sekundären Prozesses in dieser Weise ist eine altbekannte Gepflogenheit (ein derartiger Prozess ist in Netscape-Systemen als "plug-in" und in Microsoft-Systemen "ActiveX" bekannt). Derartige Anweisungen können auch Parameter enthalten, die an den sekundären Prozess übergeben werden und in dem System der 1 enthält die Anweisung den Server-URL der Aufzeichnung, die http: //www.server1/mp3_bwv565 in Bezug auf das Bach-Stück lauten würde.
3. Das Wiedergabeprogramm 37 enthält einen MP3-Decoder von herkömmlicher Arbeitsweise. Im gegenwärtigen Zusammenhang sind die im Folgenden dargelegten Steuerungsfunktionen des Programms von größerem Interesse.
4. Das Wiedergabeprogramm fügt, um eine vollständigen Adresse für die Teildatei – d. h. www.server1/mp3_bwv565/000000.bin zu erstellen, nach Erhalt des URL dieser den Dateinamen der ersten Teildatei hinzu. Festzuhalten bleibt, dass das System auf der Grundlage organisiert ist, dass die Teildateien in der oben angegebenen Art benannt sind, so dass das Endgerät nicht über die Dateinamen informiert werden muss. Das Programm erstellt eine Anforderungsnachricht für die Datei mit dieser URL und überträgt sie über die Kommunikationsschnittstelle 35 und das Internet 2 an den Server 1. (Die Vorgänge zum Übersetzen der URL in eine IP-Adresse und für die Fehlerbenachrichtigung bei ungültigen, unvollständigen oder nicht verfügbaren URLs erfolgen in der herkömmlichen Weise und werden daher nicht beschrieben). Es ist vorgesehen, dass das Wiedergabeprogramm die Anfragen eher direkt an die Kommunikationsschnittstelle als über den Browser sendet. Der Server antwortet durch Übertragen der angeforderten Teildatei.
5. Das Wiedergabeprogramm bestimmt von der Datei die in dieser Teildatei verwendete Audiodekodierung und dekodiert in Übereinstimmung mit der einschlägigen Norm (in diesem Beispiel MP3) die Datei zurück in rohe PCM-Werte, wobei es die Wiedergabezeit dieser Teildatei vermerkt. Eine Audiodatei enthält generell zur Bestimmung der verwendeten Kodierung an ihrem Anfang eine Kennzeichnung. Die dekodierte Audiodatei wird anschließend in dem Audiopufferspeicher 38 gespeichert.
6. Das Wiedergabeprogramm besitzt einen Parameter namens Abspielzeit T_p. In diesem Beispiel ist er auf 10 Sekunden gesetzt (falls erwünscht könnte er durch einen Benutzer wählbar gestaltet werden). Er bestimmt den Grad der am Endgerät vorgenommenen Pufferung.
7. Das Wiedergabeprogramm zählt den Dateinamen auf 000001.bin hoch und fordert diese zweite Teildatei wie oben in (4) und (5) beschrieben an, empfängt sie, dekodiert sie und speichert sie ab. Es wiederholt diesen Prozess, bis der Inhalt des Pufferspeichers die Abspielzeit T_p erreicht oder überschreitet. Zu beachten ist, dass das Dekodieren nicht wirklich notwendigerweise vor der Pufferung erfolgt, dies aber den Vorgang vereinfacht, da die Dauer des gepufferten Materials explizit bekannt ist, wenn die Audiodaten zurück in rohe PCM-Daten dekodiert wurden. Die Steuerung des Audiopufferspeichers vereinfacht sich, wenn jede der Teildateien dieselbe Audiowiedergabelänge aufweist.
8. Bei Erreichen des Abspielzeitschwellwerts T_p werden die dekodierten Daten von dem Pufferspeicher zur Audioschnittstelle 36 gesendet, die die Tonsignale über einen Lautsprecher (nicht dargestellt) wiedergibt.
9. Während die Tonsignale wie oben unter (8) abgespielt werden, überwacht das Wiedergabeprogramm beständig den Füllgrad des Pufferspeichers und, sobald dieser unter T_p fällt, zählt es den Dateinamen erneut hoch und erhält eine weitere Teildatei vom Server. Dieser Vorgang wird wiederholt, bis ein "file not found error" (Fehler: Datei nicht gefunden) zurückgegeben wird.
10. Falls sich der Pufferspeicher während dieses Vorgangs leert, hört, bis weitere Daten eintreffen, das Abspielprogramm mit dem Wiedergeben einfach auf.

Die hier verwendete, auf einer einfachen mit null beginnenden Nummernfolge fester Länge beruhenden Übereinkunft zur Benennung von Teildateien wird bevorzugt, da sie einfach realisiert werden kann. Jedoch kann jede Richtlinie zur Namensgebung verwendet werden, vorausgesetzt, dass das Wiedergabeprogramm entweder den Namen der ersten Teildatei und einen Algorithmus enthält (oder zugesandt bekommt), der die Berechnung nachfolgender ermöglicht, oder alternativ eine Liste von Dateinamen zugesandt bekommt.
Das oben beschriebene System bietet dem Benutzer offensichtlich keine Möglichkeit, in den Wiedergabeprozess einzugreifen. Es bietet auch keine Abhilfe für die Möglichkeit eines Pufferspeicherunterlaufs (beispielsweise infolge einer Netzwerküberlastung). Eine zweite, nun zu beschreibende anspruchsvollere Ausführungsform der Erfindung bietet daher die folgenden weiteren Merkmale:

a) Am Server sind zwei oder mehr, mit verschiedenen Kompressionsraten aufgezeichnete, Versionen der Aufzeichnung gespeichert (zum Beispiel mit Kompressionen, die jeweils (kontinuierlichen) Datenraten von 8, 16, 24 und 32 kBit/s entsprechen) und das Wiedergabeprogramm ist in der Lage, automatisch zwischen diesen umzuschalten.
b) Das Wiedergabeprogramm zeigt dem Benutzer eine Bedienkonsole an, womit der Benutzer die Wiedergabe starten, anhalten, fortsetzen (entweder vom Anfang oder von einem Punkt, an dem angehalten wurde), oder zu einem anderen Punkt in der Aufzeichnung (vorwärts oder rückwärts) springen kann.

Zu beachten ist, dass diese Merkmale nicht voneinander abhängig sind, so dass die Bedienersteuerung ohne Umschaltung der Raten oder umgekehrt verfügbar sein könnte.
Eine Person, die eine Datei zum Laden auf den Server vorbereitet, erstellt im Hinblick auf ein Umschalten der Raten mehrere Quelldateien, indem sie die gleiche PCM-Datei bei unterschiedlichen Raten wiederholt kodiert. Wie zuvor unterteilt sie dann jede Quelldatei in Teildateien. Diese können auf den Server in unterschiedliche, den unterschiedlichen Raten entsprechende Verzeichnisse, geladen werden, wie in der folgenden Beispielstruktur, worin "008k", "024k" im Verzeichnisnamen auf eine Rate von 8 kBit/s oder 24 kBit/s, usw. hinweist.
Sie erstellt auch eine Indexdatei (z. B. index.htm), deren vorrangiger Zweck das Bereitstellen einer Liste verfügbarer Datenraten ist.
Zu bemerken ist hierbei, dass die Anzahl der Teildateien für jedes Verzeichnis gleich ist, da, wie zuvor erläutert, die Länge einer Teildatei einem festen Zeitabschnitt entspricht. Die Namen der Unterverzeichnisse umfassen die Datenrate in kbit/s (drei Zeichen) und den Buchstaben "k". Zum Zweck der Verifikation sind in diesem Beispiel Kennzeichnungen der Audioabtastrate (11,025 kHz) und eine Mono-Stereo-Markierung angehängt.
Die Indexdatei erhält damit eine Anweisung in der Form:
<! Audio = "024k_11_s 032k_11_s 018k_11_s 016k_11_m 008_11_m" -->
( gibt nur an, dass die Anweisung als Kommentar in einer html-Datei eingebettet ist (es könnte auch eine einfache Textdatei verwendet werden)). Eine typische Indexdatei, worin andere Information einbezogen ist, ist in der 3 dargestellt: LFI ist die höchste Nummer einer Teildatei (d. h. es gibt 45 Teildateien) und SL ist die gesamte Abspielzeit (178 Sekunden). "Mode" (Modus) besagt (wie vorliegend) "recorded" (aufgezeichnet) oder (wie untenstehend erörtert) "live". Die anderen Einträge sind entweder selbsterklärend oder Standard-html-Anweisungen.
Zuerst beginnt das Wiedergabeprogramm von dem in der Anbindungsdatei (link file) definierten Verzeichnis die Indexdatei anzufordern und lokal eine Liste der verfügbaren Datenraten zur zukünftigen Verwendung zu speichern (es kann diese Datei ausdrücklich anfordern oder nur das Verzeichnis angeben: Die meisten Server geben, falls kein Dateiname spezifiziert ist, index.htm vor). Dann beginnt es die Audioteildateien wie zuvor beschrieben von dem zuerst erwähnten "Raten"-Verzeichnis in der Indexdatei – viz. 024k_11_s anzufordern (das Endgerät könnte dies auch übergehen, indem es dieses auf die für das Endgerät lokal festgelegte Ratenvorgabe ändert). Von da an besteht das Vorgehen darin, dass das Wiedergabeprogramm die über eine bestimmte Zeit (zum Beispiel 30 Sekunden) gemittelte, effektiv vom Server empfangene Datenrate misst. Dies erfolgt durch zeitliche Berechnung bei jeder URL-Anforderung; es wird die zwischen dem Client und dem Server erzielte Transferrate (Anzahl der Bits pro Sekunde) bestimmt. Die Genauigkeit dieser Zahl verbessert sich mit der Zunahme der Anzahl von Anforderungen.
Das Wiedergabeprogramm unterhält zwei gespeicherte Parameter, die entsprechend die aktuelle Rate und die gemessene Rate angeben.
Der Beginn einer Änderung der Rate wird ausgelöst:

a) Wenn sich der Pufferspeicher ständig leert UND die gemessene Rate geringer als die aktuelle Rate ist UND der gemessene untere Puffer-Prozentsatz (wie unten beschrieben) einen Reduzierschwellwert (Step Down Threshold) unterschreitet: Reduktion der aktuellen Rate; (vorteilhaft ist eine Änderung zu einer Zeit, zu der der Pufferspeicher bereits leer ist, da die Soundkarte nichts wiedergibt und es notwendig sein könnte, sie zu rekonfigurieren, falls sich die Audioabtastrate, die Stereo-Mono-Einstellung oder die Bitweite (Anzahl der Bits pro Abtastung) geändert hat).
b) Falls die gemessene Rate nicht nur die aktuelle Rate, sondern für eine bestimmte Zeit (zum Beispiel 120 Sekunden, wobei dies, falls erforderlich, durch einen Benutzer einstellbar gestaltet werden könnte) auch die nächst höhere Rate übersteigt: Erhöhen der aktuellen Rate.

Der untere Puffer-Prozentsatz des Pufferspeichers entspricht zeitlich umgerechnet einem Prozentsatz des Pufferspeicherinhalts von weniger als 25 % der Abspielzeit (d. h. der Pufferspeicher ist nahezu leer). Falls der Reduzierschwellwert auf 0 % gesetzt ist, reduziert das System immer dann, wenn sich der Pufferspeicher leert und den anderen Bedingungen genügt ist. Ein Setzen des Reduzierschwellwerts auf 5 % (das ist hier der bevorzugte Wert) bedeutet, dass das System, falls sich der Pufferspeicher leert, aber der untere Puffer- Prozentsatz mehr als 5% beträgt, nicht reduziert. Weitere Entleerungen des Pufferspeichers bewirken offensichtlich ein Anwachsen dieser gemessenen Rate und entleeren den Pufferspeicher gegebenenfalls bei einem Wert für den Puffer-Prozentsatz von mehr als 5 %, falls die Rate nicht gestützt werden kann. Ein Setzen des Wertes auf 100 % bedeutet, dass der Client niemals reduzieren wird.
Die tatsächliche Änderung der Rate wird einfach dadurch bewirkt, dass das Wiedergabeprogramm den in Frage kommende Teil der Teildateiadresse ändert, beispielsweise durch Ändern von "008k" auf "024k" um die Datenrate von 8 auf 24 kBit/s zu erhöhen, und den Parameter für die aktuelle Rate in Übereinstimmung ändert. Im Ergebnis wird die nächste Anfrage an den Server eine Anfrage nach einer höheren (oder niedrigeren) Rate und es wird die Teildatei aus dem neuen Verzeichnis empfangen, dekodiert und in den Pufferspeicher gegeben. Der gerade beschriebene Vorgang ist in dem folgenden Flussdiagramm zusammengefasst:
Als Benutzersteuerung werden dem Anwender auf dem Bildschirm die folgende Alternativen dargeboten, aus denen er mittels einer Tastatur oder eines anderen Eingabegeräts wie zum Beispiel einer Maus wählen kann:

a) Beginn: Durchführen der oben angegebenen, nummerierten Schritte ab Schritt 4. Ob nach dem erstmaligen Auswählen einer Aufzeichnung diese automatisch beginnt oder es einer Startanweisung des Anwenders bedarf, ist fakultativ; die Wahl kann allerdings, falls gewünscht, mittels eines zusätzlichen "Autoplay"-Parameters in der Anbindungsdatei veranlasst werden.
b) Pause: wird über eine Anweisung an den MP3-Decoder zum Unterbrechen des Lesens von Daten aus dem Pufferspeicher realisiert;
c) Fortsetzen: wird mittels einer Anweisung an den MP3-Decoder zum Fortführen des Lesens von Daten aus dem Pufferspeicher umgesetzt;
d) Springen: wird ausgeführt, indem der Anwender angibt, zu welchem Teil der Aufzeichnung er springen will- beispielsweise indem er einen Marker an die erwünschte Stelle einer, die gesamte Länge der Aufzeichnung repräsentierenden Balkendarstellung bewegt; das Wiedergabeprogramm ermittelt dann, dass sich diese Stelle bei x % der Länge des Balkens befindet und berechnet die für die nächste Anforderung zu verwendende Nummer der als nächstes benötigten Teildatei. In dem Bach-Beispiel mit 125 Teildateien würde ein Auftrag, die Aufzeichnung ab einem Punkt bei 20% ihrer Länge abzuspielen, zu einer Anforderung der 26. Teildatei – d. h. 000025.bin – führen. Es ist offensichtlich, dass sich diese Berechnung erheblich vereinfacht, wenn jede Teildatei derselben festgelegten Dauer entspricht. Vorzugsweise wird das Dekodieren im Falle eines Sprungs unterbrochen und der Pufferspeicher gelöscht, so dass die neue Anforderung sofort gesendet wird. Dies ist jedoch nicht unbedingt notwendig.

Von Interesse ist eine weitere Erörterung des Vorgangs zum Aufteilen einer Originaldatei in Teildateien. Zunächst sollte festgehalten werden, dass es (wie in der oben beschriebenen ersten Version) von geringer Bedeutung ist, wo sich die Grenzen zwischen den Teildateien befinden, wenn nicht zu erwarten ist, dass einer Teildatei eine andere Teildatei nachfolgt als die ihr in der originalen Sequenz unmittelbar folgende. In diesem Fall kann die Größe einer Teildatei durch eine festgelegte Anzahl von Bits oder eine festgelegte Wiedergabelänge (oder keines von diesen) bestimmt sein – Entscheidend ist einzig und allein, wie groß die Teildateien sein sollten. Wenn Sprünge (im Zeitablauf oder zwischen verschiedenen Datenraten) vorgesehen sind, gelten andere Überlegungen. Wenn, wie bei vielen Arten der Sprach- und Audiokodierungen (inklusive MP3) das Signal in Rahmen kodiert ist, sollte eine Teildatei eine ganze Zahl von Rahmen enthalten. Auch wenn es nicht eigentlich notwendig für ein Umschalten der Rate ist, so ist es doch sehr wünschenswert, wenn die Grenzen der Teildateien bei jeder Rate dieselben sind, so dass die erste mit einer neuen Rate empfangene Teildatei an derselben Stelle in der Aufzeichnung beginnt, an der die letzte Teildatei mit der alten Rate endete. Die Festlegung, dass jede Teildatei derselben bestimmten Zeitdauer entspricht (z. B. den oben erwähnten 4 Sekunden) stellt nicht den einzigen, aber sicherlich den brauchbarsten Weg dar, dies zu erreichen. Anzumerken ist, dass die Bedingung, wonach eine Teil datei eine ganze Anzahl von Rahmen enthalten soll, je nach dem verwendeten Kodiersystem bedeuten kann, dass sich die Wiedergabedauern der Teildateien leicht voneinander unterscheiden. Bezüglich dieser Ausführungsform der Erfindung ist anzumerken, dass die verfügbaren Datenraten jeweils auch dann dieselbe Audioabtastrate und folglich dieselbe Rahmengröße gebrauchen, wenn sie einen unterschiedlichen Grad der Quantifizierung verwenden und sich bezüglich einer Kodierung in mono oder stereo unterscheiden. Sachverhalte, die die Verwendung unterschiedlicher Rahmengrößen betreffen, werden weiter unten erörtert.
Bezüglich der tatsächliche Länge der Teildateien sollten vorzugsweise unmäßig kurze Teildateien vermieden werden, da sie (a) zusätzlichen Verkehr über das Netzwerk in Form von mehr Anforderungen erzeugen und sich (b) in bestimmten Arten von Paketnetzwerken – einschließlich IP-Netzwerken – verschwenderisch auswirken, da sie mit kleineren Paketen befördert werden müssen, wodurch der durch den Anforderungsvorgang und den Paketkopf gebildete Überbau proportional größer ist. Andererseits sind unmäßig große Teildateien nachteilig, da sie einen großen Pufferspeicher benötigen und beim Starten der Wiedergabe und/oder bei Sprüngen oder bei einem Wechsel der Rate eine größere Verzögerung bewirken. Als hinreichend wird eine Größe der Teildateien zwischen 30 % und 130 % der Abspielzeit oder vorzugsweise (wie in den oben angegebenen Beispielen) von in etwa der Hälfte der Abspielzeit angesehen.
Der tatsächliche Vorgang zum Konvertieren der Teildateien kann mittels eines Computers durchgeführt werden, der in Einklang mit den besprochenen Kriterien programmiert ist. Wahrscheinlich ist es zweckdienlich, dies an einem separaten Computer vorzunehmen, von dem aus die Teildateien auf den Server geladen werden können.
Eine weitere Verfeinerung, die zum Erhöhen der Sicherheit hinzugefügt werden kann, besteht in der Substitution durch eine komplexere Namensbildung für die Teildateien, wodurch es nicht autorisierten Personen schwieriger gemacht wird, die Teildateien zu kopieren und sie auf einem anderen Server anzubieten. Ein Beispiel ist das Erzeugen von Dateinamen unter Verwendung eines Pseudo-Zufallsequenzgenerators, der z. B. Dateinamen in der Art erzeugt:
01302546134643677534543134.bin
94543452345434533452134565.bin
...
In diesem Fall würde das Wiedergabeprogramm einen identischen Pseudo-Zufallsequenzgenerator enthalten. Der Server sendet den ersten Dateinamen oder einen "Keim" von vielleicht vier Ziffern, so dass sich der Generator des Wiedergabeprogramms synchronisieren kann und die erforderlichen Teildateinamen in der korrekten Abfolge generiert.
Im oben angegebenen Beispiel zum Umschalten der Rate hatten alle verwendeten Datenraten dieselbe Rahmengröße, insbesondere verwendeten sie eine MP3-Kodierung von PCM-Audiosignalen bei 11,025 kHz und einer (PCM) Rahmengröße von 1152 Abtastwerten. Falls ein Umschalten der Rate zwischen MP3 (oder anderen) Aufzeichnungen mit unterschiedlichen Rahmengrößen ausgeführt werden soll, so ergeben sich Probleme aufgrund der Anforderung, dass eine Teildatei eine ganze Anzahl von Rahmen enthalten soll, da die Grenzen in diesem Fall nicht übereinstimmen. Dieses Problem kann durch die folgende abgewandelte Prozedur zum Erzeugen von Teildateien gelöst werden. Zu beachten ist insbesondere, dass diese Prozedur in jeder, ein Umschalten der Rate erfordernden Situation verwendet werden kann und nicht auf das spezielle oben diskutierte Verfahren der Zustellung beschränkt ist.
Die Graphik der 4 zeigt eine Sequenz von Audiowerten, worin Grenzmarkierungen (in der Figur) B1, B2, usw. aufeinander folgende Vier-Sekunden-Segmente abgrenzen. Bei 11,025 kHz existieren in jedem Segment 44.100 Abtastwerte.

1. Um eine MP3-Teildatei zu erzeugen, werden die Audiosignale rahmenweise beginnend an der Grenze B1 solange kodiert, bis eine ganzzahlige Anzahl von Rahmen mit einer Gesamtdauer von zumindest vier Sekunden kodiert wurde. Bei einer Rahmengröße von 1152 Abtastwerten entsprechen vier Sekunden 38,3 Rahmen, so dass im Ergebnis eine Teildatei S1 mit 39 Rahmen, entsprechend einer Gesamtdauer von 4,075 Sekunden kodiert wird.
2. Kodierung der Audiosignale beginnend an Grenze B2 in der gleichen Weise.
3. Wiederholen des Vorgangs, wobei jedes Mal bei einer 4-Sekunden-Grenze begonnen wird und auf diese Weise ein Satz sich überlappender Teildateien für die gesamte zu kodierende Audiosequenz erzeugt wird. Dem letzten Segment (das durchaus kürzer als vier Sekunden sein kann) folgt natürlich nichts nach und es ist mit Nullen aufgefüllt (d. h. Stille).

Das Kodieren bei anderen Datenraten mit anderen Rahmengrößen erfolgt auf dieselbe Weise.
Am Endgerät bleiben die Steuerungsmechanismen unverändert, doch sind die Vorgänge zum Dekodieren und Puffern modifiziert:

1. Empfangen der Teildateil S1;
2. Dekodieren der Teildatei S1;
3. Schreiben von lediglich der ersten vier Sekunden der dekodier ten Audiowerte in den Pufferspeicher (Verwerfen des Rests);
4. Empfangen der Teildatei S2;
5. Dekodieren der Teildatei S2;
6. Schreiben von lediglich der ersten vier Sekunden der dekodier ten Audiowerte in den Pufferspeicher;
7. Fortfahren mit Teildatei S3, usw.

Auf diese Weise wird sichergestellt, dass die Teildateisätze für alle Raten Teildateigrenzen aufweisen, die mit denselben Stellen in der Original-PCM-Abtastsequenz korrespondieren.
Daher ist jeder außer dem letzten Vier-Sekunden-Zeitraum vor dem Kodieren mit Audiowerten des nächsten Vier-Sekunden-Zeitraums "aufgefüllt", um die Größe der Teildatei auf eine ganzzahlige Anzahl von MP3-Rahmen zu bringen. Falls erwünscht könnten die Auffüllwerte vom Ende der vorangehenden Vier-Sekunden-Zeitperiode statt (oder ebensogut) vom Anfang der nachfolgenden genommen werden.
Hierbei sei angemerkt, dass die MP3-Norm (durch ein als "Bit-Reservoir" bekanntes Schema) zulässt, gewisse Informationen von einem Audiorahmen zu einem anderen zu übertragen. Auch wenn dies im vorliegenden Zusammenhang innerhalb einer Teildatei zulässig ist, so ist es doch zwischen Teildateien nicht zulässig. Da jedoch ein entsprechender Übertrag an das Ende oder den Anfang einer Aufzeichnung von der Norm natürlicherweise nicht zugelassen ist, kann dieses Problem einfach dadurch gelöst werden, dass jede Teildatei extra kodiert wird, wie wenn es sich um eine eigenständige Aufnahme handeln würde.
Ein Wechseln der Abtastrate (und auch das Schalten zwischen Mono- und Stereobetrieb) haben einige praktische Auswirkungen auf den Betrieb der Audioschnittstelle 36. Obwohl sie bei verschiedenen Einstellungen betrieben werden können, erfordern viele herkömmliche Soundkarten ein Zurücksetzen, um Abtastraten zu ändern, wodurch natürlich eine Unterbrechung der Audioausgabe verursacht wird. Daher wird in einer weiteren Abwandlung vorgeschlagen, dass die Soundkarte kontinuierlich mit der höchsten vorgesehenen Abtastrate betrieben wird. Wenn das Wiedergabeprogramm dem Pufferspeicher Daten mit einer niedrigeren Abtastrate liefert, werden diese Daten vor oder nach dem Pufferspeicher auf diese höchste Rate hochgesetzt. Falls die Karte stets im Stereomodus betrieben wird, können auf ähnliche Weise den rechten und linken Kanälen des Soundkarteneingangs Monosignale parallel zugeführt werden. Falls die Anzahl der Bits pro Abtastung des dekodierten Signals geringer als von der Karte erwartet ist, kann die Anzahl der Bits abermals durch Auffüllen mit Nullen erhöht werden.
Unter Berücksichtigung, dass die zuvor erläuterten Kriterien für ein automatisches Heruntersetzen der Datenrate eine Reduzierung der Rate nur für den Fall eines Pufferspeicherunterlaufs vorsehen (und daher mit Unterbrechungen in der Wiedergabe verbunden sind), wird angemerkt, dass entsprechende Unterbrechungen mit dieser Abwandlung vermieden werden können und somit auch ein Kriterium zum vorab Erkennen eines Unterlaufs, um ihn in der Mehrheit der Fälle zu vermeiden. In diesem Falle würde die erste der drei oben erwähnten UND-Bedingungen (nämlich, dass der Pufferspeicher leer ist) entfallen.
Dasselbe Prinzip kann auf die Zustellung von Videoaufzeichnungen und selbstverständlich auf die Zustellung von Videoaufzeichnungen mit zugehöriger Tonspur angewandt werden. In der einfacheren Ausführung mit nur einer Aufzeichnung unterscheidet sich das System von der Audioversion nur darin, dass die Datei eine Videodatei ist (z. B. im H.261- oder MPEG-Format) und das Wiedergabeprogramm einen Videodecoder beinhaltet. Die Art der Aufteilung der Datei in Teildateien bleibt unverändert.
Wie im Audiofall können mit dem schon beschriebenen Steuermechanismus zwei oder mehr, unterschiedlichen Datenraten entsprechenden Aufzeichnungen ausgewählt werden. Es können auch zusätzliche Aufzeichnungen entsprechend unterschiedlichen Wiedergabemoden, wie zum Beispiel schnellem Vorlauf oder schnellem Rücklauf, vorgesehen sein, die über eine Erweiterung der schon beschriebenen Bediensteuereinrichtungen ausgewählt werden können. Hier kann wiederum eine systematische Namensgebung für Dateien und Verzeichnisse eingehalten werden, so dass das Wiedergabeprogramm durch Ändern der Teildateiadresse auf eine – zum Beispiel – schnelle Vorlaufanweisung reagieren kann.
Falls ein Umschalten oder Springen zugelassen sein sollen, hat die Zustellung von Videoaufzeichnungen jedoch weitere Auswirkungen auf die Unterteilung von Dateien. Für den Fall, dass bei einer Aufnahme jeder Frame eines Bildes unabhängig kodiert wird, reicht es aus, wenn eine Teildatei eine ganzzahlige Anzahl von Frames eines Bildes enthält. Bei Verwendung von Komprimierungen mit Inter-Frame-Techniken (Rahmenredundanztechniken) ist die Situation jedoch vielschichtiger. Einige dieser Systeme (zum Beispiel MPEG-Norm) erzeugen eine aus Mischung unabhängig kodierten Frames ("Intra-Frame-Methode", räumliche Redundanzreduktion) und auf einer Vorhersage beruhenden Kodierung von Frames; in diesem Fall sollte jede Teildatei vorzugsweise mit einem Intra-Frame beginnen.
Nicht möglich ist dies bei Inter-Frame-Kodierungssystemen die keine wiederholte und regelmäßige Einbeziehung von Intra-Frames zulassen, wie zum Beispiel bei der ITU H.261-Norm. Denn wenn eine Teildatei n, nimmt man die Ratenumschaltung als Beispiel, von einer Aufzeichnung mit einer höheren Bitrate angefordert wird der eine Teildatei n+1 einer Aufzeichnung mit einer geringeren Bitrate nachfolgen soll, dann würde der erste Frame der Teildatei für die geringere Bitrate auf der Grundlage der Inter-Frame-Technik kodiert, wofür der letzte dekodierte Frame der Teildatei n der Aufzeichnung mit geringerer Rate verwendet werden müsste. Dieser steht dem Endgerät natürlich nicht zur Verfügung- es ist im Besitz des letzten dekodierten Frames der Teildatei n von der Aufzeichnung mit höherer Rate. Somit würde eine schwerwiegende Fehlleistung des Decoders auftreten.
Beim Umschalten zwischen normaler Wiedergabe und schnellem Vorlaufmodus ergeben sich in der Praxis leicht unterschiedliche Si tuationen. Beim schnellen Vorlauf mit zum Beispiel dem 5-fachen der normalen Geschwindigkeit wird nur jeder 5. Frame kodiert. Folglich wird die Inter-Frame-Korrelation stark reduziert und die Inter-Frame-Kodierung unattraktiv, so dass man für eine schnelle Vorlaufsequenz im Allgemeinen eine Intra-Frame-Kodierung bevorzugt. Da die Intra-Frames ohne Schwierigkeiten dekodiert werden können, stellt ein Umschalten von normal auf schnell kein Problem dar. Bei der Rückkehr zur normalen Wiedergabe tritt erneut das zu einer Fehlleistung führende Problem auf, da dem Endgerät ein auf Prädiktion beruhend kodierter Frame vorliegt, zu dem ihm der Vorgängerframe fehlt.
In beiden Fällen kann das Problem unter Verwendung des in der internationalen Patentanmeldung Nr. WO 98/26604 (in USA als Patentschrift 6,002,440 veröffentlicht) beschriebenen Prinzips gelöst werden. Dieses beinhaltet die Kodierung einer intermediären Frame-Sequenz, welche die Lücke zwischen dem letzten Frame der vorangehenden Sequenz und dem ersten Frame der neuen Sequenz überbrückt.
Der entsprechende Funktionsablauf wird nun im Kontext eines schnellen Vorlaufbetriebs (der schnelle Rücklauf ist ähnlich, aber umgekehrt) beschrieben. Für dieses Beispiel wird angenommen, dass eine 9-minütige Videosequenz entsprechend der H.261-Norm mit 96 kBit/s kodiert wurde und ein weiteres Mal mit dem 5-fachen der normalen Rate zur Gänze mit H.261 Intra-Frames, wobei jede der resultierenden Dateien in vier Sekunden lange Teildateien aufgeteilt wurde. Die vier Sekunden beziehen sich hier auf die Dauer des ursprünglichen Videosignals und nicht auf die Wiedergabezeit für den schnellen Vorlauf. In Anlehnung an die oben verwendete Nomenklatur könnte man folgende Teildateien erhalten:
worin "name" der Name zur Kennzeichnung der bestimmten Aufzeichnung ist, "x1" die normale Rate bezeichnet und "x5" das Fünffache der normalen Rate anzeigt – d. h. schnellen Vorlauf.
Um von der normalen Wiedergabe in den schnellen Vorlauf zu schalten, muss das Wiedergabeprogramm nur die Teildateienadresse so ändern, dass sie auf die schnelle Vorlaufsequenz hinweist – z. B. folgt
der Anforderung mpg_name/096k_x1/000055.bin
die Anforderung mpg_name/096K_x5/000056.bin
Zum Erstellen einer Brückensequenz für eine Rückkehr zur normalen Wiedergabe muss für jeden möglichen Übergang eine Brückenteildatei geschaffen werden. Wie in unserer oben erwähnten internationalen Patentanmeldung beschrieben genügt im Allgemeinen eine Sequenz von drei oder vier Frames zur Überbrückung, sodass in ei nem einfachen Verfahren die Realisierung im Erstellen von Brückenteildateien mit einer Dauer von nur vier Frames besteht – z. B.
Damit lässt sich das Umschalten durch eine Reihe von Anforderungen bewerkstelligen, wie zum Beispiel:
Anfordern von mpg_name/096k_x5/000099.bin
Anfordern von mpg_name/096k_5>1/000099.bin
Anfordern von mpg_name/096k_x1/000100.bin
Die Brücken-Teildatei wird folgendermaßen erzeugt:

• Dekodieren der schnellen Vorlaufsequenz, um eine dekodierte Version des letzten Frames von Teildatei 99 zu erhalten (bei 25 Frames pro Sekunde ist dies der Rahmen 100.000 des ursprünglichen Videosignals).
• Dekodieren der normalen Sequenz, um die dekodierte Version des ersten Frames der Teildatei 100 zu erhalten (d. h. Frame 100.001). Erneutes, vierfaches Kodieren dieses einen Frames unter Verwendung der H.261-Inter-Frame-Kodiertechnik und auf Grundlage des dekodierten Frames 100.000 als anfänglichen Bezugsframe.
• Wenn der Decoder die Teildatei für den schnellen Vorlauf und die nachfolgende Brückenteildatei dekodiert hat, wird Frame 100.000 damit korrekt rekonstruiert und zum Dekodieren der normalen (x1) Frames bereit sein. Der Grund für das mehrmalige Kodieren desselben Frames bei dieser Prozedur liegt übrigens darin, dass eine einmalige Kodierung wegen der Quantisierungseigenschaft von H.261 eine schlechte Bildqualität erzeugen würde.

Genau das gleiche Verfahren könnte beim Umschalten der Rate verwendet werden (wenngleich hierbei für beide Richtungen Brückenteildateien erforderlich sind). Zu bemerken ist jedoch, dass die beschriebenen Brückenteildateien für eine Zeitdauer von vier Frames – d. h. (bei 25 Frames pro Sekunde) 160 ms – zu einem Einfrieren des Bildes führt. Beim Schalten vom schnellen Vorlauf zur normalen Wiedergabe ist dies tragbar – man würde es nämlich an dieser Stelle vorziehen, den Pufferspeicher zu löschen. Beim Umschalten der Rate kann dies subjektiv tragbar sein oder auch nicht. Als Alternative könnte daher eine viersekündige Brückensequenz erstellt werden. Die Abfragereihenfolge sähe dann so aus:
mpg_name/096k_x1/000099.bin
mpg_name/096/128_x1/000100.bin
mpg_name/128k_x1/000101.bin
Die Überbrückungsteildatei würde in diesem Fall entweder durch viermaliges Neukodieren des fünften dekodierten Frames der dekodierten 128 kBit/s-Sequenz erstellt werden, wobei mit dem dekodierten 96 kBit/s-Frame 100.000 als Bezugsframe begonnen wird, oder durch Kodieren der ersten vier Frames der dekodierten 128 kBit/s- Sequenz, wobei mit dem dekodierten 96 kBit/s-Frame 100.000 als Bezugsframe begonnen wird. In beiden Fällen wären die verbleibenden 96 Rahmen der Überbrückungsteildatei eine Kopie der 128 kBit/s-Teildatei.
Die zuzustellenden Dateien wurden bisher als "Aufzeichnungen" bezeichnet. Es ist jedoch nicht erforderlich, dass die gesamte Audio- oder Videosequenz vor Aufnahme der Zustellung bereits kodiert wurde oder überhaupt existiert. Ein Computer könnte daher so eingerichtet werden, dass er eine Direktübertragung empfängt, diese mit dem ausgewählten Kodierungsschema kodiert und die Teildateien während der Zustellung erzeugt und auf den Server legt, so dass die Übertragung beginnen kann, sobald sich einige Teildateien auf dem Server befinden.
Ein entsprechendes Zustellsystem könnte in einem Sprachinformationssystem, wie dem in 5 illustrierten angewandt werden, worin der Server 1, das Netzwerk 2 und das Endgerät 3 abermals dargestellt sind. Eine Schnittstelle für Sprachnachrichten 4 dient dem Empfangen von Telefonanrufen, zum Beispiel über ein öffentliches Telefonwählnetz (PSTN) 5, dem Aufzeichnen einer Nachricht, deren Kodierung, dem Aufteilen der Nachricht in Teildateien und dem Laden der Dateien auf den Server 1, wo in der zuvor beschriebenen Weise auf sie zugegriffen werden kann. Alternativ kann eine zweite Schnittstelle 6 mit einer Funktion ähnlich der des Endgeräts 3 vorgesehen sein, die jedoch über das Fernsprechnetz (PSTN) mittels eines dezentralen Telefons 5 ferngesteuert werden kann, zu dem die wiedergegebenen Audiosignale gesendet werden.
Dasselbe System kann für eine Audio- (oder Video-) Direktübertragung verwendet werden. In gewisser Hinsicht wird sie dennoch "aufgezeichnet" – der Unterschied besteht hauptsächlich darin, dass die Zustellung und Wiedergabe vor Beendigung der Aufzeichnung beginnen, obgleich es natürlich zu einer systembedingten Verzögerung dahingehend kommt, dass abgewartet werden muss, bis zumindest eine Teildatei aufgezeichnet und auf den Server 1 geladen wurde.
Das System kann wie oben beschrieben fortfahren und wäre abgesehen von der Tatsache ganz zufrieden stellend, dass eine Wiedergabe am Anfang beginnen würde, wohingegen ein Anmelder höchst wahrscheinlich will, dass es jetzt gestartet wird, d. h. mit der aktuell erzeugten Teildatei.
Bei länglichen Audiosequenzen kann man es vorziehen, ältere Teildateien zu löschen, um Speicherplatz zu sparen. Bei einer kontinuierlichen Übertragung (d. h. 24 Stunden täglich) wäre dies unausweichlich und außerdem müssten die Namen der Teildateien wieder verwendet werden (in unserem Prototypen-System wird 000000.bin bis 009768.bin verwendet, worauf erneut bei 000000.bin begonnen wird), so dass die älteren Teildateien ständig mit den neueren überschrieben werden. Ein einfaches Verfahren um sicherzustellen, dass die Zustellung mit der aktuellsten Teildatei beginnt, bestünde darin, eine zusätzliche Anweisung in die Indexdatei aufzunehmen, die das Wiedergabeprogramm veranlasst, mit der Anforderung nach der geeigneten Teildatei zu beginnen. Nachteilig ist hierbei jedoch, dass die Indexdatei häufig verändert werden muss – idealerweise jedes Mal, wenn eine neue Teildatei erzeugt wird. Daher schlagen wir ein Verfahren vor, wonach das Wiedergabeprogramm den Server durchsucht, um die Start-Teildatei wie folgt aufzufinden. In der Indexdatei wird der Betriebsart-Parameter auf "live" gesetzt, um das Wiedergabeprogramm zu veranlassen, dieses Verfahren anzuwenden. LFI wird so gesetzt, dass es die maximale Anzahl von Teildateien anzeigt, die gespeichert werden können – beispielsweise 9768. Das Verfahren beinhaltet die folgenden Schritte und setzt voraus, dass (wie üblich) für eine Teildatei Datum und Zeit der letzten Änderung bestimmt wurden. Falls das HTTP-Protokoll eingesetzt wird, kann dies mit einer HEAD-Anfrage erreicht werden, die nicht zur Übersendung der angeforderten Teildatei, sondern nur der HEADER (Kopfzeilen)-Information führt, welche die Zeit, zu der die Teildatei auf den Server geschrieben wurde, anzeigt oder eine Null enthält, falls die Teildatei nicht existiert. Diese Zeit ist untenstehend als GetURL(LiveIndex) dargestellt, wobei LiveIndex die Sequenznummer der in Frage stehenden Teildatei ist. Kommentaren ist ein "//" vorangestellt.
Nach dem Auffinden des LiveIndex ist es empfehlenswert, die T_p (Abspielzeit) zurückzustufen und mit den Anforderungen zu beginnen, um den Audio-Pufferspeicher von dort zu füllen. Die Wiedergabe kann in der gewohnten Weise erfolgen.
Nach dem eigentlichen Beenden der Aufzeichnung kann die Indexdatei, sofern erwünscht, zum Setzen der Betriebsart auf "aufgezeichnet" und irgendwelcher Längenparametern geändert werden.
Falls erwünscht, könnte das Wiedergabeprogramm regelmäßig überprüfen, ob sich die Indexdatei von der Betriebsart "live" auf "aufgezeichnet" geändert hat und gegebenenfalls auf den Wiedergabemodus für Aufzeichnungen umschalten.
Im Folgenden wird ein einfacheres und sehr viel schnelleres Verfahren zum Auffinden der neuesten Teildatei beschrieben, wobei zunächst von einer einzelnen durchgängigen Nummerierungsfolge der Teildateien ausgegangen wird.

1. Das Endgerät setzt eine HEAD-Anforderung für die erste Teildatei (z. B. 000000.bin) ab.
2. Der Server erwidert, indem er die Kopfzeile (Header) dieser Datei zusammen mit dem Datum und der Zeit der letzten Dateiänderung (MODTIME) und dem Datum und der Zeit, zu der die Erwiderung gesandt wurde (REPLYTIME) (beides sind Standardhttp.-Felder), sendet.
3. Das Endgerät berechnet die verstrichene Zeit (ELTIME) durch Subtrahieren der beiden (ELTIME = REPLYTIME – MODTIME) und dividiert das Ergebnis durch die Wiedergabedauer einer Teildatei (in diesem Beispiel 4 Sekunden), um LIVEINDEX = ELTIME/4 zu erhalten.
4. Das Endgerät berechnet den Dateinamen der Teildatei mit diesem Index.
5. Das Endgerät gibt eine HEAD-Anforderung mit diesem Dateinamen und, falls erforderlich, mit jedem der nachfolgenden Dateinamen aus, bis es eine Null empfängt (Datei nicht gefunden), woraufhin es die zuletzt aufgefundene Teildatei als die "aktuelle Teildatei" ansieht.
6. Das Endgerät beginnt mit der Anfrage nach Dateien, beginnend bei Punkt J1 des zuvor angegebenen Flussdiagramms.

Dieses Verfahren ist wesentlich schneller als das oben für cyclisch nummerierte Teildateien beschriebene. Es sei darauf hingewiesen, dass im Hinblick auf eine Reduktion der Speichererfordernisse ältere Teildateien noch solange gelöscht werden können, als die für den Start verwendete Teildatei erhalten bleibt. Zur Anpassung an eine Wiederverwendung von Dateinamen (cyclische Adressierungen) kann dieses Verfahren jedoch geändert werden. Dies würde jedoch erfordern:

(i) dass der Name der für den Start verwendeten Teildatei (z. B. 000000.bin) nicht wiederverwendet wird, so dass er stets zum Liefern der Headerinformationen in Schritt 2 verfügbar ist. Bei einem Überschreiben im Anschluss an 009768.bin. würde der Teildatei 009768.bin daher die Teildatei 000001.bin folgen.
(ii) Der in Schritt 3 berechnete LIVEINDEX wird Modulo 9768 genommen (d. h. der Rest von ELTIME/4 dividiert durch 9768).
(iii) Das Löschen von Teildateien führt immer zum Erzeugen neuer Teildateien, so dass einige wenige Filenamen zwischen der neuesten Teildatei und der ältesten nicht gelöschten Teildatei fehlen und die erwartete Rückmeldung "Datei nicht gefunden" bei Schritt 5 auftritt.

Es besteht die Gefahr, dass der Wiedergabebetrieb ein wenig schneller oder ein wenig langsamer als der Aufzeichnungsvorgang abläuft. Um dem Ersteren vorzubeugen, kann das Wiedergabeprogramm so ausgestaltet werden, dass es jede empfangene Teildatei überprüft um sicherzustellen, dass es eine spätere Zeitmarkierung als die vorangegangene enthält. Falls nicht, wird die Teildatei verworfen und wiederholte (beispielsweise dreimal) Anforderungen gemacht, woraufhin die Indexdatei überprüft wird, falls diese Anforderungen erfolglos bleiben.
Falls die Wiedergabe hinter dem Aufnahmeprozess zurückbleibt, kann dies vom Wiedergabeprogramm festgestellt werden, indem es den Server auf das Vorhandenseins einer signifikanten Anzahl von Teildateien überprüft, die aktueller sind als die gerade angefragten, und einen "Aufhol"-Vorgang initiiert – beispielsweise durch regelmäßiges Verwerfen einer kleineren Datenmenge, falls entsprechende Teildateien existieren.

Claims

Verfahren zum Kodieren eingehender Audiosignale, das umfasst: – Kodieren mit einem ersten Kodieralgorithmus zum Erzeugen einer ersten Kodiersequenz, wobei der erste Kodieralgorithmus eine erste Rahmenlänge für jeden der fortlaufenden ersten Zeitabschnitte des Eingangssignals aufweist, dessen Abschnitte einem ganzzahligen Vielfachen der ersten Rahmenlänge entsprechen und entweder aneinander grenzen oder sich überlappen, – Kodieren mit einem zweiten Kodieralgorithmus zum Erzeugen einer zweiten Kodiersequenz, wobei der zweite Kodieralgorithmus eine zweite Rahmenlänge für jeden der fortlaufenden zweiten Zeitabschnitte des Eingangssignals aufweist, dessen Abschnitte einem ganzzahligen Vielfachen der zweiten Rahmenlänge, nicht jedoch einem ganzzahligen Vielfachen der ersten Rahmenlänge entsprechen, und die sich dergestalt überlappen, dass jeder Überlappungsbereich der zweiten Kodiersequenz zumindest eine Grenze zwischen Abschnitten der ersten Kodiersequenz umfasst, wobei weiterhin das Zuführen einer Kodiersequenz an eine Ausgabe und, in Reaktion auf eine Schaltanweisung, ein Umschalten der Ausgabe auf eine Versorgung mit der anderen Kodiersequenz beinhaltet ist, und wobei das Umschalten an der Grenze zwischen einem kodierten Zeitabschnitt und dem nächsten erfolgt.
Verfahren nach Anspruch 1, wobei der erste und zweite Kodieralgorithmus jeweils unterschiedlichen Ausgabedatenraten entsprechen.
Verfahren zur Übertragung von Audiosignalen, das umfasst: – Kodieren der Signale unter Verwendung eines Verfahrens gemäß Anspruch 1 oder 2, – Dekodieren der einzelnen Abschnitte, und – Verwerfen des Teils des dekodierten Signals, der diesem Ende und/oder diesem Anfang entspricht.