hdm/223015b
1
0
Fork 0
Code Pull Requests Activity

split index.md into modular slide files

Browse Source 
- extract _frontmatter.md, _intro.md, _outro.md as shared components
- create separate files per termin with date-topic naming convention:
  2025-12-19-termin-1-grundlagen-text-audio.md
  2026-01-09-termin-2-bild-audio-video.md
  2026-01-23-termin-3-speichermedien-schnittstellen.md
  2026-01-30-termin-4-distribution-apis-zukunft.md
  2026-xx-xx-termin-5-vertiefung-offene-fragen.md
- keep index.md.bak as backup (gitignored)
This commit is contained in:
libretech
2025-12-14 20:34:20 +01:00
parent 660ef3426c
commit 32a8efb92d
10 changed files with 4210 additions and 4209 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.gitignore
+1
View File
@@ -61,3 +61,4 @@ Desktop.ini
*.html *.html
!build/*.html !build/*.html
*.pdf *.pdf
index.md.bak
index.md
-4209
View File
File diff suppressed because it is too large Load Diff
slides/2025-12-19-termin-1-grundlagen-text-audio.md
+634
View File
@@ -0,0 +1,634 @@
---
<!-- _class: lead -->
# Termin 1 – 19.12.2025
## Grundlagen, Text & Audio
---
![bg right:40%](./assets/matrix-code.jpg)
# Mysterium
```
89 50 4E 47 0D 0A 1A 0A
00 00 00 0D 49 48 44 52
00 00 01 90 00 00 01 2C
```
**Was ist das?**
<!--
Hex-Dump ohne Erklärung auf Bildschirm werfen
Fragen in den Raum: "Was seht ihr?"
"Ist das Text? Ein Bild? Code?"
Überleitung: "Alles digital ist nur Zahlen. Heute lernen wir, sie zu lesen."
-->
---
# Das Bit
**Kleinste Informationseinheit**
- **0 oder 1**
- AN oder AUS
- Strom fließt oder nicht
![bg right:50%](./assets/lightbulb-onoff.jpg)
<!--
Bit = Binary Digit
Demonstration: Glühbirne AN/AUS = 1 Bit
Alles Digitale basiert darauf
Transistoren in CPUs: Milliarden Bits schalten Millionen Mal pro Sekunde
-->
---
# Das Byte
**8 Bits = 1 Byte**
```
0 1 0 0 1 1 0 1
```
**Wie viele Kombinationen?**
2⁸ = **256 Möglichkeiten** (0-255)
<!--
Rechnung gemeinsam: 2×2×2×2×2×2×2×2 = 256
Jedes Bit kann 0 oder 1 sein
256 verschiedene Werte mit 8 Bits darstellbar
-->
---
# Was kann man mit 256 Zuständen machen?
- **256 Zeichen** (Buchstaben, Zahlen, Symbole)
- **256 Graustufen** (0 = Schwarz, 255 = Weiß)
- **256 Lautstärkestufen**
- **Zahlen 0-255** (oder -128 bis +127)
![bg left:40%](./assets/grayscale-gradient.jpg)
<!--
1 Byte ist extrem limitiert
Für Farbbild: 3 Bytes pro Pixel (RGB)
R=0-255, G=0-255, B=0-255 → 256³ = 16,7 Millionen Farben
-->
---
# Farben: RGB-Modell
**1 Pixel = 3 Bytes**
- **Rot:** 0-255
- **Grün:** 0-255
- **Blau:** 0-255
**Beispiel:**
`FF 00 00` = Rot
`00 FF 00` = Grün
`FF FF FF` = Weiß
![bg right:40%](./assets/rgb-color-model.jpg)
<!--
RGB = Additive Farbmischung (Bildschirme)
CMYK = Subtraktive Farbmischung (Druck)
Hex-Notation: FF = 255 in Dezimal
CSS-Farben nutzen Hex: #FF0000 = Rot
-->
---
# 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
-->
---
![bg](./assets/ascii-table.png)
<!--
ASCII-Tabelle (1963)
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
-->
---
# 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)
<!--
Unicode Consortium: Non-Profit seit 1991
Aktuell: Unicode 16.0 (2024)
UTF-8 = Unicode Transformation Format, 8-bit
ASCII-kompatibel: "A" = 1 Byte (rückwärtskompatibel)
Umlaute: "ä" = 2 Bytes, Chinesisch: 3 Bytes, Emoji: 4 Bytes
-->
---
# Beispiel: Bytes zählen
**Text:** `"Why the fuck braucht 💩 4 Bytes?!"`
```
W h y → je 1 Byte (4 Bytes)
t h e → je 1 Byte (4 Bytes)
f u 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**
<!--
Buchstaben = 1 Byte (ASCII/UTF-8-kompatibel)
Emoji = 4 Bytes (Unicode-Bereich U+1F4A9)
Haufen-Emoji: "Pile of Poo" (offizieller Name!)
UTF-8-Kodierung: Variable Länge spart Speicher bei ASCII
-->
---
# Hexadezimal: Lesbarkeit
**Binär ist unleserlich:**
`01001101 01010000 00110011`
**Hexadezimal (Base 16):**
`4D 50 33` (= "MP3" in ASCII)
**Jede Hex-Ziffer = 4 Bits**
0-9, A-F (10=A, 11=B, ..., 15=F)
![bg right:40%](./assets/hex-binary-table.jpg)
<!--
Hex = Shortcut für Menschen, nicht für Computer
Computer denken binär, wir lesen hex
1 Byte = 2 Hex-Ziffern (00-FF)
Hex-Editor: Standard-Tool für Dateianalyse
-->
---
# Magic Numbers
**Dateityp-Identifikation durch erste Bytes**
| Format | Magic Number (Hex) | ASCII |
|--------|-------------------|-------|
| PNG | `89 50 4E 47 0D 0A 1A 0A` | `.PNG` |
| JPEG | `FF D8 FF` | `ÿØÿ` |
| PDF | `25 50 44 46` | `%PDF` |
| ZIP | `50 4B 03 04` | `PK` |
<!--
Magic Number = Signature am Dateianfang
Computer schauen in erste Bytes (nicht auf .jpg/.png)
"PK" = Phil Katz (Erfinder von PKZip)
Dateiendungen können lügen, Magic Numbers nicht
-->
---
![bg](./assets/hexeditor-screenshot.png)
<!--
Hex-Editor-Screenshot mit PNG-Datei
Erste Bytes: 89 50 4E 47 = PNG-Signatur
IHDR = Image Header (Breite, Höhe, Farbtiefe)
Zeigen, wie man Magic Number liest
Tool: HxD (Windows), Hex Fiend (Mac), xxd (Linux)
-->
---
# Hands-On: Mystery Files
**Aufgabe (30 Min):**
1. Drei Dateien ohne Extension: `mystery1`, `mystery2`, `mystery3`
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
<!--
Praktische Phase: Studierende arbeiten selbst
Dateien: PNG, JPEG, TXT (vorbereitet)
Gruppenarbeit: 3-4 Personen
Ziel: Hex-Dump lesen lernen, Dateiformate verstehen
-->
---
# Aufgabe bis nächste Woche
**Finde eine Datei auf deinem Computer**
1. Öffne im Hex-Editor
2. Screenshot der ersten 16 Bytes
3. Identifiziere Magic Number
4. Poste im Forum: Format + kurze Beschreibung
**Bonus:** Finde Datei ohne Magic Number in Standard-Listen
<!--
Selbstständiges Arbeiten
Forum: Peer-Learning, gegenseitige Hilfe
Bonus: Spornt Neugierige an
-->
---
<!-- _class: lead -->
# Teil 2: Die MP3-Revolution
## Psychoakustik & Audio-Kompression
---
![bg](./assets/cassette-ipod.jpg)
<!--
Kassette neben iPod
Visueller Kontrast: Analog vs. Digital
1980er vs. 2000er
-->
---
# 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!
<!--
CD-Qualität = Standard seit 1982
Ein Album = ganze Festplatte
Download bei 56k-Modem = Tage!
Streaming? Unmöglich.
-->
---
# Zwei Philosophien
![bg right:50%](./assets/compression-types.jpg)
**Lossless (Verlustfrei):**
- Original exakt wiederherstellbar
- ZIP, PNG, FLAC
- 30-50% Ersparnis
**Lossy (Verlustbehaftet):**
- Daten irreversibel verändert
- JPEG, MP3, H.264
- 90%+ Ersparnis
<!--
Lossless: Findet Muster, beschreibt effizienter
Lossy: Wirft "Unwichtiges" weg (Psychoakustik/Psychovisuell)
Trade-off: Größe vs. Qualität
-->
---
# Lossless: Run-Length Encoding
**Original:**
```
AAAAABBBCCCCCCCC
```
**Komprimiert:**
```
5A 3B 8C
```
**Ersparnis:** 16 → 6 Zeichen (62% Reduktion)
<!--
RLE = Simplest Compression Algorithm
Gut für repetitive Daten (Fax, simple Grafiken)
Schlecht für chaotische Daten (Fotos, Audio)
-->
---
# 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
**MP3:** Schwächen des Ohrs
- Mittlere Frequenzen besser als hohe/tiefe
- Laute Töne "maskieren" leise Töne
→ **Psychoakustik / Psychovisuell**
<!--
Auditory Masking: Lauter 1000 Hz-Ton → leise 950 Hz unhörbar
Visuelle Masking: Starker Kontrast überstrahlt Details
Kompression = Modell der menschlichen Wahrnehmung
-->
---
![bg](./assets/karlheinz-brandenburg.jpg)
<!--
Foto: Karlheinz Brandenburg
Fraunhofer IIS Erlangen
"Vater der MP3"
-->
---
# 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](./assets/suzanne-vega.jpg)
<!--
Suzanne Vega – "Tom's Diner" (1987)
Der erste Song, der als MP3 kodiert wurde
Karlheinz Brandenburg hörte ihn tausende Male
-->
---
# "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
<!--
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?
**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
<!--
FFT = Fast Fourier Transform
Psychoakustik = Modell des menschlichen Gehörs
Quantisierung = Wo passiert Datenverlust
Huffman = Finaler Effizienz-Boost (lossless)
MP3 ist KEIN einfaches "Kleiner machen" – es simuliert dein Gehirn
-->
---
# 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
-->
---
![bg](./assets/audio-spectrogram.jpg)
<!--
Spektrogramm-Vergleich
Original vs. 320 kbps vs. 128 kbps
Hohe Frequenzen verschwinden bei niedriger Bitrate
Visuell: Dunkle Bereiche = fehlende Frequenzen
-->
---
# 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
<!--
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)
-->
---
![bg](./assets/napster-interface.jpg)
<!--
Napster-Screenshot (1999)
P2P-Filesharing für MP3s
Shawn Fanning, 19 Jahre alt
80 Millionen User in 2 Jahren
-->
---
# 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
<!--
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
-->
---
# 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
<!--
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
-->
---
# 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
**Optional:** Spektrogramm-Ansicht
<!--
Audacity: FOSS Audio-Editor
Export: Datei → Exportieren → MP3 → Bitrate wählen
Spektrogramm: Analysieren → Spektrogramm
Hohe Frequenzen verschwinden bei niedriger Bitrate
-->
---
# Aufgabe bis nächste Woche
**Nimm ein Lied (eigenes oder CC)**
1. Exportiere: WAV, MP3 320 kbps, MP3 128 kbps
2. Notiere: Dateigrößen, Höreindrücke
3. Poste im Forum: Screenshot + Reflexion
**Bonus:** Niedrigste Bitrate finden, bei der du keinen Unterschied hörst
<!--
WAV = Unkomprimiert (Referenz)
Goldenes Ohr: Manche hören Unterschied, manche nicht
Psychoakustik in Aktion: Subjektive Wahrnehmung
-->
slides/2026-01-09-termin-2-bild-audio-video.md
+686
View File
@@ -0,0 +1,686 @@
---
<!-- _class: lead -->
# Termin 2 – 09.01.2026
## Bild-, Audio- & Videoformate
---
![bg](./assets/photo-comparison.jpg)
<!--
Links: Hochauflösend
Rechts: Stark komprimiert (JPEG-Artefakte sichtbar)
Instagram-Effekt
-->
---
# 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!**
<!--
Zoom auf Pixel-Ebene zeigen
Jedes Pixel = RGB-Tripel (3 Bytes)
6 MB × 10.000 Fotos = 62 GB
Smartphone-Speicher wäre schnell voll ohne Kompression
-->
---
# 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
<!--
PNG wurde entwickelt als GIF-Alternative (Patent-Probleme)
Lossless: Originaldaten bleiben erhalten
Transparenz: Alpha-Kanal (sanfte Übergänge)
DEFLATE: Gleicher Algorithmus wie ZIP
-->
---
# Lossy: JPEG
**JPEG = Joint Photographic Experts Group (1992)**
**Eigenschaften:**
- Lossy Kompression
- 90%+ Platzersparnis möglich
- Artefakte bei hoher Kompression
**6 MB → 500 KB** (typisch)
<!--
JPEG-Norm beschreibt nur Kompression, nicht Speicherformat
JFIF = JPEG File Interchange Format (das eigentliche Dateiformat)
Dateierweiterungen: .jpg, .jpeg, .jfif (alle gleich)
-->
---
![bg](./assets/jpeg-artifacts.jpg)
<!--
Beispiel: Stark komprimiertes JPEG
Blocking (8×8-Blöcke sichtbar)
Ringing (Geister um Kanten)
Color Banding (Verläufe "treppig")
-->
---
# 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
<!--
YCbCr = Farbraum-Konversion
Y = Brightness, Cb = Blue-Yellow, Cr = Red-Green
4:2:0 Subsampling: Farbe nur jedes 2. Pixel horizontal & vertikal
Auge merkt's kaum, weil Helligkeitssehen dominiert
-->
---
# 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
<!--
DCT: Ähnlich wie FFT bei Audio
8×8 Blöcke: Warum JPEG "blocky" wird bei hoher Kompression
Quantisierung: Quality-Schieberegler steuert genau das
Huffman: Finale Effizienz (wie bei MP3)
-->
---
# 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
<!--
Quality 100 = Minimum Compression (nicht lossless!)
Quality 85-90 = Standard für Web
Quality 50 = Sichtbare Artefakte (Blocking, Ringing)
Photoshop "Save for Web": Standard ist 60
-->
---
![bg](./assets/gif-animation.gif)
<!--
GIF-Animation (z.B. Meme)
256 Farben, aber Animationen möglich
-->
---
# 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**
<!--
CompuServe: Früher Online-Dienst (1969-2009)
LZW = Lempel-Ziv-Welch Compression
Unisys Patent-Trolling: Erst Jahre nach GIF-Einführung
Community-Reaktion: Boykott, Suche nach Alternative
Ergebnis: PNG wurde entwickelt (1996)
-->
---
# 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!
<!--
APNG = Animated PNG (Firefox, Safari support)
WebP (Google, 2010): Animationen + bessere Kompression
GIF überlebte kulturell (Meme-Format)
"GIF" Aussprache: "Jif" vs. "Gif" – ewiger Streit
-->
---
# 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
<!--
WebP: Von Google entwickelt, deshalb Skepsis
AVIF: Alliance for Open Media (Google, Netflix, Amazon, Mozilla...)
Browser-Support 2024: WebP fast überall, AVIF wachsend
JPEG bleibt dominant (Kompatibilität!)
-->
---
![bg](./assets/instagram-quality-loss.jpg)
<!--
Vorher/Nachher: Hochauflösend vs. Instagram-Upload
Sichtbare Qualitätsverluste
-->
---
# 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)
<!--
Instagram ist keine Kunstgalerie
Optimiert für Geschwindigkeit, nicht Qualität
Facebook macht dasselbe
Lösung: Portfolio-Websites (eigene Kontrolle)
-->
---
# 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?
<!--
Squoosh.app: Browser-basiert, keine Installation
Side-by-Side-Vergleich mit Zoom
Verschiedene Codecs testen
Studis sollen selbst "Sweet Spot" finden
-->
---
# 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. Poste im Forum: Screenshot + Reflexion
**Fragen:**
- Welche Quality ist für dich "akzeptabel"?
- Wo siehst du zuerst Artefakte?
**Bonus:** Teste WebP oder AVIF
<!--
Selbstständiges Experimentieren
Subjektive Wahrnehmung (jeder anders)
Forum: Austausch über Ergebnisse
-->
---
<!-- _class: lead -->
# Teil 2: Video
## Kompression & Codecs
---
![bg](./assets/netflix-4k.jpg)
<!--
Netflix 4K-Streaming
Unmöglich ohne moderne 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!**
<!--
4K = 3840×2160 Pixel = 8,3 Megapixel pro Frame
30 fps = Standard, Kino = 24 fps, Gaming = 60+ fps
Ohne Kompression: Unmöglich zu streamen oder speichern
-->
---
# 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
<!--
Container ≠ Codec (häufiges Missverständnis!)
MP4 ist KEIN Codec, sondern Container
Schachtel-Analogie: Container = Karton, Codec = Inhalt
Ein MP4 kann H.264, H.265 oder AV1 enthalten
-->
---
![bg](./assets/container-codec-diagram.jpg)
<!--
Diagramm: Container mit verschiedenen Streams
Video-Track (H.264)
Audio-Track (AAC)
Untertitel-Track (SRT)
Metadaten (Titel, Künstler, etc.)
-->
---
# 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"
<!--
Spatial: Innerhalb eines Bildes (JPEG-ähnlich)
Temporal: Zwischen Bildern (zeitliche Redundanz)
Motion Compensation: Intelligente Vorhersage
→ 90%+ Effizienz durch temporale Kompression
-->
---
# 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
<!--
GOP = Group of Pictures (typisch 12-15 Frames)
I-Frame: Alle 1-2 Sekunden nötig (für Seeking)
P-Frame: "Pixel X bewegt sich 5px rechts"
B-Frame: Komplex, aber beste Kompression
Wenn du vorspulst: Sucht nach nächstem I-Frame
-->
---
![bg](./assets/iframe-pframe-diagram.jpg)
<!--
Visualisierung: I/P/B-Frame-Abhängigkeiten
Pfeile zeigen Referenzen
I-Frame = Anker, P/B-Frames hängen dran
-->
---
# 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
<!--
AVC = Advanced Video Coding
MPEG-4 Part 10 = H.264 (gleicher Standard)
Revolutionierte Video-Streaming
Hardware-Decoder in CPUs/GPUs → Batterie-schonend
CABAC = Context-Adaptive Binary Arithmetic 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
<!--
MPEG-LA = Licensing Authority
Firefox weigerte sich lange, H.264 zu supporten (Patent-Gründe)
Chromium musste extern linken
Patent-Pool: Firmen teilen Patente, gemeinsame Lizenzierung
"Free to View" Klausel: YouTube etc. kostenlos
-->
---
# 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
<!--
HEVC = High Efficiency Video Coding
Technisch überlegen, aber juristisch Albtraum
Apple nutzt HEVC (iPhone-Videos)
Netflix zögert wegen Lizenzkosten
Fragmentierung verzögert Adoption
-->
---
![bg](./assets/youtube-vp9.jpg)
<!--
YouTube VP9-Logo
Google's Patent-freie Alternative
-->
---
# 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
<!--
On2 Technologies: Gekauft 2010 für $133M
VP8 → VP9 → AV1 (Evolution)
YouTube forciert VP9: 4K-Videos nur VP9/AV1
Hardware-Decoder erst ab ~2016 (langsame Adoption)
-->
---
![bg](./assets/av1-logo.jpg)
<!--
AV1-Logo
Alliance for Open Media
-->
---
# 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
<!--
AOM = Alliance for Open Media (2015 gegründet)
Alle Big-Tech-Player vereint (historisch!)
"Fuck you" an Patent-Mafia
Problem: Encoding SEHR langsam (10-100x vs. H.264)
Hardware-Encoder kommen (ab 2020er-GPUs)
-->
---
# 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
<!--
DASH = Dynamic Adaptive Streaming over HTTP
HLS = HTTP Live Streaming (Apple)
Beide ähnlich, aber inkompatibel
Manifest-Datei: Liste aller Qualitäten
Player misst Bandbreite, wechselt live
→ Warum Netflix plötzlich pixelig wird
-->
---
![bg](./assets/streaming-quality-switch.jpg)
<!--
Visualisierung: Qualitätswechsel während Playback
Bandbreite schwankt → Player reagiert
-->
---
# 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
<!--
MP4 = MPEG-4 Part 14 (ISO-Standard)
Matroska = Russisch: Matrjoschka (Puppen ineinander)
WebM = Subset von Matroska (HTML5-Video)
MKV vs. MP4: Offenheit vs. Kompatibilität
-->
---
# 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
<!--
Big Buck Bunny: Open-Source-Film (Blender Foundation)
FFmpeg: Swiss Army Knife für Video
HandBrake: GUI für FFmpeg (einfacher)
MediaInfo: Detaillierte Datei-Analyse
Encoding-Zeit: H.265 deutlich langsamer als H.264
-->
---
# 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. Poste im Forum:
- Dateigrößen
- Encoding-Zeiten
- Visueller Unterschied?
**Bonus:** AV1-Encoding (Warnung: SEHR langsam!)
<!--
MediaInfo oder ffprobe für Analyse
HandBrake für Konvertierung (einfacher als CLI)
Encoding-Zeit: H.265 ~5x langsamer, AV1 ~50x langsamer
Qualität: Bei gleicher Bitrate H.265 > H.264
-->
slides/2026-01-23-termin-3-speichermedien-schnittstellen.md
+918
View File
@@ -0,0 +1,918 @@
---
<!-- _class: lead -->
# Termin 3 – 23.01.2026
## Speichermedien & Schnittstellen
---
![bg](./assets/hdd-ssd-comparison.jpg)
<!--
HDD aufgeschraubt neben SSD-Platine
Mechanisch vs. Elektronisch
-->
---
# 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
<!--
Wiederholung aus vorheriger Iteration (falls schon behandelt)
Oder erste Einführung, falls Woche 5 Startpunkt für Speicher
HDD: Platter, Lesekopf, 5.400-15.000 RPM
SSD: NAND-Flash (SLC/MLC/TLC/QLC)
-->
---
# Was fehlt? Dateisysteme!
**Dateisystem = Bibliothekskatalog für Festplatte**
**Aufgaben:**
- Dateien speichern & finden
- Metadaten verwalten
- Speicherplatz effizient nutzen
- Fehler erkennen & beheben
<!--
Ohne Dateisystem: Rohe Bytes, keine Struktur
Vergleich: Bibliothek ohne Katalog = Chaos
Jedes OS hat bevorzugtes Dateisystem
Windows: NTFS, macOS: APFS, Linux: ext4
-->
---
![bg](./assets/directory-tree.jpg)
<!--
Verzeichnisbaum-Visualisierung
Root → Ordner → Unterordner → Dateien
Unix: / (Root), Windows: C:\ (Laufwerk)
-->
---
# 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)
<!--
Partitionstabelle: MBR (alt) vs. GPT (modern)
GPT = GUID Partition Table (128 Partitionen möglich)
EFI System Partition (ESP): Bootloader bei UEFI
LBA = Logical Block Addressing
-->
---
# Formatierung
**Schnellformatierung:**
- Löscht nur Metadaten
- Daten physisch noch da
- → Datenrettung möglich!
**Vollständige Formatierung:**
- Überschreibt mit Nullen
- Dauert länger, aber sicherer
<!--
Formatierung ≠ Löschen!
Schnellformat: "Inhaltsverzeichnis" wird gelöscht
Recuva, PhotoRec: Datenrettungssoftware
Sicheres Löschen: DBAN, shred, eraser
-->
---
# 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
<!--
FAT = Tabelle am Anfang der Partition
Verkettete Liste von Clustern
Fragmentierung: Cluster verstreut → langsam
USB-Sticks heute meist FAT32 (Kompatibilität!)
exFAT: Microsoft-Patent, seit 2019 in Linux-Kernel
-->
---
# 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)
<!--
Windows NT-Ära (1993)
Master File Table (MFT): Zentrale Datenbank
Journaling: Transaktionslog verhindert Datenverlust
ACL = Access Control List
EFS = Encrypting File System
Nachfolger: ReFS (Resilient FS, noch nicht Standard)
-->
---
# APFS
**Apple File System (2017)**
**Features:**
✓ Copy-on-Write (Speicherersparnis!)
✓ Snapshots (Time Machine)
✓ Native Verschlüsselung
✓ SSD-optimiert
**Nachteil:** Nur Apple-Geräte
<!--
Ersetzt HFS+ (1998)
Copy-on-Write: Datei kopieren = nur Pointer
Clones: Duplikate ohne Speicherplatz-Verdopplung
Space Sharing: Volumes teilen dynamisch Partition
FileVault 2 nutzt APFS-Verschlüsselung
-->
---
# 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
<!--
Evolution: ext (1992) → ext2 → ext3 → ext4
Extents: Zusammenhängende Blöcke als Einheit
Delayed Allocation: Schreibvorgänge gebündelt
fsck: File System Check (Reparatur-Tool)
Alternativen: btrfs (CoW, Snapshots), XFS, ZFS
-->
---
# 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 |
<!--
EB = Exabyte = 1.000.000 TB
Kompatibilität: FAT32/exFAT für USB-Sticks
Performance: APFS/ext4 für SSDs
Sicherheit: APFS/NTFS für Verschlüsselung
-->
---
![bg](./assets/backup-disaster.jpg)
<!--
Symbolbild: Kaputte Festplatte, verzweifelter User
Oder: Ransomware-Warnung auf Bildschirm
-->
---
# 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
<!--
Backblaze: 1-2% jährliche HDD-Ausfallrate
Ransomware 2023: 300%+ Anstieg (FBI)
Horror-Story: Pixar verlor fast "Toy Story 2" (1998)
Rettung: Mitarbeiterin hatte Home-Backup
3-2-1-Regel kommt gleich
-->
---
# 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
<!--
Vollbackup: Jeden Sonntag (500 GB)
Inkrementell: Mo-Sa Änderungen (10 GB/Tag)
Differenziell: Mo-Sa Änderungen seit Sonntag (wächst)
Wiederherstellung: Full = 1 Schritt, Inkr. = 7, Diff. = 2
-->
---
# 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
<!--
3-2-1 ist MINIMUM, nicht Maximum!
Medientypen: SSD, HDD, Optical, Cloud, Tape
Offsite: Schutz vor lokalem Desaster
Versionierung: Auch alte Versionen aufbewahren
Automatisierung: Sonst vergisst man's
-->
---
# Backup-Software
**macOS:** Time Machine
**Windows:** Veeam Agent (kostenlos)
**Linux:** rsync, Borg, Restic
**Plattformübergreifend:** Duplicati, Syncthing
**Cloud:** Backblaze, Nextcloud
<!--
Time Machine: Stündliche Snapshots, APFS-Snapshots
Veeam: Enterprise-Level, kostenlose Version für Endnutzer
rsync: Unix-Tool seit 1996, extrem effizient
Borg: Deduplizierung + Verschlüsselung
Syncthing: P2P-Sync, kein zentraler Server
-->
---
![bg](./assets/bit-rot.jpg)
<!--
Visualisierung: Verfallende Daten
Oder: Alte Disketten, unlesbar
-->
---
# Langzeitarchivierung: Das Problem
**Digitale Daten altern:**
- Bit Rot (Degradation)
- Format-Obsoleszenz (WordPerfect .wpd)
- Hardware-Obsoleszenz (Diskettenlaufwerke)
**Lösung:**
Migration + offene Standards
<!--
Bit Rot: Daten verschlechtern sich über Zeit
HDDs: 10-20 Jahre, SSDs: 5-10 Jahre ohne Strom
Format-Obsoleszenz: WordPerfect dominant 1980-90er, heute tot
Hardware: Floppy, ZIP-Disks, heute unmöglich
Migration: Alle 5-10 Jahre auf neue Medien
Offene Standards: PDF/A, TIFF, TXT überleben
-->
---
![bg](./assets/lto-tape.jpg)
<!--
LTO-Kassette + Laufwerk
Magnetband-Technologie
-->
---
# 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
<!--
LTO = Offener Standard seit 1998
LTO-9: 400 MB/s, 1 Million Durchläufe
AWS Snowball nutzt intern Tapes
Problem: Sequenzieller Zugriff (langsam für einzelne Dateien)
Cold Storage: Daten, die selten gebraucht werden
-->
---
![bg](./assets/m-disc.jpg)
<!--
M-DISC Blu-ray
Metallschicht statt Farbstoff
-->
---
# M-DISC (Millennial Disc)
**Eigenschaften:**
- DVD/Blu-ray-kompatibel
- Anorganische Metallschicht
- Haltbarkeit: 1.000 Jahre (Tests)
- Einsatz: Familienfotos, Archive
<!--
Millenniata entwickelt, 2009
Normale DVDs: Organischer Farbstoff zersetzt sich (10-25 Jahre)
M-DISC: Daten "eingraviert" (nicht Farbänderung)
US-Verteidigungsministerium: Tests bestätigt
Nachteil: Teurer (~5€ vs. 0,50€ normale Blu-ray)
-->
---
![bg](./assets/dna-helix.jpg)
<!--
DNA-Helix mit Binärcode überlagert
Futuristische Darstellung
-->
---
# 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)
<!--
DNA = A, T, G, C (4 Basen)
Kodierung: Binär (00=A, 01=T, 10=G, 11=C)
Harvard (2017): Wikipedia (11 GB) in DNA
Problem: Synthese & Sequenzierung extrem langsam/teuer
Anwendung: Langzeitarchivierung (nicht Live-Daten)
-->
---
# 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
<!--
S.M.A.R.T. = Self-Monitoring, Analysis, Reporting Technology
Reallocated Sector Count: >0 = Warnsignal!
Current Pending Sector: Kritisch!
Power-On Hours: >30.000h = alt
Backup-Test: Ungetestete Backups sind wertlos!
-->
---
# Aufgabe bis nächste Woche
**Analysiere dein System:**
1. Welches Dateisystem nutzt deine Hauptpartition?
2. Hast du ein Backup? Welche Art? Wo?
3. Poste im Forum: S.M.A.R.T.-Screenshot + Backup-Strategie
**Bonus:** Richte automatisches Backup ein
<!--
Selbstreflexion: 60-70% haben KEIN Backup!
Forum: Peer-Lernen, gegenseitige Motivation
Bonus: Wer's macht, hat echten Nutzen
-->
---
<!-- _class: lead -->
# Teil 2: Schnittstellen
## USB-C, HDMI & das Kabel-Chaos
---
![bg](./assets/cable-mess.jpg)
<!--
Kabelsalat: USB-A, USB-C, HDMI, DisplayPort, Lightning
Chaos der Standards
-->
---
# Was ist eine Schnittstelle?
**Schnittstelle = Verbindung zwischen Systemen**
**Hardware-Schnittstellen:**
Physischer Anschluss (USB, HDMI, Ethernet)
**Software-Schnittstellen:**
API (nächste Woche!)
**Heute:** Hardware-Fokus
<!--
Interface = Berührungspunkt zwischen Systemen
Definiert: Form, Pins, elektrische Signale, Protokoll
Ohne Standards: Jedes Gerät braucht eigenes Kabel
-->
---
![bg](./assets/pc-back-1990s.jpg)
<!--
PC-Rückseite 1990er
PS/2, Seriell, Parallel, SCSI, VGA – Chaos!
-->
---
# 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 1.0: 1996, Intel + Microsoft + Compaq
Vorher: Jedes Gerät eigener Port
Hot-Pluggable: Ein-/Ausstecken im laufenden Betrieb
Plug & Play: Automatische Erkennung
-->
---
# 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-IF (Implementers Forum) = Marketing-Wahnsinn
USB 3.0 umbenannt in "USB 3.2 Gen 1" (2019)
Verwirrung absichtlich? Konspirations-Theorien...
USB 4 basiert auf Thunderbolt 3 (Intel spendete Spec)
-->
---
![bg](./assets/usb-c-cables.jpg)
<!--
Identisch aussehende USB-C-Kabel
Aber: Unterschiedliche Specs!
-->
---
# 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-C = "Auto" (sagt nichts über PS, Hubraum)
Kleingedrucktes lesen!
Billige Kabel oft nur USB 2.0 (Lade-Kabel)
Teuer ≠ besser (aber oft ja)
USB-IF Zertifizierung: Logo zeigt Spec an
-->
---
# 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!
<!--
Standard USB: 5V, 0,5A = 2,5W
USB PD: Variable Spannung (Verhandlung zwischen Geräten)
Günstige Kabel: Oft nur 60W
Zertifizierte Kabel: 100W+
Laptop-Netzteil ersetzbar durch USB-C 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!
<!--
Alt Mode: Andere Protokolle über USB-C-Kabel
DisplayPort Alt Mode: Häufig (Monitore)
HDMI Alt Mode: Selten
Trial & Error beim Kabelkauf
EU-Regulierung: Beschriftung gefordert (aber nicht umgesetzt)
-->
---
![bg](./assets/thunderbolt-logo.jpg)
<!--
Thunderbolt-Logo (Blitz-Symbol)
Intel + Apple Technologie
-->
---
# 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
<!--
Thunderbolt 1/2: Mini DisplayPort (2011-2013)
Thunderbolt 3: USB-C-Stecker, aber nicht jeder USB-C ist Thunderbolt!
PCIe über Kabel: Externe GPU-Gehäuse möglich
Daisychaining: Mehrere Geräte verketten (wie SCSI früher)
Zertifizierung: Blitz-Logo = echt Thunderbolt
-->
---
![bg](./assets/hdmi-cable.jpg)
<!--
HDMI-Kabel + Stecker
Heimkino-Standard
-->
---
# 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
<!--
HDMI = High-Definition Multimedia Interface
ARC = Audio Return Channel (TV → Soundbar)
HDCP = High-bandwidth Digital Content Protection (DRM!)
CEC = Consumer Electronics Control (TV ein → Receiver ein)
Lizenzgebühren: ~$10.000 Jahresgebühr + $0,15/Gerät
-->
---
![bg](./assets/displayport-cable.jpg)
<!--
DisplayPort-Kabel + Stecker
PC-Gaming-Standard
-->
---
# 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
<!--
VESA = Non-Profit-Organisation
DisplayPort über USB-C: Häufig bei Laptops
Adaptive Sync: Synchronisiert Monitor-Refresh mit GPU (kein Tearing)
AMD FreeSync, NVIDIA G-Sync: Basieren auf DP Adaptive Sync
PC-Gamer bevorzugen DP (höhere Refresh-Rates)
-->
---
# 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 |
<!--
HDMI = Heimkino/Konsolen
DisplayPort = PC-Gaming/Workstations
Beide können das Gleiche (technisch)
Politik & Marketing entscheiden
-->
---
![bg](./assets/hdcp-warning.jpg)
<!--
HDCP-Fehler auf Bildschirm
"HDCP-Handshake fehlgeschlagen"
Schwarzer Bildschirm
-->
---
# 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
<!--
Intel entwickelt (2003)
HDCP 2.2: Für 4K-Content (Netflix, Amazon)
Handshake: Gerät authentifiziert sich
HDCP-Stripper: Hardware, die HDCP entfernt (legal gray area)
Classic DRM-Problem: Nervt Zahlende, nicht Piraten
-->
---
![bg](./assets/ethernet-cable.jpg)
<!--
Ethernet-Kabel (RJ45)
Netzwerkkabel
-->
---
# 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)
<!--
Ethernet = IEEE 802.3 Standard
BASE-T = Baseband, Twisted Pair (Kupfer)
RJ45: Häufigste Bezeichnung (technisch 8P8C)
Cat = Category (Kabel-Spezifikation)
PoE = Power over Ethernet (Strom + Daten)
-->
---
![bg](./assets/vintage-ports.jpg)
<!--
Alte Anschlüsse: VGA, PS/2, Seriell, Parallel
Nostalgie-Faktor
-->
---
# 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)
<!--
RS-232: Noch in Industrie (Arduino, Sensoren)
Parallel: Schneller als Seriell (damals), aber durch USB ersetzt
PS/2: Color-Coded (Lila = Tastatur, Grün = Maus)
VGA: Manche Beamer haben's noch
Museumsbesuch: Diese Fossilien erinnern uns, Standards sterben
-->
---
# 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)
<!--
Praktische Exploration
USB-C-Ports: Oft unterschiedlich (Thunderbolt vs. nur USB)
Manche Laptops: USB-C nur Laden, keine Daten!
Dokumentation: Verstehen, was man hat
-->
---
# Aufgabe bis nächste Woche
**Analysiere deine Kabel:**
1. Liste alle Kabel (USB, HDMI, etc.)
2. Identifiziere: Standard, Geschwindigkeit, Features
3. Ist es beschriftet? Verständlich?
4. Poste im Forum: Foto + das verwirrendste Kabel
**Bonus:** Finde USB-C-Kabel, das nur USB 2.0 kann
<!--
Kabel-Sammlung durchgehen
Bewusstsein schaffen: Was habe ich eigentlich?
Viele Lade-Kabel: USB-C, aber nur USB 2.0 (langsam!)
Forum: Erfahrungsaustausch, lustige Fundstücke
-->
slides/2026-01-30-termin-4-distribution-apis-zukunft.md
+1818
View File
File diff suppressed because it is too large Load Diff
slides/2026-xx-xx-termin-5-vertiefung-offene-fragen.md
+24
View File
@@ -0,0 +1,24 @@
---
<!-- _class: lead -->
# 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
<!--
Flexibler Termin für Nachholbedarf
Themen nach Interesse der Studierenden
-->
slides/_frontmatter.md
+19
View File
@@ -0,0 +1,19 @@
---
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
---
<style>
section {
font-size: 1.7rem;
}
h2 {
color: var(--color-dimmed);
}
</style>
slides/_intro.md
+83
View File
@@ -0,0 +1,83 @@
![bg fit](./assets/digital-landscape.jpg)
<!-- Startbild: Futuristisches Netzwerk, Datenströme, oder digitale Landschaft -->
---
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
Modul "Technik 1" – 1. Semester
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart
**Wintersemester 2025/26**
---
# Über mich
**Michael Czechowski**
- Softwareentwickler & IT-Berater
- Schwerpunkte: Web-Technologien, Systemarchitektur, Open Source
- Hintergrund: Philosophie & Informatik
- Kontakt: czechowski@hdm-stuttgart.de
<!--
Kurze Vorstellung
Praxisbezug betonen
Fragen jederzeit willkommen
-->
---
# Termine
| Datum | Zeit | Thema |
|-------|------|-------|
| 19.12.2025 | 14:15 – 17:30 | Grundlagen, Text & Audio |
| 09.01.2026 | 14:15 – 17:30 | Bild- & Videoformate |
| 23.01.2026 | 14:15 – 17:30 | Speichermedien & Schnittstellen |
| 30.01.2026 | 14:15 – 17:30 | Distribution, APIs & Zukunft |
| TBA | 14:15 – 17:30 | Vertiefung (wird bekannt gegeben) |
**Ort:** HdM Stuttgart, Nobelstraße 10
---
# Kurze Umfrage
**Bitte Hand heben:**
1. Wer hat schon mal eine Datei mit einem Hex-Editor geöffnet?
2. Wer weiß, was der Unterschied zwischen JPEG und PNG ist?
3. Wer hat schon mal mit APIs gearbeitet?
4. Wer weiß, was UTF-8 bedeutet?
5. Wer hat schon mal ein Video komprimiert/konvertiert?
<!--
Niveau der Gruppe einschätzen
Keine falschen Antworten
Zeigt, wo wir starten
-->
---
# Kursübersicht
**Ziel:** Verstehen, wie digitale Medien technisch funktionieren – von Bits bis zu globalen Distributionsnetzwerken
**5 Termine:**
- **19.12.** Bits, Bytes, Zeichenkodierung & Audio-Kompression
- **09.01.** Bild- & Video-Kompression
- **23.01.** Speichermedien & Hardware-Schnittstellen
- **30.01.** Distribution, APIs, Metadaten & Zukunft
- **TBA** Vertiefung & offene Fragen
<!--
Medienwissenschaftler:innen, nicht Informatiker:innen
Fokus: Warum funktionieren Dinge so? Welche Konflikte stecken dahinter?
Hands-On jede Woche (30-40 Min)
Narrative statt Faktenlisten
-->
slides/_outro.md
+27
View File
@@ -0,0 +1,27 @@
---
<!-- _class: lead -->
# Fragen & Diskussion
**Kontakt:** czechowski@hdm-stuttgart.de
**Folien:** Online verfügbar unter https://hdm.librete.ch
---
# 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/
<!--
Open Educational Resources (OER)
Studierende können Folien nutzen, remixen, teilen
CC BY-SA: Wikipedia-Lizenz (Share-Alike)
Attribution: "Michaล‚ Czechowski, HdM Stuttgart"
-->