John Harding - Insert Catchy Title Here

Getting a new Sonos player motivated me to clean up some problems in my CD ripping workflow.  First, some background:

I decided a while back to rip all my CDs to FLAC.  The need for specific formats and bitrates are dictated by the device(s) you're trying to use, and with everything in FLAC, I can just re-encode my entire collection to a new format and/or bitrate whenever I want.

I use EAC for ripping.  Works fine.

I wrote my own tool, which I should publish sometime, to handle mirroring a music collection.  Conversion is handled by standard command line tools (e.g. lame) with config scripts that control the rules.  What's been a nagging problem for quite some time is The Compilation Problem.

It's remarkably hard to find good write-ups on the "right" way to handle compilations, so for the sake of future searchers, here you go:

• Set the artist on individual tracks to be the actual track artist.  So this will be a different artist for every track on a Soundtrack or DJ compilation
• Set the album artist ("ALBUM ARTIST" tag in FLAC/Vorbis or "TPE2" in id3v2) to something fixed for the album - "Various Artists" in the case of a soundtrack or the name of the DJ for compilation CDs.
• Ensure you set the "TCMP" tag to 1 in the id3v2 tag - this is what flags the tracks as part of a compilation.  iTunes will then pick these up and merge into one album, using the Album Artist field.

I frequently worry that I forgot to close my garage door. When this happens, I can either drive back home just to check, or assume that I closed it and try to move on with my life. While there are much better solutions to this problem, I decided to solve it by writing an Android app.

The app periodically takes a picture using the camera in the phone, and uploads it to a site where the picture can be viewed. At first, this was just a single location on my personal server, but for release, I created a simple Google AppEngine application to receive, list, and display the images.

Please post any thoughts/feedback in the comments. Some things I'll probably add:

• Configurable # of recent images to be stored
• Automatic generation of time-lapse video
• Permissions/protection on the posted images

Other weird stuff:

• It asks for permission to read the phone state - this is used to get the device's IMEI as a unique identifier. I'm sure there are better solutions, and you can just manually set an identifier in the settings. Problem will go away when I add permissions.
  
• Dealing with the camera is a pain in the butt. The emulator camera doesn't behave at all like the real hardware. Currently, I re-initialize the camera after every picture, which is probably bad. Focus is flaky. And sometimes it ends up with a blank image, due to race conditions which I need to fix. Blah blah blah.
• It's ugly. I know.

One of my favorite annual San Francisco events is Bring Your Own Big Wheel, a big wheel "race" down a steep, winding road (Vermont St in SF's Potrero Hill neighborhood). Last year, my friend Dave and I rode in the race, and learned some lessons about how badly a stock Big Wheel handles aggressive riding by an adult. Fortunately, some simple modifications and reinforcement can make a dramatic difference.

Mod #1: Remove the pedals
Pedaling a big wheel as an adult is just not effective - you're better off pushing with your feet. In fact, the pedals are most likely just going to smack you in the shins. For the SF course, they're even more of a liability, as the pedals will hit the ground on sharp turns and lift the front wheel up in the air, eliminating what little steering you had.
Instead, I recommend just putting a bolt through the front wheel, with a cap nut on the other end. Unfortunately, I didn't write down the proper length and size, but it shouldn't be hard to find them. I put washers on either side of each prong of the fork, and used loc-tite on the cap nut to make sure it holds together.

Mod #2: Tighter steering
The handlebar setup for big wheels is just not meant for aggressive steering - the plastic buckles easily, and the screw attaching the handlebars to the fork starts tearing up the plastic. The end result looks like this:

In an emergency, you can just wedge something in the gap between fork and handlebar (we used torn strips of cardboard during the race last year), but that's not going to last.

What I ended up doing was picking up a pair of L brackets like these, to effectively stiffen up the fork. Go for thin ones, since there's not a lot of wiggle room between the fork and handlebars. First, attach the L brackets to the fork as shown here.

A few notes on this:

• It's unlikely you'll be able to remove the fork from the main body of the big wheel with the L brackets on.
• Depending on where you originally screwed in the handlebars, you can try to re-use the original holes in the fork. Make sure you use shorter screws, though - not the long ones that come with the big wheel.
• I recommend putting a screw in all four sides.

Then, slide the handlebars on top of the L brackets. Depending on shape and fit, you may have to squeeze the brackets together to fit the handlebars over them. Push the handlebars down as far as you can - down to the heads of the screws holding the brackets to the fork. Use the original, long screws to attach the handlebars to the L brackets, ideally using the original holes in the handlebars. The screws will extend into the opening in the handlebars - my next step is to cut a block of wood to fit this gap, which will hold the screws in place.

The L brackets should pick up most of the pressure for turning the handlebars, such that the handlebar screws are just there to keep the handlebars from sliding up off the bracket. However, I found that putting a second pair of screws in helps it hold a bit tighter. I recommend drilling small pilot holes for the extra screws - 3/32" for use with #10 screws.

Unfortunately, my street isn't really steep enough to stress-test this new setup, so I'll have to wait until next week to see how it holds up.

I've been trying to keep an eye on the various discussions around getting AppleTV and the iPhone to display subtitles - some of the content in the iTunes store has subtitles, but Apple has no published documentation about how to add your own. It's kind of a pain to track, as there are a lot of older articles discussing burning subtitles into the video itself. This has the nice advantage of working directly off the bitmap subtitles ripped from DVDs, but makes it awkward to share a single video file between AppleTV and iPhone. It also means you can't turn them off, and if you use the zoom feature on the iPhone, you've got to be extra careful where you position them.

There are a few mentions of the fact that the subtitle tracks are basically just standard 3GP timed text tracks, but with the 'hdlr' atom handler_type set to 'sbtl' intsead of 'text'. MP4Box has support for 3GP timed text:

mp4box -add subtitle_track.ttxt video.mp4

They use their own file format for the timed text source, but can covert from SRT or SUB.

What's bizarre is that quicktime, AppleTV, and iTunes all behave slightly differently and are more or less sensitive to different aspects.

File Extension	text vs. stbl	Set Language	Quicktime	iPhone	AppleTV
mp4	text	No	Ignored	Ignored	Ignored
m4v	text	No	Displayed, regardless of subtitle/caption setting	Ignored	Ignored
mp4	text	lang=en	Ignored	Ignored	Ignored
m4v	text	lang=en	Displayed, regardless of subtitle/caption setting. Different font than without language set.	Ignored	Ignored
mp4	sbtl	No	Ignored	Displayed, with subtitle control. Language shows as "undetermined"	Ignored
m4v	sbtl	No	Displayed, with subtitle control. Text not sized appropriately.	Displayed, with subtitle control. Language shows as "undetermined"	Not displayed. Can bring up Subtitle menu, but language shows as a second "Off" item, with both checked. Selecting has no effect.
mp4	sbtl	lang=en	Ignored	Displayed, with subtitle control. Language shows as "English"	Ignored
m4v	sbtl	lang=en	Displayed, with subtitle control. Text not sized appropriately.	Displayed, with subtitle control. Language shows as "English"	Displayed, with subtitle control. Language shows as "English"

Basically:
Quicktime only works with .m4v file extension, does not require a language to be set, and handles 'text' differently than 'sbtl'
AppleTV only works with .m4v file extension, requires a language to be set, and only works with 'sbtl'
iPhone works with both .mp4 and .m4v file extensions, does not require a language to be set, and only works with 'sbtl'

I think what's happening with Quicktime is that it's attempting to use positioning information, of which I haven't specified any. Will look at that next to see if it's possible to make something that plays properly in all 3 cases.

Note: The still frames for the text/m4v files show the caption on the iPhone, even though it doesn't display during playback. I assume this is because iTunes generates the still frame.

The linked post indicates that you need to change the alternate_group in the subtitle's tkhd atom from 0x0000 to 0x0002. My testing did not show any change in handling with or without this modification in Quicktime, AppleTV, iPhone (firmware 2.1), or iPod Touch (firmware 2.1)

I had to force a software update on my AppleTV to get it to handle the files properly, even though I was already on Take 2. The symptom was that holding the "play" button would blank the screen. It worked fine after update.

Update:
Things work slightly better if you convert the SRT file to ttxt first:

mp4box -ttxt subtitles.srt

It appears that if you just add an SRT file to a video, mp4box makes the text box for the subtitles the same size as the video. So apparently, iPhone and AppleTV ignore the placement, while Quicktime respects it. So what you need to do is:

• Convert from SRT to ttxt as listed
• Modify the <TextStreamHeader> element in the resulting ttxt file: [width of video] [20% of video height] translation_x=0 translation_y=[video height - height]

Quicktime appears to disregard the font size, and instead adjusts the font based on the height of the displayed text area - enough to fit 2 lines of text. This means the amount of text you can fit is basically a function of the width of the text display.

Kimberly and I have been in Tokyo this week, where I've been visiting with our Tokyo engineering team. We were both a bit apprehensive about the eating situation, as we have somewhat "selective" taste in food (I don't eat vegetables and very little fish, Kimberly doesn't eat mammals). In San Francisco, we're well-served by Yelp, which lets us avoid any bad food experiences, but unfortunately, they don't cover Tokyo. So, I figured I'd review some of our food experiences:

7-eleven
7-eleven has been a staple of our Tokyo eating, especially for breakfast. After careful, scientific experimentation, we've determined that the best combination is 1 Starbucks Espresso Milano coffee drink and 2 halfway-covered-in-chocolate donuts per person. Kimberly was also a big fan of the shrimp rice ball (triangle of rice with a shrimp inside, all wrapped in seaweed), which was versatile enough to cover all mealtimes.
We've checked out some AM-PMs as well, but they just don't compare.

Mochi Cream
Mochi Cream appears to be relatively new (at least their web site is). They display their various flavored-filling mochi balls much like a high-end chocolate shop, and serve them frozen so you have to wait for them to thaw. The outer shell appears to be that of a standard mochi ball, but the inside is filled with flavored creams. Our favorite was the raspberry, though the chocolate banana was also quite tasty. There's one in the east-west passage at Akihabara station, and apparently also Tokyu plaza just west of Shibuya station.
I don't think this would do well in the US though - not nearly enough sugar. Also a bit pricey at 200+ Yen per ball.

Shirube
Can't find a good link/map for this one, in Shimo-kitazawa. Both the restaurant (an izakaya) and neighborhood are fantastic. Laid back, not as crowded/touristy as the neighborhoods inside the Yamanote line, and just a really great vibe. Head south from the station, and take a right at Mister Donut - should be a wall of shrubs along the right hand side of the narrow street.
The restaurant itself was packed and very lively. In nearly a week and a half in Tokyo, this was the only place we went that had us take off our shoes. They do have an English menu ("eego-menu"), which is always comforting - the fried shrimp from the "favorites" list on the back of the menu was fantastic.

Mister Donut
Speaking of Mister Donut, we checked one out in Shinjuku one evening - very disappointing. Far too chewey - almost a bit stale. We tried a green one, thinking it would be green tea, but ended up convinced that it was a seaweed donut. Blech.

Tokyu Food Show
In the basement underneath Shibuya station is the Tokyu Food Show - envision an entire floor of a deparment store devoted to take-out food. Sadly, it's apparently inappropriate to eat there, so you can't really sample as you go. For some reason, we didn't take pictures, but it's just absolutely overwhelming. There was a dessert place with a name like "Origines Cicao" or something that had a crazy delicious raspberry chocolate cake. Mmm..
One thing that was really impressive was the care they take in packing up your food, particularly the desserts. They put spacers into the box to hold everything in place, and then add disposable freezer packs to keep everything cold.

Beard Papa's
Went to the one at Shibuya station. Meh - tastes about the same as at home, but no flavored fillings and no chocolate covered puffs.

More to come...

Now that I've got my fancy new jharding.org domain name configured properly, I've moved my blog to blog.jharding.org. The old name, johnmharding.blogspot.com, should continue to redirect indefinitely.

I run a home server, which mainly exists for file serving and some hobby projects, and it's nice to have DNS actually work for it. When I first set this all up a long time ago, either my DNS registrar didn't offer any decent DNS hosting options, or I somehow missed it. No matter, as DynDNS offered cheap lifetime custom DNS service, and I wanted something like that to deal with my frequently-changing cable modem IP address.

A bit later, I went to set up a second domain, but DynDNS had stopped offering the lifetime service option, and had switched to charging ~$20/year. No big deal, signed up, and forgot about it.

Recently, I was finally able to sign up for jharding.org after someone let their registration lapse, but no way was I going to pay another $25/year just to serve a few DNS records, so I finally looked into other options.

I'd registered the new domain at godaddy, mainly because it was cheap, but they also give you decent control over DNS. Armed with that, I can actually piggyback all my domains on the single DynDNS lifetime DNS service, since all you really need is a single authoritative A-record for your dynamic IP address. Everything else can just be CNAME'd to that record. Duh.

So, if your domain is hosted at godaddy, you just:

1. Go to your domain manager interface, and select the domain you're trying to set up
2. Click the "Total DNS Control and MX Records" link in the upper display area
3. Click "Advanced Mode" to get a better UI
4. Check the "Delete" box for the default A record and all the lame CNAMEs they set up, then "OK" to wipe those out
5. Add 2 new CNAMEs: One from "www" to your A-record, and one from [your domain] to your A-record

For the second one, what I mean is if your new domain is "foobar.com", you'll actually set "foobar.com" as the host for the CNAME. Alternately, you can use their HTTP forwarding to have their web servers bounce "foobar.com" to "www.foobar.com", but that will only work for http, and results in an unecessary redirect, so I prefer the CNAME approach.

Update: Unfortunately, I can't seem to find a cheap, reputable registrar that will accept inbound 3rd-level .name transfers, such as for john.harding.name. I guess that one is stuck where it is.