Op vr 17 dec. 2021 om 12:43 schreef Michael Niedermayer
:
> > +sub->coefs[i] = sub->coefs[i]*0.98;
>
> This is ugly, the amount of actual overflow should be known at this point
> so no arbitrary downscale should be needed here
On Thu, Dec 16, 2021 at 08:43:21PM +0100, Martijn van Beurden wrote:
[...]
> @@ -972,7 +1007,25 @@ static int encode_residual_ch(FlacEncodeContext *s, int
> ch)
> for (i = 0; i < sub->order; i++)
> sub->coefs[i] = coefs[sub->order-1][i];
>
> -if (s->bps_code * 4 + s->options.
On Thu, Dec 16, 2021 at 10:09:13PM +0100, Paul B Mahol wrote:
> use wavpack, this is bad patch.
the flac specification supports 32bit
"FLAC supports from 4 to 32 bits per sample"
so theres nothing fundamental wrong with adding 32bit support
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B14
Could you please explain what makes this a bad patch, so I can try to
improve it?
Wavpack was already suggested, but using FLAC for archival is
preferred because the FLAC standard is currently in the process of
becoming an IETF RFC.
Op do 16 dec. 2021 om 22:09 schreef Paul B Mahol :
>
> use wavpa
use wavpack, this is bad patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
This commit makes ffmpeg create FLAC files with up to 32 bits-per-sample,
up from the previous limit of 24 bit. This is because of a feature request
to RAWcooked, apparently the archiving community has a need for storing
files with 32-bit integer audio samples.
See https://github.com/MediaArea/RAW
