diff --git a/slides/223015b/klausurfolien.md b/slides/223015b/klausurfolien.md
index 1f509a0..feabcd0 100644
--- a/slides/223015b/klausurfolien.md
+++ b/slides/223015b/klausurfolien.md
@@ -104,27 +104,26 @@ Hochschule der Medien Stuttgart
 <!-- _footer: "" -->
 
 
-# Verlustfrei vs. Verlustbehaftet
+# Hex begegnet euch überall
 
-| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
-|---|---|---|
-| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
-| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich weg) |
-| **Reduktion** | 30-50% | 80-99% |
-| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
-
-**Faustregel:**
-- Medien für EndnutzerInnen → Lossy oft akzeptabel
-- Quellmaterial, Code, Archive → Lossless nötig
+| Kontext | Beispiel |
+|---------|----------|
+| CSS-Farben | `#FF5733` |
+| MAC-Adressen | `00:1A:2B:3C:4D:5E` |
+| Speicheradressen | `0xA04F20` |
+| Windows-Fehlercodes | `0x80070005` |
+| Unicode-Codepoints | `U+00E4` (ä) |
+| Datei-Signaturen | `89 50 4E 47` (PNG) |
 
 <!--
-REDUNDANZ: Wiederholende Muster kompakter darstellen (z.B. "AAAA" → "4×A")
-IRRELEVANZ: Für Menschen nicht wahrnehmbar (Psychoakustik, Psychovisuell)
+Präfixe:
+- `0x` = "das ist Hex" (in C, JS, Python)
+- `U+` = Unicode-Codepoint
+- `#` = CSS-Konvention
 
-KLAUSURRELEVANT:
-- Verlustfrei = Original 1:1 wiederherstellbar
-- Verlustbehaftet = Information geht verloren, aber kaum wahrnehmbar
-- Redundanz vs. Irrelevanz ist der Kernunterschied!
+Lebensweltanker: jede:r Studi hat mindestens drei dieser Kontexte schon real gesehen. Hex ist nicht eine akademische Übung, sondern die Lesart, in der Computer mit Menschen über Byte reden.
+
+MAC-Adresse: 6 Byte = 6 Paare Hex-Ziffern. Eindeutige Hardware-Kennung der Netzwerkkarte.
 -->
 
 
@@ -134,27 +133,29 @@ KLAUSURRELEVANT:
 <!-- _footer: "" -->
 
 
-# Dateneinheiten
+# Beispiel: Byte zählen
 
-| Einheit | Bytes | Potenz | Beispiel |
-|---------|------:|:------:|----------|
-| **Byte** | 1 | 10⁰ | Farbwerte eines Pixels |
-| **Kilobyte (KB)** | 1.000 | 10³ | Kleiner Programmcode |
-| **Megabyte (MB)** | 1 Million | 10⁶ | Textdokument |
-| **Gigabyte (GB)** | 1 Milliarde | 10⁹ | Kinofilm in FullHD |
-| **Terabyte (TB)** | 1 Billion | 10¹² | ~12h Video in 4K |
-| **Petabyte (PB)** | 1 Billiarde | 10¹⁵ | Netflix-Gesamtarchiv |
-| **Exabyte (EB)** | 1 Trillion | 10¹⁸ | Alle E-Mails weltweit/Tag |
-| **Zettabyte (ZB)** | 1 Trilliarde | 10²¹ | Internet-Traffic 2016 |
+**Text:** `"Hello·🌸·こんにちは·(Kon-ni-chi-wa)"`
+
+| Zeichen | Byte |
+|---------|-------|
+| `Hello·` | 6 × 1 = **6 Byte** (ASCII) |
+| `🌸` | **4 Byte** (Emoji) |
+| `·` | **1 Byte** |
+| `こんにちは` | 5 × 3 = **15 Byte** (Hiragana) |
+| `·(Kon-ni-chi-wa)` | **16 Byte** (ASCII) |
+
+**Gesamt: 42 Byte für 29 sichtbare Zeichen.**
 
 <!--
-SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes
-Binär (IEC): 1 KiB = 1.024 Bytes (Kibibyte)
-Windows zeigt oft binär, sagt aber "KB" → Verwirrung!
-1 TB Festplatte = ~931 GiB nutzbar
+Klausurfähig: gegeben ein Text mit ASCII, Umlauten, CJK und Emoji — wie viel Byte ist das?
 
-Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
-→ "Komm Mit Großem Tee, Peter Exte Zettelt Yachten"
+- ASCII (Hello, Klammern) = 1 Byte pro Zeichen
+- Emoji 🌸 (Cherry Blossom U+1F338) = 4 Byte
+- Hiragana こんにちは = 3 Byte pro Zeichen (U+3040–309F)
+- は wird hier „wa" ausgesprochen (Partikel), nicht „ha"
+
+Pointe: 29 sichtbare Zeichen, 42 Byte. Zeichen ≠ Byte sobald Unicode > 127.
 -->
 
 
@@ -164,41 +165,25 @@ Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
 <!-- _footer: "" -->
 
 
-# Der digitale Wendepunkt
+# Magic Numbers — die Visitenkarte der Datei
 
-| Jahr | Analog | Digital | Digital-Anteil |
-|------|--------|---------|----------------|
-| **1986** | 2,6 EB | 0,02 EB | **1%** |
-| **2002** | — | — | **50%** (Wendepunkt) |
-| **2007** | 18 EB | 277 EB | **94%** |
+**Datei-Typ erkennt man an den ersten Byte:**
 
-**Perspektive:**
-- 1986: "Petabyte" war ein theoretisches Konzept
-- 2025: ~181 Zettabyte jährlich produziert
+| Format | Magic Number (Hex) | Lesbar? |
+|--------|-------------------|---------|
+| PNG | `89 50 4E 47` | (89 außerhalb ASCII) P N G |
+| JPEG | `FF D8 FF` | — |
+| PDF | `25 50 44 46` | % P D F |
+| ZIP | `50 4B 03 04` | P K — — |
 
-**Magnetband lebt:** LTO-Tapes bleiben günstigstes Archivmedium
-(AWS Glacier, Film-Archive, Rechenzentren)
+**Achtung:** Werte > 127 sind nicht ASCII-druckbar. *Hex-Editoren zeigen `.` als Platzhalter.*
 
 <!--
-PRÜFUNGSRELEVANT:
- - Wendepunkt 2002
- - Speichereinheiten (KB→MB→GB→TB→PB→EB→ZB)
- - Magnetband als Archivmedium
-
-QUELLE: Hilbert & López (2011): "The World's Technological Capacity to Store, Communicate, and Compute Information", Science
-
-METHODIK: 60 analoge + digitale Technologien untersucht (1986-2007)
-
-WENDEPUNKT 2002: Erstmals mehr digital als analog gespeichert
-
-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
-
-VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
-
+- PNG nutzt absichtlich `89` (= 137 dezimal): markiert Datei eindeutig als Binär. Erkennt kaputte Übertragungen (alte Systeme schnitten Bit 7 ab).
+- "PK" bei ZIP = Phil Katz (Erfinder von PKZip, 1989)
+- DOCX, XLSX, PPTX, ODT = alles ZIP-Archive mit XML-Inhalt
+- Dateien OHNE Magic Number: TXT, HTML, CSS, JSON, XML — reiner Text, kein binäres Format
+- Sicherheitsrelevant: virus.exe → bild.jpg umbenennen täuscht nur Menschen; `file` (Linux) liest Magic Number und erkennt die echte Identität.
 -->
 
 
@@ -208,85 +193,23 @@ VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
 <!-- _footer: "" -->
 
 
-# Analoge Medien
-### Distribution: physisch (Kauf, Verleih, Kopie)
+# KB vs KiB — warum „1 TB" als 931 GB angezeigt wird
 
-- **Text**
-    - Bücher, Zeitungen, Zeitschriften, Lochkarten
-- **Bild**
-    - Fotografie (Negativ, Dia, Polaroid), Mikrofilm
-- **Audio:**
-    - Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
-- **Video:**
-    - Film (35mm, Super 8), VHS, Betamax
+![bg right:48% contain](./assets/demos/kb-vs-kib.png)
 
+**Auf der Verpackung:** 1 TB = 10¹² Byte (dezimal).
+**Im Finder:** 931 GB = eigentlich 931 GiB (binär, 1024³).
 
----
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Digitale Medien
-### Distribution: Datenträger (CD, USB), Download, Streaming, P2P
-
-- **Text**
-    - E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
-- **Bild**
-    - Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
-- **Audio**
-    - Audiodatei (MP3, FLAC, WAV, AAC, OGG)
-- **Video**
-    - Videodatei (MP4, MKV, AVI, WebM)
-
-
----
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Digitale Speichermedien
-
-- **Optische Speicher**
-    - CD, DVD, Blu-ray
-- **Magnetische Speicher**
-    - Festplatte (HDD), Magnetband (LTO)
-- **Flash-Speicher**
-    - SSD, USB-Stick, SD-Karte
-- **Cloud-Speicher**
-    - Dropbox, Google Drive, iCloud, AWS S3
-
-
----
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-
-# Rastergrafiken
-
-**Aufbau:** Liste von Pixeln mit Farbwerten (2D-Array)
-
-**Speicherbedarf (unkomprimiert):**
-Breite × Höhe × Farbtiefe (in Bytes)
-
-**Beispiele:** JPEG, PNG, WebP
-
-| Bits (Farbtiefe) | Farben | Anwendung |
-|-----:|-------:|-----------|
-| 1 | 2 | Schwarz/Weiß (Fax) |
-| 8 | 256 | Graustufen, GIF |
-| 24 | 16,7 Mio. | True Color (Standard) |
-| 32 | 16,7 Mio. + Alpha | Transparenz |
+Es fehlt nichts — beide Seiten zählen nur in **verschiedenen Sprachen.**
 
 <!--
-KLAUSURRELEVANT:
-- Formel: Breite × Höhe × (Farbtiefe / 8) = Bytes
-- Beispielrechnung: 1920 × 1080 × 3 = 6.220.800 Bytes ≈ 6,2 MB
-- Farbtiefe: 2^n Farben bei n Bit
-- 24 Bit = 8 Bit pro Kanal (R, G, B)
-- 32 Bit = 24 Bit + 8 Bit Alpha (Transparenz)
+- Marketing nutzt SI-Präfixe (1000³, 1000⁴) → größere Zahlen auf der Packung.
+- Betriebssysteme rechnen in Zweier-Potenzen (1024³) → kleinere angezeigte Zahl, weil Bits binär organisiert sind.
+- Korrekt wären `GiB` (Gibi-, binär) und `GB` (Giga-, dezimal). Realität: beide nennen es `GB`.
+
+Rechnung: 10¹² ÷ 2³⁰ ≈ 931,3 GiB. Der Finder zeigt „931 GB".
+
+Klausurfähig: warum zeigt eine 1-TB-SSD im Finder „931 GB"? Begründung mit Rechnung.
 -->
 
 
@@ -296,27 +219,59 @@ KLAUSURRELEVANT:
 <!-- _footer: "" -->
 
 
-# Vektorgrafiken
+# Dateneinheiten — Größenordnungen
 
-**Speicherung als geometrische Primitive:**
-- Pfade (Bézierkurven mit Kontrollpunkten)
-- Grundformen (Rechteck, Ellipse, Polygon)
-- Text (Glyphen als Outlines)
+| Einheit | Bytes (dezimal) | Beispiel |
+|---------|------:|----------|
+| **Byte** | 1 | Farbwert eines Pixels |
+| **Kilobyte (KB)** | 1.000 | kleiner Programmcode |
+| **Megabyte (MB)** | 1 Million | Textdokument |
+| **Gigabyte (GB)** | 1 Milliarde | Kinofilm in FullHD |
+| **Terabyte (TB)** | 1 Billion | ~12h Video in 4K |
+| **Petabyte (PB)** | 1 Billiarde | Netflix-Gesamtarchiv |
+| **Exabyte (EB)** | 1 Trillion | Alle E-Mails weltweit/Tag |
+| **Zettabyte (ZB)** | 1 Trilliarde | globale Datenmenge ~heute |
 
-**SVG-Beispiel:**
-```xml
-<circle cx="50" cy="50" r="40" fill="#ff0000"/>
+<!--
+SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes. Auf Packungen, in Marketing.
+IEC-Präfixe (Binär): 1 KiB = 1.024 Bytes (Kibibyte). In Betriebssystemen (oft ohne i geschrieben — Verwechselung!).
+
+Eselsbrücke für die Reihenfolge:
+„**K**omm **M**it **G**roßem **T**ee, **P**eter **E**xte **Z**ettelt **Y**achten."
+→ Kilo, Mega, Giga, Tera, Peta, Exa, Zetta, Yotta.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Datenrate = Sample Rate × Bittiefe × Kanäle
+
+**Formel:**
+
+```
+Datenrate (bit/s) = Sample Rate (Hz) × Bittiefe (bit) × Kanäle
 ```
 
-<small>SVG beschreibt WAS gezeichnet werden soll, nicht WIE jeder Pixel aussieht.</small>
+**Was bestimmt jeder Faktor?**
+
+- **Sample Rate:** Bandbreite (Höhe der erfassbaren Töne)
+- **Bittiefe:** Dynamik (Stufenfeinheit)
+- **Kanäle:** Stereo, Mono, Surround
+
+Daraus ergibt sich, wie groß eine Audiodatei pro Sekunde wird — *unkomprimiert*.
 
 <!--
-KLAUSURRELEVANT:
-- Vektor = Beschreibung (deklarativ)
-- Raster = Pixel für Pixel (imperativ)
-- Rendering-Pipeline: Vektordaten → Rasterisierung → Display
-- Skalierung = Koordinaten multiplizieren → keine Information geht verloren
-- SVG = Scalable Vector Graphics (Web-Standard)
+Wichtige Klausur-Formel.
+
+Anwendungsbeispiel kommt nächste Folie (CD-Audio).
+
+Konsequenz: wenn ich Speicher sparen will, kann ich an einem dieser drei Parametern drehen. ABER: jede Reduktion ist hörbar.
+
+Brücke zu Kap2 (Kompression): da reduzieren wir nicht die Parameter, sondern *werfen unhörbare Information weg* — das ist Psychoakustik, nicht Container-Schrumpfung.
 -->
 
 
@@ -326,25 +281,28 @@ KLAUSURRELEVANT:
 <!-- _footer: "" -->
 
 
-# Die Schwächen des Auges
+# CD-Audio: die Rechnung
 
-**Menschen sehen:**
-- Helligkeit besser als Farbe
-- Große Flächen besser als feine Details
-- Niedrige Frequenzen besser als hohe
+**Audio-CD (Philips/Sony 1982):**
 
-**JPEG nutzt das aus:**
-- Farbauflösung reduzieren (Helligkeit behalten)
-- Glatte Flächen effizient speichern
-- Hohe Frequenzen (feine Details) verwerfen
+```
+44.100 Hz × 16 bit × 2 Kanäle = 1.411.200 bit/s = 1,4 Mbit/s
+```
+
+Pro Sekunde: ~172 KB. Pro Minute: ~10,3 MB. Pro Album (60 Min): ~635 MB.
+
+*Eine ganze 90er-Festplatte für ein Album.*
 
 <!--
-KLAUSURRELEVANT:
-- Mehr Stäbchen (Helligkeit) als Zapfen (Farbe) im Auge
-- "Frequenz" = räumliche Frequenz = wie schnell ändert sich Helligkeit?
-- Niedrig = langsame Änderung = große gleichmäßige Fläche
-- Hoch = schnelle Änderung = feine Details, Kanten
-- Analogie zur Psychoakustik bei MP3 (letztes Mal)
+Diese Rechnung muss in der Klausur reproduziert werden können — Formel + Anwendung.
+
+Historischer Kontext:
+- 1982: erste CD (Billy Joel – 52nd Street, Japan)
+- Festplatten der 90er: 40–500 MB → ein Album füllte die ganze Platte
+- 56k-Modem: 7 KB/s → 42 MB Song ≈ 100 Minuten Download
+- Daraus entstand der Druck zur Audio-Kompression — die wir in Kap 2 sehen werden
+
+Spektrogramm-Folie als Anschluss: 44,1 kHz → wir können bis ~22 kHz erfassen. Mehr nicht. Warum genau 22 kHz? Weil Menschen bis ~20 kHz hören. Antwort kommt mit Nyquist.
 -->
 
 
@@ -354,27 +312,32 @@ KLAUSURRELEVANT:
 <!-- _footer: "" -->
 
 
-![bg right:20%](./assets/Barn-yuv.png)
+# Nyquist-Theorem — warum 2× reicht
 
-# JPEG Schritt 1: Farbraumkonversion
+![bg right:50% contain](./assets/demos/nyquist-diagram.png)
 
-**RGB → Y'CbCr**
+**Sample-Rate muss mindestens das *Doppelte* der höchsten Signal-Frequenz sein:**
 
-- **Y** = Helligkeit (Luminanz)
-- **Cb** = Blau-Gelb-Anteil (Chrominanz)
-- **Cr** = Rot-Grün-Anteil (Chrominanz)
+```
+f_sample ≥ 2 · f_max
+```
 
-**Warum?**
-Y (Helligkeit) behält volle Auflösung
-Cb/Cr (Farbe) kann reduziert werden
+Drei Fälle:
+- **zu wenig** → Aliasing (falsche tiefere Welle)
+- **genau** → mathematisches Minimum
+- **mehr** → sichere Rekonstruktion
 
 <!--
-KLAUSURRELEVANT:
-- YCbCr = auch 3 Werte pro Pixel, aber anders organisiert
-- Statt R-G-B: Helligkeit + 2 Farbdifferenzen
-- Umrechnung ist reversibel (mathematische Transformation)
-- Vorteil: Helligkeit und Farbe getrennt behandelbar
-- Bild zeigt: Y (oben), Cb (Mitte), Cr (unten)
+Harry Nyquist (1928) + Claude Shannon (1949): Sampling-Theorem.
+
+Beweis nicht klausurrelevant. Die Aussage und das visuelle Verständnis sind klausurrelevant.
+
+Konsequenz:
+- 44,1 kHz Sample Rate → max. 22,05 kHz erfassbare Frequenz
+- Über 22 kHz wird *physisch nicht aufgenommen* (vor dem ADC sitzt ein Tiefpassfilter, der alles über 22 kHz abschneidet — anti-aliasing filter)
+- Studis hören diese hohen Frequenzen sowieso nicht (~20 kHz oben)
+
+Anschluss zur nächsten Folie: warum hat die CD genau 44,1 kHz gewählt?
 -->
 
 
@@ -384,61 +347,25 @@ KLAUSURRELEVANT:
 <!-- _footer: "" -->
 
 
-# JPEG Schritt 6: Huffman-Coding
+# Vergleich: Lossless vs. Lossy
 
-**Verlustfreie Kompression der Restwerte**
-
-**Idee:** Variable Bitlänge statt fester 8 Bit
-Häufige Werte → kurze Codes
-
-| Zeichen | Häufigkeit | Code |
-|---------|------------|------|
-| e | 40% | `0` (1 Bit) |
-| a | 25% | `10` (2 Bit) |
-| i | 20% | `110` (3 Bit) |
-| o | 10% | `1110` (4 Bit) |
-| u | 5% | `1111` (4 Bit) |
+| Eigenschaft | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
+|-------------|------------------------|--------------------------|
+| Was passiert? | Redundanz raus | Irrelevanz raus |
+| Umkehrbar? | Ja, bit-genau | Nein, nie wieder |
+| Trick | Wiederholungen kürzer kodieren | Wahrnehmung modellieren |
+| Typischer Faktor | 2× – 5× | 10× – 100× |
+| Anwendung | Archiv, Werkzeug, Code | Stream, Anzeige, Konsum |
+| Beispiele | ZIP · PNG · FLAC · RAW | MP3 · JPEG · H.264 · WebP |
 
 <!--
-KLAUSURRELEVANT:
-- Huffman = verlustfrei, optimal für bekannte Häufigkeiten
-- Präfix-frei: Kein Code ist Anfang eines anderen
-- Häufigstes Zeichen = kürzester Code
-- Auch in ZIP, PNG, MP3 verwendet
--->
+Klausurfähig: gegeben ein Anwendungsfall — soll Lossless oder Lossy verwendet werden? Mit Begründung.
 
-
----
-
-<!-- _header: "" -->
-<!-- _footer: "" -->
-
-<!--
-# Huffman-Coding: Beispiel
-
-**Originaltext:** `ABRACADABRA` (11 Zeichen × 8 Bit = 88 Bit)
-
-**Häufigkeitsanalyse:**
-A=5, B=2, R=2, C=1, D=1
-
-**Huffman-Baum → Codes:**
-| Zeichen | Häufigkeit | Code |
-|---------|------------|------|
-| A | 5 | `0` |
-| B | 2 | `10` |
-| R | 2 | `110` |
-| C | 1 | `1110` |
-| D | 1 | `1111` |
-
-**Codiert:** `0 10 110 0 1110 0 1111 0 10 110 0` = **23 Bit**
-**Kompression:** 88 → 23 Bit = **74% gespart**
-
-
-- Beispiel Schritt für Schritt durchrechnen
-- Warum funktioniert's? A kommt 5× vor, bekommt kürzesten Code
-- Präfix-Eigenschaft: Kein Code ist Anfang eines anderen → eindeutig dekodierbar
-- Frage: "Was passiert, wenn alle Zeichen gleich häufig sind?" → Keine Ersparnis
-- In JPEG: Nicht Buchstaben, sondern DCT-Koeffizienten werden so codiert
+Beispiele für Klausurfragen:
+- 4K-Stream auf Netflix → Lossy (H.265 oder AV1)
+- RAW-Datei aus der DSLR archivieren → Lossless (RAW selbst, ggf. ZIP)
+- Lecture-Capture-Aufzeichnung für Wiederverwendung → Lossless besser, aber Datenrate hoch
+- Logo-Datei für Print + Web → SVG (vektorgraphisch) oder PNG (lossless raster)
 -->
 
 
@@ -448,26 +375,23 @@ A=5, B=2, R=2, C=1, D=1
 <!-- _footer: "" -->
 
 
-# WebP & AVIF: Moderne Alternativen
+# Raster vs. Vektor
 
-**WebP (Google, 2010):**
-- Lossy und Lossless
-- Transparenz und Animationen
-- 25–35% kleiner als JPEG
-
-**AVIF (2019):**
-- Basiert auf AV1-Video-Codec
-- 50% kleiner als JPEG
-- HDR-Unterstützung, patent-frei
-
-**Browser-Support 2025:** WebP universell, AVIF wächst
+| | Raster | Vektor |
+|--|--------|--------|
+| Was | Gitter aus Pixel-Werten | Mathematische Anweisungen |
+| Speicher | wächst mit Auflösung | wächst mit Komplexität |
+| Skalierung | pixelig beim Zoom | scharf bei jeder Größe |
+| Geeignet für | Fotos, Screenshots | Logos, Icons, Schrift |
+| Formate | PNG · JPEG · GIF · WebP | SVG · PDF · Schriftarten |
 
 <!--
-KLAUSURRELEVANT:
-- WebP: VP8-Kompression (Google Video-Codec)
-- AVIF: Alliance for Open Media (Google, Netflix, Amazon, Apple, Mozilla)
-- Beide besser als JPEG, aber Kompatibilität bleibt Problem
-- JPEG bleibt dominant: alte Kameras, Software, Workflows
+Klausurfähig. Geben Sie:
+- ein Format zu jeder Spalte
+- ein Anwendungsbeispiel zu jeder Spalte
+- begründen warum Vektor bei Logos und Raster bei Fotos
+
+Trick-Frage: kann man ein Foto in SVG speichern? Theoretisch ja (mit Millionen winziger Rechtecke), praktisch nein — wird dann viel größer als JPEG.
 -->
 
 
@@ -477,24 +401,23 @@ KLAUSURRELEVANT:
 <!-- _footer: "" -->
 
 
-# Container und Codec
+# Memo: Die 6 JPEG-Schritte
 
-**Container = Dateiformat (z.B. MP4)**
-Die "Box", die verschiedene Streams zusammenpackt:
-- Video-Stream
-- Audio-Stream(s)
-- Untertitel
-- Metadaten
+| # | Schritt | Lossless / Lossy |
+|---|---------|------------------|
+| 1 | RGB → Y'CbCr (Farbraum) | Lossless |
+| 2 | Chroma-Subsampling 4:2:0 | **Lossy** |
+| 3 | 8×8 Blöcke | Lossless |
+| 4 | DCT (Frequenz-Zerlegung) | Lossless |
+| 5 | Quantisierung | **Lossy** (Haupt-Reduktion) |
+| 6 | Huffman + Zigzag + RLE | Lossless |
 
-**Codec = Kompressionsalgorithmus (z.B. H.264)**
-Bestimmt, WIE komprimiert wird
+Nur **2** der 6 Schritte verlieren Information.
 
 <!--
-KLAUSURRELEVANT:
-- Container ≠ Codec (häufiges Missverständnis!)
-- MP4 kann H.264, H.265 oder AV1 enthalten
-- Gleiche Endung, unterschiedlicher Inhalt
-- Tool-Tipp: MediaInfo zeigt beides an
+Klausurfähig. Sechs Schritte. Reihenfolge wichtig. Lossy/Lossless-Status pro Schritt wichtig.
+
+Eselsbrücke: „Farb-Sub-Block-DCT-Quant-Huff" → F-S-B-D-Q-H.
 -->
 
 
@@ -504,25 +427,24 @@ KLAUSURRELEVANT:
 <!-- _footer: "" -->
 
 
-# H.264 / AVC
+# Wann welches Bildformat?
 
-**Advanced Video Coding (2003)**
-
-**Warum dominant?**
-- Exzellente Kompression (~100:1 möglich)
-- Hardware-Decoder in jedem Gerät seit ~2010
-- YouTube, Netflix, Blu-ray – alles H.264
-
-**Features:**
-- Variable Block-Größen (16×16 bis 4×4)
-- Deblocking-Filter (reduziert Artefakte)
+| Anwendung | Format | Warum |
+|-----------|--------|-------|
+| Foto im Web (Insta, News) | **JPEG** oder **WebP** | klein, Foto-optimiert |
+| Foto-Archiv (RAW) | **RAW**, **TIFF**, **DNG** | nichts verlieren |
+| Logo, Icon (skalierbar) | **SVG** | wird neu berechnet |
+| Logo als Raster | **PNG** | Transparenz + scharfe Kanten |
+| Screenshot mit Text | **PNG** | scharfe Buchstaben |
+| Animiertes Sticker | **GIF** oder **WebP** | beide animierbar |
+| Foto in höchster Modern-Qualität | **AVIF** oder **WebP** | bessere Kompression als JPEG |
 
 <!--
-KLAUSURRELEVANT:
-- H.264 revolutionierte Video-Streaming
-- Ohne H.264 kein Netflix, kein YouTube HD
-- Hardware-Decoder = kein CPU-Aufwand, kein Akku-Drain
-- Selbst billigste Smartphones können H.264 abspielen
+Klausurfähig: gegeben ein Anwendungsfall, welches Format und warum?
+
+Sub-Frage: was schief geht, wenn ich JPEG für ein Logo nehme? → unscharfe Ränder + sichtbare Artefakte.
+
+Sub-Frage: warum nicht immer AVIF? → Browser-Support (manche ältere Browser können AVIF noch nicht), Tool-Kompatibilität, Workflow-Etablierung.
 -->
 
 
@@ -532,29 +454,23 @@ KLAUSURRELEVANT:
 <!-- _footer: "" -->
 
 
-# AV1: Die offene Zukunft
+# Audio-Format-Wahl
 
-**AV1 (2018)**
-
-**Alliance for Open Media:**
-Google, Netflix, Amazon, Microsoft, Apple, Mozilla...
-
-**Eigenschaften:**
-- 30% besser als H.265
-- Royalty-free, Open Source
-- 8K, HDR, hohe Frame-Rates
-
-**Stand 2025:**
-YouTube, Netflix nutzen AV1 für 4K/8K
-Hardware-Encoder in aktuellen GPUs
+| Anwendung | Format | Warum |
+|-----------|--------|-------|
+| Spotify-Stream | **AAC** oder **MP3 192+** | Kompression, breite Unterstützung |
+| Studio-Master | **WAV** oder **FLAC** | Bit-genau erhalten |
+| Sprachnachricht | **Opus** oder **AAC-LD** | für Sprache optimiert, niedrige Bitrate |
+| Podcast-Distribution | **MP3 128 kbit/s** | universelle Unterstützung |
+| HiFi-Audiophile | **FLAC** | lossless, kleiner als WAV |
+| Archiv eigener Aufnahmen | **FLAC** oder **WAV** | nichts verlieren |
 
 <!--
-KLAUSURRELEVANT:
-- AOM gegründet 2015 – historisch: Konkurrenten vereint
-- Ziel: Nie wieder Patent-Chaos wie bei H.265
-- Problem: Encoding sehr langsam (10–100× vs. H.264)
-- Hardware-Encoder lösen das zunehmend
-- AV1 gewann 2024 einen Emmy für technische Innovation
+Klausurfähig: gegeben ein Anwendungsfall, welches Format?
+
+Trick-Frage: warum nicht MP3 320 für Studio? → Lossless ist immer noch verlustfrei besser. Wer mastern will, braucht das.
+
+Trick-Frage 2: warum nicht WAV für Spotify? → Daten-Volumen zu hoch fürs Streaming.
 -->
 
 
@@ -564,25 +480,30 @@ KLAUSURRELEVANT:
 <!-- _footer: "" -->
 
 
-# Wann HDD, wann SSD?
+# Container ≠ Codec
 
-| Anwendung | Empfehlung |
-|-----------|------------|
-| Betriebssystem | SSD (NVMe) |
-| Anwendungen, Spiele | SSD |
-| Video-Editing (Projekte) | SSD |
-| Foto-Archiv | HDD oder SSD |
-| Backup | HDD |
-| NAS / Server | HDD (oder Mix) |
-| Cold Storage | HDD oder Band |
+![bg right:40% contain](./assets/container-codec-diagram.png)
+
+**Container** = die *Verpackung*: hält Video-Spur, Audio-Spur, Untertitel, Metadaten zusammen.
+*Beispiele:* MP4, MKV, WebM, AVI
+
+**Codec** = der *Komprimierer*: wie wird Bild/Audio gespeichert?
+*Beispiele:* H.264, H.265, AV1, VP9 (Video) · AAC, MP3, Opus (Audio)
+
+**Eine `.mp4`-Datei kann verschiedene Codecs enthalten.**
 
 <!--
-Die Faustregel:
-- Oft genutzt, schnell gebraucht → SSD
-- Selten genutzt, viel Kapazität → HDD
+Das ist DER zentrale Missverständnis-Punkt bei Video. Studis denken oft, „MP4" oder „MKV" sei das Format des Videos. Stimmt nicht. Es ist nur die Hülle.
 
-Viele setzen auf beides:
-Kleine SSD für System + große HDD für Archiv.
+Konkretes Beispiel: zwei `.mp4`-Dateien:
+- A: H.264-Video + AAC-Audio
+- B: H.265-Video + Opus-Audio
+
+Beide haben die Endung .mp4. Aber A spielt überall, B braucht moderne Player.
+
+Tool: `mediainfo <datei>` zeigt Container UND Codec.
+
+Klausurfähig.
 -->
 
 
@@ -592,30 +513,322 @@ Kleine SSD für System + große HDD für Archiv.
 <!-- _footer: "" -->
 
 
-# Die 3-2-1-Regel
+# I, P, B — Frame-Typen
 
-**3** Kopien eurer Daten
-(Original + 2 Backups)
+| Typ | Vollname | Was drin | Größe |
+|-----|----------|----------|-------|
+| **I** | Intra-coded | Komplettes Bild (wie JPEG) | groß |
+| **P** | Predicted | „Was hat sich seit voriges I/P geändert" | mittel |
+| **B** | Bidirectional | „Was zwischen vorigem und nächstem I/P" | klein |
 
-**2** verschiedene Medientypen
-(z.B. SSD + HDD, oder lokal + Cloud)
-
-**1** Kopie an anderem Ort
-(Offsite: Cloud, anderes Gebäude)
+Typische GOP: `I B B P B B P B B P B B I ...` (alle 1–3 Sekunden ein I-Frame).
 
 <!--
-Herkunft: Peter Krogh, "The DAM Book" (2005)
+Klausurfähig: was sind I/P/B-Frames? Welche ist die größte? Warum brauchen wir I-Frames trotzdem (Seeking, Stream-Start, Fehlerresistenz)?
 
-Warum 3 Kopien?
-- Original kann kaputt gehen
-- Backup 1 auch
-- Backup 2 = Sicherheitspuffer
+GOP = Group of Pictures.
 
-Warum 2 Medientypen?
-- Gleiche Medien haben gleiche Schwachstellen
-- Batch-Fehler bei HDDs derselben Charge
+I-Frame als Seeking-Anker:
+- Wenn man im Video an einer Stelle springt, kann der Player nur an I-Frames anfangen
+- Zwischen I-Frames muss Player VOM letzten I-Frame ab dekodieren bis zur Spring-Stelle
 
-Warum 1 Offsite?
-- Brand/Wasserschaden zerstört alles vor Ort
-- Ransomware verschlüsselt angeschlossene Laufwerke
+Daher: I-Frames sollten nicht zu selten sein (sonst langsames Seeking), aber auch nicht zu häufig (sonst weniger Kompression).
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Patent vs. Open — warum AV1?
+
+| Codec | Effizienz | Patent | Adoption (2026) |
+|-------|-----------|--------|-----------------|
+| H.264 | Baseline | Lizenz (MPEG-LA) | ~80 % aller Videos |
+| H.265 | +50 % | 3 Patent-Pools, chaotisch | nur Apple |
+| VP9 | ~H.265 | lizenzfrei (Google) | YouTube 4K |
+| **AV1** | **+30 % über H.265** | **lizenzfrei (Allianz)** | **YouTube, Netflix, Twitch** |
+
+**Die Lektion:** technisch beste Lösung gewinnt nicht. *Lizenz-klare* beste Lösung gewinnt.
+
+<!--
+Klausurfähig: warum hat AV1 H.265 abgelöst, wenn beide ähnlich effizient sind?
+
+Antwort: Patent-Politik. H.265 hat drei Patent-Pools, AV1 ist lizenzfrei. Industrie-Konsortium hat AV1 finanziert, weil sie nie wieder einem MPEG-LA-Pool ausgeliefert sein wollten.
+
+Sub-Frage: warum nicht VP9? → AV1 ist effizienter (~30 %), und alle wichtigen Player stehen dahinter (statt nur Google).
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# HDD vs. SSD
+
+![bg right:40% contain](./assets/hdd-ssd-comparison.png)
+
+| | HDD | SSD |
+|--|-----|-----|
+| Technik | Mechanik | Flash |
+| Geschwindigkeit | 50–250 MB/s | 500–14.000 MB/s |
+| Latenz | ~10 ms | ~0,1 ms |
+| Preis/TB (2026) | ~20 € | ~70 € |
+| Lebensdauer | ~5–10 Jahre | ~5–10 Jahre |
+| Geräusch | hörbar | lautlos |
+| Stoß-empfindlich | ja | nein |
+
+<!--
+HDD-Vorteile: viel Kapazität für wenig Geld. Lange archivierbar im Schrank.
+SSD-Vorteile: schnell, leise, robust. Aber teurer pro TB.
+
+Klausurfähig: gegeben ein Anwendungsfall, HDD oder SSD?
+
+- Betriebssystem: SSD (schnell)
+- Backup-Archiv: HDD (billig)
+- Server für Foto-Speicher: HDD (Kapazität)
+- Laptop (mobil): SSD (Stoß)
+- Video-Bearbeitung: SSD (Throughput)
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Wann nehme ich was?
+
+| Anwendung | Empfehlung | Begründung |
+|-----------|------------|------------|
+| Betriebssystem auf dem Laptop | **NVMe-SSD** | Geschwindigkeit, Boot |
+| Eigene Foto-Library (10 TB+) | **HDD** | Kapazität, Preis |
+| Server für Logfiles | **HDD oder SSD** | je nach Schreib-Last |
+| Externes Backup-Archiv | **HDD** | billig, ok wenn langsam |
+| Mobile Workstation (Reise) | **SSD** | Stoß, Geräusch |
+| Edit-Drive für 4K-Schnitt | **NVMe-SSD** | Throughput für Video |
+| Langzeitarchiv 10+ Jahre | **LTO-Band + M-DISC** | Langlebigkeit |
+
+<!--
+Klausurfähig. Trick-Frage: warum nicht alles SSD? → Preis pro TB. Faktor 3-5× teurer.
+
+Cloud-Speicher (iCloud, Google Drive, Dropbox) ist physisch HDD/SSD/LTO in Rechenzentren — kein eigenes Medium, sondern Zugriffsmethode.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Filesystem-Landschaft
+
+| Filesystem | Wo verbreitet | Max. Dateigröße | Besonderheit |
+|-----------|---------------|----------------:|--------------|
+| **FAT32** | USB-Sticks, SD-Karten alt | **4 GB** | universell, alt |
+| **exFAT** | USB-Sticks modern | 16 EB | wie FAT, ohne 4-GB-Limit |
+| **NTFS** | Windows | 16 EB | Standard seit Win 2000 |
+| **APFS** | macOS seit 2017 | 8 EB | snapshots, schnell |
+| **ext4** | Linux | 16 TB | klassisch, robust |
+| **ZFS** | Server, FreeBSD | 16 EB | checksum, snapshots |
+
+**FAT32 4-GB-Grenze** ist der häufigste Alltags-Knack: USB-Stick noch nie umformatiert → kein 4K-Video drauf.
+
+<!--
+Klausurfähig: warum kann ich 5 GB Video nicht auf den USB-Stick ziehen? Antwort: FAT32 hat 4-GB-Dateigrößen-Limit. Lösung: USB-Stick auf exFAT umformatieren (Mac und Windows lesen/schreiben beide).
+
+Asymmetrien:
+- Mac kann NTFS nur lesen, nicht schreiben (ohne Drittpartei-Treiber)
+- Windows kann APFS gar nicht
+- Linux kann mit Plugins fast alles
+
+Konsequenz für Studis: für Datentransfer zwischen Mac und Windows → exFAT. Für reinen Mac → APFS. Für Backup auf USB-Disk, die nur am eigenen Gerät benutzt wird → natives FS.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Die 3-2-1-Backup-Regel
+
+**3** Kopien deiner Daten
+
+**2** verschiedene **Medien** (z.B. SSD + HDD)
+
+**1** Kopie **off-site** (außerhalb deines Wohnorts)
+
+Beispiel:
+
+```
+Original  →  Foto-Library auf der MacBook-SSD
+Kopie 1   →  Time Machine auf externer HDD (zuhause)
+Kopie 2   →  Backblaze in der Cloud (off-site)
+```
+
+<!--
+Diese Regel löst drei Risiken:
+- Hardware-Crash: 3 Kopien, 2 davon auf anderen Geräten
+- Diebstahl/Brand: 1 Kopie off-site (Cloud oder bei Familie)
+- Ransomware: off-site-Kopie schreibgeschützt oder versioniert
+
+Klausurfähig: was ist die 3-2-1-Regel? Beispiele für jede Ebene.
+
+Cloud-Backup-Anbieter (off-site Option):
+- Backblaze: ~7 USD/Monat unlimited (Mac/Windows)
+- iCloud / Google One / OneDrive: integriert, aber begrenzt
+- Self-hosted: Synology / QNAP bei einer Person im Vertrauen
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Schnittstellen-Wahl-Matrix
+
+| Aufgabe | Beste Schnittstelle | Warum |
+|---------|---------------------|-------|
+| 4K-Monitor anschließen | **HDMI 2.0+** oder **DP 1.4+** | Bandbreite |
+| Online-Gaming | **Ethernet** | niedrige Latenz |
+| eGPU am Laptop | **Thunderbolt 3/4** | PCIe-Tunnel |
+| SD-Karte einlesen | **USB-A 3.0** oder **USB-C** | Kompatibilität |
+| Smartphone laden | **USB-C-PD** | Standard |
+| Heim-Streaming | **WiFi** oder **Ethernet** | reicht beides |
+| 4K-Stream mehrere Geräte | **Ethernet** | Stabilität |
+
+<!--
+Klausurfähig: gegeben Anwendungsfall, welche Schnittstelle und warum?
+
+Trick: warum nicht immer Thunderbolt? → Teurer Kabel, teurere Hardware. Nicht jedes Endgerät unterstützt es.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# REST: GET · POST · PUT · DELETE
+
+| Methode | Was tut sie | URL-Beispiel |
+|---------|-------------|--------------|
+| **GET** | lesen | `GET /users/42` (User mit ID 42 abfragen) |
+| **POST** | neu erstellen | `POST /users` mit Daten als Body |
+| **PUT** | überschreiben | `PUT /users/42` mit kompletten neuen Daten |
+| **PATCH** | teilweise ändern | `PATCH /users/42` mit Änderungen |
+| **DELETE** | löschen | `DELETE /users/42` |
+
+CRUD = **C**reate · **R**ead · **U**pdate · **D**elete.
+
+<!--
+Klausurfähig: welche HTTP-Methode für welche Operation?
+
+Trick-Frage: was ist der Unterschied zwischen PUT und PATCH?
+- PUT: ersetzt komplett. User wird kompletter neu gesetzt.
+- PATCH: ändert nur die mitgegebenen Felder. Rest bleibt.
+
+In der Praxis nehmen viele APIs PUT auch für partielle Updates — kein RFC-konforme Strenge.
+
+Werkzeuge zum Testen: curl, Postman, Hoppscotch (browser-basiert), VS-Code REST-Client-Plugin.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Der John-McAfee-GPS-Fall
+
+**Dezember 2012.** John McAfee (Antivirus-Erfinder) flieht aus Belize, wo er als Mordverdächtiger gesucht wird.
+
+**Vice Magazine** veröffentlicht ein Interview mit einem Foto: McAfee im T-Shirt, scheinbar in einer geheimen Location.
+
+**EXIF-Koordinaten im Foto:** `15.6541° N, 88.9939° W` → **Hotel Nana Lodge, Guatemala.** Bekannt.
+
+McAfee wird 36 Stunden später festgenommen.
+
+<!--
+Diese Story zeigt:
+1. Smartphones speichern GPS-Daten standardmäßig
+2. Online-Plattformen STRIPPEN diese Metadaten oft NICHT (Vice damals nicht)
+3. Wer ein Bild mit GPS hochlädt, kann seinen Aufenthaltsort verraten
+
+McAfee hat sich danach öffentlich darüber lustig gemacht ("yes that was the actual location"), aber der Fall wurde zum Lehrbuch-Beispiel für EXIF-Privacy.
+
+2026: die meisten großen Plattformen strippen EXIF (Twitter/X, Instagram, WhatsApp), aber:
+- WhatsApp-Originaldatei via "Dokument" senden: behält EXIF
+- E-Mail-Anhang: behält EXIF
+- Direkt-Upload zu Drittpartei-Webseiten: oft mit EXIF
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Der Tony-Blair-Fall (PDF-Metadaten)
+
+**Februar 2003.** Britische Regierung veröffentlicht PDF-Dokument zur Begründung des Irakkriegs.
+
+Ein britischer Akademiker findet im **PDF-Revisionsverlauf**: das Dokument wurde aus einer studentischen Doktorarbeit von 1991 kopiert.
+
+**Plagiats-Skandal.** Plus Hinweise auf welche Mitarbeiter:innen welche Sätze überarbeitet hatten.
+
+→ **PDF-Metadaten** verraten oft mehr als der Inhalt.
+
+<!--
+PDF-Metadaten:
+- Autor, Erstell-Zeit, letzte Änderung
+- Software (Microsoft Word, LibreOffice, Adobe Acrobat)
+- Manchmal Revision History
+- Manchmal versteckter Text (z.B. weiße Schrift auf weißem Hintergrund)
+
+Sicherheitsrelevant:
+- Schwärzungen werden manchmal nur als schwarzer Layer DRÜBER gelegt — Text bleibt extrahierbar
+- NSA-Dokumente, FBI-Reports, US-Gerichtsdokumente: viele berühmte Beispiele für gescheiterte Schwärzungen
+- Auch bei Microsoft Word: "Schwärze" via schwarzes Highlight → Text bleibt im Stream lesbar
+
+Klausurfähig: ein Beispiel für PDF-Metadaten-Privacy-Verstoß nennen + Begründung.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Vendor-Lockin als Risiko
+
+**Szenario:** Du arbeitest 5 Jahre lang mit Adobe InDesign. Dann steigt der Abo-Preis um 200 % oder Adobe ändert das Format.
+
+**Konsequenz:**
+- Bestehende INDD-Dateien öffnen sich noch — aber nur in Adobe-Produkten
+- Migration zu Affinity Publisher / Scribus: Daten müssen konvertiert werden, manche Details gehen verloren
+- Bei einigen Formaten gibt es keine Konverter — Vendor entscheidet komplett
+
+**Schutz:** Wichtige Daten in **offenen Formaten** parallel speichern.
+
+<!--
+Klausurfähig: was ist Vendor-Lockin? Beispiel + warum problematisch?
+
+Diskussion: Open-Source-Tools sind oft "fast so gut" — manchmal sogar besser. Aber Industrie-Standards halten den Status quo.
+
+Heimlich-Lockin: auch "Bug-für-Bug-Kompatibilität". Microsoft Office hat sich in den 90ern als Standard durchgesetzt, weil Konkurrenz-Office-Suites die exakten Bugs/Quirks nicht reproduzieren konnten.
 -->