uni/slides/223015b/01-grundlagen-text-audio.md

---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
---

<style>
:root {
  --color-foreground: #1a1a2e;
  --color-highlight: #1e5f8a;
  --color-dimmed: #4a4a6a;
}
section.invert {
  --color-foreground: #fff;
}
section {
  font-size: 1.7rem;
}
h1 {
  color: #1e5f8a;
}
section.invert h1 {
  color: #fff;
}
h2 {
  color: #1f2937;
}
pre {
  background: #0f0f23;
  color: #5fb3e4;
  border-radius: 8px;
  border-left: 3px solid #1e5f8a;
}
pre code {
  background: transparent;
  color: inherit;
}
code {
  background: #0f0f23;
  padding: 0.15em 0.4em;
  border-radius: 4px;
  font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
}
section code:not(.hljs) { color: #5fb3e4 !important; }
section code.hljs { color: #f8f8f8 !important; }
a {
  color: var(--color-highlight);
}
section.klausur {
  background: repeating-linear-gradient(
    135deg,
    #e3f2fd,
    #e3f2fd 40px,
    #fff 40px,
    #fff 80px
  ) !important;
}
@media print {
  section.klausur {
    background: #e3f2fd !important;
  }
}
section.aufgabe {
  background: #e3f2fd !important;
}
section.aufgabe footer {
  display: none;
}
section.erklaerung :not(header),
section.erklaerung :not(footer)
{
  font-size: 1.1rem;
}
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 -->

# Kapitel 1
## Datenfundamentale + Vom Signal zum Byte

<!--
Eine Stunde, eine Frage: *Was steckt in einer Datei — und wie kommt es da rein?*

Roter Faden:
1. Foto, Sprachnachricht, PDF — drei vertraute Dinge, alle haben dasselbe Innenleben
2. Hex-Editor auf — Zahlen, nichts als Zahlen
3. Wie man die Zahlen liest (Bit/Byte/Hex als drei Schreibweisen)
4. Was die Zahlen bedeuten (ASCII → Unicode → Magic Numbers)
5. PIVOT — aber wie kommen die Zahlen überhaupt rein?
6. Sampling + Quantisierung — zwei Schritte, die jedes Signal digitalisieren
7. Nyquist als Begründung für 44,1 kHz
8. Aliasing als „was schiefgehen kann" — Audio-Knack und Moiré als gleiches Phänomen

Das Kapitel hat zwei Strangs, die sich an der Mitte (= Byte) treffen.
-->

---

<!-- _class: lead -->

# Was steckt eigentlich in einer Datei?

<!--
Beispiele aus dem Alltag der Studis:
- Foto auf dem Smartphone
- Sprachnachricht in WhatsApp
- PDF im Studi-Mailfach

Frage: Wenn wir die alle aufmachen würden — was würden wir sehen? Was haben die *gemeinsam*?

Antwort kommt auf der nächsten Folie.
-->

---

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

![bg fit](./assets/demos/drei-dateien.png)

<!--
Aufdeckung: Foto · Sprachnachricht · PDF sehen außen ganz verschieden aus. Aber wenn man den ersten Byte-Block anschaut: alle haben eine Visitenkarte (Magic Number) und bestehen ab da nur aus Byte.

- Foto: 89 50 4E 47 = PNG
- Sprachnachricht: 49 44 33 = ID3 (MP3-Tag)
- PDF: 25 50 44 46 = %PDF

Aussage: Außen verschieden, innen dieselbe Sprache. Egal ob Bild, Ton oder Dokument — eine Datei ist immer eine Folge von Byte.

Was ein Byte ist und wie man es liest — kommt in den nächsten Folien.
-->

---

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

<!--
Schock-Hook: das hier ist eine PNG-Datei. So sieht sie wirklich aus, wenn man sie im Hex-Editor öffnet.

Studis sollen sich kurz wundern: das ist ein Bild? Es sieht aus wie Matrix-Code.

Auflösung kommt Stück für Stück.

Tool, das Studis benutzen können: hexed.it (Browser, kein Install).
-->

---

# Eine Datei ist ein Byte-Strom

**Vorne nach hinten. Ein Byte nach dem anderen.**

Egal welches Format — die Datei beginnt mit Byte 1 und endet irgendwann.

Jedes Byte ist eine Zahl zwischen `0` und `255`. *Mehr ist da nicht.*

<!--
Mentales Bild: Datei = Lokomotive aus Waggons. Jeder Waggon = 1 Byte = 1 Zahl 0..255.

- Festplatte/SSD: speichert byteweise
- Speicher (RAM): liest byteweise
- CPU: adressiert byteweise (siehe nächste Folie)

Wichtig: Es gibt keine "halben Byte" auf der Hardware. Die kleinste Adresse ist immer ein Byte. Bit gibts logisch, aber nicht physisch adressierbar.
-->

---

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

![bg fit](./assets/demos/why-8-bit.png)

<!--
Warum gerade 8 Bit (nicht 7, nicht 16)?
- CPU adressiert byteweise — kleinste adressierbare Einheit
- 8 Bit = 2 Hex-Ziffern (elegante Darstellung)
- 1964: IBM System/360 setzte den 8-Bit-Standard
- Vorher: 6-Bit + 7-Bit-Systeme parallel im Einsatz
- 1 Bit = 2 Zustände, 2 Bit = 4, ... 8 Bit = 256

Eselsbrücke: 2 hoch (Anzahl Bit) = Anzahl Zustände.
-->

---

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

![bg fit](./assets/demos/byte-fuer-byte.png)

<!--
Drei Schreibweisen, ein Inhalt:
- Fenster 1 (Bin): rohe 0/1 — was tatsächlich auf der Platte steht
- Fenster 2 (Hex): 2 Ziffern pro Byte — kompakt lesbar (1 Byte = 2 Hex-Ziffern)
- Fenster 3 (Text): ASCII-Zeichen wenn Byte ≤ 126, sonst ✗

Daraus folgt eine Klausurfrage: schon ein Byte > 126 → Binärdatei (PNG, MP3, ZIP).
Nur Werte ≤ 126 → reine Textdatei (.txt, .csv, .md).

In diesem Kapitel reden wir nicht (nur) über die ROHEN Byte. Wir reden über die drei Brillen, mit denen man dieselben Byte anschauen kann.
-->

---

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

![bg fit](./assets/demos/byte-nibble-hex.png)

<!--
Kernidee: jedes Byte lässt sich sauber in zwei 4-Bit-Hälften (Nibbles) zerlegen. Jede Hälfte hat 2⁴ = 16 Zustände — und genau 16 Symbole hat Hex (0–F). Deshalb passt Hex perfekt:

- 1 Nibble = 1 Hex-Ziffer
- 1 Byte = 2 Hex-Ziffern

Keine krumme Umrechnung. Hex ist die menschenfreundliche Schreibweise des Maschinenformats.
-->

---

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

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

<!--
Hex ↔ Dezimal Lookup:
- 0..9 wie gewohnt
- A = 10, B = 11, C = 12, D = 13, E = 14, F = 15

Studis müssen das nicht auswendig wissen. Aber sie sollen erkennen: Hex ist nicht Magic — es ist eine Schreibweise mit 16 Symbolen statt 10.
-->

---

# 01010000 oder 50 — was liest sich leichter?

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

**Hex:** `50 4E 47`

Drei Byte. Dasselbe Inhalt. Hex ist nur **handlicher**.

**Wo trifft man Hex im Alltag?** Beim CSS-Farbcode:
`#FF5733` — das sind 3 Byte (Rot, Grün, Blau).

<!--
Anker im Alltag: CSS-Farbe `#FF5733`. Jede:r hat das mal gesehen — im Designtool, in der dev console, beim Theme-Eintippen.

Auflösung:
- #FF = 255 = Rot voll
- #57 = 87 = Grün mittel
- #33 = 51 = Blau wenig
- Ergibt ein warmes Orange.

Klausurrelevant: wenn jemand sagt "lila ist B399FF", können wir die drei Byte sofort als RGB lesen.
-->

---

<!-- _class: klausur -->

# Hex begegnet euch überall

| Kontext | Beispiel |
|---------|----------|
| CSS-Farben | `#FF5733` |
| MAC-Adressen | `00:1A:2B:3C:4D:5E` |
| Speicheradressen | `0xA04F20` |
| Windows-Fehlercodes | `0x80070005` |
| Unicode-Codepoints | `U+00E4` (ä) |
| Datei-Signaturen | `89 50 4E 47` (PNG) |

<!--
Präfixe:
- `0x` = "das ist Hex" (in C, JS, Python)
- `U+` = Unicode-Codepoint
- `#` = CSS-Konvention

Lebensweltanker: jede:r Studi hat mindestens drei dieser Kontexte schon real gesehen. Hex ist nicht eine akademische Übung, sondern die Lesart, in der Computer mit Menschen über Byte reden.

MAC-Adresse: 6 Byte = 6 Paare Hex-Ziffern. Eindeutige Hardware-Kennung der Netzwerkkarte.
-->

---

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

![bg fit](./assets/demos/byte-flow.png)

<!--
1 Byte = 8 Bit = 2 Hex-Ziffern = max. 1 ASCII-Zeichen.

Dieselbe Datei, drei Schreibweisen — Byte für Byte parallel angezeigt.
- Jeder Rahmen = ein Byte.
- Byte ändern sich nicht, nur unsere Anzeige.
- `0x0A` = Zeilenumbruch, nicht druckbar → Hex-Editoren zeigen `.` als Platzhalter.
-->

---

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

![bg fit](./assets/demos/three-views.png)

<!--
Dieselben 8 Byte (PNG-Dateianfang: 89 50 4E 47 0D 0A 1A 0A) — drei Perspektiven:

1. Bitstream — was wirklich gespeichert wird (unleserlich)
2. Hex — gruppiert in 8-Bit-Häppchen (kompakt)
3. Bedeutung — was die Byte signalisieren:
   - 89: Magic Byte (>127 → "ich bin Binärdatei")
   - 50 4E 47: P · N · G (ASCII-Format-Kürzel)
   - 0D 0A 1A 0A: Carriage Return · Line Feed · End-of-File · Line Feed (erkennt kaputte Übertragung)

Aussage: dieselbe Datei, je nach Brille sehe ich anderes. Die Datei selbst ändert sich nicht.
-->

---

<!-- _class: lead -->

# Was bedeutet die Zahl `80`?

<!--
Strang-Wechsel: bis hier haben wir Byte als NOTATION gelernt (Bin/Hex parallele Schreibweisen). Jetzt fragen wir: was *bedeuten* die Byte?

Die Zahl 80 in einer Textdatei ist der Buchstabe „P". Das ist ASCII.

Auflösung kommt mit der ascii-Tabelle.
-->

---

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

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

<!--
US-ASCII (1967) Code Chart:
- 7 Bit = 128 Zeichen
- Erste 32 Zeichen: Steuerzeichen (nicht druckbar) — z.B. Tab, Newline, Backspace
- Zeichen 32–126: druckbar (Buchstaben, Ziffern, Satzzeichen)
- Zeichen 127: DEL
- Keine Umlaute, kein ñ, kein é, kein chinesisches Zeichen

Geschichte:
- 1963 als US-amerikanischer Standard
- 7 Bit, weil Fernschreiber 7-Bit-Codes nutzten + Paritätsbit für Fehlererkennung
- 60 Jahre alt, lebt aber weiter — siehe UTF-8 (ASCII-kompatibel)
-->

---

<!-- _class: lead -->

# ASCII reicht für Englisch.
## Aber was ist mit *ä, é, 中, 🌸*?

<!--
Bridge: ASCII löst das Problem nur für englischen Text.
Sobald Umlaute, Akzente, asiatische Schriften oder Emoji ins Spiel kommen, sprengt es den 7-Bit-Raum.

Quizfrage an die Studis: Wie viel Speicher braucht ein „ä"? Antwort: Kommt drauf an, welches Encoding. ASCII kann es gar nicht; UTF-8 braucht 2 Byte.

Lösung: Unicode + UTF-8 (nächste Folie).
-->

---

# Unicode: ein Standard für alle

**Unicode (1991):** jedes Schriftsystem der Welt.
**> 150.000 Zeichen.** Latein, Kyrillisch, Arabisch, Chinesisch, Japanisch, mathematische Symbole, Emoji.

**UTF-8** speichert Unicode mit *variabler Länge:*

- Zeichen 0–127: **1 Byte** (identisch mit ASCII — Abwärtskompatibilität!)
- Westeuropäische Umlaute: **2 Byte**
- Chinesisch/Japanisch: **3 Byte**
- Emoji: **4 Byte**

<!--
- Unicode Consortium: Non-Profit, gegründet 1991
- Unicode 16.0 (2024): 154.998 Zeichen
- UTF-8 = Unicode Transformation Format, 8-bit (Ken Thompson & Rob Pike, 1992)
- Die ersten 128 Zeichen in UTF-8 sind exakt ASCII — Grund warum ASCII nie verschwinden wird
- UTF-8 ist seit 2008 das häufigste Encoding im Web (W3Techs)

Pädagogisch wichtig: variable Länge heißt, dass „Zeichen zählen" und „Byte zählen" NICHT dasselbe sind. Das ist die Brücke zur nächsten Folie.
-->

---

<!-- _class: klausur -->

# Beispiel: Byte zählen

**Text:** `"Hello·🌸·こんにちは·(Kon-ni-chi-wa)"`

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

**Gesamt: 42 Byte für 29 sichtbare Zeichen.**

<!--
Klausurfähig: gegeben ein Text mit ASCII, Umlauten, CJK und Emoji — wie viel Byte ist das?

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

Pointe: 29 sichtbare Zeichen, 42 Byte. Zeichen ≠ Byte sobald Unicode > 127.
-->

---

<!-- _class: lead -->

# Woher weiß der Computer, was das ist?

<!--
Pivot zur dritten Bedeutungsebene: nicht „was bedeutet die Zahl 80?" (= P im ASCII), sondern „was bedeutet die *Folge* von Byte am Anfang einer Datei?".

Antwort: Magic Numbers. Die ersten paar Byte sind die Visitenkarte des Formats.

Auflösung kommt mit Magic-Numbers-Folie.
-->

---

<!-- _class: klausur -->

# Magic Numbers — die Visitenkarte der Datei

**Datei-Typ erkennt man an den ersten Byte:**

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

**Achtung:** Werte > 127 sind nicht ASCII-druckbar. *Hex-Editoren zeigen `.` als Platzhalter.*

<!--
- PNG nutzt absichtlich `89` (= 137 dezimal): markiert Datei eindeutig als Binär. Erkennt kaputte Übertragungen (alte Systeme schnitten Bit 7 ab).
- "PK" bei ZIP = Phil Katz (Erfinder von PKZip, 1989)
- DOCX, XLSX, PPTX, ODT = alles ZIP-Archive mit XML-Inhalt
- Dateien OHNE Magic Number: TXT, HTML, CSS, JSON, XML — reiner Text, kein binäres Format
- Sicherheitsrelevant: virus.exe → bild.jpg umbenennen täuscht nur Menschen; `file` (Linux) liest Magic Number und erkennt die echte Identität.
-->

---

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

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

<!--
Echte PNG-Datei im Hex-Editor.

Erste Byte: 89 50 4E 47 = PNG-Signatur.
- 89: non-printable (außerhalb ASCII)
- 50: P
- 4E: N
- 47: G
- Danach IHDR = Image Header (Breite, Höhe, Farbtiefe)

Tool: HxD (Windows), Hex Fiend (Mac), xxd (Linux), hexed.it (Browser).
-->

---

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

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

<!--
Zoom auf den Buchstaben „P":

- Hex: 50
- Dezimal: 80
- Binär: 01010000
- ASCII: P

Ein Byte. Acht Bit. Ein Buchstabe. Drei Schreibweisen.

Das ist die Brücke zwischen Notation (Hex/Bin) und Bedeutung (ASCII).
-->

---

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

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

# Selbstlernen — HEX Files identifizieren

1. Fünf Dateien ohne Dateiendung:
   <a href="https://librete.ch/hdm/223015b/materials/hex1">`hex1`</a> · <a href="https://librete.ch/hdm/223015b/materials/hex2">`hex2`</a> · <a href="https://librete.ch/hdm/223015b/materials/hex3">`hex3`</a> · <a href="https://librete.ch/hdm/223015b/materials/hex4">`hex4`</a> · <a href="https://librete.ch/hdm/223015b/materials/hex5">`hex5`</a>
2. Lies erste 16 Byte aus und identifiziere Dateiformat (Magic Number)
3. *Optional: Datei umbenennen und korrekte Dateiendung anhängen (z.B. `.jpg`)*

**Tools:** [hexed.it](https://hexed.it) · [Wikipedia-Magic-Number-Liste](https://en.wikipedia.org/wiki/List_of_file_signatures)

<!--
- hex1: Plaintext (keine Magic Number — pure ASCII)
- hex2: PNG (89 50 4E 47)
- hex3: JPEG (FF D8 FF)
- hex4: DOCX (50 4B 03 04 — ZIP-Container, XML drin)
- hex5: ZIP (50 4B 03 04)

Pädagogisch: Studis sollen selbst sehen, dass Datei-Erkennung nicht über die Endung läuft, sondern über die Byte am Anfang. Das ist eine kleine Macht-Erfahrung — sie können mit `hexed.it` etwas, das die meisten Leute nicht können.

Gruppenarbeit: 3–4 Personen. ~15 Min.
-->

---

<!-- _class: klausur -->

# KB vs KiB — warum „1 TB" als 931 GB angezeigt wird

![bg right:48% contain](./assets/demos/kb-vs-kib.png)

**Auf der Verpackung:** 1 TB = 10¹² Byte (dezimal).
**Im Finder:** 931 GB = eigentlich 931 GiB (binär, 1024³).

Es fehlt nichts — beide Seiten zählen nur in **verschiedenen Sprachen.**

<!--
- Marketing nutzt SI-Präfixe (1000³, 1000⁴) → größere Zahlen auf der Packung.
- Betriebssysteme rechnen in Zweier-Potenzen (1024³) → kleinere angezeigte Zahl, weil Bits binär organisiert sind.
- Korrekt wären `GiB` (Gibi-, binär) und `GB` (Giga-, dezimal). Realität: beide nennen es `GB`.

Rechnung: 10¹² ÷ 2³⁰ ≈ 931,3 GiB. Der Finder zeigt „931 GB".

Klausurfähig: warum zeigt eine 1-TB-SSD im Finder „931 GB"? Begründung mit Rechnung.
-->

---

<!-- _class: klausur -->

# Dateneinheiten — Größenordnungen

| Einheit | Bytes (dezimal) | Beispiel |
|---------|------:|----------|
| **Byte** | 1 | Farbwert eines Pixels |
| **Kilobyte (KB)** | 1.000 | kleiner Programmcode |
| **Megabyte (MB)** | 1 Million | Textdokument |
| **Gigabyte (GB)** | 1 Milliarde | Kinofilm in FullHD |
| **Terabyte (TB)** | 1 Billion | ~12h Video in 4K |
| **Petabyte (PB)** | 1 Billiarde | Netflix-Gesamtarchiv |
| **Exabyte (EB)** | 1 Trillion | Alle E-Mails weltweit/Tag |
| **Zettabyte (ZB)** | 1 Trilliarde | globale Datenmenge ~heute |

<!--
SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes. Auf Packungen, in Marketing.
IEC-Präfixe (Binär): 1 KiB = 1.024 Bytes (Kibibyte). In Betriebssystemen (oft ohne i geschrieben — Verwechselung!).

Eselsbrücke für die Reihenfolge:
„**K**omm **M**it **G**roßem **T**ee, **P**eter **E**xte **Z**ettelt **Y**achten."
→ Kilo, Mega, Giga, Tera, Peta, Exa, Zetta, Yotta.
-->

---

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

![bg fit](./assets/demos/pivot-signal-zu-byte.png)

<!--
PIVOT. Wir haben die rechte Seite des Bogens abgearbeitet: aus Byte wird Bedeutung (Notation, Encoding, Format). Jetzt drehen wir um: wie kommen die Byte überhaupt rein?

Beispiele:
- Wir machen ein Foto → Lichtwelle → Pixel-Byte
- Wir reden ins Mikro → Schallwelle → Audio-Byte
- Wir tippen Text → Tastendruck → ASCII-Byte (das ist die einfache Variante)

Die kontinuierliche Welt ist analog. Die Datei ist digital. Der Weg dazwischen heißt: Sampling + Quantisierung. Das schauen wir uns jetzt an, am Beispiel Audio.
-->

---

# Analog vs. Digital — am Beispiel Schall

![bg right:48% contain](./assets/druckwelle.png)

Eine Stimme ist eine **Druckwelle**. Kontinuierlich — keine Stufen, keine Sprünge.

Eine Audiodatei ist eine Folge von **Zahlen** — diskret, in Stufen.

Wie übersetzen wir die Welle in Zahlen?

**Zwei Schritte:** Sampling (wie oft) + Quantisierung (wie genau).

<!--
- Schall ist physikalisch: Luftmoleküle drücken auf das Trommelfell.
- Diese Druckschwankung folgt einer kontinuierlichen Kurve in der Zeit.
- Analog speichern (Vinyl, Tonband): die Rille / das Magnetfeld speichern die Druckkurve direkt.
- Digital speichern: wir messen die Welle in regelmäßigen Abständen (Sampling) und runden jede Messung auf eine Stufe (Quantisierung).

Beide Schritte sind notwendig. Beide haben einen Trade-off zwischen Datenrate und Genauigkeit.
-->

---

# Sampling — wie oft messen wir?

**Abtastrate** (Sample Rate) = wie viele Messungen pro Sekunde.

| Sample Rate | Anwendung |
|-------------|-----------|
| 8 kHz | Telefon |
| 22 kHz | alte Spiele-Sounds |
| **44,1 kHz** | **CD-Qualität** |
| 48 kHz | Video-Standard |
| 96 kHz | Studio |

Je höher die Sample Rate, desto näher kommt die Datei an die kontinuierliche Welle.

<!--
- 1 Hz = 1 Messung pro Sekunde
- 44.100 Hz = 44.100 Messungen pro Sekunde
- Warum genau 44,1 kHz? Kommt 5 Folien später (Nyquist).
- Telefon mit 8 kHz: alles oberhalb 4 kHz fehlt — deshalb klingen Telefongespräche „dumpf"
-->

---

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

![bg contain](./assets/samplerate.webp)

<!--
Visualisierung: eine kontinuierliche Welle wird mit unterschiedlichen Sample-Raten abgetastet. Niedrige Rate verliert Detail. Hohe Rate erfasst die Welle treu.

Konkrete Frage an Studis: bei welcher Rate erkennt man die Originalwelle noch?
-->

---

# Quantisierung — wie genau messen wir?

**Bittiefe** (Bit Depth) = wie fein wir jede Messung auflösen.

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

Je mehr Bit, desto kleiner der **Quantisierungsfehler** (Differenz zur Original-Druckwelle).

<!--
- Bittiefe sagt: wie viele verschiedene Lautstärke-Stufen kennt das Format pro Messung.
- 8 Bit = 256 Stufen: hörbar grobkörnig (Quantisierungsrauschen).
- 16 Bit = 65.536 Stufen: für menschliches Hören mehr als genug (~96 dB Dynamik = vom Flüstern bis zum Konzertsaal-Forte).
- 24 Bit im Studio: Headroom für Bearbeitung, kein hörbarer Unterschied beim Endprodukt (Meyer & Moran, JAES 2007).

Eselsbrücke: Sampling = horizontal (Zeit-Achse). Quantisierung = vertikal (Amplituden-Achse).
-->

---

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

![bg fit](./assets/quantized-image-8-colors.jpg)

<!--
Quantisierung am Bild-Beispiel: dasselbe Foto mit unterschiedlicher Farbtiefe.

- Original: 24-Bit-Farbe (16,8 Mio. Farben)
- 8-Bit-Quantisierung: nur 256 mögliche Farben → sichtbare Stufen, Posterisierung

Das ist dasselbe Phänomen wie Audio-Quantisierungsrauschen, nur in der visuellen Modalität. Wir reden über beides später nochmal (Aliasing-Folie).
-->

---

<!-- _class: klausur -->

# Datenrate = Sample Rate × Bittiefe × Kanäle

**Formel:**

```
Datenrate (bit/s) = Sample Rate (Hz) × Bittiefe (bit) × Kanäle
```

**Was bestimmt jeder Faktor?**

- **Sample Rate:** Bandbreite (Höhe der erfassbaren Töne)
- **Bittiefe:** Dynamik (Stufenfeinheit)
- **Kanäle:** Stereo, Mono, Surround

Daraus ergibt sich, wie groß eine Audiodatei pro Sekunde wird — *unkomprimiert*.

<!--
Wichtige Klausur-Formel.

Anwendungsbeispiel kommt nächste Folie (CD-Audio).

Konsequenz: wenn ich Speicher sparen will, kann ich an einem dieser drei Parametern drehen. ABER: jede Reduktion ist hörbar.

Brücke zu Kap2 (Kompression): da reduzieren wir nicht die Parameter, sondern *werfen unhörbare Information weg* — das ist Psychoakustik, nicht Container-Schrumpfung.
-->

---

<!-- _class: klausur -->

# CD-Audio: die Rechnung

**Audio-CD (Philips/Sony 1982):**

```
44.100 Hz × 16 bit × 2 Kanäle = 1.411.200 bit/s = 1,4 Mbit/s
```

Pro Sekunde: ~172 KB. Pro Minute: ~10,3 MB. Pro Album (60 Min): ~635 MB.

*Eine ganze 90er-Festplatte für ein Album.*

<!--
Diese Rechnung muss in der Klausur reproduziert werden können — Formel + Anwendung.

Historischer Kontext:
- 1982: erste CD (Billy Joel – 52nd Street, Japan)
- Festplatten der 90er: 40–500 MB → ein Album füllte die ganze Platte
- 56k-Modem: 7 KB/s → 42 MB Song ≈ 100 Minuten Download
- Daraus entstand der Druck zur Audio-Kompression — die wir in Kap 2 sehen werden

Spektrogramm-Folie als Anschluss: 44,1 kHz → wir können bis ~22 kHz erfassen. Mehr nicht. Warum genau 22 kHz? Weil Menschen bis ~20 kHz hören. Antwort kommt mit Nyquist.
-->

---

<!-- _class: klausur -->

# Nyquist-Theorem — warum 2× reicht

![bg right:50% contain](./assets/demos/nyquist-diagram.png)

**Sample-Rate muss mindestens das *Doppelte* der höchsten Signal-Frequenz sein:**

```
f_sample ≥ 2 · f_max
```

Drei Fälle:
- **zu wenig** → Aliasing (falsche tiefere Welle)
- **genau** → mathematisches Minimum
- **mehr** → sichere Rekonstruktion

<!--
Harry Nyquist (1928) + Claude Shannon (1949): Sampling-Theorem.

Beweis nicht klausurrelevant. Die Aussage und das visuelle Verständnis sind klausurrelevant.

Konsequenz:
- 44,1 kHz Sample Rate → max. 22,05 kHz erfassbare Frequenz
- Über 22 kHz wird *physisch nicht aufgenommen* (vor dem ADC sitzt ein Tiefpassfilter, der alles über 22 kHz abschneidet — anti-aliasing filter)
- Studis hören diese hohen Frequenzen sowieso nicht (~20 kHz oben)

Anschluss zur nächsten Folie: warum hat die CD genau 44,1 kHz gewählt?
-->

---

# Warum gerade 44,1 kHz?

**Menschliches Ohr hört bis ca. 20 kHz.**
2 × 20 kHz = 40 kHz minimum für Nyquist.

**Plus 4,1 kHz Sicherheitsmarge** (Tiefpassfilter sind nicht perfekt).

**Plus historische PAL/NTSC-Kompatibilität:**
44.100 Hz war exakt durch PAL- und NTSC-Video-Frame-Raten teilbar → CD-Master ließen sich auf den Video-Recordern jener Zeit produzieren.

<!--
- Das Hörvermögen sinkt ab ~16 kHz mit dem Alter (Presbyakusis)
- Tiefpassfilter im ADC braucht etwas Übergangsbreich — daher Sicherheitsmarge
- 44.100 Hz ergibt sich aus: 245 × 6 × 30 (NTSC) und 245 × 8 × 25 (PAL).
- Sony nutzte zu Beginn der CD-Entwicklung Video-Bandgeräte (Sony PCM-1600) zur digitalen Audio-Speicherung. Sample-Rate musste in NTSC + PAL-Frames passen.

Pointe für Studis: ein scheinbar willkürlicher Standard hat physiologische *und* historische Gründe. Technik-Geschichte ist kein Zufall.
-->

---

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

![bg fit](./assets/demos/aliasing-paar.png)

<!--
Aliasing als Phänomen — in Audio und Bild parallel.

- Audio: schriller 18-kHz-Ton, mit 22 kHz gesampelt → wird zu dumpfem 4-kHz-Brumm. Frequenz „klappt um".
- Bild: feines Streifenmuster, in zu niedriger Auflösung gerendert → breite Moiré-Bänder erscheinen.

Beides ist dasselbe mathematische Phänomen: Sampling zu grob → falsche niedrige Frequenz erscheint.

Lebensweltanker:
- Spotify Free 96 kbit/s → hohe Frequenzen werden weggeschnitten → kein Aliasing direkt, aber dieselbe Familie von Problemen.
- Foto-Stroboskop / Wagenrad-Effekt im Video → klassisches Aliasing in der Zeit-Dimension.
-->

---

<!-- _class: aufgabe -->

# Selbstlernen — Spotify-Bitrate vergleichen

Auf eurem Handy:
1. Spotify öffnen, *Lieblings-Track laden*
2. Audio-Qualität-Einstellung wechseln zwischen **niedrig (24 kbit/s)** und **sehr hoch (320 kbit/s)**
3. Mit Kopfhörer auf **Höhen** achten (Becken, Zischlaute, „s"-Töne in Stimme)

**Was fällt auf?** Welche Frequenzen verschwinden zuerst?

<!--
Pädagogisch: Studis sollen selbst hören, was Sample Rate / Bitrate praktisch bedeutet. Niedrige Bitrate = Tiefpassfilter hört früher auf zu übertragen → hohe Frequenzen weg → klingt „dumpf".

Spotify-Stufen (Premium):
- niedrig: 24 kbit/s
- normal: 96 kbit/s
- hoch: 160 kbit/s
- sehr hoch: 320 kbit/s

Ohne Premium: max. „normal".

Diskussion in der nächsten Vorlesungsrunde: was hat das mit MP3 zu tun? Antwort: alles. Kommt in Kap 2.
-->

---

<!-- _class: aufgabe -->

# Selbstlernen — Audacity Sample-Rate-Vergleich

1. **Audacity** installieren (kostenlos, audacityteam.org)
2. Eigene Stimme aufnehmen (5 s, irgendwas reinsprechen)
3. Datei → Exportieren als WAV bei **8 kHz**, **22 kHz**, **44,1 kHz**
4. Vergleichen: Größe der Datei + Klangqualität

**Beobachtung:** Größe wächst linear mit Sample Rate. Qualität auch.

<!--
Diese Übung kann zuhause gemacht werden. Audacity ist FOSS.

- 5 Sek Mono bei 44,1 kHz × 16 bit = ~441.000 Byte ≈ 430 KB
- Bei 8 kHz: 80.000 Byte ≈ 78 KB
- Klang: bei 8 kHz dumpf, „Telefon-Stimme"

Anschlussfrage in der nächsten Folie: kann man eine Datei *kleiner* machen, ohne Sample Rate / Bittiefe zu reduzieren? Antwort: ja — durch Kompression. Das ist Kap 2.
-->

---

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

![bg fit](./assets/demos/summary-organizer.png)

<!--
Zusammenfassung des Kapitels mit dem Bogen als rotem Faden.

Beide Strangs sind jetzt durch:
- WELT → BYTE (links, pink): Sampling-Rate, Bittiefe + Quantisierung, Datenrate-Formel, Nyquist 2f, Aliasing & Moiré, 44,1 kHz als Anwendung.
- BYTE → BEDEUTUNG (rechts, cyan): Bit · Byte · Hex, 256 Zustände, ASCII + UTF-8, Magic Number, KB vs KiB, Hex im Alltag.

Mitte: die Datei selbst — ein Strom von Byte, nichts als Zahlen.

Pointe: Eine Datei ist kein Mysterium. Es ist eine Reihe von Zahlen mit zwei Geschichten dran. Eine erzählt, woher die Zahlen kommen. Die andere, was sie bedeuten. Beide kennt ihr jetzt.

Anschluss zu Kap 2: in dieser Stunde haben wir die *unkomprimierten* Mengen gesehen (10 MB/min für CD-Audio). Im nächsten Kapitel: wie kommt man auf 1 MB/min und es klingt trotzdem fast gleich gut? Antwort: Kompression — und das ist ein eigenes Mysterium.
-->