Contact Video Subtitle Remover

How to reach us

The project is in its public beta phase, and we have deliberately kept the contact surface small and honest. During beta, the fastest channel to a human is the project's public issue tracker — bug reports and feature requests filed there are triaged continuously, and everything about the discussion stays visible to other users who may have hit the same problem. A dedicated support inbox opens alongside the online processing queue; until then, this page explains exactly what to send where, so your first message is also your fastest answer.

We do not hide a contact form behind an account wall. There is no sign-up, no ticket robot and no phone queue — you write once, with the details that matter, and a person reads it.

Bug reports: what to include

A good bug report gets fixed in days; a vague one gets questions back. When a removal job misbehaves, include these seven things:

1. The page or app you used — which of the fourteen tool pages, or the Windows app version number from the about dialog.
2. Your system — Windows version, GPU model (or CPU-only), and RAM if the job crashed.
3. The file, described — container (MP4, MOV, WebM), approximate duration, resolution and codec if you know them. Do not attach the video itself to a public report.
4. The route it took — track stripping or region repair, and whether you drew the mask yourself or accepted the auto-detected one.
5. What you expected, what happened — one sentence each. "Ghost outline of the second subtitle line survived the export" is instantly actionable.
6. A screenshot of the before/after preview — this alone resolves half of all reports.
7. The error text, if any — copy it verbatim; error codes are searchable, paraphrases are not.

For privacy reasons we will never ask you to post source footage publicly. If a reproduction needs the exact file, we will provide a private, expiring upload link.

Feature requests

We read every request, and the ones that match the project's contract get built first. The contract, for reference: you confirm the region, the engine repairs the pixels, your audio survives untouched. Requests that strengthen that core — better masks, more codecs, faster GPU paths, more languages in the detector — go to the top of the list. Requests that widen the product into a general video editor are politely declined, because focus is the feature that makes everything else reliable.

When you file a request, tell us the job you were trying to finish, not only the feature name. "I need to clean a bilingual fansub where the two lines change position every scene" teaches us more than "add multi-mask" — and sometimes the workflow already exists.

Business and licensing inquiries

Partnership, bulk processing, licensing and press inquiries are welcome through the same public channel during beta, marked clearly in the title. Include your organization, what you intend to build or distribute, and the volumes involved. We answer commercial mail in English; the rest of the site's languages are supported for product questions.

One boundary is fixed: we do not process DRM-protected material, and we do not build removal workflows whose evident purpose is stripping rights holders' marks from third-party content. Inquiries of that kind receive a short refusal, not a quote.

Privacy questions and data requests

If your question concerns your own data — an upload you want deleted sooner than the 24-hour automatic window, or a privacy-policy question — say so in the title and include the job timestamp shown on the result page. No account exists anywhere in the service, so the timestamp is the identifier that lets us find the record.

The rules being applied are the ones published in the privacy policy: uploads and results auto-delete within 24 hours, nothing is used for training, and the Windows app never uploads anything at all. If you believe the practice differs from the policy anywhere, that is a report we treat with the highest priority.

Accessibility feedback

The interactive mask editor, the before/after sliders and the FAQ accordions are built to be operable with a keyboard and readable by screen readers, and we know imperfect when we see it in a report. If a control traps focus, a contrast pair fails, or a label reads wrong in your language of the six we ship, tell us — accessibility reports are triaged as bugs, not suggestions.

Before you write: the two-minute checklist

Half of all support questions are answered by a page on this site. Before writing, check:

• "Is the online tool live yet?" — It opens with the public beta; the free-online page states the current status in its first screen.
• "Why was my file rejected?" — Duration over 60 seconds, resolution over 720p, size over 100 MB online, or an unsupported/protected codec. The probe reports the exact reason before upload.
• "Does it keep my audio?" — Always, on both routes; this is the project's core promise.
• "Can it remove objects/people?" — No; it removes text overlays. The limits section of every tool page lists this.
• "Is the Windows app free?" — Yes, during the beta, with no length cap; the Windows page carries requirements and release status.

What to expect after you write

Bug reports are triaged within two business days; fixes ship in versioned releases with the changelog published on the Windows page. Feature requests get an acknowledgment and a label — accepted, under consideration, or declined-with-reason. Privacy and data requests are handled within the statutory windows and usually much faster. 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 changelog entry will carry it. Reading the changelog is also part of contacting us — it is where most conversations end.