Let's get back to the interface. A feature of Spark is the use of context menus in the program (yes, this is also possible on the Macintosh, despite the militant one-button function), in particular, this is used to add a module to a matrix cell. Each cell displays the name of the processing inserted into it and the level of the input signal. Unfortunately, only one window with processing parameters can be displayed at a time, to display the module interface, you need to double-click on the cell with it or "jump" directly by selecting the desired module from the Plug-In menu in the window for editing processing parameters.

Now about the sad. Firstly, the undo function is single-level (and this is in the 21st century!). Secondly, all editing operations are very slow: first, Spark saves a backup copy of the audio file, then it does the required operation (and this is also long, because instead of working with the edited piece, the program recalculates the entire file), then it calculates the waveform ( also the whole file). In general, extremely slow and inconvenient, especially with large (20-30 minutes) files. Apparently, such slow work is caused by the fact that during standard editing operations (delete, paste, etc.), Spark cannot work with part of the file, but only with the entire file, while creating a backup copy each time. Backup creation can, in principle, be disabled, but then you lose the undo altogether. Other programs seem more thoughtful to me in this place. There is another small drawback regarding the way the calculated waveform is stored. Most Macintosh programs do not store the calculated waveform in a separate file (like many Windows programs do), but in a special area of ​​the audio file called a "resource fork". That is, the user sees only one file, without any garbage of the same name that accumulates if you edit a file in several Windows editors. This is very convenient, especially since many programs "understand" each other and do not have to recalculate the waveform every time. Spark does not shine in this sense: not only does it not understand others, it also saves a graphical representation of the waveform in a separate file, next to the original one. A trifle, of course, but still unpleasant.

But enough about the sad stuff, let's move on to working with Spark samplers. Everything is very good here, the program can communicate with samplers both via MIDI and SCSI, and although the list of directly supported models is not as wide as that of Peak, you can import samples from Akai libraries from a computer CD-ROM directly into the program (and then already - and into the sampler).

I would especially like to note the means of restoring phonograms attached to Spark XL. These are two plugins: TC Declick and TC Denoise (unfortunately they are not VST and therefore can only work in Spark). Denoise (Fig. 9) works with the noise sample, subtracting it from the soundtrack, for Declick the sample is not required, the intensity and frequency of clicks are set by the controls. The quality of noise reduction in both modules is very good. Among the resource-dependent processing of this type, modules from Spark introduce the least amount of distortion into the soundtrack. I have not seen declickers comparable in quality to Declick, and perhaps only DINR from Digidesign can compete with Denoise. The latter has a lot of settings, and sometimes, "playing around" with the DINR parameters, you can achieve better results than with Denoise. In fairness, it should be noted that Denoise is quite easy to work with, and it produces good results even with default settings (however, if the result is not satisfactory, it is almost impossible to radically correct the situation, it remains to offer the module different noise samples).

If we talk about Spark in general, then I would like to note the good concept of the program and the intuitive interface. But the implementation of many functions of this editor is, unfortunately, not very good so far, so let's hope for improvements in future versions.

Testing
The abundance of functions of modern sound editors is impressive, but how honestly do programs perform these functions? It's no secret that many companies do not inform the user about the internal architecture and "pitfalls" of their software products. It happens, for example, that the bit depth of the processors built into the program can be low (16-bit), but at the same time the program processes 24-bit files without a twinge of conscience and without warning. The result is corrupted sound. In order to clarify some of the features of the programs that do not lie on the surface, a number of tests were carried out.

So, the first test is for the correctness of recording and playback. For it, I used a RME DIGI 96/8 Pro PCI card installed in a Power Macintosh 9600/350 computer. The board has digital interfaces in ADAT, SPDIF and AES/EBU formats. This board has Sound Manager drivers, but ASIO drivers were used for testing, as only 16-bit (or lower) audio can be played and recorded through the Sound Manager. The control system was Digidesign Pro Tools 442 with Pro Master 20 interface and Sound Designer II version 2.82 installed in Macintosh Centris 650. Despite its already quite respectable (by computer standards) age, this system still works perfectly and has been tested for correctness many times and in different parts of the world, so without hesitation it was chosen as the reference. So, the technique: the generated signal was taken (sampling frequency 44.1 kHz, bit depth 16 and 24 bits) with a sliding frequency (from 5 to 22000 Hz) lasting 30 seconds, played back by the Sound Designer program (via AES / EBU on Pro Master), and recorded in the programs under study (also via AES/EBU on the RME board); then, on the contrary, it was reproduced by programs, and recorded in Sound Designer. This used half-meter Apogee Wyde Eye wires with gold-plated Neutrik connectors. The resulting files in Sound Designer were cut off at the beginning and end of the signal (of course, accurate to the sample) and compared with the original generated file. For such a comparison, Sound Designer has a Compare Files command, in which the values ​​of each sample in one file are subtracted from the corresponding samples of the other, resulting in a sound file of the "difference" between the two files. If the two files match bit by bit (as it should with digital recording), then the resulting file will consist of all zeros. For complete certainty, the Find Peak command was used, and if the values ​​of all samples in the "differences" file are zero, then Sound Designer issues a message about this. If there are values ​​other than zero (respectively, the tested files do not match bit by bit), then the cursor will be placed on the loudest of such samples. To be sure, testing was carried out at least five times for each position, if the program recorded and played back correctly, then an additional test was conducted with a signal lasting five minutes.

The results of this test were rather disappointing. Of all the programs correctly (that is, the recorded file passed the null test), only Peak was able to record and play back, and even then only on 16-bit sound. All other null tests did not pass either on 16 bits or on 24 bits. Unfortunately, it is impossible to say exactly what exactly happens to the sound when recording and playing back programs, but it is obvious that this is not a 16- or 20-bit trunk (that is, simple rejection of "unnecessary" bits) - firstly, the distortions would be much more noticeable, and secondly, the bitscope of the SpectraFoo program, with which the results were analyzed (Fig. 10), showed the activity of all 24 bits of the signal. This is also not a dither, since the frequency of the difference signal increases as the frequency of the test signal increases. It is difficult to say unequivocally about the fault of the programs under study, since the system consisted of many elements (board, ASIO driver, program), although Peak showed that it is quite possible to work correctly with at least 16-bit sound with this board and driver provide. Various RME board driver settings have been used in an attempt to achieve correct operation, the sample rate master has changed (by default, the master is the playback device), but the results are always the same.

SpectraFoo bitscope readings on 16-bit (a) and 24-bit (b) signals.

Finally, let's talk about a number of program features identified in this test. Peak could not play the sound directly from the beginning of the file, the first few samples were "chewed", so to test this program, a file with a two-second silence at the beginning was used to allow Peak to "accelerate". After recording a 24-bit signal reproduced by the Spark program, it turned out that the recorded fragment of the test signal after cutting off the silence turned out to be four samples longer than the original one. What caused this is not known, but, apparently, the effect of this fact on the sound is insignificant.

Another study was conducted using the null test. A file was taken with the same test signal, but with a two-second silence before it (the same one used for the previous test of the Peak program). Then, in each program, a fade was made on this silence. Then all unnecessary silence was cut off, and the resulting file was compared with the original. This was done in order to find out whether the processing of the beginning of the file by the program affects the rest of the audio information. Spark and sonicWORX withstood this test with honor, but processing in the Peak program with a 24-bit file somehow affects the raw part. On the spectrum plot of the test signal (I used a tone of 1 kHz, more on that later), no distortion was visible, so perhaps this effect does not have a negative effect on the sound, but this phenomenon is still alarming.

The last null test was performed only with the Spark program, since so far only it has this function. This function is to "assembly" a CD image from different audio files in the correct order. The disk image created by Spark (which can later be turned into an audio CD by the Adaptec Jam program) is a regular audio file with regions arranged to indicate the beginning and end of the track on the CD. Therefore, a 16-bit test file was taken, a three-track CD image was made from it, and then a null test was carried out. The result is that the original 16-bit files and the information contained in the disk image generated from them match bit by bit.

Then it was decided to test the quality of internal processing of audio editors. For this, a 24-bit file with a 1 kHz sinusoidal signal was taken and processed by VST modules in the following sequence: Waves Renaissance EQ, in which the equalization itself was completely turned off, and the level at the processing output was lowered by 3 dB, then the same module, but with output level increased by 3 dB, and at the end of the chain - Waves L1, which was used only for dithering from 32-bit VST processing to 24-bit output file (dither type 1, no noise shaping, all other L1 parameters did not change ). This was all converted into a new file, which was then analyzed by the spectrum analyzer of the Sonic Solutions workstation and the SpectraFoo program. In this case, all the programs under study showed their best performance - no nonlinear distortions were found on the spectrum graphs of the test files, which means that the VST system was built correctly and does not introduce any "gags" into the signal (Fig. 11).

Spectrum plot of a pure 24-bit 1 kHz sine wave:
a) - full spectrum in Sonic Solutions spectrum analyzer,
b) - spectrum above 1 kHz in SpectraFoo,
c) - for comparison, the same signal after trunking by 16 bits in the same scale as b,
d) - the same trunk, but on a different scale, allowing to consider the "forest" of emerging harmonics.

Lastly, the correctness of the built-in processing functions was tested using the same 1 kHz tone. The Change Gain command was applied to the test tone, first the level was lowered by 1 dB, then increased by the same 1 dB. In the same way, another of the most important processing was checked - fade. Then the test files were examined in the spectrum analyzer (Fig. 12). The results turned out to be quite good, that is, no non-linear distortions were found, which means that the built-in processing of all editors is true 24-bit. The only unpleasant exception is the fade of the Spark program, where an incomprehensible broadband noise appeared, which decreased along with the signal (accordingly, this is not a dither). In principle, the level of this noise is not high (maximum -110 dB), but its very appearance is alarming.

Graph of the spectrum of noise that occurs when fading in Spark:
a) - spectrum analysis in Sonic Solutions,
b) - in SpectraFoo,
c) - to compare fades in sonicWORX with the same resolution.

Thus, modern sound editors that work exclusively at the expense of the computer's central processor (and not at the expense of specialized DSPs, like Sound Designer or Sonic Solutions), despite their rather high functionality and speed, unfortunately, currently do not meet some basic requirements for professional audio work. And although they have found their place in studio practice and can be successfully used to solve certain problems, these programs are not yet suitable for any serious mastering (this is the niche where some manufacturers position their products).

conclusions
Which of the following editors to choose? There is no single answer, as always. And although all the described programs are located in approximately the same market sector, each has its own strengths and weaknesses. If you prefer to quickly edit sound and work with effects in real time, then sonicWORX will suit this purpose as well as possible. And thanks to the included file processing modules, it will also come in handy for fans of non-trivial special effects. If you prefer to work not in real time (AP and AS formats) and often edit samples, then Peak will do. The latter is also not bad as a basic editor (cut, glue, etc.), although when working with a large number of files, it loses a little in speed to sonicWORX. Peak can also be recommended to the happy owners of Pro Tools TDM, as the only one of the described editors that allows you to use the DAE protocol for sound input / output. Pro Tools users will also be interested in Spark, but Direct Connect technology is not the best way to interact with Digidesign's brainchild. The main advantage of Spark, I think, is the ability to work with projects that can contain many separate audio fragments. For those who like to edit samples, Spark is also suitable - the unique function of importing from Akai format discs is very convenient, and the long time for calculating revisions can be neglected, for short fragments it almost does not poison life.

Table 1.
Common plug-in formats.