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. _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
