1301 lines
31 KiB
Markdown
1301 lines
31 KiB
Markdown
---
|
||
marp: true
|
||
theme: gaia
|
||
paginate: true
|
||
backgroundColor: #fff
|
||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
|
||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||
---
|
||
|
||
<style>
|
||
:root {
|
||
--color-foreground: #1a1a2e;
|
||
--color-highlight: #1e5f8a;
|
||
--color-dimmed: #4a4a6a;
|
||
}
|
||
section.invert {
|
||
--color-foreground: #fff;
|
||
}
|
||
section {
|
||
font-size: 1.7rem;
|
||
}
|
||
h1 {
|
||
color: #1e5f8a;
|
||
}
|
||
section.invert h1 {
|
||
color: #fff;
|
||
}
|
||
h2 {
|
||
color: #1f2937;
|
||
}
|
||
pre {
|
||
background: #0f0f23;
|
||
color: #1e5f8a;
|
||
border-radius: 8px;
|
||
border-left: 3px solid #1e5f8a;
|
||
}
|
||
pre code {
|
||
background: transparent;
|
||
color: inherit;
|
||
}
|
||
code {
|
||
background: #1a1a2e;
|
||
color: #1e5f8a;
|
||
padding: 0.15em 0.4em;
|
||
border-radius: 4px;
|
||
}
|
||
a {
|
||
color: var(--color-highlight);
|
||
}
|
||
section.klausur {
|
||
background: #e3f2fd !important;
|
||
}
|
||
section.klausur footer {
|
||
display: none;
|
||
}
|
||
</style>
|
||
|
||
<!-- _class: invert -->
|
||
<!-- _header: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
# 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 -->
|
||
|
||
# Termin 1 – 19.12.2025
|
||
## 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
|
||
```
|
||
|
||
<!--
|
||
|
||
"Ich schaue in viele fragende Gesichte ..."
|
||
|
||
"Doch vertraut mir, am Ende der heutigen Veranstaltung werdet ihr mir genau sagen können was hier steht"
|
||
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# 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 warum somit ein Neologismus, bis dato gab es das Wort in dieser Bedeutung überhaupt nicht"
|
||
|
||
Shannon war Mathematiker bei Bell Labs – begründete die Informationstheorie
|
||
|
||
Warum binär? Elektronische Schaltungen haben nur 2 Zustände: Strom/kein Strom
|
||
Das ist physikalisch am stabilsten (weniger Fehler als 3 oder 10 Zustände)
|
||
Alles Digitale basiert auf dieser simplen Idee: AN oder AUS
|
||
Transistoren in modernen CPUs: Milliarden davon, schalten Milliarden Mal pro Sekunde
|
||
-->
|
||
|
||
---
|
||
|
||
# Das Byte
|
||
|
||
<!--
|
||
"Ein Bit allein macht nicht glücklich, die Welt ist nunmal nicht schwarz oder weiß"
|
||
|
||
"Und um noch weitere (nennen wir es Schattierungen, ganz literarisch) der Welt abbilden zu können, benötigen wir eine weiter Messgröße oder Einheit"
|
||
|
||
BYTE = Wortspiel aus "Bit" + "Bite" (Bissen) – ein "Bissen" Information
|
||
|
||
"Doch warum hat man nicht einfach »Bite« genommen?" Fangfrage -> Bit und Bite sind sich zu nahe ... Verwechslungsgefahr!
|
||
-->
|
||
|
||
---
|
||
|
||
# Das Byte
|
||
|
||
**1 Byte = 8 Bits**
|
||
|
||
```
|
||
0 1 0 0 1 1 0 1
|
||
```
|
||
|
||
<!--
|
||
|
||
"Und das sieht dann so aus"
|
||
|
||
"Aber warum genau 8 Bits?" -> "Das versteht man leider erst so richtig wenn man sich das Ergebnis anschaut, wie viele Möglichkeiten hieraus entstehen"
|
||
|
||
"Menschen neigen dazu, exponentielles Wachstum zu unterschätzen"
|
||
|
||
Rätsel: "Wenn sich das Wachstum einer Seerose auf einem Teich jeden Tag verdoppelt · und nach *zehn Tagen* der ganze Teich bedeckt ist, wann ist er zur Hälfte zugewachsen?"
|
||
|
||
Frage: "Weiß jemand wieviele Zustände wir mit 8 Bit beschreiben können?"
|
||
|
||
-->
|
||
|
||
---
|
||
|
||
# Das Byte
|
||
|
||
**1 Byte = 8 Bits**
|
||
|
||
```
|
||
0 1 0 0 1 1 0 1
|
||
```
|
||
|
||
2⁸ = **256 Möglichkeiten** (0-255)
|
||
|
||
<!--
|
||
|
||
Historie: "Es gab durchaus einen »Machtkampf« und es war überhaupt nicht klar welche Länge sich durchsetzen wird."
|
||
|
||
- 1964: IBM System/360 setzte diesen Standard (vorher: 6-Bit, 7-Bit Systeme)
|
||
- ASCII (1963) brauchte 7 Bit für 128 Zeichen
|
||
|
||
ASCII = American Standard Code for Information Interchange
|
||
|
||
Praktikabilität:
|
||
- 8 Bit = praktisch für Hardware (Zweierpotenz: 2³ = 8)
|
||
- 8 Bit = 2 Hexadezimalziffern (elegante Darstellung)
|
||
|
||
1 Bit = 2 Zustände
|
||
2 Bit = 4 Zustände
|
||
3 Bit = 8 Zustände
|
||
4 Bit = 16 Zustände
|
||
5 Bit = 32 Zustände
|
||
6 Bit = 64 Zustände
|
||
7 Bit = 128 Zustände
|
||
8 Bit = 256 Zustände
|
||
|
||
Rechnung: 2×2×2×2×2×2×2×2 = 256 mögliche Kombinationen
|
||
|
||
von griech. hexa „sechs“ und lat. decem „zehn“
|
||
|
||
Eselsbrücke: 1 Byte = 1 Buchstabe/Symbol (in ASCII/UTF-8 für einfache Zeichen)
|
||
-->
|
||
|
||
---
|
||
|
||
# Dateneinheiten
|
||
|
||
| Einheit | Bytes | Bits | Potenz |
|
||
|---------|-------|------|--------|
|
||
| **1 Byte** | 1 | 8 | 10⁰ |
|
||
| **1 Kilobyte (KB)** | 1.000 | 8.000 | 10³ |
|
||
| **1 Megabyte (MB)** | 1.000.000 | 8 Mio. | 10⁶ |
|
||
| **1 Gigabyte (GB)** | 1 Mrd. | 8 Mrd. | 10⁹ |
|
||
| **1 Terabyte (TB)** | 1 Bio. | 8 Bio. | 10¹² |
|
||
|
||
<!--
|
||
SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes
|
||
Binär (IEC): 1 KiB = 1.024 Bytes (Kibibyte)
|
||
Windows zeigt oft binär, sagt aber "KB" → Verwirrung!
|
||
1 TB Festplatte = ~931 GiB nutzbar
|
||
-->
|
||
|
||
---
|
||
|
||
# Dateneinheiten (Fortsetzung)
|
||
|
||
| Einheit | Bytes | Potenz | Beispiel |
|
||
|---------|-------|--------|----------|
|
||
| **1 Petabyte (PB)** | 10¹⁵ | 1.000 TB | Netflix-Gesamtarchiv |
|
||
| **1 Exabyte (EB)** | 10¹⁸ | 1.000 PB | Alle E-Mails weltweit/Tag |
|
||
| **1 Zettabyte (ZB)** | 10²¹ | 1.000 EB | Internet-Traffic 2016 |
|
||
| **1 Yottabyte (YB)** | 10²⁴ | 1.000 ZB | *Noch nie erreicht* |
|
||
|
||
<!--
|
||
Peta = 10^15 (Billiarde)
|
||
Exa = 10^18 (Trillion)
|
||
Zetta = 10^21 (Trilliarde)
|
||
Yotta = 10^24 (Quadrillion)
|
||
|
||
Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
|
||
→ "Komm Mit Großem Tee, Peter Exte Zettelt Yachten"
|
||
-->
|
||
|
||
---
|
||
|
||
# Datenwachstum der Menschheit
|
||
|
||
| Jahr | Datenmenge | Kontext |
|
||
|------|------------|---------|
|
||
| **100.000 v. Chr.** | 0 | Erste Menschen, nur Sprache |
|
||
| **3.000 v. Chr.** | ~wenige KB | Keilschrift, Hieroglyphen |
|
||
| **1450** | ~wenige GB | Gutenberg, Buchdruck |
|
||
| **1986** | **2,6 EB** | 99% analog (Bücher, Vinyl, VHS) |
|
||
| **2007** | **295 EB** | 94% digital |
|
||
| **2025** | **181 ZB** | 90% unstrukturiert |
|
||
|
||
<!--
|
||
Exponentielles Wachstum: Verdopplung alle 2 Jahre
|
||
1986: Letzte Ära mit analoger Dominanz
|
||
2007: Erste Jahr, in dem digital > analog
|
||
2025: 181 ZB = 181.000.000.000.000.000.000.000 Bytes
|
||
Analog blieb bei ~2,6 EB stehen (Bücher, Vinyl, Film)
|
||
Digital explodierte: IoT, Social Media, Cloud, Video
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Der digitale Wendepunkt
|
||
|
||
| Jahr | Analog | Digital | Digital-Anteil |
|
||
|------|--------|---------|----------------|
|
||
| **1986** | 2,6 EB | 0,02 EB | **1%** |
|
||
| **2002** | — | — | **50%** (Wendepunkt) |
|
||
| **2007** | 18 EB | 277 EB | **94%** |
|
||
|
||
**Perspektive:**
|
||
- 1986: "Petabyte" war ein theoretisches Konzept
|
||
- 2025: ~181 Zettabyte jährlich produziert
|
||
|
||
**Magnetband lebt:** LTO-Tapes bleiben günstigstes Archivmedium
|
||
(AWS Glacier, Film-Archive, Rechenzentren)
|
||
|
||
<!--
|
||
QUELLE: Hilbert & López (2011): "The World's Technological Capacity to Store, Communicate, and Compute Information", Science
|
||
METHODIK: 60 analoge + digitale Technologien untersucht (1986-2007)
|
||
WENDEPUNKT 2002: Erstmals mehr digital als analog gespeichert
|
||
ANALOG damals: Bücher, Zeitungen, Vinyl, VHS, Filmrollen, Fotos
|
||
DIGITAL damals: Festplatten, CDs, DVDs, frühe Flash-Speicher
|
||
HEUTE: LTO-9 (2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
|
||
VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
|
||
PRÜFUNGSRELEVANT: Wendepunkt 2002, Speichereinheiten (KB→MB→GB→TB→PB→EB→ZB), Magnetband als Archivmedium
|
||
-->
|
||
|
||
---
|
||
|
||
# 181 Zettabyte – Was bedeutet das?
|
||
|
||
**2025:** Welt erzeugt **181 ZB** pro Jahr
|
||
|
||
- **2,5 Quintillionen Bytes** täglich
|
||
- **29 Terabyte** pro Sekunde
|
||
- **90%** davon: unstrukturiert (Videos, Bilder, Audio)
|
||
- **70%** davon: von Nutzern generiert
|
||
|
||
**Zum Vergleich:**
|
||
- 1 ZB = 250 Milliarden DVDs
|
||
- 181 ZB = Jeder Mensch erzeugt ~23 TB/Jahr
|
||
|
||
<!--
|
||
Quellen: IDC Global DataSphere Forecast, Statista 2025
|
||
IoT-Geräte allein: 73 ZB in 2025
|
||
Cloud-Speicher: 100 ZB (50% der Weltdaten)
|
||
Prognose 2028: 394 ZB
|
||
-->
|
||
|
||
---
|
||
|
||
# AI-generierte Inhalte 2025
|
||
|
||
**Wie viel Content ist heute synthetisch?**
|
||
|
||
| Bereich | AI-Anteil |
|
||
|---------|-----------|
|
||
| **Neue Webseiten** | ~74% enthalten AI-Content |
|
||
| **Web-Text gesamt** | ~30-40% AI-generiert |
|
||
| **Neue Artikel** | ~52% von AI geschrieben |
|
||
| **Social-Media-Bilder** | ~71% AI-generiert |
|
||
|
||
**Prognose 2026:** 90% des Online-Contents synthetisch
|
||
|
||
<!--
|
||
Quellen: Ahrefs 2025, arXiv, Europol-Report
|
||
"Synthetic Media" = AI-generiert oder -manipuliert
|
||
Problem: Schwer zu messen, da Menschen + AI zusammenarbeiten
|
||
Model Collapse: AI trainiert auf AI-Output → Qualitätsverlust
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# ASCII
|
||
## Ein Zeichensatz to rule them all
|
||
|
||
<!--
|
||
WARUM 7 BIT STATT 8?
|
||
- 1963: Fernschreiber (Teletype) arbeiteten mit 7-Bit-Codes
|
||
- Das 8. Bit diente der Paritätsprüfung (Fehlererkennung bei Übertragung)
|
||
- Speicher war kostspielig: jedes eingesparte Bit zählte
|
||
- 128 Zeichen galten als ausreichend für den englischsprachigen Raum
|
||
|
||
KULTURHISTORISCHER KONTEXT:
|
||
- "American Standard Code for Information Interchange" (1963)
|
||
- Entwickelt für US-amerikanische Bedürfnisse
|
||
- Keine Unterstützung für: Umlaute (ä, ö, ü), ß, diakritische Zeichen (é, ñ, ç)
|
||
- Nicht-lateinische Schriftsysteme (Kyrillisch, Arabisch, CJK) wurden nicht berücksichtigt
|
||
- Führte zu zahlreichen inkompatiblen Erweiterungen (ISO-8859-1, Windows-1252, etc.)
|
||
|
||
WARUM NOCH HEUTE RELEVANT?
|
||
- Abwärtskompatibilität: UTF-8 ist vollständig ASCII-kompatibel (Zeichen 0-127 identisch)
|
||
- Internetprotokolle basieren auf ASCII: HTTP-Header, SMTP, URLs
|
||
- Programmiersprachen: Schlüsselwörter und Syntax sind ASCII
|
||
- Ein 60 Jahre alter Standard, der durch Kompatibilitätszwänge fortbesteht
|
||
|
||
HISTORISCHE RANDNOTIZ:
|
||
- Das @-Zeichen wurde nachträglich aufgenommen
|
||
- Heute unverzichtbar für E-Mail-Adressen weltweit
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
|
||
<!--
|
||
|
||
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)
|
||
|
||
* *Fällt Euch noch mehr ein?*
|
||
|
||
<!--
|
||
256 = die "magische Zahl" bei 8 Bit
|
||
Alltagsbeispiele:
|
||
- Lautstärkeregler (0 = stumm, 255 = max)
|
||
- Helligkeitswerte in Bildern (0 = schwarz, 255 = weiß)
|
||
- Alter in Jahren (0-255 reicht für Menschen locker)
|
||
- Zeichen (ASCII erweitert: 256 Buchstaben/Symbole)
|
||
Für Farbbilder: 3 Bytes pro Pixel (R, G, B)
|
||
Jeder Kanal 0-255 → 256³ = 16.777.216 Farben ("True Color")
|
||
Das menschliche Auge kann etwa 10 Millionen Farben unterscheiden
|
||
→ 24 Bit reicht für fotorealistische Bilder
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
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 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
|
||
|
||
**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
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# Hands-On: WTF Files
|
||
|
||
**Aufgabe (30 Min):**
|
||
|
||
1. Drei Dateien ohne Extension: `wtf1`, `wtf2`, `wtf3`
|
||
→ Download: `materials/` Ordner
|
||
2. Öffne im Hex-Editor
|
||
3. Lies erste 16 Bytes
|
||
4. Identifiziere Format (Magic Number)
|
||
5. Benenne um und öffne
|
||
|
||
**Tools:** [hexed.it](https://hexed.it) (online), HxD, Hex Fiend, Bless
|
||
|
||
<!--
|
||
Praktische Phase: Studierende arbeiten selbst
|
||
Dateien im materials/ Ordner:
|
||
- wtf1: Plaintext (keine Magic Number)
|
||
- wtf2: PNG (89 50 4E 47)
|
||
- wtf3: JPEG (FF D8 FF)
|
||
Gruppenarbeit: 3-4 Personen
|
||
Ziel: Hex-Dump lesen lernen, Dateiformate verstehen
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 2: Die MP3-Revolution
|
||
## Psychoakustik & Audio-Kompression
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Kassette neben iPod
|
||
Visueller Kontrast: Analog vs. Digital
|
||
1980er vs. 2000er
|
||
-->
|
||
|
||
---
|
||
|
||
# Warum digital? Das Speicherproblem
|
||
|
||
**Analog → Digital:** Kopieren ohne Qualitätsverlust, aber...
|
||
|
||
**CD-Qualität (1982):**
|
||
44.100 Hz × 16 Bit × 2 Kanäle = **10,6 MB/Minute**
|
||
|
||
| Inhalt | Größe | Problem (1990er) |
|
||
|--------|-------|------------------|
|
||
| 1 Song (4 Min) | ~42 MB | Passt gerade so |
|
||
| 1 Album (60 Min) | ~635 MB | Ganze Festplatte! |
|
||
|
||
**→ Digital ist super, aber zu groß für Speicher & Internet**
|
||
|
||
<!--
|
||
WARUM DIGITAL?
|
||
- Kopieren ohne Generationsverlust (Kassette → Kassette = schlechter)
|
||
- Perfekte Archivierung
|
||
- Bearbeitung möglich
|
||
|
||
DAS PROBLEM:
|
||
- CD = unkomprimiert, riesig
|
||
- Festplatten 1990: 100-500 MB
|
||
- Internet 1995: 56k Modem = 1 Song = Stunden
|
||
- Streaming? Unmöglich
|
||
|
||
LÖSUNG: Kompression (MP3, 1993)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
|
||
"Wenn CDs eine Sample Rate von 44kHz haben, was fällt dann hier auf?"
|
||
|
||
Fangfrage: "Wie hoch ist die Sample Rate von Vinyls?" -> *Vinyl has no sample rate. It's analog!*
|
||
|
||
-->
|
||
|
||
---
|
||
|
||
# Was ist Sample Rate?
|
||
**Analog → Digital ≙ Kontinuierlich → Diskret**
|
||
```
|
||
Analog (Vinyl): Digital (CD):
|
||
~~~~~~~~~~~~~~~ • • • • • • • •
|
||
Kontinuierliche 44.100 Messpunkte
|
||
Wellenform pro Sekunde
|
||
```
|
||
**Nyquist-Theorem:**
|
||
|
||
> Um eine Frequenz zu rekonstruieren, braucht man mindestens **2× so viele Samples**.
|
||
44.100 Hz ÷ 2 = **22.050 Hz** max. darstellbare Frequenz
|
||
(Mensch hört: ~20 Hz bis ~20.000 Hz → passt!)
|
||
|
||
<!--
|
||
SAMPLE RATE = Wie oft "fotografieren" wir die Schallwelle?
|
||
Stellt euch vor: Schallwelle = fahrendes Auto
|
||
- Analog: Videokamera läuft durchgehend
|
||
- Digital: Fotokamera macht 44.100 Fotos pro Sekunde
|
||
|
||
VINYL hat KEINE Sample Rate:
|
||
- Rille ist physische Kopie der Welle
|
||
- "Unendliche Auflösung" in der Theorie
|
||
- ABER: Rauschen, Kratzer, Nadelmasse = eigene Limits
|
||
- Praktisch: ~20 Hz bis ~20 kHz, 60-70 dB Dynamik
|
||
|
||
WARUM genau 44.100 Hz?
|
||
- Nyquist: 2× höchste hörbare Frequenz nötig
|
||
- 20.000 Hz × 2 = 40.000 Hz Minimum
|
||
- 44.100 = etwas Puffer + passte zu Video-Equipment der 80er
|
||
|
||
DAS SPEKTROGRAMM zeigt es:
|
||
- Alles über ~22 kHz ist abgeschnitten
|
||
- Das ist kein Bug, das ist das Design!
|
||
- Vinyl hätte dort noch Obertöne (die wir eh nicht hören)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Kompression
|
||
## Weniger Daten, gleiche(?) Information
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Lossless vs. Lossy Kompression
|
||
Visualisierung der beiden Philosophien
|
||
-->
|
||
|
||
---
|
||
|
||
# Sample Rate vs. Bit Depth
|
||
|
||
**Zwei Dimensionen der Digitalisierung:**
|
||
|
||
| Dimension | Was bedeutet es? | CD-Qualität |
|
||
|-----------|------------------|-------------|
|
||
| **Sample Rate** | Messungen pro Sekunde (horizontal) | 44.100 Hz |
|
||
| **Bit Depth** | Genauigkeit pro Messung (vertikal) | 16 Bit |
|
||
|
||
**16 Bit = 2¹⁶ = 65.536 Lautstärkestufen**
|
||
(von absoluter Stille bis maximaler Lautstärke)
|
||
|
||
<!--
|
||
Analogie: Digitalisierung = Raster über Schallwelle legen
|
||
|
||
HORIZONTAL (Sample Rate):
|
||
- Wie oft messen wir pro Sekunde?
|
||
- 44.100 Hz = 44.100 Messpunkte pro Sekunde
|
||
- Bestimmt, welche FREQUENZEN wir erfassen können
|
||
- Nyquist-Theorem: Sample Rate ≥ 2× höchste Frequenz
|
||
- 44.100 Hz → max. ~22.050 Hz (Mensch hört bis ~20.000 Hz)
|
||
|
||
VERTIKAL (Bit Depth):
|
||
- Wie genau messen wir jeden Punkt?
|
||
- 16 Bit = 65.536 mögliche Werte (-32.768 bis +32.767)
|
||
- Bestimmt den DYNAMIKUMFANG (leise bis laut)
|
||
- 16 Bit ≈ 96 dB Dynamik (Flüstern bis Rockkonzert)
|
||
- Mehr Bits = feinere Abstufungen = weniger Quantisierungsrauschen
|
||
|
||
KOMPRESSION nutzt beide Achsen:
|
||
- Sample Rate reduzieren = weniger Punkte horizontal (spart Daten, verliert hohe Frequenzen)
|
||
- Bit Depth reduzieren = gröbere Stufen vertikal (spart Daten, mehr Rauschen)
|
||
- MP3: Wirft unhörbare Frequenzen weg + quantisiert grober wo es nicht auffällt
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Verlustfrei vs. Verlustbehaftet
|
||
|
||
| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
|
||
|---|---|---|
|
||
| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
|
||
| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Daten unwiederbringlich weg) |
|
||
| **Reduktion** | 30-50% | 80-99% |
|
||
| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
|
||
|
||
**Faustregel:** Code/Archiv → verlustfrei · Medien → verlustbehaftet
|
||
|
||
<!--
|
||
REDUNDANZ: Wiederholende Muster kompakter darstellen (z.B. "AAAA" → "4×A")
|
||
IRRELEVANZ: Für Menschen nicht wahrnehmbar (Psychoakustik, Psychovisuell)
|
||
|
||
KLAUSURRELEVANT:
|
||
- Verlustfrei = Original 1:1 wiederherstellbar
|
||
- Verlustbehaftet = Information geht verloren, aber kaum wahrnehmbar
|
||
- Redundanz vs. Irrelevanz ist der Kernunterschied!
|
||
-->
|
||
|
||
---
|
||
|
||
# Verlustfrei: Lauflängenkodierung (RLE)
|
||
|
||
**Original:** `AAAAABBBCCCCCCCC` (16 Zeichen)
|
||
|
||
**Komprimiert:** `5A3B8C` (6 Zeichen) → **62% kleiner**
|
||
|
||
**Prinzip:** Wiederholungen zählen statt wiederholen
|
||
|
||
<!--
|
||
RLE = Run-Length Encoding = Lauflängenkodierung
|
||
Einfachster Kompressionsalgorithmus
|
||
Gut für: Fax, einfache Grafiken, Icons
|
||
Schlecht für: Fotos, Audio (zu chaotisch)
|
||
-->
|
||
|
||
---
|
||
|
||
# Verlustbehaftet: Der Trick
|
||
|
||
**Kernidee:** Entferne, was Menschen nicht wahrnehmen
|
||
|
||
| Format | Nutzt Schwächen von... | Fachbegriff |
|
||
|--------|------------------------|-------------|
|
||
| **JPEG** | Auge (Farbe < Helligkeit) | Psychovisuell |
|
||
| **MP3** | Ohr (Maskierungseffekte) | Psychoakustik |
|
||
|
||
<!--
|
||
PSYCHOVISUELL (JPEG):
|
||
- Auge nimmt Helligkeit besser wahr als Farbe
|
||
- Große Flächen besser als feine Details
|
||
- Daher: Farbinformation stärker komprimiert
|
||
|
||
PSYCHOAKUSTIK (MP3):
|
||
- Mittlere Frequenzen besser als hohe/tiefe
|
||
- Laute Töne "maskieren" leise Töne in der Nähe
|
||
- Auditory Masking: Lauter 1000 Hz-Ton → leise 950 Hz unhörbar
|
||
|
||
KERNKONZEPT: Kompression = Modell der menschlichen Wahrnehmung
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# Karlheinz Brandenburg
|
||
|
||
**"Vater der MP3"**
|
||
|
||
* Diplom-Ingenieur, Universität Erlangen-Nürnberg
|
||
* Fraunhofer IIS (Institut für Integrierte Schaltungen)
|
||
* Forschung ab 1982, Patent 1988
|
||
* Hörte "Tom's Diner" über 10.000 Mal
|
||
|
||
<!--
|
||
Fraunhofer IIS Erlangen
|
||
Forschung dauerte über 10 Jahre
|
||
Perfektionist: Jeder Hörtest musste bestehen
|
||
-->
|
||
|
||
---
|
||
|
||
# Die Geburt der MP3
|
||
|
||
**1982:** Universität Erlangen-Nürnberg
|
||
Karlheinz Brandenburg, Diplom-Ingenieur
|
||
|
||
**1987:** Fraunhofer IIS entwickelt MPEG-1 Audio Layer III
|
||
|
||
**1988:** Patentanmeldung
|
||
|
||
**1992:** Erste Software-Implementierung
|
||
|
||
**1995:** .mp3 Dateiendung offiziell
|
||
|
||
<!--
|
||
MPEG = Moving Picture Experts Group
|
||
Layer III = Dritte Verfeinerungsstufe
|
||
Forschung dauerte 10 Jahre
|
||
Patent lief 2017 aus
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# Suzanne Vega
|
||
|
||
**"Tom's Diner" (1987)**
|
||
|
||
- A cappella (keine Instrumente)
|
||
- Klare, hohe Frequenzen
|
||
- Perfekter Stresstest für Kompression
|
||
- Der erste Song, der als MP3 kodiert wurde
|
||
|
||
<!--
|
||
Suzanne Vega – "Tom's Diner" (1987)
|
||
A cappella = einfacher zu analysieren (nur Stimme)
|
||
Hohe Frequenzen = Herausforderung für Kompression
|
||
Brandenburg hörte den Song über 10.000 Mal
|
||
-->
|
||
|
||
---
|
||
|
||
# "Tom's Diner"
|
||
|
||
**Warum dieser Song?**
|
||
|
||
- A cappella (keine Instrumente)
|
||
- Suzanne Vegas Stimme ist "schwierig"
|
||
- Klare, hohe Frequenzen → Stresstest
|
||
|
||
> If I could code Suzanne Vega's voice well, I could code anything.
|
||
— Karlheinz Brandenburg
|
||
|
||
<!--
|
||
Brandenburg hörte Song 10.000+ Mal
|
||
A cappella = einfacher zu analysieren (nur Stimme)
|
||
Hohe Frequenzen = Herausforderung für Kompression
|
||
Perfektionismus: Jeder Hörtest musste bestehen
|
||
-->
|
||
|
||
---
|
||
|
||
# Wie funktioniert MP3?
|
||
|
||
Ein Zusammenspiel aus vielen Faktoren:
|
||
|
||
* **1. Frequenz-Analyse (FFT)**
|
||
Audio → Frequenzspektrum
|
||
|
||
* **2. Psychoakustisches Modell**
|
||
Welche Töne hört Mensch nicht?
|
||
|
||
* **3. Quantisierung**
|
||
Unwichtige Frequenzen reduzieren
|
||
|
||
* **4. Huffman-Coding**
|
||
Lossless-Kompression der Restdaten
|
||
|
||
<!--
|
||
MP3-Kompression in 4 Schritten (vereinfacht):
|
||
|
||
1. FFT (Fast Fourier Transform)
|
||
- Wandelt Schallwellen in Frequenzen um
|
||
- Wie ein Prisma Licht in Farben zerlegt
|
||
|
||
2. Psychoakustisches Modell
|
||
- Fragt: "Was kann ein Mensch NICHT hören?"
|
||
- Maskierungseffekte: Lauter Ton verdeckt leisen daneben
|
||
- Hohe/tiefe Frequenzen werden schlechter wahrgenommen
|
||
|
||
3. Quantisierung (hier passiert der Datenverlust!)
|
||
- Unwichtige Frequenzen werden "grob" gespeichert
|
||
- Wichtige Frequenzen bleiben genau
|
||
- Wie JPEG: Details entfernen, wo es nicht auffällt (Kontrast/Helligkeit bleibt)
|
||
|
||
4. Huffman-Coding (verlustfrei)
|
||
- Häufige Muster = kurze Codes
|
||
- Seltene Muster = lange Codes
|
||
- Finaler Effizienz-Boost
|
||
|
||
MP3 ist KEIN einfaches "Kleiner machen"
|
||
→ Es simuliert, wie dein Gehirn Musik verarbeitet!
|
||
-->
|
||
|
||
---
|
||
|
||
# Bitrate: Der Qualitäts-Knopf
|
||
|
||
| Bitrate | Qualität | Kompression |
|
||
|---------|----------|-------------|
|
||
| **128 kbps** | Hörbar schlechter | ~11x |
|
||
| **192 kbps** | Akzeptabel | ~7x |
|
||
| **256 kbps** | Gut | ~5,5x |
|
||
| **320 kbps** | "CD-Qualität" | ~4,4x |
|
||
|
||
**Original CD:** 1.411 kbps (unkomprimiert)
|
||
|
||
<!--
|
||
kbps = Kilobit pro Sekunde
|
||
128 kbps = Standard in 2000ern (Napster-Ära)
|
||
320 kbps = Maximum für MP3
|
||
Höhere Bitrate = mehr Daten = bessere Qualität
|
||
Aber: Diminishing Returns ab 256 kbps
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
<!--
|
||
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 egal)
|
||
- Einzelne Songs statt Alben
|
||
|
||
**2001:** Napster verklagt, geschlossen
|
||
|
||
**Aber:** Pandora's Box offen
|
||
→ LimeWire, Kazaa, BitTorrent, später Spotify
|
||
|
||
<!--
|
||
RIAA (Recording Industry Association of America) verklagte Napster
|
||
Urteil: Napster muss schließen (2001)
|
||
Aber: Technologie nicht mehr aufzuhalten
|
||
iPod (2001): "1.000 songs in your pocket"
|
||
iTunes Store (2003): Legale Alternative
|
||
Spotify (2008): Streaming-Ära beginnt
|
||
-->
|
||
|
||
---
|
||
|
||
# Kulturelle Revolution
|
||
|
||
**MP3 veränderte:**
|
||
|
||
✓ Musik wurde portabel (Walkman → iPod)
|
||
✓ Alben wurden irrelevant (Playlists)
|
||
✓ Musikkonsum explodierte (kostenlos/billig)
|
||
✓ Künstler verloren Kontrolle
|
||
|
||
**Aber auch:**
|
||
❌ Künstler verdienen weniger pro Stream
|
||
❌ Audio-Qualität sank (Loudness War)
|
||
❌ Physische Medien starben
|
||
|
||
<!--
|
||
Walkman (1979): Kassetten
|
||
Discman (1984): CDs
|
||
iPod (2001): MP3s
|
||
Spotify (2008): Streaming
|
||
Künstler-Einkommen: Album-Verkauf → Streaming-Pennies
|
||
Loudness War: Alles wird lauter gemastert (Dynamik verloren)
|
||
Vinyl-Revival: 2020er Gegenbewegung
|
||
-->
|
||
|
||
---
|
||
|
||
# Hands-On: MP3 sezieren
|
||
|
||
**Aufgabe (30 Min):**
|
||
|
||
1. Lade Lied runter (eigenes oder CC)
|
||
2. Konvertiere in verschiedene Bitraten:
|
||
- 320 kbps, 128 kbps, 64 kbps
|
||
3. Tool: **Audacity** (kostenlos)
|
||
4. Höre Unterschiede (Kopfhörer!)
|
||
5. Vergleiche Dateigrößen
|
||
|
||
**Spektrogramm:** Klick auf Track-Name → Spektrogramm
|
||
[https://manual.audacityteam.org/man/spectrogram_view.html](https://manual.audacityteam.org/man/spectrogram_view.html)
|
||
|
||
<!--
|
||
Audacity: FOSS Audio-Editor (audacityteam.org)
|
||
Export: Datei → Exportieren → MP3 → Bitrate wählen
|
||
Spektrogramm-Ansicht: Auf Track-Name klicken (Dropdown öffnet sich) → "Spektrogramm" wählen
|
||
Hohe Frequenzen (oben im Bild) verschwinden bei niedriger Bitrate
|
||
Alternative: Spek (spek.cc) – reiner Spektrogramm-Viewer
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Fragen & Diskussion
|
||
|
||
**Kontakt:** mail@librete.ch
|
||
**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
|
||
|
||
---
|
||
|
||
# Lizenz & Attribution
|
||
|
||
Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
|
||
|
||
- Erlaubt Teilen & Anpassen mit Namensnennung
|
||
- Adaptionen müssen unter gleicher Lizenz geteilt werden
|
||
|
||
Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
|
||
|