Contact Audio Trimmer

How to reach us

Audio Trimmer is a small project with a deliberately small contact surface. We do not publish a support email address during this phase; instead, the fastest channel to a human is the project's public issue tracker. Bug reports and feature requests filed there are triaged continuously, and every discussion stays visible to other users who hit the same problem — which means the answer you receive also helps the next person, and the answer you need may already be there.

This page explains exactly what to send where, so your first message is also your fastest answer.

Bug reports: what a good one contains

Most problems fall into three buckets, and each has a short checklist that turns a "it doesn't work" report into a fixable one:

• A file the tool refuses or mishandles. Tell us the container and codec if you know them (MP4, MOV, MKV; AAC, MP3, FLAC), the file size, the browser and its version, and what the tool said — the exact error text matters. If the file is shareable, a short clip with the same problem reproduces it better than a description ever could.
• A wrong-looking result. A trim that starts a beat late, an extraction that plays silence, a muted video with sound still in it: describe the input, the settings you chose (format, track, range), and what you expected versus what you got. Mention whether the preview played correctly before processing.
• The page itself. Broken layout, a translation that reads wrong, a download button that does nothing — include the page address, your language, and whether the browser console shows an error. Screenshots help; console text helps more.

One honest note: because processing happens in your browser, we usually cannot "check our logs" — there are no logs of your job, by design. Reproduction steps on your side are therefore gold.

Feature requests

Requests are welcome and cheap: a title, the job you are trying to do, and what you currently have to do instead. The roadmap is driven by the fourteen jobs this site already serves — trim, extract, mute, separate — so requests that deepen an existing page (more formats, more stems, better defaults) move faster than requests for entirely new product categories. Requests get a label — accepted, under consideration, or declined-with-reason — so nothing disappears silently.

Privacy questions

The privacy policy is short for a reason: the site uploads nothing and stores nothing about you or your files. If you believe the policy is inaccurate or a behaviour on the site contradicts it, the issue tracker is the place to say so; those reports are treated as bugs against the policy itself. Because we hold no personal data, there are no access, correction or deletion requests to fulfil — there is no data to access, correct or delete.

Accessibility

If any part of the site fights your assistive technology — keyboard traps, unlabelled controls, contrast that fails, players without accessible names — please file it with the page address and the behaviour you saw. The tools are keyboard-operable by design, and regressions there count as bugs, not suggestions.

Security

Found something that looks like a security issue? Report it in the tracker with reproduction details, marked clearly as security-related in the title so it can be handled with care. The attack surface is small — static pages, client-side processing, no user data — but small is not zero, and responsible reports are always welcome and credited. Reports about the recommended Windows application belong in that project's own tracker, where its maintainers can act on them directly.

What to expect after you write

Reports are triaged within a few business days; fixes ship in updates to the site and are described on the affected pages. We are a small team, so "fast" means days, not hours — but nothing sits unread. One request in return: when a fix or feature lands that you asked for, the change note will carry it, and reading the tracker back is also part of the conversation.

Why no email

An inbox grows a queue, and queues grow response-time promises a project this size should not make. A public tracker, by contrast, gives every question a searchable answer, every report a visible status, and every user the same information at the same time. If a contact channel beyond the tracker ever opens, this page will say so first — plainly, and before anything changes.

Before you write: the two-minute checklist

A surprising number of reports solve themselves with a quick pass over the basics, so it is worth sixty seconds before filing:

• Try a second browser. The browser tools depend on WebAssembly and your browser's audio decoder; a file that fails in one browser often works in another, and telling us "works in Chrome, fails in Safari" halves the investigation.
• Check the file size. Browser jobs cap at 100 MB by design; heavier files belong in the Windows application, which has no cap. The error message on the page says which case you hit.
• Confirm the file has audio. For extraction and mute tools, the page probes the container and reports when no audio track exists — a screen recording without sound is the classic case, and no tool can extract what was never recorded.
• Reproduce once more. A report that says "happens twice on reload" is worth five that say "happened once".
• Note your language. The site runs in six languages; a wrong translation or a layout that only breaks in French is fixable only if you tell us the page and the language you were reading.

If the checklist does not solve it, file the report with the details above — the tracker link is on every tool page — and you will get a human answer in days, in public, for everyone who comes after you.