flac dev - Jan 2013 - Tag flac as flac 1.2.1_git

On Jan 12, 2013, at 05:30, Martijn van Beurden wrote:
> On 12-01-13 08:23, pyth.flac-dev.5.pyt at spamgourmet.com wrote:
>> I seem to recall that changes in the second number indicated a minor
>> change in the *format* of the file itself (for example, 1.1.x to  
>> 1.2.x
>> introduced a new rice coding option used for 24-bit files).
>
> Well, the only change in format that might be merged before the next
> release that I know of is the definition of the mapping of 7- and
> 8-channel audio. As these were previously unmapped, this would qualify
> to be a minor format change, as previous decoders won't decode 1.3.x
> files properly (as they don't map channels for 7 and 8 channel audio)

I strongly recommend against changing the format just to allow  
alternate labels for the same number of channels. The goal of channel  
mapping would be better served by defining meta data that would be  
legal for any 1.x file. Sorry I didn't say anything sooner regarding  
the proposed changes.


There are very good reasons not to revise the format version.

First of all, channel mapping happens entirely external to FLAC. No  
matter how precisely the channels are labeled, it is still possible  
for playback to happen incorrectly if the audio system is not also  
configured. For that matter, someone could play a 7.1 FLAC on a  
stereo system, and it would certainly not be mapped correctly in that  
case, no matter what version of FLAC file.

Second of all, the proposed changes are just being more specific  
about the 4, 5, and 6-channel variants, while adding definitions for  
7, and 8-channel variants. Nothing about the decoding process is  
affected by these human descriptions. Only the playback engine  
external to flac would be affected, and those details can be assumed.  
The order of 4, 5, and 6-channel FLAC files does not change - Ralph  
merely suggested being specific in labeling the front channels  
instead of just saying "left" and "right." Adding
specifications for
7, and 8-channel formats does not prevent a playback system from  
correctly decoding a 1.2.1 or earlier file and getting the channels  
right, provided that meta data is defined to facilitate this or even  
if the operator configures their system with care.


Bottom line: Channel labels are no reason to alter the version number  
of FLAC, and certainly not a reason to break backward and forward  
compatibility with all of the hardware devices that have already  
shipped with 1.2.x decoders. That said, we should put our heads  
together to come up with a new METADATA_BLOCK that could describe  
existing channel layouts as well as any variations that might be seen  
in the field.

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.

Brian Willoughby
Sound Consulting

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.

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.

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

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.