feature request: better Audio default
Posted: Wed Jan 04, 2017 8:25 am
Hi,
I used Handbrake now for several years (only the stable releases, I have not the time to track down bugs, I need to convert films daily), its good and works well and most improvements are good.
Today it told me to update to 10.0.1 (I still was running 0.95 or something), so it freed me from my beloved personal presets and I had to redo them. I personally find the predefined presets a bit "strange", especially when you keep in mind that Handbrake comes from Europe and there is not even a single HD/HQ Preset that will work here...
But let's move on to the really annoying stuff, the Audio default page....
Since many years this has not really changed much, its... sorry to say: BAD, illogical and pretty much useless.
You are not able to define a halfway sane preset that fits for most of the input. You always end up to do manual adjustments for every film you convert because the preset is too much limited in choices. Thats quite the opposite of what you need for massive batch production.
What I like to see would be something like this:
* define a "everything else" (or call it "default" ) setup that is used if none of the special cases (see "rules" defined later) applies. lets say
"AAC, 160kbits, Dolby Sourround II" encoding
* add "unknown" to the list of languages ("unknown" is NOT "any"!!!)
* define a set of wanted languages (like now)
* add a new list with "rules" that can be defined:
1) language (or ANY, which means any from the global language list defined before)
2) input format, but this time much more detailed like "AC3-2channels" "AC3-5.1channel" or at least "???-stereo" and "???-surround" for more than 2channels) or "???" for "I don't care how many channels" (or 2 seperate rows, one for the Format and one for the # of channels)
3) action ("" -> use global default, "copy" -> Passthru, "convert" -> use output format defined in (4)
4) output format (or DEFAULT for the global default) or empty/ignored if 3 is not "copy"
5) (optional) if 3 is "copy" relabel to a selected language too (*)
the choices are limited enough so simple listboxes could be used that allow the user to quickly define a rule by just clicking.
This would allow much more complex constructs like:
"for any language convert all DTS to Dolby Digital, 448kbits, 5.1 channels"
"for english AC3-stereo convert all to AAC, 160kbit/s, 2 channels, stereo encoding"
"for german AC3-surround copy"
"for french AC3-surround convert all to AAC, 160kbit/s, 2 channels, Dolby-Surround-II encoding"
"for MP3" (-> use global default)
(*) the "relabel" is good for TV-Stations like ARTE for instance. The german ARTE contains an "unknown" AC5.1, a "ger" MPEG, a "fra" MPEG and a "misc" MPEG. If I wanted to keep the german 5.1 and the french MPEG, I would need these rules:
a) for UNKNOWN AC3-surround copy relabel to "ger"
b) for french MPEG convert all to AAC, 160kBit/s, 2 channels, stereo"
(the "relabel" cannot be a command by its own, else it would be evaluated later on and it also would break the global rule that the first matching rule ends the evaluation. So it has to be an optional appendix to a command like "copy". But if people would want it elsewhere too, it would complicate the GUI and the program too much, then better drop it for the sake of simplicity)
Execution Phase:
1) Rules should be evaluated from top to bottom. Therefor the GUI needs some Up/Down Buttons for the entries so the User can change the number of that particular rule.
2) The first match "wins" and exits the loop.
3) If no rule matches, the global default is implicitly applied
This is straight and simple and I guess, it also will help to develop easy to understand manual pages.
With a litte efford one could define a complete set for his needs allowing Handbrake really to be used in a unmonitored batch operation
I think, this approach would be much more straight, than the current one that needs a lot of try & error just to find out at the end that that what you really need to have is not possible with the current Handbrake.
And I also am quite sure that it would not be too much complicated to be implemented.
I used Handbrake now for several years (only the stable releases, I have not the time to track down bugs, I need to convert films daily), its good and works well and most improvements are good.
Today it told me to update to 10.0.1 (I still was running 0.95 or something), so it freed me from my beloved personal presets and I had to redo them. I personally find the predefined presets a bit "strange", especially when you keep in mind that Handbrake comes from Europe and there is not even a single HD/HQ Preset that will work here...
But let's move on to the really annoying stuff, the Audio default page....
Since many years this has not really changed much, its... sorry to say: BAD, illogical and pretty much useless.
You are not able to define a halfway sane preset that fits for most of the input. You always end up to do manual adjustments for every film you convert because the preset is too much limited in choices. Thats quite the opposite of what you need for massive batch production.
What I like to see would be something like this:
* define a "everything else" (or call it "default" ) setup that is used if none of the special cases (see "rules" defined later) applies. lets say
"AAC, 160kbits, Dolby Sourround II" encoding
* add "unknown" to the list of languages ("unknown" is NOT "any"!!!)
* define a set of wanted languages (like now)
* add a new list with "rules" that can be defined:
1) language (or ANY, which means any from the global language list defined before)
2) input format, but this time much more detailed like "AC3-2channels" "AC3-5.1channel" or at least "???-stereo" and "???-surround" for more than 2channels) or "???" for "I don't care how many channels" (or 2 seperate rows, one for the Format and one for the # of channels)
3) action ("" -> use global default, "copy" -> Passthru, "convert" -> use output format defined in (4)
4) output format (or DEFAULT for the global default) or empty/ignored if 3 is not "copy"
5) (optional) if 3 is "copy" relabel to a selected language too (*)
the choices are limited enough so simple listboxes could be used that allow the user to quickly define a rule by just clicking.
This would allow much more complex constructs like:
"for any language convert all DTS to Dolby Digital, 448kbits, 5.1 channels"
"for english AC3-stereo convert all to AAC, 160kbit/s, 2 channels, stereo encoding"
"for german AC3-surround copy"
"for french AC3-surround convert all to AAC, 160kbit/s, 2 channels, Dolby-Surround-II encoding"
"for MP3" (-> use global default)
(*) the "relabel" is good for TV-Stations like ARTE for instance. The german ARTE contains an "unknown" AC5.1, a "ger" MPEG, a "fra" MPEG and a "misc" MPEG. If I wanted to keep the german 5.1 and the french MPEG, I would need these rules:
a) for UNKNOWN AC3-surround copy relabel to "ger"
b) for french MPEG convert all to AAC, 160kBit/s, 2 channels, stereo"
(the "relabel" cannot be a command by its own, else it would be evaluated later on and it also would break the global rule that the first matching rule ends the evaluation. So it has to be an optional appendix to a command like "copy". But if people would want it elsewhere too, it would complicate the GUI and the program too much, then better drop it for the sake of simplicity)
Execution Phase:
1) Rules should be evaluated from top to bottom. Therefor the GUI needs some Up/Down Buttons for the entries so the User can change the number of that particular rule.
2) The first match "wins" and exits the loop.
3) If no rule matches, the global default is implicitly applied
This is straight and simple and I guess, it also will help to develop easy to understand manual pages.
With a litte efford one could define a complete set for his needs allowing Handbrake really to be used in a unmonitored batch operation
I think, this approach would be much more straight, than the current one that needs a lot of try & error just to find out at the end that that what you really need to have is not possible with the current Handbrake.
And I also am quite sure that it would not be too much complicated to be implemented.