From fb0db03db952ac2ff1183adc49524ffcd68e1442 Mon Sep 17 00:00:00 2001
From: Michael Czechowski <mail@dailysh.it>
Date: Mon, 2 Feb 2026 13:41:42 +0100
Subject: [PATCH 1/8] restore 01-grundlagen.md for 223015b

accidentally removed in a8343c9, restored from d77b0f2

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---
 slides/223015b/01-grundlagen.md | 2215 +++++++++++++++++++++++++++++++
 1 file changed, 2215 insertions(+)
 create mode 100644 slides/223015b/01-grundlagen.md

diff --git a/slides/223015b/01-grundlagen.md b/slides/223015b/01-grundlagen.md
new file mode 100644
index 0000000..372a66c
--- /dev/null
+++ b/slides/223015b/01-grundlagen.md
@@ -0,0 +1,2215 @@
+---
+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;
+}
+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.
+-->
+Medien
+---
+
+# 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)

From 9f2c78d536ee7b93d81b6e82b535ec940fedc1e6 Mon Sep 17 00:00:00 2001
From: Michael Czechowski <mail@dailysh.it>
Date: Mon, 2 Feb 2026 13:41:48 +0100
Subject: [PATCH 2/8] add course-specific klausurfragen files

split klausurfragen by course with appropriate CI:
- 223015b: blocks J-O (dateiformate) with blue CI
- 223015c: blocks A-I (IT-grundlagen) with pink CI

preserves existing disable markers for non-klausur questions

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---
 slides/223015b/klausurfragen.md | 924 +++++++++++++++++++++++++++++++
 slides/223015c/klausurfragen.md | 938 ++++++++++++++++++++++++++++++++
 2 files changed, 1862 insertions(+)
 create mode 100644 slides/223015b/klausurfragen.md
 create mode 100644 slides/223015c/klausurfragen.md

diff --git a/slides/223015b/klausurfragen.md b/slides/223015b/klausurfragen.md
new file mode 100644
index 0000000..09380f0
--- /dev/null
+++ b/slides/223015b/klausurfragen.md
@@ -0,0 +1,924 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Klausurfragen – 223015b"
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+title: "Klausurfragen – Dateiformate, Schnittstellen, Speichermedien"
+---
+<style>
+:root {
+  --color-foreground: #1a1a2e;
+  --color-highlight: #1e5f8a;
+  --color-dimmed: #4a4a6a;
+}
+section.invert { --color-foreground: #fff; }
+section { font-size: 1.325rem; }
+h1 { color: #1e5f8a; }
+section.invert h1 { color: #fff; }
+h2 { color: #1f2937; }
+pre { background: #0f0f23; border-radius: 8px; }
+pre code { background: transparent; color: inherit; }
+a { color: var(--color-highlight); }
+section.disable { opacity: 0.3; }
+</style>
+
+# Klausurfragen – 223015b
+**Dateiformate, Schnittstellen, Speichermedien · HdM Stuttgart · M. Czechowski**
+
+<small>Stand: 02.02.2026</small>
+
+---
+
+> **Legende – Moodle XML-Typen:**
+> `[MC]` = `multichoice` (einzelne Auswahl)
+> `[MM]` = `multichoice` + `<single>false</single>` (Mehrfachauswahl)
+> `[MATCH]` = `matching` (Zuordnung)
+> `[ORDER]` = `ordering` (Reihenfolge)
+> `[ESSAY]` = `essay` (Freitext, manuell bewertet)
+> `[SHORTANS]` = `shortanswer` (Stichwort/Satz, automatisch geprüft)
+> `[NUMERIC]` = `numerical` (Zahlenwert ± Toleranz)
+> `[CLOZE]` = `cloze` (Lückentext, gemischt)
+
+---
+
+<!-- _class: lead -->
+
+## BLOCK J – Dateiformate: Grundbegriffe
+
+---
+
+### J1 – Was bedeutet „komprimieren"?
+**Thema:** Grundbegriffe – Kompression
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was bedeutet es, eine Datei zu komprimieren?
+
+- [ ] Die Datei wird auf einem anderen Speichermedium gesichert.
+- [x] **Die Dateigröße wird durch Entfernung oder Vereinfachung von Daten reduziert.** ✅
+- [ ] Die Datei wird verschlüsselt, damit sie kleiner aussieht.
+- [ ] Die Datei wird in ein anderen Format umgewandelt, ohne dass sich die Größe ändert.
+
+> **Feedback:** Kompression = Dateigröße reduzieren. Zwei Familien: verlustfrei (alle Daten bleiben erhalten, z. B. ZIP, PNG) und verlustbehaftet (Daten werden dauerhaft weggeworfen, z. B. JPEG, MP3).
+
+---
+
+### J2 – Verlustfrei vs. verlustbehaftet
+**Thema:** Grundbegriffe – Kompressionsprimitiven
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Format zu, ob es verlustfrei oder verlustbehaftet komprimiert.
+
+| Format | Kompressions-Typ |
+|---|---|
+| JPEG | Verlustbehaftet |
+| PNG | Verlustfrei |
+| MP3 | Verlustbehaftet |
+| ZIP | Verlustfrei |
+| FLAC | Verlustfrei |
+| WebP (lossy) | Verlustbehaftet |
+
+> **Feedback:** Verlustfrei = Originaldaten perfekt rekonstruierbar (ZIP, PNG, FLAC). Verlustbehaftet = Daten dauerhaft weggeworfen, nicht mehr zurückholbar (JPEG, MP3).
+
+---
+
+### J3 – Verlustfrei vs. verlustbehaftet: Erkläre
+**Thema:** Grundbegriffe – Konzept
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre den Unterschied zwischen verlustfreier und verlustbehafteter Kompression. Nenne je ein konkretes Beispiel und erkläre, warum man in unterschiedlichen Situationen unterschiedliche Kompressionstypen wählt.
+
+> **Musterlösung:** Verlustfrei: Alle Originaldaten bleiben erhalten – die Datei kann perfekt rekonstruiert werden (z. B. ZIP, PNG). Verlustbehaftet: Daten werden dauerhaft weggeworfen – die Datei kann nicht mehr perfekt hergestellt werden (z. B. JPEG, MP3). Wahl: Fotos fürs Web → JPEG (verlustbehaftet), weil der Unterschied kaum sichtbar ist und die Datei deutlich kleiner wird. Archivierung oder Grafiken → PNG (verlustfrei), weil Qualitätsverlust inakzeptabel wäre.
+
+---
+
+### J4 – Was bedeutet „skalieren"?
+**Thema:** Grundbegriffe – Skalierung
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was passiert, wenn ein Rasterbild vergrößert wird?
+
+- [ ] Neue Pixel werden aus dem Dateiformat automatisch geladen.
+- [x] **Fehlende Pixel müssen durch Interpolation „erfunden" werden – es entsteht keine neue Information.** ✅
+- [ ] Das Bild wird verlustfrei größer, weil Pixel automatisch duplifiziert werden.
+- [ ] Die Dateigröße bleibt gleich, nur der Zoom im Betrachter ändert sich.
+
+> **Feedback:** Ein Rasterbild hat eine native Auflösung. Alles darüber hinaus = Schätzung (Interpolation). Deshalb werden vergrößerte Rasterbilder unscharf – es gibt einfach keine Daten für die fehlenden Pixel.
+
+---
+
+### J5 – Was bedeutet „konvertieren"?
+**Thema:** Grundbegriffe – Konvertierung
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was bedeutet es, eine Datei zu konvertieren?
+
+- [ ] Die Datei wird komprimiert und umbenannt.
+- [x] **Die Daten werden von einem Format in ein anderes umgewandelt (z. B. JPEG → PNG, MP4 → WebM).** ✅
+- [ ] Die Datei wird verschlüsselt und in ein neues Format gepackt.
+- [ ] Die Dateiendung wird umbenannt, ohne dass sich der Inhalt ändert.
+
+> **Feedback:** Konvertierung = Format-Umwandlung. Der Inhalt bleibt inhaltlich gleich, aber die Art der Speicherung (Kompression, Struktur) ändert sich. Wichtig: Eine Dateiendung umzubenennen ist KEINE Konvertierung.
+
+---
+
+### J6 – Was bedeutet „codieren" und „decodieren"?
+**Thema:** Grundbegriffe – Codec-Konzept
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre, was „codieren" und „decodieren" bedeuten. Erkläre anschließend, warum der Begriff „Codec" aus beiden Wörtern zusammengesetzt ist, und nenne ein konkretes Beispiel.
+
+> **Musterlösung:** Codieren = Daten in ein bestimmtes Format umwandeln (z. B. Rohvideodaten → H.264-komprimiertes Video). Decodieren = das Gegenteil: komprimierte Daten wieder in abspielbare Form zurückwandeln (z. B. H.264 → Pixeldaten für den Bildschirm). Codec = Co(der) + Dec(oder) – ein Algorithmus, der beides kann. Beispiel: H.264 ist ein Video-Codec: Der Encoder erzeugt die komprimierte Datei, der Decoder im Player spielt sie wieder ab.
+
+---
+
+### J7 – Codec vs. Container
+**Thema:** Grundbegriffe – Codec/Container-Unterschied
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Was ist der Unterschied zwischen einem Container und einem Codec bei Videodateien?
+
+- [ ] Container und Codec sind synonyme Begriffe für das gleiche Konzept.
+- [x] **Der Container (z. B. MP4) ist die „Verpackung", die verschiedene Streams zusammenpackt. Der Codec (z. B. H.264) bestimmt, wie der Video-Stream komprimiert wird.** ✅
+- [ ] Der Codec ist die Dateiendung, der Container der Kompressionsalgorithmus.
+- [ ] Ein Container enthält immer genau einen Codec – es kann keine Kombination geben.
+
+> **Feedback:** Container ≠ Codec. Ein MP4-Container kann H.264, H.265 oder AV1 enthalten. Gleiche Endung `.mp4`, unterschiedlicher Inhalt. Der Container packt zusammen (Video, Audio, Untertitel, Metadaten), der Codec komprimiert.
+
+---
+
+### J8 – Codec vs. Container: Zuordnung
+**Thema:** Grundbegriffe – Codec/Container-Zuordnung
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne zu: Container oder Codec?
+
+| Name | Typ |
+|---|---|
+| MP4 | Container |
+| H.264 | Codec |
+| WebM | Container |
+| AV1 | Codec |
+> **Feedback:** Container = Dateiformat, das Streams zusammenpackt (MP4, MKV, WebM). Codec = Kompressionsalgorithmus für einen bestimmten Stream (H.264, AV1, AAC).
+
+---
+
+### J9 – Redundanz vs. Irrelevanz
+**Thema:** Grundbegriffe – Kompressionsprinzipien
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Verlustfreie und verlustbehaftete Kompression arbeiten nach unterschiedlichen Prinzipien. Ordne zu.
+
+| Prinzip | Kompressionstyp |
+|---|---|
+| Redundanz entfernen (wiederholende Muster kompakter darstellen) | Verlustfrei |
+| Irrelevanz entfernen (für Menschen nicht wahrnehmbar) | Verlustbehaftet |
+
+> **Feedback:** Der Kernunterschied: Verlustfrei arbeitet mit Redundanz – Wiederholungen werden kompakter gespeichert, aber nichts geht verloren. Verlustbehaftet arbeitet mit Irrelevanz – Daten werden weggeworfen, die Menschen sowieso nicht wahrnehmen können (Psychovisuell bei Bildern, Psychoakustisch bei Audio).
+
+---
+
+### J10 – Dateneinheiten: Größenordnungen
+**Thema:** Grundbegriffe – Speichereinheiten
+**Punkte:** 2
+**Typ:** `[ORDER]`
+
+Sortiere die Dateneinheiten von kleinster zu größter:
+
+1. Byte
+2. Kilobyte (KB)
+3. Megabyte (MB)
+4. Gigabyte (GB)
+5. Terabyte (TB)
+6. Petabyte (PB)
+
+> **Feedback:** Jede Stufe = Faktor 1.000 (SI-Präfixe). Merkhilfe: „Komm Mit Großem Tee, Peter". Ein einzelnes Foto (12 MP, unkomprimiert) ≈ 36 MB. Ein FullHD-Kinofilm ≈ 1 GB. Ein 4K-Film pro Minute unkomprimiert ≈ 44 GB.
+
+---
+
+### J11 – Bit und Byte: Umrechnung
+**Thema:** Grundbegriffe – Bit/Byte-Verhältnis
+**Punkte:** 1
+**Typ:** `[NUMERIC]`
+
+Ein Bit ist die kleinste Informationseinheit. Ein Byte besteht aus wie vielen Bit?
+
+**Lösung:** **8** (±0)
+
+> **Feedback:** 1 Byte = 8 Bit. Ein Byte kann einen Wert von 0 bis 255 darstellen (2⁸ − 1). Die Unterscheidung Bit/Byte ist fundamental – Bit wird mit kleinem „b" abgekürzt (b), Byte mit großem „B" (B). Deshalb: 1 Mbit/s ≠ 1 MB/s.
+
+---
+
+### J12 – 7-Bit ASCII: Wie viele Zeichen?
+**Thema:** Grundbegriffe – ASCII-Zeichenkodierung
+**Punkte:** 1
+**Typ:** `[NUMERIC]`
+
+Der ASCII-Standard verwendet 7 Bit pro Zeichen. Wie viele verschiedene Zeichen können damit dargestellt werden?
+
+**Lösung:** **128** (±0)
+
+> **Feedback:** Bei n Bit gibt es 2ⁿ mögliche Werte. 7 Bit → 2⁷ = 128 Zeichen. Diese umfassen: Ziffern (0–9), Buchstaben (A–Z, a–z), Sonderzeichen und Steuerzeichen. Achtung: Umlaute (ä, ö, ü) sind nicht im ASCII-Sortiment – dafür braucht man z. B. UTF-8.
+
+---
+
+### J13 – Hexadezimalzahlen: Zwei 4-Bit-Werte
+**Thema:** Grundbegriffe – Hexadezimal
+**Punkte:** 2
+**Typ:** `[NUMERIC]`
+
+Zwei Hexadezimalzahlen werden jeweils durch 4 Bit dargestellt. Wie viele verschiedene Werte kann eine einzelne Hexadezimalziffer annehmen?
+
+**Lösung:** **16** (±0)
+
+> **Feedback:** 4 Bit → 2⁴ = 16 Werte (0–15). Diese werden in Hexadezimal als 0–9 und A–F dargestellt. Zwei Hex-Ziffern zusammen = 8 Bit = 1 Byte → ein Byte lässt sich immer als genau zwei Hex-Ziffern schreiben (z. B. Byte 255 = FF, Byte 10 = 0A).
+
+---
+
+### J14 – Ein Pixel, drei Kanäle, 8 Bit
+**Thema:** Grundbegriffe – Speicherbedarf eines Pixels
+**Punkte:** 1
+**Typ:** `[NUMERIC]`
+
+Ein einzelner Pixel wird durch drei Farbkanäle (R, G, B) mit jeweils 8 Bit Farbtiefe gespeichert. Wie viele Byte Informationen enthalten ein solcher Pixel?
+
+**Lösung:** **3** (±0)
+
+> **Feedback:** 3 Kanäle × 8 Bit = 24 Bit = 3 Byte pro Pixel. Das entspricht einer 24-Bit-Farbtiefe (True Color). Diese 3 Byte pro Pixel bilden die Basis für jede Speicherberechnung von Rasterbildern: Breite × Höhe × 3 Bytes = Gesamtgröße unkomprimiert.
+
+---
+
+<!-- _class: lead -->
+
+## BLOCK K – Bildformate & Raster vs. Vektor
+
+---
+
+### K1 – Was ist ein Pixel?
+**Thema:** Digitale Bilder – Grundbegriffe
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was ist ein Pixel in einem digitalen Bild?
+
+- [ ] Ein winziges physisches Kameraobjektiv.
+- [x] **Ein einzelner Farbpunkt in einem Rasterbild – der kleinste Baustein.** ✅
+- [ ] Eine Einheit zur Messung der Dateigröße.
+- [ ] Ein Synonym für eine Farbe im RGB-Farbraum.
+
+> **Feedback:** Pixel = Picture Element. Ein digitales Rasterbild ist ein 2D-Array aus Pixeln, jeder mit einem Farbwert (z. B. RGB).
+
+---
+
+### K2 – Speicherbedarf berechnen
+**Thema:** Rastergrafiken – Berechnung
+**Punkte:** 2
+**Typ:** `[NUMERIC]`
+
+Ein Bild ist 1920 × 1080 Pixel groß und nutzt 24-Bit-Farbtiefe (True Color). Wie groß ist das Bild unkomprimiert in Megabyte? (Runde auf eine Dezimalstelle)
+
+**Formel:** Breite × Höhe × (Farbtiefe / 8) = Bytes
+
+**Lösung:** 1920 × 1080 × 3 = 6.220.800 Bytes ≈ **6,2 MB** (±0,1)
+
+> **Feedback:** 24 Bit = 3 Bytes pro Pixel (8 Bit pro Kanal: R, G, B). 1920 × 1080 = 2.073.600 Pixel × 3 Bytes = 6.220.800 Bytes. Durch 1.000.000 ≈ 6,2 MB.
+
+---
+
+### K3 – Farbtiefe: Bedeutung
+**Thema:** Rastergrafiken – Farbtiefe
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jeder Farbtiefe ihre Bedeutung zu.
+
+| Farbtiefe | Bedeutung |
+|---|---|
+| 1 Bit | 2 Farben (Schwarz/Weiß) |
+| 8 Bit | 256 Farben (Graustufen, GIF) |
+| 24 Bit | 16,7 Millionen Farben (True Color, Standard) |
+| 32 Bit | 16,7 Millionen Farben + Alpha (Transparenz) |
+
+> **Feedback:** Bei n Bit gibt es 2ⁿ mögliche Werte. 24 Bit = 8 Bit pro Kanal (R, G, B). 32 Bit = 24 Bit Farbe + 8 Bit Alpha-Kanal für Transparenz.
+
+---
+
+### K4 – Was ist Alpha-Transparenz?
+**Thema:** Rastergrafiken – Transparenz
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was bedeutet ein 32-Bit-Bild gegenüber einem 24-Bit-Bild?
+
+- [ ] Es hat doppelt so viele Pixel.
+- [x] **Es hat einen zusätzlichen Alpha-Kanal (8 Bit), der die Transparenz jedes Pixels speichert.** ✅
+- [ ] Es nutzt eine höhere Auflösung.
+- [ ] Es kann mehr Dateiformate speichern.
+
+> **Feedback:** 32 Bit = 24 Bit (RGB) + 8 Bit Alpha. Der Alpha-Kanal bestimmt, wie durchsichtig jeder Pixel ist (0 = vollständig transparent, 255 = vollständig undurchsichtig). Wichtig für PNGs mit Hintergrund-Transparenz.
+
+---
+
+### K5 – Raster vs. Vektor: Kern-Unterschied
+**Thema:** Raster vs. Vektor – Konzept
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Was ist der fundamentale Unterschied zwischen Raster- und Vektorgrafiken?
+
+- [ ] Vektorgrafiken sind immer farbiger als Rastergrafiken.
+- [x] **Rastergrafiken speichern einzelne Pixel; Vektorgrafiken speichern geometrische Beschreibungen (Pfade, Formen), die beliebig skaliert werden können.** ✅
+- [ ] Rastergrafiken können keine Farben darstellen, Vektorgrafiken schon.
+- [ ] Der Unterschied liegt nur in der Dateiendung, nicht im Inhalt.
+
+> **Feedback:** Raster = „Malen nach Zahlen" (jeder Pixel einzeln). Vektor = „Bauanleitung" (Formen beschreiben). Diese Unterschied bestimmt alles: Skalierung, Dateigröße, Einsatzbereich.
+
+---
+
+### K6 – Raster vs. Vektor: Vergleich
+**Thema:** Raster vs. Vektor – Eigenschaften zuordnen
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jeder Eigenschaft zu: Raster oder Vektor?
+
+| Eigenschaft | Typ |
+|---|---|
+| Skalierung ohne Qualitätsverlust | Vektor |
+| Ideal für Fotos | Raster |
+| Dateigröße abhängig von der Auflösung | Raster |
+| Ideal für Logos und Icons | Vektor |
+| Speicherung als 2D-Array von Pixeln | Raster |
+| Dateigröße abhängig von der Komplexität | Vektor |
+
+> **Feedback:** Raster = Pixel-basiert, auflösungsabhängig, ideal für Fotos. Vektor = Beschreibungs-basiert, beliebig skalierbar, ideal für Grafiken/Logos.
+
+---
+
+### K7 – Skalierung: Warum werden Rasterbilder unscharf?
+**Thema:** Rastergrafiken – Skalierung Transfer
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre, warum ein Rasterbild beim Vergrößern unscharf wird, während ein Vektorbild bei beliebiger Größe scharf bleibt. Nenne einen konkreten Anwendungsfall, in dem diese Eigenschaft ausschlaggebend ist.
+
+> **Musterlösung:** Ein Rasterbild hat eine feste Auflösung (eine bestimmte Anzahl von Pixeln). Beim Vergrößern müssen neue Pixel „erfunden" werden (Interpolation) – es gibt keine echten Daten für die fehlenden Stellen → Unschärfe. Ein Vektorbild speichert nur Beschreibungen (Pfade, Formen). Beim Vergrößern werden einfach die Koordinaten skaliert – keine Information geht verloren → immer scharf. Anwendungsfall: Ein Logo auf einer Visitenkarte UND auf einem Plakat → SVG nutzen, damit es bei beliebiger Größe scharf bleibt.
+
+---
+
+### K8 – Vektor → Raster: Wie heißt das?
+**Thema:** Raster vs. Vektor – Konvertierung
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Wie heißt der Prozess, bei dem eine Vektorgrafik in eine Rastergrafik umgewandelt wird?
+
+- [ ] Vektorisierung
+- [x] **Rasterisierung** ✅
+- [ ] Pixelierung
+- [ ] Komprimierung
+
+> **Feedback:** Rasterisierung = Vektor → Raster (trivial, immer möglich). Der umgekehrte Prozess (Raster → Vektor) heißt „Tracing" und funktioniert oft nur unbefriedigend.
+
+---
+
+<!-- _class: disable -->
+
+### K9 – Interpolation: Welches Verfahren wofür?
+**Thema:** Rastergrafiken – Interpolationsverfahren
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Interpolationsverfahren seine Eigenschaft zu.
+
+| Verfahren | Eigenschaft |
+|---|---|
+| Nearest Neighbor | Schnell, pixelig – gut für Pixel-Art |
+| Bilinear | Glättet, Standard-Verfahren |
+| Bicubic | Hohe Qualität, rechenintensiver |
+| Lanczos | Beste Qualität, mathematisch komplex |
+
+> **Feedback:** Bei der Wahl: Pixel-Art → Nearest Neighbor (soll pixelig bleiben). Normale Bilder → Bilinear oder Bicubic. Maximale Qualität bei Fotos → Lanczos.
+
+---
+
+<!-- _class: lead -->
+
+## BLOCK L – JPEG: Innenleben
+
+---
+
+### L1 – JPEG: Verlustfrei oder verlustbehaftet?
+**Thema:** JPEG – Grundeigenschaft
+**Punkte:** 1
+**Typ:** `[MC]`
+
+JPEG ist ein …
+
+- [x] **…verlustbehaftetes Bildformat. Beim Speichern werden Daten dauerhaft weggeworfen.** ✅
+- [ ] …verlustfreies Bildformat wie PNG.
+- [ ] …Videoformat für Streaming.
+- [ ] …Vektorgrafik-Format.
+
+> **Feedback:** JPEG = Joint Photographic Experts Group. Verlustbehaftet: Beim Speichern werden Daten dauerhaft weggeworfen – eine gespeicherte JPEG kann nicht perfekt zum Original zurückgeführt werden. Quality 100 ≠ verlustfrei, nur „wenig wegwerfen".
+
+---
+
+### L2 – Psychovisuelle Kompression: Das Auge austricksen
+**Thema:** JPEG – Wahrnehmungsprinzip
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Wie nutzt JPEG die Schwächen des menschlichen Auges aus?
+
+- [ ] Das Auge kann keine Farben wahrnehmen – daher werden Farben komplett entfernt.
+- [x] **Das Auge sieht Helligkeit besser als Farbe. JPEG behält die Helligkeit (Y) nahezu vollständig, reduziert aber die Farbauflösung (Cb, Cr) – der Verlust wird kaum wahrgenommen.** ✅
+- [ ] Das Auge kann keine Details sehen – daher werden alle Details entfernt.
+- [ ] JPEG nutzt keine Wahrnehmungsforschung, komprimiert rein mathematisch.
+
+> **Feedback:** Psychovisuelle Kompression = Schwächen des Auges ausnutzen. Kern: Mehr Stäbchen (Helligkeit) als Zapfen (Farbe) im Auge → Helligkeit sichern, Farbe reduzieren. Der Verlust ist für Menschen kaum sichtbar.
+
+---
+
+### L3 – Farbraumkonversion: RGB → YCbCr
+**Thema:** JPEG Schritt 1 – Farbraum
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Warum wird bei JPEG von RGB in YCbCr konvertiert?
+
+- [ ] YCbCr nutzt weniger Speicher pro Pixel als RGB.
+- [x] **In YCbCr sind Helligkeit (Y) und Farbe (Cb, Cr) getrennt – die Farbauflösung kann unabhängig von der Helligkeit reduziert werden.** ✅
+- [ ] RGB kann keine Transparenz darstellen, YCbCr schon.
+- [ ] Die Konvertierung ist ein verlustfreier Schritt, der die Dateigröße halbiert.
+
+> **Feedback:** Y = Helligkeit (Luminanz), Cb/Cr = Farbdifferenzen (Chrominanz). Diese Trennung ermöglicht Chroma Subsampling: Helligkeit voll behalten, Farbe reduzieren – ohne sichtbaren Verlust.
+
+---
+
+### L4 – Chroma Subsampling: Was ist 4:2:0?
+**Thema:** JPEG Schritt 2 – Subsampling
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Was bedeutet das Subsampling-Schema 4:2:0?
+
+- [ ] 4 Pixel teilen sich eine Helligkeit, aber jeder hat eigene Farbe.
+- [x] **4 Pixel teilen sich einen Farbwert (Chrominanz), aber jeder hat eine eigene Helligkeit (Luminanz). Die Farbauflösung wird auf 25% reduziert.** ✅
+- [ ] 4:2:0 bedeutet, dass keine Farbe gespeichert wird – nur Graustufen.
+- [ ] Die Notation beschreibt die Blockgröße, nicht die Farbauflösung.
+
+> **Feedback:** 4:2:0 = JPEG-Standard. Von 4 Pixeln wird nur 1 Farbwert gespeichert (2×2-Block teilt Farbe), aber jeder Pixel behält seine eigene Helligkeit. Ergebnis: 50% Datenreduktion, kaum sichtbar.
+
+---
+
+### L5 – JPEG-Schritte: Richtige Reihenfolge
+**Thema:** JPEG – Kompressionsablauf
+**Punkte:** 2
+**Typ:** `[ORDER]`
+
+Sortiere die Schritte der JPEG-Kompression in der richtigen Reihenfolge:
+
+1. Farbraumkonversion (RGB → YCbCr)
+2. Chroma Subsampling
+3. Block-Aufteilung (8×8)
+4. DCT (Frequenzanalyse)
+5. Quantisierung (hier passiert der Verlust!)
+6. Huffman-Coding (verlustfrei)
+
+> **Feedback:** Der einzige verlustbehaftete Schritt ist die Quantisierung (Schritt 5). Alles davor bereitet die Daten vor, alles danach komprimiert die Ergebnisse verlustfrei weiter.
+
+---
+
+### L6 – Welcher Schritt ist verlustbehaftet?
+**Thema:** JPEG – Verlust lokalisieren
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Bei welchem Schritt der JPEG-Kompression werden Daten dauerhaft weggeworfen?
+
+- [ ] Farbraumkonversion (RGB → YCbCr)
+- [ ] DCT (Discrete Cosine Transform)
+- [x] **Quantisierung – hier werden unwichtige Frequenzkoeffizienten auf Null gesetzt oder vergröbert.** ✅
+- [ ] Huffman-Coding
+
+> **Feedback:** DCT selbst ist verlustfrei und reversibel – es sortiert nur die Daten nach Wichtigkeit. Die Quantisierung ist der einzige verlustbehaftete Schritt: Sie wirft hohe Frequenzen (feine Details) weg. Huffman-Coding danach ist wieder verlustfrei.
+
+---
+
+<!-- _class: disable -->
+
+### L7 – DCT: Was macht sie?
+**Thema:** JPEG – DCT-Prinzip
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was leitet die DCT (Discrete Cosine Transform) bei JPEG?
+
+- [ ] Sie komprimiert die Daten verlustbehaftet.
+- [x] **Sie wandelt 64 Pixelwerte eines 8×8-Blocks in 64 Frequenzkoeffizienten um – sortiert die Information nach Wichtigkeit (niedrige Frequenz = wichtig, hohe Frequenz = Details).** ✅
+- [ ] Sie verschlüsselt die Daten für sichere Übertragung.
+- [ ] Sie reduziert die Farbauflösung des Bildes.
+
+> **Feedback:** DCT = Herzstück von JPEG, aber selbst verlustfrei. Sie sortiert: Der DC-Koeffizient (0,0) = Durchschnittshelligkeit eines Blocks. Die AC-Koeffizienten = Helligkeitsänderungen. 90% der Information steckt in den ersten 10–15 Koeffizienten.
+
+---
+
+### L8 – Huffman-Coding: Prinzip
+**Thema:** JPEG – Huffman
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Wie funktioniert Huffman-Coding?
+
+- [ ] Alle Zeichen bekommen gleich lange Codes – einfach und effizient.
+- [x] **Häufige Werte bekommen kurze Codes, selten vorkommende lange Codes – variable Bitlänge statt fester 8 Bit.** ✅
+- [ ] Huffman-Coding verschlüsselt die Daten zusätzlich.
+- [ ] Es funktioniert nur für Texte, nicht für Bilddaten.
+
+> **Feedback:** Huffman = verlustfrei, optimal für bekannte Häufigkeiten. Präfix-frei: Kein Code ist Anfang eines anderen → eindeutig decodierbar. Auch in ZIP, PNG, MP3 verwendet.
+
+---
+
+<!-- _class: disable -->
+
+### L9 – JPEG-Artefakte: Benennen
+**Thema:** JPEG – Artefakte identifizieren
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem JPEG-Artefakt seine Beschreibung zu.
+
+| Artefakt | Beschreibung |
+|---|---|
+| Blocking | 8×8-Blöcke werden sichtbar als Rechteckmuster |
+| Ringing | „Geister" oder Halos an scharfen Kanten |
+| Posterization | Farbverläufe werden stufig statt fließend |
+
+> **Feedback:** Alle drei sind Folgen der Quantisierung. Blocking: Weil jeder 8×8-Block unabhängig komprimiert wird. Ringing: DCT hat Probleme mit harten Kanten (Gibbs-Phänomen). Posterization: Zu wenige Bits für feine Farbabstufungen.
+
+---
+
+<!-- _class: lead -->
+
+## BLOCK M – Bildformate: PNG, GIF, WebP, SVG
+
+---
+
+### M1 – PNG: Verlustfrei oder verlustbehaftet?
+**Thema:** PNG – Grundeigenschaft
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Wie komprimiert PNG?
+
+- [ ] Verlustbehaftet – wie JPEG, aber mit besserer Qualität.
+- [x] **Verlustfrei – die Originaldaten können perfekt rekonstruiert werden.** ✅
+- [ ] Gar nicht – PNG speichert Daten unkomprimiert.
+- [ ] PNG nutzt eine Kombination aus verlustfrei und verlustbehaftet.
+
+> **Feedback:** PNG nutzt DEFLATE-Kompression (wie ZIP) – verlustfrei. Deshalb ist PNG ideal für Grafiken, Screenshots und Bilder mit Transparenz, aber größer als JPEG für Fotos.
+
+---
+
+### M2 – PNG vs. JPEG: Wann was?
+**Thema:** Bildformate – Formatwahl
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erklären Sie, wann Sie PNG und wann JPEG wählen würden. Nenne je zwei konkrete Anwendungsfälle und begründen Sie Ihre Wahl.
+
+> **Musterlösung:** PNG: (1) Screenshots – Texte und Linien bleiben scharf, keine Artefakte. (2) Logos mit Transparenz – PNG unterstützt Alpha-Transparenz, JPEG nicht. JPEG: (1) Fotos fürs Web – deutlich kleiner bei kaum sichtbarem Qualitätsverlust. (2) Social Media – Plattformen re-komprimieren sowieso, PNG würde nur unnötig groß sein.
+
+---
+
+### M3 – GIF: Wie viele Farben?
+**Thema:** GIF – Eigenschaften
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Wie viele Farben kann ein GIF-Bild gleichzeitig anzeigen?
+
+- [ ] 16 Farben
+- [ ] 16,7 Millionen Farben
+- [x] **256 Farben (8-Bit-Palette)** ✅
+- [ ] Unbegrenzt – GIF unterstützt alle Farben.
+
+> **Feedback:** GIF = 8-Bit-Palette = 256 Farben maximal. Deshalb sehen GIF-Bilder bei Fotos oft banding/posterisiert aus. GIF überlebt heute wegen Animationen.
+
+---
+
+<!-- _class: disable -->
+
+### M4 – WebP vs. JPEG: Vorteil?
+**Thema:** Bildformate – WebP
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was ist der hauptsächliche Vorteil von WebP gegenüber JPEG?
+
+- [ ] WebP unterstützt Videos, JPEG nicht.
+- [x] **WebP erzeugt bei gleicher Qualität 25–35% kleinere Dateien als JPEG.** ✅
+- [ ] WebP ist verlustfrei, JPEG nicht.
+- [ ] WebP kann keine Fotos speichern, nur Grafiken.
+
+> **Feedback:** WebP (Google, 2010) kann sowohl lossy als auch lossless komprimieren, unterstützt Transparenz und Animationen. Bei gleicher visueller Qualität sind WebP-Dateien deutlich kleiner als JPEG.
+
+---
+
+### M5 – SVG: Was ist es?
+**Thema:** SVG – Grundbegriff
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was ist SVG?
+
+- [ ] Ein verlustbehaftetes Rasterbild-Format wie JPEG.
+- [x] **Ein Vektorgrafik-Format, das Bilder als geometrische Beschreibungen (XML) speichert – beliebig skalierbar ohne Qualitätsverlust.** ✅
+- [ ] Ein Video-Container wie MP4.
+- [ ] Ein komprimiertes Archivformat wie ZIP.
+
+> **Feedback:** SVG = Scalable Vector Graphics. Web-Standard für Vektorgrafiken. Beschreibt WAS gezeichnet werden soll (`<circle>`, `<rect>`, `<path>`), nicht wie jeder Pixel aussieht. Ideal für Logos, Icons, Illustrationen.
+
+---
+
+### M6 – Formatwahl: Szenario zuordnen
+**Thema:** Bildformate – Formatwahl Transfer
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Szenario das optimale Bildformat zu.
+
+| Szenario | Format |
+|---|---|
+| Ein Foto für eine Webseite (klein, OK-Qualität) | JPEG |
+| Ein Screenshot einer Benutzeroberfläche | PNG |
+| Ein Logo, das auf allen Bildschirmgrößen scharf sein muss | SVG |
+| Ein animiertes Reaktionsbild für einen Chat | GIF |
+
+> **Feedback:** JPEG = Fotos (klein, lossy OK). PNG = Screenshots, Grafiken mit Transparenz (verlustfrei). SVG = Logos, Icons (skalierbar). GIF = Animationen (256 Farben, aber Animations-Support).
+
+---
+
+<!-- _class: lead -->
+
+## BLOCK N – Video-Kompression
+
+---
+
+<!-- _class: disable -->
+
+### N1 – Spatial vs. Temporal Compression
+**Thema:** Video – Kompressionsprinzipien
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Prinzip seine Beschreibung zu.
+
+| Prinzip | Beschreibung |
+|---|---|
+| Spatial Compression (Intra-Frame) | Komprimiert jedes einzelne Bild für sich (wie JPEG) |
+| Temporal Compression (Inter-Frame) | Speichert nur die Änderungen zwischen aufeinanderfolgenden Bildern |
+| Motion Compensation | Beschreibt Bewegung durch Vektoren statt Pixel zu kopieren |
+
+> **Feedback:** Spatial = räumlich (innerhalb eines Frames). Temporal = zeitlich (zwischen Frames). Motion Compensation = Bewegungsvektoren. 90% eines Frames ist oft identisch mit dem vorherigen – deshalb ist Temporal-Kompression so wirksam.
+
+---
+
+<!-- _class: disable -->
+
+### N2 – I-Frame, P-Frame, B-Frame: Was ist was?
+**Thema:** Video – Frame-Typen
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Frame-Typ seine Beschreibung zu.
+
+| Frame-Typ | Beschreibung |
+|---|---|
+| I-Frame (Keyframe) | Vollständiges Bild, unabhängig dekodierbar – keine Referenz auf andere Frames |
+| P-Frame | Nur Änderungen gegenüber vorherigen Frames speichern (~30% der Größe eines I-Frames) |
+| B-Frame | Änderungen gegenüber vorherigen UND zukünftigen Frames (~15% der Größe eines I-Frames) |
+
+> **Feedback:** I = Intra (innerhalb). P = Predicted (aus Vergangenheit). B = Bi-directional (Vergangenheit + Zukunft). B-Frames sind am kleinsten, aber brauchen mehr Rechenleistung zum Decodieren.
+
+---
+
+<!-- _class: disable -->
+
+### N3 – Was passiert, wenn ein I-Frame beschädigt ist?
+**Thema:** Video – I-Frame Bedeutung Transfer
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre, warum ein I-Frame bei der Videokompression so wichtig ist. Was passiert, wenn ein einzelner I-Frame in einem Videostream beschädigt wird?
+
+> **Musterlösung:** Ein I-Frame ist ein vollständiges, unabhängig dekodierbare Bild. Alle nachfolgenden P- und B-Frames referenzieren auf vorherige Frames – letztlich auf das letzte I-Frame. Wenn ein I-Frame beschädigt wird, können alle abhängigen P- und B-Frames bis zum nächsten intakten I-Frame nicht mehr korrekt rekonstruiert werden → Videofehler sichtbar bis zum nächsten Keyframe. Deshalb werden typischerweise alle 1–2 Sekunden neue I-Frames eingefügt.
+
+---
+
+<!-- _class: disable -->
+
+### N4 – Motion Compensation: Prinzip
+**Thema:** Video – Motion Compensation
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was beschreibt ein Motion Vector bei der Videokompression?
+
+- [ ] Die Helligkeit eines einzelnen Pixels.
+- [x] **Die Verschiebung eines Bildblocks zwischen zwei Frames (z. B. „verschiebe um +20 Pixel nach rechts").** ✅
+- [ ] Die Kompressionsrate des gesamten Videos.
+- [ ] Die Anzahl der Farben in einem Frame.
+
+> **Feedback:** Motion Compensation speichert Bewegung als Vektoren statt Pixel zu kopieren. Wenn sich ein 16×16-Block von (100,200) auf (120,200) bewegt, wird nur „+20, 0" gespeichert – deutlich kleiner als den Block zweimal zu speichern.
+
+---
+
+<!-- _class: disable -->
+
+### N5 – Video-Codecs: Zeitstrahl
+**Thema:** Video – Codecs-Übersicht
+**Punkte:** 2
+**Typ:** `[ORDER]`
+
+Sortiere die Video-Codecs nach Veröffentlichungsjahr (alt → neu):
+
+1. H.264 / AVC (2003)
+2. H.265 / HEVC (2013)
+3. VP9 (2013)
+4. AV1 (2018)
+
+> **Feedback:** H.264 revolutionierte Streaming. H.265 und VP9 kamen gleichzeitig – H.265 technisch besser, aber Patent-Chaos. AV1 vereint die Industrie: patent-frei, 30% besser als H.265.
+
+---
+
+### N6 – AV1: Warum die Zukunft?
+**Thema:** Video – AV1 Transfer
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre, warum AV1 als „die Zukunft" der Videokompression gilt. Nenne mindestens zwei konkrete Eigenschaften und erkläre, warum H.265 trotz besserer technischer Kompression nicht die gleiche Dominanz erreicht hat.
+
+> **Musterlösung:** AV1 (2018) ist royalty-free und open source – die Alliance for Open Media vereint Google, Netflix, Amazon, Apple, Mozilla. Es liefert 30% bessere Kompression als H.265 und unterstützt 8K, HDR, hohe Frame-Rates. H.265 scheitert vor allem am Patent-Chaos: Drei konkurrierende Patent-Pools (MPEG-LA, HEVC Advance, Velos Media) erzeugen rechtliche Unsicherheit und unklare Kosten → viele Unternehmen bleiben bei H.264 oder wechseln direkt zu AV1.
+
+---
+
+<!-- _class: lead -->
+
+## BLOCK O – Speichermedien & Schnittstellen
+
+---
+
+<!-- _class: disable -->
+
+### O1 – KB vs. KiB: Was ist der Unterschied?
+**Thema:** Speicher – Einheiten
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Eine Festplatte wird als „1 TB" vermarktet, aber Windows zeigt nur ~931 GB an. Warum?
+
+- [ ] Windows zeigt falsche Werte an – das ist ein Bug.
+- [x] **Hersteller nutzen dezimale Einheiten (1 TB = 1.000 GB), Windows nutzt binäre Einheiten (1 TiB = 1.024 GiB). Bei TB-Größen entsteht eine ~7% Diskrepanz.** ✅
+- [ ] Die Festplatte verliert beim Formatieren fast 10% ihrer Kapazität.
+- [ ] Windows reserviert automatisch 10% als Sicherheitspuffer.
+
+> **Feedback:** SI (Dezimal): 1 KB = 1.000 Bytes, 1 MB = 1.000 KB. IEC (Binär): 1 KiB = 1.024 Bytes, 1 MiB = 1.024 KiB. Bei 1 TB: 1.000⁴ vs. 1.024⁴ Bytes → ~7% Unterschied. Windows zeigt binäre Werte an, aber mit SI-Bezeichnung (GB statt GiB) → Verwirrung.
+
+---
+
+<!-- _class: disable -->
+
+### O2 – HDD vs. SSD: Kern-Unterschied
+**Thema:** Speichermedien – HDD vs. SSD
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was ist der fundamentale technische Unterschied zwischen HDD und SSD?
+
+- [ ] HDDs sind elektronisch, SSDs mechanisch.
+- [x] **HDDs speichern Daten magnetisch auf sich drehenden Plattern (mechanisch). SSDs nutzen Flash-Speicher (elektronisch, keine beweglichen Teile).** ✅
+- [ ] Beide Technologien funktionieren identisch, der Unterschied liegt nur im Gehäuse.
+- [ ] HDDs nutzen Flash-Speicher, SSDs magnetische Platten.
+
+> **Feedback:** HDD = Hard Disk Drive = mechanisch (Platter, Spindel, Schreib-Lese-Kopf). SSD = Solid State Drive = elektronisch (Flash-Speicher). Diese Unterschied bestimmt alles: Geschwindigkeit, Latenz, Geräusche, Haltbarkeit.
+
+---
+
+<!-- _class: disable -->
+
+### O3 – HDD vs. SSD: Eigenschaften zuordnen
+**Thema:** Speichermedien – Vergleich
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jeder Eigenschaft zu: HDD oder SSD?
+
+| Eigenschaft | Typ |
+|---|---|
+| Sequentielle Lesgeschwindigkeit ~150 MB/s | HDD |
+| Sequentielle Lesgeschwindigkeit ~3.500 MB/s | SSD (NVMe) |
+| Latenz ~10 ms | HDD |
+| Latenz ~0,02 ms | SSD |
+| Günstig pro TB (~15€/TB) | HDD |
+| Ideal für Betriebssystem | SSD |
+
+> **Feedback:** Der dramatische Unterschied liegt bei Random Access: SSD ~500× schneller. Deshalb: Betriebssystem auf SSD, Archiv auf HDD. Viele nutzen beides: Kleine SSD für System + große HDD für Daten.
+
+---
+
+<!-- _class: disable -->
+
+### O4 – USB-C: Stecker oder Protokoll?
+**Thema:** Schnittstellen – USB-C
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Ein USB-C-Kabel kann langsam sein, obwohl es wie ein „modernes" Kabel aussieht. Warum?
+
+- [ ] USB-C-Kabel sind immer gleich schnell – die Geschwindigkeit liegt am Gerät.
+- [x] **USB-C ist nur ein Steckertyp, kein Protokoll. Ein USB-C-Kabel kann USB 2.0 (480 Mbit/s) bis USB4 (40 Gbit/s) sein – am Stecker nicht erkennbar.** ✅
+- [ ] USB-C-Kabel werden nach einem Jahr automatisch langsamer.
+- [ ] Die Geschwindigkeit hängt nur vom Betriebssystem ab.
+
+> **Feedback:** USB-C = Steckerform. Das Protokoll dahinter kann USB 2.0, 3.2 oder USB4 sein. Ein billiges USB-C-Kabel ist oft nur USB 2.0 mit neuem Stecker. Kabel-Spezifikation prüfen!
+
+---
+
+<!-- _class: disable -->
+
+### O5 – Dateisysteme: Zuordnung
+**Thema:** Dateisysteme – Überblick
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Dateisystem seine ideale Anwendung zu.
+
+| Dateisystem | Ideal für |
+|---|---|
+| FAT32 | USB-Sticks, SD-Karten (maximale Kompatibilität) |
+| NTFS | Windows-Systeme (Journaling, Rechte) |
+| APFS | macOS, iOS (Snapshots, CoW) |
+| ext4 | Linux-Systeme (Journaling, stabil) |
+| exFAT | Große Dateien auf portablen Medien |
+
+> **Feedback:** FAT32 = kleinster gemeinsamer Nenner, aber max. 4 GB pro Datei. exFAT = FAT32 ohne Größenlimits. NTFS/APFS/ext4 = moderne Systeme mit Journaling. Journaling = bei Absturz werden Änderungen nicht verloren.
+
+---
+
+<!-- _class: disable -->
+
+### O6 – FAT32: Warum nicht für große Dateien?
+**Thema:** Dateisysteme – FAT32 Limitation
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Sie versuchen, eine 5-GB-Videodatei auf einen FAT32-formatierten USB-Stick zu kopieren. Was passiert?
+
+- [ ] Die Datei wird automatisch aufgeteilt in kleinere Teile.
+- [x] **Der Vorgang fehlschlägt – FAT32 unterstützt keine einzelnen Dateien größer als 4 GB.** ✅
+- [ ] Die Datei wird automatisch komprimiert, bis sie unter 4 GB ist.
+- [ ] FAT32 hat keine Dateigrößenbeschränkung.
+
+> **Feedback:** FAT32-Limit: max. 4 GB pro Datei. Ein 4K-Video oder ISO-Image passt oft nicht. Lösung: USB-Stick mit exFAT oder NTFS formatieren.
+
+---
+
+### O7 – Die 3-2-1-Regel
+**Thema:** Backup – Prinzip
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre die 3-2-1-Regel für Backups. Begründe, warum jede der drei Ziffern wichtig ist.
+
+> **Musterlösung:** 3 Kopien: Original + 2 Backups. Warum? Das Original kann kaputt gehen, das erste Backup auch – das zweite ist der Sicherheitspuffer. 2 verschiedene Medientypen (z. B. SSD + HDD, oder lokal + Cloud). Warum? Gleiche Medien haben gleiche Schwachstellen (z. B. Batch-Fehler bei HDDs derselben Charge). 1 Kopie an einem anderen Ort (Cloud, anderes Gebäude). Warum? Brand oder Wasserschaden zerstört alles vor Ort; Ransomware verschlüsselt alle angeschlossenen Laufwerke gleichzeitig.
+
+---
+
+<!-- _class: disable -->
+
+### O8 – Backup-Arten: Unterschiede
+**Thema:** Backup – Typen
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Backup-Typ seine Beschreibung zu.
+
+| Backup-Typ | Beschreibung |
+|---|---|
+| Full (Vollständig) | Kompletter Datenbestand jedes Mal – einfach, aber langsam und platzhungrig |
+| Inkrementell | Nur Änderungen seit dem letzten Backup (egal welcher Art) – schnell, aber Wiederherstellung komplex |
+| Differenziell | Änderungen seit dem letzten Voll-Backup – Mittelweg zwischen beiden |
+
+> **Feedback:** Typisches Schema: Sonntag Full, Mo–Sa Inkrementell oder Differenziell. Inkrementell = schnellstes Backup, langsamste Wiederherstellung (Kette aufbauen). Full = langsamstes Backup, schnellste Wiederherstellung.
diff --git a/slides/223015c/klausurfragen.md b/slides/223015c/klausurfragen.md
new file mode 100644
index 0000000..c40cb76
--- /dev/null
+++ b/slides/223015c/klausurfragen.md
@@ -0,0 +1,938 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Klausurfragen – 223015c"
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+title: "Klausurfragen – Grundlagen IT- und Internettechnik"
+---
+<style>
+:root {
+  --color-foreground: #1a1a2e;
+  --color-highlight: #d63384;
+  --color-dimmed: #4a4a6a;
+}
+section.invert { --color-foreground: #fff; }
+section { font-size: 1.325rem; }
+h1 { color: #a02060; }
+section.invert h1 { color: #fff; }
+h2 { color: #1f2937; }
+pre { background: #0f0f23; border-radius: 8px; }
+pre code { background: transparent; color: inherit; }
+a { color: var(--color-highlight); }
+section.disable { opacity: 0.3; }
+</style>
+
+# Klausurfragen – 223015c
+**Grundlagen IT- und Internettechnik · HdM Stuttgart · M. Czechowski**
+
+<small>Stand: 02.02.2026</small>
+
+---
+
+> **Legende – Moodle XML-Typen:**
+> `[MC]` = `multichoice` (einzelne Auswahl)
+> `[MM]` = `multichoice` + `<single>false</single>` (Mehrfachauswahl)
+> `[MATCH]` = `matching` (Zuordnung)
+> `[ORDER]` = `ordering` (Reihenfolge)
+> `[ESSAY]` = `essay` (Freitext, manuell bewertet)
+> `[SHORTANS]` = `shortanswer` (Stichwort/Satz, automatisch geprüft)
+> `[NUMERIC]` = `numerical` (Zahlenwert ± Toleranz)
+> `[CLOZE]` = `cloze` (Lückentext, gemischt)
+
+---
+
+<!-- _class: lead -->
+
+## BLOCK A – Von-Neumann-Architektur
+
+---
+
+### A1 – Komponenten zuordnen
+**Thema:** Von-Neumann Grundstruktur
+**Punkte:** 3
+**Typ:** `[MATCH]`
+
+Ordne jeder Komponente der Von-Neumann-Architektur ihre Funktion zu.
+
+| Komponente | Funktion |
+|---|---|
+| Rechenwerk (ALU) | Führt arithmetische und logische Operationen durch |
+| Steuerwerk | Holt, dekodiert und steuert die Ausführung von Befehlen |
+| Speicherwerk | Enthält sowohl Programme als auch Daten |
+| Ein-/Ausgabe | Schnittstelle zu externen Geräten (Tastatur, Bildschirm, Netzwerk) |
+| Bus-System | Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus |
+
+> **Feedback:** Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).
+
+---
+
+<!-- _class: disable -->
+
+### A2 – Welche Komponente ist das?
+**Thema:** Von-Neumann – einzelne Komponente identifizieren
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Ein Programm besteht aus einer Folge von Befehlen. Eine Komponente der Von-Neumann-Architektur ist für das Abrufen, Dekodieren und Ausführen dieser Befehle zuständig. Welche?
+
+- [ ] Rechenwerk (ALU)
+- [x] **Steuerwerk** ✅
+- [ ] Speicherwerk
+- [ ] Ein-/Ausgabe
+
+> **Feedback:** Das Steuerwerk (Control Unit) orchestriert den Fetch-Decode-Execute-Zyklus – es ist der „Dirigent" der CPU.
+
+---
+
+### A3 – Von-Neumann: Was wird ermöglicht?
+**Thema:** Von-Neumann – Bedeutung
+**Punkte:** 2
+**Typ:** `[MM]` (Mehrfachauswahl)
+
+Welche der folgenden Aussagen werden durch die Von-Neumann-Architektur ermöglicht? (Mehrere Antworten möglich)
+
+- [x] **Betriebssysteme können verschiedene Programme aus dem Speicher laden.** ✅
+- [x] **Apps können ohne Hardwareänderung installiert werden.** ✅
+- [ ] Der Computer kann nur ein einziges Programm gleichzeitig ausführen.
+- [x] **Multitasking wird möglich.** ✅
+- [ ] Die Hardware muss für jedes neue Programm physisch umgebaut werden.
+- [x] **Software kann aktualisiert werden, ohne die Hardware zu ändern.** ✅
+
+> **Feedback:** Kern der Von-Neumann-Architektur: Programme und Daten teilen denselben Speicher → Programme sind austauschbare Daten. Ohne das: kein Betriebssystem, keine Apps, kein Multitasking, keine Updates.
+
+---
+
+<!-- _class: lead -->
+
+## BLOCK B – Netzwerk-Grundlagen (TCP/IP)
+
+---
+
+### B1 – Protokoll → TCP/IP-Schicht zuordnen
+**Thema:** TCP/IP-Schichtmodell – Zuordnung
+**Punkte:** 3
+**Typ:** `[MATCH]`
+
+Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.
+
+| Protokoll | Schicht |
+|----------|---|
+| HTTP     | Anwendung |
+| DNS      | Anwendung |
+| TCP      | Transport |
+| UDP      | Transport |
+| IP       | Internet |
+| Ethernet | Netzzugang |
+| WLAN | Netzzugang |
+
+> **Feedback:** Anwendung: HTTP, DNS, SMTP, FTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.
+
+---
+
+### B2 – Welche Schicht ist das? (einzeln)
+**Thema:** TCP/IP – einzelne Schicht identifizieren
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Das Protokoll IP arbeitet auf welcher TCP/IP-Schicht?
+
+- [ ] Anwendung
+- [ ] Transport
+- [x] **Internet** ✅
+- [ ] Netzzugang
+
+> **Feedback:** IP (Internet Protocol) arbeitet auf der Internet-Schicht – dort werden Pakete adressiert und geroutet.
+
+---
+
+<!-- _class: disable -->
+
+### B3 – Schicht-Funktion beschreiben
+**Thema:** TCP/IP – Funktionen der Schichten
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Beschreibe in einem Satz pro Schicht die Hauptfunktion jeder der vier TCP/IP-Schichten (Anwendung, Transport, Internet, Netzzugang).
+
+> **Musterlösung:** Anwendung: Stellt Protokolle für spezifische Dienste bereit (HTTP für Web, SMTP für Mail). Transport: Sorgt für zuverlässige (TCP) oder schnelle (UDP) Übertragung zwischen zwei Endpunkten. Internet: Adressiert und routet Pakete über Netzwerkgrenzen hinweg mittels IP. Netzzugang: Übertragen von Frames auf einem physischen Übertragungsweg (Ethernet, WLAN).
+
+---
+
+### B4 – Was ist eine MAC-Adresse?
+**Thema:** MAC-Adresse – Konzept
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was identifiziert eine MAC-Adresse?
+
+- [ ] Den konkreten Dienst (z. B. Webserver) auf einem Computer.
+- [ ] Den Computer im globalen Internet über Netzwerkgrenzen hinweg.
+- [x] **Die Netzwerkkarte eines Geräts auf einem lokalen Netzwerksegment.** ✅
+- [ ] Die Routen, die ein Paket durch das Internet nimmt.
+
+> **Feedback:** MAC = Media Access Control. Sie ist eine 48-Bit-Adresse, die einer Netzwerkkarte ab Werk zugewiesen wird – lokal, ein Hop.
+
+---
+
+### B5 – Was ist eine IP-Adresse?
+**Thema:** IP-Adresse – Konzept
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was identifiziert eine IP-Adresse?
+
+- [ ] Die Netzwerkkarte eines Geräts auf einem lokalen Segment.
+- [x] **Ein Gerät (Host) im globalen Internet – sie ermöglicht das Routing über Netzwerkgrenzen.** ✅
+- [ ] Den Dienst, der auf einem bestimmten Port läuft.
+- [ ] Die physische Leitung zwischen zwei Computern.
+
+> **Feedback:** IP = Internet Protocol. Die IP-Adresse ist der globale „Hausnummer" eines Geräts – routing-tauglich, im Gegensatz zur lokalen MAC-Adresse.
+
+---
+
+### B6 – Was ist eine Port-Nummer?
+**Thema:** Port – Konzept
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Wozu dient eine Port-Nummer auf dem Zielrechner?
+
+- [ ] Sie bestimmt die Geschwindigkeit der Verbindung.
+- [ ] Sie identifiziert das Gerät im Netzwerk.
+- [x] **Sie adressiert den konkreten Dienst bzw. die Anwendung auf dem Computer (z. B. Webserver auf 80, HTTPS auf 443).** ✅
+- [ ] Sie zeigt an, ob das Gerät per WLAN oder Kabel verbunden ist.
+
+> **Feedback:** IP = „Welches Gebäude?", Port = „Welche Tür im Gebäude?" (welcher Dienst soll die Anfrage empfangen).
+
+---
+
+### B7 – IP, MAC, Port: Zuordnung
+**Thema:** Adressierung – Unterschiede auf einen Blick
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jeder Adresse ihre Beschreibung zu.
+
+| Adresse | Beschreibung |
+|---|---|
+| IP-Adresse | Globale Adresse eines Geräts – ermöglicht Routing über Netzwerkgrenzen |
+| MAC-Adresse | Lokale Adresse einer Netzwerkkarte – nur innerhalb eines Segments gültig |
+| Port-Nummer | Adressiert einen bestimmten Dienst auf einem Computer |
+
+> **Feedback:** Drei Ebenen der Adressierung: Gerät global (IP), Gerät lokal (MAC), Dienst auf dem Gerät (Port).
+
+---
+
+<!-- _class: disable -->
+
+### B8 – MAC ändert sich, IP nicht: Warum?
+**Thema:** IP vs. MAC beim Routing – Transfer
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Ein Paket reist von Ihrem Laptop zu einem Webserver über mehrere Router. Erkläre in 2–3 Sätzen, warum die MAC-Adresse an jedem Router neu gesetzt wird, während die IP-Adresse des Ziel-Servers konstant bleibt.
+
+> **Musterlösung:** Die IP-Adresse des Ziel-Servers bleibt konstant, weil sie das globale Routingziel identifiziert – jeder Router nutzt sie, um das nächste Hop zu bestimmen. Die MAC-Adresse hingegen gilt nur für ein einzelnes Netzwerksegment (einen „Hop"). An jedem Router wird ein neuer Frame erstellt mit der MAC des nächsten Hops als Ziel – die alte MAC wird verworfen.
+
+---
+
+### B9 – Encapsulation: Dateneinheit → Schicht
+**Thema:** Encapsulation – Zuordnung
+**Punkte:** 3
+**Typ:** `[MATCH]`
+
+Bei der Übertragung wird eine Nachricht von Schicht zu Schicht verpackt. Ordne jeder Dateneinheit die zugehörige Schicht und was hinzugefügt wird.
+
+| Dateneinheit | Schicht + Was wird ergänzt |
+|---|---|
+| Daten | Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite) |
+| Segment | Transportschicht – Daten + Ports und Sequenznummern |
+| Paket | Internetschicht – Segment + IP-Adressen (Quelle und Ziel) |
+| Frame | Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme |
+
+> **Feedback:** D-S-P-F: Daten → Segment → Paket → Frame. Jede Schicht fügt einen Header (und beim Frame auch einen Trailer) hinzu.
+
+---
+
+### B10 – Encapsulation: Reihenfolge sortieren
+**Thema:** Encapsulation – Reihenfolge
+**Punkte:** 2
+**Typ:** `[ORDER]`
+
+Sortiere die Dateneinheiten in der Reihenfolge, wie sie beim Senden entstehen (von innen nach außen):
+
+1. Daten
+2. Segment
+3. Paket
+4. Frame
+
+> **Feedback:** Zwiebelprinzip: Die Anwendung erzeugt Daten → Transport verpackt zu einem Segment → Internet zu einem Paket → Netzzugang zum Frame.
+
+---
+
+### B11 – Decapsulation: Umgekehrte Reihenfolge
+**Thema:** Decapsulation – Empfänger-Seite
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Wenn der Server das Signal empfängt, passiert Decapsulation. In welcher Reihenfolge werden die Header entfernt?
+
+- [ ] Anwendung → Transport → Internet → Netzzugang
+- [ ] Alle Header werden gleichzeitig entfernt, sobald die Daten im RAM liegen.
+- [x] **Netzzugang (Ethernet-Header weg) → Internet (IP-Header weg) → Transport (TCP-Header weg) → Daten.** ✅
+- [ ] Internet → Netzzugang → Transport → Anwendung
+
+> **Feedback:** Das Auspacken erfolgt in umgekehrter Reihenfolge wie das Einpacken – der äußerste Header (Frame) wird zuerst entfernt.
+
+---
+
+### B12 – Encapsulation: Lückentext
+**Thema:** Encapsulation – Terminologie
+**Punkte:** 2
+**Typ:** `[CLOZE]`
+
+Bei der Übertragung wird eine Nachricht von Schicht zu Schicht verpackt. Die Transportschicht erzeugt ein [[1:Segment]], die Internetschicht ein [[2:Paket]], und die Netzzugangsschicht einen [[3:Frame]]. Am Empfänger wird dieses in [[4:umgekehrter Reihenfolge]] wieder abgepackt (Decapsulation).
+
+> **Feedback:** D-S-P-F vorwärts beim Senden, F-P-S-D beim Empfangen. Jeder Name beschreibt die Dateneinheit mit allen bis zu dieser Schicht hinzugefügten Headern.
+
+---
+
+### B13 – TCP vs. UDP: Videostreaming
+**Thema:** TCP vs. UDP – Echtzeit-Szenario
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Ein Videostreaming-Dienst sendet Daten an Ihren Browser. Ein einzelnes Paket geht verloren. Warum wählt der Dienst UDP statt TCP?
+
+- [ ] UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.
+- [x] **Bei Echtzeit ist Verzögerung schlimmer als Verlust. TCP würde das Paket erneut anfordern → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter.** ✅
+- [ ] TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.
+- [ ] UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.
+
+> **Feedback:** Der Kern: Bei Echtzeit zählt Latenz, nicht Vollständigkeit. Ein fehlendes Frame ist besser als ein eingefrorenes Video.
+
+---
+
+### B14 – TCP vs. UDP: Unterschiede beschreiben
+**Thema:** TCP vs. UDP – Konzept-Vergleich
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Nenne zwei wesentliche Unterschiede zwischen TCP und UDP und gib für jeden einen konkreten Anwendungsfall an, in dem genau dieses Eigenschaftspaar ausschlaggebend ist.
+
+> **Musterlösung:** (1) TCP ist verbindungsorientiert und zuverlässig (Handshake, Sequenznummern, ACK) → ideal für Dateiübertragung, wo jedes Byte zählt. (2) UDP ist verbindungslos und schneller, aber ohne Garantie für Lieferung oder Reihenfolge → ideal für Echtzeit-Anwendungen wie Videostreaming oder Online-Gaming, wo Latenz wichtiger als Vollständigkeit ist.
+
+---
+
+### B15 – TCP vs. UDP: Richtig oder Falsch?
+**Thema:** TCP vs. UDP – Aussagen prüfen
+**Punkte:** 1
+**Typ:** `[MC]`
+
+„UDP garantiert, dass alle Pakete in der richtigen Reihenfolge ankommen."
+
+Diese Aussage ist …
+
+- [ ] …korrekt – UDP nutzt Sequenznummern wie TCP.
+- [x] **…falsch – UDP bietet keine Garantie für Reihenfolge noch für Lieferung.** ✅
+- [ ] …korrekt – UDP ist sogar zuverlässiger als TCP.
+- [ ] …falsch – UDP existiert gar nicht mehr in modernen Netzwerken.
+
+> **Feedback:** UDP = „fire and forget". Keine Verbindung, keine Sequenznummern, keine Bestätigung. Genau deshalb ist es schneller.
+
+---
+
+### B16 – TCP 3-Way-Handshake: SYN geht verloren
+**Thema:** TCP-Verbindungsaufbau – Störfall
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Der Client sendet ein SYN zum Server. Das SYN-Paket geht verloren – es erreicht den Server nie. Was passiert als nächstes?
+
+- [ ] Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist.
+- [x] **Der Server kennt die Anfrage nicht → sendet kein SYN-ACK → der Client erhält keine Antwort → keine Verbindung. Der Client sendet das SYN nach einem Timeout erneut.** ✅
+- [ ] Der Client sendet direkt ein ACK als Fallback – Verbindung mit zwei Paketen.
+- [ ] Das verloren gegangene SYN wird vom Netzwerk automatisch rekonstruiert.
+
+> **Feedback:** Ohne SYN beim Server: kein SYN-ACK, kein Handshake, keine Verbindung. TCP retransmittiert nach Timeout.
+
+---
+
+### B17 – TCP 3-Way-Handshake: Ablauf beschreiben
+**Thema:** TCP-Verbindungsaufbau – Konzept
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Beschreibe die drei Schritte des TCP 3-Way-Handshakes. Erkläre, warum alle drei Schritte nötig sind, bevor Daten gesendet werden.
+
+> **Musterlösung:** (1) Client → Server: SYN („Ich will eine Verbindung aufbauen"). (2) Server → Client: SYN-ACK (「Ich bestätige das und will auch eine Verbindung"). (3) Client → Server: ACK ("Bestätigt"). Alle drei Schritte sind nötig, damit beide Seiten wissen, dass die andere die Verbindung akzeptiert hat – erst dann kann zuverlässiger Datenaustausch beginnen.
+
+---
+
+### B18 – TCP Sequenznummern: Wozu?
+**Thema:** TCP – Sequenznummern
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Welches Problem lösen Sequenznummern im TCP-Header konkret?
+
+- [ ] Sie verhindern, dass Hacker die Verbindung abhören können.
+- [x] **Pakete können in falscher Reihenfolge ankommen. Sequenznummern erlauben das korrekte Sortieren beim Empfänger.** ✅
+- [ ] Sie zählen, wie viele Benutzende gleichzeitig auf dem Server sind.
+- [ ] Sie bestimmen die maximale Größe einer Datei.
+
+> **Feedback:** IP-Pakete können unterschiedliche Routen nehmen → Part 3 kommt vor Part 1. TCP sortiert sie anhand der Sequenznummern wieder.
+
+---
+
+<!-- _class: lead -->
+
+## BLOCK C – HTTP
+
+---
+
+### C1 – HTTP-Methoden: Zuordnung
+**Thema:** HTTP-Methoden – Was macht was
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jeder HTTP-Methode ihre Hauptfunktion zu.
+
+| Methode | Hauptfunktion |
+|---|---|
+| GET | Ruft eine Ressource ab (nur lesen) |
+| POST | Erstellt eine neue Ressource auf dem Server |
+| PUT | Ersetzt eine existierende Ressource vollständig |
+| DELETE | Löscht eine Ressource auf dem Server |
+
+> **Feedback:** CRUD-Mapping: GET=Read, POST=Create, PUT=Update, DELETE=Delete.
+
+---
+
+### C2 – POST vs. PUT: Unterschied
+**Thema:** HTTP-Methoden – POST vs. PUT
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Eine Person erstellt einen neuen Blog-Eintrag auf einer Webseite. Welche HTTP-Methode wird verwendet?
+
+- [x] **POST – eine neue Ressource wird erstellt.** ✅
+- [ ] PUT – PUT wird immer verwendet, wenn Daten gesendet werden.
+- [ ] GET – GET kann auch Daten senden mit URL-Parametern.
+- [ ] DELETE – DELETE erstellt und löscht gleichzeitig.
+
+> **Feedback:** POST = „Erstelle etwas Neues". PUT = „Ersetze etwas Bestehendes". Neuer Blog-Eintrag → POST.
+
+---
+
+### C3 – PUT: Profilbild ersetzen
+**Thema:** HTTP-Methoden – PUT im Szenario
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Eine Person aktualisiert ihr Profilbild – das alte Bild wird durch ein neues ersetzt. Welche HTTP-Methode?
+
+- [ ] GET – GET kann auch Daten senden.
+- [x] **PUT – ersetzt eine existierende Ressource.** ✅
+- [ ] POST – POST ist immer für das Ersetzen zuständig.
+- [ ] DELETE – DELETE sendet das neue Foto und löscht das alte.
+
+> **Feedback:** „Ersetzen einer existierenden Ressource" = PUT. POST wäre, wenn ein völlig neues Bild erstellt würde, ohne dass ein vorhandenes überschrieben wird.
+
+---
+
+### C4 – DELETE: Wann nutzen?
+**Thema:** HTTP-Methoden – DELETE im Szenario
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Eine Person löscht einen von ihr erstellten Kommentar auf einer Webseite. Welche HTTP-Methode wird der Browser im Hintergrund verwenden?
+
+- [ ] GET – GET kann auch Löschvorgänge auslösen.
+- [ ] POST – POST ist die Standardmethode für alle Änderungen.
+- [ ] PUT – PUT löscht und ersetzt gleichzeitig.
+- [x] **DELETE – der Kommentar wird vom Server entfernt.** ✅
+
+> **Feedback:** DELETE = „Entferne diese Ressource vom Server." Konkret: der Kommentar wird anhand seiner URL/ID identifiziert und gelöscht.
+
+---
+
+<!-- _class: disable -->
+
+### C5 – GET: Warum nicht für Passwörter?
+**Thema:** HTTP-Methoden – GET Sicherheit
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Warum sollte man niemals GET verwenden, um sensible Daten (z. B. ein Passwort) an den Server zu senden?
+
+- [ ] GET ist langsamer als POST – Passwörter müssen schnell übertragen werden.
+- [x] **Bei GET stehen die Daten sichtbar in der URL (Browser-Verlauf, Server-Logs, Proxy-Server). Bei POST sind sie im Body versteckt.** ✅
+- [ ] GET erlaubt nur Zahlen, keine Buchstaben.
+- [ ] GET wird vom Server nie verschlüsselt, POST immer.
+
+> **Feedback:** GET-Parameter hängen an der URL (`?pw=123`). Diese ist in History, Logs, Proxies sichtbar. HTTPS verschlüsselt zwar beides auf der Leitung, aber die URL selbst wird an zu vielen Stellen gespeichert.
+
+---
+
+### C6 – Status-Codes: Kategorisierung
+**Thema:** HTTP Status-Codes – Bedeutung der ersten Ziffer
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jeder ersten Ziffer eines HTTP-Status-Codes ihre Bedeutung zu.
+
+| Erste Ziffer | Bedeutung |
+|---|---|
+| 2xx | Erfolg – die Anfrage wurde erfolgreich verarbeitet |
+| 3xx | Weiterleitung – die Ressource wurde verschoben |
+| 4xx | Client-Fehler – die Anfrage der Anfragenden war fehlerhaft |
+| 5xx | Server-Fehler – der Server hat ein Problem |
+
+> **Feedback:** Die erste Ziffer = Kategorie. 200 OK, 301 Moved, 404 Not Found, 503 Service Unavailable – die Kategorie sagt Ihnen sofort, wo das Problem liegt.
+
+---
+
+### C7 – 503: Server-Fehler erkläre
+**Thema:** HTTP Status-Codes – 5xx Transfer
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Sie rufen eine Webseite auf und erhalten `HTTP/2 503 Service Unavailable`. Was bedeutet das?
+
+- [ ] Sie haben die falsche URL eingegeben.
+- [ ] Der Server hat die Anfrage erfolgreich umgeleitet.
+- [x] **Der Server ist überlastet oder temporär nicht verfügbar – Verantwortung liegt beim Betreiber.** ✅
+- [ ] Der Server hat die Seite dauerhaft verschoben.
+
+> **Feedback:** 5xx = Server-Problem. Sie als Client können nur später erneut versuchen. Der Betreiber muss das lösen.
+
+---
+
+### C8 – 404: Wer hat „Schuld"?
+**Thema:** HTTP Status-Codes – 4xx Transfer
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Sie erhalten einen 404-Fehler. Wer ist für die Ursache verantwortlich?
+
+- [ ] Der Server ist abgestürzt.
+- [ ] Das Internet ist ausgefallen.
+- [x] **Der Client (Anfragende) – eine URL wurde angefordert, die nicht existiert (Tippfehler oder veralteter Link).** ✅
+- [ ] Der DNS-Server konnte den Namen nicht auflösen.
+
+> **Feedback:** 4xx = Client-Fehler. Der Server funktioniert perfekt, er sagt nur: „Das, was Sie anfragen, habe ich nicht."
+
+---
+
+### C9 – Status-Codes: Szenarios zuordnen
+**Thema:** HTTP Status-Codes – Transfer Zuordnung
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Szenario den passenden HTTP-Status-Code zu.
+
+| Szenario | Status-Code |
+|---|---|
+| Sie rufen eine Seite auf, die seit letztem Jahr auf eine neue URL umgeleitet wurde | 301 Moved Permanently |
+| Eine Webseite lädt erfolgreich | 200 OK |
+| Sie geben eine URL ein, die nicht existiert | 404 Not Found |
+| Der Webserver ist überlastet | 503 Service Unavailable |
+
+> **Feedback:** 200 = Alles gut. 301 = dauerhaft verschoben. 404 = nicht gefunden (Ihr Fehler). 503 = Server-Problem (Betreiber).
+
+---
+
+### C10 – Status-Codes: Freitext
+**Thema:** HTTP Status-Codes – Konzept zusammenfassen
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre, warum HTTP-Status-Codes aus einer dreistelligen Zahl bestehen und was die erste Ziffer konkret bedeutet. Nenne je einen Beispiel-Code für 2xx, 4xx und 5xx.
+
+> **Musterlösung:** Die erste Ziffer kategorisiert die Antwort: 2xx = Erfolg, 3xx = Weiterleitung, 4xx = Client-Fehler, 5xx = Server-Fehler. Die restlichen zwei Ziffern spezifizieren den genauen Fall. Beispiele: 200 OK (Erfolg), 404 Not Found (Client-Fehler), 500 Internal Server Error (Server-Fehler). Diese Struktur ermöglicht es, allein aus dem Code zu verstehen, ob und wo ein Problem liegt – ohne die Antwort ganz lesen zu müssen.
+
+---
+
+<!-- _class: lead -->
+
+## BLOCK D – DNS
+
+---
+
+### D1 – DNS: Was macht es?
+**Thema:** DNS – Grundfunktion
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was ist die Hauptfunktion eines DNS-Servers?
+
+- [ ] Er verschlüsselt die Verbindung zwischen Client und Server.
+- [x] **Er übersetzt einen Domain-Namen (z. B. `hdm-stuttgart.de`) in eine IP-Adresse.** ✅
+- [ ] Er routet Pakete durch das Internet.
+- [ ] Er weist jedem Computer eine MAC-Adresse zu.
+
+> **Feedback:** DNS = Domain Name System = „Telefonbuch des Internets". Name → IP. Ohne DNS müsste man überall IP-Adressen eintippen.
+
+---
+
+### D2 – DNS: Zeitlicher Ablauf
+**Thema:** DNS – Rolle im Gesamtablauf
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Sie geben `https://hdm-stuttgart.de` in die Adresszeile ein. Was passiert vor dem TCP-Handshake?
+
+- [ ] Der Browser sendet direkt den Namen an den Server – DNS wird erst danach benötigt.
+- [x] **DNS-Auflösung: Der Name wird in eine IP-Adresse umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen.** ✅
+- [ ] DNS passiert nach dem TCP-Handshake.
+- [ ] DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.
+
+> **Feedback:** DNS vor TCP. Kein Name-to-IP? Kein Handshake möglich. TCP arbeitet auf IP-Adressen, nicht auf Domain-Namen.
+
+---
+
+### D3 – DNS: Warum zwingend nötig?
+**Thema:** DNS – Transfer/Begründung
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre in 2–3 Sätzen, warum der DNS-Schritt zwingend vor dem TCP-Handshake stehen muss. Was würde passieren, wenn der Browser den Domain-Namen direkt an den Netzwerk-Stack übergeben würde?
+
+> **Musterlösung:** TCP arbeitet nur mit IP-Adressen – ein Domain-Name wie `hdm-stuttgart.de` ist für TCP-/IP-Stack sinnlos. Ohne vorherige DNS-Auflösung würde der Browser nicht wissen, an welche IP er das SYN senden soll. Der DNS-Schritt konvertiert den human-readable-Namen in eine maschinenlesbare IP, erst danach kann der Verbindungsaufbau beginnen.
+
+---
+
+### D4 – DNS: Lückentext
+**Thema:** DNS – Terminologie
+**Punkte:** 1
+**Typ:** `[CLOZE]`
+
+Der DNS-Server übersetzt einen [[1:Domain-Namen]] in eine [[2:IP-Adresse]]. Dieser Schritt fällt [[3:vor]] dem TCP-Handshake statt, weil TCP nur zu [[4:IP-Adressen]] Verbindungen aufbauen kann.
+
+> **Feedback:** Die vier Lücken beschreiben den DNS-Ablauf vollständig: Was wird übersetzt, in was, wann, und warum.
+
+---
+
+<!-- _class: lead -->
+
+## BLOCK E – Der Gesamtablauf (Zusammen)
+
+---
+
+### E1 – Reihenfolge eines HTTPS-Aufrufs
+**Thema:** Gesamtablauf – Sortierung
+**Punkte:** 2
+**Typ:** `[ORDER]`
+
+Sortiere die Schritte eines HTTPS-Aufrufs in der richtigen Reihenfolge:
+
+1. DNS-Auflösung (Name → IP)
+2. TCP 3-Way-Handshake (Verbindung aufbauen)
+3. TLS-Handshake (Verschlüsselung vereinbaren)
+4. HTTP GET (Anfrage senden)
+5. HTTP 200 OK + HTML (Antwort empfangen)
+
+> **Feedback:** DNS → TCP → TLS → HTTP Request → HTTP Response. Jeder Schritt ist eine Voraussetzung für den nächsten.
+
+---
+
+### E2 – Reihenfolge: Welche Folge ist korrekt?
+**Thema:** Gesamtablauf – Multiple Choice
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Sie geben eine URL ein. Welche Reihenfolge ist korrekt?
+
+- [ ] (1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK
+- [x] **(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK** ✅
+- [ ] (1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK
+- [ ] (1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK
+
+> **Feedback:** DNS immer zuerst. Dann TCP (Verbindung). Dann HTTP (Anfrage/Antwort).
+
+---
+<!-- _class: lead -->
+
+## BLOCK F – HTML-Grundlagen
+
+---
+
+### F1 – `<head>` vs. `<body>`: Was passiert bei Fehler?
+**Thema:** HTML-Struktur – head/body
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Eine studierende Person platziert den `<title>` und `<meta name="description">` im `<body>` statt im `<head>`. Welche zwei Konsequenzen hat das?
+
+- [ ] Kein Problem – Browser ignorieren die Unterscheidung.
+- [x] **(1) Der Browser-Tab zeigt keinen Titel an. (2) Suchmaschinen haben keine Beschreibung für das Snippet → schlechte SEO, Screen-Reader können die Seite nicht richtig vorlesen.** ✅
+- [ ] (1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.
+- [ ] Nur das Fehlen von `<meta charset>` ist ein Problem.
+
+> **Feedback:** `<head>` = Metadaten (unsichtbar für die Benutzenden, sichtbar für Browser/Maschinen). `<body>` = sichtbarer Inhalt. Title und description im Body werden nicht als Metadaten interpretiert.
+
+---
+
+### F2 – `<head>`: Was gehört wohin?
+**Thema:** HTML-Struktur – Zuordnung
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Element zu, ob es in `<head>` oder `<body>` gehört.
+
+| Element | Wohin? |
+|---|---|
+| `<title>` | `<head>` |
+| `<meta charset="UTF-8">` | `<head>` |
+| `<meta name="description">` | `<head>` |
+| `<h1>Willkommen</h1>` | `<body>` |
+| `<p>Text hier</p>` | `<body>` |
+| `<link rel="stylesheet">` | `<head>` |
+
+> **Feedback:** `<head>` = alles, was die Benutzenden nicht direkt sehen (Metadaten, Styles, Titel). `<body>` = alles, was im Browser-Fenster angezeigt wird.
+
+---
+
+### F3 – Charset: Was passiert ohne `<meta charset>`?
+**Thema:** HTML – Zeichenkodierung
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was ist die konkrete Konsequenz, wenn `<meta charset="UTF-8">` fehlt oder falsch gesetzt ist?
+
+- [ ] Die Webseite lädt gar nicht.
+- [x] **Sonderzeichen (Umlaute, Emojis) werden als kryptische Symbole dargestellt, weil der Browser die falsche Zeichenkodierung rät.** ✅
+- [ ] Die Seite wird langsamer, da der Browser alle Sprachen durchprobieren muss.
+- [ ] Das CSS wird nicht geladen.
+
+> **Feedback:** Ohne charset nutzt der Browser oft einen Standard wie Latin-1. Bei UTF-8-gespeicherten Dateien → Umlaute und Emojis werden falsch dargestellt (Mojibake).
+
+---
+
+<!-- _class: lead -->
+
+## BLOCK G – CSS
+
+---
+
+### G1 – Spezifität: ID vs. Klasse vs. Element
+**Thema:** CSS Spezifität – Grundregel
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Gegeben:
+```
+p           { color: blue; }
+.highlight  { color: green; }
+#main       { color: red; }
+```
+Ein Element `<p class="highlight" id="main">` wird angezeigt. Welche Farbe?
+
+- [ ] Blau – die Element-Regel steht zuerst im Code.
+- [ ] Grün – Klassen haben immer Vorrang vor IDs.
+- [x] **Rot – die ID `#main` hat die höchste Spezifität (0,1,0,0).** ✅
+- [ ] Rot – die letzte Regel im Code gewinnt immer.
+
+> **Feedback:** Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Reihenfolge im Code ist nur relevant bei gleicher Spezifität.
+
+---
+
+
+### G2 – Responsive Design: Mobile First – Welche Farbe?
+**Thema:** CSS Media Queries – Mobile First
+**Punkte:** 2
+**Typ:** `[MC]`
+
+```css
+.container { background: white; }
+@media (min-width: 768px) { .container { background: blue; } }
+@media (min-width: 1024px) { .container { background: green; } }
+```
+Welche Farbe bei 900 px Breite?
+
+- [ ] Weiß – Media-Queries gelten nur ab 1024 px.
+- [ ] Grün – die letzte Media-Query überschreibt immer.
+- [x] **Blau – bei 900 px greift `min-width: 768px` (900 ≥ 768), aber `min-width: 1024px` nicht (900 < 1024).** ✅
+- [ ] Weiß – keine Media-Query greift zwischen den Breakpoints.
+
+> **Feedback:** Mobile First: Basis = white. Bei 900px: 768px-Query greift ✓, 1024px-Query greift ✗ → blau.
+
+---
+
+<!-- _class: disable -->
+
+### G3 – Desktop First: `max-width` erkläre
+**Thema:** CSS Media Queries – Desktop First
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Wie würde eine Media Query für „Desktop First" aussehen (Standard ist Desktop, Anpassung für kleine Screens)?
+
+- [ ] `@media (device-width: small) { ... }`
+- [ ] `@media (min-width: ...)` – bleibt gleich, nur die Reihenfolge ändert sich.
+- [x] **`@media (max-width: ...)` – Stile für Bildschirme, die kleiner als eine bestimmte Breite sind.** ✅
+- [ ] `@media (mobile: true) { ... }`
+
+> **Feedback:** Desktop First: Basis-CSS für große Schirme. `max-width` = „Wenn der Bildschirm schmäler ist als X, dann…" – Ausnahmen für Tablets/Handys.
+
+---
+
+### G4 – Mobile First vs. Desktop First: Vergleich
+**Thema:** CSS Media Queries – Konzept-Vergleich
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre den Unterschied zwischen „Mobile First" und „Desktop First" beim Responsive Design. Welche Media-Query-Eigenschaft nutzt jeder Ansatz, und warum?
+
+> **Musterlösung:** Mobile First: Das Basis-CSS ist für kleine Bildschirme (Handy). Mit `min-width` werden schrittweise Anpassungen für größere Bildschirme hinzugefügt („ab dieser Breite"). Desktop First: Das Basis-CSS ist für große Bildschirme. Mit `max-width` werden Ausnahmen für kleinere Geräte definiert (「bis zu dieser Breite"). Mobile First wird bevorzugt, weil die Mehrheit der Benutzenden mobil zugrifft und forced-mobile-first die Grundlage für progressive Enhancement bietet.
+
+---
+
+<!-- _class: lead -->
+
+## BLOCK H – Barrierefreiheit
+
+---
+
+### H1 – Wie nutzen Menschen das Web?
+**Thema:** Barrierefreiheit – Eingabegeräte
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Eingabegerät seine Nutzungsweise zu.
+
+| Eingabe | Nutzungsweise |
+|---|---|
+| Maus | Klicken, Scrollen |
+| Tastatur | Tab-Navigation, Enter, Pfeiltasten |
+| Screenreader | Vorlesen von Inhalten |
+| Sprachsteuerung | „Klicke auf Anmelden" |
+| Augensteuerung | Eye-Tracking |
+| Switch-Geräte | Ein-/Aus-Schalter |
+
+> **Feedback:** Nicht alle nutzen Maus + Bildschirm. ~15% der Weltbevölkerung haben eine Behinderung (WHO). Assistive Technologien wie Screenreader (NVDA, VoiceOver, JAWS) oder Switch-Geräte ermöglichen Web-Zugang für Menschen mit verschiedenen Einschränkungen.
+
+---
+
+### H2 – Einschränkungen: Temporär vs. situativ
+**Thema:** Barrierefreiheit – Einschränkungstypen
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Eine Person kann aktuell nur mit einer Hand ihr Handy bedienen, weil sie das Baby auf dem Arm trägt. Wie klassifiziert man diese Einschränkung?
+
+- [ ] Permanent – das ist eine bleibende körperliche Behinderung.
+- [ ] Temporär – die Person ist verletzt und braucht Zeit zum Heilen.
+- [x] **Situativ – die Einschränkung entsteht durch die aktuelle Umgebung/Situation, nicht durch eine Behinderung.** ✅
+- [ ] Diese Art von Einschränkung existiert nicht – Barrierefreiheit betrifft nur Menschen mit Behinderung.
+
+> **Feedback:** Drei Typen: Permanent (z. B. Blindheit), Temporär (z. B. gebrochener Arm, Augen-OP), Situativ (z. B. helle Sonne, laute Umgebung, Baby auf dem Arm). Barrierefreie Gestaltung hilft bei allen drei.
+
+---
+
+<!-- _class: disable -->
+
+### H3 – Curb-Cut-Effekt: Beispiel identifizieren
+**Thema:** Barrierefreiheit – Curb-Cut-Effekt
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Welches Beispiel demonstriert den Curb-Cut-Effekt?
+
+- [ ] Barrierefreie Webseiten laden langsamer.
+- [x] **Untertitel: gedacht für Gehörlose, helfen aber auch in lauter Umgebung oder beim Sprachlernen.** ✅
+- [ ] Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.
+- [ ] Alt-Texte verlängern die Ladezeit einer Webseite.
+
+> **Feedback:** Curb-Cut-Effekt = eine barrierefreie Lösung nutzt am Ende allen. Untertitel für Gehörlose → helfen auch in lauter Umgebung. Kontrastreiche Farben für Sehbehinderung → besser im Sonnenlicht, für ältere Menschen.
+
+---
+
+<!-- _class: disable -->
+
+### H4 – Curb-Cut-Effekt: Erklärung
+**Thema:** Barrierefreiheit – Curb-Cut-Effekt Transfer
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre das Konzept des Curb-Cut-Effekts. Nenne zwei konkrete Web-Beispiele und erkläre jeweils, wer die ursprüngliche Zielgruppe war und wer sonst davon profitiert.
+
+> **Musterlösung:** Der Curb-Cut-Effekt beschreibt, wie eine Maßnahme für Menschen mit Behinderung am Ende allen zugute kommt – wie die Bordsteinabsenkung, die für Rollstuhlfahrer gedacht war, aber auch Kinderwagen, Rollkoffer und Fahrrädern helfen. Web-Beispiele: (1) Untertitel – primär für Gehörlose, helfen auch in lauter Umgebung oder beim Sprachlernen. (2) Alt-Texte – primär für Screen-Reader-Benutzende, helfen auch Suchmaschinen (SEO).
+
+---
+
+### H5 – EAA: Was ist das?
+**Thema:** Barrierefreiheit – Rechtlicher Rahmen
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was ist der European Accessibility Act (EAA)?
+
+- [ ] Ein freiwilliges EU-Programm zur Förderung barrierefreier Websites.
+- [x] **Eine EU-Richtlinie, die seit Juni 2025 in Kraft ist und Barrierefreiheit in bestimmten digitalen Bereichen verpflichtend macht.** ✅
+- [ ] Ein deutsches Gesetz, das nur öffentliche Behörden betrifft.
+- [ ] Ein technisches Standard wie HTML oder CSS.
+
+> **Feedback:** EAA = European Accessibility Act. Seit 28. Juni 2025 in Kraft. Betrifft E-Commerce, Banking, Telekommunikation, Transport, E-Books. In Deutschland umgesetzt durch das BFSG (Barrierefreiheitsstärkungsgesetz). Verstoß: bis 100.000€ Bußgeld möglich.
+
+---
+
+### H6 – Barrierefreiheit: Warum auch für „normale" Benutzende?
+**Thema:** Barrierefreiheit – Business Case
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre, warum barrierefreie Gestaltung nicht nur für Menschen mit Behinderung wichtig ist, sondern auch einen praktischen Nutzen für alle Benutzenden hat. Nenne mindestens zwei konkrete Beispiele.
+
+> **Musterlösung:** Barrierefreiheit verbessert die UX für alle: (1) SEO – Alt-Texte und semantisches HTML helfen Suchmaschinen, die Seite besser zu verstehen → besseres Ranking. (2) Mobile – viele barrierefreie Prinzipien (z. B. große Tippflächen, guter Kontrast) sind auch für Mobilgeräte im Sonnenlicht wichtig. (3) Ältere Menschen – Sehschwäche, motorische Einschränkungen betreffen einen großen Anteil der Bevölkerung. Der Markt: ~15% Menschen mit Behinderung + ~20% ältere Menschen.
+
+---
+
+### H7 – Tastatur-Test: Was prüfen?
+**Thema:** Barrierefreiheit – Praktischer Test
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Sie möchten eine Webseite auf Barrierefreiheit testen, ohne assistive Technologie zu installieren. Was machen Sie?
+
+- [ ] Sie scrollen durch die Seite und schauen, ob sie schön aussieht.
+- [x] **Sie navigieren nur mit Tab + Enter durch die Seite und prüfen: Erreichen Sie alle Funktionen? Ist der Fokus immer sichtbar? Ist die Tab-Reihenfolge logisch?** ✅
+- [ ] Sie installieren einen Screenreader und lassen die Seite vorlesen.
+- [ ] Sie öffnen den Quellcode und zählen die barrierefreien Tags.
+
+> **Feedback:** Der Tastatur-Test ist der schnellste barrierefreie Selbsttest: Nur Tab + Enter benutzen. Wenn man so eine Funktion nicht erreicht kann, ist sie für Tastatur-Benutzende (und damit auch für Screenreader-Benutzende) nicht zugänglich. Tools wie axe DevTools oder Lighthouse automatisieren ~30% der Checks.
+
+---
+
+<!-- _class: lead disable -->
+
+## BLOCK I – Zusammenfassung-Fragen (Übergreifend)
+
+---
+
+<!-- _class: disable -->
+
+### I1 – Gesamtablauf: Wahl der richtigen Methode
+**Thema:** HTTP + TCP + DNS zusammen
+**Punkte:** 3
+**Typ:** `[ESSAY]`
+
+Eine Person klickt auf einen „Neuen Eintrag erstellen"-Button einer Webanwendung. Beschreibe vom Klick bis zur Antwort des Servers, welche Protokolle beteiligt sind und welche HTTP-Methode verwendet wird.
+
+> **Musterlösung:** (1) Der Browser sendet eine HTTP-Anfrage. Da es sich um eine neue Ressource handelt, nutzt er POST. (2) Vorher: DNS löst den Domain-Namen auf. (3) TCP-Handshake stellt die Verbindung her. (4) POST-Anfrage wird gesendet (Daten im Body). (5) Server verarbeitet, erstellt den Eintrag, antwortet mit 201 Created.
+
+---
+
+<!-- _class: disable -->
+
+### I2 – Gesamtablauf: Störfall analysieren
+**Thema:** Netzwerk + HTTP – Transfer/Problemlösung
+**Punkte:** 3
+**Typ:** `[ESSAY]`
+
+Sie rufen eine Webseite auf und erhalten eine Fehlermeldung. Beschreibe drei verschiedene Szenarien, die zu einer Fehlermeldung führen könnten, und erkläre, in welcher „Schicht" des Ablaufs (DNS, TCP, HTTP) das Problem liegt und wie Sie es erkennen.
+
+> **Musterlösung:** (1) DNS-Fehler: „Der Server wurde nicht gefunden" → DNS konnte den Namen nicht auflösen (z. B. Tippfehler in der URL oder DNS-Server nicht erreichbar). (2) TCP-Fehler: „Die Verbindung wurde verweigert" → Server existiert (IP bekannt), akzeptiert aber keine Verbindung (nicht gestartet, Port blockiert). (3) HTTP-Fehler: 404 → TCP-Verbindung erfolgreich, aber die angeforderte Ressource existiert nicht auf dem Server.

From 62cd97c51a8c7a2d6051302d46b5ee2076e3114a Mon Sep 17 00:00:00 2001
From: Michael Czechowski <mail@dailysh.it>
Date: Mon, 2 Feb 2026 13:41:52 +0100
Subject: [PATCH 3/8] update makefile for per-course klausurfragen

- add klausurfragen to KAPITEL lists for both courses
- remove standalone build-klausurfragen target
- remove deploy-klausurfragen target
- klausurfragen now built and deployed as part of each course

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---
 Makefile | 28 +++++-----------------------
 1 file changed, 5 insertions(+), 23 deletions(-)

diff --git a/Makefile b/Makefile
index 3c707b8..60d313f 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # 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 klausur clean install deploy qr optimize-images klausurfragen build-klausurfragen deploy-klausurfragen
+.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
@@ -9,11 +9,11 @@ SLIDES_DIR = slides
 
 # Course-specific settings
 223015b_NAME = Dateiformate, Schnittstellen, Speichermedien
-223015b_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen klausurfolien
+223015b_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen klausurfolien klausurfragen
 223015b_DEPLOY_PATH = /home/tengo/html/hdm/223015b
 
 223015c_NAME = Internettechnologien
-223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien
+223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien klausurfragen
 223015c_DEPLOY_PATH = /home/tengo/html/hdm/223015c
 
 DEPLOY_HOST = tengo@tuttle.uberspace.de
@@ -85,18 +85,7 @@ build-b: build/.exists
 build-c: build/.exists
 	$(call build_course,223015c)
 
-build-klausurfragen: build/.exists
-	@echo "Building klausurfragen..."
-	@mkdir -p build
-	@if [ -f "$(SLIDES_DIR)/klausurfragen.md" ]; then \
-		echo "  Building klausurfragen.md..."; \
-		npx @marp-team/marp-cli "$(SLIDES_DIR)/klausurfragen.md" -o build/klausurfragen.html; \
-		npx @marp-team/marp-cli "$(SLIDES_DIR)/klausurfragen.md" --pdf --allow-local-files -o build/klausurfragen.pdf; \
-	else \
-		echo "  Skipping: $(SLIDES_DIR)/klausurfragen.md not found"; \
-	fi
-
-build: build-b build-c build-klausurfragen
+build: build-b build-c
 	@echo "All courses built!"
 
 # HTML only builds
@@ -210,20 +199,13 @@ deploy-b: build-b
 deploy-c: build-c
 	$(call deploy_course,223015c)
 
-# Deploy klausurfragen (root-level page)
-deploy-klausurfragen: build-klausurfragen
-	@echo "Deploying klausurfragen..."
-	@scp build/klausurfragen.html $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/ 2>/dev/null || true
-	@scp build/klausurfragen.pdf $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/ 2>/dev/null || true
-	@echo "klausurfragen deployed!"
-
 deploy-index: build-index
 	@echo "Deploying root index..."
 	scp build/index.html $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/
 	scp build/qr-root.svg $(DEPLOY_HOST):$(HDM_DEPLOY_PATH)/ 2>/dev/null || true
 	@echo "Root index deployed!"
 
-deploy: build-index deploy-b deploy-c deploy-klausurfragen deploy-index
+deploy: build-index deploy-b deploy-c deploy-index
 	@echo "All courses deployed!"
 
 # Clean

From 9b0b6bc9d6b7e75ebbf20d58090b3c33b573839c Mon Sep 17 00:00:00 2001
From: Michael Czechowski <mail@dailysh.it>
Date: Mon, 2 Feb 2026 13:41:58 +0100
Subject: [PATCH 4/8] remove global klausurfragen from root index

klausurfragen are now per-course, no longer shown on root index

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---
 scripts/generate-root-index.sh | 187 +++++++++++++++++++++++++++++++++
 1 file changed, 187 insertions(+)
 create mode 100755 scripts/generate-root-index.sh

diff --git a/scripts/generate-root-index.sh b/scripts/generate-root-index.sh
new file mode 100755
index 0000000..9f1675a
--- /dev/null
+++ b/scripts/generate-root-index.sh
@@ -0,0 +1,187 @@
+#!/usr/bin/env bash
+# Generate root index.html for /hdm/
+# Lists all courses (klausurfragen are now per-course)
+
+BUILD_DIR="build"
+
+cat > "$BUILD_DIR/index.html" << 'HEADER'
+<!DOCTYPE html>
+<html lang="de">
+<head>
+  <meta charset="UTF-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1.0">
+  <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: 0.5rem;
+    }
+    .subtitle { color: #86868b; font-size: 1rem; }
+    .courses {
+      margin-top: 2rem;
+      display: flex;
+      flex-direction: column;
+      gap: 0.75rem;
+    }
+    .course-card {
+      position: relative;
+      background: #fff;
+      border-radius: 12px;
+      box-shadow: 0 1px 3px rgba(0,0,0,0.08);
+      transition: all 0.2s ease;
+      display: grid;
+      grid-template-columns: 1fr auto auto;
+      align-items: center;
+      gap: 1rem;
+    }
+    .course-card:hover {
+      transform: translateY(-2px);
+      box-shadow: 0 4px 12px rgba(0,0,0,0.12);
+    }
+    .course-link {
+      display: block;
+      padding: 1.25rem 1.5rem;
+      text-decoration: none;
+      color: inherit;
+      grid-column: 1;
+    }
+    .course-link::after {
+      content: '';
+      position: absolute;
+      inset: 0;
+      border-radius: 12px;
+    }
+    .course-label {
+      font-size: 0.7rem;
+      font-weight: 600;
+      text-transform: uppercase;
+      letter-spacing: 0.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: 0.25rem 0;
+    }
+    .course-info { font-size: 0.85rem; color: #86868b; }
+    .btn {
+      display: inline-flex;
+      align-items: center;
+      justify-content: center;
+      padding: 0.5rem 1rem;
+      border-radius: 8px;
+      text-decoration: none;
+      font-size: 0.8rem;
+      font-weight: 500;
+      transition: all 0.2s;
+      white-space: nowrap;
+      position: relative;
+      z-index: 1;
+      margin-right: 0.5rem;
+    }
+    .btn-slides {
+      background: #6c757d;
+      color: #fff;
+    }
+    .btn-slides:hover { filter: brightness(1.1); }
+    .btn-pdf {
+      background: #f5f5f7;
+      color: #1d1d1f;
+    }
+    .btn-pdf:hover { background: #e8e8ed; }
+    .section-title {
+      font-size: 1rem;
+      font-weight: 600;
+      color: #86868b;
+      margin-top: 2.5rem;
+      margin-bottom: 0.75rem;
+    }
+    .references {
+      display: flex;
+      flex-direction: column;
+      gap: 0.75rem;
+    }
+    footer {
+      margin-top: 2.5rem;
+      padding-top: 1.5rem;
+      border-top: 1px solid #e5e5e7;
+      color: #86868b;
+      font-size: 0.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: 0.75rem; font-size: 0.85rem; color: #86868b; }
+    @media (max-width: 600px) {
+      .course-card { grid-template-columns: 1fr; }
+      .course-link { padding-bottom: 0.75rem; }
+      .btn { margin: 0 1rem 1rem 1.5rem; }
+    }
+  </style>
+</head>
+<body>
+  <h1>HdM Vorlesungen</h1>
+  <p class="subtitle">Wintersemester 2025/26 · Michael Czechowski</p>
+  <div class="courses">
+    <div class="course-card course-b">
+      <a href="223015b/" class="course-link">
+        <span class="course-label">223015b</span>
+        <div class="course-title">Dateiformate, Schnittstellen, Speichermedien &amp; Distributionswege</div>
+        <span class="course-info">6 Kapitel · Modul "Technik 1"</span>
+      </a>
+    </div>
+    <div class="course-card course-c">
+      <a href="223015c/" class="course-link">
+        <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>
+HEADER
+
+cat >> "$BUILD_DIR/index.html" << 'FOOTER'
+  </div>
+  <h2 class="section-title">Referenzen</h2>
+  <div class="references">
+    <div class="course-card">
+      <a href="https://codecrispi.es/" class="course-link">
+        <span class="course-label">Plattform</span>
+        <div class="course-title">Code Crispies</div>
+        <span class="course-info">Selbstlernplattform</span>
+      </a>
+    </div>
+  </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>
+FOOTER
+
+echo "Generated $BUILD_DIR/index.html"

From 705c5e34578fd13badf7945bfa07bcdca0bb3a15 Mon Sep 17 00:00:00 2001
From: Michael Czechowski <mail@dailysh.it>
Date: Mon, 2 Feb 2026 13:42:02 +0100
Subject: [PATCH 5/8] add klausurfragen to topic map in generate-index.sh

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---
 scripts/generate-index.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/generate-index.sh b/scripts/generate-index.sh
index ceaa889..f78644b 100755
--- a/scripts/generate-index.sh
+++ b/scripts/generate-index.sh
@@ -41,6 +41,7 @@ TOPIC_MAP["vertiefung-offene-fragen"]="Vertiefung & Offene Fragen"
 TOPIC_MAP["geschichte-grundlagen-html"]="Geschichte, Grundlagen & HTML"
 TOPIC_MAP["netzwerke-protokolle-css"]="Netzwerke, Protokolle & CSS"
 TOPIC_MAP["interaktivitaet-javascript"]="Interaktivität & JavaScript"
+TOPIC_MAP["klausurfragen"]="Klausurfragen"
 
 # Configure which topics should appear disabled per course
 # Two modes: fully disabled (non-clickable card) and buttons-disabled (link remains clickable, buttons are disabled)

From d8f68183f3d56e073bb175b0e3af2d472694bb53 Mon Sep 17 00:00:00 2001
From: Michael Czechowski <mail@dailysh.it>
Date: Mon, 2 Feb 2026 13:42:11 +0100
Subject: [PATCH 6/8] update 02-bild-audio-video.md structure and content

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---
 slides/223015b/02-bild-audio-video.md | 2384 ++++++++++++++-----------
 1 file changed, 1362 insertions(+), 1022 deletions(-)

diff --git a/slides/223015b/02-bild-audio-video.md b/slides/223015b/02-bild-audio-video.md
index f132c96..0756283 100644
--- a/slides/223015b/02-bild-audio-video.md
+++ b/slides/223015b/02-bild-audio-video.md
@@ -84,886 +84,580 @@ Hochschule der Medien Stuttgart
 
 [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
 
+---
+
+![bg fit](./assets/qrcode-1.svg)
+
+---
+
+<!-- _class: lead -->
+
+# Teil 1: Einführung
+## Grundlagen, Text & Audio
+
+---
+
+<!-- _class: lead -->
+
+# Das Problem der Datengröße
+
+---
+
+# Ein konkretes Beispiel
+
+**Eine Minute Musik in CD-Qualität:**
+
+44.100 Messungen/Sekunde
+× 16 Bit pro Messung
+× 2 Kanäle (Stereo)
+× 60 Sekunden
+
+= **10,6 MB pro Minute**
+
 <!--
-- Willkommen, kurze Vorstellung
-- Heute: Teil 2 – Bilder und Video
-- Ziel: Verstehen, WARUM Formate so funktionieren, nicht nur WAS sie tun
-- Frage zum Einstieg: "Wer hat schon mal ein Bild für Instagram hochgeladen und sich gewundert, warum es danach schlechter aussieht?"
+Das ist die unkomprimierte Größe.
+Klingt erstmal nicht dramatisch.
+Aber es skaliert schnell.
 -->
 
 ---
 
-<!-- _header: '' -->
-<!-- _footer: '' -->
+# Das Problem skaliert
 
-![bg fit](./assets/qr/slides-223015b.png)
+| Inhalt | Unkomprimiert |
+|--------|-------------:|
+| 1 Song (4 Min) | ~42 MB |
+| 1 Album (60 Min) | ~635 MB |
+| 10.000 Songs | ~420 GB |
+
+**Kontext 1990er:**
+- Festplatte: 100-500 MB
+- Modem: 56 kbit/s → 1 Song dauert Stunden
 
 <!--
-- QR-Code scannen für Folien-Link
-- Folien sind CC BY-SA lizenziert – dürft ihr nutzen und teilen
+Ein Album hätte eine komplette Festplatte gefüllt.
+Musik übers Internet war praktisch unmöglich.
+Das Problem musste gelöst werden.
+-->
+
+---
+
+# Video eskaliert
+
+**Eine Minute 4K-Video (unkomprimiert):**
+
+3840 × 2160 Pixel
+× 3 Byte pro Pixel (RGB)
+× 30 Bilder pro Sekunde
+× 60 Sekunden
+
+= **~45 GB pro Minute**
+
+Ein 2-Stunden-Film: über **5 Terabyte**
+
+<!--
+Netflix, YouTube, Streaming – nichts davon wäre ohne Kompression möglich.
+Nicht einmal Blu-rays könnten existieren.
+Die physikalische Realität erzwingt Kompression.
+-->
+
+---
+
+# Kompressionsraten in der Praxis
+
+| Medium | Unkomprimiert | Komprimiert | Faktor |
+|--------|-------------:|------------:|-------:|
+| 1 Song (4 Min) | ~42 MB | ~4 MB (MP3 320) | ~10× |
+| 1 Foto (12 MP) | ~36 MB | ~3 MB (JPEG) | ~12× |
+| 1 Min 4K-Video | ~45 GB | ~375 MB (H.264) | ~120× |
+
+<!--
+Diese Faktoren sind keine Ausnahmen, sondern die Norm.
+Ohne diese Kompression wäre die digitale Medienwelt, wie wir sie kennen, nicht existent.
+Die Frage ist nicht ob, sondern wie komprimiert wird.
 -->
 
 ---
 
 <!-- _class: lead -->
 
-# Teil 2: Bild- & Videoformate
+# Zwei Philosophien der Kompression
 
 <!--
-- Drei große Blöcke heute:
-  1. Digitale Bilder (Raster vs. Vektor)
-  2. JPEG im Detail (die Magie der Kompression)
-  3. Video (warum es nochmal komplizierter ist)
-- Interaktive Demos zwischendurch
+
+Was ist überhaupt KOMPRESSION?
+
+- Luftdruck in Auto/Fahrradreifen
+- LNG Flüssiggas
+- Tripsdrill, Disneyland
+- Oper/Theater/Telenovela
+- Cola Sirup für den Sodastream
+
 -->
 
 ---
 
-# Warum verschiedene Dateiformate?
+# Verlustfreie Kompression (Lossless)
 
-**Ein Dateiformat definiert:**
-- Ob und wie Daten komprimiert werden
-- Welche Metadaten enthalten sind
-- Wie Daten *codiert* und *decodiert* werden (*Co·dec*)
+**Prinzip:** Redundanz entfernen
 
-| Ziel | Bild | Audio | Dokument |
-|------|------|-------|----------|
-| Kleine Dateien | JPEG | MP3 | — |
-| Perfekte Qualität | PNG, RAW | FLAC | PDF |
-| Animation/Video | GIF | — | — |
-| Skalierbarkeit | SVG | — | PDF |
-
-<!--
-- Kernfrage: Warum nicht EIN Format für alles?
-- Antwort: Jedes Format ist ein Kompromiss
-- Frage an Studierende: "Was wäre wichtiger – kleine Datei oder perfekte Qualität?" → Kommt drauf an!
-- Analogie: Werkzeugkasten – Hammer für Nägel, Schraubenzieher für Schrauben
--->
-
----
-
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-![bg](./assets/photo-comparison.png)
-
-<!--
-- Links: Original (hochauflösend)
-- Rechts: Stark komprimiert
-- Frage: "Wer sieht die Unterschiede?"
-- Auf Blockartefakte und Unschärfe hinweisen
-- Das ist der Preis für kleine Dateien
--->
-
----
-
-<!-- _class: lead -->
-
-# Digitale Bilder
-## Raster- und Vektorgrafiken
-
-<!--
-- Zwei fundamental verschiedene Ansätze
-- Raster: "Malen nach Zahlen" – jeder Punkt einzeln
-- Vektor: "Bauanleitung" – Formen beschreiben
--->
-
----
-
-# Was ist ein digitales Bild?
-
-Ein digitales Bild ist ein Raster aus Farbpunkten (Pixel).
-Jeder Pixel speichert einen RGB-Farbwert (3 Bytes).
-
-**Beispiel: Full HD (1920×1080)**
-= 2.073.600 Pixel × 3 Bytes = **6,2 MB**
-
-<!--
-- Pixel = Picture Element
-- RGB = Rot, Grün, Blau (je 0-255)
-- Rechenbeispiel gemeinsam durchgehen
-- Frage: "Wie viele Fotos passen auf ein 64GB Smartphone?" → ca. 10.000 unkomprimiert
-- Pointe: Ohne Kompression wäre Smartphone-Fotografie unmöglich
--->
-
----
-
-<!-- _class: klausur -->
-<!-- _header: '' -->
-<!-- _footer: '' -->
-<!-- _backgroundColor: #e3f2fd -->
-
-# 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 |
-
-<!--
-KLAUSURRELEVANT:
-- Formel: Breite × Höhe × (Farbtiefe / 8) = Bytes
-- Beispielrechnung: 1920 × 1080 × 3 = 6.220.800 Bytes ≈ 6,2 MB
-- Farbtiefe: 2^n Farben bei n Bit
-- 24 Bit = 8 Bit pro Kanal (R, G, B)
-- 32 Bit = 24 Bit + 8 Bit Alpha (Transparenz)
--->
-
----
-
-# Das Problem der Skalierung
-
-**Vergrößern:**
-Fehlende Pixel müssen erfunden werden (Interpolation)
-
-**Verkleinern:**
-Pixel müssen zusammengefasst werden
-
-**Interpolationsverfahren:**
-- Nearest Neighbor: Schnell, pixelig
-- Bilinear: Glättet, Standardverfahren
-- Bicubic: Hohe Qualität, rechenintensiv
-- Lanczos: Beste Qualität, mathematisch komplex
-
-<!--
-- Kernproblem: Rasterbilder haben EINE native Auflösung
-- Alles darüber = Schätzung, Erfindung
-- Demo-Idee: Bild in Photoshop/GIMP stark vergrößern
-- Nearest Neighbor gut für Pixel-Art (soll pixelig bleiben)
-- Frage: "Warum wird mein Profilbild manchmal unscharf?" → Plattform skaliert
--->
-
----
-
-<!-- _class: klausur -->
-<!-- _header: '' -->
-<!-- _footer: '' -->
-<!-- _backgroundColor: #e3f2fd -->
-
-# 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"/>
+**Beispiel Lauflängenkodierung:**
+```
+Original:    AAAAABBBCCCCCCCC (16 Zeichen)
+Komprimiert: 5A3B8C            (6 Zeichen)
 ```
 
-<small>SVG beschreibt WAS gezeichnet werden soll, nicht WIE jeder Pixel aussieht.</small>
+→ 62% kleiner, 100% wiederherstellbar
+
+**Anwendung:** ZIP, PNG, FLAC, Programmcode
 
 <!--
-KLAUSURRELEVANT:
-- Vektor = Beschreibung (deklarativ)
-- Raster = Pixel für Pixel (imperativ)
-- Rendering-Pipeline: Vektordaten → Rasterisierung → Display
-- Skalierung = Koordinaten multiplizieren → keine Information geht verloren
-- SVG = Scalable Vector Graphics (Web-Standard)
+Run-Length Encoding (RLE) ist die einfachste Form.
+Das Prinzip: Muster erkennen, kompakter darstellen.
+Funktioniert gut bei strukturierten Daten.
+Bei "chaotischen" Daten wie Fotos weniger effektiv.
 -->
 
 ---
 
-# Raster- und Vektorgrafiken
+# Verlustbehaftete Kompression (Lossy)
 
-| | Raster | Vektor |
+**Prinzip:** Irrelevanz entfernen
+
+**Die Frage:** Was nimmt ein Mensch nicht wahr?
+
+- Das Ohr hört nicht alle Frequenzen gleich gut
+- Das Auge sieht nicht alle Farbnuancen
+- Laute Töne überdecken leise Töne
+
+→ Warum Daten speichern, die niemand wahrnimmt?
+
+<!--
+Das ist die zentrale Idee hinter MP3, JPEG, H.264.
+Nicht die Daten selbst reduzieren – das wäre Qualitätsverlust.
+Sondern gezielt das entfernen, was Menschen nicht wahrnehmen.
+-->
+
+---
+
+<!-- _class: klausur -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+<!-- _backgroundColor: #e3f2fd -->
+
+# Verlustfrei vs. Verlustbehaftet
+
+| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
 |---|---|---|
-| **Optimal für** | Fotos, komplexe Bilder | Logos, Icons, Illustrationen |
-| **Skalierung** | Qualitätsverlust | Verlustfrei |
-| **Dateigröße** | Abhängig von Auflösung | Abhängig von Komplexität |
-| **Formate** | JPEG, PNG, WebP | SVG, PDF, AI |
-| **Bearbeitung** | Pixel-basiert | Objekt-basiert |
+| **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
 
 <!--
-- Entscheidungsregel:
-  - Foto → immer Raster
-  - Logo → immer Vektor
-  - Screenshot → meist Raster
-- Konvertierung:
-  - Vektor → Raster: trivial (Rasterisierung)
-  - Raster → Vektor: schwierig, oft unbefriedigend (Tracing)
-- Frage: "Warum verschickt euch der Grafiker das Logo als .ai oder .svg?"
+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: '' -->
+
+![bg fit](./assets/compression-types.png)
+
+<!--
+Lossless vs. Lossy Kompression
+Visualisierung der beiden Philosophien
+-->
+
+---
+
+
 <!-- _class: lead -->
 
-# Menschliche Wahrnehmung
-## Psychovisuelle Kompression
-
-<!--
-- Jetzt wird's spannend: Wie können wir 90% der Daten wegwerfen, ohne dass es auffällt?
-- Antwort: Das menschliche Auge ist kein perfekter Sensor
-- Wir nutzen seine Schwächen aus
--->
-
----
-
-<!-- _class: klausur -->
-<!-- _header: '' -->
-<!-- _footer: '' -->
-<!-- _backgroundColor: #e3f2fd -->
-
-# 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 (Helligkeit behalten)
-* Glatte Flächen effizient speichern
-* Hohe Frequenzen (feine Details) verwerfen
-
-<!--
-KLAUSURRELEVANT:
-- Mehr Stäbchen (Helligkeit) als Zapfen (Farbe) im Auge
-- "Frequenz" = räumliche Frequenz = wie schnell ändert sich Helligkeit?
-- Niedrig = langsame Änderung = große gleichmäßige Fläche
-- Hoch = schnelle Änderung = feine Details, Kanten
-- Analogie zur Psychoakustik bei MP3 (letztes Mal)
--->
+# Die Grundbausteine
+## Bits, Bytes und ihre Darstellung
 
 ---
 
 <!-- _header: '' -->
 <!-- _footer: '' -->
 
-![bg contain 50%](./assets/Felis_silvestris_silvestris_small_gradual_decrease_of_quality_-_JPEG_compression.jpg)
+![bg](./assets/lightbulb-onoff.png)
 
 <!--
-- Kompressionsvergleich am Beispiel
-- Von links nach rechts: zunehmende Kompression
-- Frage: "Ab wo seht ihr deutliche Qualitätsverluste?"
-- Zeigt: Viel Spielraum für "unsichtbare" Kompression
+Bit = Binary Digit
+Demonstration: Glühbirne AN/AUS = 1 Bit
 -->
 
 ---
 
-![bg contain right:34%](./assets/Posterization_example.jpg)
+# Das Bit
 
-# Grenzen der Kompression: JPEG-Artefakte
+**Kleinste Informationseinheit**
 
-**Bei starker Kompression sichtbar:**
-
-* **Posterization:**
-  Farbverläufe werden stufig
-
-* **Blocking:**
-  8×8-Blöcke werden sichtbar
-
-* **Ringing:**
-  "Geister" an scharfen Kanten
+- **0 oder 1**
+- AN oder AUS
+- Strom fließt oder nicht
 
 <!--
-- Artefakte = sichtbare Spuren der Kompression
-- Blocking: Benachbarte 8×8-Blöcke unabhängig komprimiert
-- Ringing: DCT hat Probleme mit harten Kanten (Gibbs-Phänomen)
-- Posterization: Zu wenig Bits für feine Farbabstufungen
-- Demo: Stark komprimiertes JPEG zoomen
+BIT = Binary Digit (Binärziffer) – 1948 von Claude Shannon geprägt
+
+"Bit war somit ein Neologismus; bis dato gab es das Wort in dieser Bedeutung überhaupt nicht"
+
+Shannon war Mathematiker bei Bell Labs – begründete die Informationstheorie
+
+Warum binär? Elektronische Schaltungen haben nur 2 Zustände: Strom/kein Strom
+Das ist physikalisch am stabilsten (weniger Fehler als 3 oder 10 Zustände)
+Alles Digitale basiert auf dieser simplen Idee: AN oder AUS
+Transistoren in modernen CPUs: Milliarden davon, schalten Milliarden Mal pro Sekunde
 -->
 
 ---
 
-# JPEG-Qualität in der Praxis
-
-| Quality | Typische Größe (12 MP) | Artefakte |
-|--------:|----------------------:|-----------|
-| 100 | 2–3 MB | Minimal |
-| 85–90 | 200–400 KB | Kaum sichtbar |
-| 60 | ~100 KB | Bei genauem Hinsehen |
-| 30 | ~50 KB | Deutlich sichtbar |
-
-**Sweet Spot: 85–90**
-~10× Kompression, für Menschen kaum unterscheidbar
+# Das Byte
 
 <!--
-- Quality 100 ≠ unkomprimiert (immer noch lossy!)
-- Für Web/Social Media: 60–80 oft ausreichend
-- Für Archivierung: 90–100 oder besser PNG/RAW
-- Faustregel: Quality 85 = guter Kompromiss
+"Ein Bit allein macht nicht glücklich, die Welt ist nunmal nicht schwarz oder weiß"
+
+"Und um noch weitere (nennen wir es Schattierungen, ganz literarisch) der Welt abbilden zu können, benötigen wir eine weiter Messgröße oder Einheit"
+
+BYTE = Wortspiel aus "Bit" + "Bite" (Bissen) – ein "Bissen" Information
+
+"Doch warum hat man nicht einfach »Bite« genommen?" Fangfrage -> Bit und Bite sind sich zu nahe ... Verwechslungsgefahr!
 -->
 
 ---
 
-<!-- _class: lead -->
+# Das Byte
 
-# JPEG-Kompression
-## Sechs Schritte im Detail
-
-<!--
-- Jetzt: Unter die Haube schauen
-- JPEG = Joint Photographic Experts Group (1992)
-- Sechs Schritte, davon einer verlustbehaftet
-- Interaktive Demo: https://claude.ai/public/artifacts/452e62f1-8525-442d-aa88-bf3795cab2c5
--->
-
----
-
-<!-- _class: klausur -->
-<!-- _header: '' -->
-<!-- _footer: '' -->
-<!-- _backgroundColor: #e3f2fd -->
-
-![bg right:20%](./assets/Barn-yuv.png)
-
-# JPEG Schritt 1: Farbraumkonversion
-
-**RGB → Y'CbCr**
-
-- **Y** = Helligkeit (Luminanz)
-- **Cb** = Blau-Gelb-Anteil (Chrominanz)
-- **Cr** = Rot-Grün-Anteil (Chrominanz)
-
-**Warum?**
-Y (Helligkeit) behält volle Auflösung
-Cb/Cr (Farbe) kann reduziert werden
-
-<!--
-KLAUSURRELEVANT:
-- YCbCr = auch 3 Werte pro Pixel, aber anders organisiert
-- Statt R-G-B: Helligkeit + 2 Farbdifferenzen
-- Umrechnung ist reversibel (mathematische Transformation)
-- Vorteil: Helligkeit und Farbe getrennt behandelbar
-- Bild zeigt: Y (oben), Cb (Mitte), Cr (unten)
--->
-
----
-
-# JPEG Schritt 2: Chroma Subsampling
-
-**Notation `J:a:b`** (bezogen auf 4×2 Pixel-Block):
-- **J** = Referenzbreite (immer 4)
-- **a** = Farbsamples in Zeile 1
-- **b** = Farbsamples in Zeile 2
-
-| Schema | Bedeutung | Farbdaten |
-|--------|-----------|-----------|
-| 4:4:4 | Volle Farbauflösung | 100% |
-| 4:2:2 | Halbe horizontale Auflösung | 50% |
-| 4:2:0 | Viertel Auflösung (2×2 teilt Farbe) | 25% |
-
-**4:2:0 ist JPEG-Standard**
-
-<!--
-- Beispiel 4:2:0: 4 Pixel teilen sich einen Farbwert, aber jeder hat eigene Helligkeit
-- Auge merkt es kaum → psychovisuelle Kompression
-- Bereits hier: 50% Datenreduktion ohne sichtbaren Verlust
-- In Video noch wichtiger (weniger Bandbreite)
--->
-
----
-
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-![bg contain 70%](./assets/Common_chroma_subsampling_ratios_YCbCr_CORRECTED.svg.png)
-
-<!--
-- Visualisierung der Subsampling-Schemata
-- Obere Reihe: Luminanz (Y) – immer voll
-- Untere Reihen: Chrominanz (Cb, Cr) – reduziert
-- 4:2:0 am häufigsten (JPEG, Video)
--->
-
----
-
-# JPEG Schritt 3: Block-Aufteilung
-
-**Das Bild wird in 8×8-Pixel-Blöcke zerlegt**
-
-Jeder Block wird unabhängig verarbeitet.
-Bei 1920×1080: 240 × 135 = **32.400 Blöcke**
-
-**Level Shift:**
-Pixelwerte um −128 verschieben
-- Vorher: 0 bis 255
-- Nachher: −128 bis +127
-
-**Warum?**
-DCT arbeitet besser mit Werten um Null
-
-<!--
-- 8×8 = historischer Kompromiss (Rechenleistung 1992)
-- Unabhängige Verarbeitung = Grund für Blocking-Artefakte
-- Level Shift: Mathematische Vorbereitung für DCT
-- Bei nicht durch 8 teilbaren Dimensionen: Padding am Rand
--->
-
----
-
-# JPEG Schritt 4: DCT (Discrete Cosine Transform)
-
-**Jeder 8×8-Block wird transformiert:**
-64 Pixelwerte → 64 Frequenzkoeffizienten
-
-**Die 64 Koeffizienten:**
-
-| Position | Name | Bedeutung |
-|----------|------|-----------|
-| (0,0) | DC | Durchschnittshelligkeit |
-| Rest | AC | Helligkeitsänderungen |
-
-**Energy Compaction:**
-90% der Information in den ersten 10–15 Koeffizienten
-DCT selbst ist **verlustfrei** und reversibel!
-
-<!--
-- DCT = Herzstück von JPEG
-- Ähnlich wie Fourier-Transformation, aber nur Cosinus
-- Sortiert Information nach "Wichtigkeit"
-- Niedrige Frequenzen (oben links) = wichtig
-- Hohe Frequenzen (unten rechts) = Details, oft verzichtbar
-- NICHT hier passiert der Verlust!
--->
-
----
-
-# JPEG Schritt 5: Quantisierung
-
-**Hier passiert der Datenverlust!**
-
-Die DCT hat sortiert – jetzt wird aufgeräumt:
-- Wichtige Werte (niedrige Frequenz) → präzise behalten
-- Unwichtige Werte (hohe Frequenz) → vergröbern oder Null setzen
-
-**Ergebnis:**
-Von 64 Werten pro Block bleiben oft nur 5–15 übrig
-Rest wird zu Nullen → extrem gut komprimierbar
-
-**Quality-Einstellung:**
-Hoch = mehr Werte behalten = größere Datei
-Niedrig = mehr Nullen = kleinere Datei, mehr Artefakte
-
-<!--
-KLAUSURRELEVANT:
-- Quantisierung = Division durch Quantisierungsmatrix + Runden
-- Einziger verlustbehafteter Schritt!
-- Quality 100 ≠ verlustfrei, nur "wenig wegwerfen"
-- Quantisierungstabellen basieren auf Wahrnehmungsforschung
--->
-
----
-
-![bg fit](./assets/quantized-image-8-colors.jpg)
-
-<!-- _header: '' -->
-<!-- _footer: 'https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-quantization' -->
-
-<!--
-- Visualisierung von Quantisierung (hier: Farbreduktion)
-- Prinzip gilt auch für DCT-Koeffizienten
-- Weniger Stufen = weniger Daten = weniger Qualität
--->
-
----
-
-# JPEG Schritt 5b: Zigzag & RLE
-
-**Nach Quantisierung:** Viele Nullen (v.a. bei hohen Frequenzen)
-
-**Zigzag-Scan:** Matrix diagonal durchlaufen
-→ Nullen sammeln sich am Ende
+**1 Byte = 8 Bits**
 
 ```
-┌────────────────┐
-│ 1  2  6  7 ... │   Niedrig → Hoch
-│ 3  5  8 ...    │   (diagonal)
-│ 4  9 ...       │
-└────────────────┘
-```
-
-**RLE (Run-Length Encoding):**
-`0 0 0 0 0 0 0 0` → `(8, 0)` = "acht Nullen"
-
-<!--
-- Zigzag: Clever – sortiert so, dass Nullen am Ende stehen
-- RLE: Klassische verlustfreie Kompression
-- Lange Nullsequenzen → sehr kurze Codes
-- Beispiel: "00000000" (8 Byte) → "(8,0)" (2 Byte)
--->
-
----
-
-<!-- _class: klausur -->
-<!-- _header: '' -->
-<!-- _footer: '' -->
-<!-- _backgroundColor: #e3f2fd -->
-
-# JPEG Schritt 6: Huffman-Coding
-
-**Verlustfreie Kompression der Restwerte**
-
-**Idee:** Variable Bitlänge statt fester 8 Bit
-Häufige Werte → kurze Codes
-
-| Zeichen | Häufigkeit | Code |
-|---------|------------|------|
-| e | 40% | `0` (1 Bit) |
-| a | 25% | `10` (2 Bit) |
-| i | 20% | `110` (3 Bit) |
-| o | 10% | `1110` (4 Bit) |
-| u | 5% | `1111` (4 Bit) |
-
-<!--
-KLAUSURRELEVANT:
-- Huffman = verlustfrei, optimal für bekannte Häufigkeiten
-- Präfix-frei: Kein Code ist Anfang eines anderen
-- Häufigstes Zeichen = kürzester Code
-- Auch in ZIP, PNG, MP3 verwendet
-
----
-
--->
-
-
-
-<!-- _class: klausur -->
-<!-- _header: '' -->
-<!-- _footer: '' -->
-<!-- _backgroundColor: #e3f2fd -->
-<!--
-# Huffman-Coding: Beispiel
-
-**Originaltext:** `ABRACADABRA` (11 Zeichen × 8 Bit = 88 Bit)
-
-**Häufigkeitsanalyse:**
-A=5, B=2, R=2, C=1, D=1
-
-**Huffman-Baum → Codes:**
-| Zeichen | Häufigkeit | Code |
-|---------|------------|------|
-| A | 5 | `0` |
-| B | 2 | `10` |
-| R | 2 | `110` |
-| C | 1 | `1110` |
-| D | 1 | `1111` |
-
-**Codiert:** `0 10 110 0 1110 0 1111 0 10 110 0` = **23 Bit**
-**Kompression:** 88 → 23 Bit = **74% gespart**
-
-
-- Beispiel Schritt für Schritt durchrechnen
-- Warum funktioniert's? A kommt 5× vor, bekommt kürzesten Code
-- Präfix-Eigenschaft: Kein Code ist Anfang eines anderen → eindeutig dekodierbar
-- Frage: "Was passiert, wenn alle Zeichen gleich häufig sind?" → Keine Ersparnis
-- In JPEG: Nicht Buchstaben, sondern DCT-Koeffizienten werden so codiert
--->
-
----
-
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-![bg](./assets/jpeg-artifacts.png)
-
-<!--
-- Zusammenfassung: Typische JPEG-Artefakte
-- Blocking: 8×8-Struktur sichtbar
-- Ringing: Geister um Kanten
-- Color Banding: Farbverläufe werden stufig
-- Alles Folgen der Quantisierung
--->
-
----
-
-<!-- _class: lead -->
-
-# Andere Bildformate
-## PNG, GIF, WebP, AVIF
-
-15:33 Uhr weiter
-
-<!--
-- JPEG ist nicht für alles geeignet
-- Jetzt: Alternativen und ihre Stärken
--->
-
----
-
-# PNG: Verlustfrei mit Transparenz
-
-**PNG = Portable Network Graphics (1996)**
-
-**Entstehung:** GIF-Patent-Streit → Community entwickelt Alternative
-
-**Features:**
-- Verlustfrei (Lossless)
-- Alpha-Transparenz (8-Bit, 256 Stufen)
-- Millionen Farben (24/48 Bit)
-- Patent-frei
-
-**Ideal für:** Grafiken, Screenshots, Text, Logos
-
-<!--
-- PNG entstand als Reaktion auf GIF-Lizenzprobleme
-- "PNG is Not GIF" (rekursives Akronym)
-- DEFLATE-Kompression (wie ZIP)
-- Keine Qualitätsverluste, aber größer als JPEG für Fotos
-- Transparenz mit 256 Stufen (nicht nur an/aus wie GIF)
--->
-
----
-
-# GIF: Der Meme-Veteran
-
-**GIF = Graphics Interchange Format (1987)**
-
-**Features:**
-- 256 Farben (8-Bit Palette)
-- Verlustfrei (innerhalb der Palette)
-- Animationen
-
-**Das Patent-Drama (1994):**
-Unisys fordert Lizenzgebühren für LZW-Kompression
-→ "Burn All GIFs!"-Kampagne
-→ PNG als Alternative
-
-**Heute:** Kulturell unsterblich (Memes, Reaktionen)
-
-<!--
-- CompuServe entwickelte GIF 1987
-- LZW = Lempel-Ziv-Welch Kompression
-- Patent lief 2004 aus, aber PNG war da längst etabliert
-- GIF überlebte wegen Animationen
-- Aussprache: "GIF" vs. "JIF" – ewiger Streit (Erfinder sagt "JIF")
--->
-
----
-
-<!-- _class: klausur -->
-<!-- _header: '' -->
-<!-- _footer: '' -->
-<!-- _backgroundColor: #e3f2fd -->
-
-# WebP & AVIF: Moderne Alternativen
-
-**WebP (Google, 2010):**
-- Lossy und Lossless
-- Transparenz und Animationen
-- 25–35% kleiner als JPEG
-
-**AVIF (2019):**
-- Basiert auf AV1-Video-Codec
-- 50% kleiner als JPEG
-- HDR-Unterstützung, patent-frei
-
-**Browser-Support 2025:** WebP universell, AVIF wächst
-
-<!--
-KLAUSURRELEVANT:
-- WebP: VP8-Kompression (Google Video-Codec)
-- AVIF: Alliance for Open Media (Google, Netflix, Amazon, Apple, Mozilla)
-- Beide besser als JPEG, aber Kompatibilität bleibt Problem
-- JPEG bleibt dominant: alte Kameras, Software, Workflows
--->
-
----
-
-# Formatwahl in der Praxis
-
-| Anwendung | Format |
-|-----------|--------|
-| Fotos fürs Web | JPEG (85), WebP |
-| Screenshots | PNG |
-| Logos, Icons | SVG, PNG |
-| Animationen | GIF, WebP, APNG |
-| Archivierung | TIFF, PNG, RAW |
-| Social Media | Was die Plattform erlaubt |
-
-<!--
-- Kompatibilität schlägt oft Effizienz
-- TIFF für Archivierung: Unkomprimiert oder verlustfrei
-- RAW für Fotografen: Maximale Bearbeitungsfreiheit
-- Frage: "Was passiert, wenn ihr ein PNG auf Instagram hochladet?"
--->
-
----
-
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-![bg](./assets/instagram-quality-loss.png)
-
-<!--
-- Vorher/Nachher: Original vs. Instagram-Upload
-- Sichtbare Qualitätsverluste
-- Warum? → Nächste Folie
--->
-
----
-
-# Warum Instagram eure Fotos "ruiniert"
-
-**Die Upload-Pipeline:**
-1. Euer Foto: 12 MP, 8 MB
-2. Instagram skaliert: max. 1080px Breite
-3. Re-Kompression: JPEG Quality ~75
-4. Ergebnis: 200–400 KB
-
-**Warum?**
-- Speicherkosten (Milliarden Fotos)
-- Ladezeiten (Mobile-First)
-- Bandbreite (günstiger für alle)
-
-<!--
-- Instagram ist keine Kunstgalerie, sondern Massenplattform
-- Optimiert für Geschwindigkeit, nicht Qualität
-- Facebook, Twitter, TikTok – alle machen das
-- Tipp für Fotografen: Portfolio auf eigener Website
-- Diskussion: Ist das fair? Trade-off Nutzer vs. Plattform
--->
-
----
-
-<!-- _class: lead -->
-
-# Video
-## Bilder + Zeit + Audio
-
-<!--
-- Jetzt wird's richtig interessant
-- Video = viele Bilder + Ton + Synchronisation
-- Das Größenproblem potenziert sich
-- Interaktive Demo: https://claude.ai/public/artifacts/fd58ac94-6b64-4d93-82be-ffb648ed9897
--->
-
----
-
-# Das Größenproblem bei Video
-
-**4K-Video (3840×2160), unkomprimiert:**
-
-3840 × 2160 × 3 Bytes = **24,8 MB pro Frame**
-
-× 30 fps = **744 MB/Sekunde**
-
-× 60 Sekunden = **44,6 GB pro Minute**
-
-**Ein 2-Stunden-Film: über 5 Terabyte**
-
-<!--
-- Rechnung gemeinsam durchgehen
-- Frage: "Wie groß ist ein Netflix-Film typischerweise?" → 3–7 GB
-- Das ist Faktor 1000 Kompression!
-- Ohne Video-Kompression: Kein Streaming, kein YouTube, keine Blu-rays
--->
-
----
-
-<!-- _class: klausur -->
-<!-- _header: '' -->
-<!-- _footer: '' -->
-<!-- _backgroundColor: #e3f2fd -->
-
-# Container und Codec
-
-**Container = Dateiformat (z.B. MP4)**
-Die "Box", die verschiedene Streams zusammenpackt:
-- Video-Stream
-- Audio-Stream(s)
-- Untertitel
-- Metadaten
-
-**Codec = Kompressionsalgorithmus (z.B. H.264)**
-Bestimmt, WIE komprimiert wird
-
-<!--
-KLAUSURRELEVANT:
-- Container ≠ Codec (häufiges Missverständnis!)
-- MP4 kann H.264, H.265 oder AV1 enthalten
-- Gleiche Endung, unterschiedlicher Inhalt
-- Tool-Tipp: MediaInfo zeigt beides an
--->
-
----
-
-# Gängige Container
-
-| Container | Verwendung |
-|-----------|------------|
-| **MP4** (.mp4) | Web, Streaming, universell |
-| **MKV** (.mkv) | Archiv, viele Streams, offen |
-| **MOV** (.mov) | Apple-Ökosystem |
-| **WebM** (.webm) | Web, nur VP9/AV1 + Opus |
-| **AVI** (.avi) | Legacy, veraltet |
-
-<!--
-- MP4 = MPEG-4 Part 14, ISO-Standard
-- MKV = Matroska (russische Matrjoschka-Puppen)
-- WebM = Subset von Matroska für HTML5
-- MKV beliebt für Filme mit mehreren Sprachen
-- AVI: Bitte nicht mehr verwenden
--->
-
----
-
-# Video-Codecs im Überblick
-
-| Codec | Jahr | Status |
-|-------|------|--------|
-| **H.264/AVC** | 2003 | Universal, überall |
-| **H.265/HEVC** | 2013 | Effizienter, Patent-Chaos |
-| **VP9** | 2013 | YouTube, patent-frei |
-| **AV1** | 2018 | Zukunft, patent-frei |
-
-<!--
-- H.264: De-facto-Standard seit 20 Jahren, Hardware-Decoder überall
-- H.265: 50% besser, aber drei konkurrierende Patent-Pools
-- VP9: Google kaufte On2 Technologies, forciert über YouTube
-- AV1: Alliance for Open Media – die Tech-Giganten vereint
--->
-
----
-
-# Container + Codec = Video
-
-```
-┌─────────────────────────────┐
-│  Container (z.B. MP4)       │
-│  ┌────────────────────────┐ │
-│  │ Video-Stream (H.264)   │ │
-│  ├────────────────────────┤ │
-│  │ Audio-Stream (AAC)     │ │
-│  ├────────────────────────┤ │
-│  │ Untertitel (SRT)       │ │
-│  ├────────────────────────┤ │
-│  │ Metadaten              │ │
-│  └────────────────────────┘ │
-└─────────────────────────────┘
+0 1 0 0 1 1 0 1
 ```
 
 <!--
-- Container = Verpackung
-- Codec = wie der Inhalt komprimiert ist
-- Ein MP4 mit H.264 und ein MP4 mit H.265 haben dieselbe Endung
-- Wichtig für Kompatibilität: Player muss Codec unterstützen
+
+Rätsel: "Wenn sich das Wachstum einer Seerose auf einem Teich jeden Tag verdoppelt · und nach *zehn Tagen* der ganze Teich bedeckt ist, wann ist er zur Hälfte zugewachsen?"
+
+Frage: "Weiß jemand wieviele Zustände wir mit 8 Bit beschreiben können?"
+
+-->
+
+---
+
+# Das Byte
+
+**1 Byte = 8 Bits**
+
+```
+0 1 0 0 1 1 0 1
+```
+
+2⁸ = **256 Möglichkeiten** (0-255)
+
+<!--
+
+Historie: "Es gab durchaus einen »Machtkampf« und es war überhaupt nicht klar welche Länge sich durchsetzen wird."
+
+- 1964: IBM System/360 setzte diesen Standard (vorher: 6-Bit, 7-Bit Systeme)
+- ASCII (1963) brauchte 7 Bit für 128 Zeichen
+
+ASCII = American Standard Code for Information Interchange
+
+Praktikabilität:
+- 8 Bit = praktisch für Hardware (Zweierpotenz: 2³ = 8)
+- 8 Bit = 2 Hexadezimalziffern (elegante Darstellung)
+
+1 Bit = 2 Zustände
+2 Bit = 4 Zustände
+3 Bit = 8 Zustände
+4 Bit = 16 Zustände
+5 Bit = 32 Zustände
+6 Bit = 64 Zustände
+7 Bit = 128 Zustände
+8 Bit = 256 Zustände
+
+Rechnung: 2·2·2·2·2·2·2·2 = 256 mögliche Kombinationen
+
+von griech. hexa „sechs" und lat. decem „zehn"
+
+Eselsbrücke: 1 Byte = 1 Buchstabe/Symbol (in ASCII/UTF-8 für einfache Zeichen)
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+»256 Shades of Gray«
+
+![bg fit](./assets/grayscale-gradient.png)
+
+<!--
+
+»256 Shades of Gray«
+
+256 Graustufen: 0 = Schwarz, 255 = Weiß
+-->
+
+---
+
+# Was kann man mit 256 Zuständen machen?
+
+* **256 Zeichen** (Buchstaben, Zahlen, Symbole)
+* **256 Helligkeit bzw. Luminanz** (0 = Schwarz/Dunkel, 255 = Weiß/Hell)
+* **256 Lautstärkestufen**
+* **Zahlen 0-255** (oder -128 bis +127)
+
+<!--
+256 = die "magische Zahl" bei 8 Bit
+Alltagsbeispiele:
+- Lautstärkeregler (0 = stumm, 255 = max)
+- Helligkeitswerte in Bildern (0 = schwarz, 255 = weiß)
+- Alter in Jahren (0-255 reicht für Menschen locker)
+- Zeichen (ASCII erweitert: 256 Buchstaben/Symbole)
+Für Farbbilder: 3 Bytes pro Pixel (R, G, B)
+Jeder Kanal 0-255 → 256³ = 16.777.216 Farben ("True Color")
+Das menschliche Auge kann etwa 10 Millionen Farben unterscheiden
+→ 24 Bit reicht für fotorealistische Bilder
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/rgb-color-model.png)
+
+<!--
+Welche Farben für ein volles Spektrum bieten sich nach unserer gelernten Sparsamkeit hier am besten an?
+
+1. CMYK bzw. in diesem Fall CMYW
+2. RGB
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/rgb-color-model-with-title.png)
+
+<!--
+RGB = Additive Farbmischung (Bildschirme)
+
+Sog. RGB Tuple (geordnete endliche Liste)
+-->
+
+---
+
+![bg right:50%](./assets/addaptive-substractive-colors.jpg)
+
+# Farben: RGB-Modell
+
+**1 Pixel = 3 Bytes**
+
+- **Rot:** 0-255
+- **Grün:** 0-255
+- **Blau:** 0-255
+
+**Beispiele:**
+`FF 00 00` = Rot
+`00 FF 00` = Grün
+`00 00 FF` = Blau
+`00 00 00` = Schwarz
+`FF FF FF` = Weiß
+
+<!--
+"Weiß jemand oder möchte jemand raten, wofür das "s" bei "sRGB" steht?"
+
+sRGB = Standard RGB
+CMYK = Subtraktive Farbmischung (Druck)
+Hex-Notation: FF = 255 in Dezimal
+CSS-Farben nutzen Hex: #FF0000 = Rot
+Wer HTML/CSS gemacht hat, kennt das schon!
+background-color: #FF0000; = Rot
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/hex-dec-lookup-table.png)
+
+---
+
+# Das Problem: Sprachen
+
+**Die Welt hat mehr als 256 Zeichen!**
+
+- Englisches Alphabet: 52 (A-Z, a-z)
+- + Ziffern: 10 (0-9)
+- + Sonderzeichen: ~30
+
+**≈ 90 Zeichen → passt in 1 Byte**
+
+**Aber:** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 😀
+
+→ **1 Byte reicht nicht!**
+
+<!--
+Problem der Zeichenkodierung
+ASCII (1963): 7 Bit = 128 Zeichen (nur Englisch)
+ISO-8859-1 (Latin-1): 8 Bit = 256 Zeichen (Westeuropa)
+Chaos: Verschiedene Standards für verschiedene Sprachen
+-->
+
+---
+
+# Unicode: Ein Standard für alle (8 Bit)
+
+**Unicode (1991):** Jedes Schriftsystem der Welt
+
+**>150.000 Zeichen:**
+- Latein, Kyrillisch, Arabisch, Chinesisch, Japanisch...
+- Mathematische Symbole, Emoji, historische Schriften
+
+**UTF-8:** Variable Länge (1-4 Bytes pro Zeichen)
+- **Zeichen 0-127: identisch mit ASCII** (Abwärtskompatibilität!)
+- 1.112.064 gültige Zeichen
+- Umlaute: 2 Bytes · CJK: 3 Bytes · Emoji: 4 Bytes
+
+<!--
+Unicode Consortium: Non-Profit seit 1991
+Aktuell: Unicode 16.0 (2024)
+UTF-8 = Unicode Transformation Format, 8-bit
+
+WICHTIG für Kontext zur ASCII-Folie:
+- Die ersten 128 Zeichen in UTF-8 sind EXAKT ASCII
+- Deshalb funktioniert alter ASCII-Code noch heute
+- UTF-8 ist der Grund, warum ASCII nie verschwinden wird
+- "A" in ASCII = "A" in UTF-8 = 0x41 = 65 dezimal
+
+Byte-Längen:
+- ASCII-Zeichen (0-127): 1 Byte
+- Umlaute, diakritische Zeichen: 2 Bytes
+- Chinesisch, Japanisch, Koreanisch: 3 Bytes
+- Emoji, seltene Zeichen: 4 Bytes
+-->
+
+---
+
+# Beispiel: Bytes zählen
+
+**Text:** `"Hello·🌸·こんにちは·(Kon-ni-chi-wa)"`
+
+| Zeichen | Bytes |
+|---------|-------|
+| `Hello·` | 6 × 1 = **6 Bytes** (ASCII) |
+| `🌸` | **4 Bytes** (Emoji) |
+| `·` | **1 Byte** |
+| `こんにちは` | 5 × 3 = **15 Bytes** (Hiragana) |
+| `·(Kon-ni-chi-wa)` | **16 Bytes** (ASCII) |
+
+**Gesamt: 42 Bytes** für 29 sichtbare Zeichen
+
+<!--
+ASCII (Hello, Klammern) = 1 Byte pro Zeichen
+Emoji 🌸 (Cherry Blossom U+1F338) = 4 Bytes
+Hiragana こんにちは = 3 Bytes pro Zeichen (U+3040-309F)
+Hinweis: は wird hier "wa" ausgesprochen (Partikel), nicht "ha"
 -->
 
 ---
 
 <!-- _class: lead -->
 
-# Video-Kompression
-## Raum und Zeit nutzen
+# Hexadezimal
+## Die Sprache der Datei-Analyse
+
+---
+
+# Hexadezimal: Lesbarkeit
+
+**Binär ist unleserlich:**
+`01010000 01001110 01000111`
+
+**Hexadezimal (Base 16):**
+`50 4E 47` (= "PNG" in ASCII)
+
+**Jede Hex-Ziffer = 4 Bits (ein "Nibble")**
+0-9, A-F (10=A, 11=B, ..., 15=F)
+
+**ASCII Tabelle (0-127):**
+[https://www.asciitable.com](https://www.asciitable.com)
 
 <!--
-- Video hat zwei Dimensionen der Redundanz:
-  1. Räumlich (innerhalb eines Frames) – wie bei JPEG
-  2. Zeitlich (zwischen Frames) – neu!
-- Die zeitliche Redundanz ist der Schlüssel
+
+"Gerne vorab auf den Link gehen"
+
+WICHTIG: ASCII geht nur von 0-127!
+- Werte 128-255 sind NICHT in der ASCII-Tabelle
+- Das wird später bei Magic Numbers wichtig
+
+Warum Hexadezimal statt Dezimal?
+- Binär ist zu lang: 01001101 (8 Zeichen für 1 Byte)
+- Dezimal passt nicht: 77 (unregelmäßig, manchmal 2, manchmal 3 Ziffern)
+- Hex ist perfekt: 4D (immer 2 Ziffern pro Byte)
+
+Trick: 4 Bits = 1 Hex-Ziffer (weil 2⁴ = 16)
+0000 = 0, 0001 = 1, ..., 1001 = 9, 1010 = A, 1011 = B, ..., 1111 = F
+
+"Nibble" = 4 Bits = halbes Byte (Wortspiel: nibble = knabbern, byte = beißen)
+
+Umrechnung üben:
+- 0x4D = 4×16 + 13 = 64 + 13 = 77 (Dezimal) = Buchstabe "M" in ASCII
+- 0xFF = 15×16 + 15 = 255 (Maximum für 1 Byte)
+
+Hex-Editor = Standard-Tool für Dateianalyse und Reverse Engineering
+
+-->
+
+---
+
+
+
+<!-- _class: lead -->
+
+# ASCII
+## One *Zeichensatz* to rule them all
+
+<!--
+WARUM 7 BIT STATT 8?
+- 1963: Fernschreiber (Teletype) arbeiteten mit 7-Bit-Codes
+- Das 8. Bit diente der Paritätsprüfung (Fehlererkennung bei Übertragung)
+- Speicher war kostspielig: jedes eingesparte Bit zählte
+- 128 Zeichen galten als ausreichend für den englischsprachigen Raum
+
+KULTURHISTORISCHER KONTEXT:
+- "American Standard Code for Information Interchange" (1963)
+- Entwickelt für US-amerikanische Bedürfnisse
+- Keine Unterstützung für: Umlaute (ä, ö, ü), ß, diakritische Zeichen (é, ñ, ç)
+- Nicht-lateinische Schriftsysteme (Kyrillisch, Arabisch, CJK) wurden nicht berücksichtigt
+- Führte zu zahlreichen inkompatiblen Erweiterungen (ISO-8859-1, Windows-1252, etc.)
+
+WARUM NOCH HEUTE RELEVANT?
+- Abwärtskompatibilität: UTF-8 ist vollständig ASCII-kompatibel (Zeichen 0-127 identisch)
+- Internetprotokolle basieren auf ASCII: HTTP-Header, SMTP, URLs
+- Programmiersprachen: Schlüsselwörter und Syntax sind ASCII
+- Ein 60 Jahre alter Standard, der durch Kompatibilitätszwänge fortbesteht
+
+HISTORISCHE RANDNOTIZ:
+- Das @-Zeichen wurde nachträglich aufgenommen
+- Heute unverzichtbar für E-Mail-Adressen weltweit
 -->
 
 ---
@@ -971,104 +665,98 @@ KLAUSURRELEVANT:
 <!-- _header: '' -->
 <!-- _footer: '' -->
 
-![bg fit](./assets/ipb-compression-canon.jpg)
+
+![bg fit](./assets/ascii-table-colored.png)
 
 <!--
-- Visualisierung: I/P/B-Frame-Abhängigkeiten
-- I-Frame = Vollbild (Keyframe)
-- P-Frame = Vorwärts-Referenz
-- B-Frame = Bidirektionale Referenz
-- Mehr dazu auf den nächsten Folien
+
+Vorgeschichte:
+
+US-ASCII (1967) Code Chart
+- 7 Bit = 128 Zeichen
+- Erste 32: Steuerzeichen (nicht druckbar)
+- Zeichen 32-126: Druckbar (Buchstaben, Ziffern, Satzzeichen)
+- Keine Umlaute, kein ñ, kein é
+- "American Standard" → Rest der Welt ausgeschlossen
+
+"Ich möchte, dass ihr das mit mir jetzt gemeinsam lesen lernt; stellt euch vor ihr seid ArchäologInnen."
+
+"Wie würdet ihr vorgehen?"
+
 -->
 
 ---
 
-# Drei Kompressionsprinzipien
+![bg right:40%](./assets/matrix-code.png)
 
-**1. Spatial Compression (Intra-Frame)**
-Jedes Bild einzeln komprimieren (wie JPEG)
+# WTF!?
 
-**2. Temporal Compression (Inter-Frame)**
-Nur Änderungen zwischen Bildern speichern
+```
+89 50 4E 47 0D 0A 1A 0A
+00 00 00 0D 49 48 44 52
+00 00 01 90 00 00 01 2C
+```
 
-**3. Motion Compensation**
-Bewegung beschreiben statt Pixel kopieren
+---
+
+![bg right:30%](./assets/matrix-code.png)
+
+# What the HEX-Code
+
+```
+89 50 4E 47 ...
+```
+
+| Binär | Hex | Dez | ASCII |
+|-------|-----|-----|-------|
+| `1000 1001` | `89` | 137 | ✗ (> 127) |
+| `0101 0000` | `50` | 80 | **P** |
+| `0100 1110` | `4E` | 78 | **N** |
+| `0100 0111` | `47` | 71 | **G** |
+
+→ **PNG**-Signatur! (Das `89` markiert: "Ich bin binär, kein Text!")
 
 <!--
-- Spatial = räumlich, innerhalb eines Bildes
-- Temporal = zeitlich, zwischen Bildern
-- Motion Compensation = Bewegungsvektoren
-- 90% eines Frames oft identisch mit dem vorherigen!
-- Kernidee: Warum zweimal speichern, was sich nicht ändert?
+Hex = 2 Ziffern = 1 Byte = 8 Bit
+89 hex = 8×16 + 9 = 137 dezimal
+ASCII geht nur bis 127, also nicht druckbar
+50, 4E, 47 = P, N, G in ASCII
 -->
 
 ---
 
-# Spatial Compression (Intra-Frame)
+<!-- _header: '' -->
+<!-- _footer: '' -->
+<!-- _backgroundColor: #000 -->
 
-**Jedes Bild einzeln komprimieren – wie JPEG**
-
-Analysiert Redundanz *innerhalb* eines Frames:
-- DCT (Frequenzanalyse)
-- Quantisierung
-- Entropie-Coding
-
-**→ I-Frame (Keyframe)**
-Vollständiges Bild, unabhängig dekodierbar
+![bg fit](./assets/hex-code-hidden.png)
 
 <!--
-- I = Intra = innerhalb
-- I-Frames sind groß, aber wichtig für:
-  - Seeking (Springen im Video)
-  - Fehlerkorrektur
-  - Schnitt
-- Typisch alle 1–2 Sekunden ein I-Frame
+
+"Zurück zu Frage am Anfang: Was steht hier nun?"
+
+"Versucht es kurz selbst zu entschlüsseln"
+
 -->
 
 ---
 
-# Temporal Compression (Inter-Frame)
+<!-- _header: '' -->
+<!-- _footer: '' -->
+<!-- _backgroundColor: #000 -->
 
-**Nur Änderungen zwischen Bildern speichern**
-
-| Frame-Typ | Referenziert | Typische Größe |
-|-----------|--------------|----------------|
-| **I-Frame** | Nichts (Keyframe) | 100% |
-| **P-Frame** | Vorherige Frames | ~30% |
-| **B-Frame** | Vorherige + zukünftige | ~15% |
-
-**GOP (Group of Pictures):**
-I - B - B - P - B - B - P - B - B - I
+![bg fit](./assets/hex-code.png)
 
 <!--
-KLAUSURRELEVANT:
-- I = Intra (vollständig)
-- P = Predicted (vorhergesagt aus Vergangenheit)
-- B = Bi-directional (Vergangenheit + Zukunft)
-- B-Frames sind am kleinsten, aber brauchen mehr Rechenleistung
-- GOP-Länge beeinflusst Seeking-Geschwindigkeit
--->
-
----
-
-# Motion Compensation
-
-**Bewegung beschreiben statt Pixel kopieren**
-
-**Beispiel:** Ein 16×16 Pixel-Block
-
-Frame 1: Block an Position (100, 200)
-Frame 2: Block an Position (120, 200)
-
-**Statt Block zweimal speichern:**
-→ Motion Vector: "verschiebe um (+20, 0)"
-
-<!--
-- Macroblocks: Typisch 16×16 oder variable Größen
-- Motion Vectors beschreiben Verschiebung
-- Funktioniert gut bei: Kameraschwenks, bewegte Objekte
-- Funktioniert schlecht bei: Szenenwechsel, Konfetti, Feuerwerk
-- Demo: Video Frame für Frame durchgehen
+Hex-Editor-Screenshot mit PNG-Datei
+Erste Bytes: 89 50 4E 47 = PNG-Signatur
+- 89: non-printable character (signalisiert, dass wir hier außerhalb von ASCII sind)
+- 50: P
+- 4E: N
+- 47: G
+IHDR = Image Header (Breite, Höhe, Farbtiefe)
+Zeigen, wie man Magic Number liest
+Tool: HxD (Windows), Hex Fiend (Mac), xxd (Linux)
 -->
 
 ---
@@ -1076,13 +764,45 @@ Frame 2: Block an Position (120, 200)
 <!-- _header: '' -->
 <!-- _footer: '' -->
 
-![bg fit](./assets/ipb-compression-canon.jpg)
+![bg fit](./assets/8bit-P-character.png)
+
+---
+
+# Magic Numbers
+
+**Dateityp-Identifikation durch erste Bytes**
+
+| Format | Magic Number (Hex) | Lesbar? |
+|--------|-------------------|---------|
+| PNG | `89 50 4E 47` | ✗ P N G |
+| JPEG | `FF D8 FF` | ✗ ✗ ✗ |
+| PDF | `25 50 44 46` | % P D F ✓ |
+| ZIP | `50 4B 03 04` | P K ✗ ✗ |
+
+**Wichtig:** ASCII = nur 0-127! Werte darüber (z.B. `89` = 137) sind **nicht druckbar** (non-printable). *Hex-Editoren zeigen dafür `.` oder `ÿ` als Platzhalter.*
 
 <!--
-- Nochmal das Bild mit dem neuen Wissen betrachten
-- Pfeile zeigen Abhängigkeiten
-- B-Frames referenzieren in beide Richtungen
-- Frage: "Was passiert, wenn ein I-Frame beschädigt ist?"
+"Warum findet ihr 89 nicht in der ASCII-Tabelle?"
+
+KERNKONZEPT:
+- 1 Byte = 256 Werte (0-255)
+- ASCII deckt nur 0-127 ab (die "druckbaren" Zeichen)
+- 128-255 = Binärdaten, Steuerzeichen, erweiterte Zeichen
+
+WARUM nutzt PNG absichtlich 89 (= 137 dezimal)?
+1. Markiert die Datei eindeutig als BINÄR, nicht Text
+2. Erkennt kaputte Übertragungen (alte Systeme schnitten Bit 7 ab)
+3. Verhindert versehentliches Öffnen als Textdatei
+
+Geschichte: "PK" bei ZIP = Phil Katz (Erfinder von PKZip, 1989)
+Fun Fact: DOCX, XLSX, PPTX, ODT = alles ZIP-Archive mit XML-Inhalt!
+
+Dateien OHNE Magic Number: TXT, HTML, CSS, JSON, XML
+→ Reiner Text, kein binäres Format
+
+Sicherheits-Aspekt:
+virus.exe → bild.jpg umbenennen täuscht nur Menschen
+Windows vertraut der Endung, aber "file" (Linux) liest Magic Number
 -->
 
 ---
@@ -1092,144 +812,776 @@ Frame 2: Block an Position (120, 200)
 <!-- _footer: '' -->
 <!-- _backgroundColor: #e3f2fd -->
 
-# H.264 / AVC
+# Dateneinheiten
 
-**Advanced Video Coding (2003)**
-
-**Warum dominant?**
-- Exzellente Kompression (~100:1 möglich)
-- Hardware-Decoder in jedem Gerät seit ~2010
-- YouTube, Netflix, Blu-ray – alles H.264
-
-**Features:**
-- Variable Block-Größen (16×16 bis 4×4)
-- Deblocking-Filter (reduziert Artefakte)
+| 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 |
 
 <!--
-KLAUSURRELEVANT:
-- H.264 revolutionierte Video-Streaming
-- Ohne H.264 kein Netflix, kein YouTube HD
-- Hardware-Decoder = kein CPU-Aufwand, kein Akku-Drain
-- Selbst billigste Smartphones können H.264 abspielen
+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"
 -->
 
 ---
 
-# Das Patent-Problem
+# Datenwachstum der Menschheit
 
-**H.264 ist nicht frei**
+| Jahr | Datenmenge | Kontext |
+|------|------------|---------|
+| **100.000 v. Chr.** | 0 | Erste Menschen, nur Sprache |
+| **3.000 v. Chr.** | ~wenige KB | Keilschrift, Hieroglyphen |
+| **1450** | ~wenige GB | Gutenberg, Buchdruck |
+| **1986** | **2,6 EB** | 99% analog (Bücher, Vinyl, VHS) |
+| **2007** | **295 EB** | 94% digital |
+| **2025** | **181 ZB** | 90% unstrukturiert |
 
-**MPEG-LA (Patent Pool):**
-- 2.000+ Patente von ~30 Unternehmen
-- Apple, Microsoft, Sony, Panasonic...
+<!--
+Exponentielles Wachstum: Verdopplung alle 2 Jahre
+1986: Letzte Ära mit analoger Dominanz
+2007: Erste Jahr, in dem digital > analog
+2025: 181 ZB = 181.000.000.000.000.000.000.000 Bytes
+Analog blieb bei ~2,6 EB stehen (Bücher, Vinyl, Film)
+Digital explodierte: IoT, Social Media, Cloud, Video
+-->
+
+---
+
+<!-- _class: klausur -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+<!-- _backgroundColor: #e3f2fd -->
+
+# 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: '' -->
+
+
+![bg fit](./assets/2011-hilbert.png)
+
+
+---
+
+# 181 Zettabyte – Was bedeutet das?
+
+**2025:** Welt erzeugt **181 ZB** pro Jahr
+
+- **2,5 Quintillionen Bytes** täglich
+- **29 Terabyte** pro Sekunde
+- **90%** davon: unstrukturiert (Videos, Bilder, Audio)
+- **70%** davon: von NutzerInnen generiert
+
+**Zum Vergleich:**
+- 1 ZB = 250 Milliarden DVDs
+- 181 ZB = Jeder Mensch erzeugt ~23 TB/Jahr
+
+<!--
+Quellen: IDC Global DataSphere Forecast, Statista 2025
+IoT-Geräte allein: 73 ZB in 2025
+Cloud-Speicher: 100 ZB (50% der Weltdaten)
+Prognose 2028: 394 ZB
+-->
+
+---
+
+
+<!-- _header: '' -->
+<!-- _footer: 'Floridi, L.: The forth Revolution' -->
+
+
+![bg fit](./assets/growth of big data.png)
+
+---
+
+# AI-generierte Inhalte 2025
+
+**Wie viel Content ist heute synthetisch?**
+
+| Bereich | AI-Anteil |
+|---------|-----------|
+| **Neue Webseiten** | ~74% enthalten AI-Content |
+| **Web-Text gesamt** | ~30-40% AI-generiert |
+| **Neue Artikel** | ~52% von AI geschrieben |
+| **Social-Media-Bilder** | ~71% AI-generiert |
+
+**Prognose 2026:** 90% des Online-Contents synthetisch
+
+<!--
+Quellen: Ahrefs 2025, arXiv, Europol-Report
+"Synthetic Media" = AI-generiert oder -manipuliert
+Problem: Schwer zu messen, da Menschen + AI zusammenarbeiten
+Model Collapse: AI trainiert auf AI-Output → Qualitätsverlust
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Teil 2: Die MP3-Revolution
+## Psychoakustik & Audio-Kompression
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg](./assets/cassette-ipod.png)
+
+<!--
+Kassette neben iPod
+Visueller Kontrast: Analog vs. Digital
+1980er vs. 2000er
+-->
+
+---
+
+<!-- _class: klausur -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+<!-- _backgroundColor: #e3f2fd -->
+
+# 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
+
+---
+
+# Analoge Medien: Vor- und Nachteile
+
+| Vorteile | Nachteile |
+|----------|-----------|
+| Kein Abspielgerät nötig (Buch, Foto) | Qualitätsverlust bei jeder Kopie |
+| Haptisches Erlebnis | Physischer Verschleiß |
+| Unabhängig von Strom/Internet | Begrenzte Haltbarkeit |
+| Keine Formatkonvertierung | Platzbedarf bei Lagerung |
+| Eindeutiges Original | Aufwendige Durchsuchbarkeit |
+
+<!--
+GENERATIONSVERLUST:
+Kassette → Kassette = jede Kopie schlechter
+VHS → VHS = Rauschen nimmt zu
+Schallplatte: Jedes Abspielen = minimaler Verschleiß
+
+ABER: Analoges Original bleibt "das Original"
+Digitale Kopie = identisch mit Original (kein Unterschied!)
+-->
+
+---
+
+# Von Analog zu Digital: Die Kopier-Revolution
+
+**Das Problem analoger Kopien:**
+Kassette → Kassette → Kassette = immer schlechter
+
+**Was Digital anders macht:**
+- **Identische Kopien** – kein Qualitätsverlust, nie
+- **Einfache Massenproduktion** – Copy & Paste
+- **Perfekte Archivierung** – Bits verändern sich nicht
+
+**Daher: "Raubkopien"**
+Der Begriff entstand, weil digitale Kopien *tatsächlich identisch* mit dem Original waren – nicht wie bei Kassetten eine schlechtere Version.
+
+<small>Quelle: [c64-wiki.de/wiki/Raubkopie](https://www.c64-wiki.de/wiki/Raubkopie)</small>
+
+<!--
+RAUBKOPIE: Begriff aus der Musikindustrie
+Analog: Kopie war immer erkennbar schlechter
+Digital: Kopie = Original (bit-identisch)
+Das machte der Industrie Angst → "Raub"
+
+Paradox: Gerade die Perfektion wurde zum "Problem"
+-->
+
+---
+
+<!-- _class: klausur -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+<!-- _backgroundColor: #e3f2fd -->
+
+# 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)
+
+---
+
+<!-- _class: klausur -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+<!-- _backgroundColor: #e3f2fd -->
+
+# 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
+
+---
+
+# Das Speicherproblem der Digitalisierung
+
+
+**Ziel: Analoge Schallwelle möglichst originalgetreu rekonstruieren**
+
+*CD-Qualität (1982): 44.100 Hz × 16 Bit × 2 Kanäle = 10,584 MB/Minute*
+
+<!-- 44100 Hz ×16 Bit × 2 ÷ 8 ÷ 1000 ÷ 1000 × 60 = 10,584 MB/Minute -->
+
+| Inhalt | Größe | Problem (1990er) |
+|--------|-------|------------------|
+| 1 Song (4 Min) | ~42 MB | Ausreichend Speicher |
+| 1 Album (60 Min) | ~635 MB | Gesamte Festplatte |
+
+
+<!--
+"Springen wir nochmal zurück in die 90er, bevor das Internet den Globus umspann ..."
+
+CD-QUALITÄT ERKLÄRT:
+ZIEL: Die analoge Schallwelle möglichst originalgetreu digital rekonstruieren.
+Dafür brauchen wir genug "Messpunkte" (Samples) und genug Genauigkeit (Bits).
+
+- 44.100 Hz = Sample Rate (Abtastrate)
+  → 44.100 Messungen pro Sekunde
+  → Nyquist-Theorem: 2× höchste hörbare Frequenz (22 kHz)
+- 16 Bit = Bit Depth (Auflösung pro Sample)
+  → 65.536 mögliche Lautstärkestufen
+  → Dynamikumfang: ~96 dB
+- 2 Kanäle = Stereo (links + rechts)
+
+RECHNUNG:
+44.100 × 16 × 2 = 1.411.200 Bit/Sekunde
+= 176.400 Byte/Sekunde = ~172 KB/s
+= ~10,3 MB/Minute (gerundet 10,6 MB)
+
+DAS PROBLEM:
+- CD = unkomprimiert, riesig
+- Festplatten 1990: 100-500 MB
+- Internet 1995: 56k Modem = 1 Song = Stunden
+- Streaming? Unmöglich
+
+LÖSUNG: Kompression (MP3, 1993)
+-->
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg cover](./assets/spectogram-chet-baker.png)
+
+<!--
+
+"Wenn CDs eine Sample Rate von 44kHz haben, was fällt dann hier auf?"
+
+Fangfrage: "Wie hoch ist die Sample Rate von Vinyls?" -> *Vinyl has no sample rate. It's analog!*
+
+-->
+
+---
+
+# Die Abtastrate (Sample Rate)
+**Analog → Digital ≙ Kontinuierlich → Diskret**
+```
+      Analog (Vinyl):          Digital (CD):
+      ~~~~~~~~~~~~~~~          • • • • • • • •
+      Kontinuierliche          44.100 Messpunkte
+      Wellenform               pro Sekunde
+```
+**Nyquist-Theorem:**
+
+> Um eine Frequenz zu rekonstruieren, braucht man mindestens **2× so viele Samples**.
+44.100 Hz ÷ 2 = **22.050 Hz** max. darstellbare Frequenz
+(Mensch hört: ~20 Hz bis ~20.000 Hz → passt!)
+
+<!--
+ABTASTRATE (Sample Rate) = Wie oft "fotografieren" wir die Schallwelle?
+Stellt euch vor: Schallwelle = fahrendes Auto
+- Analog: Videokamera läuft durchgehend
+- Digital: Fotokamera macht 44.100 Fotos pro Sekunde
+
+VINYL hat KEINE Sample Rate:
+- Rille ist physische Kopie der Welle
+- "Unendliche Auflösung" in der Theorie
+- ABER: Rauschen, Kratzer, Nadelmasse = eigene Limits
+- Praktisch: ~20 Hz bis ~20 kHz, 60-70 dB Dynamik
+
+WARUM genau 44.100 Hz?
+- Nyquist: 2× höchste hörbare Frequenz nötig
+- 20.000 Hz × 2 = 40.000 Hz Minimum
+- 44.100 = etwas Puffer + passte zu Video-Equipment der 80er
+
+DAS SPEKTROGRAMM zeigt es:
+- Alles über ~22 kHz ist abgeschnitten
+- Das ist kein Bug, das ist das Design!
+- Vinyl hätte dort noch Obertöne (die wir eh nicht hören)
+-->
+
+---
+
+# Die Bittiefe (Bit Depth)
+
+**Wie genau messen wir jeden Punkt?**
+
+| Bittiefe | Stufen | Dynamikumfang |
+|----------|--------|---------------|
+| 8 Bit | 256 | ~48 dB |
+| 16 Bit (CD) | 65.536 | ~96 dB |
+| 24 Bit (Studio) | 16.777.216 | ~144 dB |
+
+**16 Bit = 2¹⁶ = 65.536 Lautstärkestufen**
+(von absoluter Stille bis maximaler Lautstärke)
+
+<!--
+BITTIEFE = Wie genau messen wir jeden einzelnen Punkt?
+- Mehr Bits = feinere Abstufungen
+- 16 Bit reicht für menschliches Hören (96 dB Dynamik)
+- 24 Bit im Studio: mehr Headroom für Bearbeitung
+-->
+
+---
+
+# Abtastrate (Sample Rate) × Bittiefe (Bit Depth)
+
+**Zwei Dimensionen der Digitalisierung:**
+
+| Dimension | Was bedeutet es? | CD-Qualität |
+|-----------|------------------|-------------|
+| **Abtastrate** (Sample Rate) | Messungen pro Sekunde (horizontal) | 44.100 Hz |
+| **Bittiefe** (Bit Depth) | Genauigkeit pro Messung (vertikal) | 16 Bit |
+
+**44.100 Hz × 16 Bit** × 2 Kanäle = 10,584 MB/Minute
+
+<!--
+Analogie: Digitalisierung = Raster über Schallwelle legen
+HORIZONTAL (Abtastrate): Welche FREQUENZEN wir erfassen können
+VERTIKAL (Bittiefe): DYNAMIKUMFANG (leise bis laut)
+-->
+
+---
+
+<!-- _class: lead -->
+
+# Kompression
+## Weniger Daten, gleiche(?) Information
+
+---
+
+# Wo liegt der Hebel für Kompression?
+
+**CD-Qualität:** 44.100 Hz × 16 Bit × 2 Kanäle = **10,6 MB/Min**
+**MP3 (128 kbps):** = **~1 MB/Min** (Faktor 10!)
+
+**Container-Parameter (das Raster):**
+
+| Parameter | Reduzieren → | Konsequenz |
+|-----------|--------------|------------|
+| Abtastrate | Weniger Messpunkte/Sek | Max. Frequenz sinkt |
+| Bittiefe | Weniger Lautstärkestufen | Mehr Rauschen |
+| Kanäle | Mono statt Stereo | Kein Raumklang |
+
+<!--
+CONTAINER-PARAMETER:
+Container-Parameter bestimmen das "Raster" - wie viele Messpunkte, wie genau, wie viele Kanäle.
+Wenn man diese reduziert, verliert man Qualität auf technischer Ebene.
+
+BEISPIEL Abtastrate:
+- Abtastrate 22 kHz → ALLES über 11 kHz ist physisch unmöglich zu speichern
+- Das ist ein "harter" Schnitt - alles darüber ist weg
+-->
+
+---
+
+# Psychoakustik: Der MP3-Trick
+
+**Inhalt (was durchs Raster geht):**
+
+| Methode | Reduzieren → | Konsequenz |
+|---------|--------------|------------|
+| Psychoakustik | Unhörbare Frequenzen | Kaum wahrnehmbar |
+
+→ **MP3 nutzt hauptsächlich Psychoakustik**
+→ Container bleibt ähnlich, Inhalt wird "ausgedünnt"
+
+<!--
+Psychoakustik arbeitet anders als Container-Parameter:
+- Der Container (44.1 kHz, 16 Bit, Stereo) kann gleich bleiben
+- Aber der INHALT wird "ausgedünnt" - nur das was wir hören können bleibt
+- Das ist der Trick von MP3: Nicht das Raster verkleinern, sondern intelligent weglassen
+
+BEISPIEL Abtastrate vs. Psychoakustik:
+- Abtastrate 22 kHz → ALLES über 11 kHz ist physisch unmöglich zu speichern
+- Psychoakustik bei 44.1 kHz → 0-22 kHz möglich, aber maskierte Frequenzen werden entfernt
+
+MASKIERUNG:
+- Frequenzmaskierung: Lauter Ton bei 1 kHz "überdeckt" leise Töne bei 1.1 kHz
+- Zeitliche Maskierung: Kurz vor/nach lautem Ton hören wir leise Töne nicht
+- Absolute Hörschwelle: Sehr leise Töne hören wir generell nicht
+
+WARUM funktioniert MP3 so gut?
+- Unser Gehör ist kein lineares Messgerät
+- Wir hören nicht alle Frequenzen gleich gut
+- MP3 nutzt ein Modell des menschlichen Hörens
+- Spart Bits dort wo wir es nicht merken
+-->
+
+---
+
+# Die Geburt der MP3
+
+**1982:** Universität Erlangen-Nürnberg
+Karlheinz Brandenburg, Diplom-Ingenieur
+
+**1987:** Fraunhofer IIS entwickelt MPEG-1 Audio Layer III
+
+**1988:** Patentanmeldung
+
+**1992:** Erste Software-Implementierung
+
+**1995:** .mp3 Dateiendung offiziell
+
+<!--
+MPEG = Moving Picture Experts Group
+Layer III = Dritte Verfeinerungsstufe
+Forschung dauerte 10 Jahre
+Patent lief 2017 aus
+-->
+
+---
+
+![bg right:40%](./assets/karlheinz-brandenburg.jpg)
+
+# Karlheinz Brandenburg
+
+**"Vater der MP3"**
+
+- Diplom-Ingenieur, Universität Erlangen-Nürnberg
+- Fraunhofer IIS (Institut für Integrierte Schaltungen)
+- Forschung ab 1982, Patent 1988
+
+<!--
+Fraunhofer IIS Erlangen
+Forschung dauerte über 10 Jahre
+Perfektionist: Jeder Hörtest musste bestehen
+-->
+
+---
+
+![bg right:50%](./assets/suzanne-vega.jpg)
+
+# Suzanne Vega
+
+**"Tom's Diner" (1987)**
+
+- Der erste Song, der als MP3 kodiert wurde
+- A cappella (keine Instrumente)
+- Klare, hohe Frequenzen
+- Perfekter Stresstest für Kompression
+- Brandenburg hörte "Tom's Diner" über 10.000 Mal
+
+<!--
+Suzanne Vega – "Tom's Diner" (1987)
+A cappella = einfacher zu analysieren (nur Stimme)
+Hohe Frequenzen = Herausforderung für Kompression
+Brandenburg hörte den Song über 10.000 Mal
+-->
+<!--
+
+---
+
+# "Tom's Diner"
+
+**Warum dieser Song?**
+
+- A cappella (keine Instrumente)
+- Suzanne Vegas Stimme ist "schwierig"
+- Klare, hohe Frequenzen → Stresstest
+
+> Wenn ich Suzanne Vegas Stimme kodieren könnte, kann ich alles kodieren.
+— Karlheinz Brandenburg
+
+Brandenburg hörte Song 10.000+ Mal
+A cappella = einfacher zu analysieren (nur Stimme)
+Hohe Frequenzen = Herausforderung für Kompression
+Perfektionismus: Jeder Hörtest musste bestehen
+-->
+
+---
+
+# Wie funktioniert MP3?
+
+Ein Zusammenspiel aus vielen Faktoren:
+
+* **1. Frequenz-Analyse (FFT)**
+  Audio → Frequenzspektrum
+
+* **2. Psychoakustisches Modell**
+  Welche Töne hört Mensch nicht?
+
+* **3. Quantisierung**
+  Unwichtige Frequenzen reduzieren
+
+* **4. Huffman-Coding**
+  Lossless-Kompression der Restdaten
+
+<!--
+MP3-Kompression in 4 Schritten (vereinfacht):
+
+1. FFT (Fast Fourier Transform)
+   - Wandelt Schallwellen in Frequenzen um
+   - Wie ein Prisma Licht in Farben zerlegt
+
+2. Psychoakustisches Modell
+   - Fragt: "Was kann ein Mensch NICHT hören?"
+   - Maskierungseffekte: Lauter Ton verdeckt leisen daneben
+   - Hohe/tiefe Frequenzen werden schlechter wahrgenommen
+
+3. Quantisierung (hier passiert der Datenverlust!)
+   - Unwichtige Frequenzen werden "grob" gespeichert
+   - Wichtige Frequenzen bleiben genau
+   - Wie JPEG: Details entfernen, wo es nicht auffällt (Kontrast/Helligkeit bleibt)
+
+4. Huffman-Coding (verlustfrei)
+   - Häufige Muster = kurze Codes
+   - Seltene Muster = lange Codes
+   - Finaler Effizienz-Boost
+
+MP3 ist KEIN einfaches "Kleiner machen"
+→ Es simuliert, wie dein Gehirn Musik verarbeitet!
+-->
+
+---
+
+# Bitrate: Der Qualitäts-Knopf
+
+| Bitrate | Qualität | Kompression |
+|---------|----------|-------------|
+| **128 kbps** | Hörbar schlechter | ~11x |
+| **192 kbps** | Akzeptabel | ~7x |
+| **256 kbps** | Gut | ~5,5x |
+| **320 kbps** | "CD-Qualität" | ~4,4x |
+
+**Original CD:** 1.411 kbps (unkomprimiert)
+
+<!--
+kbps = Kilobit pro Sekunde
+128 kbps = Standard in 2000ern (Napster-Ära)
+320 kbps = Maximum für MP3
+Höhere Bitrate = mehr Daten = bessere Qualität
+Aber: Diminishing Returns ab 256 kbps
+-->
+
+<!--
+---
+
+# Beispiel: Verlustbehaftet (lossy)
+
+**Kernidee:** Entferne, was Menschen nicht wahrnehmen
+
+| Format | Nutzt Schwächen von... | Fachbegriff |
+|--------|------------------------|-------------|
+| **JPEG** | Auge (Farbe < Helligkeit) | Psychovisuell |
+| **MP3** | Ohr (Maskierungseffekte) | Psychoakustik |
+
+<!--
+PSYCHOVISUELL (JPEG):
+- Auge nimmt Helligkeit besser wahr als Farbe
+- Große Flächen besser als feine Details
+- Daher: Farbinformation stärker komprimiert
+
+PSYCHOAKUSTIK (MP3):
+- Mittlere Frequenzen besser als hohe/tiefe
+- Laute Töne "maskieren" leise Töne in der Nähe
+- Auditory Masking: Lauter 1000 Hz-Ton → leise 950 Hz unhörbar
+
+KERNKONZEPT: Kompression = Modell der menschlichen Wahrnehmung
+-->
+
+<!--
+
+---
+
+
+# Beispiel: Verlustfrei (lossless)
+### Lauflängenkodierung (RLE)
+
+**Original:** `AAAAABBBCCCCCCCC` (16 Zeichen)
+
+**Komprimiert:** `5A3B8C` (6 Zeichen) → **62% kleiner**
+
+**Prinzip:** Wiederholungen zählen statt wiederholen
+
+<!--
+RLE = Run-Length Encoding = Lauflängenkodierung
+Einfachster Kompressionsalgorithmus
+Gut für: Fax, einfache Grafiken, Icons
+Schlecht für: Fotos, Audio (zu chaotisch)
+-->
+
+
+---
+
+# Der Patentkrieg
+
+**1990er:** Fraunhofer + Thomson halten MP3-Patente
 
 **Lizenzgebühren:**
-- Hardware-Decoder: $0,20 pro Einheit
-- "Internet Broadcast": Kostenlos (YouTube etc.)
+- $0,75 pro Decoder
+- $2,50 pro Encoder
 
-**Problem:** Open-Source-Projekte in Grauzone
+**Problem:** Napster (1999) → unkontrollierte Verbreitung
+
+**2017:** Patente laufen aus → MP3 ist frei
 
 <!--
-- MPEG-LA = Licensing Authority
-- Firefox weigerte sich lange, H.264 zu unterstützen
-- "Free to View" gilt nur für Endnutzer-Streaming
-- Diskussion: Sollten Standards patent-frei sein?
+Fraunhofer verklagte Winamp, andere Tools
+Millionen nutzten unlizenzierte Software
+Das Pferd war aus dem Stall
+2017: Fraunhofer selbst erklärte MP3 für "veraltet" (AAC besser)
 -->
 
 ---
 
-# H.265 / HEVC: Effizienter, aber...
+![bg right:50% fit](./assets/napster-2001.png)
 
-**High Efficiency Video Coding (2013)**
+# Napster (1999)
 
-50% bessere Kompression als H.264
+**P2P-Filesharing für MP3s**
 
-**Das Problem: Patent-Chaos**
-
-Drei konkurrierende Patent-Pools:
-- MPEG-LA
-- HEVC Advance
-- Velos Media
-
-Unklare Kosten, rechtliche Unsicherheit
-→ Viele bleiben bei H.264 oder wechseln zu AV1
+- Shawn Fanning, 19 Jahre alt
+- 80 Millionen User in 2 Jahren
+- Musikindustrie verklagt (2001)
+- Pandora's Box: Nicht mehr aufzuhalten
 
 <!--
-- Technisch überlegen, aber Lizenz-Albtraum
-- 4K-Streaming wäre ohne H.265/VP9/AV1 nicht praktikabel
-- Apple nutzt HEVC (iPhone-Videos)
-- Netflix zögerte lange
-- Lehre: Technische Überlegenheit reicht nicht
+P2P = Peer-to-Peer
+Shawn Fanning gründete Napster als Student
+RIAA verklagte Napster, Schließung 2001
+Aber: LimeWire, Kazaa, BitTorrent folgten
 -->
 
 ---
 
-# VP9: Googles Antwort
+![bg right:40% contain](./assets/bittorrent.png)
 
-**VP9 (2013)**
+# Napster & Musikindustrie
 
-Google kaufte On2 Technologies (2010, $133M)
-VP8 → VP9 → AV1
+**1999:** Napster startet
+**2001:** 80 Millionen User
 
-**Eigenschaften:**
-- Ähnliche Effizienz wie H.265
-- Patent-frei (laut Google)
-- YouTube nutzt VP9 für 4K
+**Musikindustrie:**
+- CDs kosten $15-20
+- MP3s gratis (illegal, aber yolo)
+- Einzelne Songs statt Alben
 
-**Nachteil:** Höherer CPU-Aufwand als H.264
+**2001:** Napster wird verklagt und schließt
+
+**Aber:** Pandora's Box offen
+→ LimeWire, Kazaa, BitTorrent, später Spotify
 
 <!--
-- YouTube forciert VP9: 4K-Videos nur in VP9 oder AV1
-- Hardware-Decoder ab ~2016 in GPUs
-- Google's Strategie: Eigene Infrastruktur als Hebel
-- Frage: Ist es gut, wenn ein Konzern Standards setzt?
+RIAA (Recording Industry Association of America) verklagte Napster
+Urteil: Napster muss schließen (2001)
+Aber: Technologie nicht mehr aufzuhalten
+iPod (2001): "1.000 songs in your pocket"
+iTunes Store (2003): Legale Alternative
+Spotify (2008): Streaming-Ära beginnt
 -->
 
 ---
 
-![bg contain right:28%](./assets/AV1.png)
+# Kulturelle Revolution
 
-<!-- _class: klausur -->
-<!-- _header: '' -->
-<!-- _footer: '' -->
-<!-- _backgroundColor: #e3f2fd -->
+**MP3 veränderte:**
 
-# AV1: Die offene Zukunft
+✓ Musik wurde portabel (Walkman → iPod)
+✓ Alben wurden irrelevant (Playlists)
+✓ Musikkonsum explodierte (kostenlos/billig)
+✓ KünstlerInnen verloren Kontrolle
 
-**AV1 (2018)**
-
-**Alliance for Open Media:**
-Google, Netflix, Amazon, Microsoft, Apple, Mozilla...
-
-**Eigenschaften:**
-- 30% besser als H.265
-- Royalty-free, Open Source
-- 8K, HDR, hohe Frame-Rates
-
-**Stand 2025:**
-YouTube, Netflix nutzen AV1 für 4K/8K
-Hardware-Encoder in aktuellen GPUs
+**Aber auch:**
+❌ KünstlerInnen verdienen weniger pro Stream
+❌ Audio-Qualität sank (Loudness War)
+❌ Physische Medien starben
 
 <!--
-KLAUSURRELEVANT:
-- AOM gegründet 2015 – historisch: Konkurrenten vereint
-- Ziel: Nie wieder Patent-Chaos wie bei H.265
-- Problem: Encoding sehr langsam (10–100× vs. H.264)
-- Hardware-Encoder lösen das zunehmend
-- AV1 gewann 2024 einen Emmy für technische Innovation
--->
-
----
-
-<!-- _header: '' -->
-<!-- _footer: 'https://blog.mozilla.org/en/mozilla/av1-video-codec-wins-emmy/' -->
-
-![bg contain](./assets/av1-grammy.png)
-
-<!--
-- AV1 gewann 2024 einen Emmy für technische Innovation
-- Anerkennung für offene Standards
-- Zeigt: Open Source kann Industriestandard werden
+Walkman (1979): Kassetten
+Discman (1984): CDs
+iPod (2001): MP3s
+Spotify (2008): Streaming
+Künstler-Einkommen: Album-Verkauf → Streaming-Pennies
+Loudness War: Alles wird lauter gemastert (Dynamik verloren)
+Vinyl-Revival: 2020er Gegenbewegung
 -->
 
 ---
@@ -1239,13 +1591,7 @@ KLAUSURRELEVANT:
 # Fragen & Diskussion
 
 **Kontakt:** lb-czechowski@hdm-stuttgart.de
-**Folien:** [librete.ch/hdm/223015b](https://librete.ch/hdm/223015b/)
-
-<!--
-- Offene Fragen?
-- Welches Thema war am überraschendsten?
-- Hinweis auf Selbstlernaufgaben (nächste Folien)
--->
+**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
 
 ---
 
@@ -1256,12 +1602,27 @@ Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAli
 - Erlaubt Teilen & Anpassen mit Namensnennung
 - Adaptionen müssen unter gleicher Lizenz geteilt werden
 
-Vollständige Lizenz: [creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/)
+Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Selbstlernen: Audio-Spektrogram
+
+**Aufgabe (30 Min):**
+
+- Live Spektrogram untersuchen https://borismus.github.io/spectrogram/
+- Mit Effekten experimentieren https://audiomass.co/
+- Spektrogramme vergleichen Audacity (kostenloser Download nötig) [https://manual.audacityteam.org/man/spectrogram_view.html](https://manual.audacityteam.org/man/spectrogram_view.html)
 
 <!--
-- Folien dürfen verwendet und angepasst werden
-- Bedingung: Namensnennung und gleiche Lizenz
-- Fragen zur Lizenz? → Creative Commons Website
+Audacity: FOSS Audio-Editor (audacityteam.org)
+Export: Datei → Exportieren → MP3 → Bitrate wählen
+Spektrogramm-Ansicht: Auf Track-Name klicken (Dropdown öffnet sich) → "Spektrogramm" wählen
+Hohe Frequenzen (oben im Bild) verschwinden bei niedriger Bitrate
+Alternative: Spek (spek.cc) – reiner Spektrogramm-Viewer
 -->
 
 ---
@@ -1269,47 +1630,26 @@ Vollständige Lizenz: [creativecommons.org/licenses/by-sa/4.0/](https://creative
 <!-- _header: '' -->
 <!-- _footer: '' -->
 
-![bg contain right:25%](./assets/qr/squoosh.png)
+![bg contain right:22%](./assets/qr/hexed-it.png)
 
-# Selbstlernen: Bildkompression
+# Selbstlernen: HEX Files
 
-1. Öffne [squoosh.app](https://squoosh.app)
-2. Lade ein Foto hoch
-3. Vergleiche: JPEG (verschiedene Quality) vs. WebP vs. AVIF
-4. Beobachte: Dateigröße, Artefakte, Ladezeit
-
-**Fragen zum Erkunden:**
-- Ab welcher Quality werden Artefakte sichtbar?
-- Wie viel kleiner ist WebP bei gleicher Qualität?
-
-<!--
-- Squoosh: Google-Tool zum Vergleichen von Bildformaten
-- Live-Vergleich mit Schieberegler
-- Ziel: Gefühl für Kompressionsraten entwickeln
-- Bonus: Eigene Fotos testen
--->
-
----
-
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-# Selbstlernen: Video analysieren
-
-1. Video herunterladen (z.B. Big Buck Bunny)
-2. Mit MediaInfo analysieren: Container, Codec, Bitrate
-3. Optional: Mit HandBrake konvertieren
-  - H.264 vs. H.265 bei gleicher Qualität
-  - Größe und Encoding-Zeit vergleichen
+1. Drei Dateien ohne Dateiendung:
+   <a href="../materials/wtf1"/>`hex1`</a>  <a href="../materials/wtf2"/>`hex2`</a>  <a href="../materials/wtf3"/>`hex3`</a>
+3. Lies erste 16 Bytes aus und identifiziere Dateiformat (Magic Number)
+5. *Optional: Datei umbenennen und korrekte Dateiendung anhängen (bspw. `.jpg`)*
 
 **Tools:**
-- [MediaInfo](https://mediaarea.net/MediaInfoOnline) (Online oder Desktop)
-- [HandBrake](https://handbrake.fr) (Desktop)
+- Hex-Editor: [hexed.it](https://hexed.it)
+- Magic Numbers: [en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures)
 
 <!--
-- Big Buck Bunny: Open-Source-Film der Blender Foundation
-- Frei verfügbar, ideal zum Experimentieren
-- MediaInfo zeigt alle technischen Details
-- HandBrake: GUI für FFmpeg, einfacher zu bedienen
-- Experiment: Gleiches Video, verschiedene Codecs vergleichen
+Praktische Phase: Studierende arbeiten selbst
+Dateien im materials/ Ordner:
+- wtf1: Plaintext (keine Magic Number)
+- wtf2: PNG (89 50 4E 47)
+- wtf3: JPEG (FF D8 FF)
+Gruppenarbeit: 3-4 Personen
+Ziel: Hex-Dump lesen lernen, Dateiformate verstehen
 -->
+

From c35541961e5f0d9f7a34eaf1e7b76ff3793f4812 Mon Sep 17 00:00:00 2001
From: Michael Czechowski <mail@dailysh.it>
Date: Mon, 2 Feb 2026 13:42:12 +0100
Subject: [PATCH 7/8] add archive directory with old klausurfragen files

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---
 archive/223015c_it_grundlagen_40pt.xml   |  469 ++++++
 archive/klausurfragen_it+dateiformate.md | 1829 ++++++++++++++++++++++
 archive/klausurfragen_it.md              |  439 ++++++
 3 files changed, 2737 insertions(+)
 create mode 100644 archive/223015c_it_grundlagen_40pt.xml
 create mode 100644 archive/klausurfragen_it+dateiformate.md
 create mode 100644 archive/klausurfragen_it.md

diff --git a/archive/223015c_it_grundlagen_40pt.xml b/archive/223015c_it_grundlagen_40pt.xml
new file mode 100644
index 0000000..45ce3ea
--- /dev/null
+++ b/archive/223015c_it_grundlagen_40pt.xml
@@ -0,0 +1,469 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<quiz>
+
+<!-- ============================================================
+     223015c – Grundlagen IT- und Internettechnik
+     40 Punkte / 40 Minuten
+     Michael Czechowski – HdM Stuttgart – WS 2025/26
+     ============================================================ -->
+
+<!-- ─── 3 pt – Von-Neumann: 5 Komponenten ─── -->
+<question type="matching">
+  <n><text>Q1 – Von-Neumann: Komponenten zuordnen</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Ordne jeder Komponente der Von-Neumann-Architektur ihre
+      Funktion zu.</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).</text></generalfeedback>
+  <defaultgrade>3</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <shuffleanswers>true</shuffleanswers>
+  <answer fraction="100"><text>Rechenwerk (ALU)</text><match>Führt arithmetische und logische Operationen durch.</match></answer>
+  <answer fraction="100"><text>Steuerwerk</text><match>Holt, dekodiert und steuert die Ausführung von Befehlen.</match></answer>
+  <answer fraction="100"><text>Speicherwerk</text><match>Enthält sowohl Programme als auch Daten (Stored Program Concept).</match></answer>
+  <answer fraction="100"><text>Ein-/Ausgabe</text><match>Schnittstelle zu externen Geräten wie Tastatur, Bildschirm, Netzwerk.</match></answer>
+  <answer fraction="100"><text>Bus-System</text><match>Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus.</match></answer>
+</question>
+
+<!-- ─── 2 pt – Von-Neumann vs Harvard: Transfer ─── -->
+<question type="multichoice">
+  <n><text>Q2 – Von-Neumann vs. Harvard</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Ein Arduino-Mikrocontroller nutzt die <strong>Harvard-Architektur</strong>.
+      Ein modernes Smartphone nutzt eine (modifizierte) Von-Neumann-Architektur.</p>
+      <p><strong>Warum ist die Harvard-Architektur für Echtzeit-Anwendungen
+      auf dem Arduino vorteilhafter, und was wäre der Nachteil, wenn
+      das Smartphone diese Architektur verwenden würde?</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>Harvard: separate Code/Daten-Speicher → paralleler Zugriff, schneller. Nachteil: Code und Daten nicht aus gleichem Speicher nahtlos mischbar → weniger Flexibilität, kein „Laden beliebiger Apps" wie bei Von-Neumann.</text></generalfeedback>
+  <defaultgrade>2</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <single>true</single>
+  <shuffleanswers>true</shuffleanswers>
+  <correctfeedback type="html"><text>Genau – Speed vs. Flexibilität.</text></correctfeedback>
+  <incorrectfeedback type="html"><text>Nein – überlege, was getrennte Speicher für Code und Daten bedeuten.</text></incorrectfeedback>
+  <answer fraction="100"><text><![CDATA[Harvard nutzt <strong>separate Speicher</strong> für Code und Daten → paralleler Zugriff, schneller. Beim Smartphone wäre es schwieriger, beliebige Apps zu laden – weniger Flexibilität.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Harvard ist langsamer, aber sicherer – daher für Echtzeit geeignet. Smartphones brauchen die Geschwindigkeit nicht.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Beide Architekturen sind funktional identisch – der Unterschied liegt nur im Gehäuse.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Von-Neumann ist schneller durch gemeinsamen Speicher. Harvard wird gewählt, weil Echtzeit-Apps weniger Speicher brauchen.]]></text></answer>
+</question>
+
+<!-- ─── 2 pt – Stored Program Concept Transfer ─── -->
+<question type="multichoice">
+  <n><text>Q3 – Stored Program Concept</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Vor der Von-Neumann-Architektur mussten bei Maschinen wie dem
+      ENIAC Programme durch <strong>Umstecken von Kabeln</strong> eingegeben
+      werden.</p>
+      <p><strong>Was konkret ermöglicht das Stored Program Concept, was
+      vorher nicht möglich war? Nenne zwei Beispiele.</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>Stored Program: Programme werden als Daten im Speicher abgelegt → austauschbar ohne Hardwareänderung. Ermöglicht: Betriebssysteme, Apps installieren/löschen, Multitasking, Updates.</text></generalfeedback>
+  <defaultgrade>2</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <single>true</single>
+  <shuffleanswers>true</shuffleanswers>
+  <correctfeedback type="html"><text>Genau – Programme als Daten im Speicher = Flexibilität.</text></correctfeedback>
+  <incorrectfeedback type="html"><text>Nein – der Kern liegt darin, dass Programme im Speicher als Daten residieren.</text></incorrectfeedback>
+  <answer fraction="100"><text><![CDATA[Programme werden als <strong>Daten im Speicher</strong> abgelegt → z. B. Apps können installiert/gelöscht werden und <strong>Multitasking</strong> (mehrere Programme gleichzeitig) wird möglich.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Programme werden auf separater Hardware gespeichert → die Hauptspeicher-Kapazität wird ums Doppelte gesteigert.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Die Hardware kann jetzt selbst Befehle erfinden – kein Mensch muss mehr programmieren.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Nur ein einzelnes Programm kann gleichzeitig laufen, aber es kann schneller geladenen werden.]]></text></answer>
+</question>
+
+<!-- ─── 2 pt – HTML Metadaten: Transfer ─── -->
+<question type="multichoice">
+  <n><text>Q4 – HTML: &lt;head&gt; vs. &lt;body&gt;</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Ein Student erstellt eine Webseite und platziert <em>alles</em>
+      im <code>&lt;body&gt;</code> – auch den <code>&lt;title&gt;</code>
+      und die <code>&lt;meta name="description"&gt;</code>.</p>
+      <p><strong>Welche zwei konkreten Konsequenzen hat das?</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>title und meta description gehören in &lt;head&gt;. Im &lt;body&gt;: (1) kein Titel im Browser-Tab / Suchergebnis, (2) keine Beschreibung für Suchmaschinen/Screen-Reader → SEO und Accessibility beeinträchtigt.</text></generalfeedback>
+  <defaultgrade>2</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <single>true</single>
+  <shuffleanswers>true</shuffleanswers>
+  <correctfeedback type="html"><text>Genau – Metadaten im Body werden nicht als solche interpretiert.</text></correctfeedback>
+  <incorrectfeedback type="html"><text>Nein – &lt;head&gt; und &lt;body&gt; haben spezifische Funktionen.</text></incorrectfeedback>
+  <answer fraction="100"><text><![CDATA[(1) Der Browser-Tab zeigt <strong>keinen Titel</strong> an. (2) Suchmaschinen haben <strong>keine Beschreibung</strong> für das Snippet → schlechte SEO und Screen-Reader können die Seite nicht richtig vorlesen.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Kein Problem – Browser ignorieren die Unterscheidung zwischen <code>&lt;head&gt;</code> und <code>&lt;body&gt;</code>.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[(1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Nur das Fehlen von <code>&lt;meta charset&gt;</code> ist ein Problem – title und description funktionieren überall.]]></text></answer>
+</question>
+
+<!-- ─── 3 pt – Accessibility Transfer ─── -->
+<question type="multichoice">
+  <n><text>Q5 – Barrierefreiheit: Curb-Cut-Effekt</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Der <strong>Curb-Cut-Effekt</strong> beschreibt, wie eine
+      barrierefreie Lösung – ursprünglich für Menschen mit Behinderung –
+      letztendlich <em>allen</em> zugute kommt.</p>
+      <p><strong>Nenne ein konkretes Web-Beispiel, das diesen Effekt
+      demonstriert, und erkläre, wer davon profitiert.</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>Beispiel: Untertitel (für Gehörlose) → helfen auch in lauter Umgebung, beim Sprachlernen, bei Ton aus. Alt-Texte (für Screen-Reader) → helfen auch SEO. Semantisches HTML → besser für alle.</text></generalfeedback>
+  <defaultgrade>3</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <single>true</single>
+  <shuffleanswers>true</shuffleanswers>
+  <correctfeedback type="html"><text>Genau – Barrierefreiheit hilft allen.</text></correctfeedback>
+  <incorrectfeedback type="html"><text>Nein – überlege, welche barrierefreien Maßnahmen auch Menschen ohne Behinderung nutzen.</text></incorrectfeedback>
+  <answer fraction="100"><text><![CDATA[<strong>Untertitel:</strong> Gedacht für Gehörlose, helfen aber auch in lauter Umgebung, beim Sprachlernen oder wenn der Ton aus ist – profitiert fast jedermann.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Barrierefreie Webseiten sind langsamer zu laden – der Curb-Cut-Effekt beschreibt diesen negativen Nebeneffekt.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[<strong>Dark Mode:</strong> Gedacht für Sehbehinderung, hilft auch in dunkler Umgebung – Beispiel für den Curb-Cut-Effekt.]]></text></answer>
+</question>
+
+<!-- ─── 2 pt – EAA / WCAG ─── -->
+<question type="multichoice">
+  <n><text>Q6 – European Accessibility Act</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Der <strong>European Accessibility Act (EAA)</strong> ist seit
+      Juni 2025 in Kraft.</p>
+      <p><strong>Was bedeutet das konkret für ein deutsches
+      E-Commerce-Unternehmen, das eine Webseite betreibt?</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>EAA verpflichtet u. a. E-Commerce-Anbieter zur Barrierefreiheit. Die Webseite muss WCAG-Standards erfüllen. Bei Verstoß: Bußgelder bis 100.000 € möglich.</text></generalfeedback>
+  <defaultgrade>2</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <single>true</single>
+  <shuffleanswers>true</shuffleanswers>
+  <correctfeedback type="html"><text>Genau – rechtliche Pflicht zur Barrierefreiheit.</text></correctfeedback>
+  <incorrectfeedback type="html"><text>Nein – der EAA erstellt eine rechtliche Verpflichtung für bestimmte Sektoren.</text></incorrectfeedback>
+  <answer fraction="100"><text><![CDATA[Die Webseite <strong>muss barrierefreiheitstechnisch</strong> WCAG-Standards erfüllen – E-Commerce ist explizit im EAA geregelt. Bei Verstoß: Bußgelder möglich.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Der EAA betrifft nur öffentliche Behörden – private Unternehmen sind ausgenommen.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Das Unternehmen muss nur eine englische Version der Webseite bereitstellen.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Der EAA regelt nur die Barrierefreiheit von mobilen Apps, nicht von Webseiten.]]></text></answer>
+</question>
+
+<!-- ─── 3 pt – TCP/IP Schichten: Protokoll → Schicht ─── -->
+<question type="matching">
+  <n><text>Q7 – TCP/IP: Protokoll → Schicht</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>Anwendung: HTTP, DNS, SMTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.</text></generalfeedback>
+  <defaultgrade>3</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <shuffleanswers>true</shuffleanswers>
+  <answer fraction="100"><text>HTTP</text><match>Anwendung</match></answer>
+  <answer fraction="100"><text>TCP</text><match>Transport</match></answer>
+  <answer fraction="100"><text>IP</text><match>Internet</match></answer>
+  <answer fraction="100"><text>Ethernet</text><match>Netzzugang</match></answer>
+  <answer fraction="100"><text>DNS</text><match>Anwendung</match></answer>
+  <answer fraction="100"><text>UDP</text><match>Transport</match></answer>
+</question>
+
+<!-- ─── 3 pt – Encapsulation: D-S-P-F ─── -->
+<question type="matching">
+  <n><text>Q8 – Encapsulation: Dateneinheit → Schicht</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Bei der Übertragung wird eine Nachricht von Schicht zu Schicht
+      verpackt (Encapsulation). Ordne jeder Dateneinheit die zugehörige
+      Schicht zu.</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>Daten (Anwendung) → Segment (Transport, +Ports) → Paket (Internet, +IP) → Frame (Netzzugang, +MAC). Merkhilfe: D-S-P-F.</text></generalfeedback>
+  <defaultgrade>3</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <shuffleanswers>true</shuffleanswers>
+  <answer fraction="100"><text>Daten</text><match>Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite).</match></answer>
+  <answer fraction="100"><text>Segment</text><match>Transportschicht – Daten + Ports und Sequenznummern.</match></answer>
+  <answer fraction="100"><text>Paket</text><match>Internetschicht – Segment + IP-Adressen (Quelle und Ziel).</match></answer>
+  <answer fraction="100"><text>Frame</text><match>Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme.</match></answer>
+</question>
+
+<!-- ─── 3 pt – IP vs MAC vs Port Transfer ─── -->
+<question type="multichoice">
+  <n><text>Q9 – IP vs. MAC vs. Port: Transfer-Szenario</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Dein Laptop sendet eine HTTPS-Anfrage an einen Webserver in
+      einem anderen Land. Das Paket durchläuft mehrere Router.</p>
+      <p><strong>Welche der folgenden Aussagen über die Adressen auf dem
+      Weg ist korrekt?</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>IP-Adresse des Ziel-Servers bleibt konstant (global). MAC-Adresse ändert sich bei jedem Hop (lokal, nächster Router). Port 443 (HTTPS) bleibt konstant.</text></generalfeedback>
+  <defaultgrade>3</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <single>true</single>
+  <shuffleanswers>true</shuffleanswers>
+  <correctfeedback type="html"><text>Genau – nur MAC ändert sich unterwegs.</text></correctfeedback>
+  <incorrectfeedback type="html"><text>Nein – überlege, welche Adresse bei jedem Hop neu gesetzt wird.</text></incorrectfeedback>
+  <answer fraction="100"><text><![CDATA[Die <strong>IP-Adresse</strong> des Servers bleibt konstant, der <strong>Port</strong> (443) ändert sich nicht – die <strong>MAC-Adresse</strong> wird an jedem Router neu gesetzt (lokal, ein Hop).]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Alle drei Adressen (IP, MAC, Port) ändert sich bei jedem Router.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Die MAC-Adresse bleibt konstant, die IP-Adresse ändert sich bei jedem Hop.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[IP und Port ändert sich, MAC bleibt konstant – MAC ist die globale Adresse.]]></text></answer>
+</question>
+
+<!-- ─── 3 pt – 3-Way Handshake: Transfer ─── -->
+<question type="multichoice">
+  <n><text>Q10 – TCP 3-Way-Handshake: Was passiert wäre?</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Der Client sendet ein <strong>SYN</strong> zum Server.
+      Das SYN-Paket geht verloren – es erreicht den Server nie.</p>
+      <p><strong>Was passiert als nächstes, und warum wird keine
+      Verbindung aufgebaut?</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>Der Server erhält kein SYN → sendet kein SYN-ACK zurück → der Client bekommt keine Antwort → Verbindung wird nicht aufgebaut. TCP wird das SYN nach einem Timeout erneut senden (Neuübertragung).</text></generalfeedback>
+  <defaultgrade>3</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <single>true</single>
+  <shuffleanswers>true</shuffleanswers>
+  <correctfeedback type="html"><text>Genau – ohne SYN beim Server: kein SYN-ACK, kein Handshake.</text></correctfeedback>
+  <incorrectfeedback type="html"><text>Nein – überlege, was der Server ohne SYN tun kann.</text></incorrectfeedback>
+  <answer fraction="100"><text><![CDATA[Der Server kennt die Anfrage nicht → sendet <strong>kein SYN-ACK</strong> → der Client erhält keine Antwort → <strong>keine Verbindung</strong>. Der Client wird das SYN nach einem Timeout erneut senden.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist – die Verbindung wird trotzdem aufgebaut.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Der Client sendet direkt ein ACK als Fallback – die Verbindung wird mit zwei Paketen aufgebaut.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Das verloren gegangene SYN wird automatisch vom Netzwerk rekonstruiert – kein Problem.]]></text></answer>
+</question>
+
+<!-- ─── 2 pt – TCP vs UDP Transfer ─── -->
+<question type="multichoice">
+  <n><text>Q11 – TCP vs. UDP: Videostreaming</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Ein Videostreaming-Dienst sendet Daten an deinen Browser.
+      Ein einzelnes Paket geht verloren.</p>
+      <p><strong>Warum wählt der Dienst <strong>UDP</strong> statt TCP,
+      obwohl ein Paket verloren geht?</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>Bei Echtzeit-Video ist Verzögerung schlimmer als Paketverlust. TCP würde das Paket erneut anfordern → Video friert. UDP ignoriert das Verlust → kurzer Artefakt, Video läuft weiter.</text></generalfeedback>
+  <defaultgrade>2</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <single>true</single>
+  <shuffleanswers>true</shuffleanswers>
+  <correctfeedback type="html"><text>Genau – bei Echtzeit ist Verzögerung ärger als Verlust.</text></correctfeedback>
+  <incorrectfeedback type="html"><text>Nein – überlege, was TCP bei einem verlorenen Paket tun würde.</text></incorrectfeedback>
+  <answer fraction="100"><text><![CDATA[Bei <strong>Echtzeit</strong> ist Verzögerung schlimmer als Verlust. TCP würde das Paket <strong>erneut anfordern</strong> → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.]]></text></answer>
+</question>
+
+<!-- ─── 2 pt – HTTP Methoden: Transfer ─── -->
+<question type="multichoice">
+  <n><text>Q12 – HTTP-Methoden: Szenario</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Ein Nutzer aktualisiert sein Profilbild auf einer Webseite.
+      Das Foto wird zum Server gesendet und das <strong>alte Bild
+      ersetzt</strong>.</p>
+      <p><strong>Welche HTTP-Methode wird für diese Operation verwendet,
+      und warum nicht GET?</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>PUT – Daten ersetzen (eine existierende Ressource wird überschrieben). GET ruft nur Daten ab, sendet keine Daten zum Server.</text></generalfeedback>
+  <defaultgrade>2</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <single>true</single>
+  <shuffleanswers>true</shuffleanswers>
+  <correctfeedback type="html"><text>Genau – PUT für das Ersetzen einer Ressource.</text></correctfeedback>
+  <incorrectfeedback type="html"><text>Nein – überlege, was „ersetzen" in HTTP bedeutet.</text></incorrectfeedback>
+  <answer fraction="100"><text><![CDATA[<strong>PUT</strong> – ersetzt eine existierende Ressource. GET ruft nur Daten ab und sendet <em>keine</em> Daten zum Server.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[<strong>GET</strong> – GET kann auch Daten senden, wenn eine URL mit Parameter verwendet wird.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[<strong>POST</strong> – POST ist immer für das Ersetzen von Daten zuständig.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[<strong>DELETE</strong> – DELETE sendet das neue Foto und löscht gleichzeitig das alte.]]></text></answer>
+</question>
+
+<!-- ─── 2 pt – HTTP Status-Codes Transfer ─── -->
+<question type="multichoice">
+  <n><text>Q13 – HTTP Status-Codes: Fehlerdiagnose</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Du rufst eine Webseite auf und der Browser zeigt folgende
+      Fehlermeldung an:</p>
+      <pre>HTTP/1.1 503 Service Unavailable</pre>
+      <p><strong>Was bedeutet dieser Code, und wer ist für die Behebung
+      zuständig – du oder der Betreiber der Webseite?</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>503 ist ein 5xx-Code = Server-Fehler. Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Serverbetreiber, nicht beim Nutzer.</text></generalfeedback>
+  <defaultgrade>2</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <single>true</single>
+  <shuffleanswers>true</shuffleanswers>
+  <correctfeedback type="html"><text>Genau – 5xx = Server-Problem, nicht dein Fehler.</text></correctfeedback>
+  <incorrectfeedback type="html"><text>Nein – überlege, was die Ziffer „5" im Code bedeutet.</text></incorrectfeedback>
+  <answer fraction="100"><text><![CDATA[<strong>Server-Fehler:</strong> Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim <strong>Betreiber</strong> – du kannst nur später erneut versuchen.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Client-Fehler: Du hast die falsche URL eingegeben – ein 5xx-Code bedeutet, dass deine Anfrage falsch war.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Erfolgs-Code: 503 bedeutet, dass der Server die Anfrage erfolgreich umgeleitet hat.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Der Code bedeutet, dass der Server die Seite dauerhaft verschoben hat – du muss die neue URL suchen.]]></text></answer>
+</question>
+
+<!-- ─── 2 pt – DNS Ablauf Transfer ─── -->
+<question type="multichoice">
+  <n><text>Q14 – DNS: Rolle im Ablauf</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Du gibst <code>https://hdm-stuttgart.de</code> in die
+      Adresszeile ein.</p>
+      <p><strong>Was passiert <em>vor</em> dem TCP-Handshake, und warum
+      ist dieser Schritt zwingend nötig?</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>DNS-Auflösung: Der Name „hdm-stuttgart.de" wird in eine IP-Adresse umgewandelt. TCP braucht eine IP-Adresse – names können nicht direkt verbunden werden.</text></generalfeedback>
+  <defaultgrade>2</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <single>true</single>
+  <shuffleanswers>true</shuffleanswers>
+  <correctfeedback type="html"><text>Genau – DNS vor TCP, Name → IP.</text></correctfeedback>
+  <incorrectfeedback type="html"><text>Nein – überlege, was TCP als Zieladresse braucht.</text></incorrectfeedback>
+  <answer fraction="100"><text><![CDATA[<strong>DNS-Auflösung:</strong> Der Name <code>hdm-stuttgart.de</code> wird in eine <strong>IP-Adresse</strong> umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen, nicht zu Namen.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Der Browser sendet direkt den Namen an den Server – DNS wird erst danach für die Verschlüsselung benötigt.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[DNS passiert nach dem TCP-Handshake – erst wird die Verbindung aufgebaut, dann der Name aufgelöst.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.]]></text></answer>
+</question>
+
+<!-- ─── 2 pt – CSS Spezifität Transfer ─── -->
+<question type="multichoice">
+  <n><text>Q15 – CSS Spezifität: Welche Regel gewinnt?</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Gegeben folgender CSS-Code:</p>
+      <pre>
+p           { color: blue; }      /* (A) */
+.highlight  { color: green; }     /* (B) */
+#main       { color: red; }       /* (C) */
+      </pre>
+      <p>Ein Element <code>&lt;p class="highlight" id="main"&gt;Text&lt;/p&gt;</code>
+      wird angezeigt.<br>
+      <strong>Welche Farbe zeigt der Text an, und warum?</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Alle drei Regeln treffen das Element – ID #main gewinnt → rot.</text></generalfeedback>
+  <defaultgrade>2</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <single>true</single>
+  <shuffleanswers>true</shuffleanswers>
+  <correctfeedback type="html"><text>Genau – ID gewinnt durch höchste Spezifität.</text></correctfeedback>
+  <incorrectfeedback type="html"><text>Nein – überlege die Spezifitätswerte: ID > Klasse > Element.</text></incorrectfeedback>
+  <answer fraction="100"><text><![CDATA[<strong>Rot</strong> – die ID-Regel <code>#main</code> hat die höchste Spezifität (0,1,0,0) und gewinnt über Klasse (0,0,1,0) und Element (0,0,0,1).]]></text></answer>
+  <answer fraction="0"><text><![CDATA[<strong>Blau</strong> – die Element-Regel steht zuerst im Code und hat daher Vorrang.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[<strong>Grün</strong> – Klassen-Selektoren haben immer Vorrang vor IDs.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[<strong>Rot</strong> – die letzte Regel im Code gewinnt immer, unabhängig vom Selektor-Typ.]]></text></answer>
+</question>
+
+<!-- ─── 2 pt – Responsive Design Transfer ─── -->
+<question type="multichoice">
+  <n><text>Q16 – Responsive Design: Mobile First</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Ein Developer schreibt folgendes CSS:</p>
+      <pre>
+.container { background: white; }
+
+@media (min-width: 768px) {
+    .container { background: blue; }
+}
+
+@media (min-width: 1024px) {
+    .container { background: green; }
+}
+      </pre>
+      <p><strong>Welche Farbe hat <code>.container</code> bei einem
+      Bildschirm von 900 px Breite, und warum?</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>Mobile First: Basis = white. Bei 900px greift min-width: 768px → blue. min-width: 1024px greift NICHT (900 &lt; 1024). Ergebnis: blau.</text></generalfeedback>
+  <defaultgrade>2</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <single>true</single>
+  <shuffleanswers>true</shuffleanswers>
+  <correctfeedback type="html"><text>Genau – 768px greift, 1024px nicht.</text></correctfeedback>
+  <incorrectfeedback type="html"><text>Nein – überlege, welche min-width-Bedingungen bei 900px erfüllt sind.</text></incorrectfeedback>
+  <answer fraction="100"><text><![CDATA[<strong>Blau</strong> – bei 900 px greift <code>min-width: 768px</code> (900 ≥ 768), aber <code>min-width: 1024px</code> greift nicht (900 &lt; 1024).]]></text></answer>
+  <answer fraction="0"><text><![CDATA[<strong>Weiß</strong> – Media-Queries gelten nur ab 1024 px, darunter bleibt immer die Basis-Farbe.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[<strong>Grün</strong> – die letzte Media-Query überschreibt immer alle vorherigen.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[<strong>Weiß</strong> – bei 900 px greift keine Media-Query, da 900 zwischen den beiden Breakpoints liegt.]]></text></answer>
+</question>
+
+<!-- ─── 1 pt – Zusammen: Der Ablauf eines Klicks ─── -->
+<question type="multichoice">
+  <n><text>Q17 – Zusammen: Reihenfolge eines HTTPS-Aufrufs</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Du gibst eine URL ein. <strong>Welche Reihenfolge der Schritte
+      ist korrekt?</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>Korrekte Reihenfolge: (1) DNS-Auflösung, (2) TCP 3-Way-Handshake, (3) HTTP-Request (GET), (4) HTTP-Response (200 OK + HTML).</text></generalfeedback>
+  <defaultgrade>1</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <single>true</single>
+  <shuffleanswers>true</shuffleanswers>
+  <correctfeedback type="html"><text>Genau – DNS → TCP → HTTP Request → HTTP Response.</text></correctfeedback>
+  <incorrectfeedback type="html"><text>Nein – an erster Stelle steht immer die DNS-Auflösung.</text></incorrectfeedback>
+  <answer fraction="100"><text><![CDATA[(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK]]></text></answer>
+  <answer fraction="0"><text><![CDATA[(1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK]]></text></answer>
+  <answer fraction="0"><text><![CDATA[(1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK]]></text></answer>
+  <answer fraction="0"><text><![CDATA[(1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK]]></text></answer>
+</question>
+
+<!-- ─── 1 pt – Bonusfrage: Spezifität Edge Case ─── -->
+<question type="multichoice">
+  <n><text>Q18 – CSS: 100 Element-Selektoren vs. 1 Klasse</text></n>
+  <questiontext type="html">
+    <text><![CDATA[
+      <p>Es gibt zwei CSS-Regeln für ein <code>&lt;p&gt;</code>-Element:</p>
+      <pre>
+p p p p p p p p p p  { color: blue; }   /* 100× Element-Selektor */
+.highlight           { color: red; }    /* 1× Klasse */
+      </pre>
+      <p>Das Element hat die Klasse <code>highlight</code>.
+      <strong>Welche Farbe gewinnt?</p>
+    ]]></text>
+  </questiontext>
+  <generalfeedback type="html"><text>Eine einzelne Klasse (0,0,1,0) schlägt immer hundert Element-Selektoren (0,0,0,100). Spezifität wird nicht additiv „aufgezählt" – die Stelle zählt als Einheit.</text></generalfeedback>
+  <defaultgrade>1</defaultgrade>
+  <penalty>0.25</penalty>
+  <hidden>0</hidden>
+  <single>true</single>
+  <shuffleanswers>true</shuffleanswers>
+  <correctfeedback type="html"><text>Genau – eine Klasse gewinnt immer gegen beliebig viele Elemente.</text></correctfeedback>
+  <incorrectfeedback type="html"><text>Nein – Spezifität funktioniert nicht durch Addition innerhalb einer Stelle.</text></incorrectfeedback>
+  <answer fraction="100"><text><![CDATA[<strong>Rot</strong> – eine Klasse (0,0,1,0) gewinnt immer gegen beliebig viele Element-Selektoren (0,0,0,n). Spezifität-Stellen überschreiben sich, nicht addieren.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[<strong>Blau</strong> – 100 Element-Selektoren ergeben 0,0,0,100 = höhere Spezifität als 0,0,1,0.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[<strong>Blau</strong> – die längere Regel (mehr Selektoren) hat immer höhere Spezifität.]]></text></answer>
+  <answer fraction="0"><text><![CDATA[Unentschieden – die Regeln haben exakt gleiche Spezifität.]]></text></answer>
+</question>
+
+</quiz>
diff --git a/archive/klausurfragen_it+dateiformate.md b/archive/klausurfragen_it+dateiformate.md
new file mode 100644
index 0000000..68f6e08
--- /dev/null
+++ b/archive/klausurfragen_it+dateiformate.md
@@ -0,0 +1,1829 @@
+# 223015c – Fragenkatalog (Question Pool)
+**IT-Grundlagen · HdM Stuttgart · M. Czechowski**
+**Ziel: ~100 Fragen, hohe Varianz, semestraler Los-Mechanismus**
+
+---
+
+> **Legende – Moodle XML-Typen:**
+> `[MC]` = `multichoice` (einzelne Auswahl)
+> `[MM]` = `multichoice` + `<single>false</single>` (Mehrfachauswahl)
+> `[MATCH]` = `matching` (Zuordnung)
+> `[ORDER]` = `ordering` (Reihenfolge)
+> `[ESSAY]` = `essay` (Freitext, manuell bewertet)
+> `[SHORTANS]` = `shortanswer` (Stichwort/Satz, automatisch geprüft)
+> `[NUMERIC]` = `numerical` (Zahlenwert ± Toleranz)
+> `[CLOZE]` = `cloze` (Lückentext, gemischt)`
+
+---
+---
+
+
+<!-- _class: lead -->
+## BLOCK A – Von-Neumann-Architektur
+
+---
+
+### A1 – Komponenten zuordnen
+**Thema:** Von-Neumann Grundstruktur
+**Punkte:** 3
+**Typ:** `[MATCH]`
+
+Ordne jeder Komponente der Von-Neumann-Architektur ihre Funktion zu.
+
+| Komponente | Funktion |
+|---|---|
+| Rechenwerk (ALU) | Führt arithmetische und logische Operationen durch |
+| Steuerwerk | Holt, dekodiert und steuert die Ausführung von Befehlen |
+| Speicherwerk | Enthält sowohl Programme als auch Daten |
+| Ein-/Ausgabe | Schnittstelle zu externen Geräten (Tastatur, Bildschirm, Netzwerk) |
+| Bus-System | Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus |
+
+> **Feedback:** Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).
+
+---
+
+### A2 – Welche Komponente ist das?
+**Thema:** Von-Neumann – einzelne Komponente identifizieren
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Ein Programm besteht aus einer Folge von Befehlen. Eine Komponente der Von-Neumann-Architektur ist für das Abrufen, Dekodieren und Ausführen dieser Befehle zuständig. Welche?
+
+- [ ] Rechenwerk (ALU)
+- [x] **Steuerwerk** ✅
+- [ ] Speicherwerk
+- [ ] Ein-/Ausgabe
+
+> **Feedback:** Das Steuerwerk (Control Unit) orchestriert den Fetch-Decode-Execute-Zyklus – es ist der „Dirigent" der CPU.
+
+---
+
+### A3 – Bus-Typen identifizieren
+**Thema:** Von-Neumann – Bus-System im Detail
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Bus-Typ seine Funktion zu.
+
+| Bus | Funktion |
+|---|---|
+| Adressbus | Übermittelt die Speicheradresse, an der Daten gelesen/geschrieben werden |
+| Datenbus | Führt die eigentlichen Daten zwischen CPU und Speicher |
+| Steuerbus | Übermittelt Steuersignale (Lesen/Schreiben, Takt) |
+
+> **Feedback:** Adressbus = „Wo?", Datenbus = „Was?", Steuerbus = „Wie/Wann?"
+
+---
+
+### A4 – Von-Neumann vs. Harvard: Kern-Unterschied
+**Thema:** Architektur-Vergleich – Konzept
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Was ist der fundamentale strukturelle Unterschied zwischen der Von-Neumann- und der Harvard-Architektur?
+
+- [ ] Harvard verwendet einen schnelleren Bus, Von-Neumann einen langsameren.
+- [x] **Bei Harvard sind Programm- und Datenspeicher physisch getrennt; bei Von-Neumann teilen sie denselben Speicher.** ✅
+- [ ] Von-Neumann hat mehr Prozessorkerne als Harvard.
+- [ ] Harvard verzichtet komplett auf einen Bus – die Komponenten kommunizieren drahtlos.
+
+> **Feedback:** Der eine Unterschied: ein Speicher (Von-Neumann) vs. zwei separate Speicher (Harvard). Alles andere folgt aus diesem Prinzip.
+
+---
+
+### A5 – Harvard: Vorteil für Echtzeit erkläre
+**Thema:** Von-Neumann vs. Harvard – Transfer/Begründung
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Ein Arduino nutzt die Harvard-Architektur. Erkläre in 2–3 Sätzen, warum diese Architektur für Echtzeit-Anwendungen auf einem Mikrokontroller vorteilhafter ist als die Von-Neumann-Architektur.
+
+> **Musterlösung:** Harvard trennt Code- und Datenspeicher → CPU kann gleichzeitig einen Befehl aus dem Programmspeicher lesen UND auf Daten im Datenspeicher zugreifen (paralleler Zugriff). Bei Von-Neumann konkurrieren Befehle und Daten um denselben Bus →sequentiell → langsamere Zykluszeit. Bei Echtzeit-Anwendungen zählt jeder Nanosekunde.
+
+---
+
+### A6 – Von-Neumann-Flaschenhals: Was, warum, wie lösen?
+**Thema:** Von-Neumann-Bottleneck – Transfer
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Beschreibe den „Von-Neumann-Flaschenhals" (Bottleneck). Erkläre konkret, woher er entsteht und nenne eine Maßnahme, die moderna Architekten einsetzen, um ihn zu mildern.
+
+> **Musterlösung:** CPU ist schneller als der Datentransfer über den gemeinsamen Bus. Da Befehle und Daten sich denselben Bus teilen, müssen sie nacheinander geladen werden → Engpass. Lösung: Cache-Speicher direkt an der CPU (L1/L2) reduziert Bus-Zugriffe drastisch.
+
+---
+
+### A7 – Flaschenhals: Richtig oder Falsch?
+**Thema:** Von-Neumann-Bottleneck – Verständnis prüfen
+**Punkte:** 1
+**Typ:** `[MC]`
+
+„Der Von-Neumann-Flaschenhals entsteht, weil der Speicher langsamer als die CPU ist und Befehle und Daten sich den gleichen Bus teilen müssen."
+
+Diese Aussage ist …
+
+- [x] **…korrekt.** ✅
+- [ ] …falsch – der Flaschenhals liegt bei der Ein-/Ausgabe, nicht beim Bus.
+- [ ] …falsch – In der Von-Neumann-Architektur haben Befehle und Daten separate Busse.
+- [ ] …falsch – Die CPU ist immer langsamer als der Bus.
+
+> **Feedback:** Genau diese Kombination (gemeinsamer Bus + Geschwindigkeitsdifferenz) definiert den Flaschenhals.
+
+---
+
+### A8 – Stored Program Concept: Was ermöglicht es?
+**Thema:** Stored Program Concept – Konzept verstehen
+**Punkte:** 2
+**Typ:** `[MM]` (Mehrfachauswahl)
+
+Welche der folgenden Aussagen beschreiben korrekt, was das Stored Program Concept ermöglicht? (Mehrere Antworten möglich)
+
+- [x] **Apps können ohne Hardwareänderung installiert und gelöscht werden.** ✅
+- [x] **Multitasking wird möglich, da mehrere Programme im Speicher gleichzeitig residieren können.** ✅
+- [ ] Die CPU kann jetzt selbst neue Befehle erfinden.
+- [ ] Der Speicher wird durch das Stored Program Concept doppelt so groß.
+- [x] **Betriebssysteme können sich selbst aktualisieren.** ✅
+- [ ] Programme müssen weiterhin durch Umstecken von Kabeln eingegeben werden.
+
+> **Feedback:** Kern: Programme werden als Daten im Speicher abgelegt → austauschbar ohne Hardware-Änderung. Das öffnet Tür zu: Apps, Multitasking, Updates, Betriebssysteme.
+
+---
+
+### A9 – Stored Program Concept: Lückentext
+**Thema:** Stored Program Concept – Terminologie
+**Punkte:** 1
+**Typ:** `[CLOZE]`
+
+Vor der Von-Neumann-Architektur mussten Programme durch [[1:Umstecken von Kabeln]] eingegeben werden. Das Stored Program Concept löst das dadurch, dass Programme als [[2:Daten im Speicher]] abgelegt werden. Das bedeutet, dass [[3:keine Hardwareänderung]] nötig ist, um ein anderes Programm auszuführen.
+
+> **Feedback:** Die drei Schlüsselbegriffe zusammen erzählen die Story: vorher Kabel, nachher Daten im Speicher, Konsequenz: Hardware-unabhängig.
+
+---
+
+### A10 – Stored Program Concept: Vorher vs. nachher
+**Thema:** Stored Program Concept – Transfer historisch
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Der ENIAC war einer der ersten elektronischen Computer. Erkläre in einem kurzen Satz, wie dort Programme „eingegeben" wurden, und erkläre anschließend, was konkret das Stored Program Concept daran änderte.
+
+> **Musterlösung:** Beim ENIAC mussten Programme durch Umstecken von Kabeln (Verdrahtung) physisch eingegeben werden – jedes neue Programm erforderte eine manuelle Umkonfiguration der Hardware. Das Stored Program Concept speichert Programme als Daten im selben Speicher wie die Arbeitsdaten → austauschbar per Software, keine Verdrahtung nötig.
+
+---
+---
+
+
+<!-- _class: lead -->
+## BLOCK B – Netzwerk-Grundlagen (TCP/IP)
+
+---
+
+### B1 – Protokoll → TCP/IP-Schicht zuordnen
+**Thema:** TCP/IP-Schichtmodell – Zuordnung
+**Punkte:** 3
+**Typ:** `[MATCH]`
+
+Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.
+
+| Protokoll | Schicht |
+|---|---|
+| HTTP | Anwendung |
+| DNS | Anwendung |
+| TCP | Transport |
+| UDP | Transport |
+| IP | Internet |
+| Ethernet | Netzzugang |
+
+> **Feedback:** Anwendung: HTTP, DNS, SMTP, FTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.
+
+---
+
+### B2 – Welche Schicht ist das? (einzeln)
+**Thema:** TCP/IP – einzelne Schicht identifizieren
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Das Protokoll IP arbeitet auf welcher TCP/IP-Schicht?
+
+- [ ] Anwendung
+- [ ] Transport
+- [x] **Internet** ✅
+- [ ] Netzzugang
+
+> **Feedback:** IP (Internet Protocol) arbeitet auf der Internet-Schicht – dort werden Pakete adressiert und geroutet.
+
+---
+
+### B3 – Schicht-Funktion beschreiben
+**Thema:** TCP/IP – Funktionen der Schichten
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Beschreibe in einem Satz pro Schicht die Hauptfunktion jeder der vier TCP/IP-Schichten (Anwendung, Transport, Internet, Netzzugang).
+
+> **Musterlösung:** Anwendung: Stellt Protokolle für spezifische Dienste bereit (HTTP für Web, SMTP für Mail). Transport: Sorgt für zuverlässige (TCP) oder schnelle (UDP) Übertragung zwischen zwei Endpunkten. Internet: Adressiert und routet Pakete über Netzwerkgrenzen hinweg mittels IP. Netzzugang: Übertragen von Frames auf einem physischen Übertragungsweg (Ethernet, WLAN).
+
+---
+
+### B4 – Was ist eine MAC-Adresse?
+**Thema:** MAC-Adresse – Konzept
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was identifiziert eine MAC-Adresse?
+
+- [ ] Den konkreten Dienst (z. B. Webserver) auf einem Computer.
+- [ ] Den Computer im globalen Internet über Netzwerkgrenzen hinweg.
+- [x] **Die Netzwerkkarte eines Geräts auf einem lokalen Netzwerksegment.** ✅
+- [ ] Die Routen, die ein Paket durch das Internet nimmt.
+
+> **Feedback:** MAC = Media Access Control. Sie ist eine 48-Bit-Adresse, die einer Netzwerkkarte ab Werk zugewiesen wird – lokal, ein Hop.
+
+---
+
+### B5 – Was ist eine IP-Adresse?
+**Thema:** IP-Adresse – Konzept
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was identifiziert eine IP-Adresse?
+
+- [ ] Die Netzwerkkarte eines Geräts auf einem lokalen Segment.
+- [x] **Ein Gerät (Host) im globalen Internet – sie ermöglicht das Routing über Netzwerkgrenzen.** ✅
+- [ ] Den Dienst, der auf einem bestimmten Port läuft.
+- [ ] Die physische Leitung zwischen zwei Computern.
+
+> **Feedback:** IP = Internet Protocol. Die IP-Adresse ist der globale „Hausnummer" eines Geräts – routing-tauglich, im Gegensatz zur lokalen MAC-Adresse.
+
+---
+
+### B6 – Was ist eine Port-Nummer?
+**Thema:** Port – Konzept
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Wozu dient eine Port-Nummer auf dem Zielrechner?
+
+- [ ] Sie bestimmt die Geschwindigkeit der Verbindung.
+- [ ] Sie identifiziert das Gerät im Netzwerk.
+- [x] **Sie adressiert den konkreten Dienst bzw. die Anwendung auf dem Computer (z. B. Webserver auf 80, HTTPS auf 443).** ✅
+- [ ] Sie zeigt an, ob das Gerät per WLAN oder Kabel verbunden ist.
+
+> **Feedback:** IP = „Welches Gebäude?", Port = „Welche Tür im Gebäude?" (welcher Dienst soll die Anfrage empfangen).
+
+---
+
+### B7 – IP, MAC, Port: Zuordnung
+**Thema:** Adressierung – Unterschiede auf einen Blick
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jeder Adresse ihre Beschreibung zu.
+
+| Adresse | Beschreibung |
+|---|---|
+| IP-Adresse | Globale Adresse eines Geräts – ermöglicht Routing über Netzwerkgrenzen |
+| MAC-Adresse | Lokale Adresse einer Netzwerkkarte – nur innerhalb eines Segments gültig |
+| Port-Nummer | Adressiert einen bestimmten Dienst auf einem Computer |
+
+> **Feedback:** Drei Ebenen der Adressierung: Gerät global (IP), Gerät lokal (MAC), Dienst auf dem Gerät (Port).
+
+---
+
+### B8 – MAC ändert sich, IP nicht: Warum?
+**Thema:** IP vs. MAC beim Routing – Transfer
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Ein Paket reist von deinem Laptop zu einem Webserver über mehrere Router. Erkläre in 2–3 Sätzen, warum die MAC-Adresse an jedem Router neu gesetzt wird, während die IP-Adresse des Ziel-Servers konstant bleibt.
+
+> **Musterlösung:** Die IP-Adresse des Ziel-Servers bleibt konstant, weil sie das globale Routingziel identifiziert – jeder Router nutzt sie, um das nächste Hop zu bestimmen. Die MAC-Adresse hingegen gilt nur für ein einzelnes Netzwerksegment (einen „Hop"). An jedem Router wird ein neuer Frame erstellt mit der MAC des nächsten Hops als Ziel – die alte MAC wird verworfen.
+
+---
+
+### B9 – Encapsulation: Dateneinheit → Schicht
+**Thema:** Encapsulation – Zuordnung
+**Punkte:** 3
+**Typ:** `[MATCH]`
+
+Bei der Übertragung wird eine Nachricht von Schicht zu Schicht verpackt. Ordne jeder Dateneinheit die zugehörige Schicht und was hinzugefügt wird.
+
+| Dateneinheit | Schicht + Was wird ergänzt |
+|---|---|
+| Daten | Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite) |
+| Segment | Transportschicht – Daten + Ports und Sequenznummern |
+| Paket | Internetschicht – Segment + IP-Adressen (Quelle und Ziel) |
+| Frame | Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme |
+
+> **Feedback:** D-S-P-F: Daten → Segment → Paket → Frame. Jede Schicht fügt einen Header (und beim Frame auch einen Trailer) hinzu.
+
+---
+
+### B10 – Encapsulation: Reihenfolge sortieren
+**Thema:** Encapsulation – Reihenfolge
+**Punkte:** 2
+**Typ:** `[ORDER]`
+
+Sortiere die Dateneinheiten in der Reihenfolge, wie sie beim Senden entstehen (von innen nach außen):
+
+1. Daten
+2. Segment
+3. Paket
+4. Frame
+
+> **Feedback:** Zwiebelprinzip: Die Anwendung erzeugt Daten → Transport verpackt zu einem Segment → Internet zu einem Paket → Netzzugang zum Frame.
+
+---
+
+### B11 – Decapsulation: Umgekehrte Reihenfolge
+**Thema:** Decapsulation – Empfänger-Seite
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Wenn der Server das Signal empfängt, passiert Decapsulation. In welcher Reihenfolge werden die Header entfernt?
+
+- [ ] Anwendung → Transport → Internet → Netzzugang
+- [ ] Alle Header werden gleichzeitig entfernt, sobald die Daten im RAM liegen.
+- [x] **Netzzugang (Ethernet-Header weg) → Internet (IP-Header weg) → Transport (TCP-Header weg) → Daten.** ✅
+- [ ] Internet → Netzzugang → Transport → Anwendung
+
+> **Feedback:** Das Auspacken erfolgt in umgekehrter Reihenfolge wie das Einpacken – der äußerste Header (Frame) wird zuerst entfernt.
+
+---
+
+### B12 – Encapsulation: Lückentext
+**Thema:** Encapsulation – Terminologie
+**Punkte:** 2
+**Typ:** `[CLOZE]`
+
+Bei der Übertragung wird eine Nachricht von Schicht zu Schicht verpackt. Die Transportschicht erzeugt ein [[1:Segment]], die Internetschicht ein [[2:Paket]], und die Netzzugangsschicht einen [[3:Frame]]. Am Empfänger wird dieses in [[4:umgekehrter Reihenfolge]] wieder abgepackt (Decapsulation).
+
+> **Feedback:** D-S-P-F vorwärts beim Senden, F-P-S-D beim Empfangen. Jeder Name beschreibt die Dateneinheit mit allen bis zu dieser Schicht hinzugefügten Headern.
+
+---
+
+### B13 – TCP vs. UDP: Videostreaming
+**Thema:** TCP vs. UDP – Echtzeit-Szenario
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Ein Videostreaming-Dienst sendet Daten an deinen Browser. Ein einzelnes Paket geht verloren. Warum wählt der Dienst UDP statt TCP?
+
+- [ ] UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.
+- [x] **Bei Echtzeit ist Verzögerung schlimmer als Verlust. TCP würde das Paket erneut anfordern → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter.** ✅
+- [ ] TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.
+- [ ] UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.
+
+> **Feedback:** Der Kern: Bei Echtzeit zählt Latenz, nicht Vollständigkeit. Ein fehlendes Frame ist besser als ein eingefrorenes Video.
+
+---
+
+### B14 – TCP vs. UDP: Unterschiede beschreiben
+**Thema:** TCP vs. UDP – Konzept-Vergleich
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Nenne zwei wesentliche Unterschiede zwischen TCP und UDP und gib für jeden einen konkreten Anwendungsfall an, in dem genau dieses Eigenschaftspaar ausschlaggebend ist.
+
+> **Musterlösung:** (1) TCP ist verbindungsorientiert und zuverlässig (Handshake, Sequenznummern, ACK) → ideal für Dateiübertragung, wo jedes Byte zählt. (2) UDP ist verbindungslos und schneller, aber ohne Garantie für Lieferung oder Reihenfolge → ideal für Echtzeit-Anwendungen wie Videostreaming oder Online-Gaming, wo Latenz wichtiger als Vollständigkeit ist.
+
+---
+
+### B15 – TCP vs. UDP: Richtig oder Falsch?
+**Thema:** TCP vs. UDP – Aussagen prüfen
+**Punkte:** 1
+**Typ:** `[MC]`
+
+„UDP garantiert, dass alle Pakete in der richtigen Reihenfolge ankommen."
+
+Diese Aussage ist …
+
+- [ ] …korrekt – UDP nutzt Sequenznummern wie TCP.
+- [x] **…falsch – UDP bietet keine Garantie für Reihenfolge noch für Lieferung.** ✅
+- [ ] …korrekt – UDP ist sogar zuverlässiger als TCP.
+- [ ] …falsch – UDP existiert gar nicht mehr in modernen Netzwerken.
+
+> **Feedback:** UDP = „fire and forget". Keine Verbindung, keine Sequenznummern, keine Bestätigung. Genau deshalb ist es schneller.
+
+---
+
+### B16 – TCP 3-Way-Handshake: SYN geht verloren
+**Thema:** TCP-Verbindungsaufbau – Störfall
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Der Client sendet ein SYN zum Server. Das SYN-Paket geht verloren – es erreicht den Server nie. Was passiert als nächstes?
+
+- [ ] Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist.
+- [x] **Der Server kennt die Anfrage nicht → sendet kein SYN-ACK → der Client erhält keine Antwort → keine Verbindung. Der Client sendet das SYN nach einem Timeout erneut.** ✅
+- [ ] Der Client sendet direkt ein ACK als Fallback – Verbindung mit zwei Paketen.
+- [ ] Das verloren gegangene SYN wird vom Netzwerk automatisch rekonstruiert.
+
+> **Feedback:** Ohne SYN beim Server: kein SYN-ACK, kein Handshake, keine Verbindung. TCP retransmittiert nach Timeout.
+
+---
+
+### B17 – TCP 3-Way-Handshake: Ablauf beschreiben
+**Thema:** TCP-Verbindungsaufbau – Konzept
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Beschreibe die drei Schritte des TCP 3-Way-Handshakes. Erkläre, warum alle drei Schritte nötig sind, bevor Daten gesendet werden.
+
+> **Musterlösung:** (1) Client → Server: SYN („Ich will eine Verbindung aufbauen"). (2) Server → Client: SYN-ACK (「Ich bestätige das und will auch eine Verbindung"). (3) Client → Server: ACK ("Bestätigt"). Alle drei Schritte sind nötig, damit beide Seiten wissen, dass die andere die Verbindung akzeptiert hat – erst dann kann zuverlässiger Datenaustausch beginnen.
+
+---
+
+### B18 – TCP Sequenznummern: Wozu?
+**Thema:** TCP – Sequenznummern
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Welches Problem lösen Sequenznummern im TCP-Header konkret?
+
+- [ ] Sie verhindern, dass Hacker die Verbindung abhören können.
+- [x] **Pakete können in falscher Reihenfolge ankommen. Sequenznummern erlauben das korrekte Sortieren beim Empfänger.** ✅
+- [ ] Sie zählen, wie viele Benutzer gleichzeitig auf dem Server sind.
+- [ ] Sie bestimmen die maximale Größe einer Datei.
+
+> **Feedback:** IP-Pakete können unterschiedliche Routen nehmen → Part 3 kommt vor Part 1. TCP sortiert sie anhand der Sequenznummern wieder.
+
+---
+---
+
+<!-- _class: lead -->
+
+## BLOCK C – HTTP
+
+---
+
+### C1 – HTTP-Methoden: Zuordnung
+**Thema:** HTTP-Methoden – Was macht was
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jeder HTTP-Methode ihre Hauptfunktion zu.
+
+| Methode | Hauptfunktion |
+|---|---|
+| GET | Ruft eine Ressource ab (nur lesen) |
+| POST | Erstellt eine neue Ressource auf dem Server |
+| PUT | Ersetzt eine existierende Ressource vollständig |
+| DELETE | Löscht eine Ressource auf dem Server |
+
+> **Feedback:** CRUD-Mapping: GET=Read, POST=Create, PUT=Update, DELETE=Delete.
+
+---
+
+### C2 – POST vs. PUT: Unterschied
+**Thema:** HTTP-Methoden – POST vs. PUT
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Ein Nutzer erstellt einen neuen Blog-Eintrag auf einer Webseite. Welche HTTP-Methode wird verwendet?
+
+- [x] **POST – eine neue Ressource wird erstellt.** ✅
+- [ ] PUT – PUT wird immer verwendet, wenn Daten gesendet werden.
+- [ ] GET – GET kann auch Daten senden mit URL-Parametern.
+- [ ] DELETE – DELETE erstellt und löscht gleichzeitig.
+
+> **Feedback:** POST = „Erstelle etwas Neues". PUT = „Ersetze etwas Bestehendes". Neuer Blog-Eintrag → POST.
+
+---
+
+### C3 – PUT: Profilbild ersetzen
+**Thema:** HTTP-Methoden – PUT im Szenario
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Ein Nutzer aktualisiert sein Profilbild – das alte Bild wird durch ein neues ersetzt. Welche HTTP-Methode?
+
+- [ ] GET – GET kann auch Daten senden.
+- [x] **PUT – ersetzt eine existierende Ressource.** ✅
+- [ ] POST – POST ist immer für das Ersetzen zuständig.
+- [ ] DELETE – DELETE sendet das neue Foto und löscht das alte.
+
+> **Feedback:** „Ersetzen einer existierenden Ressource" = PUT. POST wäre, wenn ein völlig neues Bild erstellt würde, ohne dass ein vorhandenes überschrieben wird.
+
+---
+
+### C4 – DELETE: Wann nutzen?
+**Thema:** HTTP-Methoden – DELETE im Szenario
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Ein Nutzer löscht einen von ihm erstellten Kommentar auf einer Webseite. Welche HTTP-Methode wird der Browser im Hintergrund verwenden?
+
+- [ ] GET – GET kann auch Löschvorgänge auslösen.
+- [ ] POST – POST ist die Standardmethode für alle Änderungen.
+- [ ] PUT – PUT löscht und ersetzt gleichzeitig.
+- [x] **DELETE – der Kommentar wird vom Server entfernt.** ✅
+
+> **Feedback:** DELETE = „Entferne diese Ressource vom Server." Konkret: der Kommentar wird anhand seiner URL/ID identifiziert und gelöscht.
+
+---
+
+### C5 – HTTP-Methoden: Freitext-Beschreibung
+**Thema:** HTTP-Methoden – Konzept zusammenfassen
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre in einem kurzen Absatz, warum es in HTTP mehrere Methoden gibt (GET, POST, PUT, DELETE) und nicht einfach eine einzige „Sende-Funktion". Nutze ein konkretes Beispiel.
+
+> **Musterlösung:** Eine einzelne Methode könnte nicht zwischen „Daten lesen", „Daten erstellen", „Daten ersetzen" und „Daten löschen" unterscheiden – der Server wüsste nicht, was er tun soll. Mit separaten Methoden kann der Server allein anhand der Methode + URL entscheiden: GET `/users/5` → Benutzer 5 anzeigen; DELETE `/users/5` → Benutzer 5 löschen. Das ist sauber, zustandslos und standardisiert.
+
+---
+
+### C6 – GET: Warum nicht für Passwörter?
+**Thema:** HTTP-Methoden – GET Sicherheit
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Warum sollte man niemals GET verwenden, um sensible Daten (z. B. ein Passwort) an den Server zu senden?
+
+- [ ] GET ist langsamer als POST – Passwörter müssen schnell übertragen werden.
+- [x] **Bei GET stehen die Daten sichtbar in der URL (Browser-Verlauf, Server-Logs, Proxy-Server). Bei POST sind sie im Body versteckt.** ✅
+- [ ] GET erlaubt nur Zahlen, keine Buchstaben.
+- [ ] GET wird vom Server nie verschlüsselt, POST immer.
+
+> **Feedback:** GET-Parameter hängen an der URL (`?pw=123`). Diese ist in History, Logs, Proxies sichtbar. HTTPS verschlüsselt zwar beides auf der Leitung, aber die URL selbst wird an zu vielen Stellen gespeichert.
+
+---
+
+### C7 – Status-Codes: Categorisierung
+**Thema:** HTTP Status-Codes – Bedeutung der ersten Ziffer
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jeder ersten Ziffer eines HTTP-Status-Codes ihre Bedeutung zu.
+
+| Erste Ziffer | Bedeutung |
+|---|---|
+| 2xx | Erfolg – die Anfrage wurde erfolgreich verarbeitet |
+| 3xx | Weiterleitung – die Ressource wurde verschoben |
+| 4xx | Client-Fehler – die Anfrage des Nutzers war fehlerhaft |
+| 5xx | Server-Fehler – der Server hat ein Problem |
+
+> **Feedback:** Die erste Ziffer = Kategorie. 200 OK, 301 Moved, 404 Not Found, 503 Service Unavailable – die Kategorie sagt dir sofort, wo das Problem liegt.
+
+---
+
+### C8 – 503: Server-Fehler erkläre
+**Thema:** HTTP Status-Codes – 5xx Transfer
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Du rufst eine Webseite auf und erhältst `HTTP/1.1 503 Service Unavailable`. Was bedeutet das?
+
+- [ ] Du hast die falsche URL eingegeben.
+- [ ] Der Server hat die Anfrage erfolgreich umgeleitet.
+- [x] **Der Server ist überlastet oder temporär nicht verfügbar – Verantwortung liegt beim Betreiber.** ✅
+- [ ] Der Server hat die Seite dauerhaft verschoben.
+
+> **Feedback:** 5xx = Server-Problem. Du als Client kannst nur später erneut versuchen. Der Betreiber muss das lösen.
+
+---
+
+### C9 – 404: Wer hat „Schuld"?
+**Thema:** HTTP Status-Codes – 4xx Transfer
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Du erhältst einen 404-Fehler. Wer ist für die Ursache verantwortlich?
+
+- [ ] Der Server ist abgestürzt.
+- [ ] Das Internet ist ausgefallen.
+- [x] **Der Client (Nutzer) – eine URL wurde angefordert, die nicht existiert (Tippfehler oder veralteter Link).** ✅
+- [ ] Der DNS-Server konnte den Namen nicht auflösen.
+
+> **Feedback:** 4xx = Client-Fehler. Der Server funktioniert perfekt, er sagt nur: „Das, was du anforderst, habe ich nicht."
+
+---
+
+### C10 – Status-Codes: Szenarios zuordnen
+**Thema:** HTTP Status-Codes – Transfer Zuordnung
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Szenario den passenden HTTP-Status-Code zu.
+
+| Szenario | Status-Code |
+|---|---|
+| Du rufst eine Seite auf, die seit letztem Jahr auf eine neue URL umgeleitet wurde | 301 Moved Permanently |
+| Eine Webseite lädt erfolgreich | 200 OK |
+| Du gibst eine URL ein, die nicht existiert | 404 Not Found |
+| Der Webserver ist überlastet | 503 Service Unavailable |
+
+> **Feedback:** 200 = Alles gut. 301 = dauerhaft verschoben. 404 = nicht gefunden (dein Fehler). 503 = Server-Problem (Betreiber).
+
+---
+
+### C11 – Status-Codes: Freitext
+**Thema:** HTTP Status-Codes – Konzept zusammenfassen
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre, warum HTTP-Status-Codes aus einer dreistelligen Zahl bestehen und was die erste Ziffer konkret bedeutet. Nenne je einen Beispiel-Code für 2xx, 4xx und 5xx.
+
+> **Musterlösung:** Die erste Ziffer kategorisiert die Antwort: 2xx = Erfolg, 3xx = Weiterleitung, 4xx = Client-Fehler, 5xx = Server-Fehler. Die restlichen zwei Ziffern spezifizieren den genauen Fall. Beispiele: 200 OK (Erfolg), 404 Not Found (Client-Fehler), 500 Internal Server Error (Server-Fehler). Diese Struktur ermöglicht es, allein aus dem Code zu verstehen, ob und wo ein Problem liegt – ohne die Antwort ganz lesen zu müssen.
+
+---
+---
+
+<!-- _class: lead -->
+
+## BLOCK D – DNS
+
+---
+
+### D1 – DNS: Was macht es?
+**Thema:** DNS – Grundfunktion
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was ist die Hauptfunktion eines DNS-Servers?
+
+- [ ] Er verschlüsselt die Verbindung zwischen Client und Server.
+- [x] **Er übersetzt einen Domain-Namen (z. B. `hdm-stuttgart.de`) in eine IP-Adresse.** ✅
+- [ ] Er routet Pakete durch das Internet.
+- [ ] Er weist jedem Computer eine MAC-Adresse zu.
+
+> **Feedback:** DNS = Domain Name System = „Telefonbuch des Internets". Name → IP. Ohne DNS müsste man überall IP-Adressen eintippen.
+
+---
+
+### D2 – DNS: Zeitlicher Ablauf
+**Thema:** DNS – Rolle im Gesamtablauf
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Du gibst `https://hdm-stuttgart.de` in die Adresszeile ein. Was passiert vor dem TCP-Handshake?
+
+- [ ] Der Browser sendet direkt den Namen an den Server – DNS wird erst danach benötigt.
+- [x] **DNS-Auflösung: Der Name wird in eine IP-Adresse umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen.** ✅
+- [ ] DNS passiert nach dem TCP-Handshake.
+- [ ] DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.
+
+> **Feedback:** DNS vor TCP. Kein Name-to-IP? Kein Handshake möglich. TCP arbeitet auf IP-Adressen, nicht auf Domain-Namen.
+
+---
+
+### D3 – DNS: Warum zwingend nötig?
+**Thema:** DNS – Transfer/Begründung
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre in 2–3 Sätzen, warum der DNS-Schritt zwingend vor dem TCP-Handshake stehen muss. Was würde passieren, wenn der Browser den Domain-Namen direkt an den Netzwerk-Stack übergeben würde?
+
+> **Musterlösung:** TCP arbeitet nur mit IP-Adressen – ein Domain-Name wie `hdm-stuttgart.de` ist für TCP-/IP-Stack sinnlos. Ohne vorherige DNS-Auflösung würde der Browser nicht wissen, an welche IP er das SYN senden soll. Der DNS-Schritt konvertiert den human-readable-Namen in eine maschinenlesbare IP, erst danach kann der Verbindungsaufbau beginnen.
+
+---
+
+### D4 – DNS: Lückentext
+**Thema:** DNS – Terminologie
+**Punkte:** 1
+**Typ:** `[CLOZE]`
+
+Der DNS-Server übersetzt einen [[1:Domain-Namen]] in eine [[2:IP-Adresse]]. Dieser Schritt fällt [[3:vor]] dem TCP-Handshake statt, weil TCP nur zu [[4:IP-Adressen]] Verbindungen aufbauen kann.
+
+> **Feedback:** Die vier Lücken beschreiben den DNS-Ablauf vollständig: Was wird übersetzt, in was, wann, und warum.
+
+---
+---
+
+## BLOCK E – Der Gesamtablauf (Zusammen)
+
+---
+
+### E1 – Reihenfolge eines HTTPS-Aufrufs
+**Thema:** Gesamtablauf – Sortierung
+**Punkte:** 2
+**Typ:** `[ORDER]`
+
+Sortiere die Schritte eines HTTPS-Aufrufs in der richtigen Reihenfolge:
+
+1. DNS-Auflösung (Name → IP)
+2. TCP 3-Way-Handshake (Verbindung aufbauen)
+3. TLS-Handshake (Verschlüsselung vereinbaren)
+4. HTTP GET (Anfrage senden)
+5. HTTP 200 OK + HTML (Antwort empfangen)
+
+> **Feedback:** DNS → TCP → TLS → HTTP Request → HTTP Response. Jeder Schritt ist eine Voraussetzung für den nächsten.
+
+---
+
+### E2 – Reihenfolge: Welche Folge ist korrekt?
+**Thema:** Gesamtablauf – Multiple Choice
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Du gibst eine URL ein. Welche Reihenfolge ist korrekt?
+
+- [ ] (1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK
+- [x] **(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK** ✅
+- [ ] (1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK
+- [ ] (1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK
+
+> **Feedback:** DNS immer zuerst. Dann TCP (Verbindung). Dann HTTP (Anfrage/Antwort).
+
+---
+
+### E3 – Gesamtablauf: Freitext
+**Thema:** Gesamtablauf – Transfer beschreiben
+**Punkte:** 3
+**Typ:** `[ESSAY]`
+
+Du gibst `https://example.com` in deinen Browser ein. Beschreibe jeden Schritt vom Eintippen der URL bis zum Anzeigen der Webseite. Erkläre kurz, was in jedem Schritt passiert und warum dieser Schritt nötig ist.
+
+> **Musterlösung:** (1) DNS: `example.com` → IP-Adresse (z. B. 93.184.216.34). Nötig, weil TCP nur IPs kennt. (2) TCP-Handshake: SYN → SYN-ACK → ACK. Stellt eine zuverlässige Verbindung her. (3) TLS-Handshake (bei HTTPS): Verschlüsselung vereinbaren. (4) HTTP GET: Browser fordert die HTML-Seite an. (5) HTTP 200 OK: Server sendet die Seite zurück. Browser rendert HTML/CSS/JS.
+
+---
+---
+
+## BLOCK F – HTML-Grundlagen
+
+---
+
+### F1 – `<head>` vs. `<body>`: Was passiert bei Fehler?
+**Thema:** HTML-Struktur – head/body
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Ein Student platziert `<title>` und `<meta name="description">` im `<body>` statt im `<head>`. Welche zwei Konsequenzen hat das?
+
+- [ ] Kein Problem – Browser ignorieren die Unterscheidung.
+- [x] **(1) Der Browser-Tab zeigt keinen Titel an. (2) Suchmaschinen haben keine Beschreibung für das Snippet → schlechte SEO, Screen-Reader können die Seite nicht richtig vorlesen.** ✅
+- [ ] (1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.
+- [ ] Nur das Fehlen von `<meta charset>` ist ein Problem.
+
+> **Feedback:** `<head>` = Metadaten (unsichtbar für den Nutzer, sichtbar für Browser/Maschinen). `<body>` = sichtbarer Inhalt. Title und description im Body werden nicht als Metadaten interpretiert.
+
+---
+
+### F2 – `<head>`: Was gehört wohin?
+**Thema:** HTML-Struktur – Zuordnung
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Element zu, ob es in `<head>` oder `<body>` gehört.
+
+| Element | Wohin? |
+|---|---|
+| `<title>` | `<head>` |
+| `<meta charset="UTF-8">` | `<head>` |
+| `<meta name="description">` | `<head>` |
+| `<h1>Willkommen</h1>` | `<body>` |
+| `<p>Text hier</p>` | `<body>` |
+| `<link rel="stylesheet">` | `<head>` |
+
+> **Feedback:** `<head>` = alles, was der Nutzer nicht direkt sieht (Metadaten, Styles, Titel). `<body>` = alles, was im Browser-Fenster angezeigt wird.
+
+---
+
+### F3 – Charset: Was passiert ohne `<meta charset>`?
+**Thema:** HTML – Zeichenkodierung
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was ist die konkrete Konsequenz, wenn `<meta charset="UTF-8">` fehlt oder falsch gesetzt ist?
+
+- [ ] Die Webseite lädt gar nicht.
+- [x] **Sonderzeichen (Umlaute, Emojis) werden als kryptische Symbole dargestellt, weil der Browser die falsche Zeichenkodierung rät.** ✅
+- [ ] Die Seite wird langsamer, da der Browser alle Sprachen durchprobieren muss.
+- [ ] Das CSS wird nicht geladen.
+
+> **Feedback:** Ohne charset nutzt der Browser oft einen Standard wie Latin-1. Bei UTF-8-gespeicherten Dateien → Umlaute und Emojis werden falsch dargestellt (Mojibake).
+
+---
+---
+
+## BLOCK G – CSS
+
+---
+
+### G1 – Spezifität: ID vs. Klasse vs. Element
+**Thema:** CSS Spezifität – Grundregel
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Gegeben:
+```
+p           { color: blue; }
+.highlight  { color: green; }
+#main       { color: red; }
+```
+Ein Element `<p class="highlight" id="main">` wird angezeigt. Welche Farbe?
+
+- [ ] Blau – die Element-Regel steht zuerst im Code.
+- [ ] Grün – Klassen haben immer Vorrang vor IDs.
+- [x] **Rot – die ID `#main` hat die höchste Spezifität (0,1,0,0).** ✅
+- [ ] Rot – die letzte Regel im Code gewinnt immer.
+
+> **Feedback:** Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Reihenfolge im Code ist nur relevant bei gleicher Spezifität.
+
+---
+
+### G2 – Spezifität: Zahlenwerte zuordnen
+**Thema:** CSS Spezifität – Werte
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Selektor-Typ seinen Spezifitätswert zu.
+
+| Selektor-Typ | Spezifitätswert |
+|---|---|
+| Inline-Style (`style="..."`) | 1,0,0,0 |
+| ID (`#main`) | 0,1,0,0 |
+| Klasse (`.highlight`) | 0,0,1,0 |
+| Element (`p`) | 0,0,0,1 |
+
+> **Feedback:** Von höchster zu niedrigster: Inline > ID > Klasse > Element. Die Stelle zählt als Einheit – sie werden nicht aufgezählt.
+
+---
+
+### G3 – Spezifität: Edge Case – 100 Elemente vs. 1 Klasse
+**Thema:** CSS Spezifität – Bonusfrage
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Zwei CSS-Regeln:
+```
+p p p p p p p p p p  { color: blue; }   /* 100× Element */
+.highlight           { color: red; }    /* 1× Klasse */
+```
+Das Element hat die Klasse `highlight`. Welche Farbe gewinnt?
+
+- [ ] Blau – 100 Element-Selektoren = höhere Spezifität als eine Klasse.
+- [x] **Rot – eine Klasse (0,0,1,0) gewinnt immer gegen beliebig viele Element-Selektoren (0,0,0,n).** ✅
+- [ ] Blau – die längere Regel gewinnt immer.
+- [ ] Unentschieden – gleiche Spezifität.
+
+> **Feedback:** Spezifität wird nicht additiv „aufgezählt" innerhalb einer Stelle. Eine Klasse = eine Stelle höher, egal wie viele Elemente.
+
+---
+
+### G4 – `!important` vs. ID
+**Thema:** CSS – `!important`
+**Punkte:** 2
+**Typ:** `[MC]`
+
+```
+#main { color: red; }
+p     { color: blue !important; }
+```
+Welche Farbe hat `<p id="main">`?
+
+- [ ] Rot – ID ist immer spezifischer.
+- [ ] Lila – die Farben mischen sich.
+- [x] **Blau – `!important` durchbricht die normale Spezifitäts-Kaskade, gewinnt sogar gegen IDs.** ✅
+- [ ] Rot – `!important` wird von modernen Browsern ignoriert.
+
+> **Feedback:** `!important` = „Atombombe" im CSS. Überschreibt normale Spezifität. Deshalb: sehr sparsam einsetzen.
+
+---
+
+### G5 – `!important`: Wann und warum vermeiden?
+**Thema:** CSS – `!important` Transfer
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre, was `!important` in CSS tut, und begründe, warum es in der Praxis als „Code Smell" gilt. Nenne eine bessere Alternative.
+
+> **Musterlösung:** `!important` setzt eine Regel auf höchste Priorität, unabhängig von der Spezifität. In der Praxis wird es als Code Smell betrachtet, weil es die normale Kaskade durchbreitet – wenn viele Regeln `!important` haben, wird die Reihenfolge kaum noch vorhersagbar. Bessere Alternative: Spezifität bewusst erhöhen (z. B. durch eine passendere Selektor-Kombination) oder die CSS-Struktur überarbeiten.
+
+---
+
+### G6 – Responsive Design: Mobile First – Welche Farbe?
+**Thema:** CSS Media Queries – Mobile First
+**Punkte:** 2
+**Typ:** `[MC]`
+
+```css
+.container { background: white; }
+@media (min-width: 768px) { .container { background: blue; } }
+@media (min-width: 1024px) { .container { background: green; } }
+```
+Welche Farbe bei 900 px Breite?
+
+- [ ] Weiß – Media-Queries gelten nur ab 1024 px.
+- [ ] Grün – die letzte Media-Query überschreibt immer.
+- [x] **Blau – bei 900 px greift `min-width: 768px` (900 ≥ 768), aber `min-width: 1024px` nicht (900 < 1024).** ✅
+- [ ] Weiß – keine Media-Query greift zwischen den Breakpoints.
+
+> **Feedback:** Mobile First: Basis = white. Bei 900px: 768px-Query greift ✓, 1024px-Query greift ✗ → blau.
+
+---
+
+### G7 – Desktop First: `max-width` erkläre
+**Thema:** CSS Media Queries – Desktop First
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Wie würde eine Media Query für „Desktop First" aussehen (Standard ist Desktop, Anpassung für kleine Screens)?
+
+- [ ] `@media (device-width: small) { ... }`
+- [ ] `@media (min-width: ...)` – bleibt gleich, nur die Reihenfolge ändert sich.
+- [x] **`@media (max-width: ...)` – Stile für Bildschirme, die kleiner als eine bestimmte Breite sind.** ✅
+- [ ] `@media (mobile: true) { ... }`
+
+> **Feedback:** Desktop First: Basis-CSS für große Schirme. `max-width` = „Wenn der Bildschirm schmäler ist als X, dann…" – Ausnahmen für Tablets/Handys.
+
+---
+
+### G8 – Mobile First vs. Desktop First: Vergleich
+**Thema:** CSS Media Queries – Konzept-Vergleich
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre den Unterschied zwischen „Mobile First" und „Desktop First" beim Responsive Design. Welche Media-Query-Eigenschaft nutzt jeder Ansatz, und warum?
+
+> **Musterlösung:** Mobile First: Das Basis-CSS ist für kleine Bildschirme (Handy). Mit `min-width` werden schrittweise Anpassungen für größere Bildschirme hinzugefügt („ab dieser Breite"). Desktop First: Das Basis-CSS ist für große Bildschirme. Mit `max-width` werden Ausnahmen für kleinere Geräte definiert (「bis zu dieser Breite"). Mobile First wird bevorzugt, weil die Mehrheit der Nutzer mobil zugreift und es forced-mobile-first die Grundlage für progressive Enhancement bietet.
+
+---
+---
+
+## BLOCK H – Barrierefreiheit
+
+---
+
+### H1 – Curb-Cut-Effekt: Beispiel identifizieren
+**Thema:** Barrierefreiheit – Curb-Cut-Effekt
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Der Curb-Cut-Effekt beschreibt, wie eine barrierefreie Lösung letztendlich allen zugute kommt. Welches Beispiel demonstriert diesen Effekt?
+
+- [ ] Barrierefreie Webseiten sind langsamer zu laden.
+- [ ] Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.
+- [x] **Untertitel: Gedacht für Gehörlose, helfen aber auch in lauter Umgebung, beim Sprachlernen oder wenn der Ton aus ist.** ✅
+- [ ] Alt-Texte verlverlängern die Ladezeit einer Webseite.
+
+> **Feedback:** Untertitel = klassisches Curb-Cut-Beispiel. Gedacht für eine Gruppe, nützlich für alle. Weitere Beispiele: Alt-Texte (Screen-Reader → auch SEO), semantisches HTML (Zugänglichkeit → auch Wartbarkeit).
+
+---
+
+### H2 – Curb-Cut-Effekt: Freitext
+**Thema:** Barrierefreiheit – Curb-Cut-Effekt Transfer
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre das Konzept des Curb-Cut-Effekts in einem kurzen Absatz. Nenne zwei konkrete Web-Beispiele und erkläre jeweils, wer ursprünglich die Zielgruppe war und wer letztendlich davon profitiert.
+
+> **Musterlösung:** Der Curb-Cut-Effekt beschreibt, wie eine Maßnahme, die primär für Menschen mit Behinderung konzipiert wurde, am Ende allen zugute kommt. (1) Untertitel: primär für Gehörlose – helfen auch in lauter Umgebung, beim Sprachlernen, wenn der Ton aus ist. (2) Alt-Texte für Bilder: primär für Screen-Reader-Nutzer – helfen auch Suchmaschinen (SEO), da sie die Bilder „verstehen" können.
+
+---
+
+### H3 – POUR-Prinzip: Verletzung identifizieren
+**Thema:** WCAG – POUR-Prinzipien
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Die WCAG basieren auf vier Prinzipien (POUR). Welches Szenario beschreibt eine Verletzung des Prinzips „Bedienbarkeit" (Operable)?
+
+- [ ] Der Textkontrast ist zu gering (grau auf hellgrau).
+- [x] **Eine Navigation funktioniert nur per Maus (Hover), ist aber per Tastatur (Tab-Taste) nicht erreichbar.** ✅
+- [ ] Der Inhalt ist in sehr komplizierter Fachsprache geschrieben.
+- [ ] Die Webseite stürzt in alten Browsern ab.
+
+> **Feedback:** „Bedienbar" = die Schnittstelle kann von jedem genutzt werden, auch ohne Maus (nur Tastatur). Kontrast gehört zu „Wahrnehmbar" (Perceivable). Fachsprache gehört zu „Verständlich" (Understandable).
+
+---
+
+### H4 – POUR: Prinzip zum Szenario zuordnen
+**Thema:** WCAG – POUR-Zuordnung
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Szenario das verletzten POUR-Prinzip zu.
+
+| Szenario | Verletztes Prinzip |
+|---|---|
+| Ein Bild hat kein Alt-Text – ein Screen-Reader kann es nicht beschreiben | Wahrnehmbar (Perceivable) |
+| Ein Formulareingabefeld kann nur mit der Maus erreicht werden | Bedienbar (Operable) |
+| Ein automatisch abspielender Ton hat keine Pause-Taste | Bedienbar (Operable) |
+| Der Seitentext ist in extrem kleiner Schrift und kann nicht vergrößert werden | Wahrnehmbar (Perceivable) |
+
+> **Feedback:** Wahrnehmbar = kann der Nutzer es sehen/hören/erkennen? Bedienbar = kann der Nutzer es steuern? Verständlich = kann der Nutzer es verstehen? Robust = funktioniert es mit verschiedenen Technologien?
+
+---
+
+### H5 – POUR: Prinzipien beschreiben
+**Thema:** WCAG – POUR Konzept
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Nenne die vier POUR-Prinzipien der WCAG und erkläre in einem Satz pro Prinzip, was es bedeutet. Nenne je ein konkretes Web-Beispiel für eine Verletzung.
+
+> **Musterlösung:** (1) Perceivable (Wahrnehmbar): Informationen müssen für jeden wahrnehmbar sein. Verletzung: Bild ohne Alt-Text. (2) Operable (Bedienbar): Die Schnittstelle muss von jedem bedient werden können. Verletzung: Navigation nur per Maus. (3) Understandable (Verständlich): Der Inhalt muss verständlich sein. Verletzung: Kein `<lang>`-Attribut → Screen-Reader liest in falscher Sprache vor. (4) Robust (Robust): Der Inhalt muss mit verschiedenen Technologien funktionieren. Verletzung: Proprietäres JavaScript, das nur in Chrome läuft.
+
+---
+---
+
+## BLOCK I – Zusammenfassung-Fragen (Übergreifend)
+
+---
+
+### I1 – Gesamtablauf: Wahl der richtigen Methode
+**Thema:** HTTP + TCP + DNS zusammen
+**Punkte:** 3
+**Typ:** `[ESSAY]`
+
+Ein Nutzer klickt auf einen „Neuen Eintrag erstellen"-Button einer Webanwendung. Beschreibe vom Klick bis zur Antwort des Servers, welche Protokolle beteiligt sind und welche HTTP-Methode verwendet wird.
+
+> **Musterlösung:** (1) Der Browser sendet eine HTTP-Anfrage. Da es sich um eine neue Ressource handelt, nutzt er POST. (2) Vorher: DNS löst den Domain-Namen auf. (3) TCP-Handshake stellt die Verbindung her. (4) POST-Anfrage wird gesendet (Daten im Body). (5) Server verarbeitet, erstellt den Eintrag, antwortet mit 201 Created.
+
+---
+
+### I2 – Gesamtablauf: Störfall analysieren
+**Thema:** Netzwerk + HTTP – Transfer/Problemlösung
+**Punkte:** 3
+**Typ:** `[ESSAY]`
+
+Du rufst eine Webseite auf und erhältst eine Fehlermeldung. Beschreibe drei verschiedene Szenarien, die zu einer Fehlermeldung führen könnten, und erkläre, in welcher „Schicht" des Ablaufs (DNS, TCP, HTTP) das Problem liegt und wie du es erkennst.
+
+> **Musterlösung:** (1) DNS-Fehler: „Der Server wurde nicht gefunden" → DNS konnte den Namen nicht auflösen (z. B. Tippfehler in der URL oder DNS-Server nicht erreichbar). (2) TCP-Fehler: „Die Verbindung wurde verweigert" → Server existiert (IP bekannt), akzeptiert aber keine Verbindung (nicht gestartet, Port blockiert). (3) HTTP-Fehler: 404 → TCP-Verbindung erfolgreich, aber die angeforderte Ressource existiert nicht auf dem Server.
+
+---
+
+---
+---
+
+## BLOCK J – Dateiformate: Grundbegriffe
+
+---
+
+### J1 – Was bedeutet „komprimieren"?
+**Thema:** Grundbegriffe – Kompression
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was bedeutet es, eine Datei zu komprimieren?
+
+- [ ] Die Datei wird auf einem anderen Speichermedium gesichert.
+- [x] **Die Dateigröße wird durch Entfernung oder Vereinfachung von Daten reduziert.** ✅
+- [ ] Die Datei wird verschlüsselt, damit sie kleiner aussieht.
+- [ ] Die Datei wird in ein anderen Format umgewandelt, ohne dass sich die Größe ändert.
+
+> **Feedback:** Kompression = Dateigröße reduzieren. Zwei Familien: verlustfrei (alle Daten bleiben erhalten, z. B. ZIP, PNG) und verlustbehaftet (Daten werden dauerhaft weggeworfen, z. B. JPEG, MP3).
+
+---
+
+### J2 – Verlustfrei vs. verlustbehaftet
+**Thema:** Grundbegriffe – Kompressionsprimitiven
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Format zu, ob es verlustfrei oder verlustbehaftet komprimiert.
+
+| Format | Kompressions-Typ |
+|---|---|
+| JPEG | Verlustbehaftet |
+| PNG | Verlustfrei |
+| MP3 | Verlustbehaftet |
+| ZIP | Verlustfrei |
+| FLAC | Verlustfrei |
+| WebP (lossy) | Verlustbehaftet |
+
+> **Feedback:** Verlustfrei = Originaldaten perfekt rekonstruierbar (ZIP, PNG, FLAC). Verlustbehaftet = Daten dauerhaft weggeworfen, nicht mehr zurückholbar (JPEG, MP3).
+
+---
+
+### J3 – Verlustfrei vs. verlustbehaftet: Erkläre
+**Thema:** Grundbegriffe – Konzept
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre den Unterschied zwischen verlustfreier und verlustbehafteter Kompression. Nenne je ein konkretes Beispiel und erkläre, warum man in unterschiedlichen Situationen unterschiedliche Kompressionstypen wählt.
+
+> **Musterlösung:** Verlustfrei: Alle Originaldaten bleiben erhalten – die Datei kann perfekt rekonstruiert werden (z. B. ZIP, PNG). Verlustbehaftet: Daten werden dauerhaft weggeworfen – die Datei kann nicht mehr perfekt hergestellt werden (z. B. JPEG, MP3). Wahl: Fotos fürs Web → JPEG (verlustbehaftet), weil der Unterschied kaum sichtbar ist und die Datei deutlich kleiner wird. Archivierung oder Grafiken → PNG (verlustfrei), weil Qualitätsverlust inakzeptabel wäre.
+
+---
+
+### J4 – Was bedeutet „skalieren"?
+**Thema:** Grundbegriffe – Skalierung
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was passiert, wenn ein Rasterbild vergrößert wird?
+
+- [ ] Neue Pixel werden aus dem Dateiformat automatisch geladen.
+- [x] **Fehlende Pixel müssen durch Interpolation „erfunden" werden – es entsteht keine neue Information.** ✅
+- [ ] Das Bild wird verlustfrei größer, weil Pixel automatisch duplifiziert werden.
+- [ ] Die Dateigröße bleibt gleich, nur der Zoom im Betrachter ändert sich.
+
+> **Feedback:** Ein Rasterbild hat eine native Auflösung. Alles darüber hinaus = Schätzung (Interpolation). Deshalb werden vergrößerte Rasterbilder unscharf – es gibt einfach keine Daten für die fehlenden Pixel.
+
+---
+
+### J5 – Was bedeutet „konvertieren"?
+**Thema:** Grundbegriffe – Konvertierung
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was bedeutet es, eine Datei zu konvertieren?
+
+- [ ] Die Datei wird komprimiert und umbenannt.
+- [x] **Die Daten werden von einem Format in ein anderes umgewandelt (z. B. JPEG → PNG, MP4 → WebM).** ✅
+- [ ] Die Datei wird verschlüsselt und in ein neues Format gepackt.
+- [ ] Die Dateiendung wird umbenannt, ohne dass sich der Inhalt ändert.
+
+> **Feedback:** Konvertierung = Format-Umwandlung. Der Inhalt bleibt inhaltlich gleich, aber die Art der Speicherung (Kompression, Struktur) ändert sich. Wichtig: Eine Dateiendung umzubenennen ist KEINE Konvertierung.
+
+---
+
+### J6 – Was bedeutet „codieren" und „decodieren"?
+**Thema:** Grundbegriffe – Codec-Konzept
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre, was „codieren" und „decodieren" bedeuten. Erkläre anschließend, warum der Begriff „Codec" aus beiden Wörtern zusammengesetzt ist, und nenne ein konkretes Beispiel.
+
+> **Musterlösung:** Codieren = Daten in ein bestimmtes Format umwandeln (z. B. Rohvideodaten → H.264-komprimiertes Video). Decodieren = das Gegenteil: komprimierte Daten wieder in abspielbare Form zurückwandeln (z. B. H.264 → Pixeldaten für den Bildschirm). Codec = Co(der) + Dec(oder) – ein Algorithmus, der beides kann. Beispiel: H.264 ist ein Video-Codec: Der Encoder erzeugt die komprimierte Datei, der Decoder im Player spielt sie wieder ab.
+
+---
+
+### J7 – Codec vs. Container
+**Thema:** Grundbegriffe – Codec/Container-Unterschied
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Was ist der Unterschied zwischen einem Container und einem Codec bei Videodateien?
+
+- [ ] Container und Codec sind synonyme Begriffe für das gleiche Konzept.
+- [x] **Der Container (z. B. MP4) ist die „Verpackung", die verschiedene Streams zusammenpackt. Der Codec (z. B. H.264) bestimmt, wie der Video-Stream komprimiert wird.** ✅
+- [ ] Der Codec ist die Dateiendung, der Container der Kompressionsalgorithmus.
+- [ ] Ein Container enthält immer genau einen Codec – es kann keine Kombination geben.
+
+> **Feedback:** Container ≠ Codec. Ein MP4-Container kann H.264, H.265 oder AV1 enthalten. Gleiche Endung `.mp4`, unterschiedlicher Inhalt. Der Container packt zusammen (Video, Audio, Untertitel, Metadaten), der Codec komprimiert.
+
+---
+
+### J8 – Codec vs. Container: Zuordnung
+**Thema:** Grundbegriffe – Codec/Container-Zuordnung
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne zu: Container oder Codec?
+
+| Name | Typ |
+|---|---|
+| MP4 | Container |
+| H.264 | Codec |
+| MKV | Container |
+| AAC | Codec |
+| WebM | Container |
+| AV1 | Codec |
+| VP9 | Codec |
+
+> **Feedback:** Container = Dateiformat, das Streams zusammenpackt (MP4, MKV, WebM). Codec = Kompressionsalgorithmus für einen bestimmten Stream (H.264, AV1, AAC).
+
+---
+---
+
+## BLOCK K – Bildformate & Raster vs. Vektor
+
+---
+
+### K1 – Was ist ein Pixel?
+**Thema:** Digitale Bilder – Grundbegriffe
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was ist ein Pixel in einem digitalen Bild?
+
+- [ ] Ein winziges physisches Kameraobjektiv.
+- [x] **Ein einzelner Farbpunkt in einem Rasterbild – der kleinste Baustein.** ✅
+- [ ] Eine Einheit zur Messung der Dateigröße.
+- [ ] Ein Synonym für eine Farbe im RGB-Farbraum.
+
+> **Feedback:** Pixel = Picture Element. Ein digitales Rasterbild ist ein 2D-Array aus Pixeln, jeder mit einem Farbwert (z. B. RGB).
+
+---
+
+### K2 – Speicherbedarf berechnen
+**Thema:** Rastergrafiken – Berechnung
+**Punkte:** 2
+**Typ:** `[NUMERIC]`
+
+Ein Bild ist 1920 × 1080 Pixel groß und nutzt 24-Bit-Farbtiefe (True Color). Wie groß ist das Bild unkomprimiert in Megabyte? (Runde auf eine Dezimalstelle)
+
+**Formel:** Breite × Höhe × (Farbtiefe / 8) = Bytes
+
+**Lösung:** 1920 × 1080 × 3 = 6.220.800 Bytes ≈ **6,2 MB** (±0,1)
+
+> **Feedback:** 24 Bit = 3 Bytes pro Pixel (8 Bit pro Kanal: R, G, B). 1920 × 1080 = 2.073.600 Pixel × 3 Bytes = 6.220.800 Bytes. Durch 1.000.000 ≈ 6,2 MB.
+
+---
+
+### K3 – Farbtiefe: Bedeutung
+**Thema:** Rastergrafiken – Farbtiefe
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jeder Farbtiefe ihre Bedeutung zu.
+
+| Farbtiefe | Bedeutung |
+|---|---|
+| 1 Bit | 2 Farben (Schwarz/Weiß) |
+| 8 Bit | 256 Farben (Graustufen, GIF) |
+| 24 Bit | 16,7 Millionen Farben (True Color, Standard) |
+| 32 Bit | 16,7 Millionen Farben + Alpha (Transparenz) |
+
+> **Feedback:** Bei n Bit gibt es 2ⁿ mögliche Werte. 24 Bit = 8 Bit pro Kanal (R, G, B). 32 Bit = 24 Bit Farbe + 8 Bit Alpha-Kanal für Transparenz.
+
+---
+
+### K4 – Was ist Alpha-Transparenz?
+**Thema:** Rastergrafiken – Transparenz
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was bedeutet ein 32-Bit-Bild gegenüber einem 24-Bit-Bild?
+
+- [ ] Es hat doppelt so viele Pixel.
+- [x] **Es hat einen zusätzlichen Alpha-Kanal (8 Bit), der die Transparenz jedes Pixels speichert.** ✅
+- [ ] Es nutzt eine höhere Auflösung.
+- [ ] Es kann mehr Dateiformate speichern.
+
+> **Feedback:** 32 Bit = 24 Bit (RGB) + 8 Bit Alpha. Der Alpha-Kanal bestimmt, wie durchsichtig jeder Pixel ist (0 = vollständig transparent, 255 = vollständig undurchsichtig). Wichtig für PNGs mit Hintergrund-Transparenz.
+
+---
+
+### K5 – Raster vs. Vektor: Kern-Unterschied
+**Thema:** Raster vs. Vektor – Konzept
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Was ist der fundamentale Unterschied zwischen Raster- und Vektorgrafiken?
+
+- [ ] Vektorgrafiken sind immer farbiger als Rastergrafiken.
+- [x] **Rastergrafiken speichern einzelne Pixel; Vektorgrafiken speichern geometrische Beschreibungen (Pfade, Formen), die beliebig skaliert werden können.** ✅
+- [ ] Rastergrafiken können keine Farben darstellen, Vektorgrafiken schon.
+- [ ] Der Unterschied liegt nur in der Dateiendung, nicht im Inhalt.
+
+> **Feedback:** Raster = „Malen nach Zahlen" (jeder Pixel einzeln). Vektor = „Bauanleitung" (Formen beschreiben). Diese Unterschied bestimmt alles: Skalierung, Dateigröße, Einsatzbereich.
+
+---
+
+### K6 – Raster vs. Vektor: Vergleich
+**Thema:** Raster vs. Vektor – Eigenschaften zuordnen
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jeder Eigenschaft zu: Raster oder Vektor?
+
+| Eigenschaft | Typ |
+|---|---|
+| Skalierung ohne Qualitätsverlust | Vektor |
+| Ideal für Fotos | Raster |
+| Dateigröße abhängig von der Auflösung | Raster |
+| Ideal für Logos und Icons | Vektor |
+| Speicherung als 2D-Array von Pixeln | Raster |
+| Dateigröße abhängig von der Komplexität | Vektor |
+
+> **Feedback:** Raster = Pixel-basiert, auflösungsabhängig, ideal für Fotos. Vektor = Beschreibungs-basiert, beliebig skalierbar, ideal für Grafiken/Logos.
+
+---
+
+### K7 – Skalierung: Warum werden Rasterbilder unscharf?
+**Thema:** Rastergrafiken – Skalierung Transfer
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre, warum ein Rasterbild beim Vergrößern unscharf wird, während ein Vektorbild bei beliebiger Größe scharf bleibt. Nenne einen konkreten Anwendungsfall, in dem diese Eigenschaft ausschlaggebend ist.
+
+> **Musterlösung:** Ein Rasterbild hat eine feste Auflösung (eine bestimmte Anzahl von Pixeln). Beim Vergrößern müssen neue Pixel „erfunden" werden (Interpolation) – es gibt keine echten Daten für die fehlenden Stellen → Unschärfe. Ein Vektorbild speichert nur Beschreibungen (Pfade, Formen). Beim Vergrößern werden einfach die Koordinaten skaliert – keine Information geht verloren → immer scharf. Anwendungsfall: Ein Logo auf einer Visitenkarte UND auf einem Plakat → SVG nutzen, damit es bei beliebiger Größe scharf bleibt.
+
+---
+
+### K8 – Vektor → Raster: Wie heißt das?
+**Thema:** Raster vs. Vektor – Konvertierung
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Wie heißt der Prozess, bei dem eine Vektorgrafik in eine Rastergrafik umgewandelt wird?
+
+- [ ] Vektorisierung
+- [x] **Rasterisierung** ✅
+- [ ] Pixelierung
+- [ ] Komprimierung
+
+> **Feedback:** Rasterisierung = Vektor → Raster (trivial, immer möglich). Der umgekehrte Prozess (Raster → Vektor) heißt „Tracing" und funktioniert oft nur unbefriedigend.
+
+---
+
+### K9 – Interpolation: Welches Verfahren wofür?
+**Thema:** Rastergrafiken – Interpolationsverfahren
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Interpolationsverfahren seine Eigenschaft zu.
+
+| Verfahren | Eigenschaft |
+|---|---|
+| Nearest Neighbor | Schnell, pixelig – gut für Pixel-Art |
+| Bilinear | Glättet, Standard-Verfahren |
+| Bicubic | Hohe Qualität, rechenintensiver |
+| Lanczos | Beste Qualität, mathematisch komplex |
+
+> **Feedback:** Bei der Wahl: Pixel-Art → Nearest Neighbor (soll pixelig bleiben). Normale Bilder → Bilinear oder Bicubic. Maximale Qualität bei Fotos → Lanczos.
+
+---
+---
+
+## BLOCK L – JPEG: Innenleben
+
+---
+
+### L1 – JPEG: Verlustfrei oder verlustbehaftet?
+**Thema:** JPEG – Grundeigenschaft
+**Punkte:** 1
+**Typ:** `[MC]`
+
+JPEG ist ein …
+
+- [x] **…verlustbehaftetes Bildformat. Beim Speichern werden Daten dauerhaft weggeworfen.** ✅
+- [ ] …verlustfreies Bildformat wie PNG.
+- [ ] …Videoformat für Streaming.
+- [ ] …Vektorgrafik-Format.
+
+> **Feedback:** JPEG = Joint Photographic Experts Group. Verlustbehaftet: Beim Speichern werden Daten dauerhaft weggeworfen – eine gespeicherte JPEG kann nicht perfekt zum Original zurückgeführt werden. Quality 100 ≠ verlustfrei, nur „wenig wegwerfen".
+
+---
+
+### L2 – Psychovisuelle Kompression: Das Auge austricksen
+**Thema:** JPEG – Wahrnehmungsprinzip
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Wie nutzt JPEG die Schwächen des menschlichen Auges aus?
+
+- [ ] Das Auge kann keine Farben wahrnehmen – daher werden Farben komplett entfernt.
+- [x] **Das Auge sieht Helligkeit besser als Farbe. JPEG behält die Helligkeit (Y) voll auf, reduziert aber die Farbauflösung (Cb, Cr) – der Verlust wird kaum wahrgenommen.** ✅
+- [ ] Das Auge kann keine Details sehen – daher werden alle Details entfernt.
+- [ ] JPEG nutzt keine Wahrnehmungsforschung, komprimiert rein mathematisch.
+
+> **Feedback:** Psychovisuelle Kompression = Schwächen des Auges ausnutzen. Kern: Mehr Stäbchen (Helligkeit) als Zapfen (Farbe) im Auge → Helligkeit sichern, Farbe reduzieren. Der Verlust ist für Menschen kaum sichtbar.
+
+---
+
+### L3 – Farbraumkonversion: RGB → YCbCr
+**Thema:** JPEG Schritt 1 – Farbraum
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Warum wird bei JPEG von RGB in YCbCr konvertiert?
+
+- [ ] YCbCr nutzt weniger Speicher pro Pixel als RGB.
+- [x] **In YCbCr sind Helligkeit (Y) und Farbe (Cb, Cr) getrennt – die Farbauflösung kann unabhängig von der Helligkeit reduziert werden.** ✅
+- [ ] RGB kann keine Transparenz darstellen, YCbCr schon.
+- [ ] Die Konvertierung ist ein verlustfreier Schritt, der die Dateigröße halbiert.
+
+> **Feedback:** Y = Helligkeit (Luminanz), Cb/Cr = Farbdifferenzen (Chrominanz). Diese Trennung ermöglicht Chroma Subsampling: Helligkeit voll behalten, Farbe reduzieren – ohne sichtbaren Verlust.
+
+---
+
+### L4 – Chroma Subsampling: Was ist 4:2:0?
+**Thema:** JPEG Schritt 2 – Subsampling
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Was bedeutet das Subsampling-Schema 4:2:0?
+
+- [ ] 4 Pixel teilen sich eine Helligkeit, aber jeder hat eigene Farbe.
+- [x] **4 Pixel teilen sich einen Farbwert (Chrominanz), aber jeder hat eine eigene Helligkeit (Luminanz). Die Farbauflösung wird auf 25% reduziert.** ✅
+- [ ] 4:2:0 bedeutet, dass keine Farbe gespeichert wird – nur Graustufen.
+- [ ] Die Notation beschreibt die Blockgröße, nicht die Farbauflösung.
+
+> **Feedback:** 4:2:0 = JPEG-Standard. Von 4 Pixeln wird nur 1 Farbwert gespeichert (2×2-Block teilt Farbe), aber jeder Pixel behält seine eigene Helligkeit. Ergebnis: 50% Datenreduktion, kaum sichtbar.
+
+---
+
+### L5 – JPEG-Schritte: Richtige Reihenfolge
+**Thema:** JPEG – Kompressionsablauf
+**Punkte:** 2
+**Typ:** `[ORDER]`
+
+Sortiere die Schritte der JPEG-Kompression in der richtigen Reihenfolge:
+
+1. Farbraumkonversion (RGB → YCbCr)
+2. Chroma Subsampling
+3. Block-Aufteilung (8×8)
+4. DCT (Frequenzanalyse)
+5. Quantisierung (hier passiert der Verlust!)
+6. Huffman-Coding (verlustfrei)
+
+> **Feedback:** Der einzige verlustbehaftete Schritt ist die Quantisierung (Schritt 5). Alles davor bereitet die Daten vor, alles danach komprimiert die Ergebnisse verlustfrei weiter.
+
+---
+
+### L6 – Welcher Schritt ist verlustbehaftet?
+**Thema:** JPEG – Verlust lokalisieren
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Bei welchem Schritt der JPEG-Kompression werden Daten dauerhaft weggeworfen?
+
+- [ ] Farbraumkonversion (RGB → YCbCr)
+- [ ] DCT (Discrete Cosine Transform)
+- [x] **Quantisierung – hier werden unwichtige Frequenzkoeffizienten auf Null gesetzt oder vergröbert.** ✅
+- [ ] Huffman-Coding
+
+> **Feedback:** DCT selbst ist verlustfrei und reversibel – es sortiert nur die Daten nach Wichtigkeit. Die Quantisierung ist der einzige verlustbehaftete Schritt: Sie wirft hohe Frequenzen (feine Details) weg. Huffman-Coding danach ist wieder verlustfrei.
+
+---
+
+### L7 – DCT: Was macht sie?
+**Thema:** JPEG – DCT-Prinzip
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was leitet die DCT (Discrete Cosine Transform) bei JPEG?
+
+- [ ] Sie komprimiert die Daten verlustbehaftet.
+- [x] **Sie wandelt 64 Pixelwerte eines 8×8-Blocks in 64 Frequenzkoeffizienten um – sortiert die Information nach Wichtigkeit (niedrige Frequenz = wichtig, hohe Frequenz = Details).** ✅
+- [ ] Sie verschlüsselt die Daten für sichere Übertragung.
+- [ ] Sie reduziert die Farbauflösung des Bildes.
+
+> **Feedback:** DCT = Herzstück von JPEG, aber selbst verlustfrei. Sie sortiert: Der DC-Koeffizient (0,0) = Durchschnittshelligkeit eines Blocks. Die AC-Koeffizienten = Helligkeitsänderungen. 90% der Information steckt in den ersten 10–15 Koeffizienten.
+
+---
+
+### L8 – Huffman-Coding: Prinzip
+**Thema:** JPEG – Huffman
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Wie funktioniert Huffman-Coding?
+
+- [ ] Alle Zeichen bekommen gleich lange Codes – einfach und effizient.
+- [x] **Häufige Werte bekommen kurze Codes, selten vorkommende lange Codes – variable Bitlänge statt fester 8 Bit.** ✅
+- [ ] Huffman-Coding verschlüsselt die Daten zusätzlich.
+- [ ] Es funktioniert nur für Texte, nicht für Bilddaten.
+
+> **Feedback:** Huffman = verlustfrei, optimal für bekannte Häufigkeiten. Präfix-frei: Kein Code ist Anfang eines anderen → eindeutig decodierbar. Auch in ZIP, PNG, MP3 verwendet.
+
+---
+
+### L9 – JPEG-Artefakte: Benennen
+**Thema:** JPEG – Artefakte identifizieren
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem JPEG-Artefakt seine Beschreibung zu.
+
+| Artefakt | Beschreibung |
+|---|---|
+| Blocking | 8×8-Blöcke werden sichtbar als Rechteckmuster |
+| Ringing | „Geister" oder Halos an scharfen Kanten |
+| Posterization | Farbverläufe werden stufig statt fließend |
+
+> **Feedback:** Alle drei sind Folgen der Quantisierung. Blocking: Weil jeder 8×8-Block unabhängig komprimiert wird. Ringing: DCT hat Probleme mit harten Kanten (Gibbs-Phänomen). Posterization: Zu wenige Bits für feine Farbabstufungen.
+
+---
+
+### L10 – JPEG Quality: Sweet Spot
+**Thema:** JPEG – Praktische Qualitätswahl
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Bei welcher JPEG-Quality sind Artefakte für die meisten Menschen kaum sichtbar, aber die Datei trotzdem deutlich kleiner?
+
+- [ ] Quality 30 – hier beginnt die Kompression erst.
+- [ ] Quality 100 – nur hier ist JPEG verlustfrei.
+- [x] **Quality 85–90 – etwa 10× Kompression, für Menschen kaum unterscheidbar vom Original.** ✅
+- [ ] Quality 50 – der optimale Kompromiss für alle Anwendungen.
+
+> **Feedback:** Quality 85–90 = der „Sweet Spot". Quality 100 ≠ verlustfrei (immer noch lossy!). Für Web/Social Media: 60–80 oft ausreichend. Für Archivierung: 90–100 oder besser PNG/RAW.
+
+---
+---
+
+## BLOCK M – Bildformate: PNG, GIF, WebP, SVG
+
+---
+
+### M1 – PNG: Verlustfrei oder verlustbehaftet?
+**Thema:** PNG – Grundeigenschaft
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Wie komprimiert PNG?
+
+- [ ] Verlustbehaftet – wie JPEG, aber mit besserer Qualität.
+- [x] **Verlustfrei – die Originaldaten können perfekt rekonstruiert werden.** ✅
+- [ ] Gar nicht – PNG speichert Daten unkomprimiert.
+- [ ] PNG nutzt eine Kombination aus verlustfrei und verlustbehaftet.
+
+> **Feedback:** PNG nutzt DEFLATE-Kompression (wie ZIP) – verlustfrei. Deshalb ist PNG ideal für Grafiken, Screenshots und Bilder mit Transparenz, aber größer als JPEG für Fotos.
+
+---
+
+### M2 – PNG vs. JPEG: Wann was?
+**Thema:** Bildformate – Formatwahl
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre, wann du PNG und wann JPEG wählen würdest. Nenne je zwei konkrete Anwendungsfälle und begründe deine Wahl.
+
+> **Musterlösung:** PNG: (1) Screenshots – Texte und Linien bleiben scharf, keine Artefakte. (2) Logos mit Transparenz – PNG unterstützt Alpha-Transparenz, JPEG nicht. JPEG: (1) Fotos fürs Web – deutlich kleiner bei kaum sichtbarem Qualitätsverlust. (2) Social Media – Plattformen re-komprimieren sowieso, PNG würde nur unnötig groß sein.
+
+---
+
+### M3 – GIF: Wie viele Farben?
+**Thema:** GIF – Eigenschaften
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Wie viele Farben kann ein GIF-Bild gleichzeitig anzeigen?
+
+- [ ] 16 Farben
+- [ ] 16,7 Millionen Farben
+- [x] **256 Farben (8-Bit-Palette)** ✅
+- [ ] Unbegrenzt – GIF unterstützt alle Farben.
+
+> **Feedback:** GIF = 8-Bit-Palette = 256 Farben maximal. Deshalb sehen GIF-Bilder bei Fotos oft banding/posterisiert aus. GIF überlebt heute wegen Animationen.
+
+---
+
+### M4 – WebP vs. JPEG: Vorteil?
+**Thema:** Bildformate – WebP
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was ist der hauptsächliche Vorteil von WebP gegenüber JPEG?
+
+- [ ] WebP unterstützt Videos, JPEG nicht.
+- [x] **WebP erzeugt bei gleicher Qualität 25–35% kleinere Dateien als JPEG.** ✅
+- [ ] WebP ist verlustfrei, JPEG nicht.
+- [ ] WebP kann keine Fotos speichern, nur Grafiken.
+
+> **Feedback:** WebP (Google, 2010) kann sowohl lossy als auch lossless komprimieren, unterstützt Transparenz und Animationen. Bei gleicher visueller Qualität sind WebP-Dateien deutlich kleiner als JPEG.
+
+---
+
+### M5 – SVG: Was ist es?
+**Thema:** SVG – Grundbegriff
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was ist SVG?
+
+- [ ] Ein verlustbehaftetes Rasterbild-Format wie JPEG.
+- [x] **Ein Vektorgrafik-Format, das Bilder als geometrische Beschreibungen (XML) speichert – beliebig skalierbar ohne Qualitätsverlust.** ✅
+- [ ] Ein Video-Container wie MP4.
+- [ ] Ein komprimiertes Archivformat wie ZIP.
+
+> **Feedback:** SVG = Scalable Vector Graphics. Web-Standard für Vektorgrafiken. Beschreibt WAS gezeichnet werden soll (`<circle>`, `<rect>`, `<path>`), nicht wie jeder Pixel aussieht. Ideal für Logos, Icons, Illustrationen.
+
+---
+
+### M6 – Formatwahl: Szenario zuordnen
+**Thema:** Bildformate – Formatwahl Transfer
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Szenario das optimale Bildformat zu.
+
+| Szenario | Format |
+|---|---|
+| Ein Foto für eine Webseite (klein, OK-Qualität) | JPEG |
+| Ein Screenshot einer Benutzeroberfläche | PNG |
+| Ein Logo, das auf allen Bildschirmgrößen scharf sein muss | SVG |
+| Ein animiertes Reaktionsbild für einen Chat | GIF |
+
+> **Feedback:** JPEG = Fotos (klein, lossy OK). PNG = Screenshots, Grafiken mit Transparenz (verlustfrei). SVG = Logos, Icons (skalierbar). GIF = Animationen (256 Farben, aber Animations-Support).
+
+---
+---
+
+## BLOCK N – Video-Kompression
+
+---
+
+### N1 – Spatial vs. Temporal Compression
+**Thema:** Video – Kompressionsprinzipien
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Prinzip seine Beschreibung zu.
+
+| Prinzip | Beschreibung |
+|---|---|
+| Spatial Compression (Intra-Frame) | Komprimiert jedes einzelne Bild für sich (wie JPEG) |
+| Temporal Compression (Inter-Frame) | Speichert nur die Änderungen zwischen aufeinanderfolgenden Bildern |
+| Motion Compensation | Beschreibt Bewegung durch Vektoren statt Pixel zu kopieren |
+
+> **Feedback:** Spatial = räumlich (innerhalb eines Frames). Temporal = zeitlich (zwischen Frames). Motion Compensation = Bewegungsvektoren. 90% eines Frames ist oft identisch mit dem vorherigen – deshalb ist Temporal-Kompression so wirksam.
+
+---
+
+### N2 – I-Frame, P-Frame, B-Frame: Was ist was?
+**Thema:** Video – Frame-Typen
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Frame-Typ seine Beschreibung zu.
+
+| Frame-Typ | Beschreibung |
+|---|---|
+| I-Frame (Keyframe) | Vollständiges Bild, unabhängig dekodierbar – keine Referenz auf andere Frames |
+| P-Frame | Nur Änderungen gegenüber vorherigen Frames speichern (~30% der Größe eines I-Frames) |
+| B-Frame | Änderungen gegenüber vorherigen UND zukünftigen Frames (~15% der Größe eines I-Frames) |
+
+> **Feedback:** I = Intra (innerhalb). P = Predicted (aus Vergangenheit). B = Bi-directional (Vergangenheit + Zukunft). B-Frames sind am kleinsten, aber brauchen mehr Rechenleistung zum Decodieren.
+
+---
+
+### N3 – Was passiert, wenn ein I-Frame beschädigt ist?
+**Thema:** Video – I-Frame Bedeutung Transfer
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre, warum ein I-Frame bei der Videogespeicherung so wichtig ist. Was passiert, wenn ein einzelner I-Frame in einem Videostream beschädigt wird?
+
+> **Musterlösung:** Ein I-Frame ist ein vollständiges, unabhängig dekodierbare Bild. Alle nachfolgenden P- und B-Frames referenzieren auf vorherige Frames – letztlich auf das letzte I-Frame. Wenn ein I-Frame beschädigt wird, können alle abhängigen P- und B-Frames bis zum nächsten intakten I-Frame nicht mehr korrekt rekonstruiert werden → Videofehler sichtbar bis zum nächsten Keyframe. Deshalb werden typischerweise alle 1–2 Sekunden neue I-Frames eingefügt.
+
+---
+
+### N4 – Motion Compensation: Prinzip
+**Thema:** Video – Motion Compensation
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was beschreibt ein Motion Vector bei der Videogespeicherung?
+
+- [ ] Die Helligkeit eines einzelnen Pixels.
+- [x] **Die Verschiebung eines Bildblocks zwischen zwei Frames (z. B. „verschiebe um +20 Pixel nach rechts").** ✅
+- [ ] Die Kompressionsrate des gesamten Videos.
+- [ ] Die Anzahl der Farben in einem Frame.
+
+> **Feedback:** Motion Compensation speichert Bewegung als Vektoren statt Pixel zu kopieren. Wenn sich ein 16×16-Block von (100,200) auf (120,200) bewegt, wird nur „+20, 0" gespeichert – deutlich kleiner als den Block zweimal zu speichern.
+
+---
+
+### N5 – Video-Codecs: Zeitstrahl
+**Thema:** Video – Codecs-Übersicht
+**Punkte:** 2
+**Typ:** `[ORDER]`
+
+Sortiere die Video-Codecs nach Veröffentlichungsjahr (alt → neu):
+
+1. H.264 / AVC (2003)
+2. H.265 / HEVC (2013)
+3. VP9 (2013)
+4. AV1 (2018)
+
+> **Feedback:** H.264 revolutionierte Streaming. H.265 und VP9 kamen gleichzeitig – H.265 technisch besser, aber Patent-Chaos. AV1 vereint die Industrie: patent-frei, 30% besser als H.265.
+
+---
+
+### N6 – AV1: Warum die Zukunft?
+**Thema:** Video – AV1 Transfer
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre, warum AV1 als „die Zukunft" der Videogespeicherung gilt. Nenne mindestens zwei konkrete Eigenschaften und erkläre, warum H.265 trotz besserer technischer Kompression nicht die gleiche Dominanz erreicht hat.
+
+> **Musterlösung:** AV1 (2018) ist royalty-free und open source – die Alliance for Open Media vereint Google, Netflix, Amazon, Apple, Mozilla. Es liefert 30% bessere Kompression als H.265 und unterstützt 8K, HDR, hohe Frame-Rates. H.265 scheitert vor allem am Patent-Chaos: Drei konkurrierende Patent-Pools (MPEG-LA, HEVC Advance, Velos Media) erzeugen rechtliche Unsicherheit und unklare Kosten → viele Unternehmen bleiben bei H.264 oder wechseln direkt zu AV1.
+
+---
+---
+
+## BLOCK O – Speichermedien & Schnittstellen
+
+---
+
+### O1 – KB vs. KiB: Was ist der Unterschied?
+**Thema:** Speicher – Einheiten
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Eine Festplatte wird als „1 TB" vermarktet, aber Windows zeigt nur ~931 GB an. Warum?
+
+- [ ] Windows zeigt falsche Werte an – das ist ein Bug.
+- [x] **Hersteller nutzen dezimale Einheiten (1 TB = 1.000 GB), Windows nutzt binäre Einheiten (1 TiB = 1.024 GiB). Bei TB-Größen entsteht eine ~7% Diskrepanz.** ✅
+- [ ] Die Festplatte verliert beim Formatieren fast 10% ihrer Kapazität.
+- [ ] Windows reserviert automatisch 10% als Sicherheitspuffer.
+
+> **Feedback:** SI (Dezimal): 1 KB = 1.000 Bytes, 1 MB = 1.000 KB. IEC (Binär): 1 KiB = 1.024 Bytes, 1 MiB = 1.024 KiB. Bei 1 TB: 1.000⁴ vs. 1.024⁴ Bytes → ~7% Unterschied. Windows zeigt binäre Werte an, aber mit SI-Bezeichnung (GB statt GiB) → Verwirrung.
+
+---
+
+### O2 – HDD vs. SSD: Kern-Unterschied
+**Thema:** Speichermedien – HDD vs. SSD
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Was ist der fundamentale technische Unterschied zwischen HDD und SSD?
+
+- [ ] HDDs sind elektronisch, SSDs mechanisch.
+- [x] **HDDs speichern Daten magnetisch auf sich drehenden Plattern (mechanisch). SSDs nutzen Flash-Speicher (elektronisch, keine beweglichen Teile).** ✅
+- [ ] Beide Technologien funktionieren identisch, der Unterschied liegt nur im Gehäuse.
+- [ ] HDDs nutzen Flash-Speicher, SSDs magnetische Platten.
+
+> **Feedback:** HDD = Hard Disk Drive = mechanisch (Platter, Spindel, Schreib-Lese-Kopf). SSD = Solid State Drive = elektronisch (Flash-Speicher). Diese Unterschied bestimmt alles: Geschwindigkeit, Latenz, Geräusche, Haltbarkeit.
+
+---
+
+### O3 – HDD vs. SSD: Eigenschaften zuordnen
+**Thema:** Speichermedien – Vergleich
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jeder Eigenschaft zu: HDD oder SSD?
+
+| Eigenschaft | Typ |
+|---|---|
+| Sequentielle Lesgeschwindigkeit ~150 MB/s | HDD |
+| Sequentielle Lesgeschwindigkeit ~3.500 MB/s | SSD (NVMe) |
+| Latenz ~10 ms | HDD |
+| Latenz ~0,02 ms | SSD |
+| Günstig pro TB (~15€/TB) | HDD |
+| Ideal für Betriebssystem | SSD |
+
+> **Feedback:** Der dramatische Unterschied liegt bei Random Access: SSD ~500× schneller. Deshalb: Betriebssystem auf SSD, Archiv auf HDD. Viele nutzen beides: Kleine SSD für System + große HDD für Daten.
+
+---
+
+### O4 – USB-C: Stecker oder Protokoll?
+**Thema:** Schnittstellen – USB-C
+**Punkte:** 2
+**Typ:** `[MC]`
+
+Ein USB-C-Kabel kann langsam sein, obwohl es wie ein „modernes" Kabel aussieht. Warum?
+
+- [ ] USB-C-Kabel sind immer gleich schnell – die Geschwindigkeit liegt am Gerät.
+- [x] **USB-C ist nur ein Steckertyp, kein Protokoll. Ein USB-C-Kabel kann USB 2.0 (480 Mbit/s) bis USB4 (40 Gbit/s) sein – am Stecker nicht erkennbar.** ✅
+- [ ] USB-C-Kabel werden nach einem Jahr automatisch langsamer.
+- [ ] Die Geschwindigkeit hängt nur vom Betriebssystem ab.
+
+> **Feedback:** USB-C = Steckerform. Das Protokoll dahinter kann USB 2.0, 3.2 oder USB4 sein. Ein billiges USB-C-Kabel ist oft nur USB 2.0 mit neuem Stecker. Kabel-Spezifikation prüfen!
+
+---
+
+### O5 – Dateisysteme: Zuordnung
+**Thema:** Dateisysteme – Überblick
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Dateisystem seine ideale Anwendung zu.
+
+| Dateisystem | Ideal für |
+|---|---|
+| FAT32 | USB-Sticks, SD-Karten (maximale Kompatibilität) |
+| NTFS | Windows-Systeme (Journaling, Rechte) |
+| APFS | macOS, iOS (Snapshots, CoW) |
+| ext4 | Linux-Systeme (Journaling, stabil) |
+| exFAT | Große Dateien auf portablen Medien |
+
+> **Feedback:** FAT32 = kleinster gemeinsamer Nenner, aber max. 4 GB pro Datei. exFAT = FAT32 ohne Größenlimits. NTFS/APFS/ext4 = moderne Systeme mit Journaling. Journaling = bei Absturz werden Änderungen nicht verloren.
+
+---
+
+### O6 – FAT32: Warum nicht für große Dateien?
+**Thema:** Dateisysteme – FAT32 Limitation
+**Punkte:** 1
+**Typ:** `[MC]`
+
+Du versuchst, eine 5-GB-Videodatei auf einen FAT32-formatierten USB-Stick zu kopieren. Was passiert?
+
+- [ ] Die Datei wird automatisch aufgeteilt in kleinere Teile.
+- [x] **Der Vorgang fehlschlägt – FAT32 unterstützt keine einzelnen Dateien größer als 4 GB.** ✅
+- [ ] Die Datei wird automatisch komprimiert, bis sie unter 4 GB ist.
+- [ ] FAT32 hat keine Dateigrößenbeschränkung.
+
+> **Feedback:** FAT32-Limit: max. 4 GB pro Datei. Ein 4K-Video oder ISO-Image passt oft nicht. Lösung: USB-Stick mit exFAT oder NTFS formatieren.
+
+---
+
+### O7 – Die 3-2-1-Regel
+**Thema:** Backup – Prinzip
+**Punkte:** 2
+**Typ:** `[ESSAY]`
+
+Erkläre die 3-2-1-Regel für Backups. Begründe, warum jede der drei Ziffern wichtig ist.
+
+> **Musterlösung:** 3 Kopien: Original + 2 Backups. Warum? Das Original kann kaputt gehen, das erste Backup auch – das zweite ist der Sicherheitspuffer. 2 verschiedene Medientypen (z. B. SSD + HDD, oder lokal + Cloud). Warum? Gleiche Medien haben gleiche Schwachstellen (z. B. Batch-Fehler bei HDDs derselben Charge). 1 Kopie an einem anderen Ort (Cloud, anderes Gebäude). Warum? Brand oder Wasserschaden zerstört alles vor Ort; Ransomware verschlüsselt alle angeschlossenen Laufwerke gleichzeitig.
+
+---
+
+### O8 – Backup-Arten: Unterschiede
+**Thema:** Backup – Typen
+**Punkte:** 2
+**Typ:** `[MATCH]`
+
+Ordne jedem Backup-Typ seine Beschreibung zu.
+
+| Backup-Typ | Beschreibung |
+|---|---|
+| Full (Vollständig) | Kompletter Datenbestand jedes Mal – einfach, aber langsam und platzhungrig |
+| Inkrementell | Nur Änderungen seit dem letzten Backup (egal welcher Art) – schnell, aber Wiederherstellung komplex |
+| Differenziell | Änderungen seit dem letzten Voll-Backup – Mittelweg zwischen beiden |
+
+> **Feedback:** Typisches Schema: Sonntag Full, Mo–Sa Inkrementell oder Differenziell. Inkrementell = schnellstes Backup, langsamste Wiederherstellung (Kette aufbauen). Full = langsamstes Backup, schnellste Wiederherstellung.
+
+---
+
+> **Ende des Katalogs – Aktuell: ~120 Fragen across 15 Blöcke.**
+> Abgedeckte Themen: Von-Neumann, TCP/IP, HTTP, DNS, Gesamtablauf, HTML, CSS, Barrierefreiheit, Dateiformate-Grundbegriffe, Bildformate (Raster/Vektor/JPEG/PNG/GIF/WebP/SVG), Video-Kompression, Speichermedien, Schnittstellen, Dateisysteme, Backup.
diff --git a/archive/klausurfragen_it.md b/archive/klausurfragen_it.md
new file mode 100644
index 0000000..e1a5fd9
--- /dev/null
+++ b/archive/klausurfragen_it.md
@@ -0,0 +1,439 @@
+Here is the quiz converted into a clean, readable Markdown format. I have preserved the structure, code snippets, and feedback for each question.
+
+---
+
+# 223015c – Grundlagen IT- und Internettechnik
+
+**WS 2025/26 – Michael Czechowski – HdM Stuttgart**
+**40 Punkte / 40 Minuten**
+
+---
+
+### Q1 – Von-Neumann: Komponenten zuordnen (3 pt)
+
+**Ordne jeder Komponente der Von-Neumann-Architektur ihre Funktion zu.**
+
+* **Rechenwerk (ALU):** Führt arithmetische und logische Operationen durch.
+* **Steuerwerk:** Holt, dekodiert und steuert die Ausführung von Befehlen.
+* **Speicherwerk:** Enthält sowohl Programme als auch Daten (Stored Program Concept).
+* **Ein-/Ausgabe:** Schnittstelle zu externen Geräten wie Tastatur, Bildschirm, Netzwerk.
+* **Bus-System:** Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus.
+
+> **Feedback:** Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).
+
+---
+
+### Q2 – Von-Neumann vs. Harvard (2 pt)
+
+**Ein Arduino-Mikrocontroller nutzt die Harvard-Architektur. Ein modernes Smartphone nutzt eine (modifizierte) Von-Neumann-Architektur.**
+
+**Warum ist die Harvard-Architektur für Echtzeit-Anwendungen auf dem Arduino vorteilhafter, und was wäre der Nachteil, wenn das Smartphone diese Architektur verwenden würde?**
+
+* [ ] Harvard ist langsamer, aber sicherer – daher für Echtzeit geeignet. Smartphones brauchen die Geschwindigkeit nicht.
+* [x] **Harvard nutzt separate Speicher für Code und Daten → paralleler Zugriff, schneller. Beim Smartphone wäre es schwieriger, beliebige Apps zu laden – weniger Flexibilität.** ✅
+* [ ] Beide Architekturen sind funktional identisch – der Unterschied liegt nur im Gehäuse.
+* [ ] Von-Neumann ist schneller durch gemeinsamen Speicher. Harvard wird gewählt, weil Echtzeit-Apps weniger Speicher brauchen.
+
+> **Feedback:** Harvard: separate Code/Daten-Speicher → paralleler Zugriff, schneller. Nachteil: Code und Daten nicht aus gleichem Speicher nahtlos mischbar → weniger Flexibilität, kein „Laden beliebiger Apps" wie bei Von-Neumann.
+
+---
+
+### Q3 – Stored Program Concept (2 pt)
+
+**Vor der Von-Neumann-Architektur mussten bei Maschinen wie dem ENIAC Programme durch Umstecken von Kabeln eingegeben werden.**
+
+**Was konkret ermöglicht das Stored Program Concept, was vorher nicht möglich war? Nenne zwei Beispiele.**
+
+* [ ] Programme werden auf separater Hardware gespeichert → die Hauptspeicher-Kapazität wird ums Doppelte gesteigert.
+* [ ] Die Hardware kann jetzt selbst Befehle erfinden – kein Mensch muss mehr programmieren.
+* [x] **Programme werden als Daten im Speicher abgelegt → z. B. Apps können installiert/gelöscht werden und Multitasking (mehrere Programme gleichzeitig) wird möglich.** ✅
+* [ ] Nur ein einzelnes Programm kann gleichzeitig laufen, aber es kann schneller geladenen werden.
+
+> **Feedback:** Stored Program: Programme werden als Daten im Speicher abgelegt → austauschbar ohne Hardwareänderung. Ermöglicht: Betriebssysteme, Apps installieren/löschen, Multitasking, Updates.
+
+---
+
+### Q4 – HTML: `<head>` vs. `<body>` (2 pt)
+
+**Ein Student erstellt eine Webseite und platziert *alles* im `<body>` – auch den `<title>` und die `<meta name="description">`.**
+
+**Welche zwei konkreten Konsequenzen hat das?**
+
+* [ ] Kein Problem – Browser ignorieren die Unterscheidung zwischen `<head>` und `<body>`.
+* [x] **(1) Der Browser-Tab zeigt keinen Titel an. (2) Suchmaschinen haben keine Beschreibung für das Snippet → schlechte SEO und Screen-Reader können die Seite nicht richtig vorlesen.** ✅
+* [ ] (1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.
+* [ ] Nur das Fehlen von `<meta charset>` ist ein Problem – title und description funktionieren überall.
+
+> **Feedback:** title und meta description gehören in `<head>`. Im `<body>`: (1) kein Titel im Browser-Tab / Suchergebnis, (2) keine Beschreibung für Suchmaschinen/Screen-Reader → SEO und Accessibility beeinträchtigt.
+
+---
+
+### Q5 – Barrierefreiheit: Curb-Cut-Effekt (3 pt)
+
+**Der Curb-Cut-Effekt beschreibt, wie eine barrierefreie Lösung – ursprünglich für Menschen mit Behinderung – letztendlich *allen* zugute kommt.**
+
+**Nenne ein konkretes Web-Beispiel, das diesen Effekt demonstriert, und erkläre, wer davon profitiert.**
+
+* [ ] Barrierefreie Webseiten sind langsamer zu laden – der Curb-Cut-Effekt beschreibt diesen negativen Nebeneffekt.
+* [ ] Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.
+* [x] **Untertitel: Gedacht für Gehörlose, helfen aber auch in lauter Umgebung, beim Sprachlernen oder wenn der Ton aus ist – profitiert fast jedermann.** ✅
+* [ ] **Dark Mode:** Gedacht für Sehbehinderung, hilft auch in dunkler Umgebung – Beispiel für den Curb-Cut-Effekt.
+
+> **Feedback:** Beispiel: Untertitel (für Gehörlose) → helfen auch in lauter Umgebung, beim Sprachlernen, bei Ton aus. Alt-Texte (für Screen-Reader) → helfen auch SEO. Semantisches HTML → besser für alle.
+
+---
+
+### Q6 – European Accessibility Act (2 pt)
+
+**Der European Accessibility Act (EAA) ist seit Juni 2025 in Kraft.**
+
+**Was bedeutet das konkret für ein deutsches E-Commerce-Unternehmen, das eine Webseite betreibt?**
+
+* [ ] Der EAA betrifft nur öffentliche Behörden – private Unternehmen sind ausgenommen.
+* [ ] Das Unternehmen muss nur eine englische Version der Webseite bereitstellen.
+* [x] **Die Webseite muss barrierefreiheitstechnisch WCAG-Standards erfüllen – E-Commerce ist explizit im EAA geregelt. Bei Verstoß: Bußgelder möglich.** ✅
+* [ ] Der EAA regelt nur die Barrierefreiheit von mobilen Apps, nicht von Webseiten.
+
+> **Feedback:** EAA verpflichtet u. a. E-Commerce-Anbieter zur Barrierefreiheit. Die Webseite muss WCAG-Standards erfüllen. Bei Verstoß: Bußgelder bis 100.000 € möglich.
+
+---
+
+### Q7 – TCP/IP: Protokoll → Schicht (3 pt)
+
+**Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.**
+
+* **HTTP:** Anwendung
+* **DNS:** Anwendung
+* **TCP:** Transport
+* **UDP:** Transport
+* **IP:** Internet
+* **Ethernet:** Netzzugang
+
+> **Feedback:** Anwendung: HTTP, DNS, SMTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.
+
+---
+
+### Q8 – Encapsulation: Dateneinheit → Schicht (3 pt)
+
+**Bei der Übertragung wird eine Nachricht von Schicht zu Schicht verpackt (Encapsulation). Ordne jeder Dateneinheit die zugehörige Schicht zu.**
+
+* **Daten:** Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite).
+* **Segment:** Transportschicht – Daten + Ports und Sequenznummern.
+* **Paket:** Internetschicht – Segment + IP-Adressen (Quelle und Ziel).
+* **Frame:** Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme.
+
+> **Feedback:** Daten (Anwendung) → Segment (Transport, +Ports) → Paket (Internet, +IP) → Frame (Netzzugang, +MAC). Merkhilfe: D-S-P-F.
+
+---
+
+### Q9 – IP vs. MAC vs. Port: Transfer-Szenario (3 pt)
+
+**Dein Laptop sendet eine HTTPS-Anfrage an einen Webserver in einem anderen Land. Das Paket durchläuft mehrere Router.**
+
+**Welche der folgenden Aussagen über die Adressen auf dem Weg ist korrekt?**
+
+* [ ] Alle drei Adressen (IP, MAC, Port) ändert sich bei jedem Router.
+* [x] **Die IP-Adresse des Servers bleibt konstant, der Port (443) ändert sich nicht – die MAC-Adresse wird an jedem Router neu gesetzt (lokal, ein Hop).** ✅
+* [ ] Die MAC-Adresse bleibt konstant, die IP-Adresse ändert sich bei jedem Hop.
+* [ ] IP und Port ändert sich, MAC bleibt konstant – MAC ist die globale Adresse.
+
+> **Feedback:** IP-Adresse des Ziel-Servers bleibt konstant (global). MAC-Adresse ändert sich bei jedem Hop (lokal, nächster Router). Port 443 (HTTPS) bleibt konstant.
+
+---
+
+### Q10 – TCP 3-Way-Handshake: Was passiert wäre? (3 pt)
+
+**Der Client sendet ein SYN zum Server. Das SYN-Paket geht verloren – es erreicht den Server nie.**
+
+**Was passiert als nächstes, und warum wird keine Verbindung aufgebaut?**
+
+* [ ] Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist – die Verbindung wird trotzdem aufgebaut.
+* [x] **Der Server kennt die Anfrage nicht → sendet kein SYN-ACK → der Client erhält keine Antwort → keine Verbindung. Der Client wird das SYN nach einem Timeout erneut senden.** ✅
+* [ ] Der Client sendet direkt ein ACK als Fallback – die Verbindung wird mit zwei Paketen aufgebaut.
+* [ ] Das verloren gegangene SYN wird automatisch vom Netzwerk rekonstruiert – kein Problem.
+
+> **Feedback:** Der Server erhält kein SYN → sendet kein SYN-ACK zurück → der Client bekommt keine Antwort → Verbindung wird nicht aufgebaut. TCP wird das SYN nach einem Timeout erneut senden (Neuübertragung).
+
+---
+
+### Q11 – TCP vs. UDP: Videostreaming (2 pt)
+
+**Ein Videostreaming-Dienst sendet Daten an deinen Browser. Ein einzelnes Paket geht verloren.**
+
+**Warum wählt der Dienst UDP statt TCP, obwohl ein Paket verloren geht?**
+
+* [ ] UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.
+* [x] **Bei Echtzeit ist Verzögerung schlimmer als Verlust. TCP würde das Paket erneut anfordern → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter.** ✅
+* [ ] TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.
+* [ ] UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.
+
+> **Feedback:** Bei Echtzeit-Video ist Verzögerung schlimmer als Paketverlust. TCP würde das Paket erneut anfordern → Video friert. UDP ignoriert das Verlust → kurzer Artefakt, Video läuft weiter.
+
+---
+
+### Q12 – HTTP-Methoden: Szenario (2 pt)
+
+**Ein Nutzer aktualisiert sein Profilbild auf einer Webseite. Das Foto wird zum Server gesendet und das *alte Bild ersetzt*.**
+
+**Welche HTTP-Methode wird für diese Operation verwendet, und warum nicht GET?**
+
+* [ ] **GET** – GET kann auch Daten senden, wenn eine URL mit Parameter verwendet wird.
+* [x] **PUT – ersetzt eine existierende Ressource. GET ruft nur Daten ab und sendet *keine* Daten zum Server.** ✅
+* [ ] **POST** – POST ist immer für das Ersetzen von Daten zuständig.
+* [ ] **DELETE** – DELETE sendet das neue Foto und löscht gleichzeitig das alte.
+
+> **Feedback:** PUT – Daten ersetzen (eine existierende Ressource wird überschrieben). GET ruft nur Daten ab, sendet keine Daten zum Server.
+
+---
+
+### Q13 – HTTP Status-Codes: Fehlerdiagnose (2 pt)
+
+**Du rufst eine Webseite auf und der Browser zeigt folgende Fehlermeldung an:**
+`HTTP/1.1 503 Service Unavailable`
+
+**Was bedeutet dieser Code, und wer ist für die Behebung zuständig – du oder der Betreiber der Webseite?**
+
+* [ ] Client-Fehler: Du hast die falsche URL eingegeben – ein 5xx-Code bedeutet, dass deine Anfrage falsch war.
+* [ ] Erfolgs-Code: 503 bedeutet, dass der Server die Anfrage erfolgreich umgeleitet hat.
+* [x] **Server-Fehler: Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Betreiber – du kannst nur später erneut versuchen.** ✅
+* [ ] Der Code bedeutet, dass der Server die Seite dauerhaft verschoben hat – du muss die neue URL suchen.
+
+> **Feedback:** 503 ist ein 5xx-Code = Server-Fehler. Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Serverbetreiber, nicht beim Nutzer.
+
+---
+
+### Q14 – DNS: Rolle im Ablauf (2 pt)
+
+**Du gibst `https://hdm-stuttgart.de` in die Adresszeile ein.**
+
+**Was passiert *vor* dem TCP-Handshake, und warum ist dieser Schritt zwingend nötig?**
+
+* [ ] Der Browser sendet direkt den Namen an den Server – DNS wird erst danach für die Verschlüsselung benötigt.
+* [x] **DNS-Auflösung: Der Name `hdm-stuttgart.de` wird in eine IP-Adresse umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen, nicht zu Namen.** ✅
+* [ ] DNS passiert nach dem TCP-Handshake – erst wird die Verbindung aufgebaut, dann der Name aufgelöst.
+* [ ] DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.
+
+> **Feedback:** DNS-Auflösung: Der Name „hdm-stuttgart.de" wird in eine IP-Adresse umgewandelt. TCP braucht eine IP-Adresse – names können nicht direkt verbunden werden.
+
+---
+
+### Q15 – CSS Spezifität: Welche Regel gewinnt? (2 pt)
+
+**Gegeben folgender CSS-Code:**
+
+```css
+p           { color: blue; }      /* (A) */
+.highlight  { color: green; }     /* (B) */
+#main       { color: red; }       /* (C) */
+
+```
+
+**Ein Element `<p class="highlight" id="main">Text</p>` wird angezeigt.**
+**Welche Farbe zeigt der Text an, und warum?**
+
+* [ ] **Blau** – die Element-Regel steht zuerst im Code und hat daher Vorrang.
+* [ ] **Grün** – Klassen-Selektoren haben immer Vorrang vor IDs.
+* [x] **Rot – die ID-Regel `#main` hat die höchste Spezifität (0,1,0,0) und gewinnt über Klasse (0,0,1,0) und Element (0,0,0,1).** ✅
+* [ ] **Rot** – die letzte Regel im Code gewinnt immer, unabhängig vom Selektor-Typ.
+
+> **Feedback:** Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Alle drei Regeln treffen das Element – ID #main gewinnt → rot.
+
+---
+
+### Q16 – Responsive Design: Mobile First (2 pt)
+
+**Ein Developer schreibt folgendes CSS:**
+
+```css
+.container { background: white; }
+
+@media (min-width: 768px) {
+    .container { background: blue; }
+}
+
+@media (min-width: 1024px) {
+    .container { background: green; }
+}
+
+```
+
+**Welche Farbe hat `.container` bei einem Bildschirm von 900 px Breite, und warum?**
+
+* [ ] **Weiß** – Media-Queries gelten nur ab 1024 px, darunter bleibt immer die Basis-Farbe.
+* [ ] **Grün** – die letzte Media-Query überschreibt immer alle vorherigen.
+* [x] **Blau – bei 900 px greift `min-width: 768px` (900 ≥ 768), aber `min-width: 1024px` greift nicht (900 < 1024).** ✅
+* [ ] **Weiß** – bei 900 px greift keine Media-Query, da 900 zwischen den beiden Breakpoints liegt.
+
+> **Feedback:** Mobile First: Basis = white. Bei 900px greift min-width: 768px → blue. min-width: 1024px greift NICHT (900 < 1024). Ergebnis: blau.
+
+---
+
+### Q17 – Zusammen: Reihenfolge eines HTTPS-Aufrufs (1 pt)
+
+**Du gibst eine URL ein. Welche Reihenfolge der Schritte ist korrekt?**
+
+* [ ] (1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK
+* [x] **(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK** ✅
+* [ ] (1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK
+* [ ] (1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK
+
+> **Feedback:** Korrekte Reihenfolge: (1) DNS-Auflösung, (2) TCP 3-Way-Handshake, (3) HTTP-Request (GET), (4) HTTP-Response (200 OK + HTML).
+
+---
+
+### Q18 – Bonusfrage: Spezifität Edge Case (1 pt)
+
+**Es gibt zwei CSS-Regeln für ein `<p>`-Element:**
+
+```css
+p p p p p p p p p p  { color: blue; }   /* 100× Element-Selektor */
+.highlight           { color: red; }    /* 1× Klasse */
+
+```
+
+**Das Element hat die Klasse `highlight`. Welche Farbe gewinnt?**
+
+* [ ] **Blau** – 100 Element-Selektoren ergeben 0,0,0,100 = höhere Spezifität als 0,0,1,0.
+* [x] **Rot – eine Klasse (0,0,1,0) gewinnt immer gegen beliebig viele Element-Selektoren (0,0,0,n). Spezifität-Stellen überschreiben sich, nicht addieren.** ✅
+* [ ] **Blau** – die längere Regel (mehr Selektoren) hat immer höhere Spezifität.
+* [ ] Unentschieden – die Regeln haben exakt gleiche Spezifität.
+
+> **Feedback:** Eine einzelne Klasse (0,0,1,0) schlägt immer hundert Element-Selektoren (0,0,0,100). Spezifität wird nicht additiv „aufgezählt" – die Stelle zählt als Einheit.
+
+---
+
+### Q19 – Von-Neumann: Der Flaschenhals (Engpass)
+
+**Die Von-Neumann-Architektur hat einen bekannten Nachteil, den sogenannten „Von-Neumann-Flaschenhals“. Was ist damit gemeint?**
+
+* [ ] Das Steuerwerk kann Befehle schneller verarbeiten, als das Rechenwerk sie berechnen kann.
+* [x] **Die CPU ist schneller als der Datentransfer über den gemeinsamen Bus. Da Daten und Befehle denselben Bus nutzen, müssen sie nacheinander geladen werden.** ✅
+* [ ] Der Speicher verliert seine Daten, wenn der Strom abgeschaltet wird, was den Startvorgang verlangsamt.
+* [ ] Die Ein-/Ausgabegeräte blockieren den Prozessor dauerhaft, da sie keinen eigenen Speicher haben.
+
+> **Feedback:** Der Flaschenhals entsteht, weil Befehle und Daten sich den gleichen Weg (Bus) teilen müssen und der Speicherzugriff langsamer ist als die CPU-Geschwindigkeit.
+
+---
+
+### Q20 – HTML: Encoding (Charset)
+
+**In Q4 ging es um Metadaten. Ein weiteres wichtiges Tag im `<head>` ist `<meta charset="UTF-8">`. Was ist die konkrete Konsequenz, wenn dieses Tag fehlt oder falsch ist?**
+
+* [ ] Die Webseite lädt gar nicht, da der Browser den Binärcode nicht interpretieren kann.
+* [x] **Sonderzeichen (Umlaute, Emojis) werden als kryptische Symbole („Hieroglyphen“) dargestellt, da der Browser die falsche Zeichenkodierung rät.** ✅
+* [ ] Die Seite wird langsamer, da der Browser erst alle Sprachen der Welt durchprobieren muss.
+* [ ] Das CSS wird nicht geladen, da CSS zwingend UTF-8 voraussetzt.
+
+> **Feedback:** Ohne definierte `charset` (Zeichensatz) nutzt der Browser oft einen Standard (z. B. Latin-1), was bei UTF-8-gespeicherten Dateien zu Darstellungsfehlern bei ä, ö, ü oder Emojis führt.
+
+---
+
+### Q21 – Barrierefreiheit: POUR-Prinzip
+
+**Die WCAG basieren auf vier Prinzipien (POUR). Eines davon ist „Bedienbarkeit“ (Operable). Welches Szenario beschreibt eine Verletzung dieses Prinzips?**
+
+* [ ] Der Textkontrast ist zu gering (grau auf hellgrau), sodass man ihn kaum lesen kann.
+* [x] **Eine Navigation funktioniert nur per Maus (Hover), ist aber per Tastatur (Tab-Taste) nicht erreichbar.** ✅
+* [ ] Der Inhalt ist in sehr komplizierter Fachsprache geschrieben, die ein Laie nicht versteht.
+* [ ] Die Webseite stürzt in alten Browsern ab.
+
+> **Feedback:** „Bedienbar“ bedeutet, dass die Schnittstelle (Buttons, Links) von jedem genutzt werden kann – also auch ohne Maus (nur Tastatur). Kontrast gehört zu „Wahrnehmbar“ (Perceivable).
+
+---
+
+### Q22 – Encapsulation: Die Empfänger-Seite (Decapsulation)
+
+**In Q8 haben wir Daten verpackt. Wenn der Server das Signal empfängt, passiert das Gegenteil (Decapsulation). In welcher Reihenfolge werden die Header *entfernt*?**
+
+* [ ] Anwendung (HTTP) → Transport (TCP) → Internet (IP) → Netzzugang (Ethernet)
+* [ ] Es werden alle Header gleichzeitig entfernt, sobald die Daten im RAM liegen.
+* [x] **Netzzugang (Ethernet-Header weg) → Internet (IP-Header weg) → Transport (TCP-Header weg) → Daten.** ✅
+* [ ] Internet (IP) → Netzzugang (Ethernet) → Transport (TCP) → Anwendung (HTTP)
+
+> **Feedback:** Das Auspacken erfolgt in umgekehrter Reihenfolge wie das Einpacken (Zwiebel-Prinzip). Erst wird der Umschlag (Ethernet) geöffnet, dann das Paket (IP), dann das Segment (TCP).
+
+---
+
+### Q23 – Ports: Wozu genau?
+
+**Wir wissen aus Q9, dass IP-Adressen Computer identifizieren. Wozu genau dient dann die Port-Nummer (z. B. 80 oder 443) auf dem Zielrechner?**
+
+* [ ] Sie bestimmt die Geschwindigkeit der Verbindung.
+* [ ] Sie dient zur Verschlüsselung der Daten.
+* [x] **Sie adressiert den konkreten Dienst bzw. die Anwendung auf dem Computer (z. B. Webserver vs. Mailserver).** ✅
+* [ ] Sie zeigt an, ob der Computer per WLAN oder Kabel verbunden ist.
+
+> **Feedback:** Die IP ist wie die Hausnummer (welches Gebäude?), der Port ist wie die Türnummer oder der Name an der Klingel (wer im Haus soll das Paket bekommen? Webserver? Mailserver?).
+
+---
+
+### Q24 – TCP: Sequenznummern
+
+**TCP ist zuverlässig. Ein Mechanismus dafür sind „Sequenznummern“ im Header. Welches Problem lösen diese konkret?**
+
+* [ ] Sie verhindern, dass Hacker die Verbindung abhören können.
+* [x] **Pakete können im Internet unterschiedliche Routen nehmen und in falscher Reihenfolge ankommen. Sequenznummern erlauben das korrekte Sortieren beim Empfänger.** ✅
+* [ ] Sie zählen, wie viele Benutzer gerade gleichzeitig auf dem Server sind.
+* [ ] Sie bestimmen die maximale Größe einer Datei.
+
+> **Feedback:** Da IP-Pakete überholen können, kommen Teil 2 und Teil 3 vielleicht vor Teil 1 an. TCP sortiert sie anhand der Nummern wieder richtig. UDP macht das nicht.
+
+---
+
+### Q25 – HTTP Methoden: Sicherheit
+
+**Warum sollte man niemals die GET-Methode verwenden, um sensible Daten (z. B. ein Passwort) an den Server zu senden?**
+
+* [ ] GET ist langsamer als POST und Passwörter müssen schnell übertragen werden.
+* [x] **Bei GET stehen die Daten sichtbar in der URL (Browser-Verlauf, Server-Logs, Proxy-Server). Bei POST stehen sie im Body.** ✅
+* [ ] GET erlaubt nur Zahlen, keine Buchstaben.
+* [ ] GET-Anfragen werden vom Server nicht verschlüsselt, POST-Anfragen immer.
+
+> **Feedback:** Parameter bei GET hängen an der URL (`?pw=123`). Das ist in der History und in Logs sichtbar. HTTPS verschlüsselt zwar beides auf der Leitung, aber die URL ist an zu vielen Stellen sichtbar.
+
+---
+
+### Q26 – HTTP Status: 404 Not Found
+
+**Du erhältst einen 404-Fehler. In Q13 (503) lag der Fehler beim Server. Wer hat beim 404-Fehler „Schuld“ bzw. wo liegt die Ursache meistens?**
+
+* [ ] Der Server ist abgestürzt.
+* [ ] Das Internet ist ausgefallen.
+* [x] **Der Client (Nutzer). Es wurde eine URL angefordert, die es nicht gibt (Tippfehler oder veralteter Link).** ✅
+* [ ] Der DNS-Server konnte den Namen nicht auflösen.
+
+> **Feedback:** 4xx-Codes sind Client-Errors. Der Server funktioniert super, er sagt dir nur: „Das, was du (Client) suchst, habe ich nicht.“
+
+---
+
+### Q27 – CSS: `!important` vs. ID
+
+**In Q15 hat die ID gewonnen. Nun ändern wir den Code:**
+
+```css
+#main { color: red; }
+p     { color: blue !important; }
+
+```
+
+**Welche Farbe hat das `<p id="main">` Element nun?**
+
+* [ ] **Rot** – ID ist immer noch spezifischer als ein Element-Selektor.
+* [ ] **Lila** – Die Farben mischen sich.
+* [x] **Blau** – `!important` durchbricht die normale Spezifitäts-Kaskade und gewinnt sogar gegen IDs (außer die ID hat auch !important). ✅
+* [ ] **Rot** – `!important` wird von modernen Browsern ignoriert.
+
+> **Feedback:** `!important` ist die „Atombombe“ im CSS. Es überschreibt normale Spezifitätsregeln (ID, Klasse, Element). Es sollte daher sehr sparsam eingesetzt werden.
+
+---
+
+### Q28 – Responsive Design: Desktop First
+
+**In Q16 nutzten wir `min-width` (Mobile First). Wie würde die Media Query aussehen, wenn wir „Desktop First“ arbeiten würden (also Standard ist Desktop, Anpassung für kleine Screens)?**
+
+* [ ] `@media (device-width: small) { ... }`
+* [ ] `@media (min-width: ...)` – das bleibt gleich, nur die Reihenfolge ändert sich.
+* [x] **`@media (max-width: ...)` – Wir definieren Stile für Bildschirme, die *kleiner* als eine bestimmte Breite sind.** ✅
+* [ ] `@media (mobile: true) { ... }`
+
+> **Feedback:** Desktop First bedeutet: Das Basis-CSS ist für große Schirme. Mit `max-width` (maximale Breite) definieren wir Ausnahmen für Geräte, die schmaler sind (Tablets, Handys).

From 64f4729f45679b4bb1775b2610aae9ef5b0b07e6 Mon Sep 17 00:00:00 2001
From: Michael Czechowski <mail@dailysh.it>
Date: Mon, 2 Feb 2026 14:03:54 +0100
Subject: [PATCH 8/8] add erklaerung slides after klausur slides in 223015c

- add section.erklaerung CSS class with pink theme styling
- add 6 explanation slides to 01-geschichte-grundlagen-html.md
- add 10 explanation slides to 02-netzwerke-protokolle-css.md
- each slide includes definition, key points, and mnemonics
---
 .../223015c/01-geschichte-grundlagen-html.md  | 163 ++++++++++
 slides/223015c/02-netzwerke-protokolle-css.md | 284 ++++++++++++++++++
 2 files changed, 447 insertions(+)

diff --git a/slides/223015c/01-geschichte-grundlagen-html.md b/slides/223015c/01-geschichte-grundlagen-html.md
index a3bf414..3ee23ae 100644
--- a/slides/223015c/01-geschichte-grundlagen-html.md
+++ b/slides/223015c/01-geschichte-grundlagen-html.md
@@ -68,6 +68,33 @@ section.aufgabe {
 section.aufgabe footer {
   display: none;
 }
+section.erklaerung {
+  font-size: 1.1rem;
+  background: linear-gradient(180deg, #fff8fa 0%, #fef0f4 100%) !important;
+  border-left: 6px solid #a02060;
+}
+section.erklaerung h1 {
+  font-size: 1.6rem;
+  color: #a02060;
+  margin-bottom: 0.5rem;
+}
+section.erklaerung h2 {
+  font-size: 1.3rem;
+  color: #1f2937;
+  margin-top: 0;
+}
+section.erklaerung ul,
+section.erklaerung ol {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung p {
+  font-size: 1.05rem;
+  line-height: 1.5;
+}
+section.erklaerung table {
+  font-size: 0.95rem;
+}
 </style>
 
 <!-- _class: invert -->
@@ -652,6 +679,26 @@ PRÜFUNGSRELEVANT: 5 Komponenten benennen und erklären können, Stored Program
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Die 5 Komponenten: Erklaerung
+
+**Definition:** Die Von-Neumann-Architektur beschreibt den grundlegenden Aufbau moderner Computer in fuenf Funktionseinheiten.
+
+| Komponente | Aufgabe | Beispiel |
+|------------|---------|----------|
+| **Rechenwerk (ALU)** | Arithmetische & logische Operationen | +, -, ×, ÷, Vergleiche |
+| **Steuerwerk** | Holt, dekodiert und steuert Befehle | Fetch-Decode-Execute-Zyklus |
+| **Speicherwerk** | Speichert Programme UND Daten | RAM, ROM |
+| **Ein-/Ausgabe** | Kommunikation mit Aussenwelt | Tastatur, Monitor, USB |
+| **Bus-System** | Verbindet alle Komponenten | Adress-, Daten-, Steuerbus |
+
+**Merkhilfe:** "**R**echnen, **S**teuern, **S**peichern, **E**in/**A**us, **B**us" (RSSEAB)
+
+---
+
 <!-- _class: klausur -->
 <!-- _header: '' -->
 <!-- _footer: '' -->
@@ -689,6 +736,27 @@ PRÜFUNGSRELEVANT: Warum Von-Neumann revolutionär, Unterschied zu Harvard, Beis
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Von-Neumann-Architektur: Erklaerung
+
+**Definition:** Das revolutionaere Prinzip, dass Programme und Daten im selben Speicher liegen und Programme somit wie Daten behandelt werden koennen.
+
+**Kernpunkte:**
+- **Stored Program Concept:** Programme sind austauschbare Daten
+- **Universalrechner:** Gleiche Hardware fuer beliebige Aufgaben
+- **Software-Flexibilitaet:** Programme koennen geladen, geaendert und geloescht werden
+
+**Vorher (ENIAC):** Programmierung durch Umstecken von Kabeln → Tage fuer jedes neue Programm
+
+**Nachher:** Software als austauschbare Datei → Betriebssysteme, Apps, Updates moeglich
+
+**Harvard-Architektur (Alternative):** Getrennter Speicher fuer Code und Daten → schneller, aber weniger flexibel (Arduino, DSPs)
+
+---
+
 <!-- _class: lead -->
 
 # Vom Militär zum Netz
@@ -1117,6 +1185,30 @@ PRÜFUNGSRELEVANT: Was gehört in <head>, Unterschied zu <body>, wichtigste Meta
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# HTML Metadaten: Erklaerung
+
+**Definition:** Der `<head>`-Bereich enthaelt Informationen ueber das Dokument, die nicht direkt im Browser angezeigt werden.
+
+| Meta-Tag | Zweck | Beispiel |
+|----------|-------|----------|
+| `<title>` | Browser-Tab, Lesezeichen, SEO | "Meine Website" |
+| `<meta charset>` | Zeichenkodierung | UTF-8 fuer Umlaute |
+| `<meta description>` | Suchmaschinen-Snippet | Max. 160 Zeichen |
+| `<meta viewport>` | Mobile Darstellung | width=device-width |
+| `<meta og:image>` | Social Media Vorschau | Bild beim Teilen |
+
+**Wichtige Unterscheidung:**
+- `<head>`: Metadaten (fuer Browser, Suchmaschinen, Social Media)
+- `<body>`: Sichtbarer Inhalt (fuer Menschen)
+
+**Merkhilfe:** "Head = Gehirn (unsichtbar), Body = Koerper (sichtbar)"
+
+---
+
 # HTML-Tags und Attribute
 
 ```html
@@ -1340,6 +1432,29 @@ PRÜFUNGSRELEVANT: Arten von Einschränkungen, Screenreader-Beispiele, WCAG
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Web-Nutzung: Erklaerung
+
+**Definition:** Menschen nutzen das Web auf sehr unterschiedliche Weisen - nicht nur mit Maus und Bildschirm.
+
+**Eingabemethoden:**
+- **Maus/Trackpad:** Klicken, Scrollen, Hover
+- **Tastatur:** Tab-Navigation, Shortcuts, Pfeiltasten
+- **Screenreader:** Vorlesen von Inhalten (NVDA, VoiceOver, JAWS)
+- **Sprache/Augen:** Sprachbefehle, Eye-Tracking, Switch-Geraete
+
+**Arten von Einschraenkungen:**
+- **Permanent:** Blindheit, Taubheit, motorische Einschraenkungen
+- **Temporaer:** Gebrochener Arm, Augen-OP
+- **Situativ:** Sonnenlicht, laute Umgebung, Baby auf Arm
+
+**Merkhilfe:** "a11y" = a + 11 Buchstaben + y = "accessibility"
+
+---
+
 <!-- _class: klausur -->
 <!-- _header: '' -->
 <!-- _footer: '' -->
@@ -1379,6 +1494,28 @@ PRÜFUNGSRELEVANT: EAA kennen, Curb-Cut-Effekt erklären können, Business Case
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Barrierefreiheit: Erklaerung
+
+**Definition:** Barrierefreiheit (Accessibility) bedeutet, dass digitale Inhalte fuer alle Menschen zugaenglich sind - unabhaengig von koerperlichen oder technischen Einschraenkungen.
+
+**Rechtlicher Rahmen:**
+- **European Accessibility Act (EAA):** Seit Juni 2025 EU-weit verpflichtend
+- **BITV 2.0:** Deutsche Verordnung fuer oeffentliche Stellen
+- **Strafen:** Bis zu 100.000 EUR Bussgeld moeglich
+
+**Curb-Cut-Effekt:** Massnahmen fuer Menschen mit Behinderung helfen allen:
+- Untertitel → laute Umgebung, Sprachlernen
+- Kontrast → Sonnenlicht, aeltere Menschen
+- Tastatur-Navigation → Power-User, RSI-Betroffene
+
+**Business Case:** ~15% Menschen mit Behinderung + ~20% Aeltere = 35% potenzielle Zielgruppe
+
+---
+
 # WCAG: Der Standard
 
 **W**eb **C**ontent **A**ccessibility **G**uidelines
@@ -1532,6 +1669,32 @@ Echte NutzerInnen einbeziehen = Gold-Standard
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Barrieren vermeiden: Erklaerung
+
+**Definition:** Praktische Massnahmen zur Pruefung und Sicherstellung der Barrierefreiheit von Webseiten.
+
+**Tastatur-Test (selbst durchfuehren):**
+1. Tab druecken → Springt der Fokus logisch durch die Seite?
+2. Ist der fokussierte Bereich immer sichtbar markiert?
+3. Kann man alle Funktionen ohne Maus bedienen?
+
+**Screenreader-Test:**
+- **Mac:** VoiceOver aktivieren mit `Cmd + F5`
+- **Windows:** NVDA installieren (kostenlos)
+- **Frage:** Ergibt die vorgelesene Seite Sinn?
+
+**Automatische Tools (finden ~30% der Probleme):**
+- axe DevTools, WAVE (Browser-Extensions)
+- Lighthouse (in Chrome DevTools unter F12)
+
+**Merkhilfe WCAG-Prinzipien:** "**P**erceivable, **O**perable, **U**nderstandable, **R**obust" (POUR)
+
+---
+
 
 <!-- _class: lead -->
 
diff --git a/slides/223015c/02-netzwerke-protokolle-css.md b/slides/223015c/02-netzwerke-protokolle-css.md
index 434e9fd..345dfd2 100644
--- a/slides/223015c/02-netzwerke-protokolle-css.md
+++ b/slides/223015c/02-netzwerke-protokolle-css.md
@@ -71,6 +71,33 @@ section.aufgabe footer {
 section.glossar {
   font-size: 1.4rem;
 }
+section.erklaerung {
+  font-size: 1.1rem;
+  background: linear-gradient(180deg, #fff8fa 0%, #fef0f4 100%) !important;
+  border-left: 6px solid #a02060;
+}
+section.erklaerung h1 {
+  font-size: 1.6rem;
+  color: #a02060;
+  margin-bottom: 0.5rem;
+}
+section.erklaerung h2 {
+  font-size: 1.3rem;
+  color: #1f2937;
+  margin-top: 0;
+}
+section.erklaerung ul,
+section.erklaerung ol {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung p {
+  font-size: 1.05rem;
+  line-height: 1.5;
+}
+section.erklaerung table {
+  font-size: 0.95rem;
+}
 </style>
 
 <!-- _class: invert -->
@@ -402,6 +429,29 @@ SPEAKER NOTES:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# TCP/IP-Modell: Erklaerung
+
+**Definition:** Das TCP/IP-Modell beschreibt die Kommunikation im Internet in vier hierarchischen Schichten.
+
+| Schicht | Frage | Protokolle | Dateneinheit |
+|---------|-------|------------|--------------|
+| 4 Anwendung | Was will ich? | HTTP, DNS, SMTP | Daten |
+| 3 Transport | Kommt es an? | TCP, UDP | Segment |
+| 2 Internet | Welcher Rechner? | IP | Paket |
+| 1 Netzzugang | Wie zum Nachbarn? | Ethernet, WLAN | Frame |
+
+**Kernprinzip:** Jede Schicht hat eine Aufgabe und kennt nur ihre Nachbarschichten.
+
+**Encapsulation:** Jede Schicht verpackt die Daten der darueberliegenden Schicht mit eigenem Header.
+
+**Merkhilfe Schichten:** "**A**lle **T**rinken **I**mmer **N**och" (Anwendung-Transport-Internet-Netzzugang)
+
+---
+
 # Schichten verpacken Daten
 
 ```
@@ -461,6 +511,30 @@ SPEAKER NOTES:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Dateneinheiten: Erklaerung
+
+**Definition:** Jede Schicht im TCP/IP-Modell hat eine eigene Bezeichnung fuer die Daten, die sie verarbeitet.
+
+| Schicht | Dateneinheit | Was kommt hinzu? |
+|---------|--------------|------------------|
+| Anwendung | **Daten** (Message) | Anwendungsspezifische Infos |
+| Transport | **Segment** | Ports, Sequenznummern |
+| Internet | **Paket** | IP-Adressen (Quelle, Ziel) |
+| Netzzugang | **Frame** | MAC-Adressen, Pruefsumme |
+
+**Encapsulation-Prozess:**
+```
+Daten → [TCP-Header + Daten] → [IP-Header + Segment] → [Eth-Header + Paket + Eth-Trailer]
+```
+
+**Merkhilfe:** "**D**er **S**ache **P**raktischer **F**olgen" (Daten-Segment-Paket-Frame, von oben nach unten)
+
+---
+
 # Warum ist das clever?
 
 **Ohne Schichten:**
@@ -640,6 +714,29 @@ SPEAKER NOTES:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# IP vs. MAC vs. Port: Erklaerung
+
+**Definition:** Drei verschiedene Adresstypen fuer drei verschiedene Fragen im Netzwerk.
+
+| Adresstyp | Frage | Reichweite | Aendert sich? |
+|-----------|-------|------------|---------------|
+| **IP-Adresse** | Welcher Rechner im Internet? | Global | Nein (Ziel bleibt) |
+| **MAC-Adresse** | Welches Geraet nebenan? | Lokal (1 Hop) | Ja, bei jedem Hop |
+| **Port** | Welches Programm? | Auf einem Rechner | Nein |
+
+**Analogie Briefpost:**
+- **IP** = Empfaengeradresse auf dem Brief (bleibt gleich)
+- **MAC** = "Naechstes Postamt" (aendert sich bei jeder Station)
+- **Port** = Wohnungsnummer im Mehrfamilienhaus
+
+**Merkhilfe:** "**I**P = **I**nternet-weit, **M**AC = **M**omentaner Nachbar, **P**ort = **P**rogramm"
+
+---
+
 <!-- _class: lead -->
 
 # Die Reise eines Klicks
@@ -922,6 +1019,31 @@ SPEAKER NOTES:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# 3-Way-Handshake: Erklaerung
+
+**Definition:** Der TCP-Verbindungsaufbau in drei Schritten, bei dem Client und Server ihre Sequenznummern austauschen.
+
+**Die drei Schritte:**
+1. **SYN** (Client → Server): "Ich will reden, starte bei Seq=1000"
+2. **SYN-ACK** (Server → Client): "OK, ich starte bei Seq=5000, erwarte 1001"
+3. **ACK** (Client → Server): "Verstanden, erwarte 5001 - los geht's!"
+
+**Warum so kompliziert?**
+- Beide Seiten muessen **bereit** sein
+- Sequenznummern werden **synchronisiert** (daher SYN)
+- Verlorene Pakete koennen spaeter **erkannt und nachgefordert** werden
+
+**Analogie Telefonat:**
+- Klingeln → Abheben → "Hallo?" → Gespraech beginnt
+
+**Merkhilfe:** "**S**ag mir → **S**icher, **A**ntworte → **A**lles klar" (SYN → SYN-ACK → ACK)
+
+---
+
 # Nach dem Handshake
 
 **Status:** Die TCP-Verbindung steht.
@@ -1429,6 +1551,31 @@ SPEAKER NOTES:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# TCP vs. UDP: Erklaerung
+
+**Definition:** Die zwei Transport-Protokolle mit unterschiedlichen Garantien und Anwendungsfaellen.
+
+| Eigenschaft | TCP | UDP |
+|-------------|-----|-----|
+| Verbindungsaufbau | Ja (3-Way-Handshake) | Nein |
+| Reihenfolge | Garantiert | Nicht garantiert |
+| Verlorene Pakete | Werden nachgefordert | Gehen verloren |
+| Geschwindigkeit | Langsamer (Overhead) | Schneller |
+
+**Wann TCP?** Wenn **alles ankommen** muss:
+- Web (HTTP/HTTPS), E-Mail, Datei-Downloads
+
+**Wann UDP?** Wenn **Geschwindigkeit** wichtiger ist als Vollstaendigkeit:
+- Video-Calls, Gaming, DNS, Streaming
+
+**Merkhilfe:** "**T**CP = **T**otal **C**omplete **P**ackages" vs. "**U**DP = **U**nsicher, **D**afuer **P**rompt"
+
+---
+
 # Warum UDP bei Video-Calls?
 
 **Szenario:** Ein Paket geht verloren.
@@ -1508,6 +1655,30 @@ Das wird wichtiger, wenn ihr mit REST-APIs arbeitet.
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# HTTP-Methoden: Erklaerung
+
+**Definition:** HTTP-Methoden beschreiben die gewuenschte Aktion auf einer Ressource.
+
+| Methode | Bedeutung | Typischer Einsatz |
+|---------|-----------|-------------------|
+| **GET** | Daten abrufen | Webseite laden, Bild anzeigen |
+| **POST** | Daten senden | Formular absenden, Login |
+| **PUT** | Daten ersetzen | Profil komplett aktualisieren |
+| **PATCH** | Daten teilweise aendern | Einzelnes Feld aendern |
+| **DELETE** | Daten loeschen | Account loeschen |
+
+**Idempotenz:** GET, PUT, DELETE koennen mehrfach ausgefuehrt werden mit gleichem Ergebnis. POST nicht (mehrfach absenden = mehrere Bestellungen).
+
+**REST-APIs:** Nutzen diese Methoden systematisch fuer CRUD-Operationen (Create, Read, Update, Delete).
+
+**Merkhilfe:** "**G**ib mir, **P**oste das, **P**latziere neu, **D**elete" (GET, POST, PUT, DELETE)
+
+---
+
 <!-- _class: klausur -->
 <!-- _header: '' -->
 <!-- _footer: '' -->
@@ -1543,6 +1714,31 @@ Status-Codes sagen euch, was passiert ist.
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# HTTP Status-Codes: Erklaerung
+
+**Definition:** Dreistellige Codes, die der Server zurueckgibt, um das Ergebnis einer Anfrage zu beschreiben.
+
+| Bereich | Bedeutung | Wichtige Codes |
+|---------|-----------|----------------|
+| **2xx** | Erfolg | 200 OK, 201 Created, 204 No Content |
+| **3xx** | Umleitung | 301 Moved Permanently, 304 Not Modified |
+| **4xx** | Client-Fehler | 400 Bad Request, 403 Forbidden, 404 Not Found |
+| **5xx** | Server-Fehler | 500 Internal Error, 502 Bad Gateway, 503 Unavailable |
+
+**Haeufigste Codes im Alltag:**
+- **200:** Alles OK, hier sind die Daten
+- **404:** Seite nicht gefunden (falsche URL)
+- **403:** Zugriff verweigert (keine Berechtigung)
+- **500:** Server hat einen Fehler (nicht eure Schuld)
+
+**Merkhilfe:** "**2**=alles **g**ut, **3**=woanders, **4**=du Fehler, **5**=Server Fehler"
+
+---
+
 <!-- _class: klausur -->
 <!-- _header: '' -->
 <!-- _footer: '' -->
@@ -1579,6 +1775,34 @@ Wie Encapsulation funktioniert.
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Netzwerke Zusammenfassung: Erklaerung
+
+**Der Ablauf eines Webseitenaufrufs:**
+1. **DNS** (UDP:53): Domain → IP-Adresse aufloesen
+2. **TCP-Handshake:** SYN → SYN-ACK → ACK (Verbindung aufbauen)
+3. **HTTP-Request:** GET /index.html (Seite anfordern)
+4. **HTTP-Response:** 200 OK + HTML (Seite erhalten)
+
+**Die 4 Schichten (TCP/IP):**
+
+| Schicht | Protokolle | Dateneinheit |
+|---------|------------|--------------|
+| Anwendung | HTTP, DNS | Daten |
+| Transport | TCP, UDP | Segment |
+| Internet | IP | Paket |
+| Netzzugang | Ethernet | Frame |
+
+**Merkhilfen:**
+- Schichten: "**A**lle **T**rinken **I**mmer **N**och"
+- Dateneinheiten: "**D**er **S**ache **P**raktischer **F**olgen"
+- IP bleibt gleich, MAC aendert sich bei jedem Hop
+
+---
+
 # Werkzeuge zum Selbst-Erkunden
 
 **Im Browser (F12 → Network-Tab):**
@@ -1870,6 +2094,33 @@ Inline-Styles schlagen alles – außer !important, was ihr vermeiden solltet.
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# CSS Spezifitaet: Erklaerung
+
+**Definition:** Spezifitaet bestimmt, welche CSS-Regel gewinnt, wenn mehrere Regeln auf dasselbe Element zutreffen.
+
+**Spezifitaet als 4-stellige Zahl (a,b,c,d):**
+
+| Kategorie | Gewicht | Beispiel |
+|-----------|---------|----------|
+| **a:** Inline-Style | 1,0,0,0 | `style="..."` |
+| **b:** ID | 0,1,0,0 | `#header` |
+| **c:** Klasse, Attribut, Pseudo-Klasse | 0,0,1,0 | `.wichtig`, `:hover` |
+| **d:** Element, Pseudo-Element | 0,0,0,1 | `p`, `::before` |
+
+**Vergleich:** Von links nach rechts, hoehere Zahl gewinnt.
+- 0,1,0,0 > 0,0,99,99 (eine ID schlaegt beliebig viele Klassen)
+
+**Praktische Tipps:**
+- Vermeide IDs in CSS (zu spezifisch)
+- Vermeide `!important` (bricht das System)
+- Nutze Klassen fuer wiederverwendbare Styles
+
+---
+
 # Box-Modell
 
 ```
@@ -2117,6 +2368,39 @@ Das Gegenteil wäre Desktop First mit max-width – aber Mobile First ist heute
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Responsive Design: Erklaerung
+
+**Definition:** Webseiten passen sich automatisch an verschiedene Bildschirmgroessen an (Desktop, Tablet, Smartphone).
+
+**Mobile First Ansatz:**
+1. Basis-CSS fuer kleine Bildschirme schreiben
+2. Mit `@media (min-width: ...)` fuer groessere Bildschirme erweitern
+
+```css
+/* Basis (Mobile) */
+.container { padding: 1rem; }
+
+/* Ab 768px (Tablet) */
+@media (min-width: 768px) { .container { padding: 2rem; } }
+
+/* Ab 1024px (Desktop) */
+@media (min-width: 1024px) { .container { max-width: 1200px; } }
+```
+
+**Typische Breakpoints:**
+- **576px:** Kleine Smartphones
+- **768px:** Tablets
+- **1024px:** Desktop
+- **1200px:** Grosse Bildschirme
+
+**Merkhilfe:** "Mobile First" = Basis klein, dann groesser werden
+
+---
+
 # Zusammenfassung CSS
 
 **Selektoren:**