gendering: fehlende person-substantive in beiden kursen
- Nutzer/User -> Nutzende - Endnutzer -> Endnutzende - Teilnehmer -> Teilnehmende - Programmierer/Entwickler -> Programmierende/Entwickelnde - Web-Entwickler -> Web-Entwickelnde - Tastatur-Nutzer -> Tastatur-Nutzende - Benutzer -> Nutzende - Konsumenten -> KonsumentInnen - Künstler -> KünstlerInnen - Autor -> AutorIn - Fotografen -> FotografInnen - Kunde -> KundIn ausgenommen: code-identifiers (User, type User, /users/), Sender/Empfänger (network protocol), Sawyer (konkrete person), Hersteller/Betreiber (organisations-rolle).
This commit is contained in:
@@ -348,7 +348,7 @@ dann **150 Mbit/s ÷ 8** = **18,75 MB/s**
|
||||
**50 MB Upload bei 10 Mbit/s = ~40 Sekunden**
|
||||
|
||||
<!--
|
||||
- ADSL (Asymmetric Digital Subscriber Line, ITU = International Telecommunication Union, Norm G.992.1, 1999): Upload bewusst begrenzt — Annahme war, Nutzer konsumieren mehr als sie produzieren
|
||||
- ADSL (Asymmetric Digital Subscriber Line, ITU = International Telecommunication Union, Norm G.992.1, 1999): Upload bewusst begrenzt — Annahme war, Nutzende konsumieren mehr als sie produzieren
|
||||
- FTTH = Fiber To The Home (Glasfaser bis in die Wohnung)
|
||||
- Glasfaser (FTTH) symmetrisch: Upload = Download
|
||||
- FTTH-Verfügbarkeit Deutschland Ende 2024: ~40% der Haushalte (Bundesnetzagentur, Breitbandatlas)
|
||||
@@ -434,7 +434,7 @@ Jede Messung = ein Zahlenwert
|
||||
<!--
|
||||
- Dynamikumfang Formel: ~6 dB pro Bit
|
||||
- 16 Bit reicht für menschliches Hören unter realen Bedingungen (~80–90 dB)
|
||||
- 24 Bit im Studio: mehr Headroom für Bearbeitung, kein perzipieller Mehrwert für Endnutzer (Meyer & Moran, JAES 2007)
|
||||
- 24 Bit im Studio: mehr Headroom für Bearbeitung, kein perzipieller Mehrwert für Endnutzende (Meyer & Moran, JAES 2007)
|
||||
- dB = Dezibel: logarithmische Einheit für Lautstärke
|
||||
-->
|
||||
|
||||
@@ -556,7 +556,7 @@ RECHNUNG:
|
||||
|
||||
- CD (1982, Sony/Philips): erstes massenmarktfähiges digitales Distributionsmedium für unkomprimiertes PCM-Audio
|
||||
- PCM (Pulse-Code Modulation) existierte bereits vorher: NHK (Nippon Hōsō Kyōkai = japanische öffentlich-rechtliche Rundfunkanstalt)-Forschung ab 1960er, digitale Studiogeräte ab 1970er
|
||||
- Die CD war nicht das erste digitale Audio — aber das erste das in Konsumentenhänden landete
|
||||
- Die CD war nicht das erste digitale Audio — aber das erste das in KonsumentInnen-Hand landete
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -600,7 +600,7 @@ _class: erklaerung
|
||||
|
||||
# CD-Audio – Vertiefung
|
||||
|
||||
Die CD (1982) war nicht das erste digitale Audiomedium — PCM-Aufnahmen existierten seit den späten 1960ern in Tonstudios (u.a. NHK, Nippon Columbia). Die CD war das erste **massenmarktfähige** digitale Distributionsmedium für unkomprimiertes Audio in Konsumentenhänden.
|
||||
Die CD (1982) war nicht das erste digitale Audiomedium — PCM-Aufnahmen existierten seit den späten 1960ern in Tonstudios (u.a. NHK, Nippon Columbia). Die CD war das erste **massenmarktfähige** digitale Distributionsmedium für unkomprimiertes Audio in KonsumentInnen-Hand.
|
||||
|
||||
**Warum 44.100 Hz?**
|
||||
Kombination aus Nyquist-Limit (2× 20 kHz = 40 kHz Minimum) und Kompatibilität mit Videobandgeräten, die in frühen digitalen Tonstudios als Speichermedium genutzt wurden. NTSC: 3 Samples × 245 Zeilen × 60 Felder = 44.100. PAL: 3 Samples × 294 Zeilen × 50 Felder = 44.100.
|
||||
@@ -1810,7 +1810,7 @@ Fangfrage: "Wie hoch ist die Sample Rate von Vinyls?" -> Vinyl has no sample rat
|
||||
<!--
|
||||
- Dynamikumfang Formel: ~6 dB pro Bit
|
||||
- 16 Bit reicht für menschliches Hören unter realen Bedingungen
|
||||
- 24 Bit im Studio: mehr Headroom für Bearbeitung, kein perzipieller Mehrwert für Endnutzer (Meyer & Moran, JAES 2007)
|
||||
- 24 Bit im Studio: mehr Headroom für Bearbeitung, kein perzipieller Mehrwert für Endnutzende (Meyer & Moran, JAES 2007)
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -2015,7 +2015,7 @@ Ein Zusammenspiel aus vielen Faktoren:
|
||||
**P2P-Filesharing für MP3s**
|
||||
|
||||
- Shawn Fanning, 19 Jahre alt
|
||||
- 80 Millionen User in 2 Jahren
|
||||
- 80 Millionen Nutzende in 2 Jahren
|
||||
- Musikindustrie verklagt (2001)
|
||||
- Pandora's Box: Nicht mehr aufzuhalten
|
||||
|
||||
@@ -2032,7 +2032,7 @@ Ein Zusammenspiel aus vielen Faktoren:
|
||||
# Napster & Musikindustrie
|
||||
|
||||
**1999:** Napster startet
|
||||
**2001:** 80 Millionen User
|
||||
**2001:** 80 Millionen Nutzende
|
||||
|
||||
**Musikindustrie:**
|
||||
- CDs kosten $15–20
|
||||
|
||||
@@ -948,7 +948,7 @@ KLAUSURRELEVANT:
|
||||
<!--
|
||||
- Kompatibilität schlägt oft Effizienz
|
||||
- TIFF für Archivierung: Unkomprimiert oder verlustfrei
|
||||
- RAW für Fotografen: Maximale Bearbeitungsfreiheit
|
||||
- RAW für FotografInnen: Maximale Bearbeitungsfreiheit
|
||||
- Frage: "Was passiert, wenn ihr ein PNG auf Instagram hochladet?"
|
||||
-->
|
||||
|
||||
@@ -984,8 +984,8 @@ KLAUSURRELEVANT:
|
||||
- Instagram ist keine Kunstgalerie, sondern Massenplattform
|
||||
- Optimiert für Geschwindigkeit, nicht Qualität
|
||||
- Facebook, Twitter, TikTok – alle machen das
|
||||
- Tipp für Fotografen: Portfolio auf eigener Website
|
||||
- Diskussion: Ist das fair? Trade-off Nutzer vs. Plattform
|
||||
- Tipp für FotografInnen: Portfolio auf eigener Website
|
||||
- Diskussion: Ist das fair? Trade-off Nutzende vs. Plattform
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -1062,7 +1062,7 @@ KLAUSURRELEVANT:
|
||||
|
||||
**Codec** (Coder-Decoder) definiert den Kompressionsalgorithmus. Derselbe Container kann verschiedene Codecs enthalten – die Dateiendung verrät den Codec nicht.
|
||||
|
||||
| Container | Entwickler | Typische Codecs | Besonderheit |
|
||||
| Container | Entwicklung | Typische Codecs | Besonderheit |
|
||||
|-----------|------------|-----------------|--------------|
|
||||
| MP4 | ISO/MPEG | H.264, H.265, AAC | Web-Standard, DRM-fähig |
|
||||
| MKV | Matroska | Alle | Beliebig viele Streams, Kapitel |
|
||||
@@ -1326,7 +1326,7 @@ H.264 (2003) ermöglichte erst YouTube (2005), Netflix-Streaming (2007) und Blu-
|
||||
|
||||
**Hardware-Ubiquität:** Seit 2010 hat jedes Smartphone, jede GPU, jeder Smart-TV einen H.264-Hardware-Decoder. Encoding in Echtzeit braucht keine CPU – das ermöglichte erst mobiles Video-Streaming und Videotelefonie.
|
||||
|
||||
**Patent-Pool (MPEG-LA):** ~2.000 Patente von 30+ Unternehmen. Endnutzer-Streaming ist lizenzfrei; Hardware-Hersteller zahlen ~$0,20/Gerät.
|
||||
**Patent-Pool (MPEG-LA):** ~2.000 Patente von 30+ Unternehmen. Endnutzungs-Streaming ist lizenzfrei; Hardware-Hersteller zahlen ~$0,20/Gerät.
|
||||
|
||||
---
|
||||
|
||||
@@ -1347,7 +1347,7 @@ H.264 (2003) ermöglichte erst YouTube (2005), Netflix-Streaming (2007) und Blu-
|
||||
<!--
|
||||
- MPEG-LA = Licensing Authority
|
||||
- Firefox weigerte sich lange, H.264 zu unterstützen
|
||||
- "Free to View" gilt nur für Endnutzer-Streaming
|
||||
- "Free to View" gilt nur für Endnutzungs-Streaming
|
||||
- Diskussion: Sollten Standards patent-frei sein?
|
||||
-->
|
||||
|
||||
|
||||
@@ -154,7 +154,7 @@ Hersteller: Dezimal (SI-Präfix) - klingt mehr!
|
||||
Betriebssysteme: Binär - aber zeigen "GB" statt "GiB"
|
||||
Diskrepanz bei 1 TB: 1.000.000.000.000 vs. 1.099.511.627.776 Bytes
|
||||
→ 10% Unterschied bei TB-Größen
|
||||
Verwirrung für Konsumenten seit Jahrzehnten
|
||||
Verwirrung für KonsumentInnen seit Jahrzehnten
|
||||
ISO/IEC 80000-13: Definiert KiB, MiB, GiB, TiB (2008)
|
||||
-->
|
||||
|
||||
@@ -592,7 +592,7 @@ Voll: Langsamstes Backup, schnellste Wiederherstellung
|
||||
|
||||
<!--
|
||||
Time Machine: Stündliche Snapshots, APFS-Integration
|
||||
Veeam: Enterprise-Level, kostenlose Endnutzer-Version
|
||||
Veeam: Enterprise-Level, kostenlose Privatversion
|
||||
rsync: Unix-Klassiker, extrem effizient
|
||||
Borg: Deduplizierung + Verschlüsselung
|
||||
-->
|
||||
|
||||
@@ -160,7 +160,7 @@ AWS Snowmobile: 45-Fuß-Container auf LKW
|
||||
|
||||
**Prozess:**
|
||||
1. AWS schickt verschlüsseltes Gerät
|
||||
2. Kunde kopiert Daten lokal (schnell!)
|
||||
2. KundIn kopiert Daten lokal (schnell!)
|
||||
3. Gerät zurück an AWS
|
||||
4. AWS lädt in S3 hoch
|
||||
|
||||
@@ -220,7 +220,7 @@ Server unter Last (symbolisch)
|
||||
**Klassisches Modell:** Ein Server, viele Clients
|
||||
|
||||
**Problem:**
|
||||
1 Million User wollen 1 GB-Datei
|
||||
1 Million Nutzende wollen 1 GB-Datei
|
||||
→ Server braucht **1 PB Bandbreite!**
|
||||
→ Server überlastet → **"Hug of Death"**
|
||||
|
||||
@@ -252,7 +252,7 @@ Globale Verteilung
|
||||
**Funktionsweise:**
|
||||
1. **Origin Server** (Hauptquelle)
|
||||
2. **Edge Servers** (geografisch verteilt)
|
||||
3. User → nächster Edge Server
|
||||
3. Nutzende → nächster Edge Server
|
||||
4. Erste Anfrage: Edge holt von Origin, cached
|
||||
5. Weitere Anfragen: Direkt vom Edge (schnell!)
|
||||
|
||||
@@ -277,7 +277,7 @@ Große CDN-Anbieter: Cloudflare, Akamai, Amazon CloudFront, Fastly
|
||||
- Lange Cache-Zeit (TTL: Tage/Wochen)
|
||||
|
||||
**Dynamic Content:**
|
||||
- User-spezifisch (Profil)
|
||||
- Nutzungs-spezifisch (Profil)
|
||||
- Kurze TTL oder nicht cachebar
|
||||
|
||||
**Cache Invalidation:**
|
||||
@@ -349,14 +349,14 @@ Dezentral, jeder ist Client & Server
|
||||
- IPFS (InterPlanetary File System)
|
||||
- Blockchain (Bitcoin, Ethereum)
|
||||
|
||||
**Vorteil:** Skalierbar (mehr User = mehr Bandbreite!)
|
||||
**Vorteil:** Skalierbar (mehr Nutzende = mehr Bandbreite!)
|
||||
|
||||
**Nachteil:** Langsam bei wenigen Peers, oft für Piraterie missbraucht
|
||||
|
||||
<!--
|
||||
P2P vs. Client-Server: Kein zentraler Server
|
||||
Last verteilt sich auf alle Teilnehmer
|
||||
Je mehr User, desto schneller (umgekehrt zu Client-Server!)
|
||||
Last verteilt sich auf alle Teilnehmenden
|
||||
Je mehr Nutzende, desto schneller (umgekehrt zu Client-Server!)
|
||||
Zensur-resistent: Kein Single Point of Failure
|
||||
Rechtliche Grauzone: Technologie neutral, aber oft illegal genutzt
|
||||
-->
|
||||
@@ -1023,8 +1023,8 @@ Privacy-Albtraum
|
||||
|
||||
**Beispiele:**
|
||||
- **Foto:** Kamera, Datum, GPS, Belichtung
|
||||
- **MP3:** Künstler, Album, Jahr, Genre, Cover
|
||||
- **PDF:** Autor, Datum, Software
|
||||
- **MP3:** KünstlerInnen, Album, Jahr, Genre, Cover
|
||||
- **PDF:** AutorIn, Datum, Software
|
||||
- **E-Mail:** Absender, Empfänger, Zeitstempel
|
||||
|
||||
**Warum wichtig?**
|
||||
@@ -1180,7 +1180,7 @@ Wikipedia für Musik-Metadaten
|
||||
**Idee:** Wikipedia für Musik-Metadaten
|
||||
|
||||
**Community-gepflegt:**
|
||||
- Künstler, Alben, Tracks
|
||||
- KünstlerInnen, Alben, Tracks
|
||||
- Relationships (Band-Mitglieder, Label...)
|
||||
- Releases (verschiedene Editionen, Länder)
|
||||
|
||||
@@ -1239,7 +1239,7 @@ Versteckte Informationen sichtbar
|
||||
**PDF-Metadaten (XMP):**
|
||||
|
||||
**Gespeichert:**
|
||||
- Titel, Autor, Betreff, Keywords
|
||||
- Titel, AutorIn, Betreff, Keywords
|
||||
- Erstellungsdatum, Änderungsdatum
|
||||
- Software, **Company** (aus Office-Lizenz!)
|
||||
|
||||
@@ -1600,7 +1600,7 @@ QKD: Abhör-sichere Kommunikation (Quantenmechanik garantiert)
|
||||
|
||||
**Filecoin (2017):**
|
||||
- Blockchain-basiert
|
||||
- User vermieten Festplatten-Platz
|
||||
- Nutzende vermieten Festplatten-Platz
|
||||
- Bezahlung in FIL (Kryptowährung)
|
||||
|
||||
**Arweave (2018):**
|
||||
@@ -1638,7 +1638,7 @@ Legitime Use-Cases: NFT-Storage, Zensur-resistente Archivierung
|
||||
- 5G + Edge Computing nötig
|
||||
|
||||
**Cloud Gaming:**
|
||||
- Spiel im Rechenzentrum, Stream zu User
|
||||
- Spiel im Rechenzentrum, Stream zu Nutzenden
|
||||
- Input-Lag = Todfeind (<50ms)
|
||||
|
||||
**Problem:** Physik (Lichtgeschwindigkeit!)
|
||||
@@ -1647,7 +1647,7 @@ Legitime Use-Cases: NFT-Storage, Zensur-resistente Archivierung
|
||||
8K: YouTube unterstützt, aber wer hat 8K-Monitor?
|
||||
VR: Meta Quest, Apple Vision Pro
|
||||
Latenz: Lichtgeschwindigkeit ~300.000 km/s, aber Routing + Processing addiert sich
|
||||
Edge Computing: Server näher an User (5G-Masten)
|
||||
Edge Computing: Server näher an Nutzende (5G-Masten)
|
||||
Cloud Gaming: Stadia gescheitert (2023 †), GeForce Now, Xbox Cloud
|
||||
Input-Lag: Fiber ~5ms/1000km, aber Server-Processing + Encoding + Decoding
|
||||
-->
|
||||
|
||||
@@ -451,9 +451,9 @@ Ordne jede Eigenschaft zu: Vorteil von Analog oder Vorteil von Digital?
|
||||
**Punkte:** 3
|
||||
**Typ:** `[ESSAY]`
|
||||
|
||||
Erklären Sie die drei digitalen Distributionswege **Download**, **Streaming** und **Peer-to-Peer (P2P)**. Beschreiben Sie für jeden Weg: (1) wie die Daten zum Nutzer gelangen, (2) ob der Nutzer eine dauerhafte Kopie erhält, und (3) nennen Sie je ein Beispiel.
|
||||
Erklären Sie die drei digitalen Distributionswege **Download**, **Streaming** und **Peer-to-Peer (P2P)**. Beschreiben Sie für jeden Weg: (1) wie die Daten zu Nutzenden gelangen, (2) ob Nutzende eine dauerhafte Kopie erhalten, und (3) nennen Sie je ein Beispiel.
|
||||
|
||||
> **Musterlösung:** **Download:** Datei wird vollständig vom Server heruntergeladen und lokal gespeichert. Nutzer erhält dauerhafte Kopie. Beispiel: iTunes Store, Steam. **Streaming:** Daten werden während des Abspielens übertragen, keine dauerhafte lokale Kopie. Beispiel: Netflix, Spotify. **P2P:** Nutzer laden Teile der Datei gleichzeitig von vielen anderen Nutzern herunter (dezentral). Dauerhafte Kopie möglich. Beispiel: BitTorrent.
|
||||
> **Musterlösung:** **Download:** Datei wird vollständig vom Server heruntergeladen und lokal gespeichert. Nutzende erhalten dauerhafte Kopie. Beispiel: iTunes Store, Steam. **Streaming:** Daten werden während des Abspielens übertragen, keine dauerhafte lokale Kopie. Beispiel: Netflix, Spotify. **P2P:** Nutzende laden Teile der Datei gleichzeitig von vielen anderen herunter (dezentral). Dauerhafte Kopie möglich. Beispiel: BitTorrent.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user