Quote:
Originally Posted by Photon
Hi all,
I have been using LameXP for over a year - excellent program! However, I'm running into a bug when trying to encode using AAC (qaac 2.66). I don't encounter this problem with either OPUS, MP3 or Vorbis.
I'm currently using Version 4.16, Build 2134.
The problem is this: under the advanced settings tab, when inputting a custom encoding parameter for AAC (in this case, simply: "--tvbr 87") the encode fails, every time.
When inspecting the log, I figured out what the problem was:
As you can see, instead of replacing and overriding the default quality setting (--tvbr 91, which the slider is set to under the Compression tab), the custom setting that I want (--tvbr 87) is just appended to the command string, thus conflicting with the first setting. Naturally this means that the encode stops in its tracks before it can do anything. It throws up this message at the bottom:
Please let me know if you can replicate this. It's the only thing holding me back from using LameXP for AAC encoding (which is otherwise first class).
|
Well, the "custom" parameters are simply
appended to the command-line that is
generated automatically. And, of course, the
generated command-line must contain the switches for the selected RC mode.
If you try to set the RC mode via "custom" parameter
too, RC mode will unavoidably appear in the command-line
twice – as the program clearly says: "custom" parameters are
not validated and you use them at your own risk.
Most CLI tools will allow to specify even "conflicting" switches, in which case simply the
last option on the command-line will take effect. This way you can easily "override" options already set by the
generated command-line.
But: It appears that QAAC does more "pedantic" checking and won't allow to "override" the already-set RC mode.
There is
no easy solution for this, because we would need figure out any possible combination of "conflicting" options. And, if a "conflicting" option was detected, remove
that option from the
generated command-line...
(Maintaining a list of potentially "conflicting" options – for every supported encoder – would be a lot of work. Just to enable a use-case that was never really intended)