Your dub came back wrong. Work out why
A diagnostic path from "it never started" to "it finished and it is wrong", with what happens to your credits and which failures get your money back.
Tätä artikkelia ei ole vielä käännetty, ja se näytetään englanniksi.
Start with which kind of wrong you have, because the four kinds have almost nothing in common.
The upload was rejected. The job failed after you confirmed it. The job is still processing and you're staring at it. Or the job finished, produced a file, and the file isn't good. Only the last one costs you money you don't get back, and it's also the most common.
Work down from the top.
The upload was rejected before you paid
Nothing has been charged and nothing can be, because every check that can reject a file runs before a single credit is touched.
Four things get checked at upload:
Size. 2 GB maximum. Checked twice, once against the declared content length and again as the bytes arrive, so an understated header doesn't get around it.
Length. 180 minutes maximum.
Format. The file extension has to be one of 17: MP4, MOV, AVI, MKV, WebM, M4V, MPEG, MPG for video, and MP3, WAV, AAC, M4A, FLAC, AIFF, OGA, OGG, Opus for audio.
Readable duration. We read the duration out of the file itself, in memory. If that read fails, the upload is rejected rather than guessed at, because a guessed duration is a guessed price.
That last one is the confusing rejection, because the file plays fine locally. A container with a damaged or missing header can be perfectly playable in a media player that tolerates it and still be unreadable to a strict parser. Re-exporting from your editor usually fixes it. So does remuxing the file.
A rejected upload costs nothing. There's no cleanup and no refund needed, because no charge was ever made.
The job failed after you confirmed it
Your credits come back automatically. There's no ticket to file and no claim to make.
Confirming is the moment the charge lands and the moment the file goes to the dubbing service. If submission itself errors, the credits deducted a moment earlier are returned and the job is marked failed before anything else happens.
If the job is accepted and then fails at the dubbing service, the poller notices and refunds what was charged.
Common causes at this stage are properties of the audio rather than the file: no detectable speech, a source language the service can't identify, or content it can't process. If you uploaded a music video, a file with ambient noise and no dialogue, or something where speech is buried under a mix, this is where it surfaces.
The job is still processing
Check how long it's been, because there's a defined ceiling.
We poll the dubbing service every 10 seconds, and there's a hard stop at 6 hours. If a job hits that ceiling without producing a file, it's marked failed and the credits are refunded, same as any other failure. So "processing forever" isn't a state that exists: the longest a job can sit there is six hours, and then it resolves itself one way or the other.
Long files legitimately take a long time. A 90 minute video is not a two minute job, and the 6 hour ceiling exists to cover the extreme end rather than to describe normal behaviour.
One case people worry about that's already handled: a server restart mid-job. Polling threads don't survive a restart, but on startup we look for jobs still marked processing and re-launch a poller for each one that has a dubbing id. So a deploy or a reboot in the middle of your job doesn't strand it, and doesn't lose your credits.
The job finished and the output is wrong
This is the expensive category, because a job that ran and produced a file is not a failure by any measure the pipeline can apply. It ran. It made a file. You were charged, and nothing will refund it automatically.
Work out which kind of wrong:
It drifts out of sync toward the end. That's a length problem rather than a sync problem. A translated sentence rarely takes the same time to say as the original, and the difference accumulates. Why dubbed audio drifts out of sync explains the mechanism and the three things that actually help.
Lines are attributed to the wrong speaker, or crosstalk is garbled. Overlapping speech is the hardest input any dubbing pipeline gets. We don't pass a speaker count, so the model decides, and nothing is corrected by hand afterwards. Dubbing a video with more than one person talking covers what you can fix in the source and what you can't.
The voice sounds flat, or words are mangled. Usually the source rather than the model: reverb, music sharing the voice's frequency range, or aggressive pre-applied compression. What to fix in your audio before you dub it is the preparation checklist.
The whole thing is in an unexpected language. The source language is detected from the audio, never declared by you, so a file whose opening is in a different language from its body can be read the wrong way. Check the first thirty seconds of what you uploaded.
The uncomfortable truth about this category: dubbing runs automatically end to end and nothing is edited by hand afterwards, which our support page states directly. So a single bad line can't be fixed on request. Everything you control sits on the input side, before you spend the credits.
What this means for how you test
Run one file into one language before you commit a catalogue.
If it fails outright, that test cost you nothing, because failures refund. If it succeeds and the output is poor, it cost you a few credits and saved you the same mistake multiplied across six languages. Either way you learn something the pricing page can't tell you, which is how your specific content behaves.
Listen to the worst two minutes you can find, not the first two. The opening of a video is usually the cleanest audio in it.
When to write in
If a file came back broken rather than imperfect, that's worth reporting, and it's a different thing from a dub you're unhappy with. Broken means truncated, silent, corrupted, or in a language nobody asked for. Imperfect means the translation isn't how you'd have phrased it.
The support page has the address and the details worth including. There's no contact form, just an address that reaches a person.
Before you scale up
Once one file works, the arithmetic is straightforward: one job per file per language, rounded up to the whole minute, with credits that don't expire. The per-language guides cover the practical side: dubbing YouTube videos from English to Spanish is the most common starting point, dubbing e-learning from English to Hindi is a good example of a longer file, and the use case index has the rest.
FAQ
Why was my file rejected before I was charged?
One of four checks: over 2 GB, over 180 minutes, an extension outside the 17 accepted formats, or a duration we couldn't read out of the file. All four run before any credit is touched, so a rejection costs nothing. An unreadable duration on a file that plays locally usually means a damaged container header, which re-exporting fixes.
My dubbing job is stuck processing. What now?
It can't stay there indefinitely. The service is polled every 10 seconds and there's a hard stop at 6 hours, after which the job is marked failed and the credits are refunded automatically. Long files genuinely take a long time, so give it proportionate patience.
Do I get my credits back if a job fails?
Yes, automatically, for every failure path: a submission error, a failure at the dubbing service, and the six hour timeout. A server restart mid-job doesn't lose them either, because stuck jobs get a fresh poller on startup.
The dub finished but it's poor. Is that refunded?
No. A job that produced a file isn't a failure the pipeline can detect, so it charged and stays charged. That category is almost always traceable to source audio or to overlapping speakers, both of which are fixable before the next run rather than after this one.