1898 lines
50 KiB
Markdown
1898 lines
50 KiB
Markdown
---
|
||
marp: true
|
||
theme: gaia
|
||
paginate: true
|
||
backgroundColor: #fff
|
||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||
---
|
||
|
||
<style>
|
||
:root {
|
||
--color-foreground: #1a1a2e;
|
||
--color-highlight: #1e5f8a;
|
||
--color-dimmed: #4a4a6a;
|
||
}
|
||
section.invert {
|
||
--color-foreground: #fff;
|
||
}
|
||
section {
|
||
font-size: 1.7rem;
|
||
}
|
||
h1 {
|
||
color: #1e5f8a;
|
||
}
|
||
section.invert h1 {
|
||
color: #fff;
|
||
}
|
||
h2 {
|
||
color: #1f2937;
|
||
}
|
||
pre {
|
||
background: #0f0f23;
|
||
color: #5fb3e4;
|
||
border-radius: 8px;
|
||
border-left: 3px solid #1e5f8a;
|
||
}
|
||
pre code {
|
||
background: transparent;
|
||
color: inherit;
|
||
}
|
||
code {
|
||
background: #1a1a2e;
|
||
color: #5fb3e4;
|
||
padding: 0.15em 0.4em;
|
||
border-radius: 4px;
|
||
}
|
||
a {
|
||
color: var(--color-highlight);
|
||
}
|
||
section.klausur {
|
||
background: repeating-linear-gradient(
|
||
135deg,
|
||
#e3f2fd,
|
||
#e3f2fd 40px,
|
||
#fff 40px,
|
||
#fff 80px
|
||
) !important;
|
||
}
|
||
@media print {
|
||
section.klausur {
|
||
background: #e3f2fd !important;
|
||
}
|
||
}
|
||
section.aufgabe {
|
||
background: #e3f2fd !important;
|
||
}
|
||
section.aufgabe footer {
|
||
display: none;
|
||
}
|
||
section.erklaerung {
|
||
font-size: 1.1rem;
|
||
background: repeating-linear-gradient(
|
||
135deg,
|
||
#e3f2fd,
|
||
#e3f2fd 40px,
|
||
#fff 40px,
|
||
#fff 80px
|
||
) !important;
|
||
}
|
||
@media print {
|
||
section.erklaerung {
|
||
background: #e3f2fd !important;
|
||
}
|
||
}
|
||
section.erklaerung h1 {
|
||
font-size: 1.5rem;
|
||
color: #1e5f8a;
|
||
margin-bottom: 0.3rem;
|
||
}
|
||
section.erklaerung ul,
|
||
section.erklaerung ol {
|
||
font-size: 1.0rem;
|
||
line-height: 1.4;
|
||
}
|
||
section.erklaerung p {
|
||
font-size: 1.0rem;
|
||
line-height: 1.4;
|
||
}
|
||
section.erklaerung table {
|
||
font-size: 0.9rem;
|
||
}
|
||
</style>
|
||
|
||
<!-- _class: invert -->
|
||
<!-- _header: '' -->
|
||
<!-- _backgroundColor: #000 -->
|
||
|
||
|
||
|
||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||
|
||
**223015b** · Modul "Technik 1" · 1. Semester
|
||
Digital- und Medienwirtschaft
|
||
Hochschule der Medien Stuttgart
|
||
|
||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||
|
||
---
|
||
|
||
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 1: Einführung
|
||
## Grundlagen, Text & Audio
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Das Problem der Datengröße
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
---
|
||
|
||
|
||
|
||
# Ein konkretes Beispiel
|
||
|
||
**Eine Minute Musik in CD-Qualität:**
|
||
|
||
44.100 Messungen/Sekunde
|
||
× 16 Bit pro Messung
|
||
× 2 Kanäle (Stereo)
|
||
× 60 Sekunden
|
||
|
||
= **10,6 MB pro Minute**
|
||
|
||
<!--
|
||
Das ist die unkomprimierte Größe.
|
||
Klingt erstmal nicht dramatisch.
|
||
Aber es skaliert schnell.
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# Das Problem skaliert
|
||
|
||
| Inhalt | Unkomprimiert |
|
||
|--------|-------------:|
|
||
| 1 Song (4 Min) | ~42 MB |
|
||
| 1 Album (60 Min) | ~635 MB |
|
||
| 10.000 Songs | ~420 GB |
|
||
|
||
**Kontext 1990er:**
|
||
- Festplatte: 100-500 MB
|
||
- Modem: 56 kbit/s → 1 Song dauert Stunden
|
||
|
||
<!--
|
||
Ein Album hätte eine komplette Festplatte gefüllt.
|
||
Musik übers Internet war praktisch unmöglich.
|
||
Das Problem musste gelöst werden.
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# Video eskaliert
|
||
|
||
**Eine Minute 4K-Video (unkomprimiert):**
|
||
|
||
3840 × 2160 Pixel
|
||
× 3 Byte pro Pixel (RGB)
|
||
× 30 Bilder pro Sekunde
|
||
× 60 Sekunden
|
||
|
||
= **~45 GB pro Minute**
|
||
|
||
Ein 2-Stunden-Film: über **5 Terabyte**
|
||
|
||
<!--
|
||
Netflix, YouTube, Streaming – nichts davon wäre ohne Kompression möglich.
|
||
Nicht einmal Blu-rays könnten existieren.
|
||
Die physikalische Realität erzwingt Kompression.
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# Artemis II orbitiert
|
||
|
||
| | Apollo (1969) | Artemis II (2026) |
|
||
|---|---|---|
|
||
| Bandbreite | ~50 kbit/s | 260 Mbit/s |
|
||
| Video | SW, ~320 Zeilen | HD live, 4K gespeichert |
|
||
| Codec | analog | H.265 (HEVC) |
|
||
|
||
260.000.000 Bit/s
|
||
÷ 8 (Bit pro Byte) = 32,5 MB/s
|
||
× 60 Sekunden = **1,95 GB pro Minute**
|
||
|
||
*Apollo: 50 kbit/s = 0,375 MB/min*
|
||
|
||
<!--
|
||
Übertragung per Infrarot-Laser (O2O = Orion Artemis II Optical Communications). MAScOT-Terminal entwickelt von MIT Lincoln Lab. 32 Kameras an Bord (Nikon D5/Z9, GoPros, Redwire 4K-Festkameras). ZCube-Encoder kodiert H.265 an Bord. Bandbreite geteilt mit Telemetrie und Voice — daher live "nur" HD, echtes 4K kommt auf CompactFlash-Karten nach Splashdown. Latenz Mond ↔ Erde: ~1,3 Sekunden (384.400 km). Apollo nutzte S-Band Radio, Artemis II Infrarot-Laser.
|
||
-->
|
||
|
||
---
|
||
|
||
# Kompressionsraten in der Praxis
|
||
|
||
| Medium | Unkomprimiert | Komprimiert | Faktor |
|
||
|--------|-------------:|------------:|-------:|
|
||
| 1 Song (4 Min) | ~42 MB | ~4 MB (MP3 128) | ~10× |
|
||
| 1 Foto (12 MP) | ~36 MB | ~3 MB (JPEG) | ~12× |
|
||
| 1 Min 4K-Video | ~45 GB | ~375 MB (H.264) | ~120× |
|
||
|
||
<!--
|
||
Diese Faktoren sind keine Ausnahmen, sondern die Norm.
|
||
Ohne diese Kompression wäre die digitale Medienwelt, wie wir sie kennen, nicht existent.
|
||
Die Frage ist nicht ob, sondern wie komprimiert wird.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Zwei Philosophien der Kompression
|
||
|
||
<!--
|
||
|
||
Was ist überhaupt KOMPRESSION?
|
||
|
||
- Luftdruck in Auto/Fahrradreifen
|
||
- LNG Flüssiggas
|
||
- Tripsdrill, Disneyland
|
||
- Oper/Theater/Telenovela
|
||
- Cola Sirup für den Sodastream
|
||
|
||
-->
|
||
|
||
---
|
||
|
||
# Verlustfreie Kompression (Lossless)
|
||
|
||
**Prinzip:** Redundanz entfernen
|
||
|
||
**Beispiel Lauflängenkodierung:**
|
||
```
|
||
Original: AAAAABBBCCCCCCCC (16 Zeichen)
|
||
Komprimiert: 5A3B8C (6 Zeichen)
|
||
```
|
||
|
||
→ 62% kleiner, 100% wiederherstellbar
|
||
|
||
**Anwendung:** ZIP, PNG, FLAC, Programmcode
|
||
|
||
<!--
|
||
Run-Length Encoding (RLE) ist die einfachste Form.
|
||
Das Prinzip: Muster erkennen, kompakter darstellen.
|
||
Funktioniert gut bei strukturierten Daten.
|
||
Bei "chaotischen" Daten wie Fotos weniger effektiv.
|
||
-->
|
||
|
||
---
|
||
|
||
# Verlustbehaftete Kompression (Lossy)
|
||
|
||
**Prinzip:** Irrelevanz entfernen
|
||
|
||
**Die Frage:** Was nimmt ein Mensch nicht wahr?
|
||
|
||
- Das Ohr hört nicht alle Frequenzen gleich gut
|
||
- Das Auge sieht nicht alle Farbnuancen
|
||
- Laute Töne überdecken leise Töne
|
||
|
||
→ Warum Daten speichern, die niemand wahrnimmt?
|
||
|
||
<!--
|
||
Das ist die zentrale Idee hinter MP3, JPEG, H.264.
|
||
Nicht die Daten selbst reduzieren – das wäre Qualitätsverlust.
|
||
Sondern gezielt das entfernen, was Menschen nicht wahrnehmen.
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# Verlustfrei vs. Verlustbehaftet
|
||
|
||
| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
|
||
|---|---|---|
|
||
| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
|
||
| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich verloren) |
|
||
| **Reduktion** | 30-50% | 80-99% |
|
||
| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
|
||
|
||
**Faustregel:**
|
||
- Medien für EndnutzerInnen → Lossy oft akzeptabel
|
||
- Quellmaterial, Code, Archive → Lossless nötig
|
||
|
||
<!--
|
||
REDUNDANZ: Wiederholende Muster kompakter darstellen (z.B. "AAAA" → "4×A")
|
||
IRRELEVANZ: Für Menschen nicht wahrnehmbar (Psychoakustik, Psychovisuell)
|
||
|
||
KLAUSURRELEVANT:
|
||
- Verlustfrei = Original 1:1 wiederherstellbar
|
||
- Verlustbehaftet = Information geht verloren, aber kaum wahrnehmbar
|
||
- Redundanz vs. Irrelevanz ist der Kernunterschied!
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Kompression – Vertiefung
|
||
|
||
Claude Shannon definierte 1948 die **Entropie** als theoretische Untergrenze der Kompression. Ein Text mit gleichmäßiger Zeichenverteilung hat hohe Entropie (schwer komprimierbar); repetitive Texte haben niedrige Entropie.
|
||
|
||
**Verlustfreie Kompression** erreicht diese Grenze durch:
|
||
- **Statistische Kodierung:** Huffman, Arithmetic Coding
|
||
- **Wörterbuch-Methoden:** LZ77, LZ78, DEFLATE (ZIP, PNG, TAR)
|
||
- Originalzustand ist exakt rekonstruierbar
|
||
|
||
**Verlustbehaftete Kompression** unterschreitet die Grenze, indem sie menschliche Wahrnehmungsgrenzen ausnutzt:
|
||
|
||
| Sinneskanal | Psychophysisches Modell | Ausnutzung |
|
||
|-------------|------------------------|------------|
|
||
| Gehör | Maskierungseffekte, Hörschwelle | MP3: Töne unter Maskierungsschwelle weglassen |
|
||
| Sehen | Farbauflösung, Kontrastempfindlichkeit | JPEG: Chroma-Subsampling, hohe Frequenzen verwerfen |
|
||
|
||
**Shannon-Limit:** Verlustfreie Kompression ist durch Entropie begrenzt; Verlustbehaftete Kompression kann beliebig weit gehen – auf Kosten der Qualität.
|
||
|
||
<!--
|
||
ABKÜRZUNGEN:
|
||
- LZ = Lempel-Ziv (nach Abraham Lempel und Jacob Ziv)
|
||
- LZ77 = Lempel-Ziv 1977 – Sliding-Window-Verfahren: sucht Wiederholungen in einem Fenster der letzten Bytes und ersetzt sie durch Rückverweise (Offset + Länge)
|
||
- LZ78 = Lempel-Ziv 1978 – baut ein explizites Wörterbuch auf: neue Muster bekommen einen Index, Wiederholungen werden durch den Index ersetzt
|
||
- DEFLATE = Kombination aus LZ77 + Huffman-Coding; verwendet in ZIP, PNG und gzip
|
||
- TAR = Tape ARchive – kein Kompressionsformat, sondern ein Archivformat (bündelt Dateien zu einer). Kompression erst durch Kombination: .tar.gz (gzip = DEFLATE), .tar.bz2 (bzip2), .tar.xz (LZMA)
|
||
- ZIP = Archivformat mit eingebauter DEFLATE-Kompression (Phil Katz, 1989)
|
||
- PNG = Portable Network Graphics – nutzt DEFLATE für verlustfreie Bildkompression
|
||
|
||
STATISTISCHE KODIERUNG:
|
||
- Huffman-Coding: Häufige Zeichen bekommen kurze Bitfolgen, seltene Zeichen lange. Beispiel: 'e' (häufig) → 2 Bit, 'q' (selten) → 8 Bit
|
||
- Arithmetic Coding: Kodiert die gesamte Nachricht als einzelne Zahl zwischen 0 und 1. Etwas effizienter als Huffman, aber rechenintensiver
|
||
|
||
ENTROPIE (Shannon):
|
||
- Maß für den Informationsgehalt: Wie "überraschend" ist jedes Zeichen?
|
||
- Hohe Entropie = schwer komprimierbar (z.B. verschlüsselte Daten, Rauschen)
|
||
- Niedrige Entropie = gut komprimierbar (z.B. "AAAAAAA" oder natürliche Sprache)
|
||
- Theoretisches Minimum: kein Algorithmus kann unter die Entropie-Grenze kommen
|
||
|
||
PRAXISBEISPIEL:
|
||
- ZIP einer .txt-Datei: ~60-70% kleiner (Text hat niedrige Entropie)
|
||
- ZIP einer .jpg-Datei: kaum kleiner (JPEG hat Entropie schon ausgereizt)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
<!--
|
||
Lossless vs. Lossy Kompression
|
||
Visualisierung der beiden Philosophien
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Die Grundbausteine
|
||
## Bits, Bytes und ihre Darstellung
|
||
|
||
---
|
||
|
||
<!-- _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 0 1 0 1 0 1 0
|
||
```
|
||
|
||
<!--
|
||
|
||
|
||
binary 00101010
|
||
= decimal 42
|
||
|
||
Rätsel: "Wenn sich das Wachstum einer Seerose auf einem Teich jeden Tag verdoppelt · und nach *zehn Tagen* der ganze Teich bedeckt ist, wann ist er zur Hälfte zugewachsen?"
|
||
|
||
Frage: "Weiß jemand wieviele Zustände wir mit 8 Bit beschreiben können?"
|
||
|
||
-->
|
||
|
||
---
|
||
|
||
# Das Byte
|
||
|
||
**1 Byte = 8 Bits**
|
||
|
||
```
|
||
0 0 1 0 1 0 1 0
|
||
```
|
||
|
||
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)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _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 (Cyan, Magenta, Yellow, Key/Black) bzw. in diesem Fall CMYW (Cyan, Magenta, Yellow, White)
|
||
2. RGB (Red, Green, Blue)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _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 (Red, Green, Blue)
|
||
CMYK = Cyan, Magenta, Yellow, Key (Black) – Subtraktive Farbmischung (Druck)
|
||
Hex-Notation: FF = 255 in Dezimal
|
||
CSS (Cascading Style Sheets)-Farben nutzen Hex: #FF0000 = Rot
|
||
Wer HTML (HyperText Markup Language)/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 passen problem in 1 Byte**
|
||
|
||
**Jedoch ohne** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 😀
|
||
|
||
<!--
|
||
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!)
|
||
- 1.112.064 gültige Zeichen
|
||
- 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:** `"Hello·🌸·こんにちは·(Kon-ni-chi-wa)"`
|
||
|
||
| Zeichen | Bytes |
|
||
|---------|-------|
|
||
| `Hello·` | 6 × 1 = **6 Bytes** (ASCII) |
|
||
| `🌸` | **4 Bytes** (Emoji) |
|
||
| `·` | **1 Byte** |
|
||
| `こんにちは` | 5 × 3 = **15 Bytes** (Hiragana) |
|
||
| `·(Kon-ni-chi-wa)` | **16 Bytes** (ASCII) |
|
||
|
||
**Gesamt: 42 Bytes** für 29 sichtbare Zeichen
|
||
|
||
<!--
|
||
ASCII (Hello, Klammern) = 1 Byte pro Zeichen
|
||
Emoji 🌸 (Cherry Blossom U+1F338) = 4 Bytes
|
||
Hiragana こんにちは = 3 Bytes pro Zeichen (U+3040-309F)
|
||
Hinweis: は wird hier "wa" ausgesprochen (Partikel), nicht "ha"
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Hexadezimal
|
||
## Die Sprache der Datei-Analyse
|
||
|
||
---
|
||
|
||
# Hexadezimal: Lesbarkeit
|
||
|
||
**Für den Menschen ungeeignet:**
|
||
`01010000 01001110 01000111`
|
||
|
||
**Hexadezimal (Base 16):**
|
||
`50 4E 47` (= "PNG" in ASCII)
|
||
|
||
**Jede Hex-Ziffer = 4 Bits (ein "Nibble")**
|
||
0-9, A-F (10=A, 11=B, ..., 15=F)
|
||
|
||
`5 = 0101` `0 = 0000`
|
||
`4 = 0100` `E = 1110`
|
||
`4 = 0100` `7 = 0111`
|
||
|
||
**ASCII Tabelle (0-127):**
|
||
[https://www.asciitable.com](https://www.asciitable.com)
|
||
|
||
<!--
|
||
|
||
Dezimalsystem passt nur umständlich 0->15 (1111) ins binäre System
|
||
Hexadezimal (16) passt perfekt
|
||
|
||
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: '' -->
|
||
|
||
|
||
|
||
---
|
||
|
||
<!-- _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 = Chinese, Japanese, Korean) 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 (Unicode Transformation Format, 8-bit) ist vollständig ASCII-kompatibel (Zeichen 0-127 identisch)
|
||
- Internetprotokolle basieren auf ASCII: HTTP (HyperText Transfer Protocol)-Header, SMTP (Simple Mail Transfer Protocol), URLs (Uniform Resource Locator)
|
||
- 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?"
|
||
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
# WTF!?
|
||
|
||
```
|
||
89 50 4E 47 0D 0A 1A 0A
|
||
00 00 00 0D 49 48 44 52
|
||
00 00 01 90 00 00 01 2C
|
||
```
|
||
|
||
---
|
||
|
||
|
||
|
||
# What the HEX-Code
|
||
|
||
```
|
||
89 50 4E 47 ...
|
||
```
|
||
|
||
| Binär | Hex | Dez | ASCII |
|
||
|-------|-----|-----|-------|
|
||
| `1000 1001` | `89` | 137 | ✗ (> 127) |
|
||
| `0101 0000` | `50` | 80 | **P** |
|
||
| `0100 1110` | `4E` | 78 | **N** |
|
||
| `0100 0111` | `47` | 71 | **G** |
|
||
|
||
→ `89` übersteigt den ASCII-Raum und markiert eie Binärdatei
|
||
|
||
<!--
|
||
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: '' -->
|
||
<!-- _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 (HyperText Markup Language), CSS (Cascading Style Sheets), JSON (JavaScript Object Notation), XML (Extensible Markup Language)
|
||
→ 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: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# Dateneinheiten
|
||
|
||
| Einheit | Bytes | Potenz | Beispiel |
|
||
|---------|------:|:------:|----------|
|
||
| **Byte** | 1 | 10⁰ | Farbwerte eines Pixels |
|
||
| **Kilobyte (KB)** | 1.000 | 10³ | Kleiner Programmcode |
|
||
| **Megabyte (MB)** | 1 Million | 10⁶ | Textdokument |
|
||
| **Gigabyte (GB)** | 1 Milliarde | 10⁹ | Kinofilm in FullHD |
|
||
| **Terabyte (TB)** | 1 Billion | 10¹² | ~12h Video in 4K |
|
||
| **Petabyte (PB)** | 1 Billiarde | 10¹⁵ | Netflix-Gesamtarchiv |
|
||
| **Exabyte (EB)** | 1 Trillion | 10¹⁸ | Alle E-Mails weltweit/Tag |
|
||
| **Zettabyte (ZB)** | 1 Trilliarde | 10²¹ | Internet-Traffic 2016 |
|
||
|
||
<!--
|
||
SI (Système International d'Unités)-Präfixe (Dezimal): 1 KB = 1.000 Bytes
|
||
Binär (IEC = International Electrotechnical Commission): 1 KiB = 1.024 Bytes (Kibibyte)
|
||
Windows zeigt oft binär, sagt aber "KB" → Verwirrung!
|
||
1 TB Festplatte = ~931 GiB nutzbar
|
||
|
||
Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
|
||
→ "Komm Mit Großem Tee, Peter Exte Zettelt Yachten"
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Dateneinheiten – Vertiefung
|
||
|
||
Zwei konkurrierende Standards existieren seit der IEC-Normierung 1998:
|
||
|
||
| Präfix | SI (Dezimal) | IEC (Binär) | Differenz |
|
||
|--------|--------------|-------------|-----------|
|
||
| Kilo | 1.000 (10³) | 1.024 (2¹⁰) KiB | 2,4% |
|
||
| Mega | 1.000.000 (10⁶) | 1.048.576 MiB | 4,9% |
|
||
| Giga | 10⁹ | 2³⁰ GiB | 7,4% |
|
||
| Tera | 10¹² | 2⁴⁰ TiB | 10% |
|
||
|
||
**Warum der Unterschied wächst:** (2¹⁰)ⁿ ÷ (10³)ⁿ = 1,024ⁿ. Bei Terabyte sind es bereits 10% Abweichung.
|
||
|
||
**Festplatten-Marketing:** Hersteller nutzen SI (dezimal), Betriebssysteme zeigen IEC (binär). Eine „1 TB"-Festplatte zeigt daher nur 931 GiB an – technisch korrekt, aber verwirrend.
|
||
|
||
**Historischer Kontext:** RAM wurde immer binär gemessen (2ⁿ Adressen), Festplatten ursprünglich dezimal (physikalische Geometrie). Die IEC führte 1998 KiB/MiB/GiB ein – diese Notation setzt sich langsam durch.
|
||
|
||
---
|
||
|
||
# Datenwachstum der Menschheit
|
||
|
||
| Jahr | Datenmenge | Kontext |
|
||
|------|------------|---------|
|
||
| **100.000 v. Chr.** | 0 | Erste Menschen, nur Sprache |
|
||
| **3.000 v. Chr.** | ~wenige KB | Keilschrift, Hieroglyphen |
|
||
| **1450** | ~wenige GB | Gutenberg, Buchdruck |
|
||
| **1986** | **2,6 EB** | 99% analog (Bücher, Vinyl, VHS) |
|
||
| **2007** | **295 EB** | 94% digital |
|
||
| **2025** | **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: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# Der digitale Wendepunkt
|
||
|
||
| Jahr | Analog | Digital | Digital-Anteil |
|
||
|------|--------|---------|----------------|
|
||
| **1986** | 2,6 EB | 0,02 EB | **1%** |
|
||
| **2002** | — | — | **50%** (Wendepunkt) |
|
||
| **2007** | 18 EB | 277 EB | **94%** |
|
||
|
||
**Perspektive:**
|
||
- 1986: "Petabyte" war ein theoretisches Konzept
|
||
- 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 (LTO = Linear Tape-Open, 2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
|
||
|
||
VERGLEICH: SSD (Solid State Drive) ~$50/TB, HDD (Hard Disk Drive) ~$15/TB, LTO ~$5/TB
|
||
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Digitaler Wendepunkt – Vertiefung
|
||
|
||
Die Studie von Hilbert & López (Science, 2011) analysierte 60 Speichertechnologien von 1986–2007. Der Wendepunkt 2002 markiert den Moment, ab dem mehr Information digital als analog existierte.
|
||
|
||
**Was 1986 „analog" bedeutete:**
|
||
- Bücher, Zeitungen, Magazine: ~8 EB
|
||
- Vinyl-Schallplatten, Musikkassetten: ~12 EB
|
||
- VHS-Kassetten, Filmrollen: ~60 EB
|
||
|
||
**Warum analog stagnierte:** Physische Medien haben Kapazitätsgrenzen. Eine VHS speichert 10 GB; eine Blu-ray (2006) bereits 50 GB auf kleinerer Fläche.
|
||
|
||
**LTO-Magnetband überlebt** trotz „alter" Technologie:
|
||
| Medium | Kosten/TB | Lebensdauer | Energiebedarf |
|
||
|--------|-----------|-------------|---------------|
|
||
| SSD | ~50 € | 5–10 Jahre | Dauerstrom |
|
||
| HDD | ~15 € | 3–5 Jahre aktiv | Dauerstrom |
|
||
| LTO-9 | ~5 € | 30+ Jahre | Nur beim Zugriff |
|
||
|
||
AWS Glacier, Google Coldline und Film-Archive nutzen LTO – langsamer Zugriff, aber unschlagbar günstig und langlebig.
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
|
||
|
||
---
|
||
|
||
# 181 Zettabyte – Was bedeutet das?
|
||
|
||
**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 NutzerInnen generiert
|
||
|
||
**Zum Vergleich:**
|
||
- 1 ZB = 250 Milliarden DVDs
|
||
- 181 ZB = Jeder Mensch erzeugt ~23 TB/Jahr
|
||
|
||
<!--
|
||
Quellen: IDC Global DataSphere Forecast, Statista 2025
|
||
IoT (Internet of Things)-Geräte allein: 73 ZB in 2025
|
||
Cloud-Speicher: 100 ZB (50% der Weltdaten)
|
||
Prognose 2028: 394 ZB
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
|
||
---
|
||
|
||
# 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 -->
|
||
|
||
# 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: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# Analoge Medien
|
||
### Distribution: physisch (Kauf, Verleih, Kopie)
|
||
|
||
* **Text**
|
||
- Bücher, Zeitungen, Zeitschriften, Lochkarten
|
||
* **Bild**
|
||
- Fotografie (Negativ, Dia, Polaroid), Mikrofilm
|
||
* **Audio:**
|
||
- Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
|
||
* **Video:**
|
||
- Film (35mm, Super 8), VHS, Betamax
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Analoge Medien – Vertiefung
|
||
|
||
Analoge Speicherung codiert Information als **kontinuierliche physikalische Größe**: Rillentiefe (Vinyl), Magnetfeldstärke (Tonband), Silberkorn-Dichte (Film). Es gibt keine diskreten Stufen – theoretisch unendliche Auflösung, praktisch begrenzt durch Rauschen.
|
||
|
||
**Generationsverlust** entsteht, weil jede Kopie neues Rauschen addiert:
|
||
- Schallplatte → Kassette: Frequenzgang leidet, Rauschen steigt
|
||
- VHS → VHS: Farbsättigung sinkt, Schärfe nimmt ab
|
||
- 3. Generation: oft unbrauchbar
|
||
|
||
| Medium | Typische Auflösung | Dynamik |
|
||
|--------|-------------------|---------|
|
||
| Vinyl (audiophil) | ~20–20.000 Hz | ~70 dB |
|
||
| Tonband (Studio) | ~30–15.000 Hz | ~55 dB |
|
||
| 35mm Film | ~4K-äquivalent | ~13 Blendenstufen |
|
||
|
||
**Paradox der Analogtechnik:** Das Original ist einzigartig und unersetzlich – aber genau deshalb anfällig. Jedes Abspielen einer Schallplatte trägt mikroskopisch Material ab; jeder Filmdurchlauf riskiert Kratzer.
|
||
|
||
---
|
||
|
||
# Analoge Medien: Vor- und Nachteile
|
||
|
||
| Vorteile | Nachteile |
|
||
|----------|-----------|
|
||
| Kein Abspielgerät nötig (Buch, Foto) | Qualitätsverlust bei jeder Kopie |
|
||
| Haptisches Erlebnis | Physischer Verschleiß |
|
||
| Unabhängig von Strom/Internet | Begrenzte Haltbarkeit |
|
||
| Keine Formatkonvertierung | Platzbedarf bei Lagerung |
|
||
| Eindeutiges Original | Aufwendige Durchsuchbarkeit |
|
||
|
||
<!--
|
||
GENERATIONSVERLUST:
|
||
Kassette → Kassette = jede Kopie schlechter
|
||
VHS (Video Home System) → 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: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# Digitale Medien
|
||
### Distribution: Datenträger (CD, USB), Download, Streaming, P2P
|
||
|
||
* **Text**
|
||
- E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
|
||
* **Bild**
|
||
- Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
|
||
* **Audio**
|
||
- Audiodatei (MP3, FLAC, WAV, AAC, OGG)
|
||
* **Video**
|
||
- Videodatei (MP4, MKV, AVI, WebM)
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Digitale Medien – Vertiefung
|
||
|
||
Digitale Speicherung quantisiert kontinuierliche Signale in diskrete Werte. Der **Quantisierungsfehler** (Differenz zum Original) ist der Preis der Digitalisierung – aber einmal digitalisiert, bleibt die Information exakt.
|
||
|
||
**Bit-identische Kopien** revolutionierten die Medienindustrie:
|
||
- Keine Qualitätskette mehr: 1000. Kopie = 1. Kopie = Original
|
||
- Kosten pro Kopie: praktisch null (nur Speicherplatz)
|
||
- Perfekte Archivierung: Bits altern nicht (nur der Datenträger)
|
||
|
||
| Aspekt | Analog | Digital |
|
||
|--------|--------|---------|
|
||
| Kopiervorgang | Physikalischer Prozess | Bit-Kopie |
|
||
| Qualität pro Generation | Verschlechtert | Identisch |
|
||
| Fehlerkorrektur | Unmöglich | Möglich (ECC = Error Correcting Code, RAID = Redundant Array of Independent Disks) |
|
||
| Formatmigration | Verlust | Verlustfrei möglich |
|
||
|
||
**Die Kehrseite:** Digitale Obsoleszenz. Ein DOCX von 2025 ist in 50 Jahren womöglich unlesbar – während ein Buch von 1525 heute noch lesbar ist. Offene Formate (PDF/A, FLAC, PNG) mildern dieses Risiko.
|
||
|
||
---
|
||
|
||
<!-- _class: klausur -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
<!-- _backgroundColor: #e3f2fd -->
|
||
|
||
# Digitale Speichermedien
|
||
|
||
* **Optische Speicher**
|
||
- CD, DVD, Blu-ray
|
||
* **Magnetische Speicher**
|
||
- Festplatte (HDD), Magnetband (LTO)
|
||
* **Flash-Speicher**
|
||
- SSD, USB-Stick, SD-Karte
|
||
* **Cloud-Speicher**
|
||
- Dropbox, Google Drive, iCloud, AWS S3
|
||
|
||
---
|
||
|
||
<!-- _class: erklaerung -->
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Digitale Speichermedien – Vertiefung
|
||
|
||
Jede Technologie hat physikalische Vor- und Nachteile:
|
||
|
||
**Optisch (CD/DVD/Blu-ray):** Laser liest Pits (Vertiefungen) und Lands (Erhöhungen). Robust gegen Magnetfelder, aber empfindlich gegenüber Kratzern und UV-Licht. M-DISC verspricht 1000 Jahre – unter Laborbedingungen.
|
||
|
||
**Magnetisch (HDD/LTO):** Magnetisierte Bereiche auf rotierenden Platten oder Band. HDDs haben bewegliche Teile (Verschleiß); LTO-Bänder sind passiv und extrem langlebig, aber sequentieller Zugriff.
|
||
|
||
**Flash (SSD/USB/SD):** Elektronen in Floating Gates speichern Bits. Keine beweglichen Teile, aber begrenzte Schreibzyklen (TLC: ~3.000, SLC: ~100.000). Ohne Strom verlieren Zellen nach Jahren ihre Ladung.
|
||
|
||
| Szenario | Empfehlung | Grund |
|
||
|----------|------------|-------|
|
||
| Betriebssystem | NVMe SSD | Geschwindigkeit |
|
||
| Videoarchiv | HDD | Kapazität/Preis |
|
||
| Langzeitarchiv | LTO + M-DISC | Lebensdauer |
|
||
| Austausch | USB/SD | Portabilität |
|
||
|
||
**Cloud** ist physisch HDD/SSD/LTO in Rechenzentren – kein eigenes Medium, sondern Zugriffsmethode.
|
||
|
||
---
|
||
|
||
# Das Speicherproblem der Digitalisierung
|
||
|
||
|
||
**Ziel: Analoge Schallwelle möglichst originalgetreu rekonstruieren**
|
||
|
||
*CD-Qualität (1982): 44.100 Hz × 16 Bit × 2 Kanäle = 10,584 MB/Minute*
|
||
|
||
<!-- 44100 Hz ×16 Bit × 2 ÷ 8 ÷ 1000 ÷ 1000 × 60 = 10,584 MB/Minute -->
|
||
|
||
| Inhalt | Größe | Problem (1990er) |
|
||
|--------|-------|------------------|
|
||
| 1 Song (4 Min) | ~42 MB | Ausreichend Speicher |
|
||
| 1 Album (60 Min) | ~635 MB | Gesamte Festplatte |
|
||
|
||
|
||
<!--
|
||
"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 = 10,584 MB/Minute
|
||
|
||
<!--
|
||
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 (Institut für Integrierte Schaltungen) 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 = Schnelle Fourier-Transformation)
|
||
- 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 (Joint Photographic Experts Group): 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
|
||
-->
|
||
|
||
<!--
|
||
---
|
||
|
||
# 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)
|
||
-->
|
||
|
||
|
||
---
|
||
|
||
# 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 = Advanced Audio Coding, 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: lead -->
|
||
|
||
# Fragen & Diskussion
|
||
|
||
**Kontakt:** lb-czechowski@hdm-stuttgart.de
|
||
**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
|
||
|
||
---
|
||
|
||
# Lizenz & Attribution
|
||
|
||
Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
|
||
|
||
- Erlaubt Teilen & Anpassen mit Namensnennung
|
||
- Adaptionen müssen unter gleicher Lizenz geteilt werden
|
||
|
||
Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
# Selbstlernen: Audio-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 (Free and Open-Source Software) 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
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _header: '' -->
|
||
<!-- _footer: '' -->
|
||
|
||
|
||
|
||
# Selbstlernen: HEX Files
|
||
|
||
1. Drei Dateien ohne Dateiendung:
|
||
<a href="../materials/wtf1"/>`hex1`</a> <a href="../materials/wtf2"/>`hex2`</a> <a href="../materials/wtf3"/>`hex3`</a>
|
||
3. Lies erste 16 Bytes aus und identifiziere Dateiformat (Magic Number)
|
||
5. *Optional: Datei umbenennen und korrekte Dateiendung anhängen (bspw. `.jpg`)*
|
||
|
||
**Tools:**
|
||
- Hex-Editor: [hexed.it](https://hexed.it)
|
||
- Magic Numbers: [en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures)
|
||
|
||
<!--
|
||
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
|
||
-->
|
||
|