[flac-dev] Tag flac as flac 1.2.1_git

[Brian Willoughby]

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