Fluggeräusche: Prüfung der tatsächlichen Windows-Ausgabe

Die fünf begrenzten Audioprüfungen bestehen mit positivem PCM-Signal und geprüften Ruhephasen. Damit sind die bereits eingebauten Übergänge erstmals an der tatsächlichen Spielausgabe belegt. Klangfarbe, Gesamtmix und menschliches Spielgefühl sind damit noch nicht abgenommen. Die öffentliche Testfassung bleibt Playtest v20; diese Runde ergänzt einen gesonderten Diagnosebuild und verändert keine normalen Flug- oder Klangregeln.

Messaufbau und Herkunft

Diagnosequellstand e34862e, Build Artifacts/AudioCheck-v2, Buildprotokoll: Unity 6000.0.45f1, erfolgreich, 228.791.013 Bytes, null Fehler, zwölf ursprüngliche Warnungen. source-provenance.json enthält Quellstand und Runtime-Hash. SHA-256 von SpaceHero.Runtime.dll: AD7051D48AEAB603CBF5D037E47ECCB4AFB948B9399B605586CC6AAA637E4ADD. GameAudio.cs, FlightDirector.cs, die ursprünglichen Skripte/Szenen und die Unity-Version sind gegenüber dem ausgelieferten v20-Spielquellstand unverändert.

--spacehero-audio-check verlangt ausdrücklich eine frische eigene Datenwurzel und lehnt konkurrierende QA-Modi ab. Jeder Fall erzeugt einen neuen Piloten ohne Upgrades. Die normalen Intro-/Karten-/Startaktionen öffnen Mission 1-1. Master und Effekte stehen nur in diesen Testprofilen auf 1, Musik und Sprache auf 0. Der ursprüngliche AudioListener und GameAudio.Update bleiben aktiv. Flugaktionen werden einmal pro tatsächlichem Frame über den normalen Flight.Tick mit derselben Begrenzung von Time.deltaTime ausgeführt; keine beschleunigte Simulation und keine direkten SFX-/AudioSource-Aufrufe als Aktionsersatz. Die Eingaben sind automatisiert; physische Gerätebedienung wird nicht behauptet.

Der Host startet und beendet ausschließlich seine eigenen Prozesse. Der Windows-Recorder nimmt über INCLUDE_TARGET_PROCESS_TREE nur den gestarteten Spielprozess samt Kindern auf. Eine gemeinsame native Windows-QPC-Uhr ordnet tatsächliche Spielereignisse den einzelnen WASAPI-Paketen zu. Die Konsolenmeldung des Recorders wird nicht als Audiobeginn interpretiert. Herkunft, Lizenz, Quelländerungen, Buildvoraussetzungen und kalibrierter Binärhash stehen in Tools/ProcessLoopback.md.

Bestandener nativer Lauf

Laufverzeichnis 114617-b43e3621, Spiel-PID 54808, alle fünf Recorder regulär beendet, anschließend reguläres Spielende mit Exit 0. manifest.json hält Prozesse, Build-/Runtime-/Recorder-/WAV-/Paket-/Ereignishashes fest. analysis.json enthält die tatsächlichen Messfenster und Einzelprüfungen; timeline.svg zeigt die Signalverläufe.

Jede Aufnahme enthält 9,99 Sekunden, 440.559 Stereo-Sampleframes bei 44,1 kHz/16 Bit in 999 Paketen. In diesen fünf Spuren: keine QPC-Sprünge, keine Discontinuity-/Timestamp-Error-Flags, 100 % Abdeckung der geprüften Fenster, keine Vollpegelsättigung. Alle Fälle verlangen sowohl passende positive Aktionssignale als auch niedrigen Ruhepegel; eine vollständig stumme oder bloß dithernde Aufnahme besteht nicht.

Fall	Tatsächlich geprüfter Ablauf und Ergebnis
`01-fire`	Drei Schüsse während gehaltenem Feuer und ein einzelner Frame mit Feuer erzeugen genau vier reale Projektile und vier unabhängig gezählte PCM-Impulse. Quellhüllkurven passen zum Impulsklang; zwischen und nach den Schüssen bleibt es ruhig.
`02-boost-pause`	Drei tatsächliche Schubstarts sind zu hören. Zwei reguläre Freigaben enthalten einen abnehmenden Ausblendrest und enden anschließend auf Ruhepegel. Pause unterbricht den aktiven Schub; Fortsetzen ohne neue Schubeingabe bleibt ruhig.
`03-pickup-hangar`	Der Pilot fliegt zur tatsächlich vorhandenen Energiezelle und sammelt sie ein; Fortschritt 1/6. Nach kurzer Pause und normalem Missionsabbruch wird der unterbrochene Sammelklang im Hangar nicht wieder abgespielt.
`04-pickup-resume`	Derselbe echte Sammelvorgang wird pausiert. Normales Fortsetzen spielt den noch offenen Teil des Sammelklangs weiter und beendet ihn einmalig. Quellhüllkurve und anschließende Ruhephase sind geprüft.
`05-pickup-rescue`	Nach echter Sammlung wird der normale Rettungsdialog geöffnet. Sein 1,6-s-UI-Klang und der anschließende Wiederholen-Klick sind erwartete positive Signale. Danach kehrt der alte Sammelklang nicht zurück. Der Rettungsübergang wird hier direkt ausgelöst; dies ist kein zusätzlicher Nachweis der Schildverlustkette.

Die beiden Schubausblendungen fallen zwischen festen aufeinanderfolgenden 60-ms-Fenstern von RMS 0,02742 auf 0,01485 und 0,02744 auf 0,01795. Nach Ende liegt der Ruhepegel bei ungefähr 0,0000146 RMS. Das belegt den Verlauf dieser Ausblendungen, keine Bewertung der Klangfarbe.

Die Auswertung verwendet 10-ms-Energiefenster und eine feste Randreserve von 60 ms. Ein einziger, an der ersten positiven Aktion bestimmter Ausgabeversatz gilt jeweils für die gesamte Spur: Feuer 140 ms, Schub 155 ms, Sammeln/Hangar 130 ms, Sammeln/Fortsetzen 145 ms, Sammeln/Rettung 140 ms. Spätere Ereignisse werden nicht einzeln passend verschoben. Das sind gemessene Versätze in diesem Aufnahmeweg, keine Abnahme der empfundenen Reaktionszeit oder alleinige Zuordnung zu Unity. Quellhüllkurven tolerieren Unity-Kompression/Resampling; keine sampleidentische Wiedergabe wird behauptet.

Technische Prüfungen und erhaltene Fehlversuche

Vier gezielte PCM-Negativkopien scheitern jeweils mit Exit 1: vollständig stumm, nur tatsächliches Baseline-Dither, ein zusätzlicher kopierter Schuss ohne Feuerereignis und ein im Hangar wieder eingefügter alter Sammelrest. Die Mutationsmanifeste enthalten aktualisierte WAV-Hashes; der Fehler wird somit am Signalinhalt erkannt. Original-WAVs, Pakete, Ereignisse und Manifest sind nach SHA-256 unverändert. Negativnachweise.
Vollständige Unity-Suite 113441: 81 bestanden, null fehlgeschlagen, drei ausdrücklich ausgelassene GPU-Präsentationstests. Nach der begrenzten Änderung an der gemeinsamen Messuhr und Dateifreigabe: zwei gezielte Argument-/Pfadprüfungen 114419 bestanden, erfolgreicher neuer Build und der oben genannte tatsächliche native Lauf. Keine erneute vollständige Suite nach dieser Instrumentierungsänderung.
Die ersten zwei Compilerläufe 113318/113340 scheiterten am falschen Integer-Typ des normierten Missionsfortschritts im neuen Prüflauf. Typ und Prüfung auf genau 1/6 wurden korrigiert. Keine Spielregeländerung.
114027-1296c9cb: erste Schussaufnahme vorhanden, danach Hostabbruch wegen des durch PowerShell leer gebundenen Backup-Pfads bei File.Replace. Korrigiert durch einen eindeutigen tatsächlichen Backup-Pfad. Lauf bleibt fehlgeschlagen.
114203-d8997500: fünf Aufnahmen vorhanden, Abschluss scheiterte an einer Dateifreigabekollision beim Anfrageaustausch. Außerdem hatten Unity/Mono-Stopwatch und WASAPI unterschiedliche Zeitursprünge. Korrigiert durch native QPC, teilbare Dateihandles und begrenzte Wiederholung von Sharing-Verletzungen. Protokoll 2 lehnt diese alten Zeitdatensätze ausdrücklich ab; keine zeitlichen Bestehensaussagen aus ihnen.
Die vorangehende Recorderkontrolle 112350-packet-calibration liefert den bekannten 440-Hz-Ton positiv. 440.118 Frames entsprechen 998 Paketen; ein einzelner 11,206-ms-QPC-Sprung beim Tonstart ist dokumentiert. Im bestandenen Spielaufnahme-Lauf trat dieser Sprung nicht auf. Die Kontrolle ersetzt keine Spielspur.

Grenzen und offene Abnahmen

Dieser Nachweis gilt für die fünf beschriebenen Tonsequenzen in Mission 1-1 mit getrenntem Effektmix. Scanner, Treffer-/Boss-/Ergebnisgeräusche und Musik-/Sprachmischung sind nicht Bestandteil dieser PCM-Runde. Es gab keine neue Boss-, Leistungs- oder physische Geräteprüfung. Die letzten Bild-/Animationsbelege bleiben im Wal- und Bossbericht.

Die drei ursprünglichen weiblichen Bordcomputeransagen bleiben aktiv. 13 neue Storyaufnahmen, die noch ausstehende Stimmenentscheidung und menschliche Hör-/Spiel-/Kinderabnahmen bleiben offen. Keine Gesamtabnahme und keine Behauptung einer bereits fertigen Vertonung.