---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
---

<style>
: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: #e3f2fd !important;
}
section.klausur 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-1.svg)

---

<!-- _class: lead -->

# Termin 1 – 19.12.2025
## Grundlagen, Text & Audio

---

![bg right:40%](./assets/matrix-code.png)

# WTF!?

```
89 50 4E 47 0D 0A 1A 0A
00 00 00 0D 49 48 44 52
00 00 01 90 00 00 01 2C
```

<!--

"Ich schaue in viele fragende Gesichte ..."

"Doch vertraut mir, am Ende der heutigen Veranstaltung werdet ihr mir genau sagen können was hier steht"

-->

---

![bg right:30%](./assets/matrix-code.png)

# What the HEX-Code

```
89 50 4E 47 ...
```

| Binär | Hex | Dez | ASCII |
|-------|-----|-----|-------|
| `1000 1001` | `89` | 137 | ✗ (> 127) |
| `0101 0000` | `50` | 80 | **P** |
| `0100 1110` | `4E` | 78 | **N** |
| `0100 0111` | `47` | 71 | **G** |

→ **PNG**-Signatur! (Das `89` markiert: "Ich bin binär, kein Text!")

<!--
Hex = 2 Ziffern = 1 Byte = 8 Bit
89 hex = 8×16 + 9 = 137 dezimal
ASCII geht nur bis 127, also nicht druckbar
50, 4E, 47 = P, N, G in ASCII
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg](./assets/lightbulb-onoff.png)

<!--
Bit = Binary Digit
Demonstration: Glühbirne AN/AUS = 1 Bit
-->

---

# Das Bit

**Kleinste Informationseinheit**

- **0 oder 1**
- AN oder AUS
- Strom fließt oder nicht

<!--
BIT = Binary Digit (Binärziffer) – 1948 von Claude Shannon geprägt

"Bit warum somit ein Neologismus, bis dato gab es das Wort in dieser Bedeutung überhaupt nicht"

Shannon war Mathematiker bei Bell Labs – begründete die Informationstheorie

Warum binär? Elektronische Schaltungen haben nur 2 Zustände: Strom/kein Strom
Das ist physikalisch am stabilsten (weniger Fehler als 3 oder 10 Zustände)
Alles Digitale basiert auf dieser simplen Idee: AN oder AUS
Transistoren in modernen CPUs: Milliarden davon, schalten Milliarden Mal pro Sekunde
-->

---

# Das Byte

<!--
"Ein Bit allein macht nicht glücklich, die Welt ist nunmal nicht schwarz oder weiß"

"Und um noch weitere (nennen wir es Schattierungen, ganz literarisch) der Welt abbilden zu können, benötigen wir eine weiter Messgröße oder Einheit"

BYTE = Wortspiel aus "Bit" + "Bite" (Bissen) – ein "Bissen" Information

"Doch warum hat man nicht einfach »Bite« genommen?" Fangfrage -> Bit und Bite sind sich zu nahe ... Verwechslungsgefahr!
-->

---

# Das Byte

**1 Byte = 8 Bits**

```
0 1 0 0 1 1 0 1
```

<!--

"Und das sieht dann so aus"

"Aber warum genau 8 Bits?" -> "Das versteht man leider erst so richtig wenn man sich das Ergebnis anschaut, wie viele Möglichkeiten hieraus entstehen"

"Menschen neigen dazu, exponentielles Wachstum zu unterschätzen"

Rätsel: "Wenn sich das Wachstum einer Seerose auf einem Teich jeden Tag verdoppelt · und nach *zehn Tagen* der ganze Teich bedeckt ist, wann ist er zur Hälfte zugewachsen?"

Frage: "Weiß jemand wieviele Zustände wir mit 8 Bit beschreiben können?"

-->

---

# Das Byte

**1 Byte = 8 Bits**

```
0 1 0 0 1 1 0 1
```

2⁸ = **256 Möglichkeiten** (0-255)

<!--

Historie: "Es gab durchaus einen »Machtkampf« und es war überhaupt nicht klar welche Länge sich durchsetzen wird."

- 1964: IBM System/360 setzte diesen Standard (vorher: 6-Bit, 7-Bit Systeme)
- ASCII (1963) brauchte 7 Bit für 128 Zeichen

ASCII = American Standard Code for Information Interchange

Praktikabilität:
- 8 Bit = praktisch für Hardware (Zweierpotenz: 2³ = 8)
- 8 Bit = 2 Hexadezimalziffern (elegante Darstellung)

1 Bit = 2 Zustände
2 Bit = 4 Zustände
3 Bit = 8 Zustände
4 Bit = 16 Zustände
5 Bit = 32 Zustände
6 Bit = 64 Zustände
7 Bit = 128 Zustände
8 Bit = 256 Zustände

Rechnung: 2×2×2×2×2×2×2×2 = 256 mögliche Kombinationen

von griech. hexa „sechs“ und lat. decem „zehn“

Eselsbrücke: 1 Byte = 1 Buchstabe/Symbol (in ASCII/UTF-8 für einfache Zeichen)
-->

---

# Dateneinheiten

| Einheit | Bytes | Bits | Potenz |
|---------|-------|------|--------|
| **1 Byte** | 1 | 8 | 10⁰ |
| **1 Kilobyte (KB)** | 1.000 | 8.000 | 10³ |
| **1 Megabyte (MB)** | 1.000.000 | 8 Mio. | 10⁶ |
| **1 Gigabyte (GB)** | 1 Mrd. | 8 Mrd. | 10⁹ |
| **1 Terabyte (TB)** | 1 Bio. | 8 Bio. | 10¹² |

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

---

# Dateneinheiten (Fortsetzung)

| Einheit | Bytes | Potenz | Beispiel |
|---------|-------|--------|----------|
| **1 Petabyte (PB)** | 10¹⁵ | 1.000 TB | Netflix-Gesamtarchiv |
| **1 Exabyte (EB)** | 10¹⁸ | 1.000 PB | Alle E-Mails weltweit/Tag |
| **1 Zettabyte (ZB)** | 10²¹ | 1.000 EB | Internet-Traffic 2016 |
| **1 Yottabyte (YB)** | 10²⁴ | 1.000 ZB | *Noch nie erreicht* |

<!--
Peta = 10^15 (Billiarde)
Exa = 10^18 (Trillion)
Zetta = 10^21 (Trilliarde)
Yotta = 10^24 (Quadrillion)

Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
→ "Komm Mit Großem Tee, Peter Exte Zettelt Yachten"
-->

---

# Datenwachstum der Menschheit

| Jahr | Datenmenge | Kontext |
|------|------------|---------|
| **100.000 v. Chr.** | 0 | Erste Menschen, nur Sprache |
| **3.000 v. Chr.** | ~wenige KB | Keilschrift, Hieroglyphen |
| **1450** | ~wenige GB | Gutenberg, Buchdruck |
| **1986** | **2,6 EB** | 99% analog (Bücher, Vinyl, VHS) |
| **2007** | **295 EB** | 94% digital |
| **2025** | **181 ZB** | 90% unstrukturiert |

<!--
Exponentielles Wachstum: Verdopplung alle 2 Jahre
1986: Letzte Ära mit analoger Dominanz
2007: Erste Jahr, in dem digital > analog
2025: 181 ZB = 181.000.000.000.000.000.000.000 Bytes
Analog blieb bei ~2,6 EB stehen (Bücher, Vinyl, Film)
Digital explodierte: IoT, Social Media, Cloud, Video
-->

---

<!-- _class: klausur -->
<!-- _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)

<!--
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
PRÜFUNGSRELEVANT: Wendepunkt 2002, Speichereinheiten (KB→MB→GB→TB→PB→EB→ZB), Magnetband als Archivmedium
-->

---

# 181 Zettabyte – Was bedeutet das?

**2025:** Welt erzeugt **181 ZB** pro Jahr

- **2,5 Quintillionen Bytes** täglich
- **29 Terabyte** pro Sekunde
- **90%** davon: unstrukturiert (Videos, Bilder, Audio)
- **70%** davon: von Nutzern generiert

**Zum Vergleich:**
- 1 ZB = 250 Milliarden DVDs
- 181 ZB = Jeder Mensch erzeugt ~23 TB/Jahr

<!--
Quellen: IDC Global DataSphere Forecast, Statista 2025
IoT-Geräte allein: 73 ZB in 2025
Cloud-Speicher: 100 ZB (50% der Weltdaten)
Prognose 2028: 394 ZB
-->

---

# AI-generierte Inhalte 2025

**Wie viel Content ist heute synthetisch?**

| Bereich | AI-Anteil |
|---------|-----------|
| **Neue Webseiten** | ~74% enthalten AI-Content |
| **Web-Text gesamt** | ~30-40% AI-generiert |
| **Neue Artikel** | ~52% von AI geschrieben |
| **Social-Media-Bilder** | ~71% AI-generiert |

**Prognose 2026:** 90% des Online-Contents synthetisch

<!--
Quellen: Ahrefs 2025, arXiv, Europol-Report
"Synthetic Media" = AI-generiert oder -manipuliert
Problem: Schwer zu messen, da Menschen + AI zusammenarbeiten
Model Collapse: AI trainiert auf AI-Output → Qualitätsverlust
-->

---

<!-- _class: lead -->

# ASCII
## Ein Zeichensatz to rule them all

<!--
WARUM 7 BIT STATT 8?
- 1963: Fernschreiber (Teletype) arbeiteten mit 7-Bit-Codes
- Das 8. Bit diente der Paritätsprüfung (Fehlererkennung bei Übertragung)
- Speicher war kostspielig: jedes eingesparte Bit zählte
- 128 Zeichen galten als ausreichend für den englischsprachigen Raum

KULTURHISTORISCHER KONTEXT:
- "American Standard Code for Information Interchange" (1963)
- Entwickelt für US-amerikanische Bedürfnisse
- Keine Unterstützung für: Umlaute (ä, ö, ü), ß, diakritische Zeichen (é, ñ, ç)
- Nicht-lateinische Schriftsysteme (Kyrillisch, Arabisch, CJK) wurden nicht berücksichtigt
- Führte zu zahlreichen inkompatiblen Erweiterungen (ISO-8859-1, Windows-1252, etc.)

WARUM NOCH HEUTE RELEVANT?
- Abwärtskompatibilität: UTF-8 ist vollständig ASCII-kompatibel (Zeichen 0-127 identisch)
- Internetprotokolle basieren auf ASCII: HTTP-Header, SMTP, URLs
- Programmiersprachen: Schlüsselwörter und Syntax sind ASCII
- Ein 60 Jahre alter Standard, der durch Kompatibilitätszwänge fortbesteht

HISTORISCHE RANDNOTIZ:
- Das @-Zeichen wurde nachträglich aufgenommen
- Heute unverzichtbar für E-Mail-Adressen weltweit
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->


![bg fit](./assets/original-ascii-table.png)

<!--

Vorgeschichte:

US-ASCII (1967) Code Chart
- 7 Bit = 128 Zeichen
- Erste 32: Steuerzeichen (nicht druckbar)
- Zeichen 32-126: Druckbar (Buchstaben, Ziffern, Satzzeichen)
- Keine Umlaute, kein ñ, kein é
- "American Standard" → Rest der Welt ausgeschlossen

"Ich möchte, dass ihr das mit mir jetzt gemeinsam lesen lernt; stellt euch vor ihr seid ArchäologInnen."

"Wie würdet ihr vorgehen?"

-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

»256 Shades of Gray«

![bg fit](./assets/grayscale-gradient.png)

<!--

»256 Shades of Gray«

256 Graustufen: 0 = Schwarz, 255 = Weiß
-->

---

# Was kann man mit 256 Zuständen machen?

* **256 Zeichen** (Buchstaben, Zahlen, Symbole)
* **256 Helligkeit bzw. Luminanz** (0 = Schwarz/Dunkel, 255 = Weiß/Hell)
* **256 Lautstärkestufen**
* **Zahlen 0-255** (oder -128 bis +127)

* *Fällt Euch noch mehr ein?*

<!--
256 = die "magische Zahl" bei 8 Bit
Alltagsbeispiele:
- Lautstärkeregler (0 = stumm, 255 = max)
- Helligkeitswerte in Bildern (0 = schwarz, 255 = weiß)
- Alter in Jahren (0-255 reicht für Menschen locker)
- Zeichen (ASCII erweitert: 256 Buchstaben/Symbole)
Für Farbbilder: 3 Bytes pro Pixel (R, G, B)
Jeder Kanal 0-255 → 256³ = 16.777.216 Farben ("True Color")
Das menschliche Auge kann etwa 10 Millionen Farben unterscheiden
→ 24 Bit reicht für fotorealistische Bilder
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/rgb-color-model.png)

<!--
Welche Farben für ein volles Spektrum bieten sich nach unserer gelernten Sparsamkeit hier am besten an?

1. CMYK bzw. in diesem Fall CMYW
2. RGB
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/rgb-color-model-with-title.png)

<!--
RGB = Additive Farbmischung (Bildschirme)

Sog. RGB Tuple (geordnete endliche Liste)
-->

---

![bg right:50%](./assets/addaptive-substractive-colors.jpg)

# Farben: RGB-Modell

**1 Pixel = 3 Bytes**

- **Rot:** 0-255
- **Grün:** 0-255
- **Blau:** 0-255

**Beispiele:**
`FF 00 00` = Rot | `00 FF 00` = Grün
`00 00 00` = Schwarz | `FF FF FF` = Weiß

<!--
"Weiß jemand oder möchte jemand raten, wofür das "s" bei "sRGB" steht?"

sRGB = Standard RGB
CMYK = Subtraktive Farbmischung (Druck)
Hex-Notation: FF = 255 in Dezimal
CSS-Farben nutzen Hex: #FF0000 = Rot
Wer HTML/CSS gemacht hat, kennt das schon!
background-color: #FF0000; = Rot
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/hex-dec-lookup-table.png)

---

# Das Problem: Sprachen

**Die Welt hat mehr als 256 Zeichen!**

- Englisches Alphabet: 52 (A-Z, a-z)
- + Ziffern: 10 (0-9)
- + Sonderzeichen: ~30

**≈ 90 Zeichen → passt in 1 Byte**

**Aber:** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 😀

→ **1 Byte reicht nicht!**

<!-- 
Problem der Zeichenkodierung
ASCII (1963): 7 Bit = 128 Zeichen (nur Englisch)
ISO-8859-1 (Latin-1): 8 Bit = 256 Zeichen (Westeuropa)
Chaos: Verschiedene Standards für verschiedene Sprachen
-->

---

# 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)
- **Zeichen 0-127: identisch mit ASCII** (Abwärtskompatibilität!)
- Umlaute: 2 Bytes · CJK: 3 Bytes · Emoji: 4 Bytes

<!--
Unicode Consortium: Non-Profit seit 1991
Aktuell: Unicode 16.0 (2024)
UTF-8 = Unicode Transformation Format, 8-bit

WICHTIG für Kontext zur ASCII-Folie:
- Die ersten 128 Zeichen in UTF-8 sind EXAKT ASCII
- Deshalb funktioniert alter ASCII-Code noch heute
- UTF-8 ist der Grund, warum ASCII nie verschwinden wird
- "A" in ASCII = "A" in UTF-8 = 0x41 = 65 dezimal

Byte-Längen:
- ASCII-Zeichen (0-127): 1 Byte
- Umlaute, diakritische Zeichen: 2 Bytes
- Chinesisch, Japanisch, Koreanisch: 3 Bytes
- Emoji, seltene Zeichen: 4 Bytes
-->

---

# Beispiel: Bytes zählen

**Text:** `"Why the heck braucht 💩 4 Bytes?!"`

```
W h y   → je 1 Byte (4 Bytes)
t h e   → je 1 Byte (4 Bytes)
h e c k → je 1 Byte (4 Bytes)
        → 1 Byte (Leerzeichen)
b r a u c h t → je 1 Byte (7 Bytes)
        → 1 Byte
💩      → 4 Bytes! (0xF0 9F 92 A9)
        → 1 Byte
4   B y t e s ? ! → je 1 Byte (9 Bytes)
```

**Gesamt: 37 Bytes**

<!-- 
Buchstaben = 1 Byte (ASCII/UTF-8-kompatibel)
Emoji = 4 Bytes (Unicode-Bereich U+1F4A9)
Haufen-Emoji: "Pile of Poo" (offizieller Name!)
UTF-8-Kodierung: Variable Länge spart Speicher bei ASCII
-->

---

# Hexadezimal: Lesbarkeit

**Binär ist unleserlich:**
`01001101 01010000 00110011`

**Hexadezimal (Base 16):**
`4D 50 33` (= "MP3" in ASCII)

**Jede Hex-Ziffer = 4 Bits (ein "Nibble")**
0-9, A-F (10=A, 11=B, ..., 15=F)

**ASCII Tabelle (0-127):**
[https://www.asciitable.com](https://www.asciitable.com)

<!--

"Gerne vorab auf den Link gehen"

WICHTIG: ASCII geht nur von 0-127!
- Werte 128-255 sind NICHT in der ASCII-Tabelle
- Das wird später bei Magic Numbers wichtig

Warum Hexadezimal statt Dezimal?
- Binär ist zu lang: 01001101 (8 Zeichen für 1 Byte)
- Dezimal passt nicht: 77 (unregelmäßig, manchmal 2, manchmal 3 Ziffern)
- Hex ist perfekt: 4D (immer 2 Ziffern pro Byte)

Trick: 4 Bits = 1 Hex-Ziffer (weil 2⁴ = 16)
0000 = 0, 0001 = 1, ..., 1001 = 9, 1010 = A, 1011 = B, ..., 1111 = F

"Nibble" = 4 Bits = halbes Byte (Wortspiel: nibble = knabbern, byte = beißen)

Umrechnung üben:
- 0x4D = 4×16 + 13 = 64 + 13 = 77 (Dezimal) = Buchstabe "M" in ASCII
- 0xFF = 15×16 + 15 = 255 (Maximum für 1 Byte)

Hex-Editor = Standard-Tool für Dateianalyse und Reverse Engineering

-->

---

<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #000 -->

![bg fit](./assets/hex-code-hidden.png)

<!--

"Zurück zu Frage am Anfang: Was steht hier nun?"

"Versucht es kurz selbst zu entschlüsseln"

-->

---

<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #000 -->

![bg fit](./assets/hex-code.png)

<!--
Hex-Editor-Screenshot mit PNG-Datei
Erste Bytes: 89 50 4E 47 = PNG-Signatur
- 89: non-printable character (signalisiert, dass wir hier außerhalb von ASCII sind)
- 50: P
- 4E: N
- 47: G
IHDR = Image Header (Breite, Höhe, Farbtiefe)
Zeigen, wie man Magic Number liest
Tool: HxD (Windows), Hex Fiend (Mac), xxd (Linux)
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/8bit-P-character.png)

---

# Magic Numbers

**Dateityp-Identifikation durch erste Bytes**

| Format | Magic Number (Hex) | Lesbar? |
|--------|-------------------|---------|
| PNG | `89 50 4E 47` | ✗ P N G |
| JPEG | `FF D8 FF` | ✗ ✗ ✗ |
| PDF | `25 50 44 46` | % P D F ✓ |
| ZIP | `50 4B 03 04` | P K ✗ ✗ |

**Wichtig:** ASCII = nur 0-127! Werte darüber (z.B. `89` = 137) sind **nicht druckbar** (non-printable). *Hex-Editoren zeigen dafür `.` oder `ÿ` als Platzhalter.*

<!--
"Warum findet ihr 89 nicht in der ASCII-Tabelle?"

KERNKONZEPT:
- 1 Byte = 256 Werte (0-255)
- ASCII deckt nur 0-127 ab (die "druckbaren" Zeichen)
- 128-255 = Binärdaten, Steuerzeichen, erweiterte Zeichen

WARUM nutzt PNG absichtlich 89 (= 137 dezimal)?
1. Markiert die Datei eindeutig als BINÄR, nicht Text
2. Erkennt kaputte Übertragungen (alte Systeme schnitten Bit 7 ab)
3. Verhindert versehentliches Öffnen als Textdatei

Geschichte: "PK" bei ZIP = Phil Katz (Erfinder von PKZip, 1989)
Fun Fact: 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

Sicherheits-Aspekt:
virus.exe → bild.jpg umbenennen täuscht nur Menschen
Windows vertraut der Endung, aber "file" (Linux) liest Magic Number
-->

---

![bg right:25%](./assets/qr/hexed-it.png)

# Hands-On: WTF Files

**Aufgabe (30 Min):**

1. Drei Dateien ohne Extension: `wtf1`, `wtf2`, `wtf3`
   → Download: `materials/` Ordner
2. Öffne im Hex-Editor
3. Lies erste 16 Bytes
4. Identifiziere Format (Magic Number)
5. Benenne um und öffne

**Tools:** [hexed.it](https://hexed.it) (online), HxD, Hex Fiend, Bless

<!--
Praktische Phase: Studierende arbeiten selbst
Dateien im materials/ Ordner:
- wtf1: Plaintext (keine Magic Number)
- wtf2: PNG (89 50 4E 47)
- wtf3: JPEG (FF D8 FF)
Gruppenarbeit: 3-4 Personen
Ziel: Hex-Dump lesen lernen, Dateiformate verstehen
-->

---

<!-- _class: lead -->

# Teil 2: Die MP3-Revolution
## Psychoakustik & Audio-Kompression

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg](./assets/cassette-ipod.png)

<!--
Kassette neben iPod
Visueller Kontrast: Analog vs. Digital
1980er vs. 2000er
-->

---

# Warum digital? Das Speicherproblem

**Analog → Digital:** Kopieren ohne Qualitätsverlust, aber...

**CD-Qualität (1982):**
44.100 Hz × 16 Bit × 2 Kanäle = **10,6 MB/Minute**

| Inhalt | Größe | Problem (1990er) |
|--------|-------|------------------|
| 1 Song (4 Min) | ~42 MB | Passt gerade so |
| 1 Album (60 Min) | ~635 MB | Ganze Festplatte! |

**→ Digital ist super, aber zu groß für Speicher & Internet**

<!--
WARUM DIGITAL?
- Kopieren ohne Generationsverlust (Kassette → Kassette = schlechter)
- Perfekte Archivierung
- Bearbeitung möglich

DAS PROBLEM:
- CD = unkomprimiert, riesig
- Festplatten 1990: 100-500 MB
- Internet 1995: 56k Modem = 1 Song = Stunden
- Streaming? Unmöglich

LÖSUNG: Kompression (MP3, 1993)
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg cover](./assets/spectogram-chet-baker.png)

<!--

"Wenn CDs eine Sample Rate von 44kHz haben, was fällt dann hier auf?"

Fangfrage: "Wie hoch ist die Sample Rate von Vinyls?" -> *Vinyl has no sample rate. It's analog!*

-->

---
	
# Was ist Sample Rate?
**Analog → Digital ≙ Kontinuierlich → Diskret**
```
      Analog (Vinyl):          Digital (CD):
      ~~~~~~~~~~~~~~~          • • • • • • • •
      Kontinuierliche          44.100 Messpunkte
      Wellenform               pro Sekunde
```
**Nyquist-Theorem:**

> Um eine Frequenz zu rekonstruieren, braucht man mindestens **2× so viele Samples**.
44.100 Hz ÷ 2 = **22.050 Hz** max. darstellbare Frequenz
(Mensch hört: ~20 Hz bis ~20.000 Hz → passt!)

<!--
SAMPLE RATE = Wie oft "fotografieren" wir die Schallwelle?
Stellt euch vor: Schallwelle = fahrendes Auto
- Analog: Videokamera läuft durchgehend
- Digital: Fotokamera macht 44.100 Fotos pro Sekunde

VINYL hat KEINE Sample Rate:
- Rille ist physische Kopie der Welle
- "Unendliche Auflösung" in der Theorie
- ABER: Rauschen, Kratzer, Nadelmasse = eigene Limits
- Praktisch: ~20 Hz bis ~20 kHz, 60-70 dB Dynamik

WARUM genau 44.100 Hz?
- Nyquist: 2× höchste hörbare Frequenz nötig
- 20.000 Hz × 2 = 40.000 Hz Minimum
- 44.100 = etwas Puffer + passte zu Video-Equipment der 80er

DAS SPEKTROGRAMM zeigt es:
- Alles über ~22 kHz ist abgeschnitten
- Das ist kein Bug, das ist das Design!
- Vinyl hätte dort noch Obertöne (die wir eh nicht hören)
-->

---

<!-- _class: lead -->

# Kompression
## Weniger Daten, gleiche(?) Information

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/compression-types.png)

<!--
Lossless vs. Lossy Kompression
Visualisierung der beiden Philosophien
-->

---

# Sample Rate vs. Bit Depth

**Zwei Dimensionen der Digitalisierung:**

| Dimension | Was bedeutet es? | CD-Qualität |
|-----------|------------------|-------------|
| **Sample Rate** | Messungen pro Sekunde (horizontal) | 44.100 Hz |
| **Bit Depth** | Genauigkeit pro Messung (vertikal) | 16 Bit |

**16 Bit = 2¹⁶ = 65.536 Lautstärkestufen**
(von absoluter Stille bis maximaler Lautstärke)

<!--
Analogie: Digitalisierung = Raster über Schallwelle legen

HORIZONTAL (Sample Rate):
- Wie oft messen wir pro Sekunde?
- 44.100 Hz = 44.100 Messpunkte pro Sekunde
- Bestimmt, welche FREQUENZEN wir erfassen können
- Nyquist-Theorem: Sample Rate ≥ 2× höchste Frequenz
- 44.100 Hz → max. ~22.050 Hz (Mensch hört bis ~20.000 Hz)

VERTIKAL (Bit Depth):
- Wie genau messen wir jeden Punkt?
- 16 Bit = 65.536 mögliche Werte (-32.768 bis +32.767)
- Bestimmt den DYNAMIKUMFANG (leise bis laut)
- 16 Bit ≈ 96 dB Dynamik (Flüstern bis Rockkonzert)
- Mehr Bits = feinere Abstufungen = weniger Quantisierungsrauschen

KOMPRESSION nutzt beide Achsen:
- Sample Rate reduzieren = weniger Punkte horizontal (spart Daten, verliert hohe Frequenzen)
- Bit Depth reduzieren = gröbere Stufen vertikal (spart Daten, mehr Rauschen)
- MP3: Wirft unhörbare Frequenzen weg + quantisiert grober wo es nicht auffällt
-->

---

<!-- _class: klausur -->
<!-- _footer: '' -->

# Verlustfrei vs. Verlustbehaftet

| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
|---|---|---|
| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Daten unwiederbringlich weg) |
| **Reduktion** | 30-50% | 80-99% |
| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |

**Faustregel:** Code/Archiv → verlustfrei · Medien → verlustbehaftet

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

---

# Verlustfrei: Lauflängenkodierung (RLE)

**Original:** `AAAAABBBCCCCCCCC` (16 Zeichen)

**Komprimiert:** `5A3B8C` (6 Zeichen) → **62% kleiner**

**Prinzip:** Wiederholungen zählen statt wiederholen

<!--
RLE = Run-Length Encoding = Lauflängenkodierung
Einfachster Kompressionsalgorithmus
Gut für: Fax, einfache Grafiken, Icons
Schlecht für: Fotos, Audio (zu chaotisch)
-->

---

# Verlustbehaftet: Der Trick

**Kernidee:** Entferne, was Menschen nicht wahrnehmen

| Format | Nutzt Schwächen von... | Fachbegriff |
|--------|------------------------|-------------|
| **JPEG** | Auge (Farbe < Helligkeit) | Psychovisuell |
| **MP3** | Ohr (Maskierungseffekte) | Psychoakustik |

<!--
PSYCHOVISUELL (JPEG):
- Auge nimmt Helligkeit besser wahr als Farbe
- Große Flächen besser als feine Details
- Daher: Farbinformation stärker komprimiert

PSYCHOAKUSTIK (MP3):
- Mittlere Frequenzen besser als hohe/tiefe
- Laute Töne "maskieren" leise Töne in der Nähe
- Auditory Masking: Lauter 1000 Hz-Ton → leise 950 Hz unhörbar

KERNKONZEPT: Kompression = Modell der menschlichen Wahrnehmung
-->

---

![bg right:40%](./assets/karlheinz-brandenburg.jpg)

# Karlheinz Brandenburg

**"Vater der MP3"**

* Diplom-Ingenieur, Universität Erlangen-Nürnberg
* Fraunhofer IIS (Institut für Integrierte Schaltungen)
* Forschung ab 1982, Patent 1988
* Hörte "Tom's Diner" über 10.000 Mal

<!--
Fraunhofer IIS Erlangen
Forschung dauerte über 10 Jahre
Perfektionist: Jeder Hörtest musste bestehen
-->

---

# Die Geburt der MP3

**1982:** Universität Erlangen-Nürnberg
Karlheinz Brandenburg, Diplom-Ingenieur

**1987:** Fraunhofer IIS entwickelt MPEG-1 Audio Layer III

**1988:** Patentanmeldung

**1992:** Erste Software-Implementierung

**1995:** .mp3 Dateiendung offiziell

<!-- 
MPEG = Moving Picture Experts Group
Layer III = Dritte Verfeinerungsstufe
Forschung dauerte 10 Jahre
Patent lief 2017 aus
-->

---

![bg right:50%](./assets/suzanne-vega.jpg)

# Suzanne Vega

**"Tom's Diner" (1987)**

- A cappella (keine Instrumente)
- Klare, hohe Frequenzen
- Perfekter Stresstest für Kompression
- Der erste Song, der als MP3 kodiert wurde

<!--
Suzanne Vega – "Tom's Diner" (1987)
A cappella = einfacher zu analysieren (nur Stimme)
Hohe Frequenzen = Herausforderung für Kompression
Brandenburg hörte den Song über 10.000 Mal
-->

---

# "Tom's Diner"

**Warum dieser Song?**

- A cappella (keine Instrumente)
- Suzanne Vegas Stimme ist "schwierig"
- Klare, hohe Frequenzen → Stresstest

> If I could code Suzanne Vega's voice well, I could code anything.
— Karlheinz Brandenburg

<!-- 
Brandenburg hörte Song 10.000+ Mal
A cappella = einfacher zu analysieren (nur Stimme)
Hohe Frequenzen = Herausforderung für Kompression
Perfektionismus: Jeder Hörtest musste bestehen
-->

---

# Wie funktioniert MP3?

Ein Zusammenspiel aus vielen Faktoren:

* **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

<!--
MP3-Kompression in 4 Schritten (vereinfacht):

1. FFT (Fast Fourier Transform)
   - Wandelt Schallwellen in Frequenzen um
   - Wie ein Prisma Licht in Farben zerlegt

2. Psychoakustisches Modell
   - Fragt: "Was kann ein Mensch NICHT hören?"
   - Maskierungseffekte: Lauter Ton verdeckt leisen daneben
   - Hohe/tiefe Frequenzen werden schlechter wahrgenommen

3. Quantisierung (hier passiert der Datenverlust!)
   - Unwichtige Frequenzen werden "grob" gespeichert
   - Wichtige Frequenzen bleiben genau
   - Wie JPEG: Details entfernen, wo es nicht auffällt (Kontrast/Helligkeit bleibt)

4. Huffman-Coding (verlustfrei)
   - Häufige Muster = kurze Codes
   - Seltene Muster = lange Codes
   - Finaler Effizienz-Boost

MP3 ist KEIN einfaches "Kleiner machen"
→ Es simuliert, wie dein Gehirn Musik verarbeitet!
-->

---

# Bitrate: Der Qualitäts-Knopf

| Bitrate | Qualität | Kompression |
|---------|----------|-------------|
| **128 kbps** | Hörbar schlechter | ~11x |
| **192 kbps** | Akzeptabel | ~7x |
| **256 kbps** | Gut | ~5,5x |
| **320 kbps** | "CD-Qualität" | ~4,4x |

**Original CD:** 1.411 kbps (unkomprimiert)

<!-- 
kbps = Kilobit pro Sekunde
128 kbps = Standard in 2000ern (Napster-Ära)
320 kbps = Maximum für MP3
Höhere Bitrate = mehr Daten = bessere Qualität
Aber: Diminishing Returns ab 256 kbps
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #000 -->

![bg fit](./assets/audio-spectrogram.png)

<!--
Spektrogramm-Vergleich
Original vs. 320 kbps vs. 128 kbps
Hohe Frequenzen verschwinden bei niedriger Bitrate
Visuell: Dunkle Bereiche = fehlende Frequenzen
-->

---

# Der Patentkrieg

**1990er:** Fraunhofer + Thomson halten MP3-Patente

**Lizenzgebühren:**
- $0,75 pro Decoder
- $2,50 pro Encoder

**Problem:** Napster (1999) → unkontrollierte Verbreitung

**2017:** Patente laufen aus → MP3 ist frei

<!-- 
Fraunhofer verklagte Winamp, andere Tools
Millionen nutzten unlizenzierte Software
Das Pferd war aus dem Stall
2017: Fraunhofer selbst erklärte MP3 für "veraltet" (AAC besser)
-->

---

![bg right:50% fit](./assets/napster-interface.png)

# Napster (1999)

**P2P-Filesharing für MP3s**

- Shawn Fanning, 19 Jahre alt
- 80 Millionen User in 2 Jahren
- Musikindustrie verklagt (2001)
- Pandora's Box: Nicht mehr aufzuhalten

<!--
P2P = Peer-to-Peer
Shawn Fanning gründete Napster als Student
RIAA verklagte Napster, Schließung 2001
Aber: LimeWire, Kazaa, BitTorrent folgten
-->

---

# Napster & Musikindustrie

**1999:** Napster startet
**2001:** 80 Millionen User

**Musikindustrie:**
- CDs kosten $15-20
- MP3s gratis (illegal, aber egal)
- Einzelne Songs statt Alben

**2001:** Napster verklagt, geschlossen

**Aber:** Pandora's Box offen
→ LimeWire, Kazaa, BitTorrent, später Spotify

<!-- 
RIAA (Recording Industry Association of America) verklagte Napster
Urteil: Napster muss schließen (2001)
Aber: Technologie nicht mehr aufzuhalten
iPod (2001): "1.000 songs in your pocket"
iTunes Store (2003): Legale Alternative
Spotify (2008): Streaming-Ära beginnt
-->

---

# Kulturelle Revolution

**MP3 veränderte:**

✓ Musik wurde portabel (Walkman → iPod)
✓ Alben wurden irrelevant (Playlists)
✓ Musikkonsum explodierte (kostenlos/billig)
✓ Künstler verloren Kontrolle

**Aber auch:**
❌ Künstler verdienen weniger pro Stream
❌ Audio-Qualität sank (Loudness War)
❌ Physische Medien starben

<!-- 
Walkman (1979): Kassetten
Discman (1984): CDs
iPod (2001): MP3s
Spotify (2008): Streaming
Künstler-Einkommen: Album-Verkauf → Streaming-Pennies
Loudness War: Alles wird lauter gemastert (Dynamik verloren)
Vinyl-Revival: 2020er Gegenbewegung
-->

---

# Hands-On: MP3 sezieren

**Aufgabe (30 Min):**

1. Lade Lied runter (eigenes oder CC)
2. Konvertiere in verschiedene Bitraten:
   - 320 kbps, 128 kbps, 64 kbps
3. Tool: **Audacity** (kostenlos)
4. Höre Unterschiede (Kopfhörer!)
5. Vergleiche Dateigrößen

**Spektrogramm:** Klick auf Track-Name → Spektrogramm
[https://manual.audacityteam.org/man/spectrogram_view.html](https://manual.audacityteam.org/man/spectrogram_view.html)

<!--
Audacity: FOSS Audio-Editor (audacityteam.org)
Export: Datei → Exportieren → MP3 → Bitrate wählen
Spektrogramm-Ansicht: Auf Track-Name klicken (Dropdown öffnet sich) → "Spektrogramm" wählen
Hohe Frequenzen (oben im Bild) verschwinden bei niedriger Bitrate
Alternative: Spek (spek.cc) – reiner Spektrogramm-Viewer
-->

---

<!-- _class: lead -->

# Fragen & Diskussion

**Kontakt:** mail@librete.ch
**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/