[flac-dev] Tag flac as flac 1.2.1_git

[Brian Willoughby]

On Jan 12, 2013, at 14:28, Martijn van Beurden wrote:
> On 12-01-13 22:46, Brian Willoughby wrote:
>> I would suggest that everyone keep in mind the vast installed base of
>> hardware FLAC recorders and players, and not senselessly make them
>> obsolete without extremely compelling reasons.
>
> This can be done for the same reason the change from 1.1 to 1.2  
> added a
> new form of residue coding: I don't believe there are many 7 or 8
> channel FLAC-players out there (just like there were not much 24-bit
> FLAC decoding devices out there when 1.2 came out). We still are at a
> point we can still make those changes.


The problem with your example is two-fold. First, residue coding  
affects the actual compressed audio data, but channel mapping does  
not. Second, there are 8-channel FLAC recorders out there, so it  
would be incredibly destructive to break compatibility for no reason  
at all.


> Josh made a decision at some point to map audio channels instead of
> storing the order in metadata. I think it was a sound decision because
> the channel order is known without the need for that piece of  
> metadata,
> for example in case of streaming. It would be silly to keep this
> behaviour on currently defined channels and do something else on 7  
> and 8
> channel audio.


It seems that you are imagining a decision on Josh's part without any  
reason to believe so. The existing format has channel count and  
channel combination attributes, not channel order variations. The  
information that exists in the headers is not optional, so I don't  
see how you've proven that Josh made any sort of decision here. The  
headers simply must include this information in order to extract the  
uncompressed audio channels.

In the METADATA_BLOCK_STREAMINFO, 7 bits are allocated for the  
channel count. This limits the format to 8 channels in a single  
stream. Nothing is implied about order or channel labels, and there  
is no room to go beyond 8 channels without breaking compatibility.

In the FRAME_HEADER, 8 bits are allocated for the channel  
interpretation. The first 8, codes 0 through 7, refer to independent  
channels, where none of the channels affect any of the other  
channels. Codes 8, 9, and 10 are variations of stereo where at least  
one of the coded channels is a combination of multiple uncompressed  
channels (side), if not both (10: mid/side). Codes 11 through 15 are  
reserved. Although these channel formats include labels, none of them  
is redundant in terms of coding the same format with different  
channel names.

In other words, the FLAC format describes purely how to extract the  
individual channels as audio data streams, without any possibility of  
channel names or labels altering the format. It's merely a convention  
that the multi-channel options mention a default channel order. There  
is no reason to change the format just to change the labels for each  
channel. There is no example yet of two FLAC files with the same  
number of channels and the same data coding for those channels, but  
which only differs in the labeling and output assignment of those  
unaltered channels. If there were, then I'd say you have a case.


> We might try to find out how current 7.1 hardware decoders behave with
> regard to channel mapping.


Yes, that would be a great project.

DVD includes uncompressed PCM, Dolby Digital surround, and DTS  
surround. It would be interesting to summarize the channel orders for  
each of those. PCM is limited to stereo, though. I have DTS encoding  
software, but have never paid attention to the channel order because  
there is no option. They have altered DTS over the years to add  
channels, but always in a backwards compatible manner so that new  
media with additional channels can still be played by old hardware  
that only understands fewer channels.

BluRay discs have even more audio formats, and it would be  
interesting to see a report on channel orders for all of those  
variations.

We have a different situation. If someone were suggesting that FLAC  
be modified to support more than 8 channels, then I would understand  
a format change and requisite version number change. But all we are  
really talking about is keeping the channel counts the same, and the  
raw compressed data, but with additional information on channel  
labels that would facilitate patching the correct audio data to the  
correct physical output wire for analog audio (or maybe digital).


Let me put this another way: Can you make a stronger case for why we  
should NOT create a standard meta data chunk for channel labels?

The existing changes that have been proposed do nothing to change the  
bit stream itself. The only difference is a change from 7 or 8  
unspecified channels of audio to 7 or 8, respective, channels of  
audio with specific labels. That is a change in human interpretation,  
not a change in how the bits are decoded. The same 7 or 8 channels of  
audio data are still created exactly the same. There is no reason to  
even revise the version number for this, beyond simply revving to  
1.2.2 as would happen anyway.

A more useful addition would be a standard meta data chunk that could  
expand beyond the existing channel count variations. For example, 4- 
channel FLAC could be marked to distinguish L/R/BL/BR (default) from  
L/R/C/S (another very common arrangement). 5.1 FLAC could be marked  
to distinguish alternate orders, assuming we find prevalent formats  
in the field that have an order different from L/R/C/LFE/SL/SR. And  
the 7 and 8-channel FLACs could be marked to define the channel order.


In the professional world of surround, there are standards for  
shipping around 8-track digital tapes of 5.1+stereo or 7.1 masters,  
and there is simply a convention for the channel order that is  
written down and documented. This is nothing more than meta data.  
It's appropriate to formalize a way of storing this meta data in the  
FLAC using the existing extension chunks that have been part of the  
standard since the beginning.

Brian Willoughby
Sound Consulting

p.s. Note that the addition of meta data chunks to support non-audio  
WAVE and AIFF chunks in a FLAC archive using the application block  
types of 'riff' and 'aiff' respectively. As far as I recall, the FLAC  
format revision was not bumped when this support was added, even  
though it was a massive feature.