Kommen wir zurück zur Schnittstelle. Ein Feature von Spark ist die Nutzung von Kontextmenüs im Programm (ja, das geht trotz der militanten One-Button-Funktion auch auf dem Macintosh), insbesondere um ein Modul zu einer Matrixzelle hinzuzufügen. Jede Zelle zeigt den Namen der darin eingefügten Verarbeitung und den Pegel des Eingangssignals an. Leider kann immer nur ein Fenster mit Verarbeitungsparametern angezeigt werden, um die Moduloberfläche anzuzeigen, müssen Sie auf die Zelle damit doppelklicken oder direkt "springen", indem Sie das gewünschte Modul aus dem Plug-In-Menü in das auswählen Fenster zum Bearbeiten von Verarbeitungsparametern.

Nun zum Traurigen. Erstens ist die Undo-Funktion einstufig (und das ist im 21. Jahrhundert!). Zweitens sind alle Bearbeitungsvorgänge sehr langsam: Zuerst speichert Spark eine Sicherungskopie der Audiodatei, dann führt es die erforderliche Operation durch (und das ist auch langwierig, weil das Programm nicht mit dem bearbeiteten Stück arbeitet, sondern die gesamte Datei neu berechnet). , dann berechnet es die Wellenform (auch die gesamte Datei). Im Allgemeinen extrem langsam und unpraktisch, insbesondere bei großen (20-30 Minuten) Dateien. Anscheinend wird diese langsame Arbeit dadurch verursacht, dass Spark bei Standardbearbeitungsvorgängen (Löschen, Einfügen usw.) nicht mit einem Teil der Datei arbeiten kann, sondern nur mit der gesamten Datei, während jedes Mal eine Sicherungskopie erstellt wird. Die Backup-Erstellung kann im Prinzip deaktiviert werden, aber dann geht das Rückgängigmachen komplett verloren. Andere Programme scheinen mir an dieser Stelle durchdachter. Es gibt noch einen weiteren kleinen Nachteil in Bezug auf die Art und Weise, wie die berechnete Wellenform gespeichert wird. Die meisten Macintosh-Programme speichern die berechnete Wellenform nicht in einer separaten Datei (wie es viele Windows-Programme tun), sondern in einem speziellen Bereich der Audiodatei, der als "Ressourcengabel" bezeichnet wird. Das heißt, der Nutzer sieht nur eine Datei, ohne gleichnamigen Müll, der sich ansammelt, wenn man eine Datei in mehreren Windows-Editoren bearbeitet. Das ist sehr praktisch, zumal sich viele Programme „verstehen“ und nicht jedes Mal die Wellenform neu berechnen müssen. Spark glänzt nicht in diesem Sinne: Es versteht nicht nur andere nicht, es speichert auch eine grafische Darstellung der Wellenform in einer separaten Datei neben dem Original. Eine Kleinigkeit natürlich, aber dennoch unangenehm.

Aber genug von den traurigen Sachen, gehen wir weiter zur Arbeit mit Spark-Samplern. Hier ist alles sehr gut, das Programm kann sowohl über MIDI als auch SCSI mit Samplern kommunizieren, und obwohl die Liste der direkt unterstützten Modelle nicht so umfangreich ist wie die von Peak, können Sie Samples aus Akai-Bibliotheken direkt von einer Computer-CD-ROM importieren das Programm (und dann auch schon - und in den Sampler).

Besonders hervorheben möchte ich die Mittel zur Wiederherstellung von Tonträgern, die an Spark XL angeschlossen sind. Dies sind zwei Plugins: TC Declick und TC Denoise (leider sind sie nicht VST und können daher nur in Spark funktionieren). Denoise (Abb. 9) arbeitet mit dem Noise-Sample und subtrahiert es von der Tonspur, für Declick wird das Sample nicht benötigt, die Intensität und Frequenz der Klicks werden durch die Regler eingestellt. Die Qualität der Rauschunterdrückung ist bei beiden Modulen sehr gut. Unter der ressourcenabhängigen Verarbeitung dieser Art führen Module von Spark am wenigsten Verzerrungen in den Soundtrack ein. Ich habe keine Declicker gesehen, die in der Qualität mit Declick vergleichbar sind, und vielleicht kann nur DINR von Digidesign mit Denoise mithalten. Letzteres hat viele Einstellungen, und manchmal können Sie durch "Herumspielen" mit den DINR-Parametern bessere Ergebnisse erzielen als mit Denoise. Fairerweise sei angemerkt, dass Denoise recht einfach zu handhaben ist und selbst mit Standardeinstellungen gute Ergebnisse liefert (wenn das Ergebnis jedoch nicht zufriedenstellend ist, ist es fast unmöglich, die Situation radikal zu korrigieren, es bleibt die Modul verschiedene Rauschproben).

Wenn wir allgemein über Spark sprechen, dann möchte ich das gute Konzept des Programms und die intuitive Oberfläche hervorheben. Aber die Implementierung vieler Funktionen dieses Editors ist leider bisher nicht sehr gut, also hoffen wir auf Verbesserungen in zukünftigen Versionen.

Testen
Die Fülle an Funktionen moderner Sound-Editoren ist beeindruckend, aber wie ehrlich erfüllen Programme diese Funktionen? Es ist kein Geheimnis, dass viele Unternehmen den Benutzer nicht über die interne Architektur und „Fallstricke“ ihrer Softwareprodukte informieren. So kommt es beispielsweise vor, dass die Bittiefe der im Programm verbauten Prozessoren gering sein kann (16 Bit), gleichzeitig verarbeitet das Programm aber ohne Gewissensbisse und ohne Vorwarnung 24-Bit-Dateien. Das Ergebnis ist ein verzerrter Klang. Um einige nicht an der Oberfläche liegende Eigenschaften der Programme zu verdeutlichen, wurden einige Tests durchgeführt.

Der erste Test gilt also der Korrektheit von Aufnahme und Wiedergabe. Ich habe dafür eine RME DIGI 96/8 Pro PCI-Karte verwendet, die in einem Power Macintosh 9600/350-Computer installiert ist. Das Board verfügt über digitale Schnittstellen in den Formaten ADAT, SPDIF und AES/EBU. Dieses Board verfügt über Sound Manager-Treiber, aber zum Testen wurden ASIO-Treiber verwendet, da nur 16-Bit-Audio (oder niedriger) über den Sound Manager wiedergegeben und aufgenommen werden kann. Das Steuerungssystem war Digidesign Pro Tools 442 mit Pro Master 20-Schnittstelle und Sound Designer II Version 2.82, installiert auf Macintosh Centris 650. Trotz seines (für Computerstandards) schon recht respektablen Alters funktioniert dieses System immer noch perfekt und wurde viele Male auf Korrektheit getestet und in verschiedenen Teilen der Welt, also wurde es ohne Zögern als Referenz gewählt. Also, die Technik: Das erzeugte Signal wurde mit einer gleitenden Frequenz (von 5 bis 22000 Hz) mit einer Dauer von 30 Sekunden aufgenommen (Abtastfrequenz 44,1 kHz, Bittiefe 16 und 24 Bit), vom Programm Sound Designer (über AES / EBU auf Pro Master) und in den Studiengängen erfasst (auch über AES/EBU im RME-Board); dann wurde es im Gegenteil von Programmen reproduziert und in Sound Designer aufgenommen. Dabei wurden Apogee-Wyde-Eye-Drähte von einem halben Meter Länge mit vergoldeten Neutrik-Anschlüssen verwendet. Die resultierenden Dateien im Sound Designer wurden am Anfang und am Ende des Signals abgeschnitten (natürlich samplegenau) und mit der ursprünglich erzeugten Datei verglichen. Für einen solchen Vergleich verfügt Sound Designer über einen Dateivergleichsbefehl, bei dem die Werte jedes Samples in einer Datei von den entsprechenden Samples der anderen subtrahiert werden, was zu einer Sounddatei der "Differenz" zwischen den beiden Dateien führt. Wenn die beiden Dateien Bit für Bit übereinstimmen (wie es bei einer digitalen Aufzeichnung sein sollte), besteht die resultierende Datei nur aus Nullen. Zur absoluten Sicherheit wurde der Find Peak-Befehl verwendet, und wenn die Werte aller Samples in der Datei "differences" Null sind, gibt Sound Designer eine entsprechende Meldung aus. Wenn andere Werte als Null vorhanden sind (bzw. die getesteten Dateien nicht Bit für Bit übereinstimmen), wird der Cursor auf das lauteste dieser Samples gesetzt. Zur Sicherheit wurde für jede Position mindestens fünfmal getestet, wenn die Sendung korrekt aufgenommen und wiedergegeben wurde, dann wurde ein zusätzlicher Test mit einem fünfminütigen Signal durchgeführt.

Die Ergebnisse dieses Tests waren eher enttäuschend. Von allen korrekt aufgenommenen Programmen (d. h. die aufgenommene Datei hat den Nulltest bestanden) konnte nur Peak aufnehmen und wiedergeben, und selbst dann nur mit 16-Bit-Ton. Alle anderen Nulltests haben weder auf 16 Bit noch auf 24 Bit bestanden.Was genau mit dem Ton beim Aufnehmen und Abspielen von Sendungen passiert, lässt sich leider nicht sagen, aber es ist offensichtlich, dass es sich nicht um 16- oder 20 handelt -Bit-Trunk (also einfaches Verwerfen "unnötiger" Bits) - erstens würden die Verzerrungen viel stärker auffallen, und zweitens zeigte das Bitscope des SpectraFoo-Programms, mit dem die Ergebnisse analysiert wurden (Bild 10), das Aktivität aller 24 Bit des Signals. Auch dies ist kein Dither, da die Frequenz des Differenzsignals mit zunehmender Frequenz des Testsignals zunimmt. Es ist schwierig, eindeutig über den Fehler der untersuchten Programme zu sprechen, da das System aus vielen Elementen bestand (Board, ASIO-Treiber, Programm), obwohl Peak zeigte, dass es durchaus möglich ist, mit mindestens 16-Bit-Sound korrekt zu arbeiten Dieses Board und Treiber bieten. Verschiedene RME-Board-Treibereinstellungen wurden verwendet, um einen korrekten Betrieb zu erreichen, der Sample-Rate-Master hat sich geändert (standardmäßig ist der Master das Wiedergabegerät), aber die Ergebnisse sind immer gleich.

SpectraFoo-Bitscope-Messwerte für 16-Bit- (a) und 24-Bit- (b) Signale.

Lassen Sie uns abschließend über eine Reihe von Programmfunktionen sprechen, die in diesem Test identifiziert wurden. Peak konnte den Sound nicht direkt vom Anfang der Datei an abspielen, die ersten paar Samples wurden "gekaut", also wurde zum Testen dieses Programms eine Datei mit einer zweisekündigen Stille am Anfang verwendet, damit Peak "beschleunigen" konnte. Nach der Aufzeichnung eines vom Spark-Programm reproduzierten 24-Bit-Signals stellte sich heraus, dass das aufgezeichnete Fragment des Testsignals nach dem Abschneiden der Stille vier Samples länger war als das Original. Was dies verursacht hat, ist nicht bekannt, aber anscheinend ist die Auswirkung dieser Tatsache auf den Klang unbedeutend.

Eine weitere Studie wurde unter Verwendung des Nulltests durchgeführt. Es wurde eine Datei mit demselben Testsignal aufgenommen, jedoch mit einer zweisekündigen Stille davor (die gleiche, die für den vorherigen Test des Peak-Programms verwendet wurde). Dann wurde in jeder Sendung diese Stille überblendet. Dann wurde jede unnötige Stille abgeschnitten und die resultierende Datei mit dem Original verglichen. Dies wurde gemacht, um herauszufinden, ob die Verarbeitung des Dateianfangs durch das Programm die restlichen Toninformationen beeinflusst. Spark und sonicWORX haben diesen Test mit Bravour bestanden, aber die Verarbeitung im Peak-Programm mit einer 24-Bit-Datei wirkt sich irgendwie auf den Rohteil aus. Auf der Spektraldarstellung des Testsignals (ich habe einen Ton von 1 kHz verwendet, dazu später mehr) war keine Verzerrung sichtbar, also wirkt sich dieser Effekt vielleicht nicht negativ auf den Klang aus, aber dieses Phänomen ist immer noch alarmierend.

Der letzte Nulltest wurde nur mit dem Spark-Programm durchgeführt, da bisher nur dieses diese Funktion hat. Diese Funktion dient zum „Zusammensetzen“ eines CD-Images aus verschiedenen Audiodateien in der richtigen Reihenfolge. Das von Spark erstellte Disk-Image (das später mit dem Jam-Programm von Adaptec in eine Audio-CD umgewandelt werden kann) ist eine normale Audiodatei mit Regionen, die so angeordnet sind, dass sie den Anfang und das Ende des Titels auf der CD anzeigen. Daher wurde eine 16-Bit-Testdatei genommen, daraus ein dreispuriges CD-Image erstellt und dann ein Nulltest durchgeführt. Das Ergebnis ist, dass die ursprünglichen 16-Bit-Dateien und die Informationen, die in dem daraus erzeugten Disk-Image enthalten sind, Stück für Stück übereinstimmen.

Dann wurde beschlossen, die Qualität der internen Verarbeitung von Audio-Editoren zu testen. Dazu wurde eine 24-Bit-Datei mit einem 1-kHz-Sinussignal aufgenommen und von VST-Modulen in folgender Reihenfolge bearbeitet: Waves Renaissance EQ, wobei die Entzerrung selbst komplett abgeschaltet und der Pegel am Processing-Ausgang um abgesenkt wurde 3 dB, dann das gleiche Modul, aber mit um 3 dB erhöhtem Ausgangspegel, und am Ende der Kette - Waves L1, das nur zum Dithern von 32-Bit-VST-Verarbeitung auf 24-Bit-Ausgabedatei verwendet wurde (Dither-Typ 1 , kein Noise Shaping, alle anderen L1 Parameter haben sich nicht verändert ). Dies wurde alles in eine neue Datei umgewandelt, die dann vom Spektrumanalysator der Sonic Solutions-Workstation und dem SpectraFoo-Programm analysiert wurde. In diesem Fall zeigten alle untersuchten Programme ihre beste Leistung - es wurden keine nichtlinearen Verzerrungen in den Spektrumsdiagrammen der Testdateien gefunden, was bedeutet, dass das VST-System korrekt aufgebaut wurde und keine "Gags" in das Signal einführt (Abb 11).

Spektrumdiagramm einer reinen 24-Bit-1-kHz-Sinuswelle:
a) - volles Spektrum im Spektrumanalysator von Sonic Solutions,
b) - Spektrum über 1 kHz in SpectraFoo,
c) - zum Vergleich das gleiche Signal nach Bündelung um 16 Bit im gleichen Maßstab wie b,
d) - derselbe Stamm, aber in einem anderen Maßstab, der es ermöglicht, den "Wald" entstehender Harmonischer zu betrachten.

Abschließend wurde die Korrektheit der eingebauten Verarbeitungsfunktionen mit demselben 1-kHz-Ton getestet. Der Change Gain-Befehl wurde auf den Testton angewendet, zuerst wurde der Pegel um 1 dB abgesenkt, dann um die gleichen 1 dB erhöht. Auf die gleiche Weise wurde eine weitere der wichtigsten Verarbeitungen überprüft - Fade. Anschließend wurden die Testdateien im Spektrumanalysator untersucht (Abb. 12). Die Ergebnisse waren recht gut, das heißt, es wurden keine nichtlinearen Verzerrungen gefunden, was bedeutet, dass die eingebaute Verarbeitung aller Editoren echte 24-Bit ist. Die einzige unangenehme Ausnahme ist das Fade des Spark-Programms, bei dem ein unverständliches Breitbandrauschen auftrat, das mit dem Signal abnahm (entsprechend ist dies kein Dither). Im Prinzip ist der Pegel dieses Rauschens nicht hoch (maximal -110 dB), aber sein bloßes Erscheinungsbild ist alarmierend.

Diagramm des Rauschspektrums, das beim Fading in Spark auftritt:
a) - Spektrumanalyse in Sonic Solutions,
b) - in SpectraFoo,
c) - um Fades in sonicWORX mit derselben Auflösung zu vergleichen.

So erfüllen moderne Sound-Editoren, die ausschließlich auf Kosten des Zentralprozessors des Computers arbeiten (und nicht auf Kosten spezialisierter DSPs, wie Sound Designer oder Sonic Solutions), trotz ihrer recht hohen Funktionalität und Geschwindigkeit derzeit leider einige Grundvoraussetzungen nicht Voraussetzungen für professionelle Audioarbeit. Und obwohl sie ihren Platz in der Studiopraxis gefunden haben und erfolgreich zur Lösung bestimmter Probleme eingesetzt werden können, sind diese Programme noch nicht für ernsthaftes Mastering geeignet (das ist die Nische, in der einige Hersteller ihre Produkte positionieren).

Schlussfolgerungen
Welchen der folgenden Editoren soll ich wählen? Es gibt wie immer keine einzige Antwort. Und obwohl alle beschriebenen Programme in ungefähr demselben Marktsegment angesiedelt sind, hat jedes seine eigenen Stärken und Schwächen. Wenn Sie den Sound lieber schnell bearbeiten und in Echtzeit mit Effekten arbeiten möchten, ist sonicWORX für diesen Zweck bestens geeignet. Und dank der mitgelieferten Dateiverarbeitungsmodule wird es auch für Fans von nicht trivialen Spezialeffekten nützlich sein. Wenn Sie lieber nicht in Echtzeit arbeiten (AP- und AS-Formate) und häufig Samples bearbeiten, ist Peak ausreichend. Letzterer ist auch als Basis-Editor (Schneiden, Kleben etc.) nicht schlecht, verliert aber beim Arbeiten mit vielen Dateien etwas an Geschwindigkeit gegenüber sonicWORX. Peak kann auch den glücklichen Besitzern von Pro Tools TDM empfohlen werden, da es der einzige der beschriebenen Editoren ist, der es Ihnen ermöglicht, das DAE-Protokoll für die Sound-Ein-/Ausgabe zu verwenden. Auch Pro Tools-Anwender werden an Spark interessiert sein, aber die Direct Connect-Technologie ist nicht der beste Weg, um mit der Idee von Digidesign zu interagieren. Der Hauptvorteil von Spark ist meiner Meinung nach die Möglichkeit, mit Projekten zu arbeiten, die viele separate Audiofragmente enthalten können. Für diejenigen, die gerne Samples bearbeiten, ist Spark ebenfalls geeignet - die einzigartige Funktion zum Importieren von Discs im Akai-Format ist sehr praktisch, und die lange Zeit zum Berechnen von Revisionen kann vernachlässigt werden, für kurze Fragmente vergiftet sie das Leben fast nicht.

Tabelle 1.
Gängige Plug-in-Formate.