Op di 2 jun. 2020 om 05:59 schreef Con Kolivas :
> It would be nice if the flac container was
> extensible to any arbitrary value for research purposes.
>
Probably not the answer that you were hoping for, but because it is only
for research purposes, why not store the samplerate outside of the
co
Isn't the FLAC encoder 'tuned' for the compression of audio data at
common sample rates anyway? Does it make sense to use FLAC to compress
arbitrary analog data at very high sample rates as opposed to other
general purpose compression algorithms?
Tor
Am 25.06.2020 um 14:49 schrieb Martijn van
To me the real question is not whether that portion of the spec has been
implemented by any existing encoders/decoders but whether the spec is
broken (i.e. cannot be implemented as written). I don't know the rationale
for making the LPC shift explicitly signed. In C a negative shift is
undefined an
On Thu, 25 Jun 2020 at 23:11, Tor-Einar Jarnbjo wrote:
>
> Isn't the FLAC encoder 'tuned' for the compression of audio data at common
> sample rates anyway? Does it make sense to use FLAC to compress arbitrary
> analog data at very high sample rates as opposed to other general purpose
> compres
Op do 25 jun. 2020 om 14:09 schreef Stephen F. Booth :
> To me the real question is not whether that portion of the spec has been
> implemented by any existing encoders/decoders but whether the spec is
> broken (i.e. cannot be implemented as written).
>
We will never know for sure whether any exi
Tor-Einar Jarnbjo writes:
> Does it make sense to use FLAC to compress arbitrary analog data at
> very high sample rates as opposed to other general purpose compression
> algorithms?
As a data point on this, the ld-decode project uses FLAC to compress
40MHz samples of LaserDisc RF, which are a c
Op do 25 jun. 2020 om 16:02 schreef Con Kolivas :
> The idea is to actually use it for playback, not just storage, and
> nothing else has the nice asymmetrical fast decompression with such
> effective compression (wavpack supports 705/768 but is woefully slow
> on decompression and poorly supporte
On Fri, 26 Jun 2020 at 00:37, Martijn van Beurden wrote:
>
> Op do 25 jun. 2020 om 16:02 schreef Con Kolivas :
>>
>> The idea is to actually use it for playback, not just storage, and
>> nothing else has the nice asymmetrical fast decompression with such
>> effective compression (wavpack supports
Progress. A simple hack to allow bitrates above 655350 seemed to work
fine for encoding, and the standard reference decoder library decoded
it fine. I'm not sure then in the documentation why it says "the
maximum sample rate is limited by the structure of frame headers to
655350Hz". Perhaps this br
I am also philosophically opposed to changing the specification.
That said, there's nothing wrong with adding a note to the specification about
the common implementations, particularly the reference library. Then, future
developers will know both the precise specification and still have the warn
On Fri, 26 Jun 2020 at 05:15, Brian Willoughby wrote:
> That said, there's nothing wrong with adding a note to the specification
> about the common implementations, particularly the reference library. Then,
> future developers will know both the precise specification and still have the
> warni
11 matches
Mail list logo
