[flac-dev] Question from Argentina

[Erik de Castro Lopo]

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/