---
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: #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

**Sommersemester 2026**

[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 EndnutzerInnen → 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 |

<!--
KLAUSURRELEVANT:
- Formel: Breite × Höhe × (Farbtiefe / 8) = Bytes
- Beispielrechnung: 1920 × 1080 × 3 = 6.220.800 Bytes ≈ 6,2 MB
- Farbtiefe: 2^n Farben bei n Bit
- 24 Bit = 8 Bit pro Kanal (R, G, B)
- 32 Bit = 24 Bit + 8 Bit Alpha (Transparenz)
-->


---

<!-- _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 WAS gezeichnet werden soll, nicht WIE jeder Pixel aussieht.</small>

<!--
KLAUSURRELEVANT:
- Vektor = Beschreibung (deklarativ)
- Raster = Pixel für Pixel (imperativ)
- Rendering-Pipeline: Vektordaten → Rasterisierung → Display
- Skalierung = Koordinaten multiplizieren → keine Information geht verloren
- SVG = Scalable Vector Graphics (Web-Standard)
-->


---

<!-- _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 (Helligkeit behalten)
- Glatte Flächen effizient speichern
- Hohe Frequenzen (feine Details) verwerfen

<!--
KLAUSURRELEVANT:
- Mehr Stäbchen (Helligkeit) als Zapfen (Farbe) im Auge
- "Frequenz" = räumliche Frequenz = wie schnell ändert sich Helligkeit?
- Niedrig = langsame Änderung = große gleichmäßige Fläche
- Hoch = schnelle Änderung = feine Details, Kanten
- Analogie zur Psychoakustik bei MP3 (letztes Mal)
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


![bg right:20%](./assets/Barn-yuv.png)

# JPEG Schritt 1: Farbraumkonversion

**RGB → Y'CbCr**

- **Y** = Helligkeit (Luminanz)
- **Cb** = Blau-Gelb-Anteil (Chrominanz)
- **Cr** = Rot-Grün-Anteil (Chrominanz)

**Warum?**
Y (Helligkeit) behält volle Auflösung
Cb/Cr (Farbe) kann reduziert werden

<!--
KLAUSURRELEVANT:
- YCbCr = auch 3 Werte pro Pixel, aber anders organisiert
- Statt R-G-B: Helligkeit + 2 Farbdifferenzen
- Umrechnung ist reversibel (mathematische Transformation)
- Vorteil: Helligkeit und Farbe getrennt behandelbar
- Bild zeigt: Y (oben), Cb (Mitte), Cr (unten)
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# JPEG Schritt 6: Huffman-Coding

**Verlustfreie Kompression der Restwerte**

**Idee:** Variable Bitlänge statt fester 8 Bit
Häufige Werte → kurze Codes

| Zeichen | Häufigkeit | Code |
|---------|------------|------|
| 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) |

<!--
KLAUSURRELEVANT:
- Huffman = verlustfrei, optimal für bekannte Häufigkeiten
- Präfix-frei: Kein Code ist Anfang eines anderen
- Häufigstes Zeichen = kürzester Code
- Auch in ZIP, PNG, MP3 verwendet
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->

<!--
# Huffman-Coding: Beispiel

**Originaltext:** `ABRACADABRA` (11 Zeichen × 8 Bit = 88 Bit)

**Häufigkeitsanalyse:**
A=5, B=2, R=2, C=1, D=1

**Huffman-Baum → Codes:**
| Zeichen | Häufigkeit | Code |
|---------|------------|------|
| A | 5 | `0` |
| B | 2 | `10` |
| R | 2 | `110` |
| C | 1 | `1110` |
| D | 1 | `1111` |

**Codiert:** `0 10 110 0 1110 0 1111 0 10 110 0` = **23 Bit**
**Kompression:** 88 → 23 Bit = **74% gespart**


- Beispiel Schritt für Schritt durchrechnen
- Warum funktioniert's? A kommt 5× vor, bekommt kürzesten Code
- Präfix-Eigenschaft: Kein Code ist Anfang eines anderen → eindeutig dekodierbar
- Frage: "Was passiert, wenn alle Zeichen gleich häufig sind?" → Keine Ersparnis
- In JPEG: Nicht Buchstaben, sondern DCT-Koeffizienten werden so codiert
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# WebP & AVIF: Moderne Alternativen

**WebP (Google, 2010):**
- Lossy und Lossless
- Transparenz und Animationen
- 25–35% kleiner als JPEG

**AVIF (2019):**
- Basiert auf AV1-Video-Codec
- 50% kleiner als JPEG
- HDR-Unterstützung, patent-frei

**Browser-Support 2025:** WebP universell, AVIF wächst

<!--
KLAUSURRELEVANT:
- WebP: VP8-Kompression (Google Video-Codec)
- AVIF: Alliance for Open Media (Google, Netflix, Amazon, Apple, Mozilla)
- Beide besser als JPEG, aber Kompatibilität bleibt Problem
- JPEG bleibt dominant: alte Kameras, Software, Workflows
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Container und Codec

**Container = Dateiformat (z.B. MP4)**
Die "Box", die verschiedene Streams zusammenpackt:
- Video-Stream
- Audio-Stream(s)
- Untertitel
- Metadaten

**Codec = Kompressionsalgorithmus (z.B. H.264)**
Bestimmt, WIE komprimiert wird

<!--
KLAUSURRELEVANT:
- Container ≠ Codec (häufiges Missverständnis!)
- MP4 kann H.264, H.265 oder AV1 enthalten
- Gleiche Endung, unterschiedlicher Inhalt
- Tool-Tipp: MediaInfo zeigt beides an
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# H.264 / AVC

**Advanced Video Coding (2003)**

**Warum dominant?**
- Exzellente Kompression (~100:1 möglich)
- Hardware-Decoder 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 Artefakte)

<!--
KLAUSURRELEVANT:
- H.264 revolutionierte Video-Streaming
- Ohne H.264 kein Netflix, kein YouTube HD
- Hardware-Decoder = kein CPU-Aufwand, kein Akku-Drain
- Selbst billigste 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, Netflix nutzen AV1 für 4K/8K
Hardware-Encoder in aktuellen GPUs

<!--
KLAUSURRELEVANT:
- AOM gegründet 2015 – historisch: Konkurrenten vereint
- Ziel: Nie wieder Patent-Chaos wie bei H.265
- Problem: Encoding sehr langsam (10–100× vs. H.264)
- Hardware-Encoder lösen das zunehmend
- AV1 gewann 2024 einen Emmy für technische Innovation
-->


---

<!-- _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
-->