New FLAC block size default of 4096 does not apply below compression level 3

[SirAtilla]

This was a feature I requested and during testing seeing different block levels at compression of 0-2.

Build: dBpoweramp Music Converter, macOS, R2026-09-05 (confirmed on Windows as well)
Encoder: FLAC (libFLAC 1.5.0)

The release note for this build reads "FLAC encoder uses default block size of 4096 (from 4608)" with no qualification. In testing, that holds only at compression levels 3 and above.

Measured STREAMINFO min/max block size, same 16/44.1 source track, this build:

Uncompressed 1152
Level 0 1152
Level 1 1152
Level 2 1152
Level 3 4096
Level 5 4096

Prior builds wrote 4608 at every level, including 0-2 and Uncompressed.

I hypothesize that block size is no longer being set at all. Rather than being set to 4096. libFLAC only applies its own rule when the value arrives at init as 0. From stream_encoder.c in 1.5.0:

if(encoder->protected_->blocksize == 0) {
if(encoder->protected_->max_lpc_order == 0)
encoder->protected_->blocksize = 1152;
else
encoder->protected_->blocksize = 4096;
}

The compression level table in the same file gives max_lpc_order = 0 for levels 0, 1 and 2, and non-zero for 3 through 8. That reproduces the split above exactly, and Uncompressed lands on 1152 for the same reason.

So 4096 at levels 3-8 is what libFLAC happens to return, not a value dBpoweramp appears to be setting. Two consequences:

1. Levels 0-2 and Uncompressed have moved from 4608 to 1152. This is a 4x reduction that isn't mentioned in the release notes and not sure intended.
2. It appears the block size is now owned by a libFLAC heuristic rather than by dBpoweramp, so a future change to that rule would move it again silently

Request: call FLAC__stream_encoder_set_blocksize(encoder, 4096) explicitly instead of leaving it unset. That makes the release note accurate as written and holds the value across all levels including Uncompressed.

Happy to run any further test encodes if useful.

[Spoon]

There must be a reason for flac to do this for lower compression levels

[Spoon]

FLAC compresses audio in two distinct phases: it predicts what the next audio sample will look like using mathematical formulas, and then it saves the leftover errors (the residual data).

Lower compression levels (0–2) use incredibly fast, hardcoded, "fixed" predictors. These simple equations don't look very far ahead. Because their prediction models are short-sighted, they compress much better when applied to smaller blocks of data before resetting.

Higher compression levels (3–8) unlock Linear Predictive Coding (LPC). LPC models are highly intelligent and computationally expensive; they search for complex audio patterns across a wider timeline. They require larger block sizes (like 4096)

[SirAtilla]

There must be a reason for flac to do this for lower compression levels

I did some research to try and find out the reasoning around that 1152 block size and was difficult to draw a conclusion even using deep research AI models to try and assemble history from code commits, discussions, and other content from the timeframe the decision was committed around 2007. I found discussions from the original creator of FLAC dating back to 2004.

I think I can safely say this wasn't some carefully optimized "1152 is mathematically ideal for fixed prediction" decision. It appears to have originated as a general-purpose, conservative libFLAC API default, while the flac command-line program overrode it for the higher-compression presets. Even calling this a "compression" level is a bit misleading as you stated in your 2nd reply it's a fundamental change from an LPC model to a fixed predictor model. Much analysis can be found showing this block size is worse for compression in general.

All this leads me back to an original request which was to expose the block size in the UI to allow user setting. dBpoweramp changed from a fixed 4608 to allowing libFLAC to make the decision based on a L# level. I won't argue against that decision as libFLAC may evolve dBpoweramp automatically adopts such changes. I suggest the release notes be updated in the interim to reflect this decision.

Given the state of hardware 20+ years later I could live with L4-L9 without an issue, but I like the choice of control, experimentation, and exploring a natural curiosity of impacts to the playback chain while hoping to retain all the great features and flexibilities in the batch converter for work I do at scale.

Thanks for considering as always as I appreciate the collaboration and your products.