Use this URL in any client supporting remote Streamable HTTP MCP. Calls return structured JSON; inputs are processed without persistence.
Call trim_wav_frames
Provide plain base64 PCM WAV and zero-based start_frame/end_frame. The start is included and the end is excluded; one frame contains one sample for each channel. Require 0 <= start_frame < end_frame <= input_frames; invalid ranges fail instead of being clamped. Sample bytes, rate, channel count and sample width are preserved. WAV container metadata is discarded and the container is rebuilt. Decode audio_base64 to save the actual .wav output. sha256 hashes the entire returned WAV; pcm_sha256 hashes only selected interleaved sample bytes. Supports mono/stereo integer PCM 8/16/24/32-bit, up to 524288 decoded upload bytes and 15 input seconds. The example extracts 40 frames, or 5 ms, from a silent 8 kHz fixture. Arbitrary cuts may click; this tool does not fade, resample, normalize, trim by silence, or preserve metadata. No URLs or paths are accepted and uploads are not stored.
The HTTP and MCP interfaces execute the same implementation. Validation errors are returned explicitly. See the tool notes above for its supported inputs and behavior.
PCM frames and exact half-open audio cuts
Read the explanation
The documented example extracts forty frames from an eight kilohertz silent fixture. Forty divided by eight thousand seconds equals five milliseconds. One frame contains one sample for each channel, so forty mono sixteen-bit frames contain eighty selected PCM bytes. Stereo sixteen-bit doubles that to one hundred sixty bytes without changing duration. The bars compare one and two channels at thirty pixels per channel. Frame count therefore must not be confused with individual interleaved sample count or byte count. The offline preview allows argument editing only; no server output or actual trimmed audio result is produced here. A zero-based interval from ten included to fifty excluded selects forty frames. Mono sixteen-bit gives eighty sample bytes, while stereo twenty-four-bit gives two hundred forty, shown with one pixel per selected byte. The contract requires zero less than or equal to start, start strictly less than end, and end no greater than input frame count. Invalid ranges fail rather than clamp; an empty interval is rejected. Sample bytes, rate, channel count, and width stay unchanged. Container metadata is discarded and the WAV container rebuilt. Frame-exact selection does not mean arbitrary cuts avoid clicks, because no fade or silence detection is promised. The returned complete WAV and selected interleaved PCM bytes have separate SHA two fifty six hashes. The first includes rebuilt container bytes; the second covers only selected samples. Decode the returned plain base sixty four to save the actual artifact, rather than treating a JSON hash as audio. The stated decoded upload cap is five hundred twenty four thousand two hundred eighty eight bytes and the input duration cap fifteen seconds. The bars show each independently at their labeled scale; passing one does not guarantee the other. Mono or stereo integer PCM widths eight, sixteen, twenty-four, or thirty-two are documented. No resampling, normalization, metadata preservation, uploads to storage, URLs, or filesystem paths are promised.
PCM Frame Indexing and Lossless WAV Container Reconstruction
How does frame-exact WAV trimming calculate byte boundaries without decoding sample values, and why must the RIFF header be rebuilt?
PCM audio data consists of consecutive multichannel frames where each frame contains exactly one sample per channel (for example, 2 bytes per sample in 16-bit mono or 4 bytes per frame in 16-bit stereo). Because uncompressed PCM is fixed-width, extracting a temporal segment [start_frame, end_frame) requires only slice index calculation: start_byte = start_frame × channels × sample_width_bytes up to end_byte = end_frame × channels × sample_width_bytes. Slicing raw PCM preserves the original digital sample values without numerical loss or resampling error, but the surrounding RIFF/WAVE container header must be reconstructed with updated 'RIFF' chunk and 'data' subchunk length fields.
Frame slicing cuts directly into the digital waveform without inserting envelope fades, windowing, or zero-crossing detection; cuts made at non-zero waveform amplitudes produce audible clicks or pops upon playback. The implementation rejects files with compression, floating-point formats, unsupported channel/width configurations, or frame ranges exceeding the total frames rather than clamping them.
Try a worked example
The default form contains an 8 kHz, 16-bit mono WAV fixture (1 channel × 2 bytes/sample = 2 bytes per frame) with 80 total frames. Setting start_frame to 20 and end_frame to 60 specifies exactly 40 frames (from byte 40 to 120, spanning 5 milliseconds). Clicking 'Run tool' executes trim_wav_frames, replacing the placeholder text in the Structured result area with a JSON response containing 'frames': 40, 'duration_seconds': 0.005, 'sample_rate': 8000, and both the complete WAV sha256 and the slice pcm_sha256 checksums.
PCM Frame Structure and Byte Geometry
In uncompressed linear PCM WAVE files, audio frames are interleaved blocks where each frame consists of one digital sample per channel. Python's standard wave module specifies that reads and writes operate strictly on uncompressed PCM frames, where duration is strictly nframes / framerate. wave — Read and write WAV files — Python 3.14.8 documentation
For an audio stream with c channels and w bytes per sample (such as w = 2 for 16-bit audio), the exact byte offset for any frame index i is given by i × c × w. Slicing on exact frame multiples ensures channel alignment is preserved without splitting multi-byte samples. wave — Read and write WAV files — Python 3.14.8 documentation
Container Header Rebuilding and Checksums
A standard RIFF/WAVE file records the overall file size and subchunk byte lengths directly in its header structures. Python's wave.Wave_write class recalculates and rewrites these header fields when closing the file or writing frames. wave — Read and write WAV files — Python 3.14.8 documentation
The trimmer discards non-audio RIFF chunks (such as INFO, LIST, or custom metadata tags) and writes a clean canonical RIFF/WAVE header around the sliced PCM byte buffer. The response provides pcm_sha256 covering only the raw slice bytes and sha256 covering the entire regenerated WAV container.