On Jan 12, 2013, at 05:30, Martijn van Beurden wrote: > On 12-01-13 08:23, pyth.flac-dev.5....@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 _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
