MPEG_5_1 formats from CoreAudioTypes.h are missing in CAFFileALAC.h, leading developers to choose
kAudioChannelLayoutTag_MPEG_5_1_D when their audio data is actually in kAudioChannelLayoutTag_MPEG_5_1_A order, leading to playback issues with audio channels going to the wrong speakers. (This problem presently manifests itself in DVD Audio Extractor and XLD.)
The CAFFileALAC.h file only defines one 5.1 format, the "MPEG_5_1_D" 124 C L R... ordering. However, CoreAudioTypes.h defines four, one of which is "MPEG_5_1_A" = 121 = L R C LFE Ls Rs.
Here's an excerpt from CoreAudioTypes.h
kAudioChannelLayoutTag_MPEG_5_1_A = (121L<<16) | 6, // L R C LFE Ls Rs
kAudioChannelLayoutTag_MPEG_5_1_B = (122L<<16) | 6, // L R Ls Rs C LFE
kAudioChannelLayoutTag_MPEG_5_1_C = (123L<<16) | 6, // L C R Ls Rs LFE
kAudioChannelLayoutTag_MPEG_5_1_D = (124L<<16) | 6, // C L R Ls Rs LFE
The A, B, and C 5.1 formats are missing in CAFFileALAC.h. Developers using this ALAC library need the kAudioChannelLayoutTag_MPEG_5_1_A to convert FLAC, WAV, etc. without reordering the channel data itself from L R C.. to C L R order.
I believe this problem extends beyond 5.1 to other multichannel formats. See this bug report for the ALAC library, which gave me the clue: https://github.com/macosforge/alac/issues/7
(Based on extensive testing, QuickTime and iTunes both properly honor the 121 flag for L R C order and Logic Pro X actually assumes the 121, ignoring the 124. Hence, ALAC files written with the 121 L R C order appear to be compatible with more Apple applications than those tagged 124, even if those had the audio channel data ordering corresponding to the 124 tag. Hex editing improperly rendered files from XLD to change the 124 (0x7C) to 121 (0x79) causes them the then be played properly in QT and iTunes. FYI: VLC may be assuming C L R order for 5.1 ALAC playback regardless of tag.)
MPEG_5_1 formats from CoreAudioTypes.h are missing in CAFFileALAC.h, leading developers to choose kAudioChannelLayoutTag_MPEG_5_1_D when their audio data is actually in kAudioChannelLayoutTag_MPEG_5_1_A order, leading to playback issues with audio channels going to the wrong speakers. (This problem presently manifests itself in DVD Audio Extractor and XLD.)
The CAFFileALAC.h file only defines one 5.1 format, the "MPEG_5_1_D" 124 C L R... ordering. However, CoreAudioTypes.h defines four, one of which is "MPEG_5_1_A" = 121 = L R C LFE Ls Rs.
Here's an excerpt from CoreAudioTypes.h
The A, B, and C 5.1 formats are missing in CAFFileALAC.h. Developers using this ALAC library need the kAudioChannelLayoutTag_MPEG_5_1_A to convert FLAC, WAV, etc. without reordering the channel data itself from L R C.. to C L R order.
I believe this problem extends beyond 5.1 to other multichannel formats. See this bug report for the ALAC library, which gave me the clue: https://github.com/macosforge/alac/issues/7
(Based on extensive testing, QuickTime and iTunes both properly honor the 121 flag for L R C order and Logic Pro X actually assumes the 121, ignoring the 124. Hence, ALAC files written with the 121 L R C order appear to be compatible with more Apple applications than those tagged 124, even if those had the audio channel data ordering corresponding to the 124 tag. Hex editing improperly rendered files from XLD to change the 124 (0x7C) to 121 (0x79) causes them the then be played properly in QT and iTunes. FYI: VLC may be assuming C L R order for 5.1 ALAC playback regardless of tag.)