Federico Miyara wrote: ...> The file format allows some unused fields for future use, such as the > padding block. It could include a flag to indicate a change in the > format adding one more streaminfo byte which would allow up to 256 > channels (actually, 256 + 8), or it could trigger a new byte when 11111111. > > There is also an invalid block identifier (127) which could be used with > the same purpose.The problem isn't *just* the 3-bit field used for the number of channels. As Brian Willoughby explained: ...>> As you cram more channels into a block, you get fewer samples per block for >> each individual channel. There simply isn't any advantage to having lots of >> channels in a single stream. >> >> I believe that Ogg allows you to create a file that interleaves multiple >> FLAC files.Perhaps comparing FLAC with the Ogg container and Vorbis codec will aid understanding. With Ogg, different streams can be either chained (sequential) or grouped (parallel/interleaved). Typically, metadata streams would be chained (so they appear before any audio data) and audio streams would be grouped. Within a single FLAC stream the audio is split into blocks which are grouped. But within each block the eight channels are chained. This makes sense with a maximum of only eight channels. Within a Vorbis stream the audio is split into frames which are grouped. Because a Vorbis stream can contain up to 256 channels, within each frame the channels are also grouped. So the maximum of eight channels is really embedded into the FLAC standard. To change this would require a whole new standard (or the use of multiple grouped FLAC streams in an Ogg container). Regards, Martin -- Martin J Leese E-mail: martin.leese stanfordalumni.org Web: http://members.tripod.com/martin_leese/
Thanks everybody for their answer. This is quite unfortunate for me, but hey, that's life. I will probably end up doing some multi mono bundle similar to what Protools did back in the days with its .L .R files ++ Le 26/01/2017 à 18:58, Martin Leese a écrit :> Federico Miyara wrote: > ... >> The file format allows some unused fields for future use, such as the >> padding block. It could include a flag to indicate a change in the >> format adding one more streaminfo byte which would allow up to 256 >> channels (actually, 256 + 8), or it could trigger a new byte when 11111111. >> >> There is also an invalid block identifier (127) which could be used with >> the same purpose. > The problem isn't *just* the 3-bit field used for > the number of channels. As Brian Willoughby > explained: > ... >>> As you cram more channels into a block, you get fewer samples per block for >>> each individual channel. There simply isn't any advantage to having lots of >>> channels in a single stream. >>> >>> I believe that Ogg allows you to create a file that interleaves multiple >>> FLAC files. > Perhaps comparing FLAC with the Ogg > container and Vorbis codec will aid > understanding. > > With Ogg, different streams can be either > chained (sequential) or grouped > (parallel/interleaved). Typically, metadata > streams would be chained (so they appear > before any audio data) and audio streams > would be grouped. > > Within a single FLAC stream the audio is > split into blocks which are grouped. But within > each block the eight channels are chained. > This makes sense with a maximum of only > eight channels. Within a Vorbis stream the > audio is split into frames which are grouped. > Because a Vorbis stream can contain up to > 256 channels, within each frame the channels > are also grouped. > > So the maximum of eight channels is really > embedded into the FLAC standard. To change > this would require a whole new standard (or > the use of multiple grouped FLAC streams in > an Ogg container). > > Regards, > Martin-- Olivier Tristan Research & Development www.uvi.net
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. Brian Willoughby On Jan 27, 2017, at 12:55 AM, Olivier Tristan <o.tristan at uvi.net> wrote:> Thanks everybody for their answer. > > This is quite unfortunate for me, but hey, that's life. > > I will probably end up doing some multi mono bundle similar to what Protools did back in the days with its .L .R files > > Le 26/01/2017 à 18:58, Martin Leese a écrit : >> Federico Miyara wrote: >> ... >>> The file format allows some unused fields for future use, such as the >>> padding block. It could include a flag to indicate a change in the >>> format adding one more streaminfo byte which would allow up to 256 >>> channels (actually, 256 + 8), or it could trigger a new byte when 11111111. >>> >>> There is also an invalid block identifier (127) which could be used with >>> the same purpose. >> The problem isn't *just* the 3-bit field used for >> the number of channels. As Brian Willoughby >> explained: >> ... >>>> As you cram more channels into a block, you get fewer samples per block for >>>> each individual channel. There simply isn't any advantage to having lots of >>>> channels in a single stream. >>>> >>>> I believe that Ogg allows you to create a file that interleaves multiple >>>> FLAC files. >> Perhaps comparing FLAC with the Ogg >> container and Vorbis codec will aid >> understanding. >> >> With Ogg, different streams can be either >> chained (sequential) or grouped >> (parallel/interleaved). Typically, metadata >> streams would be chained (so they appear >> before any audio data) and audio streams >> would be grouped. >> >> Within a single FLAC stream the audio is >> split into blocks which are grouped. But within >> each block the eight channels are chained. >> This makes sense with a maximum of only >> eight channels. Within a Vorbis stream the >> audio is split into frames which are grouped. >> Because a Vorbis stream can contain up to >> 256 channels, within each frame the channels >> are also grouped. >> >> So the maximum of eight channels is really >> embedded into the FLAC standard. To change >> this would require a whole new standard (or >> the use of multiple grouped FLAC streams in >> an Ogg container). >> >> Regards, >> Martin >