---
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
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
---
# 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?
---
# 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
---
# Termin 1 – 19.12.2025
## Grundlagen, Text & Audio
---
# 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?**
---
# Das Bit
**Kleinste Informationseinheit**
- **0 oder 1**
- AN oder AUS
- Strom fließt oder nicht
---
# Das Byte
**8 Bits = 1 Byte**
```
0 1 0 0 1 1 0 1
```
**Wie viele Kombinationen?**
2⁸ = **256 Möglichkeiten** (0-255)
---
# 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)
---
# 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ß
---
# 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 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**
---
# 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)
---
# 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` |
---
---
# 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
---
# 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
---
# 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!
---
# 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
**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
**MP3:** Schwächen des Ohrs
- Mittlere Frequenzen besser als hohe/tiefe
- Laute Töne "maskieren" leise Töne
→ **Psychoakustik / Psychovisuell**
---
---
# 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
---
---
# "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?
**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 & 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
**Optional:** Spektrogramm-Ansicht
---
# 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
---
# 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!**
---
# 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?
---
# 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
---
# 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
---
# 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!)
---
# 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
---
# 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
---
---
# 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)
---
# 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
---
# 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
---
# 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
---
---
# 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)
---
---
# 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)
---
# 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
---
# 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
---
# 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?
3. Poste im Forum: Screenshot + Erkenntnisse
**Bonus:** Linux-ISO via Torrent, poste Peer-Stats
---
# 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
---
# 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. Poste im Forum:
- Welche API?
- Interessante Daten?
- Rate-Limiting erlebt? (429 Too Many Requests)
**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)
---
# 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. Poste im Forum:
- Screenshots (OHNE sensible Infos!)
- Überraschungen?
- Wie viel KB gespart nach Entfernung?
**Bonus:** Finde alte Datei (>5 Jahre) – was verraten Metadaten über damaliges Setup?
---
# Teil 4: Zukunft
## Trends & Ausblick
---
---
# Rückblick: 9 Wochen
**Woche 1:** Bits → Bytes → Bedeutung (Encoding)
**Woche 2:** MP3 & Psychoakustik
**Woche 3:** JPEG & GIF-Kriege
**Woche 4:** H.264 vs. AV1
**Woche 5:** HDD vs. SSD, Dateisysteme, Backup
**Woche 6:** USB-C-Chaos, HDMI vs. DisplayPort
**Woche 7:** CDN, P2P, Streaming
**Woche 8:** REST, GraphQL, WebSockets
**Woche 9:** EXIF, Vendor Lock-in
**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 (Forum, E-Mail)
- Weiterlernen mit Ressourcen
**Vielen Dank für eure Aufmerksamkeit!**
---
# 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:** 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/