Federico Miyara wrote: > Fact is that FLAC is highly economical in items such as reserving 20 > bits for sampling rate or 3 bits in the middle of the middle of a > byte for number of channels (which are, in fact, currently too few > for applications such as beamforming that use arrays of several dozen > microphones), so the next logical amount could easily be 40 bits, > which would suffice for 50 h recording at 192 kHz / 32 bits / 8 > channels; or even 48 bit, which allows for 1.5 year recordings (not > unlikely, however, in long-term soundscape continuous recordings). > > If the file turns to be that huge, an efficient search would demand > probably quite a few seek points, perhaps about 0.01 % the sample > count, which might involve a huge amount of extra bytes because of > this choice (4 bytes per seek point, assuming 64 bit instead of 48 above). > > I don't find this explanation convincing enough. May be there is > another reason that just reserving space for the far far future?
There are two issues; how to represent file offsets in the software and how to represent them in a FLAC file. Representing file offsets in the software as 64 bits is a must for the reasons explained in this thread. Could there be a more space efficient way of storing those offsets in a FLAC file if most of the upper bits are zero most of the time? Yes, but this was a design decision made long before I became the main FLAC maintainer and changing this now would harm interoperability with existing files and players (including hardware ones). Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev