libretech
75c8476043
- fix course number 223015c → 223015b in termin 1 - adjust language: "fuck" → "heck" in example - add black backgrounds for image-only slides - add bg fit to fullscreen images - update digital-landscape.png - add frontmatter to termin 2-4 slides
845 lines
18 KiB
Markdown
845 lines
18 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>
|
||
section {
|
||
font-size: 1.7rem;
|
||
}
|
||
h2 {
|
||
color: var(--color-dimmed);
|
||
}
|
||
</style>
|
||
|
||
<!-- _class: invert -->
|
||
<!-- _header: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||
|
||
**223015c** · Modul "Technik 1" · 1. Semester
|
||
Digital- und Medienwirtschaft
|
||
Hochschule der Medien Stuttgart
|
||
|
||
**Wintersemester 2025/26**
|
||
|
||
[https://git.librete.ch/hdm/223015b](https://git.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
|
||
```
|
||
|
||
**Was ist das?**
|
||
|
||
<!--
|
||
Hex-Dump ohne Erklärung auf Bildschirm werfen
|
||
Fragen in den Raum: "Was seht ihr?"
|
||
"Ist das Text? Ein Bild? Code?"
|
||
Überleitung: "Alles digital ist nur Zahlen. Heute lernen wir, sie zu lesen."
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _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
|
||
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
|
||
|
||
**8 Bits = 1 Byte**
|
||
|
||
```
|
||
0 1 0 0 1 1 0 1
|
||
```
|
||
|
||
**Wie viele Kombinationen?**
|
||
2⁸ = **256 Möglichkeiten** (0-255)
|
||
|
||
<!--
|
||
BYTE = Wortspiel aus "Bit" + "Bite" (Bissen) – ein "Bissen" Information
|
||
Warum genau 8 Bits?
|
||
- 1964: IBM System/360 setzte diesen Standard (vorher: 6-Bit, 7-Bit Systeme)
|
||
- ASCII (1963) brauchte 7 Bit für 128 Zeichen
|
||
- 8 Bit = praktisch für Hardware (Zweierpotenz: 2³ = 8)
|
||
- 8 Bit = 2 Hexadezimalziffern (elegante Darstellung)
|
||
Eselsbrücke: 1 Byte = 1 Buchstabe (in ASCII/UTF-8 für einfache Zeichen)
|
||
Rechnung: 2×2×2×2×2×2×2×2 = 256 mögliche Kombinationen
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
256 Graustufen: 0 = Schwarz, 255 = Weiß
|
||
-->
|
||
|
||
---
|
||
|
||
# Was kann man mit 256 Zuständen machen?
|
||
|
||
- **256 Zeichen** (Buchstaben, Zahlen, Symbole)
|
||
- **256 Graustufen** (0 = Schwarz, 255 = Weiß)
|
||
- **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: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
RGB = Additive Farbmischung (Bildschirme)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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ß
|
||
|
||
<!--
|
||
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
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
ASCII-Tabelle (1963)
|
||
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
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
Unicode Consortium: Non-Profit seit 1991
|
||
Aktuell: Unicode 16.0 (2024)
|
||
UTF-8 = Unicode Transformation Format, 8-bit
|
||
ASCII-kompatibel: "A" = 1 Byte (rückwärtskompatibel)
|
||
Umlaute: "ä" = 2 Bytes, Chinesisch: 3 Bytes, Emoji: 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
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
<!--
|
||
Hex-Binär-Umrechnungstabelle
|
||
Jede Hex-Ziffer = 4 Bits
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
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
|
||
-->
|
||
|
||
---
|
||
|
||
# Magic Numbers
|
||
|
||
**Dateityp-Identifikation durch erste Bytes**
|
||
|
||
| Format | Magic Number (Hex) | ASCII |
|
||
|--------|-------------------|-------|
|
||
| PNG | `89 50 4E 47 0D 0A 1A 0A` | `.PNG` |
|
||
| JPEG | `FF D8 FF` | `ÿØÿ` |
|
||
| PDF | `25 50 44 46` | `%PDF` |
|
||
| ZIP/DOCX/ODT | `50 4B 03 04` | `PK` |
|
||
|
||
**Achtung:** TXT, HTML, CSS haben **keine** Magic Number!
|
||
|
||
<!--
|
||
Magic Number = Signatur/Fingerabdruck am Dateianfang
|
||
Wozu? Betriebssystem erkennt Dateityp unabhängig von Dateiendung
|
||
|
||
Geschichte: "PK" bei ZIP = Phil Katz (Erfinder von PKZip, 1989)
|
||
Fun Fact: DOCX, XLSX, PPTX, ODT = alles ZIP-Archive mit XML-Inhalt!
|
||
→ Einfach .zip anhängen und entpacken!
|
||
|
||
Dateien OHNE Magic Number: TXT, HTML, CSS, JSON, XML
|
||
→ Diese sind reiner Text, kein binäres Format
|
||
→ Werden anhand Inhalt/Endung erkannt
|
||
|
||
Sicherheits-Aspekt:
|
||
virus.exe → bild.jpg umbenennen täuscht nur Menschen
|
||
Windows vertraut der Endung, aber Tools wie "file" (Linux) lesen Magic Number
|
||
→ Nie Dateien von Fremden öffnen, nur weil sie harmlos aussehen!
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
<!--
|
||
Hex-Editor-Screenshot mit PNG-Datei
|
||
Erste Bytes: 89 50 4E 47 = PNG-Signatur
|
||
IHDR = Image Header (Breite, Höhe, Farbtiefe)
|
||
Zeigen, wie man Magic Number liest
|
||
Tool: HxD (Windows), Hex Fiend (Mac), xxd (Linux)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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 (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
|
||
-->
|
||
|
||
---
|
||
|
||
# Fleißaufgabe bis nächste Woche
|
||
|
||
**Finde eine Datei auf deinem Computer**
|
||
|
||
1. Öffne im Hex-Editor
|
||
2. Schau dir die ersten 16 Bytes an
|
||
3. Identifiziere die Magic Number (falls vorhanden)
|
||
4. Nächste Woche: Kurze Diskussion
|
||
|
||
**Bonus:** Finde Datei ohne Magic Number
|
||
|
||
<!--
|
||
Selbstständiges Experimentieren
|
||
Keine Abgabe, nur zum Ausprobieren
|
||
Nächste Woche kurz besprechen
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 2: Die MP3-Revolution
|
||
## Psychoakustik & Audio-Kompression
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Kassette neben iPod
|
||
Visueller Kontrast: Analog vs. Digital
|
||
1980er vs. 2000er
|
||
-->
|
||
|
||
---
|
||
|
||
# Das Problem (1990)
|
||
|
||
**1 Minute CD-Audio:**
|
||
|
||
- Sample Rate: 44.100 Hz
|
||
- Bit Depth: 16 Bit
|
||
- Stereo: 2 Kanäle
|
||
|
||
**Rechnung:**
|
||
44.100 × 16 × 2 = 1.411.200 Bits/Sekunde
|
||
≈ **10,6 MB/Minute**
|
||
≈ **635 MB für 60-Min-Album**
|
||
|
||
**1990:** Festplatten hatten 100-500 MB!
|
||
|
||
<!--
|
||
CD-Qualität = Standard seit 1982
|
||
Ein Album = ganze Festplatte
|
||
Download bei 56k-Modem = Tage!
|
||
Streaming? Unmöglich.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Lossless vs. Lossy Kompression
|
||
Visualisierung der beiden Philosophien
|
||
-->
|
||
|
||
---
|
||
|
||
# Zwei Philosophien
|
||
|
||
**Lossless (Verlustfrei):**
|
||
- Original exakt wiederherstellbar
|
||
- ZIP, PNG, FLAC
|
||
- 30-50% Ersparnis
|
||
|
||
**Lossy (Verlustbehaftet):**
|
||
- Daten irreversibel verändert
|
||
- JPEG, MP3, H.264
|
||
- 90%+ Ersparnis
|
||
|
||
<!--
|
||
Lossless: Findet Muster, beschreibt effizienter
|
||
Lossy: Wirft "Unwichtiges" weg (Psychoakustik/Psychovisuell)
|
||
Trade-off: Größe vs. Qualität
|
||
-->
|
||
|
||
---
|
||
|
||
# Lossless: Run-Length Encoding
|
||
## Lauflängenkodierung
|
||
|
||
**Original:**
|
||
```
|
||
AAAAABBBCCCCCCCC
|
||
```
|
||
|
||
**Komprimiert:**
|
||
```
|
||
5A 3B 8C
|
||
```
|
||
|
||
**Ersparnis:** 16 → 6 Zeichen (62% Reduktion)
|
||
|
||
<!--
|
||
RLE = Run-Length Encoding = Lauflängenkodierung
|
||
Simplest Compression Algorithm
|
||
Gut für repetitive Daten (Fax, simple Grafiken)
|
||
Schlecht für chaotische Daten (Fotos, Audio)
|
||
-->
|
||
|
||
---
|
||
|
||
# Lossy: Der Trick
|
||
|
||
**Kernidee:** Wirf weg, was der Mensch eh nicht wahrnimmt
|
||
|
||
**JPEG:** Schwächen des Auges
|
||
- Helligkeit besser als Farbe wahrgenommen
|
||
- Große Flächen besser als feine Details
|
||
|
||
**MP3:** Schwächen des Ohrs
|
||
- Mittlere Frequenzen besser als hohe/tiefe
|
||
- Laute Töne "maskieren" leise Töne
|
||
|
||
→ **Psychoakustik / Psychovisuell**
|
||
|
||
<!--
|
||
Auditory Masking: Lauter 1000 Hz-Ton → leise 950 Hz unhörbar
|
||
Visuelle Masking: Starker Kontrast überstrahlt Details
|
||
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?
|
||
|
||
**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
|
||
|
||
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:** Track-Menü → Spektrogramm
|
||
|
||
<!--
|
||
Audacity: FOSS Audio-Editor (audacityteam.org)
|
||
Export: Datei → Exportieren → MP3 → Bitrate wählen
|
||
Spektrogramm-Ansicht: Track-Name klicken → "Spektrogramm"
|
||
Hohe Frequenzen (oben im Bild) verschwinden bei niedriger Bitrate
|
||
Alternative: Spek (spek.cc) – reiner Spektrogramm-Viewer
|
||
-->
|
||
|
||
---
|
||
|
||
# Fleißaufgabe bis nächste Woche
|
||
|
||
**Nimm ein Lied (eigenes oder CC)**
|
||
|
||
1. Exportiere: WAV, MP3 320 kbps, MP3 128 kbps
|
||
2. Höre die Unterschiede (Kopfhörer!)
|
||
3. Vergleiche die Dateigrößen
|
||
|
||
**Bonus:** Niedrigste Bitrate finden, bei der du keinen Unterschied hörst
|
||
|
||
<!--
|
||
Selbstständiges Experimentieren
|
||
Keine Abgabe, nur zum Ausprobieren
|
||
Goldenes Ohr: Manche hören Unterschied, manche nicht
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Fragen & Diskussion
|
||
|
||
**Kontakt:** mail@librete.ch
|
||
**Folien:** Online verfügbar unter https://hdm.librete.ch
|
||
|
||
---
|
||
|
||
# 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/
|
||
|