Transcription and dubbing

Transcription and dubbing are separate Voice workflows with different inputs and outputs. The transcription route exists and is described as OpenAI-powered, but its endpoint schema, diarization contract, timestamp format, supported languages, batch behavior, and exports remain unverified. Dubbing is an earlier preview whose translation, speaker alignment, voice preservation, provider support, and downloadable formats remain unverified.

Transcription

Transcription converts submitted audio into text. Open /voice/transcribe to inspect the current workbench and its accepted-input guidance. Because the corresponding route handler was not part of the directly verified files, document the surface conservatively and do not infer that it uses the speech-generation request contract.

The Voice hub mentions concepts such as diarization, timestamps, and batch processing. Those labels are not enough to promise stable behavior. Visible options and results need endpoint-specific verification before they become public contract language.

Start with a short recording that you have permission to process. Clear audio reduces the number of variables involved in a first test. Review the returned text against the original audio and mark uncertainty manually. No verified confidence score replaces human review of transcription or dubbing results.

Do not promise speaker identification, word-level timing, language detection, punctuation quality, or a particular export format. Those details should be added only after the transcription handler and output schema are audited.

Transcription turns audio into text through a visible workbench whose exact backend contract still requires inspection. Transcription converts submitted audio into text, whereas dubbing would produce an alternate-language or alternate-voice media rendition. The transcription surface exists at /voice/transcribe, but its request handler was not included in the directly verified file set. The Voice hub mentions diarization, timestamps, and batch processing; those labels are not enough to document stable runtime behavior.

Transcription converts submitted audio into text, whereas dubbing would produce an alternate-language or alternate-voice media rendition; for transcription, open the dedicated surface and verify its accepted input instructions in the current UI. Dubbing is linked as a preview surface and has no verified generation contract in the supplied repository bundle; review the returned text without assuming speaker labels, word timing, or export support. Do not infer diarization, timestamps, voice cloning, language coverage, or quality guarantees from marketing-level card text.

Dubbing

Dubbing creates a translated or alternate-voice rendition of media; it is not another name for transcription. The /voice/dub route is approved as a product link, but its runtime remains preview. Live translation, speaker alignment, voice preservation, cloning, provider availability, and downloadable rendered media are not verified.

A dubbing workflow would normally involve source media, language choices, speaker handling, generated speech, timing, and final rendering. This documentation cannot turn that general shape into an Ethen procedure without direct implementation evidence. Use the preview to understand product intent and current availability labels.

Do not upload sensitive or copyrighted material merely to test a visible card. Confirm permission to process the source and review the consent boundary when a real person’s voice is represented. A consent declaration is user-provided and does not itself enable a dubbing provider or cloning model.

If the surface is marked setup-required, coming soon, or preview-only, stop at configuration review. Do not describe a successful rendered output unless the current product actually returns one.

Dubbing is a preview concept for alternate-language or alternate-voice media, not a verified production renderer. Dubbing is linked as a preview surface and has no verified generation contract in the supplied repository bundle. No approved source lists supported languages, accepted media formats, file-size ceilings, speaker-count limits, or export types. Provider setup can prevent processing even when the navigation route is present.

Voice hub mentions diarization, timestamps, and batch processing; those labels are not enough to document stable runtime behavior, as shown by the current implementation; use a short, clear sample before submitting long or sensitive recordings. Provider setup can prevent processing even when the navigation route is present; for dubbing, treat the route as product preview and do not promise a finished translation or downloadable rendition. The page remains a workflow and availability guide until endpoint-specific source files establish exact inputs and outputs.

Inputs

Accepted transcription and dubbing inputs are not defined as a stable public list. File type, size, duration, channel count, sample rate, language, speaker count, and batch limits remain unverified. Use the current UI instructions for the build being tested rather than publishing invented values.

For a cautious first attempt:

• choose a short source with clear speech;
• remove unrelated or sensitive content;
• confirm that you have the right to process the audio;
• note the provider and setup state shown by the surface;
• keep an original copy for comparison;
• avoid assuming that the route supports video, multiple tracks, or large batches.

A file accepted by the interface is not proof that every provider can process it. Provider configuration and runtime support remain separate. If the surface rejects the file, record the actual message instead of converting it into a permanent public limit.

Accepted media, size, duration, channel, and language constraints are not established by the supplied handler set. Quality depends on source audio, provider behavior, language handling, and processing settings that are not fully exposed by the inspected evidence. Review the returned text without assuming speaker labels, word timing, or export support. For dubbing, treat the route as product preview and do not promise a finished translation or downloadable rendition.

Supported languages, accepted media formats, file-size ceilings, speaker-count limits, and export types are not listed by an approved source; review the returned text without assuming speaker labels, word timing, or export support. Transcription converts submitted audio into text, whereas dubbing would produce an alternate-language or alternate-voice media rendition; avoid uploading content unless you have the right to process it and understand the applicable privacy boundary.

Outputs

Transcription output should be described only as the text and metadata actually returned by the current surface. Speaker labels, word-level timing, confidence scores, translation, and downloadable transcript formats are not verified in the current transcription implementation. Review the text against the recording, especially for names, numbers, specialized terms, and sections with overlapping or unclear speech.

A dubbing result would be a new media rendition rather than a transcript. Because the dubbing runtime is not verified, the documentation cannot promise translated audio, preserved speaker identity, timing alignment, voice matching, or an export file. A visible dubbing route is therefore an availability signal, not proof that a production rendition can be generated.

Transcription output should be described as the text returned by the current surface. The audited evidence does not establish diarized speakers, word timestamps, segment confidence, language metadata, subtitles, or export packages. If those elements appear in a build, verify them against the handler and schema before documenting them as supported.

Dubbing output is even less defined. Do not claim translated audio, preserved identity, aligned speakers, retained background sound, downloadable video, or a specific container. The route’s preview status is not evidence of a completed renderer.

Review any output against the source. A plausible transcript or rendition is not automatically accurate, authorized, or suitable for publication.

The current evidence does not define stable transcript metadata or rendered dubbing formats. Avoid uploading content unless you have the right to process it and understand the applicable privacy boundary. For transcription, open the dedicated surface and verify its accepted input instructions in the current UI.

Quality depends on source audio, provider behavior, language handling, and processing settings that are not fully exposed by the inspected evidence; for dubbing, treat the route as product preview and do not promise a finished translation or downloadable rendition. The Voice hub mentions diarization, timestamps, and batch processing; those labels are not enough to document stable runtime behavior; for transcription, open the dedicated surface and verify its accepted input instructions in the current UI.

Quality considerations

Audio quality affects transcription and any future dubbing path. Background noise, overlapping speakers, clipping, accents, microphone distance, source compression, and room acoustics can change results. No approved accuracy benchmark or supported-quality guarantee is published; quality remains environment and provider dependent.

For transcription, compare names, numbers, technical terms, and important statements manually. For dubbing, a future review would also need to consider translation fidelity, timing, speaker identity, pronunciation, and whether the result creates misleading speech. None of those review dimensions should be represented as automatically solved.

Provider setup can affect quality indirectly. A preview may use a different route than expected, or no provider may be configured at all. Keep provider attribution and fallback disclosure with the result when the surface exposes them.

Do not use generic quality claims such as production-grade, studio-quality, or human-level unless an approved source establishes the claim and the conditions under which it applies.

Result quality varies with the input media and provider behavior; the current implementation does not quantify those effects. Use a short, clear sample before submitting long or sensitive recordings.

Troubleshooting

Begin by identifying the workflow. A transcription failure is not a dubbing failure, and speech generation diagnostics do not automatically apply to either route.

For transcription:

1. Confirm the surface accepts the source.
2. Check provider setup and the visible error.
3. Try a shorter, clearer, authorized recording.
4. Review whether the result is partial, empty, or unavailable.
5. Avoid assuming undocumented language or speaker support.

For dubbing, confirm whether the route is only a preview or whether an actual processing control is enabled. If the runtime is not verified, do not invent recovery steps. Record the current state and the missing provider or capability instead.

When reporting a problem, include the route, provider state, safe source characteristics, and exact error without attaching unnecessary personal audio. Fixed retention, deletion, and provider-side handling are not approved, so troubleshooting should minimize copied media and transcripts.

Diagnosis should begin by identifying which workflow, provider state, and input stage failed.