835 lines
25 KiB
Markdown
835 lines
25 KiB
Markdown
---
|
||
marp: true
|
||
theme: gaia
|
||
paginate: true
|
||
backgroundColor: #fff
|
||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||
---
|
||
<style>
|
||
:root {
|
||
--color-foreground: #1a1a2e;
|
||
--color-highlight: #1e5f8a;
|
||
--color-dimmed: #4a4a6a;
|
||
}
|
||
section.invert {
|
||
--color-foreground: #fff;
|
||
}
|
||
section {
|
||
font-size: 1.7rem;
|
||
}
|
||
h1 {
|
||
color: #1e5f8a;
|
||
}
|
||
section.invert h1 {
|
||
color: #fff;
|
||
}
|
||
h2 {
|
||
color: #1f2937;
|
||
}
|
||
pre {
|
||
background: #0f0f23;
|
||
color: #5fb3e4;
|
||
border-radius: 8px;
|
||
border-left: 3px solid #1e5f8a;
|
||
}
|
||
pre code {
|
||
background: transparent;
|
||
color: inherit;
|
||
}
|
||
code {
|
||
background: #0f0f23;
|
||
padding: 0.15em 0.4em;
|
||
border-radius: 4px;
|
||
font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
|
||
}
|
||
section code:not(.hljs) { color: #5fb3e4 !important; }
|
||
section code.hljs { color: #f8f8f8 !important; }
|
||
a {
|
||
color: var(--color-highlight);
|
||
}
|
||
section.klausur {
|
||
background: repeating-linear-gradient(
|
||
135deg,
|
||
#e3f2fd,
|
||
#e3f2fd 40px,
|
||
#fff 40px,
|
||
#fff 80px
|
||
) !important;
|
||
}
|
||
@media print {
|
||
section.klausur {
|
||
background: #e3f2fd !important;
|
||
}
|
||
}
|
||
section.aufgabe {
|
||
background: #e3f2fd !important;
|
||
}
|
||
section.aufgabe footer {
|
||
display: none;
|
||
}
|
||
</style>
|
||
|
||
<!--
|
||
╔═══════════════════════════════════════════════════════════════════╗
|
||
║ AUTO-GENERATED FILE - DO NOT EDIT MANUALLY ║
|
||
║ ║
|
||
║ This file is generated by: make klausur ║
|
||
║ Source: scripts/extract-klausur.sh ║
|
||
║ ║
|
||
║ To update, edit the source slides and re-run make klausur ║
|
||
╚═══════════════════════════════════════════════════════════════════╝
|
||
-->
|
||
|
||
<!-- _class: invert -->
|
||
<!-- _header: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||
|
||
**223015b** · Modul "Technik 1" · 1. Semester
|
||
Digital- und Medienwirtschaft
|
||
Hochschule der Medien Stuttgart
|
||
|
||
**Sommersemester 2026**
|
||
|
||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Hex begegnet euch überall
|
||
|
||
| Kontext | Beispiel |
|
||
|---------|----------|
|
||
| CSS-Farben | `#FF5733` |
|
||
| MAC-Adressen | `00:1A:2B:3C:4D:5E` |
|
||
| Speicheradressen | `0xA04F20` |
|
||
| Windows-Fehlercodes | `0x80070005` |
|
||
| Unicode-Codepoints | `U+00E4` (ä) |
|
||
| Datei-Signaturen | `89 50 4E 47` (PNG) |
|
||
|
||
<!--
|
||
Präfixe:
|
||
- `0x` = "das ist Hex" (in C, JS, Python)
|
||
- `U+` = Unicode-Codepoint
|
||
- `#` = CSS-Konvention
|
||
|
||
Lebensweltanker: jede:r Studi hat mindestens drei dieser Kontexte schon real gesehen. Hex ist nicht eine akademische Übung, sondern die Lesart, in der Computer mit Menschen über Byte reden.
|
||
|
||
MAC-Adresse: 6 Byte = 6 Paare Hex-Ziffern. Eindeutige Hardware-Kennung der Netzwerkkarte.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Beispiel: Byte zählen
|
||
|
||
**Text:** `"Hello·🌸·こんにちは·(Kon-ni-chi-wa)"`
|
||
|
||
| Zeichen | Byte |
|
||
|---------|-------|
|
||
| `Hello·` | 6 × 1 = **6 Byte** (ASCII) |
|
||
| `🌸` | **4 Byte** (Emoji) |
|
||
| `·` | **1 Byte** |
|
||
| `こんにちは` | 5 × 3 = **15 Byte** (Hiragana) |
|
||
| `·(Kon-ni-chi-wa)` | **16 Byte** (ASCII) |
|
||
|
||
**Gesamt: 42 Byte für 29 sichtbare Zeichen.**
|
||
|
||
<!--
|
||
Klausurfähig: gegeben ein Text mit ASCII, Umlauten, CJK und Emoji — wie viel Byte ist das?
|
||
|
||
- ASCII (Hello, Klammern) = 1 Byte pro Zeichen
|
||
- Emoji 🌸 (Cherry Blossom U+1F338) = 4 Byte
|
||
- Hiragana こんにちは = 3 Byte pro Zeichen (U+3040–309F)
|
||
- は wird hier „wa" ausgesprochen (Partikel), nicht „ha"
|
||
|
||
Pointe: 29 sichtbare Zeichen, 42 Byte. Zeichen ≠ Byte sobald Unicode > 127.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Magic Numbers — die Visitenkarte der Datei
|
||
|
||
**Datei-Typ erkennt man an den ersten Byte:**
|
||
|
||
| Format | Magic Number (Hex) | Lesbar? |
|
||
|--------|-------------------|---------|
|
||
| PNG | `89 50 4E 47` | (89 außerhalb ASCII) P N G |
|
||
| JPEG | `FF D8 FF` | — |
|
||
| PDF | `25 50 44 46` | % P D F |
|
||
| ZIP | `50 4B 03 04` | P K — — |
|
||
|
||
**Achtung:** Werte > 127 sind nicht ASCII-druckbar. *Hex-Editoren zeigen `.` als Platzhalter.*
|
||
|
||
<!--
|
||
- PNG nutzt absichtlich `89` (= 137 dezimal): markiert Datei eindeutig als Binär. Erkennt kaputte Übertragungen (alte Systeme schnitten Bit 7 ab).
|
||
- "PK" bei ZIP = Phil Katz (Erfinder von PKZip, 1989)
|
||
- DOCX, XLSX, PPTX, ODT = alles ZIP-Archive mit XML-Inhalt
|
||
- Dateien OHNE Magic Number: TXT, HTML, CSS, JSON, XML — reiner Text, kein binäres Format
|
||
- Sicherheitsrelevant: virus.exe → bild.jpg umbenennen täuscht nur Menschen; `file` (Linux) liest Magic Number und erkennt die echte Identität.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# KB vs KiB — warum „1 TB" als 931 GB angezeigt wird
|
||
|
||
|
||
|
||
**Auf der Verpackung:** 1 TB = 10¹² Byte (dezimal).
|
||
**Im Finder:** 931 GB = eigentlich 931 GiB (binär, 1024³).
|
||
|
||
Es fehlt nichts — beide Seiten zählen nur in **verschiedenen Sprachen.**
|
||
|
||
<!--
|
||
- Marketing nutzt SI-Präfixe (1000³, 1000⁴) → größere Zahlen auf der Packung.
|
||
- Betriebssysteme rechnen in Zweier-Potenzen (1024³) → kleinere angezeigte Zahl, weil Bits binär organisiert sind.
|
||
- Korrekt wären `GiB` (Gibi-, binär) und `GB` (Giga-, dezimal). Realität: beide nennen es `GB`.
|
||
|
||
Rechnung: 10¹² ÷ 2³⁰ ≈ 931,3 GiB. Der Finder zeigt „931 GB".
|
||
|
||
Klausurfähig: warum zeigt eine 1-TB-SSD im Finder „931 GB"? Begründung mit Rechnung.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Dateneinheiten — Größenordnungen
|
||
|
||
| Einheit | Bytes (dezimal) | Beispiel |
|
||
|---------|------:|----------|
|
||
| **Byte** | 1 | Farbwert eines Pixels |
|
||
| **Kilobyte (KB)** | 1.000 | kleiner Programmcode |
|
||
| **Megabyte (MB)** | 1 Million | Textdokument |
|
||
| **Gigabyte (GB)** | 1 Milliarde | Kinofilm in FullHD |
|
||
| **Terabyte (TB)** | 1 Billion | ~12h Video in 4K |
|
||
| **Petabyte (PB)** | 1 Billiarde | Netflix-Gesamtarchiv |
|
||
| **Exabyte (EB)** | 1 Trillion | Alle E-Mails weltweit/Tag |
|
||
| **Zettabyte (ZB)** | 1 Trilliarde | globale Datenmenge ~heute |
|
||
|
||
<!--
|
||
SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes. Auf Packungen, in Marketing.
|
||
IEC-Präfixe (Binär): 1 KiB = 1.024 Bytes (Kibibyte). In Betriebssystemen (oft ohne i geschrieben — Verwechselung!).
|
||
|
||
Eselsbrücke für die Reihenfolge:
|
||
„**K**omm **M**it **G**roßem **T**ee, **P**eter **E**xte **Z**ettelt **Y**achten."
|
||
→ Kilo, Mega, Giga, Tera, Peta, Exa, Zetta, Yotta.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Datenrate = Sample Rate × Bittiefe × Kanäle
|
||
|
||
**Formel:**
|
||
|
||
```
|
||
Datenrate (bit/s) = Sample Rate (Hz) × Bittiefe (bit) × Kanäle
|
||
```
|
||
|
||
**Was bestimmt jeder Faktor?**
|
||
|
||
- **Sample Rate:** Bandbreite (Höhe der erfassbaren Töne)
|
||
- **Bittiefe:** Dynamik (Stufenfeinheit)
|
||
- **Kanäle:** Stereo, Mono, Surround
|
||
|
||
Daraus ergibt sich, wie groß eine Audiodatei pro Sekunde wird — *unkomprimiert*.
|
||
|
||
<!--
|
||
Wichtige Klausur-Formel.
|
||
|
||
Anwendungsbeispiel kommt nächste Folie (CD-Audio).
|
||
|
||
Konsequenz: wenn ich Speicher sparen will, kann ich an einem dieser drei Parametern drehen. ABER: jede Reduktion ist hörbar.
|
||
|
||
Brücke zu Kap2 (Kompression): da reduzieren wir nicht die Parameter, sondern *werfen unhörbare Information weg* — das ist Psychoakustik, nicht Container-Schrumpfung.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# CD-Audio: die Rechnung
|
||
|
||
**Audio-CD (Philips/Sony 1982):**
|
||
|
||
```
|
||
44.100 Hz × 16 bit × 2 Kanäle = 1.411.200 bit/s = 1,4 Mbit/s
|
||
```
|
||
|
||
Pro Sekunde: ~172 KB. Pro Minute: ~10,3 MB. Pro Album (60 Min): ~635 MB.
|
||
|
||
*Eine ganze 90er-Festplatte für ein Album.*
|
||
|
||
<!--
|
||
Diese Rechnung muss in der Klausur reproduziert werden können — Formel + Anwendung.
|
||
|
||
Historischer Kontext:
|
||
- 1982: erste CD (Billy Joel – 52nd Street, Japan)
|
||
- Festplatten der 90er: 40–500 MB → ein Album füllte die ganze Platte
|
||
- 56k-Modem: 7 KB/s → 42 MB Song ≈ 100 Minuten Download
|
||
- Daraus entstand der Druck zur Audio-Kompression — die wir in Kap 2 sehen werden
|
||
|
||
Spektrogramm-Folie als Anschluss: 44,1 kHz → wir können bis ~22 kHz erfassen. Mehr nicht. Warum genau 22 kHz? Weil Menschen bis ~20 kHz hören. Antwort kommt mit Nyquist.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Nyquist-Theorem — warum 2× reicht
|
||
|
||
|
||
|
||
**Sample-Rate muss mindestens das *Doppelte* der höchsten Signal-Frequenz sein:**
|
||
|
||
```
|
||
f_sample ≥ 2 · f_max
|
||
```
|
||
|
||
Drei Fälle:
|
||
- **zu wenig** → Aliasing (falsche tiefere Welle)
|
||
- **genau** → mathematisches Minimum
|
||
- **mehr** → sichere Rekonstruktion
|
||
|
||
<!--
|
||
Harry Nyquist (1928) + Claude Shannon (1949): Sampling-Theorem.
|
||
|
||
Beweis nicht klausurrelevant. Die Aussage und das visuelle Verständnis sind klausurrelevant.
|
||
|
||
Konsequenz:
|
||
- 44,1 kHz Sample Rate → max. 22,05 kHz erfassbare Frequenz
|
||
- Über 22 kHz wird *physisch nicht aufgenommen* (vor dem ADC sitzt ein Tiefpassfilter, der alles über 22 kHz abschneidet — anti-aliasing filter)
|
||
- Studis hören diese hohen Frequenzen sowieso nicht (~20 kHz oben)
|
||
|
||
Anschluss zur nächsten Folie: warum hat die CD genau 44,1 kHz gewählt?
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Vergleich: Lossless vs. Lossy
|
||
|
||
| Eigenschaft | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
|
||
|-------------|------------------------|--------------------------|
|
||
| Was passiert? | Redundanz raus | Irrelevanz raus |
|
||
| Umkehrbar? | Ja, bit-genau | Nein, nie wieder |
|
||
| Trick | Wiederholungen kürzer kodieren | Wahrnehmung modellieren |
|
||
| Typischer Faktor | 2× – 5× | 10× – 100× |
|
||
| Anwendung | Archiv, Werkzeug, Code | Stream, Anzeige, Konsum |
|
||
| Beispiele | ZIP · PNG · FLAC · RAW | MP3 · JPEG · H.264 · WebP |
|
||
|
||
<!--
|
||
Klausurfähig: gegeben ein Anwendungsfall — soll Lossless oder Lossy verwendet werden? Mit Begründung.
|
||
|
||
Beispiele für Klausurfragen:
|
||
- 4K-Stream auf Netflix → Lossy (H.265 oder AV1)
|
||
- RAW-Datei aus der DSLR archivieren → Lossless (RAW selbst, ggf. ZIP)
|
||
- Lecture-Capture-Aufzeichnung für Wiederverwendung → Lossless besser, aber Datenrate hoch
|
||
- Logo-Datei für Print + Web → SVG (vektorgraphisch) oder PNG (lossless raster)
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Raster vs. Vektor
|
||
|
||
| | Raster | Vektor |
|
||
|--|--------|--------|
|
||
| Was | Gitter aus Pixel-Werten | Mathematische Anweisungen |
|
||
| Speicher | wächst mit Auflösung | wächst mit Komplexität |
|
||
| Skalierung | pixelig beim Zoom | scharf bei jeder Größe |
|
||
| Geeignet für | Fotos, Screenshots | Logos, Icons, Schrift |
|
||
| Formate | PNG · JPEG · GIF · WebP | SVG · PDF · Schriftarten |
|
||
|
||
<!--
|
||
Klausurfähig. Geben Sie:
|
||
- ein Format zu jeder Spalte
|
||
- ein Anwendungsbeispiel zu jeder Spalte
|
||
- begründen warum Vektor bei Logos und Raster bei Fotos
|
||
|
||
Trick-Frage: kann man ein Foto in SVG speichern? Theoretisch ja (mit Millionen winziger Rechtecke), praktisch nein — wird dann viel größer als JPEG.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Memo: Die 6 JPEG-Schritte
|
||
|
||
| # | Schritt | Lossless / Lossy |
|
||
|---|---------|------------------|
|
||
| 1 | RGB → Y'CbCr (Farbraum) | Lossless |
|
||
| 2 | Chroma-Subsampling 4:2:0 | **Lossy** |
|
||
| 3 | 8×8 Blöcke | Lossless |
|
||
| 4 | DCT (Frequenz-Zerlegung) | Lossless |
|
||
| 5 | Quantisierung | **Lossy** (Haupt-Reduktion) |
|
||
| 6 | Huffman + Zigzag + RLE | Lossless |
|
||
|
||
Nur **2** der 6 Schritte verlieren Information.
|
||
|
||
<!--
|
||
Klausurfähig. Sechs Schritte. Reihenfolge wichtig. Lossy/Lossless-Status pro Schritt wichtig.
|
||
|
||
Eselsbrücke: „Farb-Sub-Block-DCT-Quant-Huff" → F-S-B-D-Q-H.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Wann welches Bildformat?
|
||
|
||
| Anwendung | Format | Warum |
|
||
|-----------|--------|-------|
|
||
| Foto im Web (Insta, News) | **JPEG** oder **WebP** | klein, Foto-optimiert |
|
||
| Foto-Archiv (RAW) | **RAW**, **TIFF**, **DNG** | nichts verlieren |
|
||
| Logo, Icon (skalierbar) | **SVG** | wird neu berechnet |
|
||
| Logo als Raster | **PNG** | Transparenz + scharfe Kanten |
|
||
| Screenshot mit Text | **PNG** | scharfe Buchstaben |
|
||
| Animiertes Sticker | **GIF** oder **WebP** | beide animierbar |
|
||
| Foto in höchster Modern-Qualität | **AVIF** oder **WebP** | bessere Kompression als JPEG |
|
||
|
||
<!--
|
||
Klausurfähig: gegeben ein Anwendungsfall, welches Format und warum?
|
||
|
||
Sub-Frage: was schief geht, wenn ich JPEG für ein Logo nehme? → unscharfe Ränder + sichtbare Artefakte.
|
||
|
||
Sub-Frage: warum nicht immer AVIF? → Browser-Support (manche ältere Browser können AVIF noch nicht), Tool-Kompatibilität, Workflow-Etablierung.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Audio-Format-Wahl
|
||
|
||
| Anwendung | Format | Warum |
|
||
|-----------|--------|-------|
|
||
| Spotify-Stream | **AAC** oder **MP3 192+** | Kompression, breite Unterstützung |
|
||
| Studio-Master | **WAV** oder **FLAC** | Bit-genau erhalten |
|
||
| Sprachnachricht | **Opus** oder **AAC-LD** | für Sprache optimiert, niedrige Bitrate |
|
||
| Podcast-Distribution | **MP3 128 kbit/s** | universelle Unterstützung |
|
||
| HiFi-Audiophile | **FLAC** | lossless, kleiner als WAV |
|
||
| Archiv eigener Aufnahmen | **FLAC** oder **WAV** | nichts verlieren |
|
||
|
||
<!--
|
||
Klausurfähig: gegeben ein Anwendungsfall, welches Format?
|
||
|
||
Trick-Frage: warum nicht MP3 320 für Studio? → Lossless ist immer noch verlustfrei besser. Wer mastern will, braucht das.
|
||
|
||
Trick-Frage 2: warum nicht WAV für Spotify? → Daten-Volumen zu hoch fürs Streaming.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Container ≠ Codec
|
||
|
||
|
||
|
||
**Container** = die *Verpackung*: hält Video-Spur, Audio-Spur, Untertitel, Metadaten zusammen.
|
||
*Beispiele:* MP4, MKV, WebM, AVI
|
||
|
||
**Codec** = der *Komprimierer*: wie wird Bild/Audio gespeichert?
|
||
*Beispiele:* H.264, H.265, AV1, VP9 (Video) · AAC, MP3, Opus (Audio)
|
||
|
||
**Eine `.mp4`-Datei kann verschiedene Codecs enthalten.**
|
||
|
||
<!--
|
||
Das ist DER zentrale Missverständnis-Punkt bei Video. Studis denken oft, „MP4" oder „MKV" sei das Format des Videos. Stimmt nicht. Es ist nur die Hülle.
|
||
|
||
Konkretes Beispiel: zwei `.mp4`-Dateien:
|
||
- A: H.264-Video + AAC-Audio
|
||
- B: H.265-Video + Opus-Audio
|
||
|
||
Beide haben die Endung .mp4. Aber A spielt überall, B braucht moderne Player.
|
||
|
||
Tool: `mediainfo <datei>` zeigt Container UND Codec.
|
||
|
||
Klausurfähig.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# I, P, B — Frame-Typen
|
||
|
||
| Typ | Vollname | Was drin | Größe |
|
||
|-----|----------|----------|-------|
|
||
| **I** | Intra-coded | Komplettes Bild (wie JPEG) | groß |
|
||
| **P** | Predicted | „Was hat sich seit voriges I/P geändert" | mittel |
|
||
| **B** | Bidirectional | „Was zwischen vorigem und nächstem I/P" | klein |
|
||
|
||
Typische GOP: `I B B P B B P B B P B B I ...` (alle 1–3 Sekunden ein I-Frame).
|
||
|
||
<!--
|
||
Klausurfähig: was sind I/P/B-Frames? Welche ist die größte? Warum brauchen wir I-Frames trotzdem (Seeking, Stream-Start, Fehlerresistenz)?
|
||
|
||
GOP = Group of Pictures.
|
||
|
||
I-Frame als Seeking-Anker:
|
||
- Wenn man im Video an einer Stelle springt, kann der Player nur an I-Frames anfangen
|
||
- Zwischen I-Frames muss Player VOM letzten I-Frame ab dekodieren bis zur Spring-Stelle
|
||
|
||
Daher: I-Frames sollten nicht zu selten sein (sonst langsames Seeking), aber auch nicht zu häufig (sonst weniger Kompression).
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Patent vs. Open — warum AV1?
|
||
|
||
| Codec | Effizienz | Patent | Adoption (2026) |
|
||
|-------|-----------|--------|-----------------|
|
||
| H.264 | Baseline | Lizenz (MPEG-LA) | ~80 % aller Videos |
|
||
| H.265 | +50 % | 3 Patent-Pools, chaotisch | nur Apple |
|
||
| VP9 | ~H.265 | lizenzfrei (Google) | YouTube 4K |
|
||
| **AV1** | **+30 % über H.265** | **lizenzfrei (Allianz)** | **YouTube, Netflix, Twitch** |
|
||
|
||
**Die Lektion:** technisch beste Lösung gewinnt nicht. *Lizenz-klare* beste Lösung gewinnt.
|
||
|
||
<!--
|
||
Klausurfähig: warum hat AV1 H.265 abgelöst, wenn beide ähnlich effizient sind?
|
||
|
||
Antwort: Patent-Politik. H.265 hat drei Patent-Pools, AV1 ist lizenzfrei. Industrie-Konsortium hat AV1 finanziert, weil sie nie wieder einem MPEG-LA-Pool ausgeliefert sein wollten.
|
||
|
||
Sub-Frage: warum nicht VP9? → AV1 ist effizienter (~30 %), und alle wichtigen Player stehen dahinter (statt nur Google).
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# HDD vs. SSD
|
||
|
||
|
||
|
||
| | HDD | SSD |
|
||
|--|-----|-----|
|
||
| Technik | Mechanik | Flash |
|
||
| Geschwindigkeit | 50–250 MB/s | 500–14.000 MB/s |
|
||
| Latenz | ~10 ms | ~0,1 ms |
|
||
| Preis/TB (2026) | ~20 € | ~70 € |
|
||
| Lebensdauer | ~5–10 Jahre | ~5–10 Jahre |
|
||
| Geräusch | hörbar | lautlos |
|
||
| Stoß-empfindlich | ja | nein |
|
||
|
||
<!--
|
||
HDD-Vorteile: viel Kapazität für wenig Geld. Lange archivierbar im Schrank.
|
||
SSD-Vorteile: schnell, leise, robust. Aber teurer pro TB.
|
||
|
||
Klausurfähig: gegeben ein Anwendungsfall, HDD oder SSD?
|
||
|
||
- Betriebssystem: SSD (schnell)
|
||
- Backup-Archiv: HDD (billig)
|
||
- Server für Foto-Speicher: HDD (Kapazität)
|
||
- Laptop (mobil): SSD (Stoß)
|
||
- Video-Bearbeitung: SSD (Throughput)
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Wann nehme ich was?
|
||
|
||
| Anwendung | Empfehlung | Begründung |
|
||
|-----------|------------|------------|
|
||
| Betriebssystem auf dem Laptop | **NVMe-SSD** | Geschwindigkeit, Boot |
|
||
| Eigene Foto-Library (10 TB+) | **HDD** | Kapazität, Preis |
|
||
| Server für Logfiles | **HDD oder SSD** | je nach Schreib-Last |
|
||
| Externes Backup-Archiv | **HDD** | billig, ok wenn langsam |
|
||
| Mobile Workstation (Reise) | **SSD** | Stoß, Geräusch |
|
||
| Edit-Drive für 4K-Schnitt | **NVMe-SSD** | Throughput für Video |
|
||
| Langzeitarchiv 10+ Jahre | **LTO-Band + M-DISC** | Langlebigkeit |
|
||
|
||
<!--
|
||
Klausurfähig. Trick-Frage: warum nicht alles SSD? → Preis pro TB. Faktor 3-5× teurer.
|
||
|
||
Cloud-Speicher (iCloud, Google Drive, Dropbox) ist physisch HDD/SSD/LTO in Rechenzentren — kein eigenes Medium, sondern Zugriffsmethode.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Filesystem-Landschaft
|
||
|
||
| Filesystem | Wo verbreitet | Max. Dateigröße | Besonderheit |
|
||
|-----------|---------------|----------------:|--------------|
|
||
| **FAT32** | USB-Sticks, SD-Karten alt | **4 GB** | universell, alt |
|
||
| **exFAT** | USB-Sticks modern | 16 EB | wie FAT, ohne 4-GB-Limit |
|
||
| **NTFS** | Windows | 16 EB | Standard seit Win 2000 |
|
||
| **APFS** | macOS seit 2017 | 8 EB | snapshots, schnell |
|
||
| **ext4** | Linux | 16 TB | klassisch, robust |
|
||
| **ZFS** | Server, FreeBSD | 16 EB | checksum, snapshots |
|
||
|
||
**FAT32 4-GB-Grenze** ist der häufigste Alltags-Knack: USB-Stick noch nie umformatiert → kein 4K-Video drauf.
|
||
|
||
<!--
|
||
Klausurfähig: warum kann ich 5 GB Video nicht auf den USB-Stick ziehen? Antwort: FAT32 hat 4-GB-Dateigrößen-Limit. Lösung: USB-Stick auf exFAT umformatieren (Mac und Windows lesen/schreiben beide).
|
||
|
||
Asymmetrien:
|
||
- Mac kann NTFS nur lesen, nicht schreiben (ohne Drittpartei-Treiber)
|
||
- Windows kann APFS gar nicht
|
||
- Linux kann mit Plugins fast alles
|
||
|
||
Konsequenz für Studis: für Datentransfer zwischen Mac und Windows → exFAT. Für reinen Mac → APFS. Für Backup auf USB-Disk, die nur am eigenen Gerät benutzt wird → natives FS.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Die 3-2-1-Backup-Regel
|
||
|
||
**3** Kopien deiner Daten
|
||
|
||
**2** verschiedene **Medien** (z.B. SSD + HDD)
|
||
|
||
**1** Kopie **off-site** (außerhalb deines Wohnorts)
|
||
|
||
Beispiel:
|
||
|
||
```
|
||
Original → Foto-Library auf der MacBook-SSD
|
||
Kopie 1 → Time Machine auf externer HDD (zuhause)
|
||
Kopie 2 → Backblaze in der Cloud (off-site)
|
||
```
|
||
|
||
<!--
|
||
Diese Regel löst drei Risiken:
|
||
- Hardware-Crash: 3 Kopien, 2 davon auf anderen Geräten
|
||
- Diebstahl/Brand: 1 Kopie off-site (Cloud oder bei Familie)
|
||
- Ransomware: off-site-Kopie schreibgeschützt oder versioniert
|
||
|
||
Klausurfähig: was ist die 3-2-1-Regel? Beispiele für jede Ebene.
|
||
|
||
Cloud-Backup-Anbieter (off-site Option):
|
||
- Backblaze: ~7 USD/Monat unlimited (Mac/Windows)
|
||
- iCloud / Google One / OneDrive: integriert, aber begrenzt
|
||
- Self-hosted: Synology / QNAP bei einer Person im Vertrauen
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Schnittstellen-Wahl-Matrix
|
||
|
||
| Aufgabe | Beste Schnittstelle | Warum |
|
||
|---------|---------------------|-------|
|
||
| 4K-Monitor anschließen | **HDMI 2.0+** oder **DP 1.4+** | Bandbreite |
|
||
| Online-Gaming | **Ethernet** | niedrige Latenz |
|
||
| eGPU am Laptop | **Thunderbolt 3/4** | PCIe-Tunnel |
|
||
| SD-Karte einlesen | **USB-A 3.0** oder **USB-C** | Kompatibilität |
|
||
| Smartphone laden | **USB-C-PD** | Standard |
|
||
| Heim-Streaming | **WiFi** oder **Ethernet** | reicht beides |
|
||
| 4K-Stream mehrere Geräte | **Ethernet** | Stabilität |
|
||
|
||
<!--
|
||
Klausurfähig: gegeben Anwendungsfall, welche Schnittstelle und warum?
|
||
|
||
Trick: warum nicht immer Thunderbolt? → Teurer Kabel, teurere Hardware. Nicht jedes Endgerät unterstützt es.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# REST: GET · POST · PUT · DELETE
|
||
|
||
| Methode | Was tut sie | URL-Beispiel |
|
||
|---------|-------------|--------------|
|
||
| **GET** | lesen | `GET /users/42` (User mit ID 42 abfragen) |
|
||
| **POST** | neu erstellen | `POST /users` mit Daten als Body |
|
||
| **PUT** | überschreiben | `PUT /users/42` mit kompletten neuen Daten |
|
||
| **PATCH** | teilweise ändern | `PATCH /users/42` mit Änderungen |
|
||
| **DELETE** | löschen | `DELETE /users/42` |
|
||
|
||
CRUD = **C**reate · **R**ead · **U**pdate · **D**elete.
|
||
|
||
<!--
|
||
Klausurfähig: welche HTTP-Methode für welche Operation?
|
||
|
||
Trick-Frage: was ist der Unterschied zwischen PUT und PATCH?
|
||
- PUT: ersetzt komplett. User wird kompletter neu gesetzt.
|
||
- PATCH: ändert nur die mitgegebenen Felder. Rest bleibt.
|
||
|
||
In der Praxis nehmen viele APIs PUT auch für partielle Updates — kein RFC-konforme Strenge.
|
||
|
||
Werkzeuge zum Testen: curl, Postman, Hoppscotch (browser-basiert), VS-Code REST-Client-Plugin.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Der John-McAfee-GPS-Fall
|
||
|
||
**Dezember 2012.** John McAfee (Antivirus-Erfinder) flieht aus Belize, wo er als Mordverdächtiger gesucht wird.
|
||
|
||
**Vice Magazine** veröffentlicht ein Interview mit einem Foto: McAfee im T-Shirt, scheinbar in einer geheimen Location.
|
||
|
||
**EXIF-Koordinaten im Foto:** `15.6541° N, 88.9939° W` → **Hotel Nana Lodge, Guatemala.** Bekannt.
|
||
|
||
McAfee wird 36 Stunden später festgenommen.
|
||
|
||
<!--
|
||
Diese Story zeigt:
|
||
1. Smartphones speichern GPS-Daten standardmäßig
|
||
2. Online-Plattformen STRIPPEN diese Metadaten oft NICHT (Vice damals nicht)
|
||
3. Wer ein Bild mit GPS hochlädt, kann seinen Aufenthaltsort verraten
|
||
|
||
McAfee hat sich danach öffentlich darüber lustig gemacht ("yes that was the actual location"), aber der Fall wurde zum Lehrbuch-Beispiel für EXIF-Privacy.
|
||
|
||
2026: die meisten großen Plattformen strippen EXIF (Twitter/X, Instagram, WhatsApp), aber:
|
||
- WhatsApp-Originaldatei via "Dokument" senden: behält EXIF
|
||
- E-Mail-Anhang: behält EXIF
|
||
- Direkt-Upload zu Drittpartei-Webseiten: oft mit EXIF
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Der Tony-Blair-Fall (PDF-Metadaten)
|
||
|
||
**Februar 2003.** Britische Regierung veröffentlicht PDF-Dokument zur Begründung des Irakkriegs.
|
||
|
||
Ein britischer Akademiker findet im **PDF-Revisionsverlauf**: das Dokument wurde aus einer studentischen Doktorarbeit von 1991 kopiert.
|
||
|
||
**Plagiats-Skandal.** Plus Hinweise auf welche Mitarbeiter:innen welche Sätze überarbeitet hatten.
|
||
|
||
→ **PDF-Metadaten** verraten oft mehr als der Inhalt.
|
||
|
||
<!--
|
||
PDF-Metadaten:
|
||
- Autor, Erstell-Zeit, letzte Änderung
|
||
- Software (Microsoft Word, LibreOffice, Adobe Acrobat)
|
||
- Manchmal Revision History
|
||
- Manchmal versteckter Text (z.B. weiße Schrift auf weißem Hintergrund)
|
||
|
||
Sicherheitsrelevant:
|
||
- Schwärzungen werden manchmal nur als schwarzer Layer DRÜBER gelegt — Text bleibt extrahierbar
|
||
- NSA-Dokumente, FBI-Reports, US-Gerichtsdokumente: viele berühmte Beispiele für gescheiterte Schwärzungen
|
||
- Auch bei Microsoft Word: "Schwärze" via schwarzes Highlight → Text bleibt im Stream lesbar
|
||
|
||
Klausurfähig: ein Beispiel für PDF-Metadaten-Privacy-Verstoß nennen + Begründung.
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: "" -->
|
||
<!-- _footer: "" -->
|
||
|
||
|
||
# Vendor-Lockin als Risiko
|
||
|
||
**Szenario:** Du arbeitest 5 Jahre lang mit Adobe InDesign. Dann steigt der Abo-Preis um 200 % oder Adobe ändert das Format.
|
||
|
||
**Konsequenz:**
|
||
- Bestehende INDD-Dateien öffnen sich noch — aber nur in Adobe-Produkten
|
||
- Migration zu Affinity Publisher / Scribus: Daten müssen konvertiert werden, manche Details gehen verloren
|
||
- Bei einigen Formaten gibt es keine Konverter — Vendor entscheidet komplett
|
||
|
||
**Schutz:** Wichtige Daten in **offenen Formaten** parallel speichern.
|
||
|
||
<!--
|
||
Klausurfähig: was ist Vendor-Lockin? Beispiel + warum problematisch?
|
||
|
||
Diskussion: Open-Source-Tools sind oft "fast so gut" — manchmal sogar besser. Aber Industrie-Standards halten den Status quo.
|
||
|
||
Heimlich-Lockin: auch "Bug-für-Bug-Kompatibilität". Microsoft Office hat sich in den 90ern als Standard durchgesetzt, weil Konkurrenz-Office-Suites die exakten Bugs/Quirks nicht reproduzieren konnten.
|
||
-->
|