223015b-2026 kap1: Noto Sans Mono für code-tags geladen + an code-stack-anfang. Problem: vorher hat code-font auf Noto Sans JP gefallen (war im stack vor 'monospace' generic) → Latin chars wurden proportional sans gerendert statt mono. Fix: 'Noto Sans Mono' (mono google-font) als first-choice + JP/SC weiter hinten für CJK-fallback. hex1/hex2/.jpg etc. wieder monospace

per user-request einen branch der main-content UND rewrite-content trägt — saubere separierung statt symlink/merge-conflict.

struktur:
- slides/<course>/ → main-content restored, eigene assets (kein new-demo-leak)
- slides/<course>-2026/ → rewrite-content, eigene assets (komplett kopiert + new demos)

Makefile: COURSES += 223015b-2026 223015c-2026 dhbw-2026 mit eigenen NAME/KAPITEL/DEPLOY/KLAUSUR-konfig. Klausur für b+c=1, dhbw=leer. Deploy-paths /hdm/223015b-2026 etc.

make build durchlaufen für alle 6 decks, 0 fehler.

dedup: 223015c+dhbw assets identisch in beiden ordnern (kein neu-demos auf b ergänzt). 223015b 86 → 120 files in -2026 (= +34 neue eroeffner/usb-c-drei-achsen/container-vs-codec/etc).

.gitignore

@@ -35,6 +35,6 @@ hdm-internettechnik-slides/
 *.bak
 .idea
 
-# Interne Klausur-Previews – NIE committen/deployen
-slides/**/*-INTERN.md
-slides/*-INTERN.md
+# 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 clean            # Remove generated files
+make qr URL=...               # Generate QR code
+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
+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

Makefile

@@ -7,7 +7,7 @@
 # -----------------------------------------------------------------------------
 # Course registry
 # -----------------------------------------------------------------------------
-COURSES   = 223015b 223015c dhbw
+COURSES   = 223015b 223015c dhbw 223015b-2026 223015c-2026 dhbw-2026
 SLIDES_DIR = slides
 DEPLOY_HOST = tengo@tuttle.uberspace.de
 
@@ -18,15 +18,31 @@ DEPLOY_HOST = tengo@tuttle.uberspace.de
 223015b_KLAUSUR = 1
 
 223015c_NAME    = Internettechnologien
-223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css klausurfolien klausurfragen
+223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien klausurfragen
 223015c_DEPLOY  = /home/tengo/html/hdm/223015c
 223015c_KLAUSUR = 1
 
-dhbw_NAME    = Web Engineering
-dhbw_KAPITEL = 01-intro 02-html-css 03-js-frameworks 04-nodejs-basics 05-express 06-testing 07-typescript 08-docker 09-best-practices
+dhbw_NAME    = Technik I – Grundlagen IT
+dhbw_KAPITEL = 01_web_eng 02_css_extended 03_nodejs_basics 04_nodejs_advanced 05_testing 06_typescript 07_docker 08_best_practices
 dhbw_DEPLOY  = /home/tengo/html/dhbw
 dhbw_KLAUSUR =
 
+# -- 2026-rewrite versions --------------------------------------------------
+223015b-2026_NAME    = Dateiformate, Schnittstellen, Speichermedien (Rewrite 2026)
+223015b-2026_KAPITEL = 00-intro 01-daten-grundlagen 02-kompression 03-inhalte-bild-audio-video 04-speicher-schnittstellen 05-distribution-metadaten klausurfolien klausurfragen
+223015b-2026_DEPLOY  = /home/tengo/html/hdm/223015b-2026
+223015b-2026_KLAUSUR = 1
+
+223015c-2026_NAME    = Internettechnologien (Rewrite 2026)
+223015c-2026_KAPITEL = 00-intro 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien klausurfragen
+223015c-2026_DEPLOY  = /home/tengo/html/hdm/223015c-2026
+223015c-2026_KLAUSUR = 1
+
+dhbw-2026_NAME    = Technik I – Grundlagen IT (Rewrite 2026)
+dhbw-2026_KAPITEL = 01_web_eng 02_css_extended 03_nodejs_basics 04_nodejs_advanced 05_testing 06_typescript 07_docker 08_best_practices
+dhbw-2026_DEPLOY  = /home/tengo/html/dhbw-2026
+dhbw-2026_KLAUSUR =
+
 # Courses with klausur extraction enabled
 KLAUSUR_COURSES = $(foreach c,$(COURSES),$(if $($(c)_KLAUSUR),$(c),))
 ROOT_DEPLOY     = /home/tengo/html/hdm

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: Daten-Grundlagen" 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 — Daten-Grundlagen
+
+- 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** | Daten-Grundlagen + 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-daten-grundlagen-bogen.md

@@ -0,0 +1,131 @@
+# Kapitel 1 — Daten-Grundlagen + Signal zum Byte
+
+**Bedient Klausur-Blöcke:** 1 (Daten-Grundlagen) + 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 — Daten-Grundlagen | — | — | 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 Daten-Grundlagen
+- **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/223015c-lernziele.md

@@ -0,0 +1,114 @@
+# 223015c — Operative Lernziele (Vorschlag, zur Diskussion)
+
+**Status:** Vorschlag, *nicht gelockt*. Du redigierst.
+**Basis:** Klausur-Themen-Vorschlag aus `klausur-themen-223015c.md`.
+**Eichmaß:** Fließsatz, default Bloom *Verstehen* (nicht *Anwenden*). Lebensweltanker wo sinnvoll.
+
+## Kapitel 1 — Geschichte, Grundlagen & HTML
+
+### Block A — Von-Neumann-Grundlagen
+
+**A.1** Die Studierenden können die fünf Komponenten der Von-Neumann-Architektur (Steuerwerk, Rechenwerk, Speicher, I/O, Bus) benennen und mit der Architektur ihres eigenen Laptops oder Smartphones in Verbindung bringen.
+
+**A.2** Die Studierenden können erklären, warum das *„stored-program"-Prinzip* (Daten und Programm im gleichen Speicher) eine Revolution war — im Vergleich zu ENIAC (Verkabelung neu für jedes Programm).
+
+**A.3** Die Studierenden können die Rolle der Pioniere (Lovelace, Hollerith, Turing, von Neumann, Hopper, Booth, Hamilton) im Konzept der modernen Rechenarchitektur einordnen.
+
+### Block B — Internet-Entstehung
+
+**B.1** Die Studierenden können den historischen Hintergrund von ARPANET (Kalter Krieg, Resilience gegen Atomschlag) benennen und das WWW (1989, Berners-Lee, CERN) zeitlich + technisch unterscheiden.
+
+**B.2** Die Studierenden können den physikalischen Aufbau des heutigen Internets (1,3 Mio. km Unterseekabel, Backbone-Topologie, Bedeutung großer Knotenpunkte wie Frankfurt DE-CIX) skizzieren.
+
+### Block C — TCP/IP-Schichtenmodell
+
+**C.1** Die Studierenden können die 4 Schichten von TCP/IP (Network/Link, Internet, Transport, Application) benennen und ein typisches Protokoll je Schicht zuordnen (Ethernet, IP, TCP/UDP, HTTP).
+
+**C.2** Die Studierenden können erklären, was Encapsulation bedeutet — dass jede Schicht den Datenstrom der höheren Schicht in eigene Header/Trailer einpackt.
+
+**C.3** Die Studierenden können die Bezeichnung der Daten-Einheit pro Schicht benennen (Bit/Frame/Packet/Segment/Data).
+
+**C.4** Die Studierenden können die Unterschiede TCP/IP vs. OSI auf Tabellen-Ebene wiedergeben (4 vs. 7 Schichten, was wo zusammengezogen wurde).
+
+### Block D — Adress-Tripel (IP, MAC, Port)
+
+**D.1** Die Studierenden können erklären, was eine **IP-Adresse** im Internet identifiziert (Endgerät, weltweit eindeutig im Datenfluss) — und können die Notation v4 (4 × 0-255) und v6 (8 × 0-FFFF) lesen.
+
+**D.2** Die Studierenden können erklären, dass eine **MAC-Adresse** auf der Link-Schicht das nächste physische Gerät identifiziert (lokales Netz, 6 Byte hex).
+
+**D.3** Die Studierenden können den **Port** als Identifikator des Ziel-Programms auf einem Endgerät verstehen (z.B. 80 = HTTP, 443 = HTTPS, 22 = SSH).
+
+**D.4** Die Studierenden können das Zusammenspiel am Beispiel `localhost:8080` erklären — IP zur Maschine, Port zum Programm darauf.
+
+### Block E — DNS und HTTP
+
+**E.1** Die Studierenden können den Ablauf eines DNS-Lookups skizzieren (Root → TLD → Authoritative → Records) und erklären, warum Caching die Antwortzeit drastisch reduziert.
+
+**E.2** Die Studierenden können einen HTTP-Request lesen (Method, Path, Header, Body) und seinen Response (Status, Header, Body) deuten.
+
+**E.3** Die Studierenden können die wichtigsten Statuscodes einordnen: 200 (OK), 301 (Moved), 404 (Not Found), 500 (Server Error).
+
+**E.4** Die Studierenden können HTTP/1.1 vs. HTTP/2 vs. HTTP/3 konzeptionell unterscheiden — was wurde verbessert (Header-Komprimierung, Multiplexing, QUIC).
+
+### Block F — Browser-Ablauf-Synthese
+
+**F.1** Die Studierenden können die 7 Schritte vom *Enter im Browser* bis *Pixel am Bildschirm* nacheinander erklären: URL parsen → DNS lookup → TCP-Handshake → TLS-Handshake → HTTP-Request → HTML-Parsing → CSS+JS rendern.
+
+**F.2** Die Studierenden können beispielhaft benennen, was bei einem Fehler passiert (DNS failed → kein Verbindungsaufbau, TLS-Fehler → Warnung im Browser, 404 → leere Seite mit Statuscode).
+
+### Block G — HTML-Grundlagen
+
+**G.1** Die Studierenden können die Tag-Struktur (`<tag attr="wert">Inhalt</tag>`) und ihre Bestandteile (Opening, Closing, Attribute, Inhalt) benennen.
+
+**G.2** Die Studierenden können die wichtigsten **semantischen HTML-Tags** (`header`, `nav`, `main`, `section`, `article`, `aside`, `footer`) und ihren Zweck erklären.
+
+**G.3** Die Studierenden können die Document-Struktur (`<!DOCTYPE html>`, `<html>`, `<head>` mit `meta`, `<body>`) hinschreiben.
+
+**G.4** Die Studierenden können begründen, warum semantische HTML-Tags wichtig sind — für **SEO**, für **Accessibility** (Screen-Reader), für **Wartbarkeit**.
+
+## Kapitel 2 — Netzwerke, Protokolle & CSS
+
+### Block H — CSS-Grundlagen
+
+**H.1** Die Studierenden können das **Box-Model** (Content, Padding, Border, Margin) skizzieren und die Bedeutung von `box-sizing: border-box` erklären.
+
+**H.2** Die Studierenden können die wichtigsten CSS-**Selektoren** lesen und ihre Wirkung erklären: Element (`p`), Klasse (`.btn`), ID (`#header`), Pseudo-Klassen (`:hover`, `:focus`).
+
+**H.3** Die Studierenden können die Bedeutung von **Kaskade** und **Spezifizität** erklären — warum eine `.btn`-Regel eine `p`-Regel überschreibt, eine `#header`-Regel eine `.btn`-Regel.
+
+**H.4** Die Studierenden können **Flexbox** und **Grid** konzeptionell unterscheiden — wann nehme ich welches (1D-Reihe vs. 2D-Gitter)?
+
+### Block I — Barrierefreiheit (A11y)
+
+**I.1** Die Studierenden können das **Barrierefreiheitsstärkungsgesetz (BFSG)** und den **European Accessibility Act (EAA)** zeitlich und inhaltlich einordnen — dass digitale Produkte ab 28.06.2025 barrierefrei sein müssen.
+
+**I.2** Die Studierenden können die 4 **WCAG-Prinzipien (POUR)** benennen: **P**erceivable, **O**perable, **U**nderstandable, **R**obust.
+
+**I.3** Die Studierenden können erklären, dass **semantisches HTML die Grundlage von A11y** ist — und **ARIA als Ergänzung**, nicht als Ersatz.
+
+**I.4** Die Studierenden können drei konkrete A11y-Kriterien benennen und prüfen können: Alt-Text für Bilder, Farbkontrast 4.5:1 (Text), Keyboard-Navigierbarkeit aller interaktiven Elemente.
+
+## Kapitel 3 — Interaktivität & JavaScript
+
+*Per Klausur-Themen-Vorschlag: **JavaScript ist aktuell NICHT klausurrelevant**. Lernziele auf Verstehen-Niveau (kein Code-Schreiben in der Klausur).*
+
+**J.1** Die Studierenden können die Rolle von **JavaScript im Browser** einordnen — was es kann (DOM manipulieren, auf Events reagieren, fetch, localStorage) und was nicht (lokal Dateien auf der Platte lesen ohne User-Aktion).
+
+**J.2** Die Studierenden können den Begriff **DOM** (Document Object Model) erklären — dass HTML im Browser als manipulierbarer Baum vorliegt.
+
+**J.3** Die Studierenden können den Begriff **Event** erklären — dass User-Aktionen (Klick, Tastendruck) im Browser auslösen, dass JS reagieren kann.
+
+**J.4** Die Studierenden können die Begriffe **Framework** und **Library** unterscheiden und ein Beispiel benennen (React = Library, Vue/Angular = Framework — mit Disclaimer dass die Unterscheidung umstritten ist).
+
+## Anmerkungen
+
+- **Block F (Browser-Ablauf)** ist die Synthese-Stelle — sehr klausurfähig.
+- **Block I (A11y)** ist die einzige rechtlich verpflichtende Komponente — BFSG ist neu.
+- **Kapitel 3 (JS)** ist mit Absicht auf Verstehen-Niveau gehalten. Wenn du JS in der Klausur willst, müssen wir Block J nach oben skalieren.
+
+## Offene Fragen
+
+1. Block F als Pflicht-Synthese oder optional? *(Vorschlag: Pflicht, weil verbindendes Verständnis.)*
+2. Block I (A11y) auf BFSG/EAA-Niveau oder tiefer (konkrete WCAG-Kriterien anwenden)?
+3. Block H4 (Flexbox vs Grid) — sollen Studis das anwenden (Code schreiben) oder nur unterscheiden (Konzept)?
+4. JS-Lernziele J.1–J.4 — reicht das oder JS soll mehr Tiefe bekommen?

docs/223015c/01-geschichte-grundlagen-html-bogen.md

@@ -0,0 +1,87 @@
+# Kap 1 — Geschichte, Grundlagen & HTML
+
+**Bedient Klausur-Blöcke:** A (Von-Neumann) + B (Internet-Entstehung) + G (HTML-Grundlagen)
+**Slide-Budget:** ~40 (90-min)
+**Aktueller Stand:** 100 Slides → 60% Reduktion nötig.
+
+## Bogen
+
+Eine Stunde, eine Frage: **„Wie sind wir vom Lochkarten-Rechenwerk zum HTML-Tag im Browser gekommen — und warum spielt das heute noch eine Rolle?"**
+
+1. **Eröffner:** „Du tippst `librete.ch` ein und schaust auf eine Seite. Was alles dahinter steht." → 7-Schritte-Diagramm (Vorschau auf Block F, wird in Kap 2 vertieft).
+2. **Pioniere:** Lovelace (algorithm) → Hollerith (Maschine zählt Daten) → Turing (universelle Maschine) → von Neumann (Architektur, die wir heute noch nutzen). 6 Personen, keine Galerie-Folie pro Person.
+3. **Von-Neumann-Architektur:** 5 Komponenten. Brücke zum Smartphone: „dein iPhone ist eine Von-Neumann-Maschine".
+4. **Pivot zu Netz:** „Eine Maschine ist eine Maschine. Was passiert, wenn wir zwei verbinden? ARPANET (1969)."
+5. **Internet-Timeline:** ARPANET (1969) → Email (1971) → TCP/IP (1983) → WWW (1989) → Mosaic (1993). Vier Milestones, nicht zwanzig.
+6. **Physik:** 1,3 Mio km Unterseekabel als Bodenfaktor, DE-CIX Frankfurt.
+7. **Pivot zu HTML:** „Du surfst auf der Website. Was bekommst du eigentlich vom Server geliefert?" → HTML.
+8. **HTML-Anatomie:** Tag-Struktur, DOCTYPE, head/body. Semantische Tags. Validität (warum kein div-Suppe).
+9. **Selbstlernen:** Im DevTools-Inspector eine Seite anschauen.
+
+## Advance Organizer
+
+Konkret-erkenntnisgewinnend (nicht Schablone): das **Welt-zu-Pixel-Diagramm** mit allen Stationen, die in diesem Kapitel angerissen werden — Rechenarchitektur, Internet-Layer, HTML-Render. Wird in Kap 2 (Netzwerk-Tiefe) und 3 (JS) vertieft.
+
+→ Demo-Datei: `kap-c-01-bogen.html` (NEU)
+
+## Folien-Skelett (Vorschlag)
+
+| # | Typ | Titel/Kern | Lernziel | Visualisierung |
+|---|-----|-----------|---------|----------------|
+| 1 | Cover | Kapitel 1 | — | reuse |
+| 2 | Lead | „Du tippst librete.ch ein..." | — | — |
+| 3 | Advance Organizer | Welt → Pixel (alle Stationen) | A.1+B.1+G.1 | NEU kap-c-01-bogen |
+| 4 | Lead | Pioniere | — | — |
+| 5 | Inhalt | Ada Lovelace + Hollerith | A.3 | reuse |
+| 6 | Inhalt | Turing + Manhattan-Projekt + ENIAC | A.3 | reuse |
+| 7 | Inhalt | von Neumann + die Architektur | A.1, A.2 | reuse |
+| 8 | Klausur | Die 5 Komponenten Von-Neumann | A.1 | reuse |
+| 9 | Inhalt | Hopper, Booth, Hamilton | A.3 | reuse |
+| 10 | Lead | Vom Militär zum Netz | — | — |
+| 11 | Inhalt | Kalter Krieg + ARPANET | B.1 | reuse |
+| 12 | Klausur | Internet-Timeline (4 Milestones) | B.1 | NEU timeline |
+| 13 | Inhalt | WWW 1989 Berners-Lee | B.1 | reuse |
+| 14 | Inhalt | Mosaic + die 90er | B.1 | reuse |
+| 15 | Inhalt | Unterseekabel | B.2 | reuse |
+| 16 | Inhalt | DE-CIX, Frankfurt | B.2 | NEU dce-cix-karte |
+| 17 | Lead | Was bekommt der Browser? | — | — |
+| 18 | Inhalt | Eine Webseite ist HTML | G.1 | reuse |
+| 19 | Klausur | HTML-Anatomie: Tag-Struktur | G.1 | reuse |
+| 20 | Demo | HTML-Grundgerüst | G.3 | reuse grundgeruest |
+| 21 | Klausur | DOCTYPE + head + body | G.3 | reuse |
+| 22 | Inhalt | Attribute (id, class, href, src) | G.1 | reuse tag-attribut |
+| 23 | Inhalt | Semantische HTML-Tags | G.2 | reuse |
+| 24 | Klausur | Header/nav/main/article/section/footer | G.2 | reuse |
+| 25 | Inhalt | Warum semantisch? (SEO, A11y) | G.4 | reuse |
+| 26 | Inhalt | Validität: kein div-Suppe | G.4 | — |
+| 27 | Demo | Inspector im Browser | G.1 | reuse dom-tree |
+| 28 | Inhalt | Häufige HTML-Tags-Übersicht | G.1, G.2 | NEU html-tags-cheatsheet |
+| 29 | Inhalt | Forms (input, label, button, textarea) | G.1 | reuse button + input |
+| 30 | Inhalt | Dialog + Details | G.2 | reuse dialog + details-open/closed |
+| 31 | Selbstlernen | DevTools-Inspector eigene Lieblings-Seite | G.4 | — |
+| 32 | Zusammenfassung | Pioniere → Internet → HTML | alle A+B+G | NEU |
+
+~32 statt 100 Slides. Drastische Reduktion durch Streichen der Vertiefungs-Folien und Galerie-Inflation.
+
+## Streichungs-Liste
+
+Aus aktuellem 01-geschichte-grundlagen-html.md (100 Slides):
+- Galerie-Folien pro Person (jede mit Bild + 5 Bullet Points): 12 Personen → 6 (Lovelace, Hollerith, Turing, von Neumann, Hopper, Hamilton)
+- Z3, Mark I, ENIAC als drei Einzelfolien → eine
+- IBM/NS-Vertiefung als zwei Folien → eine
+- HTML-Tag-Listen-Folien (jede mit 5-7 Tags) → eine Cheatsheet-Folie
+- Frameworks-Logos-Slides (React, Vue, Astro etc.) — gehört in JS-Kapitel (Block J)
+- A11y-Folien hier → verschieben nach Kap 2 (wo CSS/A11y kombiniert)
+- Diverse „Bei näherem Hinsehen"-Vertiefungen die Mayer-Redundancy verletzen
+
+## Visualisierungs-TODO
+
+| Demo | Neu/Reuse | Status |
+|------|-----------|--------|
+| kap-c-01-bogen | NEU | Phase 3 |
+| internet-timeline | NEU | Phase 3 |
+| dce-cix-karte | NEU | Phase 3 |
+| html-tags-cheatsheet | NEU | Phase 3 |
+| Alle anderen | reuse | bereits in 164 demos |
+
+→ 4 neue Demos für Kap 1.

docs/223015c/02-netzwerke-protokolle-css-bogen.md

@@ -0,0 +1,117 @@
+# Kap 2 — Netzwerke, Protokolle & CSS
+
+**Bedient Klausur-Blöcke:** C (TCP/IP-Schichten) + D (IP/MAC/Port) + E (DNS+HTTP) + F (Browser-Ablauf) + H (CSS) + I (A11y)
+**Slide-Budget:** ~50 (90-min, ggf. 2 Termine — größtes Kapitel)
+**Aktueller Stand:** 91 Slides → bleibt ungefähr gleich, aber strukturell aufgeräumt.
+
+## Bogen
+
+Eine Stunde, eine Frage: **„Wie reisen Bytes vom Server in Frankfurt zu deinem Browser in Stuttgart — und wie wird der ankommende HTML-Code zu einer hübschen Seite?"**
+
+1. **Eröffner:** der „URL bis Pixel"-Ablauf als Bogen-Anker. 7 Schritte, jeder kommt in diesem Kapitel dran.
+2. **Adress-Tripel:** IP, MAC, Port. Drei Schichten, drei Fragen.
+3. **TCP/IP-Schichten:** 4 Schichten + Encapsulation. Warum Schichten überhaupt?
+4. **DNS:** wie findet die Maschine die richtige IP zur URL?
+5. **HTTP:** wie sieht die Anfrage und Antwort aus?
+6. **Pivot zu Darstellung:** Browser hat HTML. Jetzt: wie wird das hübsch?
+7. **CSS-Anatomie:** Selektoren, Box-Model, Kaskade.
+8. **Layout:** Flexbox + Grid.
+9. **A11y:** BFSG/EAA + WCAG POUR + semantisch + ARIA.
+
+## Advance Organizer
+
+Bogen-konkret: „Pakete reisen → Browser rendert" als zwei-akt-pipeline. Wird in der Sub-Sektionen ausgepackt.
+
+→ Demo: `kap-c-02-bogen.html` (NEU)
+
+## Folien-Skelett (Vorschlag)
+
+### Sub-A: Netzwerk (25 Slides)
+
+| # | Typ | Titel/Kern | Lernziel | Visualisierung |
+|---|-----|-----------|---------|----------------|
+| 1 | Cover | Kapitel 2 | — | reuse |
+| 2 | Lead | Pakete reisen + Browser rendert | F.1 | NEU bogen |
+| 3 | Inhalt | URL→Pixel (Vorschau auf alle 7 Schritte) | F.1 | reuse |
+| 4 | Lead | Adressen | — | — |
+| 5 | Klausur | IP — Endgerät identifizieren | D.1 | reuse ip-packet |
+| 6 | Klausur | MAC — nächster physischer Hop | D.2 | reuse ethernet |
+| 7 | Klausur | Port — Ziel-Programm | D.3 | reuse client-server-ports |
+| 8 | Klausur | IP vs MAC vs Port — Vergleich | D.4 | reuse |
+| 9 | Lead | TCP/IP-Schichtenmodell | — | — |
+| 10 | Klausur | Die 4 Schichten | C.1 | reuse osi-tcpip-diagram |
+| 11 | Inhalt | Encapsulation Schritt für Schritt | C.2 | reuse encap-stack + decap-stack |
+| 12 | Klausur | Datenüberbringung: Bit→Frame→Packet→Segment | C.3 | reuse encap-layers |
+| 13 | Inhalt | OSI vs TCP/IP | C.4 | reuse osi-tcpip-diagram |
+| 14 | Lead | DNS | — | — |
+| 15 | Klausur | Was tut DNS? | E.1 | reuse dns-lookup |
+| 16 | Klausur | DNS-Hierarchie Root→TLD→Authoritative | E.1 | reuse dns-tree |
+| 17 | Demo | nslookup im Terminal | E.1 | — |
+| 18 | Lead | HTTP | — | — |
+| 19 | Klausur | HTTP-Request lesen (Method, Path, Header) | E.2 | NEU http-request-anatomie |
+| 20 | Klausur | HTTP-Response (Status, Header, Body) | E.2 | NEU http-response-anatomie |
+| 21 | Klausur | Statuscodes 200/301/404/500 | E.3 | NEU statuscodes-tabelle |
+| 22 | Inhalt | HTTP/1.1 → HTTP/2 → HTTP/3 | E.4 | NEU http-versionen |
+| 23 | Demo | DevTools Network-Tab | E.2 | — |
+| 24 | Inhalt | TCP-Handshake | C.1 | reuse tcp-handshake |
+| 25 | Klausur | Block F: Synthese URL→Pixel (7 Schritte) | F.1 | NEU 7-schritte-master |
+
+### Sub-B: CSS + A11y (25 Slides)
+
+| # | Typ | Titel/Kern | Lernziel | Visualisierung |
+|---|-----|-----------|---------|----------------|
+| 26 | Lead | Was tut CSS? | — | — |
+| 27 | Inhalt | CSS-Anatomie | H.1 | reuse css-anatomie |
+| 28 | Klausur | CSS-Selektoren-Übersicht | H.2 | reuse css-selector-* |
+| 29 | Inhalt | Kombinatoren | H.2 | reuse css-combinators |
+| 30 | Inhalt | Pseudo-Klassen + Pseudo-Elemente | H.2 | reuse |
+| 31 | Klausur | Spezifizität | H.3 | reuse css-specificity |
+| 32 | Klausur | Box-Model | H.1 | reuse css-box-model + box-model-diagram |
+| 33 | Inhalt | Display: block / inline / flex / grid | H.4 | — |
+| 34 | Inhalt | Flexbox-Anatomie | H.4 | NEU flexbox-axes |
+| 35 | Inhalt | Grid-Anatomie | H.4 | NEU grid-areas |
+| 36 | Klausur | Flexbox vs Grid — wann was | H.4 | NEU flexbox-vs-grid |
+| 37 | Inhalt | Responsive Design (media queries) | H.4 | reuse css-responsive |
+| 38 | Inhalt | Farbe + Kontrast | I.4 | reuse css-colors |
+| 39 | Lead | Barrierefreiheit | — | — |
+| 40 | Klausur | BFSG + EAA — was kommt 28.06.2025 | I.1 | NEU bfsg-zeitleiste |
+| 41 | Klausur | WCAG-POUR (4 Prinzipien) | I.2 | NEU pour-diagramm |
+| 42 | Klausur | Semantisches HTML als A11y-Foundation | I.3 | reuse a11y-semantic |
+| 43 | Inhalt | ARIA als Ergänzung | I.3 | — |
+| 44 | Inhalt | Alt-Text für Bilder | I.4 | — |
+| 45 | Klausur | Kontrast 4.5:1 für Text | I.4 | reuse contrast-levels |
+| 46 | Inhalt | Keyboard-Navigation | I.4 | reuse keyboard-a11y + a11y-focus |
+| 47 | Klausur | Error-States: visuell + textuell | I.4 | reuse a11y-error |
+| 48 | Demo | A11y-Audit mit DevTools | I.4 | — |
+| 49 | Selbstlernen | Eine eigene Seite auf WCAG prüfen | I.4 | — |
+| 50 | Zusammenfassung | Reise + Render | alle | NEU |
+
+## Streichungs-Liste
+
+Aus aktuellem 02-netzwerke-protokolle-css.md (91 Slides):
+- Doppelte Vertiefungs-Folien zu „Encapsulation" (3 → 1)
+- BitTorrent/P2P-Folien — gehört nicht hierhin, raus
+- Glossar-Folien — als Speaker-Notes
+- Diverse „Bei näherem Hinsehen"-Slides (Mayer-Redundancy)
+- ARP-Lookup-Detail — entfernen oder als Bonus
+- IPv6-Tiefen-Folien — auf eine Folie eindampfen
+
+## Visualisierungs-TODO
+
+| Demo | Neu/Reuse |
+|------|-----------|
+| kap-c-02-bogen | NEU |
+| http-request-anatomie | NEU |
+| http-response-anatomie | NEU |
+| statuscodes-tabelle | NEU |
+| http-versionen | NEU |
+| 7-schritte-master | NEU |
+| flexbox-axes | NEU |
+| grid-areas | NEU |
+| flexbox-vs-grid | NEU |
+| bfsg-zeitleiste | NEU |
+| pour-diagramm | NEU |
+| summary-c-02 | NEU |
+| Alle anderen | reuse aus 164 bestehenden |
+
+→ 12 neue Demos für Kap 2. Großes Demo-Investment, aber klausur-zentral.

docs/223015c/03-interaktivitaet-javascript-bogen.md

@@ -0,0 +1,75 @@
+# Kap 3 — Interaktivität & JavaScript
+
+**Bedient Klausur-Block:** J (nicht-klausurrelevant, Verstehen-Niveau)
+**Slide-Budget:** ~30 (90-min, ggf. weniger)
+**Aktueller Stand:** 49 Slides → leicht reduzieren + neu sortieren.
+
+## Bogen
+
+Eine Stunde, eine Frage: **„Was passiert, wenn der HTML-Code da ist und nichts mehr funktioniert? Wo kommt das Interaktive her?"**
+
+1. **Eröffner:** Eine statische Website (HTML+CSS) reagiert auf nichts. Klick auf Button → nichts. **JS macht es interaktiv.**
+2. **Was ist JS?** Browser-Skriptsprache seit 1995. Heute in jedem Webserver, jeder Mobile-App, vielen Desktop-Apps (Electron).
+3. **Variablen, Funktionen, Schleifen:** das Mindeste. Code-Lesen-Niveau.
+4. **DOM:** HTML ist im Browser ein Baum. JS kann ihn anfassen.
+5. **Events:** User-Aktionen lösen JS-Callbacks aus.
+6. **Hands-on:** Dark-Mode-Toggle, To-Do-Liste — kleine Beispiele für ein „Aha".
+7. **Frameworks-Vorschau:** React, Vue, Angular — was sind die, wann nimmt man sie?
+
+## Advance Organizer
+
+„Statisch → Dynamisch". HTML+CSS rendert. JS reagiert.
+
+## Folien-Skelett (Vorschlag)
+
+| # | Typ | Titel/Kern | Lernziel | Visualisierung |
+|---|-----|-----------|---------|----------------|
+| 1 | Cover | Kapitel 3 | — | reuse |
+| 2 | Lead | „Statisch ist langweilig" | — | — |
+| 3 | Inhalt | Was kann JS, was kann es nicht | J.1 | NEU js-was-kann-es |
+| 4 | Inhalt | JS-Timeline (1995, 2009 Node, 2015 ES6) | J.1 | reuse |
+| 5 | Inhalt | Wie binde ich JS ein | J.1 | reuse |
+| 6 | Inhalt | Die Browser-Konsole (DevTools) | J.1 | reuse js-console |
+| 7 | Inhalt | Variablen: let, const, var | J.1 | — |
+| 8 | Inhalt | Datentypen (string, number, boolean, ...) | J.1 | — |
+| 9 | Inhalt | Arrays | J.1 | reuse js-arrays |
+| 10 | Inhalt | Objects | J.1 | reuse js-objects |
+| 11 | Inhalt | Funktionen | J.1 | — |
+| 12 | Inhalt | Schleifen (for, forEach, map, filter) | J.1 | reuse js-loops |
+| 13 | Inhalt | Kontrollstrukturen (if/else) | J.1 | — |
+| 14 | Lead | Das DOM | — | — |
+| 15 | Inhalt | DOM als Baum | J.2 | reuse dom-tree |
+| 16 | Inhalt | Elemente finden (querySelector) | J.2 | reuse js-manipulate |
+| 17 | Inhalt | Elemente erzeugen (createElement) | J.2 | reuse js-create |
+| 18 | Inhalt | Klassen manipulieren (classList) | J.2 | reuse js-classlist |
+| 19 | Lead | Events | — | — |
+| 20 | Inhalt | Event-Listener | J.3 | reuse js-event-listener |
+| 21 | Inhalt | preventDefault | J.3 | reuse js-preventdefault |
+| 22 | Inhalt | Häufige Events (click, input, submit) | J.3 | — |
+| 23 | Demo | Dark-Mode-Toggle | J.3 | reuse js-darkmode |
+| 24 | Demo | To-Do-Liste | J.3 | reuse js-todo |
+| 25 | Inhalt | fetch + JSON | J.1 | reuse js-fetch |
+| 26 | Inhalt | localStorage | J.1 | reuse js-localstorage |
+| 27 | Lead | Frameworks | — | — |
+| 28 | Inhalt | React + Vue + Angular — was sind sie | J.4 | reuse |
+| 29 | Inhalt | Library vs Framework | J.4 | NEU library-vs-framework |
+| 30 | Selbstlernen | Eigenes Mini-Projekt | alle J | — |
+
+~30 statt 49 Slides. Reduktion durch Wegnehmen der Galerie-Folien für jedes Framework-Logo.
+
+## Streichungs-Liste
+
+Aus aktuellem 03-interaktivitaet-javascript.md (49 Slides):
+- Framework-Logo-Galerie-Folien (React-Logo + Vue-Logo + Svelte-Logo + Astro-Logo + Webpack/Vite/Parcel separat) — eine Übersichts-Folie reicht
+- Doppelte „Was kann JS"-Folien — eine reicht
+- Hands-On-Folien mit langem Code — Code in `assets/code/` als separate Datei, in Folie nur kurzer Auszug
+
+## Visualisierungs-TODO
+
+| Demo | Neu/Reuse |
+|------|-----------|
+| js-was-kann-es | NEU |
+| library-vs-framework | NEU |
+| Alle anderen | reuse |
+
+→ 2 neue Demos für Kap 3. Geringes Demo-Investment, dafür gut bestückt aus den 164 vorhandenen Demos.

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/dhbw-fundament.md

@@ -0,0 +1,44 @@
+# DHBW Technik I — Fundament (Vorschlag, zur Diskussion)
+
+**Status:** Vorschlag von mir, *nicht gelockt*. Du redigierst, dann lock.
+**Format-Vorbild:** wie das HdM-Fundament in `CLAUDE.md`, aber DHBW-spezifisch zugeschnitten.
+
+## Drei Meta-Lernziele für DHBW Technik I
+
+DHBW-Studierende sind Dualstudierende — sie pendeln zwischen Theorie-Phase (an der DHBW) und Praxis-Phase (im Unternehmen). Das verändert die didaktische Aufgabe gegenüber HdM:
+
+### 1. Industrie-Anschluss-Fähigkeit
+
+Studis sollen am Ende **mit aktuellen Industrie-Tools, -Konzepten und -Konventionen vertraut sein** — nicht nur konzeptionell, sondern handwerklich. Ziel: in der Praxis-Phase im Unternehmen können sie auf 70 % des dort verwendeten Stacks zeigen und sagen „kenne ich, kann ich".
+
+*Konsequenz:* keine veralteten Tools (kein jQuery, kein PHP-Heritage). Aktuelle Stack-Wahl: Node 24 LTS, ESM, TypeScript, Docker, Git/GitHub. CLI-First.
+
+### 2. Selbstständig-Lernen-Lernen
+
+DHBW-Studis kommen oft direkt aus dem Abi und in eine erste fachliche Auseinandersetzung mit IT. **Werkzeugkompetenz zum eigenen Lernen** ist wichtiger als enzyklopädisches Wissen.
+
+*Konsequenz:* explizite Anleitung wie man Doku liest (MDN, ARIA-Spec, RFC), wie man Errors googelt, wie man eine Issue formuliert. „Ich kenne die Doku" > „ich kenne die Antwort auswendig".
+
+### 3. Verbindung Theorie ↔ Praxis-Phase
+
+Was in der DHBW gelernt wird, wird sofort in der Praxis-Phase eingesetzt (oder eben nicht — dann hat die Veranstaltung versagt). **Jedes Thema braucht einen erkennbaren Anwendungsfall im typischen Praxis-Setting** des dualen Studiums.
+
+*Konsequenz:* Bezüge zu konkreten Unternehmens-Szenarien (z.B. „intern README schreiben", „CI-Pipeline reparieren", „Konvention im Repo lesen") sind nicht Bonus, sondern Pflicht.
+
+## Didaktische Werkzeuge (vom HdM-Fundament übernommen)
+
+Die HdM-Werkzeuge (Constructive Alignment, Advance Organizer, Mayer-12, Informatikdidaktik) gelten unverändert. Nur die *Lernziel-Inhalte* sind DHBW-spezifisch (siehe oben).
+
+## Validierungs-Kriterien (zusätzlich zur HdM-Checkliste)
+
+- [ ] Bedient die Folie mindestens eines der drei DHBW-Meta-Lernziele?
+- [ ] Gibt es einen *erkennbaren Praxis-Bezug* (Tool / Konvention / Stack-Komponente, die im Unternehmen real verwendet wird)?
+- [ ] Hilft das Material den Studis, das Thema *selbstständig zu vertiefen* (Verweis auf Doku, Beispiel-Repo, Übung)?
+
+## Offene Fragen für dich
+
+1. **Tool-Stack-Fokus:** Node + Docker + Git ist meine Lese-Annahme aus dem aktuellen Kurs. Stimmt das mit der Praxis-Verteilung an der DHBW Karlsruhe überein, oder gibt es einen anderen Industrie-Anschluss-Fokus (z.B. Java/Spring, .NET, Python)?
+2. **Praxis-Phase-Realität:** wie sehen die DHBW-Praxis-Phasen typischerweise aus? Welche Konventionen begegnen den Studis dort am häufigsten?
+3. **Soft-Skills-Block (Kapitel 8 best-practices):** soll der bleiben in dieser Tiefe oder fokussieren wir auf Hard-Skills?
+
+**Bitte beantworte → ich lock das Fundament → leite daraus die kapitelweisen Lernziele ab.**

docs/dhbw-lernziele.md

@@ -0,0 +1,146 @@
+# DHBW Technik I — Operative Lernziele (Vorschlag, zur Diskussion)
+
+**Status:** Vorschlag, *nicht gelockt*. Du redigierst.
+**Basis:** DHBW-Fundament (3 Meta-Lernziele aus `dhbw-fundament.md`) + Prüfungsleistung-Kompetenzen (`dhbw-pruefungsleistung.md`).
+**Eichmaß:** Fließsatz, default Bloom *Verstehen*, mit Praxis-Phasen-Anker.
+
+## Übergreifend (gilt für alle 8 Kapitel)
+
+Jedes Kapitel sollte mindestens *eines* der drei DHBW-Meta-Lernziele bedienen:
+1. Industrie-Anschluss-Fähigkeit (Tools, Stack, Konventionen)
+2. Selbstständig-Lernen-Lernen (Doku lesen, Errors googeln)
+3. Theorie-Praxis-Verbindung (Anwendungsfall in Unternehmens-Kontext)
+
+## Kapitel 1 — Web Engineering Grundlagen
+
+*Aktuell 1791 Zeilen — zu groß. Vorschlag: in 2 Teilkapitel splitten, oder stark reduzieren.*
+
+### Lernziele
+
+**1.1** Die Studierenden können den **Browser-Render-Ablauf** (URL → DNS → TCP/TLS → HTTP → HTML-Parsing → CSS+JS → Pixel) frei reproduzieren.
+
+**1.2** Die Studierenden können **semantisches HTML** schreiben (header, nav, main, section, article, footer, label/input/button) und begründen, warum es für SEO + A11y wichtig ist.
+
+**1.3** Die Studierenden können **A11y-Basis-Standards** (BFSG/EAA ab 28.06.2025, WCAG POUR, semantisches HTML, ARIA als Ergänzung) anwenden und ein Minimum-Lighthouse-A11y-Audit durchführen.
+
+**1.4** Die Studierenden können einen lokalen **Dev-Server** einrichten (mit `python -m http.server` oder Live-Server-Extension) und sind mit Browser-DevTools (Elements, Console, Network, Performance, Lighthouse) vertraut.
+
+**1.5** Die Studierenden kennen die heutige **Tool-Landschaft** (Editor: VS Code, Build-Tools: Vite/Webpack, Frameworks: React/Vue/Svelte/Astro) und können *eine* davon als „erste Wahl" begründen.
+
+## Kapitel 2 — CSS Extended
+
+### Lernziele
+
+**2.1** Die Studierenden können das **Box-Model** (content/padding/border/margin) anwenden und mit `box-sizing: border-box` als Default arbeiten.
+
+**2.2** Die Studierenden können **Flexbox-Layouts** schreiben (display: flex, flex-direction, justify-content, align-items, flex-wrap, gap) für 1D-Strukturen.
+
+**2.3** Die Studierenden können **Grid-Layouts** schreiben (display: grid, grid-template-columns/rows, gap, areas) für 2D-Strukturen.
+
+**2.4** Die Studierenden können **Responsive Design** mit Media Queries (mobile-first) umsetzen.
+
+**2.5** Die Studierenden können **CSS-Animations + Transitions** verwenden — und wissen, wann *nicht* (Reduced Motion, Performance).
+
+## Kapitel 3 — Node.js Basics
+
+### Lernziele
+
+**3.1** Die Studierenden verstehen die **Rolle von Node.js** — JavaScript-Runtime außerhalb des Browsers (Server, CLI-Tools, Build-Skripte).
+
+**3.2** Die Studierenden können ein **Node-Projekt initialisieren** (`npm init`, package.json verstehen, dependencies hinzufügen) und kennen den **Versions-Knoten 24 LTS** (oder aktuell).
+
+**3.3** Die Studierenden können **ESM-Module** (import/export) schreiben — und kennen die Unterschiede zu CommonJS.
+
+**3.4** Die Studierenden können einen **HTTP-Server** mit `node:http` oder Express erstellen, der REST-Endpunkte bereitstellt.
+
+**3.5** Die Studierenden können mit **fetch** in Node (oder einer HTTP-Library) Daten von externen APIs holen.
+
+## Kapitel 4 — Node.js Advanced
+
+### Lernziele
+
+**4.1** Die Studierenden können **async/await + Promise** korrekt anwenden — verstehen den Unterschied zwischen sequentiell und parallel ausführen.
+
+**4.2** Die Studierenden können mit **Datei-System (fs/promises)** lesen + schreiben.
+
+**4.3** Die Studierenden können mit **Datenbanken** (mind. SQLite oder PostgreSQL via Knex/Drizzle) CRUD-Operationen durchführen.
+
+**4.4** Die Studierenden können **Authentifizierung** in einem Hello-World-Setting umsetzen (mind. einfaches JWT oder Session-Cookie).
+
+**4.5** Die Studierenden kennen **Error-Handling** Patterns (try/catch + finally, Error-Klassen-Hierarchie).
+
+## Kapitel 5 — Testing
+
+### Lernziele
+
+**5.1** Die Studierenden können **Unit-Tests** mit Vitest (oder Jest) schreiben und ausführen.
+
+**5.2** Die Studierenden können **Testdriven Development (TDD)** an einem kleinen Beispiel durchspielen (rot → grün → refactor).
+
+**5.3** Die Studierenden können **Integration-Tests** für eine API schreiben (HTTP-Endpoint testen).
+
+**5.4** Die Studierenden kennen **End-to-End Tests** (Playwright/Cypress) und ihre Trade-offs gegenüber Unit-/Integration-Tests.
+
+**5.5** Die Studierenden können einen **Coverage-Report** lesen und beurteilen — wissen aber, dass 100% Coverage kein Qualitäts-Garant ist.
+
+## Kapitel 6 — TypeScript
+
+### Lernziele
+
+**6.1** Die Studierenden verstehen die **Rolle von TypeScript** — Aufsatz auf JavaScript für statisches Typchecking.
+
+**6.2** Die Studierenden können einfache **Typen** annotieren (string, number, boolean, arrays, objects, function-signaturen).
+
+**6.3** Die Studierenden können **Interfaces und Type-Aliase** definieren und unterscheiden.
+
+**6.4** Die Studierenden können **Generics** *lesen* (`Array<T>`, `Promise<T>`) — Schreiben ist Bonus.
+
+**6.5** Die Studierenden können **strict-mode tsconfig** Einstellungen verstehen (noImplicitAny, strictNullChecks).
+
+## Kapitel 7 — Docker
+
+### Lernziele
+
+**7.1** Die Studierenden verstehen das **Container-Konzept** — Trennung zwischen Anwendung und Host-System, „auf meinem Rechner läuft's"-Problem gelöst.
+
+**7.2** Die Studierenden können ein **Dockerfile** schreiben (FROM, COPY, RUN, CMD, EXPOSE).
+
+**7.3** Die Studierenden können **docker compose** für Multi-Container-Setups (App + Datenbank) verwenden.
+
+**7.4** Die Studierenden kennen **Multi-stage Builds** als Best Practice (Bonus).
+
+**7.5** Die Studierenden können Container in einer **CI-Pipeline** (GitHub Actions oder GitLab CI) builden + testen.
+
+## Kapitel 8 — Best Practices
+
+### Lernziele
+
+**8.1** Die Studierenden verstehen **Git-Hygiene** — sinnvolle Commits, **Conventional Commits** (feat:, fix:, docs:, …), `.gitignore` für Sprache + Editor.
+
+**8.2** Die Studierenden können eine **gute README** schreiben (was tut das Projekt, wie installieren, wie starten, wie testen, wie deployen).
+
+**8.3** Die Studierenden kennen **SOLID-Prinzipien** auf Code-Niveau und können sie *erkennen* (Anwenden ist Bonus).
+
+**8.4** Die Studierenden verstehen **12-Factor App** Prinzipien — Config über Environment, Process Stateless, ...
+
+**8.5** Die Studierenden können **Code-Reviews** geben + nehmen — wissen wie konstruktiv kommentieren.
+
+**8.6** Die Studierenden können **SemVer** (semantisches Versioning) anwenden + erklären (MAJOR.MINOR.PATCH).
+
+## Übergreifende Soft-Skills
+
+Diese sind nicht in einem Kapitel verankert sondern verteilen sich:
+
+- **Dokumentation lesen** (MDN, Node-Docs, npm-Package-Doku) — Block-übergreifend
+- **Stack Overflow + GitHub Issues** als Lern-Tools verwenden — Kap 8
+- **Code-Repos sauber strukturieren** — Kap 8
+- **Industrie-Konventionen** erkennen + einhalten — alle Kapitel
+
+## Offene Fragen
+
+1. **Kap 1 splitten** in 1a (Browser-Stack + HTML) und 1b (A11y + DevTools)? Aktuell 1791 Zeilen = zu groß.
+2. **Kap 6 TypeScript:** Tiefe — nur lesen-können oder auch selbst schreiben?
+3. **Kap 8 Best Practices:** behält der Soft-Skills-Anteil oder fokussieren wir auf Hard-Skills (Git, README, SOLID)?
+4. **Praxis-Phase-Bezug:** in welchen DHBW-Unternehmen sind die Studis verteilt? Stack-Verteilung würde uns helfen, die Schwerpunkte zu setzen (z.B. mehr Node oder mehr Java?).
+
+**Nach Beantwortung → leite ich daraus die Bögen pro Kapitel ab + plane die Slide-Restrukturierung.**

docs/dhbw-pruefungsleistung.md

@@ -0,0 +1,77 @@
+# DHBW Technik I — Prüfungsleistung-Kompetenzen (Vorschlag, zur Diskussion)
+
+**Status:** Vorschlag von mir, *nicht gelockt*. Du redigierst, dann lock.
+**Kontext:** DHBW Technik I hat keine Klausur, sondern eine **Projekt-Prüfungsleistung** (75 Pkt + 10 Bonus, Code-Abgabe + Präsentation).
+
+## Was die Prüfungsleistung zeigen soll
+
+Die Projekt-Abgabe sollte demonstrieren, dass Studis die **drei DHBW-Meta-Lernziele** verkörpern (siehe `dhbw-fundament.md`):
+
+1. **Industrie-Anschluss-Fähigkeit** — Stack ist aktuell, Konventionen werden eingehalten.
+2. **Selbstständig-Lernen** — Lösung ist nicht 1:1 aus dem Kurs, sondern eigener Pfad mit Doku/Beispielen.
+3. **Theorie-Praxis-Verbindung** — das Projekt löst ein realistisches (kleines) Industrie-Problem.
+
+## Vorschlag: 8 Kompetenz-Felder
+
+Pro Feld 5–15 Punkte (insgesamt 75 + 10 Bonus möglich).
+
+### 1. Projekt-Strukturierung & README (10 Pkt)
+- Klare Verzeichnisstruktur, sinnvolle Namen
+- README erklärt: was tut das Projekt, wie installieren, wie starten, wie testen
+- LICENSE-Datei
+
+### 2. Code-Qualität (15 Pkt)
+- Lesbar (sinnvolle Variablen-/Funktions-Namen, kurze Funktionen)
+- Konsistente Formatierung (Prettier/ESLint oder gleichwertig)
+- Keine ungenutzten Imports / Variablen
+- Sinnvolle Aufteilung in Module
+
+### 3. Git-Hygiene (10 Pkt)
+- Mindestens 5 sinnvolle Commits, keine `wip` / `fix` ohne Kontext
+- Conventional Commits Format (feat:, fix:, docs: …)
+- `.gitignore` für `node_modules`, `.env`, build-outputs
+- Optionale Bonus: GitHub-Workflow / CI
+
+### 4. Tests (10 Pkt)
+- Mindestens 3 Unit-Tests für nicht-triviale Funktionen
+- Tests laufen lokal durch (`npm test`)
+- Test-Coverage-Bericht (optional)
+
+### 5. Docker-Containerisierung (10 Pkt)
+- `Dockerfile` baut sauber
+- `docker compose up` startet das Projekt
+- Multi-stage-build (Bonus, falls sinnvoll)
+
+### 6. HTTP / API-Design (10 Pkt)
+- Mindestens 3 REST-Endpunkte (z.B. GET/POST/DELETE)
+- Sinnvolle Statuscodes (200, 400, 404, 500)
+- JSON-Antworten mit Schema
+
+### 7. Frontend (10 Pkt) *— wenn das Projekt eine UI hat*
+- Funktioniert auf Smartphone + Desktop
+- Mindestens 3 a11y-Kriterien erfüllt (semantisches HTML, alt-Text, Kontrast)
+- Build mit Vite oder gleichwertig
+
+### 8. Präsentation (5 Pkt + 10 Bonus)
+- 5 Min Live-Demo des Projekts
+- Erklärung: was war die größte Herausforderung, wie wurde sie gelöst
+- Bonus: kurze Reflexion über Design-Entscheidungen
+
+## Punkte-Skalierung
+
+| Bewertung | Punkte | Bedeutung |
+|-----------|-------:|-----------|
+| Sehr gut | 80–85 | über den Erwartungen, mit Bonus-Punkten |
+| Gut | 67–79 | alle Kompetenzen mit kleinen Lücken |
+| Befriedigend | 50–66 | alle Kompetenzen wenigstens angeschnitten |
+| Ausreichend | 33–49 | mind. 5 Felder ordentlich, 3 ggf. lückenhaft |
+| Nicht bestanden | < 33 | mehrere zentrale Felder fehlen |
+
+## Offene Fragen für dich
+
+1. **Frontend-Pflicht oder optional?** Kompetenz 7 ist nur sinnvoll wenn UI-Bestandteil — vielleicht macht es Sinn, das Projekt-Thema so zu wählen, dass UI Pflicht ist (z.B. „kleine Web-App mit Backend + Frontend").
+2. **Punkte-Verteilung 10/15/10/10/10/10/10/5:** stimmt das mit deinem Gewichts-Gefühl überein?
+3. **Bonus-Punkte:** wofür konkret? Vorschläge: Conventional Commits + CI-Workflow + Test-Coverage + Multi-stage-Docker + a11y-Audit. Welche zählst du als Bonus?
+4. **Plagiat-Erkennung:** wie gehst du mit AI-generierten Code-Anteilen um? KI-Hilfe ist Realität — sinnvoll Reglement?
+
+**Bitte beantworte → ich finalisiere die Prüfungsleistung-Kompetenzen → leite daraus die Lehrinhalte pro Kapitel ab.**

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 | **Daten-Grundlagen** | 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).

docs/klausur-themen-223015c.md

@@ -0,0 +1,86 @@
+# 223015c — Klausur-Themen-Vorschlag (zur Diskussion)
+
+**Status:** Vorschlag von mir, *nicht gelockt*. Du redigierst, dann lock.
+**Format-Vorbild:** wie `klausur-themen-2026.md` für 223015b (9 Blöcke).
+
+## Bestands-Aufnahme (Ist)
+
+- Kap 1 (Geschichte+HTML): 100 Slides — 8 mit `_class: klausur`
+- Kap 2 (Netzwerke+CSS): 91 Slides — 7 mit `_class: klausur`
+- Kap 3 (JS): 49 Slides — **0 klausur-Marker** → JS aktuell NICHT prüfungsrelevant
+- 164 demos im `assets/demos/`-Ordner (DNS-tree, TCP-handshake, CSS-selektoren, ARIA, etc.)
+
+## Vorschlag: 9 Klausur-Blöcke
+
+### Block A — Vom-Neumann-Grundlagen
+- 5 Komponenten der Von-Neumann-Architektur
+- Was war ENIAC, was Mark I, was Z3
+- Warum „stored program" eine Revolution war
+- *Berührungspunkt:* die Architektur eures eigenen Laptops
+
+### Block B — Internet-Entstehung
+- ARPANET-Motivation (Kalter Krieg)
+- Wer hat das WWW erfunden (Berners-Lee 1989), wo (CERN)
+- Was unterscheidet Internet vs WWW
+- Unterseekabel-Geographie als physische Realität
+
+### Block C — TCP/IP-Schichtenmodell
+- Die 4 Schichten (Network, Internet, Transport, Application)
+- Was passiert in jeder Schicht (Beispiel-PDU pro Schicht)
+- Warum Schichten — Trennung der Verantwortlichkeiten
+- OSI vs TCP/IP
+
+### Block D — Adress-Tripel (IP, MAC, Port)
+- Was identifiziert jede Adresse (Gerät · NIC · Programm)
+- Warum man alle drei braucht
+- Beispiel: Browser → Server bei `localhost:8080`
+
+### Block E — DNS und HTTP
+- Was tut ein DNS-Lookup
+- Hierarchie (Root → TLD → Authoritative → Records)
+- HTTP-Request-Response-Aufbau
+- Statuscodes (200, 301, 404, 500)
+- HTTP/2 + HTTP/3 (Header-Komprimierung, Multiplexing)
+
+### Block F — Gesamter Browser-Ablauf
+- Was passiert von `Enter` im Browser bis Pixel
+- 7 Schritte: URL → DNS → TCP/TLS → HTTP-Request → HTML-Parsing → CSS+JS → Render
+- *Synthese-Klausur-Block*
+
+### Block G — HTML-Grundlagen
+- Tag-Struktur (`<tag attr="wert">Inhalt</tag>`)
+- Semantische Tags (header, nav, main, article, section, footer)
+- Document-Struktur (DOCTYPE, head, body, meta-tags)
+- Validität: warum semantische Tags wichtig sind (SEO, A11y, Screen-Reader)
+
+### Block H — CSS-Grundlagen
+- Box-Model (content, padding, border, margin)
+- Selektoren (Element, Klasse, ID, Pseudo-Klassen, Kombinatoren)
+- Cascading + Spezifizität
+- Layout: Flexbox vs Grid (wann welches)
+
+### Block I — Barrierefreiheit (Accessibility / WCAG)
+- BFSG / EAA (was ist das, wann tritt es in Kraft)
+- WCAG 2.1 4 Prinzipien (POUR)
+- Semantisches HTML als Foundation
+- ARIA als Ergänzung (nicht Ersatz!)
+- Konkrete Beispiele: Alt-Text, Kontrast, Keyboard-Navigation
+
+## Verlagerungen / Kürzungen
+
+**Komplett raus (Vorschlag):**
+- JS-Hands-Ons als Klausur-Material (Block für JavaScript nicht aufnehmen)
+- BitTorrent, P2P, gRPC, GraphQL (zu speziell, gehört in Webentwicklung-Modul)
+
+**Reduziert:**
+- Geschichte-Personen-Galerie: 12 Personen → 6 (Lovelace, Turing, von Neumann, Hopper, Hamilton, Berners-Lee)
+- Hollerith/IBM/NS: behalten als Geschichts-Block, klausur-relevant Block A
+
+## Offene Fragen für dich
+
+1. **JS ja oder nein in Klausur?** Wenn ja: welche Tiefe (Konzept-Verständnis vs Code-Lesen vs Code-Schreiben)?
+2. **CSS-Tiefe:** Flexbox-Code lesen-können oder nur "Was ist Flexbox" konzeptionell?
+3. **A11y-Tiefe:** Standards aufzählen (WCAG, BFSG, EAA) oder konkrete WCAG-Kriterien anwenden?
+4. **Block F (Browser-Ablauf):** der ist methodisch synthetisch — wollen wir das als „Klausur-Pflicht-Synthese" oder als optionale Bonus-Frage?
+
+**Bitte beantworte → ich lock die Blöcke → leite daraus die operativen Lernziele ab.**

scripts/generate-index.sh

@@ -13,15 +13,6 @@ case "$COURSE" in
     SLIDES_URL="https://librete.ch/hdm/223015b"
     ACCENT_COLOR="#1e5f8a"
     ACCENT_LIGHT="#e8f4fc"
-    INSTITUTION="HdM Stuttgart"
-    HEADLINE="HdM Vorlesungen"
-    KAPITEL_TERM="Kapitel"
-    BREADCRUMB_URL="../"
-    EXAM_URL=""
-    EXAM_LABEL=""
-    KONTAKT_URL="mailto:mail@librete.ch"
-    KONTAKT_LABEL="Kontakt"
-    QR_IMG="qr-index.svg"
     ;;
   223015c)
     TITLE="Grundlagen IT- und Internettechnik"
@@ -29,72 +20,16 @@ case "$COURSE" in
     SLIDES_URL="https://librete.ch/hdm/223015c"
     ACCENT_COLOR="#d63384"
     ACCENT_LIGHT="#fce4ec"
-    INSTITUTION="HdM Stuttgart"
-    HEADLINE="HdM Vorlesungen"
-    KAPITEL_TERM="Kapitel"
-    BREADCRUMB_URL="../"
-    EXAM_URL=""
-    EXAM_LABEL=""
-    KONTAKT_URL="mailto:mail@librete.ch"
-    KONTAKT_LABEL="Kontakt"
-    QR_IMG="qr-index.svg"
-    ;;
-  dhbw)
-    TITLE="Web Engineering"
-    SUBTITLE="Informatik / Wirtschaftsinformatik"
-    SLIDES_URL="https://librete.ch/dhbw"
-    ACCENT_COLOR="#a02060"
-    ACCENT_LIGHT="#fce4ec"
-    INSTITUTION="DHBW Stuttgart"
-    HEADLINE="DHBW Vorlesungen"
-    KAPITEL_TERM="Sitzung"
-    BREADCRUMB_URL=""
-    EXAM_URL="https://git.librete.ch/DHBW/pruefungsleistung"
-    EXAM_LABEL="Prüfungsleistung"
-    KONTAKT_URL="mailto:michael.czechowski@lehre.dhbw-stuttgart.de"
-    KONTAKT_LABEL="Kontakt"
-    QR_IMG="assets/slides-dhbw.png"
     ;;
   *)
-    TITLE="$COURSE - Slides"
+    TITLE="$COURSE - HdM Slides"
     SUBTITLE="Lecture Slides"
-    SLIDES_URL="https://librete.ch/$COURSE"
+    SLIDES_URL="https://librete.ch/hdm/$COURSE"
     ACCENT_COLOR="#0066cc"
     ACCENT_LIGHT="#e8f4fc"
-    INSTITUTION="Stuttgart"
-    HEADLINE="Vorlesungen"
-    KAPITEL_TERM="Kapitel"
-    BREADCRUMB_URL=""
-    EXAM_URL=""
-    EXAM_LABEL=""
-    KONTAKT_URL="mailto:mail@librete.ch"
-    KONTAKT_LABEL="Kontakt"
-    QR_IMG="qr-index.svg"
     ;;
 esac
 
-# Optional breadcrumb HTML (empty if no parent overview)
-if [[ -n "$BREADCRUMB_URL" ]]; then
-  BREADCRUMB_HTML="<p class=\"breadcrumb\"><a href=\"$BREADCRUMB_URL\">← Kursübersicht</a></p>"
-else
-  BREADCRUMB_HTML=""
-fi
-
-# Optional exam-link HTML
-if [[ -n "$EXAM_URL" ]]; then
-  EXAM_HTML="<p class=\"exam-link\"><a href=\"$EXAM_URL\">$EXAM_LABEL →</a></p>"
-else
-  EXAM_HTML=""
-fi
-
-# Footer kursübersicht link only when breadcrumb parent exists
-if [[ -n "$BREADCRUMB_URL" ]]; then
-  FOOTER_KURS_HTML=" ·
-    <a href=\"$BREADCRUMB_URL\">Kursübersicht</a>"
-else
-  FOOTER_KURS_HTML=""
-fi
-
 # Topic mappings for nice German titles
 declare -A TOPIC_MAP
 TOPIC_MAP["intro"]="Einführung"
@@ -106,14 +41,6 @@ TOPIC_MAP["vertiefung-offene-fragen"]="Vertiefung & Offene Fragen"
 TOPIC_MAP["geschichte-grundlagen-html"]="Geschichte, Grundlagen & HTML"
 TOPIC_MAP["netzwerke-protokolle-css"]="Netzwerke, Protokolle & CSS"
 TOPIC_MAP["interaktivitaet-javascript"]="Interaktivität & JavaScript"
-TOPIC_MAP["html-css"]="HTML & CSS"
-TOPIC_MAP["js-frameworks"]="JS, Frameworks & Build Tools"
-TOPIC_MAP["nodejs-basics"]="Node.js: Scripting, Running & Building"
-TOPIC_MAP["express"]="Express API, CRUD & Middlewares"
-TOPIC_MAP["testing"]="Testing"
-TOPIC_MAP["typescript"]="TypeScript"
-TOPIC_MAP["docker"]="Docker, Proxies & DBs"
-TOPIC_MAP["best-practices"]="Wrap-up & Best Practices"
 
 # Configure which topics should appear disabled per course
 # Two modes: fully disabled (non-clickable card) and buttons-disabled (link remains clickable, buttons are disabled)
@@ -121,17 +48,8 @@ declare -A DISABLED_FULL
 declare -A DISABLED_BUTTONS
 # For course B: chapters 3,4,5 should be fully disabled
 DISABLED_FULL["223015b"]="speichermedien-schnittstellen distribution-apis-zukunft vertiefung-offene-fragen"
-# For course C: all chapters fully active
-DISABLED_BUTTONS["223015c"]=""
-
-# Courses where the "Klausurrelevante Folien" card should be active (clickable)
-declare -A KLAUSURFOLIEN_ACTIVE
-KLAUSURFOLIEN_ACTIVE["223015b"]=1
-
-# Courses where the "Klausurfragen" card should be active (clickable)
-declare -A KLAUSURFRAGEN_ACTIVE
-KLAUSURFRAGEN_ACTIVE["223015b"]=1
-KLAUSURFRAGEN_ACTIVE["223015c"]=1
+# For course C: chapter 3 should keep link clickable but buttons disabled
+DISABLED_BUTTONS["223015c"]="interaktivitaet-javascript"
 
 cat > "$BUILD_DIR/index.html" << HEADER
 <!DOCTYPE html>
@@ -183,16 +101,6 @@ cat > "$BUILD_DIR/index.html" << HEADER
       font-size: 0.875rem;
       margin-top: 0.25rem;
     }
-    .exam-link {
-      margin-top: 1rem;
-      font-size: 0.95rem;
-    }
-    .exam-link a {
-      color: $ACCENT_COLOR;
-      text-decoration: none;
-      font-weight: 500;
-    }
-    .exam-link a:hover { text-decoration: underline; }
     /* Use the .termine wrapper and add a gap between cards */
     .termine {
       margin-top: 1.5rem;
@@ -318,12 +226,11 @@ cat > "$BUILD_DIR/index.html" << HEADER
 </head>
 <body>
   <header>
-    $BREADCRUMB_HTML
-    <h1>$HEADLINE</h1>
+    <p class="breadcrumb"><a href="../">← Kursübersicht</a></p>
+    <h1>HdM Vorlesungen</h1>
     <h2 class="course-heading">$TITLE</h2>
     <p class="subtitle">$SUBTITLE</p>
-    <p class="meta">$INSTITUTION · Sommersemester 2026 · Michael Czechowski</p>
-    $EXAM_HTML
+    <p class="meta">HdM Stuttgart · Sommersemester 2026 · Michael Czechowski</p>
   </header>
   <div class="termine">
 HEADER
@@ -346,7 +253,7 @@ for html in $(ls "$BUILD_DIR"/[0-9][0-9]-*.html 2>/dev/null | sort); do
   if [[ "$kapitel_num" == "0" ]] || [[ -z "$kapitel_num" ]]; then
     kapitel_label="Einführung"
   else
-    kapitel_label="$KAPITEL_TERM $kapitel_num"
+    kapitel_label="Kapitel $kapitel_num"
   fi
 
   pdf_filename="${filename%.html}.pdf"
@@ -413,29 +320,13 @@ LINK
 
 done
 
-# Add klausurfolien entry if it exists (active per KLAUSURFOLIEN_ACTIVE, else disabled)
+# Add klausurfolien entry if it exists (disabled — wird noch überarbeitet)
 if [[ -f "$BUILD_DIR/klausurfolien.html" ]]; then
-  if [[ "${KLAUSURFOLIEN_ACTIVE[$COURSE]}" == "1" ]]; then
-    pdf_active=""
-    if [[ -f "$BUILD_DIR/klausurfolien.pdf" ]]; then
-      pdf_active="<a href=\"klausurfolien.pdf\" class=\"btn btn-pdf\">PDF</a>"
-    fi
-    cat >> "$BUILD_DIR/index.html" << KLAUSUR
-    <div class="kapitel-card" style="border-left: 3px solid $ACCENT_COLOR;">
-      <a href="klausurfolien.html" class="kapitel-link">
-        <div class="kapitel-label">Prüfung</div>
-        <div class="kapitel-title">Klausurrelevante Folien</div>
-      </a>
-      <a href="klausurfolien.html" class="btn btn-slides">Folien</a>
-      $pdf_active
-    </div>
-KLAUSUR
-  else
-    pdf_disabled=""
-    if [[ -f "$BUILD_DIR/klausurfolien.pdf" ]]; then
-      pdf_disabled="<span class=\"btn btn-pdf btn-disabled\">PDF</span>"
-    fi
-    cat >> "$BUILD_DIR/index.html" << KLAUSUROFF
+  pdf_disabled=""
+  if [[ -f "$BUILD_DIR/klausurfolien.pdf" ]]; then
+    pdf_disabled="<span class=\"btn btn-pdf btn-disabled\">PDF</span>"
+  fi
+  cat >> "$BUILD_DIR/index.html" << KLAUSUR
     <div class="kapitel-card disabled" style="border-left: 3px solid $ACCENT_COLOR;">
       <div class="kapitel-link">
         <div class="kapitel-label">Prüfung</div>
@@ -444,41 +335,20 @@ KLAUSUR
       <span class="btn btn-slides btn-disabled">Folien</span>
       $pdf_disabled
     </div>
-KLAUSUROFF
-  fi
+KLAUSUR
 fi
 
-# Add klausurfragen entry if it exists (active per KLAUSURFRAGEN_ACTIVE, else disabled)
+# Add klausurfragen entry if it exists (disabled — wird noch überarbeitet)
 if [[ -f "$BUILD_DIR/klausurfragen.html" ]] || [[ -f "$BUILD_DIR/klausurfragen.pdf" ]]; then
-  if [[ "${KLAUSURFRAGEN_ACTIVE[$COURSE]}" == "1" ]]; then
-    pdf_active=""
-    if [[ -f "$BUILD_DIR/klausurfragen.pdf" ]]; then
-      pdf_active="<a href=\"klausurfragen.pdf\" class=\"btn btn-pdf\">PDF</a>"
-    fi
-    slides_active=""
-    if [[ -f "$BUILD_DIR/klausurfragen.html" ]]; then
-      slides_active="<a href=\"klausurfragen.html\" class=\"btn btn-slides\">Folien</a>"
-    fi
-    cat >> "$BUILD_DIR/index.html" << KLAUSURFRAGEN
-    <div class="kapitel-card" style="border-left: 3px solid $ACCENT_COLOR;">
-      <a href="klausurfragen.html" class="kapitel-link">
-        <div class="kapitel-label">Prüfung</div>
-        <div class="kapitel-title">Klausurfragen</div>
-      </a>
-      $slides_active
-      $pdf_active
-    </div>
-KLAUSURFRAGEN
-  else
-    pdf_disabled=""
-    if [[ -f "$BUILD_DIR/klausurfragen.pdf" ]]; then
-      pdf_disabled="<span class=\"btn btn-pdf btn-disabled\">PDF</span>"
-    fi
-    slides_disabled=""
-    if [[ -f "$BUILD_DIR/klausurfragen.html" ]]; then
-      slides_disabled="<span class=\"btn btn-slides btn-disabled\">Folien</span>"
-    fi
-    cat >> "$BUILD_DIR/index.html" << KLAUSURFRAGENOFF
+  pdf_disabled=""
+  if [[ -f "$BUILD_DIR/klausurfragen.pdf" ]]; then
+    pdf_disabled="<span class=\"btn btn-pdf btn-disabled\">PDF</span>"
+  fi
+  slides_disabled=""
+  if [[ -f "$BUILD_DIR/klausurfragen.html" ]]; then
+    slides_disabled="<span class=\"btn btn-slides btn-disabled\">Folien</span>"
+  fi
+  cat >> "$BUILD_DIR/index.html" << KLAUSURFRAGEN
     <div class="kapitel-card disabled" style="border-left: 3px solid $ACCENT_COLOR;">
       <div class="kapitel-link">
         <div class="kapitel-label">Prüfung</div>
@@ -487,18 +357,18 @@ KLAUSURFRAGEN
       $slides_disabled
       $pdf_disabled
     </div>
-KLAUSURFRAGENOFF
-  fi
+KLAUSURFRAGEN
 fi
 
 cat >> "$BUILD_DIR/index.html" << FOOTER
   </div>
   <div class="qr-section">
-    <img src="$QR_IMG" alt="QR Code" class="qr-code">
+    <img src="qr-index.svg" alt="QR Code" class="qr-code">
     <p class="qr-url">$SLIDES_URL</p>
   </div>
   <footer>
-    <a href="$KONTAKT_URL">$KONTAKT_LABEL</a>$FOOTER_KURS_HTML
+    <a href="mailto:mail@librete.ch">Kontakt</a> ·
+    <a href="../">Kursübersicht</a>
   </footer>
 </body>
 </html>

slides/223015b-2026/00-intro.md

@@ -0,0 +1,192 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
+title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+---
+
+<style>
+:root {
+  --color-foreground: #1a1a2e;
+  --color-highlight: #1e5f8a;
+  --color-dimmed: #4a4a6a;
+}
+section.invert {
+  --color-foreground: #fff;
+}
+section {
+  font-size: 1.7rem;
+}
+h1 {
+  color: #1e5f8a;
+}
+section.invert h1 {
+  color: #fff;
+}
+h2 {
+  color: #1f2937;
+}
+pre {
+  background: #0f0f23;
+  color: #5fb3e4;
+  border-radius: 8px;
+  border-left: 3px solid #1e5f8a;
+}
+pre code {
+  background: transparent;
+  color: inherit;
+}
+code {
+  background: #0f0f23;
+  padding: 0.15em 0.4em;
+  border-radius: 4px;
+  font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
+}
+section code:not(.hljs) { color: #5fb3e4 !important; }
+section code.hljs { color: #f8f8f8 !important; }
+a {
+  color: var(--color-highlight);
+}
+section.klausur {
+  background: repeating-linear-gradient(
+    135deg,
+    #e3f2fd,
+    #e3f2fd 40px,
+    #fff 40px,
+    #fff 80px
+  ) !important;
+}
+@media print {
+  section.klausur {
+    background: #e3f2fd !important;
+  }
+}
+section.aufgabe {
+  background: #e3f2fd !important;
+}
+section.aufgabe footer {
+  display: none;
+}
+</style>
+
+<!-- _class: invert -->
+<!-- _header: '' -->
+<!-- _backgroundColor: #000 -->
+
+![bg cover opacity:0.2](./assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg)
+
+# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+
+**223015b** · Modul "Technik 1" · 1. Semester
+Digital- und Medienwirtschaft
+Hochschule der Medien Stuttgart
+
+**Sommersemester 2026**
+
+[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/qrcode-0.svg)
+
+---
+
+<!-- _class: lead -->
+
+# Herzlich willkommen!
+## Einführung
+
+---
+
+# Über mich
+
+**Michael Werner Czechowski**
+
+- Systems and Platform Engineer
+- Schwerpunkte:
+  - Web-Technologien, Barriere-Armut, Systemarchitektur, Open Source
+- Hintergrund:
+  - Philosophie (Uni Stuttgart)
+  - Wirtschaftsinformatik (Leibniz-FH Hannover)
+- Kontakt: lb-czechowski@hdm-stuttgart.de
+
+---
+
+# Warum dieses Modul?
+
+**Digitale Medien sind überall.**
+
+* Warum enthalten Fotos oft Informationen über den Aufnahmeort?
+* Warum lassen sich gelöschte Dateien wiederherstellen?
+* Warum benötigt eine Minute 4K-Video unkomprimiert 45 GB Speicher?
+* Warum zeigt eine "1 TB"-Festplatte nur 931 GB an?
+* Warum ist USB-C nicht gleich USB-C?
+* Ziel: **→ Mitreden können!**
+
+<!--
+1. EXIF (Exchangeable Image File Format)-Metadaten speichern GPS-Koordinaten, Kameramodell und Zeitstempel automatisch. Die meisten wissen nicht, dass diese Daten beim Versenden mitgeschickt werden. → Kapitel 4: Metadaten
+
+2. Beim Löschen wird nur der Verzeichniseintrag im Dateisystem entfernt, nicht die Daten selbst. Die Bits bleiben auf dem Datenträger, bis sie überschrieben werden. → Kapitel 3: Dateisysteme
+
+3. 3840 × 2160 Pixel × 3 Byte (RGB) × 30 Bilder/Sek × 60 Sek = ~45 GB. Codecs wie H.264/H.265 komprimieren um Faktor 100+. → Kapitel 1+2: Kompression
+
+4. Hersteller rechnen dezimal (1 TB = 10¹² Bytes), Betriebssysteme binär (1 TiB = 2⁴⁰ Bytes). Die Differenz beträgt bei Terabyte bereits ~10%. → Kapitel 1: Dateneinheiten
+
+5. USB-C ist nur die Steckerform. Dahinter können USB 2.0 (480 Mbit/s), USB 3.2 (20 Gbit/s) oder Thunderbolt 4 (40 Gbit/s) laufen — gleiches Kabel, völlig unterschiedliche Leistung. → Kapitel 3: Schnittstellen
+-->
+
+---
+
+# Kurze Umfrage
+
+**Bitte Hand heben:**
+
+* Wer kennt den Unterschied zwischen analog und digital?
+* Wer hat schon mal eine Datei von einem Format in ein anderes konvertiert?
+* Wer hat schon mal Metadaten aus einem Foto entfernt?
+* Wer hat schon mal ein Backup verloren?
+* Wer hat schon mal ein Backup wiederhergestellt?
+
+<!--
+Niveau der Gruppe einschätzen
+Keine falschen Antworten
+Zeigt, wo wir starten
+API = Application Programming Interface
+-->
+
+---
+
+# Kursübersicht
+
+**Kapitel:**
+
+* 1. **Grundlagen**, Text & Audio (Bits, Bytes, Zeichenkodierung, MP3)
+* 2. Bild- & Video-**Kompression** (JPEG, PNG, H.264/H.265)
+* 3. **Speichermedien** & **Schnittstellen** (HDD, SSD, USB, Thunderbolt)
+* 4. **Distribution** und Verteilung (Streaming, REST, Cloud)
+* Vertiefung & offene Fragen
+
+
+---
+
+<!-- _class: klausur -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+<!-- _backgroundColor: #e3f2fd -->
+
+# Prüfungsleistung
+
+**Nach aktuellem Kenntnisstand:**
+
+* 90 min insg. (Technik 1)
+* Schriftliche Klausur (digital)
+* Teils offene Fragen
+* Kein Coding/Programmieren
+* **Prüfungsrelevante Folien:**
+  - Gestreift oder Vollton (PDF) markiert

slides/223015b-2026/01-daten-grundlagen.md

@@ -0,0 +1,935 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
+title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+---
+
+<style>
+@import url('https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@400;700&family=Noto+Sans+SC:wght@400;700&family=Noto+Sans+Mono:wght@400;700&display=swap');
+:root {
+  --color-foreground: #1a1a2e;
+  --color-highlight: #1e5f8a;
+  --color-dimmed: #4a4a6a;
+}
+section.invert {
+  --color-foreground: #fff;
+}
+section {
+  font-size: 1.7rem;
+  font-family: system-ui, -apple-system, "Segoe UI", Roboto, "Noto Sans JP", "Noto Sans SC", "Apple Color Emoji", "Segoe UI Emoji", sans-serif;
+}
+h1 {
+  color: #1e5f8a;
+}
+section.invert h1 {
+  color: #fff;
+}
+h2 {
+  color: #1f2937;
+}
+pre {
+  background: #0f0f23;
+  color: #5fb3e4;
+  border-radius: 8px;
+  border-left: 3px solid #1e5f8a;
+}
+pre code {
+  background: transparent;
+  color: inherit;
+}
+code {
+  background: #0f0f23;
+  padding: 0.15em 0.4em;
+  border-radius: 4px;
+  font-family: "Noto Sans Mono", ui-monospace, "SF Mono", Menlo, Consolas, "Noto Sans JP", "Noto Sans SC", monospace;
+}
+section code:not(.hljs) { color: #5fb3e4 !important; }
+section code.hljs { color: #f8f8f8 !important; }
+a {
+  color: var(--color-highlight);
+}
+section.klausur {
+  background: repeating-linear-gradient(
+    135deg,
+    #e3f2fd,
+    #e3f2fd 40px,
+    #fff 40px,
+    #fff 80px
+  ) !important;
+}
+@media print {
+  section.klausur {
+    background: #e3f2fd !important;
+  }
+}
+section.aufgabe {
+  background: #e3f2fd !important;
+}
+section.aufgabe footer {
+  display: none;
+}
+section.erklaerung :not(header),
+section.erklaerung :not(footer)
+{
+  font-size: 1.1rem;
+}
+section.erklaerung h1 {
+  font-size: 1.5rem;
+  color: #1e5f8a;
+  margin-bottom: 0.3rem;
+}
+section.erklaerung ul,
+section.erklaerung ol {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung p {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung table {
+  font-size: 0.9rem;
+}
+</style>
+
+<!-- _class: invert -->
+<!-- _header: '' -->
+<!-- _backgroundColor: #000 -->
+
+![bg cover opacity:0.2](./assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg)
+
+# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+
+**223015b** · Modul "Technik 1" · 1. Semester
+Digital- und Medienwirtschaft
+Hochschule der Medien Stuttgart
+
+[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
+
+---
+
+![bg fit](./assets/qrcode-1.svg)
+
+---
+
+<!-- _class: lead -->
+
+# Kapitel 1
+## Daten-Grundlagen + Vom Signal zum Byte
+
+<!--
+Eine Stunde, eine Frage: *Was steckt in einer Datei — und wie kommt es da rein?*
+
+Roter Faden:
+1. Foto, Sprachnachricht, PDF — drei vertraute Dinge, alle haben dasselbe Innenleben
+2. Hex-Editor auf — Zahlen, nichts als Zahlen
+3. Wie man die Zahlen liest (Bit/Byte/Hex als drei Schreibweisen)
+4. Was die Zahlen bedeuten (ASCII → Unicode → Magic Numbers)
+5. PIVOT — aber wie kommen die Zahlen überhaupt rein?
+6. Sampling + Quantisierung — zwei Schritte, die jedes Signal digitalisieren
+7. Nyquist als Begründung für 44,1 kHz
+8. Aliasing als „was schiefgehen kann" — Audio-Knack und Moiré als gleiches Phänomen
+
+Das Kapitel hat zwei Strangs, die sich an der Mitte (= Byte) treffen.
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Was steckt eigentlich in einer Datei?
+
+<!--
+Beispiele aus dem Alltag der Studis:
+- Foto auf dem Smartphone
+- Sprachnachricht in WhatsApp
+- PDF im Studi-Mailfach
+
+Frage: Wenn wir die alle aufmachen würden — was würden wir sehen? Was haben die *gemeinsam*?
+
+Antwort kommt auf der nächsten Folie.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/drei-dateien.png)
+
+<!--
+Aufdeckung: Foto · Sprachnachricht · PDF sehen außen ganz verschieden aus. Aber wenn man den ersten Byte-Block anschaut: alle haben eine Visitenkarte (Magic Number) und bestehen ab da nur aus Byte.
+
+- Foto: 89 50 4E 47 = PNG
+- Sprachnachricht: 49 44 33 = ID3 (MP3-Tag)
+- PDF: 25 50 44 46 = %PDF
+
+Aussage: Außen verschieden, innen dieselbe Sprache. Egal ob Bild, Ton oder Dokument — eine Datei ist immer eine Folge von Byte.
+
+Was ein Byte ist und wie man es liest — kommt in den nächsten Folien.
+-->
+
+---
+
+![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
+```
+
+<!--
+Schock-Hook: das hier ist eine PNG-Datei. So sieht sie wirklich aus, wenn man sie im Hex-Editor öffnet.
+
+Studis sollen sich kurz wundern: das ist ein Bild? Es sieht aus wie Matrix-Code.
+
+Auflösung kommt Stück für Stück.
+
+Tool, das Studis benutzen können: hexed.it (Browser, kein Install).
+-->
+
+---
+
+# Eine Datei ist ein Byte-Strom
+
+**Vorne nach hinten. Ein Byte nach dem anderen.**
+
+Egal welches Format — die Datei beginnt mit Byte 1 und endet irgendwann.
+
+Jedes Byte ist eine Zahl zwischen `0` und `255`. *Mehr ist da nicht.*
+
+<!--
+Mentales Bild: Datei = Lokomotive aus Waggons. Jeder Waggon = 1 Byte = 1 Zahl 0..255.
+
+- Festplatte/SSD: speichert byteweise
+- Speicher (RAM): liest byteweise
+- CPU: adressiert byteweise (siehe nächste Folie)
+
+Wichtig: Es gibt keine "halben Byte" auf der Hardware. Die kleinste Adresse ist immer ein Byte. Bit gibts logisch, aber nicht physisch adressierbar.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/why-8-bit.png)
+
+<!--
+Warum gerade 8 Bit (nicht 7, nicht 16)?
+- CPU adressiert byteweise — kleinste adressierbare Einheit
+- 8 Bit = 2 Hex-Ziffern (elegante Darstellung)
+- 1964: IBM System/360 setzte den 8-Bit-Standard
+- Vorher: 6-Bit + 7-Bit-Systeme parallel im Einsatz
+- 1 Bit = 2 Zustände, 2 Bit = 4, ... 8 Bit = 256
+
+Eselsbrücke: 2 hoch (Anzahl Bit) = Anzahl Zustände.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/byte-fuer-byte.png)
+
+<!--
+Drei Schreibweisen, ein Inhalt:
+- Fenster 1 (Bin): rohe 0/1 — was tatsächlich auf der Platte steht
+- Fenster 2 (Hex): 2 Ziffern pro Byte — kompakt lesbar (1 Byte = 2 Hex-Ziffern)
+- Fenster 3 (Text): ASCII-Zeichen wenn Byte ≤ 126, sonst ✗
+
+Daraus folgt eine Klausurfrage: schon ein Byte > 126 → Binärdatei (PNG, MP3, ZIP).
+Nur Werte ≤ 126 → reine Textdatei (.txt, .csv, .md).
+
+In diesem Kapitel reden wir nicht (nur) über die ROHEN Byte. Wir reden über die drei Brillen, mit denen man dieselben Byte anschauen kann.
+-->
+
+---
+
+<!-- _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. Hex ist die menschenfreundliche Schreibweise des Maschinenformats.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/hex-dec-table.png)
+
+<!--
+Hex ↔ Dezimal Lookup:
+- 0..9 wie gewohnt
+- A = 10, B = 11, C = 12, D = 13, E = 14, F = 15
+
+Studis müssen das nicht auswendig wissen. Aber sie sollen erkennen: Hex ist nicht Magic — es ist eine Schreibweise mit 16 Symbolen statt 10.
+-->
+
+---
+
+# 01010000 oder 50 — was liest sich leichter?
+
+**Binär:** `01010000 01001110 01000111`
+
+**Hex:** `50 4E 47`
+
+Drei Byte. Dasselbe Inhalt. Hex ist nur **handlicher**.
+
+**Wo trifft man Hex im Alltag?** Beim CSS-Farbcode:
+`#FF5733` — das sind 3 Byte (Rot, Grün, Blau).
+
+<!--
+Anker im Alltag: CSS-Farbe `#FF5733`. Jede:r hat das mal gesehen — im Designtool, in der dev console, beim Theme-Eintippen.
+
+Auflösung:
+- #FF = 255 = Rot voll
+- #57 = 87 = Grün mittel
+- #33 = 51 = Blau wenig
+- Ergibt ein warmes Orange.
+
+Klausurrelevant: wenn jemand sagt "lila ist B399FF", können wir die drei Byte sofort als RGB lesen.
+-->
+
+---
+
+# Hex begegnet euch überall
+
+| Kontext | Beispiel |
+|---------|----------|
+| CSS-Farben | `#FF5733` |
+| MAC-Adressen | `00:1A:2B:3C:4D:5E` |
+| Speicheradressen | `0xA04F20` |
+| Windows-Fehlercodes | `0x80070005` |
+| Unicode-Codepoints | `U+00E4` (ä) |
+| Datei-Signaturen | `89 50 4E 47` (PNG) |
+
+<!--
+Präfixe:
+- `0x` = "das ist Hex" (in C, JS, Python)
+- `U+` = Unicode-Codepoint
+- `#` = CSS-Konvention
+
+Lebensweltanker: jede:r Studi hat mindestens drei dieser Kontexte schon real gesehen. Hex ist nicht eine akademische Übung, sondern die Lesart, in der Computer mit Menschen über Byte reden.
+
+MAC-Adresse: 6 Byte = 6 Paare Hex-Ziffern. Eindeutige Hardware-Kennung der Netzwerkkarte.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/byte-flow.png)
+
+<!--
+1 Byte = 8 Bit = 2 Hex-Ziffern = max. 1 ASCII-Zeichen.
+
+Dieselbe Datei, drei Schreibweisen — Byte für Byte parallel angezeigt.
+- Jeder Rahmen = ein Byte.
+- Byte ändern sich nicht, nur unsere Anzeige.
+- `0x0A` = Zeilenumbruch, nicht druckbar → Hex-Editoren zeigen `.` als Platzhalter.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/three-views.png)
+
+<!--
+Dieselben 8 Byte (PNG-Dateianfang: 89 50 4E 47 0D 0A 1A 0A) — drei Perspektiven:
+
+1. Bitstream — was wirklich gespeichert wird (unleserlich)
+2. Hex — gruppiert in 8-Bit-Häppchen (kompakt)
+3. Bedeutung — was die Byte signalisieren:
+   - 89: Magic Byte (>127 → "ich bin Binärdatei")
+   - 50 4E 47: P · N · G (ASCII-Format-Kürzel)
+   - 0D 0A 1A 0A: Carriage Return · Line Feed · End-of-File · Line Feed (erkennt kaputte Übertragung)
+
+Aussage: dieselbe Datei, je nach Brille sehe ich anderes. Die Datei selbst ändert sich nicht.
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Was bedeutet die Zahl `80`?
+
+<!--
+Strang-Wechsel: bis hier haben wir Byte als NOTATION gelernt (Bin/Hex parallele Schreibweisen). Jetzt fragen wir: was *bedeuten* die Byte?
+
+Die Zahl 80 in einer Textdatei ist der Buchstabe „P". Das ist ASCII.
+
+Auflösung kommt mit der ascii-Tabelle.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/ascii-table-colored.png)
+
+<!--
+US-ASCII (1967) Code Chart:
+- 7 Bit = 128 Zeichen
+- Erste 32 Zeichen: Steuerzeichen (nicht druckbar) — z.B. Tab, Newline, Backspace
+- Zeichen 32–126: druckbar (Buchstaben, Ziffern, Satzzeichen)
+- Zeichen 127: DEL
+- Keine Umlaute, kein ñ, kein é, kein chinesisches Zeichen
+
+Geschichte:
+- 1963 als US-amerikanischer Standard
+- 7 Bit, weil Fernschreiber 7-Bit-Codes nutzten + Paritätsbit für Fehlererkennung
+- 60 Jahre alt, lebt aber weiter — siehe UTF-8 (ASCII-kompatibel)
+-->
+
+---
+
+<!-- _class: lead -->
+
+# ASCII reicht für Englisch.
+## Aber was ist mit *ä, é, 中, 🌸*?
+
+<!--
+Bridge: 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.
+
+Quizfrage an die Studis: Wie viel Speicher braucht ein „ä"? Antwort: Kommt drauf an, welches Encoding. ASCII kann es gar nicht; UTF-8 braucht 2 Byte.
+
+Lösung: Unicode + UTF-8 (nächste Folie).
+-->
+
+---
+
+# Unicode: ein Standard für alle
+
+**Unicode (1991):** jedes Schriftsystem der Welt.
+**> 150.000 Zeichen.** Latein, Kyrillisch, Arabisch, Chinesisch, Japanisch, mathematische Symbole, Emoji.
+
+**UTF-8** speichert Unicode mit *variabler Länge:*
+
+- Zeichen 0–127: **1 Byte** (identisch mit ASCII — Abwärtskompatibilität!)
+- Westeuropäische Umlaute: **2 Byte**
+- Chinesisch/Japanisch: **3 Byte**
+- Emoji: **4 Byte**
+
+<!--
+- Unicode Consortium: Non-Profit, gegründet 1991
+- Unicode 16.0 (2024): 154.998 Zeichen
+- UTF-8 = Unicode Transformation Format, 8-bit (Ken Thompson & Rob Pike, 1992)
+- Die ersten 128 Zeichen in UTF-8 sind exakt ASCII — Grund warum ASCII nie verschwinden wird
+- UTF-8 ist seit 2008 das häufigste Encoding im Web (W3Techs)
+
+Pädagogisch wichtig: variable Länge heißt, dass „Zeichen zählen" und „Byte zählen" NICHT dasselbe sind. Das ist die Brücke zur nächsten Folie.
+-->
+
+---
+
+# Beispiel: Byte zählen
+
+**Text:** `"Hello·🌸·こんにちは·(Kon-ni-chi-wa)"`
+
+| Zeichen | Byte |
+|---------|-------|
+| `Hello·` | 6 × 1 = **6 Byte** (ASCII) |
+| `🌸` | **4 Byte** (Emoji) |
+| `·` | **1 Byte** |
+| `こんにちは` | 5 × 3 = **15 Byte** (Hiragana) |
+| `·(Kon-ni-chi-wa)` | **16 Byte** (ASCII) |
+
+**Gesamt: 42 Byte für 29 sichtbare Zeichen.**
+
+<!--
+Klausurfähig: gegeben ein Text mit ASCII, Umlauten, CJK und Emoji — wie viel Byte ist das?
+
+- ASCII (Hello, Klammern) = 1 Byte pro Zeichen
+- Emoji 🌸 (Cherry Blossom U+1F338) = 4 Byte
+- Hiragana こんにちは = 3 Byte pro Zeichen (U+3040–309F)
+- は wird hier „wa" ausgesprochen (Partikel), nicht „ha"
+
+Pointe: 29 sichtbare Zeichen, 42 Byte. Zeichen ≠ Byte sobald Unicode > 127.
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Woher weiß der Computer, was das ist?
+
+<!--
+Pivot zur dritten Bedeutungsebene: nicht „was bedeutet die Zahl 80?" (= P im ASCII), sondern „was bedeutet die *Folge* von Byte am Anfang einer Datei?".
+
+Antwort: Magic Numbers. Die ersten paar Byte sind die Visitenkarte des Formats.
+
+Auflösung kommt mit Magic-Numbers-Folie.
+-->
+
+---
+
+# Magic Numbers — die Visitenkarte der Datei
+
+**Datei-Typ erkennt man an den ersten Byte:**
+
+| Format | Magic Number (Hex) | Lesbar? |
+|--------|-------------------|---------|
+| PNG | `89 50 4E 47` | (89 außerhalb ASCII) P N G |
+| JPEG | `FF D8 FF` | — |
+| PDF | `25 50 44 46` | % P D F |
+| ZIP | `50 4B 03 04` | P K — — |
+
+**Achtung:** Werte > 127 sind nicht ASCII-druckbar. *Hex-Editoren zeigen einen Punkt oder ein anderes Ersatzzeichen als Platzhalter.*
+
+<!--
+- PNG nutzt absichtlich `89` (= 137 dezimal): markiert Datei eindeutig als Binär. Erkennt kaputte Übertragungen (alte Systeme schnitten Bit 7 ab).
+- "PK" bei ZIP = Phil Katz (Erfinder von PKZip, 1989)
+- DOCX, XLSX, PPTX, ODT = alles ZIP-Archive mit XML-Inhalt
+- Dateien OHNE Magic Number: TXT, HTML, CSS, JSON, XML — reiner Text, kein binäres Format
+- Sicherheitsrelevant: virus.exe → bild.jpg umbenennen täuscht nur Menschen; `file` (Linux) liest Magic Number und erkennt die echte Identität.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+<!-- _backgroundColor: #000 -->
+
+![bg fit](./assets/hex-code.png)
+
+<!--
+Echte PNG-Datei im Hex-Editor.
+
+Erste Byte: 89 50 4E 47 = PNG-Signatur.
+- 89: non-printable (außerhalb ASCII)
+- 50: P
+- 4E: N
+- 47: G
+- Danach IHDR = Image Header (Breite, Höhe, Farbtiefe)
+
+Tool: HxD (Windows), Hex Fiend (Mac), xxd (Linux), hexed.it (Browser).
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/8bit-P-character.png)
+
+<!--
+Zoom auf den Buchstaben „P":
+
+- Hex: 50
+- Dezimal: 80
+- Binär: 01010000
+- ASCII: P
+
+Ein Byte. Acht Bit. Ein Buchstabe. Drei Schreibweisen.
+
+Das ist die Brücke zwischen Notation (Hex/Bin) und Bedeutung (ASCII).
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg contain right:22%](./assets/qr/hexed-it.png)
+
+# Selbstlernen — HEX Files identifizieren
+
+1. Fünf Dateien ohne Dateiendung:
+   <a href="https://librete.ch/hdm/223015b/materials/hex1">`hex1`</a> · <a href="https://librete.ch/hdm/223015b/materials/hex2">`hex2`</a> · <a href="https://librete.ch/hdm/223015b/materials/hex3">`hex3`</a> · <a href="https://librete.ch/hdm/223015b/materials/hex4">`hex4`</a> · <a href="https://librete.ch/hdm/223015b/materials/hex5">`hex5`</a>
+2. Lies erste 16 Byte aus und identifiziere Dateiformat (Magic Number)
+3. *Optional: Datei umbenennen und korrekte Dateiendung anhängen (z.B. `.jpg`)*
+
+**Tools:** [hexed.it](https://hexed.it) · [Wikipedia-Magic-Number-Liste](https://en.wikipedia.org/wiki/List_of_file_signatures)
+
+<!--
+- hex1: Plaintext (keine Magic Number — pure ASCII)
+- hex2: PNG (89 50 4E 47)
+- hex3: JPEG (FF D8 FF)
+- hex4: DOCX (50 4B 03 04 — ZIP-Container, XML drin)
+- hex5: ZIP (50 4B 03 04)
+
+Pädagogisch: Studis sollen selbst sehen, dass Datei-Erkennung nicht über die Endung läuft, sondern über die Byte am Anfang. Das ist eine kleine Macht-Erfahrung — sie können mit `hexed.it` etwas, das die meisten Leute nicht können.
+
+Gruppenarbeit: 3–4 Personen. ~15 Min.
+-->
+
+---
+
+# KB vs KiB — warum „1 TB" als 931 GB angezeigt wird
+
+![bg right:48% contain](./assets/demos/kb-vs-kib.png)
+
+**Auf der Verpackung:** 1 TB = 10¹² Byte (dezimal).
+**Im Finder:** 931 GB = eigentlich 931 GiB (binär, 1024³).
+
+Es fehlt nichts — beide Seiten zählen nur in **verschiedenen Sprachen.**
+
+<!--
+- Marketing nutzt SI-Präfixe (1000³, 1000⁴) → größere Zahlen auf der Packung.
+- Betriebssysteme rechnen in Zweier-Potenzen (1024³) → kleinere angezeigte Zahl, weil Bits binär organisiert sind.
+- Korrekt wären `GiB` (Gibi-, binär) und `GB` (Giga-, dezimal). Realität: beide nennen es `GB`.
+
+Rechnung: 10¹² ÷ 2³⁰ ≈ 931,3 GiB. Der Finder zeigt „931 GB".
+
+Klausurfähig: warum zeigt eine 1-TB-SSD im Finder „931 GB"? Begründung mit Rechnung.
+-->
+
+---
+
+# Dateneinheiten — Größenordnungen
+
+| Einheit | Bytes (dezimal) | Beispiel |
+|---------|------:|----------|
+| **Byte** | 1 | Farbwert eines Pixels |
+| **Kilobyte (KB)** | 1.000 | kleiner Programmcode |
+| **Megabyte (MB)** | 1 Million | Textdokument |
+| **Gigabyte (GB)** | 1 Milliarde | Kinofilm in FullHD |
+| **Terabyte (TB)** | 1 Billion | ~12h Video in 4K |
+| **Petabyte (PB)** | 1 Billiarde | Netflix-Gesamtarchiv |
+| **Exabyte (EB)** | 1 Trillion | Alle E-Mails weltweit/Tag |
+| **Zettabyte (ZB)** | 1 Trilliarde | globale Datenmenge ~heute |
+
+<!--
+SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes. Auf Packungen, in Marketing.
+IEC-Präfixe (Binär): 1 KiB = 1.024 Bytes (Kibibyte). In Betriebssystemen (oft ohne i geschrieben — Verwechselung!).
+
+Eselsbrücke für die Reihenfolge:
+„**K**omm **M**it **G**roßem **T**ee, **P**eter **E**xte **Z**ettelt **Y**achten."
+→ Kilo, Mega, Giga, Tera, Peta, Exa, Zetta, Yotta.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/pivot-signal-zu-byte.png)
+
+<!--
+PIVOT. Wir haben die rechte Seite des Bogens abgearbeitet: aus Byte wird Bedeutung (Notation, Encoding, Format). Jetzt drehen wir um: wie kommen die Byte überhaupt rein?
+
+Beispiele:
+- Wir machen ein Foto → Lichtwelle → Pixel-Byte
+- Wir reden ins Mikro → Schallwelle → Audio-Byte
+- Wir tippen Text → Tastendruck → ASCII-Byte (das ist die einfache Variante)
+
+Die kontinuierliche Welt ist analog. Die Datei ist digital. Der Weg dazwischen heißt: Sampling + Quantisierung. Das schauen wir uns jetzt an, am Beispiel Audio.
+-->
+
+---
+
+# Analog vs. Digital — am Beispiel Schall
+
+![bg right:48% contain](./assets/druckwelle.png)
+
+Eine Stimme ist eine **Druckwelle**. Kontinuierlich — keine Stufen, keine Sprünge.
+
+Eine Audiodatei ist eine Folge von **Zahlen** — diskret, in Stufen.
+
+Wie übersetzen wir die Welle in Zahlen?
+
+**Zwei Schritte:** Sampling (wie oft) + Quantisierung (wie genau).
+
+<!--
+- Schall ist physikalisch: Luftmoleküle drücken auf das Trommelfell.
+- Diese Druckschwankung folgt einer kontinuierlichen Kurve in der Zeit.
+- Analog speichern (Vinyl, Tonband): die Rille / das Magnetfeld speichern die Druckkurve direkt.
+- Digital speichern: wir messen die Welle in regelmäßigen Abständen (Sampling) und runden jede Messung auf eine Stufe (Quantisierung).
+
+Beide Schritte sind notwendig. Beide haben einen Trade-off zwischen Datenrate und Genauigkeit.
+-->
+
+---
+
+# Sampling — wie oft messen wir?
+
+**Abtastrate** (Sample Rate) = wie viele Messungen pro Sekunde.
+
+| Sample Rate | Anwendung |
+|-------------|-----------|
+| 8 kHz | Telefon |
+| 22 kHz | alte Spiele-Sounds |
+| **44,1 kHz** | **CD-Qualität** |
+| 48 kHz | Video-Standard |
+| 96 kHz | Studio |
+
+Je höher die Sample Rate, desto näher kommt die Datei an die kontinuierliche Welle.
+
+<!--
+- 1 Hz = 1 Messung pro Sekunde
+- 44.100 Hz = 44.100 Messungen pro Sekunde
+- Warum genau 44,1 kHz? Kommt 5 Folien später (Nyquist).
+- Telefon mit 8 kHz: alles oberhalb 4 kHz fehlt — deshalb klingen Telefongespräche „dumpf"
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg contain](./assets/samplerate.webp)
+
+<!--
+Visualisierung: eine kontinuierliche Welle wird mit unterschiedlichen Sample-Raten abgetastet. Niedrige Rate verliert Detail. Hohe Rate erfasst die Welle treu.
+
+Konkrete Frage an Studis: bei welcher Rate erkennt man die Originalwelle noch?
+-->
+
+---
+
+# Quantisierung — wie genau messen wir?
+
+**Bittiefe** (Bit Depth) = wie fein wir jede Messung auflösen.
+
+| Bittiefe | Stufen | Dynamikumfang |
+|----------|--------|---------------|
+| 8 Bit | 256 | ~48 dB |
+| **16 Bit (CD)** | **65.536** | **~96 dB** |
+| 24 Bit (Studio) | 16,8 Mio. | ~144 dB |
+
+Je mehr Bit, desto kleiner der **Quantisierungsfehler** (Differenz zur Original-Druckwelle).
+
+<!--
+- Bittiefe sagt: wie viele verschiedene Lautstärke-Stufen kennt das Format pro Messung.
+- 8 Bit = 256 Stufen: hörbar grobkörnig (Quantisierungsrauschen).
+- 16 Bit = 65.536 Stufen: für menschliches Hören mehr als genug (~96 dB Dynamik = vom Flüstern bis zum Konzertsaal-Forte).
+- 24 Bit im Studio: Headroom für Bearbeitung, kein hörbarer Unterschied beim Endprodukt (Meyer & Moran, JAES 2007).
+
+Eselsbrücke: Sampling = horizontal (Zeit-Achse). Quantisierung = vertikal (Amplituden-Achse).
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/quantized-image-8-colors.jpg)
+
+<!--
+Quantisierung am Bild-Beispiel: dasselbe Foto mit unterschiedlicher Farbtiefe.
+
+- Original: 24-Bit-Farbe (16,8 Mio. Farben)
+- 8-Bit-Quantisierung: nur 256 mögliche Farben → sichtbare Stufen, Posterisierung
+
+Das ist dasselbe Phänomen wie Audio-Quantisierungsrauschen, nur in der visuellen Modalität. Wir reden über beides später nochmal (Aliasing-Folie).
+-->
+
+---
+
+# Datenrate = Sample Rate × Bittiefe × Kanäle
+
+**Formel:**
+
+```
+Datenrate (bit/s) = Sample Rate (Hz) × Bittiefe (bit) × Kanäle
+```
+
+**Was bestimmt jeder Faktor?**
+
+- **Sample Rate:** Bandbreite (Höhe der erfassbaren Töne)
+- **Bittiefe:** Dynamik (Stufenfeinheit)
+- **Kanäle:** Stereo, Mono, Surround
+
+Daraus ergibt sich, wie groß eine Audiodatei pro Sekunde wird — *unkomprimiert*.
+
+<!--
+Wichtige Klausur-Formel.
+
+Anwendungsbeispiel kommt nächste Folie (CD-Audio).
+
+Konsequenz: wenn ich Speicher sparen will, kann ich an einem dieser drei Parametern drehen. ABER: jede Reduktion ist hörbar.
+
+Brücke zu Kap2 (Kompression): da reduzieren wir nicht die Parameter, sondern *werfen unhörbare Information weg* — das ist Psychoakustik, nicht Container-Schrumpfung.
+-->
+
+---
+
+# CD-Audio: die Rechnung
+
+**Audio-CD (Philips/Sony 1982):**
+
+```
+44.100 Hz × 16 bit × 2 Kanäle = 1.411.200 bit/s = 1,4 Mbit/s
+```
+
+Pro Sekunde: ~172 KB. Pro Minute: ~10,3 MB. Pro Album (60 Min): ~635 MB.
+
+*Eine ganze 90er-Festplatte für ein Album.*
+
+<!--
+Diese Rechnung muss in der Klausur reproduziert werden können — Formel + Anwendung.
+
+Historischer Kontext:
+- 1982: erste CD (Billy Joel – 52nd Street, Japan)
+- Festplatten der 90er: 40–500 MB → ein Album füllte die ganze Platte
+- 56k-Modem: 7 KB/s → 42 MB Song ≈ 100 Minuten Download
+- Daraus entstand der Druck zur Audio-Kompression — die wir in Kap 2 sehen werden
+
+Spektrogramm-Folie als Anschluss: 44,1 kHz → wir können bis ~22 kHz erfassen. Mehr nicht. Warum genau 22 kHz? Weil Menschen bis ~20 kHz hören. Antwort kommt mit Nyquist.
+-->
+
+---
+
+# Nyquist — warum 2× reicht
+
+![bg right:50% contain](./assets/demos/nyquist-diagram.png)
+
+**Sample-Rate ≥ *2× höchste Signal-Frequenz.***
+
+```
+f_sample ≥ 2 · f_max
+```
+
+Drei Fälle:
+
+* **zu wenig** → Aliasing
+* **genau** → mathematisches Minimum
+* **mehr** → sichere Rekonstruktion
+
+<!--
+Harry Nyquist (1928) + Claude Shannon (1949): Sampling-Theorem.
+
+Beweis nicht klausurrelevant. Die Aussage und das visuelle Verständnis sind klausurrelevant.
+
+Konsequenz:
+- 44,1 kHz Sample Rate → max. 22,05 kHz erfassbare Frequenz
+- Über 22 kHz wird *physisch nicht aufgenommen* (vor dem ADC sitzt ein Tiefpassfilter, der alles über 22 kHz abschneidet — anti-aliasing filter)
+- Studis hören diese hohen Frequenzen sowieso nicht (~20 kHz oben)
+
+Anschluss zur nächsten Folie: warum hat die CD genau 44,1 kHz gewählt?
+-->
+
+---
+
+# Warum gerade 44,1 kHz?
+
+**Menschliches Ohr hört bis ca. 20 kHz.**
+2 × 20 kHz = 40 kHz minimum für Nyquist.
+
+**Plus 4,1 kHz Sicherheitsmarge** (Tiefpassfilter sind nicht perfekt).
+
+**Plus historische PAL/NTSC-Kompatibilität:**
+44.100 Hz war exakt durch PAL- und NTSC-Video-Frame-Raten teilbar → CD-Master ließen sich auf den Video-Recordern jener Zeit produzieren.
+
+<!--
+- Das Hörvermögen sinkt ab ~16 kHz mit dem Alter (Presbyakusis)
+- Tiefpassfilter im ADC braucht etwas Übergangsbreich — daher Sicherheitsmarge
+- 44.100 Hz ergibt sich aus: 245 × 6 × 30 (NTSC) und 245 × 8 × 25 (PAL).
+- Sony nutzte zu Beginn der CD-Entwicklung Video-Bandgeräte (Sony PCM-1600) zur digitalen Audio-Speicherung. Sample-Rate musste in NTSC + PAL-Frames passen.
+
+Pointe für Studis: ein scheinbar willkürlicher Standard hat physiologische *und* historische Gründe. Technik-Geschichte ist kein Zufall.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/aliasing-paar.png)
+
+<!--
+Aliasing als Phänomen — in Audio und Bild parallel.
+
+- Audio: schriller 18-kHz-Ton, mit 22 kHz gesampelt → wird zu dumpfem 4-kHz-Brumm. Frequenz „klappt um".
+- Bild: feines Streifenmuster, in zu niedriger Auflösung gerendert → breite Moiré-Bänder erscheinen.
+
+Beides ist dasselbe mathematische Phänomen: Sampling zu grob → falsche niedrige Frequenz erscheint.
+
+Lebensweltanker:
+- Spotify Free 96 kbit/s → hohe Frequenzen werden weggeschnitten → kein Aliasing direkt, aber dieselbe Familie von Problemen.
+- Foto-Stroboskop / Wagenrad-Effekt im Video → klassisches Aliasing in der Zeit-Dimension.
+-->
+
+---
+
+<!-- _class: aufgabe -->
+
+# Selbstlernen — Spotify-Bitrate vergleichen
+
+Auf eurem Handy:
+1. Spotify öffnen, *Lieblings-Track laden*
+2. Audio-Qualität-Einstellung wechseln zwischen **niedrig (24 kbit/s)** und **sehr hoch (320 kbit/s)**
+3. Mit Kopfhörer auf **Höhen** achten (Becken, Zischlaute, „s"-Töne in Stimme)
+
+**Was fällt auf?** Welche Frequenzen verschwinden zuerst?
+
+<!--
+Pädagogisch: Studis sollen selbst hören, was Sample Rate / Bitrate praktisch bedeutet. Niedrige Bitrate = Tiefpassfilter hört früher auf zu übertragen → hohe Frequenzen weg → klingt „dumpf".
+
+Spotify-Stufen (Premium):
+- niedrig: 24 kbit/s
+- normal: 96 kbit/s
+- hoch: 160 kbit/s
+- sehr hoch: 320 kbit/s
+
+Ohne Premium: max. „normal".
+
+Diskussion in der nächsten Vorlesungsrunde: was hat das mit MP3 zu tun? Antwort: alles. Kommt in Kap 2.
+-->
+
+---
+
+<!-- _class: aufgabe -->
+
+# Selbstlernen — Audacity Sample-Rate-Vergleich
+
+1. **Audacity** installieren (kostenlos, audacityteam.org)
+2. Eigene Stimme aufnehmen (5 s, irgendwas reinsprechen)
+3. Datei → Exportieren als WAV bei **8 kHz**, **22 kHz**, **44,1 kHz**
+4. Vergleichen: Größe der Datei + Klangqualität
+
+**Beobachtung:** Größe wächst linear mit Sample Rate. Qualität auch.
+
+<!--
+Diese Übung kann zuhause gemacht werden. Audacity ist FOSS.
+
+- 5 Sek Mono bei 44,1 kHz × 16 bit = ~441.000 Byte ≈ 430 KB
+- Bei 8 kHz: 80.000 Byte ≈ 78 KB
+- Klang: bei 8 kHz dumpf, „Telefon-Stimme"
+
+Anschlussfrage in der nächsten Folie: kann man eine Datei *kleiner* machen, ohne Sample Rate / Bittiefe zu reduzieren? Antwort: ja — durch Kompression. Das ist Kap 2.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/summary-organizer.png)
+
+<!--
+Zusammenfassung des Kapitels mit dem Bogen als rotem Faden.
+
+Beide Strangs sind jetzt durch:
+- WELT → BYTE (links, pink): Sampling-Rate, Bittiefe + Quantisierung, Datenrate-Formel, Nyquist 2f, Aliasing & Moiré, 44,1 kHz als Anwendung.
+- BYTE → BEDEUTUNG (rechts, cyan): Bit · Byte · Hex, 256 Zustände, ASCII + UTF-8, Magic Number, KB vs KiB, Hex im Alltag.
+
+Mitte: die Datei selbst — ein Strom von Byte, nichts als Zahlen.
+
+Pointe: Eine Datei ist kein Mysterium. Es ist eine Reihe von Zahlen mit zwei Geschichten dran. Eine erzählt, woher die Zahlen kommen. Die andere, was sie bedeuten. Beide kennt ihr jetzt.
+
+Anschluss zu Kap 2: in dieser Stunde haben wir die *unkomprimierten* Mengen gesehen (10 MB/min für CD-Audio). Im nächsten Kapitel: wie kommt man auf 1 MB/min und es klingt trotzdem fast gleich gut? Antwort: Kompression — und das ist ein eigenes Mysterium.
+-->

slides/223015b-2026/02-kompression.md

@@ -0,0 +1,548 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
+title: Kompression
+---
+
+<style>
+:root {
+  --color-foreground: #1a1a2e;
+  --color-highlight: #1e5f8a;
+  --color-dimmed: #4a4a6a;
+}
+section.invert { --color-foreground: #fff; }
+section { font-size: 1.7rem; }
+h1 { color: #1e5f8a; }
+section.invert h1 { color: #fff; }
+h2 { color: #1f2937; }
+pre {
+  background: #0f0f23;
+  color: #5fb3e4;
+  border-radius: 8px;
+  border-left: 3px solid #1e5f8a;
+}
+pre code { background: transparent; color: inherit; }
+code {
+  background: #0f0f23;
+  padding: 0.15em 0.4em;
+  border-radius: 4px;
+  font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
+}
+section code:not(.hljs) { color: #5fb3e4 !important; }
+section code.hljs { color: #f8f8f8 !important; }
+a { color: var(--color-highlight); }
+section.klausur {
+  background: repeating-linear-gradient(
+    135deg,
+    #e3f2fd,
+    #e3f2fd 40px,
+    #fff 40px,
+    #fff 80px
+  ) !important;
+}
+@media print {
+  section.klausur { background: #e3f2fd !important; }
+}
+section.aufgabe { background: #e3f2fd !important; }
+section.aufgabe footer { display: none; }
+section.erklaerung :not(header),
+section.erklaerung :not(footer) { font-size: 1.1rem; }
+section.erklaerung h1 { font-size: 1.5rem; color: #1e5f8a; margin-bottom: 0.3rem; }
+section.erklaerung ul, section.erklaerung ol { font-size: 1.0rem; line-height: 1.4; }
+section.erklaerung p { font-size: 1.0rem; line-height: 1.4; }
+section.erklaerung table { font-size: 0.9rem; }
+</style>
+
+<!-- _class: lead -->
+
+# Kapitel 2
+## Kompression — Prinzipien und Pipelines
+
+<!--
+Eine Stunde, eine Frage: *Wie machen wir Daten kleiner — und was darf dabei verloren gehen?*
+
+Vorbereitung für Kapitel 3 (Inhalte: Bild/Audio/Video), wo wir die konkreten Pipelines durchgehen. Hier nur die zwei großen Prinzipien.
+
+Anschluss an Kap 1: dort haben wir gesehen, wie groß unkomprimierte Audio-Daten werden (10 MB/Min für CD-Audio). Jetzt: wie kommt man auf 1 MB/Min und es klingt fast gleich?
+
+Bogen: lossless (Redundanz raus) ↔ lossy (Irrelevanz raus).
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Daten sind unhandlich
+
+<!--
+WhatsApp-Foto vom Wochenende: 200 KB.
+Dasselbe Bild aus der Kamera: 12 MB.
+
+Spotify-Track: ~3 MB für 3 Minuten.
+Derselbe Track als Studio-WAV: ~30 MB.
+
+ZIP einer Code-Sammlung: 1/3 der Originalgröße.
+
+In allen drei Fällen ist die Datei *kleiner*. Aber bei manchen ist Information *weg* — und bei anderen nicht. Was ist der Unterschied?
+-->
+
+---
+
+# Foto-Größenschock
+
+| Variante | Größe | Sichtbarer Unterschied? |
+|----------|------:|------------------------|
+| Original aus der iPhone-Kamera (HEIC) | 3,2 MB | — |
+| Foto via WhatsApp geteilt | 230 KB | kaum |
+| Instagram-Story (komprimiert) | 80 KB | minimal |
+| WhatsApp-Profilbild (klein) | 12 KB | sichtbar |
+
+**Faktor: bis zu 270×.** *Wo geht die Information hin?*
+
+<!--
+Diese Folie hängt das Konzept der Kompression an einem alltäglichen Beispiel auf.
+
+- iPhone-Kamera: bereits H.265-komprimiert (HEIC) — aber als „Original" gehandelt.
+- WhatsApp: komprimiert nochmal, plus Resolution-Reduktion. Faktor ~13x.
+- Instagram-Story: noch aggressiver, optimiert für schnelles Laden.
+- Profilbild: max. ~96×96 Pixel, hoher JPEG-Komp-Faktor.
+
+Pointe: alle vier sind „dasselbe Bild" — aber jede Stufe wirft *etwas* weg. Was genau? Und wer entscheidet, was weggeworfen wird? Antwort kommt mit dem Konzept lossy vs lossless.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/kap02-eroeffner.png)
+
+<!--
+Das gleiche Phänomen in der Audio-Welt:
+- FLAC (lossless): 5,3 MB, jede Frequenz erhalten
+- MP3 (lossy, 128 kbit/s): 480 KB, hohe Frequenzen weggeworfen, Transienten geglättet
+
+Wellenform-Vergleich macht es konkret:
+- Links (grün): detaillierte FLAC-Wellenform mit allen Spikes
+- Rechts (rot): MP3-Wellenform glatter, Detail-Information fehlt
+
+Pointe für die Studis: auf dem Smartphone-Lautsprecher hört man den Unterschied meist nicht. Im Studio-Monitor mit Kopfhörer schon. MP3 wirft 91 % der Daten weg, die der Mensch im Alltag nicht vermisst.
+
+→ Das ist „Lossy". Das Gegenteil ist „Lossless" (FLAC, ZIP).
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Erster Weg: Verlustfrei (Lossless)
+
+<!--
+Prinzip: Redundanz raus, Information unverändert.
+
+Beispiele:
+- ZIP-Archiv: gleiche Datei nach Entpacken
+- PNG-Bild: identisch zum Original
+- FLAC-Audio: identisch zur ursprünglichen Wellenform
+- TIFF, RAW (Camera-RAW): Foto im Rohformat
+
+Trick: Wiederholungen, Muster, häufige Sequenzen werden kürzer geschrieben.
+-->
+
+---
+
+# Prinzip: Redundanz raus
+
+Der Datenstrom enthält oft **Wiederholungen** — gleiche Pixel, gleiche Buchstaben, gleiche Frequenz-Häppchen.
+
+Lossless-Kompression **erkennt** diese Redundanz und schreibt sie als **Verweis** kürzer.
+
+**Umkehrbar:** beim Dekomprimieren wird die exakte Original-Datei wiederhergestellt.
+
+<!--
+- Lossless ist ein Match-und-Verweise-Spiel.
+- Gegeben: 'AAAAAAAA' → kürzer als '8×A'.
+- Gegeben: ein Bild mit großem weißen Bereich → kürzer als 'Pixel 1-10000 sind weiß'.
+- Gegeben: ein Text mit häufigen Wörtern → 'der die das' bekommt kurze Codes (Huffman).
+
+Wichtig zu verstehen: keine Information geht verloren. Aus der komprimierten Datei lässt sich das Original *bit-genau* wieder herstellen.
+-->
+
+---
+
+# RLE — Run-Length-Encoding
+
+**Eine Bilderzeile in Schwarz/Weiß:**
+
+```
+Original:    AAAAA BBB CCCCCCCC AAAAAA
+             (5×A, 3×B, 8×C, 6×A)
+
+Kodiert:     5A 3B 8C 6A
+```
+
+**22 Zeichen → 8 Zeichen.** Faktor: 2,75×.
+
+Verlustfrei, weil ich aus `5A 3B 8C 6A` exakt `AAAAABBBCCCCCCCCAAAAAA` zurückbekomme.
+
+<!--
+RLE = einfachster Lossless-Algorithmus, gut zum Verstehen des Prinzips am Whiteboard.
+
+- Wirkt bei: Schwarz/Weiß-Bildern, Schwarz-auf-Weiß-Text, Faxnachrichten.
+- Wirkt NICHT bei: zufälligen Daten, schon-komprimierten Dateien (kein Muster zum Komprimieren).
+- TIFF und BMP nutzen optional RLE. Faxgeräte nutzen es exzessiv.
+
+In der Praxis: moderne Lossless-Algorithmen wie Deflate (ZIP/PNG/gzip) und LZ77 sind viel cleverer als RLE — sie finden auch Wiederholungen auf weite Distanz im Datenstrom. Aber RLE zeigt das Prinzip in seiner einfachsten Form.
+-->
+
+---
+
+# Wo wird Lossless verwendet?
+
+| Anwendung | Format | Warum verlustfrei? |
+|-----------|--------|---------------------|
+| Code-Repository, Backup | **ZIP**, **gzip**, **tar.gz** | Jedes Bit muss exakt zurück. |
+| Foto-Archiv (RAW) | **PNG**, **TIFF**, **RAW** | Nachbearbeitung soll alle Detail haben. |
+| Studio-Master-Track | **FLAC**, **WAV** | Für Mastering muss Originalqualität da sein. |
+| Logo-Grafiken | **PNG**, **SVG** | Scharfe Kanten brauchen Pixelgenauigkeit. |
+
+**Faustregel:** Werkzeug → Lossless.
+
+<!--
+Anschluss: wenn das Werkzeug ist, mit dem ich weiterarbeite (Foto bearbeiten, Code lesen, Audio mastern), brauche ich die Original-Daten. Lossless garantiert das.
+
+PNG vs. JPEG-Konflikt: viele Studis erleben das beim Web-Hochladen. Logo als JPEG → unscharfe Ränder, weil JPEG für Fotos optimiert ist (große Farbflächen kosten wenig, Kanten erzeugen Artefakte). Logo als PNG → scharfe Ränder, weil PNG verlustfrei ist.
+-->
+
+---
+
+![bg right:40% contain](./assets/lv-original-vs-fake.jpg)
+
+# Original vs. Fälschung
+
+Eine **echte Louis-Vuitton-Tasche** und ein perfekter Fake — auf einem Foto unterscheidbar?
+
+Eine **lossless-komprimierte Datei** vs. das Original — bit-genau identisch.
+
+**Bei Lossless gibt es keine Fälschung.** Die Kopie ist mathematisch das Original.
+
+<!--
+Diese Analogie hat letztes Mal Verwirrung gestiftet (Original-Bag vs Fake). Der Punkt ist:
+
+Bei echten Gegenständen (Tasche, Gemälde, Vinyl-Schallplatte) gibt es ein „echtes Original". Eine Fälschung sieht nur ähnlich aus, ist aber nicht das Original.
+
+Bei digitalen Daten ist eine lossless-Kopie *exakt* gleich. Es gibt keinen Begriff von „Original" und „Kopie" — beide sind nur Folgen von Byte, und wenn diese Folgen Byte-für-Byte gleich sind, sind sie ununterscheidbar.
+
+Das ist die digitale Kopier-Revolution. Vinyl → Kassette → Kassette = Generationsverlust. CD → Festplatte → USB-Stick = identisch.
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Zweiter Weg: Verlustbehaftet (Lossy)
+
+<!--
+Prinzip: Irrelevanz raus. Nicht „weniger Wiederholung", sondern „Information, die der Mensch sowieso nicht wahrnimmt, wird gar nicht erst gespeichert".
+
+Beispiele:
+- MP3, AAC, OPUS (Audio)
+- JPEG, WebP (Bild)
+- H.264, H.265, AV1 (Video)
+
+Trick: Wahrnehmungsforschung — Psychoakustik (was hört der Mensch nicht?) und Psychovisualität (was sieht der Mensch nicht?).
+-->
+
+---
+
+# Prinzip: Irrelevanz raus
+
+Was der Mensch **nicht wahrnehmen** kann, muss man **nicht speichern**.
+
+**Lossy-Kompression** wirft genau diese Information weg.
+
+**Nicht umkehrbar.** Was weg ist, kommt nie zurück. Aus einem MP3 wird nie wieder ein FLAC.
+
+<!--
+Lossy hat einen anderen Charakter als Lossless:
+- Lossless: schaut auf die Daten („wo wiederholt sich was?")
+- Lossy: schaut auf den Empfänger („was nimmt er nicht wahr?")
+
+Daraus folgt: Lossy braucht ein Modell vom Empfänger. Genau das liefert die Psychoakustik (Audio) und Psychovisualität (Bild).
+
+Konsequenz: aus einem 128-kbit/s-MP3 lässt sich keine CD-Qualität wieder herstellen. Die Daten sind weg. Wenn jemand „Studio-Master 320 kbit/s" sagt: das war nie Studio-Master, das ist MP3 mit höherer Bitrate — die hohen Frequenzen sind trotzdem weg.
+-->
+
+---
+
+# Was nimmt der Mensch nicht wahr?
+
+**Ohr (Audio):**
+- Töne unter ~20 Hz oder über ~20 kHz
+- Leise Töne in der Nähe lauter Töne (Maskierung)
+- Räumlich-zeitliche Maskierung (z.B. ~200 ms nach lautem Knall)
+
+**Auge (Bild):**
+- Feine Farb-Detail (Chrominanz) abseits scharfer Helligkeitskanten
+- Kleinste Helligkeits-Differenzen (~1 Stufe in 256 ist unsichtbar)
+- Sehr feine Strukturen jenseits der Sehauflösung
+
+Lossy-Algorithmen modellieren diese Wahrnehmungs-Grenzen — und werfen alles davor weg.
+
+<!--
+Diese Folie zählt die Beschränkungen unserer Wahrnehmung auf — daraus ergibt sich, was Lossy weglassen darf.
+
+Ohr-Phänomene werden in der Psychoakustik formalisiert. Die zwei wichtigsten:
+1. Frequenzmaskierung: lauter 1-kHz-Ton überdeckt benachbarte leise Töne bei 1,1 kHz.
+2. Zeitliche Maskierung: nach einem lauten Knall hört man ~200 ms keine leisen Geräusche.
+
+Auge-Phänomene werden in der Psychovisualität formalisiert:
+1. Luminanz vor Chrominanz: Helligkeitsdetail ist scharf wichtig, Farbdetail darf grob sein.
+2. Kontrast-Empfindlichkeit: bei mittlerer Helligkeit sehen wir feiner als ganz hell oder ganz dunkel.
+
+Die nächsten beiden Folien visualisieren diese Konzepte.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/psychoakustik-grafik.png)
+
+<!--
+Visualisierung der Maskierung:
+- Hörschwelle (orange gestrichelt): die untere Grenze unseres Hörens, je nach Frequenz unterschiedlich. Am empfindlichsten bei 1–4 kHz, weniger bei sehr tiefen und sehr hohen Frequenzen.
+- Lauter Ton bei 1 kHz, 90 dB („Masker"): macht die umliegenden Frequenzen unhörbar.
+- Maskierungs-Bereich (blau): in diesem Bereich werden Töne, die unter der gestrichelten Kurve liegen, durch den Masker überdeckt.
+- Grüne Punkte: hörbar, müssen kodiert werden.
+- Graue Punkte: nicht hörbar trotz „Vorhandenseins" → werden weggeworfen.
+
+MP3-Pipeline:
+1. FFT — Audio in Frequenzen zerlegen
+2. Psychoakustisches Modell anwenden — berechne Maskierungsschwellen
+3. Quantisierung — alles unter Maskierungsschwelle wegwerfen
+4. Huffman-Coding — Rest verlustfrei komprimieren
+
+Pointe: das alles passiert ohne dass der Mensch im normalen Hören etwas vermisst. ~90 % der Daten weg.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/psychovisualitaet-grafik.png)
+
+<!--
+Visualisierung Luminanz vs Chrominanz:
+- Links: 4:4:4 — jedes Pixel speichert Helligkeit (Y) + zwei Farb-Komponenten (Cb blau-differenz, Cr rot-differenz) in voller Auflösung.
+- Rechts: 4:2:0 — Y bleibt voll, Cb und Cr werden auf 1/4 reduziert (2×2 Pixel teilen sich einen Farbwert).
+- Beide Bilder sehen für das Auge identisch aus. Datenmenge halbiert.
+
+JPEG, H.264, H.265, WebP, AVIF nutzen alle 4:2:0-Subsampling als Standard.
+
+Anekdote: Würde man stattdessen die Luminanz halbieren (Y reduziert, Cb/Cr voll), würde das Bild sofort unscharf aussehen. Das Auge ist scharf für Helligkeitskanten — daher kein Spielraum dort.
+-->
+
+---
+
+# Wo wird Lossy verwendet?
+
+| Anwendung | Format | Reduktion |
+|-----------|--------|-----------|
+| Musikstream (Spotify) | **MP3**, **AAC**, **OGG** | 10× |
+| Foto im Netz (Instagram) | **JPEG**, **WebP** | 10–30× |
+| Video (YouTube, Netflix) | **H.264**, **H.265**, **AV1** | 100–200× |
+| Sprachanruf (WhatsApp Call) | **OPUS**, **AMR** | 50× |
+
+**Faustregel:** Konsum → Lossy.
+
+<!--
+Wenn du etwas nur „konsumieren" (anschauen, anhören) willst — und nicht weiter bearbeiten — ist Lossy die richtige Wahl. Du sparst Speicher und Bandbreite, ohne dass der Konsum darunter leidet.
+
+Sobald du bearbeiten, mastern, archivieren willst → Lossless.
+-->
+
+---
+
+# Vergleich: Lossless vs. Lossy
+
+| Eigenschaft | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
+|-------------|------------------------|--------------------------|
+| Was passiert? | Redundanz raus | Irrelevanz raus |
+| Umkehrbar? | Ja, bit-genau | Nein, nie wieder |
+| Trick | Wiederholungen kürzer kodieren | Wahrnehmung modellieren |
+| Typischer Faktor | 2× – 5× | 10× – 100× |
+| Anwendung | Archiv, Werkzeug, Code | Stream, Anzeige, Konsum |
+| Beispiele | ZIP · PNG · FLAC · RAW | MP3 · JPEG · H.264 · WebP |
+
+<!--
+Klausurfähig: gegeben ein Anwendungsfall — soll Lossless oder Lossy verwendet werden? Mit Begründung.
+
+Beispiele für Klausurfragen:
+- 4K-Stream auf Netflix → Lossy (H.265 oder AV1)
+- RAW-Datei aus der DSLR archivieren → Lossless (RAW selbst, ggf. ZIP)
+- Lecture-Capture-Aufzeichnung für Wiederverwendung → Lossless besser, aber Datenrate hoch
+- Logo-Datei für Print + Web → SVG (vektorgraphisch) oder PNG (lossless raster)
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/Felis_silvestris_silvestris_small_gradual_decrease_of_quality_-_JPEG_compression.jpg)
+
+<!--
+Klassisches Bild aus Wikipedia: dieselbe Katze mit fortschreitender JPEG-Kompression.
+
+- Ganz links: kaum komprimiert, hohe Qualität
+- Schritt für Schritt: mehr Artefakte, weniger Detail, Quantisierungs-Blöcke werden sichtbar
+- Ganz rechts: extreme Kompression, sichtbare 8×8-Pixel-Blöcke (DCT-Blöcke)
+
+Die JPEG-Pipeline funktioniert in 8×8-Blöcken. Bei niedriger Qualität werden hohe Frequenzen innerhalb dieser Blöcke aggressiv quantisiert → die Blöcke werden sichtbar.
+
+Studis erkennen das aus dem Alltag:
+- Mehrfach geforwardete WhatsApp-Bilder → JPEG-Generation-Loss
+- Screenshots in Office → manchmal als JPEG gespeichert → Schrift wird unscharf
+-->
+
+---
+
+# Kompressionsraten in der Praxis
+
+| Inhalt | Roh | Komprimiert | Faktor |
+|--------|----:|------------:|-------:|
+| Foto (12 MP) | 36 MB RAW | 3,5 MB JPEG | ~10× |
+| Audio (30 s Stereo) | 5,3 MB WAV | 480 KB MP3 | ~11× |
+| Video (1 Min 4K) | 24 GB roh | 200 MB H.264 | ~120× |
+| Code-Repo (Java) | 15 MB Quellcode | 1,5 MB ZIP | ~10× |
+| Foto (Logo PNG) | 800 KB unkomp. | 80 KB PNG | ~10× |
+
+Lossy bringt mehr — *aber Werkzeug muss roh bleiben.*
+
+<!--
+Diese Folie liefert Größenordnungen für die häufigsten Kompressions-Szenarien. Studis sollen ein Bauchgefühl bekommen:
+
+- Foto: roh ist 10× größer als JPEG
+- Audio: roh ist 10× größer als MP3
+- Video: roh ist 100× größer als H.264. Das ist der Grund, warum Streaming überhaupt funktioniert.
+- Code: ZIP komprimiert um 10× weil viele Wiederholungen (Imports, Whitespace, Standard-Bibliothek-Aufrufe).
+
+In Kap 3 schauen wir uns die Pipelines an: WIE machen JPEG/MP3/H.264 das?
+-->
+
+---
+
+# Entscheidungsmatrix — wann nehme ich was?
+
+| Szenario | Empfehlung | Begründung |
+|----------|------------|------------|
+| Foto-Archiv (DSLR) | **RAW** (lossless) | Nachbearbeitung muss alle Detail haben |
+| Foto im Web/Insta | **JPEG / WebP** (lossy) | Konsum, Bandbreite zählt |
+| Studio-Master | **FLAC / WAV** (lossless) | Master soll bit-genau bleiben |
+| Spotify-Track | **AAC / MP3** (lossy) | Konsum, Smartphone-Lautsprecher |
+| Code-Backup | **ZIP / tar.gz** (lossless) | Code muss exakt zurück |
+| Lecture-Video | **H.264** (lossy) | Konsum, Streaming |
+| Logo | **PNG / SVG** (lossless) | Scharfe Kanten brauchen Pixelgenauigkeit |
+
+<!--
+Diese Matrix ist die zentrale Entscheidungshilfe. Vermitteln über Beispiele aus dem Studi-Alltag (Insta-Post, Spotify-Premium, GitHub-Repo, Vorlesungs-Aufnahme).
+
+Pädagogisches Ziel: am Ende des Kapitels haben Studis ein Bauchgefühl, wann welche Kompression sinnvoll ist. Nicht „auswendig", sondern „begründen können".
+-->
+
+---
+
+<!-- _class: aufgabe -->
+
+# Selbstlernen — ZIP-Test mit drei Dateitypen
+
+Drei Dateien gleicher Originalgröße (~1 MB) zippen:
+
+1. **Textdatei mit wiederholten Mustern** (z.B. ein Buch als TXT)
+2. **Unkomprimiertes Bitmap (BMP)** desselben Fotos
+3. **JPEG** desselben Fotos
+
+**Vergleich:** Wie groß ist die ZIP-Datei in jedem Fall?
+
+**Erwartung:** Textdatei wird klein (Wiederholungen), BMP wird klein (Farbflächen), JPEG bleibt fast gleich (schon komprimiert, keine Redundanz mehr).
+
+<!--
+Diese Übung liefert die zentrale Aha-Erkenntnis ohne Mathematik:
+
+**Schon-komprimierte Dateien lassen sich nicht weiter komprimieren.**
+
+Warum? Weil Kompression die Redundanz herausnimmt. Eine bereits komprimierte Datei *hat keine Redundanz mehr*. Das wäre ein Verstoß gegen die Entropie-Grenze (Shannon), aber das brauchen die Studis nicht zu rechnen.
+
+Erkenntnis: wer schon JPEG/MP3/H.264-Dateien hat, kann sie nicht „nochmal komprimieren". Wer Backup-ZIP über JPEG-Fotos macht: spart fast nichts.
+
+~10 Min Selbstlernen. Ideal für ein Pärchen oder als Hausaufgabe.
+-->
+
+---
+
+# Warum ZIP auf JPEG nicht mehr komprimiert
+
+**JPEG ist bereits maximal lossless-komprimiert.**
+
+Die JPEG-Pipeline endet mit **Huffman-Coding** — derselbe Trick wie in ZIP.
+
+Was ZIP machen würde (Wiederholungen finden, Häufigkeiten kürzer kodieren), hat JPEG schon getan.
+
+**Resultat:** ZIP einer JPEG-Datei ist nur ~1 % kleiner. *Manchmal sogar größer* (durch ZIP-Header-Overhead).
+
+<!--
+Pädagogisches Ziel: Studis verstehen, warum „Doppel-Kompression" nichts bringt.
+
+Konkret:
+- JPEG-Pipeline = lossy + Huffman (lossless)
+- MP3-Pipeline = lossy + Huffman (lossless)
+- H.264-Pipeline = lossy + CABAC/Huffman (lossless)
+
+In allen Fällen endet die Pipeline mit einem optimal-lossless-Schritt. Ein zusätzliches ZIP findet keine Wiederholungen mehr.
+
+Folgerung: für gemischte Backups ist ZIP trotzdem nützlich — schon-komprimierte Dateien bleiben gleich, unkomprimierte werden kleiner. „Du verlierst nichts."
+
+Übergang zu Kap 3: jetzt schauen wir uns die konkreten Lossy-Pipelines an. Wie genau funktioniert JPEG? Was passiert in MP3? Wie komprimiert H.264 Video?
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/summary-kap02.png)
+
+<!--
+Zusammenfassung:
+
+Zwei Wege, ein Ziel: Daten kleiner machen.
+
+Verlustfrei (Lossless):
+- Was: Redundanz raus
+- Umkehrbar: ja
+- Verfahren: RLE, Huffman, Deflate
+- Formate: ZIP, PNG, FLAC, RAW
+- Faktor: 2× – 5×
+
+Verlustbehaftet (Lossy):
+- Was: Irrelevanz raus
+- Umkehrbar: nein
+- Trick: Psychoakustik (Audio) / Psychovisualität (Bild)
+- Formate: MP3, JPEG, H.264, WebP
+- Faktor: 10× – 100×
+
+Entscheidungsmatrix:
+- Archiv/Code → Lossless
+- Stream/Anzeige → Lossy
+
+Faustregel: Werkzeug = Lossless. Konsum = Lossy.
+
+In Kap 3 schauen wir uns die Pipelines konkret an (JPEG, MP3, H.264) — also wie ein Lossy-Algorithmus überhaupt entscheidet, was wegzuwerfen ist.
+-->

slides/223015b-2026/03-inhalte-bild-audio-video.md

@@ -0,0 +1,987 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
+title: Inhalte — Bild, Audio, Video
+---
+
+<style>
+:root {
+  --color-foreground: #1a1a2e;
+  --color-highlight: #1e5f8a;
+  --color-dimmed: #4a4a6a;
+}
+section.invert { --color-foreground: #fff; }
+section { font-size: 1.7rem; }
+h1 { color: #1e5f8a; }
+section.invert h1 { color: #fff; }
+h2 { color: #1f2937; }
+pre {
+  background: #0f0f23;
+  color: #5fb3e4;
+  border-radius: 8px;
+  border-left: 3px solid #1e5f8a;
+}
+pre code { background: transparent; color: inherit; }
+code {
+  background: #0f0f23;
+  padding: 0.15em 0.4em;
+  border-radius: 4px;
+  font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
+}
+section code:not(.hljs) { color: #5fb3e4 !important; }
+section code.hljs { color: #f8f8f8 !important; }
+a { color: var(--color-highlight); }
+section.klausur {
+  background: repeating-linear-gradient(
+    135deg,
+    #e3f2fd,
+    #e3f2fd 40px,
+    #fff 40px,
+    #fff 80px
+  ) !important;
+}
+@media print {
+  section.klausur { background: #e3f2fd !important; }
+}
+section.aufgabe { background: #e3f2fd !important; }
+section.aufgabe footer { display: none; }
+section.erklaerung :not(header),
+section.erklaerung :not(footer) { font-size: 1.1rem; }
+section.erklaerung h1 { font-size: 1.5rem; color: #1e5f8a; margin-bottom: 0.3rem; }
+section.erklaerung ul, section.erklaerung ol { font-size: 1.0rem; line-height: 1.4; }
+section.erklaerung p { font-size: 1.0rem; line-height: 1.4; }
+section.erklaerung table { font-size: 0.9rem; }
+</style>
+
+<!-- _class: lead -->
+
+# Kapitel 3
+## Inhalte — Bild, Audio, Video
+
+<!--
+Längere Sitzung (ggf. 2 Termine): drei Modalitäten, drei Pipelines, drei Format-Politiken.
+
+Anschluss an Kap 2: dort haben wir Lossy-Prinzip kennengelernt (Psychoakustik, Psychovisualität). Hier zeigen wir die konkreten Pipelines — wie genau macht JPEG/MP3/H.264 das?
+
+Bogen:
+1. Bilder (Raster vs Vektor, JPEG-Pipeline, weitere Formate)
+2. Audio (MP3-Pipeline-Recap, Format-Wahl)
+3. Video (Container ≠ Codec, I/P/B-Frames, H.264 vs H.265 vs AV1)
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Drei Modalitäten, ein Prinzip
+
+<!--
+Anker im Alltag: Instagram, Spotify, YouTube. Was tun diese Plattformen?
+- Instagram: zeigt Fotos (Bild)
+- Spotify: spielt Musik (Audio)
+- YouTube: streamt Video (Bild + Audio + Zeit)
+
+Alle drei nutzen lossy Kompression. Alle drei nutzen Wahrnehmungs-Lücken. Aber die Pipelines sind verschieden.
+
+Vorgriff: am Ende dieses Kapitels werdet ihr wissen, was in einer JPEG-Datei, in einer MP3-Datei und in einer MP4-Datei wirklich drinsteckt.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/kap03-eroeffner.png)
+
+<!--
+Tabellarische Übersicht zum Reduktions-Hebel pro Modalität:
+- Bild (12-MP-Foto): RAW 36 MB → JPEG Q90 4 MB → JPEG Q50 800 KB (Faktor ×45)
+- Audio (30 s Stereo): WAV 5,3 MB → MP3 192 kbit/s 720 KB → MP3 64 kbit/s 240 KB (Faktor ×22)
+- Video (30 s 4K 30fps): Roh 12 GB → H.264 25 Mbit/s 94 MB → H.265 12 Mbit/s 45 MB (Faktor ×270)
+
+Jede Reduktion nutzt eine andere Wahrnehmungs-Lücke:
+- Bild → geringere Farbschärfe (Chrominanz vs Luminanz)
+- Audio → Maskierung (lauter Ton überdeckt leise)
+- Video → Frame-zu-Frame-Ähnlichkeit (Inter-Frame)
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Sub-Sektion A: Bilder
+
+<!--
+Reihenfolge:
+1. Raster vs Vektor (Konzept)
+2. JPEG-Pipeline (6 Schritte)
+3. Andere Formate (PNG, GIF, WebP, AVIF, SVG)
+4. Format-Wahl-Matrix
+5. Patent-Politik (warum WebP > JPEG XL)
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/raster-vs-vektor.png)
+
+<!--
+Zwei fundamentale Bild-Modelle:
+
+**Raster:** Bild = Gitter aus Pixel-Farbwerten. Jede Position fest belegt.
+- Beispiele: PNG, JPEG, GIF, WebP, RAW
+- Vorteil: kann Fotos darstellen (kontinuierliche Tonwerte)
+- Nachteil: feste Auflösung. Beim Vergrößern wird es pixelig.
+
+**Vektor:** Bild = mathematische Anweisungen ("Punkt 30,110 → Punkt 90,170 → Punkt 250,30, Strichbreite 14").
+- Beispiele: SVG, PDF, Schriftarten, Adobe Illustrator
+- Vorteil: scharf bei jeder Größe (wird neu berechnet)
+- Nachteil: kann keine Fotos (keine analytischen Beschreibungen für Megapixel von Pixeln)
+
+Anwendung: Logo → Vektor. Foto → Raster. Icon → Vektor.
+-->
+
+---
+
+# Raster vs. Vektor
+
+| | Raster | Vektor |
+|--|--------|--------|
+| Was | Gitter aus Pixel-Werten | Mathematische Anweisungen |
+| Speicher | wächst mit Auflösung | wächst mit Komplexität |
+| Skalierung | pixelig beim Zoom | scharf bei jeder Größe |
+| Geeignet für | Fotos, Screenshots | Logos, Icons, Schrift |
+| Formate | PNG · JPEG · GIF · WebP | SVG · PDF · Schriftarten |
+
+<!--
+Klausurfähig. Geben Sie:
+- ein Format zu jeder Spalte
+- ein Anwendungsbeispiel zu jeder Spalte
+- begründen warum Vektor bei Logos und Raster bei Fotos
+
+Trick-Frage: kann man ein Foto in SVG speichern? Theoretisch ja (mit Millionen winziger Rechtecke), praktisch nein — wird dann viel größer als JPEG.
+-->
+
+---
+
+<!-- _class: lead -->
+
+# JPEG — das Foto-Workhorse seit 1992
+
+<!--
+JPEG = Joint Photographic Experts Group, Standard seit 1992.
+
+Bis heute das dominierende Foto-Format im Web (~70 % aller Web-Bilder). Warum?
+- Sehr gute Kompression bei akzeptabler Qualität
+- Patentfrei seit 2017 (vorher schon weitgehend lizenzfrei)
+- Universelle Unterstützung in Browsern, OS, Druck
+
+Aber: lossy. Jede Speicherung erzeugt Verlust. Wer ein JPEG immer wieder bearbeitet und speichert, baut Artefakte auf (Generation Loss).
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/jpeg-pipeline.png)
+
+<!--
+JPEG-Pipeline in 6 Schritten:
+
+1. Farbraumkonversion: RGB → Y'CbCr. Helligkeit (Y) von Farbe (Cb, Cr) trennen.
+2. Chroma-Subsampling 4:2:0: Cb und Cr auf 1/4 reduziert (Auge sieht Farbdetail nicht so scharf). LOSSY.
+3. 8×8-Blöcke: Bild in kleine Kacheln teilen, jeder Block einzeln behandelt.
+4. DCT (Diskrete Kosinus-Transformation): jeden Block in Frequenz-Komponenten zerlegen. Häufige Helligkeitsmuster werden sichtbar.
+5. Quantisierung: hohe Frequenzen (Detail) werden gerundet. HIER passiert die hauptsächliche Lossy-Reduktion. Je niedriger die Qualitätsstufe, desto aggressiver.
+6. Huffman-Coding: lossless. Häufige Werte bekommen kurze Codes, seltene Werte lange Codes.
+
+Resultat: Foto-Datei ist 10× kleiner als RAW, sieht für das Auge fast identisch aus.
+-->
+
+---
+
+# Schritt 1: RGB → Y'CbCr
+
+![bg right:45% contain](./assets/Barn-yuv.png)
+
+**Trick:** Helligkeit von Farbe **trennen**.
+
+* **Y** = Luminanz (Helligkeit)
+* **Cb** = blau-gelb-Differenz
+* **Cr** = rot-grün-Differenz
+
+Auge sieht **Y scharf**, **Cb/Cr grob.** Beide werden unabhängig komprimiert.
+
+<!--
+Diese Trennung ist verlustfrei — mathematische Umrechnung zwischen Farbräumen.
+
+Y'CbCr ist auch der Farbraum, in dem Fernseh- und Video-Signale übertragen werden (BT.601, BT.709). Hat historische Gründe (kompatibel mit Schwarz-Weiß-TV: Y alleine = SW-Bild).
+
+Nach diesem Schritt: keine Reduktion, aber Vorbereitung für Schritt 2.
+-->
+
+---
+
+# Schritt 2: Chroma-Subsampling (4:2:0)
+
+![bg right:48% contain](./assets/Common_chroma_subsampling_ratios_YCbCr_CORRECTED.svg.png)
+
+**Y bleibt voll.** **Cb und Cr werden auf 1/4 reduziert** (2×2 Pixel teilen sich einen Farbwert).
+
+- 4:4:4 = keine Reduktion
+- 4:2:2 = horizontal halbiert
+- **4:2:0 = JPEG-Standard, beide Richtungen halbiert**
+
+**Lossy.** Speichermenge halbiert, sichtbarer Unterschied: null.
+
+<!--
+4:2:0-Notation kommt von alten Video-Standards. Erste Zahl = relative Y-Sample-Anzahl, zweite = Cb-Samples in Zeile 1, dritte = in Zeile 2.
+
+Konsequenz: Bilder mit sehr feinen Farbkanten (z.B. roter Text auf grünem Hintergrund) können in 4:2:0-JPEG sichtbare Farbsäume haben. Deshalb ist JPEG für solche Inhalte schlechter als PNG.
+
+Faustregel: 4:2:0 ist OK für Fotos. Für Text-Grafiken und Screenshots eher PNG nehmen.
+-->
+
+---
+
+# Schritt 3 & 4: 8×8 Blöcke + DCT
+
+Das Bild wird in **8×8-Pixel-Blöcke** zerlegt. *Jeder Block einzeln* weiterverarbeitet.
+
+**DCT** (Diskrete Kosinus-Transformation) zerlegt jeden Block in **Frequenz-Komponenten:**
+
+- niedrige Frequenz = grobe Helligkeitsänderungen (Hintergrund)
+- hohe Frequenz = feines Detail (Kanten, Rauschen)
+
+Beide Schritte sind **verlustfrei**. Sie bereiten Schritt 5 vor.
+
+<!--
+Warum 8×8? Trade-off:
+- Größere Blöcke (z.B. 16×16): bessere Kompression, aber kostspieliger zu berechnen
+- 8×8 wurde 1992 als guter Kompromiss gewählt; passt zu der damaligen Hardware
+
+DCT-Aha:
+- Ein Block, der nur eine Farbe ist → eine Frequenz-Komponente (Mittelwert)
+- Ein Block mit feinen Streifen → viele hohe Frequenzen
+- Die meisten realen Bildblöcke konzentrieren ihre Energie in den niedrigen Frequenzen
+
+Pointe: nach DCT „sieht" man, was im Block wichtig ist. Schritt 5 wirft die unwichtigen hohen Frequenzen weg.
+-->
+
+---
+
+# Schritt 5: Quantisierung — *hier* wird weggeworfen
+
+Jeder DCT-Koeffizient wird durch einen Wert aus der **Quantisierungs-Tabelle** geteilt und gerundet.
+
+**Niedrige Frequenzen** (wichtig): kleine Tabellen-Werte → wenig Rundung → bleiben erhalten.
+**Hohe Frequenzen** (Detail): große Tabellen-Werte → starke Rundung → werden Null.
+
+**Quality-Slider 100 → 1** ist nichts anderes als „aggressiver multiplizieren".
+
+<!--
+DCT-Koeffizienten in einem Block sehen typisch so aus:
+[ 200, 50, 20,  5,  2,  1,  0,  0]
+[  60, 15,  8,  3,  1,  0,  0,  0]
+[  25,  8,  4,  1,  0,  0,  0,  0]
+[  ...
+
+Quantisierungs-Tabelle (Q90, ähnlich JPEG-Standard):
+[  3,  2,  2,  4,  6, 10, 13, 16]
+[  2,  2,  3,  4,  7, 15, 16, 14]
+...
+
+Division + Rundung:
+[ 67, 25, 10,  1,  0,  0,  0,  0]
+[ 30,  8,  3,  1,  0,  0,  0,  0]
+[  8,  4,  1,  0,  0,  0,  0,  0]
+
+Die hohen Frequenzen sind Null geworden. Die NULL-Sequenzen werden in Schritt 6 sehr effizient huffman-kodiert.
+
+Bei Quality 50 oder 10 sind die Werte in der Tabelle viel höher → viel mehr Nullen → kleinere Datei, aber sichtbare Artefakte (8x8-Blöcke werden sichtbar).
+-->
+
+---
+
+# Schritt 6: Huffman-Coding (verlustfrei)
+
+Die quantisierten Koeffizienten sind voller **Nullen** (die hohen Frequenzen).
+
+**Huffman:** häufige Werte (= Nullen) bekommen **kurze Codes**, seltene Werte lange Codes.
+
+Plus **Zigzag-Scan + RLE**: lange Null-Sequenzen → ein einziges Symbol.
+
+**Resultat:** finale JPEG-Datei. Verlustfrei aus quantisierten Werten rekonstruierbar.
+
+<!--
+Huffman-Coding ist ein klassisches lossless-Verfahren, das auf der Häufigkeitsverteilung beruht. Es bezeichnet das gleiche Prinzip wie in ZIP — also kompatibel mit Kap 2.
+
+Zigzag: die 8×8-Koeffizienten werden in Zigzag-Reihenfolge gelesen (von niedriger zu hoher Frequenz). Dadurch landen alle Nullen am Ende → können als „Rest ist Null" kodiert werden.
+
+Konsequenz: nach Schritt 6 ist die Pipeline fertig. Die JPEG-Datei kann gespeichert/gesendet werden. Beim Anzeigen läuft die Pipeline rückwärts.
+-->
+
+---
+
+# Memo: Die 6 JPEG-Schritte
+
+| # | Schritt | Lossless / Lossy |
+|---|---------|------------------|
+| 1 | RGB → Y'CbCr (Farbraum) | Lossless |
+| 2 | Chroma-Subsampling 4:2:0 | **Lossy** |
+| 3 | 8×8 Blöcke | Lossless |
+| 4 | DCT (Frequenz-Zerlegung) | Lossless |
+| 5 | Quantisierung | **Lossy** (Haupt-Reduktion) |
+| 6 | Huffman + Zigzag + RLE | Lossless |
+
+Nur **2** der 6 Schritte verlieren Information.
+
+<!--
+Klausurfähig. Sechs Schritte. Reihenfolge wichtig. Lossy/Lossless-Status pro Schritt wichtig.
+
+Eselsbrücke: „Farb-Sub-Block-DCT-Quant-Huff" → F-S-B-D-Q-H.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/Felis_silvestris_silvestris_small_gradual_decrease_of_quality_-_JPEG_compression.jpg)
+
+<!--
+Wikipedia-Bild: dieselbe Katze, fortschreitende JPEG-Kompression.
+
+Links: kaum komprimiert (Quality ~100).
+Mitte: mittlere Quality (~50).
+Rechts: extreme Kompression (Quality ~10) → 8×8-Blöcke sichtbar, Farbsäume, Detail-Verlust.
+
+Studis erkennen das aus dem Alltag:
+- WhatsApp-Bilder, die durch viele Hände gingen → JPEG-Generation-Loss
+- Screenshots, die als JPEG gespeichert wurden → unscharfe Schrift
+- Instagram-Posts, die mehrfach re-uploaded wurden → wächsende Artefakte
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Andere Bildformate
+
+<!--
+JPEG ist der König — aber für bestimmte Anwendungen gibt es bessere Alternativen.
+
+Übersicht:
+- PNG: lossless, mit Transparenz
+- GIF: alt, animiert, max. 256 Farben
+- WebP: Googles JPEG-Killer
+- AVIF: AV1-basiert, noch effizienter
+- SVG: vektor, skalierbar
+-->
+
+---
+
+# Bildformate im Überblick
+
+| Format | Typ | Loss | Transparenz | Animation | Stärke |
+|--------|-----|------|------------|-----------|--------|
+| **JPEG** | Raster | Lossy | ✗ | ✗ | Fotos |
+| **PNG** | Raster | Lossless | ✓ | ✗ | Logos, Screenshots |
+| **GIF** | Raster | Lossless | 1-bit | ✓ | Memes, Sticker |
+| **WebP** | Raster | beides | ✓ | ✓ | Modern Web |
+| **AVIF** | Raster | beides | ✓ | ✓ | Höchste Qualität bei kleinster Datei |
+| **SVG** | Vektor | Lossless | ✓ | ✓ (mit JS/CSS) | Logos, Icons |
+
+<!--
+- PNG: ältester moderner Lossless-Standard, seit 1996 (als Patent-freier GIF-Ersatz entstanden).
+- GIF: 1987, eingeschränkt auf 256 Farben, animationsfähig — daher heute der Meme-Veteran.
+- WebP: Google 2010, soll JPEG ersetzen. Ist 25-35% kleiner als JPEG bei gleicher Qualität.
+- AVIF: 2019, basiert auf AV1-Video-Codec. ~50% kleiner als JPEG, ~20% kleiner als WebP.
+- SVG: 2001, das einzige Vektor-Format hier. Skaliert ohne Verlust.
+
+Quality-Bewusstsein: SVG ist nicht „Konkurrenz" zu Raster-Formaten — sie lösen verschiedene Probleme.
+-->
+
+---
+
+# Wann welches Bildformat?
+
+| Anwendung | Format | Warum |
+|-----------|--------|-------|
+| Foto im Web (Insta, News) | **JPEG** oder **WebP** | klein, Foto-optimiert |
+| Foto-Archiv (RAW) | **RAW**, **TIFF**, **DNG** | nichts verlieren |
+| Logo, Icon (skalierbar) | **SVG** | wird neu berechnet |
+| Logo als Raster | **PNG** | Transparenz + scharfe Kanten |
+| Screenshot mit Text | **PNG** | scharfe Buchstaben |
+| Animiertes Sticker | **GIF** oder **WebP** | beide animierbar |
+| Foto in höchster Modern-Qualität | **AVIF** oder **WebP** | bessere Kompression als JPEG |
+
+<!--
+Klausurfähig: gegeben ein Anwendungsfall, welches Format und warum?
+
+Sub-Frage: was schief geht, wenn ich JPEG für ein Logo nehme? → unscharfe Ränder + sichtbare Artefakte.
+
+Sub-Frage: warum nicht immer AVIF? → Browser-Support (manche ältere Browser können AVIF noch nicht), Tool-Kompatibilität, Workflow-Etablierung.
+-->
+
+---
+
+# Patent-Politik — warum WebP, nicht JPEG XL?
+
+**WebP** (Google, 2010): lizenzfrei. Chrome supportet von Anfang an. Heute überall.
+
+**JPEG XL** (2021): technisch überlegen — bessere Kompression, lossless+lossy in einem Format, JPEG-kompatibel. Sollte JPEG ablösen.
+
+**Google entfernte Chrome-Support für JPEG XL im Februar 2023.** Begründung: „nicht genug ökosystem-traction". Inoffiziell: WebP ist Google's eigenes Format.
+
+→ **Patent-Politik schlägt technische Überlegenheit.** Wer den Browser kontrolliert, kontrolliert das Format.
+
+<!--
+Diese Geschichte zeigt: die Wahl von Bildformaten ist nicht nur technisch, sondern politisch.
+
+JPEG XL hatte alles für sich:
+- Bessere Lossy-Kompression als JPEG, WebP, AVIF
+- Bessere Lossless-Kompression als PNG
+- Erlaubt lossless-Konvertierung von altem JPEG (=> zukunftssicher)
+- Patentfrei
+
+Aber: Google deklarierte 2023, Chrome supportet JPEG XL nicht. Damit war das Format faktisch tot — weil >70 % aller Browser Chrome-basiert sind.
+
+Bittersüße Lektion: technische Standards setzen sich nicht durch Verdienst durch, sondern durch Marktmacht. AVIF (auch Google) bleibt — JPEG XL nicht.
+
+Apple supportet JPEG XL ironischerweise in macOS Sonoma + Safari 17 (2023). Ein seltener Fall, wo Apple offener ist als Google.
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Sub-Sektion B: Audio
+
+<!--
+Audio ist kürzer als Bilder, weil wir die Grundlagen (Sampling, Bittiefe, Datenrate, Nyquist) bereits in Kap 1 hatten. Hier nur:
+- Recap Sampling + Bittiefe
+- MP3-Trick konkret (Maskierung)
+- Bitrate-Stufen verstehen
+- Format-Wahl-Matrix
+-->
+
+---
+
+# Sampling + Bittiefe — Recap aus Kap 1
+
+**Sampling Rate** (Hz): wie oft messen wir pro Sekunde.
+**Bittiefe** (bit): wie fein jede Messung.
+**Datenrate** = Sample Rate × Bittiefe × Kanäle.
+
+**CD-Audio:** 44,1 kHz × 16 bit × 2 = **1,4 Mbit/s** → ~10 MB/Min.
+
+**Wir wollen:** ~1 MB/Min (10× kleiner). *Wie?*
+
+<!--
+Anschluss zu Kap 1 (Nyquist): unkomprimierte Audio ist 10 MB/Min. Streaming geht aber mit 1 MB/Min. Lösung: MP3 (oder AAC, OPUS).
+
+Diese Folie ist nur Recap. Der eigentliche Inhalt kommt nächste Folie.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/psychoakustik-grafik.png)
+
+<!--
+Erinnerung aus Kap 2: Maskierung.
+
+Ein lauter Ton (Masker) macht in seiner Frequenz-Umgebung leise Töne unhörbar.
+
+MP3-Pipeline:
+1. Audio in 32 Frequenz-Bänder unterteilen (Filterbank)
+2. Psychoakustisches Modell anwenden — pro Band: was ist hörbar?
+3. Quantisierung — nicht-hörbares wegwerfen
+4. Huffman-Coding der Rest-Daten
+
+Pointe: typischerweise 90 % der Daten weggeworfen, ohne dass im Alltag etwas vermisst wird.
+
+Die Pipeline selbst ist mathematisch komplexer als JPEG (echte Filterbank statt einfacher DCT), aber das Prinzip ist gleich:
+- Wahrnehmungs-Modell
+- Quantisierung (lossy)
+- Huffman (lossless)
+-->
+
+---
+
+# Bitrate — der Qualitäts-Knopf
+
+| Bitrate | Anwendung | Hörbar? |
+|---------|-----------|---------|
+| **64 kbit/s** | Sprachnachricht WhatsApp | dumpf, hörbar schlechter |
+| **128 kbit/s** | YouTube-Audio, frühe MP3s | mittel, viele hören Unterschied |
+| **192 kbit/s** | Spotify Free | gut für Alltag |
+| **320 kbit/s** | Spotify Premium „sehr hoch" | praktisch CD-Qualität |
+| **1 411 kbit/s** | CD (unkomprimiert) | Referenz |
+
+**Faustregel:** je höher die Bitrate, desto mehr Detail bleibt erhalten — *aber Diminishing Returns ab ~256 kbit/s.*
+
+<!--
+Spotify-Premium-Stufen:
+- Niedrig: 24 kbit/s (selten benutzt)
+- Normal: 96 kbit/s
+- Hoch: 160 kbit/s
+- Sehr hoch: 320 kbit/s (nur Premium)
+
+Spotify HiFi (lossless 1411 kbit/s): seit Jahren angekündigt, immer wieder verschoben.
+
+Pointe: für die meisten Anwendungen reicht 192 kbit/s. Wer mehr will, sollte FLAC nehmen (nicht MP3).
+-->
+
+---
+
+# Audio-Format-Landschaft
+
+| Format | Loss | Anwendung | Bitrate |
+|--------|------|-----------|---------|
+| **WAV** | Lossless | Studio-Master, Wave-Editor | 1.411 kbit/s (CD) |
+| **FLAC** | Lossless | Audiophile, Archiv | ~700 kbit/s (CD-Kompression) |
+| **MP3** | Lossy | Universalformat, älter | 128-320 kbit/s |
+| **AAC** | Lossy | Apple, YouTube, modern | 128-256 kbit/s |
+| **OGG / Vorbis** | Lossy | Open-Source, Spotify (alt) | 128-320 kbit/s |
+| **Opus** | Lossy | WhatsApp Call, Zoom | 6-510 kbit/s |
+
+<!--
+Wichtig:
+- WAV ist nur ein Container. Inhalt ist roh PCM (oder seltener lossless-komprimiert).
+- FLAC = lossless, aber komprimiert (Faktor 2-3 gegenüber WAV).
+- AAC ist technisch besser als MP3 (ca. 30% kleiner bei gleicher Qualität), aber Patent-Lizenzen.
+- Opus ist der moderne Open-Source-Codec für Sprache UND Musik. Variable Bitrate.
+-->
+
+---
+
+# Audio-Format-Wahl
+
+| Anwendung | Format | Warum |
+|-----------|--------|-------|
+| Spotify-Stream | **AAC** oder **MP3 192+** | Kompression, breite Unterstützung |
+| Studio-Master | **WAV** oder **FLAC** | Bit-genau erhalten |
+| Sprachnachricht | **Opus** oder **AAC-LD** | für Sprache optimiert, niedrige Bitrate |
+| Podcast-Distribution | **MP3 128 kbit/s** | universelle Unterstützung |
+| HiFi-Audiophile | **FLAC** | lossless, kleiner als WAV |
+| Archiv eigener Aufnahmen | **FLAC** oder **WAV** | nichts verlieren |
+
+<!--
+Klausurfähig: gegeben ein Anwendungsfall, welches Format?
+
+Trick-Frage: warum nicht MP3 320 für Studio? → Lossless ist immer noch verlustfrei besser. Wer mastern will, braucht das.
+
+Trick-Frage 2: warum nicht WAV für Spotify? → Daten-Volumen zu hoch fürs Streaming.
+-->
+
+---
+
+<!-- _class: aufgabe -->
+
+# Selbstlernen — Spotify-Bitrate live
+
+Auf eurem Handy:
+
+1. Spotify Premium-Setting auf **Niedrig (24 kbit/s)** umstellen
+2. Lieblings-Track mit **Kopfhörer** anhören. Auf Höhen achten.
+3. Auf **Sehr hoch (320 kbit/s)** umstellen
+4. Gleicher Track. Vergleichen.
+
+**Was fällt auf?** Welche Frequenzen verschwinden zuerst?
+
+<!--
+Pädagogisch: Studis hören selber, was der psychoakustische Codec wegwirft.
+
+Erwartung:
+- 24 kbit/s: hochfrequente Detail weg (Cymbal, „s"-Töne), Stimme klingt dumpf
+- 320 kbit/s: praktisch identisch mit CD
+
+Diskussion: für welche Hörsituation braucht ihr 320? (Studio-Kopfhörer, gute Anlage) Für welche reicht 96? (Smartphone-Lautsprecher).
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Sub-Sektion C: Video
+
+<!--
+Video = Bild + Zeit + Audio.
+
+Drei Konzepte zentral:
+1. Container ≠ Codec (DAS Missverständnis)
+2. Inter-Frame-Kompression (Frame-zu-Frame-Ähnlichkeit nutzen)
+3. Codec-Landschaft (H.264, H.265, VP9, AV1) + Patent-Politik
+
+Wir bauen auf JPEG auf — Inter-Frame nutzt JPEG-ähnliche DCT-Kompression pro Frame, plus Zeitliches.
+-->
+
+---
+
+# Pixel × Pixel × Hz = Datenflut
+
+**Roh-Video 4K @ 60 fps:**
+
+```
+3 840 × 2 160 Pixel × 3 Byte × 60 fps = 1,49 GB/s
+```
+
+**Pro Minute:** ~90 GB. *Pro Stunde:* ~5,3 TB.
+
+Eine 1-TB-SSD wäre nach **~11 Minuten** voll.
+
+→ **Ohne Kompression ist Streaming unmöglich.**
+
+<!--
+Diese Rechnung ist klausurfähig und sollte beeindrucken:
+- Pixel pro Frame: 3840 × 2160 = ~8,3 Millionen
+- Byte pro Pixel: 3 (RGB)
+- Frame pro Sekunde: 60
+- Resultat: 1,5 GB/s
+
+Vergleich:
+- Heim-Bandbreite: ~25 Mbit/s = 3 MB/s. 500× zu langsam für rohes 4K.
+- 4G-Mobilfunk: ~50 Mbit/s = 6 MB/s. Immer noch 250× zu langsam.
+- Netflix 4K-Stream: 25 Mbit/s. Erreicht durch Kompression. Faktor 480.
+
+Die Kompression ist hier nicht „nice to have" — sie ist die Voraussetzung, dass es Video-Streaming überhaupt gibt.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/container-vs-codec.png)
+
+<!--
+Das ist DER zentrale Missverständnis-Punkt bei Video. Studis denken oft, „MP4" oder „MKV" sei das Format des Videos. Stimmt nicht. Es ist nur die Hülle.
+
+Konkretes Beispiel: zwei `.mp4`-Dateien:
+- A: H.264-Video + AAC-Audio
+- B: H.265-Video + Opus-Audio
+
+Beide haben die Endung .mp4. Aber A spielt überall, B braucht moderne Player.
+
+Tool: `mediainfo <datei>` zeigt Container UND Codec.
+
+Klausurfähig.
+-->
+
+---
+
+# Was ist in einem Container?
+
+```
+MP4-Container
+├── Video-Spur (H.264, codec: avc1)
+├── Audio-Spur (AAC, codec: mp4a)
+├── Untertitel-Spur (TTML, optional)
+└── Metadaten (Titel, Erstellungsdatum, Bitrate, GOP-Struktur, ...)
+```
+
+Container regelt:
+- **Sync** zwischen Spuren (Audio passt zum Bild)
+- **Seeking** (Springen im Video)
+- **Streaming-Sicherheit** (Header früh genug)
+
+<!--
+Container vs Codec:
+- Container = Datei-Format (.mp4, .mkv, .webm)
+- Codec = Algorithmus (H.264, H.265, AV1)
+
+Vergleich aus dem Alltag:
+- Container ≈ Buchdeckel (Hardcover, Paperback, E-Book)
+- Codec ≈ Sprache des Texts (Englisch, Deutsch, übersetzt)
+
+Ein und das selbe Buch (= Video) kann in verschiedenen Buchdeckeln (Containern) und verschiedenen Sprachen (Codecs) existieren.
+
+Konkrete Tools:
+- ffmpeg: kann Container und Codec wechseln
+- mediainfo: zeigt was in einer Video-Datei drin ist
+- HandBrake: GUI für Encoding
+-->
+
+---
+
+# Inter-Frame — die zentrale Idee
+
+![bg right:40% contain](./assets/iframe-pframe-diagram.png)
+
+Aufeinanderfolgende Frames sind **fast gleich**. Statt jedes ganz speichern: nur **Differenz**.
+
+Drei Frame-Typen:
+
+* **I** (Intra) — ganzes Bild
+* **P** (Predicted) — Diff zum vorigen
+* **B** (Bidirectional) — Diff zu vorigem + nächstem
+
+<!--
+Inter-Frame ist DER Trick, der Video-Kompression überhaupt möglich macht.
+
+Ohne Inter-Frame wäre 4K-Video ~480× kleiner als roh (nur durch Intra-Kompression). Mit Inter-Frame: ~10.000× kleiner. Das ist Streaming-tauglich.
+
+GOP (Group of Pictures): typische Anordnung
+- IBBPBBPBBPBBP...IBBPBBP...
+- Alle 1-3 Sekunden ein I-Frame (Seeking-Anker)
+- Dazwischen P- und B-Frames
+
+B-Frames sind effizienter als P-Frames (haben zwei Vorlagen), aber teurer zu enkodieren.
+-->
+
+---
+
+# I, P, B — Frame-Typen
+
+| Typ | Vollname | Was drin | Größe |
+|-----|----------|----------|-------|
+| **I** | Intra-coded | Komplettes Bild (wie JPEG) | groß |
+| **P** | Predicted | „Was hat sich seit voriges I/P geändert" | mittel |
+| **B** | Bidirectional | „Was zwischen vorigem und nächstem I/P" | klein |
+
+Typische GOP: `I B B P B B P B B P B B I ...` (alle 1–3 Sekunden ein I-Frame).
+
+<!--
+Klausurfähig: was sind I/P/B-Frames? Welche ist die größte? Warum brauchen wir I-Frames trotzdem (Seeking, Stream-Start, Fehlerresistenz)?
+
+GOP = Group of Pictures.
+
+I-Frame als Seeking-Anker:
+- Wenn man im Video an einer Stelle springt, kann der Player nur an I-Frames anfangen
+- Zwischen I-Frames muss Player VOM letzten I-Frame ab dekodieren bis zur Spring-Stelle
+
+Daher: I-Frames sollten nicht zu selten sein (sonst langsames Seeking), aber auch nicht zu häufig (sonst weniger Kompression).
+-->
+
+---
+
+# Motion Compensation
+
+Ein Block aus dem vorigen Frame wird **verschoben** — nicht neu kodiert.
+
+P-Frame speichert:
+1. Bewegungsvektor (z.B. „Block A: +5 Pixel rechts, +2 Pixel runter")
+2. Differenz zum verschobenen Block
+
+**Resultat:** Auto-Fahrt vor stehender Kamera → P-Frames mini-klein.
+
+<!--
+Motion Compensation ist der eigentliche „magic move" der Video-Kompression.
+
+Bei einer Kamerafahrt (Schwenk) ist der Großteil des Bildes nur „verschoben". Der Codec sucht für jeden 16×16- oder 32×32-Block im neuen Frame den am besten passenden Block in einem Referenz-Frame und speichert nur:
+- Position dieses Referenz-Blocks
+- Differenz (das, was sich tatsächlich geändert hat)
+
+Für statische Szenen mit reden den Personen: P-Frames sind oft ~5 % der I-Frame-Größe.
+
+Encoding ist asymmetrisch: Encoder muss diese Block-Suche durchführen → teuer. Decoder bekommt nur die fertigen Vektoren → billig. Deshalb ist Video-Encoding viel langsamer als -Decoding.
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Die Codec-Landschaft
+
+<!--
+H.264 → H.265 → AV1 → ?
+
+Vier Generationen:
+- H.264 (2003): der dominierende Codec, überall, lizenzpflichtig aber gnädig
+- H.265 (2013): 50% effizienter, aber Patent-Chaos (mehrere Patent-Pools)
+- VP9 (2013): Google-Antwort, lizenzfrei
+- AV1 (2018): Industrie-Allianz, lizenzfrei, beste Kompression
+
+Politik schlägt Technik. Ein guter Codec, der teuer ist, setzt sich nicht durch — siehe H.265.
+-->
+
+---
+
+# H.264 / AVC — der Workhorse
+
+**2003** • dominierender Video-Codec seit Smartphone-Ära.
+
+Wo überall verwendet:
+- YouTube (Hauptcodec)
+- Zoom, Teams, Meet
+- Netflix (HD-Streams)
+- Smartphones (alle iOS-Aufnahmen, viele Android)
+
+Patente: MPEG-LA-Pool. Lizenzkosten **moderat**, viele Hersteller decken die Kosten in der Hardware ab.
+
+<!--
+H.264 hat sich durchgesetzt weil:
+- Technisch deutlich besser als sein Vorgänger (MPEG-2)
+- Hardware-Decoder seit ~2010 in jedem Smartphone-Chip
+- Patente sind kostspielig, aber überschaubar (vergleichbar mit JPEG/MP3 in den 90ern)
+
+Trotz Alter (~22 Jahre) immer noch der Standard. Effizienter sind H.265 und AV1, aber Kompatibilität und Patent-Klarheit halten H.264 lebendig.
+-->
+
+---
+
+# H.265 / HEVC — Patent-Chaos
+
+**2013** • technisch ~50 % effizienter als H.264.
+
+**Aber:** drei separate Patent-Pools, intransparente Lizenzkosten.
+
+Resultat:
+- **Apple** macht alles in H.265 (HEIC-Fotos, iOS-Video) — bezahlt Lizenzen
+- **YouTube, Netflix** verzichten weitgehend — zu teuer + risikoreich
+- **Industrie-Reaktion:** Allianz für Open Media (AOMedia) gegründet, baut AV1
+
+<!--
+H.265 ist der Lehrbuch-Fall für „technisch überlegen, kommerziell gescheitert".
+
+Drei Patent-Pools (MPEG-LA, HEVC Advance, Velos Media) wollten alle separat Lizenzgebühren. Niemand wusste, was das Gesamt-Paket kostet. Software-Hersteller (Browser, Encoder) konnten kein realistisches Budget machen.
+
+YouTube und Netflix haben deshalb H.265 für ihre Streaming-Operationen meiden lassen. Investierten stattdessen in VP9 (Google) und AV1 (AOMedia).
+
+Apple ist mit HEIC ein Sonderfall: Apple hat genug Kapital, um die Lizenzen aller drei Pools zu zahlen, und nutzt H.265 für die kameraseitige Aufnahme.
+
+Pointe: ein guter Codec ohne klare Lizenz-Situation ist tot für die Industrie.
+-->
+
+---
+
+# VP9 + AV1 — die offene Antwort
+
+**VP9** (Google, 2013): lizenzfrei, ähnlich effizient wie H.265.
+- YouTube nutzt es für 4K-Streams (Chrome, Firefox).
+
+**AV1** (Alliance for Open Media, 2018): Konsortium aus Google, Mozilla, Netflix, Amazon, Apple, ARM, Microsoft, Cisco, Intel, NVIDIA...
+- **Lizenzfrei.** **30 % effizienter als H.265.**
+- Hardware-Decoder seit ~2021 verfügbar (M1, Snapdragon 888+).
+- YouTube, Netflix, Twitch streamen schon AV1.
+
+<!--
+AV1 ist die Industrie-Antwort auf das H.265-Patent-Desaster.
+
+Bei AV1 standen die wichtigsten Internet-Player zusammen und sagten: „wir bauen einen Codec, der allen gehört, lizenzfrei ist und mindestens so gut wie H.265". 2018 war der Standard fertig.
+
+Heute:
+- YouTube streamt 4K viel in AV1
+- Netflix streamt AV1 wo Decoder verfügbar
+- Twitch ebenfalls
+- Chrome, Firefox, Edge supportet AV1 nativ
+- Safari supportet seit macOS 13/Apple-M3-Chip
+
+Hardware ist der Engpass: AV1 ist rechenintensiver zu enkodieren als H.264. Aber für die Studis, die einfach Videos schauen, ist das nicht relevant.
+
+Pointe: politisch gewinnt der „offene" Codec, wenn die Industrie es will. Bei AV1 hat sie es gewollt.
+-->
+
+---
+
+# Patent vs. Open — warum AV1?
+
+| Codec | Effizienz | Patent | Adoption (2026) |
+|-------|-----------|--------|-----------------|
+| H.264 | Baseline | Lizenz (MPEG-LA) | ~80 % aller Videos |
+| H.265 | +50 % | 3 Patent-Pools, chaotisch | nur Apple |
+| VP9 | ~H.265 | lizenzfrei (Google) | YouTube 4K |
+| **AV1** | **+30 % über H.265** | **lizenzfrei (Allianz)** | **YouTube, Netflix, Twitch** |
+
+**Die Lektion:** technisch beste Lösung gewinnt nicht. *Lizenz-klare* beste Lösung gewinnt.
+
+<!--
+Klausurfähig: warum hat AV1 H.265 abgelöst, wenn beide ähnlich effizient sind?
+
+Antwort: Patent-Politik. H.265 hat drei Patent-Pools, AV1 ist lizenzfrei. Industrie-Konsortium hat AV1 finanziert, weil sie nie wieder einem MPEG-LA-Pool ausgeliefert sein wollten.
+
+Sub-Frage: warum nicht VP9? → AV1 ist effizienter (~30 %), und alle wichtigen Player stehen dahinter (statt nur Google).
+-->
+
+---
+
+# 4K-Stream vs. Heim-Bandbreite
+
+| Auflösung | Bitrate (H.265/AV1) | Heim-Bandbreite nötig |
+|-----------|---------------------|----------------------|
+| 480p (SD) | 1 Mbit/s | jeder Anschluss |
+| 720p (HD) | 3 Mbit/s | DSL ausreichend |
+| 1080p (Full HD) | 8 Mbit/s | DSL-25 + |
+| **4K (UHD)** | **25 Mbit/s** | **Glasfaser oder Kabel** |
+| 4K HDR | 35 Mbit/s | Kabel-Premium |
+| 8K | ~100 Mbit/s | Glasfaser-200 |
+
+**Spotify-Audio dagegen:** Highest = 320 kbit/s = 0,3 Mbit/s. *80× weniger als ein 4K-Stream.*
+
+<!--
+Diese Folie zeigt: Video ist die mit Abstand bandbreitenhungrigste Anwendung im Internet.
+
+Konkret in DE (2026 Stand):
+- VDSL 50 Mbit/s ist Standard → reicht für 1080p, gerade so für 4K
+- Glasfaser 250 Mbit/s in Großstädten → 4K kein Problem
+- Mobilfunk 5G ~100 Mbit/s → 4K möglich
+
+Konsequenz: ein 4K-Netflix-Stream allein nutzt einen typischen 50-Mbit-Anschluss zur Hälfte. Wenn der Mitbewohner auch streamt, wird's eng.
+
+Anschluss zum nächsten Kapitel (Kap 4): „Wie kommen die Daten überhaupt zu meinem Gerät?" → Speichermedien und Schnittstellen.
+-->
+
+---
+
+<!-- _class: aufgabe -->
+
+# Selbstlernen — drei Übungen
+
+**Bild:**
+[Squoosh.app](https://squoosh.app) öffnen. Eigenes Foto in JPEG vs WebP vs AVIF konvertieren. Größe + Qualität vergleichen.
+
+**Audio:**
+Spotify Premium-Bitrate von 24 auf 320 kbit/s wechseln. Lieblings-Track anhören. Was fällt auf?
+
+**Video:**
+`mediainfo` (CLI oder GUI) auf eine eigene Video-Datei. Welcher Container? Welcher Codec? Welche Bitrate?
+
+<!--
+Drei Übungen, eine pro Modalität. Jede sollte ~5-10 Min dauern.
+
+Tool-Empfehlungen:
+- Squoosh.app (Browser, kein Install) — Google's Foto-Komprimierer
+- mediainfo: brew install mediainfo / sudo apt install mediainfo
+- Spotify: integriert
+
+Pädagogisches Ziel: Studis sollen das Gelernte am eigenen Material durchspielen.
+-->
+
+---
+
+# Zusammenfassung
+
+**Drei Modalitäten, ein Prinzip:** Wahrnehmungs-Lücken als Hebel.
+
+| | **Bild** | **Audio** | **Video** |
+|--|----------|-----------|-----------|
+| Lossy-Trick | Chroma-Subsampling + DCT-Quantisierung | Maskierung + Hörschwelle | Inter-Frame + JPEG-pro-Frame |
+| Standardformat | JPEG | MP3/AAC | H.264 / AV1 |
+| Reduktion | ~10× | ~10× | ~100× |
+| Format-Politik | WebP > JPEG XL (Google) | MP3-Patent → AAC | H.265-Chaos → AV1 |
+
+**In Kap 4** schauen wir uns an, *wie* diese Daten zu eurem Gerät kommen — und welche Schnittstelle dabei der Engpass ist.
+
+<!--
+Recap:
+
+Drei Modalitäten:
+- BILD: Raster vs Vektor. JPEG-Pipeline 6 Schritte (Farbraum, Chroma-Sub, Blöcke, DCT, Quant, Huffman). PNG/GIF/WebP/AVIF/SVG-Landschaft. Patent-Politik (WebP vs JPEG XL).
+- AUDIO: Sampling+Bittiefe-Recap. MP3-Maskierung. Bitrate-Stufen 128/192/320. Format-Landschaft (WAV/FLAC/MP3/AAC/Opus).
+- VIDEO: Container ≠ Codec. I/P/B-Frames. Motion Compensation. Codec-Landschaft (H.264/H.265/VP9/AV1). AV1-Patent-Politik.
+
+Großes Thema dahinter: Wahrnehmung als Hebel. Was wir nicht sehen/hören → wegwerfen. Das ist die ganze Magie hinter Lossy.
+
+Anschluss Kap 4: jetzt wissen wir, WAS in einer JPEG/MP3/MP4-Datei drin ist. Jetzt: wie kommt es zu uns? Speicher + Schnittstellen.
+-->

slides/223015b-2026/04-speicher-schnittstellen.md

@@ -0,0 +1,588 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
+title: Speicher und Schnittstellen
+---
+
+<style>
+:root {
+  --color-foreground: #1a1a2e;
+  --color-highlight: #1e5f8a;
+  --color-dimmed: #4a4a6a;
+}
+section.invert { --color-foreground: #fff; }
+section { font-size: 1.7rem; }
+h1 { color: #1e5f8a; }
+section.invert h1 { color: #fff; }
+h2 { color: #1f2937; }
+pre {
+  background: #0f0f23;
+  color: #5fb3e4;
+  border-radius: 8px;
+  border-left: 3px solid #1e5f8a;
+}
+pre code { background: transparent; color: inherit; }
+code {
+  background: #0f0f23;
+  padding: 0.15em 0.4em;
+  border-radius: 4px;
+  font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
+}
+section code:not(.hljs) { color: #5fb3e4 !important; }
+section code.hljs { color: #f8f8f8 !important; }
+a { color: var(--color-highlight); }
+section.klausur {
+  background: repeating-linear-gradient(
+    135deg,
+    #e3f2fd,
+    #e3f2fd 40px,
+    #fff 40px,
+    #fff 80px
+  ) !important;
+}
+@media print {
+  section.klausur { background: #e3f2fd !important; }
+}
+section.aufgabe { background: #e3f2fd !important; }
+section.aufgabe footer { display: none; }
+section.erklaerung :not(header),
+section.erklaerung :not(footer) { font-size: 1.1rem; }
+section.erklaerung h1 { font-size: 1.5rem; color: #1e5f8a; margin-bottom: 0.3rem; }
+section.erklaerung ul, section.erklaerung ol { font-size: 1.0rem; line-height: 1.4; }
+section.erklaerung p { font-size: 1.0rem; line-height: 1.4; }
+section.erklaerung table { font-size: 0.9rem; }
+</style>
+
+<!-- _class: lead -->
+
+# Kapitel 4
+## Speicher und Schnittstellen
+
+<!--
+Eine Stunde, eine Frage: *Wo wohnen die Bytes — und wie reisen sie zwischen Geräten?*
+
+Anschluss an Kap 3: dort haben wir gesehen, was in einer JPEG/MP3/MP4 drin ist (Inhalt). Hier: wo lebt diese Datei (Speicher) und wie kommt sie auf den Bildschirm (Schnittstellen).
+
+Bogen:
+1. Speicher: HDD vs SSD, Filesystems, Backup
+2. PIVOT: wie reisen die Bytes?
+3. Schnittstellen: USB-C-Chaos, HDMI/DP/TB/Ethernet/WiFi
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/kap04-eroeffner.png)
+
+<!--
+Datei-Reise als Pipeline: SSD → Laptop → GPU → Monitor → Auge.
+
+Pro Etappe ein Engpass:
+- USB 4 / Thunderbolt 4: 3 200 MB/s
+- PCIe 4.0 (intern Laptop): ~7 000 MB/s
+- HDMI 2.1 zum Monitor: 2 200 MB/s
+- Licht zum Auge: visuell
+
+Pro Sekunde bei 4K60: 24 MB pro Frame × 60 fps = 1,4 GB/s reiner Pixel-Strom, der NIE als Datei vorliegt.
+
+Pointe: Speicher und Schnittstelle sind keine zwei Themen — sie sind die zwei Seiten desselben Engpasses. Wo Bytes wohnen, entscheidet, wie schnell sie reisen können. Wo sie reisen, entscheidet, wo sie wohnen müssen.
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Sub-Sektion A: Speicher — wo wohnen die Bytes?
+
+<!--
+Reihenfolge:
+1. HDD-Mechanik
+2. SSD-Flash
+3. HDD vs SSD: Vergleich + wann was
+4. Filesystems: FAT32 / NTFS / APFS / ext4
+5. Backup-Praxis: 3-2-1-Regel
+-->
+
+---
+
+# HDD — Magnetscheibe mit beweglichen Köpfen
+
+**Hard Disk Drive.** Erfunden 1956 (IBM RAMAC). Bis 2010 das Standard-Speichermedium.
+
+- **Magnetisierte** Bereiche auf rotierender Platter (5.400–15.000 U/min)
+- Schreib-/Lese-**Kopf** schwebt auf Luftpolster (~5 nm Abstand)
+- **Spuren** (konzentrische Kreise) + **Sektoren** (Tortenstück-Abschnitte)
+- **Bewegliche Teile** → Verschleiß, Geräusch, Stoß-empfindlich
+
+<!--
+Mechanik:
+- Platter dreht permanent, Kopf bewegt sich radial
+- Latenz: Kopf muss zur richtigen Spur (Seek Time, 5-10 ms) + Platter muss richtigen Sektor unter den Kopf bringen (Rotational Latency, ~3 ms bei 7200 rpm)
+- Sequenzieller Zugriff schnell (Kopf bleibt auf Spur), zufälliger Zugriff langsam
+
+Lebensdauer: typisch 5-10 Jahre bei moderater Nutzung. MTBF ~1 Mio Stunden. Lagerung ohne Strom: Magnetfeld hält jahrzehntelang.
+-->
+
+---
+
+# SSD — Speicher ohne Mechanik
+
+**Solid State Drive.** Massentauglich seit ~2010. Heute Standard für OS-Disks.
+
+- **Flash-Speicher** (NAND): Elektronen in Floating Gates speichern Bits
+- **Keine beweglichen Teile** → kein Geräusch, kein Stoß-Risiko
+- **NVMe-Protokoll** (PCIe-direkt) → 5–14 GB/s im Vergleich zu HDD-200 MB/s
+- **Schreibzyklen begrenzt** (TLC: ~3 000 P/E-Zyklen pro Zelle)
+
+<!--
+Flash-Technik:
+- Floating Gate Transistor speichert Ladung
+- TLC = Triple-Level Cell, 3 Bits pro Zelle = 8 Spannungs-Stufen
+- Wear Leveling: Controller verteilt Schreibvorgänge gleichmäßig über alle Zellen
+- TRIM: OS sagt Controller welche Blöcke „nicht mehr gebraucht" → Garbage Collection
+
+Lebensdauer in der Praxis: ~5-10 Jahre bei Consumer-Nutzung. Höher bei Enterprise.
+
+NVMe vs SATA:
+- SATA-SSD: max. ~600 MB/s (Bus-Limit)
+- NVMe-SSD über PCIe 4.0: ~7 000 MB/s
+- PCIe 5.0 (neuere Macs): bis ~14 000 MB/s
+-->
+
+---
+
+# HDD vs. SSD
+
+![bg right:40% contain](./assets/hdd-ssd-comparison.png)
+
+| | HDD | SSD |
+|--|-----|-----|
+| Technik | Mechanik | Flash |
+| Geschwindigkeit | 50–250 MB/s | 500–14.000 MB/s |
+| Latenz | ~10 ms | ~0,1 ms |
+| Preis/TB (2026) | ~20 € | ~70 € |
+| Lebensdauer | ~5–10 Jahre | ~5–10 Jahre |
+| Geräusch | hörbar | lautlos |
+| Stoß-empfindlich | ja | nein |
+
+<!--
+HDD-Vorteile: viel Kapazität für wenig Geld. Lange archivierbar im Schrank.
+SSD-Vorteile: schnell, leise, robust. Aber teurer pro TB.
+
+Klausurfähig: gegeben ein Anwendungsfall, HDD oder SSD?
+
+- Betriebssystem: SSD (schnell)
+- Backup-Archiv: HDD (billig)
+- Server für Foto-Speicher: HDD (Kapazität)
+- Laptop (mobil): SSD (Stoß)
+- Video-Bearbeitung: SSD (Throughput)
+-->
+
+---
+
+# Wann nehme ich was?
+
+| Anwendung | Empfehlung | Begründung |
+|-----------|------------|------------|
+| Betriebssystem auf dem Laptop | **NVMe-SSD** | Geschwindigkeit, Boot |
+| Eigene Foto-Library (10 TB+) | **HDD** | Kapazität, Preis |
+| Server für Logfiles | **HDD oder SSD** | je nach Schreib-Last |
+| Externes Backup-Archiv | **HDD** | billig, ok wenn langsam |
+| Mobile Workstation (Reise) | **SSD** | Stoß, Geräusch |
+| Edit-Drive für 4K-Schnitt | **NVMe-SSD** | Throughput für Video |
+| Langzeitarchiv 10+ Jahre | **LTO-Band + M-DISC** | Langlebigkeit |
+
+<!--
+Klausurfähig. Trick-Frage: warum nicht alles SSD? → Preis pro TB. Faktor 3-5× teurer.
+
+Cloud-Speicher (iCloud, Google Drive, Dropbox) ist physisch HDD/SSD/LTO in Rechenzentren — kein eigenes Medium, sondern Zugriffsmethode.
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Filesystems — die Sprache des Speichers
+
+<!--
+Filesystem = Buchhaltungs-System des Speichermediums.
+
+Welche Datei wo wohnt, welche Blöcke frei sind, wer welche Datei darf lesen.
+
+Studierende kommen damit in Kontakt:
+- USB-Stick formatieren (Dialog frägt: FAT32 / exFAT / NTFS / APFS?)
+- "warum kann ich 5-GB-Video nicht auf USB ziehen?" — FAT32-Limit
+- "Mac kann von Windows-USB lesen aber nicht schreiben" — NTFS-Asymmetrie
+-->
+
+---
+
+# Was macht ein Filesystem?
+
+**Vier zentrale Aufgaben:**
+
+1. **Datei-Tabelle:** welche Datei wohnt wo? (Block-Adressen)
+2. **Frei-Liste:** welche Blöcke sind ungenutzt?
+3. **Verzeichnisbaum:** Ordner-Hierarchie
+4. **Metadaten:** Berechtigung, Erstell-Zeit, Letzt-Änderung, Eigentümer
+
+Ein Speichermedium **ohne Filesystem** ist nur ein langer Strom von Bytes — niemand weiß, was wo ist.
+
+<!--
+Analog: ein Buch ohne Inhaltsverzeichnis. Du müsstest jede Seite durchblättern um zu wissen, wo Kapitel 5 anfängt.
+
+Filesystem = Inhaltsverzeichnis + Stichwortregister + Wer-darf-was-Liste.
+
+Wenn du einen USB-Stick „formatierst", wird das Filesystem neu angelegt — die existierenden Daten sind dann logisch weg (aber physisch oft noch da, deshalb Sicherheitslücke bei Verkauf).
+-->
+
+---
+
+# Filesystem-Landschaft
+
+| Filesystem | Wo verbreitet | Max. Dateigröße | Besonderheit |
+|-----------|---------------|----------------:|--------------|
+| **FAT32** | USB-Sticks, SD-Karten alt | **4 GB** | universell, alt |
+| **exFAT** | USB-Sticks modern | 16 EB | wie FAT, ohne 4-GB-Limit |
+| **NTFS** | Windows | 16 EB | Standard seit Win 2000 |
+| **APFS** | macOS seit 2017 | 8 EB | snapshots, schnell |
+| **ext4** | Linux | 16 TB | klassisch, robust |
+| **ZFS** | Server, FreeBSD | 16 EB | checksum, snapshots |
+
+**FAT32 4-GB-Grenze** ist der häufigste Alltags-Knack: USB-Stick noch nie umformatiert → kein 4K-Video drauf.
+
+<!--
+Klausurfähig: warum kann ich 5 GB Video nicht auf den USB-Stick ziehen? Antwort: FAT32 hat 4-GB-Dateigrößen-Limit. Lösung: USB-Stick auf exFAT umformatieren (Mac und Windows lesen/schreiben beide).
+
+Asymmetrien:
+- Mac kann NTFS nur lesen, nicht schreiben (ohne Drittpartei-Treiber)
+- Windows kann APFS gar nicht
+- Linux kann mit Plugins fast alles
+
+Konsequenz für Studis: für Datentransfer zwischen Mac und Windows → exFAT. Für reinen Mac → APFS. Für Backup auf USB-Disk, die nur am eigenen Gerät benutzt wird → natives FS.
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Backup — die unangenehme Pflicht
+
+<!--
+Backup-Disaster-Stories als Hook:
+- Pixar verlor 1998 fast „Toy Story 2" durch ein versehentliches `rm -rf` auf dem Server. Nur weil eine Mitarbeiterin (Galyn Susman) zu Hause an einem Mutterschafts-Backup gearbeitet hatte, konnten 30 % des Films gerettet werden.
+- Maersk wurde 2017 durch NotPetya-Ransomware getroffen, 50.000 PCs verschlüsselt. Globale Schifffahrt stand 10 Tage. Recovery: dank einem Domain-Controller in Ghana, der zum Zeitpunkt des Angriffs ohne Strom war und deshalb nicht infiziert wurde.
+
+Pointe: Backup ist kein Optional. Es ist die einzige Verteidigung gegen Hardware-Crash, Diebstahl, Ransomware und menschliches Versagen.
+-->
+
+---
+
+![bg right:40% contain](./assets/backup-disaster.png)
+
+# Pixar verlor Toy Story 2 fast
+
+**1998.** Ein Mitarbeiter führte ein Maintenance-Skript aus, das per `rm -rf /` ausversehen die Hauptdatenbank löschte.
+
+90 % des Films weg. Backup-Tapes? Defekt seit Monaten — niemand merkte es.
+
+**Glück:** Galyn Susman, im Mutterschutz, hatte privat ein Backup auf dem Heim-PC. *Daraus wurde der Film rekonstruiert.*
+
+<!--
+Diese Story zeigt zwei Backup-Wahrheiten:
+1. „Wir haben Backup" reicht nicht. Du musst regelmäßig PRÜFEN dass die Backups funktionieren (Restore-Tests).
+2. Backup auf einem System, das selbst betroffen sein kann, ist kein Backup. Galyn's Heim-PC war NICHT mit dem Pixar-Server verbunden — das hat den Film gerettet.
+
+Daraus folgt die 3-2-1-Regel.
+-->
+
+---
+
+# Die 3-2-1-Backup-Regel
+
+**3** Kopien deiner Daten
+
+**2** verschiedene **Medien** (z.B. SSD + HDD)
+
+**1** Kopie **off-site** (außerhalb deines Wohnorts)
+
+Beispiel:
+
+```
+Original  →  Foto-Library auf der MacBook-SSD
+Kopie 1   →  Time Machine auf externer HDD (zuhause)
+Kopie 2   →  Backblaze in der Cloud (off-site)
+```
+
+<!--
+Diese Regel löst drei Risiken:
+- Hardware-Crash: 3 Kopien, 2 davon auf anderen Geräten
+- Diebstahl/Brand: 1 Kopie off-site (Cloud oder bei Familie)
+- Ransomware: off-site-Kopie schreibgeschützt oder versioniert
+
+Klausurfähig: was ist die 3-2-1-Regel? Beispiele für jede Ebene.
+
+Cloud-Backup-Anbieter (off-site Option):
+- Backblaze: ~7 USD/Monat unlimited (Mac/Windows)
+- iCloud / Google One / OneDrive: integriert, aber begrenzt
+- Self-hosted: Synology / QNAP bei einer Person im Vertrauen
+-->
+
+---
+
+# Backup-Typen
+
+| Typ | Was wird gesichert | Restore-Aufwand | Speicher |
+|-----|---------------------|-----------------|----------|
+| **Full** | Alles, jedes Mal | klein (eine Datei) | viel (jedes Mal alles) |
+| **Incremental** | Nur Änderungen seit *letztem Backup* | groß (Kette aufrollen) | klein |
+| **Differential** | Alle Änderungen seit *letztem Full* | mittel | mittel |
+| **Snapshot** (APFS, ZFS) | Filesystem-Stand zu einem Zeitpunkt | sofort | Copy-on-Write |
+
+**In der Praxis:** Mix aus 1× Full pro Woche + Incremental täglich.
+
+<!--
+Time Machine (Mac) und Windows-Backup machen automatisch incremental + Snapshots im Hintergrund.
+
+Restic, BorgBackup (CLI): dedupliziertes incremental Backup mit Verschlüsselung. Ideal für Cloud-Off-site.
+
+Pointe: nicht überdenken. Time Machine + Backblaze reicht für 95 % der Studis.
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Sub-Sektion B: Schnittstellen — wie reisen die Bytes?
+
+<!--
+PIVOT. Speicher = wo. Jetzt: wie kommt's vom einen Speicher zum anderen?
+
+Drei zentrale Kategorien:
+1. USB-C (das Berührungs-Phänomen, der zentrale Aha)
+2. Video-Schnittstellen (HDMI, DisplayPort, Thunderbolt)
+3. Netzwerk (Ethernet, WiFi)
+-->
+
+---
+
+<!-- _class: lead -->
+
+# USB-C — und seine drei Achsen
+
+<!--
+Warum lädt mein Laptop am einen Port und nicht am anderen?
+Warum überträgt der eine Kabel 40 Gbit/s und der andere nur 480 Mbit/s?
+Warum erkennt der Monitor an USB-C kein Bild?
+
+Antwort: USB-C ist nicht eine Sache. Es ist drei.
+
+Diese Folie ist DER Aha-Moment des Kapitels.
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/usb-c-drei-achsen.png)
+
+<!--
+USB-C hat drei unabhängige Achsen, die alle zur „Verwirrung beim Stecker" beitragen:
+
+1. STECKER (Mechanik): die Form. Beidseitig steckbar, 24 Pins. Es gibt nur EINE Sorte USB-C.
+
+2. KABEL (was elektrisch durchgeht):
+   - Charge-only: nur Strom, ~5 W
+   - USB 2.0: 480 Mbit/s + 60 W (3 A)
+   - USB 3.2 Gen 2: 10 Gbit/s + 100 W
+   - Thunderbolt 4 / USB 4: 40 Gbit/s + 240 W (mit USB-PD 3.1)
+
+3. PROTOKOLL (was gesprochen wird):
+   - USB Power Delivery (Laden mit Verhandlung)
+   - USB 2.0 / 3.x / 4 (Datenübertragung)
+   - Thunderbolt 3 / 4 (Daten + Display tunneled)
+   - DisplayPort Alt Mode (Monitor anschließen)
+   - HDMI Alt Mode
+
+Konsequenz: wenn etwas nicht funktioniert, checke in dieser Reihenfolge:
+1. Stecker physisch okay? (USB-C, nicht Mini-USB)
+2. Kabel-Spec ausreichend? (auf der Verpackung steht meist die Klasse)
+3. Beide Geräte sprechen das gleiche Protokoll? (z.B. Thunderbolt-Hub mit USB-Mac → reduzierte Funktionen)
+-->
+
+---
+
+# HDMI — Video + Audio + Kopierschutz
+
+**High-Definition Multimedia Interface.** 2002. Standard für Heim-Elektronik.
+
+| Version | Bandbreite | Max. Video |
+|---------|-----------|-----------|
+| HDMI 1.4 | 10 Gbit/s | 4K @ 30 Hz |
+| HDMI 2.0 | 18 Gbit/s | 4K @ 60 Hz |
+| HDMI 2.1 | 48 Gbit/s | 8K @ 60 Hz oder 4K @ 120 Hz |
+
+**HDCP:** Kopierschutz, der „illegale" Aufnahmen verhindern soll. Manchmal die Ursache für „Bildschirm bleibt schwarz, wenn Netflix läuft."
+
+<!--
+HDMI ist der Standard im Heim-Bereich. PCs, TVs, Blu-ray-Player, Konsolen — alle haben HDMI.
+
+HDCP (High-bandwidth Digital Content Protection) ist eine Verschlüsselung der Übertragung. Wird gebrochen, wenn Geräte nicht „kompatibel" sind (z.B. Bild-Capture-Hardware).
+
+Studis-Erfahrung: AirPlay/Chromecast geht meist NICHT mit HDCP-Inhalten. „Ich kann meinen Bildschirm beamen, aber wenn ich Netflix öffne wird er schwarz."
+-->
+
+---
+
+# DisplayPort — HDMIs offenes Pendant
+
+**Open-Source-Industrie-Standard.** Hauptsächlich PC-Welt (Monitore).
+
+- Versionen 1.4 (32 Gbit/s) bis 2.1 (80 Gbit/s)
+- **MST (Multi-Stream Transport):** ein Kabel → mehrere Monitore
+- **Adaptive Sync:** flüssige Bildraten bei Gaming (FreeSync, G-Sync)
+
+In USB-C steckt fast immer ein **DisplayPort Alt Mode**, sodass dasselbe Kabel beides kann.
+
+<!--
+DisplayPort vs HDMI:
+- HDMI: konsumieren, TV-Welt, kostenpflichtige Lizenzen
+- DisplayPort: produzieren, PC-Welt, lizenzfrei
+
+Beide funktionieren technisch ähnlich. Im professionellen Bereich findet man eher DisplayPort, im Wohnzimmer eher HDMI.
+
+Konvertierung: HDMI ↔ DisplayPort geht mit Adapter (passiv oder aktiv je nach Richtung).
+-->
+
+---
+
+# Thunderbolt — der Tunnel für alles
+
+**Intel + Apple 2011, seit Version 3 (2015) auf USB-C-Stecker.**
+
+Spezifikation:
+- **Thunderbolt 3 / 4:** 40 Gbit/s. PCIe + DisplayPort + USB *gleichzeitig*.
+- **Thunderbolt 5** (2024): 80–120 Gbit/s.
+
+Anwendung: **externe GPU** (eGPU), 8K-Monitor, RAID-Array, ein Dock für alles.
+
+<!--
+Thunderbolt ist „USB-C auf Steroiden". Der Stecker ist gleich, aber das Protokoll tunnelt mehrere Datenströme parallel:
+- PCIe-Daten (externe GPU)
+- DisplayPort (Monitor)
+- USB (Maus, Tastatur, Audio)
+- Strom (bis 240 W)
+
+Hardware ist teurer (Thunderbolt-Controller). Kabel sind teurer (aktive Elektronik in den Steckern).
+
+Wer Thunderbolt nutzt: Mac-Nutzer, Video-Editor, eGPU-Gaming, Photo-Pro.
+
+Faustregel: Thunderbolt-Kabel = ~50€. Normal-USB-C-Kabel = ~10€.
+-->
+
+---
+
+# Ethernet vs. WiFi — Bandbreite + Latenz
+
+| | Ethernet (Kabel) | WiFi (Funk) |
+|--|------------------|-------------|
+| Bandbreite | 1–10 Gbit/s | 0,6–9,6 Gbit/s (WiFi 6E) |
+| Latenz | < 1 ms | 5–20 ms (variabel) |
+| Stabilität | konstant | abhängig von Umgebung |
+| Setup | Kabel ziehen | App, kein Kabel |
+| Sicherheit | physisch geschützt | Passwort, abhörbar |
+
+**Für Streaming:** WiFi reicht.
+**Für Gaming, Video-Call, Online-Code:** Ethernet besser (Latenz!).
+
+<!--
+Latenz-Unterschied ist der oft unterschätzte Faktor:
+- Online-Spiele: Ping muss < 50 ms bleiben. Ethernet: 5 ms. WiFi: oft 30-50 ms.
+- Video-Call: Ethernet besser, weil weniger Jitter (Variabilität in der Latenz).
+- Streaming: 5-10 Sek Buffer puffert alles weg → WiFi reicht.
+
+WiFi 6 / 6E (ax) bringt deutliche Verbesserung gegenüber WiFi 5 (ac), insbesondere bei vielen Geräten im selben Netz (Hörsaal, Stadion).
+
+5G im Mobilfunk: ~100 Mbit/s, Latenz ~30 ms. Ähnlich wie WiFi 5.
+-->
+
+---
+
+# Schnittstellen-Wahl-Matrix
+
+| Aufgabe | Beste Schnittstelle | Warum |
+|---------|---------------------|-------|
+| 4K-Monitor anschließen | **HDMI 2.0+** oder **DP 1.4+** | Bandbreite |
+| Online-Gaming | **Ethernet** | niedrige Latenz |
+| eGPU am Laptop | **Thunderbolt 3/4** | PCIe-Tunnel |
+| SD-Karte einlesen | **USB-A 3.0** oder **USB-C** | Kompatibilität |
+| Smartphone laden | **USB-C-PD** | Standard |
+| Heim-Streaming | **WiFi** oder **Ethernet** | reicht beides |
+| 4K-Stream mehrere Geräte | **Ethernet** | Stabilität |
+
+<!--
+Klausurfähig: gegeben Anwendungsfall, welche Schnittstelle und warum?
+
+Trick: warum nicht immer Thunderbolt? → Teurer Kabel, teurere Hardware. Nicht jedes Endgerät unterstützt es.
+-->
+
+---
+
+<!-- _class: aufgabe -->
+
+# Selbstlernen — zwei Übungen
+
+**1. Backup-Konzept aufschreiben**
+Inventarisiert eure Geräte: Wo wohnen welche Daten? Schreibt euer 3-2-1-Backup für eure eigene Foto-Library auf. Welches Off-site? Welche zweite Kopie?
+
+**2. USB-C-Kabel-Check**
+Holt eure USB-C-Kabel raus. Was steht drauf? Was kann jedes Kabel laut Verpackung? Habt ihr ein „Charge-only"-Kabel, ohne es zu wissen?
+
+<!--
+Pädagogisch: Studis sollen ihre eigenen Geräte/Kabel inventarisieren.
+
+Übung 1: das 3-2-1-Konzept zwingt zur Aufschriftnahme. Realistisch: die meisten Studis haben Original + iCloud, aber kein zweites lokales Backup. Diskussion: wer hat schon mal eine Festplatte verloren? Worauf war drauf?
+
+Übung 2: USB-C-Kabel haben oft kleine Aufdrucke (z.B. „USB 2.0 + 60 W" oder „USB4 240W"). Manchmal nichts — dann ist es typisch ein einfaches Charge-Kabel.
+
+Tipp: Apple-Kabel haben Marker auf den Steckern (Symbole). Aldi-Kabel oft nicht.
+-->
+
+---
+
+# Zusammenfassung
+
+**Speicher = wo wohnen die Bytes:** HDD-Mechanik vs SSD-Flash. Tradeoff Geschwindigkeit ↔ Preis/TB. Filesystem als Buchhaltung. Backup als 3-2-1.
+
+**Schnittstellen = wie reisen sie:** USB-C-Stecker täuscht — drei Achsen (Stecker · Kabel · Protokoll). HDMI/DP/TB für Video. Ethernet für Latenz, WiFi für Bequemlichkeit.
+
+**Der gemeinsame Hebel:** Engpass identifizieren, *bevor* man Hardware kauft.
+
+→ **In Kap 5** schauen wir uns an, was eine Datei *unterwegs* mitführt — und was sie *verrät*.
+
+<!--
+Recap:
+
+Speicher:
+- HDD: Magnet, mechanisch, billig, langsam
+- SSD: Flash, kein Mechanik, teuer, schnell
+- Wann was: OS auf SSD, Archiv auf HDD, Backup auf beides
+- Filesystem: FAT32 (4 GB Limit), exFAT (universal), NTFS (Win), APFS (Mac), ext4 (Linux)
+- Backup: 3-2-1-Regel. Pixar-Story als Warnung.
+
+Schnittstellen:
+- USB-C: drei Achsen — Stecker, Kabel, Protokoll. Wenn etwas nicht geht, eine davon checken.
+- Video: HDMI (TV-Welt, HDCP), DisplayPort (PC-Welt, offen), Thunderbolt (Tunnel für alles)
+- Netzwerk: Ethernet (Latenz, Stabilität) vs WiFi (Mobilität)
+
+Großes Thema: Speicher + Schnittstelle = ein Engpass. Wo Daten wohnen, bestimmt wie schnell sie reisen können.
+
+Anschluss zu Kap 5: in dieser Stunde haben wir gesehen, wo Bytes leben und wie sie reisen. Nächste Stunde: was nehmen sie mit, wenn sie reisen? EXIF, ID3, PDF-Metadaten — die unsichtbare Gepäcktasche jeder Datei.
+-->

slides/223015b-2026/05-distribution-metadaten.md

@@ -0,0 +1,616 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
+title: Distribution und Metadaten
+---
+
+<style>
+:root {
+  --color-foreground: #1a1a2e;
+  --color-highlight: #1e5f8a;
+  --color-dimmed: #4a4a6a;
+}
+section.invert { --color-foreground: #fff; }
+section { font-size: 1.7rem; }
+h1 { color: #1e5f8a; }
+section.invert h1 { color: #fff; }
+h2 { color: #1f2937; }
+pre {
+  background: #0f0f23;
+  color: #5fb3e4;
+  border-radius: 8px;
+  border-left: 3px solid #1e5f8a;
+}
+pre code { background: transparent; color: inherit; }
+code {
+  background: #0f0f23;
+  padding: 0.15em 0.4em;
+  border-radius: 4px;
+  font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
+}
+section code:not(.hljs) { color: #5fb3e4 !important; }
+section code.hljs { color: #f8f8f8 !important; }
+a { color: var(--color-highlight); }
+section.klausur {
+  background: repeating-linear-gradient(
+    135deg,
+    #e3f2fd,
+    #e3f2fd 40px,
+    #fff 40px,
+    #fff 80px
+  ) !important;
+}
+@media print {
+  section.klausur { background: #e3f2fd !important; }
+}
+section.aufgabe { background: #e3f2fd !important; }
+section.aufgabe footer { display: none; }
+section.erklaerung :not(header),
+section.erklaerung :not(footer) { font-size: 1.1rem; }
+section.erklaerung h1 { font-size: 1.5rem; color: #1e5f8a; margin-bottom: 0.3rem; }
+section.erklaerung ul, section.erklaerung ol { font-size: 1.0rem; line-height: 1.4; }
+section.erklaerung p { font-size: 1.0rem; line-height: 1.4; }
+section.erklaerung table { font-size: 0.9rem; }
+</style>
+
+<!-- _class: lead -->
+
+# Kapitel 5
+## Distribution und Metadaten
+
+<!--
+Eine Stunde, eine Frage: *Wie kommen die Bytes von der Quelle zur Endnutzerin — und was verraten sie auf dem Weg?*
+
+Anschluss an Kap 4: dort haben wir gesehen, wo Bytes wohnen und über welche Schnittstellen sie reisen. Jetzt: WIE reisen sie (Distribution) und WAS verraten sie dabei (Metadaten)?
+
+Bogen:
+1. CDN-Prinzip (warum Netflix sofort startet)
+2. REST-APIs (wie Apps Daten austauschen)
+3. PIVOT zu Metadaten
+4. EXIF, ID3, PDF-Metadaten (was Dateien über sich verraten)
+5. Vendor-Lockin (Adobe, Apple)
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/demos/kap05-eroeffner.png)
+
+<!--
+Eine Datei reist + erzählt. Smartphone-Foto Stuttgart → Tokyo zeigt drei Schichten:
+
+- INHALT (links blau): das visuelle Foto, HEIC 4032×3024, 3,2 MB. Was der Empfänger sieht.
+- GEPÄCK (rechts lila): die EXIF-Daten, die mitkommen — Kamera iPhone 15 Pro, Zeitstempel, GPS-Koordinaten (pink: Stuttgart, Königstraße), iOS-Version, Farbprofil. Was die Datei über sich weiß.
+- WEG (unten orange): Route Stuttgart → DNS → TLS 1.3 → CDN-Edge Tokyo → Tokyo. HTTP-Headers: 200 OK, RTT 47 ms, cache HIT bei Edge tok-7.
+
+Eine Datei = Inhalt + Gepäck + Weg. Drei Schichten, eine Datei.
+
+In dieser Stunde gehen wir durch alle drei: wie reist die Datei (CDN, REST), was bringt sie mit (EXIF, ID3, PDF-Meta), und wann ist das ein Privacy-Problem (McAfee, Tony Blair).
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Sub-Sektion A: Distribution — wie reist die Datei?
+
+<!--
+Reihenfolge:
+1. CDN-Prinzip (Netflix-Beispiel)
+2. REST-APIs (Wetter-App fragt Daten ab)
+3. JSON als Datenformat
+-->
+
+---
+
+# CDN — Content Delivery Network
+
+**Idee:** Daten dort speichern, wo die Nutzer:innen sind.
+
+Statt von **einem zentralen Server** in Kalifornien wird die Datei von einem **Edge-Server** in eurer Nähe geliefert.
+
+Beispiel: Netflix nutzt **Open Connect** — eigene Server in 1.000+ ISP-Rechenzentren weltweit. ~15 % des globalen Internet-Verkehrs.
+
+**Latenz** von Stuttgart zu Stuttgart: ~5 ms.
+**Latenz** von Stuttgart nach Kalifornien: ~150 ms.
+
+<!--
+CDN-Logik:
+- Origin Server: das echte Heimatverzeichnis der Datei (z.B. Netflix-Headquarters)
+- Edge Server (PoPs = Points of Presence): Kopien, geographisch verteilt
+- Wenn ein User eine Datei anfordert: DNS leitet zur nächsten Edge-Kopie
+- Edge prüft Cache: HIT → liefert sofort. MISS → holt von Origin, cached für nächste Anfrage
+
+Bekannte CDNs:
+- Cloudflare: 300+ Standorte, viele freie Websites
+- AWS CloudFront: Amazon
+- Akamai: ältester großer CDN
+- Netflix Open Connect: eigene Hardware in ISP-Rechenzentren
+
+Konsequenz: ohne CDN würde Netflix einen Server in CA haben, jeder europäische Stream müsste den Atlantik queren. Mit CDN: lokal in München, Stuttgart, Hamburg.
+-->
+
+---
+
+# Wie sieht das im DevTools aus?
+
+DevTools (F12) → Tab **Network** → reload eine Seite
+
+Was ihr seht:
+- **DNS-Lookup:** ~30 ms (oder gecacht: 0)
+- **TLS-Handshake:** ~50 ms
+- **TTFB** (Time to First Byte): ~80 ms wenn CDN, sonst 300+
+- **Cache-Status:** Header `x-cache: HIT` oder `cf-cache-status: HIT`
+
+→ **Selbstlernen:** öffnet eine populäre Seite, schaut die Response-Header an.
+
+<!--
+DevTools-Demo live in der Vorlesung:
+1. Eine bekannte Seite öffnen (z.B. github.com)
+2. F12, Tab Network
+3. Reload
+4. Eine Request anklicken → Headers
+5. Suche nach `x-cache`, `cf-cache-status`, `age` Headers
+
+Konsequenz für Studis: das ist nicht Magic — man kann es sehen.
+-->
+
+---
+
+<!-- _class: lead -->
+
+# REST-APIs — wie Apps Daten austauschen
+
+<!--
+API = Application Programming Interface = "Stelle, an der eine App mit einer anderen App redet".
+
+Beispiel:
+- Wetter-App auf dem Handy braucht aktuelle Daten
+- Stellt eine HTTP-Anfrage an die Wetter-API (z.B. https://api.wetter.com/aktuell?ort=stuttgart)
+- API antwortet mit JSON-Daten
+- App rendert die Daten als hübsche Oberfläche
+
+Im Hintergrund läuft das überall: Instagram (Daten von Server), Spotify (Tracks), Banking-Apps.
+
+Heute: REST. Das ist DAS Standardparadigma.
+-->
+
+---
+
+# Was ist eine API?
+
+**Application Programming Interface.** Eine standardisierte Stelle, an der zwei Programme Daten austauschen.
+
+```
+            HTTP-Request (GET /aktuell?ort=stuttgart)
+   ┌─────────────────────────────────────────────────┐
+   │                                                 ▼
+[App auf dem Handy]                       [API-Server]
+   ▲                                                 │
+   │           JSON-Response                         │
+   └─────────────────────────────────────────────────┘
+        { "temperatur": 14, "regen": false, ... }
+```
+
+**Beispiele:** Wetter, Maps, Banking, Twitter, jede Spotify-Anfrage.
+
+<!--
+APIs sind die Klebstoffschicht zwischen Anwendung und Daten.
+
+Frontend (App, Website): rendert die Daten
+Backend (Server): hält die Daten, beantwortet API-Anfragen
+
+REST-Konvention: jede Ressource hat eine URL. Aktion drückt sich in der HTTP-Methode aus (GET = lesen, POST = neu erstellen, PUT = updaten, DELETE = löschen).
+
+Konsistente Methoden + URLs → REST = "Representational State Transfer".
+-->
+
+---
+
+# REST: GET · POST · PUT · DELETE
+
+| Methode | Was tut sie | URL-Beispiel |
+|---------|-------------|--------------|
+| **GET** | lesen | `GET /users/42` (User mit ID 42 abfragen) |
+| **POST** | neu erstellen | `POST /users` mit Daten als Body |
+| **PUT** | überschreiben | `PUT /users/42` mit kompletten neuen Daten |
+| **PATCH** | teilweise ändern | `PATCH /users/42` mit Änderungen |
+| **DELETE** | löschen | `DELETE /users/42` |
+
+CRUD = **C**reate · **R**ead · **U**pdate · **D**elete.
+
+<!--
+Klausurfähig: welche HTTP-Methode für welche Operation?
+
+Trick-Frage: was ist der Unterschied zwischen PUT und PATCH?
+- PUT: ersetzt komplett. User wird kompletter neu gesetzt.
+- PATCH: ändert nur die mitgegebenen Felder. Rest bleibt.
+
+In der Praxis nehmen viele APIs PUT auch für partielle Updates — kein RFC-konforme Strenge.
+
+Werkzeuge zum Testen: curl, Postman, Hoppscotch (browser-basiert), VS-Code REST-Client-Plugin.
+-->
+
+---
+
+<!-- _class: aufgabe -->
+
+# Selbstlernen — eine API im Browser anfragen
+
+JSONPlaceholder ist eine kostenlose Fake-API zum Üben:
+
+```
+https://jsonplaceholder.typicode.com/users
+https://jsonplaceholder.typicode.com/posts/1
+https://jsonplaceholder.typicode.com/posts?userId=2
+```
+
+**Aufgabe:** Im Browser öffnen. Was kommt zurück? Welcher Content-Type-Header?
+
+Bonus: mit `curl https://api.github.com/users/torvalds` in der Konsole.
+
+<!--
+JSONPlaceholder = beste Spielwiese für API-Anfänger. Liefert fiktive Daten zu Users, Posts, Comments, Albums, Photos, Todos.
+
+Live-Demo im Hörsaal:
+1. URL in den Browser-Adress-Bar eingeben
+2. JSON-Antwort sehen (Firefox/Chrome rendern es hübsch)
+3. F12, Network: Headers anschauen — content-type: application/json
+4. Curl in Terminal: ähnlich, ohne Browser-Pretty-Print
+
+Daraus folgt: hinter jeder Web-App stecken API-Anfragen wie diese. Manchmal komplexer (Authentifizierung), aber im Kern dasselbe.
+-->
+
+---
+
+# JSON — das Standard-Datenformat
+
+```json
+{
+  "name": "Torvalds",
+  "alter": 56,
+  "projekte": [
+    { "name": "Linux", "stars": 180000 },
+    { "name": "Git",   "stars": 50000 }
+  ],
+  "aktiv": true
+}
+```
+
+- **Objekte** (`{ ... }`), **Listen** (`[ ... ]`), **Strings** (`"..."`), **Zahlen**, `true`/`false`, `null`
+- Universell: jede Programmiersprache hat JSON-Support
+- Lesbar: Mensch + Maschine
+
+<!--
+JSON = JavaScript Object Notation. Erfunden 2001 von Douglas Crockford.
+
+Hat XML als Standard-Datenformat im Web fast vollständig abgelöst:
+- Weniger Boilerplate als XML
+- Direkt von JavaScript-Engines parsbar
+- Streng aber einfach
+
+Heute praktisch jede REST-API liefert JSON. Manchmal noch XML, selten YAML oder Protobuf.
+
+Sub-formate: JSON5 (mit Kommentaren), JSONC (mit Trailing Commas), JSON-LD (für Schema.org).
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Sub-Sektion B: Metadaten — was Dateien über sich verraten
+
+<!--
+PIVOT. Wir haben gesehen, wie Daten reisen (CDN, REST). Jetzt: WAS reist mit?
+
+Die meisten Studis denken: "Eine JPEG-Datei ist ein Bild." Stimmt nur teilweise.
+
+Tatsächlich enthält jede JPEG-Datei:
+- Das Bild selbst (visueller Inhalt)
+- EXIF-Metadaten: Kamera, Zeit, GPS, Software, Belichtung, Linse
+- Diese Metadaten reisen mit, wenn die Datei verteilt wird
+
+Konsequenz: wer ein Foto verschickt, verschickt oft viel mehr als das Bild. Das ist die "Gepäck"-Seite des Bogens.
+-->
+
+---
+
+# EXIF — was ein Foto über sich verrät
+
+**Exchangeable Image File Format.** Standard seit 1995, in JPEG/HEIC/TIFF.
+
+Typische EXIF-Daten in einem Smartphone-Foto:
+
+| Feld | Beispiel |
+|------|----------|
+| Kamera | Apple iPhone 15 Pro · 24 mm · ƒ/1.78 |
+| Belichtung | 1/250 s · ISO 100 |
+| **Aufnahme-Zeitstempel** | 2026-04-12 · 18:47:12 +02:00 |
+| **GPS-Koordinaten** | 48.7847°N 9.1825°E (Stuttgart, Königstraße) |
+| Software | iOS 18.4.1 · Photoshop CC 2025 |
+
+<!--
+EXIF macht Fotos detektiv-tauglich.
+
+Die GPS-Information ist die kritischste. Smartphones (auch Drohnen-Kameras) speichern standardmäßig die GPS-Koordinaten in jedem Foto.
+
+Auch dabei: Datum/Uhrzeit auf die Sekunde genau, Software-Version (kann bei einem Hack als Forensik dienen).
+
+Tools zum Auslesen:
+- `exiftool` (CLI, perl)
+- ExifTool GUI (mehrere Implementierungen)
+- Browser: exifdata.com, jeffrey.exif
+
+Demo im Hörsaal: ein Foto vom Smartphone exportieren, exiftool drauf, GPS-Koordinaten in Google Maps eintippen.
+-->
+
+---
+
+# Der John-McAfee-GPS-Fall
+
+**Dezember 2012.** John McAfee (Antivirus-Erfinder) flieht aus Belize, wo er als Mordverdächtiger gesucht wird.
+
+**Vice Magazine** veröffentlicht ein Interview mit einem Foto: McAfee im T-Shirt, scheinbar in einer geheimen Location.
+
+**EXIF-Koordinaten im Foto:** `15.6541° N, 88.9939° W` → **Hotel Nana Lodge, Guatemala.** Bekannt.
+
+McAfee wird 36 Stunden später festgenommen.
+
+<!--
+Diese Story zeigt:
+1. Smartphones speichern GPS-Daten standardmäßig
+2. Online-Plattformen STRIPPEN diese Metadaten oft NICHT (Vice damals nicht)
+3. Wer ein Bild mit GPS hochlädt, kann seinen Aufenthaltsort verraten
+
+McAfee hat sich danach öffentlich darüber lustig gemacht ("yes that was the actual location"), aber der Fall wurde zum Lehrbuch-Beispiel für EXIF-Privacy.
+
+2026: die meisten großen Plattformen strippen EXIF (Twitter/X, Instagram, WhatsApp), aber:
+- WhatsApp-Originaldatei via "Dokument" senden: behält EXIF
+- E-Mail-Anhang: behält EXIF
+- Direkt-Upload zu Drittpartei-Webseiten: oft mit EXIF
+-->
+
+---
+
+# Social-Media-EXIF-Stripping
+
+| Plattform | Stripped? | Vorbehalt |
+|-----------|-----------|-----------|
+| **Instagram** | Ja | neu komprimiert |
+| **Facebook · iMessage** | Ja | — |
+| **Twitter / X** | Ja | nicht bei Direktnachricht |
+| **WhatsApp** | Ja als Foto | NEIN bei „Dokument senden" |
+| **E-Mail · Slack · Discord** | Nein | Original bleibt |
+
+*Plattform-Upload = meist Stripped. Datei direkt teilen = unsicher.*
+
+<!--
+Diese Tabelle ist nicht klausurrelevant, aber lebensweltlich wichtig.
+
+Sub-Frage: warum strippen manche Plattformen, andere nicht?
+- Social: re-komprimieren sowieso → verlieren EXIF dabei
+- Messenger: oft komplett re-komprimieren (besseres Streaming)
+- E-Mail/Dokumenten-Sharing: schickt Original-Bytes durch
+
+Privacy-Tipp: Geo-Tagging in Smartphone-Settings ausschalten, wenn ihr Fotos teilen wollt. Oder mit Apps wie "ExifEraser" reinigen.
+-->
+
+---
+
+# ID3 — Metadaten in MP3-Dateien
+
+```
+ID3v2.4 Header:
+Titel:    "Hotel California"
+Artist:   "Eagles"
+Album:    "Hotel California"
+Jahr:     1976
+Genre:    Rock
+Cover-Art: [JPEG embedded, 250 × 250 px]
+```
+
+Plus: Lyrics, Komponist, Track-Nr, ReplayGain, manchmal **ganze Lyric-Videos als Embedded-Bilder.**
+
+→ Daher ist eine 4-Min MP3 manchmal **5 MB groß** statt 3 MB.
+
+<!--
+ID3-Tags = Metadaten-Standard für MP3 seit 1996.
+
+Versionen:
+- ID3v1: 128 Byte am Ende. Sehr begrenzt.
+- ID3v2: variabel große Tags am Anfang. Standard heute.
+
+Datenbanken:
+- MusicBrainz: offene Musik-DB, vollständige Metadaten
+- AcoustID: erkennt Songs anhand Audio-Fingerprint
+- LastFM: scrobbling + Metadaten
+
+Verwendet von: iTunes, Spotify, jeder Audio-Player.
+-->
+
+---
+
+# Der Tony-Blair-Fall (PDF-Metadaten)
+
+**Februar 2003.** Britische Regierung veröffentlicht PDF-Dokument zur Begründung des Irakkriegs.
+
+Ein britischer Akademiker findet im **PDF-Revisionsverlauf**: das Dokument wurde aus einer studentischen Doktorarbeit von 1991 kopiert.
+
+**Plagiats-Skandal.** Plus Hinweise auf welche Mitarbeiter:innen welche Sätze überarbeitet hatten.
+
+→ **PDF-Metadaten** verraten oft mehr als der Inhalt.
+
+<!--
+PDF-Metadaten:
+- Autor, Erstell-Zeit, letzte Änderung
+- Software (Microsoft Word, LibreOffice, Adobe Acrobat)
+- Manchmal Revision History
+- Manchmal versteckter Text (z.B. weiße Schrift auf weißem Hintergrund)
+
+Sicherheitsrelevant:
+- Schwärzungen werden manchmal nur als schwarzer Layer DRÜBER gelegt — Text bleibt extrahierbar
+- NSA-Dokumente, FBI-Reports, US-Gerichtsdokumente: viele berühmte Beispiele für gescheiterte Schwärzungen
+- Auch bei Microsoft Word: "Schwärze" via schwarzes Highlight → Text bleibt im Stream lesbar
+
+Klausurfähig: ein Beispiel für PDF-Metadaten-Privacy-Verstoß nennen + Begründung.
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Vendor-Lockin — wenn das Format zum Käfig wird
+
+<!--
+Manche Formate sind absichtlich proprietär. Hersteller behält die Spezifikation für sich.
+
+Konsequenz:
+- Nur deren Software kann die Datei voll öffnen
+- Wer die Software lizenziert (oder ein Abo zahlt), kann arbeiten
+- Wer aus dem Ökosystem aussteigt, verliert evtl. die Daten
+
+Klassiker:
+- Adobe Photoshop PSD
+- Adobe InDesign INDD
+- Apple Pages, Numbers, Keynote
+- Microsoft Word DOC (alt, vor DOCX)
+-->
+
+---
+
+# Beispiele: proprietäre Formate
+
+| Format | Hersteller | Was nervt |
+|--------|-----------|-----------|
+| **PSD** (Photoshop) | Adobe | nur Photoshop liest Layer-Daten voll. Abo-Pflicht. |
+| **INDD** (InDesign) | Adobe | gleiches Problem |
+| **.pages** | Apple | nur in Apple-Apps voll editierbar |
+| **.numbers** | Apple | gleiches |
+| **DOC** (alt) | Microsoft | bis 2007 closed-source |
+| **PSP, AI** | Adobe | proprietäre Editor-Formate |
+
+→ **Offene Alternativen:** PNG, TIFF, ODT (LibreOffice), HTML/Markdown, SVG.
+
+<!--
+Vendor-Lockin-Logik:
+- Hersteller hat hohe Marktmacht
+- Hersteller-eigenes Format ist „besser" als offene Standards (richtiger oder gefühlt)
+- Migrations-Kosten sind hoch → User bleibt
+- Lock-in als Geschäftsmodell
+
+Beispiel Adobe:
+- Photoshop ist standardmäßig in der Industrie
+- PSD ist DAS Format für Designer
+- Abonnement Creative Cloud: ~30€/Monat
+- Wer Photoshop kündigt: kann PSD-Dateien nicht mehr voll editieren
+
+Gegenstrategien:
+- Open-Source-Tools: GIMP, Inkscape, LibreOffice
+- Export in offene Formate: PSD → TIFF (verlustlos) für Archiv
+- "Open Source Forever": Wikipedia, Sci-Hub, IPFS
+-->
+
+---
+
+# Vendor-Lockin als Risiko
+
+**Szenario:** Du arbeitest 5 Jahre lang mit Adobe InDesign. Dann steigt der Abo-Preis um 200 % oder Adobe ändert das Format.
+
+**Konsequenz:**
+- Bestehende INDD-Dateien öffnen sich noch — aber nur in Adobe-Produkten
+- Migration zu Affinity Publisher / Scribus: Daten müssen konvertiert werden, manche Details gehen verloren
+- Bei einigen Formaten gibt es keine Konverter — Vendor entscheidet komplett
+
+**Schutz:** Wichtige Daten in **offenen Formaten** parallel speichern.
+
+<!--
+Klausurfähig: was ist Vendor-Lockin? Beispiel + warum problematisch?
+
+Diskussion: Open-Source-Tools sind oft "fast so gut" — manchmal sogar besser. Aber Industrie-Standards halten den Status quo.
+
+Heimlich-Lockin: auch "Bug-für-Bug-Kompatibilität". Microsoft Office hat sich in den 90ern als Standard durchgesetzt, weil Konkurrenz-Office-Suites die exakten Bugs/Quirks nicht reproduzieren konnten.
+-->
+
+---
+
+<!-- _class: aufgabe -->
+
+# Selbstlernen — exiftool auf eigene Fotos
+
+**Installation:**
+- macOS: `brew install exiftool`
+- Linux: `sudo apt install libimage-exiftool-perl`
+- Windows: [exiftool.org](https://exiftool.org)
+
+**Aufgabe:**
+```sh
+exiftool DEIN_FOTO.jpg
+```
+
+Schaut, was alles drin steht. **Findet ihr GPS-Koordinaten?** Bonus: in [maps.google.com](https://maps.google.com) eintippen.
+
+**Optional:** EXIF entfernen mit `exiftool -all= DEIN_FOTO.jpg`.
+
+<!--
+Diese Übung ist die zentrale Aha-Erkenntnis für Studis: ihr eigenes Smartphone-Foto verrät GPS-Koordinaten.
+
+Erwartung:
+- iPhone-Aufnahme: EXIF mit GPS, Kamera-Modell, Linsen-Daten
+- Foto von Android: ähnlich
+- Foto von einem Web-Download: oft schon EXIF-stripped
+
+Diskussion: was bedeutet das für: einen unbekannten Hostessen-Service, ein Anonymous-Tweet mit Foto, ein Verkaufs-Foto auf eBay mit dem Foto vom Wohnzimmer?
+
+Privacy-Empfehlung: Geo-Tagging im Smartphone abschalten ODER vor Upload mit exiftool/ExifEraser/Squoosh.app reinigen.
+-->
+
+---
+
+# Zusammenfassung
+
+**Distribution — wie reist die Datei:**
+CDN bringt sie zur Edge. REST-API liefert Daten on-demand. JSON ist die Sprache.
+
+**Metadaten — was bringt die Datei mit:**
+EXIF (Fotos), ID3 (Audio), PDF-Meta (Dokumente). GPS + Zeitstempel + Software.
+
+**Privacy:** EXIF kann Aufenthaltsort verraten. PDF kann Revision-History verraten.
+
+**Vendor-Lockin:** proprietäre Formate als Käfig. Offene Alternativen wo möglich.
+
+→ Eine Datei ist nie nur Inhalt. **Inhalt + Gepäck + Weg.**
+
+<!--
+Recap des Kapitels — und implizit auch des ganzen Kurses:
+
+Distribution (Weg):
+- CDN: Daten dort speichern wo Nutzer sind
+- REST: standardisierte API über HTTP
+- JSON: das Datenformat
+
+Metadaten (Gepäck):
+- EXIF: was Fotos verraten (GPS, Kamera, Zeit)
+- ID3: was MP3 verraten (Artist, Titel, Album)
+- PDF-Meta: Revision History, Autor, Software
+- Privacy-Cases: McAfee (GPS), Tony Blair (Revision History)
+
+Vendor-Lockin:
+- Proprietäre Formate als Geschäftsmodell
+- Adobe, Apple, Microsoft
+- Schutz: offene Formate parallel
+
+Synthese: Eine Datei = Inhalt + Gepäck + Weg.
+- Inhalt: was wir sehen/hören
+- Gepäck: was die Datei über sich weiß (Metadaten)
+- Weg: wie sie reist (CDN, Protokolle)
+
+Alle drei sind Teil der Datei. Studis können jetzt eine JPEG/MP3/MP4/PDF als das verstehen, was sie wirklich ist: nicht ein Bild oder Song oder Dokument, sondern ein strukturierter Byte-Stream mit Inhalt + Metadaten + Distribution-Pfad.
+
+Damit endet der Kurs. Die Klausur wird zeigen, was hängen geblieben ist.
+-->

slides/223015b-2026/assets/demos/ascii-table.html

@@ -0,0 +1,311 @@
+<!DOCTYPE html>
+<html lang="de">
+<head>
+<meta charset="UTF-8">
+<title>ASCII-Tabelle</title>
+<style>
+  :root {
+    --hl: #1e5f8a;
+    --dark: #1a1a2e;
+    --muted: #6b7280;
+    --border: #cbd5e1;
+    --bg-soft: #f8fafc;
+    --c-ctrl: #e5e7eb;     /* control */
+    --c-ctrl-text: #4b5563;
+    --c-space: #fef3c7;    /* space */
+    --c-punct: #ddd6fe;    /* punctuation */
+    --c-digit: #bfdbfe;    /* digits */
+    --c-upper: #bbf7d0;    /* uppercase */
+    --c-lower: #fed7aa;    /* lowercase */
+    --c-del:   #fecaca;    /* DEL */
+  }
+  html, body { margin: 0; padding: 0; background: #fff; font-family: system-ui, -apple-system, sans-serif; color: var(--dark); }
+  body { padding: 18px 24px; }
+  h1 { text-align: center; margin: 0 0 2px; font-size: 1.5rem; }
+  .sub { text-align: center; color: var(--muted); margin-bottom: 14px; font-size: 0.9rem; }
+  .sub strong { color: var(--dark); }
+
+  .table-wrap { display: flex; justify-content: center; }
+
+  table.ascii {
+    border-collapse: separate;
+    border-spacing: 3px;
+    font-family: ui-monospace, "SF Mono", Menlo, monospace;
+  }
+  table.ascii th, table.ascii td {
+    width: 68px;
+    height: 60px;
+    padding: 0;
+    text-align: center;
+    vertical-align: middle;
+    border-radius: 5px;
+  }
+  table.ascii th {
+    background: var(--dark); color: #fff;
+    font-size: 0.78rem;
+    letter-spacing: 0.05em;
+    font-weight: 700;
+    width: 56px;
+    height: 36px;
+  }
+  table.ascii th.row { width: 64px; }
+  table.ascii th .b { display: block; font-size: 0.68rem; opacity: 0.7; font-weight: 400; margin-top: 2px; letter-spacing: 0.04em; }
+
+  table.ascii td {
+    border: 1px solid var(--border);
+    position: relative;
+  }
+  td .hex { position: absolute; top: 3px; left: 5px; font-size: 0.62rem; color: var(--muted); font-weight: 700; }
+  td .dec { position: absolute; bottom: 3px; right: 5px; font-size: 0.62rem; color: var(--muted); font-weight: 400; }
+  td .ch { font-size: 1.45rem; font-weight: 700; line-height: 1; }
+  td.ctrl .ch { font-size: 0.82rem; font-weight: 700; }
+  td.ctrl .ch small { display: block; font-size: 0.6rem; font-weight: 400; color: var(--muted); margin-top: 2px; letter-spacing: 0; }
+
+  td.ctrl  { background: var(--c-ctrl); color: var(--c-ctrl-text); }
+  td.space { background: var(--c-space); }
+  td.punct { background: var(--c-punct); }
+  td.digit { background: var(--c-digit); }
+  td.upper { background: var(--c-upper); }
+  td.lower { background: var(--c-lower); }
+  td.del   { background: var(--c-del); color: var(--c-ctrl-text); }
+
+  .legend {
+    margin: 14px auto 0;
+    display: flex; gap: 14px; justify-content: center; flex-wrap: wrap;
+    font-size: 0.85rem;
+  }
+  .legend .item { display: flex; align-items: center; gap: 6px; padding: 4px 10px; border-radius: 4px; border: 1px solid var(--border); }
+  .legend .swatch { width: 14px; height: 14px; border-radius: 3px; border: 1px solid var(--border); }
+  .legend .swatch.ctrl  { background: var(--c-ctrl); }
+  .legend .swatch.space { background: var(--c-space); }
+  .legend .swatch.punct { background: var(--c-punct); }
+  .legend .swatch.digit { background: var(--c-digit); }
+  .legend .swatch.upper { background: var(--c-upper); }
+  .legend .swatch.lower { background: var(--c-lower); }
+  .legend .swatch.del   { background: var(--c-del); }
+
+  .meta-row {
+    margin-top: 10px;
+    display: flex; gap: 18px; justify-content: center;
+    font-size: 0.85rem; color: var(--muted);
+  }
+  .meta-row strong { color: var(--dark); }
+  .meta-row code { background: var(--dark); color: #f8f8f8; padding: 1px 6px; border-radius: 3px; font-family: ui-monospace, monospace; }
+</style>
+</head>
+<body>
+  <h1>ASCII-Tabelle (1963) · 7 Bit · 128 Zeichen</h1>
+  <div class="sub">Spalte = High-Nibble (Hex 0–7) · Zeile = Low-Nibble (Hex 0–F) · <strong>Hex</strong> oben, <strong>Dezimal</strong> unten</div>
+
+  <div class="table-wrap">
+  <table class="ascii">
+    <thead>
+      <tr>
+        <th class="row">↓ Low<br>→ High</th>
+        <th>0<span class="b">0000</span></th>
+        <th>1<span class="b">0001</span></th>
+        <th>2<span class="b">0010</span></th>
+        <th>3<span class="b">0011</span></th>
+        <th>4<span class="b">0100</span></th>
+        <th>5<span class="b">0101</span></th>
+        <th>6<span class="b">0110</span></th>
+        <th>7<span class="b">0111</span></th>
+      </tr>
+    </thead>
+    <tbody>
+      <tr>
+        <th class="row">0<span class="b">0000</span></th>
+        <td class="ctrl"><span class="hex">00</span><span class="ch">NUL<small>null</small></span><span class="dec">0</span></td>
+        <td class="ctrl"><span class="hex">10</span><span class="ch">DLE<small>data link esc</small></span><span class="dec">16</span></td>
+        <td class="space"><span class="hex">20</span><span class="ch">SP<small>space</small></span><span class="dec">32</span></td>
+        <td class="digit"><span class="hex">30</span><span class="ch">0</span><span class="dec">48</span></td>
+        <td class="punct"><span class="hex">40</span><span class="ch">@</span><span class="dec">64</span></td>
+        <td class="upper"><span class="hex">50</span><span class="ch">P</span><span class="dec">80</span></td>
+        <td class="punct"><span class="hex">60</span><span class="ch">`</span><span class="dec">96</span></td>
+        <td class="lower"><span class="hex">70</span><span class="ch">p</span><span class="dec">112</span></td>
+      </tr>
+      <tr>
+        <th class="row">1<span class="b">0001</span></th>
+        <td class="ctrl"><span class="hex">01</span><span class="ch">SOH<small>start hdr</small></span><span class="dec">1</span></td>
+        <td class="ctrl"><span class="hex">11</span><span class="ch">DC1<small>XON</small></span><span class="dec">17</span></td>
+        <td class="punct"><span class="hex">21</span><span class="ch">!</span><span class="dec">33</span></td>
+        <td class="digit"><span class="hex">31</span><span class="ch">1</span><span class="dec">49</span></td>
+        <td class="upper"><span class="hex">41</span><span class="ch">A</span><span class="dec">65</span></td>
+        <td class="upper"><span class="hex">51</span><span class="ch">Q</span><span class="dec">81</span></td>
+        <td class="lower"><span class="hex">61</span><span class="ch">a</span><span class="dec">97</span></td>
+        <td class="lower"><span class="hex">71</span><span class="ch">q</span><span class="dec">113</span></td>
+      </tr>
+      <tr>
+        <th class="row">2<span class="b">0010</span></th>
+        <td class="ctrl"><span class="hex">02</span><span class="ch">STX<small>start txt</small></span><span class="dec">2</span></td>
+        <td class="ctrl"><span class="hex">12</span><span class="ch">DC2</span><span class="dec">18</span></td>
+        <td class="punct"><span class="hex">22</span><span class="ch">"</span><span class="dec">34</span></td>
+        <td class="digit"><span class="hex">32</span><span class="ch">2</span><span class="dec">50</span></td>
+        <td class="upper"><span class="hex">42</span><span class="ch">B</span><span class="dec">66</span></td>
+        <td class="upper"><span class="hex">52</span><span class="ch">R</span><span class="dec">82</span></td>
+        <td class="lower"><span class="hex">62</span><span class="ch">b</span><span class="dec">98</span></td>
+        <td class="lower"><span class="hex">72</span><span class="ch">r</span><span class="dec">114</span></td>
+      </tr>
+      <tr>
+        <th class="row">3<span class="b">0011</span></th>
+        <td class="ctrl"><span class="hex">03</span><span class="ch">ETX<small>end txt</small></span><span class="dec">3</span></td>
+        <td class="ctrl"><span class="hex">13</span><span class="ch">DC3<small>XOFF</small></span><span class="dec">19</span></td>
+        <td class="punct"><span class="hex">23</span><span class="ch">#</span><span class="dec">35</span></td>
+        <td class="digit"><span class="hex">33</span><span class="ch">3</span><span class="dec">51</span></td>
+        <td class="upper"><span class="hex">43</span><span class="ch">C</span><span class="dec">67</span></td>
+        <td class="upper"><span class="hex">53</span><span class="ch">S</span><span class="dec">83</span></td>
+        <td class="lower"><span class="hex">63</span><span class="ch">c</span><span class="dec">99</span></td>
+        <td class="lower"><span class="hex">73</span><span class="ch">s</span><span class="dec">115</span></td>
+      </tr>
+      <tr>
+        <th class="row">4<span class="b">0100</span></th>
+        <td class="ctrl"><span class="hex">04</span><span class="ch">EOT<small>end trans</small></span><span class="dec">4</span></td>
+        <td class="ctrl"><span class="hex">14</span><span class="ch">DC4</span><span class="dec">20</span></td>
+        <td class="punct"><span class="hex">24</span><span class="ch">$</span><span class="dec">36</span></td>
+        <td class="digit"><span class="hex">34</span><span class="ch">4</span><span class="dec">52</span></td>
+        <td class="upper"><span class="hex">44</span><span class="ch">D</span><span class="dec">68</span></td>
+        <td class="upper"><span class="hex">54</span><span class="ch">T</span><span class="dec">84</span></td>
+        <td class="lower"><span class="hex">64</span><span class="ch">d</span><span class="dec">100</span></td>
+        <td class="lower"><span class="hex">74</span><span class="ch">t</span><span class="dec">116</span></td>
+      </tr>
+      <tr>
+        <th class="row">5<span class="b">0101</span></th>
+        <td class="ctrl"><span class="hex">05</span><span class="ch">ENQ<small>enquiry</small></span><span class="dec">5</span></td>
+        <td class="ctrl"><span class="hex">15</span><span class="ch">NAK</span><span class="dec">21</span></td>
+        <td class="punct"><span class="hex">25</span><span class="ch">%</span><span class="dec">37</span></td>
+        <td class="digit"><span class="hex">35</span><span class="ch">5</span><span class="dec">53</span></td>
+        <td class="upper"><span class="hex">45</span><span class="ch">E</span><span class="dec">69</span></td>
+        <td class="upper"><span class="hex">55</span><span class="ch">U</span><span class="dec">85</span></td>
+        <td class="lower"><span class="hex">65</span><span class="ch">e</span><span class="dec">101</span></td>
+        <td class="lower"><span class="hex">75</span><span class="ch">u</span><span class="dec">117</span></td>
+      </tr>
+      <tr>
+        <th class="row">6<span class="b">0110</span></th>
+        <td class="ctrl"><span class="hex">06</span><span class="ch">ACK<small>ack</small></span><span class="dec">6</span></td>
+        <td class="ctrl"><span class="hex">16</span><span class="ch">SYN</span><span class="dec">22</span></td>
+        <td class="punct"><span class="hex">26</span><span class="ch">&amp;</span><span class="dec">38</span></td>
+        <td class="digit"><span class="hex">36</span><span class="ch">6</span><span class="dec">54</span></td>
+        <td class="upper"><span class="hex">46</span><span class="ch">F</span><span class="dec">70</span></td>
+        <td class="upper"><span class="hex">56</span><span class="ch">V</span><span class="dec">86</span></td>
+        <td class="lower"><span class="hex">66</span><span class="ch">f</span><span class="dec">102</span></td>
+        <td class="lower"><span class="hex">76</span><span class="ch">v</span><span class="dec">118</span></td>
+      </tr>
+      <tr>
+        <th class="row">7<span class="b">0111</span></th>
+        <td class="ctrl"><span class="hex">07</span><span class="ch">BEL<small>bell 🔔</small></span><span class="dec">7</span></td>
+        <td class="ctrl"><span class="hex">17</span><span class="ch">ETB</span><span class="dec">23</span></td>
+        <td class="punct"><span class="hex">27</span><span class="ch">'</span><span class="dec">39</span></td>
+        <td class="digit"><span class="hex">37</span><span class="ch">7</span><span class="dec">55</span></td>
+        <td class="upper"><span class="hex">47</span><span class="ch">G</span><span class="dec">71</span></td>
+        <td class="upper"><span class="hex">57</span><span class="ch">W</span><span class="dec">87</span></td>
+        <td class="lower"><span class="hex">67</span><span class="ch">g</span><span class="dec">103</span></td>
+        <td class="lower"><span class="hex">77</span><span class="ch">w</span><span class="dec">119</span></td>
+      </tr>
+      <tr>
+        <th class="row">8<span class="b">1000</span></th>
+        <td class="ctrl"><span class="hex">08</span><span class="ch">BS<small>backspace</small></span><span class="dec">8</span></td>
+        <td class="ctrl"><span class="hex">18</span><span class="ch">CAN</span><span class="dec">24</span></td>
+        <td class="punct"><span class="hex">28</span><span class="ch">(</span><span class="dec">40</span></td>
+        <td class="digit"><span class="hex">38</span><span class="ch">8</span><span class="dec">56</span></td>
+        <td class="upper"><span class="hex">48</span><span class="ch">H</span><span class="dec">72</span></td>
+        <td class="upper"><span class="hex">58</span><span class="ch">X</span><span class="dec">88</span></td>
+        <td class="lower"><span class="hex">68</span><span class="ch">h</span><span class="dec">104</span></td>
+        <td class="lower"><span class="hex">78</span><span class="ch">x</span><span class="dec">120</span></td>
+      </tr>
+      <tr>
+        <th class="row">9<span class="b">1001</span></th>
+        <td class="ctrl"><span class="hex">09</span><span class="ch">HT<small>tab ⇥</small></span><span class="dec">9</span></td>
+        <td class="ctrl"><span class="hex">19</span><span class="ch">EM</span><span class="dec">25</span></td>
+        <td class="punct"><span class="hex">29</span><span class="ch">)</span><span class="dec">41</span></td>
+        <td class="digit"><span class="hex">39</span><span class="ch">9</span><span class="dec">57</span></td>
+        <td class="upper"><span class="hex">49</span><span class="ch">I</span><span class="dec">73</span></td>
+        <td class="upper"><span class="hex">59</span><span class="ch">Y</span><span class="dec">89</span></td>
+        <td class="lower"><span class="hex">69</span><span class="ch">i</span><span class="dec">105</span></td>
+        <td class="lower"><span class="hex">79</span><span class="ch">y</span><span class="dec">121</span></td>
+      </tr>
+      <tr>
+        <th class="row">A<span class="b">1010</span></th>
+        <td class="ctrl"><span class="hex">0A</span><span class="ch">LF<small>↵ newline</small></span><span class="dec">10</span></td>
+        <td class="ctrl"><span class="hex">1A</span><span class="ch">SUB<small>EOF DOS</small></span><span class="dec">26</span></td>
+        <td class="punct"><span class="hex">2A</span><span class="ch">*</span><span class="dec">42</span></td>
+        <td class="punct"><span class="hex">3A</span><span class="ch">:</span><span class="dec">58</span></td>
+        <td class="upper"><span class="hex">4A</span><span class="ch">J</span><span class="dec">74</span></td>
+        <td class="upper"><span class="hex">5A</span><span class="ch">Z</span><span class="dec">90</span></td>
+        <td class="lower"><span class="hex">6A</span><span class="ch">j</span><span class="dec">106</span></td>
+        <td class="lower"><span class="hex">7A</span><span class="ch">z</span><span class="dec">122</span></td>
+      </tr>
+      <tr>
+        <th class="row">B<span class="b">1011</span></th>
+        <td class="ctrl"><span class="hex">0B</span><span class="ch">VT</span><span class="dec">11</span></td>
+        <td class="ctrl"><span class="hex">1B</span><span class="ch">ESC<small>escape</small></span><span class="dec">27</span></td>
+        <td class="punct"><span class="hex">2B</span><span class="ch">+</span><span class="dec">43</span></td>
+        <td class="punct"><span class="hex">3B</span><span class="ch">;</span><span class="dec">59</span></td>
+        <td class="upper"><span class="hex">4B</span><span class="ch">K</span><span class="dec">75</span></td>
+        <td class="punct"><span class="hex">5B</span><span class="ch">[</span><span class="dec">91</span></td>
+        <td class="lower"><span class="hex">6B</span><span class="ch">k</span><span class="dec">107</span></td>
+        <td class="punct"><span class="hex">7B</span><span class="ch">{</span><span class="dec">123</span></td>
+      </tr>
+      <tr>
+        <th class="row">C<span class="b">1100</span></th>
+        <td class="ctrl"><span class="hex">0C</span><span class="ch">FF<small>form feed</small></span><span class="dec">12</span></td>
+        <td class="ctrl"><span class="hex">1C</span><span class="ch">FS</span><span class="dec">28</span></td>
+        <td class="punct"><span class="hex">2C</span><span class="ch">,</span><span class="dec">44</span></td>
+        <td class="punct"><span class="hex">3C</span><span class="ch">&lt;</span><span class="dec">60</span></td>
+        <td class="upper"><span class="hex">4C</span><span class="ch">L</span><span class="dec">76</span></td>
+        <td class="punct"><span class="hex">5C</span><span class="ch">\</span><span class="dec">92</span></td>
+        <td class="lower"><span class="hex">6C</span><span class="ch">l</span><span class="dec">108</span></td>
+        <td class="punct"><span class="hex">7C</span><span class="ch">|</span><span class="dec">124</span></td>
+      </tr>
+      <tr>
+        <th class="row">D<span class="b">1101</span></th>
+        <td class="ctrl"><span class="hex">0D</span><span class="ch">CR<small>carriage</small></span><span class="dec">13</span></td>
+        <td class="ctrl"><span class="hex">1D</span><span class="ch">GS</span><span class="dec">29</span></td>
+        <td class="punct"><span class="hex">2D</span><span class="ch">-</span><span class="dec">45</span></td>
+        <td class="punct"><span class="hex">3D</span><span class="ch">=</span><span class="dec">61</span></td>
+        <td class="upper"><span class="hex">4D</span><span class="ch">M</span><span class="dec">77</span></td>
+        <td class="punct"><span class="hex">5D</span><span class="ch">]</span><span class="dec">93</span></td>
+        <td class="lower"><span class="hex">6D</span><span class="ch">m</span><span class="dec">109</span></td>
+        <td class="punct"><span class="hex">7D</span><span class="ch">}</span><span class="dec">125</span></td>
+      </tr>
+      <tr>
+        <th class="row">E<span class="b">1110</span></th>
+        <td class="ctrl"><span class="hex">0E</span><span class="ch">SO</span><span class="dec">14</span></td>
+        <td class="ctrl"><span class="hex">1E</span><span class="ch">RS</span><span class="dec">30</span></td>
+        <td class="punct"><span class="hex">2E</span><span class="ch">.</span><span class="dec">46</span></td>
+        <td class="punct"><span class="hex">3E</span><span class="ch">&gt;</span><span class="dec">62</span></td>
+        <td class="upper"><span class="hex">4E</span><span class="ch">N</span><span class="dec">78</span></td>
+        <td class="punct"><span class="hex">5E</span><span class="ch">^</span><span class="dec">94</span></td>
+        <td class="lower"><span class="hex">6E</span><span class="ch">n</span><span class="dec">110</span></td>
+        <td class="punct"><span class="hex">7E</span><span class="ch">~</span><span class="dec">126</span></td>
+      </tr>
+      <tr>
+        <th class="row">F<span class="b">1111</span></th>
+        <td class="ctrl"><span class="hex">0F</span><span class="ch">SI</span><span class="dec">15</span></td>
+        <td class="ctrl"><span class="hex">1F</span><span class="ch">US</span><span class="dec">31</span></td>
+        <td class="punct"><span class="hex">2F</span><span class="ch">/</span><span class="dec">47</span></td>
+        <td class="punct"><span class="hex">3F</span><span class="ch">?</span><span class="dec">63</span></td>
+        <td class="upper"><span class="hex">4F</span><span class="ch">O</span><span class="dec">79</span></td>
+        <td class="punct"><span class="hex">5F</span><span class="ch">_</span><span class="dec">95</span></td>
+        <td class="lower"><span class="hex">6F</span><span class="ch">o</span><span class="dec">111</span></td>
+        <td class="del"><span class="hex">7F</span><span class="ch">DEL</span><span class="dec">127</span></td>
+      </tr>
+    </tbody>
+  </table>
+  </div>
+
+  <div class="legend">
+    <div class="item"><span class="swatch ctrl"></span>Steuerzeichen (0–31)</div>
+    <div class="item"><span class="swatch space"></span>Leerzeichen (32)</div>
+    <div class="item"><span class="swatch punct"></span>Satzzeichen</div>
+    <div class="item"><span class="swatch digit"></span>Ziffern (48–57)</div>
+    <div class="item"><span class="swatch upper"></span>Großbuchstaben (65–90)</div>
+    <div class="item"><span class="swatch lower"></span>Kleinbuchstaben (97–122)</div>
+    <div class="item"><span class="swatch del"></span>DEL (127)</div>
+  </div>
+
+  <div class="meta-row">
+    <span><strong>Beispiel:</strong> <code>A</code> = Hex <code>41</code> = Dez <code>65</code> = Bin <code>0100&nbsp;0001</code></span>
+    <span><strong>Trick:</strong> Ziffern <code>0–9</code> liegen bei <code>30–39</code> · <code>'A'+1='B'</code> · Groß ↔ Klein: Bit 5 togglen</span>
+  </div>
+</body>
+</html>

slides/223015b-2026/assets/demos/byte-flow.html

@@ -0,0 +1,180 @@
+<!DOCTYPE html>
+<html lang="de">
+<head>
+<meta charset="UTF-8">
+<title>Byte-Fluss: Bit → Hex → ASCII</title>
+<style>
+  :root {
+    --hl: #d63384;
+    --dark: #1a1a2e;
+    --muted: #6b7280;
+    --border: #cbd5e1;
+    --bg-soft: #f8fafc;
+    --byte-border: #94a3b8;
+  }
+  html, body { margin: 0; padding: 0; background: #fff; font-family: system-ui, -apple-system, sans-serif; color: var(--dark); }
+  body { padding: 22px 28px; }
+  h1 { text-align: center; margin: 0 0 4px; font-size: 1.55rem; }
+  .sub { text-align: center; color: var(--muted); margin-bottom: 18px; font-size: 0.95rem; }
+
+  .stage { display: flex; flex-direction: column; align-items: center; gap: 8px; max-width: 920px; margin: 0 auto; }
+
+  .file {
+    width: 100%; box-sizing: border-box;
+    border: 2px solid var(--dark);
+    border-radius: 10px;
+    background: var(--bg-soft);
+    overflow: hidden;
+    box-shadow: 0 6px 20px rgba(0,0,0,0.08);
+  }
+  .file .head {
+    background: var(--dark); color: #fff; padding: 8px 14px;
+    font-size: 0.82rem; text-transform: uppercase; letter-spacing: 0.08em; font-weight: 700;
+    display: flex; justify-content: space-between; align-items: center;
+  }
+  .file .head .name { font-family: ui-monospace, monospace; }
+  .file .head .meta { font-weight: 400; opacity: 0.7; text-transform: none; letter-spacing: 0; font-size: 0.85em; }
+  .file .body { padding: 12px 14px; }
+
+  .row-bytes { display: flex; gap: 6px; margin-bottom: 6px; flex-wrap: nowrap; }
+  .row-bytes:last-child { margin-bottom: 0; }
+
+  .byte-bin {
+    border: 1px solid var(--byte-border);
+    border-radius: 4px;
+    padding: 4px 7px;
+    font-family: ui-monospace, "SF Mono", Menlo, monospace;
+    font-size: 0.92rem;
+    font-weight: 700;
+    background: #fff;
+    letter-spacing: 0.04em;
+  }
+  .byte-hex {
+    border: 1px solid var(--byte-border);
+    border-radius: 4px;
+    padding: 6px 0;
+    font-family: ui-monospace, monospace;
+    font-size: 1.1rem;
+    font-weight: 700;
+    background: #fff;
+    min-width: 88px;
+    text-align: center;
+  }
+  .byte-ascii {
+    border: 1px solid var(--byte-border);
+    border-radius: 4px;
+    padding: 6px 0;
+    font-family: ui-monospace, monospace;
+    font-size: 1.2rem;
+    font-weight: 700;
+    background: #fff;
+    min-width: 88px;
+    text-align: center;
+  }
+  .byte-ascii.np { color: var(--muted); font-style: italic; }
+
+  .truncate { color: var(--muted); font-family: ui-monospace, monospace; padding: 4px 6px; font-weight: 700; align-self: center; }
+
+  .arrow-stack { display: flex; flex-direction: column; align-items: center; gap: 2px; padding: 4px 0; }
+  .arrow {
+    width: 0; height: 0;
+    border-left: 11px solid transparent;
+    border-right: 11px solid transparent;
+    border-top: 14px solid var(--hl);
+  }
+  .arrow-label {
+    font-size: 0.78rem; color: var(--hl); font-weight: 700;
+    text-transform: uppercase; letter-spacing: 0.05em;
+  }
+
+  .legend {
+    margin-top: 12px;
+    display: flex; gap: 14px; flex-wrap: wrap; justify-content: center;
+    font-size: 0.85rem; color: var(--muted);
+  }
+  .legend strong { color: var(--dark); }
+  .legend code { background: var(--bg-soft); border: 1px solid var(--border); padding: 1px 6px; border-radius: 3px; font-family: ui-monospace, monospace; }
+</style>
+</head>
+<body>
+  <h1>1 Byte = 8 Bit = 2 Hex = 1 ASCII-Zeichen</h1>
+  <div class="sub">Dieselbe Datei — dieselben Byte, drei Schreibweisen. Jeder Rahmen = ein Byte.</div>
+
+  <div class="stage">
+
+    <!-- Stage 1: Bitstream -->
+    <div class="file">
+      <div class="head"><span class="name">datei.bin</span><span class="meta">Roh-Bit · 8 Bit pro Rahmen</span></div>
+      <div class="body">
+        <div class="row-bytes">
+          <span class="byte-bin">01001000</span><span class="byte-bin">01100101</span><span class="byte-bin">01101100</span><span class="byte-bin">01101100</span><span class="byte-bin">01101111</span><span class="byte-bin">00101100</span><span class="byte-bin">00100000</span><span class="byte-bin">01010111</span>
+        </div>
+        <div class="row-bytes">
+          <span class="byte-bin">01101111</span><span class="byte-bin">01110010</span><span class="byte-bin">01101100</span><span class="byte-bin">01100100</span><span class="byte-bin">00100001</span><span class="byte-bin">00100000</span><span class="byte-bin">01001000</span><span class="byte-bin">01101111</span>
+        </div>
+        <div class="row-bytes">
+          <span class="byte-bin">01110111</span><span class="byte-bin">00100000</span><span class="byte-bin">01100001</span><span class="byte-bin">01110010</span><span class="byte-bin">01100101</span><span class="byte-bin">00100000</span><span class="byte-bin">01111001</span><span class="byte-bin">01101111</span>
+        </div>
+        <div class="row-bytes">
+          <span class="byte-bin">01110101</span><span class="byte-bin">00111111</span><span class="byte-bin">00001010</span><span class="truncate">… (weitere Byte)</span>
+        </div>
+      </div>
+    </div>
+
+    <div class="arrow-stack">
+      <div class="arrow-label">je 8 Bit → 2 Hex-Ziffern</div>
+      <div class="arrow"></div>
+    </div>
+
+    <!-- Stage 2: Hex -->
+    <div class="file">
+      <div class="head"><span class="name">datei.hex</span><span class="meta">Hex-Sicht · 2 Hex-Ziffern pro Rahmen</span></div>
+      <div class="body">
+        <div class="row-bytes">
+          <span class="byte-hex">48</span><span class="byte-hex">65</span><span class="byte-hex">6C</span><span class="byte-hex">6C</span><span class="byte-hex">6F</span><span class="byte-hex">2C</span><span class="byte-hex">20</span><span class="byte-hex">57</span>
+        </div>
+        <div class="row-bytes">
+          <span class="byte-hex">6F</span><span class="byte-hex">72</span><span class="byte-hex">6C</span><span class="byte-hex">64</span><span class="byte-hex">21</span><span class="byte-hex">20</span><span class="byte-hex">48</span><span class="byte-hex">6F</span>
+        </div>
+        <div class="row-bytes">
+          <span class="byte-hex">77</span><span class="byte-hex">20</span><span class="byte-hex">61</span><span class="byte-hex">72</span><span class="byte-hex">65</span><span class="byte-hex">20</span><span class="byte-hex">79</span><span class="byte-hex">6F</span>
+        </div>
+        <div class="row-bytes">
+          <span class="byte-hex">75</span><span class="byte-hex">3F</span><span class="byte-hex">0A</span><span class="truncate">…</span>
+        </div>
+      </div>
+    </div>
+
+    <div class="arrow-stack">
+      <div class="arrow-label">je 1 Byte → 1 Zeichen</div>
+      <div class="arrow"></div>
+    </div>
+
+    <!-- Stage 3: ASCII -->
+    <div class="file">
+      <div class="head"><span class="name">datei.txt</span><span class="meta">Text-Sicht · 1 ASCII-Zeichen pro Rahmen</span></div>
+      <div class="body">
+        <div class="row-bytes">
+          <span class="byte-ascii">H</span><span class="byte-ascii">e</span><span class="byte-ascii">l</span><span class="byte-ascii">l</span><span class="byte-ascii">o</span><span class="byte-ascii">,</span><span class="byte-ascii np">␣</span><span class="byte-ascii">W</span>
+        </div>
+        <div class="row-bytes">
+          <span class="byte-ascii">o</span><span class="byte-ascii">r</span><span class="byte-ascii">l</span><span class="byte-ascii">d</span><span class="byte-ascii">!</span><span class="byte-ascii np">␣</span><span class="byte-ascii">H</span><span class="byte-ascii">o</span>
+        </div>
+        <div class="row-bytes">
+          <span class="byte-ascii">w</span><span class="byte-ascii np">␣</span><span class="byte-ascii">a</span><span class="byte-ascii">r</span><span class="byte-ascii">e</span><span class="byte-ascii np">␣</span><span class="byte-ascii">y</span><span class="byte-ascii">o</span>
+        </div>
+        <div class="row-bytes">
+          <span class="byte-ascii">u</span><span class="byte-ascii">?</span><span class="byte-ascii np">↵</span><span class="truncate">…</span>
+        </div>
+      </div>
+    </div>
+
+    <div class="legend">
+      <span><code>␣</code> = Leerzeichen (0x20)</span>
+      <span><code>↵</code> = Zeilenumbruch (0x0A, nicht druckbar)</span>
+      <span><strong>Byte ändern sich nicht.</strong> Nur die Anzeige.</span>
+    </div>
+
+  </div>
+</body>
+</html>

slides/223015b-2026/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-2026/assets/demos/byte-nibble-hex.html

@@ -0,0 +1,185 @@
+<!DOCTYPE html>
+<html lang="de">
+<head>
+<meta charset="UTF-8">
+<title>Byte → Nibble → Hex</title>
+<style>
+  :root {
+    --hl: #d63384;
+    --dark: #1a1a2e;
+    --muted: #6b7280;
+    --border: #cbd5e1;
+    --bg-soft: #f8fafc;
+  }
+  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.55rem; }
+  .sub { text-align: center; color: var(--muted); margin-bottom: 22px; font-size: 0.95rem; }
+
+  .stage { display: flex; flex-direction: column; align-items: center; gap: 6px; }
+
+  .level { display: flex; flex-direction: column; align-items: center; }
+  .label { font-size: 0.78rem; color: var(--muted); text-transform: uppercase; letter-spacing: 0.08em; margin-bottom: 6px; font-weight: 600; }
+
+  /* Level 1: whole byte */
+  .byte {
+    display: flex;
+    gap: 4px;
+    padding: 8px 14px;
+    border: 2px solid var(--dark);
+    border-radius: 8px;
+    background: var(--bg-soft);
+  }
+  .byte .bit { font-family: ui-monospace, "SF Mono", Menlo, monospace; font-size: 1.3rem; font-weight: 700; padding: 4px 8px; min-width: 22px; text-align: center; }
+  .byte .sep { width: 2px; background: var(--hl); margin: 2px 6px; border-radius: 2px; }
+
+  /* Split arrows */
+  .split { display: flex; justify-content: space-between; width: 360px; margin: 2px 0; }
+  .split .arrow {
+    width: 0; height: 0;
+    border-left: 9px solid transparent;
+    border-right: 9px solid transparent;
+    border-top: 12px solid var(--hl);
+  }
+
+  /* Level 2: two nibbles */
+  .nibbles { display: flex; gap: 80px; }
+  .nibble {
+    display: flex; flex-direction: column; align-items: center; gap: 6px;
+    padding: 10px 14px;
+    border: 2px solid var(--hl);
+    border-radius: 8px;
+    background: #fff;
+  }
+  .nibble .bits { display: flex; gap: 4px; font-family: ui-monospace, monospace; font-size: 1.15rem; font-weight: 700; }
+  .nibble .bits span { padding: 2px 6px; min-width: 20px; text-align: center; }
+  .nibble .meta { font-size: 0.78rem; color: var(--muted); }
+
+  .single-arrow {
+    width: 0; height: 0;
+    border-left: 9px solid transparent;
+    border-right: 9px solid transparent;
+    border-top: 12px solid var(--hl);
+    margin: 2px 0;
+  }
+
+  /* Level 3: hex digits */
+  .hex-digits { display: flex; gap: 80px; }
+  .hex-digit {
+    display: flex; flex-direction: column; align-items: center; gap: 4px;
+    padding: 8px 22px;
+    border: 2px solid var(--dark);
+    border-radius: 8px;
+    background: var(--dark);
+    color: var(--hl);
+  }
+  .hex-digit .digit { font-family: ui-monospace, monospace; font-size: 2rem; font-weight: 800; line-height: 1; }
+  .hex-digit .meta { font-size: 0.72rem; color: #f3f4f6; opacity: 0.7; }
+
+  /* Merge down to byte */
+  .merge {
+    display: flex; justify-content: center; margin-top: 2px;
+  }
+  .merge-v {
+    display: grid;
+    grid-template-columns: 60px 60px;
+    justify-content: center;
+    align-items: center;
+  }
+  .merge-v .line {
+    height: 20px;
+    border-right: 2px solid var(--hl);
+  }
+  .merge-v .line.l { border-right: none; border-left: 2px solid var(--hl); }
+  .bottom-bar { height: 2px; background: var(--hl); width: 120px; }
+
+  /* Final result */
+  .result {
+    margin-top: 14px;
+    padding: 14px 22px;
+    background: #fef3f8;
+    border-left: 4px solid var(--hl);
+    border-radius: 4px;
+    font-size: 1.05rem;
+    text-align: center;
+    max-width: 640px;
+  }
+  .result code { background: var(--dark); color: var(--hl); padding: 2px 8px; border-radius: 4px; font-family: ui-monospace, monospace; font-weight: 700; }
+  .result strong { color: var(--hl); }
+
+  .math {
+    margin-top: 10px;
+    font-size: 0.95rem;
+    color: var(--dark);
+    text-align: center;
+  }
+  .math .eq { font-family: ui-monospace, monospace; font-weight: 700; }
+</style>
+</head>
+<body>
+  <h1>1 Byte → 2 Nibble → 2 Hex-Ziffern</h1>
+  <div class="sub">Jedes Byte lässt sich sauber halbieren – und 4 Bit passen exakt auf eine Hex-Ziffer.</div>
+
+  <div class="stage">
+    <!-- Level 1 -->
+    <div class="level">
+      <div class="label">1 Byte · 8 Bit · 2⁸ = 256 Werte</div>
+      <div class="byte">
+        <span class="bit">0</span><span class="bit">1</span><span class="bit">0</span><span class="bit">0</span>
+        <span class="sep"></span>
+        <span class="bit">1</span><span class="bit">1</span><span class="bit">0</span><span class="bit">1</span>
+      </div>
+    </div>
+
+    <div class="split">
+      <div class="arrow"></div>
+      <div class="arrow"></div>
+    </div>
+
+    <!-- Level 2 -->
+    <div class="level">
+      <div class="label">2 Nibble · je 4 Bit · 2⁴ = 16 Werte</div>
+      <div class="nibbles">
+        <div class="nibble">
+          <div class="bits"><span>0</span><span>1</span><span>0</span><span>0</span></div>
+          <div class="meta">= 4 (dez)</div>
+        </div>
+        <div class="nibble">
+          <div class="bits"><span>1</span><span>1</span><span>0</span><span>1</span></div>
+          <div class="meta">= 13 (dez)</div>
+        </div>
+      </div>
+    </div>
+
+    <div class="split">
+      <div class="arrow"></div>
+      <div class="arrow"></div>
+    </div>
+
+    <!-- Level 3 -->
+    <div class="level">
+      <div class="label">2 Hex-Ziffern · Symbole 0–F</div>
+      <div class="hex-digits">
+        <div class="hex-digit">
+          <div class="digit">4</div>
+          <div class="meta">Nibble → 1 Ziffer</div>
+        </div>
+        <div class="hex-digit">
+          <div class="digit">D</div>
+          <div class="meta">13 → D</div>
+        </div>
+      </div>
+    </div>
+
+    <div class="result">
+      <code>01001101</code> (bin) &nbsp;=&nbsp; <code>4D</code> (hex) &nbsp;=&nbsp; <strong>77</strong> (dez) &nbsp;=&nbsp; <strong>"M"</strong> (ASCII)
+    </div>
+
+    <div class="math">
+      <span class="eq">16 × 16 = 256</span> &nbsp;·&nbsp; <span class="eq">2⁴ × 2⁴ = 2⁸</span> &nbsp;·&nbsp; Darum passt Hex so gut zu Bytes.
+    </div>
+  </div>
+</body>
+</html>
+</content>
+</invoke>

slides/223015b-2026/assets/demos/hex-dec-table.html

@@ -0,0 +1,67 @@
+<!DOCTYPE html>
+<html lang="de">
+<head>
+<meta charset="UTF-8">
+<title>Hex → Dezimal</title>
+<style>
+  html, body { margin: 0; padding: 0; background: #fff; font-family: system-ui, -apple-system, sans-serif; }
+  body { padding: 28px; }
+  h1 { text-align: center; margin: 0 0 4px; font-size: 1.6rem; color: #1a1a2e; }
+  .sub { text-align: center; color: #6b7280; margin-bottom: 18px; font-size: 0.95rem; }
+  table { border-collapse: collapse; margin: 0 auto; font-variant-numeric: tabular-nums; }
+  th, td { border: 1px solid #cbd5e1; padding: 7px 10px; text-align: center; font-size: 0.95rem; }
+  thead th { background: #1a1a2e; color: #fff; }
+  tbody th { background: #334155; color: #fff; font-weight: 600; }
+  tbody td.ascii { background: #f3f4f6; }
+  tbody td.nonascii { background: #fff; color: #6b7280; }
+  .corner { background: #0f0f23; color: #d63384; }
+  .legend { display: flex; justify-content: center; gap: 24px; margin-top: 16px; font-size: 0.9rem; color: #374151; }
+  .sw { display: inline-block; width: 14px; height: 14px; border: 1px solid #cbd5e1; vertical-align: middle; margin-right: 6px; }
+  .example { margin: 20px auto 0; max-width: 720px; padding: 14px 18px; background: #fef3f8; border-left: 4px solid #d63384; border-radius: 4px; font-size: 1rem; color: #1a1a2e; }
+  code { background: #1a1a2e; color: #d63384; padding: 2px 6px; border-radius: 3px; font-family: ui-monospace, monospace; font-weight: 700; }
+</style>
+</head>
+<body>
+  <h1>Hex → Dezimal</h1>
+  <div class="sub">Dezimalwert = (Zeile × 16) + Spalte</div>
+  <table>
+    <thead>
+      <tr>
+        <th class="corner">×16 / +</th>
+        <th>0</th><th>1</th><th>2</th><th>3</th><th>4</th><th>5</th><th>6</th><th>7</th>
+        <th>8</th><th>9</th><th>A <small style="opacity:.7;font-weight:400">(10)</small></th><th>B <small style="opacity:.7;font-weight:400">(11)</small></th><th>C <small style="opacity:.7;font-weight:400">(12)</small></th><th>D <small style="opacity:.7;font-weight:400">(13)</small></th><th>E <small style="opacity:.7;font-weight:400">(14)</small></th><th>F <small style="opacity:.7;font-weight:400">(15)</small></th>
+      </tr>
+    </thead>
+    <tbody>
+    </tbody>
+  </table>
+
+  <div class="legend">
+    <span><span class="sw" style="background:#f3f4f6"></span>ASCII (0–127)</span>
+    <span><span class="sw" style="background:#fff"></span>Non-ASCII (128–255)</span>
+  </div>
+
+  <div class="example">
+    <strong>Beispiel:</strong> <code>4D</code> → Zeile <code>4</code> × 16 + Spalte <code>D</code> = 64 + 13 = <strong>77</strong> (= "M" in ASCII)
+  </div>
+
+<script>
+  const rows = '0123456789ABCDEF';
+  const tb = document.querySelector('tbody');
+  for (let r = 0; r < 16; r++) {
+    const tr = document.createElement('tr');
+    const th = document.createElement('th');
+    th.innerHTML = r >= 10 ? rows[r] + ' <small style="opacity:.7;font-weight:400">('+r+')</small>' : rows[r];
+    tr.appendChild(th);
+    for (let c = 0; c < 16; c++) {
+      const td = document.createElement('td');
+      const v = r*16 + c;
+      td.textContent = v;
+      td.className = v <= 127 ? 'ascii' : 'nonascii';
+      tr.appendChild(td);
+    }
+    tb.appendChild(tr);
+  }
+</script>
+</body>
+</html>

slides/223015b-2026/assets/demos/three-views.html

@@ -0,0 +1,120 @@
+<!DOCTYPE html>
+<html lang="de">
+<head>
+<meta charset="UTF-8">
+<title>Dieselben Byte — drei Perspektiven</title>
+<style>
+  :root {
+    --hl: #d63384;
+    --dark: #1a1a2e;
+    --muted: #6b7280;
+    --border: #cbd5e1;
+    --bg-soft: #f8fafc;
+    --magic: #ef4444;
+    --format: #2563eb;
+    --transport: #16a34a;
+  }
+  html, body { margin: 0; padding: 0; background: #fff; font-family: system-ui, -apple-system, sans-serif; color: var(--dark); }
+  body { padding: 24px 28px; }
+  h1 { text-align: center; margin: 0 0 4px; font-size: 1.55rem; }
+  .sub { text-align: center; color: var(--muted); margin-bottom: 18px; font-size: 0.95rem; }
+
+  .stage { display: flex; flex-direction: column; gap: 14px; align-items: stretch; max-width: 1080px; margin: 0 auto; }
+
+  .row { display: grid; grid-template-columns: 200px 1fr; gap: 14px; align-items: center; }
+  .label { font-size: 0.8rem; color: var(--muted); text-transform: uppercase; letter-spacing: 0.08em; font-weight: 700; text-align: right; white-space: nowrap; }
+  .label small { display: block; font-weight: 400; text-transform: none; letter-spacing: 0; color: var(--muted); margin-top: 2px; font-size: 0.8em; white-space: nowrap; }
+
+  .panel { padding: 14px 16px; border: 2px solid var(--border); border-radius: 8px; background: var(--bg-soft); }
+  .panel.bin { background: #0f0f23; color: #fff; border-color: var(--dark); }
+  .panel.bin code { color: #e5e7eb; }
+  .mono { font-family: ui-monospace, "SF Mono", Menlo, monospace; font-size: 1.1rem; font-weight: 700; letter-spacing: 0.02em; word-break: break-all; line-height: 1.5; }
+
+  .hex-bytes { display: flex; flex-wrap: wrap; gap: 8px; }
+  .hex-byte { background: #fff; border: 1px solid var(--border); border-radius: 4px; padding: 4px 10px; font-family: ui-monospace, monospace; font-size: 1.15rem; font-weight: 700; }
+
+  .semantic { display: flex; gap: 6px; flex-wrap: wrap; align-items: stretch; }
+  .group { display: flex; flex-direction: column; gap: 4px; padding: 8px 10px; border-radius: 6px; min-width: 70px; }
+  .group .bytes { display: flex; gap: 4px; }
+  .group .b { background: #fff; border: 1px solid currentColor; border-radius: 3px; padding: 3px 7px; font-family: ui-monospace, monospace; font-size: 1rem; font-weight: 700; color: var(--dark); }
+  .group .tag { font-size: 0.72rem; font-weight: 700; text-transform: uppercase; letter-spacing: 0.05em; }
+  .group .meaning { font-size: 0.78rem; line-height: 1.3; color: var(--dark); }
+  .group.magic { background: #fee2e2; color: var(--magic); }
+  .group.format { background: #dbeafe; color: var(--format); }
+  .group.transport { background: #dcfce7; color: var(--transport); }
+
+  .arrow-row { display: flex; justify-content: center; }
+  .arrow {
+    width: 0; height: 0;
+    border-left: 11px solid transparent;
+    border-right: 11px solid transparent;
+    border-top: 14px solid var(--hl);
+  }
+
+  .footnote { margin-top: 16px; font-size: 0.88rem; color: var(--muted); text-align: center; max-width: 800px; margin-left: auto; margin-right: auto; }
+  .footnote strong { color: var(--dark); }
+</style>
+</head>
+<body>
+  <h1>Dieselben 8 Byte — drei Perspektiven</h1>
+  <div class="sub">PNG-Datei-Anfang: <code style="font-family:ui-monospace,monospace">89 50 4E 47 0D 0A 1A 0A</code></div>
+
+  <div class="stage">
+
+    <div class="row">
+      <div class="label">1 · Bitstream<small>was wirklich gespeichert wird</small></div>
+      <div class="panel bin">
+        <code class="mono">10001001&nbsp;01010000&nbsp;01001110&nbsp;01000111&nbsp;00001101&nbsp;00001010&nbsp;00011010&nbsp;00001010</code>
+      </div>
+    </div>
+
+    <div class="arrow-row"><div class="arrow"></div></div>
+
+    <div class="row">
+      <div class="label">2 · Hex<small>gruppiert in 8-Bit-Häppchen</small></div>
+      <div class="panel">
+        <div class="hex-bytes">
+          <span class="hex-byte">89</span>
+          <span class="hex-byte">50</span>
+          <span class="hex-byte">4E</span>
+          <span class="hex-byte">47</span>
+          <span class="hex-byte">0D</span>
+          <span class="hex-byte">0A</span>
+          <span class="hex-byte">1A</span>
+          <span class="hex-byte">0A</span>
+        </div>
+      </div>
+    </div>
+
+    <div class="arrow-row"><div class="arrow"></div></div>
+
+    <div class="row">
+      <div class="label">3 · Bedeutung<small>was die Byte sagen</small></div>
+      <div class="panel">
+        <div class="semantic">
+          <div class="group magic">
+            <div class="bytes"><span class="b">89</span></div>
+            <div class="tag">Magic Byte</div>
+            <div class="meaning">&gt; 127 → "Ich bin Binär, kein Text"</div>
+          </div>
+          <div class="group format">
+            <div class="bytes"><span class="b">50</span><span class="b">4E</span><span class="b">47</span></div>
+            <div class="tag">Format-Kürzel</div>
+            <div class="meaning">P · N · G (ASCII) → "PNG-Datei"</div>
+          </div>
+          <div class="group transport">
+            <div class="bytes"><span class="b">0D</span><span class="b">0A</span><span class="b">1A</span><span class="b">0A</span></div>
+            <div class="tag">Transport-Schutz</div>
+            <div class="meaning">CR · LF · EOF · LF → erkennt kaputte Übertragung</div>
+          </div>
+        </div>
+      </div>
+    </div>
+
+  </div>
+
+  <div class="footnote">
+    Byte ändern sich nicht — nur unsere <strong>Brille</strong>. Bitstream zeigt das <em>was</em>, Hex das <em>wie kompakt</em>, Bedeutung das <em>warum</em>.
+  </div>
+</body>
+</html>

slides/223015b-2026/assets/demos/why-8-bit.html

@@ -0,0 +1,135 @@
+<!DOCTYPE html>
+<html lang="de">
+<head>
+<meta charset="UTF-8">
+<title>Warum 8 Bit? Adressierung im Speicher</title>
+<style>
+  :root {
+    --hl: #d63384;
+    --dark: #1a1a2e;
+    --muted: #6b7280;
+    --border: #cbd5e1;
+    --bg-soft: #f8fafc;
+    --bad: #ef4444;
+    --good: #16a34a;
+  }
+  html, body { margin: 0; padding: 0; background: #fff; font-family: system-ui, -apple-system, sans-serif; color: var(--dark); }
+  body { padding: 24px 28px; }
+  h1 { text-align: center; margin: 0 0 4px; font-size: 1.55rem; }
+  .sub { text-align: center; color: var(--muted); margin-bottom: 22px; font-size: 0.95rem; }
+
+  .stage { display: flex; flex-direction: column; align-items: center; gap: 18px; max-width: 1100px; margin: 0 auto; }
+
+  .ram-wrap { display: flex; gap: 18px; align-items: stretch; }
+
+  .ram {
+    display: grid;
+    grid-template-columns: 90px 90px 230px;
+    border: 2px solid var(--dark);
+    border-radius: 8px;
+    overflow: hidden;
+    background: var(--bg-soft);
+  }
+  .ram .head {
+    background: var(--dark); color: #fff; padding: 8px 10px;
+    font-size: 0.78rem; text-transform: uppercase; letter-spacing: 0.08em; font-weight: 700; text-align: center;
+  }
+  .ram .cell {
+    border-top: 1px solid var(--border); padding: 10px 12px;
+    font-family: ui-monospace, "SF Mono", Menlo, monospace; font-size: 1.05rem; font-weight: 700;
+    text-align: center; background: #fff;
+  }
+  .ram .cell.addr { color: var(--muted); background: var(--bg-soft); }
+  .ram .cell.bin  { font-size: 0.95rem; letter-spacing: 0.05em; }
+  .ram .row.cur .cell { background: #fef3f8; color: var(--hl); }
+
+  .pointer-side { display: flex; flex-direction: column; gap: 12px; padding-top: 36px; }
+  .ptr-block { display: flex; align-items: center; gap: 8px; padding: 6px 10px; border-radius: 6px; font-family: ui-monospace, monospace; font-weight: 700; font-size: 0.95rem; }
+  .ptr-block.ok  { background: #dcfce7; color: var(--good); border: 2px solid var(--good); }
+  .ptr-block.bad { background: #fee2e2; color: var(--bad); border: 2px dashed var(--bad); }
+  .ptr-block.between {
+    background: #fff; color: var(--bad); border: 2px dashed var(--bad);
+    margin: -12px 0 -12px 0;
+    transform: translateX(-10px);
+  }
+  .ptr-block .ico { font-size: 1.3rem; line-height: 1; }
+
+  .legend {
+    display: flex; gap: 22px; padding: 12px 16px; border-top: 1px solid var(--border);
+    font-size: 0.9rem; color: var(--dark);
+  }
+  .legend .row { display: flex; align-items: center; gap: 6px; }
+  .legend .swatch { width: 14px; height: 14px; border-radius: 3px; }
+
+  .conclusion {
+    margin-top: 6px;
+    padding: 14px 22px;
+    background: #fef3f8;
+    border-left: 4px solid var(--hl);
+    border-radius: 4px;
+    font-size: 1rem;
+    text-align: center;
+    max-width: 760px;
+  }
+  .conclusion strong { color: var(--hl); }
+  .conclusion code { background: var(--dark); color: #f8f8f8; padding: 1px 6px; border-radius: 3px; font-family: ui-monospace, monospace; }
+</style>
+</head>
+<body>
+  <h1>Warum 8 Bit? Speicher-Adressierung</h1>
+  <div class="sub">CPU adressiert <strong>byteweise</strong> — halbe Byte existieren nicht.</div>
+
+  <div class="stage">
+
+    <div class="ram-wrap">
+
+      <div class="ram">
+        <div class="head">Adresse</div>
+        <div class="head">Hex</div>
+        <div class="head">Bit (was im Speicher steht)</div>
+
+        <div class="cell addr">0x0000</div>
+        <div class="cell">48</div>
+        <div class="cell bin">01001000</div>
+
+        <div class="cell addr">0x0001</div>
+        <div class="cell">65</div>
+        <div class="cell bin">01100101</div>
+
+        <div class="cell addr">0x0002</div>
+        <div class="cell">6C</div>
+        <div class="cell bin">01101100</div>
+
+        <div class="cell addr">0x0003</div>
+        <div class="cell">6C</div>
+        <div class="cell bin">01101100</div>
+
+        <div class="cell addr">0x0004</div>
+        <div class="cell">6F</div>
+        <div class="cell bin">01101111</div>
+
+        <div class="cell addr">0x0005</div>
+        <div class="cell">21</div>
+        <div class="cell bin">00100001</div>
+      </div>
+
+      <div class="pointer-side">
+        <div class="ptr-block ok"><span class="ico">→</span><span>read 0x0000 ✓</span></div>
+        <div class="ptr-block bad"><span class="ico">✗</span><span>read 0x0000.5 — gibt's nicht</span></div>
+        <div class="ptr-block ok"><span class="ico">→</span><span>read 0x0001 ✓</span></div>
+        <div class="ptr-block bad"><span class="ico">✗</span><span>read 0x0001.5 — gibt's nicht</span></div>
+        <div class="ptr-block ok"><span class="ico">→</span><span>read 0x0002 ✓</span></div>
+        <div class="ptr-block ok" style="opacity:0.4"><span class="ico">→</span><span>...</span></div>
+      </div>
+
+    </div>
+
+    <div class="conclusion">
+      <strong>Byte = kleinste adressierbare Einheit.</strong><br>
+      Speichercontroller, Bus und CPU sind alle auf 8-Bit-Häppchen ausgelegt.<br>
+      Einzelne Bit lesen → muss erst <code>byte = mem[addr]</code>, dann mit <code>byte &amp; 0b1000_0000</code> Bit isolieren.
+    </div>
+
+  </div>
+</body>
+</html>