Janne Hyvärinen wrote:
> On 10.6.2013 22:27, Marcus Johnson wrote:
> > Also, shouldn't the changelog feature the 4GB windows fix? I remember
> > reading about that bug fix at the start of 1.3.0, and I for one was
> > incredibly excited about it.
> >
> > if nobody remembers it I can try to hunt d
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
Here's the patch submit message for 4GB+ windows barrier.
http://lists.xiph.org/pipermail//flac-dev/2013-March/003804.html
On Wed, Jun 12, 2013 at 3:00 PM, wrote:
> Send flac-dev mailing list submissions to
> flac-dev@xiph.org
>
> To subscribe or unsubscribe via the World Wide Web, vis
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 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:
> 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 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:
> 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
