From a8343c99370fd10fc98129979f656e7a3028be57 Mon Sep 17 00:00:00 2001
From: Michael Czechowski <mail@dailysh.it>
Date: Sun, 25 Jan 2026 11:26:15 +0100
Subject: [PATCH] restructure: rename termin to kapitel, flatten folder
 structure
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- rename slide files: YYYY-MM-DD-termin-N-topic.md → NN-topic.md
- flatten folders: courses/X/slides/ → slides/X/
- replace "Termin" with "Kapitel" in all content
- add klausur extraction script (make klausur)
- update Makefile, generate-index.sh, dev-server.sh
- add README.md with full documentation
---
 CLAUDE.md                                     |   23 +-
 Makefile                                      |   59 +-
 README.md                                     |  203 +-
 courses/223015b/slides/01-grundlagen.md       | 2220 -----------------
 courses/223015b/slides/02-bild-audio-video.md | 1027 --------
 scripts/dev-server.sh                         |    6 +-
 scripts/extract-klausur.sh                    |  112 +
 scripts/generate-index.sh                     |   55 +-
 .../223015b/00-intro.md                       |    0
 .../223015b/01-grundlagen-text-audio.md       |    0
 .../223015b/02-bild-audio-video.md            |    0
 .../03-speichermedien-schnittstellen.md       |    2 +-
 .../223015b/04-distribution-apis-zukunft.md   |    2 +-
 .../223015b/05-vertiefung-offene-fragen.md    |    2 +-
 .../223015b}/assets/2011-hilbert.png          |  Bin
 .../223015b}/assets/8bit-P-character.png      |  Bin
 .../slides => slides/223015b}/assets/AV1.png  |  Bin
 .../assets/Asterisk_with_jpg-artefacts.png    |  Bin
 .../223015b}/assets/Barn-yuv.png              |  Bin
 ...subsampling_ratios_YCbCr_CORRECTED.svg.png |  Bin
 ...decrease_of_quality_-_JPEG_compression.jpg |  Bin
 .../223015b}/assets/Posterization_example.jpg |  Bin
 .../assets/addaptive-substractive-colors.jpg  |  Bin
 .../223015b}/assets/ascii-table-colored.png   |  Bin
 .../223015b}/assets/ascii-table.png           |  Bin
 .../223015b}/assets/audio-spectrogram.png     |  Bin
 .../223015b}/assets/av1-grammy-crop.png       |  Bin
 .../223015b}/assets/av1-grammy.png            |  Bin
 .../223015b}/assets/av1-logo.png              |  Bin
 .../223015b}/assets/bittorrent.png            |  Bin
 .../223015b}/assets/cassette-ipod.png         |  Bin
 .../223015b}/assets/compression-types.png     |  Bin
 .../assets/container-codec-diagram.png        |  Bin
 .../223015b}/assets/digital-landscape.png     |  Bin
 .../223015b}/assets/gif-animation.png         |  Bin
 .../223015b}/assets/grayscale-gradient.png    |  Bin
 .../223015b}/assets/growth of big data.png    |  Bin
 .../223015b}/assets/hex-binary-table.png      |  Bin
 .../223015b}/assets/hex-code-hidden.png       |  Bin
 .../223015b}/assets/hex-code.png              |  Bin
 .../223015b}/assets/hex-dec-lookup-table.png  |  Bin
 .../223015b}/assets/hexeditor-screenshot.png  |  Bin
 .../223015b}/assets/hollerith-machine-2.jpg   |  Bin
 .../223015b}/assets/iframe-pframe-diagram.png |  Bin
 .../assets/instagram-quality-loss.png         |  Bin
 .../223015b}/assets/ipb-compression-canon.jpg |  Bin
 .../223015b}/assets/jpeg-artifacts.png        |  Bin
 .../223015b}/assets/jung-naiv.png             |  Bin
 .../223015b}/assets/karlheinz-brandenburg.jpg |  Bin
 .../223015b}/assets/klausur-pattern.svg       |    0
 .../223015b}/assets/lightbulb-onoff.png       |  Bin
 .../223015b}/assets/matrix-code.png           |  Bin
 .../223015b}/assets/moores-law.png            |  Bin
 .../223015b}/assets/napster-2001.png          |  Bin
 .../223015b}/assets/napster-interface.png     |  Bin
 .../223015b}/assets/netflix-4k.png            |  Bin
 .../223015b}/assets/original-ascii-table.png  |  Bin
 .../223015b}/assets/photo-comparison.png      |  Bin
 .../223015b}/assets/qr/asciitable.png         |  Bin
 .../assets/qr/audacity-spectrogram.png        |  Bin
 .../223015b}/assets/qr/hexed-it.png           |  Bin
 .../223015b}/assets/qr/mediainfo.png          |  Bin
 .../223015b}/assets/qr/repo-223015b.png       |  Bin
 .../223015b}/assets/qr/slides-223015b.png     |  Bin
 .../223015b}/assets/qr/squoosh.png            |  Bin
 .../223015b}/assets/qrcode-0.svg              |    0
 .../223015b}/assets/qrcode-1.svg              |    0
 .../assets/quantized-image-8-colors.jpg       |  Bin
 .../radek-grzybowski-eBRTYyjwpRY-unsplash.jpg |  Bin
 .../assets/rgb-color-model-with-title.png     |  Bin
 .../223015b}/assets/rgb-color-model.png       |  Bin
 .../223015b}/assets/spectogram-chet-baker.png |  Bin
 .../assets/streaming-quality-switch.png       |  Bin
 .../223015b}/assets/suzanne-vega.jpg          |  Bin
 .../223015b}/assets/ybcbr.webp                |  Bin
 .../223015b}/assets/youtube-vp9.png           |  Bin
 slides/223015b/klausur.md                     |  563 +++++
 .../slides => slides/223015b}/materials/wtf1  |    0
 .../slides => slides/223015b}/materials/wtf2  |  Bin
 .../slides => slides/223015b}/materials/wtf3  |  Bin
 .../223015c/01-geschichte-grundlagen-html.md  |    0
 .../223015c/02-netzwerke-protokolle-css.md    |   20 +-
 .../223015c/03-interaktivitaet-javascript.md  |    4 +-
 .../223015c}/assets/8bit-P-character.png      |  Bin
 .../223015c}/assets/Ada_Lovelace.jpg          |  Bin
 ...type_by_Antoine_Claudet_1843_-_cropped.png |  Bin
 .../assets/Bletchley_Park_Mansion.jpg         |  Bin
 .../assets/First_Computer_Bug,_1947.jpg       |  Bin
 ...emini_Generated_Image_9an75b9an75b9an7.png |  Bin
 .../223015c}/assets/Grace_Hopper.jpg          |  Bin
 .../223015c}/assets/Hollerith.jpg             |  Bin
 .../IBM_Front_Cover_2021_from_Amazon.jpg      |  Bin
 .../223015c}/assets/alan-turing.jpg           |  Bin
 .../223015c}/assets/arpanet-1969.png          |  Bin
 .../223015c}/assets/arpanet.jpg               |  Bin
 .../223015c}/assets/background-termin-1.png   |  Bin
 .../223015c}/assets/background-termin-2.png   |  Bin
 .../223015c}/assets/background-termin-3.png   |  Bin
 .../223015c}/assets/dehomag-hollerith.webp    |  Bin
 .../223015c}/assets/eniac.avif                |  Bin
 .../223015c}/assets/hammilton-portrait.jpg    |  Bin
 .../223015c}/assets/hammilton.jpg             |  Bin
 .../223015c}/assets/hex-dec-lookup-table.png  |  Bin
 .../223015c}/assets/hollerith-machine-2.jpg   |  Bin
 .../223015c}/assets/hollerith-machine-3.jpg   |  Bin
 .../223015c}/assets/hollerith-machine.jpg     |  Bin
 .../223015c}/assets/hollerith-machine.tif     |  Bin
 .../223015c}/assets/john-von-neumann.png      |  Bin
 .../223015c}/assets/klausur-pattern.svg       |    0
 .../223015c}/assets/lightbulb-onoff.png       |  Bin
 .../223015c}/assets/oppenheimer.png           |  Bin
 .../223015c}/assets/qr/codepen.png            |  Bin
 .../223015c}/assets/qr/codescripsi.png        |  Bin
 .../223015c}/assets/qr/cssgridgarden.png      |  Bin
 .../223015c}/assets/qr/flexboxfroggy.png      |  Bin
 .../223015c}/assets/qr/freecodecamp.png       |  Bin
 .../223015c}/assets/qr/html-over-js.png       |  Bin
 .../223015c}/assets/qr/mandala.png            |  Bin
 .../223015c}/assets/qr/mdn-button.png         |  Bin
 .../223015c}/assets/qr/mdn-details.png        |  Bin
 .../223015c}/assets/qr/mdn-dialog.png         |  Bin
 .../223015c}/assets/qr/mdn-input.png          |  Bin
 .../223015c}/assets/qr/mdn.png                |  Bin
 .../223015c}/assets/qr/odinproject.png        |  Bin
 .../223015c}/assets/qr/repo-223015c.png       |  Bin
 .../223015c}/assets/qr/slides-223015c.png     |  Bin
 .../223015c}/assets/qr/vscode.png             |  Bin
 slides/223015c/klausur.md                     |  650 +++++
 128 files changed, 1464 insertions(+), 3484 deletions(-)
 delete mode 100644 courses/223015b/slides/01-grundlagen.md
 delete mode 100644 courses/223015b/slides/02-bild-audio-video.md
 create mode 100755 scripts/extract-klausur.sh
 rename courses/223015b/slides/2025-12-19-termin-0-intro.md => slides/223015b/00-intro.md (100%)
 rename courses/223015b/slides/2025-12-19-termin-1-grundlagen-text-audio.md => slides/223015b/01-grundlagen-text-audio.md (100%)
 rename courses/223015b/slides/2026-01-09-termin-2-bild-audio-video.md => slides/223015b/02-bild-audio-video.md (100%)
 rename courses/223015b/slides/2026-01-23-termin-3-speichermedien-schnittstellen.md => slides/223015b/03-speichermedien-schnittstellen.md (99%)
 rename courses/223015b/slides/2026-01-30-termin-4-distribution-apis-zukunft.md => slides/223015b/04-distribution-apis-zukunft.md (99%)
 rename courses/223015b/slides/2026-xx-xx-termin-5-vertiefung-offene-fragen.md => slides/223015b/05-vertiefung-offene-fragen.md (99%)
 rename {courses/223015b/slides => slides/223015b}/assets/2011-hilbert.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/8bit-P-character.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/AV1.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/Asterisk_with_jpg-artefacts.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/Barn-yuv.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/Common_chroma_subsampling_ratios_YCbCr_CORRECTED.svg.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/Felis_silvestris_silvestris_small_gradual_decrease_of_quality_-_JPEG_compression.jpg (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/Posterization_example.jpg (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/addaptive-substractive-colors.jpg (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/ascii-table-colored.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/ascii-table.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/audio-spectrogram.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/av1-grammy-crop.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/av1-grammy.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/av1-logo.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/bittorrent.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/cassette-ipod.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/compression-types.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/container-codec-diagram.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/digital-landscape.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/gif-animation.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/grayscale-gradient.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/growth of big data.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/hex-binary-table.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/hex-code-hidden.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/hex-code.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/hex-dec-lookup-table.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/hexeditor-screenshot.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/hollerith-machine-2.jpg (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/iframe-pframe-diagram.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/instagram-quality-loss.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/ipb-compression-canon.jpg (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/jpeg-artifacts.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/jung-naiv.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/karlheinz-brandenburg.jpg (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/klausur-pattern.svg (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/lightbulb-onoff.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/matrix-code.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/moores-law.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/napster-2001.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/napster-interface.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/netflix-4k.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/original-ascii-table.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/photo-comparison.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/qr/asciitable.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/qr/audacity-spectrogram.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/qr/hexed-it.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/qr/mediainfo.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/qr/repo-223015b.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/qr/slides-223015b.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/qr/squoosh.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/qrcode-0.svg (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/qrcode-1.svg (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/quantized-image-8-colors.jpg (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/rgb-color-model-with-title.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/rgb-color-model.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/spectogram-chet-baker.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/streaming-quality-switch.png (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/suzanne-vega.jpg (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/ybcbr.webp (100%)
 rename {courses/223015b/slides => slides/223015b}/assets/youtube-vp9.png (100%)
 create mode 100644 slides/223015b/klausur.md
 rename {courses/223015b/slides => slides/223015b}/materials/wtf1 (100%)
 rename {courses/223015b/slides => slides/223015b}/materials/wtf2 (100%)
 rename {courses/223015b/slides => slides/223015b}/materials/wtf3 (100%)
 rename courses/223015c/slides/2025-12-20-termin-1-geschichte-grundlagen-html.md => slides/223015c/01-geschichte-grundlagen-html.md (100%)
 rename courses/223015c/slides/2026-01-10-termin-2-netzwerke-protokolle-css.md => slides/223015c/02-netzwerke-protokolle-css.md (99%)
 rename courses/223015c/slides/2026-01-24-termin-3-interaktivitaet-javascript.md => slides/223015c/03-interaktivitaet-javascript.md (99%)
 rename {courses/223015c/slides => slides/223015c}/assets/8bit-P-character.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/Ada_Lovelace.jpg (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/Ada_Lovelace_daguerreotype_by_Antoine_Claudet_1843_-_cropped.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/Bletchley_Park_Mansion.jpg (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/First_Computer_Bug,_1947.jpg (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/Gemini_Generated_Image_9an75b9an75b9an7.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/Grace_Hopper.jpg (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/Hollerith.jpg (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/IBM_Front_Cover_2021_from_Amazon.jpg (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/alan-turing.jpg (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/arpanet-1969.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/arpanet.jpg (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/background-termin-1.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/background-termin-2.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/background-termin-3.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/dehomag-hollerith.webp (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/eniac.avif (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/hammilton-portrait.jpg (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/hammilton.jpg (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/hex-dec-lookup-table.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/hollerith-machine-2.jpg (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/hollerith-machine-3.jpg (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/hollerith-machine.jpg (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/hollerith-machine.tif (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/john-von-neumann.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/klausur-pattern.svg (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/lightbulb-onoff.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/oppenheimer.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/qr/codepen.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/qr/codescripsi.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/qr/cssgridgarden.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/qr/flexboxfroggy.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/qr/freecodecamp.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/qr/html-over-js.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/qr/mandala.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/qr/mdn-button.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/qr/mdn-details.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/qr/mdn-dialog.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/qr/mdn-input.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/qr/mdn.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/qr/odinproject.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/qr/repo-223015c.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/qr/slides-223015c.png (100%)
 rename {courses/223015c/slides => slides/223015c}/assets/qr/vscode.png (100%)
 create mode 100644 slides/223015c/klausur.md

diff --git a/CLAUDE.md b/CLAUDE.md
index a61e2bc..4a110b5 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -4,8 +4,8 @@ This project builds presentation decks for Marp, supporting multiple courses.
 
 ## Courses
 
-- **223015b** - Dateiformate, Schnittstellen, Speichermedien (6 Termine)
-- **223015c** - Internettechnologien (3 Termine)
+- **223015b** - Dateiformate, Schnittstellen, Speichermedien (6 Kapitel)
+- **223015c** - Internettechnologien (3 Kapitel)
 
 ## Agent Restrictions
 
@@ -15,7 +15,7 @@ This project builds presentation decks for Marp, supporting multiple courses.
 
 ## Critical File Protection
 
-Slide files in `courses/*/slides/*.md` are main content files:
+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
@@ -23,9 +23,9 @@ Slide files in `courses/*/slides/*.md` are main content files:
 ## Project Structure
 
 ```
-courses/
-├── 223015b/slides/     # Dateiformate course
-└── 223015c/slides/     # Internettechnik course
+slides/
+├── 223015b/            # Dateiformate course
+└── 223015c/            # Internettechnik course
 scripts/                # Shared scripts
 themes/                 # Custom Marp themes
 build/                  # Generated output (gitignored)
@@ -34,13 +34,14 @@ build/                  # Generated output (gitignored)
 ## Build Commands
 
 ```bash
-make dev-b          # Dev server 223015b (port 1312)
-make dev-c          # Dev server 223015c (port 1313)
+make dev-b          # Dev server 223015b (port 1311)
+make dev-c          # Dev server 223015c (port 1312)
 make build          # Build all courses
 make build-b        # Build 223015b only
 make build-c        # Build 223015c only
 make html           # HTML only
 make pdf            # PDF only
+make klausur        # Extract klausur slides → slides/*/klausur.md
 make deploy         # Deploy all (ASK FIRST!)
 ```
 
@@ -56,12 +57,12 @@ nix run .#optimize-img -- <path>      # Optimize images
 ## Code Style Guidelines
 
 ### File Structure
-- Slides in `courses/<course>/slides/`
-- Assets in `courses/<course>/slides/assets/`
+- Slides in `slides/<course>/`
+- Assets in `slides/<course>/assets/`
 - Always reference images as `./assets/filename.png`
 
 ### Naming Conventions
-- Slide files: `YYYY-MM-DD-termin-N-topic.md`
+- Slide files: `NN-topic.md` (e.g., `01-grundlagen.md`)
 - Images: `snake_case.jpg` or `kebab-case.jpg`
 
 ### Markdown Style
diff --git a/Makefile b/Makefile
index 37c3bd0..9aecbfc 100644
--- a/Makefile
+++ b/Makefile
@@ -1,11 +1,11 @@
 # HdM Slides - Unified Makefile
 # Supports multiple courses: 223015b (Dateiformate) and 223015c (Internettechnik)
 
-.PHONY: help dev dev-b dev-c build build-b build-c pdf html clean install deploy qr optimize-images
+.PHONY: help dev dev-b dev-c build build-b build-c pdf html klausur clean install deploy qr optimize-images
 
 # Course configuration
 COURSES = 223015b 223015c
-COURSE_DIR = courses
+SLIDES_DIR = slides
 
 # Port configuration (index starts at BASE_PORT, courses increment from there)
 BASE_PORT = 1310
@@ -14,12 +14,12 @@ INDEX_PORT = $(BASE_PORT)
 # Course-specific settings
 223015b_NAME = Dateiformate, Schnittstellen, Speichermedien
 223015b_PORT = 1311
-223015b_TERMINS = 2025-12-19-termin-0-intro 2025-12-19-termin-1-grundlagen-text-audio 2026-01-09-termin-2-bild-audio-video 2026-01-23-termin-3-speichermedien-schnittstellen 2026-01-30-termin-4-distribution-apis-zukunft 2026-xx-xx-termin-5-vertiefung-offene-fragen
+223015b_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen
 223015b_DEPLOY_PATH = /home/tengo/html/hdm/223015b
 
 223015c_NAME = Internettechnologien
 223015c_PORT = 1312
-223015c_TERMINS = 2025-12-20-termin-1-geschichte-grundlagen-html 2026-01-10-termin-2-netzwerke-protokolle-css 2026-01-24-termin-3-interaktivitaet-javascript
+223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript
 223015c_DEPLOY_PATH = /home/tengo/html/hdm/223015c
 
 DEPLOY_HOST = tengo@tuttle.uberspace.de
@@ -43,6 +43,7 @@ help:
 	@echo "  make build-c     - Build 223015c only"
 	@echo "  make pdf         - Export all to PDF"
 	@echo "  make html        - Export all to HTML"
+	@echo "  make klausur     - Extract klausur slides"
 	@echo ""
 	@echo "Tools:"
 	@echo "  make qr URL=...  - Generate QR code for URL"
@@ -74,24 +75,24 @@ dev-kill:
 dev-b:
 	@echo "Starting 223015b dev server on port $(223015b_PORT)..."
 	@echo "Open: http://localhost:$(223015b_PORT)"
-	PORT=$(223015b_PORT) npx @marp-team/marp-cli --server $(COURSE_DIR)/223015b/slides/
+	PORT=$(223015b_PORT) npx @marp-team/marp-cli --server $(SLIDES_DIR)/223015b/
 
 dev-c:
 	@echo "Starting 223015c dev server on port $(223015c_PORT)..."
 	@echo "Open: http://localhost:$(223015c_PORT)"
-	PORT=$(223015c_PORT) npx @marp-team/marp-cli --server $(COURSE_DIR)/223015c/slides/
+	PORT=$(223015c_PORT) npx @marp-team/marp-cli --server $(SLIDES_DIR)/223015c/
 
 # Build functions
 define build_course
 	@echo "Building $(1)..."
 	@mkdir -p build/$(1)
-	@cp -r $(COURSE_DIR)/$(1)/slides/assets build/$(1)/ 2>/dev/null || true
-	@cp -r $(COURSE_DIR)/$(1)/slides/materials build/$(1)/ 2>/dev/null || true
-	@for f in $($(1)_TERMINS); do \
-		if [ -f "$(COURSE_DIR)/$(1)/slides/$$f.md" ]; then \
+	@cp -r $(SLIDES_DIR)/$(1)/assets build/$(1)/ 2>/dev/null || true
+	@cp -r $(SLIDES_DIR)/$(1)/materials build/$(1)/ 2>/dev/null || true
+	@for f in $($(1)_KAPITEL); do \
+		if [ -f "$(SLIDES_DIR)/$(1)/$$f.md" ]; then \
 			echo "  Building $$f..."; \
-			npx @marp-team/marp-cli $(COURSE_DIR)/$(1)/slides/$$f.md -o build/$(1)/$$f.html; \
-			npx @marp-team/marp-cli $(COURSE_DIR)/$(1)/slides/$$f.md --pdf --allow-local-files -o build/$(1)/$$f.pdf; \
+			npx @marp-team/marp-cli $(SLIDES_DIR)/$(1)/$$f.md -o build/$(1)/$$f.html; \
+			npx @marp-team/marp-cli $(SLIDES_DIR)/$(1)/$$f.md --pdf --allow-local-files -o build/$(1)/$$f.pdf; \
 		fi \
 	done
 	@./scripts/generate-index.sh $(1) build/$(1)
@@ -110,12 +111,12 @@ build: build-b build-c
 define html_course
 	@echo "Building HTML for $(1)..."
 	@mkdir -p build/$(1)
-	@cp -r $(COURSE_DIR)/$(1)/slides/assets build/$(1)/ 2>/dev/null || true
-	@cp -r $(COURSE_DIR)/$(1)/slides/materials build/$(1)/ 2>/dev/null || true
-	@for f in $($(1)_TERMINS); do \
-		if [ -f "$(COURSE_DIR)/$(1)/slides/$$f.md" ]; then \
+	@cp -r $(SLIDES_DIR)/$(1)/assets build/$(1)/ 2>/dev/null || true
+	@cp -r $(SLIDES_DIR)/$(1)/materials build/$(1)/ 2>/dev/null || true
+	@for f in $($(1)_KAPITEL); do \
+		if [ -f "$(SLIDES_DIR)/$(1)/$$f.md" ]; then \
 			echo "  $$f.html"; \
-			npx @marp-team/marp-cli $(COURSE_DIR)/$(1)/slides/$$f.md -o build/$(1)/$$f.html; \
+			npx @marp-team/marp-cli $(SLIDES_DIR)/$(1)/$$f.md -o build/$(1)/$$f.html; \
 		fi \
 	done
 	@./scripts/generate-index.sh $(1) build/$(1)
@@ -133,10 +134,10 @@ html: html-b html-c
 define pdf_course
 	@echo "Building PDFs for $(1)..."
 	@mkdir -p build/$(1)
-	@for f in $($(1)_TERMINS); do \
-		if [ -f "$(COURSE_DIR)/$(1)/slides/$$f.md" ]; then \
+	@for f in $($(1)_KAPITEL); do \
+		if [ -f "$(SLIDES_DIR)/$(1)/$$f.md" ]; then \
 			echo "  $$f.pdf"; \
-			npx @marp-team/marp-cli $(COURSE_DIR)/$(1)/slides/$$f.md --pdf --allow-local-files -o build/$(1)/$$f.pdf; \
+			npx @marp-team/marp-cli $(SLIDES_DIR)/$(1)/$$f.md --pdf --allow-local-files -o build/$(1)/$$f.pdf; \
 		fi \
 	done
 endef
@@ -149,6 +150,16 @@ pdf-c: build/.exists
 
 pdf: pdf-b pdf-c
 
+# Klausur slide extraction
+klausur-b:
+	@./scripts/extract-klausur.sh 223015b
+
+klausur-c:
+	@./scripts/extract-klausur.sh 223015c
+
+klausur: klausur-b klausur-c
+	@echo "Klausur slides extracted for all courses!"
+
 # QR Code generation (uses nix-shell)
 qr:
 ifndef URL
@@ -174,9 +185,9 @@ ifndef COURSE
 	@echo "Usage: make optimize-images COURSE=223015b"
 else
 	@echo "Optimizing images for $(COURSE)..."
-	@mkdir -p $(COURSE_DIR)/$(COURSE)/slides/assets-original
-	@nix-shell -p imagemagick --run 'for img in $(COURSE_DIR)/$(COURSE)/slides/assets/*.png $(COURSE_DIR)/$(COURSE)/slides/assets/*.jpg 2>/dev/null; do \
-		[ -f "$$img" ] && cp "$$img" $(COURSE_DIR)/$(COURSE)/slides/assets-original/ && \
+	@mkdir -p $(SLIDES_DIR)/$(COURSE)/assets-original
+	@nix-shell -p imagemagick --run 'for img in $(SLIDES_DIR)/$(COURSE)/assets/*.png $(SLIDES_DIR)/$(COURSE)/assets/*.jpg 2>/dev/null; do \
+		[ -f "$$img" ] && cp "$$img" $(SLIDES_DIR)/$(COURSE)/assets-original/ && \
 		magick "$$img" -resize "1920x>" -quality 85 "$$img" && echo "  Optimized: $$(basename $$img)"; \
 	done || true'
 	@echo "Done! Originals in assets-original/"
@@ -187,7 +198,7 @@ HDM_DEPLOY_PATH = /home/tengo/html/hdm
 
 build-index: build/.exists
 	@echo "Building root index..."
-	@echo '<!DOCTYPE html><html lang="de"><head><meta charset="UTF-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>HdM Vorlesungen</title><style>*{box-sizing:border-box;margin:0;padding:0}body{font-family:-apple-system,BlinkMacSystemFont,"SF Pro Display","Segoe UI",Roboto,sans-serif;max-width:720px;margin:0 auto;padding:3rem 1.5rem;background:#fafafa;color:#1d1d1f;line-height:1.5}h1{font-size:2rem;font-weight:600;letter-spacing:-0.02em;margin-bottom:.5rem}.subtitle{color:#86868b;font-size:1rem}.courses{margin-top:2rem;display:flex;flex-direction:column;gap:.75rem}a.course{display:block;background:#fff;border-radius:12px;padding:1.5rem;text-decoration:none;color:inherit;box-shadow:0 1px 3px rgba(0,0,0,0.08);transition:all .2s ease;cursor:pointer}a.course:hover{transform:translateY(-2px);box-shadow:0 4px 12px rgba(0,0,0,0.12)}.course-label{font-size:.7rem;font-weight:600;text-transform:uppercase;letter-spacing:.05em}.course-b .course-label{color:#1e5f8a}.course-c .course-label{color:#d63384}.course-title{font-size:1.15rem;font-weight:500;color:#1d1d1f;margin:.25rem 0}.course-info{font-size:.85rem;color:#86868b}.section-title{font-size:1rem;font-weight:600;color:#86868b;margin-top:2.5rem;margin-bottom:.75rem}.references{display:flex;flex-direction:column;gap:.75rem}footer{margin-top:2.5rem;padding-top:1.5rem;border-top:1px solid #e5e5e7;color:#86868b;font-size:.85rem}footer a{color:#1d1d1f;text-decoration:none}footer a:hover{text-decoration:underline}.qr-section{margin-top:2.5rem;padding:1.5rem;background:#fff;border-radius:12px;box-shadow:0 1px 3px rgba(0,0,0,0.08);text-align:center}.qr-code{width:100%;height:auto}.qr-url{margin-top:.75rem;font-size:.85rem;color:#86868b}</style></head><body><h1>HdM Vorlesungen</h1><p class="subtitle">Wintersemester 2025/26 · Michael Czechowski</p><div class="courses"><a class="course course-b" href="223015b/"><span class="course-label">223015b</span><div class="course-title">Dateiformate, Schnittstellen, Speichermedien & Distributionswege</div><span class="course-info">6 Termine · Modul "Technik 1"</span></a><a class="course course-c" href="223015c/"><span class="course-label">223015c</span><div class="course-title">Grundlagen IT- und Internettechnik</div><span class="course-info">3 Termine · Modul "Technik 1"</span></a></div><h2 class="section-title">Referenzen</h2><div class="references"><a class="course" href="https://codecrispi.es/"><span class="course-label">Plattform</span><div class="course-title">Code Crispies</div><span class="course-info">Selbstlernplattform</span></a></div><div class="qr-section"><img src="qr-root.svg" alt="QR Code" class="qr-code"><p class="qr-url">https://librete.ch/hdm/</p></div><footer><a href="mailto:mail@librete.ch">Kontakt</a></footer></body></html>' > build/index.html
+	@echo '<!DOCTYPE html><html lang="de"><head><meta charset="UTF-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>HdM Vorlesungen</title><style>*{box-sizing:border-box;margin:0;padding:0}body{font-family:-apple-system,BlinkMacSystemFont,"SF Pro Display","Segoe UI",Roboto,sans-serif;max-width:720px;margin:0 auto;padding:3rem 1.5rem;background:#fafafa;color:#1d1d1f;line-height:1.5}h1{font-size:2rem;font-weight:600;letter-spacing:-0.02em;margin-bottom:.5rem}.subtitle{color:#86868b;font-size:1rem}.courses{margin-top:2rem;display:flex;flex-direction:column;gap:.75rem}a.course{display:block;background:#fff;border-radius:12px;padding:1.5rem;text-decoration:none;color:inherit;box-shadow:0 1px 3px rgba(0,0,0,0.08);transition:all .2s ease;cursor:pointer}a.course:hover{transform:translateY(-2px);box-shadow:0 4px 12px rgba(0,0,0,0.12)}.course-label{font-size:.7rem;font-weight:600;text-transform:uppercase;letter-spacing:.05em}.course-b .course-label{color:#1e5f8a}.course-c .course-label{color:#d63384}.course-title{font-size:1.15rem;font-weight:500;color:#1d1d1f;margin:.25rem 0}.course-info{font-size:.85rem;color:#86868b}.section-title{font-size:1rem;font-weight:600;color:#86868b;margin-top:2.5rem;margin-bottom:.75rem}.references{display:flex;flex-direction:column;gap:.75rem}footer{margin-top:2.5rem;padding-top:1.5rem;border-top:1px solid #e5e5e7;color:#86868b;font-size:.85rem}footer a{color:#1d1d1f;text-decoration:none}footer a:hover{text-decoration:underline}.qr-section{margin-top:2.5rem;padding:1.5rem;background:#fff;border-radius:12px;box-shadow:0 1px 3px rgba(0,0,0,0.08);text-align:center}.qr-code{width:100%;height:auto}.qr-url{margin-top:.75rem;font-size:.85rem;color:#86868b}</style></head><body><h1>HdM Vorlesungen</h1><p class="subtitle">Wintersemester 2025/26 · Michael Czechowski</p><div class="courses"><a class="course course-b" href="223015b/"><span class="course-label">223015b</span><div class="course-title">Dateiformate, Schnittstellen, Speichermedien & Distributionswege</div><span class="course-info">6 Kapitel · Modul "Technik 1"</span></a><a class="course course-c" href="223015c/"><span class="course-label">223015c</span><div class="course-title">Grundlagen IT- und Internettechnik</div><span class="course-info">3 Kapitel · Modul "Technik 1"</span></a></div><h2 class="section-title">Referenzen</h2><div class="references"><a class="course" href="https://codecrispi.es/"><span class="course-label">Plattform</span><div class="course-title">Code Crispies</div><span class="course-info">Selbstlernplattform</span></a></div><div class="qr-section"><img src="qr-root.svg" alt="QR Code" class="qr-code"><p class="qr-url">https://librete.ch/hdm/</p></div><footer><a href="mailto:mail@librete.ch">Kontakt</a></footer></body></html>' > build/index.html
 
 # Deploy
 define deploy_course
diff --git a/README.md b/README.md
index 95902cd..21f410c 100644
--- a/README.md
+++ b/README.md
@@ -1,182 +1,95 @@
 # HdM Slides
 
-**Modul "Technik 1"** - 1. Semester - Digital- und Medienwirtschaft
-Hochschule der Medien Stuttgart - Wintersemester 2025/26
+Presentation slides for HdM Stuttgart courses, built with [Marp](https://marp.app/).
 
----
+## Courses
 
-## Kurse
+| Code | Title | Kapitel |
+|------|-------|---------|
+| 223015b | Dateiformate, Schnittstellen, Speichermedien | 6 |
+| 223015c | Internettechnologien | 3 |
 
-### 223015b - Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+## Project Structure
 
-| # | Datum | Thema |
-|---|-------|-------|
-| 0 | 19.12.2025 | Intro |
-| 1 | 19.12.2025 | Grundlagen, Text & Audio |
-| 2 | 09.01.2026 | Bild- & Videoformate |
-| 3 | 23.01.2026 | Speichermedien & Schnittstellen |
-| 4 | 30.01.2026 | Distribution, APIs & Zukunft |
-| 5 | TBA | Vertiefung & offene Fragen |
-
-### 223015c - Internettechnologien
-
-| # | Datum | Thema |
-|---|-------|-------|
-| 1 | 20.12.2025 | Geschichte, Grundlagen & HTML |
-| 2 | 10.01.2026 | Netzwerke, Protokolle & CSS |
-| 3 | 24.01.2026 | Interaktivitat & JavaScript |
-
-**Dozent:** Michael Czechowski - mail@librete.ch
-
----
-
-## Quick Start
-
-### Mit Nix (empfohlen)
-
-```bash
-# Development shell mit allen Tools
-nix develop
-
-# Oder direkt QR-Code generieren
-nix run .#qr -- "https://example.com"
-nix run .#qr-slides -- 223015b
 ```
-
-### Ohne Nix
-
-```bash
-npm install
-make dev-b   # 223015b auf Port 1312
-make dev-c   # 223015c auf Port 1313
+slides/
+├── 223015b/          # Dateiformate course
+│   ├── 00-intro.md
+│   ├── 01-grundlagen-text-audio.md
+│   └── ...
+└── 223015c/          # Internettechnik course
+    ├── 01-geschichte-grundlagen-html.md
+    └── ...
+scripts/              # Build scripts
+build/                # Generated output (gitignored)
 ```
 
----
-
 ## Development
 
-### Dev Server starten
-
 ```bash
-make dev-b   # 223015b (Dateiformate) - http://localhost:1312
-make dev-c   # 223015c (Internettechnik) - http://localhost:1313
+# Start dev servers (hot reload)
+make dev              # All courses + index
+make dev-b            # 223015b only (port 1311)
+make dev-c            # 223015c only (port 1312)
 ```
 
-### Build
+## Build
 
 ```bash
-make build      # Alle Kurse (HTML + PDF)
-make build-b    # Nur 223015b
-make build-c    # Nur 223015c
-make html       # Nur HTML
-make pdf        # Nur PDF
+make build            # Build all (HTML + PDF)
+make build-b          # Build 223015b only
+make build-c          # Build 223015c only
+make html             # HTML only
+make pdf              # PDF only
 ```
 
-### Deploy
+## Klausur Slides
+
+Extract exam-relevant slides (marked with `<!-- _class: klausur -->`) into a single file:
 
 ```bash
-make deploy     # Alle Kurse
-make deploy-b   # Nur 223015b
-make deploy-c   # Nur 223015c
+make klausur          # Extract all courses
+make klausur-b        # 223015b only
+make klausur-c        # 223015c only
 ```
 
----
+Output: `slides/<course>/klausur.md`
+
+The generated file includes:
+- A title slide per kapitel for orientation
+- All slides marked with `<!-- _class: klausur -->`
 
 ## Tools
 
-### QR-Code Generator
+```bash
+make qr URL=https://example.com           # Generate QR code
+make qr-slides COURSE=223015b             # QR for course URL
+make optimize-images COURSE=223015b       # Resize images
+```
+
+## Deploy
 
 ```bash
-# Mit Nix
-nix run .#qr -- "https://librete.ch/hdm/223015b/"
-nix run .#qr -- "https://example.com" output.png
-
-# Mit Make
-make qr URL=https://example.com
-make qr URL=https://example.com OUTPUT=my-qr.png
-
-# Fur Kurse
-make qr-slides COURSE=223015b
+make deploy           # Deploy all courses
+make deploy-b         # Deploy 223015b only
+make deploy-c         # Deploy 223015c only
 ```
 
-### Bilder optimieren
+## Marking Slides as Klausur-Relevant
 
-```bash
-# Mit Nix
-nix run .#optimize-img -- courses/223015b/slides/assets/
-
-# Mit Make
-make optimize-images COURSE=223015b
-```
-
----
-
-## Projektstruktur
-
-```
-hdm/
-├── courses/
-│   ├── 223015b/
-│   │   └── slides/
-│   │       ├── 2025-12-19-termin-1-grundlagen-text-audio.md
-│   │       ├── assets/
-│   │       └── materials/
-│   └── 223015c/
-│       └── slides/
-│           ├── 2025-12-20-termin-1-geschichte-grundlagen-html.md
-│           └── assets/
-├── scripts/
-│   └── generate-index.sh
-├── themes/
-│   └── custom-theme.css
-├── build/           # Generated output
-├── flake.nix        # Nix flake with tools
-├── Makefile
-└── package.json
-```
-
----
-
-## Slides erstellen
-
-### Frontmatter
-
-```yaml
----
-marp: true
-theme: uncover
-paginate: true
-backgroundColor: #fff
----
-```
-
-### Slide-Trennung
+Add this comment block after the slide separator:
 
 ```markdown
-# Slide 1
-
-Content
-
 ---
 
-# Slide 2
+<!-- _class: klausur -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+<!-- _backgroundColor: #e3f2fd -->
 
-More content
+# Your Slide Title
+
+Content here...
 ```
 
-### Bilder
-
-```markdown
-![Alt text](./assets/image.jpg)
-```
-
-### Themes
-
-Built-in: `default`, `gaia`, `uncover`
-Custom: in `themes/` Verzeichnis
-
----
-
-## License
-
-[CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/)
+The `klausur` class adds a visual indicator (diagonal stripes) during presentation.
diff --git a/courses/223015b/slides/01-grundlagen.md b/courses/223015b/slides/01-grundlagen.md
deleted file mode 100644
index 40da4dc..0000000
--- a/courses/223015b/slides/01-grundlagen.md
+++ /dev/null
@@ -1,2220 +0,0 @@
----
-marp: true
-theme: gaia
-paginate: true
-backgroundColor: #fff
-header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
-footer: "Michael Czechowski – HdM Stuttgart"
-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: #1a1a2e;
-  color: #5fb3e4;
-  padding: 0.15em 0.4em;
-  border-radius: 4px;
-}
-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
-
-[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
-
-<!--
-## Kontext
-Dies ist die erste von drei Blocksitzungen, die sich mit den technischen Grundlagen digitaler Medien beschäftigen. Im Gesamtmodul "Technik 1" lernen Studierende über Computer, IT-Systeme und Netzwerke – unsere Veranstaltung konzentriert sich spezifisch auf **Daten**: Wie werden sie repräsentiert, gespeichert, komprimiert und übertragen?
-
-## Kernaussagen
-1. Diese Vorlesung fokussiert sich auf die **Speicher-Perspektive** der Von-Neumann-Architektur.
-2. Wir behandeln drei grundlegende Themenblöcke: Dateiformate (Repräsentation), Speichermedien (Hardware) und Schnittstellen (Übertragung).
-3. Der rote Faden: Das menschliche Bedürfnis zu speichern trifft auf die physikalische Realität begrenzter Ressourcen.
-
-## Erklärung
-Die Vorlesung ist in drei Termine gegliedert:
-- **Termin 1** (heute): Grundlagen der Datendarstellung, Textkodierung und Audio-Kompression
-- **Termin 2**: Bild- und Videoformate
-- **Termin 3**: Speichermedien, Dateisysteme und Schnittstellen
-
-Der didaktische Ansatz: Wir beginnen mit fundamentalen Konzepten (Was ist ein digitales Signal?) und arbeiten uns zu praktischen Anwendungen vor (Warum sieht mein Instagram-Foto so verpixelt aus?). Theoretisches Verständnis ermöglicht informierte Entscheidungen in der Medienproduktion.
-
-## Vertiefung
-Die Studierenden im Studiengang Digital- und Medienwirtschaft werden später keine Codecs programmieren, aber sie werden entscheiden müssen: Welches Format für welchen Anwendungsfall? Wie organisiere ich Archivierung? Welche Qualitätsstufe für welches Budget? Diese Entscheidungen erfordern konzeptionelles Verständnis der zugrundeliegenden Technologien.
-
-Das Modul ist bewusst **nicht programming-focused**. Es gibt Hands-on-Elemente am Ende jeder Session, aber der Schwerpunkt liegt auf Konzeptvermittlung. Die Zielgruppe sind zukünftige Medienproduzent:innen, Projektmanager:innen und Entscheidungsträger:innen – nicht primär Entwickler:innen.
-
-## Literatur
-Pohlmann, K. C. (2010). *Principles of Digital Audio* (6th ed.). McGraw-Hill.
-Sayood, K. (2017). *Introduction to Data Compression* (5th ed.). Morgan Kaufmann.
--->
-
----
-
-![bg fit](./assets/qrcode-1.svg)
-
-<!--
-## Kontext
-QR-Code zur Kurswebsite, wo alle Materialien, Folien und weiterführende Ressourcen verfügbar sind.
-
-## Kernaussagen
-1. Alle Kursmaterialien sind unter einer offenen Lizenz verfügbar.
-2. Die Website enthält Links zu vertiefenden Ressourcen, Tools und Selbstlern-Übungen.
-3. Studierende können die Materialien jederzeit nachlesen und für eigene Projekte nutzen.
-
-## Erklärung
-Die Kurswebsite (librete.ch/hdm/223015b/) dient als zentraler Hub für alle Ressourcen. Dort finden sich:
-- PDF-Versionen der Folien
-- Speaker Notes in ausformulierter Form
-- Verweise auf Open-Source-Tools (Audacity, FFmpeg, MediaInfo)
-- Weiterführende Literatur und Paper
-- Selbstlern-Aufgaben mit Lösungshinweisen
-
-Die Materialien stehen unter Creative Commons Lizenz (BY-SA 4.0), d.h. Studierende dürfen sie frei verwenden, remixen und weitergeben – auch für kommerzielle Zwecke, solange Attribution gegeben wird.
-
-## Vertiefung
-Open Educational Resources (OER) sind ein wichtiges Prinzip in der digitalen Bildung. Gerade bei technischen Themen, die sich schnell weiterentwickeln, ist es sinnvoll, Materialien kontinuierlich zu aktualisieren und der Community zur Verfügung zu stellen. Studierende profitieren davon, dass sie nicht nur konsumieren, sondern auch beitragen können (z.B. durch Fehlerberichte, Ergänzungen).
-
-Die Wahl von librete.ch als Domain reflektiert die Philosophie: "librete" (Esperanto für "frei") + ".ch" (Schweiz als neutraler Ort für Wissensaustausch).
--->
-
----
-
-<!-- _class: lead -->
-
-# Teil 1: Einführung
-## Grundlagen, Text & Audio
-
-<!--
-## Kontext
-Der erste Teil der Vorlesung legt die konzeptionellen Grundlagen. Wir klären fundamentale Fragen: Was bedeutet "digital"? Wie werden physische Phänomene in Daten verwandelt? Warum ist Kompression notwendig?
-
-## Kernaussagen
-1. Teil 1 deckt die fundamentalen Konzepte ab, die für alle weiteren Termine gelten.
-2. Wir fokussieren auf Text und Audio als Einstieg, weil sie konzeptionell einfacher sind als Bild/Video.
-3. Das Verständnis von Sampling, Quantisierung und Kompression hier ist essentiell für Termin 2 (Bild/Video).
-
-## Erklärung
-Die Strukturierung "Text → Audio → Bild → Video" folgt einer Logik steigender Komplexität:
-- **Text**: Diskret von Natur aus (endliches Alphabet), einfachste Kodierung
-- **Audio**: Kontinuierlich → diskret (1-dimensional: nur Zeit)
-- **Bild**: Kontinuierlich → diskret (2-dimensional: Raum)
-- **Video**: Kontinuierlich → diskret (3-dimensional: Raum + Zeit)
-
-Didaktisch sinnvoll: Konzepte einmal verstehen (bei Audio), dann Transfer auf komplexere Domäne (Video).
-
-## Überleitung
-Bevor wir in technische Details gehen: Warum gibt es diese Vorlesung überhaupt? Was ist das fundamentale Problem, das wir lösen müssen?
--->
-
----
-
-<!-- _class: lead -->
-
-# I. Einführung: Warum diese Vorlesung?
-
-<!--
-## Kontext
-Studierende müssen verstehen, wo diese Vorlesung im Gesamtkontext des Moduls und ihres Studiums steht. Die Motivation muss klar sein: Warum investieren wir Zeit in diese Themen?
-
-## Kernaussagen
-1. Diese Vorlesung behandelt einen spezifischen Aspekt von IT-Systemen: **Daten und ihre Speicherung**.
-2. Das fundamentale Problem: Menschen produzieren exponentiell wachsende Datenmengen, aber Speicher ist begrenzt und kostet Geld.
-3. Kompression ist keine optionale Optimierung, sondern **ökonomische und physikalische Notwendigkeit**.
-
-## Erklärung
-Die drei Termine bauen aufeinander auf:
-1. **Wie werden Daten repräsentiert?** (Kodierung, Digitalisierung)
-2. **Wie werden Daten komprimiert?** (Verlustfrei und verlustbehaftet)
-3. **Wo werden Daten gespeichert und wie übertragen?** (Hardware, Schnittstellen)
-
-Diese Fragen sind relevant für jede Medienproduktion: Eine Fotografin muss entscheiden, ob sie RAW oder JPEG speichert. Ein Videoproduzent muss wissen, welcher Codec für welche Plattform optimal ist. Ein Projektmanager muss Speicherkosten kalkulieren.
-
-## Vertiefung
-Die Vorlesung könnte auch "Angewandte Informationstheorie für Medienschaffende" heißen. Wir behandeln Konzepte aus Claude Shannons Informationstheorie (1948), aber immer mit Blick auf praktische Anwendung. Die theoretischen Grundlagen (Entropie, Kodierung, Kanalkapazität) werden nur so weit eingeführt, wie sie für Verständnis nötig sind – keine mathematischen Beweise, aber konzeptionelle Klarheit.
--->
-
----
-
-# Verortung im Modul
-
-**Modul "Technik 1":**
-- Computer & IT-Systeme
-- Netzwerke & Protokolle
-- **→ Unsere Vorlesung: Daten auf dem Computer**
-
-**Unser Fokus:**
-- Von-Neumann-Architektur: **Speicher** (Memory)
-- Wie werden Daten repräsentiert?
-- Wie werden Daten gespeichert?
-- Wie werden Daten übertragen?
-
-<!--
-## Kontext
-Die Von-Neumann-Architektur ist das grundlegende Modell moderner Computer: CPU, Speicher, Ein-/Ausgabe. Andere Teile des Moduls behandeln CPU (Prozessoren, Befehlssätze) und I/O (Netzwerke). Wir konzentrieren uns auf **Speicher**.
-
-## Kernaussagen
-1. Die Von-Neumann-Architektur teilt Computer in funktionale Einheiten: CPU, Memory, I/O.
-2. Unsere Vorlesung fokussiert auf **Memory** – aber nicht die Hardware (RAM-Chips), sondern die **Daten**, die dort gespeichert werden.
-3. "Daten" bedeutet: Wie codiere ich Information so, dass sie speicherbar und übertragbar wird?
-
-## Erklärung
-Die Von-Neumann-Architektur (1945) definiert, dass Programme und Daten im gleichen Speicher liegen – im Gegensatz zu früheren "Fixed-Program"-Computern, die fest verdrahtet waren. Diese Architektur ermöglichte universal programmable computers.
-
-Unsere Perspektive:
-- **Nicht**: Wie funktioniert RAM? (Das ist Hardware-Vorlesung)
-- **Sondern**: Was speichere ich dort? In welchem Format? Wie effizient?
-
-Konkret: Eine MP3-Datei ist eine spezifische **Repräsentation** von Audio-Information. Die Datei liegt im Speicher als Bytefolge. Um sie zu verstehen, muss man wissen:
-1. Wie wurde das analoge Signal digitalisiert? (Sampling, Quantisierung)
-2. Wie wurde es komprimiert? (Psychoakustik, Huffman-Coding)
-3. Wie ist es in Bytes codiert? (MP3-Container-Format)
-
-## Vertiefung
-Die Von-Neumann-Architektur hat eine inhärente Limitation: den **Von-Neumann-Bottleneck**. CPU und Memory kommunizieren über einen Bus mit begrenzter Bandbreite. Moderne Systeme nutzen Caches (L1, L2, L3) als Puffer. Für uns relevant: Datengröße beeinflusst Performance. Eine unkomprimierte 4K-Video-Datei (45 GB/min) würde den Bus lahmlegen – Kompression ist also nicht nur für Speicherplatz, sondern auch für **Verarbeitungsgeschwindigkeit** essentiell.
-
-Alternative Architekturen (Harvard-Architektur: getrennte Speicher für Daten und Programme; moderne GPUs mit massiv-parallelem Speicherzugriff) ändern nichts an der Grundfrage: Wie repräsentiere ich Information effizient?
-
-## Literatur
-Von Neumann, J. (1945). "First Draft of a Report on the EDVAC." Moore School of Electrical Engineering, University of Pennsylvania.
--->
-
----
-
-# Das menschliche Bedürfnis zu speichern
-
-**Geschichte der Informationsspeicherung:**
-
-- **40.000 v. Chr.**: Höhlenmalereien (Lascaux, Altamira)
-- **3.200 v. Chr.**: Keilschrift auf Tontafeln (Mesopotamien)
-- **1450**: Gutenberg-Druckpresse (Buchdruck revolutioniert)
-- **1877**: Edison-Phonograph (erstmals Audio gespeichert)
-- **1950er**: Magnetbänder, Lochkarten
-- **1980er**: Festplatten, CDs
-- **2000er**: Flash-Speicher, Cloud
-
-→ Das Bedürfnis ist **anthropologisch konstant**
-→ Die Technologie entwickelt sich **exponentiell**
-
-<!--
-## Kontext
-Menschen haben schon immer Information gespeichert – für Kommunikation über Raum und Zeit. Die Erfindung der Schrift vor ~5000 Jahren war ein fundamentaler Zivilisationssprung. Die Digitalisierung ist der neueste, aber nicht der letzte Schritt in dieser Evolution.
-
-## Kernaussagen
-1. Informationsspeicherung ist ein **anthropologisches Grundbedürfnis** – neben Nahrung, Unterkunft, Kommunikation.
-2. Jede Technologie hat spezifische **Trade-offs**: Haltbarkeit, Kapazität, Zugriffsgeschwindigkeit, Kosten.
-3. Der Übergang von analog zu digital ist ein **Paradigmenwechsel**, kein gradueller Fortschritt.
-
-## Erklärung
-Warum speichern Menschen Information?
-- **Gedächtnis erweitern**: Externe Speicher kompensieren begrenzte kognitive Kapazität.
-- **Wissen weitergeben**: Über Generationen, über geografische Distanzen.
-- **Verträge/Gesetze**: Gesellschaftliche Koordination erfordert fixierte Regeln.
-- **Kunst/Kultur**: Ästhetische Erfahrungen konservieren.
-
-Die Technologie-Evolution zeigt ein Muster:
-1. **Kapazität steigt**: Von einem Buch (1 MB Text) zu einer Festplatte (20 TB = 20 Millionen Bücher)
-2. **Kosten sinken**: 1980 kostete 1 GB Speicher ~$200.000, heute ~$0.02
-3. **Zugriffsgeschwindigkeit steigt**: Von sequentiellem Zugriff (Tonband: spule vor) zu Random Access (SSD: sofort)
-4. **Haltbarkeit**: Hier kein klarer Trend – Tontafeln überleben Jahrtausende, Festplatten sterben nach ~5 Jahren
-
-## Vertiefung
-**Höhlenmalerei**: Die ältesten bekannten Informationsspeicher. Warum malten Menschen Tiere an Höhlenwände? Theorien: Rituale, Lehrmaterial (Jagdtechniken), Kunstausdruck. Wichtig: **Nicht-flüchtiger** Speicher – die Information überdauert den Schöpfer.
-
-**Keilschrift**: Erste bekannte Schrift (Sumerer, ~3200 v. Chr.). Zunächst für Buchhaltung (Lagerverwaltung), später Literatur (Gilgamesch-Epos, ~2100 v. Chr.). Medium: Tontafeln – extrem haltbar (viele Tausende überleben bis heute), aber sperrig, schwer zu transportieren.
-
-**Gutenberg**: Der Buchdruck (1450) demokratisierte Wissen. Vor Gutenberg: Ein Buch kopieren dauerte Monate, kostete ein Vermögen. Nach Gutenberg: Massenprodution, Wissensexplosion (Renaissance, Reformation, Wissenschaftliche Revolution).
-
-**Edison-Phonograph** (1877): Erstmals konnte **Audio** gespeichert werden – vorher war Musik nur live erlebbar. Wachszylinder ritzten Schallwellen ein (analog). Revolutionär: Musik wurde zur **Ware**.
-
-**Digitale Ära** (ab 1950er): Von Lochkarten (1 Bit = ein Loch) zu Festplatten (magnetische Domänen) zu Flash (Elektronen in Floating Gates). Die Gemeinsamkeit: **Diskrete Zustände** (0 oder 1), nicht kontinuierliche Signale.
-
-## Überleitung
-Die Geschichte zeigt: Jede neue Technologie löste ein Problem der vorherigen – aber schuf neue. Festplatten sind haltbarer als Kassetten, aber auch sie versagen. Die digitale Revolution verspricht **perfekte Kopien**, aber wie wir sehen werden, ist "digital" keine Magie – nur eine andere Art von Trade-offs.
-
-## Literatur
-Gleick, J. (2011). *The Information: A History, A Theory, A Flood*. Pantheon.
-McLuhan, M. (1964). *Understanding Media: The Extensions of Man*. McGraw-Hill.
--->
-
----
-
-# Der Paradigmenwechsel: Analog → Digital
-
-**Analog (vor ~1980):**
-- Information als **kontinuierliche physikalische Größe**
-- Beispiel: Schallplatte (Rille formt Schallwelle nach)
-- Problem: **Degradation** bei jedem Kopiervorgang
-
-**Digital (ab ~1980):**
-- Information als **diskrete Zahlenfolge** (0 und 1)
-- Beispiel: CD (Pits & Lands = Bits)
-- Vorteil: **Perfekte Kopien** möglich
-
-→ Nicht besser oder schlechter, sondern **fundamental anders**
-
-<!--
-## Kontext
-Der Übergang von analog zu digital war kein gradueller Fortschritt (wie von Pferd zu Auto), sondern ein **kategorialer Sprung** (wie von Materie zu Energie in der Physik). Es änderte sich die **Natur der Repräsentation**.
-
-## Kernaussagen
-1. Analog: Information ist **isomorph** zur Realität (die Rille sieht aus wie die Welle).
-2. Digital: Information ist **symbolisch** (Bits repräsentieren, ähneln aber nicht).
-3. Der Vorteil von Digital: **Fehlerkorrektur** und **verlustfreies Kopieren**.
-4. Der Nachteil von Digital: **Sampling-Verlust** und **Quantisierungsrauschen**.
-
-## Erklärung
-**Analog**: Die physikalische Eigenschaft des Speichermediums **korrespondiert** direkt zur gespeicherten Information. 
-- Schallplatte: Tiefe der Rille ~ Amplitude der Schallwelle
-- Thermometer: Höhe der Quecksilbersäule ~ Temperatur
-- Fotografie (Film): Dichte der Silberkristalle ~ Lichtintensität
-
-Analogie = Ähnlichkeit. Das Medium bildet die Realität **kontinuierlich** ab.
-
-**Digital**: Die Information wird in **diskrete Symbole** codiert (typischerweise Binärzahlen). Es gibt keine direkte physikalische Ähnlichkeit mehr.
-- CD: Ein "Pit" (Vertiefung) ist nicht lauter oder leiser – es ist einfach eine 1 (oder 0, je nach Konvention)
-- Festplatte: Eine magnetische Domäne zeigt nach Norden oder Süden – 0 oder 1
-
-Der radikale Unterschied: Bei analog gibt es **unendlich viele Zwischenwerte**. Bei digital gibt es nur **endlich viele diskrete Zustände**.
-
-## Vertiefung
-**Warum siegte Digital?**
-
-1. **Shannon's Theorem** (1948): In einem digitalen System kann man Fehler mit beliebiger Genauigkeit korrigieren – bei analog nicht. Wenn eine Schallplatte zerkratzt ist, ist die Information verloren. Wenn eine CD zerkratzt ist, können Error-Correction-Codes (Reed-Solomon) die Bits rekonstruieren.
-
-2. **Generationsverlust**: Kopiere eine Kassette → schlechter. Kopiere die Kopie → noch schlechter. Bei digital: Kopiere eine Datei → identisch. Kopiere die Kopie → identisch. Unendlich oft, ohne Qualitätsverlust (solange keine Bitfehler auftreten).
-
-3. **Rechenbarkeit**: Zahlen kann man addieren, filtern, transformieren. Analoge Signale sind schwerer zu manipulieren (analoge Equalizer erfordern physikalische Schaltungen). Digitale Filter sind Software → flexibel, präzise, wiederholbar.
-
-**Was verliert Digital?**
-
-1. **Kontinuität**: Zwischen Sample 1 und Sample 2 existiert nichts. Was passiert dort, ist verloren (außer man kann es rekonstruieren via Nyquist).
-
-2. **Unendliche Präzision**: Analog könnte theoretisch unendlich präzise sein (in der Praxis limitiert durch Rauschen). Digital ist immer auf **endliche Genauigkeit** beschränkt (z.B. 16-bit = 65.536 Stufen).
-
-3. **Natürlichkeit?**: Manche Audiophile behaupten, Vinyl klinge "wärmer". Wissenschaftlich fragwürdig (meist sind es harmonische Verzerrungen, die als angenehm empfunden werden), aber subjektive Wahrnehmung ist real.
-
-## Überleitung
-Dieser Paradigmenwechsel ist der Kern unserer Vorlesung. Um zu verstehen, wie MP3, JPEG, H.264 funktionieren, müssen wir zuerst verstehen: **Was bedeutet es überhaupt, dass etwas digital ist?**
-
-## Literatur
-Shannon, C. E. (1948). "A Mathematical Theory of Communication." Bell System Technical Journal, 27(3), 379–423.
-Katz, M. (2010). *Capturing Sound: How Technology Has Changed Music* (Revised ed.). University of California Press.
--->
-
----
-
-<!-- _class: lead -->
-
-# II. Von der Welt zu den Bits
-## Die drei Ebenen des Signals
-
-<!--
-## Kontext
-Dies ist die konzeptionell wichtigste Sektion der gesamten Vorlesung. Studierende müssen die Unterscheidung zwischen physisch, analog und digital **wirklich verstehen**, sonst bleiben alle folgenden Themen (Sampling, Kompression, Codecs) abstrakt und verwirr end.
-
-## Kernaussagen
-1. Es gibt drei fundamentale Ebenen der Signalrepräsentation: physisch, analog, digital.
-2. Jeder Übergang von einer Ebene zur nächsten ist ein **Übersetzungsakt** mit spezifischen Konsequenzen.
-3. Das Verständnis dieser Ebenen erklärt, warum Digitalisierung notwendig ist – und was dabei gewonnen und verloren wird.
-
-## Erklärung
-Wir werden nun jede der drei Ebenen detailliert durchgehen:
-1. **Physisches Signal**: Die Realität selbst (Schallwellen, Lichtwellen)
-2. **Analoges Signal**: Kontinuierliche Repräsentation in einem anderen Medium (Schallplatte, Thermometer)
-3. **Digitales Signal**: Diskrete Zahlenrepräsentation (CD, MP3)
-
-Diese Abfolge ist nicht historisch zwingend (moderne Kameras überspringen "analog" komplett), aber konzeptionell hilfreich.
-
-## Didaktischer Hinweis
-Erfahrungsgemäß ist dies der Punkt, wo Studierende entweder "Aha!" haben oder verloren gehen. Wichtig: **Konkrete Beispiele** durchgehen, nicht nur abstrakt bleiben. Die Sinuswellen-Visualisierung später wird helfen.
--->
-
----
-
-# Die drei Ebenen des Signals
-
-**1. Physisches Signal** – Die Realität
-**2. Analoges Signal** – Kontinuierliche Repräsentation
-**3. Digitales Signal** – Diskrete Repräsentation
-
-→ Jeder Übergang ist ein **Übersetzungsakt** mit **Konsequenzen**
-
-**Zentrale Frage:**
-Was gewinnen wir? Was verlieren wir?
-
-<!--
-## Kontext
-Diese Übersichtsfolie stellt die drei Ebenen vor. Die nächsten Folien gehen ins Detail.
-
-## Kernaussagen
-1. Drei Ebenen bilden die konzeptionelle Struktur für alles Folgende.
-2. "Übersetzungsakt" bedeutet: Kein Übergang ist verlustfrei oder neutral – jeder hat spezifische Trade-offs.
-3. Die zentrale Frage (Was gewinnen/verlieren wir?) wird uns durch die gesamte Vorlesung begleiten.
-
-## Erklärung
-Die Metapher des "Übersetzungsakts" ist bewusst gewählt: Wie bei der Übersetzung von Deutsch nach Englisch gibt es keine perfekte 1:1-Abbildung. Manche Nuancen gehen verloren, andere werden hinzugefügt. Manche Dinge lassen sich besser ausdrücken, andere schlechter.
-
-Physisch → Analog: Wir verlieren die "Originalität" (es ist nicht mehr die Schallwelle selbst, sondern eine Rille, die sie nachformt). Wir gewinnen Speicherbarkeit.
-
-Analog → Digital: Wir verlieren Kontinuität. Wir gewinnen Robustheit, Kopierbarkeit, Rechenbarkeit.
-
-## Vertiefung
-In der Philosophie gibt es eine Debatte über "Repräsentation": Kann eine Repräsentation jemals die Realität vollständig erfassen? (Spoiler: nein.) Platos Höhlengleichnis: Wir sehen nur Schatten der Wirklichkeit. In unserem Kontext: Ein digitales Signal ist ein "Schatten" des physischen Signals – aber ein sehr präziser, kontrollierbarer Schatten.
-
-Die Informationstheorie (Shannon) argumentiert: Solange die Repräsentation alle **relevante Information** bewahrt, ist sie äquivalent. "Relevanz" ist kontextabhängig: Für menschliches Hören sind Frequenzen über 20 kHz irrelevant – also können wir sie weglassen ohne "Informationsverlust" (im Shannon'schen Sinne).
-
-## Überleitung
-Lass uns jede Ebene im Detail anschauen.
--->
-
----
-
-# 1. Physisches Signal: Die Realität
-
-**Die Welt, wie sie ist**
-
-- Schallwellen in der Luft (Luftdruckschwankungen)
-- Lichtwellen (elektromagnetische Strahlung)
-- Temperatur, Bewegung, chemische Prozesse
-
-**Eigenschaften:**
-- ✓ Kontinuierlich in **Raum und Zeit**
-- ✓ Unendlich detailliert (theoretisch)
-- ✗ Direkt **nicht speicherbar**
-
-<!--
-## Kontext
-Physische Signale sind die Wirklichkeit selbst, bevor sie durch Messgeräte oder Sensoren vermittelt werden. Diese Ebene ist abstrakt, weil wir nie direkten Zugang haben – sobald wir messen, sind wir bereits auf der analogen oder digitalen Ebene.
-
-## Kernaussagen
-1. Physische Signale sind **ontologisch primär** – sie existieren unabhängig von Beobachtung.
-2. Sie sind kontinuierlich: Zwischen zwei beliebigen Zeitpunkten gibt es unendlich viele Zwischenzustände.
-3. Sie sind **nicht direkt speicherbar** – dazu brauchen wir ein Medium, das sie repräsentiert.
-
-## Erklärung
-**Schallwellen**: Wenn ich spreche, versetzt mein Kehlkopf Luftmoleküle in Schwingung. Diese Schwingungen breiten sich als longitudinale Wellen aus (~340 m/s bei 20°C). Die Luftdruckschwankungen sind kontinuierlich: Die Funktion p(t) (Druck über Zeit) ist stetig differenzierbar.
-
-**Lichtwellen**: Elektromagnetische Strahlung mit Wellenlängen von ~380 nm (violett) bis 750 nm (rot) ist sichtbar für Menschen. Die Welle ist eine Oszillation des elektrischen und magnetischen Feldes – physikalisch real, mathematisch beschreibbar als E(x,t) = E₀ sin(kx - ωt).
-
-**Temperatur**: Mittlere kinetische Energie der Moleküle. Kontinuierlich veränderlich, kontinuierlich messbar (in der Praxis limitiert durch Thermometerpräzision, aber konzeptionell kontinuierlich).
-
-Die fundamentale Herausforderung: **Speichern** bedeutet, ein Muster in einem dauerhaften Medium zu fixieren. Luftmoleküle kann ich nicht einfrieren und ins Regal stellen. Ich brauche eine **Repräsentation**.
-
-## Vertiefung
-**Philosophische Dimension**: Ist die Realität kontinuierlich? Die klassische Physik (Newton, Maxwell) sagt ja. Die Quantenmechanik (Planck, Heisenberg) sagt: Auf sehr kleinen Skalen (Planck-Länge: 10⁻³⁵ m, Planck-Zeit: 10⁻⁴³ s) könnte Raum-Zeit diskret werden. Für unsere Zwecke (Audiofrequenzen bis 20 kHz, Videobilder mit Millisekunden-Auflösung) ist die Welt effektiv kontinuierlich.
-
-**Technische Anmerkung**: Sobald ein Mikrofon ins Spiel kommt, sind wir bereits **nicht mehr** auf der physischen Ebene. Ein Mikrofon (z.B. dynamisches Mikrofon) wandelt Luftdruck in elektrische Spannung – das ist der Übergang zu analog. Manche moderne Mikrofone haben integrierte A/D-Wandler und liefern direkt digitale Signale (USB-Mikrofone) – dann überspringen wir analog komplett.
-
-**Warum ist das wichtig?**: Weil es klar macht, dass **jede Messung bereits Interpretation ist**. Es gibt keine "rohen Daten" – Daten sind immer schon durch einen Sensor/Messapparat vermittelt. (Donna Haraway: "Situated Knowledges")
-
-## Beispiel
-Ein Baum fällt im Wald. Niemand ist da. Gibt es ein Geräusch?
-- **Physikalisch**: Ja, es gibt Luftdruckschwankungen (Schallwellen).
-- **Wahrnehmung**: Nein, "Geräusch" erfordert einen Beobachter.
-- **Speicherung**: Nein, ohne Mikrofon wird nichts aufgezeichnet.
-
-→ Physische Signale existieren unabhängig von uns, aber **Information** entsteht erst durch Messung/Kodierung.
-
-## Überleitung
-Um ein physisches Signal zu speichern, müssen wir den ersten Übersetzungsschritt machen: in ein **analoges Signal**.
-
-## Literatur
-Feynman, R. P. (1963). *The Feynman Lectures on Physics*, Vol. 1. Addison-Wesley. (Kapitel über Wellen)
-Haraway, D. (1988). "Situated Knowledges: The Science Question in Feminism and the Privilege of Partial Perspective." *Feminist Studies*, 14(3), 575-599.
--->
-
----
-
-# 2. Analoges Signal: Kontinuierliche Repräsentation
-
-**Physische Realität → Kontinuierliche Abbildung**
-
-**Beispiele:**
-- **Schallplatte**: Rille formt Schwingungen nach (räumliche Analogie)
-- **Magnetband**: Magnetisierung entspricht Schallstärke
-- **Thermometer**: Quecksilbersäule entspricht Temperatur
-- **Mikrofon**: Luftdruck → elektrische Spannung
-
-**Eigenschaften:**
-- ✓ **Analogie** zur Realität (daher "analog")
-- ✓ Immer noch **kontinuierlich**, aber in anderem Medium
-- ✗ **Verlustbehaftet** (Rauschen, Verzerrung, Abnutzung)
-
-<!--
-## Kontext
-Analoge Signale sind der erste Vermittlungsschritt zwischen Realität und Speicherung. Sie bewahren die Kontinuität des physischen Signals, aber übersetzen es in ein anderes Medium.
-
-## Kernaussagen
-1. "Analog" bedeutet **Analogie**: Das Signal im Medium formt das physische Signal nach.
-2. Analoge Signale sind **immer noch kontinuierlich** – unendlich viele Zwischenwerte (theoretisch).
-3. Jede analoge Repräsentation fügt **Rauschen und Verzerrung** hinzu – perfekte Kopien sind unmöglich.
-
-## Erklärung
-**Schallplatte (Phonograph, 1877)**: Die Nadel ritzt eine Rille in Wachs/Vinyl. Die **Tiefe und Form** der Rille entspricht der Amplitude und Frequenz der Schallwelle. Beim Abspielen folgt die Nadel der Rille und wird in Schwingung versetzt → Lautsprecher.
-
-- Vorteile: Einfach, funktioniert rein mechanisch, klingt "warm" (harmonische Verzerrungen)
-- Nachteile: Rille nutzt sich ab (Generationsverlust), Staub/Kratzer addieren Rauschen, sperrig
-
-**Magnetband (1930er)**: Eisenoxidpartikel auf Plastikband werden magnetisiert. Die **Stärke und Richtung** der Magnetisierung entspricht dem Audiosignal.
-
-- Vorteile: Kompakter als Vinyl, überspielbar (re-recordable)
-- Nachteile: Bandrauschen (thermisches Rauschen der Partikel), Abnutzung, Print-Through (benachbarte Lagen beeinflussen sich)
-
-**Thermometer**: Die Ausdehnung der Quecksilbersäule ist proportional zur Temperatur. Kontinuierliche Analogie: Je wärmer, desto höher.
-
-**Mikrofon (dynamisch)**: Eine Membran wird durch Schallwellen bewegt. Die Bewegung induziert elektrische Spannung in einer Spule (elektromagnetische Induktion). Die **Spannung** ist analog zur **Luftdruckänderung**.
-
-## Vertiefung
-**Warum "kontinuierlich"?** Theoretisch gibt es unendlich viele Magnetisierungsstufen auf dem Band. Praktisch ist es limitiert durch:
-- **Korngröße** der Eisenoxidpartikel (diskrete Partikel → effektive Quantisierung)
-- **Thermisches Rauschen** (Brown'sche Bewegung der Atome → stochastisches Signal überlagert)
-- **Bandbreite** des Aufnahme/Wiedergabe-Systems (Elektronik hat Frequenzlimits)
-
-Aber: Konzeptionell sind analoge Systeme **nicht-quantisiert**. Es gibt keine "Stufen" wie bei digital.
-
-**Generationsverlust**: Kopiere Kassette A → B: Rauschen von A wird mit aufgenommen, plus neues Rauschen von B addiert. Kopiere B → C: Noch mehr Rauschen. Nach 10 Generationen: Unhörbar.
-
-**Warum dominierte Analog ein Jahrhundert?** (1877 Phonograph bis ~1982 CD)
-- **Technische Einfachheit**: Keine Computer, keine A/D-Wandler nötig
-- **Kosten**: Vinyl-Pressen, Kassetten-Duplikation war billig und skalierbar
-- **Qualität**: Für damalige Standards völlig ausreichend (die meisten Menschen hatten nie ein "perfektes" Referenzsignal gehört)
-
-## Beispiel
-Ein konkretes Szenario: Schallplatte vs. Kassette in den 1970ern
-
-- **Schallplatte**: Bessere Frequenzantwort (bis 20 kHz), niedrigerer Störabstand (65-70 dB), aber Knistern durch Staub
-- **Kassette**: Schlechtere Frequenzantwort (bis ~15 kHz), Störabstand ~55 dB (ohne Dolby), aber portabel
-
-Beide analog, beide verlustbehaftet – unterschiedliche Trade-offs.
-
-## Überleitung
-Analoge Systeme dominierten, bis Computer billig genug wurden, um Echtzeit-A/D-Wandlung zu ermöglichen. Der Übergang zu **digital** war die größte Revolution in der Mediengeschichte.
-
-## Literatur
-Morton, D. (2004). *Sound Recording: The Life Story of a Technology*. Johns Hopkins University Press.
-Pohlmann, K. C. (2010). *Principles of Digital Audio* (6th ed.). McGraw-Hill. (Kapitel 1: History)
--->
-
----
-
-# 3. Digitales Signal: Diskrete Repräsentation
-
-**Kontinuierlich → Diskret (Sampling & Quantisierung)**
-
-**Zwei fundamentale Schritte:**
-1. **Sampling** (zeitlich): Messe nur zu bestimmten Zeitpunkten
-2. **Quantisierung** (Amplitude): Runde auf nächsten erlaubten Wert
-
-**Resultat:** Endliche Menge an Zahlen
-
-**Eigenschaften:**
-- ✓ **Speicherbar** als Bits
-- ✓ **Perfekte Kopien** möglich
-- ✓ **Rechenbar** (Filter, Effekte, Kompression)
-- ✗ **Informationsverlust** (Approximation der Realität)
-
-<!--
-## Kontext
-Dies ist der konzeptionell schwierigste Übergang. Wir geben die Kontinuität vollständig auf und arbeiten nur noch mit **diskreten Zahlen**. Dieser Schritt ermöglicht die gesamte digitale Revolution – Computer können nur Zahlen verarbeiten.
-
-## Kernaussagen
-1. Digitale Signale sind **Zahlenfolgen**, keine kontinuierlichen Funktionen.
-2. **Sampling** reduziert die zeitliche Dimension auf diskrete Messpunkte.
-3. **Quantisierung** reduziert die Amplituden-Dimension auf erlaubte Werte.
-4. Der Gewinn: Robustheit, perfekte Kopien, algorithmische Manipulation.
-5. Der Preis: Irreversibler Informationsverlust.
-
-## Erklärung
-**Sampling**: Eine kontinuierliche Funktion f(t) wird nur zu diskreten Zeitpunkten t₀, t₁, t₂, ... gemessen.
-
-Beispiel: Eine Sinuswelle bei 440 Hz (Ton A). Kontinuierlich: y(t) = sin(2π × 440 × t). Gesampelt bei 44.100 Hz: Wir nehmen nur 100,227 Samples pro Wellenzyklus (44.100 / 440 ≈ 100,2).
-
-→ Zwischen den Samples existiert **nichts**. Wir ignorieren, was die Funktion dort macht.
-
-**Nyquist-Shannon-Theorem**: Wenn wir mit mindestens **doppelter Frequenz** des höchsten Signals sampeln, können wir das Signal **perfekt rekonstruieren** (theoretisch).
-
-- Menschliches Hören: bis 20 kHz
-- CD-Standard: 44,1 kHz (2,2× höher → sicherer Puffer)
-
-**Quantisierung**: Die gemessenen Amplitudenwerte werden auf die nächste erlaubte Zahl gerundet.
-
-Beispiel: 16-bit Audio hat 2¹⁶ = 65.536 mögliche Werte. Ein gemessener Wert von 0.73421 Volt wird auf einen der 65.536 Werte gerundet (z.B. Wert #48.123).
-
-→ Der Rundungsfehler heißt **Quantisierungsrauschen**.
-
-Signal-to-Quantization-Noise Ratio (SQNR): ≈ 6 dB pro Bit
-- 16-bit: ~96 dB (für menschliches Hören mehr als ausreichend)
-- 24-bit: ~144 dB (für professionelle Aufnahmen, um Bearbeitungs-Headroom zu haben)
-
-## Vertiefung
-**Warum ist Digitalisierung irreversibel?**
-
-Sobald ich ein Signal digitalisiere, sind alle Informationen **zwischen den Samples** verloren. Ich kann nicht "zurückrechnen", was dort war – ich kann nur **interpolieren** (Annahmen treffen, z.B. durch Sinc-Interpolation).
-
-Analogie: Fotografiere einen Film, nehme nur jeden 100. Frame. Dann versuche, die Zwischenframes zu rekonstruieren. Ich kann raten (Motion Interpolation), aber ich weiß nicht, was **wirklich** passierte.
-
-**Aber: Nyquist sagt, das ist OK!**
-
-Wenn das Signal **bandbegrenzt** ist (d.h. keine Frequenzen über f_max), dann reicht Sampling mit 2×f_max, um es **perfekt** zu rekonstruieren. Das rekonstruierte Signal ist mathematisch identisch zum Original (für Frequenzen ≤ f_max).
-
-Praxis-Problem: Echte Signale sind nie perfekt bandbegrenzt. Daher:
-- **Anti-Aliasing-Filter** vor dem A/D-Wandler (entfernt Frequenzen > f_Nyquist)
-- **Oversampling** (Sample höher als nötig, z.B. 96 kHz oder 192 kHz)
-
-**Warum perfekte Kopien?**
-
-Ein digitales Signal ist eine Liste von Zahlen: [0.234, 0.456, 0.123, ...]. Kopiere die Liste → identisch. Computer nutzen **Error Correction Codes** (z.B. Reed-Solomon bei CDs), um Bitfehler zu erkennen und zu korrigieren.
-
-Analog: Kopiere Kassette → physikalischer Prozess, Rauschen addiert sich, unvermeidbar.
-Digital: Kopiere Datei → logischer Prozess, Bits werden verifiziert, Fehler korrigiert.
-
-**Warum rechenbar?**
-
-Filter (Equalizer, Kompressor, Reverb) sind mathematische Operationen auf Zahlenfolgen.
-- **FIR-Filter** (Finite Impulse Response): Faltung mit Koeffizienten
-- **IIR-Filter** (Infinite Impulse Response): Rückkopplungsstruktur
-- **FFT** (Fast Fourier Transform): Spektralanalyse
-
-All das ist nur möglich, weil das Signal **Zahlen** sind.
-
-## Beispiel
-Eine 1 kHz Sinuswelle, gesampelt bei 44.100 Hz:
-
-Ohne Quantisierung (ideale Werte):
-t₀: 0.000
-t₁: 0.142
-t₂: 0.281
-t₃: 0.415
-... (kontinuierliche Werte)
-
-Mit 16-bit Quantisierung:
-t₀: 0 / 32768 (exakt)
-t₁: 4661 / 32768 ≈ 0.1422
-t₂: 9221 / 32768 ≈ 0.2814
-t₃: 13607 / 32768 ≈ 0.4153
-... (diskrete Werte)
-
-→ Der Unterschied zwischen idealem und quantisiertem Wert ist das Quantisierungsrauschen (bei 16-bit unhörbar).
-
-## Überleitung
-Jetzt verstehen wir die fundamentale Natur digitaler Signale. Als Nächstes schauen wir, wie die drei Ebenen zusammenwirken.
-
-## Literatur
-Shannon, C. E. (1949). "Communication in the Presence of Noise." *Proceedings of the IRE*, 37(1), 10–21.
-Nyquist, H. (1928). "Certain Topics in Telegraph Transmission Theory." *Transactions of the AIEE*, 47(2), 617–644.
-Pohlmann, K. C. (2010). *Principles of Digital Audio* (6th ed.). McGraw-Hill. (Kapitel 2-3: Sampling & Quantization)
--->
-
----
-
-# Die drei Ebenen im Vergleich
-
-| Ebene | Form | Speicherbar? | Kopierbar? | Rechenbar? | Beispiel |
-|-------|------|-------------|-----------|-----------|----------|
-| **Physisch** | Kontinuierlich | ❌ | ❌ | ❌ | Schallwelle in Luft |
-| **Analog** | Kontinuierlich | ✅ | ⚠️ Mit Verlust | ⚠️ Analog-Schaltungen | Schallplatte, Kassette |
-| **Digital** | Diskret | ✅ | ✅ Perfekt | ✅ Algorithmen | MP3, WAV, CD |
-
-→ Jeder Übergang hat **Trade-offs**
-→ Digital opfert **Kontinuität** für **Robustheit**
-
-<!--
-## Kontext
-Diese Vergleichstabelle fasst die wesentlichen Unterschiede zusammen. Sie zeigt, warum Digital dominiert – aber auch, was verloren geht.
-
-## Kernaussagen
-1. Nur analoge und digitale Signale sind speicherbar (physische nicht).
-2. Nur digitale Signale erlauben verlustfreies Kopieren.
-3. Nur digitale Signale erlauben präzise algorithmische Manipulation.
-4. Der Preis: Diskretisierung = Informationsverlust (kontrolliert, aber irreversibel).
-
-## Erklärung
-**Speicherbar:**
-- Physisch: Nein. Die Schallwelle verpufft. Ohne Aufzeichnungsmedium ist sie weg.
-- Analog: Ja. Rille auf Platte, Magnetisierung auf Band.
-- Digital: Ja. Zahlen auf Festplatte, CD, Flash-Speicher.
-
-**Kopierbar:**
-- Physisch: Nein. Man kann nicht "die Welle" kopieren, nur neu erzeugen (wenn man sie kennt).
-- Analog: Ja, aber mit Degradation. Jede Kopie ist schlechter (Generationsverlust).
-- Digital: Ja, perfekt (mit Error Correction).
-
-**Rechenbar:**
-- Physisch: Nein. Man kann nicht "rechnen" mit einer Schallwelle (man kann sie physikalisch manipulieren, z.B. durch Reflexionen, aber nicht algorithmisch).
-- Analog: Bedingt. Analog-Schaltungen (Equalizer, Filter) sind möglich, aber fest verdrahtet, schwer zu ändern.
-- Digital: Ja, beliebig. Jeder Algorithmus ist anwendbar (Filter, Kompression, Synthese, ML).
-
-## Vertiefung
-**Trade-offs explizit:**
-
-Was Digital gewinnt:
-- **Fehlertoleranz**: Reed-Solomon auf CDs korrigiert bis zu 4000 fehlerhafte Bits in Folge
-- **Duplikation**: YouTube-Video wird millionenfach identisch kopiert
-- **Flexibilität**: Auto-Tune, Noise Reduction, Format-Konvertierung – all das ist Software
-
-Was Digital verliert:
-- **Kontinuität**: Nyquist garantiert Rekonstruktion nur für bandbegrenzte Signale
-- **Unendliche Präzision**: 16-bit = 96 dB dynamic range (praktisch ausreichend, aber theoretisch limitiert)
-- **"Natürlichkeit"**: Manche bevorzugen den "Sound" von Vinyl – wissenschaftlich sind es meist harmonische Verzerrungen, aber subjektive Präferenz ist real
-
-**Philosophische Frage**: Ist ein digitales Signal "weniger real" als ein analoges?
-
-Nein. Es ist nur eine **andere Art von Realität**. Ein JPEG-Bild existiert nicht weniger als ein gedrucktes Foto – es ist nur anders repräsentiert.
-
-Die Informationstheorie (Shannon) würde sagen: Solange alle **relevante Information** bewahrt wird, sind die Repräsentationen äquivalent. "Relevanz" ist kontextabhängig.
-
-## Überleitung
-Lass uns visualisieren, wie diese Übergänge aussehen.
--->
-
----
-
-# Visualisierung: Von Physisch zu Digital
-
-![bg right:50% fit](./assets/signal-levels-comparison.png)
-
-**1. Physisch** (Realität)
-Glatte Sinuswelle
-kontinuierlich in Zeit und Amplitude
-
-**2. Analog** (Repräsentation)
-Leicht verrauschte Kurve
-immer noch kontinuierlich
-
-**3. Digital** (Diskret)
-Treppenstufen-Approximation
-diskrete Zeitpunkte, diskrete Werte
-
-<!--
-## Kontext
-Eine visuelle Darstellung macht den Unterschied greifbar. Die Grafik zeigt drei Versionen derselben Sinuswelle.
-
-## Kernaussagen
-1. **Physisch**: Perfekte, glatte Kurve (existiert nur mathematisch/physikalisch).
-2. **Analog**: Verrauschte Kurve (Rauschen überlagert das Signal).
-3. **Digital**: Stufen-Approximation (Sampling + Quantisierung sichtbar).
-
-## Erklärung
-**Linke Kurve (Physisch)**:
-Eine mathematisch perfekte Sinuswelle: y(t) = A sin(ωt)
-- Kontinuierlich: unendlich viele Punkte auf der Kurve
-- Glatt: differenzierbar überall
-- Idealisiert: In der Realität gibt es immer Rauschen (thermisch, quantenmechanisch), aber konzeptionell ist das Signal glatt
-
-**Mittlere Kurve (Analog)**:
-Die Sinuswelle **plus Rauschen**. Das Rauschen kommt von:
-- Thermisches Rauschen (Brown'sche Bewegung der Moleküle in Kabeln)
-- Bandrauschen (bei Magnetbändern: stochastische Magnetisierung)
-- Elektronik-Rauschen (Verstärker, Widerstände)
-
-Die Kurve ist immer noch kontinuierlich (unendlich viele Werte), aber nicht mehr perfekt glatt.
-
-**Rechte Kurve (Digital)**:
-Die Treppenstufen zeigen:
-- **Horizontale Stufen**: Quantisierung (nur bestimmte Amplitudenwerte erlaubt)
-- **Vertikale Sprünge**: Sampling (nur zu bestimmten Zeitpunkten gemessen)
-
-Wenn Sampling-Rate und Bit-Tiefe hoch genug sind, ist die Approximation **visuell nicht unterscheidbar** vom Original (für menschliche Augen/Ohren).
-
-## Vertiefung
-**Wichtige Klarstellung**: Die Treppenstufen sind **nicht**, wie ein D/A-Wandler das Signal rekonstruiert. Ein moderner D/A-Wandler nutzt einen **Reconstruction Filter** (typischerweise Sinc-Interpolation), der die Stufen glättet. Die Ausgabe ist wieder eine glatte Kurve (innerhalb der Bandbreite).
-
-Die Treppenstu fen-Darstellung ist **konzeptionell korrekt** für die gespeicherten Daten, aber **irreführend** für die Wiedergabe.
-
-**Nyquist-Shannon nochmal**: Wenn wir mindestens 2× samplen, können wir die **exakte** Original-Kurve rekonstruieren (für Frequenzen unterhalb f_Nyquist). Die Treppenstufen sind nur eine **Darstellungsform** der Daten – mathematisch ist die Information äquivalent.
-
-**Praktisches Beispiel**:
-- Physisch: 1 kHz Sinuswelle (perfekt)
-- Analog: Aufgenommen auf Kassette (Bandrauschen ~55 dB SNR)
-- Digital: Gesampelt bei 44,1 kHz, 16-bit (Quantisierungsrauschen ~96 dB SNR)
-
-→ Das digitale Signal hat **besseren SNR** als das analoge! (96 dB vs. 55 dB)
-
-## Überleitung
-Diese Visualisierung zeigt: Digital ist keine Magie, sondern eine **kontrollierte Approximation**. Wenn die Parameter (Sampling-Rate, Bit-Tiefe) richtig gewählt sind, ist die Approximation so gut, dass Menschen keinen Unterschied hören/sehen.
--->
-
----
-
-# Warum ist diese Unterscheidung wichtig?
-
-**Verstehen, was passiert, wenn wir:**
-
-1. **Alte Schallplatten digitalisieren**
-   → Analog (mit Rauschen) → Digital
-   → **Rauschen wird "eingefroren"** (bleibt für immer)
-
-2. **Mit einer Digitalkamera filmen**
-   → Physisch (Licht) → Digital (Sensor)
-   → **Kein analoger Zwischenschritt!** (moderne Kameras)
-
-3. **Audiokassetten kopieren**
-   → Analog → Analog (Rauschen addiert sich, Generation für Generation)
-   → Digital → Digital (perfekt, unendlich kopierbar)
-
-4. **Kompression anwenden**
-   → Nur bei digitalen Signalen möglich!
-   → Algorithmen brauchen Zahlen, keine Wellen
-
-<!--
-## Kontext
-Die theoretische Unterscheidung wird praktisch relevant in konkreten Anwendungsfällen. Diese Folie zeigt, warum man verstehen muss, auf welcher Ebene man arbeitet.
-
-## Kernaussagen
-1. **Digitalisierung analoger Medien**: Rauschen wird Teil des Signals (nicht mehr trennbar).
-2. **Moderne Aufnahme**: Überspringt analog komplett (direkt physisch → digital).
-3. **Generationsverlust**: Nur bei analog-analog, nicht bei digital-digital.
-4. **Kompression**: Ist eine rein digitale Operation.
-
-## Erklärung
-**Fall 1: Schallplatten digitalisieren**
-
-Wenn ich eine Vinyl-Schallplatte digitalisiere:
-1. Die Rille ist analog (mit Knistern, Staub, Abnutzung)
-2. Der Tonabnehmer wandelt in elektrisches Signal (immer noch analog, mit Rauschen)
-3. Der A/D-Wandler samplet und quantisiert
-
-→ Das **Rauschen aus Schritt 1-2 wird eingefroren**. Es ist nun Teil der digitalen Datei und kann nicht mehr ohne weiteres entfernt werden. (Noise Reduction ist möglich, aber imperfekt – oft klingen Stimmen dann metallisch.)
-
-Konsequenz: Wenn ich eine perfekte Schallplatte habe, digitalisiere ich besser früh (bevor sie abnutzt). Spätere Digitalisierung = schlechteres Signal.
-
-**Fall 2: Digitalkameras**
-
-Moderne Digitalkameras (seit ~2000) haben **keine analoge Zwischenstufe** mehr:
-- Licht trifft auf Sensor (CCD oder CMOS)
-- Photodioden erzeugen elektrische Ladung (proportional zur Lichtintensität)
-- **Sofort** A/D-Wandlung (on-chip)
-- Ausgabe: digitale Rohdaten (RAW) oder komprimiert (JPEG)
-
-Alte Videokameras (vor ~1995):
-- Licht → Sensor → analoges Video-Signal → Band (VHS, Betacam)
-- Später digitalisiert für Bearbeitung
-
-→ Moderne Workflows überspringen analog komplett. Vorteil: Kein analoges Rauschen, kein Generationsverlust beim Kopieren.
-
-**Fall 3: Kassetten vs. Digitaldateien kopieren**
-
-Kassette A → Kassette B:
-- Abspielen: Magnetband → elektrisches Signal (mit Bandrauschen ~55 dB SNR)
-- Aufnehmen: Elektrisches Signal → Magnetband auf B (neues Bandrauschen addiert)
-- SNR nach Kopie: schlechter (~50 dB?)
-
-Digital: Datei A → Datei B:
-- Binäre Kopie: Bits werden 1:1 kopiert
-- Mit CRC/Checksums: Fehler werden erkannt und korrigiert
-- SNR nach Kopie: **identisch** (96 dB bleibt 96 dB)
-
-→ Nach 10 Kassetten-Kopien: unhörbar. Nach 10 Datei-Kopien: identisch zum Original.
-
-**Fall 4: Kompression**
-
-MP3, JPEG, H.264 – all das sind **Algorithmen**, die auf **Zahlen** operieren.
-- Fourier-Transform (FFT): Rechnet Zeitbereich → Frequenzbereich
-- Psychoakustisches Modell: Entscheidet, welche Frequenzen weggeworfen werden können
-- Huffman-Coding: Komprimiert die verbleibenden Daten verlustfrei
-
-All das ist nur möglich, weil das Signal **diskret** ist. Man kann keine FFT auf eine Schallwelle in der Luft anwenden – man kann sie nur auf eine **Liste von Zahlen** anwenden.
-
-## Vertiefung
-**Restauration alter Aufnahmen**:
-
-Wenn ich eine alte Schellackplatte aus den 1920ern digitalisiere, habe ich:
-- **Signal** (die Musik)
-- **Rauschen** (Kratzer, Knistern)
-- **Verzerrung** (Frequenzgang der damaligen Technik war schlecht)
-
-Moderne Restaurationssoftware (z.B. iZotope RX) nutzt Machine Learning, um:
-- Knistern zu entfernen (erkenne Muster von "Klick"-Geräuschen)
-- Rauschen zu reduzieren (lerne Rauschprofil in stillen Passagen)
-- Frequenzgang zu korrigieren (modelliere damalige Aufnahmetechnik, invertiere)
-
-All das funktioniert nur, weil das Signal **digital** ist. Bei einem analogen Band kann ich mechanisch nichts "herausrechnen".
-
-**Warum digitalisieren Bibliotheken/Archive alles?**
-
-Nicht wegen "besserer Qualität" (eine Schallplatte klingt wie eine Schallplatte, egal ob analog oder digital abgespielt). Sondern wegen:
-1. **Preservation**: Analoge Medien zerfallen (Magnetbänder haben ~20-30 Jahre Lebensdauer). Digital kann unendlich kopiert werden ohne Verlust.
-2. **Access**: Digital kann online gestellt werden, durchsuchbar gemacht, mit Metadaten versehen.
-3. **Manipulation**: Restauration, Normalisierung, Format-Konvertierung.
-
-## Überleitung
-Jetzt verstehen wir die fundamentale Natur von Signalen. Als Nächstes schauen wir uns an: **Warum müssen wir überhaupt komprimieren?**
--->
-
----
-
-# Praktische Konsequenzen
-
-**Digitalisierung ist irreversibel**
-
-Was zwischen Samples passiert: **für immer verloren**
-Was bei Quantisierung gerundet wurde: **für immer verloren**
-
-**Aber:**
-- Wenn Sampling-Rate hoch genug (Nyquist erfüllt): kein hörbarer Verlust
-- Wenn Bit-Tiefe hoch genug (16-bit+): Quantisierungsrauschen unhörbar
-
-**Daher die Praxis:**
-- **Archivierung**: Höchste Qualität digitalisieren (96 kHz, 24-bit)
-- **Distribution**: Dann komprimieren für Streaming/Download (AAC, Opus)
-
-→ "**You can always go down, but never up**"
-
-<!--
-## Kontext
-Diese Folie fasst die praktischen Implikationen für Medienproduktion zusammen. Sie gibt konkrete Handlungsanweisungen.
-
-## Kernaussagen
-1. **Digitalisierung ist eine Einbahnstraße**: Informationsverlust ist irreversibel.
-2. **Aber**: Wenn Parameter richtig gewählt, ist Verlust unhörbar/unsichtbar.
-3. **Workflow-Prinzip**: Archiviere in höchster Qualität, konvertiere nach unten für Distribution.
-
-## Erklärung
-**"You can always go down, but never up"**:
-
-Wenn ich mit 96 kHz, 24-bit aufnehme:
-- Kann ich zu 48 kHz, 16-bit konvertieren (für CD)
-- Kann ich zu 44,1 kHz, 16-bit konvertieren (für Streaming)
-- Kann ich zu 32 kHz, 128 kbit/s AAC komprimieren (für Web)
-
-Aber: Wenn ich mit 44,1 kHz, 16-bit aufnehme, kann ich **nicht** nachträglich zu 96 kHz, 24-bit "hochkonvertieren". (Technisch kann ich die Datei re-samplen, aber ich erfinde keine Information – es ist nur Interpolation.)
-
-**Archivierungs-Best-Practices**:
-
-Audio:
-- Mindestens 48 kHz, 24-bit (besser 96 kHz)
-- Unkomprimiert (WAV, AIFF) oder verlustfrei komprimiert (FLAC)
-- Warum 24-bit für Aufnahme? Nicht wegen dynamischem Range für Wiedergabe (16-bit reicht), sondern wegen **Headroom** bei Bearbeitung (Normalisierung, EQ, Mixing addiert Rauschen – besser mit mehr Präzision starten)
-
-Video:
-- Mindestens 1080p, besser 4K (auch wenn finale Ausgabe 1080p ist – Downscaling ist OK, Upscaling nicht)
-- Hohe Bitrate (100+ Mbit/s für ProRes, DNxHR)
-- Unkomprimiert oder nur leicht komprimiert (ProRes, DNxHR sind "mezzanine codecs" – geringe Kompression, hohe Qualität)
-
-**Distribution-Best-Practices**:
-
-Audio:
-- Streaming: AAC 128-256 kbit/s, Opus 128 kbit/s (moderner, besser)
-- Download: MP3 320 kbit/s (Kompatibilität) oder FLAC (Audiophile)
-
-Video:
-- Streaming: H.264 oder H.265, adaptive bitrate (360p/720p/1080p/4K)
-- Download: H.264 High Profile, ~5-10 Mbit/s für 1080p
-
-## Vertiefung
-**Warum nicht gleich in finaler Qualität aufnehmen?**
-
-1. **Flexibilität**: Heute streamst du in 720p, morgen will der Kunde 4K. Wenn Original 4K ist, kein Problem. Wenn Original 720p ist, Pech.
-2. **Bearbeitung**: Jede Bearbeitung (Color Grading, EQ, Normalisierung) addiert Artefakte. Besser mit höherer Qualität starten, dann degradiert es langsamer.
-3. **Zukunftssicherheit**: Codecs entwickeln sich. Heute ist H.264 Standard, morgen AV1. Wenn ich unkomprimiertes Master habe, kann ich neu encodieren. Wenn ich nur H.264 habe, re-encoding = doppelter Verlust.
-
-**Die "Prosumer-Falle"**:
-
-Viele Hobby-Filmer nehmen mit DSLR in 1080p H.264 auf (weil Kamera das direkt ausgibt). Problem:
-- H.264 ist ein **Delivery-Codec**, kein **Editing-Codec**
-- Interframe-Kompression macht Cutting schwer (Schnittprogramme müssen dekodieren, langsam)
-- Jedes Re-Encoding verschlechtert
-
-Besser: Aufnahme in ProRes (wenn Kamera unterstützt) oder extern aufzeichnen (Atomos Ninja mit ProRes RAW).
-
-**Professionelle Workflows**:
-
-Film-Produktion:
-1. Aufnahme: RAW (RED R3D, ARRI RAW) – unkomprimiert oder minimal komprimiert
-2. Bearbeitung: ProRes 4444 oder DNxHR (mezzanine codec)
-3. Color Grading: In mezzanine-Codec
-4. Export: H.264/H.265 für Streaming, DCP für Kino
-
-Musik-Produktion:
-1. Aufnahme: 96 kHz, 24-bit WAV
-2. Mixing: Intern in DAW (oft 32-bit float für noch mehr Headroom)
-3. Mastering: Export als 48 kHz, 24-bit WAV (für Streaming-Services)
-4. Distribution: Streaming-Services konvertieren zu AAC/Opus
-
-## Beispiel
-Ein konkretes Projekt: Podcast
-
-**Schlechter Workflow**:
-- Aufnahme direkt in MP3 128 kbit/s (weil "spart Speicher")
-- Bearbeitung (Schneiden, Normalisieren, EQ)
-- Export als MP3 128 kbit/s
-→ Doppelter Verlust! (Aufnahme-Encoding + Export-Encoding)
-
-**Guter Workflow**:
-- Aufnahme in WAV 48 kHz, 16-bit (oder 24-bit wenn Budget da)
-- Bearbeitung in WAV
-- Export als MP3 192 kbit/s (für Breite Kompatibilität) oder Opus 128 kbit/s (moderner)
-→ Nur einmal Verlust (bei Export), Archiv bleibt verlustfrei
-
-## Überleitung
-Jetzt verstehen wir, **warum** wir digitalisieren und **wie** wir es richtig machen. Als Nächstes: **Warum komprimieren wir überhaupt?**
-
-## Literatur
-AES Technical Council (2017). "Recommendations for Delivery of Recorded Music Projects." Audio Engineering Society.
-Apple (2024). "ProRes White Paper." Apple Inc.
-Avid (2024). "DNxHR and DNxHD Codecs." Avid Technology.
--->
-
----
-
-<!-- _class: lead -->
-
-# III. Das Problem der Knappheit
-## Warum Kompression notwendig ist
-
-<!--
-## Kontext
-Jetzt haben wir die theoretischen Grundlagen. Aber warum ist das alles relevant? Weil **Speicher endlich ist** und **Bandbreite begrenzt ist**. Kompression ist keine Optimierung, sondern **ökonomische Notwendigkeit**.
-
-## Kernaussagen
-1. Unkomprimierte digitale Medien sind **riesig** (Gigabytes pro Minute).
-2. Speicher und Bandbreite kosten **Geld**.
-3. Die gesamte digitale Medienwelt (Streaming, Social Media, Cloud) wäre ohne Kompression **unmöglich**.
-
-## Erklärung
-Wir werden jetzt konkrete Zahlen sehen: Wie groß sind unkomprimierte Dateien? Wie skaliert das Problem? Was kosten Speicher und Bandbreite?
-
-Diese Sektion motiviert die folgenden Themen (verlustfreie und verlustbehaftete Kompression).
-
-## Überleitung
-Lass uns mit einem konkreten Beispiel starten: Wie groß ist 1 Minute Musik?
--->
-
----
-
-# Ein konkretes Beispiel: 1 Minute Musik
-
-**Eine Minute Musik in CD-Qualität:**
-
-44.100 Samples/Sekunde
-× 16 Bit pro Sample
-× 2 Kanäle (Stereo)
-× 60 Sekunden
-
-= **10,584,000 Bytes** ≈ **10,6 MB pro Minute**
-
-<!--
-## Kontext
-Dies ist die erste konkrete Berechnung. Studierende sollen verstehen, **woher die Zahl kommt** – nicht nur auswendig lernen "CD = 10 MB/min".
-
-## Kernaussagen
-1. CD-Qualität ist definiert durch: 44,1 kHz Sampling, 16-bit Tiefe, Stereo.
-2. Die Datenmenge ist das Produkt aus Sample-Rate, Bit-Tiefe, Kanälen und Dauer.
-3. 10,6 MB/Minute klingt erstmal nicht dramatisch – aber es skaliert schnell.
-
-## Erklärung
-**Schritt-für-Schritt-Berechnung**:
-
-1. **Sample-Rate**: 44.100 Hz = 44.100 Messungen pro Sekunde
-   - Warum 44,1 kHz? Nyquist für 20 kHz (menschliches Hören) × 2 = 40 kHz. 44,1 kHz gibt etwas Puffer für Anti-Aliasing-Filter.
-   - Historischer Grund: Frühe digitale Aufnahmen nutzten Video-Recorder. NTSC-Video hat 30 Frames/sec × 490 Zeilen × 3 Samples = 44.100 Hz. (PAL: 25 × 588 × 3 = 44.100 Hz auch.) Zufall, aber praktisch.
-
-2. **Bit-Tiefe**: 16 Bit = 2 Bytes pro Sample
-   - 2¹⁶ = 65.536 mögliche Werte
-   - Dynamic Range: ~96 dB (6 dB × 16 bit)
-   - Für menschliches Hören mehr als ausreichend (Schmerzgrenze ~120 dB, Hörschwelle ~0 dB → 120 dB Range, aber Musik nutzt selten volle Range)
-
-3. **Kanäle**: 2 (Stereo: links + rechts)
-   - Mono wäre halb so groß
-   - Surround (5.1) wäre 6× so groß (oder 5,1× wenn LFE-Kanal weniger Samples hat)
-
-4. **Dauer**: 60 Sekunden
-
-**Berechnung**:
-44.100 Samples/sec × 2 Bytes/Sample × 2 Kanäle = 176.400 Bytes/sec
-176.400 Bytes/sec × 60 sec = 10.584.000 Bytes = 10,6 MB
-
-## Vertiefung
-**Alternative Sampling-Raten**:
-
-- **48 kHz**: DVD, professionelle Video-Produktion
-  - 48.000 × 2 × 2 × 60 = 11,52 MB/min (~9% größer)
-  - Warum 48 kHz? Bessere Teilbarkeit (teilt durch 2, 3, 4, 6 → leichter für Video-Frame-Rates)
-
-- **96 kHz**: Hi-Res Audio, Archivierung
-  - 96.000 × 2 × 2 × 60 = 23,04 MB/min (doppelt so groß)
-  - Warum? Mehr Headroom für Bearbeitung, theoretisch ultrasonic Frequenzen (obwohl Menschen nicht hören)
-
-- **192 kHz**: Extreme Hi-Res (fragwürdig ob sinnvoll)
-  - 192.000 × 2 × 2 × 60 = 46,08 MB/min (4× so groß wie CD)
-  - Wissenschaftlicher Konsens: Für Wiedergabe unnötig (Nyquist bei 96 kHz schon erfüllt). Für Aufnahme/Bearbeitung manchmal nützlich.
-
-**Alternative Bit-Tiefen**:
-
-- **24-bit**: Professionelle Aufnahme
-  - 44.100 × 3 × 2 × 60 = 15,876 MB/min (~50% größer)
-  - Dynamic Range: ~144 dB (weit über menschliche Wahrnehmung, aber nützlich für Bearbeitungs-Headroom)
-
-- **32-bit float**: DAW-intern
-  - Wird selten als Datei gespeichert (zu groß), aber intern in DAWs benutzt für präzise Berechnungen
-
-## Beispiel
-Ein 4-Minuten-Song (typische Länge):
-
-CD-Qualität (44,1 kHz, 16-bit, Stereo):
-4 min × 10,6 MB/min = **42,4 MB**
-
-Hi-Res (96 kHz, 24-bit, Stereo):
-4 min × 34,56 MB/min = **138,24 MB**
-
-→ Ein Album (12 Songs, ~50 min):
-- CD: ~530 MB
-- Hi-Res: ~1,7 GB
-
-## Überleitung
-10 MB/min klingt harmlos. Aber was passiert, wenn wir mehr Musik wollen?
--->
-
----
-
-# Konkrete Beispiele: Audio, Video, Bilder
-
-**Unkomprimierte Größen:**
-
-| Medium | Parameter | Größe |
-|--------|-----------|-------|
-| **Audio** | 44,1 kHz, 16-bit, Stereo | **10,6 MB/min** |
-| **Bild** | 4000×3000 px, RGB, 8-bit/Kanal | **34,5 MB** |
-| **Video** | 4K (3840×2160), 30 fps, 8-bit | **~45 GB/min** |
-
-**Problem:** Diese Größen sind unpraktikabel für Speicherung und Übertragung.
-
----
-
-# Skalierung: Von einem Song zu 10.000 Songs
-
-**Szenario:** Musiksammlung
-
-| Format | Größe/Song | 10.000 Songs | Speicher nötig |
-|--------|-----------|--------------|----------------|
-| **WAV (CD)** | 35 MB (3:30 min) | 350 GB | 1× 512 GB SSD |
-| **FLAC** | 18 MB (~50% Kompr.) | 180 GB | 1× 256 GB SSD |
-| **MP3 320** | 8 MB | 80 GB | 1× 128 GB SSD |
-| **MP3 128** | 3,3 MB | 33 GB | 1× 64 GB SSD |
-
-**Implikation:**
-- Ohne Kompression: 350 GB
-- Mit MP3 128: 33 GB (Faktor **10:1**)
-- **Ermöglicht** iPod (2001: 5–10 GB), Smartphone-Sammlungen
-
----
-
-# Historischer Kontext: Speicherkapazität 1990–2025
-
-| Jahr | Typische Festplatte | Preis/GB | Alben (WAV) | Alben (MP3 128) |
-|------|---------------------|----------|-------------|-----------------|
-| **1990** | 100 MB | $100 | 0,1 | 1,6 |
-| **1995** | 1 GB | $20 | 1,5 | 16 |
-| **2000** | 20 GB | $5 | 31 | 330 |
-| **2005** | 200 GB | $1 | 314 | 3.300 |
-| **2010** | 1 TB | $0,10 | 1.600 | 16.500 |
-| **2015** | 2 TB | $0,04 | 3.100 | 33.000 |
-| **2020** | 4 TB | $0,025 | 6.200 | 66.000 |
-| **2025** | 8+ TB | $0,015 | 12.500 | 132.000 |
-
-**Faktor (1990 → 2025):** 80.000× Kapazität, 6.667× billiger pro GB
-
----
-
-# Der digitale Wendepunkt: Zettabyte-Ära
-
-**Datenmenge der Menschheit:**
-- 2010: **2 Zettabyte** (ZB)
-- 2015: 15 ZB
-- 2020: 64 ZB
-- **2025: 181 ZB** (geschätzt)
-
-**Was ist ein Zettabyte?**
-1 ZB = 1.000 Exabyte = 1.000.000 Petabyte = 1.000.000.000 Terabyte
-
-**Kontext:** 181 ZB = ~18 Milliarden 10-TB-Festplatten
-
----
-
-# Zwei Philosophien der Kompression
-
-## **Lossless (Verlustfrei)**
-- **Prinzip**: Redundanz entfernen
-- **Resultat**: Original perfekt rekonstruierbar
-- **Kompression**: 2:1 bis 4:1 (typisch)
-- **Beispiele**: ZIP, FLAC, PNG, FFV1
-
-## **Lossy (Verlustbehaftet)**
-- **Prinzip**: Wahrnehmung austricksen (Psychoakustik/-visuell)
-- **Resultat**: Approximation, Original nicht rekonstruierbar
-- **Kompression**: 10:1 bis 100:1+ (typisch)
-- **Beispiele**: MP3, JPEG, H.264
-
----
-
-# Wann welche Strategie?
-
-| Anwendungsfall | Lossless | Lossy | Begründung |
-|----------------|----------|-------|------------|
-| **Archivierung** | ✅ | ❌ | Zukunftssicher, keine Degradation |
-| **Medizin (Röntgen, MRT)** | ✅ | ❌ | Rechtlich/ethisch: kein Informationsverlust erlaubt |
-| **Text, Code** | ✅ | ❌ | Jedes Bit wichtig |
-| **Musik-Streaming** | ❌ | ✅ | Bandbreite wichtiger als Perfektion |
-| **Social Media (Fotos)** | ❌ | ✅ | Speicher/Bandbreite, „gut genug" reicht |
-| **Video-Streaming** | ❌ | ✅ | Anders unpraktikabel (45 GB/min!) |
-| **Professionelle Fotografie** | ✅ | ❌* | RAW für Editing, JPEG für Delivery |
-
-*Hybrid: Bearbeiten in RAW (lossless), exportieren als JPEG (lossy)
-
----
-
-<!-- _class: lead -->
-
-# IV. Fundamentale Konzepte
-## Bits, Bytes & Kodierung
-
----
-
-# Das Bit: 0 oder 1
-
-**Die kleinste Informationseinheit**
-
-- **Bit** = Binary Digit
-- Zwei Zustände: 0 oder 1 (aus oder an, falsch oder wahr)
-- Physikalisch: Spannung (niedrig/hoch), Magnetisierung (N/S), Licht (aus/an)
-
-**Beispiele:**
-- 1 Bit: Ja/Nein-Frage
-- 2 Bits: 4 Zustände (00, 01, 10, 11)
-- n Bits: 2^n Zustände
-
-**Formel:** n Bits können 2^n verschiedene Werte darstellen
-
----
-
-# Das Byte: 8 Bits = 256 Zustände
-
-**Standard-Einheit der Informatik**
-
-- 1 Byte = 8 Bits
-- 2^8 = 256 verschiedene Werte (0–255)
-- Kann darstellen: Zahlen 0–255, Zeichen (ASCII), Graustufen
-
-**Warum 8 Bits?**
-- Historisch: IBM System/360 (1964) standardisierte 8-bit Byte
-- Praktisch: 256 Werte genug für Buchstaben + Sonderzeichen
-
-**Größere Einheiten:**
-- Kilobyte (KB): 1.000 Bytes (dezimal) oder 1.024 Bytes (binär, KiB)
-- Megabyte (MB), Gigabyte (GB), Terabyte (TB), ...
-
----
-
-# Anwendung: RGB-Farben
-
-**24-bit Farbtiefe (True Color)**
-
-Jeder Pixel: 3 Kanäle × 8 Bit = 24 Bit = 3 Bytes
-
-- **Rot**: 8 Bit (0–255)
-- **Grün**: 8 Bit (0–255)
-- **Blau**: 8 Bit (0–255)
-
-**Anzahl Farben:** 256 × 256 × 256 = **16.777.216 Farben**
-
-**Beispiele:**
-- Schwarz: (0, 0, 0)
-- Weiß: (255, 255, 255)
-- Rot: (255, 0, 0)
-- Cyan: (0, 255, 255)
-
----
-
-# Zeichenkodierung: ASCII – Der erste Standard
-
-**ASCII (American Standard Code for Information Interchange, 1963)**
-
-- 7 Bit → 128 Zeichen
-- Enthält: Buchstaben (A-Z, a-z), Ziffern (0-9), Sonderzeichen, Steuerzeichen
-
-**Beispiele:**
-- 'A' = 65 (dezimal) = 0100 0001 (binär)
-- 'a' = 97
-- '0' = 48
-- Leerzeichen = 32
-
-**Problem:** Nur für Englisch! Keine Umlaute, kein Kyrillisch, kein Chinesisch.
-
----
-
-# Das Problem: Sprachen außerhalb des Englischen
-
-**Extended ASCII (8-bit, 256 Zeichen)**
-- ISO-8859-1 (Latin-1): Westeuropäische Sprachen (äöüß)
-- ISO-8859-5: Kyrillisch
-- Windows-1252: Microsoft-Variante
-
-**Probleme:**
-- Inkompatibel zwischen Sprachen
-- Kann nicht Deutsch + Russisch in selber Datei
-- Chinesisch, Japanisch: 10.000+ Zeichen → unmöglich mit 8-bit
-
-**Lösung:** Unicode
-
----
-
-# Unicode: Ein Standard für alle Schriften
-
-**Unicode 16.0 (2024): 154.998 Zeichen**
-
-Umfasst:
-- Latein, Kyrillisch, Griechisch, Arabisch, Hebräisch
-- CJK (Chinesisch, Japanisch, Koreanisch): ~90.000 Zeichen
-- Emoji: ~3.600
-- Historische Schriften (Hieroglyphen, Keilschrift)
-
-**Struktur:**
-- Jedes Zeichen hat einen **Code Point**: U+0041 = 'A'
-- Code Points 0–1.114.111 (21 Bit theoretisch)
-
-**Verschiedene Encodings:** UTF-8, UTF-16, UTF-32
-
----
-
-# UTF-8, UTF-16, UTF-32: Encoding-Varianten
-
-**UTF-8 (variable Länge, 1–4 Bytes):**
-- ASCII-kompatibel (A = 1 Byte)
-- Umlaute: 2 Bytes (ä = C3 A4)
-- Chinesisch: 3–4 Bytes
-- **Vorteil**: Effizient für Text mit viel ASCII
-- **Standard** im Web (>98% aller Webseiten)
-
-**UTF-16 (2 oder 4 Bytes):**
-- Meiste Zeichen: 2 Bytes
-- Seltene: 4 Bytes (Surrogate Pairs)
-- **Verwendet**: Windows intern, Java
-
-**UTF-32 (immer 4 Bytes):**
-- Jedes Zeichen: 4 Bytes (verschwenderisch, aber einfach)
-- **Vorteil**: Direkter Zugriff (Zeichen N = Byte 4N)
-
----
-
-# Praxis: Bytes zählen, Dateigrößen verstehen
-
-**Beispiel: "Hello World!" in verschiedenen Encodings**
-
-| Encoding | Bytes | Hex |
-|----------|-------|-----|
-| **ASCII** | 12 | 48 65 6C 6C 6F 20 57 6F 72 6C 64 21 |
-| **UTF-8** | 12 | (identisch mit ASCII) |
-| **UTF-16** | 26 | FF FE 48 00 65 00 ... (BOM + 2 Bytes/Zeichen) |
-| **UTF-32** | 52 | (BOM + 4 Bytes/Zeichen) |
-
-**Beispiel: "Äpfel" in UTF-8**
-- 'Ä' = C3 84 (2 Bytes)
-- 'p' = 70 (1 Byte)
-- 'f' = 66
-- 'e' = 65
-- 'l' = 6C
-- **Total**: 6 Bytes (nicht 5!)
-
----
-
-# Hexadezimal: Die Sprache der Datei-Analyse
-
-**Warum Hex?**
-- Binär (0/1) ist zu lang: 11111111 = FF (kürzer)
-- Dezimal passt nicht zu Bytes: 255 ≠ klare Byte-Grenze
-- Hex: 1 Byte = 2 Hex-Ziffern (00–FF)
-
-**Hexadezimal (Base 16):**
-```
-0 1 2 3 4 5 6 7 8 9 A  B  C  D  E  F
-0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
-```
-
-**Beispiele:**
-- 0xFF = 255 (dezimal) = 1111 1111 (binär)
-- 0x10 = 16 (dezimal)
-- 0xA0 = 160 (dezimal)
-
----
-
-# Magic Numbers: Dateitypen erkennen
-
-**Jede Datei beginnt mit "Magic Bytes"**
-
-Erste Bytes identifizieren Dateityp (unabhängig von Extension)
-
-**Beispiele:**
-
-| Format | Magic Bytes (Hex) | ASCII |
-|--------|-------------------|-------|
-| **PNG** | 89 50 4E 47 0D 0A 1A 0A | .PNG.... |
-| **JPEG** | FF D8 FF | ÿØÿ |
-| **GIF** | 47 49 46 38 | GIF8 |
-| **PDF** | 25 50 44 46 | %PDF |
-| **ZIP** | 50 4B 03 04 | PK.. |
-| **MP3** | FF FB (oder FF F3) | ÿû |
-| **WAV** | 52 49 46 46 | RIFF |
-
-**Tool:** `hexdump -C filename | head` (Linux/Mac)
-
----
-
-# Praxis: "What the HEX-Code"
-
-**Live-Demo: Datei analysieren**
-
-```bash
-$ hexdump -C image.png | head -n 5
-
-00000000  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52  |.PNG........IHDR|
-00000010  00 00 05 00 00 00 03 84  08 02 00 00 00 8c d9 c0  |................|
-00000020  ea 00 00 00 09 70 48 59  73 00 00 0b 13 00 00 0b  |.....pHYs.......|
-```
-
-**Interpretation:**
-- `89 50 4E 47` = PNG Magic Number ✓
-- `49 48 44 52` = "IHDR" (Image Header Chunk)
-- Nächste Bytes: Breite, Höhe, Bit-Tiefe
-
-**Anwendung:**
-- Datei-Validierung (ist das wirklich ein PNG?)
-- Forensik (versteckte Daten?)
-- Debugging (warum öffnet Datei nicht?)
-
----
-
-# Dateneinheiten: KB, MB, GB, TB, PB, ZB
-
-**Präfixe (SI dezimal vs. Binär):**
-
-| Einheit | Dezimal (SI) | Binär (IEC) | Faktor |
-|---------|--------------|-------------|--------|
-| **Kilobyte** | 1 KB = 1.000 Bytes | 1 KiB = 1.024 Bytes | 2^10 |
-| **Megabyte** | 1 MB = 1.000 KB | 1 MiB = 1.024 KiB | 2^20 |
-| **Gigabyte** | 1 GB = 1.000 MB | 1 GiB = 1.024 MiB | 2^30 |
-| **Terabyte** | 1 TB = 1.000 GB | 1 TiB = 1.024 GiB | 2^40 |
-| **Petabyte** | 1 PB = 1.000 TB | 1 PiB = 1.024 TiB | 2^50 |
-| **Exabyte** | 1 EB = 1.000 PB | | 2^60 |
-| **Zettabyte** | 1 ZB = 1.000 EB | | 2^70 |
-
-**Unterschied:** 1 TB (dezimal) = 0,909 TiB (binär)
-→ "1 TB Festplatte" zeigt 931 GB in Windows (weil Windows GiB nutzt)
-
----
-
-# Binär vs. Dezimal: Der Marketing-Trick
-
-**Warum zwei Standards?**
-
-**Dezimal (1000-basiert):**
-- Hersteller nutzen: "1 TB = 1.000 GB"
-- Größere Zahlen → besser klingt
-
-**Binär (1024-basiert):**
-- Computer-intern: Potenzen von 2 (2^10 = 1024)
-- OS (Windows, Mac, Linux) zeigt oft GiB
-
-**Beispiel:**
-Festplatte gekauft: "2 TB"
-- Hersteller: 2.000.000.000.000 Bytes
-- Windows zeigt: 1.862 GB (eigentlich GiB)
-- **Differenz:** ~138 GB "verschwunden"
-
-**Warum?**
-2.000.000.000.000 / 1024^3 = 1.862,6 GiB
-
----
-
-# Datenwachstum der Menschheit
-
-**Exponentielles Wachstum:**
-
-| Meilenstein | Jahr | Datenmenge |
-|-------------|------|------------|
-| Gesamte Menschheitsgeschichte bis | 2003 | 5 Exabyte |
-| Alle 2 Tage (2013) | 2013 | 5 Exabyte |
-| Pro Tag (2025) | 2025 | ~500 Exabyte |
-
-**Treiber:**
-- Video (80% des Traffics)
-- IoT-Sensoren (Autos, Smart Cities)
-- AI-Training Datasets
-- Social Media
-
-**Konsequenz:** Speicherkapazität wächst, aber Daten wachsen schneller
-→ Kompression bleibt essentiell
-
----
-
-# Der digitale Wendepunkt: 181 Zettabyte (2025)
-
-**Vergleich:**
-- 181 ZB = 181.000.000.000.000.000.000.000 Bytes
-- = 181 Milliarden Terabyte
-- = Alle Worte der Menschheit × 36.000
-
-**AI-generierte Inhalte:**
-- 2030 (Prognose): 90% aller Daten AI-generiert/augmentiert
-- Text (ChatGPT), Bilder (Midjourney, DALL-E), Video (Sora)
-- Explosion synthetischer Daten
-
-**Ökologisch:**
-- Rechenzentren: ~1–2% globaler Energieverbrauch
-- Kompression reduziert Energie (kleinere Dateien = weniger Übertragung/Speicher)
-
----
-
-<!-- _class: lead -->
-
-# V. Audio
-## Von Analog zu Digital
-
----
-
-# Schall als physisches Phänomen
-
-**Was ist Schall?**
-- Mechanische Welle (Druckschwankung) in Medium (Luft, Wasser, Festkörper)
-- Geschwindigkeit: ~340 m/s in Luft (20°C)
-- Frequenz: Anzahl Schwingungen/Sekunde (Hz)
-- Amplitude: Stärke der Druckschwankung (Lautstärke)
-
-**Hörbarer Bereich (Mensch):**
-- Frequenz: 20 Hz – 20.000 Hz (20 kHz)
-- Lautstärke: 0 dB SPL (Hörschwelle) – 120 dB SPL (Schmerzgrenze)
-
-**Musik:**
-- Grundfrequenzen: 27,5 Hz (tiefste Klaviertaste) – 4.186 Hz (höchste)
-- Obertöne: bis 15–20 kHz
-
----
-
-# Analoge Audiowiedergabe: Schallplatte, Magnetband
-
-**Schallplatte (Vinyl):**
-- Rille formt Schallwelle physisch nach
-- Nadel tastet ab → mechanische Vibration → elektrisch → Lautsprecher
-- **SNR**: ~60–70 dB
-- **Frequenzgang**: 20 Hz – 20 kHz (theoretisch, praktisch schlechter)
-
-**Magnetband (Kassette):**
-- Eisenoxid-Partikel magnetisiert entsprechend Signal
-- **SNR**: ~50–60 dB (mit Dolby B/C besser)
-- **Frequenzgang**: 30 Hz – 15 kHz (Typ II/Metal besser)
-
-**Vorteile:** Direktheit, keine Digitalisierung, historisch billig
-**Nachteile:** Degradation, Generationsverlust, Rauschen
-
----
-
-# Vor- und Nachteile analoger Medien
-
-| Aspekt | Vorteil | Nachteil |
-|--------|---------|----------|
-| **Qualität** | Theoretisch unbegrenzte Auflösung | Praktisch durch Rauschen limitiert |
-| **Kopie** | — | Generationsverlust (Rauschen akkumuliert) |
-| **Haltbarkeit** | Jahrzehnte (wenn gut gelagert) | Degradiert (Abnutzung, Chemie) |
-| **Kosten** | Historisch billig | Heute teuer (Vinyl-Pressung) |
-| **Manipulation** | Schwierig, Hardware-basiert | Tape-Speed, Splicing möglich |
-
-**Fazit:** Für Massenmarkt überholt, für Audiophile/Sammler kulturell relevant.
-
----
-
-# Der Übergang: Warum Digital?
-
-**Motivationen (1970er–1980er):**
-
-1. **Perfekte Kopien**: Keine Generationsverluste (wichtig für Produktion)
-2. **Kein Rauschen**: Quantisierungsrauschen kontrolliert, nicht akkumulativ
-3. **Manipulation**: Filter, Effekte in Software → flexibel, günstig
-4. **Speicher**: Compact Disc (1982) → robust, kompakt, lange Spielzeit
-
-**Hindernisse:**
-- Technologie: ADCs/DACs teuer, langsam
-- Skepsis: "Digital klingt kalt/steril" (subjektiv, kulturell)
-- Patente: Dolby, Sony/Philips kontrollieren Standards
-
-**Durchbruch:** CD (1982), DAT (1987), dann 1990er: Digital dominiert Produktion
-
----
-
-# Digitalisierung: Sampling (zeitlich)
-
-**Sampling = zeitliche Diskretisierung**
-
-- Kontinuierliches Signal → nur bestimmte Zeitpunkte messen
-- **Sample Rate** (SR): Anzahl Messungen/Sekunde (Hz)
-
-**Beispiele:**
-- CD: 44.100 Hz (44,1 kHz)
-- DVD-Audio: 96.000 Hz
-- Pro-Audio: 48 kHz, 96 kHz, 192 kHz
-
-**Nyquist-Theorem:**
-SR ≥ 2 × höchste Frequenz → perfekte Rekonstruktion
-- Mensch hört bis ~20 kHz → brauchen ≥40 kHz
-- CD: 44,1 kHz ✓
-
-**Aliasing:**
-Wenn SR zu niedrig → hohe Frequenzen "spiegeln" als niedrige (Verzerrung)
-→ Anti-Aliasing-Filter vor ADC nötig
-
----
-
-# Digitalisierung: Quantisierung (Amplitude)
-
-**Quantisierung = Amplituden-Diskretisierung**
-
-- Kontinuierliche Spannungswerte → diskrete Stufen
-- **Bit Depth**: Anzahl Bits pro Sample
-
-**Beispiele:**
-- CD: 16-bit → 2^16 = 65.536 Stufen
-- Pro-Audio: 24-bit → 2^24 = 16.777.216 Stufen
-
-**SQNR (Signal-to-Quantization-Noise Ratio):**
-SQNR ≈ 6 dB × Bits
-- 16-bit: ~96 dB (reicht für Hören)
-- 24-bit: ~144 dB (Headroom für Produktion)
-
-**Dithering:** Kleines Rauschen vor Quantisierung → verhindert Verzerrung bei leisen Signalen
-
----
-
-# Berechnung: Sample Rate × Bit Depth × Kanäle
-
-**Formel:**
-```
-Bitrate (bit/s) = Sample Rate × Bit Depth × Kanäle
-Dateigröße = Bitrate × Zeit
-```
-
-**Beispiel: CD-Audio (Stereo)**
-- SR: 44.100 Hz
-- Bit Depth: 16-bit
-- Kanäle: 2 (Stereo)
-
-**Bitrate:**
-44.100 × 16 × 2 = 1.411.200 bit/s = **1.411 kbit/s**
-
-**1 Minute:**
-1.411 kbit/s × 60 s / 8 (bits → bytes) / 1024 (kB) = **10,6 MB/min**
-
-**1 Album (60 min):**
-10,6 MB × 60 = **636 MB**
-
----
-
-# Das Speicherproblem der Digitalisierung
-
-**Historischer Kontext:**
-
-**1990: Festplatten 100–500 MB**
-- 1 Album (636 MB) = gesamte Festplatte!
-- Lösung: Kompression (MP3, 1993)
-
-**1995: Festplatten 1–2 GB**
-- 2–3 Alben → immer noch knapp
-
-**2000: Festplatten 20–40 GB**
-- ~30–60 Alben → akzeptabel, aber MP3 = 10× mehr Musik
-
-**2025: Festplatten 4+ TB**
-- ~6.000 Alben (WAV) → Speicher kein Problem mehr
-- **Aber:** Streaming dominiert (Bandbreite wichtiger als lokaler Speicher)
-
-**Fazit:** Ohne MP3 wäre digitale Musik-Revolution der 1990er unmöglich gewesen.
-
----
-
-<!-- _class: lead -->
-
-# V-b. MP3-Revolution
-## Psychoakustik als Lösung
-
----
-
-# Psychoakustik: Der MP3-Trick
-
-**Grundidee:** Entferne, was Menschen nicht hören
-
-**Menschliches Gehör ist nicht perfekt:**
-1. **Maskierungseffekte**: Laute Töne übertönen leise
-2. **Frequenzgrenzen**: <20 Hz, >20 kHz unhörbar
-3. **Kritische Bänder**: Frequenzauflösung limitiert
-
-**Psychoakustisches Modell:**
-- Analysiere Signal: Was wird maskiert?
-- Quantisiere maskierte Komponenten grob (oder entferne)
-- Resultat: Kleinere Datei, kaum hörbarer Unterschied
-
----
-
-# Maskierungseffekte: Laute Töne übertönen leise
-
-**Simultane Maskierung:**
-- 1 kHz Ton bei 60 dB SPL
-- 1,1 kHz Ton bei 40 dB SPL gleichzeitig
-- → 1,1 kHz **unhörbar** (vom 1 kHz maskiert)
-
-**Temporale Maskierung:**
-- Lauter Ton → kurz danach sind leise Töne unhörbar (~5–10 ms)
-- Pre-Masking: Auch kurz **vor** lautem Ton (auditorische Verarbeitung)
-
-**Anwendung:**
-MP3-Encoder berechnet Masking-Kurve → entfernt/reduziert maskierte Frequenzen
-
----
-
-# Frequenzbereiche: Was Menschen nicht hören
-
-**Hörbarer Bereich: 20 Hz – 20 kHz**
-- <20 Hz: Infraschall (spürbar, nicht hörbar)
-- >20 kHz: Ultraschall (unhörbar, außer für Tiere)
-
-**Mit Alter sinkt Obergrenze:**
-- Kind: ~20 kHz
-- 30 Jahre: ~16 kHz
-- 50 Jahre: ~12 kHz
-- 70 Jahre: ~8 kHz
-
-**MP3-Strategie:**
-- Frequenzen >16 kHz: Entfernen oder stark reduzieren (bei niedrigen Bitraten)
-- <30 Hz: Ebenfalls reduzieren (wenig musikalischer Inhalt)
-
-**Savings:** ~20–30% der Daten in diesen Bereichen
-
----
-
-# Wahrnehmung ≠ Realität
-
-**Das Ohr ist kein Mikrofon**
-
-Mikrofon: Lineare Aufnahme aller Frequenzen (idealisiert)
-Ohr: Nichtlinear, frequenzabhängig empfindlich, kontextabhängig
-
-**Beispiel: Fletcher-Munson-Kurven**
-- Gleichlaute Kurven: Wie laut muss Frequenz X sein, damit sie gleich laut wie 1 kHz klingt?
-- Bei 100 Hz: Muss ~20 dB lauter sein als 1 kHz (bei leisen Pegeln)
-- → Ohr ist weniger empfindlich bei tiefen/hohen Frequenzen
-
-**MP3 nutzt das:**
-- Weniger Bits für Frequenzen, wo Ohr unempfindlich
-- Mehr Bits für 2–5 kHz (Sprachbereich, höchste Empfindlichkeit)
-
----
-
-# Die Geburt der MP3
-
-**Geschichte:**
-- 1982: IIS Fraunhofer (Erlangen) startet Forschung
-- 1987: Patent eingereicht (DE 3740215)
-- 1992: MPEG-1 Audio Layer 3 (MP3) standardisiert
-- 1995: Erste Software-Player (Winamp, 1997)
-- 1998: Erste portable Player (Diamond Rio)
-- 1999: Napster → Massenadoption
-
-**Kernentwickler:**
-- Karlheinz Brandenburg (Fraunhofer IIS)
-- Dieter Seitzer (Universität Erlangen)
-
-**Ziel:** Audio über ISDN übertragen (64 kbit/s) mit akzeptabler Qualität
-
----
-
-# Suzanne Vega: "Tom's Diner" – Die Referenz
-
-**Warum dieses Lied?**
-
-Brandenburg testete MP3-Prototypen jahrelang mit Suzanne Vega's "Tom's Diner" (a cappella Version).
-
-**Eigenschaften:**
-- Klare Stimme (testet Vocal-Encoding)
-- Minimal begleitet (keine Maskierung durch Instrumente)
-- Dynamikreich (leise/laute Passagen)
-- Sibilanten (S-Laute, schwierig zu kodieren)
-
-**Resultat:**
-- Codec-Entwicklung optimiert, bis "Tom's Diner" perfekt klang
-- → Andere Musik profitierte
-
-**Kulturelle Bedeutung:**
-"Tom's Diner" = "Mona Lisa der digitalen Audio-Ära" (weil so oft genutzt als Referenz)
-
----
-
-# Wie funktioniert MP3? (Vereinfacht)
-
-**7 Schritte:**
-
-1. **Filterbank** (Polyphase + MDCT): Teile Signal in 32/576 Frequenzbänder
-2. **Psychoakustisches Modell**: Berechne Masking-Threshold
-3. **Quantisierung**: Quantisiere jedes Band entsprechend Threshold (grob wenn maskiert, fein wenn kritisch)
-4. **Huffman-Coding**: Verlustfreie Kompression der quantisierten Werte
-5. **Bitstream-Formatierung**: Packe in MP3-Frame-Struktur
-6. **Optional: Bit Reservoir**: Nutze ungenutzte Bits von einfachen Frames für komplexe
-
-**Dekodierung:** Umkehrung (Huffman → De-Quantisierung → IMDCT → Synthese-Filterbank → Audio)
-
----
-
-# Bitrate: Der Qualitäts-Knopf
-
-**Bitrate = Anzahl Bits pro Sekunde**
-
-**Gängige MP3-Bitraten:**
-
-| Bitrate | Qualität | Anwendung | Dateigröße/min |
-|---------|----------|-----------|----------------|
-| **64 kbit/s** | Niedrig (Telefon) | Sprache, Podcasts | 0,5 MB |
-| **128 kbit/s** | Mittel (Radio) | Historisch populär | 1 MB |
-| **192 kbit/s** | Gut | Guter Kompromiss | 1,4 MB |
-| **256 kbit/s** | Sehr gut | iTunes Standard | 1,9 MB |
-| **320 kbit/s** | Höchste (MP3) | "Transparent" (für die meisten) | 2,4 MB |
-
-**CBR vs. VBR:**
-- **CBR** (Constant Bitrate): Gleiche Bitrate durchgehend (einfach, verschwenderisch)
-- **VBR** (Variable Bitrate): Bitrate variiert (komplexe Passagen → höher, einfache → niedriger) → effizienter
-
----
-
-# Variable Bitrate (VBR) vs. Constant (CBR)
-
-**CBR (Constant Bitrate):**
-- Feste Bitrate (z.B. 192 kbit/s) für gesamte Datei
-- **Vorteil**: Einfach, Dateigröße vorhersagbar, Streaming-freundlich
-- **Nachteil**: Verschwendet Bits bei einfachen Passagen, zu wenig bei komplexen
-
-**VBR (Variable Bitrate):**
-- Bitrate variiert: 128–320 kbit/s je nach Komplexität
-- **Vorteil**: Bessere Qualität bei gleicher durchschnittlicher Bitrate
-- **Nachteil**: Dateigröße schwankt, manche alte Player hatten Probleme
-
-**Beispiel:**
-- Stille: VBR nutzt ~32 kbit/s (genug)
-- Orchester-Crescendo: VBR nutzt 320 kbit/s (nötig)
-- Durchschnitt: 192 kbit/s → gleiche Dateigröße wie CBR 192, aber besser klingt
-
-**Empfehlung (heute):** VBR (alle modernen Player unterstützen)
-
----
-
-<!-- _class: lead -->
-
-# VI. Verlustfreie vs. Verlustbehaftete Audio-Codecs
-
----
-
-# Lossy-Codecs: MP3, AAC, Ogg Vorbis, Opus
-
-| Codec | Jahr | Entwickler | Typische Bitrate | Effizienz | Status |
-|-------|------|-----------|------------------|-----------|--------|
-| **MP3** | 1993 | Fraunhofer/Thomson | 128–320 kbit/s | Baseline | Patent-frei seit 2017 |
-| **AAC** | 1997 | MPEG | 96–256 kbit/s | ~30% besser als MP3 | Apple Standard, weit verbreitet |
-| **Ogg Vorbis** | 2000 | Xiph.Org | 96–256 kbit/s | Ähnlich AAC | Open Source, Spiele/Software |
-| **Opus** | 2012 | IETF | 16–256 kbit/s | Bester Lossy-Codec | WebRTC, Streaming, wächst |
-
-**Opus:** Hybrid-Codec (SILK für Sprache, CELT für Musik), sehr niedrige Latenz, patent-frei
-**AAC:** Apple Music, YouTube (Audio), bessere Qualität als MP3 bei gleicher Bitrate
-
----
-
-# Lossless-Codecs: FLAC, ALAC, APE, WAV
-
-| Codec | Jahr | Entwickler | Kompression | Plattform | Open Source |
-|-------|------|-----------|-------------|-----------|-------------|
-| **WAV** | 1991 | Microsoft/IBM | Keine (unkomprimiert) | Universal | Ja (Format) |
-| **FLAC** | 2001 | Josh Coalson (Xiph) | ~50% | Alle (via FFmpeg) | Ja |
-| **ALAC** | 2004 | Apple | ~40–60% | Apple, FFmpeg | Ja (seit 2011) |
-| **APE** | 2000 | Matthew T. Ashland | ~50–60% | Windows (primär) | Nein (Freeware) |
-
-**FLAC:** Standard für Lossless (unterstützt von fast allem)
-**ALAC:** Apple-Ökosystem (iTunes, iPhone), aber FFmpeg unterstützt auch
-**WAV:** Unkomprimiert, riesig, aber universell kompatibel
-
----
-
-# Vergleichstabelle: Kompressionsrate, Qualität, Anwendung
-
-| Kriterium | Lossy (MP3 320) | Lossless (FLAC) | Unkomprimiert (WAV) |
-|-----------|-----------------|-----------------|---------------------|
-| **Dateigröße** | 2,4 MB/min | ~5 MB/min | 10,6 MB/min |
-| **Qualität** | "Transparent" (für die meisten) | Perfekt (bitgenau) | Perfekt |
-| **Kompression** | ~4:1 | ~2:1 | 1:1 (keine) |
-| **Editing** | Vermeiden (Generationsverlust) | Gut (verlustfrei) | Perfekt |
-| **Streaming** | Ideal (klein) | Möglich (WLAN) | Unpraktikabel |
-| **Archivierung** | ❌ (irreversibel) | ✅ | ✅ (aber groß) |
-
-**Empfehlung:**
-- Archiv: FLAC
-- Mobil/Streaming: AAC 256 oder Opus 128
-- Produktion: WAV oder FLAC (24-bit)
-
----
-
-# Wann welches Format?
-
-| Anwendungsfall | Empfohlenes Format | Begründung |
-|----------------|-------------------|------------|
-| **Spotify/Streaming** | Opus 128–192 kbit/s | Effizient, niedrige Latenz |
-| **iTunes/Apple Music** | AAC 256 kbit/s | Apple-Standard, gute Qualität |
-| **Podcast** | MP3 64–96 kbit/s (Mono) | Sprache braucht weniger |
-| **Musik-Archiv** | FLAC 16-bit/44,1 kHz | Verlustfrei, zukunftssicher |
-| **Studio-Aufnahme** | WAV 24-bit/96 kHz | Maximale Qualität |
-| **Hi-Res Musik** | FLAC 24-bit/96 kHz | Verlustfrei, hohe Auflösung |
-| **Gaming (Voicechat)** | Opus 16–32 kbit/s | Niedrige Latenz |
-| **Vinyl-Digitalisierung** | FLAC 24-bit/96 kHz | Bewahrt analoge Bandbreite |
-
----
-
-# Audio-Container: MP3 vs. MP4 vs. OGG
-
-**Container ≠ Codec**
-
-**Container** = "Wrapper" (enthält Audio + Metadaten + optional Video/Untertitel)
-**Codec** = Kompressionsalgorithmus (wie Daten kodiert sind)
-
-**Beispiele:**
-
-| Container | Typische Codecs | Extension | Anwendung |
-|-----------|----------------|-----------|-----------|
-| **MP3** | MP3 | .mp3 | Musik (historisch) |
-| **MP4** | AAC, MP3, ALAC | .m4a, .mp4 | iTunes, Streaming |
-| **OGG** | Vorbis, Opus | .ogg, .opus | Open Source, Spiele |
-| **FLAC** | FLAC | .flac | Lossless Musik |
-| **Matroska** | Alles | .mka | Flexibel, wenig genutzt |
-
-**Verwirrendes Beispiel:**
-- `.mp4` Datei kann AAC (häufig), MP3 (selten), oder ALAC (Apple) enthalten
-- Nur Codec-Info gibt Qualität an, nicht Extension!
-
----
-
-# Metadaten: ID3-Tags, Vorbis Comments
-
-**Metadaten = Information über die Datei**
-
-Beispiele: Artist, Album, Track Number, Cover Art, Genre, Year
-
-**ID3-Tags (MP3):**
-- ID3v1: 128 Bytes am Ende, limitiert (30 Zeichen Artist, etc.)
-- ID3v2: Variable Länge am Anfang, umfangreich (Unicode, Bilder, Lyrics)
-
-**Vorbis Comments (FLAC, OGG):**
-- Text-basiert (key=value)
-- Flexibler als ID3 (keine Feldlängen-Limits)
-- Beispiel: `ARTIST=Suzanne Vega`, `ALBUM=Solitude Standing`
-
-**Cover Art:**
-- ID3v2: APIC-Frame (Attached Picture)
-- Vorbis: METADATA_BLOCK_PICTURE (Base64-kodiert)
-
-**Tools:** `ffmpeg -i file.mp3` (zeigt Metadaten), `id3v2`, `metaflac`
-
----
-
-# Streaming-Formate: Adaptive Bitrate
-
-**Problem:** Netzwerk-Bandbreite variiert (4G → Wi-Fi → 5G)
-
-**Lösung: Adaptive Bitrate Streaming (ABS)**
-
-**Prinzip:**
-1. Server kodiert Audio in mehreren Bitraten (64, 128, 256 kbit/s)
-2. Client misst Bandbreite
-3. Client wählt passende Bitrate
-4. Wechsel on-the-fly (bei Bandbreiten-Änderung)
-
-**Protokolle:**
-- **HLS** (HTTP Live Streaming, Apple): .m3u8 Playlist
-- **DASH** (Dynamic Adaptive Streaming over HTTP, MPEG): .mpd Manifest
-
-**Spotify:**
-- Nutzt Ogg Vorbis mit ABS (96, 160, 320 kbit/s)
-- Offline: Höchste Bitrate wird gespeichert
-
----
-
-# Audio-Archivierung: Best Practices
-
-**Ziel:** Langfristige Erhaltung (>50 Jahre)
-
-**Format:**
-- **FLAC** (16-bit/44,1 kHz minimum, besser 24-bit/96 kHz)
-- **Alternativ:** WAV (aber größer, keine Metadaten)
-
-**Speichermedium:**
-- Lokal: HDD (extern, offline) + SSD (aktiv)
-- Cloud: Backblaze, AWS Glacier (redundant, geografisch verteilt)
-- Tape: LTO-9 (professionell, 18 TB, lange Haltbarkeit)
-
-**3-2-1-Regel:**
-- **3** Kopien (Original + 2 Backups)
-- **2** verschiedene Medien (z.B. HDD + Cloud)
-- **1** offsite (extern, Feuer/Diebstahl-schutz)
-
-**Migration:**
-- Alle 5–10 Jahre: Kopiere auf neue Medien (HDDs degradieren)
-- Prüfe Checksums (MD5, SHA-256) → Datenintegrität
-
----
-
-<!-- _class: lead -->
-
-# VII. Kritische Perspektive
-## Standards & Macht
-
----
-
-# Der Patentkrieg: Fraunhofer Lizenzgebühren
-
-**MP3-Patente (1987–2017):**
-- Fraunhofer IIS + Thomson hielten Patente
-- Lizenzgebühren: ~$2 pro MP3-fähiges Gerät, $0,01 pro verkauftem Song
-- Einnahmen: >$1 Milliarde (geschätzt)
-
-**Konsequenz:**
-- Open-Source-Software (Linux, VLC) musste zahlen oder umgehen
-- → Vorbis/Opus als patent-freie Alternative
-
-**2017: Patente ausgelaufen**
-- Alle MP3-Patente weltweit abgelaufen
-- MP3 jetzt komplett frei nutzbar
-- Aber: AAC/H.264/H.265 haben eigene Patente (MPEG LA)
-
-**Kritik:**
-Patente auf mathematische Algorithmen umstritten (sollte Wissen frei sein?)
-
----
-
-# Warum Open-Source Ogg Vorbis nutzte
-
-**Problem:** MP3-Patente
-
-**Lösung:** Xiph.Org Foundation entwickelt **Ogg Vorbis** (2000)
-- Patent-frei (nach bestem Wissen)
-- Open Source (BSD-lizenziert)
-- Bessere Qualität als MP3 (bei gleicher Bitrate)
-
-**Adoption:**
-- **Wikipedia** (Vorbis für Audio)
-- **Spotify** (Vorbis für Streaming)
-- **Gaming** (Unreal Engine, Unity unterstützen Vorbis)
-- **Mozilla/Firefox** (frühe Unterstützung)
-
-**Warum nicht dominanter?**
-- MP3-Player-Hardware schon weit verbreitet (2000)
-- Apple/Microsoft unterstützten nicht nativ (AAC/WMA stattdessen)
-- Network-Effekt: "Alle nutzen MP3"
-
-**Opus (2012):** Nachfolger, noch besser, IETF-Standard, patent-frei
-
----
-
-# H.264 vs. AV1: Kampf um Video-Standards
-
-**H.264 (2003):**
-- MPEG LA Patent Pool (~1.000 Patente)
-- Lizenzgebühren: Komplex (Encoder/Decoder/Distribution)
-- **Dominiert** (YouTube, Blu-ray, Streaming bis ~2020)
-
-**H.265/HEVC (2013):**
-- 2× effizienter als H.264
-- **Problem:** 3 Patent Pools (MPEG LA, HEVC Advance, Velos Media)
-- Lizenzgebühren unklar, hoch
-- → Adoption langsam
-
-**AV1 (2018):**
-- **Alliance for Open Media** (Google, Mozilla, Cisco, Amazon, Netflix, Intel, Microsoft, Apple)
-- **Patent-frei** (Mitglieder gewähren royalty-free Lizenzen)
-- ~30% effizienter als H.265
-- **Adoption wächst:** YouTube (2021), Netflix (2021), Meta, TikTok
-
-**Bedeutung:**
-Open Standards verhindern Patent-Monopole, senken Kosten, fördern Innovation
-
----
-
-# Napster: Kulturelle Revolution durch MP3
-
-**Napster (1999–2001):**
-- P2P File-Sharing (Shawn Fanning, 19 Jahre alt)
-- 80 Millionen Nutzer (Peak, 2001)
-- Teilen von MP3s → Urheberrechtsverletzung (massiv)
-
-**Warum möglich?**
-- MP3: Klein genug für 56k Modem (1 Song in ~10 Minuten)
-- P2P: Dezentral (kein zentraler Server mit Musik)
-
-**Musikindustrie-Reaktion:**
-- Klagen (Metallica, Dr. Dre, RIAA)
-- 2001: Napster geschlossen (Gerichtsbeschluss)
-
-**Langfristige Auswirkung:**
-- Zeigte: Menschen wollen digitale Musik, on-demand
-- → iTunes Store (2003), Spotify (2008)
-- Geschäftsmodell shift: Verkauf → Streaming
-
-**Zitat (Steve Jobs, 2003):**
-> "Napster showed us what people wanted. We just had to make it legal."
-
----
-
-<!-- _class: lead -->
-
-# VIII. Abschluss
-
----
-
-# Zusammenfassung: Die Kernkonzepte
-
-**Drei Ebenen des Signals:**
-- Physisch (Realität) → Analog (kontinuierlich) → Digital (diskret)
-
-**Digitalisierung:**
-- Sampling (zeitlich) + Quantisierung (Amplitude) = Zahlen
-- Nyquist-Theorem: Kein Verlust wenn SR ≥ 2× f_max
-
-**Kompression:**
-- Lossless (Redundanz) vs. Lossy (Psychoakustik)
-- MP3: Psychoakustisches Modell → 10:1 Kompression
-
-**Formate:**
-- Lossy: MP3, AAC, Opus (Streaming)
-- Lossless: FLAC, ALAC (Archiv)
-
-**Kritische Perspektive:**
-- Patente beeinflussen Standards (MP3, H.264)
-- Open Standards (AV1, Opus) demokratisieren Zugang
-
----
-
-# Fragen & Diskussion
-
-**Offene Fragen?**
-
-**Diskussionsthemen:**
-- Vinyl vs. Digital: Subjektive Präferenz vs. objektive Messung?
-- Streaming vs. Ownership: Was verlieren wir kulturell?
-- AI-generierte Musik: Brauchen wir noch menschliche Künstler?
-
-**Kontakt:**
-[Ihre Kontaktinformationen]
-
----
-
-# Selbstlernen: Audio-Spektrogramm, HEX-Files
-
-**Aufgabe 1: Audio-Spektrogramm analysieren**
-- Tool: Audacity (kostenlos)
-- Laden Sie eine MP3 (128 kbit/s) und FLAC
-- Vergleichen Sie Spektrogramm (Analyze → Plot Spectrum)
-- Frage: Wo sehen Sie Unterschiede? (Hohe Frequenzen fehlen bei MP3?)
-
-**Aufgabe 2: HEX-File untersuchen**
-- Tool: `hexdump -C file.mp3 | head` (Linux/Mac) oder HxD (Windows)
-- Finden Sie Magic Bytes (FF FB oder FF F3)
-- Identifizieren Sie ID3-Tag (49 44 33 = "ID3")
-
-**Aufgabe 3: Encodierung vergleichen**
-- Enkodieren Sie WAV → MP3 (128, 192, 320 kbit/s)
-- Blind-Test: Können Sie Unterschied hören?
-- Tool: `ffmpeg -i input.wav -b:a 128k output.mp3`
-
----
-
-# Lizenz & Attribution
-
-**Vorlesungsinhalte:**
-© 2025 [Ihr Name], Hochschule der Medien Stuttgart
-Lizenz: CC BY-SA 4.0 (sofern nicht anders angegeben)
-
-**Verwendete Quellen:**
-- Shannon, C. E. (1948). "A Mathematical Theory of Communication"
-- Pohlmann, K. C. (2010). *Principles of Digital Audio*
-- Sterne, J. (2012). *MP3: The Meaning of a Format*
-
-**Abbildungen:**
-- Signal-Transformation: Eigene Darstellung
-- Weitere Grafiken: Attributiert in jeweiligen Slides
-
-**Danksagung:**
-Fraunhofer IIS (MP3-Geschichte), Xiph.Org (Opus/Vorbis-Dokumentation)
-
----
-
-<!-- _class: lead -->
-
-# Bis zum nächsten Termin!
-
-**Termin 2: Bild- & Videoformate**
-- JPEG, PNG, WebP
-- H.264, H.265, AV1
-- Streaming-Technologien
-
-**Vorbereitung:**
-Lesen Sie: Watkinson, J. (2004). *The MPEG Handbook* (Kapitel 1–3)
diff --git a/courses/223015b/slides/02-bild-audio-video.md b/courses/223015b/slides/02-bild-audio-video.md
deleted file mode 100644
index 7c04eaf..0000000
--- a/courses/223015b/slides/02-bild-audio-video.md
+++ /dev/null
@@ -1,1027 +0,0 @@
----
-marp: true
-theme: gaia
-paginate: true
-backgroundColor: #fff
-header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
-footer: "Michael Czechowski – HdM Stuttgart"
-title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege - Teil 2
----
-
-<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: #1a1a2e;
-  color: #5fb3e4;
-  padding: 0.15em 0.4em;
-  border-radius: 4px;
-}
-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;
-  }
-}
-</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/)
-
-<!--
-## Kontext
-Teil 2 der Vorlesungsreihe. Nachdem wir in Termin 1 Grundlagen (Physisch/Analog/Digital, Text, Audio) behandelt haben, fokussieren wir uns jetzt auf **Bild und Video** - die datenintensivsten Medientypen.
-
-## Kernaussagen
-1. Bilder und Videos sind um Größenordnungen komplexer als Audio (2D/3D statt 1D).
-2. Psychovisuelle Kompression nutzt die Schwächen des menschlichen Auges.
-3. Video-Kompression ist essentiell für Streaming, Social Media, Cloud.
-
-## Leitfrage
-Wie schaffen es YouTube, Netflix, Instagram trotz 4K-Video zu funktionieren?
--->
-
----
-
-![bg fit](./assets/qr/slides-223015b.png)
-
----
-
-<!-- _class: lead -->
-
-# Teil 2: Bild- & Videoformate
-
-<!--
-## Überblick
-**I. Grundlagen Digitaler Bilder** (Raster vs. Vektor)  
-**II. Psychovisuelle Kompression** (Schwächen des Auges)  
-**III. JPEG** (Der Bildkompressionsstandard)  
-**IV. Andere Bildformate** (PNG, GIF, WebP, AVIF)  
-**V. Instagram-Problem** (Re-Kompression)  
-**VI. Video** (Container, Codecs, Kompression)  
-**VII. Kritische Perspektive** (Deepfakes & Manipulation)
--->
-
----
-
-# Rückblick: Physisch → Analog → Digital
-
-**Bei Bildern:**
-
-- **Physisch**: Lichtwellen (elektromagnetisches Spektrum, 380-750 nm)  
-- **Analog**: Film (Silberhalogenide reagieren auf Licht, kontinuierlich)  
-- **Digital**: Kamera-Sensor (Photodioden → A/D-Wandler, diskret)
-
-→ **Moderne Kameras überspringen analog komplett!**
-
-<!--
-## Kernaussagen
-1. Alte Film-Kameras: Licht → chemische Reaktion (analog) → später digitalisiert.
-2. Moderne DSLRs/Smartphones: Licht → CCD/CMOS-Sensor → direkt digital (on-chip A/D-Wandlung).
-3. Vorteil Digital: Kein analoges Rauschen, kein Generationsverlust, sofortige Vorschau.
-
-## Vertiefung
-Kodak entwickelte 1975 erste Digitalkamera (0,01 Megapixel, 23 Sekunden/Foto). 2000er: Digital überholte Film komplett.
--->
-
----
-
-<!-- _class: lead -->
-
-# I. Grundlagen Digitaler Bilder
-
----
-
-# Was ist ein digitales Bild?
-
-**Rastergrafik (Bitmap):** Matrix aus Pixeln
-
-Jedes Pixel = 1 Farbwert (z.B. RGB)
-
-**Beispiel 4×4 Pixel Bild:**
-```
-R  G  B  W
-G  B  W  R
-B  W  R  G
-W  R  G  B
-```
-
-**Auflösung:** Pixel-Anzahl bestimmt Detailgrad  
-**1920×1080 (Full HD):** 2.073.600 Pixel  
-**3840×2160 (4K):** 8.294.400 Pixel (4× mehr!)
-
-<!--
-## Kernaussagen
-1. Pixel = Picture Element (kleinste Einheit).
-2. Mehr Pixel = mehr Detail **aber** auch mehr Daten.
-3. Ein 4K-Bild hat 4× mehr Pixel als Full HD → 4× größere Datei (unkomprimiert).
-
-## Berechnung
-Full HD: 1920 × 1080 × 3 Bytes (RGB) = 6,22 MB  
-4K: 3840 × 2160 × 3 Bytes = 24,88 MB
--->
-
----
-
-# Rastergrafiken: Das Problem der Skalierung
-
-**Problem:** Pixelbilder verlieren Qualität beim Vergrößern
-
-**Beispiel:** 100×100 Pixel Logo
-
-- Anzeige in 100×100: perfekt  
-- Anzeige in 1000×1000: **verpixelt** (Interpolation kann nicht Details erfinden)
-
-→ **Lösung:** Für verschiedene Größen verschiedene Versionen speichern  
-Oder: Vektorgrafiken nutzen
-
-<!--
-## Kernaussagen
-1. Skalierung nach oben = Interpolation (Algorithmus rät, was dazwischen ist).
-2. Gängige Interpolation: Bilinear (schnell, akzeptabel), Bicubic (langsamer, besser), Lanczos (noch besser).
-3. Aber: Keine Interpolation kann verlorene Details zurückbringen.
-
-## Beispiel
-Retina-Displays: Brauchen 2× Auflösung → Websites liefern @2x Bilder für hochauflösende Screens.
--->
-
----
-
-# Vektorgrafiken
-
-**Prinzip:** Mathematische Beschreibung statt Pixel
-
-**Beispiel Kreis:**  
-Raster: 1000×1000 Pixel gespeichert  
-Vektor: "Kreis bei (500,500), Radius 200, Farbe Rot"
-
-**Vorteile:**
-- Unbegrenzt skalierbar (verlustfrei)
-- Kleine Dateigröße (nur Gleichungen)
-
-**Nachteile:**
-- Nur für geometrische Formen geeignet  
-- Fotos unmöglich als Vektor
-
-<!--
-## Kernaussagen
-1. SVG (Scalable Vector Graphics) = Standard für Web-Vektorgrafiken.
-2. Anwendung: Logos, Icons, Illustrationen, Infografiken.
-3. Adobe Illustrator, Inkscape = Vektor-Tools.
-
-## Beispiel
-Google Material Icons: Geliefert als SVG → perfekt auf jedem Screen (Smartphone bis 8K-Monitor).
--->
-
----
-
-# Raster- und Vektorgrafiken: Vergleich
-
-| Eigenschaft | Rastergrafik | Vektorgrafik |
-|-------------|--------------|--------------|
-| **Speicherung** | Pixel-Matrix | Mathematische Formeln |
-| **Skalierung** | Verlustbehaftet (Interpolation) | Verlustfrei (neu berechnet) |
-| **Dateigröße** | Groß (abhängig von Auflösung) | Klein (nur Gleichungen) |
-| **Anwendung** | Fotos, Screenshots | Logos, Icons, Illustrationen |
-| **Formate** | PNG, JPEG, GIF | SVG, AI, EPS, PDF (Vektor-Modus) |
-
-<!--
-## Kernaussagen
-Faustregel: Foto → Raster, Logo → Vektor.
--->
-
----
-
-<!-- _class: lead -->
-
-# II. Psychovisuelle Kompression
-## Die Schwächen des Auges nutzen
-
----
-
-# Die Schwächen des Auges
-
-**Menschliches Sehen ist nicht gleichmäßig:**
-
-1. **Helligkeitsempfindlichkeit > Farbempfindlichkeit**  
-   Wir sehen Graustufen schärfer als Farbnuancen
-
-2. **Räumliche Frequenzen:**  
-   Grobe Strukturen wichtiger als feine Details
-
-3. **Foveales Sehen:**  
-   Nur Zentrum des Blickfelds ist scharf (peripher unscharf)
-
-→ **Chroma Subsampling, DCT, Quantisierung** nutzen das aus
-
-<!--
-## Kernaussagen
-1. Das Auge hat mehr Rezeptoren für Helligkeit (Stäbchen) als für Farbe (Zapfen).
-2. Peripheres Sehen: Bewegung wird erkannt, Details nicht.
-3. JPEG, H.264, etc. codieren Helligkeit (Luma) mit höherer Auflösung als Farbe (Chroma).
-
-## Vertiefung
-YCbCr-Farbraum: Y = Luma (Helligkeit), Cb/Cr = Chroma (Farbdifferenzen). Erlaubt separate Behandlung von Helligkeit und Farbe.
--->
-
----
-
-# Chroma Subsampling
-
-**Prinzip:** Farbe mit niedrigerer Auflösung speichern als Helligkeit
-
-**Notation:** 4:2:0, 4:2:2, 4:4:4
-
-**4:4:4** – Volle Auflösung (keine Subsampling)  
-**4:2:2** – Horizontale Halbierung der Chroma  
-**4:2:0** – Horizontale **und** vertikale Halbierung
-
-**Beispiel 4:2:0:**  
-4 Pixel Helligkeit → 1 Pixel Farbe  
-= **75% weniger Farbdaten, kaum sichtbar!**
-
-<!--
-## Kernaussagen
-1. 4:2:0 Standard für Web, Streaming, YouTube (JPEG, H.264).
-2. 4:2:2 für professionelles Video (Broadcasting, Color Grading).
-3. 4:4:4 nur für spezielle Anwendungen (Grafiken mit Text, medizinische Bildgebung).
-
-## Berechnung
-4:4:4: 100% Luma + 100% Chroma = 3 Bytes/Pixel  
-4:2:0: 100% Luma + 25% Chroma = 1,5 Bytes/Pixel → 50% Reduktion
--->
-
----
-
-<!-- _class: lead -->
-
-# III. JPEG: Der Bildkompressionsstandard
-
----
-
-# JPEG: Sechs Schritte der Kompression
-
-**JPEG = Joint Photographic Experts Group (1992)**
-
-**Verlustbehaftete Kompression in 6 Schritten:**
-
-1. **Farbraum-Konvertierung** (RGB → YCbCr)  
-2. **Chroma Subsampling** (4:2:0)  
-3. **DCT** (Discrete Cosine Transform)  
-4. **Quantisierung** (Hier entsteht Verlust!)  
-5. **Zigzag-Scan & RLE**  
-6. **Huffman-Coding**
-
-<!--
-## Kernaussagen
-1. JPEG ist komplex, aber jeder Schritt hat klaren Zweck.
-2. Verlust entsteht nur bei Quantisierung (Schritt 4).
-3. Restliche Schritte sind Vorbereitung oder verlustfreie Kompression.
--->
-
----
-
-# JPEG: Schritt 1 – Farbraum wechseln
-
-**RGB → YCbCr**
-
-- **Y** = Luma (Helligkeit)  
-- **Cb** = Blau-Differenz  
-- **Cr** = Rot-Differenz
-
-**Warum?**  
-Erlaubt Chroma Subsampling (Farbe weniger auflösen)
-
-<!--
-## Kernaussagen
-YCbCr separiert Helligkeit von Farbe → Kompression kann beide unterschiedlich behandeln.
--->
-
----
-
-# JPEG: Schritt 2 – Chroma Subsampling
-
-**4:2:0 Standard:**
-
-Aus 4 Pixeln wird:
-- 4 Luma-Werte (Y)  
-- 1 Cb-Wert  
-- 1 Cr-Wert
-
-**Resultat:** 50% Datenreduktion, kaum sichtbar
-
-<!--
-## Kernaussagen
-Dieser Schritt allein spart massiv Daten, ohne merklichen Qualitätsverlust.
--->
-
----
-
-# JPEG: Schritt 3 – DCT
-
-**Discrete Cosine Transform:**  
-Bild in 8×8 Pixel Blöcke teilen  
-Jeder Block → Frequenzbereich transformieren
-
-**Ergebnis:**  
-Niedrige Frequenzen (große Flächen) → hohe Werte  
-Hohe Frequenzen (feine Details) → niedrige Werte
-
-→ **Vorbereitung für Quantisierung**
-
-<!--
-## Kernaussagen
-1. DCT ähnlich wie FFT, aber für 2D-Bilder optimiert.
-2. Niedrige Frequenzen = wichtig (grobe Struktur), Hohe Frequenzen = weniger wichtig (feine Details).
-3. DCT selbst ist verlustfrei (perfekt reversibel).
--->
-
----
-
-# JPEG: Schritt 4 – Quantisierung
-
-**Hier entsteht der Verlust!**
-
-**Prinzip:** Hohe Frequenzen stark reduzieren
-
-Quantisierungstabelle teilt DCT-Koeffizienten:
-- Niedrige Frequenzen: Division durch kleine Zahl (wenig Verlust)  
-- Hohe Frequenzen: Division durch große Zahl (starker Verlust)
-
-**JPEG-Qualität (0-100):**  
-100 = sanfte Quantisierung (große Datei, hohe Qualität)  
-10 = aggressive Quantisierung (kleine Datei, Artefakte)
-
-<!--
-## Kernaussagen
-1. Quantisierung = kontrollierter Informationsverlust.
-2. "JPEG-Qualität" Slider steuert Quantisierungstabelle.
-3. Irreversibel: Einmal quantisiert, kann man Original nicht wiederherstellen.
-
-## Beispiel
-Hohe Frequenz-Koeffizient: 127  
-Quantisierungswert: 50  
-Resultat: 127 / 50 = 2,54 → gerundet 3  
-Beim Dekodieren: 3 × 50 = 150 (nicht 127!) → Fehler = 23
--->
-
----
-
-# JPEG: Schritt 5 – Zigzag & RLE
-
-**Zigzag-Scan:**  
-8×8 Block in 1D-Array umwandeln (niedrige Frequenzen zuerst)
-
-**Run-Length Encoding (RLE):**  
-Viele Nullen (hohe Frequenzen wurden stark quantisiert)  
-→ `0 0 0 0 0 0 0 5` wird zu `7×0, 5`
-
-<!--
-## Kernaussagen
-Zigzag ordnet Daten so, dass RLE effizient wird (viele aufeinanderfolgende Nullen).
--->
-
----
-
-# JPEG: Schritt 6 – Huffman-Coding
-
-**Verlustfreie Kompression** (wie ZIP)
-
-H�ufige Werte → kurze Codes  
-Seltene Werte → lange Codes
-
-**Beispiel:**  
-`0` (sehr häufig) → `1` (1 Bit)  
-`127` (selten) → `11001111` (8 Bit)
-
-<!--
-## Kernaussagen
-Huffman ist verlustfrei und nutzt Häufigkeitsverteilung. Zusammen mit RLE finale Dateigröße deutlich kleiner.
--->
-
----
-
-# Grenzen der Kompression: JPEG-Artefakte
-
-**Bei zu hoher Kompression (niedrige Qualität):**
-
-1. **Blocking:** 8×8 Pixel Blöcke sichtbar  
-2. **Color Bleeding:** Farbränder verschwimmen  
-3. **Ringing:** Halos um scharfe Kanten  
-4. **Mosquito Noise:** Flimmern um Kanten in Video
-
-**Faustregel:**  
-JPEG-Qualität < 70: Artefakte sichtbar  
-JPEG-Qualität 85-95: Sweet Spot (kaum Verlust, gute Kompression)
-
-<!--
-## Kernaussagen
-1. Artefakte entstehen durch zu starke Quantisierung.
-2. Für Web: 85% Qualität meist optimal.
-3. Mehrfache JPEG-Kompression (Re-Encoding) verschlechtert stark (Generationsverlust).
--->
-
----
-
-<!-- _class: lead -->
-
-# IV. Andere Bildformate
-
----
-
-# PNG: Verlustfrei mit Transparenz
-
-**PNG = Portable Network Graphics (1996)**
-
-**Eigenschaften:**
-- Verlustfreie Kompression (Deflate-Algorithmus, wie ZIP)  
-- **Alpha-Kanal:** Transparenz (0 = durchsichtig, 255 = undurchsichtig)  
-- Paletten-Modus (8-bit, 256 Farben) oder True Color (24/32-bit)
-
-**Anwendung:**  
-Logos, Screenshots, Grafiken mit Text, Transparenz
-
-**Nachteil:**  
-Größer als JPEG für Fotos (keine Psychovisuelle Kompression)
-
-<!--
-## Kernaussagen
-1. PNG wurde als GIF-Ersatz entwickelt (GIF hatte Patentprobleme).
-2. Keine Qualitätsverlust-Slider (immer verlustfrei).
-3. Kompression hängt ab von Bildinhalt (strukturierte Grafiken → gut, Fotos → schlecht).
--->
-
----
-
-# GIF: Der Meme-Veteran
-
-**GIF = Graphics Interchange Format (1987)**
-
-**Eigenschaften:**
-- **256 Farben** (8-bit Palette)  
-- **Animation** (Frame-basiert)  
-- LZW-Kompression (verlustfrei)
-
-**Anwendung:**  
-Memes, einfache Animationen
-
-**Nachteil:**  
-Nur 256 Farben → Fotos sehen schlecht aus  
-Ineffizient für Video (besser: MP4, WebM)
-
-<!--
-## Kernaussagen
-1. GIF dominierte Web-Animationen 1990er-2000er (keine Alternative).
-2. Heute: MP4/WebM besser für Animationen (kleinere Datei, bessere Qualität).
-3. Aber: GIF bleibt in Meme-Kultur (einfach, universell unterstützt).
-
-## Vertiefung
-GIF-Patente (Unisys LZW) expirierten 2003 → jetzt patent-frei.
--->
-
----
-
-# WebP & AVIF: Moderne Alternativen
-
-**WebP (Google, 2010):**
-- Verlustfrei **und** verlustbehaftet  
-- ~30% kleiner als JPEG bei gleicher Qualität  
-- Transparenz + Animation
-
-**AVIF (AOMedia, 2019):**
-- Basiert auf AV1-Video-Codec  
-- ~50% kleiner als JPEG  
-- Bessere Qualität, aber langsamer zu encodieren
-
-**Problem:** Browser-Support  
-WebP: >95% (gut)  
-AVIF: ~85% (wachsend)
-
-<!--
-## Kernaussagen
-1. WebP: Guter Kompromiss (Qualität, Größe, Support).
-2. AVIF: Zukunft, aber noch nicht universell (Safari erst ab 2021).
-3. Strategie: Moderne Formate + JPEG/PNG Fallback.
-
-## Beispiel
-```html
-<picture>
-  <source srcset="image.avif" type="image/avif">
-  <source srcset="image.webp" type="image/webp">
-  <img src="image.jpg" alt="Fallback">
-</picture>
-```
--->
-
----
-
-# Formatwahl in der Praxis
-
-| Anwendung | Format | Warum? |
-|-----------|--------|--------|
-| **Foto (Web)** | JPEG/WebP | Verlustbehaftet OK, kleine Datei |
-| **Logo** | SVG/PNG | Vektor (SVG) oder Transparenz (PNG) |
-| **Screenshot** | PNG | Verlustfrei, Text lesbar |
-| **Meme/Animation** | GIF/MP4 | GIF für Kompatibilität, MP4 für Effizienz |
-| **Druck (CMYK)** | TIFF/PDF | Verlustfrei, CMYK-Farbraum |
-| **Archivierung** | TIFF/DNG | Unkomprimiert oder verlustfrei |
-
-<!--
-## Kernaussagen
-Trade-off-Entscheidung: Qualität vs. Dateigröße vs. Kompatibilität vs. Features (Transparenz, Animation).
--->
-
----
-
-<!-- _class: lead -->
-
-# V. Warum Instagram eure Fotos "ruiniert"
-
----
-
-# Social Media & Re-Kompression
-
-**Problem:**  
-Instagram, Facebook, Twitter re-encodieren **alle** Uploads
-
-**Warum?**
-- Speicherkosten (Milliarden Bilder)  
-- Bandbreite (schnellere Ladezeiten)  
-- Einheitlichkeit (verschiedene Geräte)
-
-**Konsequenz:**  
-Upload PNG/JPEG → Instagram konvertiert zu JPEG (Qualität ~85%)  
-→ **Generationsverlust** bei mehrfachem Re-Upload
-
-<!--
-## Kernaussagen
-1. Instagram: Max. 1080×1080 Pixel, JPEG ~85% Qualität.
-2. TikTok: Re-encodiert Video mit H.264, variable Bitrate.
-3. Twitter: Aggressivere Kompression als Instagram.
-
-## Tip für Nutzer
-Für beste Qualität: Genau 1080×1080 hochladen (Instagram skaliert nicht). JPEG mit 90-95% Qualität exportieren (Instagram komprimiert auf ~85%, Puffer hilft).
--->
-
----
-
-<!-- _class: lead -->
-
-# VI. Video: Bilder + Zeit + Audio
-
----
-
-# Das Größenproblem bei Video
-
-**Recap: 1 Min 4K = ~45 GB unkomprimiert**
-
-Ein 2-Stunden-Film: **5,4 Terabyte**
-
-**Streaming unmöglich ohne Kompression:**
-- Netflix 4K: ~15 Mbit/s (~7 GB/Stunde)  
-- YouTube 4K: ~20-40 Mbit/s (~10-20 GB/Stunde)
-
-→ **Faktor 100-200× Kompression nötig!**
-
-<!--
-## Kernaussagen
-1. Video ist Bilder + Zeit → Datenmenge multipliziert sich.
-2. Ohne Kompression: kein Streaming, kein YouTube, kein Netflix.
-3. Video-Codecs sind die komplexesten Kompressions-Algorithmen überhaupt.
--->
-
----
-
-# Container und Codec
-
-**Wichtige Unterscheidung:**
-
-**Container (Wrapper):**  
-Datei-Format, das Video, Audio, Untertitel, Metadaten enthält  
-Beispiele: MP4, MKV, AVI, MOV, WebM
-
-**Codec (Compressor/Decompressor):**  
-Algorithmus zur Kompression/Dekompression  
-Beispiele: H.264, H.265, VP9, AV1
-
-**Container ≠ Codec!**  
-MP4 kann H.264, H.265, AV1, oder andere Codecs enthalten
-
-<!--
-## Kernaussagen
-1. Analogie: Container = Schachtel, Codec = was drin ist.
-2. .mp4 sagt nichts über Codec aus (könnte H.264 oder H.265 sein).
-3. Tools wie MediaInfo zeigen Container + Codec.
-
-## Beispiel
-```
-Datei: video.mp4
-Container: MPEG-4
-Video-Codec: H.264 (AVC)
-Audio-Codec: AAC
-```
--->
-
----
-
-# Gängige Container
-
-| Container | Endung | Codecs | Anwendung |
-|-----------|--------|--------|-----------|
-| **MP4** | .mp4, .m4v | H.264, H.265, AV1 | Web, Smartphones, universal |
-| **MKV** | .mkv | Alle | Flexibel, Open-Source, Filme |
-| **WebM** | .webm | VP8, VP9, AV1 | Web (HTML5), YouTube |
-| **AVI** | .avi | Viele (alt) | Legacy (90er), veraltet |
-| **MOV** | .mov | H.264, ProRes | Apple-Ökosystem, Editing |
-
-<!--
-## Kernaussagen
-1. MP4 = Standard (universellste Kompatibilität).
-2. MKV = Flexibelster (alle Codecs, Features wie Kapitel, multiple Audio-Tracks).
-3. WebM = Open-Source, von Google gepusht.
--->
-
----
-
-# Video-Codecs
-
-| Codec | Jahr | Effizienz | Status |
-|-------|------|-----------|--------|
-| **H.264 (AVC)** | 2003 | Basis | Standard, universell kompatibel |
-| **H.265 (HEVC)** | 2013 | ~50% besser | Patente, teuer, langsame Adoption |
-| **VP9** | 2013 | ~H.265 | Google, YouTube, patent-frei |
-| **AV1** | 2018 | ~30% besser als H.265 | Zukunft, Netflix/YouTube, patent-frei |
-
-<!--
-## Kernaussagen
-1. H.264 dominiert noch (Kompatibilität, Hardware-Support).
-2. H.265 technisch besser, aber Patentchaos bremste Adoption.
-3. AV1 wird H.265 ablösen (patent-frei, AOMedia-Konsortium: Google, Netflix, Amazon, Apple).
--->
-
----
-
-<!-- _class: lead -->
-
-# VII. Video-Kompression im Detail
-
----
-
-# Drei Kompressionsprinzipien
-
-**1. Spatial Compression (Intra-Frame):**  
-Kompression **innerhalb** eines Frames (wie JPEG)
-
-**2. Temporal Compression (Inter-Frame):**  
-Differenzen **zwischen** Frames (nur Änderungen speichern)
-
-**3. Motion Compensation:**  
-Bewegungsvektoren statt volle Frames
-
-→ **Kombination ermöglicht Faktor 100-200× Kompression**
-
-<!--
-## Kernaussagen
-1. Intra-Frame: Jedes Frame einzeln komprimieren (ineffizient, aber notwendig für Schnitte).
-2. Inter-Frame: Meiste Frames sind Differenzen (sehr effizient).
-3. Motion Compensation: Statt "Block hat sich geändert" → "Block hat sich um 5 Pixel nach rechts bewegt".
--->
-
----
-
-# 1. Spatial Compression (Intra-Frame)
-
-**Prinzip:** Wie JPEG für Video-Frames
-
-**I-Frames (Intra-coded):**  
-Vollständige Bilder, unabhängig von anderen Frames  
-→ Größer, aber notwendig für Schnitte, Wiedereinstiegspunkte
-
-**Anwendung:**  
-Jedes N-te Frame ist I-Frame (z.B. alle 2 Sekunden)
-
-<!--
-## Kernaussagen
-I-Frames = Schlüsselbilder (Keyframes). Beim Vorspulen/Schneiden muss Decoder zum nächsten I-Frame.
--->
-
----
-
-# 2. Temporal Compression (Inter-Frame)
-
-**Prinzip:** Speichere nur Änderungen zum vorherigen Frame
-
-**P-Frames (Predicted):**  
-Referenzieren vorheriges Frame, speichern nur Differenzen  
-→ Viel kleiner als I-Frames
-
-**B-Frames (Bi-directional):**  
-Referenzieren vorheriges **und** nächstes Frame  
-→ Noch kleiner, aber komplexer zu dekodieren
-
-<!--
-## Kernaussagen
-1. Typische Sequenz: I B B P B B P B B I ...
-2. P-Frames: ~10% der Größe von I-Frames.
-3. B-Frames: ~5% der Größe von I-Frames.
-
-## Beispiel
-Interview-Video (Person spricht, Hintergrund statisch):
-- I-Frame: 100 KB (voller Frame)
-- P-Frame: 10 KB (nur Gesicht bewegt sich)
-- B-Frame: 5 KB (kaum Änderung zwischen Frames)
--->
-
----
-
-# 3. Motion Compensation
-
-**Prinzip:** Bewegungsvektoren statt volle Blöcke
-
-**Beispiel:**  
-Ball bewegt sich von (100,100) zu (150,100)  
-→ Statt neuen Ball speichern: "Kopiere Block von (100,100), verschiebe um (50,0)"
-
-**Resultat:**  
-Bewegung wird mit wenigen Bytes kodiert statt komplettem Block
-
-<!--
-## Kernaussagen
-1. Motion Vectors sind der Kern moderner Video-Codecs.
-2. H.265/AV1 nutzen sehr ausgefeilte Motion Estimation (mehrere Referenz-Frames, adaptive Block-Größen).
-3. Statische Szenen: Extrem effizient (fast keine Daten). Action-Szenen: Weniger effizient (viel Bewegung).
--->
-
----
-
-# H.264 / AVC
-
-**H.264 = MPEG-4 Part 10 / AVC (Advanced Video Coding)**
-
-**Status:** De-facto Standard (seit 2003)
-
-**Vorteile:**
-- Universelle Hardware-Unterstützung (jedes Gerät kann dekodieren)  
-- Gute Qualität bei moderaten Bitraten  
-- Mature, stable
-
-**Nachteile:**
-- Patente (MPEG LA) → Lizenzgebühren  
-- Nicht so effizient wie H.265/AV1
-
-<!--
-## Kernaussagen
-H.264 wird noch Jahrzehnte bleiben (zu weit verbreitet, zu gut unterstützt).
--->
-
----
-
-# Das Patent-Problem
-
-**H.264 Patente:**  
-MPEG LA Pool (viele Unternehmen)  
-Lizenzgebühren für Encoder/Decoder  
-→ Bremste Open-Source-Adoption
-
-**H.265 noch schlimmer:**  
-Mehrere Patent-Pools, unklar wer zahlen muss  
-→ Viele Firmen verweigerten Adoption
-
-**Reaktion:**  
-AOMedia (Google, Netflix, Amazon, Apple) → AV1 (patent-frei)
-
-<!--
-## Kernaussagen
-Technologie ≠ Neutral. Patente beeinflussen, welche Standards sich durchsetzen.
--->
-
----
-
-# VP9: Googles Antwort
-
-**VP9 (2013):** Googles patent-freie Alternative zu H.265
-
-**Status:**
-- YouTube Standard (>90% der Videos)  
-- Android, Chrome unterstützen  
-- Ähnliche Effizienz wie H.265
-
-**Problem:**  
-Wenig Hardware-Support (Software-Dekodierung → Batterie)
-
-<!--
-## Kernaussagen
-VP9 war Übergangslösung. AV1 ist Nachfolger (noch besser, patent-frei).
--->
-
----
-
-# AV1: Die offene Zukunft
-
-**AV1 (2018):** AOMedia Video Codec 1
-
-**Vorteile:**
-- ~30% effizienter als H.265  
-- Patent-frei (Royalty-free)  
-- Netflix, YouTube nutzen es
-
-**Nachteile:**
-- Langsam zu encodieren (CPU-intensiv)  
-- Hardware-Support wächst erst jetzt
-
-**Ausblick:**  
-Wird H.265 langfristig ersetzen
-
-<!--
-## Kernaussagen
-1. AOMedia = Konsortium (Google, Netflix, Amazon, Apple, Microsoft, Intel, ARM).
-2. AV1 designed für Streaming (adaptive bitrate, error resilience).
-3. Hardware-Decoder in neuen GPUs (NVIDIA RTX 30xx+, Intel Arc, Apple M3).
-
-## Beispiel
-YouTube: Bietet AV1 für 4K/8K wenn Browser/Device unterstützt, sonst VP9 oder H.264 Fallback.
--->
-
----
-
-# Adaptive Bitrate Streaming
-
-**Problem:** Nutzer haben verschiedene Bandbreiten
-
-**Lösung:** Video in mehreren Qualitätsstufen encodieren
-
-**Beispiel:**
-- 360p @ 1 Mbit/s  
-- 720p @ 3 Mbit/s  
-- 1080p @ 6 Mbit/s  
-- 4K @ 15 Mbit/s
-
-**Client wählt dynamisch** je nach Bandbreite
-
-**Technologien:**  
-MPEG-DASH (Standard), HLS (Apple)
-
-<!--
-## Kernaussagen
-1. Streaming-Dienste encodieren jedes Video mehrfach (ineffizient für Server, optimal für Nutzer).
-2. Client misst Bandbreite kontinuierlich, switcht Qualität nahtlos.
-3. Warum YouTube manchmal "buffert": Client wechselt zu niedrigerer Qualität.
--->
-
----
-
-<!-- _class: lead -->
-
-# VIII. Kritische Perspektive: Deepfakes & Manipulation
-
----
-
-# Wenn Codecs lügen
-
-**Deepfakes nutzen Codec-Schwächen:**
-
-Moderne ML-Modelle (GANs) erzeugen synthetische Videos  
-→ Müssen nur "gut genug für H.264" sein, nicht pixel-perfekt
-
-**Compression Artifacts als Forensik:**
-
-Echte Kamera-Footage hat charakteristische Muster  
-Synthetische Videos zeigen andere Artefakte  
-→ Forensische Tools nutzen das zur Erkennung
-
-**Ethische Dimension:**
-
-Als Medienschaffende: Verantwortung, nicht zu täuschen  
-Technisches Wissen befähigt, Manipulationen zu erkennen
-
-<!--
-## Kernaussagen
-1. Codecs optimieren für menschliche Wahrnehmung → Angreifbar für ML-generierte Fakes.
-2. Paradox: Artefakte helfen bei Verifikation (Echtheitsprüfung).
-3. Deepfake-Detektion: Aktive Forschung (Analyse von Kompressionsmustern, Frequenz-Anomalien, Augen-Blick-Muster).
-
-## Beispiel
-2019: Deepfake-Video von Mark Zuckerberg. Forensische Analyse zeigte unnatürliche Kompressionsartefakte um Gesicht.
--->
-
----
-
-<!-- _class: lead -->
-
-# IX. Abschluss
-
----
-
-# Fragen & Diskussion
-
-**Was wir heute gelernt haben:**
-
-1. **Digitale Bilder:** Raster vs. Vektor, Skalierungsprobleme  
-2. **Psychovisuell:** Chroma Subsampling, Schwächen des Auges  
-3. **JPEG:** 6-Schritte-Kompression, Artefakte  
-4. **Formate:** PNG, GIF, WebP, AVIF  
-5. **Instagram-Problem:** Re-Kompression, Generationsverlust  
-6. **Video:** Container vs. Codec, Spatial/Temporal Compression  
-7. **Codecs:** H.264, H.265, VP9, AV1, Patent-Probleme  
-8. **Deepfakes:** Ethische Verantwortung
-
-**Fragen?**
-
----
-
-# Selbstlernen: Bildkompression experimentieren
-
-**Aufgabe:** Exportiert ein Foto in verschiedenen JPEG-Qualitätsstufen
-
-**Tools:**
-- GIMP (kostenlos, Open-Source)  
-- Photopea (Browser-basiert, kostenlos)
-
-**Experiment:**
-1. Exportiere mit Qualität 100, 85, 70, 50, 10  
-2. Vergleiche Dateigröße und visuelle Qualität  
-3. Wo werden Artefakte sichtbar?
-
-**Link:** [https://www.photopea.com/](https://www.photopea.com/)
-
----
-
-# Selbstlernen: Video analysieren
-
-**Aufgabe:** Analysiert eine Video-Datei mit MediaInfo
-
-**Tool:** MediaInfo (kostenlos)  
-[https://mediaarea.net/en/MediaInfo](https://mediaarea.net/en/MediaInfo)
-
-**Fragen:**
-- Welcher Container?  
-- Welcher Video-Codec?  
-- Welche Bitrate?  
-- I-Frame-Abstand?
-
-**Bonus:** Vergleicht YouTube-Video (Download mit yt-dlp) vs. eigene Aufnahme
-
----
-
-# Lizenz & Attribution
-
-**Dieses Foliendeck:**  
-© 2025 Michael Czechowski  
-Lizenz: CC BY-SA 4.0
-
-**Quellen:**
-- Wallace, G. K. (1992). "The JPEG Still Picture Compression Standard." *IEEE Transactions on Consumer Electronics*.
-- Sullivan, G. J., et al. (2012). "Overview of the High Efficiency Video Coding (HEVC) Standard." *IEEE Transactions on Circuits and Systems for Video Technology*.
-- AOMedia (2018). AV1 Bitstream & Decoding Process Specification.
-
-**Kontakt:** [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
diff --git a/scripts/dev-server.sh b/scripts/dev-server.sh
index 7e11104..0660023 100755
--- a/scripts/dev-server.sh
+++ b/scripts/dev-server.sh
@@ -8,7 +8,7 @@ set -e
 INDEX_PORT=1310
 COURSE_B_PORT=1311
 COURSE_C_PORT=1312
-COURSE_DIR="courses"
+SLIDES_DIR="slides"
 DEV_INDEX_DIR=".dev-index"
 
 # Colors
@@ -94,12 +94,12 @@ echo ""
 python3 -m http.server $INDEX_PORT --directory "$DEV_INDEX_DIR" &
 PID_INDEX=$!
 
-PORT=$COURSE_B_PORT npx @marp-team/marp-cli --server "$COURSE_DIR/223015b/slides/" &
+PORT=$COURSE_B_PORT npx @marp-team/marp-cli --server "$SLIDES_DIR/223015b/" &
 PID_B=$!
 
 sleep 3  # Stagger starts to avoid WebSocket port collision
 
-PORT=$COURSE_C_PORT npx @marp-team/marp-cli --server "$COURSE_DIR/223015c/slides/" &
+PORT=$COURSE_C_PORT npx @marp-team/marp-cli --server "$SLIDES_DIR/223015c/" &
 PID_C=$!
 
 # Wait for any process to exit
diff --git a/scripts/extract-klausur.sh b/scripts/extract-klausur.sh
new file mode 100755
index 0000000..c9c2a5d
--- /dev/null
+++ b/scripts/extract-klausur.sh
@@ -0,0 +1,112 @@
+#!/usr/bin/env bash
+# Extract klausur-relevant slides from all kapitel
+# Usage: ./extract-klausur.sh <course_id>
+# Output: slides/<course>/klausur.md
+
+set -e
+
+COURSE="${1:-223015b}"
+SLIDES_DIR="slides/$COURSE"
+OUTPUT_FILE="$SLIDES_DIR/klausur.md"
+
+# Find the first kapitel file (01-*.md) to copy styles from
+FIRST_KAPITEL=$(ls "$SLIDES_DIR"/01-*.md 2>/dev/null | head -1)
+
+if [[ -z "$FIRST_KAPITEL" ]]; then
+  echo "Error: No 01-*.md file found in $SLIDES_DIR"
+  exit 1
+fi
+
+echo "Extracting klausur slides for $COURSE..."
+
+# Extract frontmatter and styles (everything up to first <!-- _class: line after style block)
+# This gets the YAML frontmatter + <style> block
+awk '
+  BEGIN { in_frontmatter = 0; in_style = 0; done = 0 }
+  /^---$/ && !in_frontmatter { in_frontmatter = 1; print; next }
+  /^---$/ && in_frontmatter && !in_style { in_frontmatter = 0; print; next }
+  in_frontmatter { print; next }
+  /<style>/ { in_style = 1; print; next }
+  /<\/style>/ { in_style = 0; print; print ""; done = 1; next }
+  in_style { print; next }
+  done { exit }
+' "$FIRST_KAPITEL" > "$OUTPUT_FILE"
+
+# Add warning comment
+cat >> "$OUTPUT_FILE" << 'EOF'
+<!--
+  ╔═══════════════════════════════════════════════════════════════════╗
+  ║  AUTO-GENERATED FILE - DO NOT EDIT MANUALLY                       ║
+  ║                                                                   ║
+  ║  This file is generated by: make klausur                          ║
+  ║  Source: scripts/extract-klausur.sh                               ║
+  ║                                                                   ║
+  ║  To update, edit the source slides and re-run make klausur        ║
+  ╚═══════════════════════════════════════════════════════════════════╝
+-->
+
+EOF
+
+# Extract and copy the cover slide (first slide after frontmatter/styles, up to first ---)
+awk '
+  BEGIN { past_style = 0; in_cover = 0; printed = 0 }
+  /<\/style>/ { past_style = 1; next }
+  past_style && !in_cover && /^[^[:space:]]/ { in_cover = 1 }
+  in_cover && /^---$/ { print "---\n"; exit }
+  in_cover { print }
+' "$FIRST_KAPITEL" >> "$OUTPUT_FILE"
+
+# Process each kapitel file in order - extract klausur slides only
+for md_file in $(ls "$SLIDES_DIR"/[0-9][0-9]-*.md 2>/dev/null | grep -v klausur | sort); do
+  filename=$(basename "$md_file")
+  kapitel_num=$(echo "$filename" | grep -oE '^[0-9]+' | sed 's/^0*//')
+
+  # Skip intro (kapitel 0)
+  if [[ "$kapitel_num" == "0" ]] || [[ -z "$kapitel_num" ]]; then
+    continue
+  fi
+
+  # Check if file has any klausur slides
+  if ! grep -q '<!-- _class: klausur -->' "$md_file"; then
+    continue
+  fi
+
+  echo "  Processing Kapitel $kapitel_num..."
+
+  # Extract klausur slides, hide header/footer, convert * to - bullets
+  awk '
+    /<!-- _class: klausur -->/ {
+      in_klausur = 1
+      # Add header/footer hiding
+      print "<!-- _header: \"\" -->"
+      print "<!-- _footer: \"\" -->"
+      print ""
+      next
+    }
+    in_klausur && /^---$/ {
+      print "\n---\n"
+      in_klausur = 0
+      next
+    }
+    in_klausur {
+      # Skip marp directives (we add our own)
+      if (/<!-- _header:/ || /<!-- _footer:/ || /<!-- _backgroundColor:/) next
+      # Convert * bullets to - bullets (avoid fragments)
+      gsub(/^\* /, "- ")
+      gsub(/^  \* /, "  - ")
+      gsub(/^    \* /, "    - ")
+      print
+    }
+  ' "$md_file" >> "$OUTPUT_FILE"
+
+done
+
+# Remove trailing --- and empty lines
+perl -i -0777 -pe 's/\n*---\n*$/\n/' "$OUTPUT_FILE"
+
+# Count slides
+slide_count=$(grep -c '^---$' "$OUTPUT_FILE" 2>/dev/null || echo "0")
+
+echo ""
+echo "Generated: $OUTPUT_FILE"
+echo "Total slides: $slide_count"
diff --git a/scripts/generate-index.sh b/scripts/generate-index.sh
index 7e92d4c..ac212c6 100755
--- a/scripts/generate-index.sh
+++ b/scripts/generate-index.sh
@@ -77,13 +77,13 @@ cat > "$BUILD_DIR/index.html" << HEADER
       font-size: 0.875rem;
       margin-top: 0.25rem;
     }
-    .termine {
+    .kapitel {
       margin-top: 1.5rem;
       display: flex;
       flex-direction: column;
       gap: 0.75rem;
     }
-    .termin-card {
+    .kapitel-card {
       position: relative;
       background: #fff;
       border-radius: 12px;
@@ -94,31 +94,31 @@ cat > "$BUILD_DIR/index.html" << HEADER
       align-items: center;
       gap: 1rem;
     }
-    .termin-card:hover {
+    .kapitel-card:hover {
       transform: translateY(-2px);
       box-shadow: 0 4px 12px rgba(0,0,0,0.12);
     }
-    .termin-link {
+    .kapitel-link {
       display: block;
       padding: 1.25rem 1.5rem;
       text-decoration: none;
       color: inherit;
       grid-column: 1;
     }
-    .termin-label {
+    .kapitel-label {
       font-size: 0.7rem;
       font-weight: 600;
       color: $ACCENT_COLOR;
       text-transform: uppercase;
       letter-spacing: 0.05em;
     }
-    .termin-title {
+    .kapitel-title {
       font-size: 1.05rem;
       font-weight: 500;
       color: #1d1d1f;
       margin: 0.15rem 0;
     }
-    .termin-date {
+    .kapitel-date {
       font-size: 0.8rem;
       color: #86868b;
     }
@@ -151,7 +151,7 @@ cat > "$BUILD_DIR/index.html" << HEADER
     }
     .btn-pdf:hover { background: #e8e8ed; }
     /* Make entire card clickable via overlay */
-    .termin-link::after {
+    .kapitel-link::after {
       content: '';
       position: absolute;
       inset: 0;
@@ -184,10 +184,10 @@ cat > "$BUILD_DIR/index.html" << HEADER
       color: #86868b;
     }
     @media (max-width: 600px) {
-      .termin-card {
+      .kapitel-card {
         grid-template-columns: 1fr;
       }
-      .termin-link {
+      .kapitel-link {
         padding-bottom: 0.75rem;
       }
       .btn-slides, .btn-pdf {
@@ -205,14 +205,13 @@ cat > "$BUILD_DIR/index.html" << HEADER
   <div class="termine">
 HEADER
 
-# Generate links for each termin (sorted)
-for html in $(ls "$BUILD_DIR"/2*.html 2>/dev/null | sort); do
+# Generate links for each kapitel (sorted)
+for html in $(ls "$BUILD_DIR"/[0-9][0-9]-*.html 2>/dev/null | sort); do
   filename=$(basename "$html")
 
-  # Extract components from filename
-  date=$(echo "$filename" | grep -oE '^[0-9]{4}-[0-9x]{2}-[0-9x]{2}')
-  termin_num=$(echo "$filename" | grep -oE 'termin-[0-9]+' | grep -oE '[0-9]+')
-  topic_raw=$(echo "$filename" | sed -E 's/^[0-9]{4}-[0-9x]{2}-[0-9x]{2}-termin-[0-9]+-//' | sed 's/\.html$//')
+  # Extract components from filename (format: NN-topic.html)
+  kapitel_num=$(echo "$filename" | grep -oE '^[0-9]+' | sed 's/^0*//')
+  topic_raw=$(echo "$filename" | sed -E 's/^[0-9]+-//' | sed 's/\.html$//')
 
   # Look up nice topic name or fallback
   topic="${TOPIC_MAP[$topic_raw]}"
@@ -220,18 +219,11 @@ for html in $(ls "$BUILD_DIR"/2*.html 2>/dev/null | sort); do
     topic=$(echo "$topic_raw" | sed 's/-/ /g' | sed 's/.*/\u&/')
   fi
 
-  # Format date
-  if [[ "$date" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]] && [[ ! "$date" =~ xx ]]; then
-    formatted_date=$(date -d "$date" "+%d. %B %Y" 2>/dev/null || echo "$date")
+  # Handle kapitel number
+  if [[ "$kapitel_num" == "0" ]] || [[ -z "$kapitel_num" ]]; then
+    kapitel_label="Einführung"
   else
-    formatted_date="Termin folgt"
-  fi
-
-  # Handle termin number
-  if [[ "$termin_num" == "0" ]]; then
-    termin_label="Einführung"
-  else
-    termin_label="Termin $termin_num"
+    kapitel_label="Kapitel $kapitel_num"
   fi
 
   pdf_filename="${filename%.html}.pdf"
@@ -243,11 +235,10 @@ for html in $(ls "$BUILD_DIR"/2*.html 2>/dev/null | sort); do
   fi
 
   cat >> "$BUILD_DIR/index.html" << LINK
-    <div class="termin-card">
-      <a href="$filename" class="termin-link">
-        <div class="termin-label">$termin_label</div>
-        <div class="termin-title">$topic</div>
-        <div class="termin-date">$formatted_date</div>
+    <div class="kapitel-card">
+      <a href="$filename" class="kapitel-link">
+        <div class="kapitel-label">$kapitel_label</div>
+        <div class="kapitel-title">$topic</div>
       </a>
       <a href="$filename" class="btn btn-slides">Folien</a>
       $pdf_link
diff --git a/courses/223015b/slides/2025-12-19-termin-0-intro.md b/slides/223015b/00-intro.md
similarity index 100%
rename from courses/223015b/slides/2025-12-19-termin-0-intro.md
rename to slides/223015b/00-intro.md
diff --git a/courses/223015b/slides/2025-12-19-termin-1-grundlagen-text-audio.md b/slides/223015b/01-grundlagen-text-audio.md
similarity index 100%
rename from courses/223015b/slides/2025-12-19-termin-1-grundlagen-text-audio.md
rename to slides/223015b/01-grundlagen-text-audio.md
diff --git a/courses/223015b/slides/2026-01-09-termin-2-bild-audio-video.md b/slides/223015b/02-bild-audio-video.md
similarity index 100%
rename from courses/223015b/slides/2026-01-09-termin-2-bild-audio-video.md
rename to slides/223015b/02-bild-audio-video.md
diff --git a/courses/223015b/slides/2026-01-23-termin-3-speichermedien-schnittstellen.md b/slides/223015b/03-speichermedien-schnittstellen.md
similarity index 99%
rename from courses/223015b/slides/2026-01-23-termin-3-speichermedien-schnittstellen.md
rename to slides/223015b/03-speichermedien-schnittstellen.md
index c8db493..ce7ed2f 100644
--- a/courses/223015b/slides/2026-01-23-termin-3-speichermedien-schnittstellen.md
+++ b/slides/223015b/03-speichermedien-schnittstellen.md
@@ -97,7 +97,7 @@ Hochschule der Medien Stuttgart
 
 <!-- _class: lead -->
 
-# Termin 3 – 23.01.2026
+# Kapitel 3 – 23.01.2026
 ## Speichermedien & Schnittstellen
 
 ---
diff --git a/courses/223015b/slides/2026-01-30-termin-4-distribution-apis-zukunft.md b/slides/223015b/04-distribution-apis-zukunft.md
similarity index 99%
rename from courses/223015b/slides/2026-01-30-termin-4-distribution-apis-zukunft.md
rename to slides/223015b/04-distribution-apis-zukunft.md
index b95e53e..336bdfd 100644
--- a/courses/223015b/slides/2026-01-30-termin-4-distribution-apis-zukunft.md
+++ b/slides/223015b/04-distribution-apis-zukunft.md
@@ -98,7 +98,7 @@ Hochschule der Medien Stuttgart
 
 <!-- _class: lead -->
 
-# Termin 4 – 30.01.2026
+# Kapitel 4 – 30.01.2026
 ## Distribution, APIs & Zukunft
 
 ---
diff --git a/courses/223015b/slides/2026-xx-xx-termin-5-vertiefung-offene-fragen.md b/slides/223015b/05-vertiefung-offene-fragen.md
similarity index 99%
rename from courses/223015b/slides/2026-xx-xx-termin-5-vertiefung-offene-fragen.md
rename to slides/223015b/05-vertiefung-offene-fragen.md
index f2a3869..a3c1508 100644
--- a/courses/223015b/slides/2026-xx-xx-termin-5-vertiefung-offene-fragen.md
+++ b/slides/223015b/05-vertiefung-offene-fragen.md
@@ -98,7 +98,7 @@ Hochschule der Medien Stuttgart
 
 <!-- _class: lead -->
 
-# Termin 5 – TBA
+# Kapitel 5 – TBA
 ## Vertiefung & Offene Fragen
 
 ---
diff --git a/courses/223015b/slides/assets/2011-hilbert.png b/slides/223015b/assets/2011-hilbert.png
similarity index 100%
rename from courses/223015b/slides/assets/2011-hilbert.png
rename to slides/223015b/assets/2011-hilbert.png
diff --git a/courses/223015b/slides/assets/8bit-P-character.png b/slides/223015b/assets/8bit-P-character.png
similarity index 100%
rename from courses/223015b/slides/assets/8bit-P-character.png
rename to slides/223015b/assets/8bit-P-character.png
diff --git a/courses/223015b/slides/assets/AV1.png b/slides/223015b/assets/AV1.png
similarity index 100%
rename from courses/223015b/slides/assets/AV1.png
rename to slides/223015b/assets/AV1.png
diff --git a/courses/223015b/slides/assets/Asterisk_with_jpg-artefacts.png b/slides/223015b/assets/Asterisk_with_jpg-artefacts.png
similarity index 100%
rename from courses/223015b/slides/assets/Asterisk_with_jpg-artefacts.png
rename to slides/223015b/assets/Asterisk_with_jpg-artefacts.png
diff --git a/courses/223015b/slides/assets/Barn-yuv.png b/slides/223015b/assets/Barn-yuv.png
similarity index 100%
rename from courses/223015b/slides/assets/Barn-yuv.png
rename to slides/223015b/assets/Barn-yuv.png
diff --git a/courses/223015b/slides/assets/Common_chroma_subsampling_ratios_YCbCr_CORRECTED.svg.png b/slides/223015b/assets/Common_chroma_subsampling_ratios_YCbCr_CORRECTED.svg.png
similarity index 100%
rename from courses/223015b/slides/assets/Common_chroma_subsampling_ratios_YCbCr_CORRECTED.svg.png
rename to slides/223015b/assets/Common_chroma_subsampling_ratios_YCbCr_CORRECTED.svg.png
diff --git a/courses/223015b/slides/assets/Felis_silvestris_silvestris_small_gradual_decrease_of_quality_-_JPEG_compression.jpg b/slides/223015b/assets/Felis_silvestris_silvestris_small_gradual_decrease_of_quality_-_JPEG_compression.jpg
similarity index 100%
rename from courses/223015b/slides/assets/Felis_silvestris_silvestris_small_gradual_decrease_of_quality_-_JPEG_compression.jpg
rename to slides/223015b/assets/Felis_silvestris_silvestris_small_gradual_decrease_of_quality_-_JPEG_compression.jpg
diff --git a/courses/223015b/slides/assets/Posterization_example.jpg b/slides/223015b/assets/Posterization_example.jpg
similarity index 100%
rename from courses/223015b/slides/assets/Posterization_example.jpg
rename to slides/223015b/assets/Posterization_example.jpg
diff --git a/courses/223015b/slides/assets/addaptive-substractive-colors.jpg b/slides/223015b/assets/addaptive-substractive-colors.jpg
similarity index 100%
rename from courses/223015b/slides/assets/addaptive-substractive-colors.jpg
rename to slides/223015b/assets/addaptive-substractive-colors.jpg
diff --git a/courses/223015b/slides/assets/ascii-table-colored.png b/slides/223015b/assets/ascii-table-colored.png
similarity index 100%
rename from courses/223015b/slides/assets/ascii-table-colored.png
rename to slides/223015b/assets/ascii-table-colored.png
diff --git a/courses/223015b/slides/assets/ascii-table.png b/slides/223015b/assets/ascii-table.png
similarity index 100%
rename from courses/223015b/slides/assets/ascii-table.png
rename to slides/223015b/assets/ascii-table.png
diff --git a/courses/223015b/slides/assets/audio-spectrogram.png b/slides/223015b/assets/audio-spectrogram.png
similarity index 100%
rename from courses/223015b/slides/assets/audio-spectrogram.png
rename to slides/223015b/assets/audio-spectrogram.png
diff --git a/courses/223015b/slides/assets/av1-grammy-crop.png b/slides/223015b/assets/av1-grammy-crop.png
similarity index 100%
rename from courses/223015b/slides/assets/av1-grammy-crop.png
rename to slides/223015b/assets/av1-grammy-crop.png
diff --git a/courses/223015b/slides/assets/av1-grammy.png b/slides/223015b/assets/av1-grammy.png
similarity index 100%
rename from courses/223015b/slides/assets/av1-grammy.png
rename to slides/223015b/assets/av1-grammy.png
diff --git a/courses/223015b/slides/assets/av1-logo.png b/slides/223015b/assets/av1-logo.png
similarity index 100%
rename from courses/223015b/slides/assets/av1-logo.png
rename to slides/223015b/assets/av1-logo.png
diff --git a/courses/223015b/slides/assets/bittorrent.png b/slides/223015b/assets/bittorrent.png
similarity index 100%
rename from courses/223015b/slides/assets/bittorrent.png
rename to slides/223015b/assets/bittorrent.png
diff --git a/courses/223015b/slides/assets/cassette-ipod.png b/slides/223015b/assets/cassette-ipod.png
similarity index 100%
rename from courses/223015b/slides/assets/cassette-ipod.png
rename to slides/223015b/assets/cassette-ipod.png
diff --git a/courses/223015b/slides/assets/compression-types.png b/slides/223015b/assets/compression-types.png
similarity index 100%
rename from courses/223015b/slides/assets/compression-types.png
rename to slides/223015b/assets/compression-types.png
diff --git a/courses/223015b/slides/assets/container-codec-diagram.png b/slides/223015b/assets/container-codec-diagram.png
similarity index 100%
rename from courses/223015b/slides/assets/container-codec-diagram.png
rename to slides/223015b/assets/container-codec-diagram.png
diff --git a/courses/223015b/slides/assets/digital-landscape.png b/slides/223015b/assets/digital-landscape.png
similarity index 100%
rename from courses/223015b/slides/assets/digital-landscape.png
rename to slides/223015b/assets/digital-landscape.png
diff --git a/courses/223015b/slides/assets/gif-animation.png b/slides/223015b/assets/gif-animation.png
similarity index 100%
rename from courses/223015b/slides/assets/gif-animation.png
rename to slides/223015b/assets/gif-animation.png
diff --git a/courses/223015b/slides/assets/grayscale-gradient.png b/slides/223015b/assets/grayscale-gradient.png
similarity index 100%
rename from courses/223015b/slides/assets/grayscale-gradient.png
rename to slides/223015b/assets/grayscale-gradient.png
diff --git a/courses/223015b/slides/assets/growth of big data.png b/slides/223015b/assets/growth of big data.png
similarity index 100%
rename from courses/223015b/slides/assets/growth of big data.png
rename to slides/223015b/assets/growth of big data.png
diff --git a/courses/223015b/slides/assets/hex-binary-table.png b/slides/223015b/assets/hex-binary-table.png
similarity index 100%
rename from courses/223015b/slides/assets/hex-binary-table.png
rename to slides/223015b/assets/hex-binary-table.png
diff --git a/courses/223015b/slides/assets/hex-code-hidden.png b/slides/223015b/assets/hex-code-hidden.png
similarity index 100%
rename from courses/223015b/slides/assets/hex-code-hidden.png
rename to slides/223015b/assets/hex-code-hidden.png
diff --git a/courses/223015b/slides/assets/hex-code.png b/slides/223015b/assets/hex-code.png
similarity index 100%
rename from courses/223015b/slides/assets/hex-code.png
rename to slides/223015b/assets/hex-code.png
diff --git a/courses/223015b/slides/assets/hex-dec-lookup-table.png b/slides/223015b/assets/hex-dec-lookup-table.png
similarity index 100%
rename from courses/223015b/slides/assets/hex-dec-lookup-table.png
rename to slides/223015b/assets/hex-dec-lookup-table.png
diff --git a/courses/223015b/slides/assets/hexeditor-screenshot.png b/slides/223015b/assets/hexeditor-screenshot.png
similarity index 100%
rename from courses/223015b/slides/assets/hexeditor-screenshot.png
rename to slides/223015b/assets/hexeditor-screenshot.png
diff --git a/courses/223015b/slides/assets/hollerith-machine-2.jpg b/slides/223015b/assets/hollerith-machine-2.jpg
similarity index 100%
rename from courses/223015b/slides/assets/hollerith-machine-2.jpg
rename to slides/223015b/assets/hollerith-machine-2.jpg
diff --git a/courses/223015b/slides/assets/iframe-pframe-diagram.png b/slides/223015b/assets/iframe-pframe-diagram.png
similarity index 100%
rename from courses/223015b/slides/assets/iframe-pframe-diagram.png
rename to slides/223015b/assets/iframe-pframe-diagram.png
diff --git a/courses/223015b/slides/assets/instagram-quality-loss.png b/slides/223015b/assets/instagram-quality-loss.png
similarity index 100%
rename from courses/223015b/slides/assets/instagram-quality-loss.png
rename to slides/223015b/assets/instagram-quality-loss.png
diff --git a/courses/223015b/slides/assets/ipb-compression-canon.jpg b/slides/223015b/assets/ipb-compression-canon.jpg
similarity index 100%
rename from courses/223015b/slides/assets/ipb-compression-canon.jpg
rename to slides/223015b/assets/ipb-compression-canon.jpg
diff --git a/courses/223015b/slides/assets/jpeg-artifacts.png b/slides/223015b/assets/jpeg-artifacts.png
similarity index 100%
rename from courses/223015b/slides/assets/jpeg-artifacts.png
rename to slides/223015b/assets/jpeg-artifacts.png
diff --git a/courses/223015b/slides/assets/jung-naiv.png b/slides/223015b/assets/jung-naiv.png
similarity index 100%
rename from courses/223015b/slides/assets/jung-naiv.png
rename to slides/223015b/assets/jung-naiv.png
diff --git a/courses/223015b/slides/assets/karlheinz-brandenburg.jpg b/slides/223015b/assets/karlheinz-brandenburg.jpg
similarity index 100%
rename from courses/223015b/slides/assets/karlheinz-brandenburg.jpg
rename to slides/223015b/assets/karlheinz-brandenburg.jpg
diff --git a/courses/223015b/slides/assets/klausur-pattern.svg b/slides/223015b/assets/klausur-pattern.svg
similarity index 100%
rename from courses/223015b/slides/assets/klausur-pattern.svg
rename to slides/223015b/assets/klausur-pattern.svg
diff --git a/courses/223015b/slides/assets/lightbulb-onoff.png b/slides/223015b/assets/lightbulb-onoff.png
similarity index 100%
rename from courses/223015b/slides/assets/lightbulb-onoff.png
rename to slides/223015b/assets/lightbulb-onoff.png
diff --git a/courses/223015b/slides/assets/matrix-code.png b/slides/223015b/assets/matrix-code.png
similarity index 100%
rename from courses/223015b/slides/assets/matrix-code.png
rename to slides/223015b/assets/matrix-code.png
diff --git a/courses/223015b/slides/assets/moores-law.png b/slides/223015b/assets/moores-law.png
similarity index 100%
rename from courses/223015b/slides/assets/moores-law.png
rename to slides/223015b/assets/moores-law.png
diff --git a/courses/223015b/slides/assets/napster-2001.png b/slides/223015b/assets/napster-2001.png
similarity index 100%
rename from courses/223015b/slides/assets/napster-2001.png
rename to slides/223015b/assets/napster-2001.png
diff --git a/courses/223015b/slides/assets/napster-interface.png b/slides/223015b/assets/napster-interface.png
similarity index 100%
rename from courses/223015b/slides/assets/napster-interface.png
rename to slides/223015b/assets/napster-interface.png
diff --git a/courses/223015b/slides/assets/netflix-4k.png b/slides/223015b/assets/netflix-4k.png
similarity index 100%
rename from courses/223015b/slides/assets/netflix-4k.png
rename to slides/223015b/assets/netflix-4k.png
diff --git a/courses/223015b/slides/assets/original-ascii-table.png b/slides/223015b/assets/original-ascii-table.png
similarity index 100%
rename from courses/223015b/slides/assets/original-ascii-table.png
rename to slides/223015b/assets/original-ascii-table.png
diff --git a/courses/223015b/slides/assets/photo-comparison.png b/slides/223015b/assets/photo-comparison.png
similarity index 100%
rename from courses/223015b/slides/assets/photo-comparison.png
rename to slides/223015b/assets/photo-comparison.png
diff --git a/courses/223015b/slides/assets/qr/asciitable.png b/slides/223015b/assets/qr/asciitable.png
similarity index 100%
rename from courses/223015b/slides/assets/qr/asciitable.png
rename to slides/223015b/assets/qr/asciitable.png
diff --git a/courses/223015b/slides/assets/qr/audacity-spectrogram.png b/slides/223015b/assets/qr/audacity-spectrogram.png
similarity index 100%
rename from courses/223015b/slides/assets/qr/audacity-spectrogram.png
rename to slides/223015b/assets/qr/audacity-spectrogram.png
diff --git a/courses/223015b/slides/assets/qr/hexed-it.png b/slides/223015b/assets/qr/hexed-it.png
similarity index 100%
rename from courses/223015b/slides/assets/qr/hexed-it.png
rename to slides/223015b/assets/qr/hexed-it.png
diff --git a/courses/223015b/slides/assets/qr/mediainfo.png b/slides/223015b/assets/qr/mediainfo.png
similarity index 100%
rename from courses/223015b/slides/assets/qr/mediainfo.png
rename to slides/223015b/assets/qr/mediainfo.png
diff --git a/courses/223015b/slides/assets/qr/repo-223015b.png b/slides/223015b/assets/qr/repo-223015b.png
similarity index 100%
rename from courses/223015b/slides/assets/qr/repo-223015b.png
rename to slides/223015b/assets/qr/repo-223015b.png
diff --git a/courses/223015b/slides/assets/qr/slides-223015b.png b/slides/223015b/assets/qr/slides-223015b.png
similarity index 100%
rename from courses/223015b/slides/assets/qr/slides-223015b.png
rename to slides/223015b/assets/qr/slides-223015b.png
diff --git a/courses/223015b/slides/assets/qr/squoosh.png b/slides/223015b/assets/qr/squoosh.png
similarity index 100%
rename from courses/223015b/slides/assets/qr/squoosh.png
rename to slides/223015b/assets/qr/squoosh.png
diff --git a/courses/223015b/slides/assets/qrcode-0.svg b/slides/223015b/assets/qrcode-0.svg
similarity index 100%
rename from courses/223015b/slides/assets/qrcode-0.svg
rename to slides/223015b/assets/qrcode-0.svg
diff --git a/courses/223015b/slides/assets/qrcode-1.svg b/slides/223015b/assets/qrcode-1.svg
similarity index 100%
rename from courses/223015b/slides/assets/qrcode-1.svg
rename to slides/223015b/assets/qrcode-1.svg
diff --git a/courses/223015b/slides/assets/quantized-image-8-colors.jpg b/slides/223015b/assets/quantized-image-8-colors.jpg
similarity index 100%
rename from courses/223015b/slides/assets/quantized-image-8-colors.jpg
rename to slides/223015b/assets/quantized-image-8-colors.jpg
diff --git a/courses/223015b/slides/assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg b/slides/223015b/assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg
similarity index 100%
rename from courses/223015b/slides/assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg
rename to slides/223015b/assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg
diff --git a/courses/223015b/slides/assets/rgb-color-model-with-title.png b/slides/223015b/assets/rgb-color-model-with-title.png
similarity index 100%
rename from courses/223015b/slides/assets/rgb-color-model-with-title.png
rename to slides/223015b/assets/rgb-color-model-with-title.png
diff --git a/courses/223015b/slides/assets/rgb-color-model.png b/slides/223015b/assets/rgb-color-model.png
similarity index 100%
rename from courses/223015b/slides/assets/rgb-color-model.png
rename to slides/223015b/assets/rgb-color-model.png
diff --git a/courses/223015b/slides/assets/spectogram-chet-baker.png b/slides/223015b/assets/spectogram-chet-baker.png
similarity index 100%
rename from courses/223015b/slides/assets/spectogram-chet-baker.png
rename to slides/223015b/assets/spectogram-chet-baker.png
diff --git a/courses/223015b/slides/assets/streaming-quality-switch.png b/slides/223015b/assets/streaming-quality-switch.png
similarity index 100%
rename from courses/223015b/slides/assets/streaming-quality-switch.png
rename to slides/223015b/assets/streaming-quality-switch.png
diff --git a/courses/223015b/slides/assets/suzanne-vega.jpg b/slides/223015b/assets/suzanne-vega.jpg
similarity index 100%
rename from courses/223015b/slides/assets/suzanne-vega.jpg
rename to slides/223015b/assets/suzanne-vega.jpg
diff --git a/courses/223015b/slides/assets/ybcbr.webp b/slides/223015b/assets/ybcbr.webp
similarity index 100%
rename from courses/223015b/slides/assets/ybcbr.webp
rename to slides/223015b/assets/ybcbr.webp
diff --git a/courses/223015b/slides/assets/youtube-vp9.png b/slides/223015b/assets/youtube-vp9.png
similarity index 100%
rename from courses/223015b/slides/assets/youtube-vp9.png
rename to slides/223015b/assets/youtube-vp9.png
diff --git a/slides/223015b/klausur.md b/slides/223015b/klausur.md
new file mode 100644
index 0000000..9485231
--- /dev/null
+++ b/slides/223015b/klausur.md
@@ -0,0 +1,563 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
+footer: "Michael Czechowski – HdM Stuttgart"
+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: #1a1a2e;
+  color: #5fb3e4;
+  padding: 0.15em 0.4em;
+  border-radius: 4px;
+}
+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>
+
+<!--
+  ╔═══════════════════════════════════════════════════════════════════╗
+  ║  AUTO-GENERATED FILE - DO NOT EDIT MANUALLY                       ║
+  ║                                                                   ║
+  ║  This file is generated by: make klausur                          ║
+  ║  Source: scripts/extract-klausur.sh                               ║
+  ║                                                                   ║
+  ║  To update, edit the source slides and re-run make klausur        ║
+  ╚═══════════════════════════════════════════════════════════════════╝
+-->
+
+<!-- _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/)
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Verlustfrei vs. Verlustbehaftet
+
+| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
+|---|---|---|
+| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
+| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich weg) |
+| **Reduktion** | 30-50% | 80-99% |
+| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
+
+**Faustregel:**
+- Medien für Endnutzer → Lossy oft akzeptabel
+- Quellmaterial, Code, Archive → Lossless nötig
+
+<!--
+REDUNDANZ: Wiederholende Muster kompakter darstellen (z.B. "AAAA" → "4×A")
+IRRELEVANZ: Für Menschen nicht wahrnehmbar (Psychoakustik, Psychovisuell)
+
+KLAUSURRELEVANT:
+- Verlustfrei = Original 1:1 wiederherstellbar
+- Verlustbehaftet = Information geht verloren, aber kaum wahrnehmbar
+- Redundanz vs. Irrelevanz ist der Kernunterschied!
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Dateneinheiten
+
+| Einheit | Bytes | Potenz | Beispiel |
+|---------|------:|:------:|----------|
+| **Byte** | 1 | 10⁰ | Farbwerte eines Pixels |
+| **Kilobyte (KB)** | 1.000 | 10³ | Kleiner Programmcode |
+| **Megabyte (MB)** | 1 Million | 10⁶ | Textdokument |
+| **Gigabyte (GB)** | 1 Milliarde | 10⁹ | Kinofilm in FullHD |
+| **Terabyte (TB)** | 1 Billion | 10¹² | ~12h Video in 4K |
+| **Petabyte (PB)** | 1 Billiarde | 10¹⁵ | Netflix-Gesamtarchiv |
+| **Exabyte (EB)** | 1 Trillion | 10¹⁸ | Alle E-Mails weltweit/Tag |
+| **Zettabyte (ZB)** | 1 Trilliarde | 10²¹ | Internet-Traffic 2016 |
+
+<!--
+SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes
+Binär (IEC): 1 KiB = 1.024 Bytes (Kibibyte)
+Windows zeigt oft binär, sagt aber "KB" → Verwirrung!
+1 TB Festplatte = ~931 GiB nutzbar
+
+Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
+→ "Komm Mit Großem Tee, Peter Exte Zettelt Yachten"
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Der digitale Wendepunkt
+
+| Jahr | Analog | Digital | Digital-Anteil |
+|------|--------|---------|----------------|
+| **1986** | 2,6 EB | 0,02 EB | **1%** |
+| **2002** | — | — | **50%** (Wendepunkt) |
+| **2007** | 18 EB | 277 EB | **94%** |
+
+**Perspektive:**
+- 1986: "Petabyte" war ein theoretisches Konzept
+- 2025: ~181 Zettabyte jährlich produziert
+
+**Magnetband lebt:** LTO-Tapes bleiben günstigstes Archivmedium
+(AWS Glacier, Film-Archive, Rechenzentren)
+
+<!--
+PRÜFUNGSRELEVANT:
+ - Wendepunkt 2002
+ - Speichereinheiten (KB→MB→GB→TB→PB→EB→ZB)
+ - Magnetband als Archivmedium
+
+QUELLE: Hilbert & López (2011): "The World's Technological Capacity to Store, Communicate, and Compute Information", Science
+
+METHODIK: 60 analoge + digitale Technologien untersucht (1986-2007)
+
+WENDEPUNKT 2002: Erstmals mehr digital als analog gespeichert
+
+ANALOG damals: Bücher, Zeitungen, Vinyl, VHS, Filmrollen, Fotos
+
+DIGITAL damals: Festplatten, CDs, DVDs, frühe Flash-Speicher
+
+HEUTE: LTO-9 (2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
+
+VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
+
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Analoge Medien
+### Distribution: physisch (Kauf, Verleih, Kopie)
+
+- **Text**
+  - Bücher, Zeitungen, Zeitschriften, Lochkarten
+- **Bild**
+  - Fotografie (Negativ, Dia, Polaroid), Mikrofilm
+- **Audio:**
+  - Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
+- **Video:**
+  - Film (35mm, Super 8), VHS, Betamax
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Digitale Medien
+### Distribution: Datenträger (CD, USB), Download, Streaming, P2P
+
+- **Text**
+  - E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
+- **Bild**
+  - Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
+- **Audio**
+  - Audiodatei (MP3, FLAC, WAV, AAC, OGG)
+- **Video**
+  - Videodatei (MP4, MKV, AVI, WebM)
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Digitale Speichermedien
+
+- **Optische Speicher**
+  - CD, DVD, Blu-ray
+- **Magnetische Speicher**
+  - Festplatte (HDD), Magnetband (LTO)
+- **Flash-Speicher**
+  - SSD, USB-Stick, SD-Karte
+- **Cloud-Speicher**
+  - Dropbox, Google Drive, iCloud, AWS S3
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Rastergrafiken
+
+**Aufbau:** Liste von Pixeln mit Farbwerten (2D-Array)
+
+**Speicherbedarf (unkomprimiert):**
+Breite × Höhe × Farbtiefe (in Bytes)
+
+**Beispiele:** JPEG, PNG, WebP
+
+| Bits (Farbtiefe) | Farben | Anwendung |
+|-----:|-------:|-----------|
+| 1 | 2 | Schwarz/Weiß (Fax) |
+| 8 | 256 | Graustufen, GIF |
+| 24 | 16,7 Mio. | True Color (Standard) |
+| 32 | 16,7 Mio. + Alpha | Transparenz |
+
+<!--
+BERECHNUNG: Breite × Höhe × (Farbtiefe / 8)
+BEISPIEL: 1920×1080 × 24 Bit = 1920×1080×3 = 6.220.800 Bytes ≈ 6,2 MB
+
+Farbtiefe erklärt:
+- 1 Bit: 2^1 = 2 Farben
+- 8 Bit: 2^8 = 256 Farben
+- 24 Bit: 2^24 = 16.777.216 Farben (je 8 Bit für R, G, B)
+- 32 Bit: 24 Bit + 8 Bit Alpha-Kanal
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Vektorgrafiken
+
+**Speicherung als geometrische Primitive:**
+- Pfade (Bézierkurven mit Kontrollpunkten)
+- Grundformen (Rechteck, Ellipse, Polygon)
+- Text (Glyphen als Outlines)
+
+**SVG-Beispiel:**
+```xml
+<circle cx="50" cy="50" r="40" fill="#ff0000"/>
+```
+
+<small>SVG beschreibt nicht jeden einzelnen Pixel im Raster, sondern deklariert wie Farben und Formen gesetzt werden.</small>
+
+<!--
+Vektorgrafiken beschreiben WAS gezeichnet werden soll.
+Rastergrafiken beschreiben WIE jeder Pixel aussieht.
+
+Rendering-Pipeline:
+Vektordaten → Rasterisierung → Framebuffer → Display
+
+Beim Skalieren werden einfach die Koordinaten multipliziert.
+Keine Information geht verloren.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Die Schwächen des Auges
+
+**Menschen sehen:**
+- Helligkeit besser als Farbe
+- Große Flächen besser als feine Details
+- Niedrige Frequenzen besser als hohe
+
+**JPEG nutzt das aus:**
+- Farbauflösung reduzieren (aber Helligkeit behalten)
+- Glatte Flächen effizient speichern
+- Hohe Frequenzen (Details) verwerfen
+
+<!--
+Das ist die visuelle Entsprechung zur Psychoakustik.
+
+Das Auge hat mehr Rezeptoren für Helligkeit (Stäbchen)
+als für Farbe (Zapfen).
+
+Hohe Frequenzen = schnelle Wechsel = feine Details
+Niedrige Frequenzen = langsame Wechsel = große Flächen
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+![bg right:20%](./assets/Barn-yuv.png)
+
+# JPEG: Schritt 1 – Farbraumkonversion
+
+**RGB → Y'CbCr** (seltener Y'UV)
+
+- **Y** = Helligkeit (Luminanz) – Was das Auge am besten sieht
+- **Cb** = Blau-Gelb-Anteil (Chrominanz)
+- **Cr** = Rot-Grün-Anteil (Chrominanz)
+
+**Warum diese Trennung?**
+Y (Helligkeit) behält volle Auflösung.
+Cb/Cr (Farbe) kann reduziert werden – Auge merkt es kaum.
+
+<!--
+YCbCr ist wie RGB ein Tripel aus 3 Werten pro Pixel.
+Der Unterschied: Statt Rot-Grün-Blau speichern wir Helligkeit + 2 Farbdifferenzen.
+
+Die Umrechnung ist reversibel (mathematische Transformation).
+Der Clou: Jetzt können wir Helligkeit und Farbe getrennt behandeln.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# JPEG: Schritt 6 – Huffman-Coding
+
+**Verlustfreie Kompression der Restwerte**
+
+**Idee:** Statt fester 8 Bit pro Wert → variable Bitlänge
+Häufige Werte bekommen kurze Bit-Sequenzen.
+
+| Zeichen | Häufigkeit | Code (Bit-Sequenz) |
+|---------|------------|------|
+| e | 40% | `0` (1 Bit) |
+| a | 25% | `10` (2 Bit) |
+| i | 20% | `110` (3 Bit) |
+| o | 10% | `1110` (4 Bit) |
+| u | 5% | `1111` (4 Bit) |
+
+<!--
+Huffman-Coding ist verlustfrei.
+Der "Code" ist eine Bit-Sequenz, die das Zeichen eindeutig identifiziert.
+Weil "e" am häufigsten vorkommt, bekommt es den kürzesten Code.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Container und Codec
+
+**Container = Das Dateiformat (Beispiel: MP4)**
+Die "Box", die verschiedene Streams zusammenpackt:
+- Video-Stream
+- Audio-Stream(s)
+- Untertitel
+- Metadaten
+
+**Codec = Der Kompressionsalgorithmus (Beispiel: AV1)**
+Entscheidet, WIE komprimiert wird.
+
+
+<!--
+Container ≠ Codec
+Das ist ein häufiges Missverständnis.
+
+MP4 ist ein Container, nicht ein Codec.
+Ein MP4 kann H.264, H.265 oder AV1 enthalten.
+
+Übrigens: JPEG ist ein Codec (für Bilder), kein Container.
+Bei Bildern fallen Container und Codec oft zusammen.
+
+Tools wie MediaInfo zeigen beide Informationen.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# H.264 / AVC
+
+**Advanced Video Coding (2003)**
+
+**Warum dominant?**
+- Exzellente Kompression (~100:1 möglich)
+- Hardware-Support in jedem Gerät seit ~2010
+- YouTube, Netflix, Blu-ray – alles H.264
+
+**Features:**
+- Variable Block-Größen (16×16 bis 4×4)
+- Deblocking-Filter (reduziert Block-Artefakte)
+
+<!--
+H.264 revolutionierte Video-Streaming.
+Ohne H.264 kein Netflix, kein YouTube in HD.
+
+Hardware-Decoder bedeutet: Kein CPU-Aufwand, kein Akku-Drain.
+Selbst billige Smartphones können H.264 abspielen.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# AV1: Die offene Zukunft
+
+**AV1 (2018)**
+
+**Alliance for Open Media:**
+Google, Netflix, Amazon, Microsoft, Apple, Mozilla...
+
+**Eigenschaften:**
+- 30% besser als H.265
+- Royalty-free, Open Source
+- 8K, HDR, hohe Frame-Rates
+
+**Stand 2025:**
+YouTube und Netflix nutzen AV1 für 4K/8K
+Hardware-Encoder in aktuellen GPUs
+
+<!--
+AOM = Alliance for Open Media, gegründet 2015.
+Historisch: Konkurrierende Tech-Giganten vereint.
+
+Das Ziel: Nie wieder Patent-Chaos wie bei H.265.
+
+Problem: Encoding ist sehr langsam (10-100× vs. H.264).
+Hardware-Encoder lösen das zunehmend.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Wann HDD, wann SSD?
+
+| Anwendung | Empfehlung |
+|-----------|------------|
+| Betriebssystem | SSD (NVMe) |
+| Anwendungen, Spiele | SSD |
+| Video-Editing (Projekte) | SSD |
+| Foto-Archiv | HDD oder SSD |
+| Backup | HDD |
+| NAS / Server | HDD (oder Mix) |
+| Cold Storage | HDD oder Band |
+
+<!--
+Die Faustregel:
+- Oft genutzt, schnell gebraucht → SSD
+- Selten genutzt, viel Kapazität → HDD
+
+Viele setzen auf beides:
+Kleine SSD für System + große HDD für Archiv.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Die 3-2-1-Regel
+
+**3** Kopien eurer Daten
+(Original + 2 Backups)
+
+**2** verschiedene Medientypen
+(z.B. SSD + HDD, oder lokal + Cloud)
+
+**1** Kopie an anderem Ort
+(Offsite: Cloud, anderes Gebäude)
+
+<!--
+Herkunft: Peter Krogh, "The DAM Book" (2005)
+
+Warum 3 Kopien?
+- Original kann kaputt gehen
+- Backup 1 auch
+- Backup 2 = Sicherheitspuffer
+
+Warum 2 Medientypen?
+- Gleiche Medien haben gleiche Schwachstellen
+- Batch-Fehler bei HDDs derselben Charge
+
+Warum 1 Offsite?
+- Brand/Wasserschaden zerstört alles vor Ort
+- Ransomware verschlüsselt angeschlossene Laufwerke
+-->
diff --git a/courses/223015b/slides/materials/wtf1 b/slides/223015b/materials/wtf1
similarity index 100%
rename from courses/223015b/slides/materials/wtf1
rename to slides/223015b/materials/wtf1
diff --git a/courses/223015b/slides/materials/wtf2 b/slides/223015b/materials/wtf2
similarity index 100%
rename from courses/223015b/slides/materials/wtf2
rename to slides/223015b/materials/wtf2
diff --git a/courses/223015b/slides/materials/wtf3 b/slides/223015b/materials/wtf3
similarity index 100%
rename from courses/223015b/slides/materials/wtf3
rename to slides/223015b/materials/wtf3
diff --git a/courses/223015c/slides/2025-12-20-termin-1-geschichte-grundlagen-html.md b/slides/223015c/01-geschichte-grundlagen-html.md
similarity index 100%
rename from courses/223015c/slides/2025-12-20-termin-1-geschichte-grundlagen-html.md
rename to slides/223015c/01-geschichte-grundlagen-html.md
diff --git a/courses/223015c/slides/2026-01-10-termin-2-netzwerke-protokolle-css.md b/slides/223015c/02-netzwerke-protokolle-css.md
similarity index 99%
rename from courses/223015c/slides/2026-01-10-termin-2-netzwerke-protokolle-css.md
rename to slides/223015c/02-netzwerke-protokolle-css.md
index 6f88f61..434e9fd 100644
--- a/courses/223015c/slides/2026-01-10-termin-2-netzwerke-protokolle-css.md
+++ b/slides/223015c/02-netzwerke-protokolle-css.md
@@ -1610,21 +1610,6 @@ Das sind die Werkzeuge, mit denen Profis Netzwerk-Probleme debuggen.
 
 <!-- _class: lead -->
 
-# Pause
-## Danach: CSS
-
-<!--
-SPEAKER NOTES:
-
-Kurze Pause. Nutzt die Zeit, um Fragen zu notieren.
-
-Nach der Pause: CSS. Das ist weniger abstrakt – ihr werdet Dinge sehen, die passieren.
--->
-
----
-
-<!-- _class: lead -->
-
 # Teil 2: CSS
 ## Webseiten gestalten
 
@@ -2099,20 +2084,21 @@ Doppelpunkt zur Unterscheidung von Pseudo-Klassen – aber einfacher Doppelpunkt
 /* Mobile First: Basis-Styles */
 .container {
     padding: 1rem;
+    background: white;
 }
 
 /* Ab 768px (Tablet): Anpassungen */
 @media (min-width: 768px) {
     .container {
         padding: 2rem;
-        max-width: 720px;
+        background: red;
     }
 }
 
 /* Ab 1024px (Desktop): Weitere Anpassungen */
 @media (min-width: 1024px) {
     .container {
-        max-width: 960px;
+        background: green;
     }
 }
 ```
diff --git a/courses/223015c/slides/2026-01-24-termin-3-interaktivitaet-javascript.md b/slides/223015c/03-interaktivitaet-javascript.md
similarity index 99%
rename from courses/223015c/slides/2026-01-24-termin-3-interaktivitaet-javascript.md
rename to slides/223015c/03-interaktivitaet-javascript.md
index 6cba149..204de7f 100644
--- a/courses/223015c/slides/2026-01-24-termin-3-interaktivitaet-javascript.md
+++ b/slides/223015c/03-interaktivitaet-javascript.md
@@ -5,7 +5,7 @@ paginate: true
 backgroundColor: #fff
 header: "Grundlagen IT- und Internettechnik (223015c)"
 footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
-title: "Termin 3: Interaktivität & JavaScript"
+title: "Kapitel 3: Interaktivität & JavaScript"
 ---
 
 <style>
@@ -98,7 +98,7 @@ Hochschule der Medien Stuttgart
 
 <!-- _class: lead -->
 
-# Termin 3 – 24.01.2026
+# Kapitel 3 – 24.01.2026
 ## Interaktivität & JavaScript
 
 ---
diff --git a/courses/223015c/slides/assets/8bit-P-character.png b/slides/223015c/assets/8bit-P-character.png
similarity index 100%
rename from courses/223015c/slides/assets/8bit-P-character.png
rename to slides/223015c/assets/8bit-P-character.png
diff --git a/courses/223015c/slides/assets/Ada_Lovelace.jpg b/slides/223015c/assets/Ada_Lovelace.jpg
similarity index 100%
rename from courses/223015c/slides/assets/Ada_Lovelace.jpg
rename to slides/223015c/assets/Ada_Lovelace.jpg
diff --git a/courses/223015c/slides/assets/Ada_Lovelace_daguerreotype_by_Antoine_Claudet_1843_-_cropped.png b/slides/223015c/assets/Ada_Lovelace_daguerreotype_by_Antoine_Claudet_1843_-_cropped.png
similarity index 100%
rename from courses/223015c/slides/assets/Ada_Lovelace_daguerreotype_by_Antoine_Claudet_1843_-_cropped.png
rename to slides/223015c/assets/Ada_Lovelace_daguerreotype_by_Antoine_Claudet_1843_-_cropped.png
diff --git a/courses/223015c/slides/assets/Bletchley_Park_Mansion.jpg b/slides/223015c/assets/Bletchley_Park_Mansion.jpg
similarity index 100%
rename from courses/223015c/slides/assets/Bletchley_Park_Mansion.jpg
rename to slides/223015c/assets/Bletchley_Park_Mansion.jpg
diff --git a/courses/223015c/slides/assets/First_Computer_Bug,_1947.jpg b/slides/223015c/assets/First_Computer_Bug,_1947.jpg
similarity index 100%
rename from courses/223015c/slides/assets/First_Computer_Bug,_1947.jpg
rename to slides/223015c/assets/First_Computer_Bug,_1947.jpg
diff --git a/courses/223015c/slides/assets/Gemini_Generated_Image_9an75b9an75b9an7.png b/slides/223015c/assets/Gemini_Generated_Image_9an75b9an75b9an7.png
similarity index 100%
rename from courses/223015c/slides/assets/Gemini_Generated_Image_9an75b9an75b9an7.png
rename to slides/223015c/assets/Gemini_Generated_Image_9an75b9an75b9an7.png
diff --git a/courses/223015c/slides/assets/Grace_Hopper.jpg b/slides/223015c/assets/Grace_Hopper.jpg
similarity index 100%
rename from courses/223015c/slides/assets/Grace_Hopper.jpg
rename to slides/223015c/assets/Grace_Hopper.jpg
diff --git a/courses/223015c/slides/assets/Hollerith.jpg b/slides/223015c/assets/Hollerith.jpg
similarity index 100%
rename from courses/223015c/slides/assets/Hollerith.jpg
rename to slides/223015c/assets/Hollerith.jpg
diff --git a/courses/223015c/slides/assets/IBM_Front_Cover_2021_from_Amazon.jpg b/slides/223015c/assets/IBM_Front_Cover_2021_from_Amazon.jpg
similarity index 100%
rename from courses/223015c/slides/assets/IBM_Front_Cover_2021_from_Amazon.jpg
rename to slides/223015c/assets/IBM_Front_Cover_2021_from_Amazon.jpg
diff --git a/courses/223015c/slides/assets/alan-turing.jpg b/slides/223015c/assets/alan-turing.jpg
similarity index 100%
rename from courses/223015c/slides/assets/alan-turing.jpg
rename to slides/223015c/assets/alan-turing.jpg
diff --git a/courses/223015c/slides/assets/arpanet-1969.png b/slides/223015c/assets/arpanet-1969.png
similarity index 100%
rename from courses/223015c/slides/assets/arpanet-1969.png
rename to slides/223015c/assets/arpanet-1969.png
diff --git a/courses/223015c/slides/assets/arpanet.jpg b/slides/223015c/assets/arpanet.jpg
similarity index 100%
rename from courses/223015c/slides/assets/arpanet.jpg
rename to slides/223015c/assets/arpanet.jpg
diff --git a/courses/223015c/slides/assets/background-termin-1.png b/slides/223015c/assets/background-termin-1.png
similarity index 100%
rename from courses/223015c/slides/assets/background-termin-1.png
rename to slides/223015c/assets/background-termin-1.png
diff --git a/courses/223015c/slides/assets/background-termin-2.png b/slides/223015c/assets/background-termin-2.png
similarity index 100%
rename from courses/223015c/slides/assets/background-termin-2.png
rename to slides/223015c/assets/background-termin-2.png
diff --git a/courses/223015c/slides/assets/background-termin-3.png b/slides/223015c/assets/background-termin-3.png
similarity index 100%
rename from courses/223015c/slides/assets/background-termin-3.png
rename to slides/223015c/assets/background-termin-3.png
diff --git a/courses/223015c/slides/assets/dehomag-hollerith.webp b/slides/223015c/assets/dehomag-hollerith.webp
similarity index 100%
rename from courses/223015c/slides/assets/dehomag-hollerith.webp
rename to slides/223015c/assets/dehomag-hollerith.webp
diff --git a/courses/223015c/slides/assets/eniac.avif b/slides/223015c/assets/eniac.avif
similarity index 100%
rename from courses/223015c/slides/assets/eniac.avif
rename to slides/223015c/assets/eniac.avif
diff --git a/courses/223015c/slides/assets/hammilton-portrait.jpg b/slides/223015c/assets/hammilton-portrait.jpg
similarity index 100%
rename from courses/223015c/slides/assets/hammilton-portrait.jpg
rename to slides/223015c/assets/hammilton-portrait.jpg
diff --git a/courses/223015c/slides/assets/hammilton.jpg b/slides/223015c/assets/hammilton.jpg
similarity index 100%
rename from courses/223015c/slides/assets/hammilton.jpg
rename to slides/223015c/assets/hammilton.jpg
diff --git a/courses/223015c/slides/assets/hex-dec-lookup-table.png b/slides/223015c/assets/hex-dec-lookup-table.png
similarity index 100%
rename from courses/223015c/slides/assets/hex-dec-lookup-table.png
rename to slides/223015c/assets/hex-dec-lookup-table.png
diff --git a/courses/223015c/slides/assets/hollerith-machine-2.jpg b/slides/223015c/assets/hollerith-machine-2.jpg
similarity index 100%
rename from courses/223015c/slides/assets/hollerith-machine-2.jpg
rename to slides/223015c/assets/hollerith-machine-2.jpg
diff --git a/courses/223015c/slides/assets/hollerith-machine-3.jpg b/slides/223015c/assets/hollerith-machine-3.jpg
similarity index 100%
rename from courses/223015c/slides/assets/hollerith-machine-3.jpg
rename to slides/223015c/assets/hollerith-machine-3.jpg
diff --git a/courses/223015c/slides/assets/hollerith-machine.jpg b/slides/223015c/assets/hollerith-machine.jpg
similarity index 100%
rename from courses/223015c/slides/assets/hollerith-machine.jpg
rename to slides/223015c/assets/hollerith-machine.jpg
diff --git a/courses/223015c/slides/assets/hollerith-machine.tif b/slides/223015c/assets/hollerith-machine.tif
similarity index 100%
rename from courses/223015c/slides/assets/hollerith-machine.tif
rename to slides/223015c/assets/hollerith-machine.tif
diff --git a/courses/223015c/slides/assets/john-von-neumann.png b/slides/223015c/assets/john-von-neumann.png
similarity index 100%
rename from courses/223015c/slides/assets/john-von-neumann.png
rename to slides/223015c/assets/john-von-neumann.png
diff --git a/courses/223015c/slides/assets/klausur-pattern.svg b/slides/223015c/assets/klausur-pattern.svg
similarity index 100%
rename from courses/223015c/slides/assets/klausur-pattern.svg
rename to slides/223015c/assets/klausur-pattern.svg
diff --git a/courses/223015c/slides/assets/lightbulb-onoff.png b/slides/223015c/assets/lightbulb-onoff.png
similarity index 100%
rename from courses/223015c/slides/assets/lightbulb-onoff.png
rename to slides/223015c/assets/lightbulb-onoff.png
diff --git a/courses/223015c/slides/assets/oppenheimer.png b/slides/223015c/assets/oppenheimer.png
similarity index 100%
rename from courses/223015c/slides/assets/oppenheimer.png
rename to slides/223015c/assets/oppenheimer.png
diff --git a/courses/223015c/slides/assets/qr/codepen.png b/slides/223015c/assets/qr/codepen.png
similarity index 100%
rename from courses/223015c/slides/assets/qr/codepen.png
rename to slides/223015c/assets/qr/codepen.png
diff --git a/courses/223015c/slides/assets/qr/codescripsi.png b/slides/223015c/assets/qr/codescripsi.png
similarity index 100%
rename from courses/223015c/slides/assets/qr/codescripsi.png
rename to slides/223015c/assets/qr/codescripsi.png
diff --git a/courses/223015c/slides/assets/qr/cssgridgarden.png b/slides/223015c/assets/qr/cssgridgarden.png
similarity index 100%
rename from courses/223015c/slides/assets/qr/cssgridgarden.png
rename to slides/223015c/assets/qr/cssgridgarden.png
diff --git a/courses/223015c/slides/assets/qr/flexboxfroggy.png b/slides/223015c/assets/qr/flexboxfroggy.png
similarity index 100%
rename from courses/223015c/slides/assets/qr/flexboxfroggy.png
rename to slides/223015c/assets/qr/flexboxfroggy.png
diff --git a/courses/223015c/slides/assets/qr/freecodecamp.png b/slides/223015c/assets/qr/freecodecamp.png
similarity index 100%
rename from courses/223015c/slides/assets/qr/freecodecamp.png
rename to slides/223015c/assets/qr/freecodecamp.png
diff --git a/courses/223015c/slides/assets/qr/html-over-js.png b/slides/223015c/assets/qr/html-over-js.png
similarity index 100%
rename from courses/223015c/slides/assets/qr/html-over-js.png
rename to slides/223015c/assets/qr/html-over-js.png
diff --git a/courses/223015c/slides/assets/qr/mandala.png b/slides/223015c/assets/qr/mandala.png
similarity index 100%
rename from courses/223015c/slides/assets/qr/mandala.png
rename to slides/223015c/assets/qr/mandala.png
diff --git a/courses/223015c/slides/assets/qr/mdn-button.png b/slides/223015c/assets/qr/mdn-button.png
similarity index 100%
rename from courses/223015c/slides/assets/qr/mdn-button.png
rename to slides/223015c/assets/qr/mdn-button.png
diff --git a/courses/223015c/slides/assets/qr/mdn-details.png b/slides/223015c/assets/qr/mdn-details.png
similarity index 100%
rename from courses/223015c/slides/assets/qr/mdn-details.png
rename to slides/223015c/assets/qr/mdn-details.png
diff --git a/courses/223015c/slides/assets/qr/mdn-dialog.png b/slides/223015c/assets/qr/mdn-dialog.png
similarity index 100%
rename from courses/223015c/slides/assets/qr/mdn-dialog.png
rename to slides/223015c/assets/qr/mdn-dialog.png
diff --git a/courses/223015c/slides/assets/qr/mdn-input.png b/slides/223015c/assets/qr/mdn-input.png
similarity index 100%
rename from courses/223015c/slides/assets/qr/mdn-input.png
rename to slides/223015c/assets/qr/mdn-input.png
diff --git a/courses/223015c/slides/assets/qr/mdn.png b/slides/223015c/assets/qr/mdn.png
similarity index 100%
rename from courses/223015c/slides/assets/qr/mdn.png
rename to slides/223015c/assets/qr/mdn.png
diff --git a/courses/223015c/slides/assets/qr/odinproject.png b/slides/223015c/assets/qr/odinproject.png
similarity index 100%
rename from courses/223015c/slides/assets/qr/odinproject.png
rename to slides/223015c/assets/qr/odinproject.png
diff --git a/courses/223015c/slides/assets/qr/repo-223015c.png b/slides/223015c/assets/qr/repo-223015c.png
similarity index 100%
rename from courses/223015c/slides/assets/qr/repo-223015c.png
rename to slides/223015c/assets/qr/repo-223015c.png
diff --git a/courses/223015c/slides/assets/qr/slides-223015c.png b/slides/223015c/assets/qr/slides-223015c.png
similarity index 100%
rename from courses/223015c/slides/assets/qr/slides-223015c.png
rename to slides/223015c/assets/qr/slides-223015c.png
diff --git a/courses/223015c/slides/assets/qr/vscode.png b/slides/223015c/assets/qr/vscode.png
similarity index 100%
rename from courses/223015c/slides/assets/qr/vscode.png
rename to slides/223015c/assets/qr/vscode.png
diff --git a/slides/223015c/klausur.md b/slides/223015c/klausur.md
new file mode 100644
index 0000000..8896fbb
--- /dev/null
+++ b/slides/223015c/klausur.md
@@ -0,0 +1,650 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Grundlagen IT- und Internettechnik (223015c)"
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+title: "Kapitel 1: Geschichte, Grundlagen & HTML"
+---
+<style>
+:root {
+  --color-foreground: #1a1a2e;
+  --color-highlight: #d63384;
+  --color-dimmed: #4a4a6a;
+}
+section.invert {
+  --color-foreground: #fff;
+}
+section {
+  font-size: 1.7rem;
+}
+h1 {
+  color: #a02060;  /* darker raspberry */
+}
+section.invert h1 {
+  color: #fff;
+}
+h2 {
+  color: #1f2937;  /* dark gray, almost black */
+}
+pre {
+  background: #0f0f23;
+  color: #d63384;
+  border-radius: 8px;
+  border-left: 3px solid #d63384;
+}
+pre code {
+  background: transparent;
+  color: inherit;
+}
+code {
+  background: #1a1a2e;
+  color: #d63384;
+  padding: 0.15em 0.4em;
+  border-radius: 4px;
+}
+a {
+  color: var(--color-highlight);
+}
+section.klausur {
+  background: repeating-linear-gradient(
+    135deg,
+    #fce4ec,
+    #fce4ec 40px,
+    #fff 40px,
+    #fff 80px
+  ) !important;
+}
+@media print {
+  section.klausur {
+    background: #fce4ec !important;
+  }
+}
+section.aufgabe {
+  background: #fce4ec !important;
+}
+section.aufgabe footer {
+  display: none;
+}
+</style>
+
+<!--
+  ╔═══════════════════════════════════════════════════════════════════╗
+  ║  AUTO-GENERATED FILE - DO NOT EDIT MANUALLY                       ║
+  ║                                                                   ║
+  ║  This file is generated by: make klausur                          ║
+  ║  Source: scripts/extract-klausur.sh                               ║
+  ║                                                                   ║
+  ║  To update, edit the source slides and re-run make klausur        ║
+  ╚═══════════════════════════════════════════════════════════════════╝
+-->
+
+<!-- _class: invert -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+<!-- _backgroundColor: black -->
+
+![bg fit opacity:0.2](./assets/background-termin-2.png)
+
+# Grundlagen IT- und Internettechnik
+
+**223015c** · Modul "Technik 1" · 1. Semester
+Digital- und Medienwirtschaft
+Hochschule der Medien Stuttgart
+
+**Wintersemester 2025/26**
+
+[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Die 5 Komponenten
+
+| Komponente | Funktion |
+|------------|----------|
+| **Rechenwerk (ALU)** | Führt Berechnungen durch |
+| **Steuerwerk** | Interpretiert Befehle, steuert Ablauf |
+| **Speicherwerk** | Speichert Programme UND Daten |
+| **Ein-/Ausgabe** | Tastatur, Bildschirm, Netzwerk |
+| **Bus-System** | Verbindet alle Komponenten |
+
+**Wichtig:** Programme und Daten **gemeinsam** im Speicher!
+
+<!--
+VON-NEUMANN-ARCHITEKTUR (1945): Grundlage aller modernen Computer
+5 KOMPONENTEN:
+- ALU (Arithmetic Logic Unit): Rechnet (+, -, ×, ÷) und vergleicht (>, <, =)
+- Steuerwerk: Holt Befehle, dekodiert sie, steuert Ausführung (Fetch-Decode-Execute)
+- Speicherwerk: RAM (flüchtig) + ROM (permanent), enthält Code UND Daten
+- Ein-/Ausgabe (I/O): Tastatur, Maus, Bildschirm, Netzwerk, USB, Sensoren
+- Bus-System: Adressbus (wo), Datenbus (was), Steuerbus (wie)
+KERNPRINZIP: Stored Program Concept - Programme im selben Speicher wie Daten
+VORHER (z.B. ENIAC): Programme durch Umstecken von Kabeln, tagelange Arbeit
+NACHHER: Programme als austauschbare Daten → Flexibilität, Software-Industrie möglich
+PRÜFUNGSRELEVANT: 5 Komponenten benennen und erklären können, Stored Program Concept
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Von-Neumann-Architektur: Bedeutung
+
+**Ohne Von-Neumann-Architektur:**
+- Kein Betriebssystem
+- Keine Apps
+- Kein Multitasking
+- Keine Updates bzw. Veränderungen am Computer System
+
+**Die meisten Computer** basieren auf diesem Prinzip:
+Laptop, Smartphone, Server, Spielkonsole...
+
+**Ausnahme:** Mikrocontroller & DSPs nutzen oft die **Harvard-Architektur**
+(separate Speicher für Code und Daten → schneller für Echtzeitanwendungen)
+
+<!--
+BEDEUTUNG VON-NEUMANN-ARCHITEKTUR:
+- Betriebssystem möglich: Lädt verschiedene Programme aus gleichem Speicher
+- Apps installierbar: Können gelöscht/installiert werden ohne Hardware-Änderung
+- Multitasking: Mehrere Programme gleichzeitig im Speicher
+- Updates: Software austauschbar, Hardware bleibt gleich
+- Universalrechner: Gleiche Hardware für Text, Spiele, Video, Wissenschaft
+HARVARD-ARCHITEKTUR (Alternative):
+- Separate Speicher für Code und Daten
+- Vorteil: Schneller (paralleler Zugriff), sicherer (Code nicht überschreibbar)
+- Nachteil: Weniger flexibel, aufwändiger
+- Anwendung: Mikrocontroller (Arduino, ESP32), DSPs, einige ARM-Chips
+MODERNE CPUs: Modified Harvard (L1-Cache getrennt für Speed, RAM gemeinsam für Flexibilität)
+PRÜFUNGSRELEVANT: Warum Von-Neumann revolutionär, Unterschied zu Harvard, Beispiele
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# HTML Metadaten
+
+```html
+<html>
+  <head>
+    <title>Im Browsertab als Überschrift sichtbar</title>
+
+    <meta name="description" content="" />
+
+    <meta name="og:image" content="https://...." />
+  </head>
+
+  ...
+
+</html>
+```
+
+- <small>*Webseiten werden nicht nur von Menschen besucht, sondern auch von Suchmaschinen, Programmen, Bots etc.*</small>
+- <small>*Metadaten helfen bspw. auch Screen-Readern beim "Verstehen" der Inhalte*</small>
+
+<!--
+HEAD-BEREICH: Metadaten, nicht sichtbar im Browser-Fenster
+WICHTIGE META-TAGS:
+- <title>: Browser-Tab, Lesezeichen, Suchergebnis-Titel
+- <meta name="description">: Suchergebnis-Snippet (max. 160 Zeichen)
+- <meta name="viewport">: Mobile Darstellung (width=device-width)
+- <meta charset="UTF-8">: Zeichenkodierung (Umlaute!)
+OPEN GRAPH (og:*): Social Media Vorschau (Facebook, LinkedIn, WhatsApp)
+- og:title, og:description, og:image, og:url
+TWITTER CARDS: twitter:card, twitter:title, twitter:image
+SEO-RELEVANZ: Google nutzt title + description für Ranking und Snippet
+ACCESSIBILITY: <html lang="de"> für Screenreader-Aussprache
+PRÜFUNGSRELEVANT: Was gehört in <head>, Unterschied zu <body>, wichtigste Meta-Tags
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Wie nutzen Menschen das Web?
+
+| Eingabe | Nutzungsweise |
+|---------|---------------|
+| **Maus** | Klicken, Scrollen |
+| **Tastatur** | Tab-Navigation, Enter, Pfeiltasten |
+| **Screenreader** | Vorlesen von Inhalten (NVDA, VoiceOver, JAWS) |
+| **Sprachsteuerung** | "Klicke auf Anmelden" |
+| **Augensteuerung** | Eye-Tracking |
+| **Switch-Geräte** | Ein-/Aus-Schalter |
+
+→ **Nicht alle nutzen Maus + Bildschirm!**
+
+<!--
+ACCESSIBILITY (a11y): a + 11 Buchstaben + y
+STATISTIK: ~15% der Weltbevölkerung haben eine Behinderung (WHO)
+ARTEN VON EINSCHRÄNKUNGEN:
+- Permanent: Blindheit, Taubheit, motorische Einschränkungen
+- Temporär: Gebrochener Arm, Augen-OP, Ohrenentzündung
+- Situativ: Helle Sonne (Kontrast), laute Umgebung (kein Audio), Baby auf Arm (eine Hand)
+ASSISTIVE TECHNOLOGIEN:
+- Screenreader: NVDA (Windows, kostenlos), VoiceOver (Apple), JAWS (kommerziell)
+- Braillezeilen: Taktile Ausgabe für Blinde
+- Switch-Geräte: Für motorische Einschränkungen
+- Spracheingabe: Dragon NaturallySpeaking, Siri, Google Assistant
+WCAG: Web Content Accessibility Guidelines (A, AA, AAA)
+EUROPEAN ACCESSIBILITY ACT: Seit Juni 2025 verpflichtend!
+PRÜFUNGSRELEVANT: Arten von Einschränkungen, Screenreader-Beispiele, WCAG
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Warum "Barrierefreiheit"?
+
+**Rechtlich:**
+- EU: European Accessibility Act (seit Juni 2025 in Kraft!)
+- DE: BITV 2.0 (Behörden), Privatwirtschaft betroffen
+
+**Ethisch:**
+- Teilhabe für alle Menschen
+- Digitale Inklusion
+
+**Praktisch:**
+- Bessere UX für **alle** (SEO, Mobile, ältere Menschen)
+- Größerer Markt (~15% der Bevölkerung)
+
+<!--
+RECHTLICHER RAHMEN:
+- European Accessibility Act (EAA): EU-Richtlinie, seit 28. Juni 2025 in Kraft
+- Betrifft: E-Commerce, Banking, Telekommunikation, Transport, E-Books
+- BITV 2.0: Barrierefreie Informationstechnik-Verordnung (DE, öffentliche Stellen)
+- BFSG: Barrierefreiheitsstärkungsgesetz (DE-Umsetzung des EAA)
+- Strafen: Bis zu 100.000€ Bußgeld möglich
+CURB-CUT-EFFEKT:
+- Bordsteinabsenkung für Rollstuhlfahrer → hilft auch Kinderwagen, Rollkoffern, Fahrrädern
+- Untertitel für Gehörlose → helfen in lauter Umgebung, beim Sprachlernen
+- Kontrastreiche Farben → besser bei Sonnenlicht, für ältere Menschen
+BUSINESS CASE:
+- 15% Zielgruppe (Menschen mit Behinderung)
+- +20% ältere Menschen (Sehschwäche, motorische Einschränkungen)
+- SEO-Vorteile: Alt-Texte, semantisches HTML = besser für Google
+PRÜFUNGSRELEVANT: EAA kennen, Curb-Cut-Effekt erklären können, Business Case
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Barrieren im Netz vermeiden (a11y)
+
+**Tastatur-Test:**
+- Alle Funktionen nur mit Tab + Enter nutzbar?
+- Fokus immer sichtbar?
+- Logische Tab-Reihenfolge?
+
+**Screenreader-Test:**
+- VoiceOver (Mac): `Cmd + F5`
+- NVDA (Windows): Gratis-Download
+
+**Tools:**
+- axe DevTools, WAVE (Browser-Extensions)
+- Lighthouse (in Chrome DevTools)
+
+<!--
+Automatische Tests finden ~30% der Probleme
+Manuelles Testen unverzichtbar
+Echte NutzerInnen einbeziehen = Gold-Standard
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Das TCP/IP-Modell
+
+| Schicht | Name | Aufgabe | Protokolle |
+|---------|------|---------|------------|
+| **4** | Anwendung | Was? Welcher Dienst? | HTTP, DNS, SMTP |
+| **3** | Transport | Zuverlässigkeit, Ports | TCP, UDP |
+| **2** | Internet | Routing, globale Adressen | IP |
+| **1** | Netzzugang | Lokale Übertragung | Ethernet, WLAN |
+
+**4 Schichten. Das reicht, um das Internet zu verstehen.**
+
+<!--
+SPEAKER NOTES:
+- TCP/IP = das echte Internet
+- 4 Schichten:
+  - Anwendung: Was will ich? (HTTP, DNS, Mail)
+  - Transport: Kommt an? Welches Programm? (TCP, UDP)
+  - Internet: Wie zum Zielrechner? (IP)
+  - Netzzugang: Wie zum nächsten Gerät? (Ethernet, WLAN)
+- KLAUSUR: Welches Protokoll → welche Schicht
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Dateneinheiten pro Schicht
+
+| Schicht | Name | Dateneinheit | Was kommt hinzu? |
+|---------|------|--------------|------------------|
+| Anwendung | HTTP, DNS | **Daten** | – |
+| Transport | TCP, UDP | **Segment** | Ports, Sequenznummern |
+| Internet | IP | **Paket** | IP-Adressen |
+| Netzzugang | Ethernet | **Frame** | MAC-Adressen, Prüfsumme |
+
+Merkhilfe: **D**aten → **S**egment → **P**aket → **F**rame
+(„**D**er **S**ache **P**raktischer **F**olgen")
+
+<!--
+SPEAKER NOTES:
+- Glossar-Begriffe jetzt eingeordnet:
+  - Anwendung: Daten/Message
+  - Transport: Segment
+  - Internet: Paket
+  - Netzzugang: Frame
+- Merkhilfe: D-S-P-F (eigene erfinden!)
+- KLAUSUR: Begriff → Schicht
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# IP vs. MAC vs. Port
+
+| | IP-Adresse | MAC-Adresse | Port |
+|---|-----------|-------------|------|
+| **Frage** | Welcher Rechner? | Welches Gerät nebenan? | Welches Programm? |
+| **Reichweite** | Global | Lokal (1 Hop) | Auf einem Rechner |
+| **Ändert sich?** | Nein | Ja, bei jedem Hop | Nein |
+| **Schicht** | Internet (IP) | Netzzugang (Ethernet) | Transport (TCP/UDP) |
+| **Beispiel** | 212.132.79.37 | aa:bb:cc:dd:ee | 443 |
+
+<!--
+SPEAKER NOTES:
+- KLAUSUR: Diese Tabelle
+- IP: Welcher Rechner? Global. Bleibt gleich.
+- MAC: Welcher Nachbar? Lokal. Ändert sich.
+- Port: Welches Programm? Bleibt gleich.
+- Merken: NUR MAC ändert sich unterwegs
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Der 3-Way-Handshake
+
+```
+Client (dein Laptop)                      Server
+    |                                        |
+    |-------- SYN (Seq=1000) --------------->|
+    |         "Ich will reden"               |
+    |                                        |
+    |<--- SYN-ACK (Seq=5000, Ack=1001) ------|
+    |     "OK, ich auch. Ich starte bei 5000"|
+    |                                        |
+    |-------- ACK (Ack=5001) --------------->|
+    |         "Verstanden, los geht's"       |
+    |                                        |
+    |        [ Verbindung steht ]            |
+```
+
+**SYN** = Synchronize · **ACK** = Acknowledge
+
+<!--
+SPEAKER NOTES:
+- 3 Pakete → Verbindung steht
+- 1. Client SYN: "Will Verbindung, starte bei 1000"
+- 2. Server SYN-ACK: "OK, ich starte bei 5000, erwarte 1001"
+- 3. Client ACK: "Verstanden, erwarte 5001"
+- Seq-Nr wichtig: Beide wissen nächstes erwartetes Byte
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# TCP vs. UDP
+
+| | TCP | UDP |
+|---|-----|-----|
+| **Verbindung** | Ja (Handshake) | Nein |
+| **Reihenfolge** | Garantiert | Nicht garantiert |
+| **Verlorene Pakete** | Werden nachgefordert | Gehen verloren |
+| **Overhead** | Höher | Niedriger |
+| **Use Cases** | Web, Email, Downloads | Video-Calls, Gaming, DNS |
+
+<!--
+SPEAKER NOTES:
+- Zwei Transport-Protokolle
+- TCP: zuverlässig
+  - Handshake, Seq-Nr, Bestätigungen, Neuübertragung
+  - Perfekt für Web, Downloads (nichts darf fehlen)
+- UDP: schneller
+  - Kein Handshake, keine Bestätigungen
+  - Verloren = weg
+  - Perfekt für Video-Calls (Verzögerung schlimmer als Verlust)
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# HTTP-Methoden
+
+| Methode | Bedeutung | Beispiel |
+|---------|-----------|----------|
+| **GET** | Daten abrufen | Seite laden |
+| **POST** | Daten senden | Formular absenden |
+| **PUT** | Daten ersetzen | Profil aktualisieren |
+| **DELETE** | Daten löschen | Account löschen |
+
+```http
+GET /index.html HTTP/1.1
+POST /login HTTP/1.1
+```
+
+<!--
+SPEAKER NOTES:
+
+Zum Schluss noch HTTP-Methoden.
+
+GET ist das häufigste – "gib mir was". Wenn ihr eine URL aufruft, ist das ein GET.
+
+POST schickt Daten zum Server – wenn ihr ein Formular abschickt.
+
+PUT und DELETE sind für APIs – ersetzen oder löschen von Ressourcen.
+
+Das wird wichtiger, wenn ihr mit REST-APIs arbeitet.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# HTTP Status-Codes
+
+```http
+HTTP/1.1 200 OK
+HTTP/1.1 404 Not Found
+HTTP/1.1 500 Internal Server Error
+```
+
+| Code-Bereich | Bedeutung |
+|--------------|-----------|
+| **2xx** | Erfolg (200 OK, 201 Created) |
+| **3xx** | Umleitung (301 Moved, 304 Not Modified) |
+| **4xx** | Client-Fehler (400 Bad Request, 404 Not Found) |
+| **5xx** | Server-Fehler (500 Internal Error, 503 Unavailable) |
+
+<!--
+SPEAKER NOTES:
+
+Status-Codes sagen euch, was passiert ist.
+
+2xx heißt: Alles gut. 200 OK ist der Normalfall.
+
+3xx heißt: Umleitung. Die Seite ist woanders.
+
+4xx heißt: Ihr habt was falsch gemacht. 404 kennt ihr – Seite nicht gefunden. 403 heißt: Zugriff verweigert.
+
+5xx heißt: Der Server hat ein Problem. 500 ist ein generischer Fehler, 503 heißt: Server überlastet.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Zusammenfassung Teil 1
+
+**Der Ablauf:**
+1. DNS (UDP:53) → Name zu IP
+2. TCP-Handshake (SYN → SYN-ACK → ACK)
+3. HTTP-Request (GET /...)
+4. HTTP-Response (200 OK + HTML)
+
+**Die Konzepte:**
+- 4 Schichten: Anwendung → Transport → Internet → Netzzugang
+- IP bleibt gleich, MAC ändert sich pro Hop
+- Ports identifizieren Programme
+- Encapsulation: Jede Schicht verpackt die darüberliegende
+
+<!--
+SPEAKER NOTES:
+
+Das ist die Zusammenfassung für Teil 1. Das solltet ihr können:
+
+Den Ablauf: DNS, TCP-Handshake, HTTP-Request, HTTP-Response.
+
+Die Schichten und ihre Protokolle.
+
+Den Unterschied zwischen IP und MAC – was bleibt gleich, was ändert sich.
+
+Was Ports tun.
+
+Wie Encapsulation funktioniert.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Spezifität: Welche Regel gewinnt?
+
+| Selektor | Spezifität |
+|----------|------------|
+| Element (`p`) | 0,0,0,1 |
+| Klasse (`.wichtig`) | 0,0,1,0 |
+| ID (`#header`) | 0,1,0,0 |
+| Inline (`style="..."`) | 1,0,0,0 |
+
+```css
+p { color: blue; }           /* 0,0,0,1 */
+.text { color: green; }      /* 0,0,1,0 → gewinnt */
+#intro { color: red; }       /* 0,1,0,0 → gewinnt über beide */
+```
+
+<!--
+SPEAKER NOTES:
+
+Wenn mehrere Regeln auf ein Element zutreffen, gewinnt die spezifischere.
+
+Spezifität wird in vier Zahlen gemessen. Von links nach rechts: Inline, IDs, Klassen, Elemente.
+
+Ein Element-Selektor hat 0,0,0,1. Eine Klasse hat 0,0,1,0. Eine ID hat 0,1,0,0.
+
+0,0,1,0 schlägt 0,0,0,99 – auch hundert Element-Selektoren schlagen keine Klasse.
+
+Inline-Styles schlagen alles – außer !important, was ihr vermeiden solltet.
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# Responsive Design
+
+```css
+/* Mobile First: Basis-Styles */
+.container {
+    padding: 1rem;
+    background: white;
+}
+
+/* Ab 768px (Tablet): Anpassungen */
+@media (min-width: 768px) {
+    .container {
+        padding: 2rem;
+        background: red;
+    }
+}
+
+/* Ab 1024px (Desktop): Weitere Anpassungen */
+@media (min-width: 1024px) {
+    .container {
+        background: green;
+    }
+}
+```
+
+<!--
+SPEAKER NOTES:
+
+Responsive Design: Die Seite passt sich der Bildschirmgröße an.
+
+Mobile First: Ihr schreibt zuerst die Styles für kleine Screens. Dann fügt ihr mit @media-Queries Anpassungen für größere Screens hinzu.
+
+min-width heißt: "ab dieser Breite". Also: Basis gilt für alle. Ab 768px gelten zusätzliche Regeln. Ab 1024px noch mehr.
+
+Das Gegenteil wäre Desktop First mit max-width – aber Mobile First ist heute Standard.
+-->