-
Die
vorliegende Erfindung bezieht sich im Allgemeinen auf ein Komprimierungsverfahren
und ein Format von digitalen Daten und auf einen Komprimierer/Dekomprimierer
für dasselbe.
-
Bestehende
tragbare Kommunikationseinrichtungen, wie etwa Mobiltelefone und
schnurlose Telefone, können
im Allgemeinen Liedklingeltöne
abspielen, um ankommende Anrufe anzukündigen. Die Lieddaten können entweder
in der tragbaren Einrichtung zuvor gespeichert oder von einem Dienstleister herunter
geladen werden. Ein wirkungsvolles Komprimierungsschema ist für die Lieddaten
notwendig, um die Kosten der Speichereinrichtung zum Speichern der
Lieder zu verringern oder, um den Bandbreitebedarf zum Herunterladen
der Lieder über
einen Band begrenzten Kanal zu gewährleisten.
-
Verlust
behaftete Komprimierungsalgorithmen zum Komprimieren anspruchsvoller
Lieddaten, wie etwa MIDI (Musical Instrument Digital Interface = digitale
Musikinstrument-Schnittstelle), sind entwickelt worden. Beispielsweise,
beschreibt das U.S. Patent Nr. 6,525,256 ein Verfahren zur Komprimierung
einer MIDI-Datei. Es besteht die Möglichkeit, ferner die Daten
durch verlustlose Schemata zu komprimieren. LZ-basierende Komprimierungsschemata basierend
auf dem Algorithmus, der durch Ziv & Lempel in 1977 (LZ77) dargestellt
wurde, werden häufig verwendet,
um Lieddaten aufgrund ihrer außergewöhnlichen
Komprimierungsverhältnis
und geringer Komplexität
des Dekomprimierers zu komprimieren. Die U.S. Patent Nummern 5,869,782
und 6,476,307 beschreiben die LZ-basierenden Komprimierungsschemata.
LZ77 nutzt die wiederholbaren Eigenschaften der Daten aus. Der Dekomprimierungsvorgang
kann einfach durch das Kopieren der wiederholten Daten von dem Suchfenster
entsprechend einem Index in den verdichteten Daten ausgeführt werden. Daten,
die nicht in dem Fenster gefunden werden, werden unkomprimiert in
den verdichteten Daten belassen. Die dekomprimierten Daten werden
dann in das Suchfenster für
die nächste
Wiederholung verschoben usw. Die Daten werden in das Fenster vorbehaltlos
verschoben, ohne dass die statistische Information betrachtet wird.
Aufgrund der begrenzten Größe des Suchfensters
werden die Erst-rein-Daten vorbehaltlos heraus verschoben, wenn
das Fenster voll ist. Die Wahrscheinlichkeit ist groß, dass
das Fenster durch verwendungslose (nicht wiederholbare) Daten besetzt
ist, während
verwendungsfähige (wiederholbare)
Daten abgewiesen werden. Um das Komprimierungsverhältnis zu
steigern, sollte ein größeres Suchfenster
verwendet werden und folglich würde
mehr Speicher durch den Dekomprimierer benötigt werden.
-
In
2001 zeigten Kwong & Ho
ein Konzept des statistischen Lempel Ziv (SLZ) in IEEE Transactions on
Consumer Electronics, Band 47, Nr. 1, Seiten 154–162, Februar 2001. Es ist
ein LZ-ähnlicher
verlustfreier Komprimierungsalgorithmus, jedoch wird auch die statistische
Information in Betracht gezogen, um nützliche Daten zu kennzeichnen,
welche in das Verzeichnis (Suchfenster) aufgenommen werden sollten.
Es steigert das Komprimierungsverhältnis verglichen mit LZ77,
da mehr nützliche
Daten in dem Verzeichnis gehalten werden können.
-
Das
Verzeichnis kann zum Halten der nützlichen Daten kleiner sein
und folglich wird weniger Speicher durch den Dekomprimierer benötigt. Da nicht
alle der Daten in das Fenster verschoben werden müssen, wird
auf dem Dekomprimierer weniger Verarbeitungsleistung benötigt. Jedoch
ist SLZ ein Schema, das zum Komprimieren allgemeiner Daten entwickelt
wurde. Kwong & Ho
lehrten kein wirkungsvolles Verfahren, um das Verzeichnis zu erhalten,
in dem die Daten variable Längen
aufweisen. Dies ist ein Hindernis für SLZ, um ein praktisches allgemeines
Komprimierungsschema zu sein.
-
Wenn
die zu verdichtenden Daten in der Form von Aufnahmen in einer festgesetzten
Länge waren,
wird das Verzeichnis darauf reduziert, ein einfaches Erst-rein-Erst-raus-Schiebefenster
zu sein. Die Implementierung von SLZ wird praktisch und all die
Vorteile von SLZ werden realisiert. Die Lieddaten werden durch eine
Reihenfolge von Musiknoten dargestellt. Jede Note ist durch eine
festgesetzte Anzahl von Bytes dargestellt, welche aus der Information
der Startzeit der Note, der Notendauer, der Notenfrequenz, der Notengeschwindigkeit,
des die Note spielenden Musikinstrumentes, etc. besteht. Die inhärenten Eigenschaften
der Melodiedaten machen SLZ zu einem geeigneten Schema, um die Daten
zu komprimieren.
-
In
einem Ausführungsbeispiel
der vorliegenden Erfindung umfasst ein Datenkomprimierer zum Komprimieren
von Lieddaten zu verdichtete Daten einen Befehlsdaten-Erzeuger,
ein Verzeichnis mit einer ersten Vielzahl von Verzeichnisseingängen, ein Schiebefenster,
das verwendet wird, um eine Vielzahl von eingegebenen Musiknoten
in den Lieddaten zu erarbeiten, ein statisches Modell für die Lieddaten, und
einen Schalter, der wahlweise eine eingegebene Musiknote in das
Verzeichnis platziert, wenn die Musiknote eine Kennzeichnung gemäß dem statistischen
Modell aufweist.
-
In
einem Ausführungsbeispiel
der vorliegenden Erfindung, einem Verzeichnis basierenden Verfahren
zum Komprimieren von Lieddaten in verdichtete Daten mit einem Befehlsteil
und einem Datenteil, umfasst das Verfahren das Auswählen einer
Vielzahl von Musiknoten von den Lieddaten, das Platzieren einer
Musiknote in einem Verzeichnis als ein Verzeichniseingang, wenn
die Musiknote eine statistische Kennzeichnung aufweist, und das
Speichern eines Index für
den Verzeichniseingang in den Befehlsteil.
-
In
einem anderen Ausführungsbeispiel
der vorliegenden Erfindung, ein Datendekomprimierer zum Dekomprimieren
verdichteter Daten in Lieddaten, worin die verdichteten Daten einen
Index zur Kennzeichnung eines indizierten Verzeichniseinganges in
einem Verzeichnis, eine erste Kennzeichnung zum Kennzeichnen, ob
Veränderungen
des indizierten Verzeichniseinganges benötigt werden, eine zweite Kennzeichnung
zum Kennzeichnen, ob eine Aktualisierung des Verzeichnisses benötigt wird,
einen Datenteil zum Verändern
des indizierten Verzeichniseinganges, umfasst, wobei der Datendekomprimierer
ein Verzeichnis mit einer ersten Vielzahl von Verzeichniseingängen, und
einen Dekodierer umfasst, der so konfiguriert ist, dass er den indizierten
Verzeichniseingang von dem Verzeichnis gemäß dem Index in den verdichteten
Daten auswählt.
-
In
einem anderen Ausführungsbeispiel
der vorliegenden Erfindung, einem Datendekomprimierungs-Verfahren zum Dekomprimieren
verdichteter Daten in Lieddaten, worin die verdichteten Daten einen
Index zur Kennzeichnung eines indizierten Verzeichniseinganges in
einem Verzeichnis, eine erste Kennzeichnung zum Kennzeichnen einer
Veränderung
des indizierten Verzeichniseinganges, eine zweite Kennzeichnung
zum Kennzeichnen einer Aktualisierung des Verzeichnisses, einen
Datenteil zum Verändern
des indizierten Verzeichniseinganges umfasst, wobei das Datendekomprimierungs-Verfahren das Lesen
verdichteter Daten, das Auffinden eines indizierten Verzeichniseinganges
in dem Verzeichnis gemäß dem Index,
und das Verwenden des indizierten Verzeichniseinganges als eine
dekodierte Musiknote umfasst, wenn die erste Kennzeichnung anzeigt,
dass keine Veränderung
benötigt
wird.
-
In
einem anderen Ausführungsbeispiel
der vorliegenden Erfindung, einem Datenformat für Verzeichnis basierende verdichtete
Lieddaten, umfasst einen Befehlsteil, der einen Index umfasst, der
einen indizierten Verzeichniseingang in einem Verzeichnis kennzeichnet,
und eine erste Kennzeichnung, die so konfiguriert ist, um eine Betriebsweise
zu bestimmen, die auf dem indizierten Verzeichniseingang ausgeführt werden
soll.
-
Ausführungsbeispiele
der Erfindung werden nun unter Bezugnahme auf die Zeichnungen beschrieben,
in denen:
-
1 einen
Komprimierer- und Dekomprimiererpaar gemäß einem bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung zeigt.
-
2 eine
Struktur eines beispielhaften Verzeichnisses gemäß einem bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung zeigt.
-
3 eine
Musiknote, die in einem Befehlsdatenpaar in den verdichteten Daten
kodiert ist, gemäß einem
bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung zeigt.
-
4 ein
Blockdiagramm des Komprimierers gemäß einem bevorzugten Ausführungsbeispiel der
vorliegenden Erfindung zeigt.
-
5 ein
Blockdiagramm des Dekomprimierers gemäß einem bevorzugten Ausführungsbeispiel der
vorliegenden Erfindung zeigt.
-
6 eine
beispielhafte Tabelle zeigt, welche die Leistungsfähigkeit
der vorliegenden Erfindung auswertet.
-
7 ein
schematisches Diagramm ist, das darstellt, wie ein indizierter Verzeichniseingang
verändert
wird.
-
8 ein
Flussdiagramm ist, das einen beispielhaften Dekomprimierungsvorgang,
der durch den Dekomprimierer ausgeführt wird, gemäß einem bevorzugten
Ausführungsbeispiel
der vorliegenden Erfindung darstellt.
-
Das
bevorzugte Ausführungsbeispiel
der vorliegenden Erfindung enthält
einen Komprimierer 10 und ein Dekomprimiererpaar 20,
wie es in 1 gezeigt ist, Der Komprimierer 10 bereitet
Lieddaten auf und erzeugt die entsprechend verdichteten Daten zum
Speichern in einer Speichereinrichtung 30 oder zur Übertragung
durch einen Kommunikationskanal 40. Der Dekomprimierer 20 erhält die verdichteten Daten
von der Speichereinrichtung 30 oder durch den Kommunikationskanal 40,
und dekomprimiert die verdichteten Daten in ihre originalen Lieddaten.
-
Gemäß dem bevorzugten
Ausführungsbeispiel
der vorliegenden Erfindung erhalten sowohl der Komprimierer 10 und
der Dekomprimierer 20 ihr eigenes Verzeichnis in der Form
eines Erst-rein-Erst-raus-Schiebefensters
mit der gleichen Struktur und Größe. Der
Komprimierer 10 erzeugt Befehle auf den verdichteten Daten,
um den Dekomprimierer 20 anzuweisen, ob eine neu dekodierte
Musiknote in das Verzeichnis zu verschieben ist oder nicht. Dies
stellt sicher, dass beide Verzeichnisse synchron arbeiten und die
Daten innerhalb der Verzeichnisse immer identisch sind.
-
2 zeigt
eine beispielhafte Struktur des Verzeichnisses, in dem jede Musiknote
N Bytes besetzt, und das Verzeichnis maximal W Musiknoten aufnimmt.
In einem Aspekt kann das Verzeichnis in der Form eines einfachen
Schiebefensters sein. Der Index des Verzeichniseinganges enthält w Bits,
wobei w = log2(W) ist. Die Verzeichnisgröße W ist vorzugsweise eine
ganzzahlige Potenz von 2, um die Verbindungen von w-Bits des Index
vollständig
zu verwenden. In einem anderen Aspekt ist es sowohl durch den Komprimierer
und Dekomprimierer abgestimmt, dass das Verzeichnis vor dem Kodieren
bzw. Dekodieren der ersten Musiknote auf 0 voreingestellt ist.
-
Die
vorliegende Erfindung stellt ein Datenformat für verdichtete Lieddaten bereit.
Das Datenformat für
die verdichteten Lieddaten ist in einem Befehlsdaten-Paar. Der Befehlsteil
in den verdichteten Lieddaten wird verwendet, um einen Verzeichniseingang
(nachfolgend, indizierter Verzeichniseingang) zu indizieren, welcher
am nächsten
zu einer gegenwärtigen
Musiknote in dekomprimiertem Format ist. Darüber hinaus zeigt der Befehlsteil
in den verdichteten Lieddaten auch an, ob der indizierte Verzeichniseingang
eine Veränderung
benötigt,
um eine dekodierte Musiknote zu erhalten, und ob eine neue dekodierte
Musiknote in das Verzeichnis als ein neuer Eingang verschoben werden
sollte. Der Datenteil in den verdichteten Lieddaten zeigt an, wie
der indizierte Verzeichniseingang verändert werden sollte, wenn der
Befehlsteil die Veränderung
bestätigt.
Im Besonderen enthält
der Datenteil ein erstes Datenfeld, um eine Veränderungseinstellung für den zu
veränderten indizierten
Verzeichniseingang anzuzeigen. Die ersten Datenfeld-Elemente enthalten
eine Reihe von primären
Bits, um anzuzeigen, ob Datenbereiche in dem indizierten Verzeichniseingang
eine Veränderung
benötigen.
Der Datenteil enthält
ferner ein zweites Datenfeld, um Datensegmente, die zum erneuten Platzieren
entsprechender Datenbereiche in dem indizierten Verzeichniseingang
verwendet werden, zu speichern.
-
3 zeigt
das Format der verdichteten Lieddaten in den Befehlsdaten-Paar entsprechend einem
bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung. Der Befehlsteil ist obligatorisch, während der
Datenteil für
den bestimmten Teil abwesend sein kann. Der Befehlsteil besteht
aus 3 Bit-Feldern. Das erste Befehlsfeld C1 in dem Befehlsteil besteht
aus einer Länge
von w Bits und ist der Index zu den Eingängen des Verzeichnisses. Das
zweite Befehlsfeld C2 in dem Befehlsteil enthält 1 Bit, das den auszuführenden
Arbeitsvorgang in dem indizierten Verzeichniseingang bestimmt, um
eine neue dekodierte Musiknote zu erhalten. Beispielsweise, wenn das
Befehlsfeld C2 einen Wert von 1 hat, wird dann die dekodierte Musiknote
durch das Verändern
des indizierten Verzeichniseinganges erhalten. In diesem Fall wird
der Datenteil verwendet, um zu bestimmen, wie die Veränderung
durchgeführt
werden sollte. Wenn dieses zweite Befehlsfeld C2 einen Wert von
0 hat, wird dann die dekodierte Musiknote durch das Kopieren des
indizierten Verzeichniseinganges, der durch das erste Befehlsfeld
C1 von dem Verzeichnis ohne Veränderung
gekennzeichnet ist, erhalten. In diesem Fall ist der Datenteil abwesend.
-
Wenn
das zweite Befehlsfeld C2 den Wert von 1 trägt, dann enthält das dritte
Befehlsfeld C3 in dem Befehlsteil 1 Bit, das bestimmt, ob die dekodierte
Musiknote in das Schiebefenster, nämlich das Verzeichnis, verschoben
werden muss. Wenn das zweite Feld C2 den Wert von 0 hat, ist dann
das dritte Feld C3 abwesend. Da die identische Musiknote in dem Fenster
gefunden wurde, muss die dekodierte Musiknote nicht in das Verzeichnis
verschoben werden, um duplizierte Daten in dem Fenster zu vermeiden.
-
Der
Datenteil ist nur vorhanden, wenn das zweite Befehlsfeld C2 des
Befehlsteiles 1 ist. Der Datenteil zeigt dem Dekomprimierer an,
wie der aus dem Verzeichnis entnommene indizierte Verzeichniseingang
verändert
ist, um die dekodierte Musiknote zu erhalten. Gemäß einem
bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung besteht der Datenteil aus 2 Bit-Feldern.
-
Das
erste Feld D1 des Datenteiles enthält N Bits. Jedes Bit entspricht
einem Datenbyte in einer Musiknote von N Bytes. Wenn ein binäres Bit
in dem ersten Feld D1 einen Wert von 1 hat, wird dann das entsprechende
Byte in dem von dem Verzeichnis entnommenen indizierten Verzeichniseingang
verändert.
Wenn ein binäres
Bit in dem ersten Feld D1 einen Wert von 0 hat, verbleibt das entsprechende
Datenbyte in dem aus dem Verzeichnis entnommenen indizierten Verzeichniseingang
unverändert.
-
Das
zweite Datenfeld D2 des Datenteiles besteht aus 1 bis N Bytes abhängig von
der Anzahl von Binären
in dem ersten Datenfeld D1 des Datenteiles. Jede der Datenbytes
in dem zweiten Datenfeld D2 wird verwendet, um ein Datenbyte in
dem indizierten Verzeichniseingang erneut zu platzieren, welcher durch
ein entsprechendes Binäres
in dem ersten Datenfeld D1 gekennzeichnet ist. 7 ist
ein schematisches Diagramm, das darstellt, wie der indizierte Verzeichniseingang
verändert
wird. In dieser Figur ist ein erstes Datenfeld D1 ein n-Tuple Vektor
mit zwei binären
und (n-2) binären
Nullen. Daher enthält
das zweite Datenfeld D2 zwei Datenbytes (Datensegmente), um entsprechende
Datenbytes (Datenbereiche) in dem indizierten Verzeichniseingang
erneut zu platzieren, welche durch das erste Datenfeld D1 gekennzeichnet
sind.
-
Die
obige Beschreibung für
das Format der verdichteten Lieddaten basiert auf der Bedingung, dass
jede Musiknote N Bytes belegt und das Verzeichnis maximal W Musiknoten
aufnimmt. Jedoch kann das detaillierte Format der verdichteten Lieddaten
gemäß dem praktischen
Bedarf verändert
werden. Der Befehlsteil der verdichteten Lieddaten kann einen anderen
binären
Wert, wie etwa binär
0, verwenden, um die Veränderung
des indizierten Verzeichniseinganges zu bestätigen. Daher ist die obige Beschreibung
keine Einschränkung
des Schutzumfanges der vorliegenden Erfindung.
-
Ein
beispielhaftes Blockdiagramm des Komprimierers 10 ist in 4 gezeigt.
Wie es in dieser Figur gezeigt ist, enthält der Komprimierer 10 einen
Befehlsdaten-Erzeuger 100, ein Verzeichnis 102 von W-Eingängen, ein
statistisches Modell 106 und mindestens ein Schiebefenster 104.
Der Komprimierer 10 verdichtet Lieddaten aus einer Vielzahl
von Musiknoten in eine verdichtete Datei unter Bezugnahme auf das
statistische Modell 106. Die verdichteten Daten haben ein
in 3 gezeigtes Format. Die zu verdichteten Lieddaten
in der Form eines Zuges von Musiknoten werden sequentiell in das
Schiebefenster 104 zur Auswertung unter Verwendung des
statistischen Modells 106 verschoben. Die Fenstergröße ist einstellbar,
um das beste Komprimierungsverhältnis zu
erhalten. Das statistische Modell 106 bestimmt, ob eine
zu verdichtende Musiknote, die an dem Ende des Schiebefensters 104 angeordnet
ist, in das Verzeichnis 102 verschoben werden soll. Wenn
eine Musiknote eine statistische Eigenschaft gemäß dem statistischen Modell 106 aufweist,
schließt
der Schalter 108, so dass die Musiknote in das Verzeichnis 102 verschoben
werden kann. Andererseits ist der Schalter 108 geöffnet, um
das Verzeichnis 102 unverändert beizubehalten. In dem
statistischen Modell 106 wird vorausgesetzt, dass die zu
verdichtende Musiknote zuerst in das Verzeichnis 102 verschoben wird,
um ein imaginäres
Verzeichnis zu bilden. Dann werden die folgenden Musiknoten in dem
Schiebefenster 104 unter Verwendung des imaginären Verzeichnisses
kodiert, wie das, was in dem Befehlsdaten-Erzeuger 100 ausgeführt wurde.
Die Anzahl von Zeiten der zu verdichtenden Musiknote in dem imaginären Verzeichnis,
auf dass während
dem Kodierungsvorgang Bezug genommen wird, wird aufgezeichnet, während die
Kodierungsergebnisse verworfen werden. Die statistische Eigenschaft
der zu verdichtenden Musiknote wird gegenwärtig gehalten, wenn die Ähnlichkeit
der zu verdichtenden Musiknote eine Schwellenwertbedingung erreicht.
Im Besonderen, wenn die Anzahl von Zeiten der Bezug genommenen Musiknote
oberhalb eines vorbestimmten Schwellenwertes ist, wird sie erachtet,
eine statistische Eigenschaft zu haben, und die Musiknote wird als
verwendbar erachtet und wird in das Verzeichnis 102 verschoben.
Mit anderen Worten, wenn die zu verdichtende Musiknote, wenn erkannt,
dass sie (wie durch die Musiknote, auf die während der Kodierung von Noten
Bezug genommen wird, angezeigt ist) einer vordefinierten Anzahl
von Musiknoten von dem Schiebefenster 104 ähnelt, wird
die Musiknote in das Verzeichnis 102 verschoben.
-
Bevor
die Musiknote in das Verzeichnis 102 verschoben wird (mit
dem Sinn, dass sie benötigt wird),
verweist der Befehlsdaten-Erzeuger 100 auf die Verzeichniseingänge und
kodiert die Musiknote in einem Befehlsdaten-Paar als verdichtete
Daten. Der Bezug genommene Verzeichniseingang muss der Näheste zu
der Musiknote für
das beste Komprimierungsverhältnis
sein. Der Befehlsdaten-Erzeuger 100 zeichnet einen Index
in dem ersten Befehlsfeld C1 der verdichteten Daten so auf, dass
der Bezug genommene Verzeichniseingang ein indizierter Verzeichniseingang
ist, der durch das erste Befehlsfeld C1 gekennzeichnet ist. Wenn
ein Unterschied zwischen der Musiknote und dem indizierten Verzeichniseingang
vorhanden ist, speichert der Befehlsdaten-Erzeuger 100 eine
Kennzeichnung in dem zweiten Feld C2 der verdichteten Daten ab,
um einen Veränderungsbedarf
anzuzeigen. Darüber
hinaus speichert der Befehlsdaten-Erzeuger 100 den Unterschied
zwischen der Musiknote und dem Bezug genommenen Verzeichniseingang
in dem Datenteil der verdichteten Daten ab. Wenn die Musiknote in
das Verzeichnis 102 verschoben werden soll, in Übereinstimmung
mit dem statistischen Modell 106, erstellt der Befehlsdaten-Erzeuger 100 eine
Kennzeichnung in dem dritten Befehlsfeld C3, um einen Aktualisierungs-Bedarf
anzuzeigen.
-
Ein
beispielhaftes Blockdiagramm des Dekomprimierers 20 ist
in 5 gezeigt. Der Dekomprimierer 20 dekomprimiert
verdichtete Daten in dem Befehlsdaten-Paarformat auf die ursprünglichen Lieddaten.
Der Dekomprimierer 20 enthält einen Befehlsdaten-Dekodierer 200 und
ein Verzeichnis 202 von W Eingängen. Der Dekodierer 200 interpretiert das
eingegebene Befehlsdaten-Paar derart, dass Musiknoten in die ursprünglichen
Lieddaten entweder durch das Kopieren oder Verändern des indizierten Eingangs
von dem Verzeichnis 202 neu erstellt werden.
-
Der
Dekodierer 200 ermöglicht
auch oder verhindert, dass die dekodierte Musiknote in das Verzeichnis 202 zur
Aktualisierung des Verzeichnis 202 gemäß dem Befehl, der durch den
Befehlsteil der eingegebenen Daten vorgesehen ist, verschoben werden.
Dieser Aktualisierungsvorgang für
das Verzeichnis 202 des Dekomprimierers 20 synchronisiert
den Verzeichnisinhalt mit dem Verzeichnis 102 in dem Komprimierer 10.
-
Der
Dekomprimierungsvorgang ist unter Bezugnahme auf die 5 und 8 beschrieben. 8 zeigt
einen beispielhaften Dekomprimierungsvorgang, der durch den Dekodierer 200 durchgeführt wird,
wo ein Eingang verdichteter Daten verarbeitet wird, um eine dekodierte
Musiknote zu erhalten. Der Dekodierer 200 entscheidet auch
gemäß dem Befehlsteil
in dem Eingang verdichteter Daten, ob die dekodierte Musiknote in
das Verzeichnis 202 verschoben werden sollte, um das Verzeichnis 202 zu aktualisieren.
-
Unter
Bezugnahme auf 8, in Schritt S100, wird ein
erstes Befehlsfeld C1 des Befehlsteiles aus dem Eingang verdichteter
Daten, die im Befehlsteil-Paarformat kodiert sind, extrahiert. Das
erste Befehlsfeld C1 wird verwendet, um einen Verzeichniseingang
in dem Verzeichnis 202 zu indizieren. Schritt S110 führt das
zweite Befehlsfeld C2 in den Befehlsteil des Eingangs verdichteter
Daten aus. Wenn das zweite Feld C2 des Befehlsteiles einen Wert
von 1 hat, benötigt
der Verzeichniseingang, der durch das erste Feld C1 indiziert ist,
eine Veränderung
zum Erhalten der dekodierten Musiknote, so dass Schritt S120 als
nächstes
durchgeführt
wird. Andernfalls wird Schritt S112 durchgeführt, in dem die dekodierte
Musiknote durch direktes Kopieren des indizierten Verzeichniseinganges,
der durch das erste Feld C1 ohne Veränderung gekennzeichnet ist, erhalten
wird.
-
In
Schritt S120 wird der indizierte Verzeichniseingang unter Bezugnahme
auf eine Veränderungseinstellung
in dem ersten Datenfeld D1 des Datenteiles und des Datensegmentes
in dem zweiten Datenfeld D2 des Datenteiles verändert. Im Besonderen, wenn
ein Element in dem ersten Feld D1 einen Wert von 1 hat, wird der
entsprechende Datenbereich in dem indizierten Verzeichniseingang
durch das Datensegment in dem zweiten Datenfeld D2 verändert, welches
durch das Element in dem ersten Feld D1 des Datenteiles gekennzeichnet
ist, wie es beispielsweise in 7 dargestellt
ist.
-
Mit
anderen Worten, jede in Feld D1 dargestellte Binäre 1, welche ein entsprechendes
Byte in dem indizierten Verzeichnis anzeigt, wird verwendet, um
ein entsprechendes Byte der Daten in Feld D2 zu kennzeichnen, welches
für das
entsprechende Byte in dem indizierten Verzeichnis ersetzt wird,
um einen veränderten
indizierten Verzeichniseingang zu erzeugen.
-
In
Schritt S122 wird die dekodierte Musiknote erhalten. Der Schritt
S130 überprüft, ob das
dritte Befehlsfeld C3 einen Wert von 1 hat. Wenn das dritte Befehlsfeld
C3 einen Wert von 1 hat, wird der Schritt S132 durchgeführt, um
die dekodierte Musiknote in das Verzeichnis 202 als einen
neuen Eingang in dem Verzeichnis 202 zu verschieben. Ansonsten
bewegt sich das Verfahren direkt zu der Verarbeitung der nächsten Daten.
-
Um
die Leistung der vorliegenden Erfindung auszuwerten, wurden zwölf Lieder
zufällig,
ausgewählt
und durch LZ77, dem Power Archiver 6.1 1, und einem Ausführungsbeispiel
dieser Erfindung (SLZ) von unterschiedlicher Verzeichnisgröße verdichtet.
Jede Musiknote in der Lieddatei enthält 4 Bytes. Das LZ77 Schema
verwendete ein Suchfenster von 64 Bytes und ein Voraus-Fenster von
8 Byte. Der LZ77 Dekomprimierer benötigte die gleiche Menge von
RAM (random access memory = Schreib-Lese-Speicher) als SLZ (W = 16). Vergleiche
von den drei Schemata sind in 6 gezeigt.
Alle Dateigrößen sind
in Bytes. Der Power Archiver weist die beste Leistung für Lieder
3, 8, 9 und 12 auf. Das SLZ mit einer Verzeichnisgröße von 4
(W = 4) weist die beste Leistung für das Lied 4 auf. Das SLZ mit
einer Verzeichnisgröße von 8
(W = 8) weist die beste Leistung für das Lied 7 auf. Das SLZ mit
der Verzeichnisgröße von 16
(W = 16) weist die beste Leistung für das Lied 1, 2, 5, 6, 10 und
11 auf. Das SLZ mit den Verzeichnisgrößen von 8 und 16 übertrafen
LZ77 im Komprimierungsverhältnis.
Der Dekomprimierer von SLZ (W = 8) benötigte weniger RAM, als dies
LZ77 für
ein sogar besseres Komprimierungsverhältnis tat. Obwohl der Power
Archiver in einigen Fällen überlag,
verwendete er mehrere Schemata von Kodierung mit mittlerem Informationsgehalt
und der Lauflängenkodierung
zusätzlich
zu LZ77. Der Dekomprimierer benötigte
weitaus mehr Verarbeitungsleistung als dies lediglich SLZ tat. Tatsächlich zeigte
das SLZ die beste Leistung im gesamten Komprimierungsverhältnis.
-
Die
vorhergehende Beschreibung der bevorzugten Ausführungsbeispiele der vorliegenden
Erfindung sind zum Zwecke der Darstellung und Beschreibung vorgetragen
worden. Sie ist nicht angedacht, um vollständig zu sein, oder die Erfindung
auf die genau beschriebenen Formen einzuschränken. Viele Abänderungen
und Veränderungen
der hierin beschriebenen Ausführungsbeispiele
werden für
einen Durchschnittsfachmann im Hinblick auf die obige Beschreibung
ersichtlich. Der Schutzumfang der Erfindung ist ausschließlich durch
die hieran angehängten Ansprüche und
durch ihre Äquivalente
definiert.
-
Ferner
kann, in der Beschreibung der repräsentativen Ausführungsbeispiele
der vorliegenden Erfindung, die Beschreibung das Verfahren und/oder den
Arbeitsvorgang der vorliegenden Erfindung als eine bestimmte Abfolge
von Schritten dargestellt haben. Jedoch, soweit das Verfahren oder
der Arbeitsvorgang nicht auf eine bestimmte Abfolge von Schritten,
die hierin vorgetragen sind, beruhen, sollte das Verfahren oder
der Arbeitsvorgang nicht auf die bestimmte Abfolge von beschriebenen
Schritten eingeschränkt
werden. Wie es für
einen Durchschnittsfachmann erkenntlich wäre, können andere Abfolgen von Schritten
möglich
sein. Daher sollte die besondere Reihenfolge der Schritte, die in
der Beschreibung vorgetragen sind, nicht als Einschränkungen
der Ansprüche
betrachtet werden. Darüber
hinaus sollten die Ansprüche,
die auf das Verfahren und/oder den Arbeitsvorgang der vorliegenden
Erfindung gerichtet sind, nicht auf die Leistungsfähigkeit
der in der Reihenfolge beschriebenen Schritte eingeschränkt werden,
und ein Durchschnittsfachmann kann vollständig erkennen, dass die Abfolgen
verändert
werden können
und dennoch innerhalb des Geistes und Schutzumfanges der vorliegenden
Erfindung verbleibt.