Use this URL in any client supporting remote Streamable HTTP MCP. Calls return structured JSON; inputs are processed without persistence.
Call reverse_wav_frames
Accepts plain base64 mono/stereo uncompressed integer PCM WAV with 8/16/24/32-bit samples. Input must be nonempty, at most 524288 decoded bytes and 15 seconds. Output frame i equals input frame N-1-i. A frame contains one sample per channel: channel order and byte order inside each sample never reverse. Rate, width, duration and frame count are preserved. Reversing twice restores the original raw PCM bytes; original WAV metadata is discarded, so full container bytes need not match. This is time reversal, not phase inversion, reverse channel order, resampling or pitch shifting. Abrupt waveform endpoints may click; no fades are added. Decode audio_base64 to save the output WAV. sha256 hashes the full output; pcm_sha256 and input_pcm_sha256 hash raw interleaved samples. No paths or URLs are accepted and audio is not persisted.
POST https://app.getsupers.com/sites/agent-wav-reverse/call
Content-Type: application/json
{
"audio_base64": "UklGRkQAAABXQVZFZm10IBAAAAABAAIAQB8AAAB9AAAEABAAZGF0YSAAAAAAEAAgAPAA4AAQACAA8ADgABAAIADwAOAAEAAgAPAA4A=="
}
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.
Reverse whole frames without reversing sample bytes
Read the explanation
The compact saved example contains eight stereo frames. Reversal maps output frame i to original frame seven minus i. The paired blue and gold samples move together; blue is the left channel and gold the right. Original index seven becomes output index zero, then six becomes one, and so on. Channel order remains left then right within every frame, and bytes inside each signed sample are not reversed. This illustrates the documented operation using locally decoded fixture data; it does not invoke the remote tool. The input has thirty-two raw PCM bytes: eight frames times two channels times two bytes per sample. Reversed PCM also has thirty-two bytes, eight frames and the same one millisecond duration at eight thousand Hertz. Reversing twice restores the original raw PCM sequence. WAV metadata is rebuilt rather than preserved, so applying the operation twice does not guarantee identical whole-container bytes. Time reversal does not negate each sample, swap channels, change pitch by resampling or add fades. This alternating fixture happens to start with opposite signs after reversal, but that pattern does not make the operation phase inversion in general. Mono and stereo integer PCM are supported with stated size and duration budgets. Abrupt endpoints may click. Whole-WAV and raw-PCM hashes refer to different byte sequences. The local textarea is preserved; no returned WAV or remote execution is claimed.
Lossless WAV Frame Time Reversal Mechanism and Boundaries
How does frame-aware WAV time reversal preserve sample endianness and channel alignment while reversing audio in time?
PCM audio in a multi-channel WAV is laid out as sequential frames, where each frame contains one sample for each channel interleaved in byte order (stride = channels × sample width). Lossless time reversal reverses the chronological order of these entire frame blocks from last to first (mapping output frame i to input frame N - 1 - i). It leaves the internal channel order and little-endian byte representation within each sample slice unchanged, avoiding phase inversion, channel swapping, or sample-level byte corruption.
Accepts only uncompressed integer PCM WAV files (mono or stereo, 8/16/24/32-bit) up to 524,288 decoded bytes and 15 seconds. Non-PCM encodings, floating-point WAVs, and extra metadata chunks (such as INFO, BEXT, or cue points) are rejected or stripped when rebuilding the standard RIFF/WAV header. Reversal creates non-zero boundary transitions that may click or pop because no smoothing envelopes or fades are applied.
Try a worked example
Submitting the preset stereo audio_base64 argument via the Run tool button sends 8 stereo frames (2 channels, 16-bit / 2 bytes per sample, 4 bytes per frame) to reverse_wav_frames. The tool slices the 32 raw PCM bytes into 8 four-byte chunks and concatenates them in reverse sequence. The structured result populates with a newly packaged WAV payload, matching frame count (8), sample rate (8000 Hz), channels (2), duration (0.001 s), and distinct SHA-256 hashes for the reversed output artifact and sample stream.
Frame Striding vs. Byte Reversal
In uncompressed linear PCM WAV files, multi-channel audio data is stored as interleaved frames. For a 16-bit stereo signal, each frame consists of 4 bytes: 2 bytes for channel 0 (left) in little-endian order, followed by 2 bytes for channel 1 (right) in little-endian order. A naive byte-level reversal reverses the byte stream from end to start, which inverts sample endianness into garbage audio and swaps left and right channel positions.
The tool calculates frame stride as channels × sample_width_bytes and iterates backwards through the raw PCM buffer in stride-sized steps. By taking full stride slices without reordering bytes inside the slice, output frame i faithfully receives input frame N - 1 - i with channel positioning and numeric sample values intact.
Invertibility and Hash Verification
Because frame reordering is a bijection over discrete frame indices, invoking reverse_wav_frames a second time on its own output restores the exact initial raw PCM byte sequence. The tool returns pcm_sha256 (hash of raw interleaved samples) and input_pcm_sha256 so pipelines can mathematically verify sample-level reversibility.
The outer WAV container hash sha256 covers the regenerated canonical RIFF header. Because original input metadata or non-essential chunks are discarded during stream parsing, the full container hash after two reversal passes is not guaranteed to match the original uploaded container, even though the raw PCM payload is identical.