Feature-Request: ability to specify Vorbis by "-q", not kbps

Archive of historical feature requests.
Please use the GitHub link above to report issues.
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.

*******************************
Post Reply
Antryg
Posts: 2
Joined: Sat Dec 20, 2008 5:59 am

Feature-Request: ability to specify Vorbis by "-q", not kbps

Post by Antryg »

( note that I don't know if Theora makes that nonsensical, but I'm hoping-not
note-2: yes I've grepped the forum on Vorbis, and seen some comments about vbr creating loss of sync,
but don't know whether that was a primitive-implementation problem,
rather than a fatal design-engineering flaw in the OGG spec? )

I'd prefer to be able to specify -q 3 for my cheap put-it-on-the-net stuff, where bandwidth is going to kill my account, but
would prefer to specify -q 5 for good stuff and -q 8 for archival.

I'm asking after OGG stuff because being sued by MPEG IP patent corporations strikes me as a stupid career,
and ACTA still looks to become law
( making it *felony* to use mp4/m4v without proper pre-existing licensing, for each file-release, if I'm reading the impending law's gist right, and that'd cost $2.5k/file, after the free "free" time, if I could get 'em to agree to the free "free" time, to begin with! )

Currently HandBrakeCLI permits us to specify kbps for audio, but DOESN'T permit vbr Quality settings?

I don't *believe* that's a hard requirement of Theora
( never read about any such thing on any FAQ, and I do tend to read such things ),
and would prefer to spend bits *as necessary*,
rather-than by Policy ( wasting bandwidth sometimes, wasting quality other-times ).

So, Pretty-Please, can we have a Vorbis "-q" switch?
( with the Vorbis standard float, just to prevent the seeping-in of "bugs" when someone does a "-q 3.5" on it )

Thanks in advance,

( also, I read on Monty's blog, wherever that went ( lost it, a few weeks ago ),
that the svn/whatever version of Theora was WAY better than the released version,
but wasn't being tagged as a Release because the *mac* version relied on a buggy lib...

For the Lin/Win cli versions, would the *modern* Theora implementation be doable? .. if it isn't already, that is... )

Cheers, & Thanks In Advance,
Antryg
Posts: 2
Joined: Sat Dec 20, 2008 5:59 am

Re: Feature-Request: ability to specify Vorbis by "-q", not kbps

Post by Antryg »

nevermind: I since discovered that on openSUSE 11.0, even after replacing the Theora lib with Xiph, it isn't possible to encode a Theora file through HandBrake, that'll play through MPlayer-Packman.

Therefore I've switched to ffmpeg2theora, and behold, it has one tell it bitrate via -q switch, just like I wanted.

Sorry to have bothered youse,

Now to get back to my discovery of what compression is Just Right, for my source-material...
zak
Posts: 13
Joined: Tue Jun 02, 2009 5:33 pm

Re: Feature-Request: ability to specify Vorbis by "-q", not kbps

Post by zak »

Hi,

is this still not possible?
I would like to have this possibility, too. Or is there any workaround?


Thanks.
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: Feature-Request: ability to specify Vorbis by "-q", not kbps

Post by jbrjake »

We eagerly await your patch.

While relatively trivial, this change would be rather time-consuming and make work for Joe, John, Scott, Bonne/Gonza, and myself, as after you added the concept of audio quality levels to the audio configuration struct and implemented it in the CLI, it would still require additions to the preset system in order to handle it in the other interfaces. Not a high priority.
zak
Posts: 13
Joined: Tue Jun 02, 2009 5:33 pm

Re: Feature-Request: ability to specify Vorbis by "-q", not kbps

Post by zak »

Thanks for the quick answer.

Well I do not need the Presets and just work with the CLI, therefore a partly implemented feature which can at first just be used there would be fine for me.

But I will look at the code, maybe I will manage a quick-and-dirty hack for myself... (unlikely)
coconut
Posts: 6
Joined: Mon Jun 08, 2009 9:00 pm

Re: Feature-Request: ability to specify Vorbis by "-q", not kbps

Post by coconut »

Hi, I also want this pony (for all codecs, but especially Vorbis) and I'm working on it. If anybody is interested in helping me add support the Mac and/or Win GUI, or testing the feature with ca_aac, that would be awesome. At the moment I can only really develop and test under Linux.

I'm also wondering whether I should try to support target filesize mode with true VBR audio. IMHO it's a bizarre combination, but it's not crazy since the total bitrate is much larger than fluctuations in the audio bitrate... I'm also afraid it would be confusing if these options were mutually exclusive but belonged to different tabs in the GUI. My current approach is just to guess 160kbps, log a warning, and move on.

Thoughts are appreciated. :)
User avatar
JohnAStebbins
HandBrake Team
Posts: 5583
Joined: Sat Feb 09, 2008 7:21 pm

Re: Feature-Request: ability to specify Vorbis by "-q", not kbps

Post by JohnAStebbins »

I suggest you work on the CLI first. Get the core library working properly, then start discussions with all the ui developers as to how this is going to fit in the ui. The audio tab in the ui is crowded and I believe discussion of this will save you time in rework when we say we don't like what you did. :wink:
coconut
Posts: 6
Joined: Mon Jun 08, 2009 9:00 pm

Re: Feature-Request: ability to specify Vorbis by "-q", not kbps

Post by coconut »

(Updated 7/1: applies cleanly against r2654; CLI part requires a separate patch but allows mixing of --ab/--aq in a sensible way now.)

Thanks for the advice! Well, this patch set (against svn r2590) implements the relevant CLI switch:

Code: Select all

    --aq <float>            Set audio quality/qualities, in encoder's units
                            (default: use target bitrate instead)
I've split it into bite-sized incremental changes:
1-libhb-add-audio_config_t-out-quality.patch
2-encfaac-respect-quality.patch
2-enclame-respect-quality.patch
2-encvorbis-respect-quality.patch
2-encca_aac-respect-quality.patch
3-cli-accept-audio-quality-settings.patch
8 files changed, 170 insertions(+), 56 deletions(-)

Known problems:
  • I couldn't test with ca_aac.
  • The CLI switches aren't consistent, since -Q was already in use.
  • The average bitrate used isn't logged anywhere.
  • If you mux a VBR-encoded mp3 stream into an AVI, it will be unplayable. I think this is because we write audio headers in AVI files claiming an average bitrate of 0, since ABR encodes don't cause this problem. (We do the same with OGM, but that didn't bother mplayer a bit in my tests.)
  • hb_calc_bitrate() still tries to do its job if an audio output track is VBR, by guessing it will average 160kbps (and emit a warning that it's being dumb).
Bitrate logging isn't hard; I'm just not sure whether I could avoid copy-pasting the same thing--track the number of samples going in and bytes coming out--in 4 files. (LAME lets you query how many frames of each size were used, but that isn't much prettier.) The last 2 problems are fairly serious, but again I'm not sure whether it's better to fix them or just disable the broken feature combinations. :)

If any devs would like to work with me on the GUI bit of this, I can join the IRC channel in a bit. I do understand if you guys would rather work on higher-priority items, though.

Cheers!
Last edited by coconut on Wed Jul 01, 2009 11:28 pm, edited 1 time in total.
User avatar
JohnAStebbins
HandBrake Team
Posts: 5583
Joined: Sat Feb 09, 2008 7:21 pm

Re: Feature-Request: ability to specify Vorbis by "-q", not kbps

Post by JohnAStebbins »

We are trying to stabilize the tree for a snapshot. So this does take rather low priority at the moment.

The way you did the cli switches is a bit of a problem. There can't be a mix of tracks with bitrates and quality settings. E.g. track 1 quality, track 2 bitrate, track 3 quality. Maybe you could handle a list like "8,,8" for quality and ",160" for bitrate to accommodate scenarios like this.
User avatar
JohnAStebbins
HandBrake Team
Posts: 5583
Joined: Sat Feb 09, 2008 7:21 pm

Re: Feature-Request: ability to specify Vorbis by "-q", not kbps

Post by JohnAStebbins »

Another thought occurred to me regarding bitrate/quality interoperability. You could make a single new option that encompasses both (not sure what to call it at the moment). If you make your quality scale a float between 0 and 1, then values <= 1 can be interpreted as quality while values > 1 would be interpreted as bitrate. This would make the parsing simpler and it's not without precedent. We did something similar with video quality. Values <= 1 are interpreted as a percentage while values > 1 are interpreted as RF.

This is a little different in that we would be mixing values that control different parameters, but since those parameters are mutually exclusive, there's a certain logic to it. The other developers would need to give their approval for something like this.
coconut
Posts: 6
Joined: Mon Jun 08, 2009 9:00 pm

Re: Feature-Request: ability to specify Vorbis by "-q", not kbps

Post by coconut »

Thanks for catching the CLI mistake; on second glance it looks pretty bad.

I liked your first idea better; it could apply to any per-audio-track option.
"Pass one setting to use for all audio tracks, or a comma-separated list to apply to each track in order. Skipped tracks get default treatment."
Sounds like a (small) improvement.

The second idea makes sense, but I think using percentages for quality settings might be more harmful than asking users to learn the codecs' quality scales... which aren't really comparable linear scales from "crap" to "transparent". To be fair, I might be biased against such scales' place in HandBrake. I'm sure you guys have discussed whether they're a good idea in some detail, but all I've seen of it is this old doom9 post. :)

It's all pretty simple but I'm not sure whether I can get it done this weekend. Once that's finished I figure I should at least extend the GUIs' preset code before pestering anybody about the frontends... unless that would be likely to clash with somebody's un-checked-in custom/nested preset work?
User avatar
JohnAStebbins
HandBrake Team
Posts: 5583
Joined: Sat Feb 09, 2008 7:21 pm

Re: Feature-Request: ability to specify Vorbis by "-q", not kbps

Post by JohnAStebbins »

Using the encoders native quality scale is a good idea. So the first option sounds like the right one. Adding another control to the row of audio controls is going to make the window wider. The audio settings are the limiting factor in the width of the window. But I think I'm ok with that.
hagen
Posts: 4
Joined: Mon Jan 24, 2011 2:49 pm

Re: Feature-Request: ability to specify Vorbis by "-q", not

Post by hagen »

Has there been any further work on this feature? Reading the thread I wondered whether the easiest way might be to represent quality settings as negative bitrates internally. Since specifying bitrate and quality level are mutually exclusive, the GUI could use the same drop-down list, displaying the two different kinds of values e.g. as "q3" and "128 kbps" or something like that. That way, the GUI layout could be left unchanged.
hagen
Posts: 4
Joined: Mon Jan 24, 2011 2:49 pm

Re: Feature-Request: ability to specify Vorbis by "-q", not

Post by hagen »

Ok, so to make this a little bit more constructive than just whining about a missing feature: While making a hack to implement the functionality for myself, I noticed that in encvorbisInit (encvorbis.c) active management is explicitly enabled (ctl_rate_arg.management_active = 1). Is there any specific reason for this?

According to the oggenc man page: "This mode is much slower, and may also be lower quality. It is primarily useful for creating files for streaming." And the libvorbis docs explain that you may call "vorbis_encode_setup_managed" and then actually _disable_ managed mode as a way of doing VBR encoding while still specifying a bitrate rather than a quality level. So if I understand this correctly, it would make much more sense (and result in better performance/quality) to have "ctl_rate_arg.management_active = 0" instead. This would be a minimally invasive way of enabling VBR and not necessitate any CLI/GUI changes.

And just for the record, here's my hack for vorbis quality settings in the GTK GUI (based on coconut's earlier patch). It's not a proper patch and may well break other things, just posting it in case it's useful to anyone.

http://paste.handbrake.fr/pastebin.php?show=2066
User avatar
s55
HandBrake Team
Posts: 9850
Joined: Sun Dec 24, 2006 1:05 pm

Re: Feature-Request: ability to specify Vorbis by "-q", not

Post by s55 »

fwiw, vorbis isn't an encoder most of us developers really use, so it's probably out of date and not optimally setup at the moment. Would be nice to see work in this area from interested parties.
User avatar
s55
HandBrake Team
Posts: 9850
Joined: Sun Dec 24, 2006 1:05 pm

Re: Feature-Request: ability to specify Vorbis by "-q", not

Post by s55 »

also patches can now be posted to https://reviews.handbrake.fr/dashboard (new toy - Hoping this will make it less likely stuff will get lost in the mix)
User avatar
JohnAStebbins
HandBrake Team
Posts: 5583
Joined: Sat Feb 09, 2008 7:21 pm

Re: Feature-Request: ability to specify Vorbis by "-q", not

Post by JohnAStebbins »

Active management was enabled because without it, the encoder wouldn't produce anything near the target bitrate. It would be all over the map, sometimes higher, sometimes lower.
hagen
Posts: 4
Joined: Mon Jan 24, 2011 2:49 pm

Re: Feature-Request: ability to specify Vorbis by "-q", not

Post by hagen »

What I observe is that the average bitrate is often a bit lower than the specified one, e.g. around 58 instead of specified 64. I've not seen it deviate very much though, and presumably such savings have no impact on quality (libvorbis docs: "managed bitrate modes will always produce output inferior to VBR (given equal bitrate usage)").

I've submitted the trivial patch to disable managed mode (https://reviews.handbrake.fr/r/22/). Feel free to reject it if you don't agree that it's better this way.
User avatar
JohnAStebbins
HandBrake Team
Posts: 5583
Joined: Sat Feb 09, 2008 7:21 pm

Re: Feature-Request: ability to specify Vorbis by "-q", not

Post by JohnAStebbins »

tbh, I don't really have a strong opinion either way. HandBrake has generally been moving in the direction of preferring quality based settings instead of bitrate based settings. The main reason it hasn't been done with audio is the big problem of how to squeeze it into the already very crowded audio settings tab.

We do get the occasional complaint from people that are targeting a specific file size when we don't nail it for some reason. But I don't think that group is big or important enough to cater to.
hagen
Posts: 4
Joined: Mon Jan 24, 2011 2:49 pm

Re: Feature-Request: ability to specify Vorbis by "-q", not

Post by hagen »

Ok, as I said, disabling managed mode would be a cheap first step towards more quality based encoding without having to change the GUI.
Post Reply