Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
a7ad4c0f20 | ||
|
|
8974af49ab | ||
|
|
c8935845f6 | ||
|
|
11fd964c8c | ||
|
|
ff2d8c12c5 | ||
|
|
85b8f7f355 | ||
|
|
1b21d8653c | ||
|
|
261a2e3eff | ||
|
|
a63caa9d2d | ||
|
|
1b551c333a | ||
|
|
ddbda461d0 | ||
|
|
32dc418957 | ||
|
|
d87fce67fc | ||
|
|
2d7731c452 | ||
|
|
adaaae5ff2 |
No files matched your search
@@ -1,172 +0,0 @@
|
||||
# Asset-Liste: Bildbeschreibungen & Kontext
|
||||
|
||||
## **Allgemein / Titel**
|
||||
|
||||
| Dateiname | Kontext | Beschreibung für Suche/Generierung |
|
||||
|-----------|---------|-----------------------------------|
|
||||
| `digital-landscape.jpg` | Titelfolie, Einstieg | Futuristische digitale Landschaft mit Netzwerk-Verbindungen, leuchtende Datenpunkte, abstrakte binäre Muster, Glasfaser-Optik, cyber-ästhetisch, blau-violette Farbpalette |
|
||||
|
||||
---
|
||||
|
||||
## **Woche 1: Bits, Bytes & Encoding**
|
||||
|
||||
| Dateiname | Kontext | Beschreibung |
|
||||
|-----------|---------|--------------|
|
||||
| `matrix-code.jpg` | Hex-Dump Mystery-Folie | Matrix-Style fallender grüner Code, binäre Zahlen, Hex-Zahlen (0-9, A-F), schwarzer Hintergrund, mysteriös, "digital rain" |
|
||||
| `lightbulb-onoff.jpg` | Bit-Demonstration (AN/AUS) | Zwei Glühbirnen nebeneinander: eine leuchtend (AN/gelb), eine dunkel (AUS/grau), minimalistisch, einfache Illustration, technisch-didaktisch |
|
||||
| `grayscale-gradient.jpg` | 256 Graustufen-Beispiel | Sanfter Verlauf von reinem Schwarz (#000000) zu reinem Weiß (#FFFFFF), horizontal oder vertikal, 256 diskrete Stufen sichtbar, technische Visualisierung |
|
||||
| `rgb-color-model.jpg` | RGB-Farben erklären | RGB-Farbmodell-Diagramm mit drei überlappenden Kreisen (Rot, Grün, Blau), Venn-Diagramm-Stil, zeigt additive Farbmischung (Rot+Grün=Gelb, etc.), sauber, lehrreich |
|
||||
| `ascii-table.png` | ASCII-Tabelle (1963) | Vollständige ASCII-Tabelle, 128 Zeichen (0-127), tabellarische Darstellung mit Dezimal-, Hex- und Zeichen-Spalten, retro/technisch, schwarz-weiß oder grün-schwarz (Terminal-Stil) |
|
||||
| `hex-binary-table.jpg` | Hexadezimal-Erklärung | Konversionstabelle: Dezimal (0-15), Binär (0000-1111), Hexadezimal (0-F), drei Spalten, übersichtlich, didaktische Grafik |
|
||||
| `hexeditor-screenshot.png` | Hex-Editor mit PNG-Datei | Screenshot eines Hex-Editors (z.B. HxD, Hex Fiend), zeigt PNG-Datei-Header mit Magic Number `89 50 4E 47`, linke Spalte Adressen, Mitte Hex-Werte, rechts ASCII-Darstellung |
|
||||
|
||||
---
|
||||
|
||||
## **Woche 2: MP3 & Audio-Kompression**
|
||||
|
||||
| Dateiname | Kontext | Beschreibung |
|
||||
|-----------|---------|--------------|
|
||||
| `cassette-ipod.jpg` | Analog vs. Digital Kontrast | Kassette (1980er, retro) neben iPod Classic (2000er, weiß), Side-by-Side-Vergleich, nostalgisch vs. modern, auf neutralem Hintergrund |
|
||||
| `compression-types.jpg` | Lossless vs. Lossy Visualisierung | Diagramm mit zwei Pfeilen: "Lossless" (Original → Komprimiert → Original exakt rekonstruiert), "Lossy" (Original → Komprimiert → Ähnlich, aber nicht identisch), Wasserglas-Metapher möglich |
|
||||
| `karlheinz-brandenburg.jpg` | Fraunhofer IIS, MP3-Erfinder | Porträtfoto von Karlheinz Brandenburg (Entwickler, ~60 Jahre, graues Haar, Brille), professionell, Konferenz- oder Labor-Setting, alternativ: Fraunhofer IIS-Gebäude Erlangen |
|
||||
| `suzanne-vega.jpg` | "Tom's Diner" – erster MP3-Song | Suzanne Vega (Sängerin, 1980er-90er Ästhetik), Album-Cover "Solitude Standing" (1987) oder Konzertfoto, warm, akustisch, ikonisch |
|
||||
| `audio-spectrogram.jpg` | Frequenz-Vergleich (Bitrate) | Spektrogramm-Vergleich: drei Panels (Original, 320 kbps, 128 kbps), Y-Achse = Frequenz (Hz), X-Achse = Zeit, Farbe = Intensität, hohe Frequenzen verschwinden bei niedriger Bitrate (dunkle Bereiche oben) |
|
||||
| `napster-interface.jpg` | Napster-Screenshot (1999) | Screenshot Napster-Software (Windows 98/2000-Stil), Suchleiste, Liste von MP3-Dateien, Peer-Verbindungen, retro-UI, grün-graue Interface, historisch |
|
||||
|
||||
---
|
||||
|
||||
## **Woche 3: Bilder & JPEG-Kompression**
|
||||
|
||||
| Dateiname | Kontext | Beschreibung |
|
||||
|-----------|---------|--------------|
|
||||
| `photo-comparison.jpg` | Hochauflösend vs. komprimiert | Side-by-Side: Linkes Bild scharf und detailliert, rechts stark JPEG-komprimiert mit sichtbaren Artefakten (Blocking, Ringing), gleiches Motiv (z.B. Landschaft oder Porträt) |
|
||||
| `jpeg-artifacts.jpg` | JPEG-Artefakte Zoom | Stark vergrößerter Ausschnitt eines JPEG-Bildes: 8×8-Blöcke sichtbar (Blocking), "Geister" um Text/Kanten (Ringing), Farb-Banding in Himmel/Verläufen |
|
||||
| `gif-animation.gif` | GIF-Animation (Meme) | Klassisches animiertes GIF (z.B. "Dancing Baby" 90er-Stil oder modernes Meme), 256 Farben, loop, pixelig-charmant, Internet-Kultur |
|
||||
| `instagram-quality-loss.jpg` | Vorher/Nachher Instagram-Upload | Zwei Versionen eines Fotos: Oben "Original" (scharf, hochauflösend), unten "Nach Instagram-Upload" (sichtbar schlechter, matschig, Kompressionsartefakte), Pfeile zeigen Unterschiede |
|
||||
|
||||
---
|
||||
|
||||
## **Woche 4: Video-Kompression & Codecs**
|
||||
|
||||
| Dateiname | Kontext | Beschreibung |
|
||||
|-----------|---------|--------------|
|
||||
| `netflix-4k.jpg` | Netflix 4K-Streaming | Netflix-Interface auf 4K-TV, zeigt Filmauswahl mit "4K Ultra HD"-Badge, scharfes Bild, moderne Wohnzimmer-Setting, oder: Netflix-Logo mit "4K" |
|
||||
| `container-codec-diagram.jpg` | Container vs. Codec Visualisierung | Diagramm: Schachtel (MP4-Container) enthält mehrere Streams – Video-Track (H.264), Audio-Track (AAC), Untertitel (SRT), Metadaten, farbcodiert, technisch-didaktisch |
|
||||
| `iframe-pframe-diagram.jpg` | I/P/B-Frame-Abhängigkeiten | Diagramm: Sequenz von Frames (I-B-B-P-B-B-I), Pfeile zeigen Abhängigkeiten (P zeigt auf I, B zeigt auf I und P), farbcodiert (I=rot, P=blau, B=grün), technisch |
|
||||
| `youtube-vp9.jpg` | YouTube VP9-Logo | YouTube-Logo mit "VP9"-Badge oder Text, alternativ: YouTube-Player mit VP9-Codec-Info (Stats for Nerds), modern, Google-Branding |
|
||||
| `av1-logo.jpg` | AV1-Logo (Alliance for Open Media) | AV1-Logo (stilisiertes "AV1" mit dreieckigem Design), schwarz oder weiß auf transparentem Hintergrund, modern, clean |
|
||||
| `streaming-quality-switch.jpg` | Adaptive Bitrate Streaming | Visualisierung: Videoplayer mit Qualitätsoptionen (240p, 480p, 720p, 1080p, 4K), Balkendiagramm zeigt Bandbreite über Zeit, Qualität wechselt dynamisch, Netzwerk-Symbol |
|
||||
|
||||
---
|
||||
|
||||
## **Woche 5: Speichermedien, Dateisysteme, Backup**
|
||||
|
||||
| Dateiname | Kontext | Beschreibung |
|
||||
|-----------|---------|--------------|
|
||||
| `hdd-ssd-comparison.jpg` | HDD vs. SSD Technologie | Aufgeschraubte HDD (Platter, Lesekopf sichtbar) neben SSD-Platine (Chips, keine beweglichen Teile), Side-by-Side, technisch-präzise, neutraler Hintergrund |
|
||||
| `directory-tree.jpg` | Verzeichnisbaum-Struktur | Baumdiagramm: Root (/) an der Spitze, Zweige zu Ordnern (home, usr, etc.), Unterordner, Dateien als Blätter, hierarchisch, clean, schwarz-weiß oder minimalistisch |
|
||||
| `backup-disaster.jpg` | Festplatten-Crash / Ransomware | Kaputte Festplatte (physisch beschädigt, Kratzer auf Platter) ODER Bildschirm mit Ransomware-Warnung ("Your files are encrypted"), dramatisch, Warnsignal |
|
||||
| `bit-rot.jpg` | Daten-Degradation über Zeit | Abstraktes Bild: Binärcode oder Pixel, die sich auflösen/verfallen, visuelle Metapher für Datenverlust, glitch-artig, beunruhigend |
|
||||
| `lto-tape.jpg` | LTO-Kassette + Laufwerk | LTO-Ultrium-Kassette (schwarz, kompakt, Label sichtbar) neben oder in LTO-Bandlaufwerk (Rack-Mount), professionelle Rechenzentrum-Ästhetik |
|
||||
| `m-disc.jpg` | M-DISC Blu-ray | M-DISC Blu-ray-Disc (mit "M-DISC"-Logo auf Disc oder Verpackung), Nahaufnahme, metallisch glänzend, hochwertig |
|
||||
| `dna-helix.jpg` | DNA-Storage Konzept | DNA-Doppelhelix mit überlagerten Binärcode (0 und 1) oder Daten-Symbolen, futuristisch, wissenschaftlich, blau-grüne Farbpalette, Sci-Fi-ästhetisch |
|
||||
|
||||
---
|
||||
|
||||
## **Woche 6: Schnittstellen (Hardware)**
|
||||
|
||||
| Dateiname | Kontext | Beschreibung |
|
||||
|-----------|---------|--------------|
|
||||
| `cable-mess.jpg` | Kabelsalat / Anschluss-Chaos | Haufen verschiedener Kabel (USB-A, USB-C, HDMI, DisplayPort, Lightning, Ethernet), durcheinander, chaotisch, auf Schreibtisch oder weiß, frustrierend |
|
||||
| `pc-back-1990s.jpg` | PC-Rückseite 1990er | Rückseite eines PCs aus den 90ern: VGA, PS/2 (lila/grün), Seriell (COM), Parallel (LPT), SCSI, viele verschiedene Ports, retro, nostalgisch, beige Gehäuse |
|
||||
| `usb-c-cables.jpg` | Identische USB-C-Kabel | Mehrere USB-C-Kabel (3-5), die identisch aussehen, aber mit Fragezeichen oder Labels ("USB 2.0?", "USB 4?", "Thunderbolt?"), Verwirrung symbolisierend |
|
||||
| `thunderbolt-logo.jpg` | Thunderbolt-Logo | Thunderbolt-Logo (Blitz-Symbol, schwarz oder weiß), offizielles Intel-Branding, clean, auf transparentem Hintergrund |
|
||||
| `hdmi-cable.jpg` | HDMI-Kabel + Stecker | HDMI-Kabel mit Stecker (Typ A, Standard), Nahaufnahme des Pin-Layouts, schwarz, auf weißem Hintergrund, technisch-präzise |
|
||||
| `displayport-cable.jpg` | DisplayPort-Kabel + Stecker | DisplayPort-Kabel mit Stecker (charakteristische asymmetrische Form, Verriegelung sichtbar), schwarz, technisch |
|
||||
| `hdcp-warning.jpg` | HDCP-Fehler Bildschirm | Schwarzer Bildschirm oder blauer Error-Screen mit Text "HDCP Error" oder "HDCP-Handshake fehlgeschlagen", frustrierend, technischer Fehler |
|
||||
| `ethernet-cable.jpg` | Ethernet-Kabel (RJ45) | Cat6 Ethernet-Kabel mit RJ45-Stecker, Nahaufnahme der 8 Pins (farbcodiert), blau oder grau, technisch |
|
||||
| `vintage-ports.jpg` | Alte Anschlüsse (Nostalgie) | Collage: VGA-Port (blau, 15-Pin), PS/2 (lila/grün, rund), Seriell (DB9), Parallel (DB25), retro, beige/grau, Museums-Qualität |
|
||||
|
||||
---
|
||||
|
||||
## **Woche 7: Distribution (CDN, P2P, Streaming)**
|
||||
|
||||
| Dateiname | Kontext | Beschreibung |
|
||||
|-----------|---------|--------------|
|
||||
| `sneakernet-truck.jpg` | LKW voller Festplatten | LKW geladen mit Servern oder Festplatten-Paletten, "Sneakernet"-Konzept, humorvoll-dokumentarisch, logistisch, Lagerhalle oder Straße |
|
||||
| `aws-snowmobile.jpg` | AWS Snowmobile | AWS Snowmobile (45-Fuß-Container auf LKW), weiß mit AWS-Logo, dramatisch, Rechenzentrum im Hintergrund, offizielles AWS-Pressefoto-Stil |
|
||||
| `cd-dvd-bluray.jpg` | Optische Medien Evolution | Drei Discs nebeneinander: CD (compact, silber), DVD (ähnlich, aber Label), Blu-ray (blau-schimmernd), Evolution, zeitlich geordnet |
|
||||
| `server-overload.jpg` | Server unter Last (Hug of Death) | Server-Racks mit roten Warnlichtern oder Error-Screens, Rauch/Hitze-Effekt (metaphorisch), Überlastung, dramatisch-technisch |
|
||||
| `cdn-map.jpg` | CDN-Knoten Weltkarte | Weltkarte mit leuchtenden Punkten (Points of Presence), Linien verbinden Punkte (Netzwerk), blau-violett, futuristisch, globale Infrastruktur |
|
||||
| `netflix-openconnect.jpg` | Netflix Open Connect Appliance | Netflix Open Connect Server-Appliance (schwarzes Rack-Mount-Gerät, Netflix-Logo), professionell, Rechenzentrum-Setting |
|
||||
| `p2p-network.jpg` | P2P-Netzwerk Diagramm | Netzwerk-Diagramm: Viele Knoten (Peers) verbunden, keine zentrale Hierarchie, dezentral, organisch, Linien zwischen Knoten, technisch-didaktisch |
|
||||
| `bittorrent-swarm.jpg` | BitTorrent-Swarm Visualisierung | Visualisierung: Zentrale Datei (Torrent), umgeben von vielen Peers (kleine Kreise), Pfeile zeigen Datenfluss (Chunks), dynamisch, farbcodiert |
|
||||
| `pirate-bay-logo.jpg` | The Pirate Bay Logo | The Pirate Bay Schiffs-Logo (Piratenschiff, schwarz-weiß oder farbig), ikonisch, kontroverser historischer Kontext |
|
||||
| `ipfs-logo.jpg` | IPFS Logo | IPFS-Logo (Würfel-Design mit Verbindungen), blau-weiß, geometrisch, modern, offizielles Protocol Labs-Branding |
|
||||
| `streaming-hls.jpg` | Streaming-Pipeline (HLS/DASH) | Diagramm: Encoder → Segmente (2-10s) → CDN → Player, verschiedene Qualitäten parallel (240p-4K), technisch, Flowchart-Stil |
|
||||
|
||||
---
|
||||
|
||||
## **Woche 8: APIs & Software-Schnittstellen**
|
||||
|
||||
| Dateiname | Kontext | Beschreibung |
|
||||
|-----------|---------|--------------|
|
||||
| `api-diagram.jpg` | API-Kommunikation | Diagramm: Zwei Boxen (App A, App B) verbunden durch "API" (Pfeile bidirektional), zeigt Request/Response, clean, technisch-minimalistisch |
|
||||
| `http-request-response.jpg` | HTTP Request/Response-Zyklus | Diagramm: Client (Browser-Symbol) → Request (Pfeil mit "GET /page") → Server (Server-Symbol) → Response (Pfeil mit "200 OK + HTML") → Client, Zyklus, didaktisch |
|
||||
| `rest-api.jpg` | REST-API Struktur | Diagramm: URLs als Ressourcen (`/users`, `/posts`), HTTP-Methods (GET, POST, PUT, DELETE) daneben, tabellarisch oder Baum-Struktur, technisch |
|
||||
| `graphql-logo.jpg` | GraphQL Logo | GraphQL-Logo (rosa/magenta Raute mit "GraphQL"-Text), offizielles Branding, clean, auf transparentem Hintergrund |
|
||||
| `websocket-diagram.jpg` | WebSocket bidirektionale Verbindung | Diagramm: Client ↔ Server (bidirektionale Pfeile), "Persistent Connection", im Gegensatz zu HTTP (unidirektionale Pfeile), technisch-vergleichend |
|
||||
| `grpc-logo.jpg` | gRPC Logo | gRPC-Logo (blau-grünes "gRPC"-Design), offizielles Google/CNCF-Branding, modern |
|
||||
|
||||
---
|
||||
|
||||
## **Woche 9: Metadaten & Interoperabilität**
|
||||
|
||||
| Dateiname | Kontext | Beschreibung |
|
||||
|-----------|---------|--------------|
|
||||
| `exif-gps.jpg` | EXIF-Daten mit GPS | Foto mit eingeblendeten EXIF-Daten als Overlay: GPS-Koordinaten, Kamera-Modell, Datum, Kartenpunkt zeigt Standort, Privacy-Warnung, technisch-dokumentarisch |
|
||||
| `mcafee-exif-fail.jpg` | John McAfee Guatemala-Story | Foto von John McAfee (2012, Guatemala, mit Hund) ODER Screenshot des Vice-Artikels mit Foto + GPS-Koordinaten eingeblendet, historisch-dokumentarisch |
|
||||
| `id3-tag-editor.jpg` | ID3-Tag-Editor Screenshot | Screenshot eines ID3-Editors (z.B. Kid3, mp3tag), zeigt MP3-Datei mit Feldern (Artist, Album, Year, Genre, Cover-Art), übersichtlich |
|
||||
| `musicbrainz-logo.jpg` | MusicBrainz Logo | MusicBrainz-Logo (stilisierte Note oder "MB"-Buchstaben), offizielles Branding, open-source-freundlich |
|
||||
| `pdf-metadata-leak.jpg` | PDF-Metadaten Analyse | Screenshot: PDF-Metadaten-Fenster zeigt versteckte Infos (Autor, Firma, Software, Änderungsdatum), Warnung, forensisch |
|
||||
| `binary.png` | Binäre Limitationen | Binärcode (0 und 1) als Hintergrund, eventuell mit Warnung oder Fragezeichen, technisch-abstrakt, schwarz-weiß oder grün-schwarz (Matrix-Stil) |
|
||||
|
||||
---
|
||||
|
||||
## **Woche 10: Zukunft & Synthese**
|
||||
|
||||
| Dateiname | Kontext | Beschreibung |
|
||||
|-----------|---------|--------------|
|
||||
| `futuristic-datacenter.jpg` | Futuristisches Rechenzentrum | Modernes Rechenzentrum mit Server-Racks, blaue LED-Beleuchtung, alternativ: DNA-Helix überlagert auf Servern, Sci-Fi-ästhetisch, sauber, high-tech |
|
||||
| `jpeg-xl-logo.jpg` | JPEG XL Logo | JPEG XL Logo (stilisiertes "JXL" oder "JPEG XL"), modern, clean, offizielles Branding |
|
||||
| `dna-storage-concept.jpg` | DNA-Storage Visualisierung | DNA-Doppelhelix mit Daten-Symbolen, Petrischale mit DNA-Proben, Laborumgebung, futuristisch-wissenschaftlich, blau-grün |
|
||||
| `science.jpg` | Wissenschaft/Forschung (Allgemein) | Wissenschaftliche Visualisierung: Labor, Mikroskop, DNA-Sequenzierung, oder abstrakte Wissenschafts-Grafik, professionell, blau-weiß |
|
||||
|
||||
---
|
||||
|
||||
## **Zusammenfassung: Asset-Kategorien**
|
||||
|
||||
| Kategorie | Anzahl | Notizen |
|
||||
|-----------|--------|---------|
|
||||
| **Technische Diagramme** | 15+ | Flow-Charts, Netzwerk-Topologien, Container/Codec-Visualisierungen |
|
||||
| **Screenshots/UIs** | 10+ | Hex-Editor, Napster, ID3-Editor, Netflix, Browser DevTools |
|
||||
| **Logos** | 8+ | Thunderbolt, HDMI, GraphQL, gRPC, IPFS, AV1, MusicBrainz, JPEG XL |
|
||||
| **Hardware-Fotos** | 12+ | HDDs, SSDs, Kabel, Ports, LTO-Tapes, M-DISC |
|
||||
| **Vergleiche (Vorher/Nachher)** | 5+ | JPEG-Artefakte, Instagram-Quality, HDD vs. SSD, Kassette vs. iPod |
|
||||
| **Historische/Nostalgie** | 6+ | 90er-PC, ASCII-Tabelle, Napster, WordPerfect, John McAfee |
|
||||
| **Futuristisch/Konzeptuell** | 5+ | DNA-Storage, Quantum, Futuristic Datacenter, AI-Compression |
|
||||
|
||||
---
|
||||
|
||||
## **Generierungs-Tipps für AI-Tools (Midjourney, DALL-E, Stable Diffusion)**
|
||||
|
||||
**Allgemeine Prompts-Zusätze:**
|
||||
- Für **technische Diagramme**: `"technical diagram, clean lines, minimal colors, educational, isometric view, white background"`
|
||||
- Für **Screenshots**: `"UI screenshot, realistic software interface, high resolution, modern design"`
|
||||
- Für **Fotos/Realismus**: `"product photography, studio lighting, white background, high detail, professional"`
|
||||
- Für **Futuristisch**: `"futuristic, sci-fi, blue-violet color palette, glowing, high-tech, cinematic lighting"`
|
||||
- Für **Retro/Nostalgie**: `"1990s aesthetic, beige computer, CRT monitor, retro technology, nostalgic"`
|
||||
|
||||
**Negative Prompts (was vermeiden):**
|
||||
- `"blurry, text artifacts, watermark, low quality, distorted, unrealistic proportions"`
|
||||
|
||||
@@ -87,6 +87,14 @@ This document lists all images needed for the lecture slides. Each image include
|
||||
- **Context**: Demonstrating compression quality loss
|
||||
- **AI Prompt**: Side-by-side comparison of same landscape photo: left side crystal clear high resolution, right side heavily compressed with visible JPEG artifacts, blocky pixels and color banding, split down the middle, educational comparison style
|
||||
|
||||
### ⬚ raster-vs-vector.png
|
||||
- **Context**: Comparison of raster and vector graphics scaling
|
||||
- **AI Prompt**: Split image showing scaling comparison: left side shows raster/bitmap image (photo of flower) that becomes pixelated when zoomed in, right side shows vector graphic (simple logo/icon) that stays crisp at any zoom level, magnifying glass effect on both sides, educational diagram style, clean white background
|
||||
|
||||
### ⬚ vector-circle-example.png
|
||||
- **Context**: Explaining how vector graphics store shapes mathematically
|
||||
- **AI Prompt**: Educational diagram showing a circle with labeled parameters: center point (x,y coordinates), radius line, color fill indicator, stroke width indicator, mathematical notation style, clean technical illustration, blueprint aesthetic
|
||||
|
||||
### ✅ jpeg-artifacts.png
|
||||
- **Context**: Close-up example of JPEG compression artifacts
|
||||
- **AI Prompt**: Close-up macro shot of heavily compressed JPEG image showing visible compression artifacts, blocky 8x8 pixel blocks, mosquito noise around edges, color banding in gradients, technical demonstration image
|
||||
@@ -127,6 +135,10 @@ This document lists all images needed for the lecture slides. Each image include
|
||||
|
||||
## Termin 3: Speichermedien & Schnittstellen
|
||||
|
||||
### ⬚ rosetta-disk.png
|
||||
- **Context**: Long-term archival - Rosetta Project by Long Now Foundation
|
||||
- **AI Prompt**: Rosetta Disk by Long Now Foundation, small nickel disk with micro-etched text visible under magnification, archival preservation technology, scientific artifact photography, emphasis on the intricate etched patterns containing thousands of languages
|
||||
|
||||
### ⬚ hdd-ssd-comparison.png
|
||||
- **Context**: Storage technology comparison
|
||||
- **AI Prompt**: Side-by-side comparison: opened hard disk drive showing silver platters and read/write head on left, modern NVMe SSD circuit board with flash chips on right, technical product photography, white background, educational comparison
|
||||
@@ -187,6 +199,14 @@ This document lists all images needed for the lecture slides. Each image include
|
||||
- **Context**: Network connectivity
|
||||
- **AI Prompt**: Blue Ethernet cable with clear RJ45 connector showing gold pins, Cat6 or Cat7 network cable, technical product shot, networking infrastructure aesthetic
|
||||
|
||||
### ⬚ wifi-bluetooth.png
|
||||
- **Context**: Wireless connectivity introduction (WLAN & Bluetooth slides)
|
||||
- **AI Prompt**: Modern Wi-Fi router with antenna and Bluetooth symbol overlay, wireless technology concept, clean product photography showing both standards, blue LED lights, home networking aesthetic
|
||||
|
||||
### ⬚ nas-server.png
|
||||
- **Context**: Network Attached Storage introduction
|
||||
- **AI Prompt**: Synology or QNAP NAS device with multiple hard drive bays, blue LED status lights, home server setup in modern office environment, network storage infrastructure, clean product photography
|
||||
|
||||
### ⬚ vintage-ports.png
|
||||
- **Context**: Legacy connector nostalgia/history
|
||||
- **AI Prompt**: Collection of vintage computer ports and connectors: VGA blue, PS/2 keyboard and mouse, serial DB9, parallel DB25, arranged like museum display, retro computing history, nostalgic tech photography
|
||||
@@ -304,9 +324,9 @@ This document lists all images needed for the lecture slides. Each image include
|
||||
| Intro | 1 | 1 | 0 |
|
||||
| Termin 1 (Grundlagen/Text/Audio) | 13 | 13 | 0 |
|
||||
| Termin 2 (Bild/Audio/Video) | 10 | 10 | 0 |
|
||||
| Termin 3 (Speichermedien) | 16 | 0 | 16 |
|
||||
| Termin 3 (Speichermedien) | 19 | 0 | 19 |
|
||||
| Termin 4 (Distribution/APIs) | 25 | 0 | 25 |
|
||||
| **Total** | **65** | **24** | **41** |
|
||||
| **Total** | **68** | **24** | **44** |
|
||||
|
||||
**Note:** grayscale-gradient.png is marked ⚠️ NEEDS REGENERATION due to visibility issues at edges.
|
||||
|
||||
|
||||
@@ -7,15 +7,7 @@ Hochschule der Medien Stuttgart · Wintersemester 2025/26
|
||||
|
||||
---
|
||||
|
||||
## Über dieses Modul
|
||||
|
||||
> *Internettechnologien 1 – "Technische Grundlagen von IT-Projekten"*
|
||||
|
||||
Die Digitalisierung verändert die Prozesse und Tätigkeiten in allen Branchen. Sie hat neue Geschäftsmodelle ermöglicht und auch unseren Alltag stark verändert. Kaum ein Projekt in der Medienwelt kommt ohne digitale Technik aus – als Produkt, Kollaborationsplattform oder Marketing- und Verkaufsplattform.
|
||||
|
||||
**Ziel:** Technische Grundlagen verstehen, um mit Entwicklungsteams, Kunden und Projektpartnern auf Augenhöhe zusammenarbeiten zu können.
|
||||
|
||||
### Termine
|
||||
## Termine
|
||||
|
||||
| # | Datum | Thema |
|
||||
|---|-------|-------|
|
||||
@@ -34,7 +26,7 @@ In dieser Veranstaltung erwerben Sie folgende Kompetenzen:
|
||||
- Speichermedien und Schnittstellen kennen
|
||||
- APIs und Distributionswege verstehen
|
||||
|
||||
**Dozent:** Michael Czechowski · michael.czechowski@lehre.dhbw-stuttgart.de
|
||||
**Dozent:** Michael Czechowski · mail@librete.ch
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -37,8 +37,8 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Internettechnologien 1
|
||||
## "Technische Grundlagen von IT-Projekten"
|
||||
# Willkommen!
|
||||
## Termin 1 – Einführung & Grundlagen
|
||||
|
||||
---
|
||||
|
||||
@@ -63,12 +63,12 @@ Fragen jederzeit willkommen
|
||||
|
||||
**Bitte Hand heben:**
|
||||
|
||||
1. Wer hat schon mal ein Video komprimiert/konvertiert?
|
||||
2. Wer hat schon mal eine Datei mit einem Hex-Editor geöffnet?
|
||||
3. Wer weiß, was der Unterschied zwischen JPEG und PNG ist?
|
||||
4. Wer hat schon mal mit APIs gearbeitet?
|
||||
5. Wer weiß, was UTF-8 bedeutet?
|
||||
6. **Wer hat schon mal HTML oder CSS gemacht?** (Hex-Farben wie `#FF0000`?)
|
||||
1) Wer hat schon mal ein Video komprimiert/konvertiert?
|
||||
2) Wer hat schon mal eine Datei mit einem Hex-Editor geöffnet?
|
||||
3) Wer weiß, was der Unterschied zwischen JPEG und PNG ist?
|
||||
4) Wer hat schon mal mit APIs gearbeitet?
|
||||
5) Wer weiß, was UTF-8 bedeutet?
|
||||
6) **Wer hat schon mal HTML oder CSS gemacht?** (Hex-Farben wie `#FF0000`?)
|
||||
|
||||
<!--
|
||||
Niveau der Gruppe einschätzen
|
||||
@@ -81,31 +81,37 @@ HTML/CSS-Frage: Viele kennen Hex-Codes aus Webdesign
|
||||
|
||||
# Warum dieses Modul?
|
||||
|
||||
Die Digitalisierung verändert die Prozesse und Tätigkeiten in allen Branchen. Sie hat neue Geschäftsmodelle ermöglicht und auch unseren Alltag stark verändert.
|
||||
**Digitale Medien sind überall** – aber was steckt dahinter?
|
||||
|
||||
Kaum ein Projekt in der Medienwelt kommt ohne digitale Technik aus:
|
||||
- Als **Produkt** (z.B. Verkauf einer Webseite)
|
||||
- Als **Kollaborationsplattform**
|
||||
- Als **Marketing- und Verkaufsplattform**
|
||||
* Warum ist ein JPEG kleiner als ein PNG?
|
||||
* Warum klingt MP3 anders als FLAC?
|
||||
* Warum zeigt meine 1 TB Festplatte nur 931 GB?
|
||||
* Warum ist USB-C so verwirrend?
|
||||
* Wie funktioniert eigentlich Streaming?
|
||||
* **→ Die Technik dahinter verstehen!**
|
||||
|
||||
<!--
|
||||
Aus dem Modulhandbuch "Internettechnologien 1"
|
||||
Digitalisierung betrifft alle Branchen
|
||||
Technik ist nicht optional, sondern zentral
|
||||
Praxisnahe Fragen aus dem Alltag
|
||||
Nicht nur "was", sondern "warum"
|
||||
Verständnis für technische Entscheidungen
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Das Ziel
|
||||
|
||||
**Technische Grundlagen verstehen**, um mit Entwicklungsteams, Kunden und Projektpartnern **auf Augenhöhe** zusammenarbeiten zu können.
|
||||
**Technische Grundlagen verstehen**, um fundierte Entscheidungen treffen zu können.
|
||||
|
||||
Grundkenntnisse der Internettechnologien und der Prozesse der Software-Entwicklung sind **unabdingbar**, um ein gemeinsames Verständnis von Projektanforderungen und dem Projektvorgehen zu erreichen.
|
||||
Als Digital- und Medienwirtschaftler:innen werdet ihr täglich mit technischen Fragen konfrontiert:
|
||||
* Welches Format für welchen Zweck?
|
||||
* Welche Schnittstelle für welches Gerät?
|
||||
* Wie funktioniert die Distribution digitaler Inhalte?
|
||||
* **→ Mitreden können – nicht programmieren!**
|
||||
|
||||
<!--
|
||||
Nicht: Ihr sollt Programmierer werden
|
||||
Sondern: Ihr sollt mitreden können
|
||||
"Auf Augenhöhe" = verstehen, was Entwickler:innen meinen
|
||||
Sondern: Ihr sollt technische Entscheidungen verstehen
|
||||
Praxisbezug: Medienproduktion, Marketing, Projektmanagement
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -114,11 +120,11 @@ Sondern: Ihr sollt mitreden können
|
||||
|
||||
**In dieser Veranstaltung erwerbt ihr folgende Kompetenzen:**
|
||||
|
||||
- Technische Konzepte des Internets verstehen (Netzwerke, Protokolle, Client/Server)
|
||||
- Dateiformate analysieren und verstehen
|
||||
- Grundlagen von Kompression (Audio, Bild, Video)
|
||||
- Speichermedien und Schnittstellen kennen
|
||||
- APIs und Distributionswege verstehen
|
||||
* Technische Konzepte des Internets verstehen (Netzwerke, Protokolle, Client/Server)
|
||||
* Dateiformate analysieren und verstehen
|
||||
* Grundlagen von Kompression (Audio, Bild, Video)
|
||||
* Speichermedien und Schnittstellen kennen
|
||||
* APIs und Distributionswege verstehen
|
||||
|
||||
<!--
|
||||
Fokus auf Verständnis, nicht auf Programmierung
|
||||
@@ -148,3 +154,21 @@ Praktische Übungen jede Woche
|
||||
Medienwissenschaftler:innen, nicht Informatiker:innen
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Prüfungsleistung
|
||||
|
||||
**Nach aktuellem Kenntnisstand:**
|
||||
|
||||
* Schriftliche Klausur
|
||||
* Teils offene Fragen
|
||||
* Vermutlich digital
|
||||
* Kein Coding!
|
||||
* **Prüfungsrelevant:** Alles in den Folien/im Skript
|
||||
|
||||
<!--
|
||||
Details können sich noch ändern
|
||||
Keine Programmieraufgaben
|
||||
Verständnisfragen, keine Auswendiglernerei
|
||||
-->
|
||||
|
||||
@@ -25,7 +25,7 @@ h2 {
|
||||
|
||||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
|
||||
**223015c** · Modul "Technik 1" · 1. Semester
|
||||
**223015b** · Modul "Technik 1" · 1. Semester
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
@@ -40,7 +40,6 @@ Hochschule der Medien Stuttgart
|
||||
# Termin 1 – 19.12.2025
|
||||
## Grundlagen, Text & Audio
|
||||
|
||||
|
||||
---
|
||||
|
||||

|
||||
@@ -53,13 +52,12 @@ Hochschule der Medien Stuttgart
|
||||
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."
|
||||
|
||||
"Ich schaue in viele fragende Gesichte ..."
|
||||
|
||||
"Doch vertraut mir, am Ende der heutigen Veranstaltung werdet ihr mir genau sagen können was hier steht"
|
||||
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -86,7 +84,11 @@ Demonstration: Glühbirne AN/AUS = 1 Bit
|
||||
|
||||
<!--
|
||||
BIT = Binary Digit (Binärziffer) – 1948 von Claude Shannon geprägt
|
||||
|
||||
"Bit warum somit ein Neologismus, bis dato gab es das Wort in dieser Bedeutung überhaupt nicht"
|
||||
|
||||
Shannon war Mathematiker bei Bell Labs – begründete die Informationstheorie
|
||||
|
||||
Warum binär? Elektronische Schaltungen haben nur 2 Zustände: Strom/kein Strom
|
||||
Das ist physikalisch am stabilsten (weniger Fehler als 3 oder 10 Zustände)
|
||||
Alles Digitale basiert auf dieser simplen Idee: AN oder AUS
|
||||
@@ -97,24 +99,79 @@ Transistoren in modernen CPUs: Milliarden davon, schalten Milliarden Mal pro Sek
|
||||
|
||||
# Das Byte
|
||||
|
||||
**8 Bits = 1 Byte**
|
||||
<!--
|
||||
"Ein Bit allein macht nicht glücklich, die Welt ist nunmal nicht schwarz oder weiß"
|
||||
|
||||
"Und um noch weitere (nennen wir es Schattierungen, ganz literarisch) der Welt abbilden zu können, benötigen wir eine weiter Messgröße oder Einheit"
|
||||
|
||||
BYTE = Wortspiel aus "Bit" + "Bite" (Bissen) – ein "Bissen" Information
|
||||
|
||||
"Doch warum hat man nicht einfach »Bite« genommen?" Fangfrage -> Bit und Bite sind sich zu nahe ... Verwechslungsgefahr!
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Das Byte
|
||||
|
||||
**1 Byte = 8 Bits**
|
||||
|
||||
```
|
||||
0 1 0 0 1 1 0 1
|
||||
```
|
||||
|
||||
<!--
|
||||
|
||||
"Und das sieht dann so aus"
|
||||
|
||||
"Aber warum genau 8 Bits?" -> "Das versteht man leider erst so richtig wenn man sich das Ergebnis anschaut, wie viele Möglichkeiten hieraus entstehen"
|
||||
|
||||
"Menschen neigen dazu, exponentielles Wachstum zu unterschätzen"
|
||||
|
||||
Rätsel: "Wenn sich das Wachstum einer Seerose auf einem Teich jeden Tag verdoppelt · und nach *zehn Tagen* der ganze Teich bedeckt ist, wann ist er zur Hälfte zugewachsen?"
|
||||
|
||||
Frage: "Weiß jemand wieviele Zustände wir mit 8 Bit beschreiben können?"
|
||||
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Das Byte
|
||||
|
||||
**1 Byte = 8 Bits**
|
||||
|
||||
```
|
||||
0 1 0 0 1 1 0 1
|
||||
```
|
||||
|
||||
**Wie viele Kombinationen?**
|
||||
2⁸ = **256 Möglichkeiten** (0-255)
|
||||
|
||||
<!--
|
||||
BYTE = Wortspiel aus "Bit" + "Bite" (Bissen) – ein "Bissen" Information
|
||||
Warum genau 8 Bits?
|
||||
|
||||
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)
|
||||
Eselsbrücke: 1 Byte = 1 Buchstabe (in ASCII/UTF-8 für einfache Zeichen)
|
||||
|
||||
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)
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -122,9 +179,33 @@ Rechnung: 2×2×2×2×2×2×2×2 = 256 mögliche Kombinationen
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
|
||||
US-ASCII (1967) Code Chart
|
||||
|
||||
"Ich möchte, dass ihr das mit mir jetzt gemeinsam lesen lernt; stellt euch vor ihr seid ArchäologInnen."
|
||||
|
||||
"Wie würdet ihr vorgehen?"
|
||||
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
»256 Shades of Gray«
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
|
||||
»256 Shades of Gray«
|
||||
|
||||
|
||||
256 Graustufen: 0 = Schwarz, 255 = Weiß
|
||||
-->
|
||||
|
||||
@@ -132,10 +213,12 @@ Rechnung: 2×2×2×2×2×2×2×2 = 256 mögliche Kombinationen
|
||||
|
||||
# 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 Zeichen** (Buchstaben, Zahlen, Symbole)
|
||||
* **256 Helligkeit bzw. Luminanz** (0 = Schwarz/Dunkel, 255 = Weiß/Hell)
|
||||
* **256 Lautstärkestufen**
|
||||
* **Zahlen 0-255** (oder -128 bis +127)
|
||||
|
||||
* *Fällt Euch noch mehr ein?*
|
||||
|
||||
<!--
|
||||
256 = die "magische Zahl" bei 8 Bit
|
||||
@@ -149,7 +232,6 @@ 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: '' -->
|
||||
@@ -157,12 +239,28 @@ Das menschliche Auge kann etwa 10 Millionen Farben unterscheiden
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
Welche Farben für ein volles Spektrum bieten sich nach unserer gelernten Sparsamkeit hier am besten an?
|
||||
|
||||
1. CMYK bzw. in diesem Fall CMYW
|
||||
2. RGB
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
RGB = Additive Farbmischung (Bildschirme)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||

|
||||
|
||||
# Farben: RGB-Modell
|
||||
|
||||
**1 Pixel = 3 Bytes**
|
||||
@@ -176,6 +274,9 @@ RGB = Additive Farbmischung (Bildschirme)
|
||||
`00 00 00` = Schwarz | `FF FF FF` = Weiß
|
||||
|
||||
<!--
|
||||
"Weiß jemand oder möchte jemand raten, wofür das "s" bei "sRGB" steht?"
|
||||
|
||||
sRGB = Standard RGB
|
||||
CMYK = Subtraktive Farbmischung (Druck)
|
||||
Hex-Notation: FF = 255 in Dezimal
|
||||
CSS-Farben nutzen Hex: #FF0000 = Rot
|
||||
@@ -226,14 +327,13 @@ Keine Umlaute, kein ñ, kein é
|
||||
|
||||
# Unicode: Ein Standard für alle
|
||||
|
||||
**Unicode (1991):**
|
||||
**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)
|
||||
* 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
|
||||
@@ -296,7 +396,13 @@ Jede Hex-Ziffer = 4 Bits
|
||||
**Jede Hex-Ziffer = 4 Bits (ein "Nibble")**
|
||||
0-9, A-F (10=A, 11=B, ..., 15=F)
|
||||
|
||||
**ASCII Character Chart:**
|
||||
[https://www.eso.org/~ndelmott/ascii.html](https://www.eso.org/~ndelmott/ascii.html)
|
||||
|
||||
<!--
|
||||
|
||||
"Gerne vorab auf den Link gehen"
|
||||
|
||||
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)
|
||||
@@ -312,6 +418,39 @@ Umrechnung üben:
|
||||
- 0xFF = 15×16 + 15 = 255 (Maximum für 1 Byte)
|
||||
|
||||
Hex-Editor = Standard-Tool für Dateianalyse und Reverse Engineering
|
||||
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #000 -->
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
|
||||
"Zurück zu Frage am Anfang: Was steht hier nun?"
|
||||
|
||||
"Versucht es kurz selbst zu entschlüsseln"
|
||||
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #000 -->
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
Hex-Editor-Screenshot mit PNG-Datei
|
||||
Erste Bytes: 89 50 4E 47 = PNG-Signatur
|
||||
IHDR = Image Header (Breite, Höhe, Farbtiefe)
|
||||
Zeigen, wie man Magic Number liest
|
||||
Tool: HxD (Windows), Hex Fiend (Mac), xxd (Linux)
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -327,7 +466,7 @@ Hex-Editor = Standard-Tool für Dateianalyse und Reverse Engineering
|
||||
| PDF | `25 50 44 46` | `%PDF` |
|
||||
| ZIP/DOCX/ODT | `50 4B 03 04` | `PK` |
|
||||
|
||||
**Achtung:** TXT, HTML, CSS haben **keine** Magic Number!
|
||||
**Hinweis:** TXT, HTML, CSS haben **keine** Magic Number!
|
||||
|
||||
<!--
|
||||
Magic Number = Signatur/Fingerabdruck am Dateianfang
|
||||
@@ -349,22 +488,6 @@ Windows vertraut der Endung, aber Tools wie "file" (Linux) lesen Magic Number
|
||||
|
||||
---
|
||||
|
||||
<!-- _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):**
|
||||
@@ -444,7 +567,7 @@ Visueller Kontrast: Analog vs. Digital
|
||||
|
||||
**1990:** Festplatten hatten 100-500 MB!
|
||||
|
||||
<!--
|
||||
<!--
|
||||
CD-Qualität = Standard seit 1982
|
||||
Ein Album = ganze Festplatte
|
||||
Download bei 56k-Modem = Tage!
|
||||
@@ -456,6 +579,97 @@ Streaming? Unmöglich.
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
|
||||
"Wenn CDs eine Sample Rate von 44kHz haben, was fällt dann hier auf?"
|
||||
|
||||
Fangfrage: "Wie hoch ist die Sample Rate von Vinyls?" -> *Vinyl has no sample rate. It's analog!*
|
||||
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Was ist Sample Rate?
|
||||
**Analog → Digital ≙ Kontinuierlich → Diskret**
|
||||
```
|
||||
Analog (Vinyl): Digital (CD):
|
||||
~~~~~~~~~~~~~~~ • • • • • • • •
|
||||
Kontinuierliche 44.100 Messpunkte
|
||||
Wellenform pro Sekunde
|
||||
```
|
||||
**Nyquist-Theorem:**
|
||||
|
||||
> Um eine Frequenz zu rekonstruieren, braucht man mindestens **2× so viele Samples**.
|
||||
44.100 Hz ÷ 2 = **22.050 Hz** max. darstellbare Frequenz
|
||||
(Mensch hört: ~20 Hz bis ~20.000 Hz → passt!)
|
||||
|
||||
<!--
|
||||
SAMPLE RATE = Wie oft "fotografieren" wir die Schallwelle?
|
||||
Stellt euch vor: Schallwelle = fahrendes Auto
|
||||
- Analog: Videokamera läuft durchgehend
|
||||
- Digital: Fotokamera macht 44.100 Fotos pro Sekunde
|
||||
|
||||
VINYL hat KEINE Sample Rate:
|
||||
- Rille ist physische Kopie der Welle
|
||||
- "Unendliche Auflösung" in der Theorie
|
||||
- ABER: Rauschen, Kratzer, Nadelmasse = eigene Limits
|
||||
- Praktisch: ~20 Hz bis ~20 kHz, 60-70 dB Dynamik
|
||||
|
||||
WARUM genau 44.100 Hz?
|
||||
- Nyquist: 2× höchste hörbare Frequenz nötig
|
||||
- 20.000 Hz × 2 = 40.000 Hz Minimum
|
||||
- 44.100 = etwas Puffer + passte zu Video-Equipment der 80er
|
||||
|
||||
DAS SPEKTROGRAMM zeigt es:
|
||||
- Alles über ~22 kHz ist abgeschnitten
|
||||
- Das ist kein Bug, das ist das Design!
|
||||
- Vinyl hätte dort noch Obertöne (die wir eh nicht hören)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Sample Rate vs. Bit Depth
|
||||
|
||||
**Zwei Dimensionen der Digitalisierung:**
|
||||
|
||||
| Dimension | Was bedeutet es? | CD-Qualität |
|
||||
|-----------|------------------|-------------|
|
||||
| **Sample Rate** | Messungen pro Sekunde (horizontal) | 44.100 Hz |
|
||||
| **Bit Depth** | Genauigkeit pro Messung (vertikal) | 16 Bit |
|
||||
|
||||
**16 Bit = 2¹⁶ = 65.536 Lautstärkestufen**
|
||||
(von absoluter Stille bis maximaler Lautstärke)
|
||||
|
||||
<!--
|
||||
Analogie: Digitalisierung = Raster über Schallwelle legen
|
||||
|
||||
HORIZONTAL (Sample Rate):
|
||||
- Wie oft messen wir pro Sekunde?
|
||||
- 44.100 Hz = 44.100 Messpunkte pro Sekunde
|
||||
- Bestimmt, welche FREQUENZEN wir erfassen können
|
||||
- Nyquist-Theorem: Sample Rate ≥ 2× höchste Frequenz
|
||||
- 44.100 Hz → max. ~22.050 Hz (Mensch hört bis ~20.000 Hz)
|
||||
|
||||
VERTIKAL (Bit Depth):
|
||||
- Wie genau messen wir jeden Punkt?
|
||||
- 16 Bit = 65.536 mögliche Werte (-32.768 bis +32.767)
|
||||
- Bestimmt den DYNAMIKUMFANG (leise bis laut)
|
||||
- 16 Bit ≈ 96 dB Dynamik (Flüstern bis Rockkonzert)
|
||||
- Mehr Bits = feinere Abstufungen = weniger Quantisierungsrauschen
|
||||
|
||||
KOMPRESSION nutzt beide Achsen:
|
||||
- Sample Rate reduzieren = weniger Punkte horizontal (spart Daten, verliert hohe Frequenzen)
|
||||
- Bit Depth reduzieren = gröbere Stufen vertikal (spart Daten, mehr Rauschen)
|
||||
- MP3: Wirft unhörbare Frequenzen weg + quantisiert grober wo es nicht auffällt
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
@@ -514,14 +728,9 @@ Schlecht für chaotische Daten (Fotos, Audio)
|
||||
**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**
|
||||
* Helligkeit besser als Farbe wahrgenommen
|
||||
* Große Flächen besser als feine Details
|
||||
* **→ Psychovisuell**
|
||||
|
||||
<!--
|
||||
Auditory Masking: Lauter 1000 Hz-Ton → leise 950 Hz unhörbar
|
||||
@@ -531,16 +740,38 @@ Kompression = Modell der menschlichen Wahrnehmung
|
||||
|
||||
---
|
||||
|
||||

|
||||
# 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
|
||||
- **→ Psychovisuell**
|
||||
|
||||
**MP3:** Schwächen des Ohrs
|
||||
* Mittlere Frequenzen besser als hohe/tiefe
|
||||
* Laute Töne "maskieren" leise Töne
|
||||
* **→ Psychoakustik**
|
||||
|
||||
<!--
|
||||
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
|
||||
* 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
|
||||
@@ -600,7 +831,7 @@ Brandenburg hörte den Song über 10.000 Mal
|
||||
- Suzanne Vegas Stimme ist "schwierig"
|
||||
- Klare, hohe Frequenzen → Stresstest
|
||||
|
||||
*"If I could code Suzanne Vega's voice well, I could code anything."*
|
||||
> If I could code Suzanne Vega's voice well, I could code anything.
|
||||
— Karlheinz Brandenburg
|
||||
|
||||
<!--
|
||||
@@ -614,17 +845,19 @@ Perfektionismus: Jeder Hörtest musste bestehen
|
||||
|
||||
# Wie funktioniert MP3?
|
||||
|
||||
**1. Frequenz-Analyse (FFT)**
|
||||
Audio → Frequenzspektrum
|
||||
Ein Zusammenspiel aus vielen Faktoren:
|
||||
|
||||
**2. Psychoakustisches Modell**
|
||||
Welche Töne hört Mensch nicht?
|
||||
* **1. Frequenz-Analyse (FFT)**
|
||||
Audio → Frequenzspektrum
|
||||
|
||||
**3. Quantisierung**
|
||||
Unwichtige Frequenzen reduzieren
|
||||
* **2. Psychoakustisches Modell**
|
||||
Welche Töne hört Mensch nicht?
|
||||
|
||||
**4. Huffman-Coding**
|
||||
Lossless-Kompression der Restdaten
|
||||
* **3. Quantisierung**
|
||||
Unwichtige Frequenzen reduzieren
|
||||
|
||||
* **4. Huffman-Coding**
|
||||
Lossless-Kompression der Restdaten
|
||||
|
||||
<!--
|
||||
MP3-Kompression in 4 Schritten (vereinfacht):
|
||||
@@ -641,7 +874,7 @@ MP3-Kompression in 4 Schritten (vereinfacht):
|
||||
3. Quantisierung (hier passiert der Datenverlust!)
|
||||
- Unwichtige Frequenzen werden "grob" gespeichert
|
||||
- Wichtige Frequenzen bleiben genau
|
||||
- Wie JPEG: Details entfernen, wo es nicht auffällt
|
||||
- Wie JPEG: Details entfernen, wo es nicht auffällt (Kontrast/Helligkeit bleibt)
|
||||
|
||||
4. Huffman-Coding (verlustfrei)
|
||||
- Häufige Muster = kurze Codes
|
||||
@@ -794,12 +1027,13 @@ Vinyl-Revival: 2020er Gegenbewegung
|
||||
4. Höre Unterschiede (Kopfhörer!)
|
||||
5. Vergleiche Dateigrößen
|
||||
|
||||
**Spektrogramm:** Track-Menü → Spektrogramm
|
||||
**Spektrogramm:** Klick auf Track-Name → Spektrogramm
|
||||
[https://manual.audacityteam.org/man/spectrogram_view.html](https://manual.audacityteam.org/man/spectrogram_view.html)
|
||||
|
||||
<!--
|
||||
Audacity: FOSS Audio-Editor (audacityteam.org)
|
||||
Export: Datei → Exportieren → MP3 → Bitrate wählen
|
||||
Spektrogramm-Ansicht: Track-Name klicken → "Spektrogramm"
|
||||
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
|
||||
-->
|
||||
|
||||
@@ -19,13 +19,14 @@ h2 {
|
||||
|
||||
<!-- _class: invert -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #000 -->
|
||||
|
||||

|
||||
|
||||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
|
||||
**223015c** · Modul "Technik 1" · 1. Semester
|
||||
**223015b** · Modul "Technik 1" · 1. Semester
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
@@ -67,7 +68,7 @@ Instagram-Effekt
|
||||
|
||||
**Für EIN Foto!**
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Zoom auf Pixel-Ebene zeigen
|
||||
Jedes Pixel = RGB-Tripel (3 Bytes)
|
||||
6 MB × 10.000 Fotos = 62 GB
|
||||
@@ -76,6 +77,74 @@ Smartphone-Speicher wäre schnell voll ohne Kompression
|
||||
|
||||
---
|
||||
|
||||
# Rastergrafiken (Bitmaps)
|
||||
|
||||
**Pixelraster:** Jeder Bildpunkt hat Koordinate + Farbwert
|
||||
|
||||
**Eigenschaften:**
|
||||
- Je größer das Bild → größere Datei
|
||||
- **Verkleinern:** Meist ohne Qualitätsverlust
|
||||
- **Vergrößern:** Wird unscharf/pixelig!
|
||||
|
||||
**Formate:** JPEG, PNG, GIF, BMP, TIFF, WebP
|
||||
|
||||
**Verwendung:** Fotos, Screenshots, komplexe Bilder
|
||||
|
||||
<!--
|
||||
Bitmap = Bit-mapped graphics
|
||||
Digitalkameras erzeugen immer Rastergrafiken
|
||||
Kompression nötig wegen Dateigrößen (PNG, JPEG, GIF)
|
||||
Skalierungsproblem: Interpolation erzeugt Unschärfe
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Vektorgrafiken
|
||||
|
||||
**Mathematische Beschreibung statt Pixel**
|
||||
|
||||
**Kreis speichern:**
|
||||
- Rastergrafik: Tausende Pixel
|
||||
- Vektorgrafik: Mittelpunkt + Radius (2 Werte!)
|
||||
|
||||
**Gespeichert werden:**
|
||||
- Form (Kreis, Linie, Pfad...)
|
||||
- Position, Farbe, Strichstärke, Füllung
|
||||
|
||||
**Vorteil:** Beliebig skalierbar ohne Qualitätsverlust!
|
||||
|
||||
**Formate:** SVG, PDF, AI, EPS
|
||||
|
||||
<!--
|
||||
Vektorgrafik = geometrische Primitive + Attribute
|
||||
SVG = Scalable Vector Graphics (Web-Standard)
|
||||
AI = Adobe Illustrator
|
||||
Ideal für Logos, Icons, Infografiken
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Raster vs. Vektor
|
||||
|
||||
| | Rastergrafik | Vektorgrafik |
|
||||
|---|---|---|
|
||||
| **Basis** | Pixelraster | Mathematische Objekte |
|
||||
| **Skalierung** | Qualitätsverlust | Verlustfrei |
|
||||
| **Dateigröße** | Abhängig von Auflösung | Abhängig von Komplexität |
|
||||
| **Gut für** | Fotos | Logos, Icons, Text |
|
||||
| **Formate** | JPEG, PNG, GIF | SVG, PDF, AI |
|
||||
|
||||
**Rasterung:** Vektorgrafik → Rastergrafik (für Bildschirm/Druck)
|
||||
|
||||
<!--
|
||||
Bildschirme sind Rastergeräte (Framebuffer)
|
||||
Jede Vektorgrafik muss gerastert werden zur Anzeige
|
||||
Browser rastert SVG in Echtzeit
|
||||
Firmenlogos: Immer als Vektor anlegen!
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Lossless: PNG
|
||||
|
||||
**PNG = Portable Network Graphics (1996)**
|
||||
@@ -336,24 +405,21 @@ Studis sollen selbst "Sweet Spot" finden
|
||||
|
||||
---
|
||||
|
||||
# Aufgabe bis nächste Woche
|
||||
# Fleißaufgabe bis nächste Woche
|
||||
|
||||
**Nimm ein Foto (eigenes oder CC)**
|
||||
|
||||
1. Exportiere: PNG, JPEG Q90, JPEG Q50
|
||||
2. Vergleiche Größen & Qualität
|
||||
3. Poste im Forum: Screenshot + Reflexion
|
||||
|
||||
**Fragen:**
|
||||
- Welche Quality ist für dich "akzeptabel"?
|
||||
- Wo siehst du zuerst Artefakte?
|
||||
3. Welche Quality ist für dich "akzeptabel"?
|
||||
4. Wo siehst du zuerst Artefakte?
|
||||
|
||||
**Bonus:** Teste WebP oder AVIF
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Selbstständiges Experimentieren
|
||||
Keine Abgabe, nur zum Ausprobieren
|
||||
Subjektive Wahrnehmung (jeder anders)
|
||||
Forum: Austausch über Ergebnisse
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -729,24 +795,20 @@ Encoding-Zeit: H.265 deutlich langsamer als H.264
|
||||
|
||||
---
|
||||
|
||||
# Aufgabe bis nächste Woche
|
||||
# Fleißaufgabe bis nächste Woche
|
||||
|
||||
**Nimm kurzes Video (eigenes oder CC, max. 1 Min)**
|
||||
|
||||
1. Analysiere: Container, Codecs, Bitrate
|
||||
2. Konvertiere: H.264 + H.265 (gleiche Qualität)
|
||||
3. Poste im Forum:
|
||||
- Dateigrößen
|
||||
- Encoding-Zeiten
|
||||
- Visueller Unterschied?
|
||||
3. Vergleiche: Dateigrößen, Encoding-Zeiten, visueller Unterschied?
|
||||
|
||||
**Bonus:** AV1-Encoding (Warnung: SEHR langsam!)
|
||||
|
||||
<!--
|
||||
MediaInfo oder ffprobe für Analyse
|
||||
HandBrake für Konvertierung (einfacher als CLI)
|
||||
Encoding-Zeit: H.265 ~5x langsamer, AV1 ~50x langsamer
|
||||
Qualität: Bei gleicher Bitrate H.265 > H.264
|
||||
HandBrake für Konvertierung
|
||||
Keine Abgabe, nur zum Ausprobieren
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -755,7 +817,7 @@ Qualität: Bei gleicher Bitrate H.265 > H.264
|
||||
|
||||
# Fragen & Diskussion
|
||||
|
||||
**Kontakt:** czechowski@hdm-stuttgart.de
|
||||
**Kontakt:** mail@librete.ch
|
||||
**Folien:** Online verfügbar unter https://hdm.librete.ch
|
||||
|
||||
---
|
||||
|
||||
@@ -68,11 +68,154 @@ Mechanisch vs. Elektronisch
|
||||
- Teuer (~80-150€/TB)
|
||||
- Write-Zyklen begrenzt
|
||||
|
||||
<!--
|
||||
Wiederholung aus vorheriger Iteration (falls schon behandelt)
|
||||
Oder erste Einführung, falls Woche 5 Startpunkt für Speicher
|
||||
HDD: Platter, Lesekopf, 5.400-15.000 RPM
|
||||
SSD: NAND-Flash (SLC/MLC/TLC/QLC)
|
||||
<!--
|
||||
HDD: Magnetscheiben (Platter) rotieren mit 5.400-7.200 RPM
|
||||
Lesekopf schwebt nanometerdicht über Oberfläche
|
||||
"Head Crash": Berührung = Datenverlust (daher Stoßempfindlichkeit)
|
||||
Enterprise: 10.000-15.000 RPM (Server)
|
||||
|
||||
SSD: NAND-Flash-Speicherzellen
|
||||
Typen: SLC (1 Bit), MLC (2 Bit), TLC (3 Bit), QLC (4 Bit)
|
||||
SLC = langlebig, teuer (Enterprise)
|
||||
QLC = günstig, weniger Schreibzyklen (Consumer)
|
||||
Write Amplification: Daten werden mehrfach intern geschrieben
|
||||
TRIM: Befehl, der SSD sagt, welche Blöcke frei sind
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Speicherkapazität: KB vs. KiB
|
||||
|
||||
**Das Problem:** Hersteller vs. Betriebssysteme
|
||||
|
||||
| Dezimal (SI) | Binär (IEC) |
|
||||
|--------------|-------------|
|
||||
| 1 KB = 1.000 Bytes | 1 KiB = 1.024 Bytes |
|
||||
| 1 MB = 1.000 KB | 1 MiB = 1.024 KiB |
|
||||
| 1 GB = 1.000 MB | 1 GiB = 1.024 MiB |
|
||||
| 1 TB = 1.000 GB | 1 TiB = 1.024 GiB |
|
||||
|
||||
**1 TB Festplatte → Windows zeigt ~931 GB!**
|
||||
|
||||
<!--
|
||||
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
|
||||
ISO/IEC 80000-13: Definiert KiB, MiB, GiB, TiB (2008)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# HDD: Aufbau & Struktur
|
||||
|
||||
**Komponenten:**
|
||||
- **Platter:** Magnetisch beschichtete Scheiben
|
||||
- **Spindel:** Dreht mit 5.400-7.200 RPM
|
||||
- **Schreib-Lese-Kopf:** Schwebt nm-dünn über Platter
|
||||
- **Aktuator:** Bewegt Kopf zur richtigen Spur
|
||||
|
||||
**Logische Struktur:**
|
||||
- **Spuren:** Konzentrische Kreise auf Platter
|
||||
- **Sektoren:** Unterteilung der Spuren (512 Bytes)
|
||||
- **Zylinder:** Gleiche Spuren aller Platter
|
||||
|
||||
<!--
|
||||
Aufbau seit 1956 (IBM) grundsätzlich gleich
|
||||
Platter: Aluminium oder Glas mit Magnetschicht
|
||||
Spindelgeschwindigkeit: Desktop 7.200, Laptop 5.400, Server 15.000 RPM
|
||||
Head Crash: Schreib-Lese-Kopf berührt Platter → Kratzer → Datenverlust
|
||||
Sektor: Kleinste adressierbare Einheit
|
||||
LBA (Logical Block Addressing): Abstraktion der physischen Struktur
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# NVMe: Die SSD-Revolution
|
||||
|
||||
**NVMe = Non-Volatile Memory Express (2011)**
|
||||
|
||||
**Unterschied zu SATA-SSD:**
|
||||
- SATA: Max. ~550 MB/s (AHCI-Protokoll)
|
||||
- NVMe: Bis zu 7.000+ MB/s (PCIe direkt)
|
||||
|
||||
**Formfaktoren:**
|
||||
- M.2 (Steckplatz auf Mainboard)
|
||||
- U.2 (Serverbereich)
|
||||
- PCIe-Karte (ältere Systeme)
|
||||
|
||||
<!--
|
||||
SATA = Serial ATA, Protokoll von 2003 (für HDDs optimiert)
|
||||
AHCI = Advanced Host Controller Interface
|
||||
NVMe nutzt PCIe-Lanes direkt → weniger Overhead
|
||||
M.2-Slot kann SATA oder NVMe sein! (B-Key, M-Key, B+M-Key)
|
||||
Praxistipp: Nicht jeder M.2-Slot unterstützt NVMe
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# SD-Karten (Speicherkarten)
|
||||
|
||||
**SD = Secure Digital (2001)**
|
||||
|
||||
**Varianten:**
|
||||
- SD: bis 2 GB
|
||||
- SDHC: bis 32 GB
|
||||
- SDXC: bis 2 TB
|
||||
- microSD: Kleinere Bauform
|
||||
|
||||
**Geschwindigkeitsklassen:**
|
||||
Class 10, UHS-I, UHS-II, V30, V90...
|
||||
|
||||
**Einsatz:** Kameras, Smartphones, Raspberry Pi
|
||||
|
||||
<!--
|
||||
Entwickelt von SanDisk, Toshiba, Panasonic
|
||||
Spezifikation proprietär (nicht ISO-genormt!)
|
||||
Fälschungen: Gefälschte Kapazität häufig → Markenware kaufen!
|
||||
Flash-Speicher: Gleiche Vor-/Nachteile wie SSD
|
||||
V90: 90 MB/s Mindest-Schreibrate (für 8K Video)
|
||||
microSD in Smartphones, Drohnen, Dashcams
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
Rosetta Disk der Long Now Foundation
|
||||
Mikrogeätzte Nickelscheibe mit 1.500+ Sprachen
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Das Rosetta Project
|
||||
|
||||
**Long Now Foundation (2002)**
|
||||
|
||||
**Ziel:** Dokumentation aller menschlichen Sprachen für die Nachwelt
|
||||
|
||||
**Die Rosetta Disk:**
|
||||
- 3 Zoll Nickelscheibe
|
||||
- 13.000 Seiten mikrogeätzt
|
||||
- 1.500+ Sprachen dokumentiert
|
||||
- Lesbar mit 1000× Mikroskop
|
||||
- Haltbarkeit: 2.000+ Jahre
|
||||
|
||||
**Lektion für uns:**
|
||||
Digitale Formate veralten – physische Archivierung bleibt relevant
|
||||
|
||||
<!--
|
||||
Long Now Foundation: Denken in 10.000-Jahres-Zeiträumen
|
||||
Benannt nach dem Stein von Rosette (Schlüssel zu Hieroglyphen)
|
||||
Problem: CD/DVD halten 10-25 Jahre, Festplatten 5-10 Jahre
|
||||
Rosetta Disk: Keine Stromversorgung, kein Decoder nötig
|
||||
Nur optische Vergrößerung – Technologie die es immer geben wird
|
||||
Parallel: M-DISC, LTO-Tapes für digitale Langzeitarchivierung
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -164,11 +307,20 @@ Sicheres Löschen: DBAN, shred, eraser
|
||||
|
||||
**Nachteil:** Keine Rechte, kein Journaling
|
||||
|
||||
<!--
|
||||
FAT = Tabelle am Anfang der Partition
|
||||
Verkettete Liste von Clustern
|
||||
Fragmentierung: Cluster verstreut → langsam
|
||||
USB-Sticks heute meist FAT32 (Kompatibilität!)
|
||||
<!--
|
||||
FAT = File Allocation Table (Tabelle am Partitionsanfang)
|
||||
Wie ein Inhaltsverzeichnis: "Datei X ist in Clustern 5, 8, 12"
|
||||
Fragmentierung: Cluster verstreut → langsamer Zugriff
|
||||
Defragmentierung: Cluster zusammenrücken (bei HDD sinnvoll, bei SSD nicht!)
|
||||
|
||||
FAT32-Limit: 4 GB = 32-Bit-Zahl für Dateigröße
|
||||
2³² Bytes = 4.294.967.296 = 4 GB (daher die Grenze)
|
||||
exFAT: 64-Bit → 16 Exabyte theoretisch
|
||||
|
||||
Warum FAT32 noch existiert:
|
||||
- Kameras, Dashcams, Game-Controller
|
||||
- BIOS/UEFI-Bootpartitionen
|
||||
- Maximale Kompatibilität (alle OS lesen es)
|
||||
exFAT: Microsoft-Patent, seit 2019 in Linux-Kernel
|
||||
-->
|
||||
|
||||
@@ -329,12 +481,28 @@ Wiederherstellung: Full = 1 Schritt, Inkr. = 7, Diff. = 2
|
||||
**Beispiel:**
|
||||
Laptop + externe Festplatte + Cloud
|
||||
|
||||
<!--
|
||||
3-2-1 ist MINIMUM, nicht Maximum!
|
||||
Medientypen: SSD, HDD, Optical, Cloud, Tape
|
||||
Offsite: Schutz vor lokalem Desaster
|
||||
Versionierung: Auch alte Versionen aufbewahren
|
||||
Automatisierung: Sonst vergisst man's
|
||||
<!--
|
||||
3-2-1-Regel Herkunft: US-Photograph Peter Krogh (2005)
|
||||
Buch "The DAM Book" (Digital Asset Management)
|
||||
|
||||
Warum 3 Kopien?
|
||||
- Original kann kaputtgehen
|
||||
- Backup 1 kann auch kaputtgehen
|
||||
- Backup 2 = Sicherheitspuffer
|
||||
|
||||
Warum 2 Medientypen?
|
||||
- Gleiche Medien haben gleiche Schwachstellen
|
||||
- SSD + HDD: Unterschiedliche Ausfallmuster
|
||||
- Cloud + Lokal: Unterschiedliche Risiken
|
||||
|
||||
Warum 1 Offsite?
|
||||
- Brand/Wasserschaden zerstört alles vor Ort
|
||||
- Ransomware verschlüsselt angeschlossene Laufwerke
|
||||
- Offsite = geografisch getrennt (oder Cloud)
|
||||
|
||||
Erweiterung: 3-2-1-1-0
|
||||
- +1 Offline/Air-Gapped (Ransomware-Schutz)
|
||||
- +0 Verified Backups (regelmäßig testen!)
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -414,7 +582,7 @@ Magnetband-Technologie
|
||||
**Air-Gap-Sicherheit:**
|
||||
Offline-Band kann nicht von Ransomware verschlüsselt werden
|
||||
|
||||
<!--
|
||||
<!--
|
||||
LTO = Offener Standard seit 1998
|
||||
LTO-9: 400 MB/s, 1 Million Durchläufe
|
||||
AWS Snowball nutzt intern Tapes
|
||||
@@ -424,6 +592,53 @@ Cold Storage: Daten, die selten gebraucht werden
|
||||
|
||||
---
|
||||
|
||||
# Optische Medien: CD, DVD, Blu-ray
|
||||
|
||||
**Laser liest/schreibt Daten:**
|
||||
|
||||
| Medium | Jahr | Kapazität | Wellenlänge |
|
||||
|--------|------|-----------|-------------|
|
||||
| **CD** | 1982 | 700 MB | 780 nm (Infrarot) |
|
||||
| **DVD** | 1996 | 4,7–8,5 GB | 650 nm (Rot) |
|
||||
| **Blu-ray** | 2006 | 25–100 GB | 405 nm (Blau) |
|
||||
|
||||
**Varianten:** ROM (nur lesen), R (einmal brennen), RW (wiederbeschreibbar)
|
||||
|
||||
<!--
|
||||
CD = Compact Disc (ursprünglich für Audio)
|
||||
DVD = Digital Versatile Disc (Video, Daten)
|
||||
Blu-ray: Kürzere Wellenlänge → höhere Datendichte
|
||||
Pits & Lands: Vertiefungen in der Oberfläche kodieren Bits
|
||||
CD-ROM: ~150 KB/s (1×), DVD: ~1,35 MB/s (1×), BD: ~4,5 MB/s (1×)
|
||||
Problem: Kratzer, Lichtempfindlichkeit, Alterung der Farbstoffe
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Optische Medien: Heute noch relevant?
|
||||
|
||||
**Vorteile:**
|
||||
- Günstig (Rohlinge ~0,20–2€)
|
||||
- Lange Haltbarkeit (bei richtiger Lagerung)
|
||||
- Nicht anfällig für Magnetfelder
|
||||
|
||||
**Nachteile:**
|
||||
- Langsam im Vergleich zu SSD/HDD
|
||||
- Begrenzte Kapazität
|
||||
- Viele Laptops ohne Laufwerk
|
||||
|
||||
**Einsatz heute:**
|
||||
Musik-CDs, Film-DVDs/Blu-rays, Software-Distribution, Archive
|
||||
|
||||
<!--
|
||||
Streaming hat DVDs/Blu-rays verdrängt (aber nicht ersetzt)
|
||||
Filme: Blu-ray oft bessere Qualität als Streaming (Bitrate!)
|
||||
Spiele-Discs: Oft nur "Installer", Rest wird heruntergeladen
|
||||
Archive: M-DISC für Langzeitarchivierung (nächste Folie)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
@@ -479,7 +694,7 @@ Futuristische Darstellung
|
||||
Microsoft + Twist Bioscience
|
||||
Netflix "Biohackers"-Episode (2021)
|
||||
|
||||
<!--
|
||||
<!--
|
||||
DNA = A, T, G, C (4 Basen)
|
||||
Kodierung: Binär (00=A, 01=T, 10=G, 11=C)
|
||||
Harvard (2017): Wikipedia (11 GB) in DNA
|
||||
@@ -489,6 +704,67 @@ Anwendung: Langzeitarchivierung (nicht Live-Daten)
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
NAS-Gerät (z.B. Synology)
|
||||
Heimserver-Setup
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Network Attached Storage (NAS)
|
||||
|
||||
**NAS = Festplatten im Netzwerk**
|
||||
|
||||
**Vorteile:**
|
||||
- Zentraler Speicher für alle Geräte
|
||||
- RAID-Optionen (Redundanz)
|
||||
- Remote-Zugriff möglich
|
||||
- Eigene Cloud
|
||||
|
||||
**Anbieter:** Synology, QNAP, TrueNAS
|
||||
|
||||
**Protokolle:** SMB/CIFS (Windows), NFS (Linux), AFP (Mac legacy)
|
||||
|
||||
<!--
|
||||
RAID 1: Spiegelung (2 Platten = 1× Kapazität, aber sicher)
|
||||
RAID 5: Striping + Parity (3+ Platten, 1 kann ausfallen)
|
||||
Synology DSM: Einfache Web-Oberfläche
|
||||
NAS ≠ Backup! (Ransomware kann NAS verschlüsseln!)
|
||||
3-2-1-Regel: NAS + externe HDD + Cloud
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Cloud-Speicher: Pro & Contra
|
||||
|
||||
**Vorteile:**
|
||||
✓ Überall verfügbar
|
||||
✓ Kein Hardware-Management
|
||||
✓ Automatische Backups
|
||||
✓ Skalierbar
|
||||
|
||||
**Nachteile:**
|
||||
✗ Abhängigkeit vom Anbieter
|
||||
✗ Datenschutz-Bedenken (DSGVO!)
|
||||
✗ Laufende Kosten
|
||||
✗ Internet-Abhängigkeit
|
||||
|
||||
**Anbieter:** iCloud, OneDrive, Google Drive, Dropbox, Nextcloud
|
||||
|
||||
<!--
|
||||
Nextcloud: Self-Hosted (Datenschutz!)
|
||||
AWS S3 Glacier: Archivierung ~$1/TB/Monat
|
||||
DSGVO: US-Anbieter problematisch (Privacy Shield gekippt)
|
||||
Zero-Knowledge: Cryptomator, Boxcryptor (Client-Verschlüsselung)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Hands-On: S.M.A.R.T. & Backup
|
||||
|
||||
**Aufgabe 1 (20 Min):**
|
||||
@@ -512,20 +788,20 @@ Backup-Test: Ungetestete Backups sind wertlos!
|
||||
|
||||
---
|
||||
|
||||
# Aufgabe bis nächste Woche
|
||||
# Fleißaufgabe bis nächste Woche
|
||||
|
||||
**Analysiere dein System:**
|
||||
|
||||
1. Welches Dateisystem nutzt deine Hauptpartition?
|
||||
2. Hast du ein Backup? Welche Art? Wo?
|
||||
3. Poste im Forum: S.M.A.R.T.-Screenshot + Backup-Strategie
|
||||
3. Lies deine S.M.A.R.T.-Daten aus (CrystalDiskInfo / smartctl)
|
||||
|
||||
**Bonus:** Richte automatisches Backup ein
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Selbstreflexion: 60-70% haben KEIN Backup!
|
||||
Forum: Peer-Lernen, gegenseitige Motivation
|
||||
Bonus: Wer's macht, hat echten Nutzen
|
||||
Keine Abgabe, nur zum Ausprobieren
|
||||
Nächste Woche kurz besprechen
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -561,7 +837,7 @@ API (nächste Woche!)
|
||||
|
||||
**Heute:** Hardware-Fokus
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Interface = Berührungspunkt zwischen Systemen
|
||||
Definiert: Form, Pins, elektrische Signale, Protokoll
|
||||
Ohne Standards: Jedes Gerät braucht eigenes Kabel
|
||||
@@ -569,6 +845,68 @@ Ohne Standards: Jedes Gerät braucht eigenes Kabel
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Interne Schnittstellen
|
||||
## PCIe, SATA & M.2
|
||||
|
||||
---
|
||||
|
||||
# PCIe: Der Daten-Highway
|
||||
|
||||
**PCI Express (2003):**
|
||||
|
||||
- Lanes: x1, x4, x8, x16
|
||||
- Gen 3: 1 GB/s pro Lane
|
||||
- Gen 4: 2 GB/s pro Lane
|
||||
- Gen 5: 4 GB/s pro Lane
|
||||
|
||||
**Nutzung:**
|
||||
- Grafikkarte (x16)
|
||||
- NVMe-SSD (x4)
|
||||
- Netzwerkkarte, Sound (x1)
|
||||
|
||||
<!--
|
||||
PCIe = Point-to-Point (vs. PCI shared bus)
|
||||
Lane = bidirektionale Verbindung
|
||||
x16 Gen 4 = 32 GB/s (theoretisch)
|
||||
GPU nutzt fast immer x16 Slot
|
||||
NVMe nutzt 4 Lanes → daher ~7 GB/s max bei Gen 4
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# SATA: Der Standard für Speicher
|
||||
|
||||
**Serial ATA (2003):**
|
||||
|
||||
- SATA I: 1,5 Gbps (~150 MB/s)
|
||||
- SATA II: 3 Gbps (~300 MB/s)
|
||||
- SATA III: 6 Gbps (~550 MB/s)
|
||||
|
||||
**Vorteile:**
|
||||
- Günstig, bewährt
|
||||
- Hot-Swap möglich
|
||||
- Kabel bis 1m
|
||||
|
||||
**Nachteil:** Bottleneck für moderne SSDs
|
||||
|
||||
<!--
|
||||
SATA-Kabel: Dünn, 7-Pin Daten + 15-Pin Strom
|
||||
IDE/PATA: Breite Flachbandkabel (Vorgänger)
|
||||
SATA III = Maximum für HDD (100-200 MB/s)
|
||||
SSD erreicht SATA-Limit leicht → daher NVMe
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Externe Schnittstellen
|
||||
## USB, HDMI, DisplayPort & Co.
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
@@ -657,12 +995,25 @@ Ein USB-C-Kabel kann sein:
|
||||
- Thunderbolt 3/4 (40 Gbps)
|
||||
- Oder nur Power Delivery (Laden, keine Daten!)
|
||||
|
||||
<!--
|
||||
USB-C = "Auto" (sagt nichts über PS, Hubraum)
|
||||
Kleingedrucktes lesen!
|
||||
Billige Kabel oft nur USB 2.0 (Lade-Kabel)
|
||||
Teuer ≠ besser (aber oft ja)
|
||||
USB-IF Zertifizierung: Logo zeigt Spec an
|
||||
<!--
|
||||
USB-C = nur der physische Stecker (24-Pin, reversibel)
|
||||
Wie "Steckdose" – sagt nichts über Spannung/Leistung
|
||||
|
||||
Das Problem: Kabel sehen identisch aus, können aber:
|
||||
- Nur laden (kein Daten-Pin verdrahtet)
|
||||
- USB 2.0 (480 Mbps – wie vor 20 Jahren!)
|
||||
- USB 3.2 Gen 2 (10 Gbps)
|
||||
- USB 4 / Thunderbolt 4 (40 Gbps)
|
||||
|
||||
Warum?
|
||||
- Billige Kabel sparen Drähte (weniger Kupfer = billiger)
|
||||
- USB-IF Zertifizierung = freiwillig
|
||||
- Händler beschriften falsch oder gar nicht
|
||||
|
||||
Praxistipp:
|
||||
- Kabel vom Gerätehersteller nutzen
|
||||
- Thunderbolt-Logo = garantiert 40 Gbps
|
||||
- Im Zweifel: USB-IF zertifizierte Kabel kaufen
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -919,7 +1270,7 @@ Netzwerkkabel
|
||||
|
||||
**Stecker:** RJ45 (8P8C)
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Ethernet = IEEE 802.3 Standard
|
||||
BASE-T = Baseband, Twisted Pair (Kupfer)
|
||||
RJ45: Häufigste Bezeichnung (technisch 8P8C)
|
||||
@@ -932,6 +1283,67 @@ PoE = Power over Ethernet (Strom + Daten)
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
WLAN-Router + Bluetooth-Symbol
|
||||
Drahtlose Verbindungen
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# WLAN (Wi-Fi)
|
||||
|
||||
**IEEE 802.11:**
|
||||
|
||||
| Standard | Jahr | Max. Speed | Frequenz |
|
||||
|----------|------|-----------|----------|
|
||||
| 802.11n (Wi-Fi 4) | 2009 | 600 Mbps | 2,4/5 GHz |
|
||||
| 802.11ac (Wi-Fi 5) | 2013 | 3,5 Gbps | 5 GHz |
|
||||
| 802.11ax (Wi-Fi 6) | 2019 | 9,6 Gbps | 2,4/5/6 GHz |
|
||||
| 802.11be (Wi-Fi 7) | 2024 | 46 Gbps | 2,4/5/6 GHz |
|
||||
|
||||
**Praxis:** Geteiltes Medium → Real-Speed oft 30-50%
|
||||
|
||||
<!--
|
||||
Marketing-Namen: Wi-Fi 4, 5, 6, 6E, 7
|
||||
2,4 GHz: Bessere Reichweite, aber überlaufen (Mikrowelle!)
|
||||
5 GHz: Schneller, aber kürzere Reichweite
|
||||
Wi-Fi 6E: 6 GHz-Band (mehr Kanäle, weniger Störungen)
|
||||
Mesh-Systeme: Mehrere Access Points, nahtloses Roaming
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Bluetooth
|
||||
|
||||
**Bluetooth (1999):**
|
||||
|
||||
| Version | Jahr | Speed | Reichweite |
|
||||
|---------|------|-------|------------|
|
||||
| 4.0 (BLE) | 2010 | 1 Mbps | 100m |
|
||||
| 5.0 | 2016 | 2 Mbps | 400m |
|
||||
| 5.3 | 2021 | 2 Mbps | 400m |
|
||||
|
||||
**Anwendungen:**
|
||||
- Audio (Kopfhörer, Lautsprecher)
|
||||
- Peripherie (Maus, Tastatur)
|
||||
- IoT (Sensoren, Smart Home)
|
||||
|
||||
**Codecs:** SBC (Standard), AAC, aptX, LDAC
|
||||
|
||||
<!--
|
||||
BLE = Bluetooth Low Energy (Fitness-Tracker, AirTags)
|
||||
Classic Bluetooth: Höherer Stromverbrauch, für Audio
|
||||
aptX/LDAC: Bessere Audioqualität als SBC
|
||||
Bluetooth-Interferenz: Auch 2,4 GHz (wie WLAN)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
@@ -981,14 +1393,13 @@ Dokumentation: Verstehen, was man hat
|
||||
|
||||
---
|
||||
|
||||
# Aufgabe bis nächste Woche
|
||||
# Fleißaufgabe bis nächste Woche
|
||||
|
||||
**Analysiere deine Kabel:**
|
||||
|
||||
1. Liste alle Kabel (USB, HDMI, etc.)
|
||||
2. Identifiziere: Standard, Geschwindigkeit, Features
|
||||
3. Ist es beschriftet? Verständlich?
|
||||
4. Poste im Forum: Foto + das verwirrendste Kabel
|
||||
3. Finde das verwirrendste Kabel
|
||||
|
||||
**Bonus:** Finde USB-C-Kabel, das nur USB 2.0 kann
|
||||
|
||||
@@ -996,7 +1407,7 @@ Dokumentation: Verstehen, was man hat
|
||||
Kabel-Sammlung durchgehen
|
||||
Bewusstsein schaffen: Was habe ich eigentlich?
|
||||
Viele Lade-Kabel: USB-C, aber nur USB 2.0 (langsam!)
|
||||
Forum: Erfahrungsaustausch, lustige Fundstücke
|
||||
Keine Abgabe, nur zum Ausprobieren
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -1005,7 +1416,7 @@ Forum: Erfahrungsaustausch, lustige Fundstücke
|
||||
|
||||
# Fragen & Diskussion
|
||||
|
||||
**Kontakt:** czechowski@hdm-stuttgart.de
|
||||
**Kontakt:** mail@librete.ch
|
||||
**Folien:** Online verfügbar unter https://hdm.librete.ch
|
||||
|
||||
---
|
||||
|
||||
@@ -19,6 +19,7 @@ h2 {
|
||||
|
||||
<!-- _class: invert -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #000 -->
|
||||
|
||||

|
||||
@@ -476,7 +477,7 @@ Headers: Zeigen Cache-Status, CDN-Provider
|
||||
|
||||
---
|
||||
|
||||
# Aufgabe bis nächste Woche
|
||||
# Fleißaufgabe bis nächste Woche
|
||||
|
||||
**Analysiere Streaming-Dienst oder Website:**
|
||||
|
||||
@@ -485,12 +486,12 @@ Headers: Zeigen Cache-Status, CDN-Provider
|
||||
- Welcher CDN?
|
||||
- Wie viele Requests an CDN vs. Origin?
|
||||
- Cache-Headers?
|
||||
3. Poste im Forum: Screenshot + Erkenntnisse
|
||||
|
||||
**Bonus:** Linux-ISO via Torrent, poste Peer-Stats
|
||||
**Bonus:** Linux-ISO via Torrent, beobachte Peer-Stats
|
||||
|
||||
<!--
|
||||
Selbstständige Exploration
|
||||
<!--
|
||||
Selbstständiges Experimentieren
|
||||
Keine Abgabe, nur zum Ausprobieren
|
||||
Netflix: Schwer zu analysieren (verschlüsselt), aber CDN sichtbar
|
||||
YouTube: Google CDN (googlevideo.com)
|
||||
Spotify: Akamai CDN
|
||||
@@ -499,6 +500,31 @@ Cache-Control Header: max-age, s-maxage, public/private
|
||||
|
||||
---
|
||||
|
||||
# Dateitransfer-Protokolle
|
||||
|
||||
**FTP (File Transfer Protocol, 1971):**
|
||||
- Ältestes Internet-Protokoll für Dateitransfer
|
||||
- ⚠️ Unverschlüsselt! (Passwort im Klartext)
|
||||
- **SFTP/FTPS:** Sichere Varianten
|
||||
|
||||
**WebDAV (Web-based Distributed Authoring):**
|
||||
- HTTP-basiert → Firewall-freundlich
|
||||
- Wird von vielen Cloud-Diensten genutzt
|
||||
- Mountbar als Netzlaufwerk
|
||||
|
||||
**Moderne Alternativen:** rsync, rclone, Cloud-APIs
|
||||
|
||||
<!--
|
||||
FTP: Port 21 (Steuerung), Port 20 (Daten)
|
||||
Noch verbreitet für: Webhosting, Legacy-Systeme
|
||||
FileZilla: Populärer FTP-Client
|
||||
WebDAV: Nextcloud, Box.com nutzen WebDAV
|
||||
SMB/NFS: Für lokale Netzwerke besser (schneller)
|
||||
rsync: Inkrementelle Übertragung (nur Änderungen)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Teil 2: APIs
|
||||
@@ -928,7 +954,7 @@ WebSocket Echo: Server echot zurück (Test-Server)
|
||||
|
||||
---
|
||||
|
||||
# Aufgabe bis nächste Woche
|
||||
# Fleißaufgabe bis nächste Woche
|
||||
|
||||
**Experimentiere mit öffentlicher API:**
|
||||
|
||||
@@ -937,14 +963,13 @@ WebSocket Echo: Server echot zurück (Test-Server)
|
||||
- OpenWeather (`openweathermap.org/api`)
|
||||
- PokéAPI (`pokeapi.co`)
|
||||
2. Mache 3-5 Requests (curl, Postman, oder Code)
|
||||
3. Poste im Forum:
|
||||
- Welche API?
|
||||
- Interessante Daten?
|
||||
- Rate-Limiting erlebt? (429 Too Many Requests)
|
||||
3. Notiere: Welche Daten? Rate-Limiting erlebt?
|
||||
|
||||
**Bonus:** Baue kleinen Client (Python, JavaScript, etc.)
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Selbstständiges Experimentieren
|
||||
Keine Abgabe, nur zum Ausprobieren
|
||||
GitHub API: Repositories, Users, Issues (kostenlos, aber Rate-Limit)
|
||||
OpenWeather: Wetterdaten (API-Key nötig, Free Tier)
|
||||
PokéAPI: Pokémon-Daten (keine Auth nötig)
|
||||
@@ -1346,7 +1371,7 @@ MusicBrainz Picard: Audio-Fingerprinting in Aktion
|
||||
|
||||
---
|
||||
|
||||
# Aufgabe bis nächste Woche
|
||||
# Fleißaufgabe bis nächste Woche
|
||||
|
||||
**Metadaten-Audit:**
|
||||
|
||||
@@ -1355,15 +1380,13 @@ MusicBrainz Picard: Audio-Fingerprinting in Aktion
|
||||
- Eine MP3 (ID3)
|
||||
- Ein PDF (XMP)
|
||||
2. Analysiere: Welche Metadaten?
|
||||
3. Poste im Forum:
|
||||
- Screenshots (OHNE sensible Infos!)
|
||||
- Überraschungen?
|
||||
- Wie viel KB gespart nach Entfernung?
|
||||
3. Notiere: Überraschungen? KB gespart nach Entfernung?
|
||||
|
||||
**Bonus:** Finde alte Datei (>5 Jahre) – was verraten Metadaten über damaliges Setup?
|
||||
|
||||
<!--
|
||||
Selbst-Exploration
|
||||
<!--
|
||||
Selbstständiges Experimentieren
|
||||
Keine Abgabe, nur zum Ausprobieren
|
||||
Viele entdecken GPS zum ersten Mal
|
||||
Alte Dateien: Zeit-Kapsel (alte Software, Kamera-Modelle)
|
||||
KB-Ersparnis: Oft gering, aber Prinzip wichtig
|
||||
@@ -1387,22 +1410,18 @@ DNA-Helix überlagert
|
||||
|
||||
---
|
||||
|
||||
# Rückblick: 9 Wochen
|
||||
# Rückblick: 5 Termine
|
||||
|
||||
**Woche 1:** Bits → Bytes → Bedeutung (Encoding)
|
||||
**Woche 2:** MP3 & Psychoakustik
|
||||
**Woche 3:** JPEG & GIF-Kriege
|
||||
**Woche 4:** H.264 vs. AV1
|
||||
**Woche 5:** HDD vs. SSD, Dateisysteme, Backup
|
||||
**Woche 6:** USB-C-Chaos, HDMI vs. DisplayPort
|
||||
**Woche 7:** CDN, P2P, Streaming
|
||||
**Woche 8:** REST, GraphQL, WebSockets
|
||||
**Woche 9:** EXIF, Vendor Lock-in
|
||||
**Termin 1:** Bits, Bytes, Zeichenkodierung & Audio (MP3)
|
||||
**Termin 2:** Bild- & Videoformate (JPEG, H.264, AV1)
|
||||
**Termin 3:** Speichermedien & Schnittstellen
|
||||
**Termin 4:** Distribution, APIs & Zukunft
|
||||
**Termin 5:** Vertiefung & offene Fragen
|
||||
|
||||
**Heute:** Wohin geht die Reise?
|
||||
|
||||
<!--
|
||||
10 Wochen = Journey durch digitale Medien
|
||||
<!--
|
||||
5 Termine = Kompakte Journey durch digitale Medien
|
||||
Von Grundlagen (Bits) zu Infrastruktur (CDN)
|
||||
Technologie + Geschichte + Politik
|
||||
Heute: Zukunft + Abschluss-Projekt
|
||||
@@ -1786,8 +1805,8 @@ Digitale Medien sind das Ergebnis von Standards, Politik, Kompromissen & Innovat
|
||||
|
||||
Ihr habt jetzt die Werkzeuge, um die digitale Welt kritisch zu verstehen.
|
||||
|
||||
<!--
|
||||
10 Wochen = Intensive Journey
|
||||
<!--
|
||||
5 Termine = Intensive Journey
|
||||
Von Grundlagen zu Zukunft
|
||||
Technologie ist nicht neutral (Patent-Kriege, Vendor Lock-in)
|
||||
Kritisches Denken: Wer profitiert? Wer wird ausgeschlossen?
|
||||
@@ -1837,15 +1856,15 @@ Command Line Heroes: Tech-Geschichte (Spotify, Apple Podcasts)
|
||||
|
||||
**Nächste Schritte:**
|
||||
- Fallstudie (falls Prüfungsleistung)
|
||||
- Feedback willkommen (Forum, E-Mail)
|
||||
- Feedback willkommen (E-Mail)
|
||||
- Weiterlernen mit Ressourcen
|
||||
|
||||
**Vielen Dank für eure Aufmerksamkeit!**
|
||||
|
||||
<!--
|
||||
10 Wochen gemeinsame Reise
|
||||
5 Termine gemeinsame Reise
|
||||
Von "Was sind Bits?" zu "DNA-Storage"
|
||||
Hands-On jede Woche (Hex-Editor, FFmpeg, exiftool, APIs)
|
||||
Hands-On jedes Mal (Hex-Editor, FFmpeg, exiftool, APIs)
|
||||
Narrative statt Faktenlisten (Suzanne Vega, John McAfee, Tony Blair)
|
||||
Kritische Perspektive (Patent-Kriege, Vendor Lock-in)
|
||||
Evaluation: Feedback ernst nehmen, Kurs verbessern
|
||||
@@ -1857,7 +1876,7 @@ Evaluation: Feedback ernst nehmen, Kurs verbessern
|
||||
|
||||
# Fragen & Diskussion
|
||||
|
||||
**Kontakt:** czechowski@hdm-stuttgart.de
|
||||
**Kontakt:** mail@librete.ch
|
||||
**Folien:** Online verfügbar unter https://hdm.librete.ch
|
||||
|
||||
---
|
||||
|
||||
@@ -18,8 +18,21 @@ h2 {
|
||||
</style>
|
||||
|
||||
<!-- _class: invert -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #000 -->
|
||||
|
||||

|
||||

|
||||
|
||||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
|
||||
**223015b** · 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)
|
||||
|
||||
---
|
||||
|
||||
@@ -51,7 +64,7 @@ Themen nach Interesse der Studierenden
|
||||
|
||||
# Fragen & Diskussion
|
||||
|
||||
**Kontakt:** czechowski@hdm-stuttgart.de
|
||||
**Kontakt:** mail@librete.ch
|
||||
**Folien:** Online verfügbar unter https://hdm.librete.ch
|
||||
|
||||
---
|
||||
|
||||
|
After Width: | Height: | Size: 574 KiB |
|
After Width: | Height: | Size: 408 KiB |
|
After Width: | Height: | Size: 484 KiB |
|
After Width: | Height: | Size: 121 KiB |
|
After Width: | Height: | Size: 5.3 MiB |
|
Before Width: | Height: | Size: 5.3 MiB After Width: | Height: | Size: 4.0 MiB |
|
After Width: | Height: | Size: 1.7 MiB |