From a5f890ae247759bfafc0df1fb15abec2e77a01aa Mon Sep 17 00:00:00 2001
From: Michael Czechowski <mail@dailysh.it>
Date: Fri, 15 May 2026 09:44:50 +0200
Subject: [PATCH] hdm fixes

---
 slides/223015b/01-grundlagen-text-audio.md    | 77 +------------------
 slides/223015b/02-bild-audio-video.md         | 41 ----------
 .../03-speichermedien-schnittstellen.md       | 10 +--
 3 files changed, 6 insertions(+), 122 deletions(-)

diff --git a/slides/223015b/01-grundlagen-text-audio.md b/slides/223015b/01-grundlagen-text-audio.md
index 77d4ea2..426972c 100644
--- a/slides/223015b/01-grundlagen-text-audio.md
+++ b/slides/223015b/01-grundlagen-text-audio.md
@@ -8,7 +8,8 @@ footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
 title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
 ---
 
-<style>
+<style>Byte zählen
+
 :root {
   --color-foreground: #1a1a2e;
   --color-highlight: #1e5f8a;
@@ -1191,33 +1192,6 @@ Sog. RGB Tuple (geordnete endliche Liste)
 
 ---
 
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-![bg fit](./assets/demos/byte-nibble-hex.png)
-
-<!--
-Kernidee: jedes Byte lässt sich sauber in zwei 4-Bit-Hälften (Nibbles) zerlegen. Jede Hälfte hat 2⁴ = 16 Zustände – und genau 16 Symbole hat Hex (0-F). Deshalb passt Hex perfekt: 1 Nibble = 1 Hex-Ziffer, 1 Byte = 2 Hex-Ziffern. Keine krumme Umrechnung.
--->
-
----
-
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-![bg fit](./assets/demos/why-8-bit.png)
-
-<!--
-Warum gerade 8 Bit?
-- CPU adressiert byteweise — kleinste adressierbare Einheit
-- Halbe Byte (z.B. 0x0000.5) existieren nicht
-- Speichercontroller, Bus, CPU-Register alle auf 8-Bit-Häppchen ausgelegt
-- Einzelne Bit lesen: erst Byte holen, dann mit Bitmaske isolieren (byte & 0b1000_0000)
-- Hardware-Geschichte: IBM System/360 (1964) setzte 8-Bit-Standard, 7-Bit-ASCII + 1 Paritätsbit
--->
-
----
-
 <!-- _class: lead -->
 
 # Hexadezimal
@@ -1246,50 +1220,7 @@ Warum gerade 8 Bit?
 - "Nibble" = 4 Bits = halbes Byte (Wortspiel: nibble = knabbern, byte = beißen)
 - ASCII geht nur bis 127 — Werte 128–255 sind nicht im ASCII-Raum
 -->
-
----
-
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-![bg fit](./assets/demos/hex-dec-table.png)
-
-<!--
-Hex ↔ Dezimal Lookup-Tabelle: 0–F = 0–15
-A=10, B=11, C=12, D=13, E=14, F=15
--->
-
----
-
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-![bg fit](./assets/demos/byte-flow.png)
-
-<!--
-1 Byte = 8 Bit = 2 Hex-Ziffern = 1 ASCII-Zeichen
-- Dieselbe Datei, drei Schreibweisen
-- Jeder Rahmen = ein Byte
-- Byte ändern sich nicht, nur unsere Anzeige
-- ↵ (0x0A) = nicht druckbar → Hex-Editoren zeigen . als Platzhalter
--->
-
----
-
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-![bg fit](./assets/demos/three-views.png)
-
-<!--
-Dieselben 8 Byte (PNG-Dateianfang: 89 50 4E 47 0D 0A 1A 0A) — drei Perspektiven:
-1. Bitstream — was wirklich gespeichert wird (unleserlich)
-2. Hex — gruppiert in 8-Bit-Häppchen (kompakt)
-3. Bedeutung — was die Byte signalisieren:
-   - 89: Magic Byte (>127 → "ich bin Binärdatei")
-   - 50 4E 47: P N G (ASCII-Format-Kürzel)
-   - 0D 0A 1A 0A: CR LF EOF LF (erkennt kaputte Übertragung)
--->
+2
 
 ---
 
@@ -2143,4 +2074,4 @@ Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
 - hex5: ZIP (50 4B 03 04)
 - Gruppenarbeit: 3-4 Personen
 - Ziel: Hex-Dump lesen lernen, Dateiformate verstehen
--->
\ No newline at end of file
+-->
diff --git a/slides/223015b/02-bild-audio-video.md b/slides/223015b/02-bild-audio-video.md
index 97d7d09..d47f01d 100644
--- a/slides/223015b/02-bild-audio-video.md
+++ b/slides/223015b/02-bild-audio-video.md
@@ -713,11 +713,6 @@ KLAUSURRELEVANT:
 
 ---
 
-<!-- _class: klausur -->
-<!-- _header: '' -->
-<!-- _footer: '' -->
-<!-- _backgroundColor: #e3f2fd -->
-
 # JPEG Schritt 6: Huffman-Coding
 
 **Verlustfreie Kompression der Restwerte**
@@ -770,40 +765,6 @@ JPEG verwendet zwei Huffman-Tabellen: eine für DC-Koeffizienten (Durchschnittsw
 
 ---
 
-<!-- _class: klausur -->
-<!-- _header: '' -->
-<!-- _footer: '' -->
-<!-- _backgroundColor: #e3f2fd -->
-<!--
-# 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: '' -->
 
@@ -824,8 +785,6 @@ A=5, B=2, R=2, C=1, D=1
 # Andere Bildformate
 ## PNG, GIF, WebP, AVIF
 
-15:33 Uhr weiter
-
 <!--
 - JPEG ist nicht für alles geeignet
 - Jetzt: Alternativen und ihre Stärken
diff --git a/slides/223015b/03-speichermedien-schnittstellen.md b/slides/223015b/03-speichermedien-schnittstellen.md
index 6cd4c6d..1173101 100644
--- a/slides/223015b/03-speichermedien-schnittstellen.md
+++ b/slides/223015b/03-speichermedien-schnittstellen.md
@@ -119,7 +119,7 @@ Hochschule der Medien Stuttgart
 
 <!-- _class: lead -->
 
-# Kapitel 3 – 23.01.2026
+# Kapitel 3
 ## Speichermedien & Schnittstellen
 
 ---
@@ -369,8 +369,7 @@ Seitdem native Linux-Unterstützung.
 **Features:**
 - Journaling (Crash-Sicherheit)
 - Dateirechte (ACLs)
-- Kompression, Verschlüsselung
-- Große Dateien und Volumes
+- Kompression, Verschlüsselung, große Dateien und Volumes
 
 **Nachteile:**
 - Nur Windows schreibt nativ
@@ -629,11 +628,6 @@ Millionen von Websites und Spielen verloren.
 - 30 Jahre Haltbarkeit
 - Für Cold Storage ideal
 
-**M-DISC:**
-- Spezielle DVD/Blu-ray
-- 1.000+ Jahre Haltbarkeit (Herstellerangabe)
-- Für kleine, wichtige Daten
-
 **Cloud:**
 - Glacier, Backblaze B2
 - Günstig für Langzeit