[flac-dev] Tag flac as flac 1.2.1_git

Brian Willoughby
Sat, 12 Jan 2013 21:46:22 -0000

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