PACodec's 30% reduction: two baselines

The “30% bitrate reduction” in the PACodec paper is not one result. Two separate comparisons — one against 2 kbps baselines at 16 kHz, another against 6 kbps baselines at 48 kHz — happen to yield the same ratio. The introduction frames this as a consistent finding across sample rates. The conditions under which each half was measured differ in sample rate, baseline bitrate, dataset size, and speaker count.

The figures side by side

PACodec is reported at two operating points, each benchmarked against baselines at a different bitrate on a different dataset:

Condition	PACodec bitrate	Baseline bitrate	Absolute saving	Dataset	Sample rate	Training hours	Training speakers	Test speakers
LibriTTS	1.4 kbps	2 kbps	600 bps	LibriTTS	16 kHz	585	2,311	39
VCTK	4.2 kbps	6 kbps	1.8 kbps	VCTK	48 kHz	43	100	8

Quality metrics the paper reports for PACodec at each point:

Metric	LibriTTS @ 1.4 kbps	VCTK @ 4.2 kbps
LSD (dB)	0.89	0.78
STOI	0.93	0.89
UTMOS	3.80	3.93
DNSMOS	3.26	3.17

The bitrate follows directly from the architecture. The paper states a downsampling factor of 320, four VQs, and a codebook size of 128 per VQ. That gives 4 × 7 = 28 bits per frame. At 16 kHz the frame rate is 16000 / 320 = 50 fps, yielding 50 × 28 = 1400 bps. At 48 kHz the frame rate is 48000 / 320 = 150 fps, yielding 150 × 28 = 4200 bps.

Where the comparison holds

The 30% ratio is arithmetically correct in both cases: (2.0 − 1.4) / 2.0 = 0.30, and (6.0 − 4.2) / 6.0 = 0.30. The model is identical across the two operating points — 6.7M parameters, PAVQ configuration, ConvNeXt v2 blocks, training schedule, all unchanged. The quantization scheme does not shift either. Only the input sample rate changes, which scales the frame rate and therefore the bitrate proportionally.

Within each dataset the comparison against baselines is internally consistent. On LibriTTS the paper states that PACodec at 1.4 kbps delivers “perceptual quality on par with 2 kbps baselines.” On VCTK it “outperformed the 4.5 kbps baselines but in some metrics even surpassed the 6 kbps codecs.” The 30% figure on VCTK uses the 6 kbps baseline as the reference point.

Reported by 2609.03363 M· scroll →

Conditions around the comparison

scroll →

30%

bitrate reduction

128

codebook size

6.7M

number of parameters

1.4 kbps

bitrate on LibriTTS

Where it stops holding

The two halves of the “30%” claim are not comparable to each other. A reader who sees the introduction’s “consistently achieves about 30% bitrate reduction across both 16 kHz and 48 kHz datasets” should understand what is doing the work in that sentence.

The baselines are at different bitrates. On LibriTTS the reference is 2 kbps; on VCTK it is 6 kbps. These are not the same point on a quality-versus-bitrate curve. A codec that saves 30% against a 2 kbps baseline is making a different engineering tradeoff than one that saves 30% against a 6 kbps baseline. The absolute saving is three times larger on VCTK (1.8 kbps vs 600 bps). That matters if you are budgeting bandwidth.

The “same decoding quality” claim is metric-dependent and asymmetric. On LibriTTS, PACodec’s LSD of 0.89 dB is slightly worse than MDCTCodec (L)‘s 0.88 dB, while its STOI of 0.93 matches MDCTCodec exactly. On VCTK the picture is more favorable: PACodec’s LSD of 0.78 dB beats DAC (L)‘s 0.85 dB and Encodec (L)‘s 0.91 dB; its STOI of 0.89 exceeds DAC’s 0.87; its DNSMOS of 3.17 exceeds DAC’s 3.14. The paper’s own overview table shows PACodec leading or matching most baselines on VCTK at 4.2 kbps. The LibriTTS picture is tighter. “On par” is doing real work that “surpassed” is not.

The VCTK test set is small. 2,937 utterances from 8 unseen speakers, versus 4,837 utterances from 39 unseen speakers on LibriTTS. The 40-listener ABX test compared 10 utterance pairs per method. The paper does not address whether the metric differences on VCTK are statistically robust at that test-set size.

The 3.15 kbps variant is a different operating point. Section 3.4 reports PACodec at 3.15 kbps on VCTK with LSD 0.79, STOI 0.87, UTMOS 3.89, DNSMOS 3.16. This is presumably a 3-VQ configuration (3 × 7 = 21 bits/frame × 150 fps = 3150 bps), used for the disentanglement ablation. It is not the same result as the 4.2 kbps main entry.

The LibriTTS and VCTK metric columns in the overview table are not comparable to each other. They were measured at different bitrates (1.4 vs 4.2 kbps), on different sample rates (16 vs 48 kHz), on different datasets with different speaker demographics and durations. A reader who sees PACodec’s UTMOS jump from 3.80 to 3.93 between the two columns should not infer that the codec “improves at higher sample rates.” The baseline UTMOS values shift as well (e.g., DAC goes from 3.65 to 3.87), which is consistent with the 48 kHz signal simply having more information to preserve.

What cannot be concluded

The paper does not report what bitrate each individual baseline codec in the overview table was run at. Section 3.3 describes “2 kbps baselines” on LibriTTS and “4.5 kbps baselines” plus “6 kbps codecs” on VCTK, but the text does not map Encodec (L), AudioDec (L), DAC (L), APCodec (L), MDCTCodec (L), SQCodec (L), or HiFi-Codec (H) to a specific bitrate. The metrics in the overview table therefore cannot be read as a quality-at-matched-bitrate comparison without that mapping. The 30% claim is supported by the prose in section 3.3, but the table alone does not confirm it.

For context on how codec comparison tables can be read at face value when the conditions are actually different, see our earlier note on CSAVocoder’s mel adaptor results, where a similar issue of unstated evaluation conditions affected how the headline number should be interpreted.

---

Method: this note was drafted by qwen/qwen3.8-27b from a single source — the arXiv abstract for 2609.03363. Before publication an automated gate re-checked every extracted claim against the source document (52 claim(s) and 55 quantity(ies) verified) and every claim-shaped number in the draft against that evidence (12 derived from it, no rows from our own tables were supplied to the draft). The studio has not re-run 2609.03363’s benchmarks; figures attributed to it are its own.

FAQ

Can I use the LibriTTS numbers to predict what PACodec will do at 48 kHz?

No. The 1.4 kbps LibriTTS result and the 4.2 kbps VCTK result come from different sample rates, different datasets, and different baseline bitrates. The paper does not report a 1.4 kbps result on VCTK or a 4.2 kbps result on LibriTTS.

Is the 6.7M parameter count actually small?

It is at the low end of the reported comparison set. MDCTCodec (L) has 6.8M parameters, Encodec (L) has 17.6M, DAC (L) has 76.5M. PACodec is comparable in size to MDCTCodec and an order of magnitude smaller than DAC. Whether that matters depends on your deployment constraint. If you are serving on-device, 6.7M is small. If you are comparing quality-per-parameter, MDCTCodec at 6.8M is the relevant comparator, and its LibriTTS metrics (LSD 0.88, STOI 0.93, UTMOS 3.87) are very close to PACodec's.

What does "codebook size 128" buy you compared to typical RVQ setups?

The paper states that PACodec "can operate with a codebook size as small as 128 by focusing each VQ on local information." Standard RVQ codecs in the comparison table (Encodec, DAC, AudioDec) typically use larger codebooks or more quantization levels. Each VQ's lookup table is 128 entries, which reduces memory and potentially inference latency for the quantization step. The paper attributes the quality retention to the GLG (global-local-global) design distributing information across the four VQs rather than relying on a single large codebook.

Does the 3.15 kbps disentanglement result affect the main comparison?

No. The 3.15 kbps figures (LSD 0.79, STOI 0.87, UTMOS 3.89, DNSMOS 3.16 on VCTK) come from section 3.4, an ablation study where VQs are removed to test which one carries which type of information. It is a different operating point from the 4.2 kbps main result and should not be mixed into the bitrate-savings comparison.