223015b phase 3b: 2 konkrete eröffner-demos (statt schablone) + STATUS.md für branch-fortsetzung. kap02-eroeffner: FLAC vs MP3-128 mit synth-svg-wellenformen, echten dateigrößen (5.3 MB vs 0.48 MB), bitrate-vergleich, verdict-frage 'hört man den unterschied'. kap03-eroeffner: 3×3-tabelle bild/audio/video × roh/lossy-modern/lossy-aggressiv mit echten zahlen (foto 36MB→4MB→800KB, audio 5.3MB→720KB→240KB, video 12GB→94MB→45MB) + visuelle größenbalken + verdict mit reduktionsfaktoren ×45/×22/×270 und drei verschiedenen wahrnehmungs-tricks pro modalität. kap4+5 eröffner noch offen, status-doc beschreibt nächste schritte für branch-fortsetzung von unterwegs

.gitignore

@@ -34,3 +34,7 @@ hdm-internettechnik-slides/
 *.tmp
 *.bak
 .idea
+
+# Image-Backups (Original-Quellen vor optimize-images)
+slides/*/assets-original/
+slides/*/assets/*-original/

AGENTS.md

@@ -1,48 +1,59 @@
-# AGENTS.md - Agent Guidelines for HdM Slides
+# AGENTS.md - Agent Guidelines for Uni Slides (HdM + DHBW)
 
-This file contains comprehensive guidelines for agentic coding agents working on the HdM Slides project.
+This file contains comprehensive guidelines for agentic coding agents working on the Uni Slides project. For the short version, see `CLAUDE.md`.
 
 ## Project Overview
 
 This project builds presentation decks for Marp, supporting multiple courses:
-- **223015b** - Dateiformate, Schnittstellen, Speichermedien (6 Kapitel)
-- **223015c** - Internettechnologien (3 Kapitel)
+
+- **223015b** – Dateiformate, Schnittstellen, Speichermedien (HdM, 6 Kapitel + Klausur)
+- **223015c** – Internettechnologien (HdM, 3 Kapitel + Klausur)
+- **dhbw** – Technik I – Grundlagen IT (DHBW, 8 Kapitel)
 
 ## Development Workflow
 
 ### Build Commands
+
+Unified per-course pattern: `make <target>-<course>`. Group targets without suffix run for all courses. Single dev server serves all courses.
+
 ```bash
-# Development
-make dev              # Start single dev server on port 3000
-npm run dev           # Alternative command for development server
+# Dev (all courses, single port)
+make dev                      # Live server (HMR), port 1312
 
-# Build
-make build            # Build all courses (HTML + PDF)
-make build-b          # Build 223015b only
-make build-c          # Build 223015c only
-make html             # HTML only builds
-make pdf              # PDF only builds
+# Per-course build/deploy (replace <c> with: 223015b, 223015c, dhbw)
+make build-<c>                # Build HTML + PDF
+make html-<c>                 # HTML only
+make pdf-<c>                  # PDF only
+make klausur-<c>              # Extract klausur slides (HdM only)
+make deploy-<c>               # Build + deploy single course (ASK FIRST!)
 
-# Klausur Folien
-make klausur          # Extract klausurfolien for all courses
-make klausur-b        # Extract klausurfolien for 223015b
-make klausur-c        # Extract klausurfolien for 223015c
-
-# Deployment
-make deploy            # Deploy all courses (requires explicit permission)
-make deploy-b         # Deploy 223015b only
-make deploy-c         # Deploy 223015c only
+# All courses
+make build                    # Build everything
+make html / pdf               # HTML / PDF only
+make klausur                  # Extract klausur (HdM courses only)
+make deploy                   # Deploy everything (ASK FIRST!)
 
 # Utilities
 make qr URL=...               # Generate QR code
-make optimize-images COURSE=223015b  # Resize images
+make qr-slides COURSE=<c>     # QR for course URL
+make optimize-images COURSE=<c>   # Resize images
 make clean                    # Remove generated files
+make install                  # npm install
+```
+
+**Adding a new course:** add id to `COURSES` in `Makefile` + define `<id>_NAME`, `<id>_KAPITEL`, `<id>_DEPLOY`, `<id>_KLAUSUR`. No new targets needed.
+
+### Nix Flake
+
+```bash
+nix develop                   # Dev shell with all tools (node 22, npm, make)
 ```
 
 ### Testing
-No specific test framework is used. To validate changes:
+
+No formal test framework. To validate changes:
 1. Start dev server: `make dev`
-2. Open http://localhost:3000/223015b/ or /223015c/
+2. Open http://localhost:1312/223015b/, /223015c/, or /dhbw/
 3. Verify slides render correctly
 4. Run `make build` to ensure no build errors
 5. Check generated files in `build/` directory
@@ -50,7 +61,18 @@ No specific test framework is used. To validate changes:
 ## Code Style Guidelines
 
 ### File Structure
-- Slides in `slides/<course>/` following naming pattern `NN-topic.md`
+
+```
+slides/
+├── 223015b/            # HdM: Dateiformate
+├── 223015c/            # HdM: Internettechnik
+└── dhbw/               # DHBW: Technik I
+scripts/                # Shared scripts
+themes/                 # Custom Marp themes
+build/                  # Generated output (gitignored)
+```
+
+- Slides in `slides/<course>/` following `NN-topic.md` (HdM) or `NN_topic.md` (DHBW)
 - Assets in `slides/<course>/assets/`
 - Always reference images as `./assets/filename.png`
 - Scripts in `scripts/`
@@ -58,20 +80,22 @@ No specific test framework is used. To validate changes:
 - Generated output in `build/` (gitignored)
 
 ### Naming Conventions
-- Slide files: `NN-topic.md` (e.g., `01-grundlagen.md`, `02-bilder.md`)
+
+- Slide files: `NN-topic.md` (HdM, e.g. `01-grundlagen.md`) or `NN_topic.md` (DHBW, e.g. `01_web_eng.md`)
 - Images: `snake_case.jpg` or `kebab-case.jpg`
-- Klausur files: `klausurfolien.md` (auto-generated)
-- Function names in scripts: `snake_case`
-- Variable names in scripts: `snake_case`
+- Klausur files: `klausurfolien.md` / `klausurfragen.md` (auto-generated, HdM only)
+- Function/variable names in scripts: `snake_case`
 
 ### Markdown Style
+
 - Use ATX-style headers (`# ## ###`)
 - YAML frontmatter for slide metadata at top of each file
 - Never include a final `---` (creates empty slide)
-- Use `<!-- _class: klausur -->` for exam-relevant slides
+- Use `<!-- _class: klausur -->` for exam-relevant slides (HdM)
 - Use relative paths for assets: `./assets/image.png`
 
 ### Script Style
+
 - Use `#!/usr/bin/env bash` shebang
 - Use `set -e` for error handling
 - Use `2>/dev/null || true` for optional operations
@@ -79,6 +103,7 @@ No specific test framework is used. To validate changes:
 - Use colors for terminal output: `\033[0;32m` etc.
 
 ### Git Workflow
+
 - Commit messages: ALWAYS lowercase
 - NEVER add co-authoring lines or generated footers
 - Follow semantic naming: "add-...", "fix-...", "update-..."
@@ -87,111 +112,113 @@ No specific test framework is used. To validate changes:
 ## Agent Restrictions
 
 ### Security
-- NEVER run commands outside `/home/mwc/Coding/hdm` folder
+
+- NEVER run commands outside `/home/libretech/Repos/uni`
 - NEVER run build/deploy commands without explicit user request
-- NEVER run deploy commands (make deploy, scp, etc.) without explicit permission
+- NEVER run deploy commands (`make deploy`, `scp`, etc.) without explicit permission
+- NEVER run `git checkout --` or `git restore` on files with uncommitted work. To undo specific changes, use targeted Edit operations instead.
 
 ### File Protection
+
 Slide files in `slides/*/*.md` are main content files:
 - **ALLOWED**: Adding slides, adjusting content, fixing typos, enhancing sections
 - **FORBIDDEN** (without permission): Deleting slides, removing sections, bulk deletions
 - Before ANY deletion: ALWAYS ask user for confirmation
 
-### Klausur Handling
-- Klausur files (`klausurfolien.md`) are auto-generated
-- NEVER edit klausurfolien.md files directly
-- To update klausurfolien: edit source slides with `<!-- _class: klausur -->` markers
-- Run `make klausur` to regenerate
+### Klausur Handling (HdM only)
+
+- Klausur files (`klausurfolien.md`, `klausurfragen.md`) are auto-generated
+- NEVER edit klausur files directly
+- To update klausur: edit source slides with `<!-- _class: klausur -->` markers
+- Run `make klausur` (or `make klausur-<c>`) to regenerate
+- DHBW course has no klausur extraction (`dhbw_KLAUSUR =` is empty)
 
 ## Development Patterns
 
 ### Adding New Slides
-1. Create new file following `NN-topic.md` pattern
+
+1. Create new file following naming convention (`NN-topic.md` for HdM, `NN_topic.md` for DHBW)
 2. Copy frontmatter from existing slides in the same course
-3. Update Makefile `_KAPITEL` variable if needed
+3. Add stem to `<course>_KAPITEL` in `Makefile`
 4. Test with `make dev`
 
 ### Modifying Existing Slides
+
 1. Edit the appropriate markdown file in `slides/<course>/`
 2. Maintain consistent styling with course theme
 3. Preserve image paths as `./assets/...`
 4. Test changes with dev server
 
 ### Working with Assets
+
 1. Place images in `slides/<course>/assets/`
 2. Use descriptive names: `diagram-network.jpg`, `example-code.png`
-3. Optimize with `make optimize-images COURSE=223015b`
+3. Optimize with `make optimize-images COURSE=<c>`
 4. Reference as `./assets/filename.ext`
 
 ### Course-Specific Configuration
-Each course has specific settings in Makefile:
-- Course name and title
-- Kapitel list (slide files)
-- Deploy path
-- Theme colors (in generate-index.sh)
+
+Each course has these per-course settings in `Makefile`:
+- `<c>_NAME` – Display name
+- `<c>_KAPITEL` – Ordered list of slide file stems (without `.md`)
+- `<c>_DEPLOY` – Remote deploy path
+- `<c>_KLAUSUR` – `1` to enable klausur extraction, empty to disable
 
 ## Common Tasks
 
 ### Debugging Build Issues
-1. Check Makefile syntax: `make -n build`
-2. Verify Marp CLI installation: `npx @marp-team/marp-cli --version`
+
+1. Check Makefile syntax: `make -n build-<c>`
+2. Verify Marp CLI: `npx @marp-team/marp-cli --version`
 3. Check file permissions: `ls -la slides/`
-4. Validate markdown syntax with dev server
+4. Validate markdown via dev server
 
 ### Updating Course Structure
-1. Update `_KAPITEL` variables in Makefile
+
+1. Update `<c>_KAPITEL` in `Makefile`
 2. Ensure slide files follow naming convention
 3. Update course-specific themes if needed
-4. Test both dev and build processes
+4. Test both `make dev` and `make build-<c>`
 
 ### Working with Themes
+
 - Custom theme in `themes/custom-theme.css`
-- Course themes defined in individual slide frontmatter
+- Course themes referenced in individual slide frontmatter
 - Use consistent color schemes per course
 - Test theme changes across all slides
 
 ## Deployment Process
 
 Deployment to production server requires explicit permission:
-1. Build process: `make build` (HTML + PDF)
-2. Index generation: automatically handled
-3. Deploy to remote server via SCP
-4. Root index deployment
+1. Build: `make build` (HTML + PDF) or per-course `make build-<c>`
+2. Index generation: handled by `scripts/generate-index.sh` (per course) and `scripts/generate-root-index.sh` (root)
+3. Deploy: `scp` to `tengo@tuttle.uberspace.de` via `make deploy-<c>` or `make deploy`
+4. Root index deployed by `make deploy-index` (or as part of `make deploy`)
 
 **IMPORTANT**: Never run deployment commands without explicit user permission.
 
 ## Tools and Dependencies
 
-### Core Dependencies
-- Marp CLI for slide rendering
-- Bash scripts for automation
+### Core
+- Marp CLI for slide rendering (via `npx @marp-team/marp-cli`)
+- Bash scripts for automation (`scripts/`)
 - Make for build orchestration
 - Git for version control
 
-### Optional Tools
-- qrencode for QR generation (via nix)
-- ImageMagick for image optimization
-- Python 3 for simple HTTP server (legacy)
-
-## Testing Strategy
-
-Since there's no formal test suite:
-1. Manual testing with dev server
-2. Build process validation
-3. Slide rendering checks
-4. Asset path verification
-5. Cross-browser compatibility checks (important)
+### Optional
+- `qrencode` for QR generation (via nix-shell)
+- ImageMagick for image optimization (via nix-shell)
 
 ## Troubleshooting
 
 ### Common Issues
-- **Port conflicts**: Use `make dev-kill` to clean up processes
-- **Build failures**: Check file permissions and Marp CLI installation
-- **Asset loading**: Verify relative paths and file existence
-- **Deploy issues**: Check SSH keys and remote permissions
+- **Port conflicts**: kill the dev-server process holding port 1312
+- **Build failures**: check file permissions and Marp CLI availability via `npx`
+- **Asset loading**: verify relative paths and file existence in `slides/<c>/assets/`
+- **Deploy issues**: check SSH keys for `tengo@tuttle.uberspace.de` and remote permissions
 
 ### Getting Help
-1. Check this AGENTS.md file first
-2. Review Makefile targets and scripts
+1. Check this `AGENTS.md` first
+2. Review `Makefile` targets and `scripts/`
 3. Test changes incrementally
 4. Maintain backup of working configurations

CLAUDE.md

@@ -4,10 +4,45 @@ This project builds presentation decks for Marp, supporting multiple courses.
 
 ## Courses
 
-- **223015b** - Dateiformate, Schnittstellen, Speichermedien (HdM, 6 Kapitel + Klausur)
-- **223015c** - Internettechnologien (HdM, 3 Kapitel + Klausur)
+- **223015b** - Dateiformate, Schnittstellen, Speichermedien (HdM, 6 Kapitel + Klausur) — Fokus: **Dateien und Inhalte**
+- **223015c** - Internettechnologien (HdM, 3 Kapitel + Klausur) — Fokus: **Internet und Web**
 - **dhbw** - Technik I – Grundlagen IT (DHBW, 8 Kapitel)
 
+## Didaktisches Fundament (für alle HdM-Kurse)
+
+Diese drei Meta-Lernziele sind der Maßstab für jede inhaltliche Entscheidung — Folien, Reihenfolge, Beispiele, Übungen, Sprache. Jede Folie soll mindestens eines davon bedienen.
+
+1. **Gelernte Hilflosigkeit ablegen.** Studierende sollen am Ende fühlen, dass Technik kein Mysterium ist, das sie überfordert. Konsequenz: keine Insider-Sprache ohne Erklärung, jeder Begriff wird beim ersten Auftreten geöffnet, abstrakte Konzepte werden über konkrete Beispiele eingeführt (nicht andersrum).
+2. **Berührungspunkte schaffen.** Studierende sollen das Material mit ihrer eigenen Lebenswelt verknüpfen. Konsequenz: jedes Kapitel braucht mindestens einen Anker im Alltag der Studierenden (Smartphone, WhatsApp, Foto, Instagram-Story, eigener Laptop, eigener Browser, eigene Hex-Farbe). Theorie ohne Anker streichen oder umbauen.
+3. **Erstes fundiertes Wissen und Gefühl für Technik.** Nicht Auswendiglernen. Nicht „Klausurwissen". Ein belastbarer mentaler Bauplan, der sich später erweitern lässt. Konsequenz: lieber drei Konzepte in Tiefe als zwölf in Breite. Vereinfachen ist erlaubt, solange das Modell nicht falsch wird.
+
+### Didaktische Werkzeuge, die wir anwenden
+
+- **Constructive Alignment (Biggs):** Lernziele → Aktivitäten → Prüfung → Folien (in dieser Reihenfolge). Keine Folien-Restrukturierung ohne benannte Lernziele.
+- **Advance Organizer (Ausubel):** Jeder Themenblock öffnet mit einem visuellen Schema, das die Struktur des Bogens (nicht ein konkretes Beispiel) zeigt. Ankert Vorwissen, gibt Orientierung.
+- **Mayer Multimedia (12 Prinzipien):** Coherence (Deko-frei), Signaling (visuelle Cues), Redundancy-Vermeidung (Folientext ≠ Vorlesungstext), Spatial Contiguity (Text + Bild zusammen), Pre-Training (Grundbegriffe vor Komplexem), Personalisation.
+- **Informatikdidaktik (Magenheim / Romeike / Hartmann):** Abstrakt-Konkret-Brücke ist nicht optional, sondern Pflicht. Beispiele aus der Lebenswelt zuerst, Formalisierung danach.
+
+### Validierungs-Kriterien (vor Commit / Deploy prüfbar)
+
+Jede neue oder geänderte Folie soll folgende Fragen positiv beantworten können:
+
+- [ ] Welches der drei Meta-Lernziele bedient diese Folie?
+- [ ] Welches konkrete Lernziel des Themenblocks (formuliert mit Verb: analysieren, identifizieren, herleiten, begründen, einordnen, anwenden) wird hier vorbereitet, gestützt oder geprüft?
+- [ ] Gibt es einen Berührungspunkt zur Lebenswelt der Studierenden auf dieser Folie oder im direkten Umfeld?
+- [ ] Würde ein Student ohne Vorkenntnisse den Begriffsapparat dieser Folie verstehen — oder gibt es ungeöffnete Insider-Sprache?
+- [ ] Folientext ≠ wortwörtlicher Vorlesungstext (Mayer Redundancy)?
+- [ ] Wäre die Folie ohne den vorhergehenden Block verständlich? (Sollte NEIN sein — Folien sind nicht Inseln, sondern Schritte.)
+
+Wenn eine dieser Fragen verneint wird: nicht committen, sondern umbauen oder begründen warum die Ausnahme akzeptabel ist.
+
+### Anti-Pattern, die wir vermeiden
+
+- **Bullet-Vorlesen:** Folientext ist nicht das, was der Dozent sagt. Es ist der visuelle Anker für das, was der Dozent sagt.
+- **Motivations-Cringe:** Keine Anbiederung an Studierende durch billige Provokationen („Wer hat schon mal..." als Selbstzweck). Anker müssen substanziell sein.
+- **Theorie-First:** Niemals Definition vor Beispiel, wenn das Beispiel die Definition selbst-erklärend macht.
+- **Folien-Patchen:** Bei kaputtem Bogen keine Brücken-Folien einbauen — sondern die Lernziel-Struktur prüfen und ggf. den ganzen Block neu denken.
+
 ## Agent Restrictions
 
 - Agent NEVER runs commands outside this folder

README.md

@@ -4,11 +4,21 @@ Combined presentation slides for DHBW and HdM Stuttgart courses, built with [Mar
 
 ## Courses
 
-| Code | Title | Origin |
-|------|-------|--------|
-| 223015b | Dateiformate, Schnittstellen, Speichermedien | HdM |
-| 223015c | Internettechnologien | HdM |
-| dhbw | Technik I – Grundlagen IT | DHBW |
+| Code | Title | Origin | Fokus |
+|------|-------|--------|-------|
+| 223015b | Dateiformate, Schnittstellen, Speichermedien | HdM | **Dateien und Inhalte** |
+| 223015c | Internettechnologien | HdM | **Internet und Web** |
+| dhbw | Technik I – Grundlagen IT | DHBW | Grundlagen |
+
+## Didaktisches Fundament (HdM)
+
+Drei Meta-Lernziele bilden den Maßstab für jede inhaltliche Entscheidung:
+
+1. **Gelernte Hilflosigkeit ablegen** — Technik ist kein Mysterium. Keine Insider-Sprache ohne Erklärung; abstrakte Konzepte über konkrete Beispiele.
+2. **Berührungspunkte schaffen** — Inhalte mit der Lebenswelt der Studierenden verknüpfen. Jedes Kapitel braucht mindestens einen Alltags-Anker.
+3. **Erstes fundiertes Wissen und Gefühl für Technik** — kein Auswendiglernen, sondern ein belastbarer mentaler Bauplan. Lieber drei Konzepte in Tiefe als zwölf in Breite.
+
+Die operative Umsetzung (Werkzeuge, Validierungs-Kriterien, Anti-Pattern) ist in [CLAUDE.md](./CLAUDE.md#didaktisches-fundament-für-alle-hdm-kurse) dokumentiert und gilt für alle Beiträge — menschlich wie agentisch.
 
 ## Project Structure
 

docs/223015b-lernziele.md

@@ -0,0 +1,112 @@
+# Lernziele 223015b — Dateiformate, Schnittstellen, Speichermedien
+
+**Status:** Vorschlag für Dozent-Review (Phase 1, 2026-05-14)
+**Kurs-Fokus:** Dateien und Inhalte
+**Klausur-Blöcke gelockt:** 9 Blöcke (siehe `docs/klausur-themen-2026.md`)
+
+Die Lernziele sind als **Vorschläge** formuliert — der Dozent setzt die endgültige Latte. Default-Ambitionslevel: Verstehen/Unterscheiden/Einordnen, nicht Berechnen.
+
+---
+
+## Meta-Lernziele (aus CLAUDE.md)
+
+- Studierende legen gelernte Hilflosigkeit ab. Technik ist kein Mysterium.
+- Studierende verknüpfen das Material mit ihrer eigenen Lebenswelt.
+- Studierende verfügen über erstes fundiertes Wissen und Gefühl für Technik.
+
+---
+
+## Hinweis zur Begriffsverwendung „Block"
+
+Ein **Klausur-Block** in diesem Dokument ist ein **thematischer Lernziel-Cluster** — z.B. „Block 1: Datenfundamentale" fasst alle Lernziele rund um Bit/Byte/Hex/Encoding/Magic Numbers zusammen. Das entspricht der bestehenden Konvention in `klausurfragen.md` (BLOCK J, K, L, …).
+
+**Wichtig:** Die einzelnen klausur-markierten Folien (`<!-- _class: klausur -->`) bleiben über den Vorlesungs-Fluss **verstreut** — sie werden im pädagogischen Kontext erlebt, nicht als physischer Klausur-Abschnitt am Kapitelende gesammelt. Die Auto-Extraktion via `make klausur-223015b` fasst sie für die Prüfungs-Repetition zusammen, ohne die Vorlesungs-Reihenfolge zu verändern.
+
+---
+
+## Operative Lernziele pro Klausur-Block
+
+### Block 1 — Datenfundamentale
+
+- Studierende können den Wert einer Byte-Zahl in Binär, Dezimal und Hex erkennen und zuordnen, in welcher Schreibweise sie ihnen typischerweise begegnet (CSS-Farbcodes, Hex-Editor, Programmcode).
+- Studierende können die Beziehung zwischen Bit, Byte, Nibble und Hex-Ziffer erklären.
+- Studierende können nachvollziehen, warum ein deutscher Umlaut in UTF-8 mehr Speicher braucht als ein englischer Buchstabe und ein Emoji noch mehr.
+- Studierende können in einem Hex-Dump die ersten Byte einer Datei als Format-Signatur erkennen und daraus das Dateiformat ableiten.
+- Studierende können einordnen, warum eine als „1 TB" verkaufte SSD im Betriebssystem als „931 GB" erscheint.
+
+### Block 2 — Vom Signal zum Byte
+
+- Studierende können Abtastung und Quantisierung am Beispiel einer Audio-Aufnahme erklären.
+- Studierende können die Größenordnung des Speicherbedarfs einer Audio-Aufnahme aus Abtastrate und Bittiefe abschätzen.
+- Studierende können einordnen, warum CDs mit 44,1 kHz abgetastet werden und nicht mit weniger.
+- Studierende können Aliasing als Phänomen erkennen — sowohl als Klang-Artefakt in alten MP3s als auch als Moiré-Muster auf Hemden im Fernsehen.
+
+### Block 3 — Kompression: Prinzipien
+
+- Studierende können verlustfreie und verlustbehaftete Kompression bei Text, Audio, Bild und Video unterscheiden.
+- Studierende können an einem einfachen Muster zeigen, wie Lauflängenkodierung (RLE) Wiederholungen kompakter darstellt.
+- Studierende können für ein Anwendungsszenario (Foto-Backup, Streaming, Code-Archiv) begründen, ob Lossless oder Lossy sinnvoller ist.
+- Studierende können Psychoakustik und Psychovisualität als Grundlage einordnen, warum Lossy-Kompression überhaupt funktioniert.
+
+### Block 4 — Bilder: Raster und Vektor
+
+- Studierende können Raster- und Vektorgrafiken anhand von Skalierungsverhalten und typischen Anwendungen unterscheiden (Logo vs Foto).
+- Studierende können die sechs Stationen der JPEG-Pipeline benennen und je in einem Satz erklären, was dort passiert (Farbraum → Subsampling → Blöcke → DCT → Quantisierung → Huffman).
+- Studierende können erklären, was eine Quantisierungstabelle bei JPEG bewirkt und warum hohe Frequenzen zuerst geopfert werden.
+- Studierende können für ein Bildanliegen (Logo, Foto, Screenshot, Icon, animierte Reaktion) das passende Format begründet auswählen.
+- Studierende können einordnen, warum sich WebP schneller verbreitet hat als JPEG XL, obwohl JPEG XL technisch im Vorteil ist.
+
+### Block 5 — Audio
+
+- Studierende können den MP3-Trick (Maskierung, Hörschwelle) als gezieltes Auslassen für Menschen unhörbarer Anteile erklären.
+- Studierende können die Spotify-Streaming-Bitrate-Stufen (Normal/Hoch/Sehr hoch) mit dem hörbaren Qualitätsunterschied und dem Datenvolumen verknüpfen.
+- Studierende können für ein Audio-Anliegen (Spotify-Stream, Studio-Master, Sprachnachricht, Podcast) das passende Format begründet auswählen.
+
+### Block 6 — Video
+
+- Studierende können Container und Codec trennen: eine .mp4-Datei ist nur die Hülle, drinnen können H.264, H.265 oder AV1 stecken.
+- Studierende können I-, P- und B-Frames auseinanderhalten und erklären, warum Video so viel besser komprimiert als eine Folge einzelner Bilder.
+- Studierende können einordnen, warum AV1 als offener Standard gegen die Patent-Pools von H.265 entstanden ist (Alliance for Open Media).
+- Studierende können die Größenordnung der Bitrate eines 4K-Streams gegen die übliche Internet-Bandbreite stellen.
+
+### Block 7 — Speichermedien
+
+- Studierende können HDD und SSD anhand von Mechanik, Latenz, Lebensdauer und Preis pro Terabyte unterscheiden.
+- Studierende können für ein Anwendungsszenario (OS-Disk, Foto-Archiv, Server-Storage, Backup-Medium) HDD oder SSD begründet wählen.
+- Studierende können die wichtigsten Filesystem-Familien (FAT32, exFAT, NTFS, APFS, ext4) ihren typischen Anwendungsbereichen zuordnen.
+- Studierende können die 3-2-1-Backup-Regel erklären und auf den eigenen Foto-Archiv-Fall anwenden.
+
+### Block 8 — Schnittstellen
+
+- Studierende können bei einer USB-C-Verbindung zwischen Stecker, Kabel und Protokoll unterscheiden und erklären, warum nicht jedes USB-C-Kabel jeden USB-C-Anwendungsfall trägt.
+- Studierende können für ein Anwendungsszenario (4K-Monitor anschließen, SD-Karte auslesen, Laptop laden) die passende Schnittstelle wählen.
+- Studierende können HDMI, DisplayPort, Thunderbolt, Ethernet und WiFi anhand typischer Bandbreite und Anwendung einordnen.
+
+### Block 9 — Distribution & Metadaten
+
+- Studierende können das CDN-Prinzip am Beispiel Netflix Open Connect erklären (PoPs, Edge-Caching, geografische Verteilung).
+- Studierende können bei einer REST-API erkennen, welche Operation (GET/POST/PUT/DELETE) zu welcher Absicht passt.
+- Studierende können in EXIF- oder ID3-Metadaten enthaltene Informationen als Privacy-Risiko erkennen (McAfee-GPS-Fall, Blair-PDF-Fall).
+- Studierende können Vendor-Lockin-Effekte proprietärer Formate (Adobe PSD, Apple .pages) als Risiko einordnen.
+
+---
+
+## Kapitel-Mapping (5 Kapitel)
+
+| Kap | Titel | bedient Blöcke | Kern-Bogenkonzept |
+|-----|-------|----------------|--------------------|
+| **01** | Datenfundamentale + Signal zum Byte | Block 1 + 2 | Zahlen, Notation, Encoding, Sampling — die Atome |
+| **02** | Kompression: Prinzipien und Pipelines | Block 3 | Redundanz vs Irrelevanz, RLE und Psycho-* |
+| **03** | Inhalte: Bild, Audio, Video | Block 4 + 5 + 6 | Pipelines + Format-Wahl |
+| **04** | Speicher und Schnittstellen | Block 7 + 8 | Wie Bytes physikalisch existieren und reisen |
+| **05** | Distribution und Metadaten | Block 9 | Wie Bytes zur Endnutzerin kommen, was sie verraten |
+
+---
+
+## Validierungs-Status
+
+- [x] Pro Block 3–5 Vorschläge
+- [x] Default-Ambitionslevel: Verstehen/Unterscheiden, nicht Berechnen
+- [x] Anker im Studierenden-Alltag wo sinnvoll
+- [ ] Dozent-Review und Lock
+- [ ] Phase 2: Folien-Skelett pro Kapitel

docs/223015b/01-datenfundamentale-bogen.md

@@ -0,0 +1,131 @@
+# Kapitel 1 — Datenfundamentale + Signal zum Byte
+
+**Bedient Klausur-Blöcke:** 1 (Datenfundamentale) + 2 (Vom Signal zum Byte)
+**Slide-Budget:** ~40 (90-min-Termin)
+
+## Bogen
+
+Eine Stunde, eine Frage: **„Was steckt in einer Datei, und wie kommt es da rein?"**
+
+1. Wir öffnen mit dem Alltag: Foto, Sprachnachricht, PDF. Drei vertraute Dinge — alle haben dasselbe Innenleben.
+2. Wir machen eine Datei roh auf (Hex-Editor) und sehen: Zahlen. Nichts als Zahlen.
+3. Wir lernen die Zahlen lesen (Bit/Byte/Hex als drei Schreibweisen einer Sache).
+4. Wir lernen, was die Zahlen *bedeuten* (ASCII → Unicode → Magic Numbers).
+5. Pivot: aber wie kommen die Zahlen überhaupt in die Datei? Wenn man ein Foto macht, eine Stimme aufnimmt — Signal aus der Welt → Zahl.
+6. Sampling und Quantisierung — die zwei Schritte, die jedes Signal digitalisieren.
+7. Rechnung am CD-Beispiel, Nyquist-Theorem als Begründung warum gerade 44,1 kHz.
+8. Aliasing als „was schiefgehen kann" — Audio-Knack und Moiré als gleiches Phänomen in zwei Modalitäten.
+
+## Advance Organizer (Eröffnungs-Folie, NEU)
+
+Visuelles Schema, das den ganzen Bogen zeigt — keine konkrete Datei, sondern die Bewegung:
+
+```
+   Welt (analog)                 Datei (Byte-Strom)              Mensch (Bedeutung)
+        ╲                              ╱╲                              ╱
+         ╲   Sampling +                ╱  ╲   Notation (Hex)          ╱
+          ╲  Quantisierung            ╱    ╲  Encoding (ASCII/UTF-8) ╱
+           ╲                         ╱      ╲ Format (Magic Numbers) ╱
+            ▼                       ▼        ▼                      ▼
+        000101001001010001001110010100100111100100...
+```
+
+Aussage: dieses Kapitel überbrückt zwei Richtungen — *rein* (analog → digital) und *raus* (digital → bedeutsam). Beide treffen sich am Byte.
+
+→ neue Demo-Datei: `docs/223015b/assets/demos/kap01-advance-organizer.html`
+
+## Folien-Skelett
+
+| # | Typ | Titel/Kern | Lernziel | Berührungspunkt | Visualisierung |
+|---|-----|-----------|---------|-----------------|----------------|
+| 1 | Cover | Kapitel 1 — Datenfundamentale | — | — | reuse cover |
+| 2 | Lead | Was steckt in einer Datei? | Kapitel-Hook | Foto · Sprachnachricht · PDF | NEU collage |
+| 3 | Inhalt | Drei Dateien — dasselbe Innenleben | Hook | derselbe Trio | NEU mit Hex-Preview |
+| 4 | Advance Organizer | Welt → Datei → Bedeutung | Roter Faden | — | **NEU kap01-advance-organizer** |
+| 5 | Demo | WTF!? Rohe Bytes einer PNG-Datei | Schock-Hook | — | reuse matrix-code bg |
+| 6 | Inhalt | Eine Datei ist ein Byte-Strom | L1.2 | — | — |
+| 7 | Inhalt | Was ist ein Byte? 8 Bit, 256 Zustände | L1.2 | — | reuse why-8-bit |
+| 8 | Inhalt | Drei Schreibweisen, eine Zahl | L1.1 | — | reuse byte-fuer-byte |
+| 9 | Demo | Byte → Nibble → Hex | L1.1, L1.2 | — | reuse byte-nibble-hex |
+| 10 | Demo | Hex ↔ Dezimal-Tabelle | L1.1 | — | reuse hex-dec-table |
+| 11 | Inhalt | Lesbarkeit: 01010000 vs 50 | L1.1 | CSS-Farbe `#FF5733` | — |
+| 12 | Inhalt | Wo trifft man Hex im Alltag | L1.1 | CSS · MAC · Errorcode · Unicode | reuse hex-im-alltag-table |
+| 13 | Demo | Bin/Hex/ASCII parallel | L1.1, L1.3 | — | reuse byte-flow |
+| 14 | Demo | 8 Byte einer PNG, drei Sichten | L1.3, L1.4 | — | reuse three-views |
+| 15 | Lead | Was bedeutet die Zahl 80? | Übergang zu Encoding | — | — |
+| 16 | Inhalt | ASCII (1963, 7 Bit, 128 Zeichen) | L1.3 | — | reuse ascii-table |
+| 17 | Inhalt | ASCII reicht für Englisch — aber? | L1.3 | ä, é, 中, 🌸 | — |
+| 18 | Inhalt | Unicode + UTF-8 (1991, variable Länge) | L1.3 | — | — |
+| 19 | Demo | Byte zählen: 29 Zeichen, 42 Byte | L1.3 | „Hello·🌸·こんにちは" | reuse byte-zählen-tabelle |
+| 20 | Lead | Wie weiß der Computer was das ist? | Übergang zu Magic | — | — |
+| 21 | Inhalt | Magic Numbers — erste Byte verraten Format | L1.4 | 89 50 4E 47 = PNG | reuse what-the-hex |
+| 22 | Demo | Echte Datei im Hex-Editor | L1.4 | hexed.it im Browser | reuse hex-code |
+| 23 | Demo | Zoom: ein Byte „P" | L1.1, L1.4 | — | reuse 8bit-P-character |
+| 24 | Selbstlernen | hex-Datei identifizieren | L1.4 | — | bestehende Übung |
+| 25 | Inhalt | KB vs KiB — warum 931 GB? | L1.5 | 1-TB-SSD-Etikett | NEU diagram |
+| 26 | Inhalt | Dateneinheiten-Übersicht | L1.5 | — | reuse dateneinheiten-table |
+| 27 | **Pivot** | Aber wie kommen die Bytes da rein? | Strang-Wechsel | — | NEU split-pivot-folie |
+| 28 | Inhalt | Analog vs Digital — Druckwelle als Beispiel | L2.1 | — | reuse druckwelle |
+| 29 | Inhalt | Sampling: Wie oft messen wir? | L2.1 | — | reuse sampling |
+| 30 | Demo | Sampling-Animation | L2.1 | — | reuse sampling-grid |
+| 31 | Inhalt | Quantisierung: Wie genau? | L2.1 | — | reuse quantisierung |
+| 32 | Demo | Quantisierungsstufen | L2.1 | — | reuse quantisierung-stufen |
+| 33 | Inhalt | Datenrate = Abtastrate × Bittiefe × Kanäle | L2.2 | CD-Audio · Spotify | — |
+| 34 | Inhalt | CD-Audio: 44,1 kHz × 16 bit × 2 = 1,4 Mbit/s | L2.2 | — | — |
+| 35 | Inhalt | Nyquist-Theorem | L2.3 | — | NEU nyquist-diagram |
+| 36 | Inhalt | Warum gerade 44,1 kHz | L2.3 | — | — |
+| 37 | Inhalt | Aliasing — wenn Sampling zu grob | L2.4 | Klang-Knack · Moiré | NEU aliasing-paar (audio + bild) |
+| 38 | Demo | Aliasing live: Spotify-Bitrate-Vergleich | L2.4 | Spotify-Stream-Setting | NEU oder reuse |
+| 39 | Selbstlernen | Audacity-Sample-Rate-Vergleich | L2.1, L2.4 | — | bestehende Übung |
+| 40 | Zusammenfassung | Was wir in 90 Minuten gelernt haben | alle | — | NEU summary-organizer |
+
+## Selbstlernen Übungen (mindestens eine, hier zwei)
+
+- **Übung 1 (~10 min):** In hexed.it eine vom Dozenten bereitgestellte Datei ohne Endung öffnen, anhand der ersten Byte das Format identifizieren. Spielt L1.4 (Magic Numbers).
+- **Übung 2 (~10 min):** In Audacity eine kurze Aufnahme machen, dann auf 8 kHz / 22 kHz / 44,1 kHz resamplen und hören. Spielt L2.1, L2.3, L2.4.
+
+## Streichungs-Liste (Folien aus dem aktuellen Stand, die wegfallen)
+
+Aus dem aktuellen `01-grundlagen-text-audio.md` (~120 Slides) werden in der neuen Version Folgendes gestrichen oder verlagert:
+
+- **Datenwachstum der Menschheit / Zettabyte** — gehört konzeptuell in Kap 0 (Intro/Motivation), nicht in Datenfundamentale
+- **Bandbreite-Mathematik-Slides** (3 Stück) — gehört in Speicher/Schnittstellen-Kapitel, nicht hier
+- **Upload Flaschenhals** — gehört in Speicher-/Schnittstellen-Kapitel
+- **Kompressionsraten Tabelle** + **Album-MB-Größe** + **Artemis-Slide** — gehört in Kapitel 2 (Kompression), nicht in Fundamentale
+- **„Verlustfreie/Verlustbehaftete Kompression"-Folien** (3 Slides + Vergleichstabelle) — gehört in Kapitel 2
+- **Vertiefungs-Folie Kompression mit Shannon-Entropy** — Klausurirrelevant, raus
+- **Bit/Byte Verwirrung (Mbit/s)** — gehört in Speicher/Schnittstellen
+- **CD-Audio Vertiefung** — eindampfen oder als Speaker-Note in Folie 34
+- **AI-generierte Inhalte 2025** — out (Zukunfts-Thema, per D2 gelockt)
+- **Bilder-Aspekt Folien (Pixel-Berechnungen)** — gehört in Kapitel 3 (Bilder)
+- **„Lossless für 35 Sek = 10 MB"-Audio-Beispiele** — eindampfen
+- **Diverse Vertiefungen die Hauptfolien wörtlich wiederholen** — alle raus (Mayer Redundancy)
+
+Geschätzte Reduktion: 120 → 40 Slides (-67%).
+
+## Visualisierungen — neu zu bauen
+
+| Demo-Datei | Was zeigt sie | Stil-Referenz |
+|------------|---------------|---------------|
+| `kap01-advance-organizer.html` | Welt → Datei → Bedeutung Schema | `three-views.html` |
+| `kb-vs-kib.html` | „1 TB" verkauft vs „931 GB" angezeigt | neue Tabelle + Erklärung |
+| `nyquist-diagram.html` | Sampling-Frequenz vs Signal-Frequenz | wissenschaftliches Diagramm |
+| `aliasing-paar.html` | Aliasing in Audio + Moiré in Bild parallel | zweispaltig |
+| `pivot-signal-zu-byte.html` | „aber wie kommen die Bytes rein?" — Übergangsbild | NEU |
+| `summary-organizer.html` | Zusammenfassung am Kapitel-Ende | reuse advance-organizer-Stil, alle Konzepte erfüllt |
+
+Reuse-Demos (alle in `slides/223015b/assets/demos/`):
+- byte-fuer-byte, byte-nibble-hex, hex-dec-table, byte-flow, three-views
+- why-8-bit, ascii-table-colored, hex-code, 8bit-P-character
+
+## Validierungs-Status
+
+- [x] Bogen formuliert (eine Stunde, eine Frage)
+- [x] Advance Organizer skizziert
+- [x] Folien-Skelett mit Lernziel-Bezug pro Folie
+- [x] Mindestens ein Selbstlernen (hier zwei)
+- [x] Streichungsliste mit Begründungen
+- [x] Visualisierungs-TODO mit Reuse-Markierung
+- [ ] Dozent-Review und Lock
+- [ ] Phase 3: Visualisierungen bauen
+- [ ] Phase 4: Folien schreiben

docs/223015b/02-kompression-bogen.md

@@ -0,0 +1,100 @@
+# Kapitel 2 — Kompression: Prinzipien und Pipelines
+
+**Bedient Klausur-Block:** 3 (Kompression: Prinzipien)
+**Slide-Budget:** ~22 (90-min-Termin, das kürzeste Kapitel — Vorbereitung für Kapitel 3)
+
+## Bogen
+
+Eine Stunde, eine Frage: **„Wie machen wir Daten kleiner — und was darf dabei verloren gehen?"**
+
+1. Wir öffnen mit dem Alltag: WhatsApp-Bild vs Original-Foto (Dateigröße-Schock).
+2. Zwei fundamental verschiedene Wege werden eingeführt: Redundanz raus (verlustfrei) vs Irrelevanz raus (verlustbehaftet).
+3. Verlustfrei wird an RLE durchgespielt — manuell, am Whiteboard, anfassbar.
+4. Verlustbehaftet wirft die Frage auf: was darf verloren gehen? Antwort kommt aus der Wahrnehmungsforschung — Psychoakustik (Audio), Psychovisualität (Bild). Hier nur das Prinzip, die Pipelines folgen in Kap 3.
+5. Entscheidungsmatrix für den Alltag: Foto-Archiv (Lossless), Streaming (Lossy), Code-Repo (Lossless), Backup (kommt drauf an).
+6. Selbstlernen: ZIP-Test mit drei Dateitypen, der zeigt warum schon-komprimierte Dateien nicht weiter komprimieren.
+
+## Advance Organizer
+
+```
+                   Daten sind unhandlich.
+                          │
+              ┌───────────┴───────────┐
+              ▼                       ▼
+       VERLUSTFREI               VERLUSTBEHAFTET
+       Redundanz raus            Irrelevanz raus
+       (umkehrbar)               (nicht umkehrbar)
+              │                       │
+         RLE · Huffman           Psychoakustik (MP3)
+         ZIP · PNG · FLAC        Psychovisualität (JPEG)
+              │                       │
+              └───────────┬───────────┘
+                          ▼
+                   Wann was?
+                   (Entscheidungsmatrix)
+```
+
+→ neue Demo-Datei: `kap02-kompression-bogen.html`
+
+## Folien-Skelett
+
+| # | Typ | Titel/Kern | Lernziel | Berührungspunkt | Visualisierung |
+|---|-----|-----------|---------|-----------------|----------------|
+| 1 | Cover | Kapitel 2 — Kompression | — | — | reuse cover |
+| 2 | Lead | Daten sind unhandlich | Hook | WhatsApp · Spotify · ZIP | — |
+| 3 | Inhalt | Foto-Größenschock | Hook | Original 12 MB → WhatsApp 200 KB | NEU vergleich |
+| 4 | Advance Organizer | Zwei Wege der Kompression | Roter Faden | — | **NEU kap02-bogen** |
+| 5 | Lead | Verlustfrei (Lossless) | L3.1 | — | — |
+| 6 | Inhalt | Prinzip: Redundanz raus, umkehrbar | L3.1 | — | — |
+| 7 | Demo | RLE manuell: AAAAABBBCCCCCCCC → 5A3B8C | L3.2 | — | reuse RLE-Beispiel |
+| 8 | Inhalt | Wo wird Lossless eingesetzt | L3.1, L3.3 | ZIP · PNG · FLAC · RAW | — |
+| 9 | Inhalt | LV-Tasche-Analogie: Original vs Fälschung | L3.1 | — | reuse lv-original-vs-fake |
+| 10 | Lead | Verlustbehaftet (Lossy) | L3.1 | — | — |
+| 11 | Inhalt | Prinzip: Irrelevanz raus, nicht umkehrbar | L3.1, L3.4 | Spotify-Stream | — |
+| 12 | Inhalt | Was nimmt ein Mensch nicht wahr? | L3.4 | — | — |
+| 13 | Inhalt | Psychoakustik: Maskierung, Hörschwelle | L3.4 | Vorgriff auf MP3 | NEU psychoakustik-grafik |
+| 14 | Inhalt | Psychovisualität: Luminanz vor Chrominanz | L3.4 | Vorgriff auf JPEG | NEU psychovisualität-grafik |
+| 15 | Inhalt | Wo wird Lossy eingesetzt | L3.1, L3.3 | MP3 · JPEG · H.264 · WebP | — |
+| 16 | Klausur | Vergleichstabelle Lossless vs Lossy | L3.1, L3.3 | — | reuse vergleichstabelle |
+| 17 | Demo | Bild in 100% / 50% / 10% Qualität | L3.3 | — | reuse jpeg-qualität-vergleich |
+| 18 | Inhalt | Kompressionsraten in der Praxis | L3.1 | Song 10× · Foto 12× · 4K-Video 120× | reuse kompressionsraten-tabelle |
+| 19 | Inhalt | Wann verwendet man was? | L3.3 | Foto-Archiv · Stream · Code · Backup | NEU entscheidungsmatrix |
+| 20 | Selbstlernen | ZIP-Test: txt vs bmp vs jpeg | L3.1, L3.2, L3.3 | — | — |
+| 21 | Inhalt | Warum komprimiert ZIP-auf-JPEG nicht mehr | L3.1, L3.2 | — | — |
+| 22 | Zusammenfassung | Was wir gelernt haben | alle B3 | — | NEU summary |
+
+## Selbstlernen Übung
+
+- **ZIP-Test (~10 min):** Drei Dateien gleicher Originalgröße zippen: (a) Textdatei mit wiederholten Mustern, (b) unkomprimierte BMP, (c) JPEG. Vergleich der ZIP-Größen liefert die Aha-Erkenntnis: schon-komprimierte Dateien lassen sich nicht weiter komprimieren (Entropie-Grenze ohne Mathematik).
+
+## Streichungs-Liste (Verlagerungen aus Kap 1)
+
+Aktuell stehen diese Inhalte in `01-grundlagen-text-audio.md` und werden hierher verschoben (nicht erfunden):
+- Verlustfreie/Verlustbehaftete Kompression (3 Slides + Vergleichstabelle)
+- Kompressionsraten-in-der-Praxis-Tabelle
+- LV-Original-vs-Fake-Bridge-Folie
+
+Diese Vertiefungen entfallen:
+- Vertiefungs-Slide „Claude Shannon Entropie"-Math — Klausurirrelevant, raus
+- „Cola-Sirup für Sodastream"-Analogie-Sammlung in Speaker-Notes — Auswahl reduzieren auf max 2 Analogien
+
+## Visualisierungen — neu zu bauen
+
+| Demo-Datei | Was zeigt sie |
+|------------|---------------|
+| `kap02-bogen.html` | Advance Organizer für Kompression |
+| `psychoakustik-grafik.html` | Maskierung visualisieren (lauter Ton überdeckt leisen) |
+| `psychovisualität-grafik.html` | Luminanz-Detail vs Chrominanz-Detail nebeneinander |
+| `entscheidungsmatrix-kompression.html` | Wann-was-Tabelle (Archiv/Stream/Code/Backup) |
+| `summary-kap02.html` | Zusammenfassung |
+
+Reuse: lv-original-vs-fake, RLE-Beispiel, kompressionsraten-tabelle, vergleichstabelle (alle in Bestand).
+
+## Validierungs-Status
+
+- [x] Bogen formuliert
+- [x] Advance Organizer skizziert
+- [x] Folien-Skelett mit Lernziel-Bezug
+- [x] Selbstlernen geplant
+- [x] Verlagerungen aus Kap 1 dokumentiert
+- [ ] Dozent-Review und Lock

docs/223015b/03-inhalte-bild-audio-video-bogen.md

@@ -0,0 +1,173 @@
+# Kapitel 3 — Inhalte: Bild, Audio, Video
+
+**Bedient Klausur-Blöcke:** 4 (Bilder) + 5 (Audio) + 6 (Video)
+**Slide-Budget:** ~49 (das umfangreichste Kapitel, ggf. 2 Vorlesungstermine)
+
+## Bogen
+
+Eine längere Sitzung (oder zwei), eine Linie: **„Drei Modalitäten — Bild, Audio, Video — drei Pipelines, drei Format-Politiken. Was passiert technisch und was politisch, und wie wählt man im Alltag?"**
+
+1. Wir öffnen damit, dass *alle drei* Modalitäten Lossy-Kompression nutzen — und dass diese Lossy-Kompression nur funktioniert weil sie Wahrnehmungs-Lücken ausnutzt. Brücke zu Kapitel 2 (Psychoakustik/Psychovisualität).
+2. **Bilder** zuerst — am stärksten visualisierbar, JPEG-Pipeline ist die didaktische Königsdisziplin. Alle 6 Schritte durchspielen.
+3. **Audio** als zweite Modalität — MP3-Trick konkret, Spotify-Stufen am Handy, Format-Wahl-Matrix.
+4. **Video** als „Bild + Zeit". Container/Codec-Trennung als entscheidendes Konzept. I/P/B-Frames. Patent-Politik (AV1 vs HEVC) als Industrie-Geschichte.
+
+## Advance Organizer
+
+```
+                Wahrnehmung als Hebel (aus Kap 2)
+                          │
+              ┌───────────┼───────────┐
+              ▼           ▼           ▼
+            BILD        AUDIO       VIDEO
+              │           │           │
+       Raster/Vektor   Sampling    Container
+       JPEG-Pipeline   MP3-Trick   + Codec
+       Format-Wahl     Format-Wahl I/P/B
+              │           │           │
+              └───────────┴───────────┘
+                          │
+                 Patent · Adoption · Politik
+                  (JPEG XL · WebP · AV1)
+```
+
+→ neue Demo-Datei: `kap03-modalitäten-bogen.html`
+
+## Folien-Skelett
+
+### Eröffnung (3 Slides)
+
+| # | Typ | Titel/Kern | Lernziel | Berührungspunkt | Visualisierung |
+|---|-----|-----------|---------|-----------------|----------------|
+| 1 | Cover | Kapitel 3 — Inhalte: Bild, Audio, Video | — | — | reuse |
+| 2 | Lead | Drei Modalitäten, ein Prinzip | Hook | Instagram · Spotify · YouTube | NEU collage |
+| 3 | Advance Organizer | Wahrnehmung als gemeinsamer Hebel | Roter Faden | — | **NEU kap03-bogen** |
+
+### Sub-Sektion A — Bilder (18 Slides, bedient Block 4)
+
+| # | Typ | Titel/Kern | Lernziel | Berührungspunkt | Visualisierung |
+|---|-----|-----------|---------|-----------------|----------------|
+| 4 | Lead | Bilder | — | — | — |
+| 5 | Inhalt | Pixel — ein Bild als Zahlen-Gitter | L4.1 | Smartphone-Foto-Auflösung | NEU pixel-gitter |
+| 6 | Inhalt | Rastergrafik: viele Pixel | L4.1 | Smartphone-Foto | NEU raster-zoom |
+| 7 | Inhalt | Vektorgrafik: mathematische Anweisungen | L4.1 | Logo · Icon | NEU vektor-skalierung |
+| 8 | Klausur | Raster vs Vektor (Tabelle + Skalierung) | L4.1 | — | reuse vergleichs-tabelle |
+| 9 | Inhalt | Wann welches? | L4.1, L4.4 | Logo (V), Foto (R), Icon (V) | — |
+| 10 | Lead | JPEG: das Foto-Workhorse seit 1992 | — | — | — |
+| 11 | Inhalt | JPEG-Pipeline-Übersicht (6 Schritte) | L4.2 | — | NEU pipeline-übersicht |
+| 12 | Inhalt | Schritt 1: RGB → Y'CbCr (Farbraumkonversion) | L4.2 | — | reuse yuv-zerlegung |
+| 13 | Inhalt | Schritt 2: Chroma-Subsampling 4:2:0 | L4.2 | — | NEU chroma-subsampling-grafik |
+| 14 | Inhalt | Schritt 3: 8×8 Blöcke | L4.2 | — | NEU block-aufteilung |
+| 15 | Inhalt | Schritt 4: DCT (Diskrete Kosinus-Transformation) | L4.2, L4.3 | — | NEU dct-frequenzraum |
+| 16 | Inhalt | Schritt 5: Quantisierung | L4.2, L4.3 | — | NEU quantisierungstabelle |
+| 17 | Inhalt | Schritt 6: Huffman-Coding | L4.2 | — | NEU huffman-zip |
+| 18 | Klausur | Die 6 Schritte als Memo-Liste | L4.2 | — | NEU |
+| 19 | Demo | JPEG-Artefakte sichtbar machen | L4.2, L4.3 | Squoosh im Browser | reuse jpeg-artifacts |
+| 20 | Lead | Andere Bildformate | — | — | — |
+| 21 | Inhalt | PNG · GIF · WebP · AVIF · SVG | L4.4 | — | reuse format-grid |
+| 22 | Klausur | Wann-welches-Format-Matrix | L4.4 | Logo · Foto · Screenshot · Icon · Animation | NEU entscheidungsmatrix |
+| 23 | Inhalt | Patent-Politik: warum WebP > JPEG XL | L4.5 | Chrome-Adoption · Apple | NEU patent-zeitleiste |
+
+### Sub-Sektion B — Audio (8 Slides, bedient Block 5)
+
+| # | Typ | Titel/Kern | Lernziel | Berührungspunkt | Visualisierung |
+|---|-----|-----------|---------|-----------------|----------------|
+| 24 | Lead | Audio | — | — | — |
+| 25 | Inhalt | Sampling + Bittiefe Recap | L5.1 | aus Kap 1 | — |
+| 26 | Inhalt | MP3-Trick: Maskierung | L5.1 | — | NEU maskierung-grafik |
+| 27 | Inhalt | MP3-Trick: Hörschwelle | L5.1 | — | NEU hörschwelle-grafik |
+| 28 | Inhalt | Bitrate-Stufen 128/192/320 kbit/s | L5.2 | Spotify-Setting | NEU bitrate-vergleich |
+| 29 | Inhalt | Audio-Format-Landschaft | L5.3 | WAV · MP3 · FLAC · AAC · OGG · Opus | NEU format-tabelle |
+| 30 | Klausur | Format-Wahl: Stream · Master · Sprachnachricht · Podcast | L5.3 | — | NEU entscheidungsmatrix-audio |
+| 31 | Demo | Spotify-Stream-Bitrate live anhören | L5.2 | Spotify-App | — |
+
+### Sub-Sektion C — Video (14 Slides, bedient Block 6)
+
+| # | Typ | Titel/Kern | Lernziel | Berührungspunkt | Visualisierung |
+|---|-----|-----------|---------|-----------------|----------------|
+| 32 | Lead | Video — Bild plus Zeit | — | — | — |
+| 33 | Inhalt | Pixel × Pixel × Hz = Datenflut | L6.4 | 4K@60fps roh | NEU datenflut-rechnung |
+| 34 | Klausur | **Container ≠ Codec** | L6.1 | .mp4 öffnen | NEU container-codec-trennung |
+| 35 | Inhalt | Was ist ein Container | L6.1 | MP4 · MKV · WebM | NEU container-anatomie |
+| 36 | Inhalt | Was ist ein Codec | L6.1 | H.264 · H.265 · VP9 · AV1 | — |
+| 37 | Inhalt | Inter-Frame-Kompression — die zentrale Idee | L6.2 | — | NEU inter-frame-diagram |
+| 38 | Klausur | I- · P- · B-Frames | L6.2 | — | reuse IPB-frame-diagram |
+| 39 | Inhalt | Motion Compensation | L6.2 | — | NEU motion-compensation |
+| 40 | Lead | Die Codec-Landschaft | — | — | — |
+| 41 | Inhalt | H.264 / AVC — der Workhorse | L6.3 | YouTube · Zoom | reuse h264-folie |
+| 42 | Inhalt | H.265 / HEVC — Patent-Chaos | L6.3 | Apple-Adoption | reuse h265-folie |
+| 43 | Inhalt | VP9 + AV1 — Antwort von Google + Alliance | L6.3 | YouTube-Streaming | reuse av1-folie |
+| 44 | Klausur | Patent vs Open: warum AV1 | L6.3 | Netflix · YouTube · Twitch | NEU patent-vergleich |
+| 45 | Inhalt | 4K-Stream-Bitrate vs Heim-Bandbreite | L6.4 | 25 Mbit/s eigener Anschluss | NEU bandbreite-vergleich |
+
+### Selbstlernen + Zusammenfassung (4 Slides)
+
+| # | Typ | Titel/Kern | Lernziel | Berührungspunkt | Visualisierung |
+|---|-----|-----------|---------|-----------------|----------------|
+| 46 | Selbstlernen | Bild in Squoosh.app komprimieren | L4.2, L4.4 | Squoosh im Browser | — |
+| 47 | Selbstlernen | MP3 vs FLAC unterscheidbar? | L5.1, L5.2 | Spotify HiFi-Test | — |
+| 48 | Selbstlernen | mediainfo auf eine Videodatei | L6.1, L6.2 | mediainfo CLI | — |
+| 49 | Zusammenfassung | Drei Modalitäten, gleiches Prinzip | alle | — | NEU summary |
+
+## Streichungs-Liste
+
+Aus dem aktuellen `02-bild-audio-video.md` (~70 Slides):
+- Diverse Vertiefungs-Slides die Hauptfolien wörtlich wiederholen — raus (Mayer Redundancy)
+- DCT-Math-Tiefe in einer eigenen Folie — eindampfen auf Schritt 4 (Slide 15)
+- Doppelte „Container vs Codec"-Folien — eine reicht (Slide 34)
+- AV1-Emmy-Award als eigene Folie — als Speaker-Note in Slide 43
+
+Aus dem aktuellen `01-grundlagen-text-audio.md` werden Bilder/Audio/Video-Folien hierher verschoben:
+- MP3-Psychoakustik-Slides
+- Sampling-Recap nur als Vorgriff (Recap statt Vollerklärung — die kam in Kap 1)
+
+## Visualisierungen — neu zu bauen
+
+| Demo-Datei | Was zeigt sie |
+|------------|---------------|
+| `kap03-modalitäten-bogen.html` | Advance Organizer drei Modalitäten |
+| `pixel-gitter.html` | Bild als Zahlen-Gitter |
+| `raster-zoom.html` | Rasterbild beim Skalieren pixelig |
+| `vektor-skalierung.html` | Vektorbild bleibt scharf |
+| `pipeline-übersicht.html` | JPEG 6 Schritte als Pipeline |
+| `chroma-subsampling-grafik.html` | 4:4:4 vs 4:2:0 visuell |
+| `dct-frequenzraum.html` | Bildblock im Frequenzraum |
+| `quantisierungstabelle.html` | Tabelle + Effekt |
+| `huffman-zip.html` | Huffman als finale Kompression |
+| `entscheidungsmatrix-bildformate.html` | Wann-welches-Bildformat |
+| `patent-zeitleiste.html` | JPEG XL vs WebP Adoption |
+| `maskierung-grafik.html` | Lauter-Ton-überdeckt-leisen |
+| `hörschwelle-grafik.html` | Hörschwelle im Frequenzraum |
+| `bitrate-vergleich.html` | 128/192/320 kbit/s mit Größenvergleich |
+| `format-tabelle-audio.html` | WAV/MP3/FLAC/AAC/OGG/Opus |
+| `entscheidungsmatrix-audio.html` | Wann-welches-Audio-Format |
+| `datenflut-rechnung.html` | 4K@60fps roh: Datenrate |
+| `container-codec-trennung.html` | MP4-Hülle, drinnen verschiedene Codecs |
+| `container-anatomie.html` | MP4-Container-Aufbau |
+| `inter-frame-diagram.html` | Inter-Frame als Konzept |
+| `motion-compensation.html` | Block aus vorigem Frame verschieben |
+| `patent-vergleich.html` | H.264/H.265/AV1 Patent-Politik |
+| `bandbreite-vergleich.html` | 4K-Bitrate vs Internet-Bandbreite |
+| `summary-kap03.html` | Zusammenfassung |
+
+Reuse: yuv-zerlegung, jpeg-artifacts, format-grid, IPB-frame-diagram, h264/h265/av1-Slides, vergleichs-tabelle (alle Bestand in `slides/223015b/assets/`).
+
+## Hinweis Zeitlich
+
+50 Slides für 90 Min ist eng (~1,8 min pro Slide inkl Erklärung). Optionen:
+- **Variante A:** Als zwei Termine planen (Termin 1: Bilder, Termin 2: Audio+Video). Sauberster pädagogischer Schnitt.
+- **Variante B:** In einem Termin durchziehen, Selbstlernens als Hausaufgabe.
+- **Variante C:** Audio kürzen (Sub-Sektion B als reduzierte Vertiefungs-Stunde mit Verweis auf Kap 1).
+
+Entscheidung Dozent.
+
+## Validierungs-Status
+
+- [x] Bogen formuliert
+- [x] Advance Organizer skizziert
+- [x] Folien-Skelett (3 Sub-Sektionen)
+- [x] Selbstlernen in jeder Sub-Sektion
+- [x] Streichungs-Liste
+- [x] Visualisierungs-TODO
+- [x] Zeit-Hinweis für Dozent
+- [ ] Dozent-Review und Lock

docs/223015b/04-speicher-schnittstellen-bogen.md

@@ -0,0 +1,125 @@
+# Kapitel 4 — Speicher und Schnittstellen
+
+**Bedient Klausur-Blöcke:** 7 (Speichermedien) + 8 (Schnittstellen)
+**Slide-Budget:** ~30 (90-min-Termin)
+
+## Bogen
+
+Eine Stunde, eine Frage: **„Wo wohnen die Bytes — und wie reisen sie zwischen Geräten?"**
+
+1. Wir öffnen mit dem eigenen Setup: Laptop hat SSD, Server hat HDDs, Handy hat Flash, externe Disk steht im Schrank. Jedes Medium löst ein anderes Problem — und alle haben Tradeoffs.
+2. **HDD und SSD** technisch ausgepackt: Mechanik vs Flash-Zellen, Latenz, Lebensdauer, Preis/TB. Entscheidungsmatrix.
+3. **Filesystems** als die Sprache, in der ein Speichermedium organisiert wird. FAT32 / NTFS / APFS / ext4 — wann was. USB-Stick-FAT32-Limit als Alltagsproblem.
+4. **Backup** als Praxis: 3-2-1-Regel am eigenen Foto-Archiv durchgespielt.
+5. **Pivot zu Schnittstellen** — wie kommen die Bytes von einem Medium zum anderen?
+6. **USB-C-Chaos** als zentrales Berührungs-Phänomen — drei separate Achsen (Stecker, Kabel, Protokoll) entwirren. Das ist die Aha-Folie.
+7. **HDMI · DisplayPort · Thunderbolt · Ethernet · WiFi** anhand Bandbreite und typischer Anwendung einordnen.
+
+## Advance Organizer
+
+```
+                Bytes wohnen + reisen
+                          │
+              ┌───────────┴───────────┐
+              ▼                       ▼
+          WO?  Speicher           WIE?  Schnittstellen
+              │                       │
+        HDD · SSD · Flash       USB-C · HDMI · DP
+        Filesystems             Thunderbolt
+        Backup 3-2-1            Ethernet · WiFi
+              │                       │
+              └───────────┬───────────┘
+                          ▼
+                   Anwendungs-Wahl
+```
+
+→ neue Demo-Datei: `kap04-bogen.html`
+
+## Folien-Skelett
+
+### Eröffnung (3 Slides)
+
+| # | Typ | Titel/Kern | Lernziel | Berührungspunkt | Visualisierung |
+|---|-----|-----------|---------|-----------------|----------------|
+| 1 | Cover | Kapitel 4 — Speicher und Schnittstellen | — | — | reuse |
+| 2 | Lead | Wo wohnen die Bytes, wie reisen sie? | Hook | Eigenes Setup im Hörsaal | — |
+| 3 | Advance Organizer | Wohnen + Reisen | Roter Faden | — | **NEU kap04-bogen** |
+
+### Sub-Sektion A — Speichermedien (15 Slides, Block 7)
+
+| # | Typ | Titel/Kern | Lernziel | Berührungspunkt | Visualisierung |
+|---|-----|-----------|---------|-----------------|----------------|
+| 4 | Lead | Speicher | — | — | — |
+| 5 | Inhalt | HDD: Magnetscheibe, Mechanik | L7.1 | externe Backup-Platte | reuse hdd-internals |
+| 6 | Inhalt | HDD: Spuren, Sektoren, Latenz | L7.1 | — | NEU hdd-anatomie |
+| 7 | Inhalt | SSD: Flash-Zellen, keine Mechanik | L7.1 | Laptop-SSD | reuse ssd-internals |
+| 8 | Inhalt | SSD: Schreibzyklen, Wear Leveling | L7.1 | — | NEU ssd-wear-leveling |
+| 9 | Klausur | HDD vs SSD: Vergleichstabelle | L7.1 | — | reuse hdd-ssd-comparison |
+| 10 | Klausur | Wann welches? Entscheidungsmatrix | L7.2 | OS-Disk · Foto-Archiv · Server · Backup | NEU entscheidungsmatrix-speicher |
+| 11 | Lead | Filesystems | — | — | — |
+| 12 | Inhalt | Was macht ein Filesystem? | L7.3 | USB-Stick formatieren | — |
+| 13 | Inhalt | FAT32 / exFAT / NTFS / APFS / ext4 | L7.3 | „warum kann ich 5-GB-Datei nicht auf USB ziehen" | reuse filesystem-vergleich |
+| 14 | Inhalt | Filesystem-Limits konkret | L7.3 | FAT32 4-GB-Grenze | NEU filesystem-limits |
+| 15 | Lead | Backup — die unangenehme Pflicht | — | — | — |
+| 16 | Inhalt | Pixar verlor Toy Story 2 fast | L7.4 | Pixar-Story | reuse backup-disaster |
+| 17 | Klausur | Die 3-2-1-Regel | L7.4 | eigenes Foto-Archiv | reuse 3-2-1 |
+| 18 | Inhalt | Backup-Typen: full · incremental · differential | L7.4 | — | NEU backup-typen |
+
+### Sub-Sektion B — Schnittstellen (12 Slides, Block 8)
+
+| # | Typ | Titel/Kern | Lernziel | Berührungspunkt | Visualisierung |
+|---|-----|-----------|---------|-----------------|----------------|
+| 19 | Pivot | Wie kommen Bytes von A nach B? | — | — | — |
+| 20 | Lead | USB-C — das Berührungspunkt-Phänomen | L8.1 | „warum lädt mein Laptop am einen Port und am anderen nicht" | — |
+| 21 | Klausur | **USB-C: drei separate Achsen** | L8.1 | — | NEU usb-c-drei-achsen |
+| 22 | Inhalt | Achse 1: Stecker (mechanisch) | L8.1 | — | NEU |
+| 23 | Inhalt | Achse 2: Kabel (was es kann) | L8.1 | Aldi-Kabel vs Apple-Kabel | NEU |
+| 24 | Inhalt | Achse 3: Protokoll (was drüber läuft) | L8.1 | USB 2/3, Thunderbolt | NEU |
+| 25 | Demo | „Warum lädt es nicht?" — drei Achsen prüfen | L8.1, L8.2 | — | — |
+| 26 | Inhalt | HDMI: Video + Audio + HDCP | L8.3 | Monitor anschließen | — |
+| 27 | Inhalt | DisplayPort: HDMI's offenes Pendant | L8.3 | — | — |
+| 28 | Inhalt | Thunderbolt: Tunnel für alles | L8.3 | Mac mit Hub | — |
+| 29 | Inhalt | Ethernet vs WiFi: Bandbreite + Latenz | L8.3 | Gaming · Streaming | NEU bandbreite-tabelle |
+| 30 | Klausur | Entscheidungsmatrix Schnittstellen | L8.2 | 4K-Monitor · SD-Karte · Laden | NEU |
+
+### Selbstlernen + Zusammenfassung (3 Slides)
+
+| # | Typ | Titel/Kern | Lernziel | Berührungspunkt | Visualisierung |
+|---|-----|-----------|---------|-----------------|----------------|
+| 31 | Selbstlernen | eigenes Backup-Konzept aufschreiben | L7.4 | eigene Foto-Library | — |
+| 32 | Selbstlernen | USB-C-Kabel-Check | L8.1, L8.2 | mitgebrachte Kabel | — |
+| 33 | Zusammenfassung | Wohnen + Reisen — Recap | alle B7+B8 | — | NEU summary |
+
+## Streichungs-Liste
+
+Aus dem aktuellen `03-speichermedien-schnittstellen.md` (~38 Slides) bleibt der Stoff größtenteils, aber:
+- Doppelte HDD/SSD-Vertiefungen — eine reicht (Slide 5+6, 7+8)
+- Schnittstellen-Slides ohne Bezug (z.B. legacy-Kabel-Sammlung) — raus
+- Wiederholte „latenz vs Throughput"-Slides — eindampfen
+
+## Visualisierungen — neu zu bauen
+
+| Demo-Datei | Was zeigt sie |
+|------------|---------------|
+| `kap04-bogen.html` | Advance Organizer Speicher+Schnittstellen |
+| `hdd-anatomie.html` | HDD-Schnitt: Platter, Heads, Spuren |
+| `ssd-wear-leveling.html` | SSD-Zellen, P/E-Zyklen, Wear Leveling |
+| `entscheidungsmatrix-speicher.html` | HDD/SSD pro Anwendungsfall |
+| `filesystem-limits.html` | Konkrete Limits (FAT32 4 GB, NTFS, ext4) |
+| `backup-typen.html` | full · incremental · differential visuell |
+| `usb-c-drei-achsen.html` | Stecker · Kabel · Protokoll als 3 unabhängige Dimensionen |
+| `bandbreite-tabelle.html` | HDMI/DP/TB/Ethernet/WiFi mit Bandbreite + Latenz |
+| `entscheidungsmatrix-schnittstellen.html` | Welche Schnittstelle für welchen Use Case |
+| `summary-kap04.html` | Zusammenfassung |
+
+Reuse: hdd-internals, ssd-internals, hdd-ssd-comparison, filesystem-vergleich, backup-disaster, 3-2-1 (alle Bestand).
+
+## Validierungs-Status
+
+- [x] Bogen mit klarem Pivot Speicher → Schnittstellen
+- [x] Advance Organizer
+- [x] Folien-Skelett (2 Sub-Sektionen + Selbstlernen)
+- [x] USB-C-Aufklärung als zentraler Berührungspunkt
+- [x] Streichungs-Liste
+- [x] Visualisierungs-TODO
+- [ ] Dozent-Review und Lock

docs/223015b/05-distribution-metadaten-bogen.md

@@ -0,0 +1,125 @@
+# Kapitel 5 — Distribution und Metadaten
+
+**Bedient Klausur-Block:** 9 (Distribution & Metadaten)
+**Slide-Budget:** ~25 (90-min-Termin)
+
+## Bogen
+
+Eine Stunde, eine Frage: **„Wie kommen die Bytes von der Quelle zur Endnutzerin — und was verraten sie auf dem Weg?"**
+
+1. Wir öffnen mit dem Alltag: Netflix-Stream startet in unter einer Sekunde. Wie kann das? Antwort: CDN.
+2. **CDN-Prinzip** am Netflix-Open-Connect-Beispiel — PoPs, Edge-Caching, geografische Verteilung. Selbstlernen: DevTools-Tab Network einsehen.
+3. **REST-APIs** als die Sprache, in der Apps Daten austauschen — GET/POST/PUT/DELETE auf Resources abgebildet. Tools: curl, Postman, JSONPlaceholder.
+4. **Pivot zu Metadaten** — Dateien tragen nicht nur Inhalt, sondern auch versteckte Daten über sich selbst.
+5. **EXIF in Fotos** — der McAfee-Fall (GPS verraten Aufenthaltsort). Privacy-Schock.
+6. **ID3 in MP3s · PDF-Metadaten** — der Tony-Blair-Fall (PDF-Edits verraten Quellen).
+7. **Vendor-Lockin** — Adobe PSD, Apple .pages: proprietäre Formate als Geschäftsmodell.
+8. **Selbstlernen:** exiftool auf eigene Fotos werfen.
+
+## Advance Organizer
+
+```
+              Eine Datei reist und erzählt
+                          │
+              ┌───────────┴───────────┐
+              ▼                       ▼
+         WEG                    GEPÄCK
+         CDN                    Metadaten
+         REST-API               EXIF · ID3 · PDF
+              │                       │
+         Latenz · Caching         Privacy-Leak
+         Open Connect            Vendor-Lockin
+              │                       │
+              └───────────┬───────────┘
+                          ▼
+                   Aufmerksamkeit für
+                   das was wir nicht
+                       sehen
+```
+
+→ neue Demo-Datei: `kap05-bogen.html`
+
+## Folien-Skelett
+
+### Eröffnung (3 Slides)
+
+| # | Typ | Titel/Kern | Lernziel | Berührungspunkt | Visualisierung |
+|---|-----|-----------|---------|-----------------|----------------|
+| 1 | Cover | Kapitel 5 — Distribution und Metadaten | — | — | reuse |
+| 2 | Lead | Eine Datei reist — was passiert dabei? | Hook | Netflix-Stream startet sofort | — |
+| 3 | Advance Organizer | Weg + Gepäck | Roter Faden | — | **NEU kap05-bogen** |
+
+### Sub-Sektion A — Distribution (10 Slides, L9.1 + L9.2)
+
+| # | Typ | Titel/Kern | Lernziel | Berührungspunkt | Visualisierung |
+|---|-----|-----------|---------|-----------------|----------------|
+| 4 | Lead | CDN — Content Delivery Network | — | — | — |
+| 5 | Inhalt | Warum sind Streams überhaupt schnell? | L9.1 | YouTube-Latenz | NEU latenz-frage |
+| 6 | Klausur | CDN-Prinzip: PoP + Edge-Caching | L9.1 | — | NEU cdn-prinzip |
+| 7 | Inhalt | Netflix Open Connect: 15 % des Welt-Traffics | L9.1 | Netflix-App | reuse netflix-cdn |
+| 8 | Demo | DevTools-Tab Network live | L9.1 | im Browser | — |
+| 9 | Lead | REST-APIs | — | — | — |
+| 10 | Inhalt | Was ist eine API? | L9.2 | Wetter-App holt Daten | NEU api-konzept |
+| 11 | Klausur | GET · POST · PUT · DELETE | L9.2 | — | NEU rest-methods |
+| 12 | Demo | JSONPlaceholder im Browser | L9.2 | jsonplaceholder.typicode.com | — |
+| 13 | Inhalt | JSON als Datenformat | L9.2 | — | NEU json-anatomie |
+
+### Sub-Sektion B — Metadaten (10 Slides, L9.3 + L9.4)
+
+| # | Typ | Titel/Kern | Lernziel | Berührungspunkt | Visualisierung |
+|---|-----|-----------|---------|-----------------|----------------|
+| 14 | Pivot | Dateien tragen auch Gepäck | — | — | — |
+| 15 | Inhalt | EXIF: was ein Foto über sich verrät | L9.3 | eigenes Smartphone-Foto | NEU exif-grafik |
+| 16 | Klausur | Der John-McAfee-GPS-Fall | L9.3 | — | reuse mcafee-fall |
+| 17 | Inhalt | Social-Media-EXIF-Stripping | L9.3 | Twitter · WhatsApp · Facebook | reuse social-stripping-tabelle |
+| 18 | Inhalt | ID3 in MP3-Dateien | L9.3 | iTunes · MusicBrainz | — |
+| 19 | Inhalt | PDF-Metadaten: Tony Blair 2003 | L9.3 | — | reuse blair-fall |
+| 20 | Lead | Vendor-Lockin | — | — | — |
+| 21 | Inhalt | Adobe PSD, INDD: das Geschäftsmodell | L9.4 | InDesign-Abo | NEU vendor-lockin-grafik |
+| 22 | Inhalt | Apple .pages, .numbers, .keynote | L9.4 | iPad-User | — |
+| 23 | Klausur | Vendor-Lockin als Risiko | L9.4 | „was wenn Adobe das Format ändert?" | — |
+
+### Selbstlernen + Zusammenfassung (2 Slides)
+
+| # | Typ | Titel/Kern | Lernziel | Berührungspunkt | Visualisierung |
+|---|-----|-----------|---------|-----------------|----------------|
+| 24 | Selbstlernen | exiftool auf eigene Fotos | L9.3 | Terminal · GUI | — |
+| 25 | Zusammenfassung | Datei = Inhalt + Gepäck | alle B9 | — | NEU summary |
+
+## Streichungs-Liste
+
+Aus dem aktuellen `04-distribution-apis-zukunft.md` (~89 Slides) — **deutliche Reduktion**:
+- BitTorrent/P2P-Detail-Slides — eindampfen auf eine Folie (Verweis als Kontext)
+- IPFS — raus (nicht Klausurthema, kein Berührungspunkt)
+- WebSockets, gRPC — raus (zu speziell, gehört in Internettechnik-Kurs 223015c)
+- **Komplette Zukunfts-Sektion** (AI-Kompression, JPEG XL, DNA-Storage, holographische Speicher, Web3, 8K-VR, Cloud Gaming, Sustainability) — **raus** (per D2-Lock)
+- Sneakernet/AWS-Snowball — raus (Klausurirrelevant)
+- Diverse Vertiefungs-Slides ohne Bezug — raus
+
+Geschätzte Reduktion: 89 → 25 Slides (-72%).
+
+## Visualisierungen — neu zu bauen
+
+| Demo-Datei | Was zeigt sie |
+|------------|---------------|
+| `kap05-bogen.html` | Advance Organizer Distribution+Metadaten |
+| `latenz-frage.html` | Warum Streams schnell starten |
+| `cdn-prinzip.html` | PoP + Edge-Caching Schema |
+| `api-konzept.html` | App ↔ API ↔ Datenbank |
+| `rest-methods.html` | GET/POST/PUT/DELETE auf Resource-Modell |
+| `json-anatomie.html` | JSON-Beispiel mit Anmerkungen |
+| `exif-grafik.html` | Foto mit eingeblendeten EXIF-Daten |
+| `vendor-lockin-grafik.html` | Proprietäres Format als geschlossener Kreis |
+| `summary-kap05.html` | Zusammenfassung |
+
+Reuse: netflix-cdn, mcafee-fall, social-stripping-tabelle, blair-fall (alle Bestand).
+
+## Validierungs-Status
+
+- [x] Bogen mit Pivot Distribution → Metadaten
+- [x] Advance Organizer
+- [x] Folien-Skelett (2 Sub-Sektionen)
+- [x] Privacy als zentraler Berührungspunkt (McAfee, Blair, Vendor-Lockin)
+- [x] Aggressive Streichungs-Liste (89 → 25)
+- [x] Visualisierungs-TODO
+- [ ] Dozent-Review und Lock

docs/STATUS.md

@@ -0,0 +1,64 @@
+# Refactor-Status · `refactor/didaktik-rewrite-2026`
+
+Letzter Stand: 2026-05-14
+
+## Was steht
+
+### Foundation (Phasen 0–1)
+- [x] `CLAUDE.md` · `README.md` · `AGENTS.md` mit didaktischem Fundament (auf `main`)
+- [x] `docs/klausur-themen-2026.md` — 9 Klausur-Blöcke für 223015b gelockt (D1–D4 entschieden)
+- [x] `docs/223015b-lernziele.md` — 33 operative Lernziele im Fließsatz-Eichmaß
+- [x] `docs/223015b/01-…-bogen.md` bis `05-…-bogen.md` — 5 Kapitel-Skelette mit Folien-Plan, Streichungs-Liste, Demo-TODO
+
+### Demos (Phase 3)
+- [x] `kap02-eroeffner.png` — Lossless vs Lossy Wellenform-Vergleich (FLAC vs MP3 128)
+- [x] `kap03-eroeffner.png` — Drei Modalitäten Datei-Größen-Tabelle (Bild/Audio/Video)
+- [ ] **Kap 4 Eröffner** — Datei-Reise-Pfad (SSD → SATA → USB-C → HDMI → Display mit Datenraten)
+- [ ] **Kap 5 Eröffner** — Foto mit EXIF-Overlay (Privacy-Reveal)
+- [ ] Übrige ~40 unterstützende Demos pro Kapitel (siehe Visualisierungs-Listen in den Bogen-Docs)
+
+### Erste 5 Eröffner-Versuche (verworfen)
+Frühere Advance Organizer (`kap01-advance-organizer`, `kap02-bogen`, `kap03-modalitäten-bogen`, `kap04-bogen`, `kap05-bogen`) waren plump, gleichförmig und nicht erkenntnisgewinnend. Per Commit `1c8185b` gelöscht. Begründung: Topic-Boxen mit Pfeilen statt konkrete Daten in Transformation. Neue Strategie: pro Kapitel eigene Konkret-Komposition.
+
+### Slides selbst (Phase 4)
+- [ ] Komplett offen — die Bogen-Docs sind das Skelett, daraus werden in Phase 4 die Marp-Markdown-Files erzeugt
+- Reihenfolge laut Plan: 01-fundamentale → 02-kompression → 03-inhalte → 04-speicher → 05-distribution
+- Aktuelle Slide-Files (`01-grundlagen-text-audio.md` etc.) bleiben unangetastet bis die neuen Files stehen — kein „halb migriert"-Zustand
+- Make-Pattern erlaubt es, die alten Files weiterzulaufen während neue gebaut werden (gleicher Build-Befehl)
+
+## Wo weitermachen
+
+**Empfohlene nächste Schritte (in dieser Reihenfolge):**
+
+1. Kap 4 Eröffner-Demo bauen — Datei-Reise-Pfad
+2. Kap 5 Eröffner-Demo bauen — EXIF-Overlay
+3. Pro Kapitel die 3–4 wichtigsten neuen Demos (z.B. JPEG-Pipeline-Stationen, USB-C-drei-Achsen, CDN-Schema)
+4. Phase 4 starten: Slide-MD-Files pro Kapitel schreiben, dabei existierende + neue Demos einbinden
+5. Build-Test (`make build-223015b`), Render-Spot-Check
+6. Erste Dozenten-Lesart durch Kapitel 1+2, justieren
+7. Iterativ Kap 3–5
+8. PR auf `main`, Review, Merge, Deploy
+
+## Wichtige Konventionen
+
+- **Keine Emojis** — auch nicht als Icons in HTML-Demos
+- **„Bit"/„Byte" sind Maßwörter** — kein s-Plural („Bits"/„Bytes")
+- **„Selbstlernen"**, nicht „Hands-On"
+- **Klausur-Folien bleiben verstreut** — kein Sammelblock am Kapitel-Ende
+- **Lernziele = Vorschläge** an den Dozenten, nicht gesetzte Anforderungen; Default Bloom-Level Verstehen
+- **Render vor Layout-Aussage** — chromium-headless, dann PNG mit Read-Tool inspizieren
+- **Advance Organizer = Erkenntnisgewinn**, nicht Topic-Boxen mit Pfeilen
+
+## Branch-Operationen
+
+```bash
+# Stand sehen
+git log --oneline refactor/didaktik-rewrite-2026
+
+# Auf neuesten Stand bringen
+git switch refactor/didaktik-rewrite-2026
+git pull origin refactor/didaktik-rewrite-2026
+
+# Plan-Datei
+cat ~/.claude/plans/1-infinity-2-neue-wild-ember.md
+```

docs/klausur-themen-2026.md

@@ -0,0 +1,79 @@
+# Klausur-Themen 2026 — HdM-Kurse
+
+Status: **LOCK 223015b · Entwurf 223015c · pending dhbw**
+
+Maßstab: Die drei Meta-Lernziele aus `CLAUDE.md` (gelernte Hilflosigkeit ablegen · Berührungspunkte schaffen · Gefühl für Technik). Jeder Klausur-Block muss mindestens eines davon nachweisbar bedienen.
+
+---
+
+## 223015b — Dateiformate, Schnittstellen, Speichermedien
+
+**Kurs-Fokus:** Dateien und Inhalte
+**Klausur-Format (bisher):** 90 Min digital, offene Fragen, kein Code
+**Bestehende Klausur-Blöcke (Stand vor Rewrite):** J,K,L,M,N,O (6 Blöcke) — Grundbegriffe, Bild/Raster vs Vektor, JPEG, Bildformate PNG/GIF/WebP/SVG, Video-Kompression, Speicher/Schnittstellen
+**Bestand ohne Klausur-Marker:** komplettes Kapitel 4 (Distribution, APIs, Metadaten, Zukunft — 89 Slides)
+
+### Vorgeschlagene Klausur-Themen-Architektur (Tabula rasa, 9 Themen-Blöcke)
+
+| # | Block | Kern | Was reinkommt | Berührungspunkt |
+|---|---|---|---|---|
+| 1 | **Datenfundamentale** | Daten als Zahlen begreifen | Bit/Byte/Hex, Dateneinheiten (KB vs KiB), Encoding (ASCII/Unicode/UTF-8), Magic Numbers | „warum spielt mein USB-Stick mit 32 GB nur 29 GB an" |
+| 2 | **Vom Signal zum Byte** | Analog → Digital | Sampling, Quantisierung, Bittiefe, Abtastrate, Nyquist | „warum klingen alte MP3s blechern" |
+| 3 | **Kompression: Prinzipien** | Redundanz vs Irrelevanz | Lossless vs Lossy, RLE/Huffman/LZ77 konzeptuell, Psychoakustik, Psychovisualität | WhatsApp-Bilder vs Original |
+| 4 | **Bilder: Raster und Vektor** | Wann welches Bildformat | Raster vs Vektor, JPEG-Pipeline (6 Schritte), PNG/GIF/WebP/AVIF/SVG-Vergleich, Wann-Welches-Format | Instagram-Story-Qualitätsverlust, Logo skalieren |
+| 5 | **Audio** | MP3-Trick verstehen | Sampling-Recap, MP3-Psychoakustik, WAV/MP3/FLAC/AAC, Spotify-Quality-Math | Spotify-Bitrate-Setting, AirPod-Streaming |
+| 6 | **Video** | Container vs Codec | I/P/B-Frames, H.264/265/VP9/AV1 (Politik+Technik), Streaming-Bitrate | Netflix-Quality, YouTube-1080p vs 4K |
+| 7 | **Speichermedien** | HDD vs SSD entscheiden | HDD-Mechanik, SSD-Zellen, Filesystems-Übersicht, 3-2-1-Backup | „warum ist meine SSD voll obwohl ich nichts habe" |
+| 8 | **Schnittstellen** | USB-C-Chaos entwirren | USB-Generationen, USB-C-Stecker vs Protokoll, Thunderbolt, HDMI/DP, Ethernet vs WiFi | „warum lädt mein Laptop am einen USB-C-Port und am anderen nicht" |
+| 9 | **Distribution & Metadaten** | Wie Inhalte ins Netz kommen | CDN-Prinzip, REST-API, EXIF/ID3, Vendor-Lockin | Netflix-Stream-Latenz, Instagram strippt EXIF |
+
+### Lock-Entscheidungen (Dozent, 2026-05-13)
+
+- **D1 — Block 9 Distribution & Metadaten:** **PFLICHT-KLAUSUR.** Schließt den Bogen „vom Bit bis zum Bildschirm der Endnutzerin".
+- **D2 — Zukunfts-Themen** (AI-Kompression, JPEG XL, DNA-Storage, Web3): **RAUS.** Werden nicht aufgenommen, weder Klausur noch Lehre.
+- **D3 — JPEG-Pipeline-Tiefe:** **VOLLE TIEFE** inkl. DCT und Quantisierungstabellen. Härteste konzeptuelle Nuss bleibt als „Verstehen-statt-Auswendiglernen"-Test drin. Reduzieren passiert nötigenfalls im Live-Vortrag, nicht in der Architektur.
+- **D4 — Granularität:** **9 granulare Blöcke** (Dozent-agnostisch zur Wahl, granular liegt näher an Inhalt).
+
+Leitprinzip aus dem Workshop: **„nicht reduzieren — skippen passiert während der Vorlesung."** Architektur bleibt ambitioniert, Live-Anpassung übernimmt die Skalierung.
+
+### Verhältnis zu den Kapiteln
+
+Vorgeschlagene Themen ↔ Kapitel-Mapping (welches Kapitel liefert das Material für welchen Block):
+
+- Block 1 (Fundamentale) ← Kap 0 (Intro) + Kap 1 (Grundlagen)
+- Block 2 (Signal→Byte) ← Kap 1 (Text+Audio)
+- Block 3 (Kompression) ← Kap 1 + Kap 2 (übergreifend)
+- Block 4 (Bilder) ← Kap 2 (Bild+Video)
+- Block 5 (Audio) ← Kap 1 (Text+Audio)
+- Block 6 (Video) ← Kap 2 (Bild+Video)
+- Block 7 (Speicher) ← Kap 3
+- Block 8 (Schnittstellen) ← Kap 3
+- Block 9 (Distribution) ← Kap 4 (falls drin) / sonst raus
+
+→ Daraus folgt eine Kapitel-Neugliederung mit 5 Kapiteln (statt aktuell 6 mit Platzhalter):
+- Kap 1: Fundamentale + Signal→Byte
+- Kap 2: Kompression
+- Kap 3: Bilder + Audio + Video
+- Kap 4: Speicher + Schnittstellen
+- Kap 5: Distribution + Metadaten (optional, Zukunfts-Bonus integriert)
+
+### Lock-Status
+
+- [x] D1–D4 entschieden (2026-05-13)
+- [x] Block-Architektur (9 Blöcke) festgelegt
+- [x] Kapitel-Neugliederung (6→5) festgelegt
+- [ ] Phase 1: Operative Lernziele pro Block formuliert
+- [ ] Phase 2: Folien-Skelett pro Kapitel
+
+---
+
+## 223015c — Internettechnologien
+
+**Status:** wird nach 223015b bearbeitet (Reihenfolge laut Plan: b → c → dhbw).
+Platzhalter — Vorschlag folgt nach Abschluss von 223015b.
+
+---
+
+## DHBW Technik I
+
+**Status:** keine Klausur, separate Prüfungsleistungs-Architektur in `docs/dhbw-pruefungsleistung-2026.md` (Phase 0).

slides/223015b/01-grundlagen-text-audio.md

@@ -713,14 +713,19 @@ Kinofilm in üblicher Länge (~120min) über **5 TB (Terabyte)**
 
 ---
 
-<!--
-Was ist überhaupt KOMPRESSION?
+<!-- _header: "" -->
+<!-- _footer: "" -->
+<!-- _paginate: false -->
 
-- Luftdruck in Auto/Fahrradreifen
-- LNG Flüssiggas
-- Tripsdrill, Disneyland
-- Oper/Theater/Telenovela
-- Cola Sirup für den Sodastream
+![bg](./assets/lv-original-vs-fake.jpg)
+
+<!--
+Analogie: Original vs Fake-Tasche
+
+- Links: Original — jedes Detail erhalten (Lossless)
+- Rechts: Fälschung — sieht ähnlich aus, Details verloren (Lossy)
+- Weitere Analogien: Luftdruck im Reifen, LNG, Tripsdrill-Schlange,
+  Telenovela-Zusammenfassung, Sodastream-Sirup
 -->
 
 ---
@@ -800,7 +805,7 @@ Komprimiert: 5A3B8C            (6 Zeichen)
 * Das Ohr hört nicht alle Frequenzen (hohe und tiefe Töne) gleich gut
 * Laute Töne überdecken leise Töne (Maskierung)
 * Das Auge sieht nicht alle Farbnuancen gleich scharf
-* Luminanz (Helligkeit/Dunkelheit) besser erkennen als Chrominanz (Farbunterschiede/Farbigkeit)
+* Luminanz (Helligkeit/Dunkelheit) besser erkennbar als Chrominanz (Farbunterschiede/Farbigkeit)
 * und Vieles mehr
 
 <!--
@@ -1145,6 +1150,66 @@ Sog. RGB Tuple (geordnete endliche Liste)
 
 ---
 
+<!-- _class: lead -->
+
+# ASCII
+## One *Zeichensatz* to rule them all
+
+<!--
+WARUM 7 BIT STATT 8?
+- 1963: Fernschreiber (Teletype) arbeiteten mit 7-Bit-Codes
+- Das 8. Bit diente der Paritätsprüfung (Fehlererkennung bei Übertragung)
+- Speicher war kostspielig: jedes eingesparte Bit zählte
+- 128 Zeichen galten als ausreichend für den englischsprachigen Raum
+
+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 nicht berücksichtigt
+- Führte zu zahlreichen inkompatiblen Erweiterungen (ISO-8859-1, Windows-1252, etc.)
+
+WARUM NOCH HEUTE RELEVANT?
+- UTF-8 vollständig ASCII-kompatibel (Zeichen 0–127 identisch)
+- Internetprotokolle basieren auf ASCII: HTTP-Header, SMTP, URLs
+- Programmiersprachen: Schlüsselwörter und Syntax sind ASCII
+- Ein 60 Jahre alter Standard, der durch Kompatibilitätszwänge fortbesteht
+
+HISTORISCHE RANDNOTIZ:
+- Das @-Zeichen wurde nachträglich aufgenommen
+- Heute unverzichtbar für E-Mail-Adressen weltweit
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/ascii-table-colored.png)
+
+<!--
+US-ASCII (1967) Code Chart
+- 7 Bit = 128 Zeichen
+- Erste 32: Steuerzeichen (nicht druckbar)
+- Zeichen 32–126: Druckbar (Buchstaben, Ziffern, Satzzeichen)
+- Keine Umlaute, kein ñ, kein é
+-->
+
+---
+
+<!-- _class: lead -->
+
+# ASCII reicht für Englisch.
+## Aber was ist mit *ä, é, 中, 🌸*?
+
+<!--
+Brücke: ASCII löst das Problem nur für englischen Text.
+Sobald Umlaute, Akzente, asiatische Schriften oder Emoji ins Spiel kommen,
+sprengt es den 7-Bit-Raum. Lösung: Unicode + UTF-8.
+-->
+
+---
+
 # Unicode: Ein Standard für alle
 
 **Unicode (1991):** Jedes Schriftsystem der Welt
@@ -1194,14 +1259,35 @@ Sog. RGB Tuple (geordnete endliche Liste)
 <!-- _header: '' -->
 <!-- _footer: '' -->
 
-![bg fit](./assets/demos/byte-nibble-hex.png)
+![bg fit](./assets/demos/byte-fuer-byte.png)
 
 <!--
-Kernidee: jedes Byte lässt sich sauber in zwei 4-Bit-Hälften (Nibbles) zerlegen. Jede Hälfte hat 2⁴ = 16 Zustände – und genau 16 Symbole hat Hex (0-F). Deshalb passt Hex perfekt: 1 Nibble = 1 Hex-Ziffer, 1 Byte = 2 Hex-Ziffern. Keine krumme Umrechnung.
+Brücke / Strang-Wechsel:
+Bis hier: Wie speichern wir Buchstaben als Byte? (Encoding)
+Ab jetzt: Wie schauen Byte aus, wenn man die Datei roh anstarrt? (Darstellung)
+
+Aussage der Grafik:
+- Fenster 1 (Bin): rohe 0/1 — was tatsächlich auf der Platte steht
+- Fenster 2 (Hex): 2 Ziffern pro Byte — kompakt lesbar
+- Fenster 3 (Text): ASCII-Zeichen wenn ≤ 126, sonst ✗
+- Schon ein Byte > 126 → Binärdatei (z.B. PNG, MP3, ZIP)
+- Nur Werte ≤ 126 → reine Textdatei (z.B. .txt, .csv, .md)
 -->
 
 ---
 
+![bg right:40%](./assets/matrix-code.png)
+
+# WTF!?
+
+```
+89 50 4E 47 0D 0A 1A 0A
+00 00 00 0D 49 48 44 52
+00 00 01 90 00 00 01 2C
+```
+
+---
+
 <!-- _header: '' -->
 <!-- _footer: '' -->
 
@@ -1252,6 +1338,17 @@ Warum gerade 8 Bit?
 <!-- _header: '' -->
 <!-- _footer: '' -->
 
+![bg fit](./assets/demos/byte-nibble-hex.png)
+
+<!--
+Kernidee: jedes Byte lässt sich sauber in zwei 4-Bit-Hälften (Nibbles) zerlegen. Jede Hälfte hat 2⁴ = 16 Zustände – und genau 16 Symbole hat Hex (0-F). Deshalb passt Hex perfekt: 1 Nibble = 1 Hex-Ziffer, 1 Byte = 2 Hex-Ziffern. Keine krumme Umrechnung.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
 ![bg fit](./assets/demos/hex-dec-table.png)
 
 <!--
@@ -1293,117 +1390,6 @@ Dieselben 8 Byte (PNG-Dateianfang: 89 50 4E 47 0D 0A 1A 0A) — drei Perspektive
 
 ---
 
-# Wo begegnet Ihnen Hex-Code?
-
-| Kontext | Beispiel |
-|---------|----------|
-| CSS-Farben | `#FF5733` |
-| MAC-Adressen | `00:1A:2B:3C:4D:5E` |
-| Fehlercodes | `0x80070005` |
-| Speicheradressen | `0xA04F20` |
-| Unicode | `U+00E4` (ä) |
-| Datei-Signaturen | `89 50 4E 47` (PNG) |
-
-<!--
-Präfixe:
-- 0x = "das ist Hexadezimal" (C, JavaScript, Python)
-- U+ = Unicode-Codepoint (Standard für Zeichenkodierung)
-- # = CSS-Konvention für Farben
-
-ABKÜRZUNGEN:
-- MAC = Media Access Control (eindeutige Hardware-Adresse einer Netzwerkkarte)
-- Unicode = universeller Zeichensatz für alle Schriftsysteme
-
-Speicheradressen erklärt:
-- 64-Bit-System → Adresse hat 64 Bit = 16 Hex-Ziffern
-- Beispiel vollständig: 0x0000000000A04F20 (führende Nullen weggelassen)
-- "0x" = Präfix, sagt nur "jetzt kommt Hex"
-
-Fehlercodes: Windows zeigt diese bei Bluescreens
--->
-
----
-
-# Bit vs. Byte: Die Verwirrung
-
-**1 Byte = 8 Bit** → Bit ÷ 8 = Byte
-
-| Einheit (Bit) | Einheit (Byte) |
-|---------------|----------------|
-| 1 Kbit = 1.000 Bit | 1 KB = 1.000 Byte = 8.000 Bit |
-| 1 Mbit = 1.000.000 Bit | 1 MB = 1.000.000 Byte = 8 Mbit |
-| 1 Gbit = 1 Mrd. Bit | 1 GB = 1 Mrd. Byte = 8 Gbit |
-
-100 Mbit/s Bandbreite = **12,5 MB/s** Downloadrate
-
-<!--
-Bits = kleines b, Bytes = großes B
-Internetanbieter: Mbit/s (klingt größer!)
-100 Mbit/s ÷ 8 = 12,5 MB/s
-Marketing - 100 klingt besser als 12,5
--->
-
----
-
-<!-- _class: lead -->
-
-# ASCII
-## One *Zeichensatz* to rule them all
-
-<!--
-WARUM 7 BIT STATT 8?
-- 1963: Fernschreiber (Teletype) arbeiteten mit 7-Bit-Codes
-- Das 8. Bit diente der Paritätsprüfung (Fehlererkennung bei Übertragung)
-- Speicher war kostspielig: jedes eingesparte Bit zählte
-- 128 Zeichen galten als ausreichend für den englischsprachigen Raum
-
-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 nicht berücksichtigt
-- Führte zu zahlreichen inkompatiblen Erweiterungen (ISO-8859-1, Windows-1252, etc.)
-
-WARUM NOCH HEUTE RELEVANT?
-- UTF-8 vollständig ASCII-kompatibel (Zeichen 0–127 identisch)
-- Internetprotokolle basieren auf ASCII: HTTP-Header, SMTP, URLs
-- Programmiersprachen: Schlüsselwörter und Syntax sind ASCII
-- Ein 60 Jahre alter Standard, der durch Kompatibilitätszwänge fortbesteht
-
-HISTORISCHE RANDNOTIZ:
-- Das @-Zeichen wurde nachträglich aufgenommen
-- Heute unverzichtbar für E-Mail-Adressen weltweit
--->
-
----
-
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-![bg fit](./assets/ascii-table-colored.png)
-
-<!--
-US-ASCII (1967) Code Chart
-- 7 Bit = 128 Zeichen
-- Erste 32: Steuerzeichen (nicht druckbar)
-- Zeichen 32–126: Druckbar (Buchstaben, Ziffern, Satzzeichen)
-- Keine Umlaute, kein ñ, kein é
--->
-
----
-
-![bg right:40%](./assets/matrix-code.png)
-
-# WTF!?
-
-```
-89 50 4E 47 0D 0A 1A 0A
-00 00 00 0D 49 48 44 52
-00 00 01 90 00 00 01 2C
-```
-
----
-
 ![bg right:30%](./assets/matrix-code.png)
 
 # What the HEX-Code
@@ -1463,6 +1449,71 @@ US-ASCII (1967) Code Chart
 
 ---
 
+<!-- _class: lead -->
+
+# Hex ist überall.
+## Schon mal *gesehen*?
+
+<!--
+Brücke vom Theorie-Block zum Alltags-Recall.
+Bis hier: Was ist Hex und wie liest man es?
+Ab jetzt: Wo siehst du Hex in der Praxis (CSS, MAC, Errorcodes, Unicode, Magic Numbers)?
+-->
+
+---
+
+# Wo begegnet Ihnen Hex-Code?
+
+| Kontext | Beispiel |
+|---------|----------|
+| CSS-Farben | `#FF5733` |
+| MAC-Adressen | `00:1A:2B:3C:4D:5E` |
+| Fehlercodes | `0x80070005` |
+| Speicheradressen | `0xA04F20` |
+| Unicode | `U+00E4` (ä) |
+| Datei-Signaturen | `89 50 4E 47` (PNG) |
+
+<!--
+Präfixe:
+- 0x = "das ist Hexadezimal" (C, JavaScript, Python)
+- U+ = Unicode-Codepoint (Standard für Zeichenkodierung)
+- # = CSS-Konvention für Farben
+
+ABKÜRZUNGEN:
+- MAC = Media Access Control (eindeutige Hardware-Adresse einer Netzwerkkarte)
+- Unicode = universeller Zeichensatz für alle Schriftsysteme
+
+Speicheradressen erklärt:
+- 64-Bit-System → Adresse hat 64 Bit = 16 Hex-Ziffern
+- Beispiel vollständig: 0x0000000000A04F20 (führende Nullen weggelassen)
+- "0x" = Präfix, sagt nur "jetzt kommt Hex"
+
+Fehlercodes: Windows zeigt diese bei Bluescreens
+-->
+
+---
+
+# Bit vs. Byte: Die Verwirrung
+
+**1 Byte = 8 Bit** → Bit ÷ 8 = Byte
+
+| Einheit (Bit) | Einheit (Byte) |
+|---------------|----------------|
+| 1 Kbit = 1.000 Bit | 1 KB = 1.000 Byte = 8.000 Bit |
+| 1 Mbit = 1.000.000 Bit | 1 MB = 1.000.000 Byte = 8 Mbit |
+| 1 Gbit = 1 Mrd. Bit | 1 GB = 1 Mrd. Byte = 8 Gbit |
+
+100 Mbit/s Bandbreite = **12,5 MB/s** Downloadrate
+
+<!--
+Bits = kleines b, Bytes = großes B
+Internetanbieter: Mbit/s (klingt größer!)
+100 Mbit/s ÷ 8 = 12,5 MB/s
+Marketing - 100 klingt besser als 12,5
+-->
+
+---
+
 # Magic Numbers
 
 **Dateityp-Identifikation durch erste Bytes**

slides/223015b/assets/demos/byte-fuer-byte.html

@@ -0,0 +1,117 @@
+<!DOCTYPE html>
+<html lang="de">
+<head>
+<meta charset="UTF-8">
+<title>Byte für Byte — drei Brillen</title>
+<style>
+  :root {
+    --hl: #d63384;
+    --dark: #1a1a2e;
+    --muted: #6b7280;
+    --border: #cbd5e1;
+    --bg-soft: #f8fafc;
+    --bin-bg: #0f0f23;
+    --bin-fg: #e5e7eb;
+    --binary-mark: #ef4444;
+    --ascii-ok: #16a34a;
+    --ctrl: #9ca3af;
+  }
+  html, body { margin: 0; padding: 0; background: #fff; font-family: system-ui, -apple-system, sans-serif; color: var(--dark); }
+  body { padding: 28px 32px; }
+  h1 { text-align: center; margin: 0 0 4px; font-size: 1.75rem; }
+  .sub { text-align: center; color: var(--muted); margin-bottom: 22px; font-size: 1rem; }
+  .sub code { font-family: ui-monospace, "SF Mono", Menlo, monospace; }
+
+  .windows { display: grid; grid-template-columns: 1fr 1fr 1fr; gap: 18px; max-width: 1180px; margin: 0 auto; }
+
+  .window { border: 2px solid var(--border); border-radius: 10px; overflow: hidden; display: flex; flex-direction: column; }
+  .window-header { background: var(--bg-soft); padding: 10px 14px; border-bottom: 2px solid var(--border); display: flex; flex-direction: column; gap: 2px; }
+  .window-title { font-size: 0.78rem; font-weight: 700; text-transform: uppercase; letter-spacing: 0.1em; color: var(--muted); }
+  .window-name { font-size: 1.15rem; font-weight: 700; color: var(--dark); }
+
+  .window-body { padding: 14px 16px; flex: 1; display: flex; flex-direction: column; gap: 6px; font-family: ui-monospace, "SF Mono", Menlo, monospace; }
+
+  .window.bin .window-body { background: var(--bin-bg); }
+  .window.bin .row { color: var(--bin-fg); font-size: 1.05rem; letter-spacing: 0.04em; }
+
+  .window.hex .row { color: var(--dark); font-size: 1.4rem; font-weight: 700; letter-spacing: 0.06em; }
+
+  .window.text .row { font-size: 1.4rem; font-weight: 700; display: flex; align-items: center; gap: 10px; }
+  .window.text .glyph.printable { color: var(--ascii-ok); }
+  .window.text .glyph.ctrl { color: var(--ctrl); font-size: 1.1rem; }
+  .window.text .glyph.binary { color: var(--binary-mark); }
+  .window.text .note { font-size: 0.78rem; font-weight: 400; color: var(--muted); margin-left: auto; }
+
+  .footnote { margin-top: 24px; max-width: 1100px; margin-left: auto; margin-right: auto; display: flex; gap: 32px; justify-content: center; font-size: 0.95rem; }
+  .legend { display: flex; align-items: center; gap: 8px; }
+  .swatch { display: inline-block; width: 16px; height: 16px; border-radius: 3px; }
+  .swatch.binary { background: #fee2e2; border: 2px solid var(--binary-mark); }
+  .swatch.ascii { background: #dcfce7; border: 2px solid var(--ascii-ok); }
+  .verdict { margin-top: 14px; text-align: center; font-size: 1.05rem; color: var(--dark); }
+  .verdict strong { color: var(--binary-mark); }
+</style>
+</head>
+<body>
+  <h1>Byte für Byte</h1>
+  <div class="sub">Eine Datei — drei Brillen. Beispiel: erste 8 Byte einer PNG-Datei.</div>
+
+  <div class="windows">
+
+    <div class="window bin">
+      <div class="window-header">
+        <div class="window-title">Fenster 1</div>
+        <div class="window-name">Bin · rohe 0 und 1</div>
+      </div>
+      <div class="window-body">
+        <div class="row">10001001</div>
+        <div class="row">01010000</div>
+        <div class="row">01001110</div>
+        <div class="row">01000111</div>
+        <div class="row">00001101</div>
+        <div class="row">00001010</div>
+        <div class="row">00011010</div>
+        <div class="row">00001010</div>
+      </div>
+    </div>
+
+    <div class="window hex">
+      <div class="window-header">
+        <div class="window-title">Fenster 2</div>
+        <div class="window-name">Hex · 2 Ziffern pro Byte</div>
+      </div>
+      <div class="window-body">
+        <div class="row">89</div>
+        <div class="row">50</div>
+        <div class="row">4E</div>
+        <div class="row">47</div>
+        <div class="row">0D</div>
+        <div class="row">0A</div>
+        <div class="row">1A</div>
+        <div class="row">0A</div>
+      </div>
+    </div>
+
+    <div class="window text">
+      <div class="window-header">
+        <div class="window-title">Fenster 3</div>
+        <div class="window-name">Text · ASCII oder ✗ (> 126)</div>
+      </div>
+      <div class="window-body">
+        <div class="row"><span class="glyph binary">✗</span><span class="note">137 &gt; 126</span></div>
+        <div class="row"><span class="glyph printable">P</span><span class="note">80</span></div>
+        <div class="row"><span class="glyph printable">N</span><span class="note">78</span></div>
+        <div class="row"><span class="glyph printable">G</span><span class="note">71</span></div>
+        <div class="row"><span class="glyph ctrl">CR</span><span class="note">13 · Steuerz.</span></div>
+        <div class="row"><span class="glyph ctrl">LF</span><span class="note">10 · Steuerz.</span></div>
+        <div class="row"><span class="glyph ctrl">SUB</span><span class="note">26 · Steuerz.</span></div>
+        <div class="row"><span class="glyph ctrl">LF</span><span class="note">10 · Steuerz.</span></div>
+      </div>
+    </div>
+
+  </div>
+
+  <div class="verdict">
+    Mindestens ein Byte mit Wert &gt; 126 → <strong>Binärdatei</strong>. Sonst: reine Textdatei.
+  </div>
+</body>
+</html>

slides/223015b/assets/demos/kap02-eroeffner.html

@@ -0,0 +1,158 @@
+<!DOCTYPE html>
+<html lang="de">
+<head>
+<meta charset="UTF-8">
+<title>Dieselbe Aufnahme, zwei Formate</title>
+<style>
+  :root {
+    --dark: #1a1a2e;
+    --muted: #6b7280;
+    --soft: #f8fafc;
+    --border: #cbd5e1;
+    --hl: #d63384;
+    --lossless: #16a34a;
+    --lossy: #ef4444;
+  }
+  html, body { margin: 0; padding: 0; background: #fff; font-family: system-ui, -apple-system, sans-serif; color: var(--dark); }
+  body { padding: 36px 48px; }
+  h1 { text-align: center; margin: 0 0 6px; font-size: 1.85rem; }
+  .sub { text-align: center; color: var(--muted); margin-bottom: 28px; font-size: 1.05rem; }
+
+  .grid { display: grid; grid-template-columns: 1fr 1fr; gap: 26px; max-width: 1200px; margin: 0 auto; }
+  .panel { border: 2px solid var(--border); border-radius: 12px; padding: 22px 24px; display: flex; flex-direction: column; gap: 14px; background: #fff; }
+  .panel.left  { border-color: var(--lossless); }
+  .panel.right { border-color: var(--lossy); }
+
+  .panel-head { display: flex; justify-content: space-between; align-items: baseline; }
+  .panel-tag {
+    font-size: 0.74rem;
+    font-weight: 700;
+    letter-spacing: 0.12em;
+    text-transform: uppercase;
+    color: var(--muted);
+  }
+  .panel-name { font-size: 1.5rem; font-weight: 700; }
+  .panel.left .panel-name { color: var(--lossless); }
+  .panel.right .panel-name { color: var(--lossy); }
+  .panel-format {
+    font-family: ui-monospace, "SF Mono", Menlo, monospace;
+    font-size: 0.85rem;
+    color: var(--muted);
+  }
+
+  .waveform {
+    background: #0f0f23;
+    border-radius: 8px;
+    padding: 6px;
+    display: block;
+  }
+
+  .stats { display: grid; grid-template-columns: 1fr 1fr; gap: 8px; }
+  .stat { background: var(--soft); border: 1px solid var(--border); border-radius: 7px; padding: 8px 12px; }
+  .stat .label { font-size: 0.7rem; text-transform: uppercase; letter-spacing: 0.08em; color: var(--muted); font-weight: 700; }
+  .stat .value { font-family: ui-monospace, "SF Mono", Menlo, monospace; font-size: 1rem; font-weight: 700; color: var(--dark); margin-top: 2px; }
+
+  .verdict {
+    margin-top: 26px;
+    border: 2px solid var(--hl);
+    background: #fff;
+    border-radius: 12px;
+    padding: 16px 22px;
+    text-align: center;
+    max-width: 1200px;
+    margin-left: auto;
+    margin-right: auto;
+  }
+  .verdict-q { font-size: 1.2rem; font-weight: 700; color: var(--hl); }
+  .verdict-a { font-size: 1rem; color: var(--dark); margin-top: 6px; }
+  .verdict-a strong { color: var(--hl); }
+</style>
+</head>
+<body>
+  <h1>Dieselbe Aufnahme, zwei Formate</h1>
+  <div class="sub">3 Sekunden Snare-Hit mit Cymbal-Tail · 44,1 kHz Sample-Rate · Stereo</div>
+
+  <div class="grid">
+
+    <div class="panel left">
+      <div class="panel-head">
+        <span class="panel-name">Lossless</span>
+        <span class="panel-tag">FLAC</span>
+      </div>
+      <div class="panel-format">verlustfrei · alle Frequenzen 0–22 kHz erhalten</div>
+
+      <svg class="waveform" viewBox="0 0 800 160" preserveAspectRatio="none">
+        <defs>
+          <linearGradient id="green-grad" x1="0" y1="0" x2="0" y2="1">
+            <stop offset="0%" stop-color="#34d399"/>
+            <stop offset="100%" stop-color="#16a34a"/>
+          </linearGradient>
+        </defs>
+        <line x1="0" y1="80" x2="800" y2="80" stroke="#374151" stroke-width="1"/>
+        <!-- detailed waveform: transient peak + cymbal decay with high-freq noise -->
+        <path d="M0,80
+          L40,80 L42,78 L44,82 L46,74 L48,88
+          L60,30 L62,135 L64,18 L66,142 L68,28 L70,128 L72,38 L74,118 L76,48 L78,108
+          L90,55 L92,108 L94,52 L96,112 L98,58 L100,105 L102,62 L104,98 L106,68 L108,92
+          L130,72 L132,92 L134,68 L136,94 L138,72 L140,90 L142,74 L144,88
+          L170,76 L172,86 L174,74 L176,87 L178,76 L180,85
+          L220,77 L222,84 L224,76 L226,85 L228,77 L230,83
+          L280,78 L282,83 L284,77 L286,84 L288,78 L290,82
+          L340,79 L342,82 L344,78 L346,82 L348,79 L350,81
+          L400,79 L402,81 L404,79 L406,81 L408,79 L410,81
+          L460,80 L462,81 L464,79 L466,81 L468,80 L470,80
+          L520,80 L522,81 L524,79 L526,80
+          L580,80 L582,80 L584,80
+          L640,80 L700,80 L800,80 Z"
+          fill="url(#green-grad)" stroke="#16a34a" stroke-width="1" opacity="0.95"/>
+      </svg>
+
+      <div class="stats">
+        <div class="stat"><div class="label">Dateigröße</div><div class="value">5,3 MB</div></div>
+        <div class="stat"><div class="label">Bitrate</div><div class="value">1.411 kbit/s</div></div>
+      </div>
+    </div>
+
+    <div class="panel right">
+      <div class="panel-head">
+        <span class="panel-name">Lossy</span>
+        <span class="panel-tag">MP3 128 kbit/s</span>
+      </div>
+      <div class="panel-format">verlustbehaftet · hohe Frequenzen weggeworfen, Transienten geglättet</div>
+
+      <svg class="waveform" viewBox="0 0 800 160" preserveAspectRatio="none">
+        <defs>
+          <linearGradient id="red-grad" x1="0" y1="0" x2="0" y2="1">
+            <stop offset="0%" stop-color="#fca5a5"/>
+            <stop offset="100%" stop-color="#ef4444"/>
+          </linearGradient>
+        </defs>
+        <line x1="0" y1="80" x2="800" y2="80" stroke="#374151" stroke-width="1"/>
+        <!-- smoothed waveform: same overall shape, no fine detail in transient peak -->
+        <path d="M0,80
+          L40,80 L48,80
+          L60,48 L65,120 L70,52 L75,115 L80,58 L85,108
+          L100,68 L108,92 L114,70 L120,90
+          L150,75 L160,86 L168,76 L174,85
+          L200,77 L210,84 L220,77 L230,83
+          L260,78 L280,82 L300,78 L320,82
+          L360,79 L380,81 L400,79 L420,81
+          L460,80 L480,80 L520,80
+          L580,80 L640,80 L700,80 L800,80 Z"
+          fill="url(#red-grad)" stroke="#ef4444" stroke-width="1" opacity="0.95"/>
+      </svg>
+
+      <div class="stats">
+        <div class="stat"><div class="label">Dateigröße</div><div class="value">0,48 MB</div></div>
+        <div class="stat"><div class="label">Bitrate</div><div class="value">128 kbit/s</div></div>
+      </div>
+    </div>
+
+  </div>
+
+  <div class="verdict">
+    <div class="verdict-q">Hört man den Unterschied?</div>
+    <div class="verdict-a">Auf dem Smartphone-Lautsprecher: meist nicht. Im Studio-Monitor mit Kopfhörer: oft schon. — MP3 wirft <strong>91 % der Daten weg</strong>, die der Mensch im Alltag nicht vermisst.</div>
+  </div>
+</body>
+</html>

slides/223015b/assets/demos/kap03-eroeffner.html

@@ -0,0 +1,119 @@
+<!DOCTYPE html>
+<html lang="de">
+<head>
+<meta charset="UTF-8">
+<title>Drei Modalitäten, ein Hebel</title>
+<style>
+  :root {
+    --dark: #1a1a2e;
+    --muted: #6b7280;
+    --soft: #f8fafc;
+    --border: #cbd5e1;
+    --hl: #d63384;
+    --bild: #2563eb;
+    --audio: #ea580c;
+    --video: #7c3aed;
+  }
+  html, body { margin: 0; padding: 0; background: #fff; font-family: system-ui, -apple-system, sans-serif; color: var(--dark); }
+  body { padding: 32px 48px; }
+  h1 { text-align: center; margin: 0 0 6px; font-size: 1.85rem; }
+  .sub { text-align: center; color: var(--muted); margin-bottom: 26px; font-size: 1.05rem; }
+
+  .table { display: grid; grid-template-columns: 140px 1fr 1fr 1fr; gap: 12px; max-width: 1180px; margin: 0 auto; align-items: stretch; }
+  .col-head { font-size: 0.7rem; text-transform: uppercase; letter-spacing: 0.1em; font-weight: 700; color: var(--muted); padding: 0 8px 4px; }
+
+  .row-label { font-size: 1.15rem; font-weight: 700; padding: 16px 12px; display: flex; flex-direction: column; gap: 4px; justify-content: center; border-radius: 10px; }
+  .row-label.bild { background: #dbeafe; color: var(--bild); }
+  .row-label.audio { background: #ffedd5; color: var(--audio); }
+  .row-label.video { background: #ede9fe; color: var(--video); }
+  .row-label small { font-size: 0.78rem; font-weight: 400; color: var(--muted); text-transform: none; letter-spacing: 0; }
+
+  .cell { border: 1.5px solid var(--border); border-radius: 10px; padding: 12px 14px; background: #fff; display: flex; flex-direction: column; gap: 8px; }
+  .cell-format { font-family: ui-monospace, monospace; font-size: 0.85rem; color: var(--muted); }
+  .cell-size { font-size: 1.7rem; font-weight: 700; color: var(--dark); font-family: ui-monospace, monospace; }
+  .cell-bar { height: 8px; border-radius: 4px; background: var(--soft); position: relative; overflow: hidden; }
+  .cell-bar .fill { position: absolute; left: 0; top: 0; bottom: 0; border-radius: 4px; }
+
+  .verdict {
+    margin-top: 22px;
+    max-width: 1180px;
+    margin-left: auto;
+    margin-right: auto;
+    border: 2px solid var(--hl);
+    border-radius: 12px;
+    padding: 14px 22px;
+    text-align: center;
+  }
+  .verdict-q { font-size: 1.05rem; font-weight: 700; color: var(--hl); }
+  .verdict-a { font-size: 0.95rem; color: var(--dark); margin-top: 4px; }
+  .verdict-a strong { color: var(--hl); }
+</style>
+</head>
+<body>
+  <h1>Drei Modalitäten — derselbe Hebel</h1>
+  <div class="sub">Bild, Audio, Video schrumpfen alle dramatisch. Warum? Weil Wahrnehmung Lücken hat.</div>
+
+  <div class="table">
+    <div></div>
+    <div class="col-head">Roh</div>
+    <div class="col-head">Lossy (modern)</div>
+    <div class="col-head">Lossy (aggressiv)</div>
+
+    <div class="row-label bild">Bild<small>12-MP-Foto</small></div>
+    <div class="cell">
+      <div class="cell-format">RAW</div>
+      <div class="cell-size">36 MB</div>
+      <div class="cell-bar"><div class="fill" style="width:100%;background:#2563eb"></div></div>
+    </div>
+    <div class="cell">
+      <div class="cell-format">JPEG · Q 90</div>
+      <div class="cell-size">4 MB</div>
+      <div class="cell-bar"><div class="fill" style="width:11%;background:#2563eb"></div></div>
+    </div>
+    <div class="cell">
+      <div class="cell-format">JPEG · Q 50</div>
+      <div class="cell-size">800 KB</div>
+      <div class="cell-bar"><div class="fill" style="width:2.2%;background:#2563eb"></div></div>
+    </div>
+
+    <div class="row-label audio">Audio<small>30 s Stereo</small></div>
+    <div class="cell">
+      <div class="cell-format">WAV · 44,1 kHz · 16 bit</div>
+      <div class="cell-size">5,3 MB</div>
+      <div class="cell-bar"><div class="fill" style="width:100%;background:#ea580c"></div></div>
+    </div>
+    <div class="cell">
+      <div class="cell-format">MP3 · 192 kbit/s</div>
+      <div class="cell-size">720 KB</div>
+      <div class="cell-bar"><div class="fill" style="width:14%;background:#ea580c"></div></div>
+    </div>
+    <div class="cell">
+      <div class="cell-format">MP3 · 64 kbit/s</div>
+      <div class="cell-size">240 KB</div>
+      <div class="cell-bar"><div class="fill" style="width:4.5%;background:#ea580c"></div></div>
+    </div>
+
+    <div class="row-label video">Video<small>30 s · 4K · 30 fps</small></div>
+    <div class="cell">
+      <div class="cell-format">Roh · 8 bit</div>
+      <div class="cell-size">12 GB</div>
+      <div class="cell-bar"><div class="fill" style="width:100%;background:#7c3aed"></div></div>
+    </div>
+    <div class="cell">
+      <div class="cell-format">H.264 · 25 Mbit/s</div>
+      <div class="cell-size">94 MB</div>
+      <div class="cell-bar"><div class="fill" style="width:0.8%;background:#7c3aed"></div></div>
+    </div>
+    <div class="cell">
+      <div class="cell-format">H.265 · 12 Mbit/s</div>
+      <div class="cell-size">45 MB</div>
+      <div class="cell-bar"><div class="fill" style="width:0.4%;background:#7c3aed"></div></div>
+    </div>
+  </div>
+
+  <div class="verdict">
+    <div class="verdict-q">Bilder schrumpfen ×45. Audio ×22. Video ×270.</div>
+    <div class="verdict-a">Jede Reduktion nutzt eine andere Wahrnehmungs-Lücke: <strong>Bild</strong> die geringere Farbschärfe, <strong>Audio</strong> die Maskierung, <strong>Video</strong> die Frame-zu-Frame-Ähnlichkeit.</div>
+  </div>
+</body>
+</html>