Offline Audio Summary Pipeline on Android

Direct answer

An offline audio summary test should treat transcription and summarization as separate operations. The test first establishes what the audio decoder and recognizer produced, then asks whether a summarizer preserves required facts and marks omissions. `COVE-ASR-01` documents a project audio path that wraps PCM as WAV and sends audio with a transcription instruction through the shared engine; `COVE-ASR-02` describes sequential audio segments and visible placeholders for failed segments. These facts support preserving raw transcript and segment outcomes. They do not establish that a particular app already summarizes audio offline or that any generated summary is accurate. Define the user task precisely: summarize a selected audio file, summarize a new recording, or summarize an existing transcript. These paths have different permission, file-provider, recording-lifecycle, and resource requirements. Keep the source file or original transcript immutable. Record which transcript revision the summary used, whether it was complete, which segments failed, and whether the user corrected words before summary generation. A summary from a partial transcript should remain labeled partial or incomplete; it must not be silently presented as a faithful summary of the entire recording. Prepare fixed synthetic or consented audio fixtures with checked transcripts and required-fact expectations. Include a short file, a segmented long file, silence, an interruption, a proper name, a number, negation, and a segment whose transcript intentionally fails or is missing. Do not measure general summary quality from one pleasant sample. For each fixture, separately compare recognized text to its reference, then verify whether the summary preserves designated facts, speaker attribution if in scope, chronology, uncertainty, and action ownership. Do not invent a numeric quality score or claim universal offline operation. Document the pipeline configuration: app build, file URI/provider, media track and decoding path, sample format, segmentation policy, transcript version, model/runtime/prompt/schema where known, network state, and user review. For file input, Android's `MediaExtractor` API exposes track and sample extraction; the implementation still needs to handle provider access, format, and cleanup. For microphone capture, Android audio APIs and lifecycle rules are separate. Do not imply a pre-recorded file path uses the same permissions or capture route as live recording. Exercise partial and recovery cases deliberately. Cancel during decoding, after some transcript segments, while the summarizer is producing text, during result persistence, and before export. Verify that transcript segments remain individually attributable, summary generation receives a declared completeness state, and the UI never replaces the raw transcript with a summary. If the process is recreated, reload durable source and task identifiers; do not persist native handles as resumable state. A retry should create a new run or a clearly versioned revision so the user can compare outputs. Test the offline condition after setup. Record whether files, model assets, or decoder data must be prepared while connected; then disconnect and run a new fixture from a cold app state. Observe supported network requests and inspect dependency/call-site paths for clients that a network inspector may not see. Reconnect afterward and verify whether any queued upload or diagnostic route exists. An offline inference stage does not establish zero network use in setup, analytics, backups, or export. Report method and limits: exact app and artifact, fixture IDs, transcript references, required summary facts, segment failure policy, output-review protocol, connectivity state, and all runs. The conclusion can describe whether the tested pipeline produced a reviewable draft from the recorded transcript. It cannot establish summary accuracy in general, legal suitability of a meeting record, or that a named product provides this feature. This page focuses on transcript-to-summary separation, not participant consent or meeting-recording privacy practices.

A user summarizes a prerecorded clip after transcription

A user selects a short recording, which is decoded into sequential transcript segments before note export. One segment is missing after processing is interrupted, and the user requests a summary; the workflow must expose the gap rather than present a fluent draft as complete.

Decision

Preserve the source and transcript, mark completeness, and ensure the summary is labeled partial unless every required segment is available and reviewed.

Expected outcome

The test shows which source text supported the summary and whether the user could inspect, edit, or reject it before export.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Audio fixture and transcript
• Summary requirements
• Partial-failure behavior

Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.

Implementation workflow

1. Separate audio, transcript, and summary records. Give source file, decoder run, transcript revision, summary run, user edits, and export distinct identifiers. Preserve the original transcript rather than replacing it.
2. Prepare checked audio and transcript fixtures. Use synthetic or consented samples with names, numbers, negation, silence, interruption, long segmentation, and one intentionally missing or failed segment.
3. Declare transcript completeness before summarizing. Pass a complete/partial state and segment outcomes into the summary task. Test that missing segments remain visible and the output is not labeled a full-record summary.
4. Validate required facts and review actions. Compare the transcript to its reference, then check designated facts, chronology, attribution, and uncertainty in the summary. Let the user edit, reject, or keep a partial draft.
5. Test interruption, offline setup, and export. Cancel at decode, transcript, summary, save, and export boundaries; cold-start offline after required setup; inspect traffic and verify source/transcript are preserved.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• Every summary identifies its source file and transcript revision, with complete/partial status and segment failures preserved.
• A partial transcript cannot be silently represented as a complete summary, and the original transcript remains available for review.
• The report records setup dependencies, network observations, fixture method, and limits without claiming general summary accuracy or a product feature.

Decision table

Failure patterns to prevent

• Discarding raw transcript
• One giant unbounded recording

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Cove Travel voice translation
• Cove Voice transcription
• Android MediaExtractor reference
• Android audio capture overview
• Android WorkManager cancellation

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions