diff --git a/.claude/skills/marp/REFERENCE.md b/.claude/skills/marp/REFERENCE.md
new file mode 100644
index 0000000..5b9215a
--- /dev/null
+++ b/.claude/skills/marp/REFERENCE.md
@@ -0,0 +1,373 @@
+# Marp/Marpit Complete Reference
+
+## Overview
+
+**Marp** = Markdown Presentation Ecosystem
+**Marpit** = The core framework ("skinny framework for creating slide deck from Markdown")
+
+Built-in themes: `default`, `gaia`, `uncover`
+
+---
+
+## Slide Structure
+
+### Slide Separation
+Slides are separated by horizontal rulers:
+```markdown
+---
+```
+Alternatives: `___`, `***`, `- - -`
+
+**Important**: May need empty line before `---` per CommonMark spec.
+
+### Basic Document Structure
+```markdown
+---
+marp: true
+theme: gaia
+paginate: true
+---
+
+# First Slide
+
+Content here
+
+---
+
+# Second Slide
+
+More content
+
+
+```
+
+---
+
+## Directives
+
+### Syntax Options
+
+**HTML Comments:**
+```markdown
+
+
+```
+
+**Front-matter (YAML):**
+```markdown
+---
+theme: default
+paginate: true
+---
+```
+
+### Directive Scopes
+
+| Scope | Applies to | Syntax |
+|-------|-----------|--------|
+| Global | Entire deck | Normal directive |
+| Local | Current + following slides | Normal directive mid-document |
+| Spot | Single slide only | Underscore prefix: `_directive` |
+
+### Global Directives
+- `theme` — Slide deck theme
+- `style` — Custom CSS
+- `lang` — Language attribute (accessibility)
+- `headingDivider` — Auto-split at heading levels (1-6)
+
+### Local Directives
+- `paginate` — Page numbers (true/false/hold/skip)
+- `header` — Persistent header text
+- `footer` — Persistent footer text
+- `class` — CSS class for slide
+- `backgroundColor` — Slide background color
+- `backgroundImage` — Background image URL
+- `backgroundPosition` — CSS background-position
+- `backgroundRepeat` — CSS background-repeat
+- `backgroundSize` — CSS background-size
+- `color` — Text color
+
+### Spot Directive Example
+```markdown
+
+
+```
+Only affects current slide.
+
+### Pagination Values
+- `true` — Show and increment
+- `false` — Hide but increment
+- `hold` — Show without incrementing
+- `skip` — Hide without incrementing
+
+### Heading Divider
+```markdown
+---
+headingDivider: 2
+---
+
+# Section 1
+Content
+
+## Slide 1.1
+Content
+
+## Slide 1.2
+Content
+```
+
+---
+
+## Image Syntax
+
+### Basic Resizing
+```markdown
+
+
+
+```
+
+Units: px, em, cm, pt, etc. (no viewport units vw/vh)
+
+### Image Filters
+```markdown
+
+
+
+
+
+
+
+
+
+
+```
+
+Combine multiple:
+```markdown
+
+```
+
+### Background Images
+```markdown
+
+
+
+
+
+```
+
+### Split Backgrounds
+```markdown
+
+
+
+
+```
+
+### Multiple Backgrounds
+```markdown
+
+
+
+```
+Arranges horizontally by default.
+
+```markdown
+
+
+```
+Arranges vertically.
+
+---
+
+## Fragmented Lists (Animations)
+
+### Bullet Lists — Use `*`
+```markdown
+* First item
+* Second item
+* Third item
+```
+
+Regular `-` or `+` bullets don't animate.
+
+### Ordered Lists — Use `)`
+```markdown
+1) First item
+2) Second item
+3) Third item
+```
+
+Regular `.` numbered lists don't animate.
+
+### Output
+```html
+First
+Second
+```
+
+**Note**: Actual animation depends on presentation viewer.
+
+---
+
+## Theme CSS
+
+### Required Metadata
+```css
+/* @theme my-theme */
+```
+
+### Core Selectors
+```css
+/* Slide container */
+section {
+ width: 1280px;
+ height: 720px;
+ font-size: 32px;
+}
+
+/* Higher specificity alternative */
+:root {
+ --color-primary: #3498db;
+}
+
+/* Pagination */
+section::after {
+ content: attr(data-marpit-pagination) ' / ' attr(data-marpit-pagination-total);
+}
+```
+
+### Scoped Styles
+```markdown
+
+```
+
+### Global Inline Styles
+```markdown
+
+```
+
+### Theme Inheritance
+```css
+/* @theme derived-theme */
+@import 'default';
+/* or */
+@import-theme 'default';
+```
+
+### Units
+- `rem` scales relative to slide `` (isolated from HTML root)
+- Slide dimensions require absolute units (px, cm, in, mm)
+
+---
+
+## Marp CLI
+
+### Installation
+```bash
+npm install -g @marp-team/marp-cli
+# or
+brew install marp-cli
+```
+
+### Basic Conversion
+```bash
+marp slide.md # → HTML
+marp --pdf slide.md # → PDF
+marp --pptx slide.md # → PowerPoint
+marp --images png slide.md # → PNG images
+```
+
+### Development Server
+```bash
+marp --server ./slides/
+PORT=1312 marp --server ./
+```
+
+Query formats: `http://localhost:8080/deck.md?pdf`
+
+### Watch Mode
+```bash
+marp --watch slide.md
+```
+
+### Key Options
+```bash
+-o, --output # Output path
+-w, --watch # Watch for changes
+-s, --server # HTTP server mode
+-p, --preview # Open preview window
+--pdf # PDF output
+--pptx # PowerPoint output
+--images [png|jpeg] # Image output
+--image-scale # Resolution (e.g., 2 for 2x)
+--allow-local-files # Enable local file access (security risk)
+--pdf-notes # Include speaker notes in PDF
+--browser # chrome, edge, firefox
+```
+
+---
+
+## Common Patterns
+
+### Title Slide
+```markdown
+
+
+# Presentation Title
+
+**Author Name**
+Date
+```
+
+### Two-Column Layout (via background)
+```markdown
+
+
+# Right Content
+
+Text appears on right side
+```
+
+### Speaker Notes
+```markdown
+# Slide Title
+
+Content
+
+
+```
+
+### Custom Class
+```markdown
+
+
+# Centered Dark Slide
+```
+
+Then in CSS/theme:
+```css
+section.centered { text-align: center; }
+section.dark { background: #222; color: #fff; }
+```
+
+---
+
+## Project Conventions (This Project)
+
+- Theme: `gaia`
+- Assets: `./assets/filename.png`
+- Build output: `build/`
+- Dev server: `make dev` (port 1312)
+- Never end with `---` (creates empty slide)
diff --git a/.claude/skills/marp/SKILL.md b/.claude/skills/marp/SKILL.md
new file mode 100644
index 0000000..3d9a9fe
--- /dev/null
+++ b/.claude/skills/marp/SKILL.md
@@ -0,0 +1,79 @@
+---
+name: marp
+description: Marp/Marpit documentation and slide creation guide. Use this skill when working with Marp presentations, slide syntax, themes, directives, or troubleshooting Marp-related issues.
+allowed-tools:
+ - Read
+ - Glob
+ - Grep
+ - WebFetch
+---
+
+# Marp/Marpit Skill
+
+## Purpose
+
+This skill provides comprehensive knowledge about Marp (Markdown Presentation Ecosystem) and its core engine Marpit. Use this when creating, editing, or troubleshooting Markdown-based slide presentations.
+
+## Documentation Sources
+
+When you need Marp information, fetch from these official sources:
+
+### Marpit Framework (Core Engine)
+- **Main docs**: https://marpit.marp.app/
+- **Markdown syntax**: https://marpit.marp.app/markdown
+- **Directives**: https://marpit.marp.app/directives
+- **Theme CSS**: https://marpit.marp.app/theme-css
+- **Fragmented list**: https://marpit.marp.app/fragmented-list
+- **Image syntax**: https://marpit.marp.app/image-syntax
+
+### Marp CLI
+- **Usage guide**: https://github.com/marp-team/marp-cli
+
+## Key Concepts to Learn
+
+### 1. Slide Separation
+Slides are separated by `---` (horizontal rule). The first `---` after frontmatter starts the first slide.
+
+### 2. Directives
+- **Global directives**: Apply to all slides (in frontmatter)
+- **Local directives**: Apply to current slide only (``)
+- **Spot directives**: Underscore prefix for local scope
+
+### 3. Image Syntax
+Marp extends standard Markdown image syntax:
+- `` - background image
+- `` - fit to slide
+- `` - split background
+- `` - width filter
+- `` - height filter
+
+### 4. Theme CSS
+- Themes use CSS with special Marpit selectors
+- `section` = slide container
+- `section::after` = pagination
+- CSS variables for theming
+
+### 5. Scoped Styles
+```html
+
+```
+
+## Workflow
+
+When asked about Marp:
+
+1. **Read REFERENCE.md first** - Contains comprehensive syntax documentation
+2. **Check local files** - Read existing slides and themes in the project
+3. **Fetch official docs if needed** - Use WebFetch for edge cases
+4. **Provide concrete examples** - Show actual Marp syntax
+5. **Reference project conventions** - Follow CLAUDE.md guidelines
+
+## Project-Specific Notes
+
+This project uses:
+- Theme: `gaia`
+- Assets path: `./assets/`
+- Build output: `build/`
+- Dev server: `make dev` (port 1312)
diff --git a/.gitignore b/.gitignore
index 10d7422..c16b28e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -61,3 +61,5 @@ Desktop.ini
*.html
!build/*.html
*.pdf
+index.md.bak
+hdm-lehrauftrag-uebersicht.md
diff --git a/CLAUDE.md b/CLAUDE.md
index 56c648c..baa7216 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -6,6 +6,13 @@ This project builds a presentation deck for Marp based on Markdown files.
- Agent NEVER runs commands on its own except changing files INSIDE THIS FOLDER, never any other then this
- Agent NEVER runs build commands or any automated processes without explicit user request, as the user is working in dev mode
+## Critical File Protection: index.md
+- `index.md` is the MAIN CONTENT FILE for the entire lecture series - treat with extreme care
+- ALLOWED: Adding new slides, adjusting existing content, fixing typos, enhancing sections
+- FORBIDDEN (without explicit permission): Deleting slides, removing sections, bulk replacements that remove content
+- Before ANY deletion in index.md: ALWAYS ask user for confirmation and warn about what will be removed
+- When in doubt, ADD rather than REPLACE - let the user decide what to remove
+
## Build Commands
- `npm run build` - Build slides from Markdown using Marp
- `npm run dev` - Start development server at http://localhost:8080
diff --git a/IMAGE_LIST.md b/IMAGE_LIST.md
new file mode 100644
index 0000000..8f13fc4
--- /dev/null
+++ b/IMAGE_LIST.md
@@ -0,0 +1,319 @@
+# Image List for HdM Dateiformate Slides
+
+This document lists all images needed for the lecture slides. Each image includes:
+- **Filename**: Target filename in `./assets/`
+- **Context**: Where/why it's used in the slides
+- **AI Prompt**: Suggested prompt for image generation (Gemini, DALL-E, Midjourney, etc.)
+
+**Recommended settings:**
+- Aspect ratio: 16:9 (1920x1080 or similar)
+- Style: Clean, professional, educational
+- For logos: Consider downloading official versions from the web instead of generating
+
+**Legend:**
+- ✅ = Already generated and in assets/
+- ⬚ = Not yet generated
+
+---
+
+## Intro
+
+### ✅ digital-landscape.png
+- **Context**: Opening slide background, sets futuristic tech mood
+- **AI Prompt**: Futuristic digital landscape with glowing blue and purple data streams, abstract network connections, binary patterns flowing through a neon-lit cyber environment, wide cinematic shot, no text
+
+---
+
+## Termin 1: Grundlagen, Text & Audio
+
+### ✅ matrix-code.png
+- **Context**: Opening visual for "WTF!?" hex dump slide
+- **AI Prompt**: Matrix-style green digital rain code falling on black background, glowing green characters, cyberpunk hacker aesthetic, mysterious data visualization
+
+### ✅ lightbulb-onoff.png
+- **Context**: Explaining the bit concept (0 or 1, on or off)
+- **AI Prompt**: Simple lightbulb comparison: one lit bright yellow, one dark/off, side by side, clean minimal style, binary concept visualization, white background
+
+### ✅ grayscale-gradient.png ⚠️ NEEDS REGENERATION
+- **Context**: Explaining 256 grayscale values (0=black to 255=white)
+- **AI Prompt**: Horizontal grayscale gradient bar on a neutral gray background (#808080), gradient goes from pure black (left) to pure white (right), add visible value labels "0" on left and "255" on right, ensure edges are clearly visible against background, clean educational diagram style, 16:9 aspect ratio
+- **Issue**: Current image has barely visible edges on left (black) and right (white) sides
+
+### ✅ rgb-color-model.png
+- **Context**: Explaining RGB color model (3 bytes per pixel)
+- **AI Prompt**: RGB color model visualization showing three overlapping circles (red, green, blue) creating cyan, magenta, yellow, and white in overlaps, clean educational diagram style
+
+### ✅ ascii-table.png
+- **Context**: Showing ASCII character encoding (7-bit, 128 characters total)
+- **AI Prompt**: Clean ASCII table showing printable characters 32-126 with their decimal and hex values, vintage computer terminal aesthetic, green on black or clean white background, educational reference chart. Note: ASCII is 7-bit encoding with 128 total characters (0-127), not 256. First 32 (0-31) are control characters, 127 is DEL.
+
+### ✅ hex-binary-table.png
+- **Context**: Hex to binary conversion reference
+- **AI Prompt**: Clean conversion table showing hexadecimal digits 0-F with their 4-bit binary equivalents, educational reference style, programmer cheat sheet aesthetic
+
+### ✅ hexeditor-screenshot.png
+- **Context**: Showing what a hex editor looks like
+- **AI Prompt**: Screenshot of hex editor software showing file bytes in hexadecimal with ASCII representation on the right side, typical hex editor layout, technical software interface
+
+### ✅ cassette-ipod.png
+- **Context**: Audio format evolution intro
+- **AI Prompt**: Vintage audio cassette tape next to modern iPod or MP3 player, technology evolution comparison, nostalgic meets modern, clean product photography style
+
+### ✅ compression-types.png
+- **Context**: Lossless vs lossy compression comparison
+- **AI Prompt**: Split diagram comparing lossless (ZIP icon, identical files) vs lossy (JPEG/MP3 icon, smaller but different), educational infographic style, clear visual distinction
+
+### ✅ karlheinz-brandenburg.jpg
+- **Context**: MP3 inventor portrait/reference (Fraunhofer IIS)
+- **AI Prompt**: Professional portrait style of a German scientist/engineer in academic setting, Fraunhofer institute aesthetic, 1990s technology pioneer look (or use real photo)
+
+### ✅ suzanne-vega.jpg
+- **Context**: "Tom's Diner" - the song used to test MP3 compression
+- **AI Prompt**: Female singer-songwriter aesthetic, acoustic guitar, 1980s folk music style, intimate cafe performance setting (or use real photo)
+
+### ✅ audio-spectrogram.png
+- **Context**: Visualizing audio frequencies and MP3 compression effects
+- **AI Prompt**: Colorful audio spectrogram visualization showing frequency spectrum over time, rainbow gradient from low (red) to high (blue) frequencies, scientific audio analysis display
+
+### ✅ napster-interface.png
+- **Context**: MP3 piracy era / file sharing history (1999-2001)
+- **AI Prompt**: Late 1990s peer-to-peer file sharing interface aesthetic, Windows 98/2000 style dialog boxes, music file listings, nostalgic internet era, retro software UI
+
+---
+
+## Termin 2: Bild, Audio, Video
+
+### ✅ photo-comparison.png
+- **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
+
+### ✅ 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
+
+### ✅ gif-animation.png
+- **Context**: Explaining GIF format limitations
+- **AI Prompt**: Classic internet aesthetic image with limited color palette (256 colors), dithering patterns visible, retro web 1.0 style, simple animation frames concept, nostalgic internet culture
+
+### ✅ instagram-quality-loss.png
+- **Context**: Real-world example of social media compression
+- **AI Prompt**: Split image comparison: left side showing original crisp smartphone photo, right side showing same image after social media upload with visible quality degradation, compression artifacts, softer details, educational before/after style
+
+### ✅ netflix-4k.png
+- **Context**: Modern streaming technology introduction
+- **AI Prompt**: Modern living room with large OLED TV displaying streaming interface, 4K UHD quality visible, cozy home theater setup, ambient lighting, contemporary interior design, cinematic wide shot
+
+### ✅ container-codec-diagram.png
+- **Context**: Explaining video container vs codec concept
+- **AI Prompt**: Clean technical diagram showing video container structure as a box containing separate colored tracks: video stream (blue), audio stream (green), subtitle stream (yellow), metadata (gray), arrows showing data flow, minimal infographic style, white background
+
+### ✅ iframe-pframe-diagram.png
+- **Context**: Video compression frame types explanation
+- **AI Prompt**: Technical diagram showing video compression frame sequence: large I-frame (keyframe) in blue, smaller P-frames (predicted) in green, tiny B-frames (bidirectional) in orange, arrows showing dependencies between frames, timeline visualization, clean educational style
+
+### ✅ youtube-vp9.png
+- **Context**: VP9 codec discussion
+- **AI Prompt**: YouTube video player interface with VP9 codec indicator, stats for nerds overlay showing codec information, modern streaming technology aesthetic, screen capture style
+
+### ✅ av1-logo.png
+- **Context**: AV1 codec introduction
+- **AI Prompt**: AV1 video codec logo visualization, Alliance for Open Media branding, clean modern tech logo style, blue and white color scheme, professional technology branding
+
+### ✅ streaming-quality-switch.png
+- **Context**: Adaptive bitrate streaming explanation
+- **AI Prompt**: Visualization of adaptive bitrate streaming: video player with quality indicator showing switch from 480p to 720p to 1080p, buffer loading bar, bandwidth graph in corner, technical streaming diagram style
+
+---
+
+## Termin 3: Speichermedien & Schnittstellen
+
+### ⬚ 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
+
+### ⬚ directory-tree.png
+- **Context**: File system structure explanation
+- **AI Prompt**: File system directory tree visualization, hierarchical folder structure with branching paths, root folder at top expanding into subdirectories, clean diagram style with folder icons, blue and gray color scheme, technical illustration
+
+### ⬚ backup-disaster.png
+- **Context**: Importance of backups - cautionary tale
+- **AI Prompt**: Dramatic scene of broken hard drive with visible damage, smoke rising, concerned person in background looking at computer screen showing error message, data loss disaster concept, moody lighting, cautionary illustration style
+
+### ⬚ bit-rot.png
+- **Context**: Data degradation over time
+- **AI Prompt**: Abstract visualization of digital decay: image gradually corrupting from left to right, pixels breaking apart, glitch effects spreading, data entropy concept, corrupted file aesthetic, technical art style
+
+### ⬚ lto-tape.png
+- **Context**: Professional archival storage
+- **AI Prompt**: LTO tape cartridge in professional data center setting, tape drive unit visible, blue and black enterprise storage equipment, clean technical product shot, professional backup infrastructure
+
+### ⬚ m-disc.png
+- **Context**: Long-term optical storage
+- **AI Prompt**: M-DISC optical disc showing distinctive gold/bronze reflective surface, archival grade media, jewel case partially visible, product photography style, emphasis on durability and longevity
+
+### ⬚ dna-helix.png
+- **Context**: Future storage technology
+- **AI Prompt**: DNA double helix structure with binary code (0s and 1s) integrated into the strand pattern, futuristic data storage concept, blue bioluminescent glow, science fiction meets biology, clean dark background
+
+### ⬚ cable-mess.png
+- **Context**: Cable/connector chaos problem
+- **AI Prompt**: Chaotic tangle of various cables: USB-A, USB-C, HDMI, DisplayPort, Lightning, micro-USB, all intertwined in frustrating mess, cable drawer chaos, relatable tech problem, overhead shot
+
+### ⬚ pc-back-1990s.png
+- **Context**: Legacy port evolution
+- **AI Prompt**: Back panel of vintage 1990s beige desktop PC showing rainbow of legacy ports: blue VGA, green/purple PS/2, gray serial DB9, pink parallel DB25, game port, nostalgic retro computing, authentic vintage tech
+
+### ⬚ usb-c-cables.png
+- **Context**: USB-C confusion (same connector, different specs)
+- **AI Prompt**: Five identical-looking USB-C cables laid out in a row, all appearing the same but with subtle question marks or spec labels (USB 2.0, 3.0, 3.1, Thunderbolt, charging only), consumer confusion concept, clean product shot
+
+### ⬚ thunderbolt-logo.png
+- **Context**: Thunderbolt interface explanation
+- **AI Prompt**: Thunderbolt technology logo, stylized lightning bolt symbol, Intel branding aesthetic, clean modern tech logo on dark background, high-speed connection concept
+
+### ⬚ hdmi-cable.png
+- **Context**: HDMI interface explanation
+- **AI Prompt**: HDMI cable with gold-plated connector in sharp focus, premium build quality visible, professional AV equipment aesthetic, product photography on neutral background
+
+### ⬚ displayport-cable.png
+- **Context**: DisplayPort interface explanation
+- **AI Prompt**: DisplayPort cable and connector close-up, distinctive asymmetrical shape visible, professional display connection, technical product photography, clean background
+
+### ⬚ hdcp-warning.png
+- **Context**: DRM/content protection issues
+- **AI Prompt**: TV or monitor screen displaying HDCP error message dialog box, "Content Protection Error" or "HDCP not supported" warning, frustrated user experience, screen capture style, consumer electronics problem
+
+### ⬚ ethernet-cable.png
+- **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
+
+### ⬚ 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
+
+---
+
+## Termin 4: Distribution, APIs, Zukunft
+
+### ⬚ sneakernet-truck.png
+- **Context**: Physical data transport concept ("Never underestimate bandwidth of a truck full of tapes")
+- **AI Prompt**: Semi truck loaded with pallets of hard drives and storage media, highway background, humorous take on data transfer, "sneakernet" concept visualization, photorealistic style
+
+### ⬚ aws-snowmobile.png
+- **Context**: AWS Snowmobile - extreme data transfer
+- **AI Prompt**: Large shipping container truck (semi-trailer) with data center branding, AWS style, massive scale data transfer concept, industrial tech photography
+
+### ⬚ cd-dvd-bluray.png
+- **Context**: Physical media distribution history
+- **AI Prompt**: Three optical discs arranged showing evolution: CD, DVD, Blu-ray, each with distinctive colors/labels, product photography, media format comparison
+
+### ⬚ server-overload.png
+- **Context**: "Hug of Death" / traffic spike problems
+- **AI Prompt**: Server rack with red warning lights flashing, smoke or heat waves rising, overwhelmed system visualization, too many connection requests flooding in as visual arrows, data center stress, dramatic lighting
+
+### ⬚ cdn-map.png
+- **Context**: Content Delivery Network explanation
+- **AI Prompt**: World map with glowing nodes representing CDN edge locations, connection lines between points of presence, global content delivery network visualization, dark background with bright cyan/green nodes, tech infographic style
+
+### ⬚ netflix-openconnect.png
+- **Context**: Netflix CDN case study
+- **AI Prompt**: Netflix Open Connect server appliance in ISP data center rack, red Netflix branding visible, professional server hardware, content delivery infrastructure, enterprise equipment photography
+
+### ⬚ p2p-network.png
+- **Context**: Peer-to-peer architecture explanation
+- **AI Prompt**: Peer-to-peer network diagram showing decentralized mesh of connected computer nodes, no central server, all nodes equal, bidirectional arrows between peers, clean technical diagram style, blue network aesthetic
+
+### ⬚ bittorrent-swarm.png
+- **Context**: BitTorrent technology explanation
+- **AI Prompt**: BitTorrent swarm visualization showing multiple peers exchanging colored file chunks/pieces, some peers have complete file (seeders), others downloading (leechers), piece availability concept, technical diagram style
+
+### ⬚ pirate-bay-logo.png
+- **Context**: BitTorrent history/controversy discussion
+- **AI Prompt**: Pirate ship silhouette in vintage woodcut style, cassette tape as sail, controversial but historically significant internet culture reference, monochrome illustration style
+
+### ⬚ ipfs-logo.png
+- **Context**: Decentralized storage future
+- **AI Prompt**: IPFS (InterPlanetary File System) logo concept, interconnected nodes forming globe shape, decentralized web aesthetic, teal/cyan color scheme, modern tech branding
+
+### ⬚ streaming-hls.png
+- **Context**: HLS/DASH streaming protocols
+- **AI Prompt**: Streaming pipeline diagram: video encoder box connecting to CDN cloud connecting to multiple player devices, HLS/DASH segment chunks visualized as small boxes along the path, technical flowchart style
+
+### ⬚ api-diagram.png
+- **Context**: API concept introduction
+- **AI Prompt**: Clean API diagram showing multiple application icons connected by arrows through central API gateway, request/response flow visualization, software integration concept, modern flat design infographic
+
+### ⬚ http-request-response.png
+- **Context**: HTTP basics
+- **AI Prompt**: HTTP request/response cycle diagram: client computer on left, server on right, arrows showing GET request going right, response with data coming back left, status codes visible, clean technical illustration
+
+### ⬚ rest-api.png
+- **Context**: REST architecture explanation
+- **AI Prompt**: REST API structure diagram showing resource URLs (/users, /posts, /comments) with HTTP methods (GET, POST, PUT, DELETE) color-coded, CRUD operations mapped, clean API documentation style
+
+### ⬚ graphql-logo.png
+- **Context**: GraphQL introduction
+- **AI Prompt**: GraphQL logo, distinctive pink/magenta hexagonal shape, query language for APIs branding, modern tech aesthetic, clean vector style on dark background
+
+### ⬚ websocket-diagram.png
+- **Context**: Real-time communication
+- **AI Prompt**: WebSocket vs HTTP comparison diagram: HTTP showing multiple request-response pairs, WebSocket showing single persistent bidirectional connection, real-time communication concept, technical comparison illustration
+
+### ⬚ grpc-logo.png
+- **Context**: gRPC introduction
+- **AI Prompt**: gRPC logo, Google's RPC framework branding, blue and white color scheme, protocol buffers concept, modern microservices aesthetic, clean tech logo
+
+### ⬚ exif-gps.png
+- **Context**: Metadata privacy concerns
+- **AI Prompt**: Smartphone photo with semi-transparent overlay showing EXIF metadata: GPS coordinates on map, camera model, date/time, exposure settings, privacy concern visualization, metadata exposure concept
+
+### ⬚ mcafee-exif-fail.png
+- **Context**: Real-world EXIF privacy incident
+- **AI Prompt**: News headline style image about location data leak, map with pin showing exposed location, journalist camera icon, privacy fail case study concept, documentary style illustration
+
+### ⬚ id3-tag-editor.png
+- **Context**: Audio metadata explanation
+- **AI Prompt**: Screenshot-style image of ID3 tag editor software interface showing MP3 metadata fields: title, artist, album, year, genre, track number, album art placeholder, music file management aesthetic
+
+### ⬚ musicbrainz-logo.png
+- **Context**: Music metadata database
+- **AI Prompt**: MusicBrainz logo concept, music database branding, orange/yellow color scheme, open source music metadata project aesthetic
+
+### ⬚ pdf-metadata-leak.png
+- **Context**: Document metadata privacy
+- **AI Prompt**: PDF document properties dialog showing hidden metadata: author name, creation date, software used, revision history, privacy concern visualization, document forensics concept
+
+### ⬚ futuristic-datacenter.png
+- **Context**: Future of data storage intro
+- **AI Prompt**: Futuristic data center with glowing blue server racks, holographic displays, advanced cooling systems, sci-fi technology aesthetic, next-generation computing infrastructure
+
+### ⬚ jpeg-xl-logo.png
+- **Context**: Next-gen image formats
+- **AI Prompt**: JPEG XL logo concept, modern image format branding, evolution of JPEG, clean tech logo style, future of image compression
+
+### ⬚ dna-storage-concept.png
+- **Context**: DNA data storage future
+- **AI Prompt**: DNA strand with digital data visualization, binary code transforming into genetic sequence, futuristic biotechnology concept, scientific illustration style, data storage evolution
+
+---
+
+## Summary
+
+| Lecture | Total | ✅ Done | ⬚ Todo |
+|---------|-------|--------|--------|
+| 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 4 (Distribution/APIs) | 25 | 0 | 25 |
+| **Total** | **65** | **24** | **41** |
+
+**Note:** grayscale-gradient.png is marked ⚠️ NEEDS REGENERATION due to visibility issues at edges.
+
+## Generation Tips
+
+1. **Diagrams**: Use "clean infographic style", "technical illustration", "minimal diagram" in prompts
+2. **Photos**: Use "product photography", "professional shot", "realistic" for hardware images
+3. **Concepts**: Use "visualization", "abstract representation" for abstract ideas
+4. **Logos**: Consider downloading official logos instead of generating (better accuracy)
+5. **Consistency**: Add "educational style", "professional presentation" to maintain visual coherence
diff --git a/Makefile b/Makefile
index 018c16e..ac08e41 100644
--- a/Makefile
+++ b/Makefile
@@ -1,48 +1,92 @@
# Makefile for Marp Slides Project
-.PHONY: help build dev watch pdf html clean install deploy
+.PHONY: help build dev watch pdf html clean install deploy assemble
+
+# Slide components
+SLIDES_DIR = slides
+BUILD_DIR = build
+HEADER = $(SLIDES_DIR)/_frontmatter.md
+INTRO = $(SLIDES_DIR)/_intro.md
+OUTRO = $(SLIDES_DIR)/_outro.md
+
+# Termin files (date-topic naming convention)
+TERMIN_1 = 2025-12-19-termin-1-grundlagen-text-audio
+TERMIN_2 = 2026-01-09-termin-2-bild-audio-video
+TERMIN_3 = 2026-01-23-termin-3-speichermedien-schnittstellen
+TERMIN_4 = 2026-01-30-termin-4-distribution-apis-zukunft
+TERMIN_5 = 2026-xx-xx-termin-5-vertiefung-offene-fragen
+TERMINS = $(TERMIN_1) $(TERMIN_2) $(TERMIN_3) $(TERMIN_4) $(TERMIN_5)
# Default target
help:
@echo "Available commands:"
- @echo " make build - Build slides from Markdown"
- @echo " make dev - Start development server with live reload"
- @echo " make watch - Watch for changes and rebuild automatically"
- @echo " make pdf - Export slides to PDF format"
- @echo " make html - Export slides to HTML format"
- @echo " make clean - Remove generated files"
- @echo " make install - Install dependencies"
- @echo " make deploy - Deploy slides to server"
+ @echo ""
+ @echo " Development:"
+ @echo " make dev - Start dev server (browse all files at localhost:1312)"
+ @echo ""
+ @echo " Build:"
+ @echo " make build - Build all slides (HTML + PDF)"
+ @echo " make pdf - Export all slides to PDF"
+ @echo " make html - Export all slides to HTML"
+ @echo ""
+ @echo " Other:"
+ @echo " make assemble - Assemble all termin files in build/"
+ @echo " make clean - Remove generated files"
+ @echo " make install - Install dependencies"
+ @echo " make deploy - Deploy slides to server"
-# Build slides
-build:
- @echo "Building slides..."
- npm run build
+# Ensure build directory exists
+$(BUILD_DIR)/.exists:
+ @mkdir -p $(BUILD_DIR)
+ @touch $@
-# Start development server
+# Assemble all termin files
+assemble: $(BUILD_DIR)/.exists
+ @echo "Assembling slides..."
+ @for f in $(TERMINS); do \
+ echo " $$f.md"; \
+ cat $(HEADER) $(INTRO) $(SLIDES_DIR)/$$f.md $(OUTRO) > $(BUILD_DIR)/$$f.md; \
+ done
+ @echo " all.md"
+ @cat $(HEADER) $(INTRO) $(foreach t,$(TERMINS),$(SLIDES_DIR)/$(t).md) $(OUTRO) > $(BUILD_DIR)/all.md
+ @cp -r $(SLIDES_DIR)/assets $(BUILD_DIR)/ 2>/dev/null || true
+
+# Development server - serves slides/ directly with HMR
dev:
- @echo "Starting development server..."
- npm run dev
+ @echo "Starting dev server with HMR..."
+ @echo "Open: http://localhost:1312"
+ PORT=1312 npx @marp-team/marp-cli --server $(SLIDES_DIR)/
# Watch for changes
-watch:
- @echo "Watching for changes..."
- npm run watch
+watch: assemble
+ npx @marp-team/marp-cli --watch $(BUILD_DIR)/all.md
-# Export to PDF
-pdf:
+# Build all slides (HTML + PDF)
+build: assemble
+ @echo "Building all slides..."
+ @for f in $(TERMINS); do \
+ echo "Building $$f..."; \
+ npx @marp-team/marp-cli $(BUILD_DIR)/$$f.md -o $(BUILD_DIR)/$$f.html; \
+ npx @marp-team/marp-cli $(BUILD_DIR)/$$f.md --pdf --allow-local-files -o $(BUILD_DIR)/$$f.pdf; \
+ done
+ @echo "Building all.md..."
+ npx @marp-team/marp-cli $(BUILD_DIR)/all.md -o $(BUILD_DIR)/all.html
+ npx @marp-team/marp-cli $(BUILD_DIR)/all.md --pdf --allow-local-files -o $(BUILD_DIR)/all.pdf
+
+# Export to PDF (all slides combined)
+pdf: assemble
@echo "Exporting to PDF..."
- npm run export:pdf -- --allow-local-files
+ npx @marp-team/marp-cli $(BUILD_DIR)/all.md --pdf --allow-local-files -o $(BUILD_DIR)/all.pdf
-# Export to HTML
-html:
+# Export to HTML (all slides combined)
+html: assemble
@echo "Exporting to HTML..."
- npm run export:html
+ npx @marp-team/marp-cli $(BUILD_DIR)/all.md -o $(BUILD_DIR)/all.html
# Clean generated files
clean:
@echo "Cleaning generated files..."
- rm -rf dist/ build/ *.pdf *.html
+ rm -rf $(BUILD_DIR)/ *.pdf *.html
# Install dependencies
install:
@@ -52,5 +96,5 @@ install:
# Deploy slides
deploy: build
@echo "Deploying slides..."
- scp build/index.html tengo@tuttle.uberspace.de:/home/tengo/html/malta/
- scp -r build/assets/ tengo@tuttle.uberspace.de:/home/tengo/html/malta/
+ scp $(BUILD_DIR)/all.html tengo@tuttle.uberspace.de:/home/tengo/html/malta/index.html
+ scp -r $(BUILD_DIR)/assets/ tengo@tuttle.uberspace.de:/home/tengo/html/malta/
diff --git a/README.md b/README.md
index ef33982..cbe5ba0 100644
--- a/README.md
+++ b/README.md
@@ -1,6 +1,44 @@
-# HdM - Dateiformate, Speichermedien und Schnittstellen
+# 223015b – Dateiformate, Schnittstellen, Speichermedien & Distributionswege
-## Creating Slides
+**Modul "Technik 1"** · 1. Semester · Digital- und Medienwirtschaft
+Hochschule der Medien Stuttgart · Wintersemester 2025/26
+
+**Repository:** [git.librete.ch/hdm/223015b](https://git.librete.ch/hdm/223015b)
+
+---
+
+## Ü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
+
+| # | Datum | Thema |
+|---|-------|-------|
+| 1 | 19.12.2025 | Grundlagen, Text & Audio |
+| 2 | 09.01.2026 | Bild- & Videoformate |
+| 3 | 23.01.2026 | Speichermedien & Schnittstellen |
+| 4 | 30.01.2026 | Distribution, APIs & Zukunft |
+| 5 | TBA | Vertiefung & offene Fragen |
+
+### Kompetenzen
+
+In dieser Veranstaltung erwerben Sie 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
+
+**Dozent:** Michael Czechowski · michael.czechowski@lehre.dhbw-stuttgart.de
+
+---
+
+## Slides erstellen
### Basic Slide Structure
diff --git a/index.md b/index.md
deleted file mode 100644
index 66e81f3..0000000
--- a/index.md
+++ /dev/null
@@ -1,4135 +0,0 @@
----
-marp: true
-theme: gaia
-paginate: true
-backgroundColor: #fff
-header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
-footer: "Michael Czechowski – HdM Stuttgart – SoSe 2025"
-title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
----
-
-
-
-
-
-
-
----
-
-# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
-
-Medienwissenschaften
-Hochschule der Medien Stuttgart
-
-**Michael Czechowski**
-Wintersemester 2025/26
-
----
-
-# Kursübersicht
-
-**Ziel:** Verstehen, wie digitale Medien technisch funktionieren – von Bits bis zu globalen Distributionsnetzwerken
-
-**10 Wochen:**
-- Wochen 1-4: Formate & Kompression
-- Wochen 5-6: Speicher & Schnittstellen
-- Wochen 7-9: Distribution, APIs & Metadaten
-- Woche 10: Zukunft & Synthese
-
-
-
----
-
-
-
-# Woche 1
-## Von Bits zu Bedeutung
-
----
-
-
-
-# Mysterium
-
-```
-89 50 4E 47 0D 0A 1A 0A
-00 00 00 0D 49 48 44 52
-00 00 01 90 00 00 01 2C
-```
-
-**Was ist das?**
-
-
-
----
-
-# Das Bit
-
-**Kleinste Informationseinheit**
-
-- **0 oder 1**
-- AN oder AUS
-- Strom fließt oder nicht
-
-
-
-
-
----
-
-# Das Byte
-
-**8 Bits = 1 Byte**
-
-```
-0 1 0 0 1 1 0 1
-```
-
-**Wie viele Kombinationen?**
-2⁸ = **256 Möglichkeiten** (0-255)
-
-
-
----
-
-# 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)
-
-
-
-
-
----
-
-# Farben: RGB-Modell
-
-**1 Pixel = 3 Bytes**
-
-- **Rot:** 0-255
-- **Grün:** 0-255
-- **Blau:** 0-255
-
-**Beispiel:**
-`FF 00 00` = Rot
-`00 FF 00` = Grün
-`FF FF FF` = Weiß
-
-
-
-
-
----
-
-# Das Problem: Sprachen
-
-**Die Welt hat mehr als 256 Zeichen!**
-
-- Englisches Alphabet: 52 (A-Z, a-z)
-- + Ziffern: 10 (0-9)
-- + Sonderzeichen: ~30
-
-**≈ 90 Zeichen → passt in 1 Byte**
-
-**Aber:** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 😀
-
-→ **1 Byte reicht nicht!**
-
-
-
----
-
-
-
-
-
----
-
-# Unicode: Ein Standard für alle
-
-**Unicode (1991):**
-Jedes Schriftsystem der Welt
-
-**>150.000 Zeichen:**
-- Latein, Kyrillisch, Arabisch, Chinesisch, Japanisch...
-- Mathematische Symbole, Emoji, historische Schriften
-
-**UTF-8:** Variable Länge (1-4 Bytes pro Zeichen)
-
-
-
----
-
-# Beispiel: Bytes zählen
-
-**Text:** `"Why the fuck braucht 💩 4 Bytes?!"`
-
-```
-W h y → je 1 Byte (4 Bytes)
-t h e → je 1 Byte (4 Bytes)
-f u c k → je 1 Byte (4 Bytes)
- → 1 Byte (Leerzeichen)
-b r a u c h t → je 1 Byte (7 Bytes)
- → 1 Byte
-💩 → 4 Bytes! (0xF0 9F 92 A9)
- → 1 Byte
-4 B y t e s ? ! → je 1 Byte (9 Bytes)
-```
-
-**Gesamt: 37 Bytes**
-
-
-
----
-
-# Hexadezimal: Lesbarkeit
-
-**Binär ist unleserlich:**
-`01001101 01010000 00110011`
-
-**Hexadezimal (Base 16):**
-`4D 50 33` (= "MP3" in ASCII)
-
-**Jede Hex-Ziffer = 4 Bits**
-0-9, A-F (10=A, 11=B, ..., 15=F)
-
-
-
-
-
----
-
-# Magic Numbers
-
-**Dateityp-Identifikation durch erste Bytes**
-
-| Format | Magic Number (Hex) | ASCII |
-|--------|-------------------|-------|
-| PNG | `89 50 4E 47 0D 0A 1A 0A` | `.PNG` |
-| JPEG | `FF D8 FF` | `ÿØÿ` |
-| PDF | `25 50 44 46` | `%PDF` |
-| ZIP | `50 4B 03 04` | `PK` |
-
-
-
----
-
-
-
-
-
----
-
-# Hands-On: Mystery Files
-
-**Aufgabe (30 Min):**
-
-1. Drei Dateien ohne Extension: `mystery1`, `mystery2`, `mystery3`
-2. Öffne im Hex-Editor
-3. Lies erste 16 Bytes
-4. Identifiziere Format (Magic Number)
-5. Benenne um und öffne
-
-**Tools:** hexed.it (online), HxD, Hex Fiend, Bless
-
-
-
----
-
-# Aufgabe bis nächste Woche
-
-**Finde eine Datei auf deinem Computer**
-
-1. Öffne im Hex-Editor
-2. Screenshot der ersten 16 Bytes
-3. Identifiziere Magic Number
-4. Poste im Forum: Format + kurze Beschreibung
-
-**Bonus:** Finde Datei ohne Magic Number in Standard-Listen
-
-
-
----
-
-
-
-# Woche 2
-## Kompression I: Die MP3-Revolution
-
----
-
-
-
-
-
----
-
-# Das Problem (1990)
-
-**1 Minute CD-Audio:**
-
-- Sample Rate: 44.100 Hz
-- Bit Depth: 16 Bit
-- Stereo: 2 Kanäle
-
-**Rechnung:**
-44.100 × 16 × 2 = 1.411.200 Bits/Sekunde
-≈ **10,6 MB/Minute**
-≈ **635 MB für 60-Min-Album**
-
-**1990:** Festplatten hatten 100-500 MB!
-
-
-
----
-
-# Zwei Philosophien
-
-
-
-**Lossless (Verlustfrei):**
-- Original exakt wiederherstellbar
-- ZIP, PNG, FLAC
-- 30-50% Ersparnis
-
-**Lossy (Verlustbehaftet):**
-- Daten irreversibel verändert
-- JPEG, MP3, H.264
-- 90%+ Ersparnis
-
-
-
----
-
-# Lossless: Run-Length Encoding
-
-**Original:**
-```
-AAAAABBBCCCCCCCC
-```
-
-**Komprimiert:**
-```
-5A 3B 8C
-```
-
-**Ersparnis:** 16 → 6 Zeichen (62% Reduktion)
-
-
-
----
-
-# Lossy: Der Trick
-
-**Kernidee:** Wirf weg, was der Mensch eh nicht wahrnimmt
-
-**JPEG:** Schwächen des Auges
-- Helligkeit besser als Farbe wahrgenommen
-- Große Flächen besser als feine Details
-
-**MP3:** Schwächen des Ohrs
-- Mittlere Frequenzen besser als hohe/tiefe
-- Laute Töne "maskieren" leise Töne
-
-→ **Psychoakustik / Psychovisuell**
-
-
-
----
-
-
-
-
-
----
-
-# Die Geburt der MP3
-
-**1982:** Universität Erlangen-Nürnberg
-Karlheinz Brandenburg, Diplom-Ingenieur
-
-**1987:** Fraunhofer IIS entwickelt MPEG-1 Audio Layer III
-
-**1988:** Patentanmeldung
-
-**1992:** Erste Software-Implementierung
-
-**1995:** .mp3 Dateiendung offiziell
-
-
-
----
-
-
-
-
-
----
-
-# "Tom's Diner"
-
-**Warum dieser Song?**
-
-- A cappella (keine Instrumente)
-- Suzanne Vegas Stimme ist "schwierig"
-- Klare, hohe Frequenzen → Stresstest
-
-*"If I could code Suzanne Vega's voice well, I could code anything."*
-— Karlheinz Brandenburg
-
-
-
----
-
-# Wie funktioniert MP3?
-
-**1. Frequenz-Analyse (FFT)**
-Audio → Frequenzspektrum
-
-**2. Psychoakustisches Modell**
-Welche Töne hört Mensch nicht?
-
-**3. Quantisierung**
-Unwichtige Frequenzen reduzieren
-
-**4. Huffman-Coding**
-Lossless-Kompression der Restdaten
-
-
-
----
-
-# Bitrate: Der Qualitäts-Knopf
-
-| Bitrate | Qualität | Kompression |
-|---------|----------|-------------|
-| **128 kbps** | Hörbar schlechter | ~11x |
-| **192 kbps** | Akzeptabel | ~7x |
-| **256 kbps** | Gut | ~5,5x |
-| **320 kbps** | "CD-Qualität" | ~4,4x |
-
-**Original CD:** 1.411 kbps (unkomprimiert)
-
-
-
----
-
-
-
-
-
----
-
-# Der Patentkrieg
-
-**1990er:** Fraunhofer + Thomson halten MP3-Patente
-
-**Lizenzgebühren:**
-- $0,75 pro Decoder
-- $2,50 pro Encoder
-
-**Problem:** Napster (1999) → unkontrollierte Verbreitung
-
-**2017:** Patente laufen aus → MP3 ist frei
-
-
-
----
-
-
-
-
-
----
-
-# Napster & Musikindustrie
-
-**1999:** Napster startet
-**2001:** 80 Millionen User
-
-**Musikindustrie:**
-- CDs kosten $15-20
-- MP3s gratis (illegal, aber egal)
-- Einzelne Songs statt Alben
-
-**2001:** Napster verklagt, geschlossen
-
-**Aber:** Pandora's Box offen
-→ LimeWire, Kazaa, BitTorrent, später Spotify
-
-
-
----
-
-# Kulturelle Revolution
-
-**MP3 veränderte:**
-
-✓ Musik wurde portabel (Walkman → iPod)
-✓ Alben wurden irrelevant (Playlists)
-✓ Musikkonsum explodierte (kostenlos/billig)
-✓ Künstler verloren Kontrolle
-
-**Aber auch:**
-❌ Künstler verdienen weniger pro Stream
-❌ Audio-Qualität sank (Loudness War)
-❌ Physische Medien starben
-
-
-
----
-
-# Hands-On: MP3 sezieren
-
-**Aufgabe (30 Min):**
-
-1. Lade Lied runter (eigenes oder CC)
-2. Konvertiere in verschiedene Bitraten:
- - 320 kbps, 128 kbps, 64 kbps
-3. Tool: Audacity (kostenlos)
-4. Höre Unterschiede (Kopfhörer!)
-5. Vergleiche Dateigrößen
-
-**Optional:** Spektrogramm-Ansicht
-
-
-
----
-
-# Aufgabe bis nächste Woche
-
-**Nimm ein Lied (eigenes oder CC)**
-
-1. Exportiere: WAV, MP3 320 kbps, MP3 128 kbps
-2. Notiere: Dateigrößen, Höreindrücke
-3. Poste im Forum: Screenshot + Reflexion
-
-**Bonus:** Niedrigste Bitrate finden, bei der du keinen Unterschied hörst
-
-
-
----
-
-
-
-# Woche 3
-## Kompression II: Bilder & JPEG
-
----
-
-
-
-
-
----
-
-# Was ist ein Bild?
-
-**Digital = Pixelraster**
-
-**Beispiel: 1920×1080 (Full HD)**
-= 2.073.600 Pixel
-
-**Jedes Pixel = 3 Bytes (RGB)**
-2.073.600 × 3 = **6,2 MB**
-
-**Für EIN Foto!**
-
-
-
----
-
-# Lossless: PNG
-
-**PNG = Portable Network Graphics (1996)**
-
-**Funktionsweise:**
-- Vorhersage (Pixel ähneln Nachbarn)
-- Differenz-Encoding
-- DEFLATE-Algorithmus (wie ZIP)
-
-**Kompression:** 20-50% Ersparnis
-
-**Gut für:** Screenshots, Logos, Text
-**Schlecht für:** Fotos
-
-
-
----
-
-# Lossy: JPEG
-
-**JPEG = Joint Photographic Experts Group (1992)**
-
-**Eigenschaften:**
-- Lossy Kompression
-- 90%+ Platzersparnis möglich
-- Artefakte bei hoher Kompression
-
-**6 MB → 500 KB** (typisch)
-
-
-
----
-
-
-
-
-
----
-
-# Wie funktioniert JPEG? (1/2)
-
-**Schritt 1: RGB → YCbCr**
-- Y = Helligkeit (Luminanz)
-- Cb/Cr = Farbe (Chrominanz)
-
-**Warum?** Menschen sehen Helligkeit besser als Farbe
-
-**Schritt 2: Chroma Subsampling**
-Farbauflösung reduzieren (4:2:0)
-→ 50% Datenmenge weg, kaum sichtbar
-
-
-
----
-
-# Wie funktioniert JPEG? (2/2)
-
-**Schritt 3: DCT (Discrete Cosine Transform)**
-Bild in 8×8-Blöcke → Frequenzspektrum
-
-**Schritt 4: Quantisierung**
-Hohe Frequenzen (Details) stark reduzieren
-→ **Hier passiert Datenverlust!**
-
-**Schritt 5: Huffman-Coding**
-Lossless-Kompression der Restdaten
-
-
-
----
-
-# JPEG Quality
-
-| Quality | Dateigröße | Artefakte |
-|---------|------------|-----------|
-| **100** | ≈2-3 MB | Kaum |
-| **85-90** | ≈200-400 KB | Minimal |
-| **50** | ≈100 KB | Sichtbar |
-
-**Sweet Spot: 85-90**
-10x Kompression, für Menschen kaum unterscheidbar
-
-
-
----
-
-
-
-
-
----
-
-# Die GIF-Geschichte
-
-**GIF = Graphics Interchange Format (1987)**
-CompuServe (US-Online-Dienst)
-
-**Features:**
-- 256 Farben max (8-bit Palette)
-- Lossless (für Palette)
-- Animationen!
-
-**1994 Twist:** Unisys hält Patent auf LZW-Kompression
-→ Fordert Lizenzgebühren
-
-→ **"Burn All GIFs!" Kampagne**
-
-
-
----
-
-# PNG vs. GIF
-
-**GIF:**
-✓ Animationen
-✓ Breite Unterstützung
-❌ Nur 256 Farben
-❌ Patent-Probleme (bis 2003)
-
-**PNG:**
-✓ Millionen Farben
-✓ Alpha-Transparenz
-✓ Patent-frei
-❌ Keine Animationen (bis APNG, 2004)
-
-**Ergebnis:** PNG für Grafiken, GIF für Memes!
-
-
-
----
-
-# WebP & AVIF
-
-**WebP (Google, 2010):**
-- Lossy UND Lossless
-- Animationen
-- 25-35% kleiner als JPEG
-
-**AVIF (2019):**
-- Basiert auf AV1-Video-Codec
-- 50% kleiner als JPEG
-- HDR-Unterstützung
-- Patent-frei
-
-**Problem:** Browser-Support dauert Jahre
-
-
-
----
-
-
-
-
-
----
-
-# Warum Instagram eure Fotos "ruiniert"
-
-**Upload-Pipeline:**
-1. Dein Foto: 12 MP, 8 MB
-2. Instagram skaliert: max. 1080px
-3. Re-Kompression: JPEG Quality ~75
-4. Endgröße: 200-400 KB
-
-**Warum?**
-- Speicherkosten (Milliarden Fotos!)
-- Ladezeiten (Mobile)
-- Bandbreite (günstiger)
-
-
-
----
-
-# Hands-On: Kompression vergleichen
-
-**Aufgabe (40 Min):**
-
-1. Hochauflösendes Foto (eigenes oder CC)
-2. Exportiere:
- - PNG
- - JPEG Q100, Q85, Q50
- - WebP (optional)
-3. Tool: **Squoosh.app** (Google-Tool)
-4. Vergleiche: Dateigrößen, sichtbare Unterschiede
-5. Wo werden Artefakte sichtbar?
-
-
-
----
-
-# 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?
-
-**Bonus:** Teste WebP oder AVIF
-
-
-
----
-
-
-
-# Woche 4
-## Video-Kompression & Codecs
-
----
-
-
-
-
-
----
-
-# Das Problem: Video ist RIESIG
-
-**1 Minute 4K-Video (3840×2160):**
-
-- 30 fps (Bilder/Sekunde)
-- Jedes Bild: 24,8 MB (unkomprimiert)
-
-**Rechnung:**
-30 × 24,8 MB = **744 MB/Sekunde**
-× 60 Sekunden = **44,6 GB/Minute**
-
-**2-Stunden-Film: 5,3 TB!**
-
-
-
----
-
-# Container vs. Codec
-
-**Container = Die Box**
-Verpackt Video, Audio, Untertitel, Metadaten
-
-**Beispiele:** MP4, MKV, AVI, MOV
-
-**Codec = Kompressionsalgorithmus**
-Entscheidet, WIE Daten komprimiert werden
-
-**Video-Codecs:** H.264, H.265, VP9, AV1
-**Audio-Codecs:** AAC, MP3, Opus
-
-
-
----
-
-
-
-
-
----
-
-# Video-Kompression: Drei Prinzipien
-
-**1. Spatial Compression (Intra-Frame)**
-Jedes Bild einzeln (wie JPEG)
-→ I-Frames
-
-**2. Temporal Compression (Inter-Frame)**
-Nur Änderungen zwischen Bildern
-→ P-Frames, B-Frames
-
-**3. Motion Compensation**
-"Ball bewegt sich von A nach B"
-
-
-
----
-
-# I-Frames, P-Frames, B-Frames
-
-**I-Frame (Intra):**
-Vollständiges Bild (wie JPEG)
-Groß, aber unabhängig
-
-**P-Frame (Predicted):**
-Referenziert vorherige Frames
-Viel kleiner
-
-**B-Frame (Bi-directional):**
-Referenziert vorherige UND zukünftige Frames
-Am effizientesten
-
-**GOP:** I - B - B - P - B - B - P - B - B - I
-
-
-
----
-
-
-
-
-
----
-
-# H.264: Der König
-
-**H.264 / AVC (2003)**
-
-**Warum dominant?**
-✓ Exzellente Kompression (100:1 möglich)
-✓ Hardware-Support (jedes Gerät seit ~2010)
-✓ YouTube, Netflix, Blu-ray – alles H.264
-
-**Features:**
-- Variable Block-Größen (16×16 bis 4×4)
-- Deblocking-Filter
-- CABAC-Coding
-
-
-
----
-
-# Das Patent-Problem
-
-**H.264 ist NICHT frei!**
-
-**MPEG-LA (Patent Pool):**
-- 2.000+ Patente von ~30 Unternehmen
-- Apple, Microsoft, Sony, Panasonic...
-
-**Lizenzgebühren:**
-- Hardware-Decoder: $0,20/Einheit
-- Content-Distribution: Kostenlos für "Internet Broadcast"
-
-**Problem:** Open-Source-Projekte in Grauzone
-
-
-
----
-
-# H.265 / HEVC
-
-**H.265 (2013):**
-50% bessere Kompression als H.264
-
-**ABER:** Patent-Desaster
-
-**Drei (!) konkurrierende Patent-Pools:**
-- MPEG-LA
-- HEVC Advance
-- Velos Media
-
-→ Viele bleiben bei H.264 oder suchen Alternativen
-
-
-
----
-
-
-
-
-
----
-
-# VP9: Googles Antwort
-
-**VP9 (2013):**
-Entwickelt von Google (On2-Akquisition)
-
-**Eigenschaften:**
-✓ Ähnlich H.265-Kompression
-✓ KOSTENLOS, patent-frei (laut Google)
-✓ YouTube nutzt VP9 für 4K
-
-**Nachteile:**
-❌ Hardware-Support langsam
-❌ Höherer CPU-Aufwand
-❌ Nicht universell wie H.264
-
-
-
----
-
-
-
-
-
----
-
-# AV1: Die Open-Source-Revolution
-
-**AV1 (2018):**
-Alliance for Open Media: Google, Netflix, Amazon, Microsoft, Apple, Mozilla...
-
-**Ziel:** Patent-freier, moderner Codec
-
-**Features:**
-✓ 30% besser als H.265
-✓ Royalty-free, Open Source
-✓ 8K, HDR, hohe Frame-Rates
-
-**Stand 2025:**
-YouTube, Netflix nutzen AV1 für 4K/8K
-
-
-
----
-
-# Adaptive Bitrate Streaming
-
-**Problem:** Internet-Geschwindigkeit variiert
-
-**Lösung:** Mehrere Qualitäten parallel
-
-**MPEG-DASH / HLS:**
-- 4K (20 Mbps)
-- 1080p (5 Mbps)
-- 720p (2,5 Mbps)
-- 480p (1 Mbps)
-- 240p (0,5 Mbps)
-
-Segmente: 2-10 Sekunden
-Player wählt dynamisch
-
-
-
----
-
-
-
-
-
----
-
-# Container im Detail
-
-**MP4:**
-- Standard für Web, Mobile
-- H.264, H.265, AV1
-- DRM-fähig
-
-**MKV (Matroska):**
-- Open Source, extrem flexibel
-- Beliebig viele Audio-/Untertitel-Spuren
-- Fast jeden Codec
-
-**WebM:**
-- Google, Web-optimiert
-- Nur VP9/AV1 + Opus/Vorbis
-
-
-
----
-
-# Hands-On: Video analysieren
-
-**Aufgabe (40 Min):**
-
-**Tool:** FFmpeg (CLI) oder HandBrake (GUI)
-
-1. Download: CC-Video (Big Buck Bunny, ~1 Min)
-2. Analysiere: `ffmpeg -i video.mp4` oder MediaInfo
-3. Notiere: Container, Codec, Bitrate, Auflösung
-4. Konvertiere:
- - H.264, 1080p, 5 Mbps
- - H.265, 1080p, 2,5 Mbps
-5. Vergleiche: Größen, Encoding-Zeit, Qualität
-
-
-
----
-
-# 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?
-
-**Bonus:** AV1-Encoding (Warnung: SEHR langsam!)
-
-
-
----
-
-
-
-# Woche 5
-## Speichermedien, Dateisysteme & Backup
-
----
-
-
-
-
-
----
-
-# Rückblick: HDD vs. SSD
-
-**HDD:**
-- Mechanisch, magnetisch
-- Langsam (~150 MB/s)
-- Günstig (~20€/TB)
-- Empfindlich (Stöße!)
-
-**SSD:**
-- Elektronisch, Flash
-- Schnell (~500-7.000 MB/s)
-- Teuer (~80-150€/TB)
-- Write-Zyklen begrenzt
-
-
-
----
-
-# Was fehlt? Dateisysteme!
-
-**Dateisystem = Bibliothekskatalog für Festplatte**
-
-**Aufgaben:**
-- Dateien speichern & finden
-- Metadaten verwalten
-- Speicherplatz effizient nutzen
-- Fehler erkennen & beheben
-
-
-
----
-
-
-
-
-
----
-
-# Partitionen & Volumes
-
-**Partition:**
-Zusammenhängender Bereich auf Festplatte
-
-**Volume:**
-Logische Einheit mit Dateisystem
-
-**Beispiel:**
-1 TB HDD → 2 Partitionen
-- 500 GB Windows (NTFS)
-- 500 GB Daten (exFAT)
-
-
-
----
-
-# Formatierung
-
-**Schnellformatierung:**
-- Löscht nur Metadaten
-- Daten physisch noch da
-- → Datenrettung möglich!
-
-**Vollständige Formatierung:**
-- Überschreibt mit Nullen
-- Dauert länger, aber sicherer
-
-
-
----
-
-# FAT (File Allocation Table)
-
-**Geschichte:** 1977, Microsoft
-
-**Versionen:**
-- FAT16: Max. 2 GB
-- FAT32: Max. 4 GB Dateien, 2 TB Partitionen
-- exFAT: Keine 4 GB-Grenze
-
-**Vorteil:** Universelle Kompatibilität
-
-**Nachteil:** Keine Rechte, kein Journaling
-
-
-
----
-
-# NTFS
-
-**NTFS = New Technology File System (1993)**
-
-**Features:**
-✓ Dateien >4 GB (bis 16 EB)
-✓ Zugriffsrechte (ACLs)
-✓ Journaling (Crash-Schutz)
-✓ Kompression & Verschlüsselung
-✓ Shadow Copies
-
-**Nachteil:** Proprietär (nur Windows nativ)
-
-
-
----
-
-# APFS
-
-**Apple File System (2017)**
-
-**Features:**
-✓ Copy-on-Write (Speicherersparnis!)
-✓ Snapshots (Time Machine)
-✓ Native Verschlüsselung
-✓ SSD-optimiert
-
-**Nachteil:** Nur Apple-Geräte
-
-
-
----
-
-# ext4
-
-**Fourth Extended File System (2008)**
-Linux-Standard
-
-**Features:**
-✓ Journaling
-✓ Extents (schneller)
-✓ Max. 16 TB Dateien, 1 EB Partitionen
-✓ Online-Defragmentierung
-
-**Nachteil:** Windows/macOS können nicht nativ lesen
-
-
-
----
-
-# Dateisysteme: Vergleich
-
-| FS | OS | Max. Datei | Features |
-|----|----|-----------:|----------|
-| FAT32 | Alle | 4 GB | Kompatibilität |
-| exFAT | Alle | 16 EB | Flash-optimiert |
-| NTFS | Win | 16 EB | Journaling, ACLs |
-| APFS | macOS | 8 EB | Snapshots, CoW |
-| ext4 | Linux | 16 TB | Journaling |
-
-
-
----
-
-
-
-
-
----
-
-# Backup: Warum?
-
-**Realität:**
-- Festplatten sterben ohne Vorwarnung
-- Ransomware verschlüsselt Daten
-- Versehentliches Löschen
-- Diebstahl, Brand, Wasserschaden
-
-**Faustregel: 3-2-1**
-Mindestens 3 Kopien, auf mindestens 2 unterschiedlichen Speichermedien und mindestens 1 an einem anderen Ort
-
-
-
----
-
-# Backup-Arten
-
-**Vollständig (Full):**
-Kompletter Datenbestand
-Langsam, aber einfach
-
-**Inkrementell:**
-Nur Änderungen seit letztem Backup
-Schnell, aber Wiederherstellung komplex
-
-**Differenziell:**
-Änderungen seit letztem Voll-Backup
-Mittelweg
-
-
-
----
-
-# 3-2-1-Regel
-
-**3** Kopien (Original + 2 Backups)
-
-**2** verschiedene Medientypen (SSD + HDD)
-
-**1** Offsite-Backup (Cloud, externes Lager)
-
-**Beispiel:**
-Laptop + externe Festplatte + Cloud
-
-
-
----
-
-# Backup-Software
-
-**macOS:** Time Machine
-**Windows:** Veeam Agent (kostenlos)
-**Linux:** rsync, Borg, Restic
-**Plattformübergreifend:** Duplicati, Syncthing
-**Cloud:** Backblaze, Nextcloud
-
-
-
----
-
-
-
-
-
----
-
-# Langzeitarchivierung: Das Problem
-
-**Digitale Daten altern:**
-- Bit Rot (Degradation)
-- Format-Obsoleszenz (WordPerfect .wpd)
-- Hardware-Obsoleszenz (Diskettenlaufwerke)
-
-**Lösung:**
-Migration + offene Standards
-
-
-
----
-
-
-
-
-
----
-
-# Magnetbänder (LTO)
-
-**Linear Tape-Open:**
-
-- LTO-9 (2021): 18 TB nativ, 45 TB komprimiert
-- Haltbarkeit: 30 Jahre
-- Kosten: ~5€/TB (Laufwerk ~5.000€)
-- Nutzung: Rechenzentren, Archive
-
-**Air-Gap-Sicherheit:**
-Offline-Band kann nicht von Ransomware verschlüsselt werden
-
-
-
----
-
-
-
-
-
----
-
-# M-DISC (Millennial Disc)
-
-**Eigenschaften:**
-- DVD/Blu-ray-kompatibel
-- Anorganische Metallschicht
-- Haltbarkeit: 1.000 Jahre (Tests)
-- Einsatz: Familienfotos, Archive
-
-
-
----
-
-
-
-
-
----
-
-# DNA-Storage (Zukunft)
-
-**Konzept:** Daten in DNA-Sequenzen
-
-**Eigenschaften:**
-- Speicherdichte: 215 Petabyte/Gramm (!!)
-- Haltbarkeit: Tausende Jahre
-- Kosten: Aktuell $3.500/MB
-
-**Beispiele:**
-Microsoft + Twist Bioscience
-Netflix "Biohackers"-Episode (2021)
-
-
-
----
-
-# Hands-On: S.M.A.R.T. & Backup
-
-**Aufgabe 1 (20 Min):**
-S.M.A.R.T.-Daten auslesen
-- Windows: CrystalDiskInfo
-- macOS/Linux: `smartctl -a /dev/sda`
-- Notiere: Health, Power-On Hours, Temp
-
-**Aufgabe 2 (20 Min):**
-Test-Backup erstellen
-- rsync (Linux/macOS) oder Robocopy (Windows)
-- Simuliere Datenverlust → Wiederherstellung
-
-
-
----
-
-# 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
-
-**Bonus:** Richte automatisches Backup ein
-
-
-
----
-
-
-
-# Woche 6
-## Schnittstellen: USB-C-Chaos & HDMI-Kriege
-
----
-
-
-
-
-
----
-
-# Was ist eine Schnittstelle?
-
-**Schnittstelle = Verbindung zwischen Systemen**
-
-**Hardware-Schnittstellen:**
-Physischer Anschluss (USB, HDMI, Ethernet)
-
-**Software-Schnittstellen:**
-API (nächste Woche!)
-
-**Heute:** Hardware-Fokus
-
-
-
----
-
-
-
-
-
----
-
-# USB: Die Idee
-
-**Universal Serial Bus (1996)**
-
-**Ziel:** Ein Kabel für alles
-
-**Vorher:**
-- PS/2 (Maus, Tastatur)
-- Seriell (Modem)
-- Parallel (Drucker)
-- SCSI (Festplatten)
-
-**USB-Versprechen:**
-✓ Ein Stecker, Hot-Pluggable, Stromversorgung
-
-
-
----
-
-# USB-Versionen: Chaos
-
-| Version | Jahr | Geschwindigkeit | Marketing-Name |
-|---------|------|----------------:|----------------|
-| USB 1.0 | 1996 | 12 Mbps | – |
-| USB 2.0 | 2000 | 480 Mbps | Hi-Speed |
-| USB 3.0 | 2008 | 5 Gbps | USB 3.2 Gen 1 |
-| USB 3.1 | 2013 | 10 Gbps | USB 3.2 Gen 2 |
-| USB 3.2 | 2017 | 20 Gbps | USB 3.2 Gen 2×2 |
-| USB 4 | 2019 | 40 Gbps | USB4 |
-
-**NIEMAND versteht das mehr!**
-
-
-
----
-
-
-
-
-
----
-
-# USB-C: Stecker ≠ Geschwindigkeit
-
-**USB-C = Physischer Stecker (2014)**
-
-**Eigenschaften:**
-✓ Reversibel (beide Seiten gleich)
-✓ 24 Pins (vs. 4 bei USB-A)
-✓ Unterstützt: Daten, Strom, Video, Audio
-
-**ABER:** USB-C sagt NICHTS über Geschwindigkeit!
-
-Ein USB-C-Kabel kann sein:
-- USB 2.0 (480 Mbps) 😱
-- USB 3.2 Gen 2 (10 Gbps)
-- USB 4 (40 Gbps)
-- Thunderbolt 3/4 (40 Gbps)
-- Oder nur Power Delivery (Laden, keine Daten!)
-
-
-
----
-
-# USB Power Delivery
-
-**USB PD (über USB-C):**
-
-- Profile: 5V bis 20V
-- Max. 5A
-- Bis zu **240W** (USB PD 3.1, 2021)
-
-**Anwendungen:**
-- Laptop-Ladung (60-100W)
-- Monitor mit Stromversorgung
-- Docking-Stations
-
-**Problem:** Nicht jedes Kabel unterstützt volles PD!
-
-
-
----
-
-# USB-C: Das Wirrwarr
-
-**Was ein USB-C-Kabel KÖNNEN KANN:**
-
-**Daten:** USB 2.0 bis USB4 (40 Gbps)
-
-**Strom:** 5W bis 240W
-
-**Video:** DisplayPort Alt Mode, HDMI Alt Mode
-
-**Audio:** USB Audio Class
-
-**Problem:** Am Kabel steht's oft NICHT drauf!
-
-
-
----
-
-
-
-
-
----
-
-# Thunderbolt: Premium-Schnittstelle
-
-**Thunderbolt (Intel + Apple):**
-
-- Thunderbolt 3/4 (2015/2020): USB-C, 40 Gbps
-- **PCIe über Kabel** → externe GPUs!
-- Daisychaining (bis 6 Geräte)
-- 100W Power Delivery garantiert
-
-**Nachteile:**
-❌ Teuer (Kabel: 30-80€)
-❌ Lizenzgebühren (Intel)
-❌ Nur High-End-Geräte
-
-
-
----
-
-
-
-
-
----
-
-# HDMI: Der Heimkino-Standard
-
-**HDMI (2002):**
-Entwickelt von Sony, Panasonic, Toshiba...
-
-**Versionen:**
-- HDMI 1.4 (2009): 4K @ 30 Hz, ARC
-- HDMI 2.0 (2013): 4K @ 60 Hz, HDR
-- HDMI 2.1 (2017): 8K @ 60 Hz, 4K @ 120 Hz, VRR
-
-**Features:**
-✓ Audio + Video in einem Kabel
-✓ HDCP (Copy Protection)
-✓ CEC (Gerätesteuerung)
-
-**Nachteile:**
-❌ Proprietär, Lizenzgebühren
-❌ Keine Daisychaining
-
-
-
----
-
-
-
-
-
----
-
-# DisplayPort: Die PC-Alternative
-
-**DisplayPort (2006):**
-VESA (Video Electronics Standards Association)
-
-**Versionen:**
-- DP 1.4 (2016): 8K @ 60 Hz, HDR
-- DP 2.0 (2019): 16K @ 60 Hz, 8K @ 120 Hz
-
-**Vorteile:**
-✓ Lizenzfrei (keine Gebühren!)
-✓ Daisychaining (Multi-Monitor)
-✓ Adaptive Sync (FreeSync, G-Sync)
-✓ USB-C Alt Mode
-
-**Nachteil:** Weniger verbreitet in TVs
-
-
-
----
-
-# HDMI vs. DisplayPort
-
-| Feature | HDMI 2.1 | DisplayPort 2.0 |
-|---------|----------|-----------------|
-| **Max. Auflösung** | 8K @ 60 Hz | 16K @ 60 Hz |
-| **Lizenz** | Ja (~$10k/Jahr) | Nein |
-| **Daisychaining** | Nein | Ja |
-| **Adaptive Sync** | VRR (neu) | Ja (nativ) |
-| **USB-C** | Alt Mode (selten) | Alt Mode (häufig) |
-| **Verbreitung** | TVs dominant | PCs/Monitore |
-
-
-
----
-
-
-
-
-
----
-
-# HDCP: Copy Protection
-
-**HDCP = High-bandwidth Digital Content Protection**
-
-**Was ist das?**
-- DRM für Video-Signale
-- Verschlüsselt zwischen Quelle und Display
-- Verhindert "Man-in-the-Middle"-Aufnahme
-
-**Problem:**
-- Alte Monitore: Kein HDCP 2.2 → 4K-Netflix funktioniert nicht!
-- Capture-Cards oft blockiert
-- "HDCP-Handshake-Fehler" → Schwarzer Bildschirm
-
-**Kritik:** Schikaniert ehrliche Nutzer, Piraten umgehen es leicht
-
-
-
----
-
-
-
-
-
----
-
-# Ethernet: Das Netzwerkkabel
-
-**Ethernet (1980er):**
-
-**Versionen:**
-- 100BASE-TX (1995): 100 Mbps
-- 1000BASE-T (1999): 1 Gbps (Gigabit)
-- 10GBASE-T (2006): 10 Gbps
-
-**Kabel-Kategorien:**
-- Cat5e: bis 1 Gbps (veraltet)
-- Cat6: bis 10 Gbps (55m)
-- Cat6a: bis 10 Gbps (100m)
-
-**Stecker:** RJ45 (8P8C)
-
-
-
----
-
-
-
-
-
----
-
-# Veraltete Schnittstellen
-
-**Seriell (RS-232):** 1960er, 115,2 kbps, Modems
-**Parallel (LPT):** Drucker, 8 Bits gleichzeitig
-**PS/2:** Maus + Tastatur (1987-2010er)
-**VGA:** Analoges Video (1987-2010er)
-
-**Heute:** Manchmal noch auf Mainboards (Legacy-Support)
-
-
-
----
-
-# Hands-On: Schnittstellen identifizieren
-
-**Aufgabe (30 Min):**
-
-1. Untersuche deinen Laptop/Desktop
-2. Welche Anschlüsse vorhanden?
-3. Für USB-C: Welche Features? (Daten, Video, Laden?)
-4. Teste: Schließe Gerät an verschiedenen Ports an
-5. Dokumentiere: Foto + Beschriftung
-
-**Tools:** Systeminfo (Win), System Report (Mac), lsusb (Linux)
-
-
-
----
-
-# 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
-
-**Bonus:** Finde USB-C-Kabel, das nur USB 2.0 kann
-
-
-
----
-
-
-
-# Woche 7
-## Distributionswege: CDN, P2P & Streaming
-
----
-
-
-
-
-
----
-
-# Das Problem: Daten müssen reisen
-
-**Szenario:** 100 TB von Berlin nach München
-
-**Option 1: Internet-Upload**
-- 1 Gbps Uplink = 125 MB/s
-- Zeit: **9,3 Tage** (non-stop!)
-
-**Option 2: Festplatte per Post**
-- 10× 10TB HDDs (~2.000€)
-- Kopieren: ~10 Stunden
-- Versand: 1-2 Tage
-- Gesamt: **~3 Tage**
-
-*"Never underestimate the bandwidth of a station wagon full of tapes."* — Andrew Tanenbaum (1981)
-
-
-
----
-
-
-
-
-
----
-
-# AWS Snowball
-
-**AWS Snowball (seit 2015):**
-
-**Problem:** Petabytes on-premise → AWS-Cloud
-
-**Geräte:**
-- Snowball Edge: 100 TB
-- **Snowmobile:** 100 PB (Container auf LKW!)
-
-**Prozess:**
-1. AWS schickt verschlüsseltes Gerät
-2. Kunde kopiert Daten lokal (schnell!)
-3. Gerät zurück an AWS
-4. AWS lädt in S3 hoch
-
-**Kosten:** Günstiger als Internet-Transfer bei >10 TB
-
-
-
----
-
-
-
-
-
----
-
-# Physische Distribution
-
-**CD (1982):** 700 MB
-**DVD (1995):** 4,7 GB / 8,5 GB
-**Blu-ray (2006):** 25 GB / 50 GB / 100 GB
-
-**Problem heute:**
-- Games: 50-150 GB (Call of Duty: 200+ GB!)
-- Filme: Streaming überholt Blu-ray
-- Disc = "License Key", Rest wird geladen
-
-
-
----
-
-
-
-
-
----
-
-# Zentralisierte Distribution
-
-**Klassisches Modell:** Ein Server, viele Clients
-
-**Problem:**
-1 Million User wollen 1 GB-Datei
-→ Server braucht **1 PB Bandbreite!**
-→ Server überlastet → **"Hug of Death"**
-
-**Lösung:** Content Delivery Networks (CDNs)
-
-
-
----
-
-
-
-
-
----
-
-# CDNs: Content Delivery Networks
-
-**CDN = Verteiltes Netzwerk weltweit**
-
-**Funktionsweise:**
-1. **Origin Server** (Hauptquelle)
-2. **Edge Servers** (geografisch verteilt)
-3. User → nächster Edge Server
-4. Erste Anfrage: Edge holt von Origin, cached
-5. Weitere Anfragen: Direkt vom Edge (schnell!)
-
-**Vorteile:**
-✓ Reduzierte Latenz (geografische Nähe)
-✓ Last-Verteilung
-✓ Bandbreitenersparnis
-
-
-
----
-
-# CDN-Strategien
-
-**Static Content:**
-- Bilder, CSS, JS, Videos
-- Lange Cache-Zeit (TTL: Tage/Wochen)
-
-**Dynamic Content:**
-- User-spezifisch (Profil)
-- Kurze TTL oder nicht cachebar
-
-**Cache Invalidation:**
-- Versioning (`style.css` → `style.v2.css`)
-- Cache-Purge (manuell leeren)
-
-*"There are only two hard things in Computer Science: cache invalidation and naming things."* — Phil Karlton
-
-
-
----
-
-
-
-
-
----
-
-# Netflix: Fallstudie CDN
-
-**Netflix Open Connect (eigenes CDN):**
-
-**Strategie:**
-- Server IN ISP-Rechenzentren (Telekom, Vodafone...)
-- Popular Content vorgeladen (Predictive Caching)
-- **95%+ Traffic vom lokalen ISP-Server**
-
-**Zahlen (2024):**
-- 200M+ Subscriber
-- ~15% des globalen Internet-Traffics!
-- Ohne CDN: Unmöglich
-
-
-
----
-
-
-
-
-
----
-
-# P2P: Peer-to-Peer
-
-**P2P = Jeder ist Client UND Server**
-
-**Philosophie:** Dezentralisierung
-
-**Anwendungen:**
-- BitTorrent (File-Sharing)
-- IPFS (InterPlanetary File System)
-- Blockchain (Bitcoin, Ethereum)
-
-**Vorteil:** Skalierbar (mehr User = mehr Bandbreite!)
-
-**Nachteil:** Langsam bei wenigen Peers, oft für Piraterie missbraucht
-
-
-
----
-
-
-
-
-
----
-
-# BitTorrent: Wie funktioniert's?
-
-**BitTorrent (Bram Cohen, 2001):**
-
-**Komponenten:**
-1. **.torrent-Datei:** Metadaten (Hashes, Tracker-URL)
-2. **Tracker:** Vermittelt Peers
-3. **Seeders:** Haben komplette Datei
-4. **Leechers:** Laden noch
-5. **Swarm:** Alle Peers zusammen
-
-**Mechanismus:**
-- Datei in Chunks (z.B. 256 KB)
-- Jeder Peer lädt von verschiedenen Peers
-- "Tit-for-tat": Wer uploaded, lädt schneller
-
-
-
----
-
-
-
-
-
----
-
-# BitTorrent & Piraterie
-
-**2000er:** Musik-/Film-Piraterie-Revolution
-
-**Napster (1999-2001):** Zentralisiert → Verklagt, Shutdown
-
-**BitTorrent (2001+):** Dezentral → Schwerer zu verklagen
-
-**The Pirate Bay (2003):** BitTorrent-Index
-- Blockiert, zieht um, neue Domains
-- **Whack-a-Mole-Spiel**
-
-**Rechtliche Grauzone:**
-- Protokoll selbst: Legal
-- Inhalte: Oft illegal (Urheberrecht)
-- Legitime Uses: Linux-ISOs, Open-Source, Public Domain
-
-
-
----
-
-
-
-
-
----
-
-# IPFS: Dezentrales Web?
-
-**IPFS = InterPlanetary File System (2015)**
-
-**Vision:** Web ohne Server
-
-**Funktionsweise:**
-- **Content-Addressable:** Dateien durch Hash identifiziert
-- **CID:** Content Identifier (`QmXyZ123...`)
-- Datei auf vielen Knoten (wie BitTorrent, aber persistent)
-- Abruf: "Gib mir Datei mit Hash X" (egal wo)
-
-**Vorteile:** Zensur-resistent, kein Single Point of Failure
-
-**Nachteile:** Langsam (noch), keine Verfügbarkeitsgarantie
-
-**Anwendung:** NFT-Speicher
-
-
-
----
-
-
-
-
-
----
-
-# Streaming: Real-Time-Distribution
-
-**Streaming = Daten während Empfang konsumiert**
-
-**Protokolle:**
-- **HLS** (Apple): HTTP-basiert, Segmente
-- **MPEG-DASH:** Standard, ähnlich HLS
-- **WebRTC:** Browser-zu-Browser, niedrige Latenz
-
-**Adaptive Bitrate:**
-- Stream in mehreren Qualitäten (240p-4K)
-- Player wechselt dynamisch
-- Segmente: 2-10 Sekunden
-
-**Latenz:**
-- Traditional (HLS): 10-30 Sekunden
-- Low-Latency HLS: 2-5 Sekunden
-- WebRTC: <1 Sekunde (Videocalls)
-
-
-
----
-
-# Hands-On: Torrent & CDN
-
-**Aufgabe (40 Min):**
-
-**Teil 1: BitTorrent (20 Min)**
-1. Lade legalen Torrent (Linux-ISO: ubuntu.com)
-2. Tool: qBittorrent oder Transmission
-3. Beobachte: Peers, Seeders, Download-Speed, Upload-Speed
-
-**Teil 2: CDN-Analyse (20 Min)**
-1. Öffne populäre Website (z.B. nytimes.com)
-2. Browser DevTools → Network-Tab
-3. Schaue auf Requests: Welche CDN-Domains?
-4. Response-Headers: `X-Cache`, `CF-Ray`, etc.
-
-**Tools:** cdn77.com/cdn-check
-
-
-
----
-
-# Aufgabe bis nächste Woche
-
-**Analysiere Streaming-Dienst oder Website:**
-
-1. Wähle: Netflix, YouTube, Spotify, News-Seite
-2. DevTools (Network-Tab):
- - 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
-
-
-
----
-
-
-
-# Woche 8
-## Software-Schnittstellen: APIs & Protokolle
-
----
-
-
-
-
-
----
-
-# Was ist eine API?
-
-**API = Application Programming Interface**
-
-**Analogie: Restaurant**
-- Du (Client) → Speisekarte (API-Dokumentation)
-- Bestellst (Request)
-- Küche bereitet zu (Backend)
-- Kellner bringt Essen (Response)
-- Du weißt nicht, WIE gekocht wird – nur WAS du kriegst
-
-**Typen:** Hardware-APIs, OS-APIs, Web-APIs, Library-APIs
-
-
-
----
-
-
-
-
-
----
-
-# HTTP: Das Fundament
-
-**HTTP = HyperText Transfer Protocol (1991)**
-
-**Request-Struktur:**
-- **Method:** GET, POST, PUT, DELETE
-- **URL:** Resource-Identifier
-- **Headers:** Metadaten (Content-Type, Authorization...)
-- **Body:** Optional (bei POST/PUT)
-
-**Response-Struktur:**
-- **Status Code:** 200 OK, 404 Not Found, 500 Error
-- **Headers:** Metadaten
-- **Body:** HTML, JSON, XML, Binary...
-
-
-
----
-
-# HTTP-Methods: CRUD
-
-**CRUD = Create, Read, Update, Delete**
-
-| Method | CRUD | Beispiel |
-|--------|------|----------|
-| **GET** | Read | `/posts` → Alle Posts |
-| **POST** | Create | `/posts` → Neuer Post |
-| **PUT** | Update | `/posts/42` → Post ersetzen |
-| **PATCH** | Update | `/posts/42` → Teilupdate |
-| **DELETE** | Delete | `/posts/42` → Post löschen |
-
-**GET = Idempotent** (mehrfach ausführen = gleiches Ergebnis)
-
-
-
----
-
-
-
-
-
----
-
-# REST: Representational State Transfer
-
-**REST (Roy Fielding, 2000):**
-
-**Prinzipien:**
-1. **Stateless:** Jede Anfrage eigenständig
-2. **Resource-Based:** URLs = Ressourcen (`/users/123`)
-3. **HTTP-Methods:** CRUD-Operationen
-4. **Hypermedia:** Links zu verwandten Ressourcen
-
-**Beispiel: Twitter-API**
-```
-GET /tweets/123 → Tweet mit ID 123
-POST /tweets → Neuen Tweet erstellen
-DELETE /tweets/123 → Tweet löschen
-GET /users/alice/tweets → Tweets von Alice
-```
-
-
-
----
-
-# REST-Probleme
-
-**Problem 1: Over-Fetching**
-```
-GET /users/123
-→ Gibt zurück: Name, Email, Bio, Avatar,
- Follower-Count, Posts, Friends...
-```
-Du willst nur Name → Kriegst 90% zu viel
-
-**Problem 2: Under-Fetching**
-```
-GET /users/123 → User-Daten
-GET /users/123/posts → Alle Posts
-```
-2 Requests statt einem
-
-**Lösung:** GraphQL
-
-
-
----
-
-
-
-
-
----
-
-# GraphQL: Die REST-Alternative
-
-**GraphQL (Facebook, 2015):**
-
-**Idee:** Client fragt EXAKT, was er braucht
-
-**Query-Beispiel:**
-```graphql
-{
- user(id: 123) {
- name
- email
- posts(limit: 5) {
- title
- createdAt
- }
- }
-}
-```
-
-**Vorteile:**
-✓ Kein Over-/Under-Fetching
-✓ Ein Endpoint (`/graphql`)
-✓ Strongly Typed (Schema!)
-
-
-
----
-
-# GraphQL Schema
-```graphql
-type User {
- id: ID!
- name: String!
- email: String
- posts: [Post!]!
-}
-
-type Post {
- id: ID!
- title: String!
- content: String!
- author: User!
-}
-
-type Query {
- user(id: ID!): User
- posts: [Post!]!
-}
-
-type Mutation {
- createPost(title: String!, content: String!): Post!
-}
-```
-
-**`!` = Required (non-nullable)**
-
-
-
----
-
-
-
-
-
----
-
-# WebSockets: Real-Time
-
-**Problem mit HTTP:**
-- Request-Response-Zyklus
-- Server kann nicht "pushen"
-- Polling ineffizient
-
-**WebSocket (2011):**
-- **Bidirektionale Verbindung**
-- Bleibt offen (Persistent)
-- Server kann jederzeit senden
-
-**Anwendungen:**
-Chat (Discord), Live-Updates (Aktienkurse), Multiplayer-Games
-
-
-
----
-
-# WebSocket: Chat-Beispiel
-
-**Flow:**
-1. Alice öffnet Chat → WebSocket-Connection
-2. Bob öffnet Chat → Eigene Connection
-3. Alice tippt: "Hi Bob!"
-4. Client sendet: `{"type": "message", "text": "Hi Bob!", "to": "bob"}`
-5. Server leitet an Bobs Connection weiter
-6. Bob empfängt, zeigt an
-
-**Kein Polling! Instant!**
-
-
-
----
-
-
-
-
-
----
-
-# gRPC: Google's Approach
-
-**gRPC = Google Remote Procedure Call (2015)**
-
-**Idee:** Funktion auf Remote-Server aufrufen, als wäre es lokal
-
-**Eigenschaften:**
-- **Protocol Buffers (Protobuf):** Binär, kompakt (statt JSON)
-- **HTTP/2:** Multiplexing, Bidirektional
-- **Strongly Typed**
-- **Code-Generierung** (Client/Server aus `.proto`-Datei)
-
-**Vorteile:** Performance, Streaming
-**Nachteile:** Nicht Browser-kompatibel, Debugging schwieriger
-
-
-
----
-
-# gRPC Beispiel
-
-**`.proto`-Datei:**
-```protobuf
-service UserService {
- rpc GetUser (UserRequest) returns (UserResponse);
- rpc ListPosts (Empty) returns (stream Post);
-}
-
-message UserRequest {
- int32 id = 1;
-}
-
-message UserResponse {
- string name = 1;
- string email = 2;
-}
-```
-
-**Code-Generierung:** Client/Server-Code automatisch generiert
-
-
-
----
-
-# JSON: Das Standard-Format
-
-**JSON = JavaScript Object Notation**
-
-**Eigenschaften:**
-- Textbasiert, menschenlesbar
-- Schlüssel-Wert-Paare
-- Unterstützt: Objekte, Arrays, Strings, Numbers, Booleans, null
-
-**Beispiel:**
-```json
-{
- "name": "Alice",
- "age": 28,
- "posts": [
- {"title": "Hello", "views": 42},
- {"title": "World", "views": 123}
- ]
-}
-```
-
-
-
----
-
-# Hands-On: API abfragen
-
-**Aufgabe (40 Min):**
-
-**Teil 1: REST-API (20 Min)**
-1. Öffentliche API: `jsonplaceholder.typicode.com`
-2. Tool: curl (Terminal) oder Postman (GUI)
-3. Beispiele:
-```bash
-curl https://jsonplaceholder.typicode.com/posts/1
-curl -X POST https://jsonplaceholder.typicode.com/posts \
- -H "Content-Type: application/json" \
- -d '{"title":"Test","body":"Hello","userId":1}'
-```
-4. Analysiere: Status-Code, Headers, Body
-
-**Teil 2: WebSocket (20 Min)**
-1. Öffne: `websocket.org/echo.html`
-2. Verbinde, sende Nachrichten
-3. Beobachte: Instant Response
-
-
-
----
-
-# Aufgabe bis nächste Woche
-
-**Experimentiere mit öffentlicher API:**
-
-1. Wähle:
- - GitHub API (`api.github.com`)
- - 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)
-
-**Bonus:** Baue kleinen Client (Python, JavaScript, etc.)
-
-
-
----
-
-
-
-# Woche 9
-## Metadaten & Interoperabilität
-
----
-
-
-
-
-
----
-
-# Was sind Metadaten?
-
-**Metadaten = Daten über Daten**
-
-**Beispiele:**
-- **Foto:** Kamera, Datum, GPS, Belichtung
-- **MP3:** Künstler, Album, Jahr, Genre, Cover
-- **PDF:** Autor, Datum, Software
-- **E-Mail:** Absender, Empfänger, Zeitstempel
-
-**Warum wichtig?**
-✓ Organisation, Suche
-✓ Kontext (Wann/Wo/Wie?)
-
-**Aber auch:**
-❌ Privacy-Risiko, Forensische Spuren
-
-
-
----
-
-# EXIF: Exchangeable Image File Format
-
-**EXIF (1995, Kamera-Hersteller):**
-
-**Typische Daten:**
-- Kamera-Modell (z.B. "iPhone 15 Pro")
-- Datum & Uhrzeit
-- Belichtung (Blende, Verschlusszeit, ISO)
-- **GPS-Koordinaten** (Latitude, Longitude, Altitude)
-- Software (z.B. "Photoshop 2024")
-
-**Speicherort:** JPEG-Header (Binärformat)
-
-**Tools:** exiftool, ExifPurge, metapicz.com
-
-
-
----
-
-
-
-
-
----
-
-# EXIF: Privacy-Albtraum
-
-**Szenario 1: Stalking**
-- Foto auf Twitter: "Zuhause entspannen 🏡"
-- EXIF: GPS 52.5200° N, 13.4050° E
-- → Stalker weiß, wo du wohnst
-
-**Szenario 2: Whistleblowing**
-- Anonyme Quelle schickt PDF
-- Metadaten: "Erstellt von: John Doe, Firma XY"
-- → Quelle identifiziert
-
-**Berühmter Fall:**
-John McAfee (2012): Vice-Magazine vergaß EXIF zu entfernen
-→ GPS verriet Aufenthaltsort in Guatemala
-
-
-
----
-
-# Social Media & EXIF-Stripping
-
-**Welche Plattformen entfernen EXIF?**
-
-✓ **Twitter/X:** Ja (seit 2015)
-✓ **Facebook/Instagram:** Ja (GPS entfernt)
-✓ **Reddit:** Ja
-❌ **WhatsApp:** Nein (privat, aber Metadaten bleiben)
-❌ **E-Mail-Anhänge:** Nein
-❌ **Cloud (Dropbox, Google Drive):** Nein
-
-**Best Practice:** EXIF manuell entfernen vor Upload
-```bash
-exiftool -all= foto.jpg # Entfernt ALLE Metadaten
-```
-
-
-
----
-
-
-
-
-
----
-
-# ID3-Tags: Musik-Metadaten
-
-**ID3 = Identification 3 (1996)**
-
-**Versionen:**
-- **ID3v1:** 128 Bytes am Ende (limitiert!)
- - Titel (30 Zeichen), Artist, Album, Jahr
-- **ID3v2:** Am Anfang, variable Länge
- - Unbegrenzte Textfelder, Cover-Art, Lyrics, BPM
-
-**Tools:**
-- Kid3 (GUI, Multi-Platform)
-- MusicBrainz Picard (Auto-Tagging!)
-- mp3tag (Windows)
-
-
-
----
-
-
-
-
-
----
-
-# MusicBrainz: Offene Musik-Datenbank
-
-**MusicBrainz (2000):**
-
-**Idee:** Wikipedia für Musik-Metadaten
-
-**Community-gepflegt:**
-- Künstler, Alben, Tracks
-- Relationships (Band-Mitglieder, Label...)
-- Releases (verschiedene Editionen, Länder)
-
-**MusicBrainz Picard:**
-- Audio-Fingerprinting (AcoustID)
-- Analysiert Waveform, matched mit Datenbank
-- Auto-Tagging (auch bei falsch benannten Dateien!)
-
-**Philosophie:** Open Data (gegen proprietäre Gracenote/CDDB)
-
-
-
----
-
-# Dublin Core: Universelle Metadaten
-
-**Dublin Core (1995, Dublin, Ohio):**
-
-**15 Kern-Elemente:**
-1. Title, 2. Creator, 3. Subject, 4. Description
-5. Publisher, 6. Contributor, 7. Date, 8. Type
-9. Format, 10. Identifier (ISBN, DOI)
-11. Source, 12. Language, 13. Relation
-14. Coverage, 15. Rights
-
-**Anwendung:** Bibliotheken, Archive, Webseiten (HTML ``)
-
-
-
----
-
-
-
-
-
----
-
-# PDF-Metadaten: Hidden Dangers
-
-**PDF-Metadaten (XMP):**
-
-**Gespeichert:**
-- Titel, Autor, Betreff, Keywords
-- Erstellungsdatum, Änderungsdatum
-- Software, **Company** (aus Office-Lizenz!)
-
-**Versteckte Daten:**
-- Änderungshistorie (Track Changes)
-- Kommentare (vermeintlich gelöscht)
-- Ebenen (InDesign, Illustrator)
-
-**Berühmter Fall:**
-Tony Blair Dossier (2003, Irak-Krieg)
-→ PDF-Metadaten zeigten Manipulation
-
-
-
----
-
-# Interoperabilität: Offene vs. Proprietäre
-
-**Offene Formate:**
-✓ Spezifikation öffentlich
-✓ Keine Lizenzgebühren
-✓ Viele Programme unterstützen
-**Beispiele:** PNG, OGG, MKV, Markdown, SVG
-
-**Proprietäre Formate:**
-❌ Spezifikation geheim
-❌ Oft nur in einer Software voll nutzbar
-❌ **Lock-in-Effekt**
-**Beispiele:** PSD (Photoshop), INDD (InDesign), DWG (AutoCAD), .pages
-
-
-
----
-
-# Vendor Lock-in: Beispiele
-
-**Fall 1: Microsoft Office (.docx)**
-- Historisch: .doc undokumentiert
-- LibreOffice konnte nicht perfekt konvertieren
-- "Formatierung kaputt" → Zurück zu MS Office
-
-**Fall 2: Adobe Creative Suite**
-- PSD: Layer, Blend-Modes → Nur in Photoshop voll editierbar
-- GIMP kann öffnen, aber Features fehlen
-
-**Fall 3: Apple Ecosystem**
-- .pages, .numbers, .key → Nur auf Apple native Bearbeitung
-
-
-
----
-
-# Datenmigration & Langzeitarchivierung
-
-**Beispiele toter Formate:**
-- WordPerfect (.wpd) – 1980-90er dominant, heute kaum lesbar
-- Lotus 1-2-3 (.wks) – Spreadsheet, verschwunden
-- Flash (.swf) – Millionen Websites/Games, seit 2020 tot
-
-**Archivierungs-Strategien:**
-1. **Migration:** Regelmäßig in aktuelle Formate konvertieren
-2. **Emulation:** Alte Software in VM
-3. **Offene Standards:** PDF/A, TIFF, Plain Text
-
-
-
----
-
-# Metadaten für Accessibility
-
-**Alt-Text (Alternative Text):**
-```html
-
-```
-
-**Warum?**
-✓ Screen-Reader (Blinde/Sehbehinderte)
-✓ SEO (Suchmaschinen)
-✓ Fallback (Bild lädt nicht)
-
-**PDF-Tags:** Strukturierte PDFs (Überschriften, Listen)
-→ Screen-Reader kann navigieren
-
-**Video:** Closed Captions (CC), Audio Descriptions
-
-
-
----
-
-# Hands-On: Metadaten analysieren & entfernen
-
-**Aufgabe (40 Min):**
-
-**Teil 1: EXIF (20 Min)**
-1. Nimm Foto (oder nutze altes)
-2. Analysiere: `exiftool foto.jpg` oder metapicz.com
-3. Notiere: GPS? Kamera-Modell? Software?
-4. Entferne: `exiftool -all= foto.jpg`
-5. Vergleiche Dateigrößen
-
-**Teil 2: ID3 (20 Min)**
-1. Nimm MP3-Datei
-2. Analysiere: Kid3, mp3tag, oder exiftool
-3. Ändere Tags (z.B. falscher Artist)
-4. Optional: MusicBrainz Picard (Auto-Tagging)
-
-
-
----
-
-# Aufgabe bis nächste Woche
-
-**Metadaten-Audit:**
-
-1. Wähle 3 Dateitypen:
- - Ein Foto (EXIF)
- - 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?
-
-**Bonus:** Finde alte Datei (>5 Jahre) – was verraten Metadaten über damaliges Setup?
-
-
-
----
-
-
-
-# Woche 10
-## Zukunft & Synthese
-
----
-
-
-
-
-
----
-
-# Rückblick: 9 Wochen
-
-**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
-
-**Heute:** Wohin geht die Reise?
-
-
-
----
-
-# AI-basierte Kompression
-
-**Problem:** JPEG/H.264 basieren auf 90er-Jahre-Modellen
-
-**Neue Ansätze:**
-
-1. **Neuronale Bild-Kompression:**
- - Deep Learning lernt Kompression/Dekompression
- - Google's "Learned Image Compression" (2018)
- - Outperforms JPEG bei gleicher Größe
-
-2. **Generative Kompression:**
- - Encoder extrahiert semantische Features
- - Decoder generiert Bild neu (wie DALL-E)
- - **99%+ Kompression**, aber nicht bit-genau!
-
-**Problem:** Hoher Rechenaufwand, keine Standardisierung
-
-
-
----
-
-
-
-
-
----
-
-# JPEG XL: Der moderne JPEG
-
-**JPEG XL (2021, ISO-Standard):**
-
-**Ziele:**
-✓ 60% besser als JPEG
-✓ Besser als WebP/AVIF (manchmal)
-✓ Lossless UND Lossy
-✓ Progressive Decoding (wie klassisches JPEG)
-✓ Rückwärtskompatibel (JPEG → JPEG XL "Wrapper")
-
-**Features:** HDR, Animation (wie GIF, aber besser)
-
-**Status 2025:** Browser-Support langsam (Safari ja, Chrome on-off)
-
-**Problem:** Google favorisiert WebP/AVIF → politischer Kampf
-
-
-
----
-
-# AV1 & VVC: Codec-Krieg
-
-**AV1 (Alliance for Open Media):**
-✓ Etabliert sich (YouTube 4K, Netflix)
-✓ Hardware-Decoder in neuen GPUs/Smartphones
-
-**VVC (H.266, 2020):**
-- 50% besser als H.265
-- **Aber:** Patent-Problem (mehrere Pools, unklare Kosten)
-- Adoption gering
-
-**LCEVC:** Add-on für existierende Codecs
-
-**Zukunft:**
-- AV2 (Nachfolger AV1) in Entwicklung
-- ML integriert?
-
-
-
----
-
-
-
-
-
----
-
-# DNA-Storage
-
-**Konzept:** Daten in DNA-Sequenzen
-
-**Eigenschaften:**
-- Speicherdichte: **215 Petabyte/Gramm**
-- Haltbarkeit: Tausende Jahre
-- Kosten: Aktuell $3.500/MB (sinkend)
-
-**Beispiele:**
-- Microsoft + Twist Bioscience
-- Netflix "Biohackers"-Episode (2021)
-- Harvard: Wikipedia (11 GB) in DNA (2017)
-
-**Problem:** Synthese & Sequenzierung extrem langsam/teuer
-
-**Anwendung:** Langzeitarchivierung (nicht Live-Daten)
-
-
-
----
-
-# Holografischer Speicher
-
-**Holographic Data Storage:**
-
-**Prinzip:**
-- Laser schreibt in 3D-Kristall (statt 2D-Oberfläche)
-- Interferenzmuster speichert Bits
-- Paralleler Zugriff (schnell!)
-
-**Vorteile:**
-✓ Hohe Dichte (Terabytes pro Disc)
-✓ Schnelle Lesegeschwindigkeit
-✓ Langlebig (50+ Jahre)
-
-**Stand 2025:** Prototypen (Sony, InPhase †), Kommerzialisierung gescheitert
-
-**Problem:** Teuer, Konkurrenz durch SSDs
-
-
-
----
-
-# Quantum Storage?
-
-**Quantenspeicher:**
-
-**Konzept:**
-- Qubits statt klassische Bits
-- Superposition: 0 UND 1 gleichzeitig
-- Verschränkung: Qubits korreliert über Distanz
-
-**Anwendung:**
-- Nicht für klassische Daten (Qubits instabil)
-- Quantum Key Distribution (QKD) für Kommunikation
-- Zukunft: Quanten-RAM für Quantencomputer
-
-**Stand 2025:** Experimentell, Speicherzeit Millisekunden
-
-
-
----
-
-# Web3 & Dezentraler Speicher
-
-**IPFS, Filecoin, Arweave, Storj:**
-
-**Idee:** Speicher ohne zentrale Server
-
-**Filecoin (2017):**
-- Blockchain-basiert
-- User vermieten Festplatten-Platz
-- Bezahlung in FIL (Kryptowährung)
-
-**Arweave (2018):**
-- "Permanent Storage"
-- Einmalige Zahlung → Daten für immer (theoretisch)
-
-**Kritik:**
-❌ Langsam vs. AWS S3
-❌ Teurer (oft)
-❌ Keine Garantie (Nodes offline)
-
-
-
----
-
-# Streaming-Zukunft
-
-**Trends:**
-
-**8K-Streaming:**
-- 7680×4320 = 33 Megapixel/Frame
-- Braucht 100+ Mbps (selbst mit AV1)
-- Problem: Kaum Content, kaum TVs
-
-**VR/AR-Streaming:**
-- 2× 4K (pro Auge), 90-120 fps
-- Latenz <20ms kritisch
-- 5G + Edge Computing nötig
-
-**Cloud Gaming:**
-- Spiel im Rechenzentrum, Stream zu User
-- Input-Lag = Todfeind (<50ms)
-
-**Problem:** Physik (Lichtgeschwindigkeit!)
-
-
-
----
-
-# Nachhaltigkeit
-
-**Digitalisierung ≠ Umweltfreundlich**
-
-**Rechenzentren:**
-- 2024: 1-2% globaler Stromverbrauch (steigend!)
-- Kühlung, Server, Netzwerk
-
-**Streaming:**
-- 1h Netflix (HD): ~3 GB, ~0,1 kWh
-- × Milliarden Stunden = massiver CO₂
-
-**E-Waste:**
-- Smartphones: 2-3 Jahre Lebensdauer
-- SSDs, HDDs: Nicht ewig
-
-**Lösungen:**
-- Effizientere Codecs (weniger Bandbreite)
-- Renewable Energy für Rechenzentren
-- Längere Hardware-Lebensdauer (Right to Repair!)
-
-
-
----
-
-# Regulierung & Standardisierung
-
-**Wer entscheidet?**
-
-**Standards-Organisationen:**
-- ISO/IEC (International)
-- IETF (Internet-Protokolle)
-- W3C (Web-Standards)
-- IEEE (Hardware)
-
-**Problem:** Industrie-Dominanz
-- MPEG-LA (Patent-Pools)
-- USB-IF (Intel-dominiert)
-- HDMI Forum (Consumer-Electronics)
-
-**EU-Regulierung:**
-- USB-C-Pflicht (ab 2024)
-- DMA (Digital Markets Act): Interoperabilität
-- GDPR: Datenschutz (betrifft Metadaten!)
-
-**Zukunft:** Mehr Open Standards? Oder Fragmentierung?
-
-
-
----
-
-# Fallstudie: Gruppenarbeit
-
-**Aufgabe (90 Min, ca. 5 Personen):**
-
-**Szenario:** Mittelständisches Medienunternehmen produziert Videos
-
-**Erarbeitet Konzept für:**
-1. Speichermedien (intern/extern, kurz-/langfristig)
-2. Dateiformate (Produktion, Distribution, Archivierung)
-3. Dateisysteme (welche für was?)
-4. Schnittstellen (SATA, USB, PCIe, Netzwerk)
-5. Distributionswege (NAS, Cloud, FTP)
-6. Backup-Strategie (3-2-1-Regel!)
-
-**Ergebnis:** Konzeptpapier (Mindmap, Tabelle, Poster)
-**Präsentation:** 5 Min pro Gruppe
-
-
-
----
-
-# Alternative Szenarien (Auswahl)
-
-1. **Mittelständisches Medienunternehmen** (Videos, Streaming)
-2. **Kommunales Stadtarchiv** (Digitalisierung historischer Bestände)
-3. **Agentur für digitale Kommunikation** (internationale Kampagne)
-4. **Digitale Hochschul-Mediathek** (Lehrvideos, Podcasts)
-5. **Freiberufliche Fotografin** (Tausende RAW-Fotos/Jahr)
-6. **Internationales Reporterteam** (investigative Recherche, sensibel)
-
-**Jede Gruppe wählt ein Szenario**
-
-
-
----
-
-# Was wir insgesamt gelernt haben
-
-✓ **Bits → Formate:** Encoding, Kompression (MP3, JPEG, H.264)
-✓ **Speicher:** HDD, SSD, Dateisysteme, Backup, Archivierung
-✓ **Schnittstellen:** USB-C, HDMI, DisplayPort, Ethernet
-✓ **Distribution:** CDN, P2P, Streaming, APIs
-✓ **Metadaten:** EXIF, ID3, Privacy, Interoperabilität
-✓ **Zukunft:** AI-Kompression, DNA-Storage, Nachhaltigkeit
-
-**Kernbotschaft:**
-Digitale Medien sind das Ergebnis von Standards, Politik, Kompromissen & Innovation.
-
-Ihr habt jetzt die Werkzeuge, um die digitale Welt kritisch zu verstehen.
-
-
-
----
-
-# Weiterführende Ressourcen
-
-**Bücher:**
-- "Code" – Charles Petzold (Basics)
-- "Understanding Digital Signal Processing" – Richard Lyons
-
-**Websites:**
-- IETF RFCs (ietf.org)
-- FFmpeg Documentation (ffmpeg.org)
-- Protocol Labs (IPFS, Filecoin)
-
-**YouTube:**
-- Computerphile (Kompression, Encoding)
-- Branch Education (Hardware-Visualisierungen)
-
-**Podcasts:**
-- Command Line Heroes (Red Hat)
-
-**Tools:** MediaInfo, exiftool, FFmpeg, Wireshark
-
-
-
----
-
-# Abschluss & Dank
-
-**Ihr habt gelernt:**
-- Dateien zu lesen (Hex, Metadaten)
-- Formate zu vergleichen (JPEG vs. PNG, H.264 vs. AV1)
-- Infrastruktur zu verstehen (CDN, P2P, APIs)
-- Kritisch zu denken (Open Standards, Lock-in, Nachhaltigkeit)
-
-**Nächste Schritte:**
-- Fallstudie (falls Prüfungsleistung)
-- Feedback willkommen (Forum, E-Mail)
-- Weiterlernen mit Ressourcen
-
-**Vielen Dank für eure Aufmerksamkeit!**
-
-
-
----
-
-
-
-# Fragen & Diskussion
-
-**Kontakt:** m.czechowski@librete.ch
-**Folien:** Online verfügbar unter https://hdm.librete.ch
-
----
-
-# Lizenz & Attribution
-
-Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
-
-- Erlaubt Teilen & Anpassen mit Namensnennung
-- Adaptionen müssen unter gleicher Lizenz geteilt werden
-
-Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
-
-
-
diff --git a/slides/2025-12-19-termin-0-intro.md b/slides/2025-12-19-termin-0-intro.md
new file mode 100644
index 0000000..5f953fc
--- /dev/null
+++ b/slides/2025-12-19-termin-0-intro.md
@@ -0,0 +1,150 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+---
+
+
+
+
+
+
+
+
+
+# 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)
+
+---
+
+
+
+# Internettechnologien 1
+## "Technische Grundlagen von IT-Projekten"
+
+---
+
+# Über mich
+
+**Michael Czechowski**
+
+- Softwareentwickler & IT-Berater
+- Schwerpunkte: Cloud, AI, Web-Technologien, Systemarchitektur, Open Source
+- Hintergrund: Philosophie & Informatik
+- Kontakt: mail@librete.ch
+
+
+
+---
+
+# Kurze Umfrage
+
+**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`?)
+
+
+
+---
+
+# 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.
+
+Kaum ein Projekt in der Medienwelt kommt ohne digitale Technik aus:
+- Als **Produkt** (z.B. Verkauf einer Webseite)
+- Als **Kollaborationsplattform**
+- Als **Marketing- und Verkaufsplattform**
+
+
+
+---
+
+# Das Ziel
+
+**Technische Grundlagen verstehen**, um mit Entwicklungsteams, Kunden und Projektpartnern **auf Augenhöhe** zusammenarbeiten 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.
+
+
+
+---
+
+# Was ihr lernt
+
+**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
+
+
+
+---
+
+# Kursübersicht
+
+**5 Termine:**
+
+| # | Datum | Thema |
+|---|-------|-------|
+| 1 | 19.12.2025 | Bits, Bytes, Zeichenkodierung & Audio |
+| 2 | 09.01.2026 | Bild- & Video-Kompression |
+| 3 | 23.01.2026 | Speichermedien & Schnittstellen |
+| 4 | 30.01.2026 | Distribution, APIs & Zukunft |
+| 5 | TBA | Vertiefung & offene Fragen |
+
+**Format:** Theorie + Hands-On (30-40 Min pro Termin)
+
+
+
diff --git a/slides/2025-12-19-termin-1-grundlagen-text-audio.md b/slides/2025-12-19-termin-1-grundlagen-text-audio.md
new file mode 100644
index 0000000..c8de9dc
--- /dev/null
+++ b/slides/2025-12-19-termin-1-grundlagen-text-audio.md
@@ -0,0 +1,844 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+---
+
+
+
+
+
+
+
+
+
+# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+
+**223015c** · Modul "Technik 1" · 1. Semester
+Digital- und Medienwirtschaft
+Hochschule der Medien Stuttgart
+
+**Wintersemester 2025/26**
+
+[https://git.librete.ch/hdm/223015b](https://git.librete.ch/hdm/223015b)
+
+---
+
+
+
+# Termin 1 – 19.12.2025
+## Grundlagen, Text & Audio
+
+
+---
+
+
+
+# WTF!?
+
+```
+89 50 4E 47 0D 0A 1A 0A
+00 00 00 0D 49 48 44 52
+00 00 01 90 00 00 01 2C
+```
+
+**Was ist das?**
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Das Bit
+
+**Kleinste Informationseinheit**
+
+- **0 oder 1**
+- AN oder AUS
+- Strom fließt oder nicht
+
+
+
+---
+
+# Das Byte
+
+**8 Bits = 1 Byte**
+
+```
+0 1 0 0 1 1 0 1
+```
+
+**Wie viele Kombinationen?**
+2⁸ = **256 Möglichkeiten** (0-255)
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# 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)
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Farben: RGB-Modell
+
+**1 Pixel = 3 Bytes**
+
+- **Rot:** 0-255
+- **Grün:** 0-255
+- **Blau:** 0-255
+
+**Beispiele:**
+`FF 00 00` = Rot | `00 FF 00` = Grün
+`00 00 00` = Schwarz | `FF FF FF` = Weiß
+
+
+
+---
+
+# Das Problem: Sprachen
+
+**Die Welt hat mehr als 256 Zeichen!**
+
+- Englisches Alphabet: 52 (A-Z, a-z)
+- + Ziffern: 10 (0-9)
+- + Sonderzeichen: ~30
+
+**≈ 90 Zeichen → passt in 1 Byte**
+
+**Aber:** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 😀
+
+→ **1 Byte reicht nicht!**
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Unicode: Ein Standard für alle
+
+**Unicode (1991):**
+Jedes Schriftsystem der Welt
+
+**>150.000 Zeichen:**
+- Latein, Kyrillisch, Arabisch, Chinesisch, Japanisch...
+- Mathematische Symbole, Emoji, historische Schriften
+
+**UTF-8:** Variable Länge (1-4 Bytes pro Zeichen)
+
+
+
+---
+
+# Beispiel: Bytes zählen
+
+**Text:** `"Why the heck braucht 💩 4 Bytes?!"`
+
+```
+W h y → je 1 Byte (4 Bytes)
+t h e → je 1 Byte (4 Bytes)
+h e c k → je 1 Byte (4 Bytes)
+ → 1 Byte (Leerzeichen)
+b r a u c h t → je 1 Byte (7 Bytes)
+ → 1 Byte
+💩 → 4 Bytes! (0xF0 9F 92 A9)
+ → 1 Byte
+4 B y t e s ? ! → je 1 Byte (9 Bytes)
+```
+
+**Gesamt: 37 Bytes**
+
+
+
+---
+
+
+
+
+
+
+
+
+
+---
+
+# Hexadezimal: Lesbarkeit
+
+**Binär ist unleserlich:**
+`01001101 01010000 00110011`
+
+**Hexadezimal (Base 16):**
+`4D 50 33` (= "MP3" in ASCII)
+
+**Jede Hex-Ziffer = 4 Bits (ein "Nibble")**
+0-9, A-F (10=A, 11=B, ..., 15=F)
+
+
+
+---
+
+# Magic Numbers
+
+**Dateityp-Identifikation durch erste Bytes**
+
+| Format | Magic Number (Hex) | ASCII |
+|--------|-------------------|-------|
+| PNG | `89 50 4E 47 0D 0A 1A 0A` | `.PNG` |
+| JPEG | `FF D8 FF` | `ÿØÿ` |
+| PDF | `25 50 44 46` | `%PDF` |
+| ZIP/DOCX/ODT | `50 4B 03 04` | `PK` |
+
+**Achtung:** TXT, HTML, CSS haben **keine** Magic Number!
+
+
+
+---
+
+
+
+
+
+
+
+
+
+---
+
+# Hands-On: WTF Files
+
+**Aufgabe (30 Min):**
+
+1. Drei Dateien ohne Extension: `wtf1`, `wtf2`, `wtf3`
+ → Download: `materials/` Ordner
+2. Öffne im Hex-Editor
+3. Lies erste 16 Bytes
+4. Identifiziere Format (Magic Number)
+5. Benenne um und öffne
+
+**Tools:** hexed.it (online), HxD, Hex Fiend, Bless
+
+
+
+---
+
+# Fleißaufgabe bis nächste Woche
+
+**Finde eine Datei auf deinem Computer**
+
+1. Öffne im Hex-Editor
+2. Schau dir die ersten 16 Bytes an
+3. Identifiziere die Magic Number (falls vorhanden)
+4. Nächste Woche: Kurze Diskussion
+
+**Bonus:** Finde Datei ohne Magic Number
+
+
+
+---
+
+
+
+# Teil 2: Die MP3-Revolution
+## Psychoakustik & Audio-Kompression
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Das Problem (1990)
+
+**1 Minute CD-Audio:**
+
+- Sample Rate: 44.100 Hz
+- Bit Depth: 16 Bit
+- Stereo: 2 Kanäle
+
+**Rechnung:**
+44.100 × 16 × 2 = 1.411.200 Bits/Sekunde
+≈ **10,6 MB/Minute**
+≈ **635 MB für 60-Min-Album**
+
+**1990:** Festplatten hatten 100-500 MB!
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Zwei Philosophien
+
+**Lossless (Verlustfrei):**
+- Original exakt wiederherstellbar
+- ZIP, PNG, FLAC
+- 30-50% Ersparnis
+
+**Lossy (Verlustbehaftet):**
+- Daten irreversibel verändert
+- JPEG, MP3, H.264
+- 90%+ Ersparnis
+
+
+
+---
+
+# Lossless: Run-Length Encoding
+## Lauflängenkodierung
+
+**Original:**
+```
+AAAAABBBCCCCCCCC
+```
+
+**Komprimiert:**
+```
+5A 3B 8C
+```
+
+**Ersparnis:** 16 → 6 Zeichen (62% Reduktion)
+
+
+
+---
+
+# Lossy: Der Trick
+
+**Kernidee:** Wirf weg, was der Mensch eh nicht wahrnimmt
+
+**JPEG:** Schwächen des Auges
+- Helligkeit besser als Farbe wahrgenommen
+- Große Flächen besser als feine Details
+
+**MP3:** Schwächen des Ohrs
+- Mittlere Frequenzen besser als hohe/tiefe
+- Laute Töne "maskieren" leise Töne
+
+→ **Psychoakustik / Psychovisuell**
+
+
+
+---
+
+
+
+# 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
+
+
+
+---
+
+# Die Geburt der MP3
+
+**1982:** Universität Erlangen-Nürnberg
+Karlheinz Brandenburg, Diplom-Ingenieur
+
+**1987:** Fraunhofer IIS entwickelt MPEG-1 Audio Layer III
+
+**1988:** Patentanmeldung
+
+**1992:** Erste Software-Implementierung
+
+**1995:** .mp3 Dateiendung offiziell
+
+
+
+---
+
+
+
+# Suzanne Vega
+
+**"Tom's Diner" (1987)**
+
+- A cappella (keine Instrumente)
+- Klare, hohe Frequenzen
+- Perfekter Stresstest für Kompression
+- Der erste Song, der als MP3 kodiert wurde
+
+
+
+---
+
+# "Tom's Diner"
+
+**Warum dieser Song?**
+
+- A cappella (keine Instrumente)
+- Suzanne Vegas Stimme ist "schwierig"
+- Klare, hohe Frequenzen → Stresstest
+
+*"If I could code Suzanne Vega's voice well, I could code anything."*
+— Karlheinz Brandenburg
+
+
+
+---
+
+# Wie funktioniert MP3?
+
+**1. Frequenz-Analyse (FFT)**
+Audio → Frequenzspektrum
+
+**2. Psychoakustisches Modell**
+Welche Töne hört Mensch nicht?
+
+**3. Quantisierung**
+Unwichtige Frequenzen reduzieren
+
+**4. Huffman-Coding**
+Lossless-Kompression der Restdaten
+
+
+
+---
+
+# Bitrate: Der Qualitäts-Knopf
+
+| Bitrate | Qualität | Kompression |
+|---------|----------|-------------|
+| **128 kbps** | Hörbar schlechter | ~11x |
+| **192 kbps** | Akzeptabel | ~7x |
+| **256 kbps** | Gut | ~5,5x |
+| **320 kbps** | "CD-Qualität" | ~4,4x |
+
+**Original CD:** 1.411 kbps (unkomprimiert)
+
+
+
+---
+
+
+
+
+
+
+
+
+
+---
+
+# Der Patentkrieg
+
+**1990er:** Fraunhofer + Thomson halten MP3-Patente
+
+**Lizenzgebühren:**
+- $0,75 pro Decoder
+- $2,50 pro Encoder
+
+**Problem:** Napster (1999) → unkontrollierte Verbreitung
+
+**2017:** Patente laufen aus → MP3 ist frei
+
+
+
+---
+
+
+
+# Napster (1999)
+
+**P2P-Filesharing für MP3s**
+
+- Shawn Fanning, 19 Jahre alt
+- 80 Millionen User in 2 Jahren
+- Musikindustrie verklagt (2001)
+- Pandora's Box: Nicht mehr aufzuhalten
+
+
+
+---
+
+# Napster & Musikindustrie
+
+**1999:** Napster startet
+**2001:** 80 Millionen User
+
+**Musikindustrie:**
+- CDs kosten $15-20
+- MP3s gratis (illegal, aber egal)
+- Einzelne Songs statt Alben
+
+**2001:** Napster verklagt, geschlossen
+
+**Aber:** Pandora's Box offen
+→ LimeWire, Kazaa, BitTorrent, später Spotify
+
+
+
+---
+
+# Kulturelle Revolution
+
+**MP3 veränderte:**
+
+✓ Musik wurde portabel (Walkman → iPod)
+✓ Alben wurden irrelevant (Playlists)
+✓ Musikkonsum explodierte (kostenlos/billig)
+✓ Künstler verloren Kontrolle
+
+**Aber auch:**
+❌ Künstler verdienen weniger pro Stream
+❌ Audio-Qualität sank (Loudness War)
+❌ Physische Medien starben
+
+
+
+---
+
+# Hands-On: MP3 sezieren
+
+**Aufgabe (30 Min):**
+
+1. Lade Lied runter (eigenes oder CC)
+2. Konvertiere in verschiedene Bitraten:
+ - 320 kbps, 128 kbps, 64 kbps
+3. Tool: **Audacity** (kostenlos)
+4. Höre Unterschiede (Kopfhörer!)
+5. Vergleiche Dateigrößen
+
+**Spektrogramm:** Track-Menü → Spektrogramm
+
+
+
+---
+
+# Fleißaufgabe bis nächste Woche
+
+**Nimm ein Lied (eigenes oder CC)**
+
+1. Exportiere: WAV, MP3 320 kbps, MP3 128 kbps
+2. Höre die Unterschiede (Kopfhörer!)
+3. Vergleiche die Dateigrößen
+
+**Bonus:** Niedrigste Bitrate finden, bei der du keinen Unterschied hörst
+
+
+
+---
+
+
+
+# Fragen & Diskussion
+
+**Kontakt:** mail@librete.ch
+**Folien:** Online verfügbar unter https://hdm.librete.ch
+
+---
+
+# Lizenz & Attribution
+
+Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
+
+- Erlaubt Teilen & Anpassen mit Namensnennung
+- Adaptionen müssen unter gleicher Lizenz geteilt werden
+
+Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
+
diff --git a/slides/2026-01-09-termin-2-bild-audio-video.md b/slides/2026-01-09-termin-2-bild-audio-video.md
new file mode 100644
index 0000000..0aa4ed4
--- /dev/null
+++ b/slides/2026-01-09-termin-2-bild-audio-video.md
@@ -0,0 +1,771 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+---
+
+
+
+
+
+
+
+
+
+# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+
+**223015c** · Modul "Technik 1" · 1. Semester
+Digital- und Medienwirtschaft
+Hochschule der Medien Stuttgart
+
+**Wintersemester 2025/26**
+
+[https://git.librete.ch/hdm/223015b](https://git.librete.ch/hdm/223015b)
+
+---
+
+
+
+# Termin 2 – 09.01.2026
+## Bild-, Audio- & Videoformate
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Was ist ein Bild?
+
+**Digital = Pixelraster**
+
+**Beispiel: 1920×1080 (Full HD)**
+= 2.073.600 Pixel
+
+**Jedes Pixel = 3 Bytes (RGB)**
+2.073.600 × 3 = **6,2 MB**
+
+**Für EIN Foto!**
+
+
+
+---
+
+# Lossless: PNG
+
+**PNG = Portable Network Graphics (1996)**
+
+**Funktionsweise:**
+- Vorhersage (Pixel ähneln Nachbarn)
+- Differenz-Encoding
+- DEFLATE-Algorithmus (wie ZIP)
+
+**Kompression:** 20-50% Ersparnis
+
+**Gut für:** Screenshots, Logos, Text
+**Schlecht für:** Fotos
+
+
+
+---
+
+# Lossy: JPEG
+
+**JPEG = Joint Photographic Experts Group (1992)**
+
+**Eigenschaften:**
+- Lossy Kompression
+- 90%+ Platzersparnis möglich
+- Artefakte bei hoher Kompression
+
+**6 MB → 500 KB** (typisch)
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Wie funktioniert JPEG? (1/2)
+
+**Schritt 1: RGB → YCbCr**
+- Y = Helligkeit (Luminanz)
+- Cb/Cr = Farbe (Chrominanz)
+
+**Warum?** Menschen sehen Helligkeit besser als Farbe
+
+**Schritt 2: Chroma Subsampling**
+Farbauflösung reduzieren (4:2:0)
+→ 50% Datenmenge weg, kaum sichtbar
+
+
+
+---
+
+# Wie funktioniert JPEG? (2/2)
+
+**Schritt 3: DCT (Discrete Cosine Transform)**
+Bild in 8×8-Blöcke → Frequenzspektrum
+
+**Schritt 4: Quantisierung**
+Hohe Frequenzen (Details) stark reduzieren
+→ **Hier passiert Datenverlust!**
+
+**Schritt 5: Huffman-Coding**
+Lossless-Kompression der Restdaten
+
+
+
+---
+
+# JPEG Quality
+
+| Quality | Dateigröße | Artefakte |
+|---------|------------|-----------|
+| **100** | ≈2-3 MB | Kaum |
+| **85-90** | ≈200-400 KB | Minimal |
+| **50** | ≈100 KB | Sichtbar |
+
+**Sweet Spot: 85-90**
+10x Kompression, für Menschen kaum unterscheidbar
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Die GIF-Geschichte
+
+**GIF = Graphics Interchange Format (1987)**
+CompuServe (US-Online-Dienst)
+
+**Features:**
+- 256 Farben max (8-bit Palette)
+- Lossless (für Palette)
+- Animationen!
+
+**1994 Twist:** Unisys hält Patent auf LZW-Kompression
+→ Fordert Lizenzgebühren
+
+→ **"Burn All GIFs!" Kampagne**
+
+
+
+---
+
+# PNG vs. GIF
+
+**GIF:**
+✓ Animationen
+✓ Breite Unterstützung
+❌ Nur 256 Farben
+❌ Patent-Probleme (bis 2003)
+
+**PNG:**
+✓ Millionen Farben
+✓ Alpha-Transparenz
+✓ Patent-frei
+❌ Keine Animationen (bis APNG, 2004)
+
+**Ergebnis:** PNG für Grafiken, GIF für Memes!
+
+
+
+---
+
+# WebP & AVIF
+
+**WebP (Google, 2010):**
+- Lossy UND Lossless
+- Animationen
+- 25-35% kleiner als JPEG
+
+**AVIF (2019):**
+- Basiert auf AV1-Video-Codec
+- 50% kleiner als JPEG
+- HDR-Unterstützung
+- Patent-frei
+
+**Problem:** Browser-Support dauert Jahre
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Warum Instagram eure Fotos "ruiniert"
+
+**Upload-Pipeline:**
+1. Dein Foto: 12 MP, 8 MB
+2. Instagram skaliert: max. 1080px
+3. Re-Kompression: JPEG Quality ~75
+4. Endgröße: 200-400 KB
+
+**Warum?**
+- Speicherkosten (Milliarden Fotos!)
+- Ladezeiten (Mobile)
+- Bandbreite (günstiger)
+
+
+
+---
+
+# Hands-On: Kompression vergleichen
+
+**Aufgabe (40 Min):**
+
+1. Hochauflösendes Foto (eigenes oder CC)
+2. Exportiere:
+ - PNG
+ - JPEG Q100, Q85, Q50
+ - WebP (optional)
+3. Tool: **Squoosh.app** (Google-Tool)
+4. Vergleiche: Dateigrößen, sichtbare Unterschiede
+5. Wo werden Artefakte sichtbar?
+
+
+
+---
+
+# 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?
+
+**Bonus:** Teste WebP oder AVIF
+
+
+
+---
+
+
+
+# Teil 2: Video
+## Kompression & Codecs
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Das Problem: Video ist RIESIG
+
+**1 Minute 4K-Video (3840×2160):**
+
+- 30 fps (Bilder/Sekunde)
+- Jedes Bild: 24,8 MB (unkomprimiert)
+
+**Rechnung:**
+30 × 24,8 MB = **744 MB/Sekunde**
+× 60 Sekunden = **44,6 GB/Minute**
+
+**2-Stunden-Film: 5,3 TB!**
+
+
+
+---
+
+# Container vs. Codec
+
+**Container = Die Box**
+Verpackt Video, Audio, Untertitel, Metadaten
+
+**Beispiele:** MP4, MKV, AVI, MOV
+
+**Codec = Kompressionsalgorithmus**
+Entscheidet, WIE Daten komprimiert werden
+
+**Video-Codecs:** H.264, H.265, VP9, AV1
+**Audio-Codecs:** AAC, MP3, Opus
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Video-Kompression: Drei Prinzipien
+
+**1. Spatial Compression (Intra-Frame)**
+Jedes Bild einzeln (wie JPEG)
+→ I-Frames
+
+**2. Temporal Compression (Inter-Frame)**
+Nur Änderungen zwischen Bildern
+→ P-Frames, B-Frames
+
+**3. Motion Compensation**
+"Ball bewegt sich von A nach B"
+
+
+
+---
+
+# I-Frames, P-Frames, B-Frames
+
+**I-Frame (Intra):**
+Vollständiges Bild (wie JPEG)
+Groß, aber unabhängig
+
+**P-Frame (Predicted):**
+Referenziert vorherige Frames
+Viel kleiner
+
+**B-Frame (Bi-directional):**
+Referenziert vorherige UND zukünftige Frames
+Am effizientesten
+
+**GOP:** I - B - B - P - B - B - P - B - B - I
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# H.264: Der König
+
+**H.264 / AVC (2003)**
+
+**Warum dominant?**
+✓ Exzellente Kompression (100:1 möglich)
+✓ Hardware-Support (jedes Gerät seit ~2010)
+✓ YouTube, Netflix, Blu-ray – alles H.264
+
+**Features:**
+- Variable Block-Größen (16×16 bis 4×4)
+- Deblocking-Filter
+- CABAC-Coding
+
+
+
+---
+
+# Das Patent-Problem
+
+**H.264 ist NICHT frei!**
+
+**MPEG-LA (Patent Pool):**
+- 2.000+ Patente von ~30 Unternehmen
+- Apple, Microsoft, Sony, Panasonic...
+
+**Lizenzgebühren:**
+- Hardware-Decoder: $0,20/Einheit
+- Content-Distribution: Kostenlos für "Internet Broadcast"
+
+**Problem:** Open-Source-Projekte in Grauzone
+
+
+
+---
+
+# H.265 / HEVC
+
+**H.265 (2013):**
+50% bessere Kompression als H.264
+
+**ABER:** Patent-Desaster
+
+**Drei (!) konkurrierende Patent-Pools:**
+- MPEG-LA
+- HEVC Advance
+- Velos Media
+
+→ Viele bleiben bei H.264 oder suchen Alternativen
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# VP9: Googles Antwort
+
+**VP9 (2013):**
+Entwickelt von Google (On2-Akquisition)
+
+**Eigenschaften:**
+✓ Ähnlich H.265-Kompression
+✓ KOSTENLOS, patent-frei (laut Google)
+✓ YouTube nutzt VP9 für 4K
+
+**Nachteile:**
+❌ Hardware-Support langsam
+❌ Höherer CPU-Aufwand
+❌ Nicht universell wie H.264
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# AV1: Die Open-Source-Revolution
+
+**AV1 (2018):**
+Alliance for Open Media: Google, Netflix, Amazon, Microsoft, Apple, Mozilla...
+
+**Ziel:** Patent-freier, moderner Codec
+
+**Features:**
+✓ 30% besser als H.265
+✓ Royalty-free, Open Source
+✓ 8K, HDR, hohe Frame-Rates
+
+**Stand 2025:**
+YouTube, Netflix nutzen AV1 für 4K/8K
+
+
+
+---
+
+# Adaptive Bitrate Streaming
+
+**Problem:** Internet-Geschwindigkeit variiert
+
+**Lösung:** Mehrere Qualitäten parallel
+
+**MPEG-DASH / HLS:**
+- 4K (20 Mbps)
+- 1080p (5 Mbps)
+- 720p (2,5 Mbps)
+- 480p (1 Mbps)
+- 240p (0,5 Mbps)
+
+Segmente: 2-10 Sekunden
+Player wählt dynamisch
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Container im Detail
+
+**MP4:**
+- Standard für Web, Mobile
+- H.264, H.265, AV1
+- DRM-fähig
+
+**MKV (Matroska):**
+- Open Source, extrem flexibel
+- Beliebig viele Audio-/Untertitel-Spuren
+- Fast jeden Codec
+
+**WebM:**
+- Google, Web-optimiert
+- Nur VP9/AV1 + Opus/Vorbis
+
+
+
+---
+
+# Hands-On: Video analysieren
+
+**Aufgabe (40 Min):**
+
+**Tool:** FFmpeg (CLI) oder HandBrake (GUI)
+
+1. Download: CC-Video (Big Buck Bunny, ~1 Min)
+2. Analysiere: `ffmpeg -i video.mp4` oder MediaInfo
+3. Notiere: Container, Codec, Bitrate, Auflösung
+4. Konvertiere:
+ - H.264, 1080p, 5 Mbps
+ - H.265, 1080p, 2,5 Mbps
+5. Vergleiche: Größen, Encoding-Zeit, Qualität
+
+
+
+---
+
+# 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?
+
+**Bonus:** AV1-Encoding (Warnung: SEHR langsam!)
+
+
+
+---
+
+
+
+# Fragen & Diskussion
+
+**Kontakt:** czechowski@hdm-stuttgart.de
+**Folien:** Online verfügbar unter https://hdm.librete.ch
+
+---
+
+# Lizenz & Attribution
+
+Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
+
+- Erlaubt Teilen & Anpassen mit Namensnennung
+- Adaptionen müssen unter gleicher Lizenz geteilt werden
+
+Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
+
diff --git a/slides/2026-01-23-termin-3-speichermedien-schnittstellen.md b/slides/2026-01-23-termin-3-speichermedien-schnittstellen.md
new file mode 100644
index 0000000..6ff73d7
--- /dev/null
+++ b/slides/2026-01-23-termin-3-speichermedien-schnittstellen.md
@@ -0,0 +1,1021 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+---
+
+
+
+
+
+
+
+
+
+# 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)
+
+---
+
+
+
+# Termin 3 – 23.01.2026
+## Speichermedien & Schnittstellen
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Rückblick: HDD vs. SSD
+
+**HDD:**
+- Mechanisch, magnetisch
+- Langsam (~150 MB/s)
+- Günstig (~20€/TB)
+- Empfindlich (Stöße!)
+
+**SSD:**
+- Elektronisch, Flash
+- Schnell (~500-7.000 MB/s)
+- Teuer (~80-150€/TB)
+- Write-Zyklen begrenzt
+
+
+
+---
+
+# Was fehlt? Dateisysteme!
+
+**Dateisystem = Bibliothekskatalog für Festplatte**
+
+**Aufgaben:**
+- Dateien speichern & finden
+- Metadaten verwalten
+- Speicherplatz effizient nutzen
+- Fehler erkennen & beheben
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Partitionen & Volumes
+
+**Partition:**
+Zusammenhängender Bereich auf Festplatte
+
+**Volume:**
+Logische Einheit mit Dateisystem
+
+**Beispiel:**
+1 TB HDD → 2 Partitionen
+- 500 GB Windows (NTFS)
+- 500 GB Daten (exFAT)
+
+
+
+---
+
+# Formatierung
+
+**Schnellformatierung:**
+- Löscht nur Metadaten
+- Daten physisch noch da
+- → Datenrettung möglich!
+
+**Vollständige Formatierung:**
+- Überschreibt mit Nullen
+- Dauert länger, aber sicherer
+
+
+
+---
+
+# FAT (File Allocation Table)
+
+**Geschichte:** 1977, Microsoft
+
+**Versionen:**
+- FAT16: Max. 2 GB
+- FAT32: Max. 4 GB Dateien, 2 TB Partitionen
+- exFAT: Keine 4 GB-Grenze
+
+**Vorteil:** Universelle Kompatibilität
+
+**Nachteil:** Keine Rechte, kein Journaling
+
+
+
+---
+
+# NTFS
+
+**NTFS = New Technology File System (1993)**
+
+**Features:**
+✓ Dateien >4 GB (bis 16 EB)
+✓ Zugriffsrechte (ACLs)
+✓ Journaling (Crash-Schutz)
+✓ Kompression & Verschlüsselung
+✓ Shadow Copies
+
+**Nachteil:** Proprietär (nur Windows nativ)
+
+
+
+---
+
+# APFS
+
+**Apple File System (2017)**
+
+**Features:**
+✓ Copy-on-Write (Speicherersparnis!)
+✓ Snapshots (Time Machine)
+✓ Native Verschlüsselung
+✓ SSD-optimiert
+
+**Nachteil:** Nur Apple-Geräte
+
+
+
+---
+
+# ext4
+
+**Fourth Extended File System (2008)**
+Linux-Standard
+
+**Features:**
+✓ Journaling
+✓ Extents (schneller)
+✓ Max. 16 TB Dateien, 1 EB Partitionen
+✓ Online-Defragmentierung
+
+**Nachteil:** Windows/macOS können nicht nativ lesen
+
+
+
+---
+
+# Dateisysteme: Vergleich
+
+| FS | OS | Max. Datei | Features |
+|----|----|-----------:|----------|
+| FAT32 | Alle | 4 GB | Kompatibilität |
+| exFAT | Alle | 16 EB | Flash-optimiert |
+| NTFS | Win | 16 EB | Journaling, ACLs |
+| APFS | macOS | 8 EB | Snapshots, CoW |
+| ext4 | Linux | 16 TB | Journaling |
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Backup: Warum?
+
+**Realität:**
+- Festplatten sterben ohne Vorwarnung
+- Ransomware verschlüsselt Daten
+- Versehentliches Löschen
+- Diebstahl, Brand, Wasserschaden
+
+**Faustregel: 3-2-1**
+Mindestens 3 Kopien, auf mindestens 2 unterschiedlichen Speichermedien und mindestens 1 an einem anderen Ort
+
+
+
+---
+
+# Backup-Arten
+
+**Vollständig (Full):**
+Kompletter Datenbestand
+Langsam, aber einfach
+
+**Inkrementell:**
+Nur Änderungen seit letztem Backup
+Schnell, aber Wiederherstellung komplex
+
+**Differenziell:**
+Änderungen seit letztem Voll-Backup
+Mittelweg
+
+
+
+---
+
+# 3-2-1-Regel
+
+**3** Kopien (Original + 2 Backups)
+
+**2** verschiedene Medientypen (SSD + HDD)
+
+**1** Offsite-Backup (Cloud, externes Lager)
+
+**Beispiel:**
+Laptop + externe Festplatte + Cloud
+
+
+
+---
+
+# Backup-Software
+
+**macOS:** Time Machine
+**Windows:** Veeam Agent (kostenlos)
+**Linux:** rsync, Borg, Restic
+**Plattformübergreifend:** Duplicati, Syncthing
+**Cloud:** Backblaze, Nextcloud
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Langzeitarchivierung: Das Problem
+
+**Digitale Daten altern:**
+- Bit Rot (Degradation)
+- Format-Obsoleszenz (WordPerfect .wpd)
+- Hardware-Obsoleszenz (Diskettenlaufwerke)
+
+**Lösung:**
+Migration + offene Standards
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Magnetbänder (LTO)
+
+**Linear Tape-Open:**
+
+- LTO-9 (2021): 18 TB nativ, 45 TB komprimiert
+- Haltbarkeit: 30 Jahre
+- Kosten: ~5€/TB (Laufwerk ~5.000€)
+- Nutzung: Rechenzentren, Archive
+
+**Air-Gap-Sicherheit:**
+Offline-Band kann nicht von Ransomware verschlüsselt werden
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# M-DISC (Millennial Disc)
+
+**Eigenschaften:**
+- DVD/Blu-ray-kompatibel
+- Anorganische Metallschicht
+- Haltbarkeit: 1.000 Jahre (Tests)
+- Einsatz: Familienfotos, Archive
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# DNA-Storage (Zukunft)
+
+**Konzept:** Daten in DNA-Sequenzen
+
+**Eigenschaften:**
+- Speicherdichte: 215 Petabyte/Gramm (!!)
+- Haltbarkeit: Tausende Jahre
+- Kosten: Aktuell $3.500/MB
+
+**Beispiele:**
+Microsoft + Twist Bioscience
+Netflix "Biohackers"-Episode (2021)
+
+
+
+---
+
+# Hands-On: S.M.A.R.T. & Backup
+
+**Aufgabe 1 (20 Min):**
+S.M.A.R.T.-Daten auslesen
+- Windows: CrystalDiskInfo
+- macOS/Linux: `smartctl -a /dev/sda`
+- Notiere: Health, Power-On Hours, Temp
+
+**Aufgabe 2 (20 Min):**
+Test-Backup erstellen
+- rsync (Linux/macOS) oder Robocopy (Windows)
+- Simuliere Datenverlust → Wiederherstellung
+
+
+
+---
+
+# 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
+
+**Bonus:** Richte automatisches Backup ein
+
+
+
+---
+
+
+
+# Teil 2: Schnittstellen
+## USB-C, HDMI & das Kabel-Chaos
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Was ist eine Schnittstelle?
+
+**Schnittstelle = Verbindung zwischen Systemen**
+
+**Hardware-Schnittstellen:**
+Physischer Anschluss (USB, HDMI, Ethernet)
+
+**Software-Schnittstellen:**
+API (nächste Woche!)
+
+**Heute:** Hardware-Fokus
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# USB: Die Idee
+
+**Universal Serial Bus (1996)**
+
+**Ziel:** Ein Kabel für alles
+
+**Vorher:**
+- PS/2 (Maus, Tastatur)
+- Seriell (Modem)
+- Parallel (Drucker)
+- SCSI (Festplatten)
+
+**USB-Versprechen:**
+✓ Ein Stecker, Hot-Pluggable, Stromversorgung
+
+
+
+---
+
+# USB-Versionen: Chaos
+
+| Version | Jahr | Geschwindigkeit | Marketing-Name |
+|---------|------|----------------:|----------------|
+| USB 1.0 | 1996 | 12 Mbps | – |
+| USB 2.0 | 2000 | 480 Mbps | Hi-Speed |
+| USB 3.0 | 2008 | 5 Gbps | USB 3.2 Gen 1 |
+| USB 3.1 | 2013 | 10 Gbps | USB 3.2 Gen 2 |
+| USB 3.2 | 2017 | 20 Gbps | USB 3.2 Gen 2×2 |
+| USB 4 | 2019 | 40 Gbps | USB4 |
+
+**NIEMAND versteht das mehr!**
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# USB-C: Stecker ≠ Geschwindigkeit
+
+**USB-C = Physischer Stecker (2014)**
+
+**Eigenschaften:**
+✓ Reversibel (beide Seiten gleich)
+✓ 24 Pins (vs. 4 bei USB-A)
+✓ Unterstützt: Daten, Strom, Video, Audio
+
+**ABER:** USB-C sagt NICHTS über Geschwindigkeit!
+
+Ein USB-C-Kabel kann sein:
+- USB 2.0 (480 Mbps) 😱
+- USB 3.2 Gen 2 (10 Gbps)
+- USB 4 (40 Gbps)
+- Thunderbolt 3/4 (40 Gbps)
+- Oder nur Power Delivery (Laden, keine Daten!)
+
+
+
+---
+
+# USB Power Delivery
+
+**USB PD (über USB-C):**
+
+- Profile: 5V bis 20V
+- Max. 5A
+- Bis zu **240W** (USB PD 3.1, 2021)
+
+**Anwendungen:**
+- Laptop-Ladung (60-100W)
+- Monitor mit Stromversorgung
+- Docking-Stations
+
+**Problem:** Nicht jedes Kabel unterstützt volles PD!
+
+
+
+---
+
+# USB-C: Das Wirrwarr
+
+**Was ein USB-C-Kabel KÖNNEN KANN:**
+
+**Daten:** USB 2.0 bis USB4 (40 Gbps)
+
+**Strom:** 5W bis 240W
+
+**Video:** DisplayPort Alt Mode, HDMI Alt Mode
+
+**Audio:** USB Audio Class
+
+**Problem:** Am Kabel steht's oft NICHT drauf!
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Thunderbolt: Premium-Schnittstelle
+
+**Thunderbolt (Intel + Apple):**
+
+- Thunderbolt 3/4 (2015/2020): USB-C, 40 Gbps
+- **PCIe über Kabel** → externe GPUs!
+- Daisychaining (bis 6 Geräte)
+- 100W Power Delivery garantiert
+
+**Nachteile:**
+❌ Teuer (Kabel: 30-80€)
+❌ Lizenzgebühren (Intel)
+❌ Nur High-End-Geräte
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# HDMI: Der Heimkino-Standard
+
+**HDMI (2002):**
+Entwickelt von Sony, Panasonic, Toshiba...
+
+**Versionen:**
+- HDMI 1.4 (2009): 4K @ 30 Hz, ARC
+- HDMI 2.0 (2013): 4K @ 60 Hz, HDR
+- HDMI 2.1 (2017): 8K @ 60 Hz, 4K @ 120 Hz, VRR
+
+**Features:**
+✓ Audio + Video in einem Kabel
+✓ HDCP (Copy Protection)
+✓ CEC (Gerätesteuerung)
+
+**Nachteile:**
+❌ Proprietär, Lizenzgebühren
+❌ Keine Daisychaining
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# DisplayPort: Die PC-Alternative
+
+**DisplayPort (2006):**
+VESA (Video Electronics Standards Association)
+
+**Versionen:**
+- DP 1.4 (2016): 8K @ 60 Hz, HDR
+- DP 2.0 (2019): 16K @ 60 Hz, 8K @ 120 Hz
+
+**Vorteile:**
+✓ Lizenzfrei (keine Gebühren!)
+✓ Daisychaining (Multi-Monitor)
+✓ Adaptive Sync (FreeSync, G-Sync)
+✓ USB-C Alt Mode
+
+**Nachteil:** Weniger verbreitet in TVs
+
+
+
+---
+
+# HDMI vs. DisplayPort
+
+| Feature | HDMI 2.1 | DisplayPort 2.0 |
+|---------|----------|-----------------|
+| **Max. Auflösung** | 8K @ 60 Hz | 16K @ 60 Hz |
+| **Lizenz** | Ja (~$10k/Jahr) | Nein |
+| **Daisychaining** | Nein | Ja |
+| **Adaptive Sync** | VRR (neu) | Ja (nativ) |
+| **USB-C** | Alt Mode (selten) | Alt Mode (häufig) |
+| **Verbreitung** | TVs dominant | PCs/Monitore |
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# HDCP: Copy Protection
+
+**HDCP = High-bandwidth Digital Content Protection**
+
+**Was ist das?**
+- DRM für Video-Signale
+- Verschlüsselt zwischen Quelle und Display
+- Verhindert "Man-in-the-Middle"-Aufnahme
+
+**Problem:**
+- Alte Monitore: Kein HDCP 2.2 → 4K-Netflix funktioniert nicht!
+- Capture-Cards oft blockiert
+- "HDCP-Handshake-Fehler" → Schwarzer Bildschirm
+
+**Kritik:** Schikaniert ehrliche Nutzer, Piraten umgehen es leicht
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Ethernet: Das Netzwerkkabel
+
+**Ethernet (1980er):**
+
+**Versionen:**
+- 100BASE-TX (1995): 100 Mbps
+- 1000BASE-T (1999): 1 Gbps (Gigabit)
+- 10GBASE-T (2006): 10 Gbps
+
+**Kabel-Kategorien:**
+- Cat5e: bis 1 Gbps (veraltet)
+- Cat6: bis 10 Gbps (55m)
+- Cat6a: bis 10 Gbps (100m)
+
+**Stecker:** RJ45 (8P8C)
+
+
+
+---
+
+
+
+
+
+
+
+
+---
+
+# Veraltete Schnittstellen
+
+**Seriell (RS-232):** 1960er, 115,2 kbps, Modems
+**Parallel (LPT):** Drucker, 8 Bits gleichzeitig
+**PS/2:** Maus + Tastatur (1987-2010er)
+**VGA:** Analoges Video (1987-2010er)
+
+**Heute:** Manchmal noch auf Mainboards (Legacy-Support)
+
+
+
+---
+
+# Hands-On: Schnittstellen identifizieren
+
+**Aufgabe (30 Min):**
+
+1. Untersuche deinen Laptop/Desktop
+2. Welche Anschlüsse vorhanden?
+3. Für USB-C: Welche Features? (Daten, Video, Laden?)
+4. Teste: Schließe Gerät an verschiedenen Ports an
+5. Dokumentiere: Foto + Beschriftung
+
+**Tools:** Systeminfo (Win), System Report (Mac), lsusb (Linux)
+
+
+
+---
+
+# 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
+
+**Bonus:** Finde USB-C-Kabel, das nur USB 2.0 kann
+
+
+
+---
+
+
+
+# Fragen & Diskussion
+
+**Kontakt:** czechowski@hdm-stuttgart.de
+**Folien:** Online verfügbar unter https://hdm.librete.ch
+
+---
+
+# Lizenz & Attribution
+
+Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
+
+- Erlaubt Teilen & Anpassen mit Namensnennung
+- Adaptionen müssen unter gleicher Lizenz geteilt werden
+
+Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
+
diff --git a/slides/2026-01-30-termin-4-distribution-apis-zukunft.md b/slides/2026-01-30-termin-4-distribution-apis-zukunft.md
new file mode 100644
index 0000000..4b92584
--- /dev/null
+++ b/slides/2026-01-30-termin-4-distribution-apis-zukunft.md
@@ -0,0 +1,1873 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+---
+
+
+
+
+
+
+
+
+
+# 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)
+
+---
+
+
+
+# Termin 4 – 30.01.2026
+## Distribution, APIs & Zukunft
+
+---
+
+
+
+
+
+---
+
+# Das Problem: Daten müssen reisen
+
+**Szenario:** 100 TB von Berlin nach München
+
+**Option 1: Internet-Upload**
+- 1 Gbps Uplink = 125 MB/s
+- Zeit: **9,3 Tage** (non-stop!)
+
+**Option 2: Festplatte per Post**
+- 10× 10TB HDDs (~2.000€)
+- Kopieren: ~10 Stunden
+- Versand: 1-2 Tage
+- Gesamt: **~3 Tage**
+
+*"Never underestimate the bandwidth of a station wagon full of tapes."* — Andrew Tanenbaum (1981)
+
+
+
+---
+
+
+
+
+
+---
+
+# AWS Snowball
+
+**AWS Snowball (seit 2015):**
+
+**Problem:** Petabytes on-premise → AWS-Cloud
+
+**Geräte:**
+- Snowball Edge: 100 TB
+- **Snowmobile:** 100 PB (Container auf LKW!)
+
+**Prozess:**
+1. AWS schickt verschlüsseltes Gerät
+2. Kunde kopiert Daten lokal (schnell!)
+3. Gerät zurück an AWS
+4. AWS lädt in S3 hoch
+
+**Kosten:** Günstiger als Internet-Transfer bei >10 TB
+
+
+
+---
+
+
+
+
+
+---
+
+# Physische Distribution
+
+**CD (1982):** 700 MB
+**DVD (1995):** 4,7 GB / 8,5 GB
+**Blu-ray (2006):** 25 GB / 50 GB / 100 GB
+
+**Problem heute:**
+- Games: 50-150 GB (Call of Duty: 200+ GB!)
+- Filme: Streaming überholt Blu-ray
+- Disc = "License Key", Rest wird geladen
+
+
+
+---
+
+
+
+
+
+---
+
+# Zentralisierte Distribution
+
+**Klassisches Modell:** Ein Server, viele Clients
+
+**Problem:**
+1 Million User wollen 1 GB-Datei
+→ Server braucht **1 PB Bandbreite!**
+→ Server überlastet → **"Hug of Death"**
+
+**Lösung:** Content Delivery Networks (CDNs)
+
+
+
+---
+
+
+
+
+
+---
+
+# CDNs: Content Delivery Networks
+
+**CDN = Verteiltes Netzwerk weltweit**
+
+**Funktionsweise:**
+1. **Origin Server** (Hauptquelle)
+2. **Edge Servers** (geografisch verteilt)
+3. User → nächster Edge Server
+4. Erste Anfrage: Edge holt von Origin, cached
+5. Weitere Anfragen: Direkt vom Edge (schnell!)
+
+**Vorteile:**
+✓ Reduzierte Latenz (geografische Nähe)
+✓ Last-Verteilung
+✓ Bandbreitenersparnis
+
+
+
+---
+
+# CDN-Strategien
+
+**Static Content:**
+- Bilder, CSS, JS, Videos
+- Lange Cache-Zeit (TTL: Tage/Wochen)
+
+**Dynamic Content:**
+- User-spezifisch (Profil)
+- Kurze TTL oder nicht cachebar
+
+**Cache Invalidation:**
+- Versioning (`style.css` → `style.v2.css`)
+- Cache-Purge (manuell leeren)
+
+*"There are only two hard things in Computer Science: cache invalidation and naming things."* — Phil Karlton
+
+
+
+---
+
+
+
+
+
+---
+
+# Netflix: Fallstudie CDN
+
+**Netflix Open Connect (eigenes CDN):**
+
+**Strategie:**
+- Server IN ISP-Rechenzentren (Telekom, Vodafone...)
+- Popular Content vorgeladen (Predictive Caching)
+- **95%+ Traffic vom lokalen ISP-Server**
+
+**Zahlen (2024):**
+- 200M+ Subscriber
+- ~15% des globalen Internet-Traffics!
+- Ohne CDN: Unmöglich
+
+
+
+---
+
+
+
+
+
+---
+
+# P2P: Peer-to-Peer
+
+**P2P = Jeder ist Client UND Server**
+
+**Philosophie:** Dezentralisierung
+
+**Anwendungen:**
+- BitTorrent (File-Sharing)
+- IPFS (InterPlanetary File System)
+- Blockchain (Bitcoin, Ethereum)
+
+**Vorteil:** Skalierbar (mehr User = mehr Bandbreite!)
+
+**Nachteil:** Langsam bei wenigen Peers, oft für Piraterie missbraucht
+
+
+
+---
+
+
+
+
+
+---
+
+# BitTorrent: Wie funktioniert's?
+
+**BitTorrent (Bram Cohen, 2001):**
+
+**Komponenten:**
+1. **.torrent-Datei:** Metadaten (Hashes, Tracker-URL)
+2. **Tracker:** Vermittelt Peers
+3. **Seeders:** Haben komplette Datei
+4. **Leechers:** Laden noch
+5. **Swarm:** Alle Peers zusammen
+
+**Mechanismus:**
+- Datei in Chunks (z.B. 256 KB)
+- Jeder Peer lädt von verschiedenen Peers
+- "Tit-for-tat": Wer uploaded, lädt schneller
+
+
+
+---
+
+
+
+
+
+---
+
+# BitTorrent & Piraterie
+
+**2000er:** Musik-/Film-Piraterie-Revolution
+
+**Napster (1999-2001):** Zentralisiert → Verklagt, Shutdown
+
+**BitTorrent (2001+):** Dezentral → Schwerer zu verklagen
+
+**The Pirate Bay (2003):** BitTorrent-Index
+- Blockiert, zieht um, neue Domains
+- **Whack-a-Mole-Spiel**
+
+**Rechtliche Grauzone:**
+- Protokoll selbst: Legal
+- Inhalte: Oft illegal (Urheberrecht)
+- Legitime Uses: Linux-ISOs, Open-Source, Public Domain
+
+
+
+---
+
+
+
+
+
+---
+
+# IPFS: Dezentrales Web?
+
+**IPFS = InterPlanetary File System (2015)**
+
+**Vision:** Web ohne Server
+
+**Funktionsweise:**
+- **Content-Addressable:** Dateien durch Hash identifiziert
+- **CID:** Content Identifier (`QmXyZ123...`)
+- Datei auf vielen Knoten (wie BitTorrent, aber persistent)
+- Abruf: "Gib mir Datei mit Hash X" (egal wo)
+
+**Vorteile:** Zensur-resistent, kein Single Point of Failure
+
+**Nachteile:** Langsam (noch), keine Verfügbarkeitsgarantie
+
+**Anwendung:** NFT-Speicher
+
+
+
+---
+
+
+
+
+
+---
+
+# Streaming: Real-Time-Distribution
+
+**Streaming = Daten während Empfang konsumiert**
+
+**Protokolle:**
+- **HLS** (Apple): HTTP-basiert, Segmente
+- **MPEG-DASH:** Standard, ähnlich HLS
+- **WebRTC:** Browser-zu-Browser, niedrige Latenz
+
+**Adaptive Bitrate:**
+- Stream in mehreren Qualitäten (240p-4K)
+- Player wechselt dynamisch
+- Segmente: 2-10 Sekunden
+
+**Latenz:**
+- Traditional (HLS): 10-30 Sekunden
+- Low-Latency HLS: 2-5 Sekunden
+- WebRTC: <1 Sekunde (Videocalls)
+
+
+
+---
+
+# Hands-On: Torrent & CDN
+
+**Aufgabe (40 Min):**
+
+**Teil 1: BitTorrent (20 Min)**
+1. Lade legalen Torrent (Linux-ISO: ubuntu.com)
+2. Tool: qBittorrent oder Transmission
+3. Beobachte: Peers, Seeders, Download-Speed, Upload-Speed
+
+**Teil 2: CDN-Analyse (20 Min)**
+1. Öffne populäre Website (z.B. nytimes.com)
+2. Browser DevTools → Network-Tab
+3. Schaue auf Requests: Welche CDN-Domains?
+4. Response-Headers: `X-Cache`, `CF-Ray`, etc.
+
+**Tools:** cdn77.com/cdn-check
+
+
+
+---
+
+# Aufgabe bis nächste Woche
+
+**Analysiere Streaming-Dienst oder Website:**
+
+1. Wähle: Netflix, YouTube, Spotify, News-Seite
+2. DevTools (Network-Tab):
+ - 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
+
+
+
+---
+
+
+
+# Teil 2: APIs
+## Software-Schnittstellen & Protokolle
+
+---
+
+
+
+
+
+---
+
+# Was ist eine API?
+
+**API = Application Programming Interface**
+
+**Analogie: Restaurant**
+- Du (Client) → Speisekarte (API-Dokumentation)
+- Bestellst (Request)
+- Küche bereitet zu (Backend)
+- Kellner bringt Essen (Response)
+- Du weißt nicht, WIE gekocht wird – nur WAS du kriegst
+
+**Typen:** Hardware-APIs, OS-APIs, Web-APIs, Library-APIs
+
+
+
+---
+
+
+
+
+
+---
+
+# HTTP: Das Fundament
+
+**HTTP = HyperText Transfer Protocol (1991)**
+
+**Request-Struktur:**
+- **Method:** GET, POST, PUT, DELETE
+- **URL:** Resource-Identifier
+- **Headers:** Metadaten (Content-Type, Authorization...)
+- **Body:** Optional (bei POST/PUT)
+
+**Response-Struktur:**
+- **Status Code:** 200 OK, 404 Not Found, 500 Error
+- **Headers:** Metadaten
+- **Body:** HTML, JSON, XML, Binary...
+
+
+
+---
+
+# HTTP-Methods: CRUD
+
+**CRUD = Create, Read, Update, Delete**
+
+| Method | CRUD | Beispiel |
+|--------|------|----------|
+| **GET** | Read | `/posts` → Alle Posts |
+| **POST** | Create | `/posts` → Neuer Post |
+| **PUT** | Update | `/posts/42` → Post ersetzen |
+| **PATCH** | Update | `/posts/42` → Teilupdate |
+| **DELETE** | Delete | `/posts/42` → Post löschen |
+
+**GET = Idempotent** (mehrfach ausführen = gleiches Ergebnis)
+
+
+
+---
+
+
+
+
+
+---
+
+# REST: Representational State Transfer
+
+**REST (Roy Fielding, 2000):**
+
+**Prinzipien:**
+1. **Stateless:** Jede Anfrage eigenständig
+2. **Resource-Based:** URLs = Ressourcen (`/users/123`)
+3. **HTTP-Methods:** CRUD-Operationen
+4. **Hypermedia:** Links zu verwandten Ressourcen
+
+**Beispiel: Twitter-API**
+```
+GET /tweets/123 → Tweet mit ID 123
+POST /tweets → Neuen Tweet erstellen
+DELETE /tweets/123 → Tweet löschen
+GET /users/alice/tweets → Tweets von Alice
+```
+
+
+
+---
+
+# REST-Probleme
+
+**Problem 1: Over-Fetching**
+```
+GET /users/123
+→ Gibt zurück: Name, Email, Bio, Avatar,
+ Follower-Count, Posts, Friends...
+```
+Du willst nur Name → Kriegst 90% zu viel
+
+**Problem 2: Under-Fetching**
+```
+GET /users/123 → User-Daten
+GET /users/123/posts → Alle Posts
+```
+2 Requests statt einem
+
+**Lösung:** GraphQL
+
+
+
+---
+
+
+
+
+
+---
+
+# GraphQL: Die REST-Alternative
+
+**GraphQL (Facebook, 2015):**
+
+**Idee:** Client fragt EXAKT, was er braucht
+
+**Query-Beispiel:**
+```graphql
+{
+ user(id: 123) {
+ name
+ email
+ posts(limit: 5) {
+ title
+ createdAt
+ }
+ }
+}
+```
+
+**Vorteile:**
+✓ Kein Over-/Under-Fetching
+✓ Ein Endpoint (`/graphql`)
+✓ Strongly Typed (Schema!)
+
+
+
+---
+
+# GraphQL Schema
+```graphql
+type User {
+ id: ID!
+ name: String!
+ email: String
+ posts: [Post!]!
+}
+
+type Post {
+ id: ID!
+ title: String!
+ content: String!
+ author: User!
+}
+
+type Query {
+ user(id: ID!): User
+ posts: [Post!]!
+}
+
+type Mutation {
+ createPost(title: String!, content: String!): Post!
+}
+```
+
+**`!` = Required (non-nullable)**
+
+
+
+---
+
+
+
+
+
+---
+
+# WebSockets: Real-Time
+
+**Problem mit HTTP:**
+- Request-Response-Zyklus
+- Server kann nicht "pushen"
+- Polling ineffizient
+
+**WebSocket (2011):**
+- **Bidirektionale Verbindung**
+- Bleibt offen (Persistent)
+- Server kann jederzeit senden
+
+**Anwendungen:**
+Chat (Discord), Live-Updates (Aktienkurse), Multiplayer-Games
+
+
+
+---
+
+# WebSocket: Chat-Beispiel
+
+**Flow:**
+1. Alice öffnet Chat → WebSocket-Connection
+2. Bob öffnet Chat → Eigene Connection
+3. Alice tippt: "Hi Bob!"
+4. Client sendet: `{"type": "message", "text": "Hi Bob!", "to": "bob"}`
+5. Server leitet an Bobs Connection weiter
+6. Bob empfängt, zeigt an
+
+**Kein Polling! Instant!**
+
+
+
+---
+
+
+
+
+
+---
+
+# gRPC: Google's Approach
+
+**gRPC = Google Remote Procedure Call (2015)**
+
+**Idee:** Funktion auf Remote-Server aufrufen, als wäre es lokal
+
+**Eigenschaften:**
+- **Protocol Buffers (Protobuf):** Binär, kompakt (statt JSON)
+- **HTTP/2:** Multiplexing, Bidirektional
+- **Strongly Typed**
+- **Code-Generierung** (Client/Server aus `.proto`-Datei)
+
+**Vorteile:** Performance, Streaming
+**Nachteile:** Nicht Browser-kompatibel, Debugging schwieriger
+
+
+
+---
+
+# gRPC Beispiel
+
+**`.proto`-Datei:**
+```protobuf
+service UserService {
+ rpc GetUser (UserRequest) returns (UserResponse);
+ rpc ListPosts (Empty) returns (stream Post);
+}
+
+message UserRequest {
+ int32 id = 1;
+}
+
+message UserResponse {
+ string name = 1;
+ string email = 2;
+}
+```
+
+**Code-Generierung:** Client/Server-Code automatisch generiert
+
+
+
+---
+
+# JSON: Das Standard-Format
+
+**JSON = JavaScript Object Notation**
+
+**Eigenschaften:**
+- Textbasiert, menschenlesbar
+- Schlüssel-Wert-Paare
+- Unterstützt: Objekte, Arrays, Strings, Numbers, Booleans, null
+
+**Beispiel:**
+```json
+{
+ "name": "Alice",
+ "age": 28,
+ "posts": [
+ {"title": "Hello", "views": 42},
+ {"title": "World", "views": 123}
+ ]
+}
+```
+
+
+
+---
+
+# Hands-On: API abfragen
+
+**Aufgabe (40 Min):**
+
+**Teil 1: REST-API (20 Min)**
+1. Öffentliche API: `jsonplaceholder.typicode.com`
+2. Tool: curl (Terminal) oder Postman (GUI)
+3. Beispiele:
+```bash
+curl https://jsonplaceholder.typicode.com/posts/1
+curl -X POST https://jsonplaceholder.typicode.com/posts \
+ -H "Content-Type: application/json" \
+ -d '{"title":"Test","body":"Hello","userId":1}'
+```
+4. Analysiere: Status-Code, Headers, Body
+
+**Teil 2: WebSocket (20 Min)**
+1. Öffne: `websocket.org/echo.html`
+2. Verbinde, sende Nachrichten
+3. Beobachte: Instant Response
+
+
+
+---
+
+# Aufgabe bis nächste Woche
+
+**Experimentiere mit öffentlicher API:**
+
+1. Wähle:
+ - GitHub API (`api.github.com`)
+ - 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)
+
+**Bonus:** Baue kleinen Client (Python, JavaScript, etc.)
+
+
+
+---
+
+
+
+# Teil 3: Metadaten
+## Daten über Daten & Interoperabilität
+
+---
+
+
+
+
+
+---
+
+# Was sind Metadaten?
+
+**Metadaten = Daten über Daten**
+
+**Beispiele:**
+- **Foto:** Kamera, Datum, GPS, Belichtung
+- **MP3:** Künstler, Album, Jahr, Genre, Cover
+- **PDF:** Autor, Datum, Software
+- **E-Mail:** Absender, Empfänger, Zeitstempel
+
+**Warum wichtig?**
+✓ Organisation, Suche
+✓ Kontext (Wann/Wo/Wie?)
+
+**Aber auch:**
+❌ Privacy-Risiko, Forensische Spuren
+
+
+
+---
+
+# EXIF: Exchangeable Image File Format
+
+**EXIF (1995, Kamera-Hersteller):**
+
+**Typische Daten:**
+- Kamera-Modell (z.B. "iPhone 15 Pro")
+- Datum & Uhrzeit
+- Belichtung (Blende, Verschlusszeit, ISO)
+- **GPS-Koordinaten** (Latitude, Longitude, Altitude)
+- Software (z.B. "Photoshop 2024")
+
+**Speicherort:** JPEG-Header (Binärformat)
+
+**Tools:** exiftool, ExifPurge, metapicz.com
+
+
+
+---
+
+
+
+
+
+---
+
+# EXIF: Privacy-Albtraum
+
+**Szenario 1: Stalking**
+- Foto auf Twitter: "Zuhause entspannen 🏡"
+- EXIF: GPS 52.5200° N, 13.4050° E
+- → Stalker weiß, wo du wohnst
+
+**Szenario 2: Whistleblowing**
+- Anonyme Quelle schickt PDF
+- Metadaten: "Erstellt von: John Doe, Firma XY"
+- → Quelle identifiziert
+
+**Berühmter Fall:**
+John McAfee (2012): Vice-Magazine vergaß EXIF zu entfernen
+→ GPS verriet Aufenthaltsort in Guatemala
+
+
+
+---
+
+# Social Media & EXIF-Stripping
+
+**Welche Plattformen entfernen EXIF?**
+
+✓ **Twitter/X:** Ja (seit 2015)
+✓ **Facebook/Instagram:** Ja (GPS entfernt)
+✓ **Reddit:** Ja
+❌ **WhatsApp:** Nein (privat, aber Metadaten bleiben)
+❌ **E-Mail-Anhänge:** Nein
+❌ **Cloud (Dropbox, Google Drive):** Nein
+
+**Best Practice:** EXIF manuell entfernen vor Upload
+```bash
+exiftool -all= foto.jpg # Entfernt ALLE Metadaten
+```
+
+
+
+---
+
+
+
+
+
+---
+
+# ID3-Tags: Musik-Metadaten
+
+**ID3 = Identification 3 (1996)**
+
+**Versionen:**
+- **ID3v1:** 128 Bytes am Ende (limitiert!)
+ - Titel (30 Zeichen), Artist, Album, Jahr
+- **ID3v2:** Am Anfang, variable Länge
+ - Unbegrenzte Textfelder, Cover-Art, Lyrics, BPM
+
+**Tools:**
+- Kid3 (GUI, Multi-Platform)
+- MusicBrainz Picard (Auto-Tagging!)
+- mp3tag (Windows)
+
+
+
+---
+
+
+
+
+
+---
+
+# MusicBrainz: Offene Musik-Datenbank
+
+**MusicBrainz (2000):**
+
+**Idee:** Wikipedia für Musik-Metadaten
+
+**Community-gepflegt:**
+- Künstler, Alben, Tracks
+- Relationships (Band-Mitglieder, Label...)
+- Releases (verschiedene Editionen, Länder)
+
+**MusicBrainz Picard:**
+- Audio-Fingerprinting (AcoustID)
+- Analysiert Waveform, matched mit Datenbank
+- Auto-Tagging (auch bei falsch benannten Dateien!)
+
+**Philosophie:** Open Data (gegen proprietäre Gracenote/CDDB)
+
+
+
+---
+
+# Dublin Core: Universelle Metadaten
+
+**Dublin Core (1995, Dublin, Ohio):**
+
+**15 Kern-Elemente:**
+1. Title, 2. Creator, 3. Subject, 4. Description
+5. Publisher, 6. Contributor, 7. Date, 8. Type
+9. Format, 10. Identifier (ISBN, DOI)
+11. Source, 12. Language, 13. Relation
+14. Coverage, 15. Rights
+
+**Anwendung:** Bibliotheken, Archive, Webseiten (HTML ``)
+
+
+
+---
+
+
+
+
+
+---
+
+# PDF-Metadaten: Hidden Dangers
+
+**PDF-Metadaten (XMP):**
+
+**Gespeichert:**
+- Titel, Autor, Betreff, Keywords
+- Erstellungsdatum, Änderungsdatum
+- Software, **Company** (aus Office-Lizenz!)
+
+**Versteckte Daten:**
+- Änderungshistorie (Track Changes)
+- Kommentare (vermeintlich gelöscht)
+- Ebenen (InDesign, Illustrator)
+
+**Berühmter Fall:**
+Tony Blair Dossier (2003, Irak-Krieg)
+→ PDF-Metadaten zeigten Manipulation
+
+
+
+---
+
+# Interoperabilität: Offene vs. Proprietäre
+
+**Offene Formate:**
+✓ Spezifikation öffentlich
+✓ Keine Lizenzgebühren
+✓ Viele Programme unterstützen
+**Beispiele:** PNG, OGG, MKV, Markdown, SVG
+
+**Proprietäre Formate:**
+❌ Spezifikation geheim
+❌ Oft nur in einer Software voll nutzbar
+❌ **Lock-in-Effekt**
+**Beispiele:** PSD (Photoshop), INDD (InDesign), DWG (AutoCAD), .pages
+
+
+
+---
+
+# Vendor Lock-in: Beispiele
+
+**Fall 1: Microsoft Office (.docx)**
+- Historisch: .doc undokumentiert
+- LibreOffice konnte nicht perfekt konvertieren
+- "Formatierung kaputt" → Zurück zu MS Office
+
+**Fall 2: Adobe Creative Suite**
+- PSD: Layer, Blend-Modes → Nur in Photoshop voll editierbar
+- GIMP kann öffnen, aber Features fehlen
+
+**Fall 3: Apple Ecosystem**
+- .pages, .numbers, .key → Nur auf Apple native Bearbeitung
+
+
+
+---
+
+# Datenmigration & Langzeitarchivierung
+
+**Beispiele toter Formate:**
+- WordPerfect (.wpd) – 1980-90er dominant, heute kaum lesbar
+- Lotus 1-2-3 (.wks) – Spreadsheet, verschwunden
+- Flash (.swf) – Millionen Websites/Games, seit 2020 tot
+
+**Archivierungs-Strategien:**
+1. **Migration:** Regelmäßig in aktuelle Formate konvertieren
+2. **Emulation:** Alte Software in VM
+3. **Offene Standards:** PDF/A, TIFF, Plain Text
+
+
+
+---
+
+# Metadaten für Accessibility
+
+**Alt-Text (Alternative Text):**
+```html
+
+```
+
+**Warum?**
+✓ Screen-Reader (Blinde/Sehbehinderte)
+✓ SEO (Suchmaschinen)
+✓ Fallback (Bild lädt nicht)
+
+**PDF-Tags:** Strukturierte PDFs (Überschriften, Listen)
+→ Screen-Reader kann navigieren
+
+**Video:** Closed Captions (CC), Audio Descriptions
+
+
+
+---
+
+# Hands-On: Metadaten analysieren & entfernen
+
+**Aufgabe (40 Min):**
+
+**Teil 1: EXIF (20 Min)**
+1. Nimm Foto (oder nutze altes)
+2. Analysiere: `exiftool foto.jpg` oder metapicz.com
+3. Notiere: GPS? Kamera-Modell? Software?
+4. Entferne: `exiftool -all= foto.jpg`
+5. Vergleiche Dateigrößen
+
+**Teil 2: ID3 (20 Min)**
+1. Nimm MP3-Datei
+2. Analysiere: Kid3, mp3tag, oder exiftool
+3. Ändere Tags (z.B. falscher Artist)
+4. Optional: MusicBrainz Picard (Auto-Tagging)
+
+
+
+---
+
+# Aufgabe bis nächste Woche
+
+**Metadaten-Audit:**
+
+1. Wähle 3 Dateitypen:
+ - Ein Foto (EXIF)
+ - 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?
+
+**Bonus:** Finde alte Datei (>5 Jahre) – was verraten Metadaten über damaliges Setup?
+
+
+
+---
+
+
+
+# Teil 4: Zukunft
+## Trends & Ausblick
+
+---
+
+
+
+
+
+---
+
+# Rückblick: 9 Wochen
+
+**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
+
+**Heute:** Wohin geht die Reise?
+
+
+
+---
+
+# AI-basierte Kompression
+
+**Problem:** JPEG/H.264 basieren auf 90er-Jahre-Modellen
+
+**Neue Ansätze:**
+
+1. **Neuronale Bild-Kompression:**
+ - Deep Learning lernt Kompression/Dekompression
+ - Google's "Learned Image Compression" (2018)
+ - Outperforms JPEG bei gleicher Größe
+
+2. **Generative Kompression:**
+ - Encoder extrahiert semantische Features
+ - Decoder generiert Bild neu (wie DALL-E)
+ - **99%+ Kompression**, aber nicht bit-genau!
+
+**Problem:** Hoher Rechenaufwand, keine Standardisierung
+
+
+
+---
+
+
+
+
+
+---
+
+# JPEG XL: Der moderne JPEG
+
+**JPEG XL (2021, ISO-Standard):**
+
+**Ziele:**
+✓ 60% besser als JPEG
+✓ Besser als WebP/AVIF (manchmal)
+✓ Lossless UND Lossy
+✓ Progressive Decoding (wie klassisches JPEG)
+✓ Rückwärtskompatibel (JPEG → JPEG XL "Wrapper")
+
+**Features:** HDR, Animation (wie GIF, aber besser)
+
+**Status 2025:** Browser-Support langsam (Safari ja, Chrome on-off)
+
+**Problem:** Google favorisiert WebP/AVIF → politischer Kampf
+
+
+
+---
+
+# AV1 & VVC: Codec-Krieg
+
+**AV1 (Alliance for Open Media):**
+✓ Etabliert sich (YouTube 4K, Netflix)
+✓ Hardware-Decoder in neuen GPUs/Smartphones
+
+**VVC (H.266, 2020):**
+- 50% besser als H.265
+- **Aber:** Patent-Problem (mehrere Pools, unklare Kosten)
+- Adoption gering
+
+**LCEVC:** Add-on für existierende Codecs
+
+**Zukunft:**
+- AV2 (Nachfolger AV1) in Entwicklung
+- ML integriert?
+
+
+
+---
+
+
+
+
+
+---
+
+# DNA-Storage
+
+**Konzept:** Daten in DNA-Sequenzen
+
+**Eigenschaften:**
+- Speicherdichte: **215 Petabyte/Gramm**
+- Haltbarkeit: Tausende Jahre
+- Kosten: Aktuell $3.500/MB (sinkend)
+
+**Beispiele:**
+- Microsoft + Twist Bioscience
+- Netflix "Biohackers"-Episode (2021)
+- Harvard: Wikipedia (11 GB) in DNA (2017)
+
+**Problem:** Synthese & Sequenzierung extrem langsam/teuer
+
+**Anwendung:** Langzeitarchivierung (nicht Live-Daten)
+
+
+
+---
+
+# Holografischer Speicher
+
+**Holographic Data Storage:**
+
+**Prinzip:**
+- Laser schreibt in 3D-Kristall (statt 2D-Oberfläche)
+- Interferenzmuster speichert Bits
+- Paralleler Zugriff (schnell!)
+
+**Vorteile:**
+✓ Hohe Dichte (Terabytes pro Disc)
+✓ Schnelle Lesegeschwindigkeit
+✓ Langlebig (50+ Jahre)
+
+**Stand 2025:** Prototypen (Sony, InPhase †), Kommerzialisierung gescheitert
+
+**Problem:** Teuer, Konkurrenz durch SSDs
+
+
+
+---
+
+# Quantum Storage?
+
+**Quantenspeicher:**
+
+**Konzept:**
+- Qubits statt klassische Bits
+- Superposition: 0 UND 1 gleichzeitig
+- Verschränkung: Qubits korreliert über Distanz
+
+**Anwendung:**
+- Nicht für klassische Daten (Qubits instabil)
+- Quantum Key Distribution (QKD) für Kommunikation
+- Zukunft: Quanten-RAM für Quantencomputer
+
+**Stand 2025:** Experimentell, Speicherzeit Millisekunden
+
+
+
+---
+
+# Web3 & Dezentraler Speicher
+
+**IPFS, Filecoin, Arweave, Storj:**
+
+**Idee:** Speicher ohne zentrale Server
+
+**Filecoin (2017):**
+- Blockchain-basiert
+- User vermieten Festplatten-Platz
+- Bezahlung in FIL (Kryptowährung)
+
+**Arweave (2018):**
+- "Permanent Storage"
+- Einmalige Zahlung → Daten für immer (theoretisch)
+
+**Kritik:**
+❌ Langsam vs. AWS S3
+❌ Teurer (oft)
+❌ Keine Garantie (Nodes offline)
+
+
+
+---
+
+# Streaming-Zukunft
+
+**Trends:**
+
+**8K-Streaming:**
+- 7680×4320 = 33 Megapixel/Frame
+- Braucht 100+ Mbps (selbst mit AV1)
+- Problem: Kaum Content, kaum TVs
+
+**VR/AR-Streaming:**
+- 2× 4K (pro Auge), 90-120 fps
+- Latenz <20ms kritisch
+- 5G + Edge Computing nötig
+
+**Cloud Gaming:**
+- Spiel im Rechenzentrum, Stream zu User
+- Input-Lag = Todfeind (<50ms)
+
+**Problem:** Physik (Lichtgeschwindigkeit!)
+
+
+
+---
+
+# Nachhaltigkeit
+
+**Digitalisierung ≠ Umweltfreundlich**
+
+**Rechenzentren:**
+- 2024: 1-2% globaler Stromverbrauch (steigend!)
+- Kühlung, Server, Netzwerk
+
+**Streaming:**
+- 1h Netflix (HD): ~3 GB, ~0,1 kWh
+- × Milliarden Stunden = massiver CO₂
+
+**E-Waste:**
+- Smartphones: 2-3 Jahre Lebensdauer
+- SSDs, HDDs: Nicht ewig
+
+**Lösungen:**
+- Effizientere Codecs (weniger Bandbreite)
+- Renewable Energy für Rechenzentren
+- Längere Hardware-Lebensdauer (Right to Repair!)
+
+
+
+---
+
+# Regulierung & Standardisierung
+
+**Wer entscheidet?**
+
+**Standards-Organisationen:**
+- ISO/IEC (International)
+- IETF (Internet-Protokolle)
+- W3C (Web-Standards)
+- IEEE (Hardware)
+
+**Problem:** Industrie-Dominanz
+- MPEG-LA (Patent-Pools)
+- USB-IF (Intel-dominiert)
+- HDMI Forum (Consumer-Electronics)
+
+**EU-Regulierung:**
+- USB-C-Pflicht (ab 2024)
+- DMA (Digital Markets Act): Interoperabilität
+- GDPR: Datenschutz (betrifft Metadaten!)
+
+**Zukunft:** Mehr Open Standards? Oder Fragmentierung?
+
+
+
+---
+
+# Fallstudie: Gruppenarbeit
+
+**Aufgabe (90 Min, ca. 5 Personen):**
+
+**Szenario:** Mittelständisches Medienunternehmen produziert Videos
+
+**Erarbeitet Konzept für:**
+1. Speichermedien (intern/extern, kurz-/langfristig)
+2. Dateiformate (Produktion, Distribution, Archivierung)
+3. Dateisysteme (welche für was?)
+4. Schnittstellen (SATA, USB, PCIe, Netzwerk)
+5. Distributionswege (NAS, Cloud, FTP)
+6. Backup-Strategie (3-2-1-Regel!)
+
+**Ergebnis:** Konzeptpapier (Mindmap, Tabelle, Poster)
+**Präsentation:** 5 Min pro Gruppe
+
+
+
+---
+
+# Alternative Szenarien (Auswahl)
+
+1. **Mittelständisches Medienunternehmen** (Videos, Streaming)
+2. **Kommunales Stadtarchiv** (Digitalisierung historischer Bestände)
+3. **Agentur für digitale Kommunikation** (internationale Kampagne)
+4. **Digitale Hochschul-Mediathek** (Lehrvideos, Podcasts)
+5. **Freiberufliche Fotografin** (Tausende RAW-Fotos/Jahr)
+6. **Internationales Reporterteam** (investigative Recherche, sensibel)
+
+**Jede Gruppe wählt ein Szenario**
+
+
+
+---
+
+# Was wir insgesamt gelernt haben
+
+✓ **Bits → Formate:** Encoding, Kompression (MP3, JPEG, H.264)
+✓ **Speicher:** HDD, SSD, Dateisysteme, Backup, Archivierung
+✓ **Schnittstellen:** USB-C, HDMI, DisplayPort, Ethernet
+✓ **Distribution:** CDN, P2P, Streaming, APIs
+✓ **Metadaten:** EXIF, ID3, Privacy, Interoperabilität
+✓ **Zukunft:** AI-Kompression, DNA-Storage, Nachhaltigkeit
+
+**Kernbotschaft:**
+Digitale Medien sind das Ergebnis von Standards, Politik, Kompromissen & Innovation.
+
+Ihr habt jetzt die Werkzeuge, um die digitale Welt kritisch zu verstehen.
+
+
+
+---
+
+# Weiterführende Ressourcen
+
+**Bücher:**
+- "Code" – Charles Petzold (Basics)
+- "Understanding Digital Signal Processing" – Richard Lyons
+
+**Websites:**
+- IETF RFCs (ietf.org)
+- FFmpeg Documentation (ffmpeg.org)
+- Protocol Labs (IPFS, Filecoin)
+
+**YouTube:**
+- Computerphile (Kompression, Encoding)
+- Branch Education (Hardware-Visualisierungen)
+
+**Podcasts:**
+- Command Line Heroes (Red Hat)
+
+**Tools:** MediaInfo, exiftool, FFmpeg, Wireshark
+
+
+
+---
+
+# Abschluss & Dank
+
+**Ihr habt gelernt:**
+- Dateien zu lesen (Hex, Metadaten)
+- Formate zu vergleichen (JPEG vs. PNG, H.264 vs. AV1)
+- Infrastruktur zu verstehen (CDN, P2P, APIs)
+- Kritisch zu denken (Open Standards, Lock-in, Nachhaltigkeit)
+
+**Nächste Schritte:**
+- Fallstudie (falls Prüfungsleistung)
+- Feedback willkommen (Forum, E-Mail)
+- Weiterlernen mit Ressourcen
+
+**Vielen Dank für eure Aufmerksamkeit!**
+
+
+
+---
+
+
+
+# Fragen & Diskussion
+
+**Kontakt:** czechowski@hdm-stuttgart.de
+**Folien:** Online verfügbar unter https://hdm.librete.ch
+
+---
+
+# Lizenz & Attribution
+
+Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
+
+- Erlaubt Teilen & Anpassen mit Namensnennung
+- Adaptionen müssen unter gleicher Lizenz geteilt werden
+
+Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
+
diff --git a/slides/2026-xx-xx-termin-5-vertiefung-offene-fragen.md b/slides/2026-xx-xx-termin-5-vertiefung-offene-fragen.md
new file mode 100644
index 0000000..915381d
--- /dev/null
+++ b/slides/2026-xx-xx-termin-5-vertiefung-offene-fragen.md
@@ -0,0 +1,67 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
+footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+---
+
+
+
+
+
+
+
+---
+
+
+
+# Termin 5 – TBA
+## Vertiefung & Offene Fragen
+
+---
+
+# Ersatztermin
+
+**Dieser Termin wird noch bekannt gegeben.**
+
+Mögliche Inhalte:
+- Vertiefung von Themen nach Wunsch
+- Praxisübungen & Hands-On
+- Offene Fragen & Diskussion
+- Prüfungsvorbereitung
+
+
+
+---
+
+
+
+# Fragen & Diskussion
+
+**Kontakt:** czechowski@hdm-stuttgart.de
+**Folien:** Online verfügbar unter https://hdm.librete.ch
+
+---
+
+# Lizenz & Attribution
+
+Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
+
+- Erlaubt Teilen & Anpassen mit Namensnennung
+- Adaptionen müssen unter gleicher Lizenz geteilt werden
+
+Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
+
diff --git a/slides/assets/ascii-table.png b/slides/assets/ascii-table.png
new file mode 100644
index 0000000..d30d409
Binary files /dev/null and b/slides/assets/ascii-table.png differ
diff --git a/slides/assets/audio-spectrogram.png b/slides/assets/audio-spectrogram.png
new file mode 100644
index 0000000..62fcc7e
Binary files /dev/null and b/slides/assets/audio-spectrogram.png differ
diff --git a/slides/assets/av1-logo.png b/slides/assets/av1-logo.png
new file mode 100644
index 0000000..5677a32
Binary files /dev/null and b/slides/assets/av1-logo.png differ
diff --git a/slides/assets/cassette-ipod.png b/slides/assets/cassette-ipod.png
new file mode 100644
index 0000000..51ded5a
Binary files /dev/null and b/slides/assets/cassette-ipod.png differ
diff --git a/slides/assets/compression-types.png b/slides/assets/compression-types.png
new file mode 100644
index 0000000..9293fef
Binary files /dev/null and b/slides/assets/compression-types.png differ
diff --git a/slides/assets/container-codec-diagram.png b/slides/assets/container-codec-diagram.png
new file mode 100644
index 0000000..71679e9
Binary files /dev/null and b/slides/assets/container-codec-diagram.png differ
diff --git a/slides/assets/digital-landscape.png b/slides/assets/digital-landscape.png
new file mode 100644
index 0000000..1be1abe
Binary files /dev/null and b/slides/assets/digital-landscape.png differ
diff --git a/slides/assets/gif-animation.png b/slides/assets/gif-animation.png
new file mode 100644
index 0000000..ab50bc4
Binary files /dev/null and b/slides/assets/gif-animation.png differ
diff --git a/slides/assets/grayscale-gradient.png b/slides/assets/grayscale-gradient.png
new file mode 100644
index 0000000..3faa51e
Binary files /dev/null and b/slides/assets/grayscale-gradient.png differ
diff --git a/slides/assets/hex-binary-table.png b/slides/assets/hex-binary-table.png
new file mode 100644
index 0000000..a7d8869
Binary files /dev/null and b/slides/assets/hex-binary-table.png differ
diff --git a/slides/assets/hexeditor-screenshot.png b/slides/assets/hexeditor-screenshot.png
new file mode 100644
index 0000000..378b684
Binary files /dev/null and b/slides/assets/hexeditor-screenshot.png differ
diff --git a/slides/assets/iframe-pframe-diagram.png b/slides/assets/iframe-pframe-diagram.png
new file mode 100644
index 0000000..8b3a4fd
Binary files /dev/null and b/slides/assets/iframe-pframe-diagram.png differ
diff --git a/slides/assets/instagram-quality-loss.png b/slides/assets/instagram-quality-loss.png
new file mode 100644
index 0000000..f4bdf87
Binary files /dev/null and b/slides/assets/instagram-quality-loss.png differ
diff --git a/slides/assets/jpeg-artifacts.png b/slides/assets/jpeg-artifacts.png
new file mode 100644
index 0000000..64b95f6
Binary files /dev/null and b/slides/assets/jpeg-artifacts.png differ
diff --git a/slides/assets/karlheinz-brandenburg.jpg b/slides/assets/karlheinz-brandenburg.jpg
new file mode 100644
index 0000000..ba3579b
Binary files /dev/null and b/slides/assets/karlheinz-brandenburg.jpg differ
diff --git a/slides/assets/lightbulb-onoff.png b/slides/assets/lightbulb-onoff.png
new file mode 100644
index 0000000..ef11de4
Binary files /dev/null and b/slides/assets/lightbulb-onoff.png differ
diff --git a/slides/assets/matrix-code.png b/slides/assets/matrix-code.png
new file mode 100644
index 0000000..d962969
Binary files /dev/null and b/slides/assets/matrix-code.png differ
diff --git a/slides/assets/napster-interface.png b/slides/assets/napster-interface.png
new file mode 100644
index 0000000..46fbc8a
Binary files /dev/null and b/slides/assets/napster-interface.png differ
diff --git a/slides/assets/netflix-4k.png b/slides/assets/netflix-4k.png
new file mode 100644
index 0000000..9c8228a
Binary files /dev/null and b/slides/assets/netflix-4k.png differ
diff --git a/slides/assets/photo-comparison.png b/slides/assets/photo-comparison.png
new file mode 100644
index 0000000..89945a3
Binary files /dev/null and b/slides/assets/photo-comparison.png differ
diff --git a/slides/assets/rgb-color-model.png b/slides/assets/rgb-color-model.png
new file mode 100644
index 0000000..6f25cb7
Binary files /dev/null and b/slides/assets/rgb-color-model.png differ
diff --git a/slides/assets/streaming-quality-switch.png b/slides/assets/streaming-quality-switch.png
new file mode 100644
index 0000000..7f83ef7
Binary files /dev/null and b/slides/assets/streaming-quality-switch.png differ
diff --git a/slides/assets/suzanne-vega.jpg b/slides/assets/suzanne-vega.jpg
new file mode 100644
index 0000000..737082b
Binary files /dev/null and b/slides/assets/suzanne-vega.jpg differ
diff --git a/slides/assets/youtube-vp9.png b/slides/assets/youtube-vp9.png
new file mode 100644
index 0000000..3ac2ee6
Binary files /dev/null and b/slides/assets/youtube-vp9.png differ
diff --git a/slides/materials/wtf1 b/slides/materials/wtf1
new file mode 100644
index 0000000..a11e251
--- /dev/null
+++ b/slides/materials/wtf1
@@ -0,0 +1 @@
+Dies ist eine einfache Textdatei. Keine Magic Number hier! Plaintext hat keinen Standard-Header.
diff --git a/slides/materials/wtf2 b/slides/materials/wtf2
new file mode 100644
index 0000000..6f25cb7
Binary files /dev/null and b/slides/materials/wtf2 differ
diff --git a/slides/materials/wtf3 b/slides/materials/wtf3
new file mode 100644
index 0000000..ba3579b
Binary files /dev/null and b/slides/materials/wtf3 differ