Magic Master 3.6.0 — Reliable and Faster on Long Tracks
Version 3.6.0 is about reliability and speed on long, heavy tracks. The sound didn't change by a single bit — we verified it with hashes. Two things worth reading about.
The false "Mastering error" on long tracks — fixed
There used to be an ugly scenario. A long track (5+ minutes) with heavy modules enabled — AI-trace removal, post-separation cleanup, parallel compression — legitimately processes for up to ~10 minutes. And the master completed successfully. Yet the interface showed a red "Mastering error".
The cause wasn't in the audio — it was in the progress channel. The event stream (SSE) that drives the processing indicator was hard-capped at 600 seconds. Hit the ceiling, and it emitted a fake error, even though the job was already done or nearly done. Users saw an "error", re-ran the mastering, and wasted a token on work that was already finished.
What we did in 3.6.0:
- stream ceiling raised to 20 minutes — with headroom for the heaviest chains;
- added a heartbeat during quiet stages so the connection isn't treated as "stalled";
- on timeout the stream no longer fabricates an error — it falls back to authoritative status polling and shows the real result.
Result: no more false error, no need to re-run and burn a token.
Spectral processing — faster, sound byte-identical
The second change is about speed. The spectral stages (spectral denoise, AI-separation-artifact cleanup, vocal HF-resonance cleanup) now process the left and right stereo channels in parallel, on separate threads.
The key point: the sound does not change at all. The result is byte-identical to before. We verified this with golden SHA-256 hashes on real Suno tracks: the edm, hiphop and standard profiles matched exactly. This is a purely computational optimization, not new processing.
How much faster: up to ~1.3× end-to-end on tracks that use cleanup or denoise. In testing, a master with denoise and vocal cleanup went 27.3s → 21.0s, and the denoise stage alone sped up about 1.6×. Tracks without those modules are unchanged in speed — there's nothing there to parallelize.
Why this matters
Byte-identical is a trust signal. We didn't quietly "improve the sound" or tweak the chain under the guise of a speedup. The quality is exactly what you heard before the release — long tracks simply reach the finish line reliably now, and tracks with cleanup are ready faster.
Try it on your own material: magicmaster.pro/app. Pricing and tokens are on the pricing page.
Questions and answers
Why does a long track take so long to master?
A long track (5+ minutes) with heavy modules — AI-trace removal, separation cleanup, parallel compression — legitimately takes up to ~10 minutes. That's normal: the chain runs several full-spectrum passes. In 3.6.0 we raised the progress-stream ceiling to 20 minutes, so the interface waits for the real result instead of cutting it off early.
Did the sound change after the speedup?
No. We parallelized the spectral stages across the stereo channels, but the result is byte-identical to before — verified with golden SHA-256 hashes on real Suno tracks (edm, hiphop, standard matched exactly). The speedup is purely computational; the sound does not change at all.
What caused the false error?
The progress stream (SSE) hard-capped at 600 seconds and emitted a fake 'Mastering error', even though the master itself had already completed. Users saw the error and re-ran the job, wasting a token. Now, on timeout the stream no longer fabricates an error — it falls back to the authoritative job status.
Are all tracks faster now?
Tracks that use cleanup or denoise get up to ~1.3× faster end-to-end (e.g. a denoise + vocal-cleanup master went 27.3s → 21.0s; the denoise stage alone ~1.6×). Tracks without those modules are unchanged in speed.
Upload a track — a finished master in about a minute.
Open mastering →AI mastering onlineLUFS analyzer