Batch audio & media conversion

This is the single most repeated signal in this cluster. A macOS developer (wcjiang) keeps shipping and re-validating a local, offline batch audio converter for one reason: the online options are frustrating. They require an internet connection, put limits on file count or size, support formats unpredictably, and handle metadata and cover art badly. For anyone converting more than a handful of tracks, the web workflow of "upload, wait, download, repeat" stops being worth it.

The actual jobs are ordinary and repetitive: convert a whole folder from one format to another, change bitrate or sample rate to hit a target, trim or split many clips at once, normalize volume, and keep or edit the ID3 tags and cover art instead of having them stripped. One person just wants to clip a batch of audio files without a full digital audio workstation; another wants a music score split cleanly. None of that needs the cloud — the files are already local, and the conversion is a mechanical transform.

The features that matter for batch audio work are unglamorous: preview before you commit, write outputs to a new destination rather than overwriting originals, and show clearly which files converted and which failed. Silent partial success — where half the batch quietly errors — is the worst outcome when you are processing a hundred files.

This is a concrete, common job: someone has a roughly 1GB video and needs it under about 300MB to share or upload, and the machine doing the work has only 8GB of RAM. That memory constraint quietly rules out half the options.

Browser-based compressors are the worst fit here. A tab is already a memory-hungry environment, and feeding it a gigabyte of video to transcode in-page tends to end in a crash or a silent failure two-thirds of the way through. Some services dodge that by uploading the file to a server — which trades the memory problem for an upload-time-and-privacy problem, and those uploads are slow and unwelcome for private footage.

The part people underestimate is the quality tradeoff. Going from 1GB to 300MB is roughly a 3-to-1 cut, and that has to come from somewhere — usually the bitrate. A native encoder lets you steer it: pick a constant-quality target instead of a fixed output size, hold resolution where it matters, and let the bitrate float. On a constrained machine, a local tool that streams the file through the encoder a chunk at a time will finish a job an in-browser transcoder cannot even start. And when the same 3:1 pass has to run across a folder of clips, batching it beats compressing one file at a time.

One user received split Android/Snapchat evidence videos where most files play audio but have no visible video track, and needed to know whether the video stream was missing, corrupted, or just unplayable in their player. That is a diagnosis problem before it is a repair problem, and it is easy to get wrong by guessing.

The first move is to inspect the container: list the streams a file actually contains and their codecs. If there is no video stream at all, no repair will conjure one back — but if the stream exists and is simply not decoding in a given player, re-encoding or remuxing the file into a standard format often makes it playable again. The same toolkit covers the adjacent "make this watchable" jobs that show up in these threads: cleaning up a frame rate after a glitchy capture (for example VHS digitizing that stuttered because it was written to a larger drive), and re-encoding shaky or off-color event footage into a usable copy.

Two constraints make this a local job specifically. First, the files are often huge — raw footage, long captures — so uploading them anywhere is impractical. Second, they are frequently sensitive: evidence files, family video, personal archives that are irreplaceable. The safe default is to inspect and re-encode on the machine where the file already lives, keeping the original untouched so a failed attempt costs nothing.

Some conversions look trivial and are not, because the target has hard requirements. One user needed offline batch MP4-to-GIF conversion. Another was building a custom toolbar and needed an icon in a specific format — say a BMP at an exact pixel size and color depth — and the widget kept rejecting "close enough" exports as too big or too small. A third needed a 300KB PDF to become exactly 150KB to clear an upload limit.

Casual web converters fall down here because they optimize for the common case and quietly re-encode with their own assumptions about color depth, compression, and metadata. For a 16x16 BMP that a legacy widget parses byte by byte, those helpful assumptions are exactly what break the import. The same is true for GIFs, where frame rate and palette choices decide whether the output is usable, and for any job where the output has to hit a precise number.

What these jobs need is deterministic control: set the exact dimensions, lock the pixel format and bit depth, decide on purpose whether to strip or preserve metadata, and write the format the target actually expects rather than a modern reinterpretation of it. When the requirement is exact, you want a tool that does exactly what you specify and nothing helpful on the side — and if the same conversion has to run across many files, it should batch without changing the result file to file.

A recurring media-to-text job: someone is capturing scanned forms, screenshots, or photographed documents and running OCR to pull the text out — sometimes to make a searchable PDF, sometimes as the first step in a larger archive workflow. In one thread the stakes were explicit: could the result be externally audited? Does the captured file carry trustworthy metadata, and can a third party verify when and how it was produced rather than taking the extracted text on faith?

That question reframes OCR from a convenience into a chain-of-custody problem. A web OCR service hands you back text, but you usually cannot see what it did to the source, what it logged, or whether the file's original metadata survived the round trip. If the whole point is that an outside party can audit the document, routing it through an opaque server is the wrong move. Local OCR keeps the source file, the recognition step, and the exported output on one machine where you can inspect each stage and decide whether timestamps and metadata are preserved or stripped.

This is also the backbone of a proper digitization workflow, which is more than "run OCR once." A sane bound-book or archive process preserves raw and cropped page images, a searchable PDF, the OCR text, metadata, checksums, and missing-page logs in a durable folder structure. Offline OCR has gotten accurate enough that staying local no longer means accepting worse results.

It helps to know why web tools fail in these specific ways, because the reasons are structural rather than a matter of finding a better website. Developers who have tried to build serious in-browser file utilities hit the same wall, and it pushes the heavy work back to native code.

The usual approach is ffmpeg.wasm — FFmpeg compiled to WebAssembly so audio and video processing can run in the page. It works in a demo and then collides with the browser's security model. To run efficiently it needs threads, and threads need SharedArrayBuffer, which browsers only enable when the page is served with strict cross-origin isolation headers (COOP and COEP). Get that setup slightly wrong and the whole pipeline refuses to start. Even when it does start, a WASM heap is bounded, so a large video pushes it straight into an out-of-memory crash — the same failure the 1GB compression job hits, now from the developer's side of the glass.

Native processing has none of those limits: direct access to system memory, real multithreading, mature codec libraries, and the filesystem. That is why the hardest jobs end up there. Browser tools genuinely earn their place for small, casual, one-off files — there is no reason to abandon them for that. The line to watch is simple: when the file is large, when the format has to be exact, or when the job has to be repeatable and private, the sandbox stops being a convenience and becomes the constraint.

A lot of media work is not one big task; it is a pile of small "in-between" file chores that end up scattered across too many apps. One recurring description (from a builder, iordv) is a local file tray for the everyday actions: move, convert, compress, zip and unzip, rename, screenshot, transcribe, and share — each currently handled by a different utility. That sprawl is not just annoying; it makes a workflow harder to repeat and harder to trust, because every hand-off is another chance to upload the wrong file or lose track of which copy is current.

The mental model that works is file-first, like a toolbox rather than a grand suite: open the file, preview, choose the operation, run it locally, verify the output. That same shape fits audio conversion, video compression, image conversion, OCR, and the maintenance chores around a growing archive — comparing and syncing folders, removing duplicate files, or searching subtitles across a media library.

For anything run across many files, the make-or-break feature is reviewable batch work. A good batch flow makes it obvious which files were accepted, which were skipped, where outputs will land, and whether the originals were preserved. Speed is nice; not silently corrupting a folder of irreplaceable material is the point. One local workbench that keeps these adjacent operations close means you finish the job without building a temporary toolchain each time.

For most short clips, the actual editing is small and mechanical: cut the dead air at the front, drop the file size under the platform's cap, burn the captions into the frame, maybe pull the audio out for a separate track. The subscription editors bundle a whole studio — recording, transcription, effects — and a monthly bill around a job that, for a lot of creators, is three quick operations. They also tend to route the file through their cloud to process or transcribe it, which matters more than people admit: a product demo often contains a staging URL, a customer name, or an internal dashboard you didn't mean to hand to a third party.

Separate the recorder from the chores. The recorder and any automatic-transcript editing are one thing; trimming, captioning, resizing, and compressing the finished file are another, and that second half needs no server and no subscription. On captions specifically, decide whether you want them burned into the video (one file, plays everywhere, no toggle) or as a sidecar subtitle track — for social clips that autoplay muted, burned-in usually wins.

The honest limit: a local file tool won't record your screen or auto-generate a transcript for you. What it does well is the deterministic post-record work — the cut, the caption burn, the compress-to-fit — done on your own machine, fast, and repeatable across every clip in a batch.

MKV-to-MP4 trips people up because the two are containers, not video formats. An MKV file is a box; inside it sits a video stream, one or more audio streams, and sometimes subtitles. MP4 is a different box with a stricter guest list. When a converter fails, or produces a file that plays sound but shows no picture, it is almost always because a stream inside the MKV — HEVC video, an audio codec like FLAC or TrueHD, or an image-based subtitle — is not something MP4 accepts as-is.

That distinction tells you which of two very different jobs you actually need. If the streams are already MP4-friendly (most commonly H.264 video with AAC audio), the file only needs to be remuxed — repackaged into the new container. That is nearly instant and lossless, because nothing is re-encoded. If a stream is incompatible, it has to be re-encoded, which is slower and does cost a little quality, but is unavoidable.

The reason the web results confuse you is that most online converters hide this decision, re-encode everything by default (slow, and a needless quality hit), and choke on the multi-gigabyte files MKV usually holds — a two-hour rip can be 8 to 15 GB, well past any upload limit. Doing it locally sidesteps the size wall entirely and lets you look inside the file first, so you remux when you can and only re-encode when you must.

Compression and metadata live in different parts of a video file, and most transcoders only care about one of them. When you re-encode a clip, the tool rebuilds the audio and video streams into a fresh container and, unless told otherwise, writes that container clean — dropping the sidecar information that was never part of the picture: the original creation timestamp, the recording-device tags, GPS, track titles, and app-specific fields. The pixels survive; the context does not. That is why a gallery or instant-replay app that groups clips by capture date suddenly stacks everything on the day you compressed them, or stops recognizing the files at all. Nothing is corrupted — the sort key those apps depended on simply is not in the file anymore.

Two things are worth separating. The container timestamp — the "media created" date apps read — is the one that usually breaks, and it is distinct from the filesystem's modified date, which your OS rewrites on almost any save. Some libraries also key off metadata they treat as a compatibility signal, so losing a field can make a perfectly playable file look broken to the app even though it opens fine everywhere else.

The durable habit is to treat the source as the record of truth and verify before you delete it. Keep the original until you have confirmed the compressed copy actually carries the fields you rely on: open both and compare the metadata rather than assuming a smaller file was a harmless trade. If a field you need did not survive, you still have the original to read it from, and you can decide whether the space saved is worth the loss before you commit to throwing the source away.

Every convenient path from an iPhone to a Windows machine has a quiet opinion about your file. Messaging apps recompress aggressively — WhatsApp and Telegram will turn 4K footage into something you wouldn't grade. iCloud's "Optimize Storage" can mean the full-quality original isn't even on the phone anymore, so what transfers is a fetch that's slow or a proxy that's small. Cables should be the honest path, but Windows driver flakiness plus Apple's HEVC transcode-on-transfer setting means even that route sometimes hands you a converted file. The result people describe — "the quality got destroyed somewhere" — is usually three small silent transcodes stacked on top of each other.

Two rules cut through it. First, know what the original actually is: modern iPhone video is HEVC (H.265), often HDR/Dolby Vision, which also explains the other classic symptom — a file that arrives intact but "won't play" or looks washed out on Windows. That's a codec and HDR-handling gap on the receiving end, not a broken file. Set the iPhone to transfer originals ("Keep Originals" rather than "Automatic") so nothing converts in flight.

Second, move bytes, not renders: a local-network transfer or a direct copy that treats the video as a file — not as media to be helpfully re-encoded — preserves everything, has no upload cap, and doesn't route your footage through anyone's server. Then, if your editor wants H.264, do that as one deliberate local conversion on the PC, keeping the original. One intentional transcode you chose always beats three accidental ones you didn't.

Not any more. Speech recognition that runs on a laptop is now good enough for daily work, and for an accessibility tool used every day the difference between local and hosted is not a preference — it's whether the capability keeps working when the network, the subscription, or the vendor doesn't.

What to look for:

• It takes files, not just a microphone. Recordings, meetings, lecture video, voice memos. If the tool only listens live, half the job is missing.
• The model is named and swappable. Accuracy varies enormously by model size and language; you want to know which is running and be able to trade speed for accuracy.
• Output formats you can use. Plain text for reading, timestamped segments for editing, subtitle files for video. Being locked to one format means re-transcribing later.
• A correction dictionary. Names, jargon, and acronyms are where every engine fails, and where a personal word list gives the biggest accuracy jump for the least effort.
• Searchable local history. Transcripts are only useful if you can find them again; a folder of undated .txt files recreates the original problem.
• No account. An accessibility utility shouldn't stop working because a card expired.

For video, extract the audio track first and transcribe that — smaller, faster, and it lets you keep the video untouched.

Watching is the bottleneck, so the whole strategy is to make the decision from something faster than playback.

• Generate a contact sheet per file. A grid of frames sampled across the video tells you what it is in about two seconds. For most culling decisions that's all you need, and it turns hours of scrubbing into an afternoon of glancing.
• Sample, don't stream. A frame every N seconds is cheap; decoding whole files is not.
• Tag in a sidecar, not in the filename. A small file next to each video holds your categories without a mass-rename you can't undo. Filenames break; sidecars survive re-encoding and moves.
• Use three buckets, not two. Keep / delete / unsure. The unsure pile is what stops you deleting something irreversibly at 11pm — review it separately when you're fresh.
• Stage deletions. Move to a holding folder, live with it for a week, then delete. The regret window on video is longer than you think.
• Do the cheap wins first. Exact duplicates and zero-byte or truncated files can go before any judgment is required, and they're often a surprising share of the total.
• Record what you decided. A manifest of what was removed and why makes the next pass faster and stops you re-reviewing the same files.

Everything here is local by necessity — nobody is uploading 400GB to sort it, and for personal libraries you wouldn't want to.

The hard part isn't the syncing, it's the pairing — and it's worth being honest that no local utility fully automates the identification the way a dedicated fingerprinting tool once did. What you can do is narrow the problem until the matching is mechanical rather than a listening marathon.

Work it in two stages:

• Narrow the pairs before you sync anything. File timestamps, creation times, and clip duration eliminate most of the guessing — a 3-minute recorder file can only match a video of similar length recorded in the same window. Cameras record a low-quality scratch track too; playing just the first few seconds of each against your recorder audio confirms a pair far faster than watching whole clips.
• Align on a shared transient. Once you know a pair, a clap, a slate, or any sharp sound gives both tracks a common spike to line up on. That's the same principle the automated tools used; you're supplying the pair, they supplied the search.
• Then attach and export. With the pair known and the offset found, replacing the camera's scratch audio with the clean recorder track is a straightforward local operation — no timeline suite required.

You won't get one button that does all of it offline, but you can turn "listen to everything" into "confirm a handful of candidates," which is the part that actually eats your day.

Every social platform re-encodes what you upload — you cannot stop that. What you can do is hand their encoder a file that survives the second pass instead of one that falls apart under it. Most visible quality loss isn't the platform being cruel; it's your export giving their compressor a hard starting point.

Encode for the recompression, not against it:

• Upload at the platform's target resolution and a generous bitrate. Feeding a 4K master to a service that outputs 1080p means their encoder does the downscale — badly, and once, with no care for your grade. Down-scaling yourself, cleanly, gives the re-encode less to mangle.
• Match frame rate and colour to the destination. A frame-rate mismatch forces the platform to resample motion; getting it right removes a whole category of judder and smearing.
• Give the compressor headroom. A slightly higher-bitrate, clean upload compresses better than an already-crushed file — compressing twice compounds the artifacts. The goal is a pristine source at the right dimensions, not the smallest possible file.
• Compare source and export before uploading. Checking the encoded result against your master locally tells you what you're handing over, so the platform's pass is the only quality you lose.

You're not beating their compression; you're making it start from a clean, correctly-sized file so the one re-encode it does is the only one that hurts.

Searchable means an index, and the index comes from three separate extractions that each answer a different question.

• Speech becomes a timestamped transcript. This is the bulk of your searchable text. Run it per file and keep the timestamped segment format (SRT/VTT or JSON) rather than flattened prose — the timestamps are what make a hit navigable instead of merely findable. For non-English audio, pick a model by language rather than by benchmark average, and plan to spot-check: proper nouns are exactly what you're searching for and exactly where transcription is weakest.
• On-screen text becomes OCR of sampled frames. Lower thirds, captions, and titles carry names and affiliations that the speech never states. You don't OCR every frame — sample at an interval, or detect frames where the lower-third region changes, and OCR those. This is usually where "which school was that person from" actually lives.
• File-level metadata becomes a sidecar per video. Year, episode number, source, and whatever else you can infer. Keep it beside the file rather than in the filename, so it survives renames and re-encodes.

Then the part that makes it an archive instead of a pile of transcripts: normalize everything into one record per episode — path, duration, transcript segments, OCR hits, metadata — and index that. A search returns an episode plus an offset, and the offset is what turns a result into a link you can jump to.

Two practical warnings. Run it as a resumable batch with per-file state, because a job this size will fail partway and you don't want to redo the finished half. And decide name-matching rules deliberately: fuzzy matching on transcribed names produces confident wrong associations, so keep the entity matches in a reviewable list rather than baking them into the index.

A mixed-folder viewer has to solve two separate problems. It needs one navigation layer that treats images and videos as neighboring files, and it needs decoders for every codec stored inside those containers. Supporting the MP4 filename does not guarantee support for the video stream inside it. That is why a clip can show a black frame and still play audio: the container opened and the audio decoded, while the video codec or hardware-decoding path did not.

First test the affected clip in another player. If it works there, the file is probably intact and the original viewer has a decoder or GPU-acceleration problem. Inspect the video stream's codec, resolution, and duration rather than guessing from the extension. If the stream exists but your preferred viewer cannot decode it, convert a copy to a broadly supported format and keep the original untouched. If no video stream is present, conversion cannot reconstruct one.

For the browsing job itself, look for explicit mixed-media folder navigation, keyboard next/previous controls, support for the formats you actually keep, and a visible error when a file is unsupported. A viewer that silently shows black is worse than one that names the missing codec. It should also open folders in place rather than forcing an import, and it should never rewrite originals merely to preview them.

Treat viewing and repair as separate layers: browse everything that already works, diagnose exceptions, and normalize only the copies that need compatibility.

No, and it's worth understanding why every tool offering it is heavier than the job. Resume tracking itself is trivial. The products that provide it bundle it with a library database, metadata scraping, transcoding, and a client-server architecture — because they're built to stream to other devices. You want none of that. You want a bookmark.

The three pieces actually required:

• Parse show, season, and episode from the path. Breaking Bad/Season 03/S03E07.mkv is already structured, and the SxxExx convention is near-universal. Matching it needs no online lookup unless you want artwork, which you didn't ask for.
• Store the position beside the files, not inside an application database. A small sidecar per file, or one index at the library root. The advantage over a server's internal database is that it survives moving the library, reinstalling, and the app itself being abandoned — which for a niche utility is the realistic ten-year risk.
• Hand off to your player and read the position back. Most desktop players already expose playback position, and many remember it per file. The piece that's usually missing isn't the position — it's the list across the library.

Worth checking before installing anything: your player may already do most of this. Several remember per-file position by default and keep a recently-played list, which would leave you needing only the continue-watching view rather than the whole stack.

The general shape recurs across local media: the filenames already encode the structure, so the useful tool reads what's there and writes small portable sidecars — rather than importing everything into a library you then have to maintain forever.