The Robservatory

Robservations on everything…

 

Search Results for – "homebrew"

Revisiting ripping Blu-ray discs

A couple years back, I explained how I rip Blu-ray discs. A lot of time has passed, and I now use a slightly different procedure that results in much faster rips—with the caveat that the resulting file will be larger than the “slow” method, and is technically of slightly lower quality, though I can’t visually distinguish the two.

The new method uses Don Melton’s amazing video transcoding tools, a set of Unix programs that optimize video conversion in ways you cannot do (or easily do) in the Handbrake GUI. If you’re new to Unix, but would still like to try these tools, I wrote a detailed set of instructions that should help get you up and running.

Using these Unix programs, you can rip a disc with various parameters, including one to optimize for speed (with good image quality) and another that tries to minimize the file size.

Here’s a quick comparison of all three methods, as tested with the three-hour Hamlet Blu-ray. The ‘Handbrake GUI’ rip was done using, well, the Handbrake GUI as described in my original article. The second and third rows use Don’s tools set to quick and veryquick modes, and the final row uses Don’s tools set to optimize the file size.

Method Data Copied Convert (hrs:mins) File Size
Handbrake GUI 47.5GB 3:52 6.8GB
transcode – quick 40.1GB 2:20 9.2GB
transcode – small 40.1GB 3:12 6.5GB

Tested on a late 2014 27″ iMac with a 4GHz Core i7 and 24GB of RAM.

Using Don’s tools in “quick” mode, you save time two ways: 7GB (15%) less data is copied to the hard drive, and the conversion process is over 90 minutes (38%) faster. The downside is that the final file size is 2.4GB (35%) larger. And that’s what they call a tradeoff.

Using the “small” mode in Don’s tools, you still save the 7GB (15%) of data copy, and still save 40 minutes (17%) over the original method. In addition, the file size is smaller than the Handbrake GUI version.

To summarize, regardless of whether you care more about file size or ripping speed, Don’s tools provide an advantage over the Handbrake GUI: Either method is notably faster, and the small option generates smaller (or probably at worst, very similar) file sizes. (There’s also a “big” option, if you don’t mind somewhat larger files at a higher quality level.)

Keep reading to see some examples of the image quality of each method, and information on how to install and use Don’s video transcoding tools.

(more…)

Behind OS X’s modern face lies an aging collection of Unix tools

Note: This article has been heavily modified, as I was a total knucklehead and completely forgot about GPL v3—thanks to Geordie Korper for pointing it out in the comments. Basically, the cause of the aging Unix tools in OS X is GPL v3. I’ve updated the following table to include the license information. In every case but one (nano), GPL v3 is the license on the non-updated apps. So that’s that…I’ll leave this up, though, in case anyone’s curious about this stuff.

As I covered recently, the version of bash that ships with OS X is quite old, and as such, is vulnerable to the recently-revealed bash security hole.

At some point, Apple will release an OS X update containing a patched version of bash. (Update released.)

So while Apple has patched bash, this version of the shell is simply ancient. Just how old is it? bash 3.2.53(1) is roughly seven years behind the current version, 4.3.25. Seven years is like, well, forever, in Internet time!

With that bash age gap in mind, I took at look at a number of common Unix apps—in both Mavericks and Yosemite—to see which versions were in use. Then I checked the same apps in MacPorts, a tool that makes it simple to install many Unix apps.

(MacPorts doesn’t necessarily have the absolute latest version of every Unix app, but they do stay relatively current. For instance, they already have a patched version of bash that fixes the above vulnerability.)

The results were interesting, to say the least—many of the core Unix utilities in OS X are years and multiple versions behind their open source, er, sources. You can thank GPL v3 for that, as noted above (and covered in more detail below). But that still leaves the big question:

Does it matter?

That is, should we care that these tools aren’t keeping up with their latest and (presumably) greatest versions? Is it a problem, or merely a statement that what we have works well enough for the majority of users? (For those who don’t want to bother reading, my general opinion is no, it doesn’t matter.)

(more…)

The Robservatory © 2018 • Privacy Policy Built from the Frontier theme