[vlc-devel] [PATCH V3 2/4] aout: add "audio-bitexact" option

[Rémi Denis-Courmont]

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?

Same issue for up-mixing.

The only clear case is sample format conversion.

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

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20191210/38db4a28/attachment.html>