I had understood that as an indication of Neutron using floating point internally ( because otherwise it wouldn't make much sense to want to output in that format in the first place ).
A big problem with FRC and AGP
Re: A big problem with FRC and AGP
Re: A big problem with FRC and AGP
@Astell Rozen, DSP in Neutron is fully floating point. By default it is 32-bit fp but if you switch on 64-bit Processing it becomes fully true 64-bit fp. So, headroom is really large.
> Also, in the current situation the preamp slider in FRC may confuse new users who apply AutoEQ profiles and hear distortion no matter how low the preamp they set.
Yes, but here Preamp is inherited from EQ DSP (FRC is really an EQ but placed additionally in the tail of the DSP chain).
I still think that the control of overloading with AGP should embrace FRC, just in case somebody misconfigures EQ, Preamp + FRC with its Preamp. In the end we anyway must get non overloaded sound but if it is detected then it is a problem and it is better to allow an action from AGP rather than get overloaded, harsh sound as output.
Spectrum though should not take into account a processing done by FRC? But on the other hand it is what user gets on output (true signal representation). Therefore there is still a dilemma.
> Also, in the current situation the preamp slider in FRC may confuse new users who apply AutoEQ profiles and hear distortion no matter how low the preamp they set.
Yes, but here Preamp is inherited from EQ DSP (FRC is really an EQ but placed additionally in the tail of the DSP chain).
I still think that the control of overloading with AGP should embrace FRC, just in case somebody misconfigures EQ, Preamp + FRC with its Preamp. In the end we anyway must get non overloaded sound but if it is detected then it is a problem and it is better to allow an action from AGP rather than get overloaded, harsh sound as output.
Spectrum though should not take into account a processing done by FRC? But on the other hand it is what user gets on output (true signal representation). Therefore there is still a dilemma.
Re: A big problem with FRC and AGP
Well, then I suggest keep things safe - let's eitherdmitrykos wrote: ↑Mon Jan 10, 2022 11:21 amI still think that the control of overloading with AGP should embrace FRC, just in case somebody misconfigures EQ, Preamp + FRC with its Preamp. In the end we anyway must get non overloaded sound but if it is detected then it is a problem and it is better to allow an action from AGP rather than get overloaded, harsh sound as output.
Spectrum though should not take into account a processing done by FRC? But on the other hand it is what user gets on output (true signal representation). Therefore there is still a dilemma.
- make the pos-amp a real pre-amp and get the data for both AGP and Spectrum Analyzer after FRC
or
- keep the pre-amp implemented as a pos-amp and get the data after ( pos-amp + Master Software Volume ) but before bit-level-reduction
so that FRC is covered by AGP, and Spectrum Analyzer consistently reports what AGP checks.
And should someone complain that an incorrectly set FRC-preamp gets corrected via AGP with the EQ-preamp ... well, so what . And should the maximum allowed level of complexity for a music player app allow for another option one could even make the point where the data is extracted optional - either as described above or before the FRC, in which case AGP and Spectrum would ignore FRC.
Re: A big problem with FRC and AGP
> - make the pos-amp a real pre-amp and get the data for both AGP and Spectrum Analyzer after FRC
I propose to use this approach as it allows protection from overloaded sound done by AGP. User will then notice that AGP is triggering Preamp and will try to fix FRC. Showing Spectrum for FRC maybe useful too, if for example user adjusts it based on pink noise which is equal for all frequencies.
E.g. we do not touch current implementation.
I propose to use this approach as it allows protection from overloaded sound done by AGP. User will then notice that AGP is triggering Preamp and will try to fix FRC. Showing Spectrum for FRC maybe useful too, if for example user adjusts it based on pink noise which is equal for all frequencies.
E.g. we do not touch current implementation.
Re: A big problem with FRC and AGP
It seems this hasn't been solved by the new 2.18.5-5
Re: A big problem with FRC and AGP
Is being corrected, the developer sent a test version, works well.
Re: A big problem with FRC and AGP
Has been fixed in 2.19
Who is online
Users browsing this forum: No registered users and 28 guests