[flac-dev] Define 6.1 and 7.1 channel mappings

Brian Willoughby brianw at sounds.wa.com
Thu Jan 17 19:26:03 PST 2013


I vote for documenting the --channel-map option in the --help

I don't like the idea of rejecting a multichannel file merely for  
mapping, so there should be a documented option plus an error message  
pointing to the option. This should compare to the WAVE and AIFF  
errors where the utility suggests to the user how to get the file  
converted safely.

Brian Willoughby
Sound Consulting


On Jan 17, 2013, at 17:34, Ralph Giles wrote:
> On 13-01-01 4:36 PM, Tim W. wrote:
>> - 4 channels: left, right, back left, back right (FL FR BL BR)
>> - 5 channels: left, right, center, back/surround left, back/ 
>> surround right
>>               (FL FR FC BL BR or FL FR FC SL SR, same order so  
>> doesn't matter)
>> - 6 channels: left, right, center, LFE, back/surround left, back/ 
>> surround right
>>               (FL FR FC LFE BL BR or FL FR FC LFE SL SR, same  
>> order so doesn't matter)
>
> I looked at the 'flac' command-line front-end code today, and it uses
> Back Left and Back Right for 4 channel but Side Left and Side Right  
> for
> 5 and 6 channel files when writing out WAVE from FLAC files without a
> WAVFORMATEXTENSIBLE_CHANNEL_MASK metadata tag.
>
> As you say, the order is the same, and for less that 7 channels the
> physical speaker configurations are equivalent.
>
> The encoder accepts both Side and Back in the input channel mask, but
> passes them on in the tag, of course. If the input is AIFF the support
> is more limited, rejecting any multichannel file unless the  
> undocumented
> --channel-map=none is passed, followed by some dead code saying  
> only 1,
> 2, 3, and 5 channels can be unambiguously mapped.
>
>> - 6.1: FL FR FC LFE BC SL SR (L R C LFE Cs Ls Rs)
>> - 7.1: FL FR FC LFE BL BR SL SR (L R C LFE Rls Rrs Ls Rs)
>
> Again, I'm suggesting we update the spec to define these as the  
> default
> channel maps for 7 and 8 channel FLAC files in the absence of the
> overriding WAVFORMATEXTENSIBLE_CHANNEL_MASK metadata tag, and  
> modify the
> included 'flac' front-end to write out those masks when decoding such
> files. Likewise, we would modify 'flac' to accept files with those
> channel masks as input when encoding.
>
> Untested patch attached.



More information about the flac-dev mailing list