wie gesagt in der Praxis haengt's halt dann von der Routine ab. Eine "billige" Art zwei Samples zusammenzumischen ist vorher jeweils Lautstaerke oder Sample-Rate oder -Frequenz halbieren, damit's garantiert nicht uebersteuert.

Vielleicht liegt es aber auch einfach in der Natur der Sache. Richtig Mixen/Mastern im Studio ist ja ein Handwerk, das man lernen muss. Wenn man die Spuren nicht nachbearbeitet mit EQ und was weiss ich, dann klingt's hand nicht so gut. Selbst bei einer High-Fidelity-Orchesteraufnahme hoerst du auch nicht mehr jedes Instrument raus wie einzeln, zumindest nicht mehr so gut. Und womoeglich wird das, wenn das Medium von Haus aus keine CD-Qualitaet kann, noch verstaerkt.

Die "edle" Art zu mischen jedenfalls ist intern mit mehr Bits zu arbeiten und dann die Waveform wieder runter-dithern quasi. Dachte das ist hinreichend, aber in dem Artikel redet er davon dass das bei professioneller Hardware auch mit der Amplitude gemacht wird. Aber auch das sollte mit Software eigentlich gehen, auch auf dem Amiga.

@ Grumbler:

Warum war dann die Audioqualität der einzelnen Samples beim Amiga hörbar schlechter, wenn mehrere Stimmen auf einen Kanal gemixt wurden? So bisschen schlaffer, rauer, rauschiger.

Beim MOD4WIN, einem MOD-Dateien-Player für Windows 3.1, kann man in der Hilfe die Problematiken nachlesen. Da gibt es verschiedene Optionen, um einerseits das auf dem IBM-PC nötige Software-Mixing zu ermöglichen, andererseits nicht zu viel Leistung der CPU zu fressen.

Auf heutigen PCs natürlich längst kein Problem mehr, damals für 386er und langsame 486er wohl.
Kommentar wurde am 24.09.2024, 11:01 von DaBBa editiert.

> Denn vielleicht koennte das der Nachteil sein der Software-Methode statt Hardware: Dass immer auch Audioqualitaet verlorengeht?

Nein, im Prinzip nicht, theoretisch zumindest, digital ist digital, Hardware oder Software, die machen das gleiche. Hardware dient nur dazu dass es keine oder kaum CPU-Zeit wegnimmt. Egal ob Amiga oder High-End-Studio, egal ob Hardware-Loesung oder Software, das Prinzip ist dasselbe.

In der Praxis kommt's auf den verwendeten Algorithmus an, und da koennen einige auch mehr Rechenzeit verbraten als andere, die dann vielleicht Abstriche bei der Qualitaet machen.

Hab hier glaub ich schon mal geschrieben und verlinkt. https://www.powerprograms.nl/amiga/audio-mixing.html

Mischen ist tatsaechlich nur die Sample-Werte aufaddieren. Das ist alles. Aber wenn per Software dann musst du das halt per Frame fuer ein paar Dutzend Werte machen. Und wie gehst du mit dem Overflow um, dass es nicht digital uebersteuert? Das ist dann das, wo die Qualitaetsfrage ins Spiel kommt (wenn man nicht einfach nur Sample-Rate verringert).
Kommentar wurde am 22.09.2024, 03:42 von Grumbler editiert.

Nein, nicht wirklich. Weiß auch kaum noch was davon. Ist sicher fast 30 Jahre, das ich sowas versucht hatte.

Wobei das Hardpanning eigentlich nur über Kopfhörer "komisch" klingt, zumal es in der Mitte keinen Kanal gibt. Aber sonst fällt das nicht negativ auf über den Monitor oder anderen Lautsprechern, eher noch klingt es besonders breit und auch eindrucksvoll, wenn mit Stereo-Effekten gearbeitet wurde.

Es gab mal für den Amiga ein Musikprogramm, das "OctaMed" hieß. Das konnte wie der "Oktalyzer" 8 Stimmen Samples abspielen. So ungefähr 1995/1996 wurde daraus das "Sound Studio", das per Software bis zu 64 Stimmen mixte. Ich hatte das zwar nicht mehr wirklich ausprobiert, weil ich da schon mit MIDI herummachte, war aber schon krass.

Schon mit der 7-Voice-Routine von Hippel/Hülsbeck hätte man 16 Stimmen generieren können, 4 Stimmen pro Kanal auf allen Kanälen, statt nur auf einem.

Ich weiß gerade nicht, ob die Sample-Qualität mit jeder "Halbierung" weiter reduziert wird? Also 2 Stimmen statt einer Stimme auf einem Kanal hatte auf jeden Fall hörbare Einbußen. Jetzt frage ich mich, ob diese Einbußen zunehmen, je mehr Stimmen gemixt werden?

Denn vielleicht könnte das der Nachteil sein der Software-Methode statt Hardware: Dass immer auch Audioqualität verlorengeht?

War das denn leicht, diese Werte einzustellen? Also ich weiß noch, davon hatte ich keine Ahnung. Konntest du das?

Ohne zu wissen wie man die Sync Werte für das interne und externe Laufwerk korrekt in X-Copy/Siegfried Copy eintstellt ging das sehr oft auch nicht. Disks mit Longtracks z.B. konnte man nur so mitkopieren.
Kommentar wurde am 20.09.2024, 19:06 von Retro-Nerd editiert.

Alles ging auch mit Cyclone nicht. Beim berühmt-berüchtigen Rob Northern Copylock scheiterte auch es.

So ein Hardware-Teil mit X-Copy hatte ich auch, wirklich kopiert bekam ich aber eigentlich kaum was damit. Ich hatte ja reichlich Originale.

Joa, X-Copy konnte dann später noch den Nibblecopy-Modus, der einige, wenn auch längst nicht alle Kopierschutz-Mechanismen mitkopieren konnte. Wer Cachet Software Suite inkl. X-Copy original gekauft hat (ja, komische Vorstellung) bekam auch noch einen Hardware-Aufsatz, der in Verbindung mit Cyclone* noch deutlich meher Kopierschutz-Systeme mitkopieren konnte.
* Übrigens entwickelt vom nicht ganz unbekannten Richard Aplin.

Die auch vollkommen gerechtfertigt war. Pfeifen wie ich konnten ja nur mit X-Copy probieren, ob man das gekaufte Original dem Kumpel kopieren kann. Ging das nicht, bekam der Kumpel halt keine Kopie. Das machte dann insgesamt gesehen bestimmt einige Verkaufseinheiten eines Spiels aus.

bin mir nicht sicher ob er das meint.

am Amiga duerfte es recht einfach sein, auch "offiziell" Frame-orientiert zu programmieren. Du kriegst 'nen Interrupt fuer einen neuen Frame und richtest alles danach aus. So werden auch Arcade- und Konsolenspiele i.d.R. entwickelt. Das entwickelte Spiel laeuft dann egal ob auf 8 MHz oder 14 MHz genauso schnell, du kannst bei 14 MHz innerhalb eines Frames mehr machen. Aber es gibt halt 'zig andere "inoffizielle" Dinge, die man machen kann, wo man sich nicht an die Vorgaben, Empfehlungen oder Guidelines haelt, in Speicherbereiche schreibt wo man nicht sollte, um irgendwelche Tricks zu erreichen, etc...

Weiss noch dass beim Amstrad CPC die Vorgabe war, nur bestimmte Firmware-Routinen zu nutzen, weil sich die Hardware bei zukuenftigen Revisionen und neuen Modellen ja aendern koennte. Diese Routinen waren aber absolut kacke. War damals quasi schon ein Abstraktions-Layer, heute ja gang und gaebe, aber damals kam's eben auf jeden Cycle an. Drum waren die fruehen Spiele oft besonders flackernd oder die Software-Sprites bewegten sich nicht sauber (in manchen Frames verdoppelte Pixel am Rand etc). "Zum Glueck" war ja die CPC-Modellreihe recht ueberschaubar, so dass sich die Entwickler spaeter nicht mehr daran gehalten haben.

Selbst wenn beim Amiga die Vorgaben recht streng waren, durch die ganze spezialisierte Hardware, die man "offiziell" ansprechen darf, duerften die Performance-Einbussen nicht so schlimm gewesen sein. Deswegen war wie hier im Thread erwaehnt ein Turrican wohl sowohl "konform" als auch performant.

Bei PCs hingegen war wegen der vielfaeltigen Architekturen und Hardware-Konfigurationen das Problem, dass es meines Wissens ueberhaupt keinen standardisierten Weg gab, zu ermitteln, wann ein neuer Frame kommt. Der "Nachteil" einiger Spiele, die keine PC-Bremse benoetigen oder wo man heute keine Spezialeinstellung im Emulator braucht, duerfte gewesen sein, dass sie dann oft wahrscheinlich nicht auf jedem PC liefen.
Kommentar wurde am 20.09.2024, 12:23 von Grumbler editiert.

Ja, bzgl. CPU-Geschwindigkeiten gibt es auch alte MS-DOS-Spiele, die auf CPUs, die fünf oder zehn Jahre nach Release erschienen, viel zu schnell laufen. Dafür gab es dann Tools wie PC-Bremse, die oft leidlich erfolgreich versucht haben, eine langsame CPU zu simulieren, indem sie im Hintergrund sinnlose Rechenoperationen durchführten und so die verbleibende CPU-Kapazität reduzieren wollten.

Heute, mit Emulation, ist das natürlich kein Problem mehr.

Generell unterscheidet sich die Art zu programmieren stark, ob man von einer bestimmten Speichergröße, CPU Taktfrequenz, Anzahl der Taktzyklen pro CPU Befehl, Bildwiederholfrequenz (PAL/NTSC), etc., wo das Timing von der Hardware vorgegeben wird, ausgeht, oder ob man so programmiert, dass ein Programm sich selbst um das Timing und die Synchronisation mit der vorhandenen Hardware kümmern muss. Letzteres macht Programme komplexer und somit prinzipiell auch noch langsamer. Dafür sind die dann kompatibler.