Upload a video, let DocEasy automatically find each speaker, give every voice its own effect, and download one finished MP4. Everything runs on your device — nothing is uploaded.
No. Reading, decoding, speaker detection, effects, playback capture, re-encoding, and muxing all happen inside your browser tab using the File System, Streams, Web Audio, and WebCodecs APIs. Nothing is sent to a server.
FFmpeg.wasm needs SharedArrayBuffer and a fair amount of memory to run, and most mobile browsers either block SharedArrayBuffer entirely or restrict it heavily for security reasons (it requires specific cross-origin isolation headers that aren't always practical to set, and even when set, mobile Safari and many mobile Chrome configurations still refuse it or run out of memory). That made muxing fail silently or crash on phones. The replacement — mp4-muxer, a small pure-JavaScript MP4 writer built on the WebCodecs standard — needs none of that, so it works the same way on a phone as on a laptop.
The audio is newly generated from your effect choices, as expected. The video picture, however, is re-encoded, not losslessly copied. Doing a true byte-level copy of your original video stream (what FFmpeg's "copy" mode did) requires understanding and unpacking the exact container format your file came in — a "demuxer" — and this build doesn't include one. Instead, your original video is played back once in the background, each displayed frame is captured, and that captured frame is compressed again into a new H.264 video stream. This means there is a small, real quality trade-off from that second compression pass, the same way saving a JPEG a second time loses a little more detail than the first save. For most videos this is not visually obvious, but it is a genuine trade-off worth knowing about rather than a lossless copy.
Because of the re-encode explained above, DocEasy has to actually play your video from start to finish in the background to capture every frame — there's no shortcut around watching it once. A 10-minute video takes roughly 10 minutes to mux; a 2-hour video takes roughly 2 hours. This is slower than the original "copy" approach was designed to be, and is the direct cost of removing the FFmpeg/SharedArrayBuffer dependency so the tool works reliably on mobile.
DocEasy checks, before you click the button, whether your browser's WebCodecs VideoEncoder and AudioEncoder actually support the codecs needed (H.264 video, and AAC audio with an Opus fallback). If they don't, the muxing button stays disabled and a clear message explains why — you can still download your processed audio and your original video separately and combine them yourself in a video editor.
Audio is split into short windows; loudness finds where someone is actually speaking, and an autocorrelation-based pitch detector estimates each segment's fundamental pitch. Segments with similar pitch are grouped into "Speaker 1," "Speaker 2," and so on. This is a real pitch-based heuristic, not a trained neural voice-recognition model — it works best when speakers have noticeably different vocal pitch ranges, and less well when two speakers sound similar or a single speaker's pitch varies a lot.
Deep and Chipmunk shift pitch down or up with a phase vocoder, preserving your original speaking speed. Monster adds a bigger downward shift plus a simple echo-based reverb. Robot uses ring modulation for that buzzy, mechanical tone. Echo repeats the voice with decaying feedback. Alien combines a pitch shift with a rhythmic volume wobble (tremolo). Whisper gates out quiet moments and flattens loud peaks. Custom exposes raw pitch and formant sliders.
The phase vocoder used here is a genuine, from-scratch implementation with no external audio library, and it's honest about its limits: shifts within about plus or minus one octave sound natural; push further, or apply it to breathy/noisy audio, and you'll hear phase-vocoder smearing artifacts. If a shift sounds too artificial, dial it back.
Chrome and Edge (90+) have the most complete WebCodecs and Origin Private File System support and are recommended, especially for the muxing step, which depends on VideoEncoder/AudioEncoder and requestVideoFrameCallback. Firefox and Safari support varies — DocEasy checks capability before offering muxing rather than pretending it works everywhere.
Yes — that's specifically why FFmpeg.wasm was removed. Very large files (over 1GB) will still warn you, since mobile devices have much less memory than a desktop, but the muxing pipeline itself no longer depends on anything mobile browsers block.
The file-reading stage checkpoints its progress, so a reload can detect leftover chunks from an interrupted session. Speaker detection, effects processing, and the muxing/capture stage do not currently have their own save points — if the tab closes during those, you'll need to restart from file selection. Making every stage resumable is on the roadmap.
No — an audio track is required for speaker detection and voice effects. DocEasy will tell you plainly if none is found rather than silently producing a broken result.
This usually means the two speakers have similar vocal pitch, or one speaks only briefly. This is a known limit of a pitch-based clustering approach rather than a full neural diarization model.
Processing and muxing use your browser's on-device Origin Private File System (or IndexedDB as a fallback) to hold data temporarily. DocEasy checks how much free space is actually available and warns you up front rather than failing partway through a long file.