restructure: rename termin to kapitel, flatten folder structure

- rename slide files: YYYY-MM-DD-termin-N-topic.md → NN-topic.md
- flatten folders: courses/X/slides/ → slides/X/
- replace "Termin" with "Kapitel" in all content
- add klausur extraction script (make klausur)
- update Makefile, generate-index.sh, dev-server.sh
- add README.md with full documentation
This commit is contained in:
2026-01-25 11:26:15 +01:00
parent b951341376
commit a8343c9937
128 changed files with 1464 additions and 3484 deletions

254
slides/223015b/00-intro.md Normal file
View File

@@ -0,0 +1,254 @@
---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
footer: "Michael Czechowski HdM Stuttgart WS 2025/26"
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
---
<style>
:root {
--color-foreground: #1a1a2e;
--color-highlight: #1e5f8a;
--color-dimmed: #4a4a6a;
}
section.invert {
--color-foreground: #fff;
}
section {
font-size: 1.7rem;
}
h1 {
color: #1e5f8a;
}
section.invert h1 {
color: #fff;
}
h2 {
color: #1f2937;
}
pre {
background: #0f0f23;
color: #5fb3e4;
border-radius: 8px;
border-left: 3px solid #1e5f8a;
}
pre code {
background: transparent;
color: inherit;
}
code {
background: #1a1a2e;
color: #5fb3e4;
padding: 0.15em 0.4em;
border-radius: 4px;
}
a {
color: var(--color-highlight);
}
section.klausur {
background: repeating-linear-gradient(
135deg,
#e3f2fd,
#e3f2fd 40px,
#fff 40px,
#fff 80px
) !important;
}
@media print {
section.klausur {
background: #e3f2fd !important;
}
}
section.aufgabe {
background: #e3f2fd !important;
}
section.aufgabe footer {
display: none;
}
</style>
<!-- _class: invert -->
<!-- _header: '' -->
<!-- _backgroundColor: #000 -->
![bg cover opacity:0.2](./assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg)
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
**223015b** · Modul "Technik 1" · 1. Semester
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart
**Wintersemester 2025/26**
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
---
![bg fit](./assets/qrcode-0.svg)
---
<!-- _class: lead -->
# Willkommen!
## Einführung
---
# Über mich
**Michael Czechowski**
- Irgendwas mit IT, Cloud und AI
- Schwerpunkte:
- Web-Technologien, Barriere-Armut, Systemarchitektur, Open Source
- Hintergrund:
- Philosophie (Uni Stuttgart) -> NO degree
- Wirtschafts-Informatik (Leibniz-FH) -> B.Sc.
- Kontakt: lb-czechowski@hdm-stuttgart.de
<!--
Kurze Vorstellung
Praxisbezug betonen
Fragen jederzeit willkommen
-->
---
<!-- _footer: '' -->
![bg fit](./assets/jung-naiv.png)
---
# AMA (Ask my anything)
*Nur ein Vorschlag ...*
* Hast du alle Bände von AoT daheim?
* Hast du eine Studierenden-Kneipe mal geleitet?
* Hast du wirklich 17 Semester Philosophie ohne Abschluss studiert?
---
# Kurze Umfrage
**Bitte Hand heben:**
1) Wer hat schon mal ein Video komprimiert/konvertiert?
2) Wer kennte die 3-2-1 Regel?
3) Wer weiß, was der Unterschied zwischen JPEG und PNG ist?
4) Wer hat schon mal mit APIs gearbeitet?
5) Wer weiß, was UTF-8 bedeutet?
6) Wer hat schon mal mit einem CLI gearbeitet?
6) **Wer hat schon mal etwas mit HTML oder CSS gemacht?** (Hex-Farben wie `#FF0000`?)
<!--
Niveau der Gruppe einschätzen
Keine falschen Antworten
Zeigt, wo wir starten
HTML/CSS-Frage: Viele kennen Hex-Codes aus Webdesign
API = Application Programming Interface
-->
---
# Warum dieses Modul?
**Digitale Medien sind überall** aber was steckt dahinter?
* Warum ist ein JPEG kleiner als ein PNG?
* Warum klingt MP3 anders als FLAC?
* Warum zeigt meine 1 TB Festplatte nur 931 GB?
* Warum ist USB-C so verwirrend?
* Wie funktioniert eigentlich Streaming?
* **→ Die Technik dahinter verstehen!**
<!--
Praxisnahe Fragen aus dem Alltag
Nicht nur "was", sondern "warum"
Verständnis für technische Entscheidungen
-->
---
# Das Ziel
**Technische Grundlagen verstehen**, um fundierte Entscheidungen treffen zu können.
Als Digital- und Medienwirtschaftler:innen werdet ihr täglich mit technischen Fragen konfrontiert:
* Welches Format für welchen Zweck?
* Welche Schnittstelle für welches Gerät?
* Wie funktioniert die Distribution digitaler Inhalte?
* **→ Mitreden können nicht (zwingend) programmieren!**
<!--
Nicht: Ihr sollt Programmierer werden
Sondern: Ihr sollt technische Entscheidungen verstehen
Praxisbezug: Medienproduktion, Marketing, Projektmanagement
-->
---
# Was ihr lernt
**In dieser Veranstaltung erwerbt ihr folgende Kompetenzen:**
* Fundiertes Grundwissen über Daten und Informationen
* Dateiformate analysieren und verstehen
* Grundlagen von Kompression (Audio, Bild, Video)
* Speichermedien unterscheiden
* Programmier-Schnittstellen kennenlernen
* APIs und Distributionswege verstehen
<!--
Fokus auf Verständnis, nicht auf Programmierung
Hands-On jede Woche: Selbst ausprobieren
Ziel: Einblick in die Denkweise von Software-Entwicklern
-->
---
# Kursübersicht
**5 Termine:**
| # | Datum | Thema |
|---|-------|-------|
| 1 | 19.12.2025 | Bits, Bytes, Zeichenkodierung & Audio |
| 2 | 09.01.2026 | Bild- & Video-Kompression |
| 3 | 23.01.2026 | Speichermedien & Schnittstellen |
| 4 | 30.01.2026 | Distribution, APIs & Zukunft |
| 5 | TBA | Vertiefung & offene Fragen |
**Format:** Theorie + Hands-On (30-40 Min pro Termin)
<!--
Nicht nur theoretische Inhalte
Praktische Übungen jede Woche
Medienwissenschaftler:innen, nicht Informatiker:innen
-->
---
# Prüfungsleistung 18.02.
**Nach aktuellem Kenntnisstand:**
* 90 min (40% Grundlagen, 40% Dateiformate, 20% AV)
* Schriftliche Klausur
* Teils offene Fragen
* Vermutlich digital
* Kein Coding!
* **Prüfungsrelevant:** Alles in den Folien/im Skript
<!--
Details können sich noch ändern
Keine Programmieraufgaben
Verständnisfragen, keine Auswendiglernerei
-->

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,781 @@
---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
footer: "Michael Czechowski HdM Stuttgart WS 2025/26"
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
---
<style>
:root {
--color-foreground: #1a1a2e;
--color-highlight: #1e5f8a;
--color-dimmed: #4a4a6a;
}
section.invert {
--color-foreground: #fff;
}
section {
font-size: 1.7rem;
}
h1 {
color: #1e5f8a;
}
section.invert h1 {
color: #fff;
}
h2 {
color: #1f2937;
}
pre {
background: #0f0f23;
color: #5fb3e4;
border-radius: 8px;
border-left: 3px solid #1e5f8a;
}
pre code {
background: transparent;
color: inherit;
}
code {
background: #1a1a2e;
color: #5fb3e4;
padding: 0.15em 0.4em;
border-radius: 4px;
}
a {
color: var(--color-highlight);
}
section.klausur {
background: repeating-linear-gradient(
135deg,
#e3f2fd,
#e3f2fd 40px,
#fff 40px,
#fff 80px
) !important;
}
@media print {
section.klausur {
background: #e3f2fd !important;
}
}
section.aufgabe {
background: #e3f2fd !important;
}
section.aufgabe footer {
display: none;
}
</style>
<!-- _class: invert -->
<!-- _header: '' -->
<!-- _backgroundColor: #000 -->
![bg cover opacity:0.2](./assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg)
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
**223015b** · Modul "Technik 1" · 1. Semester
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart
**Wintersemester 2025/26**
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg fit](./assets/qr/slides-223015b.png)
---
<!-- _class: lead -->
# Kapitel 3 23.01.2026
## Speichermedien & Schnittstellen
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg](./assets/hdd-ssd-comparison.png)
<!--
HDD aufgeschraubt neben SSD-Platine
Mechanisch vs. Elektronisch
-->
---
# Speicherkapazität: KB vs. KiB
**Das Problem:** Hersteller vs. Betriebssysteme
| Dezimal (SI) | Binär (IEC) |
|--------------|-------------|
| 1 KB = 1.000 Bytes | 1 KiB = 1.024 Bytes |
| 1 MB = 1.000 KB | 1 MiB = 1.024 KiB |
| 1 GB = 1.000 MB | 1 GiB = 1.024 MiB |
| 1 TB = 1.000 GB | 1 TiB = 1.024 GiB |
**1 TB Festplatte → Windows zeigt ~931 GB!**
<!--
Hersteller: Dezimal (SI-Präfix) - klingt mehr!
Betriebssysteme: Binär - aber zeigen "GB" statt "GiB"
Diskrepanz bei 1 TB: 1.000.000.000.000 vs. 1.099.511.627.776 Bytes
→ 10% Unterschied bei TB-Größen
Verwirrung für Konsumenten seit Jahrzehnten
ISO/IEC 80000-13: Definiert KiB, MiB, GiB, TiB (2008)
-->
---
# HDD: Aufbau & Struktur
**Komponenten:**
- **Platter:** Magnetisch beschichtete Scheiben
- **Spindel:** Dreht mit 5.400-7.200 RPM
- **Schreib-Lese-Kopf:** Schwebt nm-dünn über Platter
- **Aktuator:** Bewegt Kopf zur richtigen Spur
**Logische Struktur:**
- **Spuren:** Konzentrische Kreise auf Platter
- **Sektoren:** Unterteilung der Spuren (512 Bytes)
- **Zylinder:** Gleiche Spuren aller Platter
<!--
Aufbau seit 1956 (IBM) grundsätzlich gleich
Platter: Aluminium oder Glas mit Magnetschicht
Spindelgeschwindigkeit: Desktop 7.200, Laptop 5.400, Server 15.000 RPM
Head Crash: Schreib-Lese-Kopf berührt Platter → Kratzer → Datenverlust
Sektor: Kleinste adressierbare Einheit
LBA (Logical Block Addressing): Abstraktion der physischen Struktur
-->
---
# NVMe: Die SSD-Revolution
**NVMe = Non-Volatile Memory Express (2011)**
**Unterschied zu SATA-SSD:**
- SATA: Max. ~550 MB/s (AHCI-Protokoll)
- NVMe: Bis zu 7.000+ MB/s (PCIe direkt)
**Form-Faktoren:**
2,5" (SATA), M.2 (SATA oder NVMe), PCIe-Karte
<!--
NVMe = Non-Volatile Memory Express
Protokoll speziell für Flash-Speicher entwickelt.
SATA wurde für HDDs entwickelt.
Für SSDs ein Flaschenhals.
M.2 ist ein Formfaktor, kein Protokoll!
M.2 kann SATA oder NVMe sein prüfen!
-->
---
# HDD vs. SSD: Vergleich
| Aspekt | HDD | SSD (NVMe) |
|--------|----:|----------:|
| Sequentiell | ~150 MB/s | ~3.500 MB/s |
| Random Read | ~1 MB/s | ~500 MB/s |
| Latenz | ~10 ms | ~0,02 ms |
| Preis/TB | ~15€ | ~60€ |
| Max. Kapazität | 24 TB | 8 TB (Consumer) |
| Haltbarkeit | 3-5 Jahre | 5-10 Jahre |
<!--
Der Random-Access-Unterschied ist dramatisch.
500× schneller bei zufälligen Zugriffen.
Das ist der Grund, warum SSDs Betriebssysteme
so viel schneller starten lassen.
-->
---
<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->
# Wann HDD, wann SSD?
| Anwendung | Empfehlung |
|-----------|------------|
| Betriebssystem | SSD (NVMe) |
| Anwendungen, Spiele | SSD |
| Video-Editing (Projekte) | SSD |
| Foto-Archiv | HDD oder SSD |
| Backup | HDD |
| NAS / Server | HDD (oder Mix) |
| Cold Storage | HDD oder Band |
<!--
Die Faustregel:
- Oft genutzt, schnell gebraucht → SSD
- Selten genutzt, viel Kapazität → HDD
Viele setzen auf beides:
Kleine SSD für System + große HDD für Archiv.
-->
---
<!-- _class: lead -->
# Dateisysteme
## Die Organisation der Daten
---
# Was macht ein Dateisystem?
**Aufgaben:**
- Dateien in Blöcke aufteilen
- Speicherort verwalten (Allokation)
- Verzeichnisstruktur pflegen
- Metadaten speichern (Name, Datum, Rechte)
- Integrität sichern (Journaling)
**Ohne Dateisystem:**
Nur eine Folge von Bytes ohne Struktur.
<!--
Das Dateisystem ist die Abstraktionsschicht
zwischen Anwendungen und rohem Speicher.
Es entscheidet:
- Wie Dateien gefunden werden
- Wie freier Speicher verwaltet wird
- Was bei Abstürzen passiert
-->
---
# FAT32: Der Kompatibilitätskönig
**File Allocation Table, 32-bit (1996)**
**Vorteile:**
- Überall lesbar (Windows, Mac, Linux, Kameras, Fernseher...)
- Einfach, robust
**Nachteile:**
- Max. 4 GB pro Datei
- Max. 2 TB pro Volume
- Keine Berechtigungen
- Kein Journaling
**Ideal für:** USB-Sticks, SD-Karten (Kompatibilität)
<!--
4 GB Limit ist das Hauptproblem.
Ein 4K-Video oder ISO-Image passt oft nicht drauf.
Trotzdem: FAT32 ist der kleinste gemeinsame Nenner.
Wenn Kompatibilität wichtiger ist als Features → FAT32.
-->
---
# exFAT: FAT32 ohne Limits
**Extended FAT (2006, Microsoft)**
**Vorteile:**
- Keine praktischen Dateigrößen-Limits
- Breite Unterstützung (seit 2019 auch Linux-Kernel)
- Für Flash-Speicher optimiert
**Nachteile:**
- Kein Journaling
- Weniger robust als NTFS/APFS/ext4
**Ideal für:** Große Dateien auf portablen Medien
<!--
exFAT ist der Nachfolger von FAT32 für portable Medien.
SD-Karten über 32 GB sind standardmäßig exFAT.
Microsoft hat 2019 die Patente freigegeben.
Seitdem native Linux-Unterstützung.
-->
---
# NTFS: Windows-Standard
**New Technology File System (1993)**
**Features:**
- Journaling (Crash-Sicherheit)
- Dateirechte (ACLs)
- Kompression, Verschlüsselung
- Große Dateien und Volumes
**Nachteile:**
- Nur Windows schreibt nativ
- macOS: Nur lesen
- Linux: Über ntfs-3g (langsamer)
<!--
NTFS ist seit Windows NT der Standard.
Alle modernen Windows-Versionen nutzen es.
Für Windows-only-Systeme die beste Wahl.
Für portable Medien: Kompatibilitätsprobleme.
-->
---
# APFS: Apple-Modern
**Apple File System (2017)**
**Features:**
- Snapshots (Zeitpunkt-Kopien)
- Copy-on-Write (CoW)
- Native Verschlüsselung
- Optimiert für SSDs
**Nachteile:**
- Nur Apple-Geräte
- Nicht abwärtskompatibel mit HFS+
<!--
APFS ersetzte HFS+ auf allen Apple-Geräten.
Snapshots ermöglichen Time Machine und APFS-Klone.
Copy-on-Write: Daten werden nicht überschrieben,
sondern neue Versionen werden geschrieben.
Gut für Integrität und Snapshots.
-->
---
# ext4: Linux-Standard
**Fourth Extended File System (2008)**
**Features:**
- Journaling
- Extents (effiziente große Dateien)
- Online-Defragmentierung
- Bewährt und stabil
**Nachteile:**
- Windows/macOS können nicht nativ lesen
- Weniger Features als btrfs/ZFS
<!--
ext4 ist der Standard für Linux-Systeme.
Evolution: ext (1992) → ext2 → ext3 → ext4
Alternativen: btrfs (Snapshots, CoW), XFS, ZFS
Für Server oft XFS oder ZFS.
-->
---
# Dateisysteme: Übersicht
| FS | Max. Datei | Journaling | Ideal für |
|----|----------:|:----------:|-----------|
| FAT32 | 4 GB | ❌ | Kompatibilität |
| exFAT | 16 EB | ❌ | Große portable Dateien |
| NTFS | 16 EB | ✓ | Windows |
| APFS | 8 EB | ✓ | macOS, iOS |
| ext4 | 16 TB | ✓ | Linux |
<!--
Die Wahl hängt vom Kontext ab.
Portable Medien: FAT32 oder exFAT
Interne Laufwerke: NTFS, APFS, ext4 je nach OS
-->
---
<!-- _class: lead -->
# Backup & Archivierung
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg](./assets/backup-disaster.png)
<!--
Symbolbild: Kaputte Festplatte oder Ransomware
Das Worst-Case-Szenario
-->
---
# Warum Backup?
**Realitäten:**
- HDDs haben 1-2% jährliche Ausfallrate
- SSDs können ohne Vorwarnung sterben
- Ransomware verschlüsselt Daten
- Versehentliches Löschen passiert
- Diebstahl, Brand, Wasserschaden
**Die Frage ist nicht ob, sondern wann.**
<!--
Backblaze veröffentlicht jährliche HDD-Statistiken.
1-2% Ausfallrate klingt wenig, aber bei 100 Platten...
Pixar verlor fast "Toy Story 2" (1998).
Rettung: Eine Mitarbeiterin hatte ein Home-Backup.
-->
---
<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->
# Die 3-2-1-Regel
**3** Kopien eurer Daten
(Original + 2 Backups)
**2** verschiedene Medientypen
(z.B. SSD + HDD, oder lokal + Cloud)
**1** Kopie an anderem Ort
(Offsite: Cloud, anderes Gebäude)
<!--
Herkunft: Peter Krogh, "The DAM Book" (2005)
Warum 3 Kopien?
- Original kann kaputt gehen
- Backup 1 auch
- Backup 2 = Sicherheitspuffer
Warum 2 Medientypen?
- Gleiche Medien haben gleiche Schwachstellen
- Batch-Fehler bei HDDs derselben Charge
Warum 1 Offsite?
- Brand/Wasserschaden zerstört alles vor Ort
- Ransomware verschlüsselt angeschlossene Laufwerke
-->
---
# Backup-Arten
**Vollständig (Full):**
Kompletter Datenbestand jedes Mal.
Einfach, aber langsam und platzhungrig.
**Inkrementell:**
Nur Änderungen seit dem letzten Backup.
Schnell, aber Wiederherstellung komplex (Kette).
**Differenziell:**
Änderungen seit dem letzten Voll-Backup.
Mittelweg zwischen beiden.
<!--
Typisches Schema:
- Sonntag: Voll-Backup
- Mo-Sa: Inkrementell oder Differenziell
Inkrementell: Schnellstes Backup, langsamste Wiederherstellung
Differenziell: Kompromiss
Voll: Langsamstes Backup, schnellste Wiederherstellung
-->
---
# Backup in der Praxis
**macOS:** Time Machine
**Windows:** Veeam Agent (kostenlos), Windows Backup
**Linux:** rsync, Borg, Restic
**Cloud:** Backblaze, iCloud, Google Drive
**Wichtig:**
- Automatisieren (manuell wird vergessen)
- Regelmäßig testen (Backup nützt nichts, wenn Restore nicht funktioniert)
<!--
Time Machine: Stündliche Snapshots, APFS-Integration
Veeam: Enterprise-Level, kostenlose Endnutzer-Version
rsync: Unix-Klassiker, extrem effizient
Borg: Deduplizierung + Verschlüsselung
-->
---
# Langzeitarchivierung
**Probleme:**
- Bit Rot (Daten degradieren)
- Format-Obsoleszenz (wer öffnet .wpd?)
- Hardware-Obsoleszenz (Diskettenlaufwerk?)
**Lösungen:**
- Migration alle 5-10 Jahre auf neue Medien
- Offene Standards (PDF/A, TIFF, Plain Text)
- Redundante Kopien
<!--
WordPerfect dominierte die 1980er/90er.
Heute kann kaum jemand .wpd-Dateien öffnen.
Flash-Dateien (.swf) sind seit 2020 praktisch tot.
Millionen von Websites und Spielen verloren.
-->
---
# Archivmedien
**LTO-Tapes:**
- 18 TB pro Band (LTO-9)
- ~5€/TB
- 30 Jahre Haltbarkeit
- Für Cold Storage ideal
**M-DISC:**
- Spezielle DVD/Blu-ray
- 1.000+ Jahre Haltbarkeit (Herstellerangabe)
- Für kleine, wichtige Daten
**Cloud:**
- Glacier, Backblaze B2
- Günstig für Langzeit
<!--
LTO = Linear Tape-Open
AWS, Google, Netflix nutzen Tape für Archive.
M-DISC nutzt anorganische Schicht statt Dye.
Theoretisch sehr langlebig, praktisch ungetestet.
Cloud-Archive haben laufende Kosten.
Aber: Keine Hardware-Wartung.
-->
---
<!-- _class: lead -->
# Schnittstellen
---
# USB: Die Universal-Schnittstelle
| Version | Jahr | Geschwindigkeit |
|---------|------|----------------:|
| USB 1.1 | 1998 | 12 Mbit/s |
| USB 2.0 | 2000 | 480 Mbit/s (~60 MB/s) |
| USB 3.0 | 2008 | 5 Gbit/s (~625 MB/s) |
| USB 3.1 Gen 2 | 2013 | 10 Gbit/s |
| USB 3.2 Gen 2×2 | 2017 | 20 Gbit/s |
| USB4 | 2019 | 40 Gbit/s |
<!--
USB = Universal Serial Bus
Die Namensgebung ist ein Chaos.
USB 3.0 wurde nachträglich zu "USB 3.1 Gen 1" umbenannt.
Dann zu "USB 3.2 Gen 1".
Die Industrie verwirrt absichtlich.
-->
---
# USB-C: Der Stecker, nicht die Geschwindigkeit
**USB-C ist ein Steckertyp, kein Protokoll!**
Ein USB-C-Kabel kann sein:
- USB 2.0 (480 Mbit/s)
- USB 3.2 (bis 20 Gbit/s)
- USB4 (40 Gbit/s)
- Thunderbolt 3/4 (40 Gbit/s)
**Am Stecker nicht erkennbar.**
→ Kabel-Spezifikation prüfen!
<!--
Das ist eine häufige Quelle für Frustration.
"Ich habe ein USB-C-Kabel, warum ist es so langsam?"
Weil es ein USB 2.0-Kabel mit USB-C-Stecker ist.
Gute Kabel sind teurer, aber es lohnt sich.
-->
---
# Thunderbolt
**Thunderbolt 3/4 (2015/2020):**
- 40 Gbit/s
- PCIe über Kabel (externe GPUs möglich)
- DisplayPort integriert
- USB-C-Stecker
**Vorteile:**
- Sehr schnell
- Vielseitig (Daten, Video, Strom)
**Nachteile:**
- Teure Kabel
- Nicht alle USB-C-Ports sind Thunderbolt
<!--
Intel und Apple entwickelten Thunderbolt gemeinsam.
Lizenzfrei seit 2019.
Thunderbolt-Kabel haben oft ein Blitz-Symbol.
Aber nicht immer.
-->
---
# Video-Schnittstellen
| Schnittstelle | Max. Auflösung | Features |
|---------------|---------------:|----------|
| HDMI 2.0 | 4K/60Hz | ARC, CEC |
| HDMI 2.1 | 8K/60Hz, 4K/120Hz | VRR, eARC |
| DisplayPort 1.4 | 8K/60Hz | Daisy-Chain |
| DisplayPort 2.0 | 16K/60Hz | Mehr Bandbreite |
**HDMI:** Consumer-Geräte (TV, Konsolen)
**DisplayPort:** Computer, Monitore
<!--
HDMI hat Lizenzgebühren, DisplayPort nicht.
Deshalb ist DP bei Monitoren beliebter.
DisplayPort kann Daisy-Chaining:
Laptop → Monitor 1 → Monitor 2 über ein Kabel.
HDMI hat ARC (Audio Return Channel):
TV schickt Audio an Soundbar über HDMI.
-->
---
# Netzwerk
**Ethernet:**
| Standard | Geschwindigkeit |
|----------|----------------:|
| Fast Ethernet | 100 Mbit/s |
| Gigabit | 1 Gbit/s |
| 2.5 Gigabit | 2,5 Gbit/s |
| 10 Gigabit | 10 Gbit/s |
**WiFi:**
| Generation | Standard | Geschwindigkeit |
|------------|----------|----------------:|
| WiFi 5 | 802.11ac | ~1,3 Gbit/s |
| WiFi 6 | 802.11ax | ~9,6 Gbit/s |
| WiFi 7 | 802.11be | ~46 Gbit/s |
<!--
Gigabit-Ethernet ist heute Standard.
2,5G und 10G verbreiten sich für NAS und Poweruser.
WiFi-Geschwindigkeiten sind theoretische Maxima.
Real: Bruchteil davon, abhängig von Entfernung und Störungen.
-->
---
# Welche Schnittstelle für was?
| Anwendung | Empfehlung |
|-----------|------------|
| Externe SSD | USB 3.2 Gen 2 oder Thunderbolt |
| USB-Stick | USB 3.0 reicht |
| Monitor | DisplayPort oder HDMI 2.0+ |
| NAS im Heimnetz | Gigabit Ethernet |
| Backup-Platte | USB 3.0 |
| Video-Editing extern | Thunderbolt |
<!--
Die Schnittstelle muss zum Gerät passen.
Externe HDD über Thunderbolt?
Bringt nichts, die HDD ist der Flaschenhals.
NVMe-SSD über USB 2.0?
Verschwendung, USB ist der Flaschenhals.
-->
---
<!-- _class: aufgabe -->
# Hands-On: Eigene Speicher analysieren
**Aufgabe (30 Min):**
1. Welche Laufwerke habt ihr? (SSD, HDD, extern)
2. Welches Dateisystem nutzt ihr?
3. Wie ist eure Backup-Situation?
4. Welche Schnittstellen nutzt ihr?
**Tools:**
- Windows: Datenträgerverwaltung
- macOS: Festplattendienstprogramm
- Linux: `lsblk`, `df -h`
<!--
Ziel: Bewusstsein für eigene Infrastruktur.
Die meisten wissen nicht, welches Dateisystem
auf ihrem USB-Stick ist.
-->
---
<!-- _class: lead -->
# Fragen & Diskussion
**Kontakt:** lb-czechowski@hdm-stuttgart.de
**Folien:** [librete.ch/hdm/223015b](https://librete.ch/hdm/223015b/)
---
# Lizenz & Attribution
Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
- Erlaubt Teilen & Anpassen mit Namensnennung
- Adaptionen müssen unter gleicher Lizenz geteilt werden
Vollständige Lizenz: [creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/)

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,140 @@
---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
footer: "Michael Czechowski HdM Stuttgart WS 2025/26"
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
---
<style>
:root {
--color-foreground: #1a1a2e;
--color-highlight: #1e5f8a;
--color-dimmed: #4a4a6a;
}
section.invert {
--color-foreground: #fff;
}
section {
font-size: 1.7rem;
}
h1 {
color: #1e5f8a;
}
section.invert h1 {
color: #fff;
}
h2 {
color: #1f2937;
}
pre {
background: #0f0f23;
color: #5fb3e4;
border-radius: 8px;
border-left: 3px solid #1e5f8a;
}
pre code {
background: transparent;
color: inherit;
}
code {
background: #1a1a2e;
color: #5fb3e4;
padding: 0.15em 0.4em;
border-radius: 4px;
}
a {
color: var(--color-highlight);
}
section.klausur {
background: repeating-linear-gradient(
135deg,
#e3f2fd,
#e3f2fd 40px,
#fff 40px,
#fff 80px
) !important;
}
@media print {
section.klausur {
background: #e3f2fd !important;
}
}
section.aufgabe {
background: #e3f2fd !important;
}
section.aufgabe footer {
display: none;
}
</style>
<!-- _class: invert -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #000 -->
![bg cover opacity:0.2](./assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg)
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
**223015b** · Modul "Technik 1" · 1. Semester
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart
**Wintersemester 2025/26**
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
---
<!-- _header: '' -->
<!-- _footer: '' -->
![bg fit](./assets/qr/slides-223015b.png)
---
<!-- _class: lead -->
# Kapitel 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
-->
---
<!-- _class: lead -->
# Fragen & Diskussion
**Kontakt:** lb-czechowski@hdm-stuttgart.de
**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
---
# Lizenz & Attribution
Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
- Erlaubt Teilen & Anpassen mit Namensnennung
- Adaptionen müssen unter gleicher Lizenz geteilt werden
Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/

Binary file not shown.

After

Width:  |  Height:  |  Size: 220 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.0 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 9.2 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 425 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 64 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 241 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 232 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 484 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.6 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.9 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 249 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 388 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.3 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 27 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.4 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 956 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.4 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.0 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.7 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.8 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 161 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.3 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 175 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 204 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.0 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.7 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 112 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.1 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.6 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 55 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.5 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 525 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 171 KiB

View File

@@ -0,0 +1,9 @@
<svg xmlns="http://www.w3.org/2000/svg" width="80" height="80">
<defs>
<pattern id="diagonalStripes" patternUnits="userSpaceOnUse" width="80" height="80" patternTransform="rotate(135)">
<rect width="40" height="80" fill="#e3f2fd"/>
<rect x="40" width="40" height="80" fill="#ffffff"/>
</pattern>
</defs>
<rect width="100%" height="100%" fill="url(#diagonalStripes)"/>
</svg>

After

Width:  |  Height:  |  Size: 401 B

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.0 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.7 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 97 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 38 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.3 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.7 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 125 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.0 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 455 B

Binary file not shown.

After

Width:  |  Height:  |  Size: 631 B

Binary file not shown.

After

Width:  |  Height:  |  Size: 381 B

Binary file not shown.

After

Width:  |  Height:  |  Size: 528 B

Binary file not shown.

After

Width:  |  Height:  |  Size: 542 B

Binary file not shown.

After

Width:  |  Height:  |  Size: 463 B

Binary file not shown.

After

Width:  |  Height:  |  Size: 447 B

View File

@@ -0,0 +1 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 41 41" shape-rendering="crispEdges"><path fill="#ffffff" d="M0 0h41v41H0z"/><path stroke="#000000" d="M4 4.5h7m1 0h3m1 0h3m2 0h2m3 0h2m2 0h7M4 5.5h1m5 0h1m2 0h1m2 0h11m3 0h1m5 0h1M4 6.5h1m1 0h3m1 0h1m2 0h1m2 0h1m2 0h1m1 0h1m2 0h1m1 0h3m1 0h1m1 0h3m1 0h1M4 7.5h1m1 0h3m1 0h1m1 0h1m2 0h2m2 0h2m3 0h1m1 0h3m1 0h1m1 0h3m1 0h1M4 8.5h1m1 0h3m1 0h1m1 0h1m1 0h3m1 0h1m2 0h1m2 0h1m1 0h3m1 0h1m1 0h3m1 0h1M4 9.5h1m5 0h1m1 0h2m1 0h4m4 0h1m2 0h1m3 0h1m5 0h1M4 10.5h7m1 0h1m1 0h1m1 0h1m1 0h1m1 0h1m1 0h1m1 0h1m1 0h1m1 0h1m1 0h7M12 11.5h2m2 0h2m3 0h7M4 12.5h1m3 0h1m1 0h4m3 0h2m2 0h13m2 0h1M6 13.5h1m1 0h2m1 0h2m3 0h1m1 0h1m2 0h2m4 0h1m1 0h1m3 0h4M7 14.5h2m1 0h2m1 0h2m2 0h5m3 0h1m1 0h1m1 0h2m2 0h1M5 15.5h1m6 0h1m1 0h4m1 0h4m3 0h1m2 0h1M6 16.5h1m2 0h4m1 0h2m1 0h1m2 0h3m2 0h1m7 0h1m2 0h1M4 17.5h1m1 0h1m4 0h1m1 0h2m3 0h2m1 0h1m2 0h1m1 0h3m3 0h1m1 0h1M8 18.5h3m1 0h5m1 0h1m1 0h1m1 0h2m1 0h1m3 0h2m1 0h1m2 0h1M4 19.5h1m2 0h2m3 0h4m1 0h1m3 0h2m1 0h2m3 0h2m2 0h1M5 20.5h3m2 0h1m1 0h2m3 0h2m1 0h1m1 0h4m4 0h1m1 0h4M4 21.5h2m1 0h3m4 0h3m1 0h1m1 0h1m6 0h1m1 0h1m3 0h4M8 22.5h4m1 0h1m2 0h1m1 0h1m3 0h1m1 0h1m2 0h1m3 0h1m1 0h1m1 0h1M4 23.5h2m1 0h1m1 0h1m2 0h1m1 0h3m3 0h1m1 0h4m4 0h2m4 0h1M5 24.5h3m2 0h2m3 0h2m1 0h1m1 0h1m1 0h1m6 0h2m2 0h1M4 25.5h3m4 0h1m1 0h1m3 0h1m1 0h1m4 0h9m1 0h2M6 26.5h1m1 0h1m1 0h1m2 0h1m1 0h1m1 0h5m1 0h1m3 0h1m1 0h2m2 0h1m1 0h1M7 27.5h2m2 0h2m1 0h1m1 0h3m1 0h2m1 0h4m6 0h4M4 28.5h3m2 0h7m3 0h1m2 0h11m3 0h1M12 29.5h1m2 0h1m1 0h1m6 0h1m3 0h1m3 0h1m1 0h1m1 0h1M4 30.5h7m1 0h3m1 0h1m1 0h2m2 0h1m5 0h1m1 0h1m1 0h2m2 0h1M4 31.5h1m5 0h1m3 0h1m2 0h1m3 0h2m3 0h1m1 0h1m3 0h1m2 0h1M4 32.5h1m1 0h3m1 0h1m1 0h1m1 0h1m4 0h4m5 0h6m1 0h2M4 33.5h1m1 0h3m1 0h1m2 0h3m3 0h1m1 0h1m1 0h2m1 0h3m1 0h3m1 0h1m1 0h1M4 34.5h1m1 0h3m1 0h1m2 0h1m1 0h1m1 0h1m1 0h3m4 0h3m1 0h4M4 35.5h1m5 0h1m8 0h1m5 0h1m2 0h1m1 0h1M4 36.5h7m1 0h5m1 0h1m1 0h1m3 0h3m3 0h1m2 0h2m1 0h1"/></svg>

After

Width:  |  Height:  |  Size: 1.9 KiB

View File

@@ -0,0 +1 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 45 45" shape-rendering="crispEdges"><path fill="#ffffff" d="M0 0h45v45H0z"/><path stroke="#000000" d="M4 4.5h7m1 0h1m1 0h1m1 0h1m2 0h1m2 0h1m3 0h5m3 0h7M4 5.5h1m5 0h1m1 0h1m3 0h4m1 0h1m2 0h1m4 0h1m1 0h2m1 0h1m5 0h1M4 6.5h1m1 0h3m1 0h1m2 0h4m3 0h1m1 0h1m1 0h3m2 0h1m1 0h2m1 0h1m1 0h3m1 0h1M4 7.5h1m1 0h3m1 0h1m1 0h4m3 0h1m2 0h1m2 0h2m2 0h3m2 0h1m1 0h3m1 0h1M4 8.5h1m1 0h3m1 0h1m7 0h1m2 0h2m1 0h4m2 0h2m2 0h1m1 0h3m1 0h1M4 9.5h1m5 0h1m5 0h2m2 0h1m2 0h1m1 0h2m7 0h1m5 0h1M4 10.5h7m1 0h1m1 0h1m1 0h1m1 0h1m1 0h1m1 0h1m1 0h1m1 0h1m1 0h1m1 0h1m1 0h1m1 0h7M12 11.5h3m2 0h1m1 0h1m1 0h1m3 0h1m1 0h1m1 0h2m1 0h1M4 12.5h1m1 0h2m1 0h3m3 0h2m2 0h2m2 0h4m1 0h1m5 0h1m2 0h1m1 0h2M4 13.5h2m2 0h1m4 0h8m1 0h2m2 0h3m1 0h1m2 0h1m2 0h1m2 0h1M5 14.5h3m2 0h1m1 0h5m2 0h1m1 0h1m1 0h4m2 0h3m2 0h2m2 0h1M5 15.5h1m2 0h2m3 0h1m2 0h1m1 0h2m1 0h1m2 0h1m2 0h4m1 0h1m2 0h1M5 16.5h2m1 0h1m1 0h2m4 0h2m2 0h3m2 0h1m3 0h3m1 0h2m1 0h1m1 0h3M4 17.5h2m2 0h1m2 0h1m1 0h2m4 0h1m7 0h1m2 0h8m2 0h1M4 18.5h1m4 0h2m1 0h1m3 0h1m1 0h2m1 0h3m1 0h2m1 0h1m1 0h1m1 0h1m1 0h1m1 0h1m1 0h1M5 19.5h2m1 0h1m4 0h1m2 0h4m1 0h5m1 0h1m2 0h7m2 0h2M4 20.5h1m1 0h3m1 0h2m3 0h4m1 0h4m1 0h1m2 0h1m1 0h1m1 0h2m1 0h1m1 0h4M6 21.5h4m1 0h2m4 0h1m2 0h1m9 0h11M4 22.5h1m2 0h2m1 0h1m1 0h1m2 0h1m3 0h2m1 0h1m5 0h1m2 0h1m4 0h2m1 0h2M5 23.5h2m1 0h2m3 0h1m2 0h1m1 0h1m2 0h1m1 0h4m3 0h3m2 0h2m1 0h2M4 24.5h4m2 0h2m6 0h1m3 0h1m1 0h1m2 0h1m5 0h1m1 0h3m2 0h1M4 25.5h1m6 0h1m2 0h2m1 0h1m1 0h1m5 0h4m3 0h1m4 0h1m1 0h1M6 26.5h1m1 0h1m1 0h1m3 0h1m1 0h1m4 0h1m1 0h1m2 0h4m2 0h4m3 0h2M4 27.5h2m2 0h2m1 0h2m4 0h1m1 0h2m1 0h2m1 0h2m1 0h1m5 0h1m1 0h3m1 0h1M6 28.5h1m1 0h3m5 0h2m1 0h1m2 0h1m1 0h1m2 0h1m1 0h1m1 0h2m2 0h1m2 0h1m1 0h1M5 29.5h3m4 0h1m1 0h1m1 0h1m1 0h1m1 0h1m1 0h3m1 0h1m2 0h1m1 0h1m2 0h1m2 0h1m1 0h2M5 30.5h3m2 0h4m1 0h1m3 0h5m2 0h1m3 0h1m1 0h1m2 0h1m1 0h1m1 0h1M4 31.5h1m1 0h1m1 0h1m9 0h1m1 0h2m2 0h2m4 0h1m5 0h2m1 0h1M6 32.5h1m3 0h2m2 0h9m1 0h1m4 0h1m2 0h6M12 33.5h3m1 0h2m1 0h1m1 0h1m1 0h1m2 0h3m3 0h1m3 0h1m1 0h3M4 34.5h7m1 0h2m1 0h3m2 0h2m1 0h1m2 0h1m1 0h2m2 0h1m1 0h1m1 0h1m1 0h1m1 0h1M4 35.5h1m5 0h1m1 0h4m2 0h1m1 0h1m3 0h5m1 0h3m3 0h1m2 0h2M4 36.5h1m1 0h3m1 0h1m3 0h1m1 0h2m1 0h1m2 0h1m1 0h1m1 0h1m1 0h1m3 0h6m2 0h1M4 37.5h1m1 0h3m1 0h1m1 0h5m2 0h1m1 0h3m1 0h10m1 0h1m2 0h2M4 38.5h1m1 0h3m1 0h1m1 0h3m2 0h2m1 0h3m3 0h1m3 0h1m3 0h1m1 0h1m1 0h2M4 39.5h1m5 0h1m4 0h2m1 0h1m1 0h3m1 0h2m1 0h1m1 0h1m1 0h1m1 0h1m1 0h2M4 40.5h7m1 0h1m1 0h4m1 0h1m2 0h1m2 0h1m2 0h4m1 0h1m2 0h1m2 0h2"/></svg>

After

Width:  |  Height:  |  Size: 2.4 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 465 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 438 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.0 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.9 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.0 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.3 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 338 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 29 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.5 MiB

563
slides/223015b/klausur.md Normal file
View File

@@ -0,0 +1,563 @@
---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
footer: "Michael Czechowski HdM Stuttgart"
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
---
<style>
:root {
--color-foreground: #1a1a2e;
--color-highlight: #1e5f8a;
--color-dimmed: #4a4a6a;
}
section.invert {
--color-foreground: #fff;
}
section {
font-size: 1.7rem;
}
h1 {
color: #1e5f8a;
}
section.invert h1 {
color: #fff;
}
h2 {
color: #1f2937;
}
pre {
background: #0f0f23;
color: #5fb3e4;
border-radius: 8px;
border-left: 3px solid #1e5f8a;
}
pre code {
background: transparent;
color: inherit;
}
code {
background: #1a1a2e;
color: #5fb3e4;
padding: 0.15em 0.4em;
border-radius: 4px;
}
a {
color: var(--color-highlight);
}
section.klausur {
background: repeating-linear-gradient(
135deg,
#e3f2fd,
#e3f2fd 40px,
#fff 40px,
#fff 80px
) !important;
}
@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 -->
![bg cover opacity:0.2](./assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg)
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
**223015b** · Modul "Technik 1" · 1. Semester
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Verlustfrei vs. Verlustbehaftet
| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
|---|---|---|
| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich weg) |
| **Reduktion** | 30-50% | 80-99% |
| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
**Faustregel:**
- Medien für Endnutzer → Lossy oft akzeptabel
- Quellmaterial, Code, Archive → Lossless nötig
<!--
REDUNDANZ: Wiederholende Muster kompakter darstellen (z.B. "AAAA" → "4×A")
IRRELEVANZ: Für Menschen nicht wahrnehmbar (Psychoakustik, Psychovisuell)
KLAUSURRELEVANT:
- Verlustfrei = Original 1:1 wiederherstellbar
- Verlustbehaftet = Information geht verloren, aber kaum wahrnehmbar
- Redundanz vs. Irrelevanz ist der Kernunterschied!
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Dateneinheiten
| Einheit | Bytes | Potenz | Beispiel |
|---------|------:|:------:|----------|
| **Byte** | 1 | 10⁰ | Farbwerte eines Pixels |
| **Kilobyte (KB)** | 1.000 | 10³ | Kleiner Programmcode |
| **Megabyte (MB)** | 1 Million | 10⁶ | Textdokument |
| **Gigabyte (GB)** | 1 Milliarde | 10⁹ | Kinofilm in FullHD |
| **Terabyte (TB)** | 1 Billion | 10¹² | ~12h Video in 4K |
| **Petabyte (PB)** | 1 Billiarde | 10¹⁵ | Netflix-Gesamtarchiv |
| **Exabyte (EB)** | 1 Trillion | 10¹⁸ | Alle E-Mails weltweit/Tag |
| **Zettabyte (ZB)** | 1 Trilliarde | 10²¹ | Internet-Traffic 2016 |
<!--
SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes
Binär (IEC): 1 KiB = 1.024 Bytes (Kibibyte)
Windows zeigt oft binär, sagt aber "KB" → Verwirrung!
1 TB Festplatte = ~931 GiB nutzbar
Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
→ "Komm Mit Großem Tee, Peter Exte Zettelt Yachten"
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Der digitale Wendepunkt
| Jahr | Analog | Digital | Digital-Anteil |
|------|--------|---------|----------------|
| **1986** | 2,6 EB | 0,02 EB | **1%** |
| **2002** | — | — | **50%** (Wendepunkt) |
| **2007** | 18 EB | 277 EB | **94%** |
**Perspektive:**
- 1986: "Petabyte" war ein theoretisches Konzept
- 2025: ~181 Zettabyte jährlich produziert
**Magnetband lebt:** LTO-Tapes bleiben günstigstes Archivmedium
(AWS Glacier, Film-Archive, Rechenzentren)
<!--
PRÜFUNGSRELEVANT:
- Wendepunkt 2002
- Speichereinheiten (KB→MB→GB→TB→PB→EB→ZB)
- Magnetband als Archivmedium
QUELLE: Hilbert & López (2011): "The World's Technological Capacity to Store, Communicate, and Compute Information", Science
METHODIK: 60 analoge + digitale Technologien untersucht (1986-2007)
WENDEPUNKT 2002: Erstmals mehr digital als analog gespeichert
ANALOG damals: Bücher, Zeitungen, Vinyl, VHS, Filmrollen, Fotos
DIGITAL damals: Festplatten, CDs, DVDs, frühe Flash-Speicher
HEUTE: LTO-9 (2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Analoge Medien
### Distribution: physisch (Kauf, Verleih, Kopie)
- **Text**
- Bücher, Zeitungen, Zeitschriften, Lochkarten
- **Bild**
- Fotografie (Negativ, Dia, Polaroid), Mikrofilm
- **Audio:**
- Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
- **Video:**
- Film (35mm, Super 8), VHS, Betamax
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Digitale Medien
### Distribution: Datenträger (CD, USB), Download, Streaming, P2P
- **Text**
- E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
- **Bild**
- Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
- **Audio**
- Audiodatei (MP3, FLAC, WAV, AAC, OGG)
- **Video**
- Videodatei (MP4, MKV, AVI, WebM)
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Digitale Speichermedien
- **Optische Speicher**
- CD, DVD, Blu-ray
- **Magnetische Speicher**
- Festplatte (HDD), Magnetband (LTO)
- **Flash-Speicher**
- SSD, USB-Stick, SD-Karte
- **Cloud-Speicher**
- Dropbox, Google Drive, iCloud, AWS S3
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Rastergrafiken
**Aufbau:** Liste von Pixeln mit Farbwerten (2D-Array)
**Speicherbedarf (unkomprimiert):**
Breite × Höhe × Farbtiefe (in Bytes)
**Beispiele:** JPEG, PNG, WebP
| Bits (Farbtiefe) | Farben | Anwendung |
|-----:|-------:|-----------|
| 1 | 2 | Schwarz/Weiß (Fax) |
| 8 | 256 | Graustufen, GIF |
| 24 | 16,7 Mio. | True Color (Standard) |
| 32 | 16,7 Mio. + Alpha | Transparenz |
<!--
BERECHNUNG: Breite × Höhe × (Farbtiefe / 8)
BEISPIEL: 1920×1080 × 24 Bit = 1920×1080×3 = 6.220.800 Bytes ≈ 6,2 MB
Farbtiefe erklärt:
- 1 Bit: 2^1 = 2 Farben
- 8 Bit: 2^8 = 256 Farben
- 24 Bit: 2^24 = 16.777.216 Farben (je 8 Bit für R, G, B)
- 32 Bit: 24 Bit + 8 Bit Alpha-Kanal
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Vektorgrafiken
**Speicherung als geometrische Primitive:**
- Pfade (Bézierkurven mit Kontrollpunkten)
- Grundformen (Rechteck, Ellipse, Polygon)
- Text (Glyphen als Outlines)
**SVG-Beispiel:**
```xml
<circle cx="50" cy="50" r="40" fill="#ff0000"/>
```
<small>SVG beschreibt nicht jeden einzelnen Pixel im Raster, sondern deklariert wie Farben und Formen gesetzt werden.</small>
<!--
Vektorgrafiken beschreiben WAS gezeichnet werden soll.
Rastergrafiken beschreiben WIE jeder Pixel aussieht.
Rendering-Pipeline:
Vektordaten → Rasterisierung → Framebuffer → Display
Beim Skalieren werden einfach die Koordinaten multipliziert.
Keine Information geht verloren.
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Die Schwächen des Auges
**Menschen sehen:**
- Helligkeit besser als Farbe
- Große Flächen besser als feine Details
- Niedrige Frequenzen besser als hohe
**JPEG nutzt das aus:**
- Farbauflösung reduzieren (aber Helligkeit behalten)
- Glatte Flächen effizient speichern
- Hohe Frequenzen (Details) verwerfen
<!--
Das ist die visuelle Entsprechung zur Psychoakustik.
Das Auge hat mehr Rezeptoren für Helligkeit (Stäbchen)
als für Farbe (Zapfen).
Hohe Frequenzen = schnelle Wechsel = feine Details
Niedrige Frequenzen = langsame Wechsel = große Flächen
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
![bg right:20%](./assets/Barn-yuv.png)
# JPEG: Schritt 1 Farbraumkonversion
**RGB → Y'CbCr** (seltener Y'UV)
- **Y** = Helligkeit (Luminanz) Was das Auge am besten sieht
- **Cb** = Blau-Gelb-Anteil (Chrominanz)
- **Cr** = Rot-Grün-Anteil (Chrominanz)
**Warum diese Trennung?**
Y (Helligkeit) behält volle Auflösung.
Cb/Cr (Farbe) kann reduziert werden Auge merkt es kaum.
<!--
YCbCr ist wie RGB ein Tripel aus 3 Werten pro Pixel.
Der Unterschied: Statt Rot-Grün-Blau speichern wir Helligkeit + 2 Farbdifferenzen.
Die Umrechnung ist reversibel (mathematische Transformation).
Der Clou: Jetzt können wir Helligkeit und Farbe getrennt behandeln.
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# JPEG: Schritt 6 Huffman-Coding
**Verlustfreie Kompression der Restwerte**
**Idee:** Statt fester 8 Bit pro Wert → variable Bitlänge
Häufige Werte bekommen kurze Bit-Sequenzen.
| Zeichen | Häufigkeit | Code (Bit-Sequenz) |
|---------|------------|------|
| e | 40% | `0` (1 Bit) |
| a | 25% | `10` (2 Bit) |
| i | 20% | `110` (3 Bit) |
| o | 10% | `1110` (4 Bit) |
| u | 5% | `1111` (4 Bit) |
<!--
Huffman-Coding ist verlustfrei.
Der "Code" ist eine Bit-Sequenz, die das Zeichen eindeutig identifiziert.
Weil "e" am häufigsten vorkommt, bekommt es den kürzesten Code.
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Container und Codec
**Container = Das Dateiformat (Beispiel: MP4)**
Die "Box", die verschiedene Streams zusammenpackt:
- Video-Stream
- Audio-Stream(s)
- Untertitel
- Metadaten
**Codec = Der Kompressionsalgorithmus (Beispiel: AV1)**
Entscheidet, WIE komprimiert wird.
<!--
Container ≠ Codec
Das ist ein häufiges Missverständnis.
MP4 ist ein Container, nicht ein Codec.
Ein MP4 kann H.264, H.265 oder AV1 enthalten.
Übrigens: JPEG ist ein Codec (für Bilder), kein Container.
Bei Bildern fallen Container und Codec oft zusammen.
Tools wie MediaInfo zeigen beide Informationen.
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# H.264 / AVC
**Advanced Video Coding (2003)**
**Warum dominant?**
- Exzellente Kompression (~100:1 möglich)
- Hardware-Support in jedem Gerät seit ~2010
- YouTube, Netflix, Blu-ray alles H.264
**Features:**
- Variable Block-Größen (16×16 bis 4×4)
- Deblocking-Filter (reduziert Block-Artefakte)
<!--
H.264 revolutionierte Video-Streaming.
Ohne H.264 kein Netflix, kein YouTube in HD.
Hardware-Decoder bedeutet: Kein CPU-Aufwand, kein Akku-Drain.
Selbst billige Smartphones können H.264 abspielen.
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# AV1: Die offene Zukunft
**AV1 (2018)**
**Alliance for Open Media:**
Google, Netflix, Amazon, Microsoft, Apple, Mozilla...
**Eigenschaften:**
- 30% besser als H.265
- Royalty-free, Open Source
- 8K, HDR, hohe Frame-Rates
**Stand 2025:**
YouTube und Netflix nutzen AV1 für 4K/8K
Hardware-Encoder in aktuellen GPUs
<!--
AOM = Alliance for Open Media, gegründet 2015.
Historisch: Konkurrierende Tech-Giganten vereint.
Das Ziel: Nie wieder Patent-Chaos wie bei H.265.
Problem: Encoding ist sehr langsam (10-100× vs. H.264).
Hardware-Encoder lösen das zunehmend.
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Wann HDD, wann SSD?
| Anwendung | Empfehlung |
|-----------|------------|
| Betriebssystem | SSD (NVMe) |
| Anwendungen, Spiele | SSD |
| Video-Editing (Projekte) | SSD |
| Foto-Archiv | HDD oder SSD |
| Backup | HDD |
| NAS / Server | HDD (oder Mix) |
| Cold Storage | HDD oder Band |
<!--
Die Faustregel:
- Oft genutzt, schnell gebraucht → SSD
- Selten genutzt, viel Kapazität → HDD
Viele setzen auf beides:
Kleine SSD für System + große HDD für Archiv.
-->
---
<!-- _header: "" -->
<!-- _footer: "" -->
# Die 3-2-1-Regel
**3** Kopien eurer Daten
(Original + 2 Backups)
**2** verschiedene Medientypen
(z.B. SSD + HDD, oder lokal + Cloud)
**1** Kopie an anderem Ort
(Offsite: Cloud, anderes Gebäude)
<!--
Herkunft: Peter Krogh, "The DAM Book" (2005)
Warum 3 Kopien?
- Original kann kaputt gehen
- Backup 1 auch
- Backup 2 = Sicherheitspuffer
Warum 2 Medientypen?
- Gleiche Medien haben gleiche Schwachstellen
- Batch-Fehler bei HDDs derselben Charge
Warum 1 Offsite?
- Brand/Wasserschaden zerstört alles vor Ort
- Ransomware verschlüsselt angeschlossene Laufwerke
-->

View File

@@ -0,0 +1 @@
Dies ist eine einfache Textdatei. Keine Magic Number hier! Plaintext hat keinen Standard-Header.

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.3 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 197 KiB