When I posted my 787 takeoffs and landings video, I ran into a weird problem: When embedded here, the video would play in Safari at 4K (2160p), but when viewed on YouTube, the max resolution available was 1440p. After failing with web searches, I asked Twitter about it…
…but didn’t hear anything back. I pretty much gave up on the issue until today, when I stumbled across this article, which describes the exact problem I’m having. The summary of the article describes both the problem and the apparent cause:
What appears to be Google’s shift to the VP9 codec for delivering 4K video on the YouTube homepage is preventing Safari users from watching videos uploaded to the service since early December in full 4K resolution, but not from viewing webpage-embedded videos in the same resolution.
Bingo! Google seems to now be using the open and royalty-free VP9 codec for 4K videos viewed on its YouTube site, but reverts to the H264 codec when those same videos are embedded on other sites.
Note that this issue only affects videos uploaded after December 6, 2016:
Videos uploaded to the service prior to Dec. 6 in 4K resolution can still play back in full 4K resolution on Safari from the YouTube homepage.
I was curious about which macOS browsers this issue affects, so I thought I’d do a little experiment…
Ever want to grab the cover art for some album? Or have you ever wanted the full-size icon from an iOS app? Or the cover image from a movie or TV show? A podcast’s icon? Ben Dodson hosts an excellent web-based tool that lets you do all that and more: The iTunes Artwork Finder.
Usage is about as simple as it gets: Pick a category, enter your search term, set the geographical region, and click Get the artwork.
Note that this only works for things available from the iTunes Store in the specified region, so you can’t use it to find cover art for that digitized copy of some obscure record you found at an underground music store in New York City back in 1973.
Also note that if you have your own web site, you can host your own artwork finder, as Ben has made the code available for all. I wouldn’t recommend making it publicly available, though, unless you have bandwidth to spare—a single search for “Friends,” for instance, returned about 25 high-resolution images.
Here’s how I set it up on our family’s web site; it’s really easy to do, and it works great:
Download the zipped archive from GitHub.
Create a new folder on your server. I called mine getart.
Upload the two files (php, js) from the archive into the folder.
Add basic HTML tags (html, head, body) to the stub of HTML shown on the GitHub page, and save it as index.html in the same folder. If you like fancy and have time to spend, go ahead and pretty it up with CSS and layout. I just left it bare.
That’s all there is to it; you can now look up artwork by loading http://yourdomain/getart (or whatever you called it) in your fave browser.
During today’s recording of our The Committed podcast, Ian mentioned a site he uses to check for sometimes hard-to-acquire Apple products. The site, iStockNow, is very nicely designed and makes it really simple to check availability not only at your local stores, but also globally.
Start by clicking the left-side filters section for the products you’d like to check on, then view the map on the right to see where they’re in stock. For example, a search for the 15″ MacBook Pro Touch Bar in Space Gray shows that it’s available throughout North America, except in Mexico City:
But if you search for a 42mm Apple Watch in Stainless Steel in retail stores, you’ll see that most of North America is a sea of red. Zoom in on the map, though, and there are some stores with stock:
When you find a store with inventory—the green pushpin—click on it to get the details of that store’s inventory:
If you’re looking for something particularly hard to find—cough AirPods cough—iStockNow may just help you secure your item. According to Ian, at least, that’s exactly how he got his AirPods!
First, let me say we know that this took too long for many of you. It’s been three years since we last updated the Mac Pro, but we’ve been working super hard on it. Years and years of work went into what I’m about to show you. This thing is packed with amazing technology, and we think you’re going to love it! So here it is…
My method of ripping Blu-ray discs relies on Don Melton’s video_transcoding tools. While these tools work great, they are command-line only (i.e. Terminal required). In my guide, I glossed over the installation bit, referring back to Don’s basic guide. But for those new to Terminal, even Don’s instructions may be too light on the details.
Hence this detailed installation guide for Don’s video_transcoding tools. This guide walks a new user through every step of the process, hopefully getting even someone brand new to Terminal up and running with Don’s tools. This will only be of interest if you’re having trouble getting the video_transcoding tools installed. If that’s you, though, hopefully this will be helpful.
The entire installation of the video_transcoding tool set and all its dependencies will take place in Terminal, which is the direct line to the Unix core of macOS. Open Terminal, which you’ll find in /Applications > Utilities, and you’ll be greeted by a window with some text; something like this:
This lovely interface is where you’ll spend the next chunk of time, installing the video_transcoding tools, and all the programs it uses to get its work done.
Note that this guide is not a detailed introduction to Terminal or Unix. (There are manysuchguides on the net, and if you’re interested, they’re well worth reading.) This guide is focused solely on how to use Terminal to install the video_transcoding tools, not how to use Terminal on its own. So let’s get started…
Once a month, I download roughly 25 gzipped (.gz) files from Apple—these are our Mac App Store sales reports, with one file for each App Store region. I could have Safari expand these files (via the “Open ‘safe’ files after downloading’ item in its preferences), but I prefer to leave that option unchecked. (Why? I often download archives that I want to leave archived, and I like to keep originals of many of the things I download).
If you work with lots of compressed files, you’re probably familiar with what happens in Finder (see note) when you go to expand any semi-large number of files: The infamous Dancing Dialog™. It looks something like this…
[Note: Technically, this isn’t Finder, it’s Archive Utility doing the expansion. But this is the service that Apple provides to expand compressed files, and it’s what 99% of macOS users will use. It can be changed via the Get Info dialog, but very few people will take that step. So to most users, it seems it’s Finder handling the expansion. For ease of reference, I’m going to say it’s Finder doing the expansion.]
Not only is this randomly-resizing dialog box visually annoying, it turns what should be a super-fast process into one that takes a ridiculous amount of time. The end result is that users think they have a slow machine—”it took over 12 seconds to expand 25 tiny little archives!”—when what they really have is a horrendously slow GUI interface to a super fast task.
Just how fast is the task, if the GUI doesn’t get in the way? Thanks to the Unix core of macOS, we can answer that question using Terminal, the geeky front-end to the Unix core. The Unix command to expand .gz archives is gzip; so to expand all the .gz files in a folder (and keep the originals), you’d use this command in Terminal:
gzip -d -k *.gz
If you try this, you’ll find out it’s nearly instantaneous—press Return, and the files are expanded. Unix actually gives us a way to see exactly how fast it is, via the time command:
$ time gzip -d -k *.gz
This was for a set of 24 .gz archive files (on a solid state drive), and the real line in the output shows exactly how long it took to expand them all: 0.013 seconds. By comparison, I made a screen recording (with an onscreen stopwatch for timing) of Finder expanding the same 24 files; it took 12.8 seconds for all the dialog dancing to end. Think about that…
Expand 24 .gz files
Finder: 12.8 seconds
Terminal: .013 seconds
Terminal is 984.6x faster than Finder
To put those results another way, if expansion time is linear, gzip could expand 23,631 files in the time Finder takes to expand 24 files. That’s nuts!
(You can watch this video for a visual comparison of expanding the same set of files in Finder and Terminal.)
So it’s not the computer that’s slow, it’s the GUI interface to the computer that (in this particular use case) is incredibly, horrendously slow. And there’s no need for it—the separate individual progress bars, appearing and vanishing in under a second each, provide no useful feedback to the user. They just slow down the task.
Finder (née Archive Utility) should just execute the task without any visual feedback (though it should pop up a window if there are exceptions). If visual feedback is really required, a window with a single progress bar for the entire task would be OK, but would still slow operations down.
This is a great example of how an everyday task can make you think you have a slow computer, when what you really have is a fast computer with a slow interface element. Given how often we all deal with compressed files, it’d be nice to see Apple clean up this mess. Until they do, however, you can harness the power of Unix—even while in Finder—to speed up the task. Here’s one way to do just that.
Back in 2013, Apple introduced the new Mac Pro, an amazing wonder of design. But it was also a study in compromise for “Pro” users, requiring all peripherals to be externally attached, and not allowing for any after-purchase upgrades (video card, CPU, etc.). It was also shockingly expensive.
I can only imagine how hard it must have been for Apple to try to build a perfect Mac “Pro” desktop for everyone. As nicely designed as the new Mac Pro was, it missed the perfect mark for many Pro users by quite a bit.
So how does Apple try to design one Mac that can satisfy a diverse group that encompasses design professionals, gamers, scientific researchers, video creators, and who knows what else? Quite simply, they shouldn’t try, as such an exercise is destined to fail. (See “new Mac Pro,” above.)
Instead, Apple should design one Mac that can become anything and everything to each type of “Pro” user. While that may sound daungting, the good news is that Apple’s already done this in its recent past. And done it very well, I might add…
One aspect of Apple’s decision to remove the headphone jack from the iPhone 7/7 Plus that I haven’t seen discussed anywhere is the impact it will have on third-party battery pack case makers. Traditionally, third-party battery pack cases plug into the Lightning port, and typically provide a micro USB connector in its place. They also then usually have a headphone passthrough, either via a port extender or a special headphone cable extender, to allow you to plug in headphones without removing the battery pack.
I was curious how the case makers were going to address this for the iPhone 7, because blocking the Lightning port means that users will have to use wireless headphones when using a battery pack. I searched Amazon for iPhone 7 battery case, to see what might be in store. However, the results were disappointing—basically, everysingleproductusesmicro USBforchargeandsync. I could go on, but you get the idea: None of the manufacturers seem to be worried about blocking the Lightning port with their battery cases.
The only exception I found was the SOLEMEMO Ultra Slim Charging Case, which isn’t actually designed for the iPhone 7. But as designed for the iPhone 6, this case uses an ultra-slim bottom with a tiny Lightning pass-through, as seen in the photo below (borrowed from one of the reviews on Amazon).
This style of connector would allow you to connect wired headphones (either Apple’s Lightning pods, or standard headphones via Apple’s Lightning to 3.5mm adapater cable). I don’t know if this company will be making an iPhone 7 version or not; the iPhone 6 case should fit the iPhone 7, but the camera opening won’t line up with the camera’s new position on the iPhone 7.
(I checked Mophie, too, but they’re early on in their iPhone 7 case building process; their iPhone 7 link takes you to their Explore our Process page, which describes the method and timeline they follow in making products for new devices.)
So if you’re buying an iPhone 7, and you want a battery case right now, and you want to use wired headphones with that case, as of today I see three solutions:
Buy the SOLEMEMO Ultra Slim Charging Case for $35, knowing you won’t be able to take pictures. Note that this is a 2400mAh battery pack, so it’s not as large as some of the others (but it is very slim).
Buy Apple’s $99 iPhone Battery Case. This is an 2365mAh battery pack (up from 1877mAh for the iPhone 6s), and it nicely integrates—at the iOS level—with your iPhone. But it’s pricey, underpowered, and has The Hump. For the cost of the Apple pack, you could get two SOLEMEMO packs and have $30 left over!
Buy any of the forthcoming iPhone 7 battery cases and use wireless headphones. OK, so that totally skips the ‘use wired headphones’ requirement, but it’s really the only other option at this time.
I’m hoping we’ll see someone come out with something truly innovative here, such as Lex Friedman’s suggestion on Twitter:
@rgriff Million dollar idea: Battery case with headphone jack pass through
Adding an actual headphone jack would probably be a home run product; I have no idea if it’s technically possible to split the Lightning port’s signals in that way (I would bet it’s not). Even lacking that, though, it’d be nice to see more third-party cases that pass through the Lightning connector, so that wired headphones could still be used.
David really doesn’t like Messages (for many valid reasons), and has often tweeted and written about other, better messaging platforms, including his current best-of-breed example, Facebook’s Messenger.
And you know what? In general, I agree with David: Messages sucks. It’s got latency issues, messages sometimes vanish, shared URLs are ugly, search is troublesome, it lacks many features found in other apps, etc. Yet still, it’s my messaging app of choice, and will remain my messaging app of choice, probably forever. Why?
First of all, it’s bundled with every Mac and iOS device sold, which means that most of the people in my social group already have it and use it. I don’t have to send a link to someone and explain how to install the app, set up an account, find my name/phone number, add me to their group of friends, and initiate a conversation.
Does that make Messages good? No, just because an app is bundled doesn’t mean it’s excellent. (See previous generations of Internet Explorer on Windows, for instance.) But it does make it pervasive, and in a messaging app, that’s what I want.
But even beyond that—even if Messages were so abysmal it lost 50% of the messages I sent and often force rebooted my devices and remotely spilled my milk—I would probably continue to use it. Why? Because Apple isn’t in the business of making money off of who I talk to, what I talk to them about, or what devices I use to do that talking. Apple wants to sell devices, not data about how people are using Apple’s devices.