Michael Czechowski
b45a528faf
- add svg diagonal stripe patterns for pdf background - use @media print to apply svg only in pdf export - keep css gradient for web/screen display - add _header: '' and _footer: '' to all klausur slides
1507 lines
37 KiB
Markdown
1507 lines
37 KiB
Markdown
---
|
||
marp: true
|
||
theme: gaia
|
||
paginate: true
|
||
backgroundColor: #fff
|
||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||
---
|
||
|
||
<style>
|
||
:root {
|
||
--color-foreground: #1a1a2e;
|
||
--color-highlight: #1e5f8a;
|
||
--color-dimmed: #4a4a6a;
|
||
}
|
||
section.invert {
|
||
--color-foreground: #fff;
|
||
}
|
||
section {
|
||
font-size: 1.7rem;
|
||
}
|
||
h1 {
|
||
color: #1e5f8a;
|
||
}
|
||
section.invert h1 {
|
||
color: #fff;
|
||
}
|
||
h2 {
|
||
color: #1f2937;
|
||
}
|
||
pre {
|
||
background: #0f0f23;
|
||
color: #5fb3e4;
|
||
border-radius: 8px;
|
||
border-left: 3px solid #1e5f8a;
|
||
}
|
||
pre code {
|
||
background: transparent;
|
||
color: inherit;
|
||
}
|
||
code {
|
||
background: #1a1a2e;
|
||
color: #5fb3e4;
|
||
padding: 0.15em 0.4em;
|
||
border-radius: 4px;
|
||
}
|
||
a {
|
||
color: var(--color-highlight);
|
||
}
|
||
section.klausur {
|
||
background: repeating-linear-gradient(
|
||
135deg,
|
||
#e3f2fd,
|
||
#e3f2fd 40px,
|
||
#fff 40px,
|
||
#fff 80px
|
||
) !important;
|
||
}
|
||
@media print {
|
||
section.klausur {
|
||
background: url('./assets/klausur-pattern.svg') !important;
|
||
background-size: cover !important;
|
||
}
|
||
}
|
||
section.aufgabe {
|
||
background: #e3f2fd !important;
|
||
}
|
||
section.aufgabe footer {
|
||
display: none;
|
||
}
|
||
</style>
|
||
|
||
<!-- _class: invert -->
|
||
<!-- _header: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||
|
||
**223015b** · Modul "Technik 1" · 1. Semester
|
||
Digital- und Medienwirtschaft
|
||
Hochschule der Medien Stuttgart
|
||
|
||
**Wintersemester 2025/26**
|
||
|
||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||
|
||
---
|
||
|
||
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 1: Einführung
|
||
## Grundlagen, Text & Audio
|
||
|
||
---
|
||
|
||
|
||
|
||
# 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** |
|
||
|
||
→ **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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Dateneinheiten
|
||
|
||
| Einheit | Bytes | Potenz | Beispiel |
|
||
|---------|-------|--------|----------|
|
||
| **1 Byte** | 1 | 10⁰ | Farbwerte eines Pixels |
|
||
| **1 Kilobyte (KB)** | 1.000 | 10³ | Kleiner Programmcode |
|
||
| **1 Megabyte (MB)** | 1 Million (Mio.) | 10⁶ | Textdokument |
|
||
| **1 Gigabyte (GB)** | 1 Milliarde (Mrd.) | 10⁹ | Kinofilm in FullHD |
|
||
| **1 Terabyte (TB)** | 1 Billion (Bio.) | 10¹² | ~12h Video in 4K |
|
||
|
||
<!--
|
||
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
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Dateneinheiten (Fortsetzung)
|
||
|
||
| Einheit | Bytes | Potenz | Beispiel |
|
||
|---------|-------|--------|----------|
|
||
| **1 Petabyte (PB)** | 1 Billiarde (Brd.) | 10¹⁵ | Netflix-Gesamtarchiv |
|
||
| **1 Exabyte (EB)** | 1 Trillion (Trill.) | 10¹⁸ | Alle E-Mails weltweit/Tag |
|
||
| **1 Zettabyte (ZB)** | 1 Trilliarde | 10²¹ | Internet-Traffic 2016 |
|
||
| **1 Yottabyte (YB)** | 1 Quadrillion | 10²⁴ | *Noch nie erreicht* |
|
||
|
||
<!--
|
||
Peta = 10^15 (Billiarde)
|
||
Exa = 10^18 (Trillion)
|
||
Zetta = 10^21 (Trilliarde)
|
||
Yotta = 10^24 (Quadrillion)
|
||
|
||
|
||
Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
|
||
→ "Komm Mit Großem Tee, Peter Exte Zettelt Yachten"
|
||
-->
|
||
|
||
---
|
||
|
||
# Datenwachstum der Menschheit
|
||
|
||
| Jahr | Datenmenge | Kontext |
|
||
|------|------------|---------|
|
||
| **100.000 v. Chr.** | 0 | Erste Menschen, nur Sprache |
|
||
| **3.000 v. Chr.** | ~wenige KB | Keilschrift, Hieroglyphen |
|
||
| **1450** | ~wenige GB | Gutenberg, Buchdruck |
|
||
| **1986** | **2,6 EB** | 99% analog (Bücher, Vinyl, VHS) |
|
||
| **2007** | **295 EB** | 94% digital |
|
||
| **2025** | **181 ZB** | 90% unstrukturiert |
|
||
|
||
<!--
|
||
Exponentielles Wachstum: Verdopplung alle 2 Jahre
|
||
1986: Letzte Ära mit analoger Dominanz
|
||
2007: Erste Jahr, in dem digital > analog
|
||
2025: 181 ZB = 181.000.000.000.000.000.000.000 Bytes
|
||
Analog blieb bei ~2,6 EB stehen (Bücher, Vinyl, Film)
|
||
Digital explodierte: IoT, Social Media, Cloud, Video
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Der digitale Wendepunkt
|
||
|
||
| Jahr | Analog | Digital | Digital-Anteil |
|
||
|------|--------|---------|----------------|
|
||
| **1986** | 2,6 EB | 0,02 EB | **1%** |
|
||
| **2002** | — | — | **50%** (Wendepunkt) |
|
||
| **2007** | 18 EB | 277 EB | **94%** |
|
||
|
||
**Perspektive:**
|
||
- 1986: "Petabyte" war ein theoretisches Konzept
|
||
- 2025: ~181 Zettabyte jährlich produziert
|
||
|
||
**Magnetband lebt:** LTO-Tapes bleiben günstigstes Archivmedium
|
||
(AWS Glacier, Film-Archive, Rechenzentren)
|
||
|
||
<!--
|
||
PRÜFUNGSRELEVANT:
|
||
- Wendepunkt 2002
|
||
- Speichereinheiten (KB→MB→GB→TB→PB→EB→ZB)
|
||
- Magnetband als Archivmedium
|
||
|
||
QUELLE: Hilbert & López (2011): "The World's Technological Capacity to Store, Communicate, and Compute Information", Science
|
||
|
||
METHODIK: 60 analoge + digitale Technologien untersucht (1986-2007)
|
||
|
||
WENDEPUNKT 2002: Erstmals mehr digital als analog gespeichert
|
||
|
||
ANALOG damals: Bücher, Zeitungen, Vinyl, VHS, Filmrollen, Fotos
|
||
|
||
DIGITAL damals: Festplatten, CDs, DVDs, frühe Flash-Speicher
|
||
|
||
HEUTE: LTO-9 (2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
|
||
|
||
VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
|
||
|
||
-->
|
||
|
||
---
|
||
|
||
# 181 Zettabyte – Was bedeutet das?
|
||
|
||
**2025:** Welt erzeugt **181 ZB** pro Jahr
|
||
|
||
- **2,5 Quintillionen Bytes** täglich
|
||
- **29 Terabyte** pro Sekunde
|
||
- **90%** davon: unstrukturiert (Videos, Bilder, Audio)
|
||
- **70%** davon: von Nutzern generiert
|
||
|
||
**Zum Vergleich:**
|
||
- 1 ZB = 250 Milliarden DVDs
|
||
- 181 ZB = Jeder Mensch erzeugt ~23 TB/Jahr
|
||
|
||
<!--
|
||
Quellen: IDC Global DataSphere Forecast, Statista 2025
|
||
IoT-Geräte allein: 73 ZB in 2025
|
||
Cloud-Speicher: 100 ZB (50% der Weltdaten)
|
||
Prognose 2028: 394 ZB
|
||
-->
|
||
|
||
---
|
||
|
||
# AI-generierte Inhalte 2025
|
||
|
||
**Wie viel Content ist heute synthetisch?**
|
||
|
||
| Bereich | AI-Anteil |
|
||
|---------|-----------|
|
||
| **Neue Webseiten** | ~74% enthalten AI-Content |
|
||
| **Web-Text gesamt** | ~30-40% AI-generiert |
|
||
| **Neue Artikel** | ~52% von AI geschrieben |
|
||
| **Social-Media-Bilder** | ~71% AI-generiert |
|
||
|
||
**Prognose 2026:** 90% des Online-Contents synthetisch
|
||
|
||
<!--
|
||
Quellen: Ahrefs 2025, arXiv, Europol-Report
|
||
"Synthetic Media" = AI-generiert oder -manipuliert
|
||
Problem: Schwer zu messen, da Menschen + AI zusammenarbeiten
|
||
Model Collapse: AI trainiert auf AI-Output → Qualitätsverlust
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# ASCII
|
||
## 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: '' -->
|
||
|
||
|
||
|
||
|
||
<!--
|
||
|
||
Vorgeschichte:
|
||
|
||
US-ASCII (1967) Code Chart
|
||
- 7 Bit = 128 Zeichen
|
||
- Erste 32: Steuerzeichen (nicht druckbar)
|
||
- Zeichen 32-126: Druckbar (Buchstaben, Ziffern, Satzzeichen)
|
||
- Keine Umlaute, kein ñ, kein é
|
||
- "American Standard" → Rest der Welt ausgeschlossen
|
||
|
||
"Ich möchte, dass ihr das mit mir jetzt gemeinsam lesen lernt; stellt euch vor ihr seid ArchäologInnen."
|
||
|
||
"Wie würdet ihr vorgehen?"
|
||
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
»256 Shades of Gray«
|
||
|
||
|
||
|
||
<!--
|
||
|
||
»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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
RGB = Additive Farbmischung (Bildschirme)
|
||
|
||
Sog. RGB Tuple (geordnete endliche Liste)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# 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: '' -->
|
||
|
||
|
||
|
||
---
|
||
|
||
# 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!)
|
||
- Umlaute: 2 Bytes · CJK: 3 Bytes · Emoji: 4 Bytes
|
||
|
||
<!--
|
||
Unicode Consortium: Non-Profit seit 1991
|
||
Aktuell: Unicode 16.0 (2024)
|
||
UTF-8 = Unicode Transformation Format, 8-bit
|
||
|
||
WICHTIG für Kontext zur ASCII-Folie:
|
||
- Die ersten 128 Zeichen in UTF-8 sind EXAKT ASCII
|
||
- Deshalb funktioniert alter ASCII-Code noch heute
|
||
- UTF-8 ist der Grund, warum ASCII nie verschwinden wird
|
||
- "A" in ASCII = "A" in UTF-8 = 0x41 = 65 dezimal
|
||
|
||
Byte-Längen:
|
||
- ASCII-Zeichen (0-127): 1 Byte
|
||
- Umlaute, diakritische Zeichen: 2 Bytes
|
||
- Chinesisch, Japanisch, Koreanisch: 3 Bytes
|
||
- Emoji, seltene Zeichen: 4 Bytes
|
||
-->
|
||
|
||
---
|
||
|
||
# Beispiel: Bytes zählen
|
||
|
||
**Text:** `"Why the heck braucht 💩 4 Bytes?!"`
|
||
|
||
```
|
||
W h y → je 1 Byte (4 Bytes)
|
||
t h e → je 1 Byte (4 Bytes)
|
||
h e c k → je 1 Byte (4 Bytes)
|
||
→ 1 Byte (Leerzeichen)
|
||
b r a u c h t → je 1 Byte (7 Bytes)
|
||
→ 1 Byte
|
||
💩 → 4 Bytes! (0xF0 9F 92 A9)
|
||
→ 1 Byte
|
||
4 B y t e s ? ! → je 1 Byte (9 Bytes)
|
||
```
|
||
|
||
**Gesamt: 37 Bytes**
|
||
|
||
<!--
|
||
Buchstaben = 1 Byte (ASCII/UTF-8-kompatibel)
|
||
Emoji = 4 Bytes (Unicode-Bereich U+1F4A9)
|
||
Haufen-Emoji: "Pile of Poo" (offizieller Name!)
|
||
UTF-8-Kodierung: Variable Länge spart Speicher bei ASCII
|
||
-->
|
||
|
||
---
|
||
|
||
# Hexadezimal: Lesbarkeit
|
||
|
||
**Binär ist unleserlich:**
|
||
`01001101 01010000 00110011`
|
||
|
||
**Hexadezimal (Base 16):**
|
||
`4D 50 33` (= "MP3" in ASCII)
|
||
|
||
**Jede Hex-Ziffer = 4 Bits (ein "Nibble")**
|
||
0-9, A-F (10=A, 11=B, ..., 15=F)
|
||
|
||
**ASCII Tabelle (0-127):**
|
||
[https://www.asciitable.com](https://www.asciitable.com)
|
||
|
||
<!--
|
||
|
||
"Gerne vorab auf den Link gehen"
|
||
|
||
WICHTIG: ASCII geht nur von 0-127!
|
||
- Werte 128-255 sind NICHT in der ASCII-Tabelle
|
||
- Das wird später bei Magic Numbers wichtig
|
||
|
||
Warum Hexadezimal statt Dezimal?
|
||
- Binär ist zu lang: 01001101 (8 Zeichen für 1 Byte)
|
||
- Dezimal passt nicht: 77 (unregelmäßig, manchmal 2, manchmal 3 Ziffern)
|
||
- Hex ist perfekt: 4D (immer 2 Ziffern pro Byte)
|
||
|
||
Trick: 4 Bits = 1 Hex-Ziffer (weil 2⁴ = 16)
|
||
0000 = 0, 0001 = 1, ..., 1001 = 9, 1010 = A, 1011 = B, ..., 1111 = F
|
||
|
||
"Nibble" = 4 Bits = halbes Byte (Wortspiel: nibble = knabbern, byte = beißen)
|
||
|
||
Umrechnung üben:
|
||
- 0x4D = 4×16 + 13 = 64 + 13 = 77 (Dezimal) = Buchstabe "M" in ASCII
|
||
- 0xFF = 15×16 + 15 = 255 (Maximum für 1 Byte)
|
||
|
||
Hex-Editor = Standard-Tool für Dateianalyse und Reverse Engineering
|
||
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
<!--
|
||
|
||
"Zurück zu Frage am Anfang: Was steht hier nun?"
|
||
|
||
"Versucht es kurz selbst zu entschlüsseln"
|
||
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
<!--
|
||
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: '' -->
|
||
|
||
|
||
|
||
---
|
||
|
||
# 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: aufgabe -->
|
||
|
||
|
||
|
||
# Hands-On: HEX Files
|
||
|
||
**Aufgabe (30 Min):**
|
||
|
||
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
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 2: Die MP3-Revolution
|
||
## Psychoakustik & Audio-Kompression
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Kassette neben iPod
|
||
Visueller Kontrast: Analog vs. Digital
|
||
1980er vs. 2000er
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Analoge Medien
|
||
### Distribution: physisch (Kauf, Verleih, Kopie)
|
||
|
||
* **Text**
|
||
* Bücher, Zeitungen, Zeitschriften, Lochkarten
|
||
* **Bild**
|
||
* Fotografie (Negativ, Dia, Polaroid), Mikrofilm
|
||
* **Audio:**
|
||
* Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
|
||
* **Video:**
|
||
* Film (35mm, Super 8), VHS, Betamax
|
||
|
||
---
|
||
|
||
# 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: '' -->
|
||
|
||
# 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: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Digitale Speichermedien
|
||
|
||
* **Optische Speicher**
|
||
* CD, DVD, Blue-Ray
|
||
* **Magnetische Speicher**
|
||
* Festplatte (HDD), Magnetband (LTO)
|
||
* **Flash-Speicher**
|
||
* SSD, USB-Stick, SD-Karte
|
||
* **Cloud-Speicher**
|
||
* Dropbox, Google Drive, iCloud, AWS S3
|
||
|
||
---
|
||
|
||
# Das Speicherproblem der Digitalisierung
|
||
|
||
**CD-Qualität (1982):**
|
||
Ziel: Analoge Schallwelle möglichst originalgetreu rekonstruieren
|
||
44.100 Hz × 16 Bit × 2 Kanäle = **10,6 MB/Minute**
|
||
|
||
| Inhalt | Größe | Problem (1990er) |
|
||
|--------|-------|------------------|
|
||
| 1 Song (4 Min) | ~42 MB | Passt gerade so |
|
||
| 1 Album (60 Min) | ~635 MB | Ganze Festplatte! |
|
||
|
||
**→ Digital ist super, aber zu groß für Speicher & Internet**
|
||
|
||
<!--
|
||
"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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
|
||
"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
|
||
|
||
<!--
|
||
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
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# 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
|
||
|
||
<!--
|
||
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
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Lossless vs. Lossy Kompression
|
||
Visualisierung der beiden Philosophien
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Verlustfrei vs. Verlustbehaftet
|
||
|
||
| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
|
||
|---|---|---|
|
||
| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
|
||
| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Daten unwiederbringlich weg) |
|
||
| **Reduktion** | 30-50% | 80-99% |
|
||
| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
|
||
|
||
**Faustregel:**
|
||
* **Medien**, Bilder, Videos, Audio → (tendenziell) verlustbehaftet
|
||
* **Vektorgrafiken**, Textdokumente, Archive, Programmcode → verlustfrei
|
||
|
||
<!--
|
||
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!
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
<!--
|
||
Spektrogramm-Vergleich
|
||
Original vs. 320 kbps vs. 128 kbps
|
||
Hohe Frequenzen verschwinden bei niedriger Bitrate
|
||
Visuell: Dunkle Bereiche = fehlende Frequenzen
|
||
-->
|
||
|
||
---
|
||
|
||
# Der Patentkrieg
|
||
|
||
**1990er:** Fraunhofer + Thomson halten MP3-Patente
|
||
|
||
**Lizenzgebühren:**
|
||
- $0,75 pro Decoder
|
||
- $2,50 pro Encoder
|
||
|
||
**Problem:** Napster (1999) → unkontrollierte Verbreitung
|
||
|
||
**2017:** Patente laufen aus → MP3 ist frei
|
||
|
||
<!--
|
||
Fraunhofer verklagte Winamp, andere Tools
|
||
Millionen nutzten unlizenzierte Software
|
||
Das Pferd war aus dem Stall
|
||
2017: Fraunhofer selbst erklärte MP3 für "veraltet" (AAC besser)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# Napster (1999)
|
||
|
||
**P2P-Filesharing für MP3s**
|
||
|
||
- Shawn Fanning, 19 Jahre alt
|
||
- 80 Millionen User in 2 Jahren
|
||
- Musikindustrie verklagt (2001)
|
||
- Pandora's Box: Nicht mehr aufzuhalten
|
||
|
||
<!--
|
||
P2P = Peer-to-Peer
|
||
Shawn Fanning gründete Napster als Student
|
||
RIAA verklagte Napster, Schließung 2001
|
||
Aber: LimeWire, Kazaa, BitTorrent folgten
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# Napster & Musikindustrie
|
||
|
||
**1999:** Napster startet
|
||
**2001:** 80 Millionen User
|
||
|
||
**Musikindustrie:**
|
||
- CDs kosten $15-20
|
||
- MP3s gratis (illegal, aber 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: aufgabe -->
|
||
|
||
# Hands-On: 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
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Fragen & Diskussion
|
||
|
||
**Kontakt:** mail@librete.ch
|
||
**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
|
||
|
||
---
|
||
|
||
# Lizenz & Attribution
|
||
|
||
Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
|
||
|
||
- Erlaubt Teilen & Anpassen mit Namensnennung
|
||
- Adaptionen müssen unter gleicher Lizenz geteilt werden
|
||
|
||
Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
|
||
|