DE102006062062B4

DE102006062062B4 - Komprimierung von Lieddaten und Komprimierer/Dekomprimierer

Info

Publication number: DE102006062062B4
Application number: DE102006062062A
Authority: DE
Inventors: Yu Fan New Territories Ho
Original assignee: VTech Telecommunications Ltd
Current assignee: VTech Telecommunications Ltd
Priority date: 2005-12-30
Filing date: 2006-12-29
Publication date: 2010-01-21
Anticipated expiration: 2026-12-30
Also published as: CA2572526A1; US20070152853A1; DE102006062062A1; US7507897B2

Abstract

Datenkomprimierer zum Komprimieren von Lieddaten zu komprimierten Daten, umfassend:
einen Befehlsdaten-Erzeuger (100);
ein Verzeichnis (102) mit einer ersten Vielzahl von Verzeichniseinträgen;
ein Schiebefenster, das verwendet wird, um eine Vielzahl von eingegebenen Musiknoten in den Lieddaten zusammenzufassen;
ein statistisches Modell, mit dem man die zu komprimierende Musiknote mit nachfolgenden Musiknoten in dem Schiebefenster vergleichen kann; und
ein Schalter, der so ausgestaltet ist, dass er aus einem geöffneten in eine geschlossene Position umschalten kann, um wahlweise eine zu komprimierende eingegebene Musiknote in das Verzeichnis (102) zu platzieren, wenn die eingegebene Musiknote eine Eigenschaft entsprechend dem statistischen Modell aufweist, dadurch gekennzeichnet, dass, bevor die Musiknote in das Verzeichnis (102) geschoben wird, der Befehlsdatenerzeuger (100) auf die Verzeichniseinträge verweist und die Musiknote in ein Befehls-Daten-Paar, bestehend aus einem Befehlsteil (C1–C3) und einem Datenteil (D1, D2) codiert.

Description

Die vorliegende Erfindung bezieht sich im Allgemeinen auf das Komprimieren und dekomprimieren von Lieddaten.
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 die US 6,525,256 B2 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 US 5,869,782 A und die US 6,476,307 A 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 komprimierten Daten ausgeführt werden. Daten, die nicht in dem Fenster gefunden werden, werden unkomprimiert in den komprimierten 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 und Ho ein Konzept des statistischen Lempel Ziv (SLZ) in KWONG, S.; HO, Y. F.: A statistical Lempel-Ziv Compression Algorithm for Personal Digital Assistent (PDA), 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. Solch eine Modellierung ist auch aus BELL, T.; WITTEN, I.; CLEARY, J.: Modelling for Text Compression, ACM Computer Surveys, Band 21, Nr. 4, Dezember 1989 bekannt.
Das Verzeichnis kann zum Halten der nützlichen Daten kleiner sein und folglich wird weniger Speicher durch den Dekomprimierer benötigt. Da nicht alle 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 komprimierenden 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.
Die US 6,535,642 B1 zeigt einen Datenkomprimierer zum Komprimieren von Lieddaten zu komprimierten Daten, mit einem Befehlsdaten-Erzeuger, einem Verzeichnis mit einer ersten Vielzahl von Verzeichniseinträgen und einem Schiebefenster, das verwendet wird, um eine Vielzahl von eingegebenen Musiknoten in den Lieddaten zusammenzufassen. Ein statistisches Modell wird verwendet, um die zu komprimierende Musiknote mit nachfolgenden Musiknoten in dem Schiebefenster zu vergleichen. Eine zu komprimierende Musiknote wird wahlweise in das Verzeichnis platziert, wenn die eingegebene Musiknote eine Eigenschaft entsprechend dem statistischen Modell aufweist.
Der Erfindung liegt die Aufgabe zugrunde, eine Komprimierung und Dekomprimierung bereit zu stellen, bei der eine erhöhte Leistung insgesamt bei der Komprimierung von Lieddaten, die eine in einem weiten Bereich variierende Größe haben, bei möglichst geringer Speicherkapazität des Datenspeichers erreicht wird.
Dazu stellt die Erfindung den Datenkomprimierer zum Komprimieren von Lieddaten nach Anspruch 1 bereit.
Im Rahmen der vorstehenden Aufgabe stellt die Erfindung ferner das Verzeichnis basierenden Verfahren zum Komprimieren von Lieddaten nach Anspruch 1 bereit.
Im Rahmen der vorstehenden Aufgabe stellt die Erfindung ferner das Verfahren zum Komprimieren und Dekomprimieren von Lieddaten nach Anspruch 7 bereit.
Im Rahmen der vorstehenden Aufgabe stellt die Erfindung ferner den Daten-Dekomprimierer zum Dekomprimieren von Lieddaten nach Anspruch 10 bereit.
Im Rahmen der vorstehenden Aufgabe stellt die Erfindung ferner den Daten-Dekomprimiervefahren zum Dekomprimieren von Lieddaten nach Anspruch 16 bereit.
Vorteilhafte Ausführungsformen der Erfindung sind in den jeweiligen Unteransprüchen gekennzeichnet.
Bei der Erfindung wird die Leistung insgesamt bei der Komprimierung von Lieddaten, die eine in einem weiten Bereich variierende Größe haben, erhöht, wobei die Leistungsfähigkeit bei der Komprimierung von Lieddaten nicht nur bei einzelnen Lieddaten (Lieder) sondern bei verschieden Lieder unterschiedlicher Länge (Datenmenge oder Größe) in Zusammenschau zu beurteilen ist.
Ausführungsbeispiele der Erfindung werden nun unter Bezugnahme auf die Zeichnungen beschrieben, in denen:
1 einen Komprimierer- und Dekomprimierer-Paar 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 komprimierten 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 Verzeichniseintrag 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 Erfindung enthält einen Komprimierer 10 und ein Dekomprimiererpaar 20, wie es in 1 gezeigt ist. Der Komprimierer 10 bereitet Lieddaten auf, die aus einer Vielzahl von eingegebenen Musiknoten bestehen, und erzeugt die entsprechend komprimierten Daten zum Speichern in einer Speichereinrichtung 30 oder zur Übertragung durch einen Kommunikationskanal 40. Der Dekomprimierer 20 erhält die komprimierten Daten von der Speichereinrichtung 30 oder durch den Kommunikationskanal 40, und dekomprimiert die komprimierten 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 komprimierten Daten, um den Dekomprimierer 20 anzuweisen, ob eine neu decodierte 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 Verzeichniseintrages 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 Codieren bzw. Decodieren der ersten Musiknote auf „0” voreingestellt ist.
Die vorliegende Erfindung stellt ein Datenformat für komprimierte Lieddaten bereit. Das Datenformat für die komprimierten Lieddaten ist in einem Befehl-Daten-Paar. Der Befehlsteil in den komprimierten Lieddaten wird verwendet, um einen Verzeichniseintrag (nachfolgend, indizierter Verzeichniseintrag) zu indizieren, welcher am nächsten zu einer gegenwärtigen Musiknote in dekomprimiertem Format ist. Darüber hinaus zeigt der Befehlsteil in den komprimierten Lieddaten auch an, ob der indizierte Verzeichniseintrag eine Veränderung benötigt, um eine decodierte Musiknote zu erhalten, und ob eine neue decodierte Musiknote in das Verzeichnis als ein neuer Eintrag verschoben werden sollte. Der Datenteil in den komprimierten Lieddaten zeigt an, wie der indizierte Verzeichniseintrag 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 Verzeichniseintrag anzuzeigen. Die ersten Datenfeld-Elemente enthalten eine Reihe von primären Bits, um anzuzeigen, ob Datenbereiche in dem indizierten Verzeichniseintrag eine Veränderung benötigen. Der Datenteil enthält ferner ein zweites Datenfeld, um Datensegmente, die zum erneuten Platzieren entsprechender Datenbereiche in dem indizierten Verzeichniseintrag verwendet werden, zu speichern.
3 zeigt das Format der komprimierten Lieddaten in den Befehl-Daten-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 Einträgen des Verzeichnisses. Das zweite Befehlsfeld C2 in dem Befehlsteil enthält 1 Bit, das den auszuführenden Arbeitsvorgang in dem indizierten Verzeichniseintrag bestimmt, um eine neue decodierte Musiknote zu erhalten. Beispielsweise, wenn das Befehlsfeld C2 einen Wert von „1” hat, wird dann die decodierte Musiknote durch das Verändern des indizierten Verzeichniseintrages 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 decodierte Musiknote durch das Kopieren des indizierten Verzeichniseintrages, 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 decodierte 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 decodierte 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 Verzeichniseintrag verändert ist, um die decodierte 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 Verzeichniseintrag 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 Verzeichniseintrag 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 Verzeichniseintrag 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 Verzeichniseintrag 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 Verzeichniseintrag erneut zu platzieren, welche durch das erste Datenfeld D1 gekennzeichnet sind.
Die obige Beschreibung für das Format der komprimierten Lieddaten basiert auf der Bedingung, dass jede Musiknote N Bytes belegt und das Verzeichnis maximal W Musiknoten aufnimmt. Jedoch kann das detaillierte Format der komprimierten Lieddaten gemäß dem praktischen Bedarf verändert werden. Der Befehlsteil der komprimierten Lieddaten kann einen anderen binären Wert, wie etwa binär 0, verwenden, um die Veränderung des indizierten Verzeichniseintrages 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-Einträgen, ein statistisches Modell 106 und mindestens ein Schiebefenster 104. Der Komprimierer 10 komprimiert Lieddaten aus einer Vielzahl von Musiknoten in eine komprimierte Datei unter Bezugnahme auf das statistische Modell 106. Die komprimierten Daten haben ein in 3 gezeigtes Format. Die zu komprimierten 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 komprimierende 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 komprimierende 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 codiert, wie das, was in dem Befehlsdaten-Erzeuger 100 ausgeführt wurde. Die Anzahl von Zeiten der zu komprimierenden Musiknote in dem imaginären Verzeichnis, auf dass während dem Codierungsvorgang Bezug genommen wird, wird aufgezeichnet, während die Codierungsergebnisse verworfen werden. Die statistische Eigenschaft der zu komprimierenden Musiknote wird gegenwärtig gehalten, wenn die Ähnlichkeit der zu komprimierenden 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 komprimierende 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 Verzeichniseinträge und codiert die Musiknote in einem Befehl-Daten-Paar als komprimierte Daten. Der Bezug genommene Verzeichniseintrag 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 komprimierten Daten so auf, dass der Bezug genommene Verzeichniseintrag ein indizierter Verzeichniseintrag ist, der durch das erste Befehlsfeld C1 gekennzeichnet ist. Wenn ein Unterschied zwischen der Musiknote und dem indizierten Verzeichniseintrag vorhanden ist, speichert der Befehlsdaten-Erzeuger 100 eine Kennzeichnung in dem zweiten Feld C2 der komprimierten Daten ab, um einen Veränderungsbedarf anzuzeigen. Darüber hinaus speichert der Befehlsdaten-Erzeuger 100 den Unterschied zwischen der Musiknote und dem Bezug genommenen Verzeichniseintrag in dem Datenteil der komprimierten 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 komprimierte Daten in dem Befehl-Daten-Paarformat auf die ursprünglichen Lieddaten. Der Dekomprimierer 20 enthält einen Befehlsdaten-Dekodierer 200 und ein Verzeichnis 202 von W Einträgen. Der Decodierer 200 interpretiert das eingegebene Befehl-Daten-Paar derart, dass Musiknoten in die ursprünglichen Lieddaten entweder durch das Kopieren oder Verändern des indizierten Eintrags von dem Verzeichnis 202 neu erstellt werden.
Der Decodierer 200 ermöglicht auch oder verhindert, dass die decodierte 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 Decodierer 200 durchgeführt wird, wo ein Eintrag komprimierter Daten verarbeitet wird, um eine decodierte Musiknote zu erhalten. Der Decodierer 200 entscheidet auch gemäß dem Befehlsteil in dem Eintrag komprimierter Daten, ob die decodierte 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 Eintrag komprimierter Daten, die im Format eines Befehl-Daten-Paares codiert sind, extrahiert. Das erste Befehlsfeld C1 wird verwendet, um einen Verzeichniseintrag in dem Verzeichnis 202 zu indizieren. Schritt S110 führt das zweite Befehlsfeld C2 in den Befehlsteil des Eintrags komprimierter Daten aus. Wenn das zweite Feld C2 des Befehlsteiles einen Wert von „1” hat, benötigt der Verzeichniseintrag, der durch das erste Feld C1 indiziert ist, eine Veränderung zum Erhalten der decodierten Musiknote, so dass Schritt S120 als nächstes durchgeführt wird. Andernfalls wird Schritt S112 durchgeführt, in dem die decodierte Musiknote durch direktes Kopieren des indizierten Verzeichniseintrages, der durch das erste Feld C1 ohne Veränderung gekennzeichnet ist, erhalten wird.
In Schritt S120 wird der indizierte Verzeichniseintrag 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 Verzeichniseintrag 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 Verzeichniseintrag zu erzeugen.
In Schritt S122 wird die decodierte 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 decodierte Musiknote in das Verzeichnis 202 als einen neuen Eintrag in dem Verzeichnis 202 zu verschieben. Ansonsten bewegt sich das Verfahren direkt zu der Verarbeitung der nächsten Daten.
Um die Leistungsfähigkeit der vorliegenden Erfindung zu zeigen, wurden zwölf Lieder zufällig ausgewählt und durch LZ77, dem Power Archiver 6.11, und durch ein Ausführungsbeispiel der Erfindung (SLZ) von unterschiedlicher Verzeichnisgröße komprimiert. 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 überlegen war, verwendete er mehrere Schemata von Codierung mit mittlerem Informationsgehalt und der Lauflängencodierung 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, sodass durch die Erfindung eine erhöhte Leistung insgesamt bei der Komprimierung von Lieddaten, die eine in einem weiten Bereich variierende Größe haben, bei möglichst geringer Speicherkapazität des Datenspeichers erreicht wird.

Claims

Datenkomprimierer zum Komprimieren von Lieddaten zu komprimierten Daten, umfassend: einen Befehlsdaten-Erzeuger (100); ein Verzeichnis (102) mit einer ersten Vielzahl von Verzeichniseinträgen; ein Schiebefenster, das verwendet wird, um eine Vielzahl von eingegebenen Musiknoten in den Lieddaten zusammenzufassen; ein statistisches Modell, mit dem man die zu komprimierende Musiknote mit nachfolgenden Musiknoten in dem Schiebefenster vergleichen kann; und ein Schalter, der so ausgestaltet ist, dass er aus einem geöffneten in eine geschlossene Position umschalten kann, um wahlweise eine zu komprimierende eingegebene Musiknote in das Verzeichnis (102) zu platzieren, wenn die eingegebene Musiknote eine Eigenschaft entsprechend dem statistischen Modell aufweist, dadurch gekennzeichnet, dass, bevor die Musiknote in das Verzeichnis (102) geschoben wird, der Befehlsdatenerzeuger (100) auf die Verzeichniseinträge verweist und die Musiknote in ein Befehls-Daten-Paar, bestehend aus einem Befehlsteil (C1–C3) und einem Datenteil (D1, D2) codiert.
Datenkomprimierer nach Anspruch 1, dadurch gekennzeichnet, dass der Befehlsdaten-Erzeuger (100) so ausgestaltet ist, dass er einen Verzeichniseintrag am nächsten zu der zu komprimierenden Musiknote findet, und so ausgestaltet ist, dass er einen Index für den Verzeichniseintrag in dem Befehlsteil (C1–C3) speichert.
Datenkomprimierer nach Anspruch 2, dadurch gekennzeichnet, dass der Befehlsdaten-Erzeuger (100) so konfiguriert ist, dass er einen Unterschied zwischen der Musiknote und dem Verzeichniseintrag in dem Datenteil (D1, D2) aufnimmt.
Datenkomprimierer nach Anspruch 3, dadurch gekennzeichnet, dass der Befehlsdaten-Erzeuger (100) so konfiguriert ist, dass er eine Anzeige einer Aktualisierung in dem Befehlsteil (C1–C3) speichert, um anzuzeigen, ob das Verzeichnis (102) eine Aktualisierung benötigt.
Datenkomprimierer nach Anspruch 1, dadurch gekennzeichnet, dass die Zahl der Einträge in das Verzeichnis (102) gleich einer ganzzahligen Potenz von „2” ist.
Datenkomprimierer nach Anspruch 1, dadurch gekennzeichnet, dass das Verzeichnis (102) ein Erster-rein-Erster-raus-Schiebefenster umfasst.
Verfahren zum Komprimieren von Lieddaten in komprimierten Daten mit einem Befehlsteil (C1–C3) und einem Datenteil (D1, D2), wobei das Verfahren umfasst: Platzieren einer Vielzahl von Musiknoten von den Lieddaten in einem Schiebefenster; Vergleichen einer ersten Musiknote, die von dem Schiebefenster empfangen wird, mit einer Vielzahl von folgenden Noten, die von dem Schiebefenster empfangen werden, um eine statistische Eigenschaft der ersten Musiknote entsprechend einem statistischen Modell zu bestimmen; Platzieren der ersten Musiknote, die von dem Schiebefenster empfangen wird, in einem Verzeichnis (102) als ein Verzeichniseintrag, wenn die Musiknote die statistische Eigenschaft entsprechend dem Modell aufweist; und Speichern eines Index für den Verzeichniseintrag in dem Befehlsteil (C1–C3), dadurch gekennzeichnet, dass, bevor die Musiknote in das Verzeichnis (102) geschoben wird, der Befehlsdatenerzeuger (100) auf die Verzeichniseinträge verweist und die Musiknote in einen Befehls-Daten-Paar, bestehend aus einem Befehlsteil (C1–C3) und einem Datenteil (D1, D2) codiert.
Verfahren nach Anspruch 7, ferner umfassend: Herausfinden eines Unterschiedes zwischen einer Musiknote und einem bestehenden Verzeichniseintrag in dem Verzeichnis (102); und Speichern des Unterschiedes in dem Datenteil (D1, D2) der komprimierten Daten.
Verfahren nach Anspruch 7, ferner umfassend: Platzieren einer Aktualisierungskennung in dem Befehlsteil (C1–C3), wenn bestimmt ist, dass die Musiknote die statistische Eigenschaft aufweist.
Daten-Dekomprimierer zum Dekomprimieren komprimierter Daten in Lieddaten, wobei die komprimierten Daten einen Index zum Kennzeichnen eines indizierten Verzeichniseintrags in einem Verzeichnis (102), eine erste Kennzeichnung, zum Kennzeichnen, ob Veränderungen des indizierten Verzeichniseintrags benötigt wird, eine zweite Kennzeichnung zum Kennzeichnen, ob eine Aktualisierung des Verzeichnisses (102) benötigt wird, einen Datenteil (D1, D2) zum Verändern des indizierten Verzeichniseintrages umfassen, wobei der Daten-Dekomprimierer umfasst: ein Verzeichnis (102) mit einer ersten Vielzahl von Verzeichniseinträgen; und einen Decodierer, der so ausgestaltet ist, dass er den indizierten Verzeichniseintrag von dem Verzeichnis (102) gemäß dem Index in den komprimierten Daten auswählt, dadurch gekennzeichnet, dass eine Abänderung des indizierten Verzeichniseintrags durch Ersetzen einzelner im Datenteil (D1, D2) gekennzeichneter Datenbytes erfolgt, und dass eine Musiknote, welche einer vordefinierten Anzahl von Musiknoten in dem Schiebefenster (104) ähnelt, in das Verzeichnis (102) geschoben wird.
Daten-Dekomprimierer nach Anspruch 10, dadurch gekennzeichnet, dass der Decodierer so ausgestaltet ist, dass er den indizierten Verzeichniseintrag in eine decodierte Musiknote verändert, wenn die erste Kennzeichnung zeigt, dass die Veränderung benötigt wird.
Daten-Dekomprimierer nach Anspruch 11, dadurch gekennzeichnet, dass der Decodierer so ausgestaltet ist, dass er den indizierten Verzeichniseintrag gemäß dem Datenteil (D1, D2) in den komprimierten Daten verändert.
Daten-Dekomprimierer nach Anspruch 12, dadurch gekennzeichnet, dass der Decodierer so ausgestaltet ist, dass er das Verzeichnis (102) durch die decodierte Musiknote aktualisiert, wenn die zweite Kennzeichnung anzeigt, dass die Aktualisierung benötigt wird.
Daten-Dekomprimierer nach Anspruch 10, dadurch gekennzeichnet, dass die Zahl der Einträge in das Verzeichnis (102) gleich einer ganzzahligen Potenz von „2” ist.
Daten-Dekomprimierer nach Anspruch 10, dadurch gekennzeichnet, dass das Verzeichnis (102) ein Erster-rein-Erster-raus-Schiebefenster umfasst.
Verfahren zum Dekomprimieren komprimierter Daten in Lieddaten, bei dem die komprimierten Daten einen Index zur Kennzeichnung eines indizierten Verzeichniseintrags in einem Verzeichnis (102), eine erste Kennzeichnung zur Kennzeichnung einer Veränderung eines indizierten Verzeichniseintrages, eine zweite Kennzeichnung zur Kennzeichnung einer Aktualisierung des Verzeichnisses (102), einen Datenteil (D1, D2) zur Veränderung des indizierten Verzeichniseintrages umfassen, wobei das Verfahren umfasst: Lesen komprimierter Daten; Auffinden eines indizierten Verzeichniseintrages in dem Verzeichnis (102) gemäß dem Index; dadurch gekennzeichnet, dass entweder der indizierte Verzeichniseintrag als eine decodierte Musiknote verwendet wird, wenn die erste Kennzeichnung anzeigt, dass keine Veränderung benötigt wird, oder ansonsten der indizierte Verzeichniseintrag durch Ersetzen einzelner im Datenteil (D1, D2) gekennzeichneter Datenbytes abgeändert wird, und dass eine Musiknote, welche einer vordefinierten Anzahl von Musiknoten in dem Schiebefenster (104) ähnelt, in das Verzeichnis (102) geschoben wird
Verfahren nach Anspruch 16, ferner gekennzeichnet durch Verändern des indizierten Verzeichniseintrages durch den Datenteil (D1, D2), um eine decodierte Musiknote zu erhalten, wenn die erste Kennzeichnung anzeigt, dass eine Veränderung benötigt wird.
Verfahren nach Anspruch 17, ferner gekennzeichnet durch Platzieren der decodierten Musiknote in dem Verzeichnis (102), wenn die zweite Kennzeichnung anzeigt, dass eine Aktualisierung des Verzeichnisses (102) benötigt wird.
Verfahren nach Anspruch 17, dadurch gekennzeichnet, dass der Datenteil (D1, D2) ein erstes Datenfeld zum Speichern einer Veränderungseinstellung für den indizierten Verzeichniseintrag und ein zweites Datenfeld zum Speichern wenigstens eines Datensegmentes umfasst, dadurch gekennzeichnet, dass eine decodierte Note ein Datensegment des zweiten Datenfeldes, das durch einen Bereich des indizierten Verzeichniseintrages, der durch das erste Datenfeld gekennzeichnet ist, ersetzt wurde, umfasst.
Verfahren nach Anspruch 19, dadurch gekennzeichnet, dass das Verzeichnis (102) konfiguriert ist, dass es die decodierte Musiknote empfängt, wenn die zweite Kennzeichnung zeigt, dass eine Aktualisierung des Verzeichnisses (102) benötigt wird.
Verfahren nach Anspruch 20, dadurch gekennzeichnet, dass, wenn ein Element in dem ersten Datenfeld einen binären Wert von „1” aufweist, ein entsprechender Datenbereich des indizierten Verzeichniseintrages konfiguriert ist, dass er durch ein Datensegment des zweiten Datenfeldes ersetzt wird, welches durch das Element gekennzeichnet ist.
Verfahren nach Anspruch 21, dadurch gekennzeichnet, dass, wenn ein Element in dem ersten Datenfeld einen binären Wert von „0” aufweist, ein entsprechender Bereich des indizierten Verzeichniseintrages unverändert verbleibt.