Michael Czechowski
1bbe41b6fc
- add druckwelle.png, samplerate.webp, kubrick.jpg, morpheus.jpg - remove Red-Pill-Blue-Pill-in-Matrix.jpg - update slide content
1948 lines
54 KiB
Markdown
1948 lines
54 KiB
Markdown
---
|
||
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 :not(header),
|
||
section.erklaerung :not(footer)
|
||
{
|
||
font-size: 1.1rem;
|
||
}
|
||
@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 -->
|
||
|
||
|
||
|
||
# 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/)
|
||
|
||
---
|
||
|
||
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 1: Einführung
|
||
## Grundlagen, Text & Audio
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Was sind Daten?
|
||
|
||
---
|
||
|
||
# Was sind (digitale) Daten?
|
||
|
||
* **Text** — Artikel, Gesetzestext, Chat → `.txt` `.docx` `.pdf`
|
||
* **Bild** — Foto, Screenshot, Logo → `.jpg` `.png` `.svg`
|
||
* **Audio** — Song, Podcast, Sprachmemo → `.mp3` `.wav` `.flac`
|
||
* **Video** — Reel, Film, Stream → `.mp4` `.mov` `.mkv`
|
||
|
||
<!--
|
||
- Hilbert & López (Science 332, 2011): 60 Technologien untersucht, 1986–2007
|
||
- Wendepunkt 2002: erstmals mehr digital als analog gespeichert
|
||
- 2007: 94% aller gespeicherten Information bereits digital
|
||
- IDC DataSphere Forecast (2021): Prognose ~181 ZB produziert/repliziert für 2025
|
||
-->
|
||
---
|
||
|
||
# Was sind (digitale) Daten?
|
||
|
||
- **Text** — Artikel, Gesetzestext, Chat → `.txt` `.docx` `.pdf`
|
||
- **Bild** — Foto, Screenshot, Logo → `.jpg` `.png` `.svg`
|
||
- **Audio** — Song, Podcast, Sprachmemo → `.mp3` `.wav` `.flac`
|
||
- **Video** — Reel, Film, Stream → `.mp4` `.mov` `.mkv`
|
||
|
||
**Am Ende alles nur Nullen und Einsen**
|
||
|
||
<!--
|
||
- Hilbert & López (Science 332, 2011): 60 Technologien untersucht, 1986–2007
|
||
- Wendepunkt 2002: erstmals mehr digital als analog gespeichert
|
||
- 2007: 94% aller gespeicherten Information bereits digital
|
||
- IDC DataSphere Forecast (2021): Prognose ~181 ZB produziert/repliziert für 2025
|
||
-->
|
||
|
||
---
|
||
|
||
# Bandbreite: Was bedeuten 150 Mbit/s?
|
||
|
||
**1 Byte = 8 Bit**
|
||
|
||
daraus folgt
|
||
|
||
**f(x) = y MB/s = x Mbit/s ÷ 8**
|
||
|
||
| Bandbreite | MB/s | 1 GB Film |
|
||
|---------|-----:|----------:|
|
||
| 16 Mbit/s (ADSL) | 2 MB/s | ~8 Min |
|
||
| 50 Mbit/s (ADSL) | 6,25 MB/s | ~2,7 Min |
|
||
| 150 Mbit/s (ADSL) | 18,75 MB/s | ~54 Sek |
|
||
| 1 Gbit/s (Glasfaser) | 125 MB/s | ~8 Sek |
|
||
|
||
<!--
|
||
- Internetanbieter werben in Mbit/s, Dateien werden in MByte angegeben
|
||
- Formel: Mbit/s ÷ 8 = MB/s
|
||
- 100 Mbit/s verfügbar für >93% der deutschen Haushalte (Bundesnetzagentur, Breitbandatlas, Stand Ende 2023)
|
||
- Gigabitversorgung (alle Technologien) Ende 2024: ~78% der Haushalte (Bundesnetzagentur, Dez. 2024)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Wie viele Megabyte können bei einer Bandbreite von 250 Mbit/s pro Minute heruntergeladen werden?
|
||
|
||
* A) 1,8 GB
|
||
* B) 31,25 MB
|
||
* C) 1.875 MB
|
||
* D) 250 MB
|
||
|
||
<!--
|
||
|
||
250 Megabit/s / 8 Bit * 60 = 31,25 MB/s * 60 = 1875 MB/Minute = ~ 2GB pro Minute
|
||
|
||
-->
|
||
|
||
---
|
||
|
||
# Upload: Der stille Flaschenhals
|
||
|
||
**ADSL = Asymmetric Digital Subscriber Line**
|
||
|
||
| Bandbreite | Download | Upload |
|
||
|---------|----------:|-------:|
|
||
| 16 Mbit/s DSL | 16 Mbit/s | 1 Mbit/s |
|
||
| 50 Mbit/s DSL | 50 Mbit/s | 10 Mbit/s |
|
||
| 150 Mbit/s DSL | 150 Mbit/s | 40 Mbit/s |
|
||
| Glasfaser (FTTH) | 1 Gbit/s | 1 Gbit/s |
|
||
|
||
**50 MB Upload bei 10 Mbit/s = ~40 Sekunden**
|
||
|
||
<!--
|
||
- ADSL (Asymmetric Digital Subscriber Line, ITU = International Telecommunication Union, Norm G.992.1, 1999): Upload bewusst begrenzt — Annahme war, Nutzer konsumieren mehr als sie produzieren
|
||
- FTTH = Fiber To The Home (Glasfaser bis in die Wohnung)
|
||
- Glasfaser (FTTH) symmetrisch: Upload = Download
|
||
- FTTH-Verfügbarkeit Deutschland Ende 2024: ~40% der Haushalte (Bundesnetzagentur, Breitbandatlas)
|
||
- EU-Schnitt FTTH 2024: ~56% (FTTH Council Europe)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Analog vs. Digital
|
||
|
||
---
|
||
|
||
|
||
|
||
# Schall ist eine Druckwelle
|
||
|
||
* Lautsprecher drückt Luft → Luftmoleküle schwingen
|
||
* Die Welle breitet sich aus — kontinuierlich, ohne Stufen
|
||
* Vakuum: Keine Schallübertragung möglich (kein Medium)
|
||
|
||
<!--
|
||
- Schall = Druckschwankungen in Luft, kein Lufttransport sondern Druckvariation
|
||
- Kontinuierlich = unendlich viele Zwischenwerte, keine Stufen
|
||
- Vinyl hat keine Abtastrate — analoge Speicherung kennt keine Diskretisierung
|
||
- Rillengeometrie: die Tiefe und Kurve der Rille entspricht direkt der Amplitude der Schallwelle
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
|
||
# Schall ist eine Druckwelle
|
||
|
||
- Lautsprecher drückt Luft → Luftmoleküle schwingen
|
||
- Die Welle breitet sich aus — kontinuierlich, ohne Stufen
|
||
- Vakuum: Keine Schallübertragung möglich (kein Medium)
|
||
|
||
**Vinyl:** Die Rille *ist* die Schallwelle — physische Kopie der Druckschwankung in Rillengeometrie
|
||
|
||
---
|
||
|
||
|
||
|
||
# Abtastung (Sampling)
|
||
|
||
**Problem:** Eine kontinuierliche Welle lässt sich nicht direkt als Zahl speichern
|
||
|
||
**Lösung:** Wir messen sie in regelmäßigen Abständen
|
||
|
||
* 44.100 Messungen *pro Sekunde* = **Abtastrate** (Sample Rate)
|
||
* Einheit: Hz (Hertz) = *pro Sekunde*
|
||
* Nyquist-Theorem: min. 2× höchste darzustellende Frequenz
|
||
→ 44.100 ÷ 2 = 22.050 Hz (Mensch hört ~20–20 kHz)
|
||
|
||
<!--
|
||
- Nyquist-Shannon-Abtasttheorem (1928/1949): Harry Nyquist (Bell Labs), Claude Shannon (Bell Labs)
|
||
- 44.100 Hz: Kompromiss aus Nyquist-Limit + Kompatibilität mit Videoequipment der frühen 1980er (NTSC = National Television System Committee / PAL = Phase Alternating Line — die damaligen Fernsehstandards in USA bzw. Europa)
|
||
- Hz = Hertz: Einheit für Frequenz, benannt nach Heinrich Hertz (1857–1894), 1 Hz = 1 Schwingung pro Sekunde
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# Das digitale Ergebnis
|
||
|
||
Jede Messung = ein Zahlenwert
|
||
|
||
**Wie genau ist jede Messung? → Bittiefe (Bit Depth)**
|
||
|
||
| Bittiefe | Stufen | Dynamikumfang |
|
||
|----------|-------:|---------------|
|
||
| 8 Bit | 256 | ~48 dB |
|
||
| 16 Bit (CD) | 65.536 | ~96 dB |
|
||
| 24 Bit (Studio) | 16.777.216 | ~144 dB |
|
||
|
||
**Ergebnis:** Eine Datei aus Zahlen
|
||
|
||
<!--
|
||
- Dynamikumfang Formel: ~6 dB pro Bit
|
||
- 16 Bit reicht für menschliches Hören unter realen Bedingungen (~80–90 dB)
|
||
- 24 Bit im Studio: mehr Headroom für Bearbeitung, kein perzipieller Mehrwert für Endnutzer (Meyer & Moran, JAES 2007)
|
||
- dB = Dezibel: logarithmische Einheit für Lautstärke
|
||
-->
|
||
|
||
---
|
||
|
||
# Zurück zu Analog
|
||
|
||
Beim Abspielen läuft der Prozess rückwärts:
|
||
|
||
* Zahlen → **DAC** (Digital-Analog-Converter)
|
||
* DAC → elektrische Spannung
|
||
* Spannung → Lautsprechermembran schwingt
|
||
* Membran → Luft schwingt
|
||
* Luft → Druckwelle → Ohr
|
||
|
||
<!--
|
||
- DAC = Digital-Analog-Converter (Deutsch: Digital-Analog-Wandler)
|
||
- Jedes Abspielgerät enthält einen DAC: Smartphone, Laptop, HiFi-Verstärker
|
||
- Die Rekonstruktion ist keine identische Kopie der Originalwelle — Nyquist-Theorem definiert die theoretische Grenze
|
||
- Hochwertige DACs sind ein eigenes Produktsegment (HiFi, Profi-Audio)
|
||
-->
|
||
|
||
---
|
||
|
||
# Zurück zu Analog
|
||
|
||
Beim Abspielen läuft der Prozess rückwärts:
|
||
|
||
- Zahlen → **DAC** (Digital-Analog-Converter)
|
||
- DAC → elektrische Spannung
|
||
- Spannung → Lautsprechermembran schwingt
|
||
- Membran → Luft schwingt
|
||
- Luft → Druckwelle → Ohr
|
||
|
||
**Was wir hören ist wieder analog**
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Das Problem der Datengröße
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
---
|
||
|
||
|
||
|
||
# Ein konkretes Beispiel
|
||
|
||
**Eine Minute Musik in CD-Qualität:**
|
||
|
||
**44.100 Messungen** (pro Sekunde)
|
||
× **16 Bit** (pro Messung)
|
||
× **2 Kanäle** (Stereo)
|
||
× **60 Sekunden**
|
||
|
||
= **10,6 MB pro Minute**
|
||
|
||
<!--
|
||
BEGRIFFE:
|
||
- 44.100 Messungen/Sekunde = Abtastrate (Sample Rate): Wie oft pro Sekunde wird die Schallwelle gemessen/abgetastet. Einheit: Hz (Hertz). 44.100 Hz = 44,1 kHz.
|
||
- 16 Bit pro Messung = Bittiefe (Bit Depth): Wie fein wird jede einzelne Messung aufgelöst. 16 Bit = 2¹⁶ = 65.536 mögliche Lautstärkestufen.
|
||
- 2 Kanäle (Stereo): Links und rechts getrennt gespeichert. Mono = 1 Kanal, Stereo = 2 Kanäle.
|
||
|
||
RECHNUNG:
|
||
44.100 × 16 × 2 = 1.411.200 Bit/Sekunde = 176.400 Byte/Sekunde ≈ 10,3 MB/Minute
|
||
|
||
- CD (1982, Sony/Philips): erstes massenmarktfähiges digitales Distributionsmedium für unkomprimiertes PCM-Audio
|
||
- PCM (Pulse-Code Modulation) existierte bereits vorher: NHK (Nippon Hōsō Kyōkai = japanische öffentlich-rechtliche Rundfunkanstalt)-Forschung ab 1960er, digitale Studiogeräte ab 1970er
|
||
- Die CD war nicht das erste digitale Audio — aber das erste das in Konsumentenhänden landete
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung
|
||
|
||
# CD-Audio – Vertiefung
|
||
|
||
Die CD (1982) war nicht das erste digitale Audiomedium — PCM-Aufnahmen existierten seit den späten 1960ern in Tonstudios (u.a. NHK, Nippon Columbia). Die CD war das erste **massenmarktfähige** digitale Distributionsmedium für unkomprimiertes Audio in Konsumentenhänden.
|
||
|
||
**Warum 44.100 Hz?**
|
||
Kombination aus Nyquist-Limit (2× 20 kHz = 40 kHz Minimum) und Kompatibilität mit Videobandgeräten, die in frühen digitalen Tonstudios als Speichermedium genutzt wurden. NTSC: 3 Samples × 245 Zeilen × 60 Felder = 44.100. PAL: 3 Samples × 294 Zeilen × 50 Felder = 44.100.
|
||
|
||
**Warum 16 Bit?**
|
||
96 dB Dynamikumfang übersteigt den des menschlichen Gehörs unter realen Hörbedingungen (~80–90 dB). Kompromiss zwischen Qualität und Speicherbedarf auf der physischen Disc.
|
||
|
||
---
|
||
-->
|
||
|
||
|
||
# Das Problem skaliert
|
||
|
||
| Inhalt | Unkomprimiert |
|
||
|--------|-------------:|
|
||
| 1 Song (4 Min) | ~42 MB |
|
||
| 1 Album (60 Min) | ~635 MB |
|
||
| 10.000 Songs | ~420 GB |
|
||
|
||
**Kontext 1990er:**
|
||
- Übliche Festplattengröße: 100–500 MB
|
||
- 56 kbit/s Modem → Einfache Songs laden Stunden
|
||
|
||
<!--
|
||
- Ein Album hätte eine komplette Festplatte gefüllt
|
||
- 56k-Modem: theoretisch 56 kbit/s = 7 KB/s → 42 MB Song = ~100 Minuten Download
|
||
- Erstes kommerziell erhältliches 1-GB-Laufwerk: IBM 3380 (1980), Größe eines Kühlschranks, ~$40.000
|
||
- Consumer-Festplatten 1990: Seagate ST-251 (40 MB), ~$200
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# Video eskaliert
|
||
|
||
**Eine Minute 4K-Video (unkomprimiert):**
|
||
|
||
**3840 × 2160 Pixel** (Auflösung pro Bild)
|
||
× **3 Byte** (pro Pixel – RGB)
|
||
× **30 Bilder** (pro Sekunde)
|
||
× **60 Sekunden**
|
||
|
||
= **~45 GB pro Minute**
|
||
|
||
Kinofilm in üblicher Länge (~120min) über **5 TB (Terabyte)**
|
||
|
||
<!--
|
||
- Netflix, YouTube, Streaming — nichts davon wäre ohne Kompression möglich
|
||
- Blu-ray (2006): max. 50 GB Kapazität — reicht nicht einmal für 2 Minuten unkomprimiertes 4K
|
||
- Tatsächliche 4K-Blu-ray nutzt H.265 (HEVC): ~75–100 Mbit/s → ~2h Film passt auf eine Disc
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# Artemis II orbitiert
|
||
|
||
| | Apollo (1969) | Artemis II (2026) |
|
||
|---|---|---|
|
||
| Bandbreite | ~50 kbit/s | 260 Mbit/s |
|
||
| Video | SW, ~320 Zeilen | HD live, 4K gespeichert |
|
||
| Codec | analog | H.265 (HEVC) |
|
||
|
||
260.000.000 Bit/s
|
||
÷ 8 (Bit pro Byte) = 32,5 MB/s
|
||
× 60 Sekunden = **1,95 GB pro Minute**
|
||
|
||
*Apollo: 50 kbit/s = 0,375 MB/min*
|
||
|
||
<!--
|
||
- Übertragung per Infrarot-Laser: O2O (Orion Artemis II Optical Communications)
|
||
- MAScOT-Terminal: entwickelt von MIT Lincoln Lab
|
||
- 32 Kameras an Bord (Nikon D5/Z9, GoPros, Redwire 4K-Festkameras)
|
||
- ZCube-Encoder kodiert H.265 an Bord
|
||
- Bandbreite geteilt mit Telemetrie und Voice — live daher "nur" HD, 4K kommt auf CompactFlash-Karten nach Splashdown
|
||
- Latenz Mond ↔ Erde: ~1,3 Sekunden (384.400 km)
|
||
- Apollo: S-Band Radio, Artemis II: Infrarot-Laser
|
||
-->
|
||
|
||
---
|
||
|
||
# Kompressionsraten in der Praxis
|
||
|
||
| Medium | Unkomprimiert | Komprimiert | Faktor |
|
||
|--------|-------------:|------------:|-------:|
|
||
| 1 Song (4 Min) | ~42 MB | ~4 MB (MP3 128) | ~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 Kompression: kein Streaming, keine Smartphones, keine sozialen Medien
|
||
- Die Frage ist nicht ob, sondern wie komprimiert wird
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Zwei Arten der Datenkompression
|
||
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Zwei Arten von Datenkompressionsalgorithmen
|
||
|
||
---
|
||
|
||
<!--
|
||
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
|
||
|
||
<!--
|
||
- Run-Length Encoding (RLE): einfachste Form der verlustfreien Kompression
|
||
- Prinzip: Muster erkennen, kompakter darstellen
|
||
- Gut bei strukturierten Daten (Text, einfache Grafiken)
|
||
- Schlecht bei "chaotischen" Daten (Fotos, Audio) — dort kaum Wiederholungen
|
||
-->
|
||
|
||
---
|
||
|
||
# Verlustfreie Kompression (Lossless)
|
||
|
||
**Prinzip:** Redundanz entfernen
|
||
|
||
Beispiel **Lauflängenkodierung** (Run-Length-Encoding – RLE):
|
||
```
|
||
Original: AAAAABBBCCCCCCCC (16 Zeichen)
|
||
Komprimiert: 5A3B8C (6 Zeichen)
|
||
```
|
||
|
||
→ Komprimiert 62% kleiner und **100% wiederherstellbar**
|
||
|
||
<!--
|
||
- Run-Length Encoding (RLE): einfachste Form der verlustfreien Kompression
|
||
- Prinzip: Muster erkennen, kompakter darstellen
|
||
- Gut bei strukturierten Daten (Text, einfache Grafiken)
|
||
- Schlecht bei "chaotischen" Daten (Fotos, Audio) — dort kaum Wiederholungen
|
||
-->
|
||
|
||
---
|
||
|
||
# Verlustfreie Kompression (Lossless)
|
||
|
||
**Prinzip:** Redundanz entfernen
|
||
|
||
Beispiel **Lauflängenkodierung** (Run-Length-Encoding – RLE):
|
||
```
|
||
Original: AAAAABBBCCCCCCCC (16 Zeichen)
|
||
Komprimiert: 5A3B8C (6 Zeichen)
|
||
```
|
||
|
||
→ Komprimiert 62% kleiner und **100% wiederherstellbar**
|
||
|
||
**Anwendung:**
|
||
* ZIP-Archive, PNG-Bilder, FLAC-Audiodateien, RAW-Dateien, Programmcode
|
||
|
||
<!--
|
||
- Run-Length Encoding (RLE): einfachste Form der verlustfreien Kompression
|
||
- Prinzip: Muster erkennen, kompakter darstellen
|
||
- Gut bei strukturierten Daten (Text, einfache Grafiken)
|
||
- Schlecht bei "chaotischen" Daten (Fotos, Audio) — dort kaum Wiederholungen
|
||
-->
|
||
|
||
---
|
||
|
||
# Verlustbehaftete Kompression (Lossy)
|
||
|
||
**Prinzip:** Irrelevanz entfernen → *Wozu Daten speichern, die niemand wahrnimmt?*
|
||
|
||
---
|
||
|
||
# Verlustbehaftete Kompression (Lossy)
|
||
|
||
**Prinzip:** Irrelevanz entfernen → *Wozu Daten speichern, die niemand wahrnimmt?*
|
||
|
||
**Originaldatei nicht wiederherstellbar (!)**
|
||
|
||
**Die Frage:** Was nimmt ein Mensch eigentlich (nicht oder sehr schlecht) wahr?
|
||
|
||
* Das Ohr hört nicht alle Frequenzen (hohe und tiefe Töne) gleich gut
|
||
* Laute Töne überdecken leise Töne (Maskierung)
|
||
* Das Auge sieht nicht alle Farbnuancen gleich scharf
|
||
* Luminanz (Helligkeit/Dunkelheit) besser erkennen als Chrominanz (Farbunterschiede/Farbigkeit)
|
||
* und Vieles mehr
|
||
|
||
<!--
|
||
- Zentrale Idee hinter MP3, JPEG, H.264
|
||
- Nicht die Daten selbst reduzieren — das wäre bloßer Qualitätsverlust
|
||
- Sondern gezielt das entfernen, was Menschen nicht wahrnehmen
|
||
- Psychoakustik (Audio) / Psychovisualität (Bild) als wissenschaftliche Grundlage
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# Verlustfrei vs. Verlustbehaftet
|
||
|
||
| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
|
||
|---|---|---|
|
||
| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
|
||
| **Reversibel** | Ja | Nein (Information unwiederbringlich verloren) |
|
||
| **Reduktion** | 30–50% | 80–99% |
|
||
| **Formate** | ZIP, PNG, FLAC, GIF, ... | JPEG, MP3, H.264/H.265, ... |
|
||
|
||
**Faustregel:**
|
||
- Medien für EndnutzerInnen (Ton, Bild, Film) → Lossy oft akzeptabel
|
||
- Quellmaterial, Code, Archive (RAW) → 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 -->
|
||
|
||
# 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, TAR)
|
||
- 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 ist durch Entropie begrenzt; Verlustbehaftete Kompression kann beliebig weit gehen — auf Kosten der Qualität.
|
||
|
||
<!--
|
||
ABKÜRZUNGEN:
|
||
- LZ77 = Lempel-Ziv 1977 — Sliding-Window: sucht Wiederholungen in einem Fenster der letzten Bytes, ersetzt durch Rückverweise (Offset + Länge)
|
||
- LZ78 = Lempel-Ziv 1978 — baut explizites Wörterbuch auf: neue Muster bekommen Index, Wiederholungen werden durch Index ersetzt
|
||
- DEFLATE = Kombination LZ77 + Huffman-Coding; verwendet in ZIP, PNG, gzip
|
||
- TAR = Tape ARchive — kein Kompressionsformat, sondern Archivformat. Kompression durch Kombination: .tar.gz (gzip), .tar.bz2 (bzip2), .tar.xz (LZMA)
|
||
- ZIP = Archivformat mit eingebauter DEFLATE-Kompression (Phil Katz, 1989)
|
||
- PNG = Portable Network Graphics — nutzt DEFLATE für verlustfreie Bildkompression
|
||
|
||
STATISTISCHE KODIERUNG:
|
||
- Huffman-Coding: Häufige Zeichen → kurze Bitfolgen, seltene Zeichen → lange Bitfolgen
|
||
- Arithmetic Coding: Kodiert gesamte Nachricht als einzelne Zahl zwischen 0 und 1. Effizienter als Huffman, rechenintensiver
|
||
|
||
ENTROPIE (Shannon, 1948):
|
||
- Maß für den Informationsgehalt: Wie "überraschend" ist jedes Zeichen?
|
||
- Hohe Entropie = schwer komprimierbar (verschlüsselte Daten, Rauschen)
|
||
- Niedrige Entropie = gut komprimierbar ("AAAAAAA", natürliche Sprache)
|
||
- Theoretisches Minimum: kein Algorithmus kann unter die Entropie-Grenze kommen
|
||
|
||
PRAXISBEISPIEL:
|
||
- ZIP einer .txt-Datei: ~60–70% kleiner (Text hat niedrige Entropie)
|
||
- ZIP einer .jpg-Datei: kaum kleiner (JPEG hat Entropie schon ausgereizt)
|
||
-->
|
||
|
||
---
|
||
|
||
- Alltagsbeispiele für Kompression sammeln
|
||
- Wie sieht Kompression aus, wenn man es visualisieren würde? Eine Maske, hinter der nichts zu sehen ist?
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
<!-- -->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Die Grundbausteine
|
||
## Bits, Bytes und ihre Darstellung
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Bit = Binary Digit
|
||
Demonstration: Glühbirne AN/AUS = 1 Bit
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
|
||
---
|
||
|
||
# Das Bit
|
||
|
||
### Kleinste *logische* Informationseinheit
|
||
|
||
* **0 oder 1**
|
||
* AN oder AUS
|
||
* Strom fließt oder nicht
|
||
* Schwarz oder Weiß
|
||
* Richtig oder Falsch
|
||
|
||
<!--
|
||
- BIT = Binary Digit (Binärziffer) — Begriff geprägt von John W. Tukey, 1947; popularisiert durch Claude Shannon, 1948
|
||
- Shannon begründete die Informationstheorie (Bell Labs)
|
||
- Warum binär? Elektronische Schaltungen haben physikalisch stabile 2 Zustände: Strom/kein Strom
|
||
- Transistoren in modernen CPUs: Apple M4 ~28 Milliarden Transistoren, schalten Milliarden Mal pro Sekunde
|
||
-->
|
||
|
||
---
|
||
|
||
# Das Byte
|
||
|
||
### Die kleinste *adressierbare* Informationseinheit
|
||
|
||
<!--
|
||
BYTE = Wortspiel aus "Bit" + "Bite" (Bissen) — ein "Bissen" Information
|
||
Begriff geprägt von Werner Buchholz (IBM), 1956, während der Entwicklung des IBM 7030 Stretch
|
||
Schreibweise mit "y" statt "i": bewusste Änderung zur Vermeidung von Verwechslung mit "Bit"
|
||
-->
|
||
|
||
---
|
||
|
||
# Das Byte
|
||
|
||
### Die kleinste *adressierbare* Informationseinheit
|
||
|
||
### 1 Byte = 8 Bits
|
||
|
||
|
||
```
|
||
0 0 1 0 1 0 1 0 = 42
|
||
```
|
||
|
||
<!--
|
||
binary 00101010 = decimal 42
|
||
|
||
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?"
|
||
-->
|
||
|
||
---
|
||
|
||
# Das Byte
|
||
|
||
### Die kleinste *adressierbare* Informationseinheit
|
||
|
||
### 1 Byte = 8 Bits
|
||
|
||
|
||
```
|
||
0 0 0 0 0 0 0 0 = 0
|
||
0 0 0 0 0 0 0 1 = 1
|
||
0 0 0 0 0 0 1 0 = 2
|
||
0 0 0 0 0 0 1 1 = 3
|
||
0 0 0 0 0 1 0 0 = 4
|
||
|
||
0 1 0 0 0 0 0 0 = 64
|
||
0 1 1 1 1 1 1 1 = 127
|
||
1 1 1 1 1 1 1 1 = ?
|
||
```
|
||
|
||
<!--
|
||
- 1964: IBM System/360 setzte den 8-Bit-Byte-Standard — vorher: 6-Bit und 7-Bit-Systeme im Einsatz
|
||
- ASCII (1963) brauchte 7 Bit für 128 Zeichen
|
||
- 8 Bit = praktisch für Hardware (Zweierpotenz: 2³ = 8)
|
||
- 8 Bit = 2 Hexadezimalziffern (elegante Darstellung)
|
||
- Kleinste adressierbare Einheit im Speicher: Prozessor kann nicht einzelne Bits direkt ansprechen, immer Bytes
|
||
|
||
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
|
||
-->
|
||
|
||
---
|
||
|
||
# Das Byte
|
||
|
||
### Die kleinste *adressierbare* Informationseinheit
|
||
|
||
### 1 Byte = 8 Bits
|
||
|
||
|
||
```
|
||
0 0 0 0 0 0 0 0 = 0
|
||
0 0 0 0 0 0 0 1 = 1
|
||
0 0 0 0 0 0 1 0 = 2
|
||
0 0 0 0 0 0 1 1 = 3
|
||
0 0 0 0 0 1 0 0 = 4
|
||
|
||
0 1 0 0 0 0 0 0 = 64
|
||
0 1 1 1 1 1 1 1 = 127
|
||
1 1 1 1 1 1 1 1 = ?
|
||
```
|
||
|
||
2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 = 2⁸ = **256 Möglichkeiten** (0–255)
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
»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
|
||
- 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 ca. 10 Millionen Farben unterscheiden (Schnapf et al., J. Neuroscience 1987)
|
||
- 24 Bit reicht für fotorealistische Bilder
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Welche Farben für ein volles Spektrum bieten sich nach unserer gelernten Sparsamkeit hier am besten an?
|
||
|
||
1. CMYK (Cyan, Magenta, Yellow, Key/Black)
|
||
2. RGB (Red, Green, Blue)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
RGB = Additive Farbmischung (Bildschirme)
|
||
Sog. RGB Tuple (geordnete endliche Liste)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# Farben: RGB-Modell
|
||
|
||
**1 Pixel = 3 Byte**
|
||
|
||
- **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ß
|
||
|
||
<!--
|
||
- sRGB = Standard RGB (IEC = International Electrotechnical Commission, Norm 61966-2-1, 1999)
|
||
- CMYK = Cyan, Magenta, Yellow, Key (Black) — subtraktive Farbmischung (Druck)
|
||
- Hex-Notation: FF = 255 in Dezimal
|
||
- CSS-Farben nutzen Hex: #FF0000 = Rot
|
||
-->
|
||
|
||
---
|
||
|
||
# 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 passen problemlos in 1 Byte**
|
||
|
||
**Jedoch ohne** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 🌸
|
||
|
||
<!--
|
||
- ASCII (1963): 7 Bit = 128 Zeichen (nur Englisch)
|
||
- ISO-8859-1 (Latin-1, 1987): 8 Bit = 256 Zeichen (Westeuropa)
|
||
- Chaos der 1980/90er: Verschiedene inkompatible Standards für verschiedene Sprachen
|
||
- Windows-1252 vs. ISO-8859-1: ähnlich, aber nicht identisch — Ursache unzähliger Encoding-Bugs
|
||
-->
|
||
|
||
---
|
||
|
||
# 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!)
|
||
- 1.112.064 gültige Codepunkte
|
||
- Umlaute: 2 Bytes · CJK: 3 Bytes · Emoji: 4 Bytes
|
||
|
||
<!--
|
||
- 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)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
- は wird hier "wa" ausgesprochen (Partikel), nicht "ha"
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Hexadezimal
|
||
## Die Sprache der Datei-Analyse
|
||
|
||
---
|
||
|
||
# Hexadezimal: Lesbarkeit
|
||
|
||
**Für den Menschen ungeeignet:**
|
||
`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)
|
||
|
||
`5 = 0101` `0 = 0000`
|
||
`4 = 0100` `E = 1110`
|
||
`4 = 0100` `7 = 0111`
|
||
|
||
**ASCII Tabelle (0–127):**
|
||
[https://www.asciitable.com](https://www.asciitable.com)
|
||
|
||
<!--
|
||
- Dezimalsystem passt unelegant ins binäre System: 0–15 (1111) braucht 1–2 Dezimalziffern, immer 1 Hex-Ziffer
|
||
- Hexadezimal (16 = 2⁴) passt perfekt: 4 Bits = 1 Hex-Ziffer, 8 Bits = 2 Hex-Ziffern
|
||
- "Nibble" = 4 Bits = halbes Byte (Wortspiel: nibble = knabbern, byte = beißen)
|
||
- ASCII geht nur bis 127 — Werte 128–255 sind nicht im ASCII-Raum
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
---
|
||
|
||
<!-- _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 nicht berücksichtigt
|
||
- Führte zu zahlreichen inkompatiblen Erweiterungen (ISO-8859-1, Windows-1252, etc.)
|
||
|
||
WARUM NOCH HEUTE RELEVANT?
|
||
- UTF-8 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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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 é
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# 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
|
||
```
|
||
|
||
---
|
||
|
||
|
||
|
||
# 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** |
|
||
|
||
→ `89` übersteigt den ASCII-Raum und markiert eine Binärdatei
|
||
|
||
<!--
|
||
- Hex = 2 Ziffern = 1 Byte = 8 Bit
|
||
- 89 hex = 8×16 + 9 = 137 dezimal
|
||
- ASCII geht nur bis 127 — 137 ist nicht druckbar
|
||
- 50, 4E, 47 = P, N, G in ASCII
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
<!--
|
||
- Erste Bytes: 89 50 4E 47 = PNG-Signatur
|
||
- 89: non-printable character (außerhalb ASCII)
|
||
- 50: P
|
||
- 4E: N
|
||
- 47: G
|
||
- IHDR = Image Header (Breite, Höhe, Farbtiefe)
|
||
- Tool: HxD (Windows), Hex Fiend (Mac), xxd (Linux)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
---
|
||
|
||
# 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.*
|
||
|
||
<!--
|
||
- PNG nutzt absichtlich 89 (= 137 dezimal): markiert Datei eindeutig als Binär, nicht Text
|
||
- 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
|
||
- Sicherheit: virus.exe → bild.jpg umbenennen täuscht nur Menschen; "file" (Linux) liest Magic Number
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# Dateneinheiten
|
||
|
||
| Einheit | Bytes | Potenz | Beispiel |
|
||
|---------|------:|:------:|----------|
|
||
| **Byte** | 1 | 10⁰ | Farbwert 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²¹ | Globale Datenmenge 2025 |
|
||
|
||
<!--
|
||
- 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** | **~175–181 ZB** | Prognose (IDC DataSphere Forecast, 2021) |
|
||
|
||
<!--
|
||
- Exponentielles Wachstum: Verdopplung alle ~2 Jahre
|
||
- 1986: Letzte Ära mit analoger Dominanz
|
||
- 2002: Wendepunkt — erstmals mehr digital als analog (Hilbert & López, Science 332, 2011)
|
||
- 2007: 94% digital (ebd.)
|
||
- ~175–181 ZB für 2025: IDC-Prognose von 2021, keine gemessene Zahl
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _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
|
||
- Magnetband lebt: LTO-Tapes bleiben günstigstes Archivmedium (AWS Glacier, Film-Archive, Rechenzentren)
|
||
|
||
<!--
|
||
KLAUSURRELEVANT:
|
||
- 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 332(6025), 60–65. DOI: 10.1126/science.1200970
|
||
|
||
METHODIK: 60 analoge + digitale Technologien untersucht (1986–2007)
|
||
|
||
ANALOG damals: Bücher, Zeitungen, Vinyl, VHS, Filmrollen, Fotos
|
||
DIGITAL damals: Festplatten, CDs, DVDs, frühe Flash-Speicher
|
||
|
||
LTO-9 (2021): 18 TB pro Band, ~5€/TB für Cold Storage
|
||
SSD: ~50€/TB, HDD: ~15€/TB, LTO: ~5€/TB
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Digitaler Wendepunkt – Vertiefung
|
||
|
||
Die Studie von Hilbert & López (Science 332, 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: '' -->
|
||
|
||
|
||
|
||
---
|
||
|
||
# 181 Zettabyte – Was bedeutet das?
|
||
|
||
**Prognose 2025:** Welt erzeugt ca. **175–181 ZB** pro Jahr
|
||
|
||
- **1 ZB** = 250 Milliarden DVDs
|
||
- **29 Terabyte** pro Sekunde (Hochrechnung)
|
||
|
||
**Zum Vergleich:**
|
||
- 2007: 295 Exabyte (Hilbert & López, Science 2011)
|
||
- 2020: ~64 Zettabyte (IDC)
|
||
- ~2025: ~175–181 ZB (IDC DataSphere Forecast, Prognose von 2021)
|
||
|
||
<!--
|
||
- Quelle: IDC Global DataSphere Forecast 2021–2025 — Prognose, keine gemessene Zahl
|
||
- Tatsächlich gemessen 2024: ~149 ZB (IDC)
|
||
- IoT-Geräte allein: prognostiziert ~73 ZB in 2025 (IDC)
|
||
- Prognose 2028: ~394 ZB (IDC)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Quelle: Floridi, L.: The Fourth Revolution
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
- Schwer zu messen, da Menschen + AI zusammenarbeiten
|
||
- Model Collapse: AI trainiert auf AI-Output → Qualitätsverlust (Shumailov et al., Nature 2024)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 2: Die MP3-Revolution
|
||
## Psychoakustik & Audio-Kompression
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
---
|
||
|
||
<!-- _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ß
|
||
|
||
Digitale Kopie = bit-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>
|
||
|
||
<!--
|
||
- Analog: Kopie war immer erkennbar schlechter
|
||
- Digital: Kopie = Original (bit-identisch)
|
||
- Gerade die Perfektion wurde zum "Problem" der Musikindustrie
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _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*
|
||
|
||
| Inhalt | Größe | Problem (1990er) |
|
||
|--------|-------|------------------|
|
||
| 1 Song (4 Min) | ~42 MB | Ausreichend Speicher |
|
||
| 1 Album (60 Min) | ~635 MB | Gesamte Festplatte |
|
||
|
||
<!--
|
||
CD-QUALITÄT:
|
||
- 44.100 Hz = Sample Rate (Abtastrate): 44.100 Messungen pro Sekunde
|
||
- 16 Bit = Bit Depth: 65.536 mögliche Lautstärkestufen, ~96 dB Dynamikumfang
|
||
- 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
|
||
|
||
- Consumer-Festplatten 1990: 40–500 MB
|
||
- 56k-Modem: 7 KB/s → 42 MB Song ≈ 100 Minuten Download
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
"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**
|
||
|
||
**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!)
|
||
|
||
<!--
|
||
- Nyquist-Shannon-Abtasttheorem: Harry Nyquist (1928), Claude Shannon (1949)
|
||
- Vinyl: Rille = physische Kopie der Welle, "unendliche Auflösung" in der Theorie
|
||
- Vinyl praktisch begrenzt durch: Rauschen, Kratzer, Nadelmasse, Rillengeometrie
|
||
- Warum genau 44.100 Hz: Nyquist + Kompatibilität mit PAL/NTSC-Videogeräten der frühen 1980er
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
- Dynamikumfang Formel: ~6 dB pro Bit
|
||
- 16 Bit reicht für menschliches Hören unter realen Bedingungen
|
||
- 24 Bit im Studio: mehr Headroom für Bearbeitung, kein perzipieller Mehrwert für Endnutzer (Meyer & Moran, JAES 2007)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
- Horizontal (Abtastrate): welche Frequenzen erfassbar sind
|
||
- 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 bestimmen das "Raster"
|
||
- Reduzierung = harter Schnitt auf technischer Ebene
|
||
- Abtastrate 22 kHz → alles über 11 kHz physisch unmöglich zu speichern
|
||
-->
|
||
|
||
---
|
||
|
||
# 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"
|
||
|
||
<!--
|
||
- Der Container (44.1 kHz, 16 Bit, Stereo) kann gleich bleiben
|
||
- Inhalt wird "ausgedünnt" — nur was hörbar ist, bleibt
|
||
- 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 (~200ms)
|
||
- Absolute Hörschwelle: sehr leise Töne generell unhörbar
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# 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
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# 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
|
||
|
||
<!--
|
||
- A cappella = einfacher zu analysieren (nur Stimme)
|
||
- Hohe Frequenzen = Herausforderung für Kompression
|
||
- Brandenburg hörte den Song über 10.000 Mal
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
1. FFT (Fast Fourier Transform): Wandelt Schallwellen in Frequenzen um — wie ein Prisma Licht in Farben zerlegt
|
||
2. Psychoakustisches Modell: Maskierungseffekte, hohe/tiefe Frequenzen werden schlechter wahrgenommen
|
||
3. Quantisierung: Unwichtige Frequenzen "grob" gespeichert, wichtige bleiben genau — hier passiert der Datenverlust
|
||
4. Huffman-Coding: Häufige Muster = kurze Codes, seltene = lange Codes — finaler verlustfreier Boost
|
||
-->
|
||
|
||
---
|
||
|
||
# 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 Napster-Ära
|
||
- 320 kbps = Maximum für MP3
|
||
- Diminishing Returns ab 256 kbps
|
||
-->
|
||
|
||
---
|
||
|
||
# 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 und andere Tools
|
||
- Millionen nutzten unlizenzierte Software
|
||
- 2017: Fraunhofer selbst erklärte MP3 für "veraltet" (AAC besser)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# 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
|
||
- RIAA verklagte Napster, Schließung 2001
|
||
- LimeWire, Kazaa, BitTorrent folgten
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# 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
|
||
- 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
|
||
- Loudness War: Alles wird lauter gemastert, Dynamik geht verloren
|
||
- Vinyl-Revival: 2020er Gegenbewegung — RIAA 2023: Vinyl-Umsatz übersteigt erstmals seit 1987 CD-Umsatz
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _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-Spektrogramm
|
||
|
||
**Aufgabe (30 Min):**
|
||
|
||
- Live Spektrogramm 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 → "Spektrogramm"
|
||
- Hohe Frequenzen (oben im Bild) verschwinden bei niedriger Bitrate
|
||
- Alternative: Spek (spek.cc) — reiner Spektrogramm-Viewer
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
- 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
|
||
--> |