Bei einer monochromen Fläche innerhalb des 8x8-Ausschnits sind keine Schwingungskoeffizienten in der DCT-Matrix vorhanden. Nur ein Farbintensitätswert (999) für den jeweiligen Kanal ist gegeben.

Bei Betrachtung eines senkrechten Streifens innerhalb des Ausschnitts ist zu erahnen wie die DCT-Matrix funktioniert. Die erste Zeile der Matrix beschreibt nun die Intensität des Kanals und die Grundschwingung sowie ihre Oberschwingungen.

Bei einer "quasi zufälligen" Anordnung der Bildpunkte im Bildausschnitt wird deutlich, dass das DCT-Verfahren hier nicht viel machen kann. Beide Matritzen sind "informationsbeladen".

Programmiertechnisch dürfte die Umsetzung dieses Verfahrens nicht sonderlich schwierig sein. Die Matritzen können durch zweidimensionale Arrays vom Typ int (DCT-Matrix) und vom Typ char (Farbanteil-Matrix) repräsentiert werden. Die eigentliche Transformationsfunktion lässt sich auch einfach durch zwei geschachtelte Zählschleifen realisieren.

Kontrolle im Applet:

Kompressionsverfahren: Ogg Vorbis
Qualitätsstufe (fixed Bitrate): 4
Ursprüngliche Dateigröße: 158654 Bytes
Komprimierte Dateigröße: 18587 Bytes (~85% Einsparung)

Die Datei besteht aus einzelnen Einheiten, die Pages genannt werden. Jede Page ist folgendermaßen aufgebaut:

Offset 0x00, Länge 4 Byte - Capture Pattern

Jede Page beginnt mit der Sequenz "OggS". (dient unter anderem dafür dass ein Parser sich in einem abgeschnittenen Datenstrom wieder synchronisieren kann)

Offset 0x04, Länge 1 Byte - Version

Für zukünftige Versionen. Bisher noch unbenutzt und laut Standard auf 00 gesetzt.

Offset 0x05, Länge 1 Byte - Header Type

Ein Flag-Feld, welches beschreibt ob wir uns am Anfang, Ende oder mitten in einem Bitstream befinden.

Offset 0x06, Länge 8 Byte - Granule Position

Zeitmarker, der vom Codec bestimmt wird.

Offset 0x0E, Länge 4 Byte - Bitstream Serial Number

Eindeutiger Wert um die zugehörigkeit zu einem logischen Bitstream zu gewähren.

Offset 0x12, Länge 4 Byte - Page Sequence Number

Feld, dass einen Zähler für Segmente des logischen Bitstreams darstellt - hierdurch kann zB festgestellt werden ob Segmente verloren gegangen sind beim Transport.

Offset 0x16, Länge 4 Byte - Checksum

Prüfsummenfeld für die gesamte Page.

Offset 0x1A, Länge 1 Byte - Page Segments

Feld zur Indizierung wieviele Segmente in der Page vorhanden sind.

Offset 0x1B, Länge variable - Segment Table und Page Body

Vektor für die Segmente und eigentliche Nutzdaten. In dem Screenshot ist auch zu erkennen dass hinter dem Body wieder eine neue Page folgt (erkennbar an dem Capture Pattern "OggS").

Metadaten in MP3-Dateien

ID3v1 (Identifier on MP3)

Frühes Taggingsystem, 1996 von Eric Kemp eingeführt.
Metadaten wurden an das Ende der Datei angefügt um zu verhinder, dass alte Player diese als Audioinformation interpretieren.

Block von 128 Byte Größe mit festem Aufbau:

Offset 0x00 - Länge 3 - Marker


Offset 0x03 - Länge 30 - Title


Offset 0x21 - Länge 30 - Artist


Offset 0x3F - Länge 30 - Album


Offset 0x5D - Länge 4 - Year


Offset 0x61 - Länge 30 - Comment


Offset 0x7F - Länge 1 - Genre

siehe: http://de.wikipedia.org/wiki/Liste_der_ID3-Genres

ID3v2:
Neu entworfene Version von Martin Nilson. Mitlerweile sind die Versionen ID3v2.1, ID3v2.2 und ID3v2.4 bekannt.
Aufhebung der Beschränkung auf maximal 30 Zeichen je Datenfeld. Zudem wurden neue Datenfelder eingeführt, wie auch eine Möglichkeit der Festlegung wie diese Felder codiert sind (bspw. UTF8).
Können mitlerweile mitten in den Stream eingefügt werden.

Metadaten in AAC-Dateien.

AAC-Daten werden in einem MPEG4-Container untergebracht. Dort sind Nutzinformationen als sog. Atome innerhalb eines hiearchichen Baumes untergebracht. Für Metadaten existiert kein Standard wie sie in diesem Container platziert sind. Die Industrie versucht jedoch ihre eigenen Formate dafür zu etablieren - allen voran Apple mit Musikstücken aus ihrem iTunes-Store.
Es existiert ein Open-Source-Projekt, welches versucht diese Metadaten zu analysieren und zu verstehen:

Siehe: http://sourceforge.net/projects/atomicparsley

ID3v1	ID3v2
MPEG4