<div dir="ltr">This could make sense indeed.<div>I suppose this is not a libFlac feature and that I should end up using libogg and or adding myself basic ogg support</div><div>in order to support that ?</div><div><br></div><div>Thanks !</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-01-28 7:37 GMT+01:00 Brian Willoughby <span dir="ltr"><<a href="mailto:brianw@audiobanshee.com" target="_blank">brianw@audiobanshee.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Don't overlook the FLAC in Ogg container solution. That's established as a standard for some time now, as far as I know, and would probably be better than a new, proprietary multi mono bundle. I haven't used it myself, but people have been talking about it for a while, and I believe that some "FLAC" users are actually working with FLAC in Ogg container files.<br>
<span class="HOEnZb"><font color="#888888"><br>
Brian Willoughby<br>
</font></span><span class="im HOEnZb"><br>
<br>
On Jan 27, 2017, at 12:55 AM, Olivier Tristan <<a href="mailto:o.tristan@uvi.net">o.tristan@uvi.net</a>> wrote:<br>
> Thanks everybody for their answer.<br>
><br>
> This is quite unfortunate for me, but hey, that's life.<br>
><br>
> I will probably end up doing some multi mono bundle similar to what Protools did back in the days with its .L .R files<br>
><br>
</span><div class="HOEnZb"><div class="h5">> Le 26/01/2017 à 18:58, Martin Leese a écrit :<br>
>> Federico Miyara wrote:<br>
>> ...<br>
>>> The file format allows some unused fields for future use, such as the<br>
>>> padding block. It could include a flag to indicate a change in the<br>
>>> format adding one more streaminfo byte which would allow up to 256<br>
>>> channels (actually, 256 + 8), or it could trigger a new byte when 11111111.<br>
>>><br>
>>> There is also an invalid block identifier (127) which could be used with<br>
>>> the same purpose.<br>
>> The problem isn't *just* the 3-bit field used for<br>
>> the number of channels.  As Brian Willoughby<br>
>> explained:<br>
>> ...<br>
>>>> As you cram more channels into a block, you get fewer samples per block for<br>
>>>> each individual channel. There simply isn't any advantage to having lots of<br>
>>>> channels in a single stream.<br>
>>>><br>
>>>> I believe that Ogg allows you to create a file that interleaves multiple<br>
>>>> FLAC files.<br>
>> Perhaps comparing FLAC with the Ogg<br>
>> container and Vorbis codec will aid<br>
>> understanding.<br>
>><br>
>> With Ogg, different streams can be either<br>
>> chained (sequential) or grouped<br>
>> (parallel/interleaved).  Typically, metadata<br>
>> streams would be chained (so they appear<br>
>> before any audio data) and audio streams<br>
>> would be grouped.<br>
>><br>
>> Within a single FLAC stream the audio is<br>
>> split into blocks which are grouped.  But within<br>
>> each block the eight channels are chained.<br>
>> This makes sense with a maximum of only<br>
>> eight channels.  Within a Vorbis stream the<br>
>> audio is split into frames which are grouped.<br>
>> Because a Vorbis stream can contain up to<br>
>> 256 channels, within each frame the channels<br>
>> are also grouped.<br>
>><br>
>> So the maximum of eight channels is really<br>
>> embedded into the FLAC standard.  To change<br>
>> this would require a whole new standard (or<br>
>> the use of multiple grouped FLAC streams in<br>
>> an Ogg container).<br>
>><br>
>> Regards,<br>
>> Martin<br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Olivier Tristan<div>Research & Development</div><div><a href="http://www.uvi.net" target="_blank">www.uvi.net</a></div></div></div>
</div>