Sample rates, mono audio and transcription memory

Understand what a sample rate describes

Digital audio represents a signal through a sequence of sampled values. The sample rate expresses how often those values occur. It is different from the compressed bitrate printed beside a delivery file. A recording can have the same sample rate as another while using a different codec, channel count and storage size.

A speech model is designed around a particular input representation. MurmurScribe decodes the source recording and resamples it to the rate expected by Whisper. That step happens locally before the worker runs inference. The number is a processing requirement, not a claim that every source should have been recorded that way.

Resampling cannot recreate the source

Resampling changes the sequence of samples used to represent existing audio. It can make data compatible with the model, but it cannot reconstruct speech that was never captured clearly. Increasing the output sample rate does not add missing consonants, remove clipping or separate speakers who talked over one another.

For an archive or production master, retain the original recording. Make a processing copy when a tool needs another representation. That preserves your ability to use a different workflow later and avoids confusing an intermediate file with the source. The most useful preparation is often simply choosing the correct complete recording.

Mono input is a deliberate tradeoff

The app prepares a mono signal for Whisper. When a source contains several channels, the browser’s audio graph mixes them down for this path. This is suitable for a general transcription draft, but it does not preserve separate microphone tracks for speaker analysis.

If a recording places different participants on different channels, those channels may be valuable in a specialist workflow. Keep the originals and do not assume a mono transcript identifies who said each line. MurmurScribe provides manual speaker labels. It does not infer identity from the mix or offer automatic diarization.

Compressed size is not decoded size

A compressed file stores an efficient representation of audio. After decoding, the browser holds sample arrays. Their memory requirements depend on duration, channel count and the sample representation. The model then adds its own weights and intermediate state. This is why a small uploaded-looking file can still be demanding to process locally.

The calculation in the worked example only describes a mono floating-point sample buffer. It is not the total browser memory requirement. The browser may temporarily hold the original bytes, decoded channels and resampled data at the same time. Other tabs and the operating system also use memory. Do not treat a single buffer estimate as a safe maximum file duration.

Use short tests to isolate the problem

If the file fails before model loading, investigate decoding and source compatibility first. If it decodes but the worker stops during model loading, try the smaller model or CPU path. If a long recording fails while a short excerpt works, resource demand may be the practical limitation.

Keep the test representative. A short passage that uses the same codec and contains the same microphone conditions helps isolate the file and model choices. It does not prove the entire long recording will fit into memory, but it prevents a costly model download from being mistaken for a repair to an unsupported file.

The app imposes no product minutes quota. That is not a promise of unbounded device capacity. A browser can terminate a heavy tab even when the interface has no duration counter or subscription limit.

Record for intelligibility before specifications

For new recordings, make a brief test and listen with headphones. Check that the intended speaker is clear, the signal is not distorted and background sounds do not mask words. Keep microphone position consistent when practical. A useful source recording matters more to transcription than increasing a number in an export dialog.

Avoid applying aggressive processing without comparing it to the original. Noise reduction or gating can remove parts of quiet speech. If an edit makes the recording sound cleaner but drops syllables, it can make transcription harder. Keep a copy of the original and listen to difficult sections before choosing the processing version.

After transcription, verify the result against the same audio. A model may produce plausible language over a damaged passage. Technical compatibility gets the recording into the model; human review determines whether the text reflects what was said.

Worked example

For an illustrative 10-minute mono sample buffer at 16,000 samples per second, there are 10 × 60 × 16,000 = 9,600,000 samples. A Float32Array uses 4 bytes per sample, so that buffer alone represents 38,400,000 bytes, or 38.4 decimal MB. The arithmetic describes this implementation’s sample array, not total memory. Add source-file bytes, decoding allocations, model weights and runtime state before thinking about the whole process. A compressed recording with a smaller file size can therefore require considerably more working memory than its stored size suggests.

Open the local transcriber to test an authorized recording and review the draft against the sound.

Keep storage, processing and delivery calculations separate

A storage estimate answers how much space an encoded file may occupy. A decoded-buffer calculation answers how many sample values a processing step holds. A model download total answers which weight files must be retrieved. These are related costs, but adding or comparing them without their units can produce a misleading device requirement.

When documenting a workflow, label every quantity. Use bytes or decimal megabytes for file totals, samples per second for sample rate, and channels for the signal arrangement. If you use a floating-point buffer estimate, say that it describes a particular representation in memory. Do not call it the size of the original MP3 or the total footprint of the browser tab.

The distinction is useful when a recording succeeds on one machine but fails on another. The same source file may be small enough to download everywhere while its decoded form and model state exceed a particular device’s available memory. A change of compressed bitrate can reduce transfer size without proportionally reducing the sample buffer used after decoding.

For a long archive, plan the review and storage workflow before running every file. Preserve originals in the approved location, process copies the device can handle, and export reviewed results with clear source identifiers. Do not rely on browser storage as the only copy of an important collection. Local processing provides control over the audio path, but the person operating it still has to manage capacity, versions and retention deliberately.