add diday and palantir slides to 223015c chapter 1

- add cd logo, cd player, dvd, artemis images
- add artemis ii slide with apollo comparison and bandwidth calculation
- regenerate hex-dec lookup table as 16x16 grid with ascii highlight
- move hex-dec table next to hexadezimal slides
- fix mp3 bitrate: 320 -> 128 kbps to match stated file size

AGENTS.md

@@ -0,0 +1,197 @@
+# AGENTS.md - Agent Guidelines for HdM Slides
+
+This file contains comprehensive guidelines for agentic coding agents working on the HdM Slides project.
+
+## Project Overview
+
+This project builds presentation decks for Marp, supporting multiple courses:
+- **223015b** - Dateiformate, Schnittstellen, Speichermedien (6 Kapitel)
+- **223015c** - Internettechnologien (3 Kapitel)
+
+## Development Workflow
+
+### Build Commands
+```bash
+# Development
+make dev              # Start single dev server on port 3000
+npm run dev           # Alternative command for development server
+
+# Build
+make build            # Build all courses (HTML + PDF)
+make build-b          # Build 223015b only
+make build-c          # Build 223015c only
+make html             # HTML only builds
+make pdf              # PDF only builds
+
+# Klausur Folien
+make klausur          # Extract klausurfolien for all courses
+make klausur-b        # Extract klausurfolien for 223015b
+make klausur-c        # Extract klausurfolien for 223015c
+
+# Deployment
+make deploy            # Deploy all courses (requires explicit permission)
+make deploy-b         # Deploy 223015b only
+make deploy-c         # Deploy 223015c only
+
+# Utilities
+make qr URL=...       # Generate QR code
+make optimize-images COURSE=223015b  # Resize images
+make clean            # Remove generated files
+```
+
+### Testing
+No specific test framework is used. To validate changes:
+1. Start dev server: `make dev`
+2. Open http://localhost:3000/223015b/ or /223015c/
+3. Verify slides render correctly
+4. Run `make build` to ensure no build errors
+5. Check generated files in `build/` directory
+
+## Code Style Guidelines
+
+### File Structure
+- Slides in `slides/<course>/` following naming pattern `NN-topic.md`
+- Assets in `slides/<course>/assets/`
+- Always reference images as `./assets/filename.png`
+- Scripts in `scripts/`
+- Themes in `themes/`
+- Generated output in `build/` (gitignored)
+
+### Naming Conventions
+- Slide files: `NN-topic.md` (e.g., `01-grundlagen.md`, `02-bilder.md`)
+- Images: `snake_case.jpg` or `kebab-case.jpg`
+- Klausur files: `klausurfolien.md` (auto-generated)
+- Function names in scripts: `snake_case`
+- Variable names in scripts: `snake_case`
+
+### Markdown Style
+- Use ATX-style headers (`# ## ###`)
+- YAML frontmatter for slide metadata at top of each file
+- Never include a final `---` (creates empty slide)
+- Use `<!-- _class: klausur -->` for exam-relevant slides
+- Use relative paths for assets: `./assets/image.png`
+
+### Script Style
+- Use `#!/usr/bin/env bash` shebang
+- Use `set -e` for error handling
+- Use `2>/dev/null || true` for optional operations
+- Define variables in UPPER_CASE at script top
+- Use colors for terminal output: `\033[0;32m` etc.
+
+### Git Workflow
+- Commit messages: ALWAYS lowercase
+- NEVER add co-authoring lines or generated footers
+- Follow semantic naming: "add-...", "fix-...", "update-..."
+- Commit changes to scripts, Makefile, documentation separately from slide content
+
+## Agent Restrictions
+
+### Security
+- NEVER run commands outside `/home/mwc/Coding/hdm` folder
+- NEVER run build/deploy commands without explicit user request
+- NEVER run deploy commands (make deploy, scp, etc.) without explicit permission
+
+### File Protection
+Slide files in `slides/*/*.md` are main content files:
+- **ALLOWED**: Adding slides, adjusting content, fixing typos, enhancing sections
+- **FORBIDDEN** (without permission): Deleting slides, removing sections, bulk deletions
+- Before ANY deletion: ALWAYS ask user for confirmation
+
+### Klausur Handling
+- Klausur files (`klausurfolien.md`) are auto-generated
+- NEVER edit klausurfolien.md files directly
+- To update klausurfolien: edit source slides with `<!-- _class: klausur -->` markers
+- Run `make klausur` to regenerate
+
+## Development Patterns
+
+### Adding New Slides
+1. Create new file following `NN-topic.md` pattern
+2. Copy frontmatter from existing slides in the same course
+3. Update Makefile `_KAPITEL` variable if needed
+4. Test with `make dev`
+
+### Modifying Existing Slides
+1. Edit the appropriate markdown file in `slides/<course>/`
+2. Maintain consistent styling with course theme
+3. Preserve image paths as `./assets/...`
+4. Test changes with dev server
+
+### Working with Assets
+1. Place images in `slides/<course>/assets/`
+2. Use descriptive names: `diagram-network.jpg`, `example-code.png`
+3. Optimize with `make optimize-images COURSE=223015b`
+4. Reference as `./assets/filename.ext`
+
+### Course-Specific Configuration
+Each course has specific settings in Makefile:
+- Course name and title
+- Kapitel list (slide files)
+- Deploy path
+- Theme colors (in generate-index.sh)
+
+## Common Tasks
+
+### Debugging Build Issues
+1. Check Makefile syntax: `make -n build`
+2. Verify Marp CLI installation: `npx @marp-team/marp-cli --version`
+3. Check file permissions: `ls -la slides/`
+4. Validate markdown syntax with dev server
+
+### Updating Course Structure
+1. Update `_KAPITEL` variables in Makefile
+2. Ensure slide files follow naming convention
+3. Update course-specific themes if needed
+4. Test both dev and build processes
+
+### Working with Themes
+- Custom theme in `themes/custom-theme.css`
+- Course themes defined in individual slide frontmatter
+- Use consistent color schemes per course
+- Test theme changes across all slides
+
+## Deployment Process
+
+Deployment to production server requires explicit permission:
+1. Build process: `make build` (HTML + PDF)
+2. Index generation: automatically handled
+3. Deploy to remote server via SCP
+4. Root index deployment
+
+**IMPORTANT**: Never run deployment commands without explicit user permission.
+
+## Tools and Dependencies
+
+### Core Dependencies
+- Marp CLI for slide rendering
+- Bash scripts for automation
+- Make for build orchestration
+- Git for version control
+
+### Optional Tools
+- qrencode for QR generation (via nix)
+- ImageMagick for image optimization
+- Python 3 for simple HTTP server (legacy)
+
+## Testing Strategy
+
+Since there's no formal test suite:
+1. Manual testing with dev server
+2. Build process validation
+3. Slide rendering checks
+4. Asset path verification
+5. Cross-browser compatibility checks (important)
+
+## Troubleshooting
+
+### Common Issues
+- **Port conflicts**: Use `make dev-kill` to clean up processes
+- **Build failures**: Check file permissions and Marp CLI installation
+- **Asset loading**: Verify relative paths and file existence
+- **Deploy issues**: Check SSH keys and remote permissions
+
+### Getting Help
+1. Check this AGENTS.md file first
+2. Review Makefile targets and scripts
+3. Test changes incrementally
+4. Maintain backup of working configurations

CLAUDE.md

@@ -12,6 +12,7 @@ This project builds presentation decks for Marp, supporting multiple courses.
 - Agent NEVER runs commands outside this folder
 - Agent NEVER runs build/deploy commands without explicit user request
 - Agent NEVER runs deploy commands (make deploy, scp, etc.) without explicit user permission
+- Agent NEVER runs `git checkout --` or `git restore` on files with uncommitted work. To undo specific changes, use targeted Edit operations instead.
 
 ## Critical File Protection
 
@@ -34,8 +35,9 @@ build/                  # Generated output (gitignored)
 ## Build Commands
 
 ```bash
-make dev-b          # Dev server 223015b (port 1311)
-make dev-c          # Dev server 223015c (port 1312)
+make dev            # Marp live server all courses (port 1312, HMR)
+make dev-b          # Marp live server 223015b (port 1313, HMR)
+make dev-c          # Marp live server 223015c (port 1314, HMR)
 make build          # Build all courses
 make build-b        # Build 223015b only
 make build-c        # Build 223015c only
@@ -48,10 +50,7 @@ make deploy         # Deploy all (ASK FIRST!)
 ## Nix Flake Commands
 
 ```bash
-nix develop                           # Dev shell with all tools
-nix run .#qr -- "https://example.com" # Generate QR code
-nix run .#qr-slides -- 223015b        # QR for course
-nix run .#optimize-img -- <path>      # Optimize images
+nix develop                           # Dev shell with all tools (node 22, npm, make)
 ```
 
 ## Code Style Guidelines

Makefile

@@ -7,19 +7,13 @@
 COURSES = 223015b 223015c
 SLIDES_DIR = slides
 
-# Port configuration (index starts at BASE_PORT, courses increment from there)
-BASE_PORT = 1310
-INDEX_PORT = $(BASE_PORT)
-
 # Course-specific settings
 223015b_NAME = Dateiformate, Schnittstellen, Speichermedien
-223015b_PORT = 1311
-223015b_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen klausur
+223015b_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen klausurfolien klausurfragen
 223015b_DEPLOY_PATH = /home/tengo/html/hdm/223015b
 
 223015c_NAME = Internettechnologien
-223015c_PORT = 1312
-223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausur
+223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien klausurfragen
 223015c_DEPLOY_PATH = /home/tengo/html/hdm/223015c
 
 DEPLOY_HOST = tengo@tuttle.uberspace.de
@@ -33,9 +27,9 @@ help:
 	@echo "  223015c - Internettechnologien"
 	@echo ""
 	@echo "Development:"
-	@echo "  make dev         - Both servers + index (ports 1311, 1312, 1313)"
-	@echo "  make dev-b       - Dev server for 223015b (port 1312)"
-	@echo "  make dev-c       - Dev server for 223015c (port 1313)"
+	@echo "  make dev         - Marp live server all courses (port 1312, HMR)"
+	@echo "  make dev-b       - Marp live server 223015b (port 1313, HMR)"
+	@echo "  make dev-c       - Marp live server 223015c (port 1314, HMR)"
 	@echo ""
 	@echo "Build:"
 	@echo "  make build       - Build all courses"
@@ -43,7 +37,7 @@ help:
 	@echo "  make build-c     - Build 223015c only"
 	@echo "  make pdf         - Export all to PDF"
 	@echo "  make html        - Export all to HTML"
-	@echo "  make klausur     - Extract klausur slides"
+	@echo "  make klausur     - Extract klausurfolien slides"
 	@echo ""
 	@echo "Tools:"
 	@echo "  make qr URL=...  - Generate QR code for URL"
@@ -63,24 +57,20 @@ build/.exists:
 	@mkdir -p build/223015b build/223015c
 	@touch $@
 
-# Development servers
+# Development server (Marp live server with HMR)
 dev:
 	@./scripts/dev-server.sh
 
-dev-kill:
-	@-pkill -f "python3 -m http.server" 2>/dev/null || true
-	@-pkill -f "marp-cli.*--server" 2>/dev/null || true
-	@sleep 0.5
-
 dev-b:
-	@echo "Starting 223015b dev server on port $(223015b_PORT)..."
-	@echo "Open: http://localhost:$(223015b_PORT)"
-	PORT=$(223015b_PORT) npx @marp-team/marp-cli --server $(SLIDES_DIR)/223015b/
+	@./scripts/dev-server.sh 223015b 1313
 
 dev-c:
-	@echo "Starting 223015c dev server on port $(223015c_PORT)..."
-	@echo "Open: http://localhost:$(223015c_PORT)"
-	PORT=$(223015c_PORT) npx @marp-team/marp-cli --server $(SLIDES_DIR)/223015c/
+	@./scripts/dev-server.sh 223015c 1314
+
+dev-kill:
+	@-fuser -k 1312/tcp 2>/dev/null || true
+	@-fuser -k 1313/tcp 2>/dev/null || true
+	@-fuser -k 1314/tcp 2>/dev/null || true
 
 # Build functions
 define build_course
@@ -158,7 +148,7 @@ klausur-c:
 	@./scripts/extract-klausur.sh 223015c
 
 klausur: klausur-b klausur-c
-	@echo "Klausur slides extracted for all courses!"
+	@echo "Klausurfolien slides extracted for all courses!"
 
 # QR Code generation (uses nix-shell)
 qr:
@@ -198,7 +188,8 @@ HDM_DEPLOY_PATH = /home/tengo/html/hdm
 
 build-index: build/.exists
 	@echo "Building root index..."
-	@echo '<!DOCTYPE html><html lang="de"><head><meta charset="UTF-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>HdM Vorlesungen</title><style>*{box-sizing:border-box;margin:0;padding:0}body{font-family:-apple-system,BlinkMacSystemFont,"SF Pro Display","Segoe UI",Roboto,sans-serif;max-width:720px;margin:0 auto;padding:3rem 1.5rem;background:#fafafa;color:#1d1d1f;line-height:1.5}h1{font-size:2rem;font-weight:600;letter-spacing:-0.02em;margin-bottom:.5rem}.subtitle{color:#86868b;font-size:1rem}.courses{margin-top:2rem;display:flex;flex-direction:column;gap:.75rem}a.course{display:block;background:#fff;border-radius:12px;padding:1.5rem;text-decoration:none;color:inherit;box-shadow:0 1px 3px rgba(0,0,0,0.08);transition:all .2s ease;cursor:pointer}a.course:hover{transform:translateY(-2px);box-shadow:0 4px 12px rgba(0,0,0,0.12)}.course-label{font-size:.7rem;font-weight:600;text-transform:uppercase;letter-spacing:.05em}.course-b .course-label{color:#1e5f8a}.course-c .course-label{color:#d63384}.course-title{font-size:1.15rem;font-weight:500;color:#1d1d1f;margin:.25rem 0}.course-info{font-size:.85rem;color:#86868b}.section-title{font-size:1rem;font-weight:600;color:#86868b;margin-top:2.5rem;margin-bottom:.75rem}.references{display:flex;flex-direction:column;gap:.75rem}footer{margin-top:2.5rem;padding-top:1.5rem;border-top:1px solid #e5e5e7;color:#86868b;font-size:.85rem}footer a{color:#1d1d1f;text-decoration:none}footer a:hover{text-decoration:underline}.qr-section{margin-top:2.5rem;padding:1.5rem;background:#fff;border-radius:12px;box-shadow:0 1px 3px rgba(0,0,0,0.08);text-align:center}.qr-code{width:100%;height:auto}.qr-url{margin-top:.75rem;font-size:.85rem;color:#86868b}</style></head><body><h1>HdM Vorlesungen</h1><p class="subtitle">Wintersemester 2025/26 · Michael Czechowski</p><div class="courses"><a class="course course-b" href="223015b/"><span class="course-label">223015b</span><div class="course-title">Dateiformate, Schnittstellen, Speichermedien & Distributionswege</div><span class="course-info">6 Kapitel · Modul "Technik 1"</span></a><a class="course course-c" href="223015c/"><span class="course-label">223015c</span><div class="course-title">Grundlagen IT- und Internettechnik</div><span class="course-info">3 Kapitel · Modul "Technik 1"</span></a></div><h2 class="section-title">Referenzen</h2><div class="references"><a class="course" href="https://codecrispi.es/"><span class="course-label">Plattform</span><div class="course-title">Code Crispies</div><span class="course-info">Selbstlernplattform</span></a></div><div class="qr-section"><img src="qr-root.svg" alt="QR Code" class="qr-code"><p class="qr-url">https://librete.ch/hdm/</p></div><footer><a href="mailto:mail@librete.ch">Kontakt</a></footer></body></html>' > build/index.html
+	@mkdir -p build
+	@./scripts/generate-root-index.sh
 
 # Deploy
 define deploy_course

README.md

@@ -27,10 +27,12 @@ build/                # Generated output (gitignored)
 ## Development
 
 ```bash
-# Start dev servers (hot reload)
-make dev              # All courses + index
-make dev-b            # 223015b only (port 1311)
-make dev-c            # 223015c only (port 1312)
+# Start development server (hot reload)
+make dev              # Single server for all courses (port 3000)
+
+# Access individual courses:
+# 223015b: http://localhost:3000/223015b/
+# 223015c: http://localhost:3000/223015c/
 ```
 
 ## Build
@@ -43,7 +45,7 @@ make html             # HTML only
 make pdf              # PDF only
 ```
 
-## Klausur Slides
+## Klausur Folien
 
 Extract exam-relevant slides (marked with `<!-- _class: klausur -->`) into a single file:
 
@@ -53,7 +55,7 @@ make klausur-b        # 223015b only
 make klausur-c        # 223015c only
 ```
 
-Output: `slides/<course>/klausur.md`
+Output: `slides/<course>/klausurfolien.md`
 
 The generated file includes:
 - A title slide per kapitel for orientation

flake.nix

@@ -1,5 +1,5 @@
 {
-  description = "HdM Slides - Marp presentation builder with tools";
+  description = "HdM Slides - Marp presentation builder";
 
   inputs = {
     nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
@@ -9,114 +9,19 @@
   outputs = { self, nixpkgs, flake-utils }:
     flake-utils.lib.eachDefaultSystem (system:
       let
-        pkgs = nixpkgs.legacyPackages.${system};
-
-        # QR code generator script
-        qr-gen = pkgs.writeShellScriptBin "qr" ''
-          if [ -z "$1" ]; then
-            echo "Usage: qr <url> [output.png]"
-            echo ""
-            echo "Examples:"
-            echo "  qr https://example.com"
-            echo "  qr https://example.com my-qr.png"
-            echo "  qr 'https://librete.ch/hdm/223015b/' slides-qr.png"
-            exit 1
-          fi
-
-          URL="$1"
-          OUTPUT="''${2:-qr-code.png}"
-
-          ${pkgs.qrencode}/bin/qrencode -o "$OUTPUT" -s 10 -m 2 "$URL"
-          echo "Generated: $OUTPUT"
-        '';
-
-        # QR code for course slides
-        qr-slides = pkgs.writeShellScriptBin "qr-slides" ''
-          COURSE="''${1:-223015b}"
-          OUTPUT="''${2:-build/$COURSE/qr-$COURSE.png}"
-
-          mkdir -p "$(dirname "$OUTPUT")"
-          ${pkgs.qrencode}/bin/qrencode -o "$OUTPUT" -s 10 -m 2 "https://librete.ch/hdm/$COURSE/"
-          echo "Generated QR for $COURSE: $OUTPUT"
-        '';
-
-        # Image optimizer script
-        optimize-img = pkgs.writeShellScriptBin "optimize-img" ''
-          if [ -z "$1" ]; then
-            echo "Usage: optimize-img <image-or-directory> [max-width]"
-            echo ""
-            echo "Resizes images to max width (default: 1920px)"
-            exit 1
-          fi
-
-          TARGET="$1"
-          MAX_WIDTH="''${2:-1920}"
-
-          if [ -d "$TARGET" ]; then
-            for img in "$TARGET"/*.{png,jpg,jpeg,webp} 2>/dev/null; do
-              [ -f "$img" ] || continue
-              echo "Optimizing: $(basename "$img")"
-              ${pkgs.imagemagick}/bin/magick "$img" -resize "''${MAX_WIDTH}x>" -quality 85 "$img"
-            done
-          elif [ -f "$TARGET" ]; then
-            echo "Optimizing: $TARGET"
-            ${pkgs.imagemagick}/bin/magick "$TARGET" -resize "''${MAX_WIDTH}x>" -quality 85 "$TARGET"
-          else
-            echo "Error: $TARGET not found"
-            exit 1
-          fi
-          echo "Done!"
-        '';
-
+        pkgs = import nixpkgs { inherit system; };
       in {
-        # Development shell with all tools
         devShells.default = pkgs.mkShell {
           buildInputs = with pkgs; [
-            nodejs_20
+            nodejs_22
             nodePackages.npm
-            qrencode
-            imagemagick
             gnumake
           ];
 
           shellHook = ''
-            echo "HdM Slides Development Environment"
-            echo ""
-            echo "Available commands:"
-            echo "  make dev-b     - Start 223015b dev server (port 1312)"
-            echo "  make dev-c     - Start 223015c dev server (port 1313)"
-            echo "  make build     - Build all courses"
-            echo "  qr <url>       - Generate QR code"
-            echo "  qr-slides 223015b - Generate QR for course"
-            echo "  optimize-img <dir> - Optimize images"
-            echo ""
+            echo "HdM Slides - run 'make' for available commands"
           '';
         };
-
-        # Standalone apps
-        packages = {
-          qr = qr-gen;
-          qr-slides = qr-slides;
-          optimize-img = optimize-img;
-          default = qr-gen;
-        };
-
-        # Direct runnable apps
-        apps = {
-          qr = {
-            type = "app";
-            program = "${qr-gen}/bin/qr";
-          };
-          qr-slides = {
-            type = "app";
-            program = "${qr-slides}/bin/qr-slides";
-          };
-          optimize-img = {
-            type = "app";
-            program = "${optimize-img}/bin/optimize-img";
-          };
-          default = self.apps.${system}.qr;
-        };
       }
     );
 }

package.json

@@ -3,13 +3,14 @@
   "version": "1.0.0",
   "description": "HdM Stuttgart - Lecture Slides (Marp)",
   "scripts": {
-    "dev:b": "PORT=1312 marp --server --allow-local-files courses/223015b/slides/",
-    "dev:c": "PORT=1313 marp --server --allow-local-files courses/223015c/slides/",
+    "dev": "PORT=3000 marp --server --allow-local-files slides/",
     "build": "make build",
     "build:b": "make build-b",
     "build:c": "make build-c",
     "pdf": "make pdf",
     "html": "make html",
+    "klausur": "make klausur",
+    "deploy": "make deploy",
     "test": "echo \"No tests specified\" && exit 0"
   },
   "keywords": ["marp", "slides", "hdm", "lectures"],

scripts/dev-server.sh

@@ -1,106 +1,44 @@
 #!/usr/bin/env bash
-# Development server script for HdM slides
-# Starts index server + marp servers for each course
+# Development server for HdM slides
+# Usage:
+#   ./dev-server.sh              - Marp live server for all courses (port 1312)
+#   ./dev-server.sh 223015b 1313 - Marp live server for single course
+#   ./dev-server.sh 223015c 1314 - Marp live server for single course
 
 set -e
 
 # Configuration
-INDEX_PORT=1310
-COURSE_B_PORT=1311
-COURSE_C_PORT=1312
 SLIDES_DIR="slides"
-DEV_INDEX_DIR=".dev-index"
+COURSE="${1:-}"
+DEV_PORT="${2:-1312}"
 
 # Colors
-RED='\033[0;31m'
 GREEN='\033[0;32m'
 BLUE='\033[0;34m'
+RED='\033[0;31m'
 NC='\033[0m' # No Color
 
-# Cleanup function
-cleanup() {
-    echo -e "\n${RED}Shutting down servers...${NC}"
-    kill $PID_INDEX $PID_B $PID_C 2>/dev/null || true
-    exit 0
-}
-
-# Kill existing processes on our ports
-kill_existing() {
-    echo -e "${BLUE}Cleaning up existing processes...${NC}"
-    # Kill marp processes first
-    pkill -9 -f "marp-cli" 2>/dev/null || true
-    pkill -f "python3 -m http.server" 2>/dev/null || true
-    # Kill ports including marp's WebSocket ports (37717-37720 range)
-    fuser -k $INDEX_PORT/tcp $COURSE_B_PORT/tcp $COURSE_C_PORT/tcp 2>/dev/null || true
-    fuser -k 37717/tcp 37718/tcp 37719/tcp 37720/tcp 2>/dev/null || true
-    sleep 2
-}
-
-# Generate dev index
-generate_index() {
-    mkdir -p "$DEV_INDEX_DIR"
-    cat > "$DEV_INDEX_DIR/index.html" << 'EOF'
-<!DOCTYPE html>
-<html lang="de">
-<head>
-  <meta charset="UTF-8">
-  <meta name="viewport" content="width=device-width,initial-scale=1">
-  <title>HdM Slides - Dev</title>
-  <style>
-    *{box-sizing:border-box;margin:0;padding:0}
-    body{font-family:-apple-system,BlinkMacSystemFont,"SF Pro Display","Segoe UI",Roboto,sans-serif;max-width:720px;margin:0 auto;padding:3rem 1.5rem;background:#fafafa;color:#1d1d1f;line-height:1.5}
-    h1{font-size:2rem;font-weight:600;letter-spacing:-0.02em;margin-bottom:.5rem}
-    .subtitle{color:#86868b;font-size:1rem}
-    .courses{margin-top:2rem;display:flex;flex-direction:column;gap:.75rem}
-    a.course{display:block;background:#fff;border-radius:12px;padding:1.5rem;text-decoration:none;color:inherit;box-shadow:0 1px 3px rgba(0,0,0,0.08);transition:all .2s ease;cursor:pointer}
-    a.course:hover{transform:translateY(-2px);box-shadow:0 4px 12px rgba(0,0,0,0.12)}
-    .course-label{font-size:.7rem;font-weight:600;text-transform:uppercase;letter-spacing:.05em}
-    .course-b .course-label{color:#1e5f8a}
-    .course-c .course-label{color:#d63384}
-    .course-title{font-size:1.15rem;font-weight:500;color:#1d1d1f;margin:.25rem 0}
-    .course-info{font-size:.85rem;color:#86868b}
-  </style>
-</head>
-<body>
-  <h1>HdM Slides</h1>
-  <p class="subtitle">Development Server</p>
-  <div class="courses">
-EOF
-    echo "    <a class=\"course course-b\" href=\"http://localhost:$COURSE_B_PORT\"><span class=\"course-label\">223015b</span><div class=\"course-title\">Dateiformate, Schnittstellen, Speichermedien & Distributionswege</div><span class=\"course-info\">Port $COURSE_B_PORT</span></a>" >> "$DEV_INDEX_DIR/index.html"
-    echo "    <a class=\"course course-c\" href=\"http://localhost:$COURSE_C_PORT\"><span class=\"course-label\">223015c</span><div class=\"course-title\">Grundlagen IT- und Internettechnik</div><span class=\"course-info\">Port $COURSE_C_PORT</span></a>" >> "$DEV_INDEX_DIR/index.html"
-    cat >> "$DEV_INDEX_DIR/index.html" << 'EOF'
-  </div>
-</body>
-</html>
-EOF
+# Kill existing process on our port only
+kill_port() {
+    fuser -k "$DEV_PORT/tcp" 2>/dev/null || true
+    sleep 0.5
 }
 
 # Main
-trap cleanup SIGINT SIGTERM
+trap 'echo -e "\n${RED}Shutting down...${NC}"; kill 0; exit 0' SIGINT SIGTERM
 
-kill_existing
-generate_index
+kill_port
 
-echo -e "${GREEN}Starting development servers...${NC}"
-echo ""
-echo -e "  Index:    ${BLUE}http://localhost:$INDEX_PORT${NC}"
-echo -e "  223015b:  ${BLUE}http://localhost:$COURSE_B_PORT${NC}"
-echo -e "  223015c:  ${BLUE}http://localhost:$COURSE_C_PORT${NC}"
-echo ""
-echo -e "Press ${RED}Ctrl+C${NC} to stop all servers"
+if [ -n "$COURSE" ]; then
+    SERVE_DIR="$SLIDES_DIR/$COURSE"
+    echo -e "${GREEN}Marp dev server${NC} · ${BLUE}$COURSE${NC}"
+else
+    SERVE_DIR="$SLIDES_DIR"
+    echo -e "${GREEN}Marp dev server${NC} · ${BLUE}all courses${NC}"
+fi
+
+echo -e "  ${BLUE}http://localhost:$DEV_PORT${NC}"
+echo -e "  ${BLUE}$SERVE_DIR/${NC}"
 echo ""
 
-# Start servers
-python3 -m http.server $INDEX_PORT --directory "$DEV_INDEX_DIR" &
-PID_INDEX=$!
-
-PORT=$COURSE_B_PORT npx @marp-team/marp-cli --server "$SLIDES_DIR/223015b/" &
-PID_B=$!
-
-sleep 3  # Stagger starts to avoid WebSocket port collision
-
-PORT=$COURSE_C_PORT npx @marp-team/marp-cli --server "$SLIDES_DIR/223015c/" &
-PID_C=$!
-
-# Wait for any process to exit
-wait
+PORT=$DEV_PORT exec npx @marp-team/marp-cli --server "$SERVE_DIR/"

scripts/extract-klausur.sh

@@ -1,19 +1,19 @@
 #!/usr/bin/env bash
 # Extract klausur-relevant slides from all kapitel
 # Usage: ./extract-klausur.sh <course_id>
-# Output: slides/<course>/klausur.md
+# Output: slides/<course>/klausurfolien.md
 
 set -e
 
 COURSE="${1:-223015b}"
 SLIDES_DIR="slides/$COURSE"
-OUTPUT_FILE="$SLIDES_DIR/klausur.md"
+OUTPUT_FILE="$SLIDES_DIR/klausurfolien.md"
 
-# Find the first kapitel file (01-*.md) to copy styles from
-FIRST_KAPITEL=$(ls "$SLIDES_DIR"/01-*.md 2>/dev/null | head -1)
+# Find the first kapitel file (00-intro.md or 01-*.md) to copy styles from
+FIRST_KAPITEL=$(ls "$SLIDES_DIR"/00-intro.md "$SLIDES_DIR"/01-*.md 2>/dev/null | head -1)
 
 if [[ -z "$FIRST_KAPITEL" ]]; then
-  echo "Error: No 01-*.md file found in $SLIDES_DIR"
+  echo "Error: No 00-intro.md or 01-*.md file found in $SLIDES_DIR"
   exit 1
 fi
 
@@ -57,7 +57,7 @@ awk '
 ' "$FIRST_KAPITEL" >> "$OUTPUT_FILE"
 
 # Process each kapitel file in order - extract klausur slides only
-for md_file in $(ls "$SLIDES_DIR"/[0-9][0-9]-*.md 2>/dev/null | grep -v klausur | sort); do
+for md_file in $(ls "$SLIDES_DIR"/[0-9][0-9]-*.md 2>/dev/null | grep -v klausurfolien | sort); do
   filename=$(basename "$md_file")
   kapitel_num=$(echo "$filename" | grep -oE '^[0-9]+' | sed 's/^0*//')
 

scripts/generate-index.sh

@@ -42,6 +42,15 @@ TOPIC_MAP["geschichte-grundlagen-html"]="Geschichte, Grundlagen & HTML"
 TOPIC_MAP["netzwerke-protokolle-css"]="Netzwerke, Protokolle & CSS"
 TOPIC_MAP["interaktivitaet-javascript"]="Interaktivität & JavaScript"
 
+# Configure which topics should appear disabled per course
+# Two modes: fully disabled (non-clickable card) and buttons-disabled (link remains clickable, buttons are disabled)
+declare -A DISABLED_FULL
+declare -A DISABLED_BUTTONS
+# For course B: chapters 3,4,5 should be fully disabled
+DISABLED_FULL["223015b"]="speichermedien-schnittstellen distribution-apis-zukunft vertiefung-offene-fragen"
+# For course C: chapter 3 should keep link clickable but buttons disabled
+DISABLED_BUTTONS["223015c"]="interaktivitaet-javascript"
+
 cat > "$BUILD_DIR/index.html" << HEADER
 <!DOCTYPE html>
 <html lang="de">
@@ -61,6 +70,15 @@ cat > "$BUILD_DIR/index.html" << HEADER
       line-height: 1.5;
     }
     header { margin-bottom: 2rem; }
+    .breadcrumb {
+      margin-bottom: 1rem;
+      font-size: 0.85rem;
+    }
+    .breadcrumb a {
+      color: #86868b;
+      text-decoration: none;
+    }
+    .breadcrumb a:hover { text-decoration: underline; }
     h1 {
       font-size: 1.75rem;
       font-weight: 600;
@@ -68,6 +86,12 @@ cat > "$BUILD_DIR/index.html" << HEADER
       margin-bottom: 0.5rem;
       color: $ACCENT_COLOR;
     }
+    .course-heading {
+      font-size: 1.25rem;
+      font-weight: 500;
+      color: #1d1d1f;
+      margin-bottom: 0.25rem;
+    }
     .subtitle {
       color: #86868b;
       font-size: 0.95rem;
@@ -77,7 +101,8 @@ cat > "$BUILD_DIR/index.html" << HEADER
       font-size: 0.875rem;
       margin-top: 0.25rem;
     }
-    .kapitel {
+    /* Use the .termine wrapper and add a gap between cards */
+    .termine {
       margin-top: 1.5rem;
       display: flex;
       flex-direction: column;
@@ -93,6 +118,7 @@ cat > "$BUILD_DIR/index.html" << HEADER
       grid-template-columns: 1fr auto auto;
       align-items: center;
       gap: 1rem;
+      padding: 0; /* inner padding handled by kapitel-link */
     }
     .kapitel-card:hover {
       transform: translateY(-2px);
@@ -105,6 +131,8 @@ cat > "$BUILD_DIR/index.html" << HEADER
       color: inherit;
       grid-column: 1;
     }
+    /* Disabled look: dim the entire card and prevent pointer events */
+    .kapitel-card.disabled { opacity: 0.6; pointer-events: none; }
     .kapitel-label {
       font-size: 0.7rem;
       font-weight: 600;
@@ -135,11 +163,11 @@ cat > "$BUILD_DIR/index.html" << HEADER
       white-space: nowrap;
       position: relative;
       z-index: 1;
+      margin-right: 0.5rem;
     }
     .btn-slides {
       background: $ACCENT_COLOR;
       color: #fff;
-      margin-right: 0.5rem;
     }
     .btn-slides:hover {
       filter: brightness(1.1);
@@ -147,9 +175,9 @@ cat > "$BUILD_DIR/index.html" << HEADER
     .btn-pdf {
       background: #f5f5f7;
       color: #1d1d1f;
-      margin-right: 1rem;
     }
     .btn-pdf:hover { background: #e8e8ed; }
+    .btn-disabled { opacity: 0.6; pointer-events: none; }
     /* Make entire card clickable via overlay */
     .kapitel-link::after {
       content: '';
@@ -198,9 +226,11 @@ cat > "$BUILD_DIR/index.html" << HEADER
 </head>
 <body>
   <header>
-    <h1>$TITLE</h1>
+    <p class="breadcrumb"><a href="../">← Kursübersicht</a></p>
+    <h1>HdM Vorlesungen</h1>
+    <h2 class="course-heading">$TITLE</h2>
     <p class="subtitle">$SUBTITLE</p>
-    <p class="meta">HdM Stuttgart · Wintersemester 2025/26 · Michael Czechowski</p>
+    <p class="meta">HdM Stuttgart · Sommersemester 2026 · Michael Czechowski</p>
   </header>
   <div class="termine">
 HEADER
@@ -216,7 +246,7 @@ for html in $(ls "$BUILD_DIR"/[0-9][0-9]-*.html 2>/dev/null | sort); do
   # Look up nice topic name or fallback
   topic="${TOPIC_MAP[$topic_raw]}"
   if [[ -z "$topic" ]]; then
-    topic=$(echo "$topic_raw" | sed 's/-/ /g' | sed 's/.*/\u&/')
+    topic=$(echo "$topic_raw" | sed 's/-/ /g' | sed 's/.*/\\u&/')
   fi
 
   # Handle kapitel number
@@ -228,42 +258,108 @@ for html in $(ls "$BUILD_DIR"/[0-9][0-9]-*.html 2>/dev/null | sort); do
 
   pdf_filename="${filename%.html}.pdf"
 
-  # Check if PDF exists
-  pdf_link=""
-  if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
-    pdf_link="<a href=\"$pdf_filename\" class=\"btn btn-pdf\">PDF</a>"
+  # Determine whether this topic is configured as disabled for this course
+  disabled_full=false
+  disabled_buttons=false
+  for t in ${DISABLED_FULL["$COURSE"]}; do
+    if [[ "$topic_raw" == "$t" ]]; then
+      disabled_full=true
+      break
+    fi
+  done
+  if [[ "$disabled_full" == false ]]; then
+    for t in ${DISABLED_BUTTONS["$COURSE"]}; do
+      if [[ "$topic_raw" == "$t" ]]; then
+        disabled_buttons=true
+        break
+      fi
+    done
+  fi
+
+  # Decide card class
+  card_class="kapitel-card"
+  if [[ "$disabled_full" == true ]] || [[ "$disabled_buttons" == true ]]; then
+    card_class="$card_class disabled"
+  fi
+
+  # Build link/button HTML depending on disabled state
+  if [[ "$disabled_full" == true ]]; then
+    # non-interactive card (visually dimmed and not clickable)
+    link_html="<div class=\"kapitel-link\"><div class=\"kapitel-label\">$kapitel_label</div><div class=\"kapitel-title\">$topic</div></div>"
+    slides_html="<span class=\"btn btn-slides btn-disabled\">Folien</span>"
+    pdf_html=""
+    if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
+      pdf_html="<span class=\"btn btn-pdf btn-disabled\">PDF</span>"
+    fi
+  elif [[ "$disabled_buttons" == true ]]; then
+    # link stays clickable, but buttons are disabled; card appears dimmed
+    link_html="<a href=\"$filename\" class=\"kapitel-link\"><div class=\"kapitel-label\">$kapitel_label</div><div class=\"kapitel-title\">$topic</div></a>"
+    slides_html="<span class=\"btn btn-slides btn-disabled\">Folien</span>"
+    pdf_html=""
+    if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
+      pdf_html="<span class=\"btn btn-pdf btn-disabled\">PDF</span>"
+    fi
+  else
+    # normal interactive card
+    pdf_link=""
+    if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
+      pdf_link="<a href=\"$pdf_filename\" class=\"btn btn-pdf\">PDF</a>"
+    fi
+    link_html="<a href=\"$filename\" class=\"kapitel-link\"><div class=\"kapitel-label\">$kapitel_label</div><div class=\"kapitel-title\">$topic</div></a>"
+    slides_html="<a href=\"$filename\" class=\"btn btn-slides\">Folien</a>"
+    pdf_html="$pdf_link"
   fi
 
   cat >> "$BUILD_DIR/index.html" << LINK
-    <div class="kapitel-card">
-      <a href="$filename" class="kapitel-link">
-        <div class="kapitel-label">$kapitel_label</div>
-        <div class="kapitel-title">$topic</div>
-      </a>
-      <a href="$filename" class="btn btn-slides">Folien</a>
-      $pdf_link
+    <div class="$card_class">
+      $link_html
+      $slides_html
+      $pdf_html
     </div>
 LINK
+
 done
 
-# Add klausur entry if it exists
-if [[ -f "$BUILD_DIR/klausur.html" ]]; then
+# Add klausurfolien entry if it exists
+if [[ -f "$BUILD_DIR/klausurfolien.html" ]]; then
   pdf_link=""
-  if [[ -f "$BUILD_DIR/klausur.pdf" ]]; then
-    pdf_link="<a href=\"klausur.pdf\" class=\"btn btn-pdf\">PDF</a>"
+  if [[ -f "$BUILD_DIR/klausurfolien.pdf" ]]; then
+    pdf_link="<a href=\"klausurfolien.pdf\" class=\"btn btn-pdf\">PDF</a>"
   fi
   cat >> "$BUILD_DIR/index.html" << KLAUSUR
     <div class="kapitel-card" style="border-left: 3px solid $ACCENT_COLOR;">
-      <a href="klausur.html" class="kapitel-link">
+      <a href="klausurfolien.html" class="kapitel-link">
         <div class="kapitel-label">Prüfung</div>
         <div class="kapitel-title">Klausurrelevante Folien</div>
       </a>
-      <a href="klausur.html" class="btn btn-slides">Folien</a>
+      <a href="klausurfolien.html" class="btn btn-slides">Folien</a>
       $pdf_link
     </div>
 KLAUSUR
 fi
 
+# Add klausurfragen entry if it exists (HTML and/or PDF)
+if [[ -f "$BUILD_DIR/klausurfragen.html" ]] || [[ -f "$BUILD_DIR/klausurfragen.pdf" ]]; then
+  pdf_link=""
+  if [[ -f "$BUILD_DIR/klausurfragen.pdf" ]]; then
+    pdf_link="<a href=\"klausurfragen.pdf\" class=\"btn btn-pdf\">PDF</a>"
+  fi
+  slides_link=""
+  if [[ -f "$BUILD_DIR/klausurfragen.html" ]]; then
+    slides_link="<a href=\"klausurfragen.html\" class=\"btn btn-slides\">Folien</a>"
+  fi
+  cat >> "$BUILD_DIR/index.html" << KLAUSURFRAGEN
+    <div class="kapitel-card" style="border-left: 3px solid $ACCENT_COLOR;">
+      <a href="klausurfragen.html" class="kapitel-link">
+        <div class="kapitel-label">Prüfung</div>
+        <div class="kapitel-title">Klausurfragen</div>
+      </a>
+      $slides_link
+      $pdf_link
+    </div>
+KLAUSURFRAGEN
+fi
+
 cat >> "$BUILD_DIR/index.html" << FOOTER
   </div>
   <div class="qr-section">
@@ -272,7 +368,7 @@ cat >> "$BUILD_DIR/index.html" << FOOTER
   </div>
   <footer>
     <a href="mailto:mail@librete.ch">Kontakt</a> ·
-    <a href="../">Alle Kurse</a>
+    <a href="../">Kursübersicht</a>
   </footer>
 </body>
 </html>

scripts/generate-root-index.sh

@@ -0,0 +1,158 @@
+#!/usr/bin/env bash
+# Generate root index.html for HdM slides overview
+# Usage: ./generate-root-index.sh
+
+BUILD_DIR="${1:-build}"
+
+cat > "$BUILD_DIR/index.html" << 'HEADER'
+<!DOCTYPE html>
+<html lang="de">
+<head>
+  <meta charset="UTF-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1.0">
+  <title>HdM Vorlesungen</title>
+  <style>
+    * { box-sizing: border-box; margin: 0; padding: 0; }
+    body {
+      font-family: -apple-system, BlinkMacSystemFont, "SF Pro Display", "Segoe UI", Roboto, sans-serif;
+      max-width: 720px;
+      margin: 0 auto;
+      padding: 3rem 1.5rem;
+      background: #fafafa;
+      color: #1d1d1f;
+      line-height: 1.5;
+    }
+    h1 {
+      font-size: 2rem;
+      font-weight: 600;
+      letter-spacing: -0.02em;
+      margin-bottom: 0.5rem;
+    }
+    .subtitle { color: #86868b; font-size: 1rem; }
+    .courses {
+      margin-top: 2rem;
+      display: flex;
+      flex-direction: column;
+      gap: 0.75rem;
+    }
+    .course-card {
+      position: relative;
+      background: #fff;
+      border-radius: 12px;
+      box-shadow: 0 1px 3px rgba(0,0,0,0.08);
+      transition: all 0.2s ease;
+      display: grid;
+      grid-template-columns: 1fr auto auto;
+      align-items: center;
+      gap: 1rem;
+    }
+    .course-card:hover {
+      transform: translateY(-2px);
+      box-shadow: 0 4px 12px rgba(0,0,0,0.12);
+    }
+    .course-link {
+      display: block;
+      padding: 1.25rem 1.5rem;
+      text-decoration: none;
+      color: inherit;
+      grid-column: 1;
+    }
+    .course-link::after {
+      content: '';
+      position: absolute;
+      inset: 0;
+      border-radius: 12px;
+    }
+    .course-label {
+      font-size: 0.7rem;
+      font-weight: 600;
+      text-transform: uppercase;
+      letter-spacing: 0.05em;
+    }
+    .course-b .course-label { color: #1e5f8a; }
+    .course-c .course-label { color: #d63384; }
+    .course-title {
+      font-size: 1.15rem;
+      font-weight: 500;
+      color: #1d1d1f;
+      margin: 0.25rem 0;
+    }
+    .course-info { font-size: 0.85rem; color: #86868b; }
+    .section-title {
+      font-size: 1rem;
+      font-weight: 600;
+      color: #86868b;
+      margin-top: 2.5rem;
+      margin-bottom: 0.75rem;
+    }
+    .references {
+      display: flex;
+      flex-direction: column;
+      gap: 0.75rem;
+    }
+    footer {
+      margin-top: 2.5rem;
+      padding-top: 1.5rem;
+      border-top: 1px solid #e5e5e7;
+      color: #86868b;
+      font-size: 0.85rem;
+    }
+    footer a { color: #1d1d1f; text-decoration: none; }
+    footer a:hover { text-decoration: underline; }
+    .qr-section {
+      margin-top: 2.5rem;
+      padding: 1.5rem;
+      background: #fff;
+      border-radius: 12px;
+      box-shadow: 0 1px 3px rgba(0,0,0,0.08);
+      text-align: center;
+    }
+    .qr-code { width: 100%; height: auto; }
+    .qr-url { margin-top: 0.75rem; font-size: 0.85rem; color: #86868b; }
+    @media (max-width: 600px) {
+      .course-card { grid-template-columns: 1fr; }
+      .course-link { padding-bottom: 0.75rem; }
+    }
+  </style>
+</head>
+<body>
+  <h1>HdM Vorlesungen</h1>
+  <p class="subtitle">Sommersemester 2026 · Michael Czechowski</p>
+  <div class="courses">
+    <div class="course-card course-b">
+      <a href="223015b/" class="course-link">
+        <span class="course-label">223015b</span>
+        <div class="course-title">Dateiformate, Schnittstellen, Speichermedien &amp; Distributionswege</div>
+        <span class="course-info">6 Kapitel · Modul &quot;Technik 1&quot;</span>
+      </a>
+    </div>
+    <div class="course-card course-c">
+      <a href="223015c/" class="course-link">
+        <span class="course-label">223015c</span>
+        <div class="course-title">Grundlagen IT- und Internettechnik</div>
+        <span class="course-info">3 Kapitel · Modul &quot;Technik 1&quot;</span>
+      </a>
+    </div>
+  </div>
+  <h2 class="section-title">Referenzen</h2>
+  <div class="references">
+    <div class="course-card">
+      <a href="https://codecrispi.es/" class="course-link">
+        <span class="course-label">Plattform</span>
+        <div class="course-title">Code Crispies</div>
+        <span class="course-info">Selbstlernplattform</span>
+      </a>
+    </div>
+  </div>
+  <div class="qr-section">
+    <img src="qr-root.svg" alt="QR Code" class="qr-code">
+    <p class="qr-url">https://librete.ch/hdm/</p>
+  </div>
+  <footer>
+    <a href="mailto:mail@librete.ch">Kontakt</a>
+  </footer>
+</body>
+</html>
+HEADER
+
+echo "Generated $BUILD_DIR/index.html"

slides/223015b/00-intro.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
-footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
 ---
 
@@ -82,173 +82,109 @@ section.aufgabe footer {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
-**Wintersemester 2025/26**
+**Sommersemester 2026**
 
 [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
 
 ---
 
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
 ![bg fit](./assets/qrcode-0.svg)
 
 ---
 
 <!-- _class: lead -->
 
-# Willkommen!
+# Herzlich willkommen!
 ## Einführung
 
 ---
 
 # Über mich
 
-**Michael Czechowski**
+**Michael Werner Czechowski**
 
-- Irgendwas mit IT, Cloud und AI
+- Systems and Platform Engineer
 - Schwerpunkte:
   - Web-Technologien, Barriere-Armut, Systemarchitektur, Open Source
 - Hintergrund:
-  - Philosophie (Uni Stuttgart) -> NO degree
-  - Wirtschafts-Informatik (Leibniz-FH) -> B.Sc.
+  - Philosophie (Uni Stuttgart)
+  - Wirtschaftsinformatik (Leibniz-FH Hannover)
 - Kontakt: lb-czechowski@hdm-stuttgart.de
 
+---
+
+# Warum dieses Modul?
+
+**Digitale Medien sind überall.**
+
+* Warum enthalten Fotos oft Informationen über den Aufnahmeort?
+* Warum lassen sich gelöschte Dateien wiederherstellen?
+* Warum benötigt eine Minute 4K-Video unkomprimiert 45 GB Speicher?
+* Warum zeigt eine "1 TB"-Festplatte nur 931 GB an?
+* Warum ist USB-C nicht gleich USB-C?
+* Ziel: **→ Mitreden können!**
+
 <!--
-Kurze Vorstellung
-Praxisbezug betonen
-Fragen jederzeit willkommen
+1. EXIF (Exchangeable Image File Format)-Metadaten speichern GPS-Koordinaten, Kameramodell und Zeitstempel automatisch. Die meisten wissen nicht, dass diese Daten beim Versenden mitgeschickt werden. → Kapitel 4: Metadaten
+
+2. Beim Löschen wird nur der Verzeichniseintrag im Dateisystem entfernt, nicht die Daten selbst. Die Bits bleiben auf dem Datenträger, bis sie überschrieben werden. → Kapitel 3: Dateisysteme
+
+3. 3840 × 2160 Pixel × 3 Byte (RGB) × 30 Bilder/Sek × 60 Sek = ~45 GB. Codecs wie H.264/H.265 komprimieren um Faktor 100+. → Kapitel 1+2: Kompression
+
+4. Hersteller rechnen dezimal (1 TB = 10¹² Bytes), Betriebssysteme binär (1 TiB = 2⁴⁰ Bytes). Die Differenz beträgt bei Terabyte bereits ~10%. → Kapitel 1: Dateneinheiten
+
+5. USB-C ist nur die Steckerform. Dahinter können USB 2.0 (480 Mbit/s), USB 3.2 (20 Gbit/s) oder Thunderbolt 4 (40 Gbit/s) laufen — gleiches Kabel, völlig unterschiedliche Leistung. → Kapitel 3: Schnittstellen
 -->
 
 ---
 
-<!-- _footer: '' -->
-
-![bg fit](./assets/jung-naiv.png)
-
----
-
-# AMA (Ask my anything)
-
-*Nur ein Vorschlag ...*
-
-* Hast du alle Bände von AoT daheim?
-* Hast du eine Studierenden-Kneipe mal geleitet?
-* Hast du wirklich 17 Semester Philosophie ohne Abschluss studiert?
-
----
-
 # Kurze Umfrage
 
 **Bitte Hand heben:**
 
-1) Wer hat schon mal ein Video komprimiert/konvertiert?
-2) Wer kennte die 3-2-1 Regel?
-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 mit einem CLI gearbeitet?
-6) **Wer hat schon mal etwas mit HTML oder CSS gemacht?** (Hex-Farben wie `#FF0000`?)
+1) Wer kennt den Unterschied zwischen analog und digital?
+2) Wer hat schon mal eine Datei von einem Format in ein anderes konvertiert?
+3) Wer hat schon mal Metadaten aus einem Foto entfernt?
+4) Wer kennt die 3-2-1 Backup-Regel?
+5) Wer hat schon mal eine API benutzt?
 
 <!--
 Niveau der Gruppe einschätzen
 Keine falschen Antworten
 Zeigt, wo wir starten
-HTML/CSS-Frage: Viele kennen Hex-Codes aus Webdesign
 API = Application Programming Interface
 -->
 
 ---
 
-# Warum dieses Modul?
-
-**Digitale Medien sind überall** – aber was steckt dahinter?
-
-* Warum ist ein JPEG kleiner als ein PNG?
-* Warum klingt MP3 anders als FLAC?
-* Warum zeigt meine 1 TB Festplatte nur 931 GB?
-* Warum ist USB-C so verwirrend?
-* Wie funktioniert eigentlich Streaming?
-* **→ Die Technik dahinter verstehen!**
-
-<!--
-Praxisnahe Fragen aus dem Alltag
-Nicht nur "was", sondern "warum"
-Verständnis für technische Entscheidungen
--->
-
----
-
-# Das Ziel
-
-**Technische Grundlagen verstehen**, um fundierte Entscheidungen treffen zu können.
-
-Als Digital- und Medienwirtschaftler:innen werdet ihr täglich mit technischen Fragen konfrontiert:
-* Welches Format für welchen Zweck?
-* Welche Schnittstelle für welches Gerät?
-* Wie funktioniert die Distribution digitaler Inhalte?
-* **→ Mitreden können – nicht (zwingend) programmieren!**
-
-<!--
-Nicht: Ihr sollt Programmierer werden
-Sondern: Ihr sollt technische Entscheidungen verstehen
-Praxisbezug: Medienproduktion, Marketing, Projektmanagement
--->
-
----
-
-# Was ihr lernt
-
-**In dieser Veranstaltung erwerbt ihr folgende Kompetenzen:**
-
-* Fundiertes Grundwissen über Daten und Informationen
-* Dateiformate analysieren und verstehen
-* Grundlagen von Kompression (Audio, Bild, Video)
-* Speichermedien unterscheiden
-* Programmier-Schnittstellen kennenlernen
-* APIs und Distributionswege verstehen
-
-<!--
-Fokus auf Verständnis, nicht auf Programmierung
-Hands-On jede Woche: Selbst ausprobieren
-Ziel: Einblick in die Denkweise von Software-Entwicklern
--->
-
----
-
 # Kursübersicht
 
-**5 Termine:**
+**Kapitel:**
 
-| # | 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 |
+1. Grundlagen, Text & **Audio** (Bits, Bytes, Zeichenkodierung, MP3)
+2. **Bild** & **Video**-Kompression (JPEG, PNG, H.264/H.265)
+3. **Speichermedien** & **Schnittstellen** (HDD, SSD, USB, Thunderbolt)
+4. **Distribution**, **APIs** & Zukunft (Streaming, REST, Cloud)
+5. Vertiefung & offene Fragen
 
-**Format:** Theorie + Hands-On (30-40 Min pro Termin)
-
-<!--
-Nicht nur theoretische Inhalte
-Praktische Übungen jede Woche
-Medienwissenschaftler:innen, nicht Informatiker:innen
--->
 
 ---
 
-# Prüfungsleistung 18.02.
+<!-- _class: klausur -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+<!-- _backgroundColor: #e3f2fd -->
+
+# Prüfungsleistung
 
 **Nach aktuellem Kenntnisstand:**
 
-* 90 min (40% Grundlagen, 40% Dateiformate, 20% AV)
-* Schriftliche Klausur
+* 90 min insg. (Technik 1)
+* Schriftliche Klausur (digital)
 * Teils offene Fragen
-* Vermutlich digital
-* Kein Coding!
-* **Prüfungsrelevant:** Alles in den Folien/im Skript
-
-<!--
-Details können sich noch ändern
-Keine Programmieraufgaben
-Verständnisfragen, keine Auswendiglernerei
--->
-
+* Kein Coding/Programmieren
+* **Prüfungsrelevante Folien:**
+  - Gestreift oder Vollton (PDF) markiert

slides/223015b/01-grundlagen-text-audio.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
-footer: "Michael Czechowski – HdM Stuttgart"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
 ---
 
@@ -68,6 +68,38 @@ section.aufgabe {
 section.aufgabe footer {
   display: none;
 }
+section.erklaerung {
+  font-size: 1.1rem;
+  background: repeating-linear-gradient(
+    135deg,
+    #e3f2fd,
+    #e3f2fd 40px,
+    #fff 40px,
+    #fff 80px
+  ) !important;
+}
+@media print {
+  section.erklaerung {
+    background: #e3f2fd !important;
+  }
+}
+section.erklaerung h1 {
+  font-size: 1.5rem;
+  color: #1e5f8a;
+  margin-bottom: 0.3rem;
+}
+section.erklaerung ul,
+section.erklaerung ol {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung p {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung table {
+  font-size: 0.9rem;
+}
 </style>
 
 <!-- _class: invert -->
@@ -103,6 +135,15 @@ Hochschule der Medien Stuttgart
 
 ---
 
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/compact-disc-cd.jpg)
+
+---
+
+![bg right:40%](./assets/IMG_3617.jpg)
+
 # Ein konkretes Beispiel
 
 **Eine Minute Musik in CD-Qualität:**
@@ -122,6 +163,8 @@ Aber es skaliert schnell.
 
 ---
 
+![bg right:40%](./assets/IMG_3617.jpg)
+
 # Das Problem skaliert
 
 | Inhalt | Unkomprimiert |
@@ -142,6 +185,8 @@ Das Problem musste gelöst werden.
 
 ---
 
+![bg right:32% contain](./assets/dvd.jpg)
+
 # Video eskaliert
 
 **Eine Minute 4K-Video (unkomprimiert):**
@@ -163,11 +208,33 @@ Die physikalische Realität erzwingt Kompression.
 
 ---
 
+![bg right:40%](./assets/artemis.jpg)
+
+# Artemis II orbitiert
+
+| | Apollo (1969) | Artemis II (2026) |
+|---|---|---|
+| Bandbreite | ~50 kbit/s | 260 Mbit/s |
+| Video | SW, ~320 Zeilen | HD live, 4K gespeichert |
+| Codec | analog | H.265 (HEVC) |
+
+260.000.000 Bit/s
+÷ 8 (Bit pro Byte) = 32,5 MB/s
+× 60 Sekunden = **1,95 GB pro Minute**
+
+*Apollo: 50 kbit/s = 0,375 MB/min*
+
+<!--
+Übertragung per Infrarot-Laser (O2O = Orion Artemis II Optical Communications). MAScOT-Terminal entwickelt von MIT Lincoln Lab. 32 Kameras an Bord (Nikon D5/Z9, GoPros, Redwire 4K-Festkameras). ZCube-Encoder kodiert H.265 an Bord. Bandbreite geteilt mit Telemetrie und Voice — daher live "nur" HD, echtes 4K kommt auf CompactFlash-Karten nach Splashdown. Latenz Mond ↔ Erde: ~1,3 Sekunden (384.400 km). Apollo nutzte S-Band Radio, Artemis II Infrarot-Laser.
+-->
+
+---
+
 # Kompressionsraten in der Praxis
 
 | Medium | Unkomprimiert | Komprimiert | Faktor |
 |--------|-------------:|------------:|-------:|
-| 1 Song (4 Min) | ~42 MB | ~4 MB (MP3 320) | ~10× |
+| 1 Song (4 Min) | ~42 MB | ~4 MB (MP3 128) | ~10× |
 | 1 Foto (12 MP) | ~36 MB | ~3 MB (JPEG) | ~12× |
 | 1 Min 4K-Video | ~45 GB | ~375 MB (H.264) | ~120× |
 
@@ -250,12 +317,12 @@ Sondern gezielt das entfernen, was Menschen nicht wahrnehmen.
 | | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
 |---|---|---|
 | **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
-| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich weg) |
+| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich verloren) |
 | **Reduktion** | 30-50% | 80-99% |
 | **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
 
 **Faustregel:**
-- Medien für Endnutzer → Lossy oft akzeptabel
+- Medien für EndnutzerInnen → Lossy oft akzeptabel
 - Quellmaterial, Code, Archive → Lossless nötig
 
 <!--
@@ -270,6 +337,55 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Kompression – Vertiefung
+
+Claude Shannon definierte 1948 die **Entropie** als theoretische Untergrenze der Kompression. Ein Text mit gleichmäßiger Zeichenverteilung hat hohe Entropie (schwer komprimierbar); repetitive Texte haben niedrige Entropie.
+
+**Verlustfreie Kompression** erreicht diese Grenze durch:
+- **Statistische Kodierung:** Huffman, Arithmetic Coding
+- **Wörterbuch-Methoden:** LZ77, LZ78, DEFLATE (ZIP, PNG, TAR)
+- Originalzustand ist exakt rekonstruierbar
+
+**Verlustbehaftete Kompression** unterschreitet die Grenze, indem sie menschliche Wahrnehmungsgrenzen ausnutzt:
+
+| Sinneskanal | Psychophysisches Modell | Ausnutzung |
+|-------------|------------------------|------------|
+| Gehör | Maskierungseffekte, Hörschwelle | MP3: Töne unter Maskierungsschwelle weglassen |
+| Sehen | Farbauflösung, Kontrastempfindlichkeit | JPEG: Chroma-Subsampling, hohe Frequenzen verwerfen |
+
+**Shannon-Limit:** Verlustfreie Kompression ist durch Entropie begrenzt; Verlustbehaftete Kompression kann beliebig weit gehen – auf Kosten der Qualität.
+
+<!--
+ABKÜRZUNGEN:
+- LZ = Lempel-Ziv (nach Abraham Lempel und Jacob Ziv)
+- LZ77 = Lempel-Ziv 1977 – Sliding-Window-Verfahren: sucht Wiederholungen in einem Fenster der letzten Bytes und ersetzt sie durch Rückverweise (Offset + Länge)
+- LZ78 = Lempel-Ziv 1978 – baut ein explizites Wörterbuch auf: neue Muster bekommen einen Index, Wiederholungen werden durch den Index ersetzt
+- DEFLATE = Kombination aus LZ77 + Huffman-Coding; verwendet in ZIP, PNG und gzip
+- TAR = Tape ARchive – kein Kompressionsformat, sondern ein Archivformat (bündelt Dateien zu einer). Kompression erst durch Kombination: .tar.gz (gzip = DEFLATE), .tar.bz2 (bzip2), .tar.xz (LZMA)
+- ZIP = Archivformat mit eingebauter DEFLATE-Kompression (Phil Katz, 1989)
+- PNG = Portable Network Graphics – nutzt DEFLATE für verlustfreie Bildkompression
+
+STATISTISCHE KODIERUNG:
+- Huffman-Coding: Häufige Zeichen bekommen kurze Bitfolgen, seltene Zeichen lange. Beispiel: 'e' (häufig) → 2 Bit, 'q' (selten) → 8 Bit
+- Arithmetic Coding: Kodiert die gesamte Nachricht als einzelne Zahl zwischen 0 und 1. Etwas effizienter als Huffman, aber rechenintensiver
+
+ENTROPIE (Shannon):
+- Maß für den Informationsgehalt: Wie "überraschend" ist jedes Zeichen?
+- Hohe Entropie = schwer komprimierbar (z.B. verschlüsselte Daten, Rauschen)
+- Niedrige Entropie = gut komprimierbar (z.B. "AAAAAAA" oder natürliche Sprache)
+- Theoretisches Minimum: kein Algorithmus kann unter die Entropie-Grenze kommen
+
+PRAXISBEISPIEL:
+- ZIP einer .txt-Datei: ~60-70% kleiner (Text hat niedrige Entropie)
+- ZIP einer .jpg-Datei: kaum kleiner (JPEG hat Entropie schon ausgereizt)
+-->
+
+---
+
 <!-- _header: '' -->
 <!-- _footer: '' -->
 
@@ -344,11 +460,15 @@ BYTE = Wortspiel aus "Bit" + "Bite" (Bissen) – ein "Bissen" Information
 **1 Byte = 8 Bits**
 
 ```
-0 1 0 0 1 1 0 1
+0 0 1 0 1 0 1 0
 ```
 
 <!--
 
+
+binary 00101010 
+= decimal 42
+
 Rätsel: "Wenn sich das Wachstum einer Seerose auf einem Teich jeden Tag verdoppelt · und nach *zehn Tagen* der ganze Teich bedeckt ist, wann ist er zur Hälfte zugewachsen?"
 
 Frage: "Weiß jemand wieviele Zustände wir mit 8 Bit beschreiben können?"
@@ -362,7 +482,7 @@ Frage: "Weiß jemand wieviele Zustände wir mit 8 Bit beschreiben können?"
 **1 Byte = 8 Bits**
 
 ```
-0 1 0 0 1 1 0 1
+0 0 1 0 1 0 1 0
 ```
 
 2⁸ = **256 Möglichkeiten** (0-255)
@@ -444,8 +564,8 @@ Das menschliche Auge kann etwa 10 Millionen Farben unterscheiden
 <!--
 Welche Farben für ein volles Spektrum bieten sich nach unserer gelernten Sparsamkeit hier am besten an?
 
-1. CMYK bzw. in diesem Fall CMYW
-2. RGB
+1. CMYK (Cyan, Magenta, Yellow, Key/Black) bzw. in diesem Fall CMYW (Cyan, Magenta, Yellow, White)
+2. RGB (Red, Green, Blue)
 -->
 
 ---
@@ -483,23 +603,16 @@ Sog. RGB Tuple (geordnete endliche Liste)
 <!--
 "Weiß jemand oder möchte jemand raten, wofür das "s" bei "sRGB" steht?"
 
-sRGB = Standard RGB
-CMYK = Subtraktive Farbmischung (Druck)
+sRGB = Standard RGB (Red, Green, Blue)
+CMYK = Cyan, Magenta, Yellow, Key (Black) – Subtraktive Farbmischung (Druck)
 Hex-Notation: FF = 255 in Dezimal
-CSS-Farben nutzen Hex: #FF0000 = Rot
-Wer HTML/CSS gemacht hat, kennt das schon!
+CSS (Cascading Style Sheets)-Farben nutzen Hex: #FF0000 = Rot
+Wer HTML (HyperText Markup Language)/CSS gemacht hat, kennt das schon!
 background-color: #FF0000; = Rot
 -->
 
 ---
 
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-![bg fit](./assets/hex-dec-lookup-table.png)
-
----
-
 # Das Problem: Sprachen
 
 **Die Welt hat mehr als 256 Zeichen!**
@@ -508,11 +621,9 @@ background-color: #FF0000; = Rot
 - + Ziffern: 10 (0-9)
 - + Sonderzeichen: ~30
 
-**≈ 90 Zeichen → passt in 1 Byte**
+**≈ 90 Zeichen passen problemlos in 1 Byte**
 
-**Aber:** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 😀
-
-→ **1 Byte reicht nicht!**
+**Jedoch ohne** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 🌸  
 
 <!--
 Problem der Zeichenkodierung
@@ -550,7 +661,7 @@ WICHTIG für Kontext zur ASCII-Folie:
 Byte-Längen:
 - ASCII-Zeichen (0-127): 1 Byte
 - Umlaute, diakritische Zeichen: 2 Bytes
-- Chinesisch, Japanisch, Koreanisch: 3 Bytes
+- CJK -> Chinesisch, Japanisch, Koreanisch: 3 Bytes
 - Emoji, seltene Zeichen: 4 Bytes
 -->
 
@@ -588,7 +699,7 @@ Hinweis: は wird hier "wa" ausgesprochen (Partikel), nicht "ha"
 
 # Hexadezimal: Lesbarkeit
 
-**Binär ist unleserlich:**
+**Für den Menschen ungeeignet:**
 `01010000 01001110 01000111`
 
 **Hexadezimal (Base 16):**
@@ -597,12 +708,17 @@ Hinweis: は wird hier "wa" ausgesprochen (Partikel), nicht "ha"
 **Jede Hex-Ziffer = 4 Bits (ein "Nibble")**
 0-9, A-F (10=A, 11=B, ..., 15=F)
 
+`5 = 0101` `0 = 0000`
+`4 = 0100` `E = 1110`
+`4 = 0100` `7 = 0111`
+
 **ASCII Tabelle (0-127):**
 [https://www.asciitable.com](https://www.asciitable.com)
 
 <!--
 
-"Gerne vorab auf den Link gehen"
+Dezimalsystem passt nur umständlich 0->15 (1111) ins binäre System
+Hexadezimal (16) passt perfekt
 
 WICHTIG: ASCII geht nur von 0-127!
 - Werte 128-255 sind NICHT in der ASCII-Tabelle
@@ -628,7 +744,12 @@ Hex-Editor = Standard-Tool für Dateianalyse und Reverse Engineering
 
 ---
 
+<!-- _header: '' -->
+<!-- _footer: '' -->
 
+![bg fit](./assets/hex-dec-lookup-table.png)
+
+---
 
 <!-- _class: lead -->
 
@@ -646,12 +767,12 @@ KULTURHISTORISCHER KONTEXT:
 - "American Standard Code for Information Interchange" (1963)
 - Entwickelt für US-amerikanische Bedürfnisse
 - Keine Unterstützung für: Umlaute (ä, ö, ü), ß, diakritische Zeichen (é, ñ, ç)
-- Nicht-lateinische Schriftsysteme (Kyrillisch, Arabisch, CJK) wurden nicht berücksichtigt
+- Nicht-lateinische Schriftsysteme (Kyrillisch, Arabisch, CJK = Chinese, Japanese, Korean) wurden nicht berücksichtigt
 - Führte zu zahlreichen inkompatiblen Erweiterungen (ISO-8859-1, Windows-1252, etc.)
 
 WARUM NOCH HEUTE RELEVANT?
-- Abwärtskompatibilität: UTF-8 ist vollständig ASCII-kompatibel (Zeichen 0-127 identisch)
-- Internetprotokolle basieren auf ASCII: HTTP-Header, SMTP, URLs
+- Abwärtskompatibilität: UTF-8 (Unicode Transformation Format, 8-bit) ist vollständig ASCII-kompatibel (Zeichen 0-127 identisch)
+- Internetprotokolle basieren auf ASCII: HTTP (HyperText Transfer Protocol)-Header, SMTP (Simple Mail Transfer Protocol), URLs (Uniform Resource Locator)
 - Programmiersprachen: Schlüsselwörter und Syntax sind ASCII
 - Ein 60 Jahre alter Standard, der durch Kompatibilitätszwänge fortbesteht
 
@@ -714,7 +835,7 @@ US-ASCII (1967) Code Chart
 | `0100 1110` | `4E` | 78 | **N** |
 | `0100 0111` | `47` | 71 | **G** |
 
-→ **PNG**-Signatur! (Das `89` markiert: "Ich bin binär, kein Text!")
+→ `89` übersteigt den ASCII-Raum und markiert eie Binärdatei
 
 <!--
 Hex = 2 Ziffern = 1 Byte = 8 Bit
@@ -797,7 +918,7 @@ WARUM nutzt PNG absichtlich 89 (= 137 dezimal)?
 Geschichte: "PK" bei ZIP = Phil Katz (Erfinder von PKZip, 1989)
 Fun Fact: DOCX, XLSX, PPTX, ODT = alles ZIP-Archive mit XML-Inhalt!
 
-Dateien OHNE Magic Number: TXT, HTML, CSS, JSON, XML
+Dateien OHNE Magic Number: TXT, HTML (HyperText Markup Language), CSS (Cascading Style Sheets), JSON (JavaScript Object Notation), XML (Extensible Markup Language)
 → Reiner Text, kein binäres Format
 
 Sicherheits-Aspekt:
@@ -826,8 +947,8 @@ Windows vertraut der Endung, aber "file" (Linux) liest Magic Number
 | **Zettabyte (ZB)** | 1 Trilliarde | 10²¹ | Internet-Traffic 2016 |
 
 <!--
-SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes
-Binär (IEC): 1 KiB = 1.024 Bytes (Kibibyte)
+SI (Système International d'Unités)-Präfixe (Dezimal): 1 KB = 1.000 Bytes
+Binär (IEC = International Electrotechnical Commission): 1 KiB = 1.024 Bytes (Kibibyte)
 Windows zeigt oft binär, sagt aber "KB" → Verwirrung!
 1 TB Festplatte = ~931 GiB nutzbar
 
@@ -837,6 +958,29 @@ Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Dateneinheiten – Vertiefung
+
+Zwei konkurrierende Standards existieren seit der IEC-Normierung 1998:
+
+| Präfix | SI (Dezimal) | IEC (Binär) | Differenz |
+|--------|--------------|-------------|-----------|
+| Kilo | 1.000 (10³) | 1.024 (2¹⁰) KiB | 2,4% |
+| Mega | 1.000.000 (10⁶) | 1.048.576 MiB | 4,9% |
+| Giga | 10⁹ | 2³⁰ GiB | 7,4% |
+| Tera | 10¹² | 2⁴⁰ TiB | 10% |
+
+**Warum der Unterschied wächst:** (2¹⁰)ⁿ ÷ (10³)ⁿ = 1,024ⁿ. Bei Terabyte sind es bereits 10% Abweichung.
+
+**Festplatten-Marketing:** Hersteller nutzen SI (dezimal), Betriebssysteme zeigen IEC (binär). Eine „1 TB"-Festplatte zeigt daher nur 931 GiB an – technisch korrekt, aber verwirrend.
+
+**Historischer Kontext:** RAM wurde immer binär gemessen (2ⁿ Adressen), Festplatten ursprünglich dezimal (physikalische Geometrie). Die IEC führte 1998 KiB/MiB/GiB ein – diese Notation setzt sich langsam durch.
+
+---
+
 # Datenwachstum der Menschheit
 
 | Jahr | Datenmenge | Kontext |
@@ -895,14 +1039,40 @@ ANALOG damals: Bücher, Zeitungen, Vinyl, VHS, Filmrollen, Fotos
 
 DIGITAL damals: Festplatten, CDs, DVDs, frühe Flash-Speicher
 
-HEUTE: LTO-9 (2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
+HEUTE: LTO-9 (LTO = Linear Tape-Open, 2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
 
-VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
+VERGLEICH: SSD (Solid State Drive) ~$50/TB, HDD (Hard Disk Drive) ~$15/TB, LTO ~$5/TB
 
 -->
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Digitaler Wendepunkt – Vertiefung
+
+Die Studie von Hilbert & López (Science, 2011) analysierte 60 Speichertechnologien von 1986–2007. Der Wendepunkt 2002 markiert den Moment, ab dem mehr Information digital als analog existierte.
+
+**Was 1986 „analog" bedeutete:**
+- Bücher, Zeitungen, Magazine: ~8 EB
+- Vinyl-Schallplatten, Musikkassetten: ~12 EB
+- VHS-Kassetten, Filmrollen: ~60 EB
+
+**Warum analog stagnierte:** Physische Medien haben Kapazitätsgrenzen. Eine VHS speichert 10 GB; eine Blu-ray (2006) bereits 50 GB auf kleinerer Fläche.
+
+**LTO-Magnetband überlebt** trotz „alter" Technologie:
+| Medium | Kosten/TB | Lebensdauer | Energiebedarf |
+|--------|-----------|-------------|---------------|
+| SSD | ~50 € | 5–10 Jahre | Dauerstrom |
+| HDD | ~15 € | 3–5 Jahre aktiv | Dauerstrom |
+| LTO-9 | ~5 € | 30+ Jahre | Nur beim Zugriff |
+
+AWS Glacier, Google Coldline und Film-Archive nutzen LTO – langsamer Zugriff, aber unschlagbar günstig und langlebig.
+
+---
+
 <!-- _header: '' -->
 <!-- _footer: '' -->
 
@@ -927,7 +1097,7 @@ VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
 
 <!--
 Quellen: IDC Global DataSphere Forecast, Statista 2025
-IoT-Geräte allein: 73 ZB in 2025
+IoT (Internet of Things)-Geräte allein: 73 ZB in 2025
 Cloud-Speicher: 100 ZB (50% der Weltdaten)
 Prognose 2028: 394 ZB
 -->
@@ -936,10 +1106,14 @@ Prognose 2028: 394 ZB
 
 
 <!-- _header: '' -->
-<!-- _footer: 'Floridi, L.: The forth Revolution' -->
+<!-- _footer: '' -->
 
 
-![bg fit](./assets/growth of big data.png)
+![bg fit](./assets/growth-of-big-data.png)
+
+<!--
+Quelle: Floridi, L.: The Fourth Revolution
+-->
 
 ---
 
@@ -994,13 +1168,36 @@ Visueller Kontrast: Analog vs. Digital
 ### Distribution: physisch (Kauf, Verleih, Kopie)
 
 * **Text**
-  - Bücher, Zeitungen, Zeitschriften, Lochkarten
+    - Bücher, Zeitungen, Zeitschriften, Lochkarten
 * **Bild**
-  - Fotografie (Negativ, Dia, Polaroid), Mikrofilm
+    - Fotografie (Negativ, Dia, Polaroid), Mikrofilm
 * **Audio:**
-  - Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
+    - Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
 * **Video:**
-  - Film (35mm, Super 8), VHS, Betamax
+    - Film (35mm, Super 8), VHS, Betamax
+
+---
+
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Analoge Medien – Vertiefung
+
+Analoge Speicherung codiert Information als **kontinuierliche physikalische Größe**: Rillentiefe (Vinyl), Magnetfeldstärke (Tonband), Silberkorn-Dichte (Film). Es gibt keine diskreten Stufen – theoretisch unendliche Auflösung, praktisch begrenzt durch Rauschen.
+
+**Generationsverlust** entsteht, weil jede Kopie neues Rauschen addiert:
+- Schallplatte → Kassette: Frequenzgang leidet, Rauschen steigt
+- VHS → VHS: Farbsättigung sinkt, Schärfe nimmt ab
+- 3. Generation: oft unbrauchbar
+
+| Medium | Typische Auflösung | Dynamik |
+|--------|-------------------|---------|
+| Vinyl (audiophil) | ~20–20.000 Hz | ~70 dB |
+| Tonband (Studio) | ~30–15.000 Hz | ~55 dB |
+| 35mm Film | ~4K-äquivalent | ~13 Blendenstufen |
+
+**Paradox der Analogtechnik:** Das Original ist einzigartig und unersetzlich – aber genau deshalb anfällig. Jedes Abspielen einer Schallplatte trägt mikroskopisch Material ab; jeder Filmdurchlauf riskiert Kratzer.
 
 ---
 
@@ -1017,7 +1214,7 @@ Visueller Kontrast: Analog vs. Digital
 <!--
 GENERATIONSVERLUST:
 Kassette → Kassette = jede Kopie schlechter
-VHS → VHS = Rauschen nimmt zu
+VHS (Video Home System) → VHS = Rauschen nimmt zu
 Schallplatte: Jedes Abspielen = minimaler Verschleiß
 
 ABER: Analoges Original bleibt "das Original"
@@ -1061,13 +1258,37 @@ Paradox: Gerade die Perfektion wurde zum "Problem"
 ### Distribution: Datenträger (CD, USB), Download, Streaming, P2P
 
 * **Text**
-  - E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
+    - E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
 * **Bild**
-  - Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
+    - Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
 * **Audio**
-  - Audiodatei (MP3, FLAC, WAV, AAC, OGG)
+    - Audiodatei (MP3, FLAC, WAV, AAC, OGG)
 * **Video**
-  - Videodatei (MP4, MKV, AVI, WebM)
+    - Videodatei (MP4, MKV, AVI, WebM)
+
+---
+
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Digitale Medien – Vertiefung
+
+Digitale Speicherung quantisiert kontinuierliche Signale in diskrete Werte. Der **Quantisierungsfehler** (Differenz zum Original) ist der Preis der Digitalisierung – aber einmal digitalisiert, bleibt die Information exakt.
+
+**Bit-identische Kopien** revolutionierten die Medienindustrie:
+- Keine Qualitätskette mehr: 1000. Kopie = 1. Kopie = Original
+- Kosten pro Kopie: praktisch null (nur Speicherplatz)
+- Perfekte Archivierung: Bits altern nicht (nur der Datenträger)
+
+| Aspekt | Analog | Digital |
+|--------|--------|---------|
+| Kopiervorgang | Physikalischer Prozess | Bit-Kopie |
+| Qualität pro Generation | Verschlechtert | Identisch |
+| Fehlerkorrektur | Unmöglich | Möglich (ECC = Error Correcting Code, RAID = Redundant Array of Independent Disks) |
+| Formatmigration | Verlust | Verlustfrei möglich |
+
+**Die Kehrseite:** Digitale Obsoleszenz. Ein DOCX von 2025 ist in 50 Jahren womöglich unlesbar – während ein Buch von 1525 heute noch lesbar ist. Offene Formate (PDF/A, FLAC, PNG) mildern dieses Risiko.
 
 ---
 
@@ -1079,13 +1300,38 @@ Paradox: Gerade die Perfektion wurde zum "Problem"
 # Digitale Speichermedien
 
 * **Optische Speicher**
-  - CD, DVD, Blu-ray
+    - CD, DVD, Blu-ray
 * **Magnetische Speicher**
-  - Festplatte (HDD), Magnetband (LTO)
+    - Festplatte (HDD), Magnetband (LTO)
 * **Flash-Speicher**
-  - SSD, USB-Stick, SD-Karte
+    - SSD, USB-Stick, SD-Karte
 * **Cloud-Speicher**
-  - Dropbox, Google Drive, iCloud, AWS S3
+    - Dropbox, Google Drive, iCloud, AWS S3
+
+---
+
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Digitale Speichermedien – Vertiefung
+
+Jede Technologie hat physikalische Vor- und Nachteile:
+
+**Optisch (CD/DVD/Blu-ray):** Laser liest Pits (Vertiefungen) und Lands (Erhöhungen). Robust gegen Magnetfelder, aber empfindlich gegenüber Kratzern und UV-Licht. M-DISC verspricht 1000 Jahre – unter Laborbedingungen.
+
+**Magnetisch (HDD/LTO):** Magnetisierte Bereiche auf rotierenden Platten oder Band. HDDs haben bewegliche Teile (Verschleiß); LTO-Bänder sind passiv und extrem langlebig, aber sequentieller Zugriff.
+
+**Flash (SSD/USB/SD):** Elektronen in Floating Gates speichern Bits. Keine beweglichen Teile, aber begrenzte Schreibzyklen (TLC: ~3.000, SLC: ~100.000). Ohne Strom verlieren Zellen nach Jahren ihre Ladung.
+
+| Szenario | Empfehlung | Grund |
+|----------|------------|-------|
+| Betriebssystem | NVMe SSD | Geschwindigkeit |
+| Videoarchiv | HDD | Kapazität/Preis |
+| Langzeitarchiv | LTO + M-DISC | Lebensdauer |
+| Austausch | USB/SD | Portabilität |
+
+**Cloud** ist physisch HDD/SSD/LTO in Rechenzentren – kein eigenes Medium, sondern Zugriffsmethode.
 
 ---
 
@@ -1330,7 +1576,7 @@ Patent lief 2017 aus
 - Forschung ab 1982, Patent 1988
 
 <!--
-Fraunhofer IIS Erlangen
+Fraunhofer IIS (Institut für Integrierte Schaltungen) Erlangen
 Forschung dauerte über 10 Jahre
 Perfektionist: Jeder Hörtest musste bestehen
 -->
@@ -1397,7 +1643,7 @@ Ein Zusammenspiel aus vielen Faktoren:
 <!--
 MP3-Kompression in 4 Schritten (vereinfacht):
 
-1. FFT (Fast Fourier Transform)
+1. FFT (Fast Fourier Transform = Schnelle Fourier-Transformation)
    - Wandelt Schallwellen in Frequenzen um
    - Wie ein Prisma Licht in Farben zerlegt
 
@@ -1409,7 +1655,7 @@ MP3-Kompression in 4 Schritten (vereinfacht):
 3. Quantisierung (hier passiert der Datenverlust!)
    - Unwichtige Frequenzen werden "grob" gespeichert
    - Wichtige Frequenzen bleiben genau
-   - Wie JPEG: Details entfernen, wo es nicht auffällt (Kontrast/Helligkeit bleibt)
+   - Wie JPEG (Joint Photographic Experts Group): Details entfernen, wo es nicht auffällt (Kontrast/Helligkeit bleibt)
 
 4. Huffman-Coding (verlustfrei)
    - Häufige Muster = kurze Codes
@@ -1482,7 +1728,7 @@ KERNKONZEPT: Kompression = Modell der menschlichen Wahrnehmung
 **Prinzip:** Wiederholungen zählen statt wiederholen
 
 <!--
-RLE = Run-Length Encoding = Lauflängenkodierung
+RLE = Run-Length Encoding (Lauflängenkodierung)
 Einfachster Kompressionsalgorithmus
 Gut für: Fax, einfache Grafiken, Icons
 Schlecht für: Fotos, Audio (zu chaotisch)
@@ -1507,7 +1753,7 @@ Schlecht für: Fotos, Audio (zu chaotisch)
 Fraunhofer verklagte Winamp, andere Tools
 Millionen nutzten unlizenzierte Software
 Das Pferd war aus dem Stall
-2017: Fraunhofer selbst erklärte MP3 für "veraltet" (AAC besser)
+2017: Fraunhofer selbst erklärte MP3 für "veraltet" (AAC = Advanced Audio Coding, besser)
 -->
 
 ---
@@ -1550,7 +1796,7 @@ Aber: LimeWire, Kazaa, BitTorrent folgten
 → LimeWire, Kazaa, BitTorrent, später Spotify
 
 <!--
-RIAA (Recording Industry Association of America) verklagte Napster
+RIAA = Recording Industry Association of America – verklagte Napster
 Urteil: Napster muss schließen (2001)
 Aber: Technologie nicht mehr aufzuhalten
 iPod (2001): "1.000 songs in your pocket"
@@ -1618,7 +1864,7 @@ Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
 - Spektrogramme vergleichen Audacity (kostenloser Download nötig) [https://manual.audacityteam.org/man/spectrogram_view.html](https://manual.audacityteam.org/man/spectrogram_view.html)
 
 <!--
-Audacity: FOSS Audio-Editor (audacityteam.org)
+Audacity: FOSS (Free and Open-Source Software) Audio-Editor (audacityteam.org)
 Export: Datei → Exportieren → MP3 → Bitrate wählen
 Spektrogramm-Ansicht: Auf Track-Name klicken (Dropdown öffnet sich) → "Spektrogramm" wählen
 Hohe Frequenzen (oben im Bild) verschwinden bei niedriger Bitrate

slides/223015b/02-bild-audio-video.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
-footer: "Michael Czechowski – HdM Stuttgart"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
 ---
 
@@ -68,6 +68,38 @@ section.aufgabe {
 section.aufgabe footer {
   display: none;
 }
+section.erklaerung {
+  font-size: 1.1rem;
+  background: repeating-linear-gradient(
+    135deg,
+    #e3f2fd,
+    #e3f2fd 40px,
+    #fff 40px,
+    #fff 80px
+  ) !important;
+}
+@media print {
+  section.erklaerung {
+    background: #e3f2fd !important;
+  }
+}
+section.erklaerung h1 {
+  font-size: 1.5rem;
+  color: #1e5f8a;
+  margin-bottom: 0.3rem;
+}
+section.erklaerung ul,
+section.erklaerung ol {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung p {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung table {
+  font-size: 0.9rem;
+}
 </style>
 
 <!-- _class: invert -->
@@ -220,6 +252,26 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Rastergrafik – Vertiefung
+
+Ein Pixel ist die kleinste adressierbare Einheit. Bei 24-Bit-Farbtiefe speichert jeder Pixel drei 8-Bit-Werte (0–255) für Rot, Grün und Blau. Diese additive Farbmischung erzeugt 256³ = 16,7 Millionen mögliche Farbtöne.
+
+**Speicherberechnung:** `Breite × Höhe × Bytes pro Pixel`
+
+| Auflösung | Farbtiefe | Berechnung | Größe |
+|-----------|-----------|------------|-------|
+| 1920×1080 | 24 Bit (3 B) | 2.073.600 × 3 | 6,2 MB |
+| 4K (3840×2160) | 24 Bit | 8.294.400 × 3 | 24,9 MB |
+| 4K | 32 Bit (4 B) | 8.294.400 × 4 | 33,2 MB |
+
+Der Alpha-Kanal (32 Bit) speichert Transparenz als Wert von 0 (unsichtbar) bis 255 (vollständig sichtbar). PNG nutzt dies für weiche Kanten; JPEG unterstützt keinen Alpha-Kanal.
+
+---
+
 # Das Problem der Skalierung
 
 **Vergrößern:**
@@ -274,6 +326,30 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Vektorgrafik – Vertiefung
+
+Vektorgrafiken speichern keine Pixel, sondern mathematische Beschreibungen: Koordinaten, Kurvenparameter (Bézier-Kontrollpunkte), Füllfarben, Strichstärken. Der Renderer berechnet die Pixel erst bei der Ausgabe – daher beliebig skalierbar.
+
+**Bézier-Kurven** (Pierre Bézier, 1962, für Renault-Karosserien entwickelt):
+- Definiert durch Ankerpunkte und Kontrollpunkte
+- Kubische Bézier: 2 Anker + 2 Kontrollpunkte
+- Mathematisch exakt reproduzierbar
+
+| Aspekt | Raster | Vektor |
+|--------|--------|--------|
+| Skalierung 10× | Pixel sichtbar | Perfekt scharf |
+| Foto-Realismus | Gut geeignet | Unpraktikabel |
+| Dateigröße Logo | Wächst mit Auflösung | Konstant (~5 KB) |
+| Editierbarkeit | Destruktiv | Nicht-destruktiv |
+
+**Rasterisierung:** GPU wandelt Vektordaten in Pixel um. Geschieht bei jeder Darstellung neu – deshalb ist ein 4K-Monitor schärfer als ein 1080p-Monitor bei gleichem SVG.
+
+---
+
 # Raster- und Vektorgrafiken
 
 | | Raster | Vektor |
@@ -338,6 +414,28 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Psychovisuelle Wahrnehmung – Vertiefung
+
+Die Netzhaut enthält ~120 Mio. Stäbchen (Helligkeitswahrnehmung) aber nur ~6 Mio. Zapfen (Farbwahrnehmung). Dieses 20:1-Verhältnis erklärt, warum JPEG Farbinformationen stärker reduzieren kann als Helligkeitsinformationen.
+
+**Räumliche Frequenz** beschreibt, wie schnell sich die Helligkeit über eine Bildfläche ändert:
+- **Niedrig:** Himmel, Wand – große einheitliche Flächen
+- **Hoch:** Haare, Texturen, Schrift – schnelle Wechsel
+
+Das Auge ist ein Tiefpassfilter: Hohe Frequenzen (feine Details) werden schwächer wahrgenommen. JPEG verwirft daher zuerst die hohen Frequenzen – der Qualitätsverlust bleibt meist unsichtbar.
+
+| Biologisches Limit | Ausnutzung in JPEG |
+|-------------------|-------------------|
+| Farbauflösung ~20× geringer | Chroma Subsampling (4:2:0) |
+| Hohe Frequenzen unscharf | DCT + Quantisierung |
+| Kontrast-Maskierung | Artefakte in Texturen versteckt |
+
+---
+
 <!-- _header: '' -->
 <!-- _footer: '' -->
 
@@ -442,6 +540,34 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Farbraumkonversion – Vertiefung
+
+RGB→YCbCr nutzt die Biologie des menschlichen Auges: 120 Mio. Stäbchen (Helligkeit) vs. nur 6 Mio. Zapfen (Farbe) – ein 20:1-Verhältnis. Die Transformation erfolgt über eine lineare Matrix:
+
+```
+Y  =  0.299·R + 0.587·G + 0.114·B
+Cb = −0.169·R − 0.331·G + 0.500·B + 128
+Cr =  0.500·R − 0.419·G − 0.081·B + 128
+```
+
+Die Gewichtung (G dominiert mit 59%) entspricht der spektralen Empfindlichkeit des Auges bei Tageslicht. Y enthält alle Schärfeinformation; Cb/Cr können reduziert werden.
+
+**Chroma Subsampling – Notation J:a:b** (bezogen auf 4×2 Pixel):
+
+| Schema | Farbdaten | Einsatz |
+|--------|-----------|---------|
+| 4:4:4 | 100% | Postproduktion, Grafik |
+| 4:2:2 | 50% | Broadcast, Pro-Video |
+| 4:2:0 | 25% | JPEG, H.264, Streaming |
+
+Bei 4:2:0 teilen sich 4 Pixel einen Farbwert, behalten aber individuelle Helligkeit → 50% Dateneinsparung bei kaum sichtbarem Unterschied.
+
+---
+
 # JPEG Schritt 2: Chroma Subsampling
 
 **Notation `J:a:b`** (bezogen auf 4×2 Pixel-Block):
@@ -623,12 +749,36 @@ KLAUSURRELEVANT:
 - Präfix-frei: Kein Code ist Anfang eines anderen
 - Häufigstes Zeichen = kürzester Code
 - Auch in ZIP, PNG, MP3 verwendet
+-->
 
 ---
 
--->
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
 
+# Huffman-Coding – Vertiefung
 
+David Huffman entwickelte 1952 als Student am MIT einen optimalen Algorithmus für präfixfreie Codes – ursprünglich als Hausaufgabe, die zur Veröffentlichung führte.
+
+**Algorithmus (Bottom-Up-Baumkonstruktion):**
+1. Alle Symbole nach Häufigkeit sortieren
+2. Die zwei seltensten Symbole zu einem Knoten kombinieren
+3. Wiederholen bis nur noch die Wurzel übrig ist
+4. Codes ablesen: links = 0, rechts = 1
+
+**Präfixfreiheit:** Kein Code ist Anfang eines anderen → sofort dekodierbar ohne Trennzeichen.
+
+| Eigenschaft | Huffman | Arithmetisch |
+|-------------|---------|--------------|
+| Einheit | Ganze Bits | Fraktionale Bits |
+| Optimalität | Optimal für ganze Bits | Näher an Entropie |
+| Geschwindigkeit | Schneller | Langsamer |
+| JPEG-Einsatz | Standard (Baseline) | Optional (selten) |
+
+JPEG verwendet zwei Huffman-Tabellen: eine für DC-Koeffizienten (Durchschnittswerte), eine für AC-Koeffizienten (Frequenzen). Die Tabellen sind im JPEG-Header gespeichert.
+
+---
 
 <!-- _class: klausur -->
 <!-- _header: '' -->
@@ -772,6 +922,28 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# WebP & AVIF – Vertiefung
+
+**WebP** entstand 2010 aus Googles VP8-Videocodec (On2 Technologies, für $133M gekauft). Statt I-Frames für Video werden sie als Einzelbilder verwendet. WebP nutzt Intra-Frame-Prediction, die benachbarte Blöcke zur Vorhersage verwendet – effizienter als JPEGs blockweise DCT.
+
+**AVIF** basiert auf dem AV1-Videocodec, entwickelt 2015–2018 von der Alliance for Open Media (Google, Apple, Netflix, Amazon, Microsoft, Mozilla). Nach dem Patent-Chaos von H.265/HEVC vereinten sich die Konkurrenten für einen lizenzfreien Standard.
+
+| Aspekt | WebP | AVIF |
+|--------|------|------|
+| Basis-Codec | VP8/VP9 | AV1 |
+| Kompression vs. JPEG | 25–35% besser | 50% besser |
+| HDR/Wide Gamut | Nein | Ja (10/12 Bit) |
+| Encoding-Geschwindigkeit | Schnell | Sehr langsam |
+| Browser-Support 2025 | 97%+ | 93%+ |
+
+**Warum JPEG dominiert:** Kameras, Bildbearbeitungssoftware und Content-Management-Systeme sind auf JPEG optimiert. Der Wechsel erfordert Infrastruktur-Updates über die gesamte Pipeline.
+
+---
+
 # Formatwahl in der Praxis
 
 | Anwendung | Format |
@@ -890,6 +1062,33 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Container vs. Codec – Vertiefung
+
+**Container** (Multiplexer-Format) organisiert mehrere Datenströme mit Timing-Informationen. Er enthält keine Kompressionslogik, sondern synchronisiert Video, Audio, Untertitel und Metadaten.
+
+**Codec** (Coder-Decoder) definiert den Kompressionsalgorithmus. Derselbe Container kann verschiedene Codecs enthalten – die Dateiendung verrät den Codec nicht.
+
+| Container | Entwickler | Typische Codecs | Besonderheit |
+|-----------|------------|-----------------|--------------|
+| MP4 | ISO/MPEG | H.264, H.265, AAC | Web-Standard, DRM-fähig |
+| MKV | Matroska | Alle | Beliebig viele Streams, Kapitel |
+| WebM | Google | VP9, AV1, Opus | HTML5-optimiert, lizenzfrei |
+| MOV | Apple | ProRes, H.264 | Professionelle Produktion |
+
+**Metadaten im Container:**
+- Timecodes für Frame-genaue Synchronisation
+- Kapitelmarken, Thumbnails
+- Sprach-Tags für Audio/Untertitel
+- HDR-Metadaten (MaxCLL, MaxFALL)
+
+**Praktisches Problem:** Eine `.mp4`-Datei mit AV1-Codec spielt auf älteren Geräten nicht ab, obwohl sie MP4 „unterstützen" – der Hardware-Decoder fehlt für AV1.
+
+---
+
 # Gängige Container
 
 | Container | Verwendung |
@@ -1115,6 +1314,32 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# H.264/AVC – Vertiefung
+
+H.264 (2003) ermöglichte erst YouTube (2005), Netflix-Streaming (2007) und Blu-ray. Vor H.264 war MPEG-2 Standard – H.264 erreichte bei gleicher Qualität die halbe Bitrate.
+
+**Technische Innovationen:**
+- **Variable Blockgrößen:** 16×16 bis 4×4 Macroblocks (MPEG-2: nur 16×16)
+- **Intra-Prediction:** Blöcke werden aus Nachbarn vorhergesagt
+- **In-Loop Deblocking:** Filter reduziert Blockartefakte vor der Referenzierung
+- **CABAC:** Arithmetic Coding ersetzt Huffman (10–15% effizienter)
+
+| Profile | Anwendung | Max. Auflösung |
+|---------|-----------|----------------|
+| Baseline | Videotelefonie, ältere Geräte | 480p |
+| Main | Broadcast, Streaming | 1080p |
+| High | Blu-ray, professionell | 4K |
+
+**Hardware-Ubiquität:** Seit 2010 hat jedes Smartphone, jede GPU, jeder Smart-TV einen H.264-Hardware-Decoder. Encoding in Echtzeit braucht keine CPU – das ermöglichte erst mobiles Video-Streaming und Videotelefonie.
+
+**Patent-Pool (MPEG-LA):** ~2.000 Patente von 30+ Unternehmen. Endnutzer-Streaming ist lizenzfrei; Hardware-Hersteller zahlen ~$0,20/Gerät.
+
+---
+
 # Das Patent-Problem
 
 **H.264 ist nicht frei**
@@ -1221,6 +1446,29 @@ KLAUSURRELEVANT:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# AV1 – Vertiefung
+
+Die **Alliance for Open Media** (2015) vereinte Konkurrenten nach dem Patent-Chaos von H.265/HEVC. Drei separate Patent-Pools (MPEG-LA, HEVC Advance, Velos Media) machten H.265-Lizenzierung unberechenbar – die Industrie wollte einen garantiert lizenzfreien Standard.
+
+**Gründungsmitglieder:** Google, Mozilla, Cisco, Netflix, Amazon, Microsoft. Apple trat 2018 bei – historisch, da Apple sonst eigene Standards bevorzugt.
+
+| Technische Innovation | Beschreibung |
+|----------------------|--------------|
+| Superblocks | Bis 128×128 Pixel (H.264: max 16×16) |
+| Prediction Modes | 56 Intra-Modi (H.264: 9) |
+| Transform | 10 verschiedene Transformtypen |
+| Film Grain Synthesis | Filmkorn wird als Parameter übertragen |
+
+**Encoding-Performance:** Software-Encoding ist 50–200× langsamer als H.264. Erst Hardware-Encoder (Intel ab Gen 12, NVIDIA RTX 40, Apple M3) machen Echtzeit-Encoding praktikabel.
+
+**Adoption 2025:** YouTube und Netflix nutzen AV1 für 4K/8K-Streams. 2024 gewann AV1 einen Emmy für technische Innovation – offene Standards können Industriestandard werden.
+
+---
+
 <!-- _header: '' -->
 <!-- _footer: 'https://blog.mozilla.org/en/mozilla/av1-video-codec-wins-emmy/' -->
 

slides/223015b/03-speichermedien-schnittstellen.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
-footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
 ---
 
@@ -68,6 +68,38 @@ section.aufgabe {
 section.aufgabe footer {
   display: none;
 }
+section.erklaerung {
+  font-size: 1.1rem;
+  background: repeating-linear-gradient(
+    135deg,
+    #e3f2fd,
+    #e3f2fd 40px,
+    #fff 40px,
+    #fff 80px
+  ) !important;
+}
+@media print {
+  section.erklaerung {
+    background: #e3f2fd !important;
+  }
+}
+section.erklaerung h1 {
+  font-size: 1.5rem;
+  color: #1e5f8a;
+  margin-bottom: 0.3rem;
+}
+section.erklaerung ul,
+section.erklaerung ol {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung p {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung table {
+  font-size: 0.9rem;
+}
 </style>
 
 <!-- _class: invert -->
@@ -82,7 +114,7 @@ section.aufgabe footer {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
-**Wintersemester 2025/26**
+**Sommersemester 2026**
 
 [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
 
@@ -235,6 +267,29 @@ Kleine SSD für System + große HDD für Archiv.
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# HDD vs. SSD – Vertiefung
+
+**HDD (Hard Disk Drive):** Magnetplatten rotieren mit 5.400–7.200 RPM; ein Schreib-/Lesekopf schwebt nanometerweit über der Oberfläche. Die Zugriffszeit setzt sich zusammen aus Seek Time (Kopf bewegen) + Rotational Latency (warten auf Sektor).
+
+**SSD (Solid State Drive):** NAND-Flash-Zellen speichern Bits als elektrische Ladung. Kein mechanischer Zugriff → konstant schnelle Latenz. Aber: Zellen haben begrenzte Schreibzyklen (P/E Cycles).
+
+| Aspekt | HDD | SATA SSD | NVMe SSD |
+|--------|-----|----------|----------|
+| Latenz | 5–10 ms | 0,1 ms | 0,02 ms |
+| Seq. Lesen | 150 MB/s | 550 MB/s | 7.000 MB/s |
+| IOPS (4K random) | 100 | 90.000 | 1.000.000 |
+| TBW (1 TB Modell) | ∞ | 600 TBW | 600 TBW |
+
+**Wear Leveling:** SSD-Controller verteilen Schreibvorgänge gleichmäßig, um einzelne Zellen nicht vorzeitig zu erschöpfen. TRIM informiert den Controller über gelöschte Blöcke.
+
+**Praxis:** System-SSD für OS/Anwendungen (Geschwindigkeit), HDD für Medienarchiv (Kapazität/Preis). RAID schützt vor Einzelausfällen bei beiden.
+
+---
+
 <!-- _class: lead -->
 
 # Dateisysteme
@@ -484,6 +539,30 @@ Warum 1 Offsite?
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# 3-2-1-Backup-Regel – Vertiefung
+
+Peter Krogh formulierte die Regel 2005 in „The DAM Book" (Digital Asset Management). Sie schützt gegen unterschiedliche Verlustszenarien:
+
+| Bedrohung | Schutz durch | Beispiel |
+|-----------|--------------|----------|
+| Hardware-Defekt | 3 Kopien | SSD stirbt → HDD-Backup vorhanden |
+| Firmware-Bug/Ransomware | 2 Medientypen | Malware infiziert nur ein System |
+| Feuer/Diebstahl/Flut | 1 Offsite | Haus brennt → Cloud-Backup sicher |
+
+**Moderne Erweiterung 3-2-1-1-0:**
+- **+1** Air-Gapped (offline, nicht verbunden)
+- **+0** Verifizierte Backups (regelmäßig Restore testen)
+
+**Ransomware-Problem:** Vernetzte Backups werden oft mitverschlüsselt. Air-Gapped-Medien (externe HDD im Safe, LTO-Band) bleiben sicher, weil sie physisch getrennt sind.
+
+**Realitäts-Check:** Die meisten Datenverluste entstehen durch menschliche Fehler (versehentliches Löschen), nicht Hardware-Ausfälle. Versionierte Backups (Time Machine, Borg) schützen auch davor – die gelöschte Datei existiert noch in älteren Snapshots.
+
+---
+
 # Backup-Arten
 
 **Vollständig (Full):**

slides/223015b/04-distribution-apis-zukunft.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
-footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
 ---
 
@@ -83,7 +83,7 @@ section.aufgabe footer {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
-**Wintersemester 2025/26**
+**Sommersemester 2026**
 
 [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
 

slides/223015b/05-vertiefung-offene-fragen.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
-footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
 ---
 
@@ -83,7 +83,7 @@ section.aufgabe footer {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
-**Wintersemester 2025/26**
+**Sommersemester 2026**
 
 [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
 

slides/223015b/klausurfolien.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
-footer: "Michael Czechowski – HdM Stuttgart"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
 ---
 <style>
@@ -92,6 +92,8 @@ section.aufgabe footer {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
+**Sommersemester 2026**
+
 [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
 
 ---
@@ -110,7 +112,7 @@ Hochschule der Medien Stuttgart
 | **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
 
 **Faustregel:**
-- Medien für Endnutzer → Lossy oft akzeptabel
+- Medien für EndnutzerInnen → Lossy oft akzeptabel
 - Quellmaterial, Code, Archive → Lossless nötig
 
 <!--
@@ -208,13 +210,13 @@ VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
 ### Distribution: physisch (Kauf, Verleih, Kopie)
 
 - **Text**
-  - Bücher, Zeitungen, Zeitschriften, Lochkarten
+    - Bücher, Zeitungen, Zeitschriften, Lochkarten
 - **Bild**
-  - Fotografie (Negativ, Dia, Polaroid), Mikrofilm
+    - Fotografie (Negativ, Dia, Polaroid), Mikrofilm
 - **Audio:**
-  - Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
+    - Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
 - **Video:**
-  - Film (35mm, Super 8), VHS, Betamax
+    - Film (35mm, Super 8), VHS, Betamax
 
 
 ---
@@ -227,13 +229,13 @@ VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
 ### Distribution: Datenträger (CD, USB), Download, Streaming, P2P
 
 - **Text**
-  - E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
+    - E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
 - **Bild**
-  - Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
+    - Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
 - **Audio**
-  - Audiodatei (MP3, FLAC, WAV, AAC, OGG)
+    - Audiodatei (MP3, FLAC, WAV, AAC, OGG)
 - **Video**
-  - Videodatei (MP4, MKV, AVI, WebM)
+    - Videodatei (MP4, MKV, AVI, WebM)
 
 
 ---
@@ -245,13 +247,13 @@ VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
 # Digitale Speichermedien
 
 - **Optische Speicher**
-  - CD, DVD, Blu-ray
+    - CD, DVD, Blu-ray
 - **Magnetische Speicher**
-  - Festplatte (HDD), Magnetband (LTO)
+    - Festplatte (HDD), Magnetband (LTO)
 - **Flash-Speicher**
-  - SSD, USB-Stick, SD-Karte
+    - SSD, USB-Stick, SD-Karte
 - **Cloud-Speicher**
-  - Dropbox, Google Drive, iCloud, AWS S3
+    - Dropbox, Google Drive, iCloud, AWS S3
 
 
 ---
@@ -277,14 +279,12 @@ Breite × Höhe × Farbtiefe (in Bytes)
 | 32 | 16,7 Mio. + Alpha | Transparenz |
 
 <!--
-BERECHNUNG: Breite × Höhe × (Farbtiefe / 8)
-BEISPIEL: 1920×1080 × 24 Bit = 1920×1080×3 = 6.220.800 Bytes ≈ 6,2 MB
-
-Farbtiefe erklärt:
-- 1 Bit: 2^1 = 2 Farben
-- 8 Bit: 2^8 = 256 Farben
-- 24 Bit: 2^24 = 16.777.216 Farben (je 8 Bit für R, G, B)
-- 32 Bit: 24 Bit + 8 Bit Alpha-Kanal
+KLAUSURRELEVANT:
+- Formel: Breite × Höhe × (Farbtiefe / 8) = Bytes
+- Beispielrechnung: 1920 × 1080 × 3 = 6.220.800 Bytes ≈ 6,2 MB
+- Farbtiefe: 2^n Farben bei n Bit
+- 24 Bit = 8 Bit pro Kanal (R, G, B)
+- 32 Bit = 24 Bit + 8 Bit Alpha (Transparenz)
 -->
 
 
@@ -306,17 +306,15 @@ Farbtiefe erklärt:
 <circle cx="50" cy="50" r="40" fill="#ff0000"/>
 ```
 
-<small>SVG beschreibt nicht jeden einzelnen Pixel im Raster, sondern deklariert wie Farben und Formen gesetzt werden.</small>
+<small>SVG beschreibt WAS gezeichnet werden soll, nicht WIE jeder Pixel aussieht.</small>
 
 <!--
-Vektorgrafiken beschreiben WAS gezeichnet werden soll.
-Rastergrafiken beschreiben WIE jeder Pixel aussieht.
-
-Rendering-Pipeline:
-Vektordaten → Rasterisierung → Framebuffer → Display
-
-Beim Skalieren werden einfach die Koordinaten multipliziert.
-Keine Information geht verloren.
+KLAUSURRELEVANT:
+- Vektor = Beschreibung (deklarativ)
+- Raster = Pixel für Pixel (imperativ)
+- Rendering-Pipeline: Vektordaten → Rasterisierung → Display
+- Skalierung = Koordinaten multiplizieren → keine Information geht verloren
+- SVG = Scalable Vector Graphics (Web-Standard)
 -->
 
 
@@ -334,18 +332,17 @@ Keine Information geht verloren.
 - Niedrige Frequenzen besser als hohe
 
 **JPEG nutzt das aus:**
-- Farbauflösung reduzieren (aber Helligkeit behalten)
+- Farbauflösung reduzieren (Helligkeit behalten)
 - Glatte Flächen effizient speichern
-- Hohe Frequenzen (Details) verwerfen
+- Hohe Frequenzen (feine Details) verwerfen
 
 <!--
-Das ist die visuelle Entsprechung zur Psychoakustik.
-
-Das Auge hat mehr Rezeptoren für Helligkeit (Stäbchen)
-als für Farbe (Zapfen).
-
-Hohe Frequenzen = schnelle Wechsel = feine Details
-Niedrige Frequenzen = langsame Wechsel = große Flächen
+KLAUSURRELEVANT:
+- Mehr Stäbchen (Helligkeit) als Zapfen (Farbe) im Auge
+- "Frequenz" = räumliche Frequenz = wie schnell ändert sich Helligkeit?
+- Niedrig = langsame Änderung = große gleichmäßige Fläche
+- Hoch = schnelle Änderung = feine Details, Kanten
+- Analogie zur Psychoakustik bei MP3 (letztes Mal)
 -->
 
 
@@ -357,24 +354,25 @@ Niedrige Frequenzen = langsame Wechsel = große Flächen
 
 ![bg right:20%](./assets/Barn-yuv.png)
 
-# JPEG: Schritt 1 – Farbraumkonversion
+# JPEG Schritt 1: Farbraumkonversion
 
-**RGB → Y'CbCr** (seltener Y'UV)
+**RGB → Y'CbCr**
 
-- **Y** = Helligkeit (Luminanz) – Was das Auge am besten sieht
+- **Y** = Helligkeit (Luminanz)
 - **Cb** = Blau-Gelb-Anteil (Chrominanz)
 - **Cr** = Rot-Grün-Anteil (Chrominanz)
 
-**Warum diese Trennung?**
-Y (Helligkeit) behält volle Auflösung.
-Cb/Cr (Farbe) kann reduziert werden – Auge merkt es kaum.
+**Warum?**
+Y (Helligkeit) behält volle Auflösung
+Cb/Cr (Farbe) kann reduziert werden
 
 <!--
-YCbCr ist wie RGB ein Tripel aus 3 Werten pro Pixel.
-Der Unterschied: Statt Rot-Grün-Blau speichern wir Helligkeit + 2 Farbdifferenzen.
-
-Die Umrechnung ist reversibel (mathematische Transformation).
-Der Clou: Jetzt können wir Helligkeit und Farbe getrennt behandeln.
+KLAUSURRELEVANT:
+- YCbCr = auch 3 Werte pro Pixel, aber anders organisiert
+- Statt R-G-B: Helligkeit + 2 Farbdifferenzen
+- Umrechnung ist reversibel (mathematische Transformation)
+- Vorteil: Helligkeit und Farbe getrennt behandelbar
+- Bild zeigt: Y (oben), Cb (Mitte), Cr (unten)
 -->
 
 
@@ -384,14 +382,14 @@ Der Clou: Jetzt können wir Helligkeit und Farbe getrennt behandeln.
 <!-- _footer: "" -->
 
 
-# JPEG: Schritt 6 – Huffman-Coding
+# JPEG Schritt 6: Huffman-Coding
 
 **Verlustfreie Kompression der Restwerte**
 
-**Idee:** Statt fester 8 Bit pro Wert → variable Bitlänge
-Häufige Werte bekommen kurze Bit-Sequenzen.
+**Idee:** Variable Bitlänge statt fester 8 Bit
+Häufige Werte → kurze Codes
 
-| Zeichen | Häufigkeit | Code (Bit-Sequenz) |
+| Zeichen | Häufigkeit | Code |
 |---------|------------|------|
 | e | 40% | `0` (1 Bit) |
 | a | 25% | `10` (2 Bit) |
@@ -400,9 +398,74 @@ Häufige Werte bekommen kurze Bit-Sequenzen.
 | u | 5% | `1111` (4 Bit) |
 
 <!--
-Huffman-Coding ist verlustfrei.
-Der "Code" ist eine Bit-Sequenz, die das Zeichen eindeutig identifiziert.
-Weil "e" am häufigsten vorkommt, bekommt es den kürzesten Code.
+KLAUSURRELEVANT:
+- Huffman = verlustfrei, optimal für bekannte Häufigkeiten
+- Präfix-frei: Kein Code ist Anfang eines anderen
+- Häufigstes Zeichen = kürzester Code
+- Auch in ZIP, PNG, MP3 verwendet
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+<!--
+# Huffman-Coding: Beispiel
+
+**Originaltext:** `ABRACADABRA` (11 Zeichen × 8 Bit = 88 Bit)
+
+**Häufigkeitsanalyse:**
+A=5, B=2, R=2, C=1, D=1
+
+**Huffman-Baum → Codes:**
+| Zeichen | Häufigkeit | Code |
+|---------|------------|------|
+| A | 5 | `0` |
+| B | 2 | `10` |
+| R | 2 | `110` |
+| C | 1 | `1110` |
+| D | 1 | `1111` |
+
+**Codiert:** `0 10 110 0 1110 0 1111 0 10 110 0` = **23 Bit**
+**Kompression:** 88 → 23 Bit = **74% gespart**
+
+
+- Beispiel Schritt für Schritt durchrechnen
+- Warum funktioniert's? A kommt 5× vor, bekommt kürzesten Code
+- Präfix-Eigenschaft: Kein Code ist Anfang eines anderen → eindeutig dekodierbar
+- Frage: "Was passiert, wenn alle Zeichen gleich häufig sind?" → Keine Ersparnis
+- In JPEG: Nicht Buchstaben, sondern DCT-Koeffizienten werden so codiert
+-->
+
+
+---
+
+<!-- _header: "" -->
+<!-- _footer: "" -->
+
+
+# WebP & AVIF: Moderne Alternativen
+
+**WebP (Google, 2010):**
+- Lossy und Lossless
+- Transparenz und Animationen
+- 25–35% kleiner als JPEG
+
+**AVIF (2019):**
+- Basiert auf AV1-Video-Codec
+- 50% kleiner als JPEG
+- HDR-Unterstützung, patent-frei
+
+**Browser-Support 2025:** WebP universell, AVIF wächst
+
+<!--
+KLAUSURRELEVANT:
+- WebP: VP8-Kompression (Google Video-Codec)
+- AVIF: Alliance for Open Media (Google, Netflix, Amazon, Apple, Mozilla)
+- Beide besser als JPEG, aber Kompatibilität bleibt Problem
+- JPEG bleibt dominant: alte Kameras, Software, Workflows
 -->
 
 
@@ -414,28 +477,22 @@ Weil "e" am häufigsten vorkommt, bekommt es den kürzesten Code.
 
 # Container und Codec
 
-**Container = Das Dateiformat (Beispiel: MP4)**
+**Container = Dateiformat (z.B. MP4)**
 Die "Box", die verschiedene Streams zusammenpackt:
 - Video-Stream
 - Audio-Stream(s)
 - Untertitel
 - Metadaten
 
-**Codec = Der Kompressionsalgorithmus (Beispiel: AV1)**
-Entscheidet, WIE komprimiert wird.
-
+**Codec = Kompressionsalgorithmus (z.B. H.264)**
+Bestimmt, WIE komprimiert wird
 
 <!--
-Container ≠ Codec
-Das ist ein häufiges Missverständnis.
-
-MP4 ist ein Container, nicht ein Codec.
-Ein MP4 kann H.264, H.265 oder AV1 enthalten.
-
-Übrigens: JPEG ist ein Codec (für Bilder), kein Container.
-Bei Bildern fallen Container und Codec oft zusammen.
-
-Tools wie MediaInfo zeigen beide Informationen.
+KLAUSURRELEVANT:
+- Container ≠ Codec (häufiges Missverständnis!)
+- MP4 kann H.264, H.265 oder AV1 enthalten
+- Gleiche Endung, unterschiedlicher Inhalt
+- Tool-Tipp: MediaInfo zeigt beides an
 -->
 
 
@@ -451,19 +508,19 @@ Tools wie MediaInfo zeigen beide Informationen.
 
 **Warum dominant?**
 - Exzellente Kompression (~100:1 möglich)
-- Hardware-Support in jedem Gerät seit ~2010
+- Hardware-Decoder in jedem Gerät seit ~2010
 - YouTube, Netflix, Blu-ray – alles H.264
 
 **Features:**
 - Variable Block-Größen (16×16 bis 4×4)
-- Deblocking-Filter (reduziert Block-Artefakte)
+- Deblocking-Filter (reduziert Artefakte)
 
 <!--
-H.264 revolutionierte Video-Streaming.
-Ohne H.264 kein Netflix, kein YouTube in HD.
-
-Hardware-Decoder bedeutet: Kein CPU-Aufwand, kein Akku-Drain.
-Selbst billige Smartphones können H.264 abspielen.
+KLAUSURRELEVANT:
+- H.264 revolutionierte Video-Streaming
+- Ohne H.264 kein Netflix, kein YouTube HD
+- Hardware-Decoder = kein CPU-Aufwand, kein Akku-Drain
+- Selbst billigste Smartphones können H.264 abspielen
 -->
 
 
@@ -486,17 +543,16 @@ Google, Netflix, Amazon, Microsoft, Apple, Mozilla...
 - 8K, HDR, hohe Frame-Rates
 
 **Stand 2025:**
-YouTube und Netflix nutzen AV1 für 4K/8K
+YouTube, Netflix nutzen AV1 für 4K/8K
 Hardware-Encoder in aktuellen GPUs
 
 <!--
-AOM = Alliance for Open Media, gegründet 2015.
-Historisch: Konkurrierende Tech-Giganten vereint.
-
-Das Ziel: Nie wieder Patent-Chaos wie bei H.265.
-
-Problem: Encoding ist sehr langsam (10-100× vs. H.264).
-Hardware-Encoder lösen das zunehmend.
+KLAUSURRELEVANT:
+- AOM gegründet 2015 – historisch: Konkurrenten vereint
+- Ziel: Nie wieder Patent-Chaos wie bei H.265
+- Problem: Encoding sehr langsam (10–100× vs. H.264)
+- Hardware-Encoder lösen das zunehmend
+- AV1 gewann 2024 einen Emmy für technische Innovation
 -->
 
 

slides/223015c/00-intro.md

@@ -0,0 +1,228 @@
+---
+marp: true
+theme: gaia
+paginate: true
+backgroundColor: #fff
+header: "Grundlagen IT- und Internettechnik (223015c)"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
+title: Grundlagen IT- und Internettechnik
+---
+
+<style>
+:root {
+  --color-foreground: #1a1a2e;
+  --color-highlight: #d63384;
+  --color-dimmed: #4a4a6a;
+}
+section.invert {
+  --color-foreground: #fff;
+}
+section {
+  font-size: 1.7rem;
+}
+h1 {
+  color: #a02060;
+}
+section.invert h1 {
+  color: #fff;
+}
+h2 {
+  color: #1f2937;
+}
+pre {
+  background: #0f0f23;
+  color: #d63384;
+  border-radius: 8px;
+  border-left: 3px solid #d63384;
+}
+pre code {
+  background: transparent;
+  color: inherit;
+}
+code {
+  background: #1a1a2e;
+  color: #d63384;
+  padding: 0.15em 0.4em;
+  border-radius: 4px;
+}
+a {
+  color: var(--color-highlight);
+}
+section.klausur {
+  background: repeating-linear-gradient(
+    135deg,
+    #fce4ec,
+    #fce4ec 40px,
+    #fff 40px,
+    #fff 80px
+  ) !important;
+}
+@media print {
+  section.klausur {
+    background: #fce4ec !important;
+  }
+}
+section.aufgabe {
+  background: #fce4ec !important;
+}
+section.aufgabe footer {
+  display: none;
+}
+</style>
+
+<!-- _class: invert -->
+<!-- _header: '' -->
+<!-- _backgroundColor: #000 -->
+
+![bg cover opacity:0.2](./assets/background-termin-1.png)
+
+# Grundlagen IT- und Internettechnik
+
+**223015c** · Modul "Technik 1" · 1. Semester
+Digital- und Medienwirtschaft
+Hochschule der Medien Stuttgart
+
+**Sommersemester 2026**
+
+[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/qr/slides-223015c.png)
+
+---
+
+<!-- _class: lead -->
+
+# Herzlich willkommen!
+## Einführung
+
+---
+
+# Über mich
+
+**Michael Werner Czechowski**
+
+- Systems and Platform Engineer
+- Schwerpunkte:
+  - Web-Technologien, Barriere-Armut, Open Source
+- Hintergrund:
+  - Philosophie (Uni Stuttgart)
+  - Wirtschaftsinformatik (Leibniz-FH Hannover)
+- Kontakt: lb-czechowski@hdm-stuttgart.de
+
+---
+
+# Warum dieses Modul?
+
+**Das Internet ist überall** – aber was steckt dahinter?
+
+* Warum sehen Webseiten auf dem Handy anders aus?
+* Wie funktioniert eigentlich das Internet?
+* Wie erkennen Sie, ob eine Werbeagentur gute Arbeit leistet?
+* Was hat ein Unterseekabel mit meiner E-Mail zu tun?
+* **→ Die Technik dahinter verstehen und fundierte Entscheidungen treffen**
+
+---
+
+# Das Ziel
+
+**Technische Grundlagen verstehen**, um fundierte Entscheidungen treffen zu können.
+
+Als Digital- und MedienwirtschaftlerInnen werdet ihr täglich mit technischen Fragen konfrontiert:
+* Wie baue ich eine barrierearme Webseite?
+* Welches Protokoll für welchen Zweck?
+* Wie funktioniert das Web hinter den Kulissen?
+* **→ Mitreden können – und selbst Webseiten bauen!**
+
+---
+
+# Was Sie hier lernen werden
+
+**In dieser Veranstaltung erwerben Sie folgende Kompetenzen:**
+
+* Geschichte des Computers und Internets
+* HTML-Grundlagen und semantisches Markup
+* CSS für Layout und Gestaltung
+* Netzwerke und Protokolle (TCP/IP, DNS, HTTP(S))
+* "Barrierefreiheit" im Web
+* Grundlagen von JavaScript und Interaktivität
+
+---
+
+# Kurze Umfrage
+
+**Bitte Hand heben:**
+* Wer hat schon mal eine Webseite gebaut?
+* Wer weiß, was HTML ist?
+* Wer hat schon mal CSS geschrieben? 
+* Wer kennt den Unterschied zwischen Internet und WWW? 
+* Wer hat schon mal mit JavaScript gearbeitet?
+
+---
+
+# Kursübersicht
+
+**Kapitel:**
+
+1. Geschichte, Grundlagen & **HTML**
+2. Netzwerke, Protokolle, **semantisches HTML** & **CSS**
+3. Interaktivität, Animationen & **JavaScript**
+
+**Ziel:** "Gelernte Hilflosigkeit" ablegen
+
+---
+
+<!-- _class: klausur -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+<!-- _backgroundColor: #fce4ec -->
+
+# Prüfungsleistung
+
+**Nach aktuellem Kenntnisstand:**
+
+* 90 min insg. (Technik 1)
+* Schriftliche Klausur (digital)
+* Teils offene Fragen
+* So gut wie kein Coding/Programmieren
+* **Prüfungsrelevant:** Folien sind markiert mit anderem Hintergrund
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/klausur-01.png)
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/klausur-02.png)
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/klausur-03.png)
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/splan.png)
+
+---
+
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+![bg fit](./assets/asta.png)
+

slides/223015c/02-netzwerke-protokolle-css.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Grundlagen IT- und Internettechnik (223015c)"
-footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: "Kapitel 2: Netzwerke, Protokolle & CSS"
 ---
 
@@ -71,6 +71,38 @@ section.aufgabe footer {
 section.glossar {
   font-size: 1.4rem;
 }
+section.erklaerung {
+  font-size: 1.1rem;
+  background: repeating-linear-gradient(
+    135deg,
+    #fce4ec,
+    #fce4ec 40px,
+    #fff 40px,
+    #fff 80px
+  ) !important;
+}
+@media print {
+  section.erklaerung {
+    background: #fce4ec !important;
+  }
+}
+section.erklaerung h1 {
+  font-size: 1.5rem;
+  color: #a02060;
+  margin-bottom: 0.3rem;
+}
+section.erklaerung ul,
+section.erklaerung ol {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung p {
+  font-size: 1.0rem;
+  line-height: 1.4;
+}
+section.erklaerung table {
+  font-size: 0.9rem;
+}
 </style>
 
 <!-- _class: invert -->
@@ -86,7 +118,7 @@ section.glossar {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
-**Wintersemester 2025/26**
+**Sommersemester 2026**
 
 [https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
 
@@ -402,6 +434,31 @@ SPEAKER NOTES:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# TCP/IP-Modell – Vertiefung
+
+Das TCP/IP-Modell entstand praktisch aus dem ARPANET (1970er), im Gegensatz zum theoretischen OSI-Modell (7 Schichten, 1984). TCP/IP hat sich durchgesetzt, weil es das reale Internet beschreibt.
+
+**Schicht-Aufgaben im Detail:**
+
+| Schicht | Frage | Protokolle | Geräte |
+|---------|-------|------------|--------|
+| 4 Anwendung | Was will ich? | HTTP, DNS, SMTP, FTP | – (Software) |
+| 3 Transport | Kommt es an? Welches Programm? | TCP, UDP | – (Software) |
+| 2 Internet | Welcher Rechner weltweit? | IP, ICMP | Router |
+| 1 Netzzugang | Wie zum Nachbarn? | Ethernet, WLAN, PPP | Switch, Access Point |
+
+**OSI vs. TCP/IP:**
+- OSI Schicht 5–7 (Session, Presentation, Application) → TCP/IP Schicht 4
+- OSI Schicht 1–2 (Physical, Data Link) → TCP/IP Schicht 1
+
+**Warum Schichten?** Abstraktion. HTTP muss nicht wissen, ob Ethernet oder WLAN verwendet wird. Änderungen in einer Schicht betreffen andere nicht.
+
+---
+
 # Schichten verpacken Daten
 
 ```
@@ -461,6 +518,33 @@ SPEAKER NOTES:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Dateneinheiten & Encapsulation – Vertiefung
+
+**Encapsulation** (Verkapselung): Jede Schicht fügt ihren Header hinzu, ohne den Inhalt der oberen Schicht zu verändern.
+
+**Was jeder Header enthält:**
+
+| Schicht | Einheit | Header-Inhalte |
+|---------|---------|----------------|
+| Anwendung | Daten | HTTP-Header, Cookies, Content-Type |
+| Transport | Segment | Quell-/Zielport, Sequenznummer, Flags (SYN, ACK) |
+| Internet | Paket | Quell-/Ziel-IP, TTL, Protokoll (TCP=6, UDP=17) |
+| Netzzugang | Frame | Quell-/Ziel-MAC, EtherType, CRC-Prüfsumme |
+
+**Overhead-Rechnung (1 Byte HTTP-Body):**
+- Ethernet: 14 + 4 Bytes (Header + Trailer)
+- IP: 20 Bytes (ohne Optionen)
+- TCP: 20 Bytes (ohne Optionen)
+- **Minimum: 58 Bytes für 1 Byte Nutzlast**
+
+**Decapsulation:** Empfänger packt in umgekehrter Reihenfolge aus. Jede Schicht prüft ihren Header (z.B. CRC) und reicht Nutzdaten nach oben.
+
+---
+
 # Warum ist das clever?
 
 **Ohne Schichten:**
@@ -640,6 +724,34 @@ SPEAKER NOTES:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# IP, MAC, Port – Vertiefung
+
+Drei Adressebenen lösen drei verschiedene Probleme:
+
+**IP-Adresse (Schicht 2 – Internet):**
+- Hierarchisch aufgebaut: Netzwerk-Teil + Host-Teil
+- Router lesen nur den Netzwerk-Teil für Routing-Entscheidungen
+- IPv4: 32 Bit (z.B. 192.168.1.1), IPv6: 128 Bit
+
+**MAC-Adresse (Schicht 1 – Netzzugang):**
+- 48 Bit, vom Hersteller fest vergeben (theoretisch)
+- Erste 24 Bit = OUI (Organizationally Unique Identifier) = Hersteller
+- Nur relevant für den **nächsten Hop** – wird bei jedem Router ersetzt
+- ARP (Address Resolution Protocol) übersetzt IP → MAC
+
+**Port (Schicht 3 – Transport):**
+- 16 Bit → 65.535 mögliche Ports
+- Well-Known Ports (0–1023): HTTP=80, HTTPS=443, SSH=22
+- Ephemeral Ports (49152–65535): Dynamisch für Client-Verbindungen
+
+**Warum ändert sich nur MAC?** IP ist das Endziel (Brief-Adresse), MAC ist der aktuelle Bote (wer trägt den Brief gerade?).
+
+---
+
 <!-- _class: lead -->
 
 # Die Reise eines Klicks
@@ -922,6 +1034,36 @@ SPEAKER NOTES:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# 3-Way-Handshake – Vertiefung
+
+Der Handshake synchronisiert **Sequenznummern** – essenziell für TCPs Zuverlässigkeit.
+
+**Warum zufällige Startwerte (ISN)?**
+- Sicherheit: Verhindert Session-Hijacking durch Raten
+- Eindeutigkeit: Unterscheidet alte von neuen Verbindungen
+- ISN = Initial Sequence Number, vom OS zufällig gewählt
+
+**TCP-Flags im Handshake:**
+
+| Paket | Flags | Bedeutung |
+|-------|-------|-----------|
+| 1 | SYN | Client will Verbindung, sendet seine ISN |
+| 2 | SYN+ACK | Server akzeptiert, sendet seine ISN, bestätigt Client-ISN+1 |
+| 3 | ACK | Client bestätigt Server-ISN+1 |
+
+**Was passiert bei Problemen?**
+- Kein SYN-ACK → Client wiederholt SYN (Timeout)
+- SYN-Flood-Attacke: Millionen SYNs ohne ACK → Server-Ressourcen erschöpft
+- Schutz: SYN-Cookies (Server speichert keinen State bis ACK kommt)
+
+**Verbindungsabbau:** 4-Way-Handshake (FIN → ACK → FIN → ACK) oder RST für sofortigen Abbruch.
+
+---
+
 # Nach dem Handshake
 
 **Status:** Die TCP-Verbindung steht.
@@ -1429,6 +1571,38 @@ SPEAKER NOTES:
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# TCP vs. UDP – Vertiefung
+
+Beide sind Transport-Protokolle (Schicht 3), aber mit fundamental unterschiedlichen Garantien.
+
+**TCP (Transmission Control Protocol):**
+- Verbindungsorientiert (Handshake vor Daten)
+- Sequenznummern → Reihenfolge garantiert
+- ACKs + Retransmission → Kein Datenverlust
+- Flow Control (Sliding Window) → Empfänger nicht überlasten
+- Congestion Control → Netzwerk nicht überlasten
+
+**UDP (User Datagram Protocol):**
+- Verbindungslos (Fire-and-Forget)
+- Keine Sequenznummern, keine ACKs
+- Header nur 8 Bytes (TCP: 20+ Bytes)
+- Anwendung muss selbst für Zuverlässigkeit sorgen
+
+| Anwendung | Protokoll | Grund |
+|-----------|-----------|-------|
+| HTTP/HTTPS | TCP | Vollständigkeit kritisch |
+| DNS | UDP | Kleine Pakete, schnelle Antwort |
+| Video-Streaming | UDP/QUIC | Latenz wichtiger als Perfektion |
+| Online-Gaming | UDP | Echtzeit, veraltete Daten nutzlos |
+
+**QUIC:** Googles Protokoll kombiniert UDP-Geschwindigkeit mit TCP-ähnlicher Zuverlässigkeit (HTTP/3).
+
+---
+
 # Warum UDP bei Video-Calls?
 
 **Szenario:** Ein Paket geht verloren.
@@ -1508,6 +1682,37 @@ Das wird wichtiger, wenn ihr mit REST-APIs arbeitet.
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# HTTP-Methoden – Vertiefung
+
+HTTP-Methoden definieren die **Semantik** der Anfrage – was der Client vom Server erwartet.
+
+**CRUD-Mapping (Create, Read, Update, Delete):**
+
+| Methode | CRUD | Idempotent | Safe | Typischer Einsatz |
+|---------|------|------------|------|-------------------|
+| GET | Read | Ja | Ja | Ressource abrufen |
+| POST | Create | Nein | Nein | Formular, neue Ressource |
+| PUT | Update | Ja | Nein | Ressource vollständig ersetzen |
+| PATCH | Update | Nein | Nein | Ressource teilweise ändern |
+| DELETE | Delete | Ja | Nein | Ressource löschen |
+
+**Idempotent:** Mehrfaches Ausführen hat denselben Effekt wie einmaliges (GET, PUT, DELETE).
+**Safe:** Ändert nichts am Server (nur GET, HEAD, OPTIONS).
+
+**REST-Prinzip:** URLs identifizieren Ressourcen, Methoden definieren Aktionen.
+```
+GET /users/42        → Benutzer 42 abrufen
+PUT /users/42        → Benutzer 42 vollständig ersetzen
+DELETE /users/42     → Benutzer 42 löschen
+POST /users          → Neuen Benutzer erstellen
+```
+
+---
+
 <!-- _class: klausur -->
 <!-- _header: '' -->
 <!-- _footer: '' -->
@@ -1543,6 +1748,31 @@ Status-Codes sagen euch, was passiert ist.
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# HTTP Status-Codes – Vertiefung
+
+Die erste Ziffer kategorisiert die Antwort:
+
+| Bereich | Kategorie | Häufige Codes |
+|---------|-----------|---------------|
+| 1xx | Informational | 100 Continue, 101 Switching Protocols |
+| 2xx | Success | 200 OK, 201 Created, 204 No Content |
+| 3xx | Redirection | 301 Moved Permanently, 302 Found, 304 Not Modified |
+| 4xx | Client Error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
+| 5xx | Server Error | 500 Internal Error, 502 Bad Gateway, 503 Unavailable |
+
+**Wichtige Unterscheidungen:**
+- **401 vs. 403:** 401 = nicht authentifiziert (wer bist du?), 403 = nicht autorisiert (du darfst nicht)
+- **301 vs. 302:** 301 = permanent umgezogen (Cache-fähig), 302 = temporär (nicht cachen)
+- **304 Not Modified:** Browser hat Cache, Server bestätigt: noch aktuell → spart Bandbreite
+
+**API-Design:** Korrekte Status-Codes sind wichtig für Clients. `200` bei Fehler mit `{"error": "..."}` im Body ist schlechtes Design.
+
+---
+
 <!-- _class: klausur -->
 <!-- _header: '' -->
 <!-- _footer: '' -->
@@ -1579,6 +1809,40 @@ Wie Encapsulation funktioniert.
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Netzwerk-Grundlagen – Vertiefung
+
+Die vier Kernkonzepte für Web-Entwickler:
+
+**1. DNS-Auflösung:**
+- Browser fragt DNS-Resolver (z.B. 8.8.8.8)
+- Rekursive Abfrage: Root → TLD → Authoritative
+- Caching auf jeder Ebene (TTL = Time To Live)
+
+**2. TCP-Verbindungsaufbau:**
+- 3-Way-Handshake vor jeder HTTP-Anfrage (HTTP/1.1)
+- Keep-Alive: Verbindung bleibt offen für mehrere Requests
+- HTTP/2: Multiplexing – viele Requests über eine Verbindung
+
+**3. HTTP Request/Response:**
+```
+Request:  Methode + URL + Header + (Body)
+Response: Status + Header + Body
+```
+
+**4. Schichten & Adressen:**
+| Was bleibt gleich? | Was ändert sich? |
+|-------------------|------------------|
+| Ziel-IP | MAC-Adressen (bei jedem Hop) |
+| Ports | – |
+
+**Debugging:** Browser DevTools (F12 → Network) zeigt alle Requests, Timing, Header.
+
+---
+
 # Werkzeuge zum Selbst-Erkunden
 
 **Im Browser (F12 → Network-Tab):**
@@ -1870,6 +2134,33 @@ Inline-Styles schlagen alles – außer !important, was ihr vermeiden solltet.
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# CSS Spezifität – Vertiefung
+
+Spezifität bestimmt, welche CSS-Regel gewinnt, wenn mehrere auf dasselbe Element zutreffen. Sie wird als 4-stellige Zahl berechnet: **(Inline, IDs, Klassen, Elemente)**.
+
+**Berechnung:**
+
+| Selektor | Inline | IDs | Klassen | Elemente | Gesamt |
+|----------|--------|-----|---------|----------|--------|
+| `p` | 0 | 0 | 0 | 1 | 0,0,0,1 |
+| `.info` | 0 | 0 | 1 | 0 | 0,0,1,0 |
+| `p.info` | 0 | 0 | 1 | 1 | 0,0,1,1 |
+| `#header` | 0 | 1 | 0 | 0 | 0,1,0,0 |
+| `#header .nav a` | 0 | 1 | 1 | 1 | 0,1,1,1 |
+
+**Wichtige Regeln:**
+- Eine Klasse (0,0,1,0) schlägt **jede Anzahl** von Elementen (0,0,0,99)
+- Eine ID schlägt jede Anzahl von Klassen
+- `!important` bricht alles → vermeiden, da schwer zu überschreiben
+
+**Best Practice:** Flache Spezifität anstreben. BEM-Methodik (`.block__element--modifier`) hält Spezifität gleichmäßig niedrig.
+
+---
+
 # Box-Modell
 
 ```
@@ -2117,6 +2408,37 @@ Das Gegenteil wäre Desktop First mit max-width – aber Mobile First ist heute
 
 ---
 
+<!-- _class: erklaerung -->
+<!-- _header: '' -->
+<!-- _footer: '' -->
+
+# Responsive Design – Vertiefung
+
+**Mobile First** ist der Standard: Basis-CSS für kleine Screens, dann Erweiterungen für größere.
+
+**Breakpoints (gängige Werte):**
+
+| Breakpoint | Gerät | Media Query |
+|------------|-------|-------------|
+| < 576px | Smartphone (Portrait) | Basis (kein Query) |
+| ≥ 576px | Smartphone (Landscape) | `@media (min-width: 576px)` |
+| ≥ 768px | Tablet | `@media (min-width: 768px)` |
+| ≥ 992px | Desktop | `@media (min-width: 992px)` |
+| ≥ 1200px | Large Desktop | `@media (min-width: 1200px)` |
+
+**Viewport-Meta-Tag (kritisch!):**
+```html
+<meta name="viewport" content="width=device-width, initial-scale=1">
+```
+Ohne diesen Tag ignorieren mobile Browser eure Media Queries und rendern die Desktop-Version verkleinert.
+
+**Moderne Alternativen zu Media Queries:**
+- `clamp()`: `font-size: clamp(1rem, 2vw, 2rem);`
+- Container Queries: Reagieren auf Container-Größe statt Viewport
+- CSS Grid `auto-fit`/`auto-fill`: Automatisches Responsive Layout
+
+---
+
 # Zusammenfassung CSS
 
 **Selektoren:**

slides/223015c/03-interaktivitaet-javascript.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Grundlagen IT- und Internettechnik (223015c)"
-footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: "Kapitel 3: Interaktivität & JavaScript"
 ---
 
@@ -83,7 +83,7 @@ section.aufgabe footer {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
-**Wintersemester 2025/26**
+**Sommersemester 2026**
 
 [https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
 

slides/223015c/klausurfolien.md

@@ -4,7 +4,7 @@ theme: gaia
 paginate: true
 backgroundColor: #fff
 header: "Grundlagen IT- und Internettechnik (223015c)"
-footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
+footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: "Kapitel 1: Geschichte, Grundlagen & HTML"
 ---
 <style>
@@ -93,7 +93,7 @@ section.aufgabe footer {
 Digital- und Medienwirtschaft
 Hochschule der Medien Stuttgart
 
-**Wintersemester 2025/26**
+**Sommersemester 2026**
 
 [https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)