<html><head></head><body>Even that is left for interpretation though. Resampling to a higher rate is (or rather, can be) lossless from entropy standpoint, i.e. potentially reversible. But it should probably not be allowed? Or should it?<br><br>Same issue for up-mixing.<br><br>The only clear case is sample format conversion.<br><br><div class="gmail_quote">Le 10 décembre 2019 09:22:11 GMT+02:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 2019-12-09 21:16, Remi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Le 2019-12-09 16:20, Thomas Guillem a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">If you do bit exact in aout, you don't have a filter chain.<br></blockquote> I could have used a boolean for the "audio-bitexact" option. In that<br> case, indeed, there is no need to use a filters chain.<br><br> But what about --audio-bitexact with an aout specific exclusive mode ?<br></blockquote>Hmm yeah, what about it?<br><br>First off, I am not convinced that we need a core flag at all. It seems <br>that the intended semantics are exactly the same as '--audio-filter= <br>--resampler=none --no-audio-time-stretch', which means that it already <br>works. And I don't think we should go actively out of our way to support <br>audiophile nonsense... just tell them how to configure it.<br><br>(Actually, it is not so much that audio-time-stretch should be disabled, <br>than that the playback rate should be fixed to 1, but I digress.)<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">People won't be able to play mp3 with these 2 modes enabled (FL32<br>decoder). Is that wanted ? And what about S16N when you have a S24N or<br>S32N soundcard ?<br></blockquote>Bit exact with a floating point format sounds like an oxymoron. AFAIK, <br>auto-proclaimed audiophiles use lossless formats which they expect to <br>decode as fixed point.<br><br>The discussion is turning in circle now. If the goal is to forcefully <br>fail if the audio decoder output _cannot_ be rendered in bit exact mode, <br>then we need a boolean flag. But if the goal is merely to minimise <br>filtering to necessary conversion, then I don't think we need much <br>anything?<br><br>In any case, I don't see why this needs to be exposed to the filter <br>chain; it should be exposed to the owner of the filter chain. And <br>conversely, I do see why it should not be exposed there: it's used in <br>different contexts some of which should not be affected by aout settings.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> Using "on"/"off" for "audio-bitexact" seems dubious. That is why I<br> would prefer using something like the following:<br><br> --audio-bitexact=0: default<br><br> --audio-bitexact=1: on (with one converter)<br></blockquote>Meaning format conversion only? Should only lossless format conversions <br>be allowed? What about (mathematically) exact rate-multiple up-sampling <br>(8k, 16k, or 24k to 48k, 11025 or 22050 to 44100)? ...<br></blockquote><br>I think there's even 2 kinds of conversions, the lossless ones and the <br>lossy ones (24 bits to 16 bits soundcard). Given the name <br>"audio-bitexact" the lossy ones should probably not be allowed or only <br>in the most permissive mode (0=default=off).<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> --audio-bitexact=2: strict (without any converters)<br><br> The big question is: should we remove 1 or 2 ?<br></blockquote>Again, I think we should really *not* go out of our way to support this. <br>Just make a boolean that refuses to convert and filter if somebody wants <br>one. We already have settings to turn filters off, but retain any <br>necessary conversions.<br><br>-- <br>Rémi Denis-Courmont<hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></blockquote><hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>