From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id E6522450EE for ; Fri, 6 Jan 2023 17:25:17 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B1FB668BCF0; Fri, 6 Jan 2023 19:25:14 +0200 (EET) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 288FD68BB81 for ; Fri, 6 Jan 2023 19:25:08 +0200 (EET) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id 67A5FC000A for ; Fri, 6 Jan 2023 17:25:07 +0000 (UTC) Date: Fri, 6 Jan 2023 18:25:06 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230106172506.GG4028235@pb2> References: <20230105205342.GE4028235@pb2> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH] libswresample: avoid s16p internal processing format X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============0161919151065958791==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============0161919151065958791== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JI+G0+mN8WmwPnOn" Content-Disposition: inline --JI+G0+mN8WmwPnOn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 05, 2023 at 11:08:25PM +0100, Paul B Mahol wrote: > On Thu, Jan 5, 2023 at 9:53 PM Michael Niedermayer > wrote: >=20 > > On Thu, Jan 05, 2023 at 01:44:10PM +0100, Paul B Mahol wrote: > > > Patch attached. > > > > > swresample.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > eee7a0685b44aa867562138a2e2437ecb8844612 > > 0001-libswresample-swresample-avoid-s16p-internal-transfe.patch > > > From 9c4cd60e2dd41cf98d693c8251f4cfade0807073 Mon Sep 17 00:00:00 2001 > > > From: Paul B Mahol > > > Date: Thu, 5 Jan 2023 13:40:12 +0100 > > > Subject: [PATCH] libswresample/swresample: avoid s16p internal transf= er > > format > > > > > > Instead use float one by default for sample rate conversions. > > > The s16p internal transfer format produces visible and hearable > > > quantization artifacts. > > > > When does this occur and why? > > >=20 > It occurs always. Just compare output with 16bit and int32/float/double. > Look at other people report on internet. > Look at src.infinitewave.ca src.infinitewave.ca uses 32bit none of what it shows should touch the codep= ath you change. if we look at src.infinitewave.ca for swr we see 2 types of artifacts 1. Aliassing which is at maybe -120db with the actual signal at 0db i would like to see some evidence that a human can hear this 2. Reflection and attenuation at the transition frequency With linear filters there is a tradeof between attenuation of the passband, reflection of frequencies beyond, latency and so on You can have a perfect sharp cutoff with no attenuation and no refelection that requires a infinitly long filter. And while this looks best in this frequency plot, does it actually sound best ? If you can hear -120db signals you surely would then also hear the ringing long before a gunshot =66rom such long filter. also what actually is the optimal frequency response of this filter ? with a 22khz cutoff, a 22.1khz sine should be silence is that really subjectively better than a 21.9khz sine ? Iam not sure about this. Has someone done actual hearing tests with actual real audio? the sinc filter originates from the idea of lossless reconstruction of frequencies below nyquist if iam not mistaken, but humans are not trying to losslessly restore a block of frequencies. A human listen= er generally wants to enjoy listening to some media. Has someone looked into what is actually best for that real use case ? This question matters because with it we can tune the filter parameters to target humans. But lets push the doubts about choosing resampling purely based on frequency analysis away. swresample has several parameters with which you can tune this: we have a filter_size, if thats bigger you should get closer to the ideal sinc. Theres phase_shift which may reduce the (i assume) unhearable aliasin= g.=20 And cutoff which should allow to tune the (i assume) hearable=20 reflection/attenuation tradeoff also theres filter_type to allow you to tun= e the window function.=20 If there are issues reported by people using their ears, please provide more details, iam interrested in these cases. >=20 >=20 > > This change should be limited to the case that benefits, this would for= ce > > this > > even without resampling in some cases. > > >=20 > It is forced only if sample rates between input and output differs. If iam not mistaken it affects rematrixing without resampling too thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once" - "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew .= =2E." --JI+G0+mN8WmwPnOn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCY7hZawAKCRBhHseHBAsP q6UjAJ9dbWNHrRL9/w0V3JQ1//um6c0olQCgh1AaVBDGZmx4NATxIn0/Yk7cR7c= =5eAC -----END PGP SIGNATURE----- --JI+G0+mN8WmwPnOn-- --===============0161919151065958791== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". --===============0161919151065958791==--