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/ _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev