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 >
This could make sense indeed. I suppose this is not a libFlac feature and that I should end up using libogg and or adding myself basic ogg support in order to support that ? Thanks ! 2017-01-28 7:37 GMT+01:00 Brian Willoughby <brianw at audiobanshee.com>:> 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 > > >-- Olivier Tristan Research & Development www.uvi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20170128/00a3adf4/attachment.html>
Olivier Tristan wrote:> This could make sense indeed. > I suppose this is not a libFlac feature and that I should end up using > libogg and or adding myself basic ogg support > in order to support that ?libFLAC supports writing a single FLAC stream to an OGG container. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/