I’m reaching out because I’ve spent several years running into multichannel channel‑mapping issues across various Linux applications and toolchains, and every time I try to track down the root cause, I end up getting a different explanation from each layer of the stack.
Applications say it’s sending the files fine.
Raspberry Pi says it's not them, HDMI and ALSA are working as designed.
ALSA says it's the app's responsibility to forward channel mapping.
App devs are often writing workarounds to these issues.
Recently, after digging deeper into how my FLAC files were originally created, I discovered another layer: the way flac.exe handles WAVEFORMATEXTENSIBLE channel masks when encoding multichannel WAV files.
In my case, the files were created through foobar2000, which calls flac.exe as its encoder. Foobar2000 generates a WAV with a valid dwChannelMask, but when flac.exe encodes it:
• the mask is copied into the Vorbis comment WAVEFORMATEXTENSIBLE_CHANNEL_MASK
• the FLAC bitstream’s channel‑assignment field is set to independent for any non‑canonical layout
On Windows, this “works” because the WAV writer and audio stack honor the mask after decode.
On Linux, the mask is ignored, and decoders rely solely on the FLAC bitstream’s channel‑assignment field — which is unset — so the layout is lost.
Foobar2000’s developer pointed me back to flac.exe, saying that foobar2000 simply passes the WAV to the encoder. From their perspective, the encoder is responsible for translating the mask into FLAC’s native channel‑assignment metadata.
From the ffmpeg/libFLAC/Linux side, the response is that the Vorbis comment mask is optional metadata, not authoritative, and that decoders are correct to ignore it.
So I’m stuck between multiple components, each behaving correctly in isolation, but collectively producing FLAC files that decode inconsistently across platforms.
My questions for the FLAC developers are:
Is it the intended behavior that flac.exe does not translate the WAV channel mask into FLAC’s native channel‑assignment metadata, even though the mask contains enough information to derive a correct layout?
If so, what is the recommended way for tools like foobar2000 to produce multichannel FLAC files that decode correctly across Linux, Windows, and other platforms without relying on optional Vorbis comments?
Has automatic translation of the WAV mask into FLAC’s channel‑assignment field ever been considered, or is there a historical or technical reason it hasn’t been implemented?
I’ve already written scripts to repair my library and to create new FLACs with explicit channel maps, so I’m not stuck. I’m just trying to understand the design philosophy behind the current behavior, because from the outside it feels like each layer assumes another layer will handle layout, and the end result is that nobody does.
Any insight into how this is expected to work — or how it should
I’m reaching out because I’ve spent several years running into multichannel channel‑mapping issues across various Linux applications and toolchains, and every time I try to track down the root cause, I end up getting a different explanation from each layer of the stack.
Applications say it’s sending the files fine.
Raspberry Pi says it's not them, HDMI and ALSA are working as designed.
ALSA says it's the app's responsibility to forward channel mapping.
App devs are often writing workarounds to these issues.
Recently, after digging deeper into how my FLAC files were originally created, I discovered another layer: the way flac.exe handles WAVEFORMATEXTENSIBLE channel masks when encoding multichannel WAV files.
In my case, the files were created through foobar2000, which calls flac.exe as its encoder. Foobar2000 generates a WAV with a valid dwChannelMask, but when flac.exe encodes it:
• the mask is copied into the Vorbis comment WAVEFORMATEXTENSIBLE_CHANNEL_MASK
• the FLAC bitstream’s channel‑assignment field is set to independent for any non‑canonical layout
On Windows, this “works” because the WAV writer and audio stack honor the mask after decode.
On Linux, the mask is ignored, and decoders rely solely on the FLAC bitstream’s channel‑assignment field — which is unset — so the layout is lost.
Foobar2000’s developer pointed me back to flac.exe, saying that foobar2000 simply passes the WAV to the encoder. From their perspective, the encoder is responsible for translating the mask into FLAC’s native channel‑assignment metadata.
From the ffmpeg/libFLAC/Linux side, the response is that the Vorbis comment mask is optional metadata, not authoritative, and that decoders are correct to ignore it.
So I’m stuck between multiple components, each behaving correctly in isolation, but collectively producing FLAC files that decode inconsistently across platforms.
My questions for the FLAC developers are:
Is it the intended behavior that flac.exe does not translate the WAV channel mask into FLAC’s native channel‑assignment metadata, even though the mask contains enough information to derive a correct layout?
If so, what is the recommended way for tools like foobar2000 to produce multichannel FLAC files that decode correctly across Linux, Windows, and other platforms without relying on optional Vorbis comments?
Has automatic translation of the WAV mask into FLAC’s channel‑assignment field ever been considered, or is there a historical or technical reason it hasn’t been implemented?
I’ve already written scripts to repair my library and to create new FLACs with explicit channel maps, so I’m not stuck. I’m just trying to understand the design philosophy behind the current behavior, because from the outside it feels like each layer assumes another layer will handle layout, and the end result is that nobody does.
Any insight into how this is expected to work — or how it should