Some Requests

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
peter_h
Posts: 17
Joined: Thu Jul 23, 2009 11:40 pm

Some Requests

Post by peter_h »

I've been using Handbrake for a month now, after using Nero Recode for the last year.
However, I'm still going back to Recode to do around half my movie encodes. This is why:

Many DVD sources are over 16:9 ratios - often 2.35:1. Nearly all HD widescreen monitors are 16:9. I always prefer to watch my movies as big as poss, so to avoid the black bars top and bottom, I crop the movie at playback. That is, if it's possible - if it's going out to a TV, it's not - black bars will have to stay, unless the TV itself has a cropping function. All way too complicated and such a waste of encoding space for those pixels at the side you never see. I could use that space to get better quality for the image I do see.

So I ALWAYS crop movies to 16:9.

Seems like it would be a frequently-used and obvious feature, but it's a real pain to do:

Once I know the height of the black bars I'm cropping off in the source, I need to work out the width of the final movie, in order for it to be 16:9, taking into account the PAR (Pixel Aspect Ratio). Now this is were it gets tricky. It's easier in Recode, but still a pain. In addition to the live preview in Recode, to facilitate visual cropping, it at least gives me a calculation of the cropped size taking into account the PAR . Handbrake doesn't - I have to get out my calculator and work out the PAR. Then I do the "Pixels to crop off each side = Original width - (cropped height*1.78)" calculation.

What I would LOVE, is for HB to have a "Restrict Crop to <16:9 | 16:10 | 4:3> " dropdown option, where it automatically takes the vertical crop of the black areas top and bottom, adds a little to make it a multiple of 16, then, taking the PAR into account, work out what the nearest horizontal crop values need to be to crop to the chosen aspect ratio, whilst maintaining the horizontal size as a multiple of 16.

To show my appreciation, I would happily make a donation equivalent to what I paid for my Nero Recode ($30) if someone could make this happen. Not to mention, expound HB's ease-of-use to everyone I know... oh hang on, there's just a couple of other things... :)
Last edited by s55 on Fri Jul 24, 2009 10:56 am, edited 1 time in total.
Reason: Changed Title to reflect multiple requests threads combined into one.

peter_h
Posts: 17
Joined: Thu Jul 23, 2009 11:40 pm

Auto-selection of manual crop values after tabbing

Post by peter_h »

After hitting tab each time to manual set each of the 4 crop values, it's a bit of a pain that it doesn't automatically select the value that's already there - which is the default Windows behaviour. I have to manually delete the value before putting in a replacement.

My request is that after hitting tab, the existing value is auto-selected/highlighted.

:) Ta

peter_h
Posts: 17
Joined: Thu Jul 23, 2009 11:40 pm

Auto-add all titles on a DVD that are between A-Z minutes

Post by peter_h »

This would be a real time-saver: auto-adding to the queue, all episodes of a TV series from a DVD.

For example, there maybe 10 titles on a DVD of all around 20 minutes (the episodes), plus some promos and extras of 30 secs to 10 mins long, plus a "Play all" title of 200 mins. Now all I'd want is the 20 min episodes. Currently I have to manually choose the title, hit [Generate Query] and then [Add to Queue]. For all ten titles!

My request is for an option that looks like this:

FOR ALL TITLES BETWEEN [minLength] and [maxLength] [ADD TO QUEUE]

Of course it would have to automatically name them too.

Ideally, but not a high priority, I'd also like to enforce a consistent crop on every one, so the series episodes end up all being the same size.

peter_h
Posts: 17
Joined: Thu Jul 23, 2009 11:40 pm

Is it helpful to vote for a feature that we support...

Post by peter_h »

...by adding our "Yay / would love to see this feature/ w ould save me hours / etc" post to a "feature request" thread?

I'm new around here, so I was just wondering about the etiquette.

Adding a post like this would bump it up, of course, to give an indication to the developers about the support of the community to a particular feature.

Then again, it would be harder to see new posts added because older ones are getting bumped.

What's generally regarded as preferable?

:) Ta

User avatar
s55
HandBrake Team
Posts: 9773
Joined: Sun Dec 24, 2006 1:05 pm

Re: Some Requests

Post by s55 »

1. 0.9.4 will have a new Picture Settings panel with calculation code included. If you let it do what it's supposed to do, you won't have a problem.

2. Tab / Arrow Key selection works fine in current code so was probably fixed in the new Picture settings panel.

3. Batch encoding features will not happen until several other core features (filters) are reliable enough to be used in a "Set and forget" fashion. This is some way off. If we implement batch features now, there is a high risk of screwing up an entire queue worth of jobs because of 1 mis-configured option. That'll just cause a bucket load of complaints and moaning that we don't want to deal with.

4. We don't need any ""Yay / would love to see this feature/ w ould save me hours / etc"". Once posted, we see the request. Features are not implemented on a user demand basis. Features are implemented that interest developers. If there are no interested developers, it doesn't happen.

peter_h
Posts: 17
Joined: Thu Jul 23, 2009 11:40 pm

Re: Some Requests

Post by peter_h »

ssb: Thanks for the quick responses, and the good news about the Picture Settings feature. I look forward to it!
Great to hear that all feature requests are read.
Really appreciate all your work in providing a great free product - Thanks :)

Post Reply