flac: 'encoding wrapper is super buggy and doesn't work yet' #891
Labels
No labels
CI
all
basisu
blog
bug
build
contributor-friendly
core
correctness
deferred
dev
direct3d-headers
docs
driver-os-issue
duplicate
dxcompiler
editor
examples
experiment
feature-idea
feedback
flac
freetype
gamemode
gkurve
glfw
gpu
gpu-dawn
harfbuzz
help welcome
in-progress
infrastructure
invalid
libmach
linux-audio-headers
long-term
mach
mach.gfx
mach.math
mach.physics
mach.testing
model3d
needs-triage
object
opengl-headers
opus
os/linux
os/macos
os/wasm
os/windows
package-manager
priority
proposal
proposal-accepted
question
roadmap
slipped
stability
sysaudio
sysgpu
sysjs
validating-fix
vulkan-zig-generated
wayland-headers
website
wontfix
wrench
www
x11-headers
xcode-frameworks
zig-update
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
hexops/mach#891
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The encoding implementation in mach-flac should be brought up to standards and there should be an example of encoding a flac file.
Hello!
I spent some time looking into this and with some tweaks, was able to encode a working FLAC file.
I've outlined my findings below and if you're interested, I can open PRs in
hexops/mach-flacandhexops/flacto help integrate these fixes :)Background
As noted by @alichraghi in their comment above
encodeStreamThe encoder crashes when compiled with Zig safety rules turned on (e.g.,
ReleaseFastdoesn't crash):When this crash happens,
raw_bits_per_partitionis a null pointer and I'm assuming Zig considers pointer arithmetic with a null pointer an illegal instruction. Makes sense!Through code inspection,
raw_bits_per_partitiononly seems relevant when dealing with something called "escape coding" in FLAC files and it looks like escape code support was dropped in xiph/flac@3b5f471837.A Fix
I patched the C code with the following:
And now if I run my demo program, it produces a valid file:
Bonus Decoder Fix
The decoder was shifting the samples in
writeCallback:This was causing samples values to far exceed the expected value range for 16-bit samples. I removed the shift.
Demo
Here's the demo to decode and encode the file:
PRs welcome
Hello, I opened an issue in the upstream FLAC library to address the undefined behavior that breaks encoding when Zig compiles with safety rules on.
If you bring the changes from this PR into your mach-flac fork, we should see better behavior.