<div dir="ltr">I second Brian's position on the matter, for what it's worth...<div><br></div><div>Pyt.<br><div class="gmail_extra"><br clear="all"><div><br></div>
<br><br><div class="gmail_quote">On Sun, Jan 13, 2013 at 12:46 AM, Brian Willoughby <span dir="ltr"><<a href="mailto:brianw@sounds.wa.com" target="_blank">brianw@sounds.wa.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Jan 12, 2013, at 14:28, Martijn van Beurden wrote:<br>
> On 12-01-13 22:46, Brian Willoughby wrote:<br>
>> I would suggest that everyone keep in mind the vast installed base of<br>
>> hardware FLAC recorders and players, and not senselessly make them<br>
>> obsolete without extremely compelling reasons.<br>
><br>
> This can be done for the same reason the change from 1.1 to 1.2<br>
> added a<br>
> new form of residue coding: I don't believe there are many 7 or 8<br>
> channel FLAC-players out there (just like there were not much 24-bit<br>
> FLAC decoding devices out there when 1.2 came out). We still are at a<br>
> point we can still make those changes.<br>
<br>
<br>
</div>The problem with your example is two-fold. First, residue coding<br>
affects the actual compressed audio data, but channel mapping does<br>
not. Second, there are 8-channel FLAC recorders out there, so it<br>
would be incredibly destructive to break compatibility for no reason<br>
at all.<br>
<div class="im"></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">[...]</div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the professional world of surround, there are standards for<br>
shipping around 8-track digital tapes of 5.1+stereo or 7.1 masters,<br>
and there is simply a convention for the channel order that is<br>
written down and documented. This is nothing more than meta data.<br>
It's appropriate to formalize a way of storing this meta data in the<br>
FLAC using the existing extension chunks that have been part of the<br>
standard since the beginning.<br>
<br>
Brian Willoughby<br>
Sound Consulting<br>
<br>
p.s. Note that the addition of meta data chunks to support non-audio<br>
WAVE and AIFF chunks in a FLAC archive using the application block<br>
types of 'riff' and 'aiff' respectively. As far as I recall, the FLAC<br>
format revision was not bumped when this support was added, even<br>
though it was a massive feature.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
flac-dev mailing list<br>
<a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/flac-dev" target="_blank">http://lists.xiph.org/mailman/listinfo/flac-dev</a><br>
</div></div></blockquote></div><br></div></div></div>