[flac-dev] Tag flac as flac 1.2.1_git

[Pierre-Yves Thoulon]

I second Brian's position on the matter, for what it's worth...

Pyt.




On Sun, Jan 13, 2013 at 12:46 AM, Brian Willoughby <brianw at sounds.wa.com>wrote:

>
> 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.
>


> [...]
>


> 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 at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20130113/eef1bc67/attachment.htm