---
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;
}
section.erklaerung {
  font-size: 1.1rem;
  background: repeating-linear-gradient(
    135deg,
    #e3f2fd,
    #e3f2fd 40px,
    #fff 40px,
    #fff 80px
  ) !important;
}
@media print {
  section.erklaerung {
    background: #e3f2fd !important;
  }
}
section.erklaerung h1 {
  font-size: 1.5rem;
  color: #1e5f8a;
  margin-bottom: 0.3rem;
}
section.erklaerung ul,
section.erklaerung ol {
  font-size: 1.0rem;
  line-height: 1.4;
}
section.erklaerung p {
  font-size: 1.0rem;
  line-height: 1.4;
}
section.erklaerung table {
  font-size: 0.9rem;
}
</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

[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)

---

![bg fit](./assets/qrcode-1.svg)

---

<!-- _class: lead -->

# Teil 1: Einführung
## Grundlagen, Text & Audio

---

<!-- _class: lead -->

# Das Problem der Datengröße

---

# Ein konkretes Beispiel

**Eine Minute Musik in CD-Qualität:**

44.100 Messungen/Sekunde
× 16 Bit pro Messung
× 2 Kanäle (Stereo)
× 60 Sekunden

= **10,6 MB pro Minute**

<!--
Das ist die unkomprimierte Größe.
Klingt erstmal nicht dramatisch.
Aber es skaliert schnell.
-->

---

# Das Problem skaliert

| Inhalt | Unkomprimiert |
|--------|-------------:|
| 1 Song (4 Min) | ~42 MB |
| 1 Album (60 Min) | ~635 MB |
| 10.000 Songs | ~420 GB |

**Kontext 1990er:**
- Festplatte: 100-500 MB
- Modem: 56 kbit/s → 1 Song dauert Stunden

<!--
Ein Album hätte eine komplette Festplatte gefüllt.
Musik übers Internet war praktisch unmöglich.
Das Problem musste gelöst werden.
-->

---

# Video eskaliert

**Eine Minute 4K-Video (unkomprimiert):**

3840 × 2160 Pixel
× 3 Byte pro Pixel (RGB)
× 30 Bilder pro Sekunde
× 60 Sekunden

= **~45 GB pro Minute**

Ein 2-Stunden-Film: über **5 Terabyte**

<!--
Netflix, YouTube, Streaming – nichts davon wäre ohne Kompression möglich.
Nicht einmal Blu-rays könnten existieren.
Die physikalische Realität erzwingt Kompression.
-->

---

# Kompressionsraten in der Praxis

| Medium | Unkomprimiert | Komprimiert | Faktor |
|--------|-------------:|------------:|-------:|
| 1 Song (4 Min) | ~42 MB | ~4 MB (MP3 320) | ~10× |
| 1 Foto (12 MP) | ~36 MB | ~3 MB (JPEG) | ~12× |
| 1 Min 4K-Video | ~45 GB | ~375 MB (H.264) | ~120× |

<!--
Diese Faktoren sind keine Ausnahmen, sondern die Norm.
Ohne diese Kompression wäre die digitale Medienwelt, wie wir sie kennen, nicht existent.
Die Frage ist nicht ob, sondern wie komprimiert wird.
-->

---

<!-- _class: lead -->

# Zwei Philosophien der Kompression

<!--

Was ist überhaupt KOMPRESSION?

- Luftdruck in Auto/Fahrradreifen
- LNG Flüssiggas
- Tripsdrill, Disneyland
- Oper/Theater/Telenovela
- Cola Sirup für den Sodastream

-->

---

# Verlustfreie Kompression (Lossless)

**Prinzip:** Redundanz entfernen

**Beispiel Lauflängenkodierung:**
```
Original:    AAAAABBBCCCCCCCC (16 Zeichen)
Komprimiert: 5A3B8C            (6 Zeichen)
```

→ 62% kleiner, 100% wiederherstellbar

**Anwendung:** ZIP, PNG, FLAC, Programmcode

<!--
Run-Length Encoding (RLE) ist die einfachste Form.
Das Prinzip: Muster erkennen, kompakter darstellen.
Funktioniert gut bei strukturierten Daten.
Bei "chaotischen" Daten wie Fotos weniger effektiv.
-->

---

# Verlustbehaftete Kompression (Lossy)

**Prinzip:** Irrelevanz entfernen

**Die Frage:** Was nimmt ein Mensch nicht wahr?

- Das Ohr hört nicht alle Frequenzen gleich gut
- Das Auge sieht nicht alle Farbnuancen
- Laute Töne überdecken leise Töne

→ Warum Daten speichern, die niemand wahrnimmt?

<!--
Das ist die zentrale Idee hinter MP3, JPEG, H.264.
Nicht die Daten selbst reduzieren – das wäre Qualitätsverlust.
Sondern gezielt das entfernen, was Menschen nicht wahrnehmen.
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

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

---

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

# Kompression – Vertiefung

Claude Shannon definierte 1948 die **Entropie** als theoretische Untergrenze der Kompression. Ein Text mit gleichmäßiger Zeichenverteilung hat hohe Entropie (schwer komprimierbar); repetitive Texte haben niedrige Entropie.

**Verlustfreie Kompression** erreicht diese Grenze durch:
- **Statistische Kodierung:** Huffman, Arithmetic Coding
- **Wörterbuch-Methoden:** LZ77, LZ78, DEFLATE (ZIP, PNG)
- Originalzustand ist exakt rekonstruierbar

**Verlustbehaftete Kompression** unterschreitet die Grenze, indem sie menschliche Wahrnehmungsgrenzen ausnutzt:

| Sinneskanal | Psychophysisches Modell | Ausnutzung |
|-------------|------------------------|------------|
| Gehör | Maskierungseffekte, Hörschwelle | MP3: Töne unter Maskierungsschwelle weglassen |
| Sehen | Farbauflösung, Kontrastempfindlichkeit | JPEG: Chroma-Subsampling, hohe Frequenzen verwerfen |

**Shannon-Limit:** Verlustfreie Kompression kann nicht unter die Entropie; verlustbehaftete kann beliebig weit gehen – auf Kosten der Qualität.

---

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

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

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

---


<!-- _class: lead -->

# Die Grundbausteine
## Bits, Bytes und ihre Darstellung

---

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

<!--

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

---

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

<!--
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 FF` = Blau
`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 (8 Bit)

**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!)
- 1.112.064 gültige Zeichen
- 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:** `"Hello·🌸·こんにちは·(Kon-ni-chi-wa)"`

| Zeichen | Bytes |
|---------|-------|
| `Hello·` | 6 × 1 = **6 Bytes** (ASCII) |
| `🌸` | **4 Bytes** (Emoji) |
| `·` | **1 Byte** |
| `こんにちは` | 5 × 3 = **15 Bytes** (Hiragana) |
| `·(Kon-ni-chi-wa)` | **16 Bytes** (ASCII) |

**Gesamt: 42 Bytes** für 29 sichtbare Zeichen

<!--
ASCII (Hello, Klammern) = 1 Byte pro Zeichen
Emoji 🌸 (Cherry Blossom U+1F338) = 4 Bytes
Hiragana こんにちは = 3 Bytes pro Zeichen (U+3040-309F)
Hinweis: は wird hier "wa" ausgesprochen (Partikel), nicht "ha"
-->

---

<!-- _class: lead -->

# Hexadezimal
## Die Sprache der Datei-Analyse

---

# Hexadezimal: Lesbarkeit

**Binär ist unleserlich:**
`01010000 01001110 01000111`

**Hexadezimal (Base 16):**
`50 4E 47` (= "PNG" 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

-->

---



<!-- _class: lead -->

# ASCII
## One *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/ascii-table-colored.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?"

-->

---

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

---

![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: '' -->
<!-- _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
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

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

---

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

# Dateneinheiten – Vertiefung

Zwei konkurrierende Standards existieren seit der IEC-Normierung 1998:

| Präfix | SI (Dezimal) | IEC (Binär) | Differenz |
|--------|--------------|-------------|-----------|
| Kilo | 1.000 (10³) | 1.024 (2¹⁰) KiB | 2,4% |
| Mega | 1.000.000 (10⁶) | 1.048.576 MiB | 4,9% |
| Giga | 10⁹ | 2³⁰ GiB | 7,4% |
| Tera | 10¹² | 2⁴⁰ TiB | 10% |

**Warum der Unterschied wächst:** (2¹⁰)ⁿ ÷ (10³)ⁿ = 1,024ⁿ. Bei Terabyte sind es bereits 10% Abweichung.

**Festplatten-Marketing:** Hersteller nutzen SI (dezimal), Betriebssysteme zeigen IEC (binär). Eine „1 TB"-Festplatte zeigt daher nur 931 GiB an – technisch korrekt, aber verwirrend.

**Historischer Kontext:** RAM wurde immer binär gemessen (2ⁿ Adressen), Festplatten ursprünglich dezimal (physikalische Geometrie). Die IEC führte 1998 KiB/MiB/GiB ein – diese Notation setzt sich langsam durch.

---

# 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 -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

# 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

-->

---

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

# Digitaler Wendepunkt – Vertiefung

Die Studie von Hilbert & López (Science, 2011) analysierte 60 Speichertechnologien von 1986–2007. Der Wendepunkt 2002 markiert den Moment, ab dem mehr Information digital als analog existierte.

**Was 1986 „analog" bedeutete:**
- Bücher, Zeitungen, Magazine: ~8 EB
- Vinyl-Schallplatten, Musikkassetten: ~12 EB
- VHS-Kassetten, Filmrollen: ~60 EB

**Warum analog stagnierte:** Physische Medien haben Kapazitätsgrenzen. Eine VHS speichert 10 GB; eine Blu-ray (2006) bereits 50 GB auf kleinerer Fläche.

**LTO-Magnetband überlebt** trotz „alter" Technologie:
| Medium | Kosten/TB | Lebensdauer | Energiebedarf |
|--------|-----------|-------------|---------------|
| SSD | ~50 € | 5–10 Jahre | Dauerstrom |
| HDD | ~15 € | 3–5 Jahre aktiv | Dauerstrom |
| LTO-9 | ~5 € | 30+ Jahre | Nur beim Zugriff |

AWS Glacier, Google Coldline und Film-Archive nutzen LTO – langsamer Zugriff, aber unschlagbar günstig und langlebig.

---

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


![bg fit](./assets/2011-hilbert.png)


---

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

---


<!-- _header: '' -->
<!-- _footer: 'Floridi, L.: The forth Revolution' -->


![bg fit](./assets/growth of big data.png)

---

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

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

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

# 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

---

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

# Analoge Medien – Vertiefung

Analoge Speicherung codiert Information als **kontinuierliche physikalische Größe**: Rillentiefe (Vinyl), Magnetfeldstärke (Tonband), Silberkorn-Dichte (Film). Es gibt keine diskreten Stufen – theoretisch unendliche Auflösung, praktisch begrenzt durch Rauschen.

**Generationsverlust** entsteht, weil jede Kopie neues Rauschen addiert:
- Schallplatte → Kassette: Frequenzgang leidet, Rauschen steigt
- VHS → VHS: Farbsättigung sinkt, Schärfe nimmt ab
- 3. Generation: oft unbrauchbar

| Medium | Typische Auflösung | Dynamik |
|--------|-------------------|---------|
| Vinyl (audiophil) | ~20–20.000 Hz | ~70 dB |
| Tonband (Studio) | ~30–15.000 Hz | ~55 dB |
| 35mm Film | ~4K-äquivalent | ~13 Blendenstufen |

**Paradox der Analogtechnik:** Das Original ist einzigartig und unersetzlich – aber genau deshalb anfällig. Jedes Abspielen einer Schallplatte trägt mikroskopisch Material ab; jeder Filmdurchlauf riskiert Kratzer.

---

# Analoge Medien: Vor- und Nachteile

| Vorteile | Nachteile |
|----------|-----------|
| Kein Abspielgerät nötig (Buch, Foto) | Qualitätsverlust bei jeder Kopie |
| Haptisches Erlebnis | Physischer Verschleiß |
| Unabhängig von Strom/Internet | Begrenzte Haltbarkeit |
| Keine Formatkonvertierung | Platzbedarf bei Lagerung |
| Eindeutiges Original | Aufwendige Durchsuchbarkeit |

<!--
GENERATIONSVERLUST:
Kassette → Kassette = jede Kopie schlechter
VHS → VHS = Rauschen nimmt zu
Schallplatte: Jedes Abspielen = minimaler Verschleiß

ABER: Analoges Original bleibt "das Original"
Digitale Kopie = identisch mit Original (kein Unterschied!)
-->

---

# Von Analog zu Digital: Die Kopier-Revolution

**Das Problem analoger Kopien:**
Kassette → Kassette → Kassette = immer schlechter

**Was Digital anders macht:**
- **Identische Kopien** – kein Qualitätsverlust, nie
- **Einfache Massenproduktion** – Copy & Paste
- **Perfekte Archivierung** – Bits verändern sich nicht

**Daher: "Raubkopien"**
Der Begriff entstand, weil digitale Kopien *tatsächlich identisch* mit dem Original waren – nicht wie bei Kassetten eine schlechtere Version.

<small>Quelle: [c64-wiki.de/wiki/Raubkopie](https://www.c64-wiki.de/wiki/Raubkopie)</small>

<!--
RAUBKOPIE: Begriff aus der Musikindustrie
Analog: Kopie war immer erkennbar schlechter
Digital: Kopie = Original (bit-identisch)
Das machte der Industrie Angst → "Raub"

Paradox: Gerade die Perfektion wurde zum "Problem"
-->

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

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

---

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

# Digitale Medien – Vertiefung

Digitale Speicherung quantisiert kontinuierliche Signale in diskrete Werte. Der **Quantisierungsfehler** (Differenz zum Original) ist der Preis der Digitalisierung – aber einmal digitalisiert, bleibt die Information exakt.

**Bit-identische Kopien** revolutionierten die Medienindustrie:
- Keine Qualitätskette mehr: 1000. Kopie = 1. Kopie = Original
- Kosten pro Kopie: praktisch null (nur Speicherplatz)
- Perfekte Archivierung: Bits altern nicht (nur der Datenträger)

| Aspekt | Analog | Digital |
|--------|--------|---------|
| Kopiervorgang | Physikalischer Prozess | Bit-Kopie |
| Qualität pro Generation | Verschlechtert | Identisch |
| Fehlerkorrektur | Unmöglich | Möglich (ECC, RAID) |
| Formatmigration | Verlust | Verlustfrei möglich |

**Die Kehrseite:** Digitale Obsoleszenz. Ein DOCX von 2025 ist in 50 Jahren womöglich unlesbar – während ein Buch von 1525 heute noch lesbar ist. Offene Formate (PDF/A, FLAC, PNG) mildern dieses Risiko.

---

<!-- _class: klausur -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #e3f2fd -->

# 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

---

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

# Digitale Speichermedien – Vertiefung

Jede Technologie hat physikalische Vor- und Nachteile:

**Optisch (CD/DVD/Blu-ray):** Laser liest Pits (Vertiefungen) und Lands (Erhöhungen). Robust gegen Magnetfelder, aber empfindlich gegenüber Kratzern und UV-Licht. M-DISC verspricht 1000 Jahre – unter Laborbedingungen.

**Magnetisch (HDD/LTO):** Magnetisierte Bereiche auf rotierenden Platten oder Band. HDDs haben bewegliche Teile (Verschleiß); LTO-Bänder sind passiv und extrem langlebig, aber sequentieller Zugriff.

**Flash (SSD/USB/SD):** Elektronen in Floating Gates speichern Bits. Keine beweglichen Teile, aber begrenzte Schreibzyklen (TLC: ~3.000, SLC: ~100.000). Ohne Strom verlieren Zellen nach Jahren ihre Ladung.

| Szenario | Empfehlung | Grund |
|----------|------------|-------|
| Betriebssystem | NVMe SSD | Geschwindigkeit |
| Videoarchiv | HDD | Kapazität/Preis |
| Langzeitarchiv | LTO + M-DISC | Lebensdauer |
| Austausch | USB/SD | Portabilität |

**Cloud** ist physisch HDD/SSD/LTO in Rechenzentren – kein eigenes Medium, sondern Zugriffsmethode.

---

# Das Speicherproblem der Digitalisierung


**Ziel: Analoge Schallwelle möglichst originalgetreu rekonstruieren**

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

<!-- 44100 Hz ×16 Bit × 2 ÷ 8 ÷ 1000 ÷ 1000 × 60 = 10,584 MB/Minute -->

| Inhalt | Größe | Problem (1990er) |
|--------|-------|------------------|
| 1 Song (4 Min) | ~42 MB | Ausreichend Speicher |
| 1 Album (60 Min) | ~635 MB | Gesamte Festplatte |


<!--
"Springen wir nochmal zurück in die 90er, bevor das Internet den Globus umspann ..."

CD-QUALITÄT ERKLÄRT:
ZIEL: Die analoge Schallwelle möglichst originalgetreu digital rekonstruieren.
Dafür brauchen wir genug "Messpunkte" (Samples) und genug Genauigkeit (Bits).

- 44.100 Hz = Sample Rate (Abtastrate)
  → 44.100 Messungen pro Sekunde
  → Nyquist-Theorem: 2× höchste hörbare Frequenz (22 kHz)
- 16 Bit = Bit Depth (Auflösung pro Sample)
  → 65.536 mögliche Lautstärkestufen
  → Dynamikumfang: ~96 dB
- 2 Kanäle = Stereo (links + rechts)

RECHNUNG:
44.100 × 16 × 2 = 1.411.200 Bit/Sekunde
= 176.400 Byte/Sekunde = ~172 KB/s
= ~10,3 MB/Minute (gerundet 10,6 MB)

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

-->

---

# Die Abtastrate (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!)

<!--
ABTASTRATE (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)
-->

---

# Die Bittiefe (Bit Depth)

**Wie genau messen wir jeden Punkt?**

| Bittiefe | Stufen | Dynamikumfang |
|----------|--------|---------------|
| 8 Bit | 256 | ~48 dB |
| 16 Bit (CD) | 65.536 | ~96 dB |
| 24 Bit (Studio) | 16.777.216 | ~144 dB |

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

<!--
BITTIEFE = Wie genau messen wir jeden einzelnen Punkt?
- Mehr Bits = feinere Abstufungen
- 16 Bit reicht für menschliches Hören (96 dB Dynamik)
- 24 Bit im Studio: mehr Headroom für Bearbeitung
-->

---

# Abtastrate (Sample Rate) × Bittiefe (Bit Depth)

**Zwei Dimensionen der Digitalisierung:**

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

**44.100 Hz × 16 Bit** × 2 Kanäle = 10,584 MB/Minute

<!--
Analogie: Digitalisierung = Raster über Schallwelle legen
HORIZONTAL (Abtastrate): Welche FREQUENZEN wir erfassen können
VERTIKAL (Bittiefe): DYNAMIKUMFANG (leise bis laut)
-->

---

<!-- _class: lead -->

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

---

# Wo liegt der Hebel für Kompression?

**CD-Qualität:** 44.100 Hz × 16 Bit × 2 Kanäle = **10,6 MB/Min**
**MP3 (128 kbps):** = **~1 MB/Min** (Faktor 10!)

**Container-Parameter (das Raster):**

| Parameter | Reduzieren → | Konsequenz |
|-----------|--------------|------------|
| Abtastrate | Weniger Messpunkte/Sek | Max. Frequenz sinkt |
| Bittiefe | Weniger Lautstärkestufen | Mehr Rauschen |
| Kanäle | Mono statt Stereo | Kein Raumklang |

<!--
CONTAINER-PARAMETER:
Container-Parameter bestimmen das "Raster" - wie viele Messpunkte, wie genau, wie viele Kanäle.
Wenn man diese reduziert, verliert man Qualität auf technischer Ebene.

BEISPIEL Abtastrate:
- Abtastrate 22 kHz → ALLES über 11 kHz ist physisch unmöglich zu speichern
- Das ist ein "harter" Schnitt - alles darüber ist weg
-->

---

# Psychoakustik: Der MP3-Trick

**Inhalt (was durchs Raster geht):**

| Methode | Reduzieren → | Konsequenz |
|---------|--------------|------------|
| Psychoakustik | Unhörbare Frequenzen | Kaum wahrnehmbar |

→ **MP3 nutzt hauptsächlich Psychoakustik**
→ Container bleibt ähnlich, Inhalt wird "ausgedünnt"

<!--
Psychoakustik arbeitet anders als Container-Parameter:
- Der Container (44.1 kHz, 16 Bit, Stereo) kann gleich bleiben
- Aber der INHALT wird "ausgedünnt" - nur das was wir hören können bleibt
- Das ist der Trick von MP3: Nicht das Raster verkleinern, sondern intelligent weglassen

BEISPIEL Abtastrate vs. Psychoakustik:
- Abtastrate 22 kHz → ALLES über 11 kHz ist physisch unmöglich zu speichern
- Psychoakustik bei 44.1 kHz → 0-22 kHz möglich, aber maskierte Frequenzen werden entfernt

MASKIERUNG:
- Frequenzmaskierung: Lauter Ton bei 1 kHz "überdeckt" leise Töne bei 1.1 kHz
- Zeitliche Maskierung: Kurz vor/nach lautem Ton hören wir leise Töne nicht
- Absolute Hörschwelle: Sehr leise Töne hören wir generell nicht

WARUM funktioniert MP3 so gut?
- Unser Gehör ist kein lineares Messgerät
- Wir hören nicht alle Frequenzen gleich gut
- MP3 nutzt ein Modell des menschlichen Hörens
- Spart Bits dort wo wir es nicht merken
-->

---

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

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

---

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

# Suzanne Vega

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

- Der erste Song, der als MP3 kodiert wurde
- A cappella (keine Instrumente)
- Klare, hohe Frequenzen
- Perfekter Stresstest für Kompression
- Brandenburg hörte "Tom's Diner" über 10.000 Mal

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

> Wenn ich Suzanne Vegas Stimme kodieren könnte, kann ich alles kodieren.
— 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
-->

<!--
---

# Beispiel: Verlustbehaftet (lossy)

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

<!--

---


# Beispiel: Verlustfrei (lossless)
### 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)
-->


---

# 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-2001.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
-->

---

![bg right:40% contain](./assets/bittorrent.png)

# Napster & Musikindustrie

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

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

**2001:** Napster wird verklagt und schließt

**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ünstlerInnen verloren Kontrolle

**Aber auch:**
❌ KünstlerInnen 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
-->

---

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

---

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

# Selbstlernen: Audio-Spektrogram

**Aufgabe (30 Min):**

- Live Spektrogram untersuchen https://borismus.github.io/spectrogram/
- Mit Effekten experimentieren https://audiomass.co/
- Spektrogramme vergleichen Audacity (kostenloser Download nötig) [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
-->

---

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

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

# Selbstlernen: HEX Files

1. Drei Dateien ohne Dateiendung:
   <a href="../materials/wtf1"/>`hex1`</a>  <a href="../materials/wtf2"/>`hex2`</a>  <a href="../materials/wtf3"/>`hex3`</a>
3. Lies erste 16 Bytes aus und identifiziere Dateiformat (Magic Number)
5. *Optional: Datei umbenennen und korrekte Dateiendung anhängen (bspw. `.jpg`)*

**Tools:**
- Hex-Editor: [hexed.it](https://hexed.it)
- Magic Numbers: [en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures)

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