diff --git a/courses/223015b/slides/2025-12-19-termin-0-intro.md b/courses/223015b/slides/2025-12-19-termin-0-intro.md
new file mode 100644
index 0000000..2365622
--- /dev/null
+++ b/courses/223015b/slides/2025-12-19-termin-0-intro.md
@@ -0,0 +1,228 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+---
+
+
+
+
+
+
+
+
+
+# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+
+**223015b** · Modul "Technik 1" · 1. Semester
+Digital- und Medienwirtschaft
+Hochschule der Medien Stuttgart
+
+**Wintersemester 2025/26**
+
+[https://git.librete.ch/hdm/223015b](https://git.librete.ch/hdm/223015b)
+
+---
+
+
+
+---
+
+
+
+# Willkommen!
+## Termin 1 – Einführung & Grundlagen
+
+---
+
+# Über mich
+
+**Michael Czechowski**
+
+- Irgendwas mit IT, Cloud und AI
+- Schwerpunkte:
+ - Web-Technologien, Barriere-Armut, Systemarchitektur, Open Source
+- Hintergrund:
+ - Philosophie (Uni Stuttgart) -> NO degree
+ - Wirtschafts-Informatik (Leibniz-FH) -> B.Sc.
+- Kontakt: mail@librete.ch
+
+
+
+---
+
+
+
+
+
+---
+
+# AMA (Ask my anything)
+
+*Nur ein Vorschlag ...*
+
+* Hast du alle Bände von AoT daheim?
+* Hast du eine Studierenden-Kneipe mal geleitet?
+* Hast du wirklich 17 Semester Philosophie ohne Abschluss studiert?
+
+---
+
+# Kurze Umfrage
+
+**Bitte Hand heben:**
+
+1) Wer hat schon mal ein Video komprimiert/konvertiert?
+2) Wer kennte die 3-2-1 Regel?
+3) Wer weiß, was der Unterschied zwischen JPEG und PNG ist?
+4) Wer hat schon mal mit APIs gearbeitet?
+5) Wer weiß, was UTF-8 bedeutet?
+6) Wer hat schon mal mit einem CLI gearbeitet?
+6) **Wer hat schon mal etwas mit HTML oder CSS gemacht?** (Hex-Farben wie `#FF0000`?)
+
+
+
+---
+
+# Warum dieses Modul?
+
+**Digitale Medien sind überall** – aber was steckt dahinter?
+
+* Warum ist ein JPEG kleiner als ein PNG?
+* Warum klingt MP3 anders als FLAC?
+* Warum zeigt meine 1 TB Festplatte nur 931 GB?
+* Warum ist USB-C so verwirrend?
+* Wie funktioniert eigentlich Streaming?
+* **→ Die Technik dahinter verstehen!**
+
+
+
+---
+
+# Das Ziel
+
+**Technische Grundlagen verstehen**, um fundierte Entscheidungen treffen zu können.
+
+Als Digital- und Medienwirtschaftler:innen werdet ihr täglich mit technischen Fragen konfrontiert:
+* Welches Format für welchen Zweck?
+* Welche Schnittstelle für welches Gerät?
+* Wie funktioniert die Distribution digitaler Inhalte?
+* **→ Mitreden können – nicht (zwingend) programmieren!**
+
+
+
+---
+
+# Was ihr lernt
+
+**In dieser Veranstaltung erwerbt ihr folgende Kompetenzen:**
+
+* Fundiertes Grundwissen über Daten und Informationen
+* Dateiformate analysieren und verstehen
+* Grundlagen von Kompression (Audio, Bild, Video)
+* Speichermedien unterscheiden
+* Programmier-Schnittstellen kennenlernen
+* APIs und Distributionswege verstehen
+
+
+
+---
+
+# Kursübersicht
+
+**5 Termine:**
+
+| # | Datum | Thema |
+|---|-------|-------|
+| 1 | 19.12.2025 | Bits, Bytes, Zeichenkodierung & Audio |
+| 2 | 09.01.2026 | Bild- & Video-Kompression |
+| 3 | 23.01.2026 | Speichermedien & Schnittstellen |
+| 4 | 30.01.2026 | Distribution, APIs & Zukunft |
+| 5 | TBA | Vertiefung & offene Fragen |
+
+**Format:** Theorie + Hands-On (30-40 Min pro Termin)
+
+
+
+---
+
+# Prüfungsleistung 18.02.
+
+**Nach aktuellem Kenntnisstand:**
+
+* 90 min (40% Grundlagen, 40% Dateiformate, 20% AV)
+* Schriftliche Klausur
+* Teils offene Fragen
+* Vermutlich digital
+* Kein Coding!
+* **Prüfungsrelevant:** Alles in den Folien/im Skript
+
+
+
diff --git a/courses/223015b/slides/2025-12-19-termin-1-grundlagen-text-audio.md b/courses/223015b/slides/2025-12-19-termin-1-grundlagen-text-audio.md
new file mode 100644
index 0000000..be17776
--- /dev/null
+++ b/courses/223015b/slides/2025-12-19-termin-1-grundlagen-text-audio.md
@@ -0,0 +1,1255 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+---
+
+
+
+
+
+
+
+
+
+# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+
+**223015b** · Modul "Technik 1" · 1. Semester
+Digital- und Medienwirtschaft
+Hochschule der Medien Stuttgart
+
+**Wintersemester 2025/26**
+
+[https://git.librete.ch/hdm/223015b](https://git.librete.ch/hdm/223015b)
+
+---
+
+
+
+---
+
+
+
+# Termin 1 – 19.12.2025
+## Grundlagen, Text & Audio
+
+---
+
+
+
+# WTF!?
+
+```
+89 50 4E 47 0D 0A 1A 0A
+00 00 00 0D 49 48 44 52
+00 00 01 90 00 00 01 2C
+```
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Das Bit
+
+**Kleinste Informationseinheit**
+
+- **0 oder 1**
+- AN oder AUS
+- Strom fließt oder nicht
+
+
+
+---
+
+# Das Byte
+
+
+
+---
+
+# Das Byte
+
+**1 Byte = 8 Bits**
+
+```
+0 1 0 0 1 1 0 1
+```
+
+
+
+---
+
+# Das Byte
+
+**1 Byte = 8 Bits**
+
+```
+0 1 0 0 1 1 0 1
+```
+
+2⁸ = **256 Möglichkeiten** (0-255)
+
+
+
+---
+
+# Dateneinheiten
+
+| Einheit | Bytes | Bits | Potenz |
+|---------|-------|------|--------|
+| **1 Byte** | 1 | 8 | 10⁰ |
+| **1 Kilobyte (KB)** | 1.000 | 8.000 | 10³ |
+| **1 Megabyte (MB)** | 1.000.000 | 8 Mio. | 10⁶ |
+| **1 Gigabyte (GB)** | 1 Mrd. | 8 Mrd. | 10⁹ |
+| **1 Terabyte (TB)** | 1 Bio. | 8 Bio. | 10¹² |
+
+
+
+---
+
+# Dateneinheiten (Fortsetzung)
+
+| Einheit | Bytes | Potenz | Beispiel |
+|---------|-------|--------|----------|
+| **1 Petabyte (PB)** | 10¹⁵ | 1.000 TB | Netflix-Gesamtarchiv |
+| **1 Exabyte (EB)** | 10¹⁸ | 1.000 PB | Alle E-Mails weltweit/Tag |
+| **1 Zettabyte (ZB)** | 10²¹ | 1.000 EB | Internet-Traffic 2016 |
+| **1 Yottabyte (YB)** | 10²⁴ | 1.000 ZB | *Noch nie erreicht* |
+
+
+
+---
+
+# Datenwachstum der Menschheit
+
+| 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 |
+
+
+
+---
+
+
+
+
+# Der digitale Wendepunkt (Hilbert-Studie)
+
+| Jahr | Analog | Digital | Digital-Anteil |
+|------|--------|---------|----------------|
+| **1986** | 2,57 EB | 0,02 EB | **1%** |
+| **2000** | ~37 EB | ~13 EB | 25% |
+| **2002** | — | — | **50%** (Wendepunkt) |
+| **2007** | ~18 EB | ~277 EB | **94%** |
+
+**Beobachtung:** Analog blieb nahezu konstant (~2,6 → ~18 EB)
+Digital explodierte: ×14.000 in 21 Jahren
+
+
+
+---
+
+# 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 Nutzern generiert
+
+**Zum Vergleich:**
+- 1 ZB = 250 Milliarden DVDs
+- 181 ZB = Jeder Mensch erzeugt ~23 TB/Jahr
+
+
+
+---
+
+# 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
+
+
+
+---
+
+
+
+
+
+
+
+
+
+---
+
+
+
+
+»256 Shades of Gray«
+
+
+
+
+
+---
+
+# 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)
+
+* *Fällt Euch noch mehr ein?*
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+
+
+# 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 00` = Schwarz | `FF FF FF` = Weiß
+
+
+
+---
+
+
+
+
+
+
+---
+
+# 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!**
+
+
+
+---
+
+# Unicode: Ein Standard für alle
+
+**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)
+
+
+
+---
+
+# Beispiel: Bytes zählen
+
+**Text:** `"Why the heck braucht 💩 4 Bytes?!"`
+
+```
+W h y → je 1 Byte (4 Bytes)
+t h e → je 1 Byte (4 Bytes)
+h e c k → je 1 Byte (4 Bytes)
+ → 1 Byte (Leerzeichen)
+b r a u c h t → je 1 Byte (7 Bytes)
+ → 1 Byte
+💩 → 4 Bytes! (0xF0 9F 92 A9)
+ → 1 Byte
+4 B y t e s ? ! → je 1 Byte (9 Bytes)
+```
+
+**Gesamt: 37 Bytes**
+
+
+
+---
+
+# Hexadezimal: Lesbarkeit
+
+**Binär ist unleserlich:**
+`01001101 01010000 00110011`
+
+**Hexadezimal (Base 16):**
+`4D 50 33` (= "MP3" 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)
+
+
+
+---
+
+
+
+
+
+
+
+
+
+---
+
+
+
+
+
+
+
+
+
+---
+
+
+
+
+
+
+---
+
+# 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.*
+
+
+
+---
+
+# Hands-On: WTF Files
+
+**Aufgabe (30 Min):**
+
+1. Drei Dateien ohne Extension: `wtf1`, `wtf2`, `wtf3`
+ → Download: `materials/` Ordner
+2. Öffne im Hex-Editor
+3. Lies erste 16 Bytes
+4. Identifiziere Format (Magic Number)
+5. Benenne um und öffne
+
+**Tools:** hexed.it (online), HxD, Hex Fiend, Bless
+
+
+
+---
+
+# Fleißaufgabe bis nächste Woche
+
+**Finde eine Datei auf deinem Computer**
+
+1. Öffne im Hex-Editor
+2. Schau dir die ersten 16 Bytes an
+3. Identifiziere die Magic Number (falls vorhanden)
+4. Nächste Woche: Kurze Diskussion
+
+**Bonus:** Finde Datei ohne Magic Number
+
+
+
+---
+
+
+
+# Teil 2: Die MP3-Revolution
+## Psychoakustik & Audio-Kompression
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Das Problem (1990)
+
+**1 Minute CD-Audio:**
+
+- Sample Rate: 44.100 Hz
+- Bit Depth: 16 Bit
+- Stereo: 2 Kanäle
+
+**Rechnung:**
+44.100 × 16 × 2 = 1.411.200 Bits/Sekunde
+≈ **10,6 MB/Minute**
+≈ **635 MB für 60-Min-Album**
+
+**1990:** Festplatten hatten 100-500 MB!
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Was ist 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!)
+
+
+
+---
+
+# Sample Rate vs. Bit Depth
+
+**Zwei Dimensionen der Digitalisierung:**
+
+| Dimension | Was bedeutet es? | CD-Qualität |
+|-----------|------------------|-------------|
+| **Sample Rate** | Messungen pro Sekunde (horizontal) | 44.100 Hz |
+| **Bit Depth** | Genauigkeit pro Messung (vertikal) | 16 Bit |
+
+**16 Bit = 2¹⁶ = 65.536 Lautstärkestufen**
+(von absoluter Stille bis maximaler Lautstärke)
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Zwei Philosophien
+
+**Lossless (Verlustfrei):**
+- Original exakt wiederherstellbar
+- ZIP, PNG, FLAC
+- 30-50% Ersparnis
+
+**Lossy (Verlustbehaftet):**
+- Daten irreversibel verändert
+- JPEG, MP3, H.264
+- 90%+ Ersparnis
+
+
+
+---
+
+# Lossless: Run-Length Encoding
+## Lauflängenkodierung
+
+**Original:**
+```
+AAAAABBBCCCCCCCC
+```
+
+**Komprimiert:**
+```
+5A 3B 8C
+```
+
+**Ersparnis:** 16 → 6 Zeichen (62% Reduktion)
+
+
+
+---
+
+# Lossy: Der Trick
+
+**Kernidee:** Wirf weg, was der Mensch eh nicht wahrnimmt
+
+**JPEG:** Schwächen des Auges
+* Helligkeit besser als Farbe wahrgenommen
+* Große Flächen besser als feine Details
+* **→ Psychovisuell**
+
+
+
+---
+
+# Lossy: Der Trick
+
+**Kernidee:** Wirf weg, was der Mensch eh nicht wahrnimmt
+
+**JPEG:** Schwächen des Auges
+- Helligkeit besser als Farbe wahrgenommen
+- Große Flächen besser als feine Details
+- **→ Psychovisuell**
+
+**MP3:** Schwächen des Ohrs
+* Mittlere Frequenzen besser als hohe/tiefe
+* Laute Töne "maskieren" leise Töne
+* **→ Psychoakustik**
+
+
+
+---
+
+
+
+# Karlheinz Brandenburg
+
+**"Vater der MP3"**
+
+* Diplom-Ingenieur, Universität Erlangen-Nürnberg
+* Fraunhofer IIS (Institut für Integrierte Schaltungen)
+* Forschung ab 1982, Patent 1988
+* Hörte "Tom's Diner" über 10.000 Mal
+
+
+
+---
+
+# 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
+
+
+
+---
+
+
+
+# Suzanne Vega
+
+**"Tom's Diner" (1987)**
+
+- A cappella (keine Instrumente)
+- Klare, hohe Frequenzen
+- Perfekter Stresstest für Kompression
+- Der erste Song, der als MP3 kodiert wurde
+
+
+
+---
+
+# "Tom's Diner"
+
+**Warum dieser Song?**
+
+- A cappella (keine Instrumente)
+- Suzanne Vegas Stimme ist "schwierig"
+- Klare, hohe Frequenzen → Stresstest
+
+> If I could code Suzanne Vega's voice well, I could code anything.
+— Karlheinz Brandenburg
+
+
+
+---
+
+# 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
+
+
+
+---
+
+# 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)
+
+
+
+---
+
+
+
+
+
+
+
+
+
+---
+
+# Der Patentkrieg
+
+**1990er:** Fraunhofer + Thomson halten MP3-Patente
+
+**Lizenzgebühren:**
+- $0,75 pro Decoder
+- $2,50 pro Encoder
+
+**Problem:** Napster (1999) → unkontrollierte Verbreitung
+
+**2017:** Patente laufen aus → MP3 ist frei
+
+
+
+---
+
+
+
+# Napster (1999)
+
+**P2P-Filesharing für MP3s**
+
+- Shawn Fanning, 19 Jahre alt
+- 80 Millionen User in 2 Jahren
+- Musikindustrie verklagt (2001)
+- Pandora's Box: Nicht mehr aufzuhalten
+
+
+
+---
+
+# Napster & Musikindustrie
+
+**1999:** Napster startet
+**2001:** 80 Millionen User
+
+**Musikindustrie:**
+- CDs kosten $15-20
+- MP3s gratis (illegal, aber egal)
+- Einzelne Songs statt Alben
+
+**2001:** Napster verklagt, geschlossen
+
+**Aber:** Pandora's Box offen
+→ LimeWire, Kazaa, BitTorrent, später Spotify
+
+
+
+---
+
+# Kulturelle Revolution
+
+**MP3 veränderte:**
+
+✓ Musik wurde portabel (Walkman → iPod)
+✓ Alben wurden irrelevant (Playlists)
+✓ Musikkonsum explodierte (kostenlos/billig)
+✓ Künstler verloren Kontrolle
+
+**Aber auch:**
+❌ Künstler verdienen weniger pro Stream
+❌ Audio-Qualität sank (Loudness War)
+❌ Physische Medien starben
+
+
+
+---
+
+# Hands-On: MP3 sezieren
+
+**Aufgabe (30 Min):**
+
+1. Lade Lied runter (eigenes oder CC)
+2. Konvertiere in verschiedene Bitraten:
+ - 320 kbps, 128 kbps, 64 kbps
+3. Tool: **Audacity** (kostenlos)
+4. Höre Unterschiede (Kopfhörer!)
+5. Vergleiche Dateigrößen
+
+**Spektrogramm:** Klick auf Track-Name → Spektrogramm
+[https://manual.audacityteam.org/man/spectrogram_view.html](https://manual.audacityteam.org/man/spectrogram_view.html)
+
+
+
+---
+
+# Fleißaufgabe bis nächste Woche
+
+**Nimm ein Lied (eigenes oder CC)**
+
+1. Exportiere: WAV, MP3 320 kbps, MP3 128 kbps
+2. Höre die Unterschiede (Kopfhörer!)
+3. Vergleiche die Dateigrößen
+
+**Bonus:** Niedrigste Bitrate finden, bei der du keinen Unterschied hörst
+
+
+
+---
+
+
+
+# Fragen & Diskussion
+
+**Kontakt:** mail@librete.ch
+**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
+
+---
+
+# Lizenz & Attribution
+
+Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
+
+- Erlaubt Teilen & Anpassen mit Namensnennung
+- Adaptionen müssen unter gleicher Lizenz geteilt werden
+
+Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
+
diff --git a/courses/223015b/slides/2026-01-09-termin-2-bild-audio-video.md b/courses/223015b/slides/2026-01-09-termin-2-bild-audio-video.md
new file mode 100644
index 0000000..eb7c9ff
--- /dev/null
+++ b/courses/223015b/slides/2026-01-09-termin-2-bild-audio-video.md
@@ -0,0 +1,860 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+---
+
+
+
+
+
+
+
+
+
+
+# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+
+**223015b** · Modul "Technik 1" · 1. Semester
+Digital- und Medienwirtschaft
+Hochschule der Medien Stuttgart
+
+**Wintersemester 2025/26**
+
+[https://git.librete.ch/hdm/223015b](https://git.librete.ch/hdm/223015b)
+
+---
+
+
+
+# Termin 2 – 09.01.2026
+## Bild-, Audio- & Videoformate
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Was ist ein Bild?
+
+**Digital = Pixelraster**
+
+**Beispiel: 1920×1080 (Full HD)**
+= 2.073.600 Pixel
+
+**Jedes Pixel = 3 Bytes (RGB)**
+2.073.600 × 3 = **6,2 MB**
+
+**Für EIN Foto!**
+
+
+
+---
+
+# Rastergrafiken (Bitmaps)
+
+**Pixelraster:** Jeder Bildpunkt hat Koordinate + Farbwert
+
+**Eigenschaften:**
+- Je größer das Bild → größere Datei
+- **Verkleinern:** Meist ohne Qualitätsverlust
+- **Vergrößern:** Wird unscharf/pixelig!
+
+**Formate:** JPEG, PNG, GIF, BMP, TIFF, WebP
+
+**Verwendung:** Fotos, Screenshots, komplexe Bilder
+
+
+
+---
+
+# Vektorgrafiken
+
+**Mathematische Beschreibung statt Pixel**
+
+**Kreis speichern:**
+- Rastergrafik: Tausende Pixel
+- Vektorgrafik: Mittelpunkt + Radius (2 Werte!)
+
+**Gespeichert werden:**
+- Form (Kreis, Linie, Pfad...)
+- Position, Farbe, Strichstärke, Füllung
+
+**Vorteil:** Beliebig skalierbar ohne Qualitätsverlust!
+
+**Formate:** SVG, PDF, AI, EPS
+
+
+
+---
+
+# Raster vs. Vektor
+
+| | Rastergrafik | Vektorgrafik |
+|---|---|---|
+| **Basis** | Pixelraster | Mathematische Objekte |
+| **Skalierung** | Qualitätsverlust | Verlustfrei |
+| **Dateigröße** | Abhängig von Auflösung | Abhängig von Komplexität |
+| **Gut für** | Fotos | Logos, Icons, Text |
+| **Formate** | JPEG, PNG, GIF | SVG, PDF, AI |
+
+**Rasterung:** Vektorgrafik → Rastergrafik (für Bildschirm/Druck)
+
+
+
+---
+
+# Lossless: PNG
+
+**PNG = Portable Network Graphics (1996)**
+
+**Funktionsweise:**
+- Vorhersage (Pixel ähneln Nachbarn)
+- Differenz-Encoding
+- DEFLATE-Algorithmus (wie ZIP)
+
+**Kompression:** 20-50% Ersparnis
+
+**Gut für:** Screenshots, Logos, Text
+**Schlecht für:** Fotos
+
+
+
+---
+
+# Lossy: JPEG
+
+**JPEG = Joint Photographic Experts Group (1992)**
+
+**Eigenschaften:**
+- Lossy Kompression
+- 90%+ Platzersparnis möglich
+- Artefakte bei hoher Kompression
+
+**6 MB → 500 KB** (typisch)
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Wie funktioniert JPEG? (1/2)
+
+**Schritt 1: RGB → YCbCr**
+- Y = Helligkeit (Luminanz)
+- Cb/Cr = Farbe (Chrominanz)
+
+**Warum?** Menschen sehen Helligkeit besser als Farbe
+
+**Schritt 2: Chroma Subsampling**
+Farbauflösung reduzieren (4:2:0)
+→ 50% Datenmenge weg, kaum sichtbar
+
+
+
+---
+
+# Wie funktioniert JPEG? (2/2)
+
+**Schritt 3: DCT (Discrete Cosine Transform)**
+Bild in 8×8-Blöcke → Frequenzspektrum
+
+**Schritt 4: Quantisierung**
+Hohe Frequenzen (Details) stark reduzieren
+→ **Hier passiert Datenverlust!**
+
+**Schritt 5: Huffman-Coding**
+Lossless-Kompression der Restdaten
+
+
+
+---
+
+# JPEG Quality
+
+| Quality | Dateigröße | Artefakte |
+|---------|------------|-----------|
+| **100** | ≈2-3 MB | Kaum |
+| **85-90** | ≈200-400 KB | Minimal |
+| **50** | ≈100 KB | Sichtbar |
+
+**Sweet Spot: 85-90**
+10x Kompression, für Menschen kaum unterscheidbar
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Die GIF-Geschichte
+
+**GIF = Graphics Interchange Format (1987)**
+CompuServe (US-Online-Dienst)
+
+**Features:**
+- 256 Farben max (8-bit Palette)
+- Lossless (für Palette)
+- Animationen!
+
+**1994 Twist:** Unisys hält Patent auf LZW-Kompression
+→ Fordert Lizenzgebühren
+
+→ **"Burn All GIFs!" Kampagne**
+
+
+
+---
+
+# PNG vs. GIF
+
+**GIF:**
+✓ Animationen
+✓ Breite Unterstützung
+❌ Nur 256 Farben
+❌ Patent-Probleme (bis 2003)
+
+**PNG:**
+✓ Millionen Farben
+✓ Alpha-Transparenz
+✓ Patent-frei
+❌ Keine Animationen (bis APNG, 2004)
+
+**Ergebnis:** PNG für Grafiken, GIF für Memes!
+
+
+
+---
+
+# WebP & AVIF
+
+**WebP (Google, 2010):**
+- Lossy UND Lossless
+- Animationen
+- 25-35% kleiner als JPEG
+
+**AVIF (2019):**
+- Basiert auf AV1-Video-Codec
+- 50% kleiner als JPEG
+- HDR-Unterstützung
+- Patent-frei
+
+**Problem:** Browser-Support dauert Jahre
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Warum Instagram eure Fotos "ruiniert"
+
+**Upload-Pipeline:**
+1. Dein Foto: 12 MP, 8 MB
+2. Instagram skaliert: max. 1080px
+3. Re-Kompression: JPEG Quality ~75
+4. Endgröße: 200-400 KB
+
+**Warum?**
+- Speicherkosten (Milliarden Fotos!)
+- Ladezeiten (Mobile)
+- Bandbreite (günstiger)
+
+
+
+---
+
+# Hands-On: Kompression vergleichen
+
+**Aufgabe (40 Min):**
+
+1. Hochauflösendes Foto (eigenes oder CC)
+2. Exportiere:
+ - PNG
+ - JPEG Q100, Q85, Q50
+ - WebP (optional)
+3. Tool: **Squoosh.app** (Google-Tool)
+4. Vergleiche: Dateigrößen, sichtbare Unterschiede
+5. Wo werden Artefakte sichtbar?
+
+
+
+---
+
+# Fleißaufgabe bis nächste Woche
+
+**Nimm ein Foto (eigenes oder CC)**
+
+1. Exportiere: PNG, JPEG Q90, JPEG Q50
+2. Vergleiche Größen & Qualität
+3. Welche Quality ist für dich "akzeptabel"?
+4. Wo siehst du zuerst Artefakte?
+
+**Bonus:** Teste WebP oder AVIF
+
+
+
+---
+
+
+
+# Teil 2: Video
+## Kompression & Codecs
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Das Problem: Video ist RIESIG
+
+**1 Minute 4K-Video (3840×2160):**
+
+- 30 fps (Bilder/Sekunde)
+- Jedes Bild: 24,8 MB (unkomprimiert)
+
+**Rechnung:**
+30 × 24,8 MB = **744 MB/Sekunde**
+× 60 Sekunden = **44,6 GB/Minute**
+
+**2-Stunden-Film: 5,3 TB!**
+
+
+
+---
+
+# Container vs. Codec
+
+**Container = Die Box**
+Verpackt Video, Audio, Untertitel, Metadaten
+
+**Beispiele:** MP4, MKV, AVI, MOV
+
+**Codec = Kompressionsalgorithmus**
+Entscheidet, WIE Daten komprimiert werden
+
+**Video-Codecs:** H.264, H.265, VP9, AV1
+**Audio-Codecs:** AAC, MP3, Opus
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Video-Kompression: Drei Prinzipien
+
+**1. Spatial Compression (Intra-Frame)**
+Jedes Bild einzeln (wie JPEG)
+→ I-Frames
+
+**2. Temporal Compression (Inter-Frame)**
+Nur Änderungen zwischen Bildern
+→ P-Frames, B-Frames
+
+**3. Motion Compensation**
+"Ball bewegt sich von A nach B"
+
+
+
+---
+
+# I-Frames, P-Frames, B-Frames
+
+**I-Frame (Intra):**
+Vollständiges Bild (wie JPEG)
+Groß, aber unabhängig
+
+**P-Frame (Predicted):**
+Referenziert vorherige Frames
+Viel kleiner
+
+**B-Frame (Bi-directional):**
+Referenziert vorherige UND zukünftige Frames
+Am effizientesten
+
+**GOP:** I - B - B - P - B - B - P - B - B - I
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# H.264: Der König
+
+**H.264 / AVC (2003)**
+
+**Warum dominant?**
+✓ Exzellente Kompression (100:1 möglich)
+✓ Hardware-Support (jedes Gerät seit ~2010)
+✓ YouTube, Netflix, Blu-ray – alles H.264
+
+**Features:**
+- Variable Block-Größen (16×16 bis 4×4)
+- Deblocking-Filter
+- CABAC-Coding
+
+
+
+---
+
+# Das Patent-Problem
+
+**H.264 ist NICHT frei!**
+
+**MPEG-LA (Patent Pool):**
+- 2.000+ Patente von ~30 Unternehmen
+- Apple, Microsoft, Sony, Panasonic...
+
+**Lizenzgebühren:**
+- Hardware-Decoder: $0,20/Einheit
+- Content-Distribution: Kostenlos für "Internet Broadcast"
+
+**Problem:** Open-Source-Projekte in Grauzone
+
+
+
+---
+
+# H.265 / HEVC
+
+**H.265 (2013):**
+50% bessere Kompression als H.264
+
+**ABER:** Patent-Desaster
+
+**Drei (!) konkurrierende Patent-Pools:**
+- MPEG-LA
+- HEVC Advance
+- Velos Media
+
+→ Viele bleiben bei H.264 oder suchen Alternativen
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# VP9: Googles Antwort
+
+**VP9 (2013):**
+Entwickelt von Google (On2-Akquisition)
+
+**Eigenschaften:**
+✓ Ähnlich H.265-Kompression
+✓ KOSTENLOS, patent-frei (laut Google)
+✓ YouTube nutzt VP9 für 4K
+
+**Nachteile:**
+❌ Hardware-Support langsam
+❌ Höherer CPU-Aufwand
+❌ Nicht universell wie H.264
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# AV1: Die Open-Source-Revolution
+
+**AV1 (2018):**
+Alliance for Open Media: Google, Netflix, Amazon, Microsoft, Apple, Mozilla...
+
+**Ziel:** Patent-freier, moderner Codec
+
+**Features:**
+✓ 30% besser als H.265
+✓ Royalty-free, Open Source
+✓ 8K, HDR, hohe Frame-Rates
+
+**Stand 2025:**
+YouTube, Netflix nutzen AV1 für 4K/8K
+
+
+
+---
+
+# Adaptive Bitrate Streaming
+
+**Problem:** Internet-Geschwindigkeit variiert
+
+**Lösung:** Mehrere Qualitäten parallel
+
+**MPEG-DASH / HLS:**
+- 4K (20 Mbps)
+- 1080p (5 Mbps)
+- 720p (2,5 Mbps)
+- 480p (1 Mbps)
+- 240p (0,5 Mbps)
+
+Segmente: 2-10 Sekunden
+Player wählt dynamisch
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Container im Detail
+
+**MP4:**
+- Standard für Web, Mobile
+- H.264, H.265, AV1
+- DRM-fähig
+
+**MKV (Matroska):**
+- Open Source, extrem flexibel
+- Beliebig viele Audio-/Untertitel-Spuren
+- Fast jeden Codec
+
+**WebM:**
+- Google, Web-optimiert
+- Nur VP9/AV1 + Opus/Vorbis
+
+
+
+---
+
+# Hands-On: Video analysieren
+
+**Aufgabe (40 Min):**
+
+**Tool:** FFmpeg (CLI) oder HandBrake (GUI)
+
+1. Download: CC-Video (Big Buck Bunny, ~1 Min)
+2. Analysiere: `ffmpeg -i video.mp4` oder MediaInfo
+3. Notiere: Container, Codec, Bitrate, Auflösung
+4. Konvertiere:
+ - H.264, 1080p, 5 Mbps
+ - H.265, 1080p, 2,5 Mbps
+5. Vergleiche: Größen, Encoding-Zeit, Qualität
+
+
+
+---
+
+# Fleißaufgabe bis nächste Woche
+
+**Nimm kurzes Video (eigenes oder CC, max. 1 Min)**
+
+1. Analysiere: Container, Codecs, Bitrate
+2. Konvertiere: H.264 + H.265 (gleiche Qualität)
+3. Vergleiche: Dateigrößen, Encoding-Zeiten, visueller Unterschied?
+
+**Bonus:** AV1-Encoding (Warnung: SEHR langsam!)
+
+
+
+---
+
+
+
+# Fragen & Diskussion
+
+**Kontakt:** mail@librete.ch
+**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
+
+---
+
+# Lizenz & Attribution
+
+Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
+
+- Erlaubt Teilen & Anpassen mit Namensnennung
+- Adaptionen müssen unter gleicher Lizenz geteilt werden
+
+Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
+
diff --git a/courses/223015b/slides/2026-01-23-termin-3-speichermedien-schnittstellen.md b/courses/223015b/slides/2026-01-23-termin-3-speichermedien-schnittstellen.md
new file mode 100644
index 0000000..0a6576f
--- /dev/null
+++ b/courses/223015b/slides/2026-01-23-termin-3-speichermedien-schnittstellen.md
@@ -0,0 +1,1459 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+---
+
+
+
+
+
+
+
+
+
+# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+
+**223015b** · Modul "Technik 1" · 1. Semester
+Digital- und Medienwirtschaft
+Hochschule der Medien Stuttgart
+
+**Wintersemester 2025/26**
+
+[https://git.librete.ch/hdm/223015b](https://git.librete.ch/hdm/223015b)
+
+---
+
+
+
+# Termin 3 – 23.01.2026
+## Speichermedien & Schnittstellen
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Rückblick: HDD vs. SSD
+
+**HDD:**
+- Mechanisch, magnetisch
+- Langsam (~150 MB/s)
+- Günstig (~20€/TB)
+- Empfindlich (Stöße!)
+
+**SSD:**
+- Elektronisch, Flash
+- Schnell (~500-7.000 MB/s)
+- Teuer (~80-150€/TB)
+- Write-Zyklen begrenzt
+
+
+
+---
+
+# Speicherkapazität: KB vs. KiB
+
+**Das Problem:** Hersteller vs. Betriebssysteme
+
+| Dezimal (SI) | Binär (IEC) |
+|--------------|-------------|
+| 1 KB = 1.000 Bytes | 1 KiB = 1.024 Bytes |
+| 1 MB = 1.000 KB | 1 MiB = 1.024 KiB |
+| 1 GB = 1.000 MB | 1 GiB = 1.024 MiB |
+| 1 TB = 1.000 GB | 1 TiB = 1.024 GiB |
+
+**1 TB Festplatte → Windows zeigt ~931 GB!**
+
+
+
+---
+
+# HDD: Aufbau & Struktur
+
+**Komponenten:**
+- **Platter:** Magnetisch beschichtete Scheiben
+- **Spindel:** Dreht mit 5.400-7.200 RPM
+- **Schreib-Lese-Kopf:** Schwebt nm-dünn über Platter
+- **Aktuator:** Bewegt Kopf zur richtigen Spur
+
+**Logische Struktur:**
+- **Spuren:** Konzentrische Kreise auf Platter
+- **Sektoren:** Unterteilung der Spuren (512 Bytes)
+- **Zylinder:** Gleiche Spuren aller Platter
+
+
+
+---
+
+# NVMe: Die SSD-Revolution
+
+**NVMe = Non-Volatile Memory Express (2011)**
+
+**Unterschied zu SATA-SSD:**
+- SATA: Max. ~550 MB/s (AHCI-Protokoll)
+- NVMe: Bis zu 7.000+ MB/s (PCIe direkt)
+
+**Formfaktoren:**
+- M.2 (Steckplatz auf Mainboard)
+- U.2 (Serverbereich)
+- PCIe-Karte (ältere Systeme)
+
+
+
+---
+
+# SD-Karten (Speicherkarten)
+
+**SD = Secure Digital (2001)**
+
+**Varianten:**
+- SD: bis 2 GB
+- SDHC: bis 32 GB
+- SDXC: bis 2 TB
+- microSD: Kleinere Bauform
+
+**Geschwindigkeitsklassen:**
+Class 10, UHS-I, UHS-II, V30, V90...
+
+**Einsatz:** Kameras, Smartphones, Raspberry Pi
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Das Rosetta Project
+
+**Long Now Foundation (2002)**
+
+**Ziel:** Dokumentation aller menschlichen Sprachen für die Nachwelt
+
+**Die Rosetta Disk:**
+- 3 Zoll Nickelscheibe
+- 13.000 Seiten mikrogeätzt
+- 1.500+ Sprachen dokumentiert
+- Lesbar mit 1000× Mikroskop
+- Haltbarkeit: 2.000+ Jahre
+
+**Lektion für uns:**
+Digitale Formate veralten – physische Archivierung bleibt relevant
+
+
+
+---
+
+# Was fehlt? Dateisysteme!
+
+**Dateisystem = Bibliothekskatalog für Festplatte**
+
+**Aufgaben:**
+- Dateien speichern & finden
+- Metadaten verwalten
+- Speicherplatz effizient nutzen
+- Fehler erkennen & beheben
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Partitionen & Volumes
+
+**Partition:**
+Zusammenhängender Bereich auf Festplatte
+
+**Volume:**
+Logische Einheit mit Dateisystem
+
+**Beispiel:**
+1 TB HDD → 2 Partitionen
+- 500 GB Windows (NTFS)
+- 500 GB Daten (exFAT)
+
+
+
+---
+
+# Formatierung
+
+**Schnellformatierung:**
+- Löscht nur Metadaten
+- Daten physisch noch da
+- → Datenrettung möglich!
+
+**Vollständige Formatierung:**
+- Überschreibt mit Nullen
+- Dauert länger, aber sicherer
+
+
+
+---
+
+# FAT (File Allocation Table)
+
+**Geschichte:** 1977, Microsoft
+
+**Versionen:**
+- FAT16: Max. 2 GB
+- FAT32: Max. 4 GB Dateien, 2 TB Partitionen
+- exFAT: Keine 4 GB-Grenze
+
+**Vorteil:** Universelle Kompatibilität
+
+**Nachteil:** Keine Rechte, kein Journaling
+
+
+
+---
+
+# NTFS
+
+**NTFS = New Technology File System (1993)**
+
+**Features:**
+✓ Dateien >4 GB (bis 16 EB)
+✓ Zugriffsrechte (ACLs)
+✓ Journaling (Crash-Schutz)
+✓ Kompression & Verschlüsselung
+✓ Shadow Copies
+
+**Nachteil:** Proprietär (nur Windows nativ)
+
+
+
+---
+
+# APFS
+
+**Apple File System (2017)**
+
+**Features:**
+✓ Copy-on-Write (Speicherersparnis!)
+✓ Snapshots (Time Machine)
+✓ Native Verschlüsselung
+✓ SSD-optimiert
+
+**Nachteil:** Nur Apple-Geräte
+
+
+
+---
+
+# ext4
+
+**Fourth Extended File System (2008)**
+Linux-Standard
+
+**Features:**
+✓ Journaling
+✓ Extents (schneller)
+✓ Max. 16 TB Dateien, 1 EB Partitionen
+✓ Online-Defragmentierung
+
+**Nachteil:** Windows/macOS können nicht nativ lesen
+
+
+
+---
+
+# Dateisysteme: Vergleich
+
+| FS | OS | Max. Datei | Features |
+|----|----|-----------:|----------|
+| FAT32 | Alle | 4 GB | Kompatibilität |
+| exFAT | Alle | 16 EB | Flash-optimiert |
+| NTFS | Win | 16 EB | Journaling, ACLs |
+| APFS | macOS | 8 EB | Snapshots, CoW |
+| ext4 | Linux | 16 TB | Journaling |
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Backup: Warum?
+
+**Realität:**
+- Festplatten sterben ohne Vorwarnung
+- Ransomware verschlüsselt Daten
+- Versehentliches Löschen
+- Diebstahl, Brand, Wasserschaden
+
+**Faustregel: 3-2-1**
+Mindestens 3 Kopien, auf mindestens 2 unterschiedlichen Speichermedien und mindestens 1 an einem anderen Ort
+
+
+
+---
+
+# Backup-Arten
+
+**Vollständig (Full):**
+Kompletter Datenbestand
+Langsam, aber einfach
+
+**Inkrementell:**
+Nur Änderungen seit letztem Backup
+Schnell, aber Wiederherstellung komplex
+
+**Differenziell:**
+Änderungen seit letztem Voll-Backup
+Mittelweg
+
+
+
+---
+
+# 3-2-1-Regel
+
+**3** Kopien (Original + 2 Backups)
+
+**2** verschiedene Medientypen (SSD + HDD)
+
+**1** Offsite-Backup (Cloud, externes Lager)
+
+**Beispiel:**
+Laptop + externe Festplatte + Cloud
+
+
+
+---
+
+# Backup-Software
+
+**macOS:** Time Machine
+**Windows:** Veeam Agent (kostenlos)
+**Linux:** rsync, Borg, Restic
+**Plattformübergreifend:** Duplicati, Syncthing
+**Cloud:** Backblaze, Nextcloud
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Langzeitarchivierung: Das Problem
+
+**Digitale Daten altern:**
+- Bit Rot (Degradation)
+- Format-Obsoleszenz (WordPerfect .wpd)
+- Hardware-Obsoleszenz (Diskettenlaufwerke)
+
+**Lösung:**
+Migration + offene Standards
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Magnetbänder (LTO)
+
+**Linear Tape-Open:**
+
+- LTO-9 (2021): 18 TB nativ, 45 TB komprimiert
+- Haltbarkeit: 30 Jahre
+- Kosten: ~5€/TB (Laufwerk ~5.000€)
+- Nutzung: Rechenzentren, Archive
+
+**Air-Gap-Sicherheit:**
+Offline-Band kann nicht von Ransomware verschlüsselt werden
+
+
+
+---
+
+# Optische Medien: CD, DVD, Blu-ray
+
+**Laser liest/schreibt Daten:**
+
+| Medium | Jahr | Kapazität | Wellenlänge |
+|--------|------|-----------|-------------|
+| **CD** | 1982 | 700 MB | 780 nm (Infrarot) |
+| **DVD** | 1996 | 4,7–8,5 GB | 650 nm (Rot) |
+| **Blu-ray** | 2006 | 25–100 GB | 405 nm (Blau) |
+
+**Varianten:** ROM (nur lesen), R (einmal brennen), RW (wiederbeschreibbar)
+
+
+
+---
+
+# Optische Medien: Heute noch relevant?
+
+**Vorteile:**
+- Günstig (Rohlinge ~0,20–2€)
+- Lange Haltbarkeit (bei richtiger Lagerung)
+- Nicht anfällig für Magnetfelder
+
+**Nachteile:**
+- Langsam im Vergleich zu SSD/HDD
+- Begrenzte Kapazität
+- Viele Laptops ohne Laufwerk
+
+**Einsatz heute:**
+Musik-CDs, Film-DVDs/Blu-rays, Software-Distribution, Archive
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# M-DISC (Millennial Disc)
+
+**Eigenschaften:**
+- DVD/Blu-ray-kompatibel
+- Anorganische Metallschicht
+- Haltbarkeit: 1.000 Jahre (Tests)
+- Einsatz: Familienfotos, Archive
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# DNA-Storage (Zukunft)
+
+**Konzept:** Daten in DNA-Sequenzen
+
+**Eigenschaften:**
+- Speicherdichte: 215 Petabyte/Gramm (!!)
+- Haltbarkeit: Tausende Jahre
+- Kosten: Aktuell $3.500/MB
+
+**Beispiele:**
+Microsoft + Twist Bioscience
+Netflix "Biohackers"-Episode (2021)
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Network Attached Storage (NAS)
+
+**NAS = Festplatten im Netzwerk**
+
+**Vorteile:**
+- Zentraler Speicher für alle Geräte
+- RAID-Optionen (Redundanz)
+- Remote-Zugriff möglich
+- Eigene Cloud
+
+**Anbieter:** Synology, QNAP, TrueNAS
+
+**Protokolle:** SMB/CIFS (Windows), NFS (Linux), AFP (Mac legacy)
+
+
+
+---
+
+# Cloud-Speicher: Pro & Contra
+
+**Vorteile:**
+✓ Überall verfügbar
+✓ Kein Hardware-Management
+✓ Automatische Backups
+✓ Skalierbar
+
+**Nachteile:**
+✗ Abhängigkeit vom Anbieter
+✗ Datenschutz-Bedenken (DSGVO!)
+✗ Laufende Kosten
+✗ Internet-Abhängigkeit
+
+**Anbieter:** iCloud, OneDrive, Google Drive, Dropbox, Nextcloud
+
+
+
+---
+
+# Hands-On: S.M.A.R.T. & Backup
+
+**Aufgabe 1 (20 Min):**
+S.M.A.R.T.-Daten auslesen
+- Windows: CrystalDiskInfo
+- macOS/Linux: `smartctl -a /dev/sda`
+- Notiere: Health, Power-On Hours, Temp
+
+**Aufgabe 2 (20 Min):**
+Test-Backup erstellen
+- rsync (Linux/macOS) oder Robocopy (Windows)
+- Simuliere Datenverlust → Wiederherstellung
+
+
+
+---
+
+# Fleißaufgabe bis nächste Woche
+
+**Analysiere dein System:**
+
+1. Welches Dateisystem nutzt deine Hauptpartition?
+2. Hast du ein Backup? Welche Art? Wo?
+3. Lies deine S.M.A.R.T.-Daten aus (CrystalDiskInfo / smartctl)
+
+**Bonus:** Richte automatisches Backup ein
+
+
+
+---
+
+
+
+# Teil 2: Schnittstellen
+## USB-C, HDMI & das Kabel-Chaos
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Was ist eine Schnittstelle?
+
+**Schnittstelle = Verbindung zwischen Systemen**
+
+**Hardware-Schnittstellen:**
+Physischer Anschluss (USB, HDMI, Ethernet)
+
+**Software-Schnittstellen:**
+API (nächste Woche!)
+
+**Heute:** Hardware-Fokus
+
+
+
+---
+
+
+
+# Interne Schnittstellen
+## PCIe, SATA & M.2
+
+---
+
+# PCIe: Der Daten-Highway
+
+**PCI Express (2003):**
+
+- Lanes: x1, x4, x8, x16
+- Gen 3: 1 GB/s pro Lane
+- Gen 4: 2 GB/s pro Lane
+- Gen 5: 4 GB/s pro Lane
+
+**Nutzung:**
+- Grafikkarte (x16)
+- NVMe-SSD (x4)
+- Netzwerkkarte, Sound (x1)
+
+
+
+---
+
+# SATA: Der Standard für Speicher
+
+**Serial ATA (2003):**
+
+- SATA I: 1,5 Gbps (~150 MB/s)
+- SATA II: 3 Gbps (~300 MB/s)
+- SATA III: 6 Gbps (~550 MB/s)
+
+**Vorteile:**
+- Günstig, bewährt
+- Hot-Swap möglich
+- Kabel bis 1m
+
+**Nachteil:** Bottleneck für moderne SSDs
+
+
+
+---
+
+
+
+# Externe Schnittstellen
+## USB, HDMI, DisplayPort & Co.
+
+---
+
+
+
+
+
+
+
+
+---
+
+# USB: Die Idee
+
+**Universal Serial Bus (1996)**
+
+**Ziel:** Ein Kabel für alles
+
+**Vorher:**
+- PS/2 (Maus, Tastatur)
+- Seriell (Modem)
+- Parallel (Drucker)
+- SCSI (Festplatten)
+
+**USB-Versprechen:**
+✓ Ein Stecker, Hot-Pluggable, Stromversorgung
+
+
+
+---
+
+# USB-Versionen: Chaos
+
+| Version | Jahr | Geschwindigkeit | Marketing-Name |
+|---------|------|----------------:|----------------|
+| USB 1.0 | 1996 | 12 Mbps | – |
+| USB 2.0 | 2000 | 480 Mbps | Hi-Speed |
+| USB 3.0 | 2008 | 5 Gbps | USB 3.2 Gen 1 |
+| USB 3.1 | 2013 | 10 Gbps | USB 3.2 Gen 2 |
+| USB 3.2 | 2017 | 20 Gbps | USB 3.2 Gen 2×2 |
+| USB 4 | 2019 | 40 Gbps | USB4 |
+
+**NIEMAND versteht das mehr!**
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# USB-C: Stecker ≠ Geschwindigkeit
+
+**USB-C = Physischer Stecker (2014)**
+
+**Eigenschaften:**
+✓ Reversibel (beide Seiten gleich)
+✓ 24 Pins (vs. 4 bei USB-A)
+✓ Unterstützt: Daten, Strom, Video, Audio
+
+**ABER:** USB-C sagt NICHTS über Geschwindigkeit!
+
+Ein USB-C-Kabel kann sein:
+- USB 2.0 (480 Mbps) 😱
+- USB 3.2 Gen 2 (10 Gbps)
+- USB 4 (40 Gbps)
+- Thunderbolt 3/4 (40 Gbps)
+- Oder nur Power Delivery (Laden, keine Daten!)
+
+
+
+---
+
+# USB Power Delivery
+
+**USB PD (über USB-C):**
+
+- Profile: 5V bis 20V
+- Max. 5A
+- Bis zu **240W** (USB PD 3.1, 2021)
+
+**Anwendungen:**
+- Laptop-Ladung (60-100W)
+- Monitor mit Stromversorgung
+- Docking-Stations
+
+**Problem:** Nicht jedes Kabel unterstützt volles PD!
+
+
+
+---
+
+# USB-C: Das Wirrwarr
+
+**Was ein USB-C-Kabel KÖNNEN KANN:**
+
+**Daten:** USB 2.0 bis USB4 (40 Gbps)
+
+**Strom:** 5W bis 240W
+
+**Video:** DisplayPort Alt Mode, HDMI Alt Mode
+
+**Audio:** USB Audio Class
+
+**Problem:** Am Kabel steht's oft NICHT drauf!
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Thunderbolt: Premium-Schnittstelle
+
+**Thunderbolt (Intel + Apple):**
+
+- Thunderbolt 3/4 (2015/2020): USB-C, 40 Gbps
+- **PCIe über Kabel** → externe GPUs!
+- Daisychaining (bis 6 Geräte)
+- 100W Power Delivery garantiert
+
+**Nachteile:**
+❌ Teuer (Kabel: 30-80€)
+❌ Lizenzgebühren (Intel)
+❌ Nur High-End-Geräte
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# HDMI: Der Heimkino-Standard
+
+**HDMI (2002):**
+Entwickelt von Sony, Panasonic, Toshiba...
+
+**Versionen:**
+- HDMI 1.4 (2009): 4K @ 30 Hz, ARC
+- HDMI 2.0 (2013): 4K @ 60 Hz, HDR
+- HDMI 2.1 (2017): 8K @ 60 Hz, 4K @ 120 Hz, VRR
+
+**Features:**
+✓ Audio + Video in einem Kabel
+✓ HDCP (Copy Protection)
+✓ CEC (Gerätesteuerung)
+
+**Nachteile:**
+❌ Proprietär, Lizenzgebühren
+❌ Keine Daisychaining
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# DisplayPort: Die PC-Alternative
+
+**DisplayPort (2006):**
+VESA (Video Electronics Standards Association)
+
+**Versionen:**
+- DP 1.4 (2016): 8K @ 60 Hz, HDR
+- DP 2.0 (2019): 16K @ 60 Hz, 8K @ 120 Hz
+
+**Vorteile:**
+✓ Lizenzfrei (keine Gebühren!)
+✓ Daisychaining (Multi-Monitor)
+✓ Adaptive Sync (FreeSync, G-Sync)
+✓ USB-C Alt Mode
+
+**Nachteil:** Weniger verbreitet in TVs
+
+
+
+---
+
+# HDMI vs. DisplayPort
+
+| Feature | HDMI 2.1 | DisplayPort 2.0 |
+|---------|----------|-----------------|
+| **Max. Auflösung** | 8K @ 60 Hz | 16K @ 60 Hz |
+| **Lizenz** | Ja (~$10k/Jahr) | Nein |
+| **Daisychaining** | Nein | Ja |
+| **Adaptive Sync** | VRR (neu) | Ja (nativ) |
+| **USB-C** | Alt Mode (selten) | Alt Mode (häufig) |
+| **Verbreitung** | TVs dominant | PCs/Monitore |
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# HDCP: Copy Protection
+
+**HDCP = High-bandwidth Digital Content Protection**
+
+**Was ist das?**
+- DRM für Video-Signale
+- Verschlüsselt zwischen Quelle und Display
+- Verhindert "Man-in-the-Middle"-Aufnahme
+
+**Problem:**
+- Alte Monitore: Kein HDCP 2.2 → 4K-Netflix funktioniert nicht!
+- Capture-Cards oft blockiert
+- "HDCP-Handshake-Fehler" → Schwarzer Bildschirm
+
+**Kritik:** Schikaniert ehrliche Nutzer, Piraten umgehen es leicht
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Ethernet: Das Netzwerkkabel
+
+**Ethernet (1980er):**
+
+**Versionen:**
+- 100BASE-TX (1995): 100 Mbps
+- 1000BASE-T (1999): 1 Gbps (Gigabit)
+- 10GBASE-T (2006): 10 Gbps
+
+**Kabel-Kategorien:**
+- Cat5e: bis 1 Gbps (veraltet)
+- Cat6: bis 10 Gbps (55m)
+- Cat6a: bis 10 Gbps (100m)
+
+**Stecker:** RJ45 (8P8C)
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# WLAN (Wi-Fi)
+
+**IEEE 802.11:**
+
+| Standard | Jahr | Max. Speed | Frequenz |
+|----------|------|-----------|----------|
+| 802.11n (Wi-Fi 4) | 2009 | 600 Mbps | 2,4/5 GHz |
+| 802.11ac (Wi-Fi 5) | 2013 | 3,5 Gbps | 5 GHz |
+| 802.11ax (Wi-Fi 6) | 2019 | 9,6 Gbps | 2,4/5/6 GHz |
+| 802.11be (Wi-Fi 7) | 2024 | 46 Gbps | 2,4/5/6 GHz |
+
+**Praxis:** Geteiltes Medium → Real-Speed oft 30-50%
+
+
+
+---
+
+# Bluetooth
+
+**Bluetooth (1999):**
+
+| Version | Jahr | Speed | Reichweite |
+|---------|------|-------|------------|
+| 4.0 (BLE) | 2010 | 1 Mbps | 100m |
+| 5.0 | 2016 | 2 Mbps | 400m |
+| 5.3 | 2021 | 2 Mbps | 400m |
+
+**Anwendungen:**
+- Audio (Kopfhörer, Lautsprecher)
+- Peripherie (Maus, Tastatur)
+- IoT (Sensoren, Smart Home)
+
+**Codecs:** SBC (Standard), AAC, aptX, LDAC
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Veraltete Schnittstellen
+
+**Seriell (RS-232):** 1960er, 115,2 kbps, Modems
+**Parallel (LPT):** Drucker, 8 Bits gleichzeitig
+**PS/2:** Maus + Tastatur (1987-2010er)
+**VGA:** Analoges Video (1987-2010er)
+
+**Heute:** Manchmal noch auf Mainboards (Legacy-Support)
+
+
+
+---
+
+# Hands-On: Schnittstellen identifizieren
+
+**Aufgabe (30 Min):**
+
+1. Untersuche deinen Laptop/Desktop
+2. Welche Anschlüsse vorhanden?
+3. Für USB-C: Welche Features? (Daten, Video, Laden?)
+4. Teste: Schließe Gerät an verschiedenen Ports an
+5. Dokumentiere: Foto + Beschriftung
+
+**Tools:** Systeminfo (Win), System Report (Mac), lsusb (Linux)
+
+
+
+---
+
+# Fleißaufgabe bis nächste Woche
+
+**Analysiere deine Kabel:**
+
+1. Liste alle Kabel (USB, HDMI, etc.)
+2. Identifiziere: Standard, Geschwindigkeit, Features
+3. Finde das verwirrendste Kabel
+
+**Bonus:** Finde USB-C-Kabel, das nur USB 2.0 kann
+
+
+
+---
+
+
+
+# Fragen & Diskussion
+
+**Kontakt:** mail@librete.ch
+**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
+
+---
+
+# Lizenz & Attribution
+
+Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
+
+- Erlaubt Teilen & Anpassen mit Namensnennung
+- Adaptionen müssen unter gleicher Lizenz geteilt werden
+
+Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
+
diff --git a/courses/223015b/slides/2026-01-30-termin-4-distribution-apis-zukunft.md b/courses/223015b/slides/2026-01-30-termin-4-distribution-apis-zukunft.md
new file mode 100644
index 0000000..851877e
--- /dev/null
+++ b/courses/223015b/slides/2026-01-30-termin-4-distribution-apis-zukunft.md
@@ -0,0 +1,1919 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+---
+
+
+
+
+
+
+
+
+
+
+# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+
+**223015b** · Modul "Technik 1" · 1. Semester
+Digital- und Medienwirtschaft
+Hochschule der Medien Stuttgart
+
+**Wintersemester 2025/26**
+
+[https://git.librete.ch/hdm/223015b](https://git.librete.ch/hdm/223015b)
+
+---
+
+
+
+# Termin 4 – 30.01.2026
+## Distribution, APIs & Zukunft
+
+---
+
+
+
+
+
+---
+
+# Das Problem: Daten müssen reisen
+
+**Szenario:** 100 TB von Berlin nach München
+
+**Option 1: Internet-Upload**
+- 1 Gbps Uplink = 125 MB/s
+- Zeit: **9,3 Tage** (non-stop!)
+
+**Option 2: Festplatte per Post**
+- 10× 10TB HDDs (~2.000€)
+- Kopieren: ~10 Stunden
+- Versand: 1-2 Tage
+- Gesamt: **~3 Tage**
+
+*"Never underestimate the bandwidth of a station wagon full of tapes."* — Andrew Tanenbaum (1981)
+
+
+
+---
+
+
+
+
+
+---
+
+# AWS Snowball
+
+**AWS Snowball (seit 2015):**
+
+**Problem:** Petabytes on-premise → AWS-Cloud
+
+**Geräte:**
+- Snowball Edge: 100 TB
+- **Snowmobile:** 100 PB (Container auf LKW!)
+
+**Prozess:**
+1. AWS schickt verschlüsseltes Gerät
+2. Kunde kopiert Daten lokal (schnell!)
+3. Gerät zurück an AWS
+4. AWS lädt in S3 hoch
+
+**Kosten:** Günstiger als Internet-Transfer bei >10 TB
+
+
+
+---
+
+
+
+
+
+---
+
+# Physische Distribution
+
+**CD (1982):** 700 MB
+**DVD (1995):** 4,7 GB / 8,5 GB
+**Blu-ray (2006):** 25 GB / 50 GB / 100 GB
+
+**Problem heute:**
+- Games: 50-150 GB (Call of Duty: 200+ GB!)
+- Filme: Streaming überholt Blu-ray
+- Disc = "License Key", Rest wird geladen
+
+
+
+---
+
+
+
+
+
+---
+
+# Zentralisierte Distribution
+
+**Klassisches Modell:** Ein Server, viele Clients
+
+**Problem:**
+1 Million User wollen 1 GB-Datei
+→ Server braucht **1 PB Bandbreite!**
+→ Server überlastet → **"Hug of Death"**
+
+**Lösung:** Content Delivery Networks (CDNs)
+
+
+
+---
+
+
+
+
+
+---
+
+# CDNs: Content Delivery Networks
+
+**CDN = Verteiltes Netzwerk weltweit**
+
+**Funktionsweise:**
+1. **Origin Server** (Hauptquelle)
+2. **Edge Servers** (geografisch verteilt)
+3. User → nächster Edge Server
+4. Erste Anfrage: Edge holt von Origin, cached
+5. Weitere Anfragen: Direkt vom Edge (schnell!)
+
+**Vorteile:**
+✓ Reduzierte Latenz (geografische Nähe)
+✓ Last-Verteilung
+✓ Bandbreitenersparnis
+
+
+
+---
+
+# CDN-Strategien
+
+**Static Content:**
+- Bilder, CSS, JS, Videos
+- Lange Cache-Zeit (TTL: Tage/Wochen)
+
+**Dynamic Content:**
+- User-spezifisch (Profil)
+- Kurze TTL oder nicht cachebar
+
+**Cache Invalidation:**
+- Versioning (`style.css` → `style.v2.css`)
+- Cache-Purge (manuell leeren)
+
+*"There are only two hard things in Computer Science: cache invalidation and naming things."* — Phil Karlton
+
+
+
+---
+
+
+
+
+
+---
+
+# Netflix: Fallstudie CDN
+
+**Netflix Open Connect (eigenes CDN):**
+
+**Strategie:**
+- Server IN ISP-Rechenzentren (Telekom, Vodafone...)
+- Popular Content vorgeladen (Predictive Caching)
+- **95%+ Traffic vom lokalen ISP-Server**
+
+**Zahlen (2024):**
+- 200M+ Subscriber
+- ~15% des globalen Internet-Traffics!
+- Ohne CDN: Unmöglich
+
+
+
+---
+
+
+
+
+
+---
+
+# P2P: Peer-to-Peer
+
+**P2P = Jeder ist Client UND Server**
+
+**Philosophie:** Dezentralisierung
+
+**Anwendungen:**
+- BitTorrent (File-Sharing)
+- IPFS (InterPlanetary File System)
+- Blockchain (Bitcoin, Ethereum)
+
+**Vorteil:** Skalierbar (mehr User = mehr Bandbreite!)
+
+**Nachteil:** Langsam bei wenigen Peers, oft für Piraterie missbraucht
+
+
+
+---
+
+
+
+
+
+---
+
+# BitTorrent: Wie funktioniert's?
+
+**BitTorrent (Bram Cohen, 2001):**
+
+**Komponenten:**
+1. **.torrent-Datei:** Metadaten (Hashes, Tracker-URL)
+2. **Tracker:** Vermittelt Peers
+3. **Seeders:** Haben komplette Datei
+4. **Leechers:** Laden noch
+5. **Swarm:** Alle Peers zusammen
+
+**Mechanismus:**
+- Datei in Chunks (z.B. 256 KB)
+- Jeder Peer lädt von verschiedenen Peers
+- "Tit-for-tat": Wer uploaded, lädt schneller
+
+
+
+---
+
+
+
+
+
+---
+
+# BitTorrent & Piraterie
+
+**2000er:** Musik-/Film-Piraterie-Revolution
+
+**Napster (1999-2001):** Zentralisiert → Verklagt, Shutdown
+
+**BitTorrent (2001+):** Dezentral → Schwerer zu verklagen
+
+**The Pirate Bay (2003):** BitTorrent-Index
+- Blockiert, zieht um, neue Domains
+- **Whack-a-Mole-Spiel**
+
+**Rechtliche Grauzone:**
+- Protokoll selbst: Legal
+- Inhalte: Oft illegal (Urheberrecht)
+- Legitime Uses: Linux-ISOs, Open-Source, Public Domain
+
+
+
+---
+
+
+
+
+
+---
+
+# IPFS: Dezentrales Web?
+
+**IPFS = InterPlanetary File System (2015)**
+
+**Vision:** Web ohne Server
+
+**Funktionsweise:**
+- **Content-Addressable:** Dateien durch Hash identifiziert
+- **CID:** Content Identifier (`QmXyZ123...`)
+- Datei auf vielen Knoten (wie BitTorrent, aber persistent)
+- Abruf: "Gib mir Datei mit Hash X" (egal wo)
+
+**Vorteile:** Zensur-resistent, kein Single Point of Failure
+
+**Nachteile:** Langsam (noch), keine Verfügbarkeitsgarantie
+
+**Anwendung:** NFT-Speicher
+
+
+
+---
+
+
+
+
+
+---
+
+# Streaming: Real-Time-Distribution
+
+**Streaming = Daten während Empfang konsumiert**
+
+**Protokolle:**
+- **HLS** (Apple): HTTP-basiert, Segmente
+- **MPEG-DASH:** Standard, ähnlich HLS
+- **WebRTC:** Browser-zu-Browser, niedrige Latenz
+
+**Adaptive Bitrate:**
+- Stream in mehreren Qualitäten (240p-4K)
+- Player wechselt dynamisch
+- Segmente: 2-10 Sekunden
+
+**Latenz:**
+- Traditional (HLS): 10-30 Sekunden
+- Low-Latency HLS: 2-5 Sekunden
+- WebRTC: <1 Sekunde (Videocalls)
+
+
+
+---
+
+# Hands-On: Torrent & CDN
+
+**Aufgabe (40 Min):**
+
+**Teil 1: BitTorrent (20 Min)**
+1. Lade legalen Torrent (Linux-ISO: ubuntu.com)
+2. Tool: qBittorrent oder Transmission
+3. Beobachte: Peers, Seeders, Download-Speed, Upload-Speed
+
+**Teil 2: CDN-Analyse (20 Min)**
+1. Öffne populäre Website (z.B. nytimes.com)
+2. Browser DevTools → Network-Tab
+3. Schaue auf Requests: Welche CDN-Domains?
+4. Response-Headers: `X-Cache`, `CF-Ray`, etc.
+
+**Tools:** cdn77.com/cdn-check
+
+
+
+---
+
+# Fleißaufgabe bis nächste Woche
+
+**Analysiere Streaming-Dienst oder Website:**
+
+1. Wähle: Netflix, YouTube, Spotify, News-Seite
+2. DevTools (Network-Tab):
+ - Welcher CDN?
+ - Wie viele Requests an CDN vs. Origin?
+ - Cache-Headers?
+
+**Bonus:** Linux-ISO via Torrent, beobachte Peer-Stats
+
+
+
+---
+
+# Dateitransfer-Protokolle
+
+**FTP (File Transfer Protocol, 1971):**
+- Ältestes Internet-Protokoll für Dateitransfer
+- ⚠️ Unverschlüsselt! (Passwort im Klartext)
+- **SFTP/FTPS:** Sichere Varianten
+
+**WebDAV (Web-based Distributed Authoring):**
+- HTTP-basiert → Firewall-freundlich
+- Wird von vielen Cloud-Diensten genutzt
+- Mountbar als Netzlaufwerk
+
+**Moderne Alternativen:** rsync, rclone, Cloud-APIs
+
+
+
+---
+
+
+
+# Teil 2: APIs
+## Software-Schnittstellen & Protokolle
+
+---
+
+
+
+
+
+---
+
+# Was ist eine API?
+
+**API = Application Programming Interface**
+
+**Analogie: Restaurant**
+- Du (Client) → Speisekarte (API-Dokumentation)
+- Bestellst (Request)
+- Küche bereitet zu (Backend)
+- Kellner bringt Essen (Response)
+- Du weißt nicht, WIE gekocht wird – nur WAS du kriegst
+
+**Typen:** Hardware-APIs, OS-APIs, Web-APIs, Library-APIs
+
+
+
+---
+
+
+
+
+
+---
+
+# HTTP: Das Fundament
+
+**HTTP = HyperText Transfer Protocol (1991)**
+
+**Request-Struktur:**
+- **Method:** GET, POST, PUT, DELETE
+- **URL:** Resource-Identifier
+- **Headers:** Metadaten (Content-Type, Authorization...)
+- **Body:** Optional (bei POST/PUT)
+
+**Response-Struktur:**
+- **Status Code:** 200 OK, 404 Not Found, 500 Error
+- **Headers:** Metadaten
+- **Body:** HTML, JSON, XML, Binary...
+
+
+
+---
+
+# HTTP-Methods: CRUD
+
+**CRUD = Create, Read, Update, Delete**
+
+| Method | CRUD | Beispiel |
+|--------|------|----------|
+| **GET** | Read | `/posts` → Alle Posts |
+| **POST** | Create | `/posts` → Neuer Post |
+| **PUT** | Update | `/posts/42` → Post ersetzen |
+| **PATCH** | Update | `/posts/42` → Teilupdate |
+| **DELETE** | Delete | `/posts/42` → Post löschen |
+
+**GET = Idempotent** (mehrfach ausführen = gleiches Ergebnis)
+
+
+
+---
+
+
+
+
+
+---
+
+# REST: Representational State Transfer
+
+**REST (Roy Fielding, 2000):**
+
+**Prinzipien:**
+1. **Stateless:** Jede Anfrage eigenständig
+2. **Resource-Based:** URLs = Ressourcen (`/users/123`)
+3. **HTTP-Methods:** CRUD-Operationen
+4. **Hypermedia:** Links zu verwandten Ressourcen
+
+**Beispiel: Twitter-API**
+```
+GET /tweets/123 → Tweet mit ID 123
+POST /tweets → Neuen Tweet erstellen
+DELETE /tweets/123 → Tweet löschen
+GET /users/alice/tweets → Tweets von Alice
+```
+
+
+
+---
+
+# REST-Probleme
+
+**Problem 1: Over-Fetching**
+```
+GET /users/123
+→ Gibt zurück: Name, Email, Bio, Avatar,
+ Follower-Count, Posts, Friends...
+```
+Du willst nur Name → Kriegst 90% zu viel
+
+**Problem 2: Under-Fetching**
+```
+GET /users/123 → User-Daten
+GET /users/123/posts → Alle Posts
+```
+2 Requests statt einem
+
+**Lösung:** GraphQL
+
+
+
+---
+
+
+
+
+
+---
+
+# GraphQL: Die REST-Alternative
+
+**GraphQL (Facebook, 2015):**
+
+**Idee:** Client fragt EXAKT, was er braucht
+
+**Query-Beispiel:**
+```graphql
+{
+ user(id: 123) {
+ name
+ email
+ posts(limit: 5) {
+ title
+ createdAt
+ }
+ }
+}
+```
+
+**Vorteile:**
+✓ Kein Over-/Under-Fetching
+✓ Ein Endpoint (`/graphql`)
+✓ Strongly Typed (Schema!)
+
+
+
+---
+
+# GraphQL Schema
+```graphql
+type User {
+ id: ID!
+ name: String!
+ email: String
+ posts: [Post!]!
+}
+
+type Post {
+ id: ID!
+ title: String!
+ content: String!
+ author: User!
+}
+
+type Query {
+ user(id: ID!): User
+ posts: [Post!]!
+}
+
+type Mutation {
+ createPost(title: String!, content: String!): Post!
+}
+```
+
+**`!` = Required (non-nullable)**
+
+
+
+---
+
+
+
+
+
+---
+
+# WebSockets: Real-Time
+
+**Problem mit HTTP:**
+- Request-Response-Zyklus
+- Server kann nicht "pushen"
+- Polling ineffizient
+
+**WebSocket (2011):**
+- **Bidirektionale Verbindung**
+- Bleibt offen (Persistent)
+- Server kann jederzeit senden
+
+**Anwendungen:**
+Chat (Discord), Live-Updates (Aktienkurse), Multiplayer-Games
+
+
+
+---
+
+# WebSocket: Chat-Beispiel
+
+**Flow:**
+1. Alice öffnet Chat → WebSocket-Connection
+2. Bob öffnet Chat → Eigene Connection
+3. Alice tippt: "Hi Bob!"
+4. Client sendet: `{"type": "message", "text": "Hi Bob!", "to": "bob"}`
+5. Server leitet an Bobs Connection weiter
+6. Bob empfängt, zeigt an
+
+**Kein Polling! Instant!**
+
+
+
+---
+
+
+
+
+
+---
+
+# gRPC: Google's Approach
+
+**gRPC = Google Remote Procedure Call (2015)**
+
+**Idee:** Funktion auf Remote-Server aufrufen, als wäre es lokal
+
+**Eigenschaften:**
+- **Protocol Buffers (Protobuf):** Binär, kompakt (statt JSON)
+- **HTTP/2:** Multiplexing, Bidirektional
+- **Strongly Typed**
+- **Code-Generierung** (Client/Server aus `.proto`-Datei)
+
+**Vorteile:** Performance, Streaming
+**Nachteile:** Nicht Browser-kompatibel, Debugging schwieriger
+
+
+
+---
+
+# gRPC Beispiel
+
+**`.proto`-Datei:**
+```protobuf
+service UserService {
+ rpc GetUser (UserRequest) returns (UserResponse);
+ rpc ListPosts (Empty) returns (stream Post);
+}
+
+message UserRequest {
+ int32 id = 1;
+}
+
+message UserResponse {
+ string name = 1;
+ string email = 2;
+}
+```
+
+**Code-Generierung:** Client/Server-Code automatisch generiert
+
+
+
+---
+
+# JSON: Das Standard-Format
+
+**JSON = JavaScript Object Notation**
+
+**Eigenschaften:**
+- Textbasiert, menschenlesbar
+- Schlüssel-Wert-Paare
+- Unterstützt: Objekte, Arrays, Strings, Numbers, Booleans, null
+
+**Beispiel:**
+```json
+{
+ "name": "Alice",
+ "age": 28,
+ "posts": [
+ {"title": "Hello", "views": 42},
+ {"title": "World", "views": 123}
+ ]
+}
+```
+
+
+
+---
+
+# Hands-On: API abfragen
+
+**Aufgabe (40 Min):**
+
+**Teil 1: REST-API (20 Min)**
+1. Öffentliche API: `jsonplaceholder.typicode.com`
+2. Tool: curl (Terminal) oder Postman (GUI)
+3. Beispiele:
+```bash
+curl https://jsonplaceholder.typicode.com/posts/1
+curl -X POST https://jsonplaceholder.typicode.com/posts \
+ -H "Content-Type: application/json" \
+ -d '{"title":"Test","body":"Hello","userId":1}'
+```
+4. Analysiere: Status-Code, Headers, Body
+
+**Teil 2: WebSocket (20 Min)**
+1. Öffne: `websocket.org/echo.html`
+2. Verbinde, sende Nachrichten
+3. Beobachte: Instant Response
+
+
+
+---
+
+# Fleißaufgabe bis nächste Woche
+
+**Experimentiere mit öffentlicher API:**
+
+1. Wähle:
+ - GitHub API (`api.github.com`)
+ - OpenWeather (`openweathermap.org/api`)
+ - PokéAPI (`pokeapi.co`)
+2. Mache 3-5 Requests (curl, Postman, oder Code)
+3. Notiere: Welche Daten? Rate-Limiting erlebt?
+
+**Bonus:** Baue kleinen Client (Python, JavaScript, etc.)
+
+
+
+---
+
+
+
+# Teil 3: Metadaten
+## Daten über Daten & Interoperabilität
+
+---
+
+
+
+
+
+---
+
+# Was sind Metadaten?
+
+**Metadaten = Daten über Daten**
+
+**Beispiele:**
+- **Foto:** Kamera, Datum, GPS, Belichtung
+- **MP3:** Künstler, Album, Jahr, Genre, Cover
+- **PDF:** Autor, Datum, Software
+- **E-Mail:** Absender, Empfänger, Zeitstempel
+
+**Warum wichtig?**
+✓ Organisation, Suche
+✓ Kontext (Wann/Wo/Wie?)
+
+**Aber auch:**
+❌ Privacy-Risiko, Forensische Spuren
+
+
+
+---
+
+# EXIF: Exchangeable Image File Format
+
+**EXIF (1995, Kamera-Hersteller):**
+
+**Typische Daten:**
+- Kamera-Modell (z.B. "iPhone 15 Pro")
+- Datum & Uhrzeit
+- Belichtung (Blende, Verschlusszeit, ISO)
+- **GPS-Koordinaten** (Latitude, Longitude, Altitude)
+- Software (z.B. "Photoshop 2024")
+
+**Speicherort:** JPEG-Header (Binärformat)
+
+**Tools:** exiftool, ExifPurge, metapicz.com
+
+
+
+---
+
+
+
+
+
+---
+
+# EXIF: Privacy-Albtraum
+
+**Szenario 1: Stalking**
+- Foto auf Twitter: "Zuhause entspannen 🏡"
+- EXIF: GPS 52.5200° N, 13.4050° E
+- → Stalker weiß, wo du wohnst
+
+**Szenario 2: Whistleblowing**
+- Anonyme Quelle schickt PDF
+- Metadaten: "Erstellt von: John Doe, Firma XY"
+- → Quelle identifiziert
+
+**Berühmter Fall:**
+John McAfee (2012): Vice-Magazine vergaß EXIF zu entfernen
+→ GPS verriet Aufenthaltsort in Guatemala
+
+
+
+---
+
+# Social Media & EXIF-Stripping
+
+**Welche Plattformen entfernen EXIF?**
+
+✓ **Twitter/X:** Ja (seit 2015)
+✓ **Facebook/Instagram:** Ja (GPS entfernt)
+✓ **Reddit:** Ja
+❌ **WhatsApp:** Nein (privat, aber Metadaten bleiben)
+❌ **E-Mail-Anhänge:** Nein
+❌ **Cloud (Dropbox, Google Drive):** Nein
+
+**Best Practice:** EXIF manuell entfernen vor Upload
+```bash
+exiftool -all= foto.jpg # Entfernt ALLE Metadaten
+```
+
+
+
+---
+
+
+
+
+
+---
+
+# ID3-Tags: Musik-Metadaten
+
+**ID3 = Identification 3 (1996)**
+
+**Versionen:**
+- **ID3v1:** 128 Bytes am Ende (limitiert!)
+ - Titel (30 Zeichen), Artist, Album, Jahr
+- **ID3v2:** Am Anfang, variable Länge
+ - Unbegrenzte Textfelder, Cover-Art, Lyrics, BPM
+
+**Tools:**
+- Kid3 (GUI, Multi-Platform)
+- MusicBrainz Picard (Auto-Tagging!)
+- mp3tag (Windows)
+
+
+
+---
+
+
+
+
+
+---
+
+# MusicBrainz: Offene Musik-Datenbank
+
+**MusicBrainz (2000):**
+
+**Idee:** Wikipedia für Musik-Metadaten
+
+**Community-gepflegt:**
+- Künstler, Alben, Tracks
+- Relationships (Band-Mitglieder, Label...)
+- Releases (verschiedene Editionen, Länder)
+
+**MusicBrainz Picard:**
+- Audio-Fingerprinting (AcoustID)
+- Analysiert Waveform, matched mit Datenbank
+- Auto-Tagging (auch bei falsch benannten Dateien!)
+
+**Philosophie:** Open Data (gegen proprietäre Gracenote/CDDB)
+
+
+
+---
+
+# Dublin Core: Universelle Metadaten
+
+**Dublin Core (1995, Dublin, Ohio):**
+
+**15 Kern-Elemente:**
+1. Title, 2. Creator, 3. Subject, 4. Description
+5. Publisher, 6. Contributor, 7. Date, 8. Type
+9. Format, 10. Identifier (ISBN, DOI)
+11. Source, 12. Language, 13. Relation
+14. Coverage, 15. Rights
+
+**Anwendung:** Bibliotheken, Archive, Webseiten (HTML ``)
+
+
+
+---
+
+
+
+
+
+---
+
+# PDF-Metadaten: Hidden Dangers
+
+**PDF-Metadaten (XMP):**
+
+**Gespeichert:**
+- Titel, Autor, Betreff, Keywords
+- Erstellungsdatum, Änderungsdatum
+- Software, **Company** (aus Office-Lizenz!)
+
+**Versteckte Daten:**
+- Änderungshistorie (Track Changes)
+- Kommentare (vermeintlich gelöscht)
+- Ebenen (InDesign, Illustrator)
+
+**Berühmter Fall:**
+Tony Blair Dossier (2003, Irak-Krieg)
+→ PDF-Metadaten zeigten Manipulation
+
+
+
+---
+
+# Interoperabilität: Offene vs. Proprietäre
+
+**Offene Formate:**
+✓ Spezifikation öffentlich
+✓ Keine Lizenzgebühren
+✓ Viele Programme unterstützen
+**Beispiele:** PNG, OGG, MKV, Markdown, SVG
+
+**Proprietäre Formate:**
+❌ Spezifikation geheim
+❌ Oft nur in einer Software voll nutzbar
+❌ **Lock-in-Effekt**
+**Beispiele:** PSD (Photoshop), INDD (InDesign), DWG (AutoCAD), .pages
+
+
+
+---
+
+# Vendor Lock-in: Beispiele
+
+**Fall 1: Microsoft Office (.docx)**
+- Historisch: .doc undokumentiert
+- LibreOffice konnte nicht perfekt konvertieren
+- "Formatierung kaputt" → Zurück zu MS Office
+
+**Fall 2: Adobe Creative Suite**
+- PSD: Layer, Blend-Modes → Nur in Photoshop voll editierbar
+- GIMP kann öffnen, aber Features fehlen
+
+**Fall 3: Apple Ecosystem**
+- .pages, .numbers, .key → Nur auf Apple native Bearbeitung
+
+
+
+---
+
+# Datenmigration & Langzeitarchivierung
+
+**Beispiele toter Formate:**
+- WordPerfect (.wpd) – 1980-90er dominant, heute kaum lesbar
+- Lotus 1-2-3 (.wks) – Spreadsheet, verschwunden
+- Flash (.swf) – Millionen Websites/Games, seit 2020 tot
+
+**Archivierungs-Strategien:**
+1. **Migration:** Regelmäßig in aktuelle Formate konvertieren
+2. **Emulation:** Alte Software in VM
+3. **Offene Standards:** PDF/A, TIFF, Plain Text
+
+
+
+---
+
+# Metadaten für Accessibility
+
+**Alt-Text (Alternative Text):**
+```html
+
+```
+
+**Warum?**
+✓ Screen-Reader (Blinde/Sehbehinderte)
+✓ SEO (Suchmaschinen)
+✓ Fallback (Bild lädt nicht)
+
+**PDF-Tags:** Strukturierte PDFs (Überschriften, Listen)
+→ Screen-Reader kann navigieren
+
+**Video:** Closed Captions (CC), Audio Descriptions
+
+
+
+---
+
+# Hands-On: Metadaten analysieren & entfernen
+
+**Aufgabe (40 Min):**
+
+**Teil 1: EXIF (20 Min)**
+1. Nimm Foto (oder nutze altes)
+2. Analysiere: `exiftool foto.jpg` oder metapicz.com
+3. Notiere: GPS? Kamera-Modell? Software?
+4. Entferne: `exiftool -all= foto.jpg`
+5. Vergleiche Dateigrößen
+
+**Teil 2: ID3 (20 Min)**
+1. Nimm MP3-Datei
+2. Analysiere: Kid3, mp3tag, oder exiftool
+3. Ändere Tags (z.B. falscher Artist)
+4. Optional: MusicBrainz Picard (Auto-Tagging)
+
+
+
+---
+
+# Fleißaufgabe bis nächste Woche
+
+**Metadaten-Audit:**
+
+1. Wähle 3 Dateitypen:
+ - Ein Foto (EXIF)
+ - Eine MP3 (ID3)
+ - Ein PDF (XMP)
+2. Analysiere: Welche Metadaten?
+3. Notiere: Überraschungen? KB gespart nach Entfernung?
+
+**Bonus:** Finde alte Datei (>5 Jahre) – was verraten Metadaten über damaliges Setup?
+
+
+
+---
+
+
+
+# Teil 4: Zukunft
+## Trends & Ausblick
+
+---
+
+
+
+
+
+---
+
+# Rückblick: 5 Termine
+
+**Termin 1:** Bits, Bytes, Zeichenkodierung & Audio (MP3)
+**Termin 2:** Bild- & Videoformate (JPEG, H.264, AV1)
+**Termin 3:** Speichermedien & Schnittstellen
+**Termin 4:** Distribution, APIs & Zukunft
+**Termin 5:** Vertiefung & offene Fragen
+
+**Heute:** Wohin geht die Reise?
+
+
+
+---
+
+# AI-basierte Kompression
+
+**Problem:** JPEG/H.264 basieren auf 90er-Jahre-Modellen
+
+**Neue Ansätze:**
+
+1. **Neuronale Bild-Kompression:**
+ - Deep Learning lernt Kompression/Dekompression
+ - Google's "Learned Image Compression" (2018)
+ - Outperforms JPEG bei gleicher Größe
+
+2. **Generative Kompression:**
+ - Encoder extrahiert semantische Features
+ - Decoder generiert Bild neu (wie DALL-E)
+ - **99%+ Kompression**, aber nicht bit-genau!
+
+**Problem:** Hoher Rechenaufwand, keine Standardisierung
+
+
+
+---
+
+
+
+
+
+---
+
+# JPEG XL: Der moderne JPEG
+
+**JPEG XL (2021, ISO-Standard):**
+
+**Ziele:**
+✓ 60% besser als JPEG
+✓ Besser als WebP/AVIF (manchmal)
+✓ Lossless UND Lossy
+✓ Progressive Decoding (wie klassisches JPEG)
+✓ Rückwärtskompatibel (JPEG → JPEG XL "Wrapper")
+
+**Features:** HDR, Animation (wie GIF, aber besser)
+
+**Status 2025:** Browser-Support langsam (Safari ja, Chrome on-off)
+
+**Problem:** Google favorisiert WebP/AVIF → politischer Kampf
+
+
+
+---
+
+# AV1 & VVC: Codec-Krieg
+
+**AV1 (Alliance for Open Media):**
+✓ Etabliert sich (YouTube 4K, Netflix)
+✓ Hardware-Decoder in neuen GPUs/Smartphones
+
+**VVC (H.266, 2020):**
+- 50% besser als H.265
+- **Aber:** Patent-Problem (mehrere Pools, unklare Kosten)
+- Adoption gering
+
+**LCEVC:** Add-on für existierende Codecs
+
+**Zukunft:**
+- AV2 (Nachfolger AV1) in Entwicklung
+- ML integriert?
+
+
+
+---
+
+
+
+
+
+---
+
+# DNA-Storage
+
+**Konzept:** Daten in DNA-Sequenzen
+
+**Eigenschaften:**
+- Speicherdichte: **215 Petabyte/Gramm**
+- Haltbarkeit: Tausende Jahre
+- Kosten: Aktuell $3.500/MB (sinkend)
+
+**Beispiele:**
+- Microsoft + Twist Bioscience
+- Netflix "Biohackers"-Episode (2021)
+- Harvard: Wikipedia (11 GB) in DNA (2017)
+
+**Problem:** Synthese & Sequenzierung extrem langsam/teuer
+
+**Anwendung:** Langzeitarchivierung (nicht Live-Daten)
+
+
+
+---
+
+# Holografischer Speicher
+
+**Holographic Data Storage:**
+
+**Prinzip:**
+- Laser schreibt in 3D-Kristall (statt 2D-Oberfläche)
+- Interferenzmuster speichert Bits
+- Paralleler Zugriff (schnell!)
+
+**Vorteile:**
+✓ Hohe Dichte (Terabytes pro Disc)
+✓ Schnelle Lesegeschwindigkeit
+✓ Langlebig (50+ Jahre)
+
+**Stand 2025:** Prototypen (Sony, InPhase †), Kommerzialisierung gescheitert
+
+**Problem:** Teuer, Konkurrenz durch SSDs
+
+
+
+---
+
+# Quantum Storage?
+
+**Quantenspeicher:**
+
+**Konzept:**
+- Qubits statt klassische Bits
+- Superposition: 0 UND 1 gleichzeitig
+- Verschränkung: Qubits korreliert über Distanz
+
+**Anwendung:**
+- Nicht für klassische Daten (Qubits instabil)
+- Quantum Key Distribution (QKD) für Kommunikation
+- Zukunft: Quanten-RAM für Quantencomputer
+
+**Stand 2025:** Experimentell, Speicherzeit Millisekunden
+
+
+
+---
+
+# Web3 & Dezentraler Speicher
+
+**IPFS, Filecoin, Arweave, Storj:**
+
+**Idee:** Speicher ohne zentrale Server
+
+**Filecoin (2017):**
+- Blockchain-basiert
+- User vermieten Festplatten-Platz
+- Bezahlung in FIL (Kryptowährung)
+
+**Arweave (2018):**
+- "Permanent Storage"
+- Einmalige Zahlung → Daten für immer (theoretisch)
+
+**Kritik:**
+❌ Langsam vs. AWS S3
+❌ Teurer (oft)
+❌ Keine Garantie (Nodes offline)
+
+
+
+---
+
+# Streaming-Zukunft
+
+**Trends:**
+
+**8K-Streaming:**
+- 7680×4320 = 33 Megapixel/Frame
+- Braucht 100+ Mbps (selbst mit AV1)
+- Problem: Kaum Content, kaum TVs
+
+**VR/AR-Streaming:**
+- 2× 4K (pro Auge), 90-120 fps
+- Latenz <20ms kritisch
+- 5G + Edge Computing nötig
+
+**Cloud Gaming:**
+- Spiel im Rechenzentrum, Stream zu User
+- Input-Lag = Todfeind (<50ms)
+
+**Problem:** Physik (Lichtgeschwindigkeit!)
+
+
+
+---
+
+# Nachhaltigkeit
+
+**Digitalisierung ≠ Umweltfreundlich**
+
+**Rechenzentren:**
+- 2024: 1-2% globaler Stromverbrauch (steigend!)
+- Kühlung, Server, Netzwerk
+
+**Streaming:**
+- 1h Netflix (HD): ~3 GB, ~0,1 kWh
+- × Milliarden Stunden = massiver CO₂
+
+**E-Waste:**
+- Smartphones: 2-3 Jahre Lebensdauer
+- SSDs, HDDs: Nicht ewig
+
+**Lösungen:**
+- Effizientere Codecs (weniger Bandbreite)
+- Renewable Energy für Rechenzentren
+- Längere Hardware-Lebensdauer (Right to Repair!)
+
+
+
+---
+
+# Regulierung & Standardisierung
+
+**Wer entscheidet?**
+
+**Standards-Organisationen:**
+- ISO/IEC (International)
+- IETF (Internet-Protokolle)
+- W3C (Web-Standards)
+- IEEE (Hardware)
+
+**Problem:** Industrie-Dominanz
+- MPEG-LA (Patent-Pools)
+- USB-IF (Intel-dominiert)
+- HDMI Forum (Consumer-Electronics)
+
+**EU-Regulierung:**
+- USB-C-Pflicht (ab 2024)
+- DMA (Digital Markets Act): Interoperabilität
+- GDPR: Datenschutz (betrifft Metadaten!)
+
+**Zukunft:** Mehr Open Standards? Oder Fragmentierung?
+
+
+
+---
+
+# Fallstudie: Gruppenarbeit
+
+**Aufgabe (90 Min, ca. 5 Personen):**
+
+**Szenario:** Mittelständisches Medienunternehmen produziert Videos
+
+**Erarbeitet Konzept für:**
+1. Speichermedien (intern/extern, kurz-/langfristig)
+2. Dateiformate (Produktion, Distribution, Archivierung)
+3. Dateisysteme (welche für was?)
+4. Schnittstellen (SATA, USB, PCIe, Netzwerk)
+5. Distributionswege (NAS, Cloud, FTP)
+6. Backup-Strategie (3-2-1-Regel!)
+
+**Ergebnis:** Konzeptpapier (Mindmap, Tabelle, Poster)
+**Präsentation:** 5 Min pro Gruppe
+
+
+
+---
+
+# Alternative Szenarien (Auswahl)
+
+1. **Mittelständisches Medienunternehmen** (Videos, Streaming)
+2. **Kommunales Stadtarchiv** (Digitalisierung historischer Bestände)
+3. **Agentur für digitale Kommunikation** (internationale Kampagne)
+4. **Digitale Hochschul-Mediathek** (Lehrvideos, Podcasts)
+5. **Freiberufliche Fotografin** (Tausende RAW-Fotos/Jahr)
+6. **Internationales Reporterteam** (investigative Recherche, sensibel)
+
+**Jede Gruppe wählt ein Szenario**
+
+
+
+---
+
+# Was wir insgesamt gelernt haben
+
+✓ **Bits → Formate:** Encoding, Kompression (MP3, JPEG, H.264)
+✓ **Speicher:** HDD, SSD, Dateisysteme, Backup, Archivierung
+✓ **Schnittstellen:** USB-C, HDMI, DisplayPort, Ethernet
+✓ **Distribution:** CDN, P2P, Streaming, APIs
+✓ **Metadaten:** EXIF, ID3, Privacy, Interoperabilität
+✓ **Zukunft:** AI-Kompression, DNA-Storage, Nachhaltigkeit
+
+**Kernbotschaft:**
+Digitale Medien sind das Ergebnis von Standards, Politik, Kompromissen & Innovation.
+
+Ihr habt jetzt die Werkzeuge, um die digitale Welt kritisch zu verstehen.
+
+
+
+---
+
+# Weiterführende Ressourcen
+
+**Bücher:**
+- "Code" – Charles Petzold (Basics)
+- "Understanding Digital Signal Processing" – Richard Lyons
+
+**Websites:**
+- IETF RFCs (ietf.org)
+- FFmpeg Documentation (ffmpeg.org)
+- Protocol Labs (IPFS, Filecoin)
+
+**YouTube:**
+- Computerphile (Kompression, Encoding)
+- Branch Education (Hardware-Visualisierungen)
+
+**Podcasts:**
+- Command Line Heroes (Red Hat)
+
+**Tools:** MediaInfo, exiftool, FFmpeg, Wireshark
+
+
+
+---
+
+# Abschluss & Dank
+
+**Ihr habt gelernt:**
+- Dateien zu lesen (Hex, Metadaten)
+- Formate zu vergleichen (JPEG vs. PNG, H.264 vs. AV1)
+- Infrastruktur zu verstehen (CDN, P2P, APIs)
+- Kritisch zu denken (Open Standards, Lock-in, Nachhaltigkeit)
+
+**Nächste Schritte:**
+- Fallstudie (falls Prüfungsleistung)
+- Feedback willkommen (E-Mail)
+- Weiterlernen mit Ressourcen
+
+**Vielen Dank für eure Aufmerksamkeit!**
+
+
+
+---
+
+
+
+# Fragen & Diskussion
+
+**Kontakt:** mail@librete.ch
+**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
+
+---
+
+# Lizenz & Attribution
+
+Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
+
+- Erlaubt Teilen & Anpassen mit Namensnennung
+- Adaptionen müssen unter gleicher Lizenz geteilt werden
+
+Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
+
diff --git a/courses/223015b/slides/2026-xx-xx-termin-5-vertiefung-offene-fragen.md b/courses/223015b/slides/2026-xx-xx-termin-5-vertiefung-offene-fragen.md
new file mode 100644
index 0000000..994a9d2
--- /dev/null
+++ b/courses/223015b/slides/2026-xx-xx-termin-5-vertiefung-offene-fragen.md
@@ -0,0 +1,107 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+---
+
+
+
+
+
+
+
+
+
+
+# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+
+**223015b** · Modul "Technik 1" · 1. Semester
+Digital- und Medienwirtschaft
+Hochschule der Medien Stuttgart
+
+**Wintersemester 2025/26**
+
+[https://git.librete.ch/hdm/223015b](https://git.librete.ch/hdm/223015b)
+
+---
+
+
+
+# Termin 5 – TBA
+## Vertiefung & Offene Fragen
+
+---
+
+# Ersatztermin
+
+**Dieser Termin wird noch bekannt gegeben.**
+
+Mögliche Inhalte:
+- Vertiefung von Themen nach Wunsch
+- Praxisübungen & Hands-On
+- Offene Fragen & Diskussion
+- Prüfungsvorbereitung
+
+
+
+---
+
+
+
+# Fragen & Diskussion
+
+**Kontakt:** mail@librete.ch
+**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
+
+---
+
+# Lizenz & Attribution
+
+Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
+
+- Erlaubt Teilen & Anpassen mit Namensnennung
+- Adaptionen müssen unter gleicher Lizenz geteilt werden
+
+Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
+
diff --git a/courses/223015b/slides/assets/8bit-P-character.png b/courses/223015b/slides/assets/8bit-P-character.png
new file mode 100644
index 0000000..04a8f7c
Binary files /dev/null and b/courses/223015b/slides/assets/8bit-P-character.png differ
diff --git a/courses/223015b/slides/assets/addaptive-substractive-colors.jpg b/courses/223015b/slides/assets/addaptive-substractive-colors.jpg
new file mode 100644
index 0000000..f4ed381
Binary files /dev/null and b/courses/223015b/slides/assets/addaptive-substractive-colors.jpg differ
diff --git a/courses/223015b/slides/assets/ascii-table.png b/courses/223015b/slides/assets/ascii-table.png
new file mode 100644
index 0000000..32d8521
Binary files /dev/null and b/courses/223015b/slides/assets/ascii-table.png differ
diff --git a/courses/223015b/slides/assets/audio-spectrogram.png b/courses/223015b/slides/assets/audio-spectrogram.png
new file mode 100644
index 0000000..e99cacc
Binary files /dev/null and b/courses/223015b/slides/assets/audio-spectrogram.png differ
diff --git a/courses/223015b/slides/assets/av1-logo.png b/courses/223015b/slides/assets/av1-logo.png
new file mode 100644
index 0000000..eef700d
Binary files /dev/null and b/courses/223015b/slides/assets/av1-logo.png differ
diff --git a/courses/223015b/slides/assets/cassette-ipod.png b/courses/223015b/slides/assets/cassette-ipod.png
new file mode 100644
index 0000000..e05aecf
Binary files /dev/null and b/courses/223015b/slides/assets/cassette-ipod.png differ
diff --git a/courses/223015b/slides/assets/compression-types.png b/courses/223015b/slides/assets/compression-types.png
new file mode 100644
index 0000000..f29a122
Binary files /dev/null and b/courses/223015b/slides/assets/compression-types.png differ
diff --git a/courses/223015b/slides/assets/container-codec-diagram.png b/courses/223015b/slides/assets/container-codec-diagram.png
new file mode 100644
index 0000000..a9b09b7
Binary files /dev/null and b/courses/223015b/slides/assets/container-codec-diagram.png differ
diff --git a/courses/223015b/slides/assets/digital-landscape.png b/courses/223015b/slides/assets/digital-landscape.png
new file mode 100644
index 0000000..a062f8c
Binary files /dev/null and b/courses/223015b/slides/assets/digital-landscape.png differ
diff --git a/courses/223015b/slides/assets/gif-animation.png b/courses/223015b/slides/assets/gif-animation.png
new file mode 100644
index 0000000..340e131
Binary files /dev/null and b/courses/223015b/slides/assets/gif-animation.png differ
diff --git a/courses/223015b/slides/assets/grayscale-gradient.png b/courses/223015b/slides/assets/grayscale-gradient.png
new file mode 100644
index 0000000..b3acb67
Binary files /dev/null and b/courses/223015b/slides/assets/grayscale-gradient.png differ
diff --git a/courses/223015b/slides/assets/hex-binary-table.png b/courses/223015b/slides/assets/hex-binary-table.png
new file mode 100644
index 0000000..01b011a
Binary files /dev/null and b/courses/223015b/slides/assets/hex-binary-table.png differ
diff --git a/courses/223015b/slides/assets/hex-code-hidden.png b/courses/223015b/slides/assets/hex-code-hidden.png
new file mode 100644
index 0000000..af6fd9a
Binary files /dev/null and b/courses/223015b/slides/assets/hex-code-hidden.png differ
diff --git a/courses/223015b/slides/assets/hex-code.png b/courses/223015b/slides/assets/hex-code.png
new file mode 100644
index 0000000..6d8558c
Binary files /dev/null and b/courses/223015b/slides/assets/hex-code.png differ
diff --git a/courses/223015b/slides/assets/hex-dec-lookup-table.png b/courses/223015b/slides/assets/hex-dec-lookup-table.png
new file mode 100644
index 0000000..74560d8
Binary files /dev/null and b/courses/223015b/slides/assets/hex-dec-lookup-table.png differ
diff --git a/courses/223015b/slides/assets/hexeditor-screenshot.png b/courses/223015b/slides/assets/hexeditor-screenshot.png
new file mode 100644
index 0000000..6e54eb2
Binary files /dev/null and b/courses/223015b/slides/assets/hexeditor-screenshot.png differ
diff --git a/courses/223015b/slides/assets/iframe-pframe-diagram.png b/courses/223015b/slides/assets/iframe-pframe-diagram.png
new file mode 100644
index 0000000..f30bf46
Binary files /dev/null and b/courses/223015b/slides/assets/iframe-pframe-diagram.png differ
diff --git a/courses/223015b/slides/assets/instagram-quality-loss.png b/courses/223015b/slides/assets/instagram-quality-loss.png
new file mode 100644
index 0000000..91e0b4e
Binary files /dev/null and b/courses/223015b/slides/assets/instagram-quality-loss.png differ
diff --git a/courses/223015b/slides/assets/jpeg-artifacts.png b/courses/223015b/slides/assets/jpeg-artifacts.png
new file mode 100644
index 0000000..a7d09ab
Binary files /dev/null and b/courses/223015b/slides/assets/jpeg-artifacts.png differ
diff --git a/courses/223015b/slides/assets/jung-naiv.png b/courses/223015b/slides/assets/jung-naiv.png
new file mode 100644
index 0000000..5f43daa
Binary files /dev/null and b/courses/223015b/slides/assets/jung-naiv.png differ
diff --git a/courses/223015b/slides/assets/karlheinz-brandenburg.jpg b/courses/223015b/slides/assets/karlheinz-brandenburg.jpg
new file mode 100644
index 0000000..a53feb6
Binary files /dev/null and b/courses/223015b/slides/assets/karlheinz-brandenburg.jpg differ
diff --git a/courses/223015b/slides/assets/lightbulb-onoff.png b/courses/223015b/slides/assets/lightbulb-onoff.png
new file mode 100644
index 0000000..2625690
Binary files /dev/null and b/courses/223015b/slides/assets/lightbulb-onoff.png differ
diff --git a/courses/223015b/slides/assets/matrix-code.png b/courses/223015b/slides/assets/matrix-code.png
new file mode 100644
index 0000000..2939e8c
Binary files /dev/null and b/courses/223015b/slides/assets/matrix-code.png differ
diff --git a/courses/223015b/slides/assets/napster-interface.png b/courses/223015b/slides/assets/napster-interface.png
new file mode 100644
index 0000000..abefb30
Binary files /dev/null and b/courses/223015b/slides/assets/napster-interface.png differ
diff --git a/courses/223015b/slides/assets/netflix-4k.png b/courses/223015b/slides/assets/netflix-4k.png
new file mode 100644
index 0000000..2d2f88e
Binary files /dev/null and b/courses/223015b/slides/assets/netflix-4k.png differ
diff --git a/courses/223015b/slides/assets/original-ascii-table.png b/courses/223015b/slides/assets/original-ascii-table.png
new file mode 100644
index 0000000..2c12218
Binary files /dev/null and b/courses/223015b/slides/assets/original-ascii-table.png differ
diff --git a/courses/223015b/slides/assets/photo-comparison.png b/courses/223015b/slides/assets/photo-comparison.png
new file mode 100644
index 0000000..78d2e9f
Binary files /dev/null and b/courses/223015b/slides/assets/photo-comparison.png differ
diff --git a/courses/223015b/slides/assets/qrcode-0.svg b/courses/223015b/slides/assets/qrcode-0.svg
new file mode 100644
index 0000000..e7c08fd
--- /dev/null
+++ b/courses/223015b/slides/assets/qrcode-0.svg
@@ -0,0 +1 @@
+
diff --git a/courses/223015b/slides/assets/qrcode-1.svg b/courses/223015b/slides/assets/qrcode-1.svg
new file mode 100644
index 0000000..d6a6c92
--- /dev/null
+++ b/courses/223015b/slides/assets/qrcode-1.svg
@@ -0,0 +1 @@
+
diff --git a/courses/223015b/slides/assets/rgb-color-model-with-title.png b/courses/223015b/slides/assets/rgb-color-model-with-title.png
new file mode 100644
index 0000000..ba1d892
Binary files /dev/null and b/courses/223015b/slides/assets/rgb-color-model-with-title.png differ
diff --git a/courses/223015b/slides/assets/rgb-color-model.png b/courses/223015b/slides/assets/rgb-color-model.png
new file mode 100644
index 0000000..4f0ae08
Binary files /dev/null and b/courses/223015b/slides/assets/rgb-color-model.png differ
diff --git a/courses/223015b/slides/assets/spectogram-chet-baker.png b/courses/223015b/slides/assets/spectogram-chet-baker.png
new file mode 100644
index 0000000..8917dd7
Binary files /dev/null and b/courses/223015b/slides/assets/spectogram-chet-baker.png differ
diff --git a/courses/223015b/slides/assets/streaming-quality-switch.png b/courses/223015b/slides/assets/streaming-quality-switch.png
new file mode 100644
index 0000000..2e7c2e3
Binary files /dev/null and b/courses/223015b/slides/assets/streaming-quality-switch.png differ
diff --git a/courses/223015b/slides/assets/suzanne-vega.jpg b/courses/223015b/slides/assets/suzanne-vega.jpg
new file mode 100644
index 0000000..68c65e9
Binary files /dev/null and b/courses/223015b/slides/assets/suzanne-vega.jpg differ
diff --git a/courses/223015b/slides/assets/youtube-vp9.png b/courses/223015b/slides/assets/youtube-vp9.png
new file mode 100644
index 0000000..9d1b7c6
Binary files /dev/null and b/courses/223015b/slides/assets/youtube-vp9.png differ
diff --git a/courses/223015b/slides/materials/wtf1 b/courses/223015b/slides/materials/wtf1
new file mode 100644
index 0000000..a11e251
--- /dev/null
+++ b/courses/223015b/slides/materials/wtf1
@@ -0,0 +1 @@
+Dies ist eine einfache Textdatei. Keine Magic Number hier! Plaintext hat keinen Standard-Header.
diff --git a/courses/223015b/slides/materials/wtf2 b/courses/223015b/slides/materials/wtf2
new file mode 100644
index 0000000..6f25cb7
Binary files /dev/null and b/courses/223015b/slides/materials/wtf2 differ
diff --git a/courses/223015b/slides/materials/wtf3 b/courses/223015b/slides/materials/wtf3
new file mode 100644
index 0000000..ba3579b
Binary files /dev/null and b/courses/223015b/slides/materials/wtf3 differ