On Tue, Apr 05, 2022 at 11:41:12AM +0200, Martijn van Beurden wrote:
> Extrapolating from these results, it seems unlikely that increasing
> the residual limit beyond a 32-bit int would bring significant
> compression improvement for music sources.
Interesting. I wasn't expecting that. I tried
Op vr 1 apr. 2022 om 09:19 schreef Martijn van Beurden :
> I'll start working on a patch to include stereo decorrelation and
> handling fixed subframes for 32-bit FLAC in both decoder and encoder
> to do some more testing. It seems that those two changes are worth the
> extra encoding and decoding
Op wo 30 mrt. 2022 om 16:02 schreef Martijn van Beurden :
> One added advantage of setting both limits for 32-bit encodings (not
> allowing stereo decorrelation and limiting residuals to 32-bit) is
> that libFLAC from 1.2.1 onwards and ffmpeg since May 2015 are
> "forward-compatible". ffmpeg
Op do 31 mrt. 2022 om 09:23 schreef Miroslav Lichvar :
> Can you post some examples of the impact on compression ratio? Do the
> samples actually use all of the 32 bits? I have no experince with
> this.
I did some tests with ffmpeg with the patch I linked earlier. This
patch limits the residuals
On Wed, Mar 30, 2022 at 04:02:11PM +0200, Martijn van Beurden wrote:
> Granted, it won't provide the best possible compression, but 32-bit
> PCM is itself already an extremely inefficient format. So I think the
> choice here is between slightly better compression and a simpler
> encoder versus
Op wo 30 mrt. 2022 om 11:03 schreef Miroslav Lichvar :
> I think that should apply only to <=24 bits. If I understand it
> correctly, with 32 bits it would be a real limitation, not hit only
> with specifically crafted encodings.
>
> [...]
>
> No, that doesn't seem acceptable to me.
>
One added
On Tue, Mar 29, 2022 at 04:57:10PM +0200, Martijn van Beurden wrote:
> Op di 29 mrt. 2022 om 11:43 schreef Miroslav Lichvar :
> > The third option makes most sense to me. I don't think we should
> > complicate decoders by requiring them to support 64-bit residuals only
> > because it's technically
Op di 29 mrt. 2022 om 11:43 schreef Miroslav Lichvar :
> The third option makes most sense to me. I don't think we should
> complicate decoders by requiring them to support 64-bit residuals only
> because it's technically possible to encode such a stream.
Would you argue this limitation is
On Thu, Mar 24, 2022 at 05:05:02PM +0100, Martijn van Beurden wrote:
> 3) Add a note to the FLAC spec that residuals should not exceed
> 32-bit, and add a mechanism to the encoder to ascertain this. In case
> the encoder finds a residual exceeding the 32-bit range, it defaults
> to using a
Op do 24 mrt. 2022 om 18:01 schreef Brian Willoughby :
>
> Can you briefly explain the consequences of this unexpected residual?
>
Of course. The WAV file I've used now does not cause problems when
compressed with any release version of libFLAC as far as I can tell.
For now, this is more of a
Can you briefly explain the consequences of this unexpected residual?
Will a 24-bit crafted file be compressed in a lossy way?
Are there tests in the FLAC suite that would reveal this?
Can we add such a crafted 24-bit file to the test suite?
When would the new _ultrawide variants of existing
Hi Martijn,
I just want to thank you for your thoughtful attention to these details.
Much appreciated!
Jim
On Thu, March 24, 2022 9:05 am, Martijn van Beurden wrote:
> Hi all,
>
>
> I just filed an issue on github:
> https://github.com/xiph/flac/issues/306 Long story
12 matches
Mail list logo
