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 severa
Dear Erik,
>Its not that we need space for 7616 years, its that if we only use
>32 bit offsets, then we would be limited to files of 2 Gigabytes
>(signed 32 bit integer) is simply not enough.
>
>For instance, at 96kHz/24 bits, recording 8 channels would chew up
>the 2Gigabytes in about 15 minutes
Federico Miyara wrote:
> Thanks for your answer.
>
> >Well, today 4 GiB is about half an hour of 8-channel, 96 kHz, 24-bit
> >uncompressed audio, or about 0.9 % of the capacity of a modest 2 TB
> >HDD. Not much, in other words, and who hasn't cursed yet at artificial
> >4 GiB (or even 2 GiB) limi
Dear Ulrich,
Thanks for your answer.
>Well, today 4 GiB is about half an hour of 8-channel, 96 kHz, 24-bit
>uncompressed audio, or about 0.9 % of the capacity of a modest 2 TB
>HDD. Not much, in other words, and who hasn't cursed yet at artificial
>4 GiB (or even 2 GiB) limitations? So I wouldn'
Federico Miyara wrote:
> I would like to ask why the seekpoint information in the seek table
> metadata block reserves 64 bit for the number of first sample in
> target frame and for the offset of the first byte of target frame.
>
> It seems to me a lot, since 2^64 = 1.84e+19, i.e., far more sampl
Dear Friends,
I am new to this mailing list. I am with the National University of
Rosario, Argentina, and I am writing a book on software-based
acoustical measurements, which includes a chapter on FLAC for
archival and streaming purposes from an remote embedded system
including a sensor.
I w
