update 223015b chapter 1: content fixes, expand speaker notes with abbreviations
- endnutzer -> endnutzerInnen, fix lossy reversibility wording - add tar to deflate examples, reword shannon-limit - expand kompression-vertiefung speaker notes: lz77/lz78/deflate/tar explained - resolve all abbreviations in speaker notes (cmyk, rgb, css, html, http, smtp, url, cjk, utf-8, si, iec, iot, lto, ssd, hdd, ecc, raid, vhs, fft, jpeg, aac, riaa, foss, iis, rle) - minor slide fixes: hex examples, byte value, wording improvements
This commit is contained in:
@@ -282,12 +282,12 @@ Sondern gezielt das entfernen, was Menschen nicht wahrnehmen.
|
||||
| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
|
||||
|---|---|---|
|
||||
| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
|
||||
| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich weg) |
|
||||
| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich verloren) |
|
||||
| **Reduktion** | 30-50% | 80-99% |
|
||||
| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
|
||||
|
||||
**Faustregel:**
|
||||
- Medien für Endnutzer → Lossy oft akzeptabel
|
||||
- Medien für EndnutzerInnen → Lossy oft akzeptabel
|
||||
- Quellmaterial, Code, Archive → Lossless nötig
|
||||
|
||||
<!--
|
||||
@@ -312,7 +312,7 @@ Claude Shannon definierte 1948 die **Entropie** als theoretische Untergrenze der
|
||||
|
||||
**Verlustfreie Kompression** erreicht diese Grenze durch:
|
||||
- **Statistische Kodierung:** Huffman, Arithmetic Coding
|
||||
- **Wörterbuch-Methoden:** LZ77, LZ78, DEFLATE (ZIP, PNG)
|
||||
- **Wörterbuch-Methoden:** LZ77, LZ78, DEFLATE (ZIP, PNG, TAR)
|
||||
- Originalzustand ist exakt rekonstruierbar
|
||||
|
||||
**Verlustbehaftete Kompression** unterschreitet die Grenze, indem sie menschliche Wahrnehmungsgrenzen ausnutzt:
|
||||
@@ -322,7 +322,32 @@ Claude Shannon definierte 1948 die **Entropie** als theoretische Untergrenze der
|
||||
| Gehör | Maskierungseffekte, Hörschwelle | MP3: Töne unter Maskierungsschwelle weglassen |
|
||||
| Sehen | Farbauflösung, Kontrastempfindlichkeit | JPEG: Chroma-Subsampling, hohe Frequenzen verwerfen |
|
||||
|
||||
**Shannon-Limit:** Verlustfreie Kompression kann nicht unter die Entropie; verlustbehaftete kann beliebig weit gehen – auf Kosten der Qualität.
|
||||
**Shannon-Limit:** Verlustfreie Kompression ist durch Entropie begrenzt; Verlustbehaftete Kompression kann beliebig weit gehen – auf Kosten der Qualität.
|
||||
|
||||
<!--
|
||||
ABKÜRZUNGEN:
|
||||
- LZ = Lempel-Ziv (nach Abraham Lempel und Jacob Ziv)
|
||||
- LZ77 = Lempel-Ziv 1977 – Sliding-Window-Verfahren: sucht Wiederholungen in einem Fenster der letzten Bytes und ersetzt sie durch Rückverweise (Offset + Länge)
|
||||
- LZ78 = Lempel-Ziv 1978 – baut ein explizites Wörterbuch auf: neue Muster bekommen einen Index, Wiederholungen werden durch den Index ersetzt
|
||||
- DEFLATE = Kombination aus LZ77 + Huffman-Coding; verwendet in ZIP, PNG und gzip
|
||||
- TAR = Tape ARchive – kein Kompressionsformat, sondern ein Archivformat (bündelt Dateien zu einer). Kompression erst durch Kombination: .tar.gz (gzip = DEFLATE), .tar.bz2 (bzip2), .tar.xz (LZMA)
|
||||
- ZIP = Archivformat mit eingebauter DEFLATE-Kompression (Phil Katz, 1989)
|
||||
- PNG = Portable Network Graphics – nutzt DEFLATE für verlustfreie Bildkompression
|
||||
|
||||
STATISTISCHE KODIERUNG:
|
||||
- Huffman-Coding: Häufige Zeichen bekommen kurze Bitfolgen, seltene Zeichen lange. Beispiel: 'e' (häufig) → 2 Bit, 'q' (selten) → 8 Bit
|
||||
- Arithmetic Coding: Kodiert die gesamte Nachricht als einzelne Zahl zwischen 0 und 1. Etwas effizienter als Huffman, aber rechenintensiver
|
||||
|
||||
ENTROPIE (Shannon):
|
||||
- Maß für den Informationsgehalt: Wie "überraschend" ist jedes Zeichen?
|
||||
- Hohe Entropie = schwer komprimierbar (z.B. verschlüsselte Daten, Rauschen)
|
||||
- Niedrige Entropie = gut komprimierbar (z.B. "AAAAAAA" oder natürliche Sprache)
|
||||
- Theoretisches Minimum: kein Algorithmus kann unter die Entropie-Grenze kommen
|
||||
|
||||
PRAXISBEISPIEL:
|
||||
- ZIP einer .txt-Datei: ~60-70% kleiner (Text hat niedrige Entropie)
|
||||
- ZIP einer .jpg-Datei: kaum kleiner (JPEG hat Entropie schon ausgereizt)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
@@ -400,11 +425,15 @@ BYTE = Wortspiel aus "Bit" + "Bite" (Bissen) – ein "Bissen" Information
|
||||
**1 Byte = 8 Bits**
|
||||
|
||||
```
|
||||
0 1 0 0 1 1 0 1
|
||||
0 0 1 0 1 0 1 0
|
||||
```
|
||||
|
||||
<!--
|
||||
|
||||
|
||||
binary 00101010
|
||||
= decimal 42
|
||||
|
||||
Rätsel: "Wenn sich das Wachstum einer Seerose auf einem Teich jeden Tag verdoppelt · und nach *zehn Tagen* der ganze Teich bedeckt ist, wann ist er zur Hälfte zugewachsen?"
|
||||
|
||||
Frage: "Weiß jemand wieviele Zustände wir mit 8 Bit beschreiben können?"
|
||||
@@ -500,8 +529,8 @@ Das menschliche Auge kann etwa 10 Millionen Farben unterscheiden
|
||||
<!--
|
||||
Welche Farben für ein volles Spektrum bieten sich nach unserer gelernten Sparsamkeit hier am besten an?
|
||||
|
||||
1. CMYK bzw. in diesem Fall CMYW
|
||||
2. RGB
|
||||
1. CMYK (Cyan, Magenta, Yellow, Key/Black) bzw. in diesem Fall CMYW (Cyan, Magenta, Yellow, White)
|
||||
2. RGB (Red, Green, Blue)
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -539,11 +568,11 @@ Sog. RGB Tuple (geordnete endliche Liste)
|
||||
<!--
|
||||
"Weiß jemand oder möchte jemand raten, wofür das "s" bei "sRGB" steht?"
|
||||
|
||||
sRGB = Standard RGB
|
||||
CMYK = Subtraktive Farbmischung (Druck)
|
||||
sRGB = Standard RGB (Red, Green, Blue)
|
||||
CMYK = Cyan, Magenta, Yellow, Key (Black) – Subtraktive Farbmischung (Druck)
|
||||
Hex-Notation: FF = 255 in Dezimal
|
||||
CSS-Farben nutzen Hex: #FF0000 = Rot
|
||||
Wer HTML/CSS gemacht hat, kennt das schon!
|
||||
CSS (Cascading Style Sheets)-Farben nutzen Hex: #FF0000 = Rot
|
||||
Wer HTML (HyperText Markup Language)/CSS gemacht hat, kennt das schon!
|
||||
background-color: #FF0000; = Rot
|
||||
-->
|
||||
|
||||
@@ -564,11 +593,9 @@ background-color: #FF0000; = Rot
|
||||
- + Ziffern: 10 (0-9)
|
||||
- + Sonderzeichen: ~30
|
||||
|
||||
**≈ 90 Zeichen → passt in 1 Byte**
|
||||
**≈ 90 Zeichen passen problem in 1 Byte**
|
||||
|
||||
**Aber:** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 😀
|
||||
|
||||
→ **1 Byte reicht nicht!**
|
||||
**Jedoch ohne** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 😀
|
||||
|
||||
<!--
|
||||
Problem der Zeichenkodierung
|
||||
@@ -644,7 +671,7 @@ Hinweis: は wird hier "wa" ausgesprochen (Partikel), nicht "ha"
|
||||
|
||||
# Hexadezimal: Lesbarkeit
|
||||
|
||||
**Binär ist unleserlich:**
|
||||
**Für den Menschen ungeeignet:**
|
||||
`01010000 01001110 01000111`
|
||||
|
||||
**Hexadezimal (Base 16):**
|
||||
@@ -653,12 +680,17 @@ Hinweis: は wird hier "wa" ausgesprochen (Partikel), nicht "ha"
|
||||
**Jede Hex-Ziffer = 4 Bits (ein "Nibble")**
|
||||
0-9, A-F (10=A, 11=B, ..., 15=F)
|
||||
|
||||
`5 = 0101` `0 = 0000`
|
||||
`4 = 0100` `E = 1110`
|
||||
`4 = 0100` `7 = 0111`
|
||||
|
||||
**ASCII Tabelle (0-127):**
|
||||
[https://www.asciitable.com](https://www.asciitable.com)
|
||||
|
||||
<!--
|
||||
|
||||
"Gerne vorab auf den Link gehen"
|
||||
Dezimalsystem passt nur umständlich 0->15 (1111) ins binäre System
|
||||
Hexadezimal (16) passt perfekt
|
||||
|
||||
WICHTIG: ASCII geht nur von 0-127!
|
||||
- Werte 128-255 sind NICHT in der ASCII-Tabelle
|
||||
@@ -702,12 +734,12 @@ KULTURHISTORISCHER KONTEXT:
|
||||
- "American Standard Code for Information Interchange" (1963)
|
||||
- Entwickelt für US-amerikanische Bedürfnisse
|
||||
- Keine Unterstützung für: Umlaute (ä, ö, ü), ß, diakritische Zeichen (é, ñ, ç)
|
||||
- Nicht-lateinische Schriftsysteme (Kyrillisch, Arabisch, CJK) wurden nicht berücksichtigt
|
||||
- Nicht-lateinische Schriftsysteme (Kyrillisch, Arabisch, CJK = Chinese, Japanese, Korean) wurden nicht berücksichtigt
|
||||
- Führte zu zahlreichen inkompatiblen Erweiterungen (ISO-8859-1, Windows-1252, etc.)
|
||||
|
||||
WARUM NOCH HEUTE RELEVANT?
|
||||
- Abwärtskompatibilität: UTF-8 ist vollständig ASCII-kompatibel (Zeichen 0-127 identisch)
|
||||
- Internetprotokolle basieren auf ASCII: HTTP-Header, SMTP, URLs
|
||||
- Abwärtskompatibilität: UTF-8 (Unicode Transformation Format, 8-bit) ist vollständig ASCII-kompatibel (Zeichen 0-127 identisch)
|
||||
- Internetprotokolle basieren auf ASCII: HTTP (HyperText Transfer Protocol)-Header, SMTP (Simple Mail Transfer Protocol), URLs (Uniform Resource Locator)
|
||||
- Programmiersprachen: Schlüsselwörter und Syntax sind ASCII
|
||||
- Ein 60 Jahre alter Standard, der durch Kompatibilitätszwänge fortbesteht
|
||||
|
||||
@@ -770,7 +802,7 @@ US-ASCII (1967) Code Chart
|
||||
| `0100 1110` | `4E` | 78 | **N** |
|
||||
| `0100 0111` | `47` | 71 | **G** |
|
||||
|
||||
→ **PNG**-Signatur! (Das `89` markiert: "Ich bin binär, kein Text!")
|
||||
→ `89` übersteigt den ASCII-Raum und markiert eie Binärdatei
|
||||
|
||||
<!--
|
||||
Hex = 2 Ziffern = 1 Byte = 8 Bit
|
||||
@@ -853,7 +885,7 @@ WARUM nutzt PNG absichtlich 89 (= 137 dezimal)?
|
||||
Geschichte: "PK" bei ZIP = Phil Katz (Erfinder von PKZip, 1989)
|
||||
Fun Fact: DOCX, XLSX, PPTX, ODT = alles ZIP-Archive mit XML-Inhalt!
|
||||
|
||||
Dateien OHNE Magic Number: TXT, HTML, CSS, JSON, XML
|
||||
Dateien OHNE Magic Number: TXT, HTML (HyperText Markup Language), CSS (Cascading Style Sheets), JSON (JavaScript Object Notation), XML (Extensible Markup Language)
|
||||
→ Reiner Text, kein binäres Format
|
||||
|
||||
Sicherheits-Aspekt:
|
||||
@@ -882,8 +914,8 @@ Windows vertraut der Endung, aber "file" (Linux) liest Magic Number
|
||||
| **Zettabyte (ZB)** | 1 Trilliarde | 10²¹ | Internet-Traffic 2016 |
|
||||
|
||||
<!--
|
||||
SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes
|
||||
Binär (IEC): 1 KiB = 1.024 Bytes (Kibibyte)
|
||||
SI (Système International d'Unités)-Präfixe (Dezimal): 1 KB = 1.000 Bytes
|
||||
Binär (IEC = International Electrotechnical Commission): 1 KiB = 1.024 Bytes (Kibibyte)
|
||||
Windows zeigt oft binär, sagt aber "KB" → Verwirrung!
|
||||
1 TB Festplatte = ~931 GiB nutzbar
|
||||
|
||||
@@ -974,9 +1006,9 @@ ANALOG damals: Bücher, Zeitungen, Vinyl, VHS, Filmrollen, Fotos
|
||||
|
||||
DIGITAL damals: Festplatten, CDs, DVDs, frühe Flash-Speicher
|
||||
|
||||
HEUTE: LTO-9 (2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
|
||||
HEUTE: LTO-9 (LTO = Linear Tape-Open, 2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
|
||||
|
||||
VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
|
||||
VERGLEICH: SSD (Solid State Drive) ~$50/TB, HDD (Hard Disk Drive) ~$15/TB, LTO ~$5/TB
|
||||
|
||||
-->
|
||||
|
||||
@@ -1032,7 +1064,7 @@ AWS Glacier, Google Coldline und Film-Archive nutzen LTO – langsamer Zugriff,
|
||||
|
||||
<!--
|
||||
Quellen: IDC Global DataSphere Forecast, Statista 2025
|
||||
IoT-Geräte allein: 73 ZB in 2025
|
||||
IoT (Internet of Things)-Geräte allein: 73 ZB in 2025
|
||||
Cloud-Speicher: 100 ZB (50% der Weltdaten)
|
||||
Prognose 2028: 394 ZB
|
||||
-->
|
||||
@@ -1145,7 +1177,7 @@ Analoge Speicherung codiert Information als **kontinuierliche physikalische Grö
|
||||
<!--
|
||||
GENERATIONSVERLUST:
|
||||
Kassette → Kassette = jede Kopie schlechter
|
||||
VHS → VHS = Rauschen nimmt zu
|
||||
VHS (Video Home System) → VHS = Rauschen nimmt zu
|
||||
Schallplatte: Jedes Abspielen = minimaler Verschleiß
|
||||
|
||||
ABER: Analoges Original bleibt "das Original"
|
||||
@@ -1216,7 +1248,7 @@ Digitale Speicherung quantisiert kontinuierliche Signale in diskrete Werte. Der
|
||||
|--------|--------|---------|
|
||||
| Kopiervorgang | Physikalischer Prozess | Bit-Kopie |
|
||||
| Qualität pro Generation | Verschlechtert | Identisch |
|
||||
| Fehlerkorrektur | Unmöglich | Möglich (ECC, RAID) |
|
||||
| Fehlerkorrektur | Unmöglich | Möglich (ECC = Error Correcting Code, RAID = Redundant Array of Independent Disks) |
|
||||
| Formatmigration | Verlust | Verlustfrei möglich |
|
||||
|
||||
**Die Kehrseite:** Digitale Obsoleszenz. Ein DOCX von 2025 ist in 50 Jahren womöglich unlesbar – während ein Buch von 1525 heute noch lesbar ist. Offene Formate (PDF/A, FLAC, PNG) mildern dieses Risiko.
|
||||
@@ -1507,7 +1539,7 @@ Patent lief 2017 aus
|
||||
- Forschung ab 1982, Patent 1988
|
||||
|
||||
<!--
|
||||
Fraunhofer IIS Erlangen
|
||||
Fraunhofer IIS (Institut für Integrierte Schaltungen) Erlangen
|
||||
Forschung dauerte über 10 Jahre
|
||||
Perfektionist: Jeder Hörtest musste bestehen
|
||||
-->
|
||||
@@ -1574,7 +1606,7 @@ Ein Zusammenspiel aus vielen Faktoren:
|
||||
<!--
|
||||
MP3-Kompression in 4 Schritten (vereinfacht):
|
||||
|
||||
1. FFT (Fast Fourier Transform)
|
||||
1. FFT (Fast Fourier Transform = Schnelle Fourier-Transformation)
|
||||
- Wandelt Schallwellen in Frequenzen um
|
||||
- Wie ein Prisma Licht in Farben zerlegt
|
||||
|
||||
@@ -1586,7 +1618,7 @@ MP3-Kompression in 4 Schritten (vereinfacht):
|
||||
3. Quantisierung (hier passiert der Datenverlust!)
|
||||
- Unwichtige Frequenzen werden "grob" gespeichert
|
||||
- Wichtige Frequenzen bleiben genau
|
||||
- Wie JPEG: Details entfernen, wo es nicht auffällt (Kontrast/Helligkeit bleibt)
|
||||
- Wie JPEG (Joint Photographic Experts Group): Details entfernen, wo es nicht auffällt (Kontrast/Helligkeit bleibt)
|
||||
|
||||
4. Huffman-Coding (verlustfrei)
|
||||
- Häufige Muster = kurze Codes
|
||||
@@ -1659,7 +1691,7 @@ KERNKONZEPT: Kompression = Modell der menschlichen Wahrnehmung
|
||||
**Prinzip:** Wiederholungen zählen statt wiederholen
|
||||
|
||||
<!--
|
||||
RLE = Run-Length Encoding = Lauflängenkodierung
|
||||
RLE = Run-Length Encoding (Lauflängenkodierung)
|
||||
Einfachster Kompressionsalgorithmus
|
||||
Gut für: Fax, einfache Grafiken, Icons
|
||||
Schlecht für: Fotos, Audio (zu chaotisch)
|
||||
@@ -1684,7 +1716,7 @@ Schlecht für: Fotos, Audio (zu chaotisch)
|
||||
Fraunhofer verklagte Winamp, andere Tools
|
||||
Millionen nutzten unlizenzierte Software
|
||||
Das Pferd war aus dem Stall
|
||||
2017: Fraunhofer selbst erklärte MP3 für "veraltet" (AAC besser)
|
||||
2017: Fraunhofer selbst erklärte MP3 für "veraltet" (AAC = Advanced Audio Coding, besser)
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -1727,7 +1759,7 @@ Aber: LimeWire, Kazaa, BitTorrent folgten
|
||||
→ LimeWire, Kazaa, BitTorrent, später Spotify
|
||||
|
||||
<!--
|
||||
RIAA (Recording Industry Association of America) verklagte Napster
|
||||
RIAA = Recording Industry Association of America – verklagte Napster
|
||||
Urteil: Napster muss schließen (2001)
|
||||
Aber: Technologie nicht mehr aufzuhalten
|
||||
iPod (2001): "1.000 songs in your pocket"
|
||||
@@ -1795,7 +1827,7 @@ Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
|
||||
- Spektrogramme vergleichen Audacity (kostenloser Download nötig) [https://manual.audacityteam.org/man/spectrogram_view.html](https://manual.audacityteam.org/man/spectrogram_view.html)
|
||||
|
||||
<!--
|
||||
Audacity: FOSS Audio-Editor (audacityteam.org)
|
||||
Audacity: FOSS (Free and Open-Source Software) Audio-Editor (audacityteam.org)
|
||||
Export: Datei → Exportieren → MP3 → Bitrate wählen
|
||||
Spektrogramm-Ansicht: Auf Track-Name klicken (Dropdown öffnet sich) → "Spektrogramm" wählen
|
||||
Hohe Frequenzen (oben im Bild) verschwinden bei niedriger Bitrate
|
||||
|
||||
Reference in New Issue
Block a user