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:
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.
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:
- 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.
- 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.