How much faster is mastering now?

The service now processes up to 4 tracks at once instead of a strict one-at-a-time queue. In a test on our production server, four tracks that took ~43 seconds back-to-back are now ready together in ~14 seconds — 3x faster under load. During peak times you no longer wait for the server to free up.

Is a single track faster too?

The processing time for one track is essentially unchanged — the mastering algorithm itself is the same. The speedup shows when several tracks run at once: they used to queue up, now they process in parallel, so you get your result sooner.

Can my mastering get stuck in the processing state?

No. We fixed a rare case where a job finished but its status stayed at 'processing'. Every master now reliably reaches a final state — 'Done', or an honest error with a token refund.

Did parallel processing hurt sound quality?

No. We ran a load test: with several tracks processing at once, every output was checked for loudness (LUFS), True Peak, clipping and distortion — results are identical to processing one at a time. Quality does not depend on how many tracks run in parallel.

Mastering is faster now: up to 4 tracks at once, with no stuck jobs

2026-07-23 · Magic Master

Good news for anyone who masters regularly, especially at busy times: Magic Master is now faster and more reliable. We scaled the engine to process several tracks at once, and closed a rare bug that could leave a mastering status "stuck". The sound algorithm is unchanged — your masters sound exactly the same, they just arrive sooner.

Up to 4 tracks at once — up to 3x faster under load

Previously, free masters were processed strictly one at a time: if several people uploaded tracks at the same moment, the jobs lined up in a queue, and the last one waited for all the others to finish.

Now the service processes up to four tracks in parallel. The difference is most noticeable under load:

in a test on our production server, four tracks that took ~43 seconds back-to-back are now ready together in ~14 seconds — that's 3x faster;
at peak times your track no longer waits behind other people's — the server picks it up as soon as one of the parallel slots frees up.

For a single track, processing time is the same (it's the same high-quality pipeline) — the win is that tracks no longer wait for each other.

Your master always finishes

We fixed a rare but annoying case: a job would actually finish (the result was ready and downloadable), yet its history status could stay at "processing". It looked as if the mastering had "hung", even though everything was done.

Now every master reliably reaches a final status — "Done", or an honest error with an automatic token refund. No more "phantom" jobs stuck in processing. This applies to every mode: normal mastering, express AI-fingerprint cleanup, stem mastering and batch processing.

We tested quality under load separately

Speeding things up is pointless if the sound suffers. So we ran a load test: launching several masters at once and checking every output — hitting the target loudness (LUFS), True Peak ≤ −1 dBTP, no clipping and no distortion.

The result: with parallel processing, quality is identical to one-at-a-time. Your track sounds the same no matter how many sessions run alongside it — and under the hood we added a safeguard that keeps load from degrading the processing.

What this means for you

Faster at peak times — up to 3x less waiting when the service is busy.
More reliable — a master always finishes, with no stuck statuses.
Same quality — the sound is unchanged, and parallel processing is verified by a load test.

It's all live already and needs nothing from you — just upload a track. Your first basic master each day is free.

Want to go deeper on loudness and metrics? See What is LUFS and True Peak for streaming.

Try Magic Master

Upload a track — a finished master in seconds.

Open mastering →LUFS analyzer