Csináltam html-ben néhány projektet, mint például audio normalizáló, auto gain stage, eq match és lenne egy fontos kérdésem?

Te csináltad a projektet, te tudod, hogy milyen technológiát, algoritmusokat, libeket használtál. Ez az infó nélkül max annyit lehet mondani, hogy vegyél több ramot, zárj be minden mást, ja csak javascript kell akkor keress egy javascript engine-t böngésző nélkül.

De az igazi az lenne, ha a kódodat megjavítanád

A HTML - mint a nevében is benne van - csak egy, a weboldal szerkezetét leíró nyelv, azzal nem tudsz audio fájlokat feldolgozni, ahhoz kell valami kliens oldali (alkalmasint Javascript, de a WASM sem elvetendő) illetve szerver oldali programkód.

Ha ezt valóban a kliens oldalon dolgozod fel, az kemény meló a gépnek: egy audio CD minőségű tömörítetlen hang másodpercenként 44100 Hz * 16 bit * 2 csatorna = 1411200 bit vagyis 176,4 kbájt, vagyis egy 3 perces (átlag kb. ilyen hosszú egy popszám) zene 31,752 MB - azt egyszerre a kliensoldalon kezelni szép teljesítmény.

Jó lenne látni a forráskódot, hogy láthassuk a probléma forrását.

2

30MB-ot kezelni egyszerre miért lenne szép teljesítmény?

#5:

1. "Báttya leragadt a 2000-es években." - argumentum ad hominem érvelési hiba. Szakmaiatlan, fórumképtelen.

2. Nem írtam olyasmit, hogy böngészőben nem lehetne kezelni. Csak azt, hogy:

- pusztán HTML-ben nem lehet, hisz az csak a weboldal szerkezetét leíró nyelv

- kliensoldalon, pusztán Javascripttel (lásd: #4-es hozzászólásom) "szép teljesítmény", nem épp optimális teljesítményt biztosít (pláne hangszerkesztésnél, ami erőforrásigényesebb feladat)

3. Továbbra sem tudjuk, hogy a kérdező milyen megoldásokat használ - például alkalmaz-e WASM-t (ami tud némi teljesítménybeli javulást okozni - például: [link] ), Web Workers API-t (ami lehetővé teszi, hogy a folyamatok a háttérben fussanak - [link] - így nem "omlik össze", "fagy le" az előtérben futó alkalmazás), vagy hogy a "audio normalizáló, auto gain stage, eq match" hogyan került megvalósításra