Use this URL in any client supporting remote Streamable HTTP MCP. Calls return structured JSON; inputs are processed without persistence.
Call assemble_stereo_wav
Both inputs must be plain base64 uncompressed mono integer PCM WAV, 8/16/24/32-bit, with identical sample rate, sample width and nonzero frame count. Combined decoded input budget is 524288 bytes; each recording must be at most 15 seconds. Left input becomes channel 0 and right input becomes channel 1. Samples are interleaved byte-for-byte; there is no resampling, gain adjustment, mixing, automatic time alignment, padding or truncation. Output duration equals either input duration. Original container metadata is discarded. Decode audio_base64 to save the stereo WAV. sha256 hashes the full output; pcm_sha256 hashes interleaved samples; left_pcm_sha256 and right_pcm_sha256 hash the respective mono sample streams. This operation does not create stereo separation from a single source. No file paths or URLs are accepted, and audio is not persisted.
POST https://app.getsupers.com/sites/agent-wav-stereo/call
Content-Type: application/json
{
"left_base64": "UklGRjQAAABXQVZFZm10IBAAAAABAAEAQB8AAIA+AAACABAAZGF0YRAAAAAAEADwABAA8AAQAPAAEADw",
"right_base64": "UklGRjQAAABXQVZFZm10IBAAAAABAAEAQB8AAIA+AAACABAAZGF0YRAAAAAAIADgACAA4AAgAOAAIADg"
}
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.
The saved examples decode into two uncompressed mono WAV recordings. Each has eight frames at eight thousand frames per second, with sixteen-bit samples. Each mono sample occupies two bytes, so eight frames contain sixteen PCM bytes. Stereo interleaves left sample zero, right sample zero, left sample one, right sample one, and so on, producing thirty-two PCM bytes. Both bars use fifteen pixels per PCM byte. The frame count remains eight and duration remains one millisecond; doubling channel count does not double playback time. Matching sample rate, width and frame count are required. The service contract rejects mismatches instead of resampling, padding or truncating. This explanation independently decodes the saved examples locally, but does not call the remote tool. The left example alternates positive and negative four thousand ninety-six. The right alternates positive and negative eight thousand one hundred ninety-two. On a shared scale of fifteen pixels per two hundred fifty-six amplitude units, the right magnitude is twice the left. These are stored signed integer values, not decibels or a playback loudness claim. The first stereo frame is left positive four thousand ninety-six followed by right positive eight thousand one hundred ninety-two; the second contains their negative values. Every original sample byte is retained in its channel. There is no gain adjustment, summing or mixing. Combining identical mono streams would produce identical channels; this operation cannot invent spatial separation from a single source, nor automatically synchronize recordings that began at different times. Both source streams have equal sixteen-byte PCM payloads even though their sample amplitudes differ. The equal bars share fifteen pixels per PCM byte. The contract returns encoded stereo audio, a hash of the complete output WAV, a hash of its interleaved PCM, and separate hashes of each original channel stream. Container metadata is discarded, so preserving audio bytes does not mean preserving the original file headers. A channel hash can support checking that extracted channel bytes match a source, while the complete file hash also covers the newly written container. Supported inputs are mono integer PCM at eight, sixteen, twenty-four or thirty-two bits, with nonzero matching frames, at most fifteen seconds each and a combined decoded budget of five hundred twenty-four thousand two hundred eighty-eight bytes. Inputs are plain base64, not file paths or URLs. Actual service output and public playback remain unverified; no HTTP, MCP or model backend request occurs here.
Lossless Mono-to-Stereo WAV Assembly Mechanism
How does this assembler combine separate mono PCM audio recordings into a stereo WAV artifact without altering sample values?
The tool accepts two base64-encoded, uncompressed integer pulse-code modulation (PCM) mono WAV recordings and interleaves them byte-for-byte into a single 2-channel stereo WAV artifact. Left mono sample bytes become channel 0 and right mono sample bytes become channel 1 across each frame. The underlying implementation does not resample, apply gain, pad frames, or mix channels, and it generates independent SHA-256 hashes for the overall stereo file and raw interleaved PCM samples.
Both input files must strictly share identical sample rate, sample width (8, 16, 24, or 32-bit integer PCM), and frame counts; any mismatch causes immediate validation rejection without padding or truncation. The combined decoded payload cannot exceed 524,288 bytes, and each channel is capped at a 15-second duration. The tool does not perform acoustic source separation or stereo widening from a single mono file.
Try a worked example
Submitting the preloaded 8-frame 16-bit 8000 Hz sample inputs by clicking 'Run tool' evaluates both streams. The tool verifies identical sample rates (8000 Hz), sample widths (2 bytes), and frame counts (8 frames), interleaves 16 bytes from each mono input into 32 total PCM bytes (4 bytes per stereo frame), and outputs the stereo WAV base64 string along with sha256 and pcm_sha256 digest fields.
PCM Byte Interleaving and Channel Order
For uncompressed PCM WAV containers, multi-channel audio frames arrange sample bytes in sequentially interleaved order. In a standard two-channel stereo stream, channel 0 represents the left channel and channel 1 represents the right channel. For each discrete time slice, sample width bytes from the left input are followed immediately by sample width bytes from the right input.
Because samples are combined directly without dithering, rounding, or re-quantization, the binary representation of every incoming audio frame is strictly preserved. In addition to returning the containerized stereo WAV artifact, the tool returns separate SHA-256 digests for the raw interleaved PCM payload and each isolated channel input to verify sample integrity.
Strict Frame and Parameter Matching Requirements
The assembler requires strict equality across audio parameters rather than attempting automated audio conversion. The sample rate in Hz, sample width in bytes (1 to 4 bytes for 8/16/24/32-bit audio), and frame count must match exactly between both mono sources. An input difference of even a single frame raises an explicit error rather than silently appending silence or cropping duration.