rusty_vorbis Decodes ArtCraft's File Faster Than Symphonia

ArtCraft's audio editor imports Vorbis and writes a 24-bit WAV through its own command. On 22 October 2026 that path was lewton, called from the remade_ffmpeg_rs adapter, and it was slower than symphonia 0.5.5. They put Vorbis back on symphonia and asked for a house decoder. rusty_vorbis 0.1.2 is that decoder. On their 10-minute stereo file, after demux, it is faster than symphonia on every paired round, and the samples agree. The editor's package list still names symphonia. The JPEG half of the same week is rusty_jpeg 0.4.4. The pipeline is remade_ffmpeg_rs. The catalog is Remade with Rust.

Trust is the same file, the two decoders alternating, and a sample difference small enough to print. Security is an audio parser with no C library in the process. Incentive is a house Vorbis decoder the editor can call because it is no longer the slow one. Vorbis itself is the royalty-free codec from Xiph. The Electronic Frontier Foundation treats the parser inside a file as a security boundary. The NIST Secure Software Development Framework asks for that boundary in a memory-safe language.

Why rusty_vorbis 0.1.1 Left ArtCraft on symphonia

Version 0.1.1 encoded. Its docs told callers to decode with lewton, and the adapter did. The editor's command, a 10-minute stereo 44.1 kHz file encoded at Vorbis quality 5, came out 1.22× slower on one core and 1.24× slower on eight. Zero wins in 20 rounds. The null arm, the same binary against itself, was 1.01 and 1.00. An in-process split, indicative only, put lewton's own decode at about 1.4–1.5× symphonia's Vorbis decoder on that file. The glue around lewton was not the gap.

They asked for float samples, the Ogg end-granule trim, WAV channel order, and at least symphonia's speed. Those are correctness items sitting next to the clock. A decoder that is faster and still drops the tail of the file, or still hands back 16-bit samples, would not have answered the report. rusty_vorbis 0.1.2 is scoped to both.

What rusty_vorbis 0.1.2 Returns

The crate is a decoder now, and the library has no dependencies. lewton remains in the test suite as the oracle the decoder is gated against. It is not on the decode path a caller links. The match target for channel order and the end of the stream is FFmpeg's native decoder: float output, the final page's granule position honored, frame counts that agree, from one channel through eight, across the quality range and the sample rates the suite covers.

rusty_vorbis emits float samples in WAV order

The lewton adapter emitted 16-bit samples, so a float caller got a quantised copy, up to one 16-bit step away from a float decode. It also skipped the end-granule trim. One test file came out 44,608 frames long against the correct 43,972. On more than two channels the old path kept Vorbis order, front-left then center then front-right, instead of WAV order. 0.1.2 answers that list: interleaved float, the trim applied, WAV channel order. ArtCraft had been calling lewton directly to get the float samples. The house decoder is what makes that direct call unnecessary.

The 10-minute file is where rusty_vorbis wins

The probe demuxes once, then times a decode to interleaved float, under rusty_alloc, 20 rounds, one whole file per round, pinned. The median time ratio against symphonia is 0.729 on one core and 0.640 on four logical cores. rusty_vorbis won all 20 rounds on both masks. Both arms produced 26,460,032 frames. The largest absolute sample difference was 2.98×10⁻⁸ across about 52.9 million samples. That is the file the editor cares about, a music-like stereo signal at 44.1 kHz, quality 5, ten minutes. It is a decode probe. It is not the editor's WAV export.

lewton stays a test oracle beside rusty_vorbis

The published library does not depend on lewton. The dependency shows up only where the tests compare the two decoders. A program that links rusty_vorbis 0.1.2 for decode is not also linking the decoder it replaced. That split is the point of the release. The encode half of the crate was already the permissive Rust encoder. The ArtCraft request was the decoder, and 0.1.2 is the version that carries it.

remade_ffmpeg_rs Calls rusty_vorbis for Decode

The workspace copy is rusty_vorbis 0.1.2. The Vorbis adapter calls that decoder. A Disco Party node and FFAI take media through this pipeline. ArtCraft's editor is a separate package list, and that list has not moved yet.

The rff tool is a second rusty_vorbis clock

Through the engine, Ogg demux plus decode to float is 1.61× faster than symphonia 0.5.5 on a 10-minute stereo quality-5 file, 20 of 20 paired rounds, pinned. The rff command-line tool decodes that file 2.33× faster than the same tool did with lewton, 30 of 30. Those two figures have different baselines. The 1.61× is against symphonia. The 2.33× is against the old lewton build of rff. Neither figure is the editor writing a 24-bit WAV. Why the distributed cloud needs memory-safe Rust is why that command is a Rust binary in the first place.

ArtCraft's package list still decodes with symphonia

The audio editor's manifest names symphonia for Vorbis, including Vorbis inside Ogg and Matroska, because that decoder was faster than lewton. rusty_vorbis 0.1.2 is the measurement that reverses the reason for staying. The run that closes it is the editor's own export, same file, same WAV, paired the way the lewton loss was paired. Until that run, the probe and the rff clocks are the evidence, and the manifest is unchanged.

A mata.network page does not decode with rusty_vorbis

The public site is built ahead of time. A Learn page request does not open an Ogg file. When media is the job, the decoder is the one remade_ffmpeg_rs registered. Ship notes for that stack go to futureweb.news. The importance of Remade with Rust is the catalog those notes belong to.