When adding any .mkv with ASS subtitles (that I've tried), the subtitles are not correctly added and an exception is displayed. The last version that I know of that does not suffer this bug is svn4366 (it's been a while since I upgraded).
Because the developers were receiving flak from some very vocal users about a 1.5-2% error in target bitrate on some encodes, and concerns that it was going to become even less accurate once VBR audio was brought into play.
If you really need target file size, then there are many online bitrate calculators that can do the required math to the same level of precision as HandBrake.
Awesome The world doesn't need more 700 MB movie files. Seriously.
Trying out the new and lovely Handbrake, had one crash so far (startup, suspecting it was related to the previous preset files, not sure), love the new features!
Here's the error:
An Unknown Error has occured.
System.NullReferenceException: Object reference not set to an instance of an object.
at Handbrake.frmMain..ctor(String[] args)
at Handbrake.Program.Main(String[] args)
I noticed that the 64-bit version is listed in the download. Does this mean it is no longer experimental? I noticed in the nightly downloads that it was always listed as experimental but good results.
Are there any features that are not available in the 64-bit version due to there not being 64-bit utilities available such as the codecs? Any reason to use the 32-bit over the 64-bit?
In my humble opinion, the individuals who need to predict file sizes for storage purposes are self-deluded (terabytes are cheap!), and the exceptionally few who need to forecast nominal streaming bandwidth for WAN servers are fully capable of the fifth-grade math needed to get there.
A more productive post from me, once I have had time to put the new stable through its paces, is forthcoming. ;?)
GregiBoy wrote:@MV... I totally agree with you. Terabytes ARE cheap and who does 700Mb movies anymore?
There are many very nice 400-500MB 720p movies (I prefer them over any others).
Not everyone have so much storage and not everyone has very fast Internet (I have DL 4mbit, UL only 0.5mbit)!
Anyway, it is good that I can still use v0.95, but it is weird that ANYBODY thinks that "target size" is so big problem - if you don't like, you don't have to use it, right? There was no reason to remove that option.
I agree, however from what I have read, a few bad apples ruined by whining about a small overage in file size, so it was decided to eliminate the option. By doing that the developers can focus on improving what works best.
It has been my experience that when something is removed from Handbrake, for a reason, it's gone and it's not coming back.
Otherwise, I'm not sure what your internet speed has to do with transcoding.
Smithcraft wrote:
I agree, however from what I have read, a few bad apples ruined by whining about a small overage in file size
This was a contributing factor, but the bigger reason was that it was getting increasingly difficult to maintain. There are a large collection of corner cases that require special treatment when trying to compute bitrate from target file size. The number of these corner cases keeps increasing due to additions like VBR audio. To summarize my feelings about it, it is a feature that *none* of the developers ever use, has become a PITA to maintain, is misused by many users for the purpose of "quality" control, and causes endless support problems. We all just wanted to spend our limited development time on other more useful features instead of constantly beating this dead horse.
velikibrat wrote:
There was no reason to remove that option.
I was disappointed when target file size was yanked from the betas way back when.
However, I quickly found that the average bitrate setting worked just as well, for my use anyway, and I could better configure consistent video rate size with multiple audio streams.
(Personally, I've found that CQ works great for bluray re-encodes but I prefer the size consistency of two-pass average bitrate for dvd encoding)
Quick question about DTS-in-mp4. The release notes state:
DTS Passthru to MP4 container (in addition to MKV) (supported by e.g. VLC, MPlayer)
I encoded a chapter of a DTS film with track 1 AAC, track 2 AC3, track 3 DTS using a nightly build from around November last year. Using v2 of VLC the track plays fine but the DTS track is recognised as "stereo" and no audio is heard when it is selected.
Has the DTS-passthrough to MP4 changed in the final release and can anyone confirm that VLC v2 will plays these tracks?
Sorry to repost but I think my questions got ran over by the target files size issue.
My question was on the 64-bit version and is the 7th one in this thread.
Additionally, with this new version and new AC3 updates can anyone tell a difference between DTS Passthru and encoding the DTS to AC3? I am trying to keep an easy way to convert to PS3 compatible should I need to and so many Blu-Rays I get have DTS. I used one of the nightlies awhile back and made 2 clips, one with DTS Passthru and one with AC3. I could not tell a difference but my wife could. However, my wife has an ear for music so when she could tell a difference I stopped converting to AC3 and wanted to retain the best sound I could without keeping the HD sound.
The world doesn't need more 700 MB movie files. Seriously.
But, if I want to upload something, I would prefer to know size before upload starts 
