Să revenim la interfață. O caracteristică a Spark este utilizarea meniurilor contextuale în program (da, acest lucru este posibil și pe Macintosh, în ciuda funcției militante cu un singur buton), în special, aceasta este folosită pentru a adăuga un modul la o celulă matriceală. Fiecare celulă afișează numele procesării introduse în ea și nivelul semnalului de intrare. Din păcate, o singură fereastră cu parametrii de procesare poate fi afișată la un moment dat, pentru a afișa interfața modulului, trebuie să faceți dublu clic pe celulă cu aceasta sau să „săriți” direct selectând modulul dorit din meniul Plug-In din meniul Plug-in. fereastra pentru editarea parametrilor de procesare.

Acum despre trist. În primul rând, funcția de anulare este cu un singur nivel (și aceasta este în secolul 21!). În al doilea rând, toate operațiunile de editare sunt foarte lente: în primul rând, Spark salvează o copie de rezervă a fișierului audio, apoi face operația necesară (și aceasta este, de asemenea, lungă, deoarece în loc să lucreze cu piesa editată, programul recalculează întregul fișier) , apoi calculează forma de undă (de asemenea, întregul fișier). În general, extrem de lent și incomod, mai ales cu fișiere mari (20-30 de minute). Aparent, o astfel de muncă lentă este cauzată de faptul că în timpul operațiunilor standard de editare (ștergere, lipire etc.), Spark nu poate lucra cu o parte a fișierului, ci doar cu întregul fișier, creând în același timp o copie de rezervă de fiecare dată. Crearea backupului poate fi, în principiu, dezactivată, dar apoi pierzi complet anularea. Alte programe mi se par mai gânditoare în acest loc. Există un alt mic dezavantaj în ceea ce privește modul în care este stocată forma de undă calculată. Majoritatea programelor Macintosh nu stochează forma de undă calculată într-un fișier separat (cum o fac multe programe Windows), ci într-o zonă specială a fișierului audio numită „furcătură de resurse”. Adică, utilizatorul vede un singur fișier, fără niciun gunoi cu același nume care se acumulează dacă editezi un fișier în mai multe editoare Windows. Acest lucru este foarte convenabil, mai ales că multe programe se „înțeleg” între ele și nu trebuie să recalculeze forma de undă de fiecare dată. Spark nu strălucește în acest sens: nu numai că nu îi înțelege pe alții, dar salvează și o reprezentare grafică a formei de undă într-un fișier separat, alături de cel original. Un fleac, desigur, dar tot neplăcut.

Dar destule despre lucrurile triste, să trecem la lucrul cu probele Spark. Totul este foarte bine aici, programul poate comunica cu samplere atât prin MIDI, cât și prin SCSI și, deși lista modelelor suportate direct nu este la fel de largă ca cea a lui Peak, puteți importa mostre din bibliotecile Akai de pe un CD-ROM al computerului direct în programul (și apoi deja - și în sampler).

Aș dori în special să notez mijloacele de restaurare a fonogramelor atașate la Spark XL. Acestea sunt două plugin-uri: TC Declick și TC Denoise (din păcate, nu sunt VST și, prin urmare, pot funcționa doar în Spark). Denoise (Fig. 9) lucrează cu proba de zgomot, scăzând-o din coloana sonoră, pentru Declick nu este necesară proba, intensitatea și frecvența clicurilor sunt stabilite de controale. Calitatea reducerii zgomotului în ambele module este foarte bună. Dintre procesele dependente de resurse de acest tip, modulele de la Spark introduc cea mai mică distorsiune în coloana sonoră. Nu am văzut declicker-uri comparabile ca calitate cu Declick și poate doar DINR de la Digidesign poate concura cu Denoise. Acesta din urmă are o mulțime de setări, iar uneori, „jucându-vă” cu parametrii DINR, puteți obține rezultate mai bune decât cu Denoise. Pentru dreptate, trebuie remarcat că Denoise este destul de ușor de lucrat și produce rezultate bune chiar și cu setările implicite (cu toate acestea, dacă rezultatul nu este satisfăcător, este aproape imposibil să corectăm radical situația, rămâne să oferim module diferite mostre de zgomot).

Dacă vorbim despre Spark în general, atunci aș dori să remarc conceptul bun al programului și interfața intuitivă. Dar implementarea multor funcții ale acestui editor nu este, din păcate, foarte bună până acum, așa că să sperăm la îmbunătățiri în versiunile viitoare.

Testare
Abundența de funcții ale editorilor de sunet modern este impresionantă, dar cât de sincer îndeplinesc programele aceste funcții? Nu este un secret pentru nimeni că multe companii nu informează utilizatorul despre arhitectura internă și „capcanele” produselor lor software. Se întâmplă, de exemplu, că adâncimea de biți a procesoarelor încorporate în program poate fi mică (16 biți), dar, în același timp, programul procesează fișiere pe 24 de biți fără o strângere de conștiință și fără avertisment. Rezultatul este sunet corupt. Pentru a clarifica unele dintre caracteristicile programelor care nu se află la suprafață, au fost efectuate o serie de teste.

Deci, primul test este pentru corectitudinea înregistrării și redării. Pentru aceasta, am folosit o placă PCI RME DIGI 96/8 Pro instalată într-un computer Power Macintosh 9600/350. Placa are interfețe digitale în formatele ADAT, SPDIF și AES/EBU. Această placă are drivere Sound Manager, dar driverele ASIO au fost folosite pentru testare, deoarece doar sunetul pe 16 biți (sau mai mic) poate fi redat și înregistrat prin Sound Manager. Sistemul de control a fost Digidesign Pro Tools 442 cu interfață Pro Master 20 și Sound Designer II versiunea 2.82 instalată în Macintosh Centris 650. În ciuda vechimii sale destul de respectabile (după standardele computerelor), acest sistem încă funcționează perfect și a fost testat de mai multe ori pentru corectitudine. și în diferite părți ale lumii, așa că fără ezitare a fost ales ca referință. Deci, tehnica: semnalul generat a fost preluat (frecvența de eșantionare 44,1 kHz, adâncime de biți 16 și 24 de biți) cu o frecvență de glisare (de la 5 la 22000 Hz) cu durata de 30 de secunde, redat de programul Sound Designer (prin AES / EBU pe Pro Master), și înregistrate în programele în studiu (tot prin AES/EBU pe placa RME); apoi, dimpotrivă, a fost reprodus prin programe și înregistrat în Sound Designer. Acesta a folosit fire Apogee Wyde Eye de jumătate de metru cu conectori Neutrik placați cu aur. Fișierele rezultate în Sound Designer au fost tăiate la începutul și la sfârșitul semnalului (desigur, exacte pentru eșantion) și comparate cu fișierul generat original. Pentru o astfel de comparație, Sound Designer are o comandă Compare Files, în care valorile fiecărei mostre dintr-un fișier sunt scăzute din mostrele corespunzătoare ale celuilalt, rezultând un fișier de sunet al „diferenței” dintre cele două fișiere. Dacă cele două fișiere se potrivesc bit cu bit (cum ar trebui în cazul înregistrării digitale), atunci fișierul rezultat va consta din toate zerourile. Pentru o certitudine completă, a fost folosită comanda Find Peak și, dacă valorile tuturor mostrelor din fișierul „diferențe” sunt zero, atunci Sound Designer emite un mesaj despre acest lucru. Dacă există alte valori decât zero (respectiv, fișierele testate nu se potrivesc bit cu bit), atunci cursorul va fi plasat pe cea mai tare dintre astfel de mostre. Pentru a fi sigur, testarea a fost efectuată de cel puțin cinci ori pentru fiecare poziție, dacă programul a fost înregistrat și redat corect, atunci a fost efectuat un test suplimentar cu un semnal de cinci minute.

Rezultatele acestui test au fost destul de dezamăgitoare. Dintre toate programele corect (adică fișierul înregistrat a trecut testul nul), doar Peak a putut să înregistreze și să reda, și chiar și atunci doar pe sunet pe 16 biți. Toate celelalte teste nule nu au trecut nici pe 16 biți, nici pe 24 de biți.Din păcate, este imposibil să spunem exact ce se întâmplă exact cu sunetul la înregistrarea și redarea programelor, dar este evident că acesta nu este un 16 sau 20 de biți. -bit trunk (adică simpla respingere a biților „inutili”) - în primul rând, distorsiunile ar fi mult mai vizibile, iar în al doilea rând, bitscope-ul programului SpectraFoo, cu care au fost analizate rezultatele (Fig. 10), a arătat activitatea tuturor celor 24 de biți ai semnalului. De asemenea, acesta nu este un dither, deoarece frecvența semnalului de diferență crește pe măsură ce crește frecvența semnalului de test. Este greu de spus fără echivoc despre vina programelor studiate, deoarece sistemul consta din multe elemente (placă, driver ASIO, program), deși Peak a arătat că este destul de posibil să se lucreze corect cu sunet de cel puțin 16 biți cu această placă și șofer oferă. Au fost utilizate diverse setări ale driverului plăcii RME în încercarea de a obține o funcționare corectă, masterul ratei de eșantionare s-a schimbat (în mod implicit, masterul este dispozitivul de redare), dar rezultatele sunt întotdeauna aceleași.

Citirile de biți SpectraFoo pe semnale de 16 biți (a) și 24 de biți (b).

În cele din urmă, să vorbim despre o serie de caracteristici ale programului identificate în acest test. Peak nu a putut reda sunetul direct de la începutul fișierului, primele mostre au fost „mestecate”, așa că pentru a testa acest program, a fost folosit un fișier cu o liniște de două secunde la început pentru a permite lui Peak să „accelereze”. După înregistrarea unui semnal pe 24 de biți reprodus de programul Spark, s-a dovedit că fragmentul înregistrat al semnalului de test după întreruperea tăcerii s-a dovedit a fi cu patru mostre mai lung decât cel original. Nu se știe ce a cauzat acest lucru, dar, aparent, efectul acestui fapt asupra sunetului este nesemnificativ.

Un alt studiu a fost realizat folosind testul nul. Un fișier a fost preluat cu același semnal de test, dar cu o liniște de două secunde înainte (același folosit pentru testul anterior al programului Peak). Apoi, în fiecare program, s-a făcut un fade pe această tăcere. Apoi, toată tăcerea inutilă a fost întreruptă, iar fișierul rezultat a fost comparat cu originalul. Acest lucru a fost făcut pentru a afla dacă procesarea începutului fișierului de către program afectează restul informațiilor de sunet. Spark și sonicWORX au rezistat cu onoare acestui test, dar procesarea în programul Peak cu un fișier pe 24 de biți afectează cumva partea brută. Pe graficul spectrului semnalului de testare (am folosit un ton de 1 kHz, mai multe despre asta mai târziu), nu a fost vizibilă nicio distorsiune, așa că poate că acest efect nu are un efect negativ asupra sunetului, dar acest fenomen este încă alarmant.

Ultimul test nul a fost efectuat doar cu programul Spark, deoarece până acum doar acesta are această funcție. Această funcție este de a „asambla” o imagine CD din diferite fișiere audio în ordinea corectă. Imaginea de disc creată de Spark (care poate fi ulterior transformată într-un CD audio de către programul Adaptec Jam) este un fișier audio obișnuit cu regiuni aranjate pentru a indica începutul și sfârșitul piesei de pe CD. Prin urmare, a fost luat un fișier de testare pe 16 biți, a fost realizată o imagine CD cu trei piese din acesta și apoi a fost efectuat un test nul. Rezultatul este că fișierele originale pe 16 biți și informațiile conținute în imaginea de disc generată din ele se potrivesc bit cu bit.

Apoi s-a decis testarea calității procesării interne a editorilor audio. Pentru aceasta, un fișier de 24 de biți cu un semnal sinusoidal de 1 kHz a fost preluat și procesat de modulele VST în următoarea secvență: Waves Renaissance EQ, în care egalizarea în sine a fost complet oprită, iar nivelul la ieșirea de procesare a fost scăzut cu 3 dB, apoi același modul, dar cu nivelul de ieșire crescut cu 3 dB, iar la sfârșitul lanțului - Waves L1, care a fost folosit doar pentru dithering de la procesarea VST pe 32 de biți la fișierul de ieșire pe 24 de biți (dither tip 1 , fără modelare a zgomotului, toți ceilalți parametri L1 nu s-au modificat). Toate acestea au fost convertite într-un fișier nou, care a fost apoi analizat de analizorul de spectru al stației de lucru Sonic Solutions și de programul SpectraFoo. În acest caz, toate programele studiate și-au arătat cele mai bune performanțe - nu au fost găsite distorsiuni neliniare pe graficele de spectru ale fișierelor de testare, ceea ce înseamnă că sistemul VST a fost construit corect și nu introduce niciun „gag” în semnal (Fig. . 11).

Graficul spectrului de undă sinusoidală pură de 24 de biți de 1 kHz:
a) - spectru complet în analizorul de spectru Sonic Solutions,
b) - spectru peste 1 kHz în SpectraFoo,
c) - pentru comparație, același semnal după trunking cu 16 biți la aceeași scară ca b,
d) - același trunchi, dar la o scară diferită, permițând să se ia în considerare „pădurea” armonicilor emergente.

În cele din urmă, corectitudinea funcțiilor de procesare încorporate a fost testată folosind același ton de 1 kHz. Comanda Change Gain a fost aplicată tonului de test, mai întâi nivelul a fost scăzut cu 1 dB, apoi crescut cu același 1 dB. În același mod, a fost verificată o altă procesare dintre cele mai importante - fade. Apoi fișierele de testare au fost examinate în analizorul de spectru (Fig. 12). Rezultatele s-au dovedit a fi destul de bune, adică nu au fost găsite distorsiuni neliniare, ceea ce înseamnă că procesarea încorporată a tuturor editorilor este adevărată pe 24 de biți. Singura excepție neplăcută este estomparea programului Spark, unde a apărut un zgomot de bandă largă de neînțeles, care a scăzut odată cu semnalul (în consecință, acesta nu este un dither). În principiu, nivelul acestui zgomot nu este ridicat (maximum -110 dB), dar însăși aspectul său este alarmant.

Graficul spectrului de zgomot care apare la estomparea în Spark:
a) - analiza spectrului în Sonic Solutions,
b) - în SpectraFoo,
c) - pentru a compara fade în sonicWORX cu aceeași rezoluție.

Astfel, editorii de sunet moderni care lucrează exclusiv în detrimentul procesorului central al computerului (și nu în detrimentul DSP-urilor specializate, precum Sound Designer sau Sonic Solutions), în ciuda funcționalității și vitezei lor destul de ridicate, din păcate, în prezent nu îndeplinesc unele de bază. cerințe pentru munca audio profesională. Și deși și-au găsit locul în practica de studio și pot fi folosite cu succes pentru a rezolva anumite probleme, aceste programe nu sunt încă potrivite pentru vreo mastering serios (aceasta este nișa în care unii producători își poziționează produsele).

concluzii
Pe care dintre următorii editori să alegi? Nu există un singur răspuns, ca întotdeauna. Și deși toate programele descrise sunt situate în aproximativ același sector de piață, fiecare are propriile sale puncte forte și puncte slabe. Dacă preferați să editați rapid sunetul și să lucrați cu efecte în timp real, atunci sonicWORX se va potrivi cât mai bine acestui scop. Și datorită modulelor de procesare a fișierelor incluse, va fi de asemenea util pentru fanii efectelor speciale non-triviale. Dacă preferați să lucrați nu în timp real (formatele AP și AS) și să editați adesea mostre, atunci Peak va face. Acesta din urmă nu este rău nici ca editor de bază (tăiat, lipit etc.), deși atunci când lucrezi cu un număr mare de fișiere, pierde puțin în viteză față de sonicWORX. Peak poate fi recomandat și fericiților posesori ai Pro Tools TDM, ca singurul dintre editorii descriși care vă permite să utilizați protocolul DAE pentru intrare/ieșire sunet. Utilizatorii Pro Tools vor fi, de asemenea, interesați de Spark, dar tehnologia Direct Connect nu este cea mai bună modalitate de a interacționa cu creația lui Digidesign. Principalul avantaj al Spark, cred, este capacitatea de a lucra cu proiecte care pot conține multe fragmente audio separate. Pentru cei cărora le place să editeze mostre, Spark este, de asemenea, potrivit - funcția unică de import de pe discuri în format Akai este foarte convenabilă, iar timpul lung pentru calcularea revizuirilor poate fi neglijat, pentru fragmente scurte aproape că nu otrăvește viața.

Tabelul 1.
Formate comune de plug-in.