Slides

Audio

Video

Or you can just search the iTunes Store for “Backup Bouncer”. Surprisingly enough, my talk is the only hit.

It was nice to get a chance to talk about my work, but a bit strange to give a talk over Skype. I was expecting a video feed from the other end but there wasn’t any, so for all I know I was giving the talk to an empty room. This had the beneficial side effect of totally eliminating any stage fright I might have felt, so maybe it was a net win.

Skype doesn’t support screen sharing and webcam video simultaneously, so the poor attendees were stuck looking at my (very static) slides while listening to my disembodied voice. Furthermore, judging by the stuff on iTunes the sound quality of my bluetooth headset let a bit to be desired. (Geez, you sink a whole $5 into a bluetooth headset and you get junk! Where is the love?)

To make matters worse, the system’s top-secret non-configurable algorithm for resolving conflicts appears to work backwards from what users might hope for. The Xcode plugin lives inside an Apple-supplied app bundle in a system directory. It’s installed automatically if you choose to install Xcode itself, so it can easily up on your system without you even knowing it. Compare this to QLCC. You, the user, have actively downloaded it and installed it for the express purpose of handling source code files in the Quick Look system. You can easily remove it if you decide you don’t like it anymore. Which plugin do you think should win if they conflict? Apple thinks different. The system always picks the Xcode plugin over QLCC.

But come on, if you’re going to have a system like this there ought to be a way of saying “I want plugin X to handle UTI Y.” This could be a nice shiny user interface somewhere or a down-n-dirty terminal command, but it needs to exist. I sent a bug report to Apple saying as much (rdar://7240036, mirrored here). I described my problem and made it clear that the solution ought to be a preference system for Quick Look. At the very least, I said, user-installed plugins should rule supreme.

Apple engineering’s response? You can register for more specific UTIs than public.source-code. Nothing about why they don’t want to have a preference system or let user-installed plugins override others. Just “register for more specific UTIs.” The idiocy of this suggestion is staggering. The whole purpose of the hierarchical nature of the UTI system is to allow folks like me to say “I handle source code” without having to list every type of source code. Highlight, the library that QLCC is based on, can colorize about 140 programming languages. Apple engineering, with a straight face, is telling me that I should be registering for 140 UTIs because Xcode decided to register for the one I actually need.

It gets worse. Even if I decided to take Apple’s advice, it’s impossible to say what those 140 UTIs should actually be, because there’s no central authority for registering UTIs. (This is another glaring flaw with the UTI system as implemented by Apple.) UTIs like org.ocaml.ocaml-source are generally defined and bound to file extensions like .ml by applications or other entities like Quick Look plugins. So what happens if you install one app that binds .ml to org.ocaml.ocaml-source and another that binds it to fr.inria.ocaml-source? Your guess is as good as mine. That’s another bit of non-configurable secret sauce. But I think it’s safe to say that only one will win.

So let’s go back to my hypothetical 140-UTI plugin. Imagine the confusion and headaches when a user’s .ml files stop being highlighted just because she happened to download some random app that bound .ml to fr.inria.ocaml-source and my plugin has registered for org.ocaml.ocaml-source. Can you imagine trying to solve these problems for random users of 140 programming languages, of which you actively use maybe 10?

But really, this is just an example of brush-off via bug report. Despite my slagging I do believe the engineers at Apple are generally quite talented and bright. They must know that the problem exists, but for whatever reason they’ve decided it’s not worth solving. Furthermore, they’ve decided it’s not worth telling some no-name hacker why they think it’s not worth solving. But the most insulting thing is that they didn’t even bother to mark my issue as a duplicate of some other issue requesting a prefs system for Quick Look. (You’d better believe that one exists.)

“Go register for more specific UTIs, kid, yer bothering me.”

¹ If you’re unfamiliar with the UTI system, John Siracusa’s encyclopedic review of Tiger has a detailed description.

For history’s sake, I’m observing this on Snow Leopard 10.6.1, Xcode 3.2, Instruments 2.0.

Continuing on my “update side projects for Snow Leopard” theme, I’ve just rolled a new release of QLColorCode. I added support for a few new languages, including Scala, which is a personal fave. I also fixed a bug or two and finally upgraded the bundled version of Highlight from 2.6.6 to 2.12, which was long overdue.

On the ‘meta’ side, I moved the project’s source code from google code’s subversion to github. I’ve been using git a lot lately so I expect I’ll do the same for my other projects as well. Once you’ve gotten used to firing off branches for every little thing that crosses your mind and seamlessly switching between them at a moment’s notice it becomes hard to work in the SVN mindset again.

Unfortunately, QLCC has hit a bit of a roadblock with Snow Leopard. More specifically, it’s not SnoLep that’s giving me a headache, it’s Xcode 3.2. With the new Xcode Apple decided to include their own QL plugin for source code. That’s great, I say, more choice is good! QLCC will render everything that Xcode renders plus OCaml files, Scala files, and all sorts of other interesting languages that Xcode can’t handle. I’m not worried about QLCC losing in a fair fight. But no, Apple doesn’t fight fair.

It turns out that Quick Look always picks the Xcode plugin when rendering source code files (on my machine, at least). I don’t think the Xcode plugin gets special treatment, it just happens to win in the algorithm QL uses to resolve plugin conflicts. What is that algorithm? Nobody outside of Apple knows. It could be a coin-flip for all we know. Heck, after a reboot it’s possible QLCC will always win! In any case, when there are two plugins that both want to render files of type public.source-code it seems like maybe letting the user pick one would be a good idea, right? Apple doesn’t think so. No, they don’t want users to worry their pretty little heads about such matters. Don’t worry about the algorithm, don’t worry about making choices, it’ll all be juuust fine. Have a lollipop.

Except it’s not all fine. Because let’s say a user decides that they prefer QLCC over the Xcode plugin. Their only option for getting QLCC consistently and predictably is to somehow disable Xcode’s plugin. They could remove it, rename it, or move it somewhere that quicklookd won’t find it. But who wants to do something like that to an Apple-supplied file? Nobody. Even worse, Xcode’s application bundle is cryptographically signed. I believe that disabling the plugin by any of those means will invalidate the signature, though I haven’t confirmed this as fact.

Update: After further research, it appears that disabling the plugin will not invalidate the signature on Xcode itself, so there shouldn’t be any terrible consequences if you choose to do so. The plugin is located at: /Developer/Applications/Xcode.app/Contents/Library/QuickLook/SourceCode.qlgenerator

So anyhow, QLColorCode 2.0 is out. It works with Snow Leopard. If you have Xcode 3.2 installed you’ll probably never get to see it do its thing, but maybe one or two of you will still get something out of it.

For what it’s worth, quick look still sends .plist files to QLCC. Xcode’s plugin won’t touch those things.

All is not quite well on the Snow Leopard front, however. The rsync that Apple ships (at least the one in 10.6.1) has a bug. When copying a FIFO it attempts to copy the contents of the FIFO. If you know what a FIFO is, you know why this is bad. So rsync hangs in the 90-fifo test of the test suite. When running from a terminal you can work around this by just hitting Control-C, which will cause the copy to stop and the other copiers to be tested. If you want to avoid the hang you can rename tests.d/90-fifo.test to tests.d/90-fifo.test.disabled or whatever floats your boat. I haven’t done that already because, well, a hang is arguably a valid test result!

Oh, and I also fixed a bug with the BSD flags test. If you care about that stuff you should re-test.

One other interesting tidbit — I changed the “lots of metadata” test to lock the file. This trips up some copiers that duplicate the “locked” status before setting up other metadata, causing the other metadata to be lost.

Much to my shame, I had an e-mail upheaval and I can’t find the names of the individuals who reported the BSD flags bug and the “early locking” phenomenon. If that was you, please drop me a message and I’ll give you the credit you deserve.

UPDATE: It was Rob Kennedy who reported the BSD flags bug and the “early locking” phenomenon. I hadn’t thought to search through my blog comments. Silly me! Thanks a lot for those tips, Rob!

First, to access a shared printer on another machine, you have to turn on print sharing on your machine. This defies all logic, but there you go.

Second, for some utterly inscrutable reason Apple decided to *dis*able the CUPS browsing protocol, leaving only Bonjour browsing working. ???? Stupid. Stupid. Stupid. It’s as if they said “let’s make sure Mac users will have lots of trouble printing to Linux servers, that’ll improve our customer satisfaction!” To fix this lameness, do the following:

Combining these two tips, the shared printer finally appeared in the “Default” pane of the new printer dialog and printing to it just worked. Hopefully Apple makes this more sensible in Snow Leopard…

Here’s how you test Time Machine with Backup Bouncer:

$ mkdir ~/bb
# We need to trick BB into thinking this is a volume it created
$ touch ~/bb/bbouncer-vol
$ sudo bbouncer create ~/bb
# Now do a Time Machine backup and wait till it's done
$ mv ~/bb ~/bb-orig
# Now restore the ~/bb directory from Time Machine.  
# Try not to catch SPACE MADNESS!!!
$ bbouncer verify -d ~/bb-orig ~/bb

On my Leopard 10.5.3 machine here’s what I get with BB 0.1.3:

Verifying:    basic-permissions ... ok (Critical)
Verifying:           timestamps ... ok (Critical)
Verifying:             symlinks ... ok (Critical)
Verifying:    symlink-ownership ... FAIL 
Verifying:            hardlinks ... FAIL (Important)
Verifying:       resource-forks ... 
   Sub-test:             on files ... ok (Critical)
   Sub-test:  on hardlinked files ... FAIL (Important)
Verifying:         finder-flags ... ok (Critical)
Verifying:         finder-locks ... ok 
Verifying:        creation-date ... ok 
Verifying:            bsd-flags ... FAIL 
Verifying:       extended-attrs ... 
   Sub-test:             on files ... ok (Important)
   Sub-test:       on directories ... ok (Important)
   Sub-test:          on symlinks ... ok 
Verifying: access-control-lists ... 
   Sub-test:             on files ... ok (Important)
   Sub-test:              on dirs ... ok (Important)
Verifying:                 fifo ... FAIL 
Verifying:              devices ... FAIL 
Verifying:          combo-tests ... 
   Sub-test:  xattrs + rsrc forks ... ok 
   Sub-test:     lots of metadata ... ok 

The only annoyance is that hardlinks aren’t preserved, but that’s not surprising considering the way hardlinks are used internally by TM to prevent wasted space. (I should point out that the hardlink failure here is not the same as the Apple rsync one I mentioned earlier today, and it’s not nearly as bad.) These results are not perfect but I would have no problem recommending TM backups to any less-than-hardcore user.

------------------ rsync-apple ------------------
Verifying:    basic-permissions ... ok (Critical)
Verifying:           timestamps ... ok (Critical)
Verifying:             symlinks ... ok (Critical)
Verifying:    symlink-ownership ... ok 
Verifying:            hardlinks ... ok (Important)
Verifying:       resource-forks ... 
   Sub-test:             on files ... ok (Critical)
   Sub-test:  on hardlinked files ... FAIL (Important)
Verifying:         finder-flags ... ok (Critical)
Verifying:         finder-locks ... FAIL 
Verifying:        creation-date ... FAIL 
Verifying:            bsd-flags ... ok 
Verifying:       extended-attrs ... 
   Sub-test:             on files ... ok (Important)
   Sub-test:       on directories ... ok (Important)
   Sub-test:          on symlinks ... FAIL 
Verifying: access-control-lists ... 
   Sub-test:             on files ... ok (Important)
   Sub-test:              on dirs ... ok (Important)
Verifying:                 fifo ... ok 
Verifying:              devices ... ok 
Verifying:          combo-tests ... 
   Sub-test:  xattrs + rsrc forks ... ok 
   Sub-test:     lots of metadata ... ok 

If you add a resource fork to a file that’s hardlinked to another file then only one of the files gets copied. This, no doubt, is due to the hackery involved to make HFS+ look like it has a real hardlinks when it actually doesn’t.

Some of the changes in BB 0.1.3 were a bit invasive and Bash is not the greatest of programming languages, so please keep your eyes open for bugs. If you see something in your results that doesn’t make sense just let me know.

So I wasn’t too surprised when a user forwarded me a somewhat exasperated-sounding note from Shirt Pocket software explaining why SD doesn’t pass BB’s FIFO and device file tests. I won’t paste the note in here, since I feel that would be poor form, but I will pass along their rationale for not copying these files. They feel that FIFOs and device files are normally system-created files that are not meant to be preserved across reboots or backups. For that reason, SD doesn’t back up these filesystem object types at all.

One can understand how Shirt Pocket arrived at this policy. Writing a good system-level backup tool is more subtle than it might appear. There are actually parts of the filesystem that you don’t want to back up, like caches, VM files, and so forth. You don’t want to back up the device files under /dev, since those get created dynamically depending on what devices are attached. In short, there are some parts of the filesystem that are tied to the state of the running system, and these should not normally be copied in a backup.

The problem with Shirt Pocket’s policy is that although it is certainly true that the system-created FIFOs and device files should not be copied in a system-level backup, there are legitimate reasons a user might create FIFOs or device files, and there’s every reason to preserve those user-created objects during a backup. Don’t get me wrong — this is obscure stuff that only advanced UNIX hackers would do, but hey, advanced UNIX hackers need reliable backups too! SD’s policy is, IMHO, overly broad. I would be much more comfortable if SD excluded filesystem locations rather than entire classes of filesystem objects.

The Shirt Pocket letter also accused BB of being “rather misleading to most” on this issue because it makes people worry about something that won’t cause them any problems. Although I vehemently disagree with the “misleading” characterization, I agree that not every BB test is equally important in practical terms. Most end-users will absolutely not care that tool X doesn’t backup FIFOs. This is why BB has always had a prioritization feature. Quoting from the usage string of bbouncer:

-T <set>     Use the given set of tests.  <set> can be either 
             "critical", for tests whose failure will cause problems
             for average users, or "important", for tests whose
             failure may not cause problems for many users, but which
             may be important to power-users or may qualify as 
             critical in the future.

The FIFO/device file tests are not included in either the “critical” or “important” set of tests. So I’m saying (and have always said) that most users, even most power users, won’t care about them. So why test for them at all? Consider the situation before Maurits’ blogged on backups and BB existed. Most people, myself included, didn’t even know what the full set of OS X filesystem object types and metadata was. Maurits filled us in on what existed, but knowing how to test for preservation was still a black art. BB was meant to democratize that testing, but also to act as an exhaustive test set. (I don’t claim to have achieved even close to 100% coverage, but that’s the goal.) So it’s important to me that BB include tests for any metadatum or filesystem object that can conceivably have a reason to be backed up.

Having said that, I’ll concede there’s a usability bug here. The -T option is unlikely to be discovered by casual users, and they’re the ones who need it most! It’s not used by autopilot and it’s not even documented in the README. So I think I’ll be making the following changes:

• I’ll document -T more pervasively
• I’ll have the priority of a test appear in BB’s output
• I’ll have BB default to running in “important” mode, changing the exhaustive mode to an opt-in option

Hopefully this will help prevent confusion for casual users and ease the support burden of tool developers while maintaining BB’s goals of providing easy backup tool validation and exhaustive test coverage.

Get it at the goog.

Well, it turns out to be trivially easy to do a QL plugin that renders HTML. Mix in Pygments, the very capable syntax highlighting engine that can output HTML, and you’ve got a syntax highlighting QL plugin in under 100 lines of code!

Rather than host this project myself I’ve decided to try making a Google Code project. You can find it here:

http://code.google.com/p/qlcolorcode/

Enjoy!

• VERY LIKELY BREAKS OLD SCRIPTEXPORT SCRIPTS!
• BREAKS COMPATIBILITY WITH IPHOTO 6 AND EARLIER!
• Ported to the official iPhoto ‘08 Export Plugin API.
• The set of metadata available has changed in the iPhoto ‘08 API, and these changes are reflected in ScriptExport. Summarizing the differences:
  • iPImageRanking is renamed iPImageRating
  • iPImageCaption is renamed iPImageTitle
  • Added iPImageIsPortrait and iPImageIsEdited
  • iPImageArchiveDate and iPImageModifiedDate no longer exist
  • Albums are handled much differently, so iPAlbumName, iPAlbumComments, and iPAlbumMusicPath no longer exist. See the documentation above for their replacements.
• The output window Auto-scrolls! Thanks to Kevin Reid for the example code.
• Fixed a crash when the source file for an image is missing.

Download the iPhoto ‘08 Export Plug-in SDK

ADC Members can download the iPhoto 2008 SDK package which includes documentation and sample code on how to write iPhoto Export plug-ins supported by iPhoto ‘08. With step-by-step instructions, you’ll learn how to make a simple file exporter plug-in using iPhoto’s Export Plug-in API. This sample plug-in will allow users to set export image size, quality, and whether or not to embed metadata in the output image.

I haven’t had a chance to look at the API yet, but yay! Hopefully the documentation will clear up some of the more confusing aspects of the API (like the threading model, for example), and I’m sure this means good things for its longer-term stability.

This is only in the svn version, folks, so don’t go downloading 1.4 and expecting greatness.

------------------ xar ------------------
Verifying:    basic-permissions ... ok
Verifying:           timestamps ...
   Sub-test:    modification time ... ok
ok
Verifying:             symlinks ... ok
Verifying:    symlink-ownership ... ok
Verifying:            hardlinks ... ok
Verifying:       resource-forks ... ok
Verifying:         finder-flags ... ok
Verifying:         finder-locks ... ok
Verifying:        creation-date ... ok
Verifying:            bsd-flags ... ok
Verifying:       extended-attrs ...
   Sub-test:             on files ... ok
   Sub-test:       on directories ... ok
   Sub-test:          on symlinks ... ok
ok
Verifying: access-control-lists ...
   Sub-test:             on files ... ok
   Sub-test:              on dirs ... ok
ok
Verifying:                 fifo ... ok
Verifying:              devices ... ok
Verifying:          combo-tests ...
   Sub-test:  xattrs + rsrc forks ... ok
   Sub-test:     lots of metadata ... ok
ok

Hmm, I guess that means it’s time to start thinking up some harder tests. Single-file backups? These are tricky on Mac because the finder puts the metadata for a whole folder into a single .DS_Store file. To do single-file backup right you need to be able to extract that one file’s metadata from the .DS_Store file, archive it, then reinsert it when you do a restore, all without disturbing the metadata of any other files in the folder. It can be done, but it’s not the easiest thing in the world.

------------------ xar ------------------
Verifying:    basic-permissions ... ok
Verifying:           timestamps ...
   Sub-test:    modification time ... ok
ok
Verifying:             symlinks ... ok
Verifying:    symlink-ownership ... ok
Verifying:            hardlinks ... ok
Verifying:       resource-forks ... ok
Verifying:         finder-flags ... ok
Verifying:         finder-locks ... ok
Verifying:        creation-date ... FAIL
Verifying:            bsd-flags ... ok
Verifying:       extended-attrs ...
   Sub-test:             on files ... ok
   Sub-test:       on directories ... ok
   Sub-test:          on symlinks ... ok
ok
Verifying: access-control-lists ...
   Sub-test:             on files ... ok
   Sub-test:              on dirs ... ok
ok
Verifying:                 fifo ... ok
Verifying:              devices ... ok
Verifying:          combo-tests ...
   Sub-test:  xattrs + rsrc forks ... ok
   Sub-test:     lots of metadata ... ok
ok

Now that’s one impressive result! They’ve got a bug in their tracker for the creation date issue, so hopefully it’ll be solved soon. There’s still an unfortunate issue with xar that prevents me from gushing uncontrollably about it — you can’t build a “xarpipe” to copy filesystem subtrees around. In other words, you always have to archive to a file, then unarchive from that file. This means that if you want to, say, transfer all your files from an old drive to a new drive you’d better have a third drive around, or your new drive had better be twice as big as the size of the files on your old one.

Do you back up your files? Of course you do! (Right? Right???) But do your backups work? Really? Are you sure? Have you checked?

Doing backups in OS X has always been a bit nerve-wracking. We’ve got resource forks, Finder flags, and various other odd metadata that don’t exist on other platforms. With the advent of Tiger, Apple told us that cp, tar, and rsync would finally be aware of our metadata and preserve it properly. And there was much rejoicing.

But then someone (or something?) named maurits actually tested these tools (and quite a few others), and the results weren’t pretty. This was a valuable wake-up call for many in the Mac community, but maurits never got around to releasing his test suite so we could do our own testing. Backup Bouncer is here to remedy this omission.

Backup Bouncer’s job is to keep the ugly backup tools out of the club. It’s here to show you exactly how bad (or, dare I say it, good?) your backup tools are. The way you use it is simple. First you create a couple of volumes:

bbouncer create-vol Src
bbouncer create-vol Dst

Next you create the test files on the source volume:

Now you use any old method you want to copy the files from /Volumes/Src to /Volumes/Dst. Once that’s done, you verify the copy and see how well (or poorly) it went. You can start by checking the “critical” properties — properties that you’ll almost always want preserved:

Next you can expand the scope to “important” properties — properties that power-users may find important or may be critical in the future:

Finally, you can see how the tool fares on the entire test suite:

As an example of how the results look, here are the results for ditto on the entire test suite:

Verifying:    basic-permissions ... ok
Verifying:           timestamps ...
   Sub-test:    modification time ... ok
ok
Verifying:             symlinks ... ok
Verifying:    symlink-ownership ... FAIL
Verifying:            hardlinks ... ok
Verifying:       resource-forks ... ok
Verifying:         finder-flags ... ok
Verifying:         finder-locks ... FAIL
Verifying:        creation-date ... FAIL
Verifying:            bsd-flags ... FAIL
Verifying:       extended-attrs ...
   Sub-test:             on files ... FAIL
   Sub-test:       on directories ... FAIL
   Sub-test:          on symlinks ... FAIL
FAIL
Verifying: access-control-lists ...
   Sub-test:             on files ... FAIL
   Sub-test:              on dirs ... FAIL
ok
Verifying:                 fifo ... FAIL
Verifying:              devices ... ok
Verifying:          combo-tests ...
   Sub-test:  xattrs + rsrc forks ... FAIL
   Sub-test:     lots of metadata ... FAIL
FAIL

Pretty bad, eh? On a more optimistic note, here are the results from Shirt Pocket Software’s SuperDuper!, one of the only tools to even come close to passing all tests:

Verifying:    basic-permissions ... ok
Verifying:           timestamps ...
   Sub-test:    modification time ... ok
ok
Verifying:             symlinks ... ok
Verifying:    symlink-ownership ... ok
Verifying:            hardlinks ... ok
Verifying:       resource-forks ... ok
Verifying:         finder-flags ... ok
Verifying:         finder-locks ... ok
Verifying:        creation-date ... ok
Verifying:            bsd-flags ... ok
Verifying:       extended-attrs ...
   Sub-test:             on files ... ok
   Sub-test:       on directories ... ok
   Sub-test:          on symlinks ... ok
ok
Verifying: access-control-lists ...
   Sub-test:             on files ... ok
   Sub-test:              on dirs ... ok
ok
Verifying:                 fifo ... FAIL
Verifying:              devices ... FAIL
Verifying:          combo-tests ...
   Sub-test:  xattrs + rsrc forks ... ok
   Sub-test:     lots of metadata ... ok
ok

Very nice!

Backup Bouncer also has a built-in set of “copiers”, to automate testing of command-line tools like cp, rsync, tar, asr, pax, ditto, and so on. You can run these tests using the “bbouncer copy” command:

You’ll get several pages of output, so I won’t show it all here. Finally, I’ve included an autopilot script that you can use to create some volumes, initialize the source files, run all the copiers, and verify the results.

You can get Backup Bouncer here.

Update: My ACL tests were broken. I’ve updated the output shown here to reflect the corrected tests.

It’s a nice feeling to see your name in the blogs you read on a daily basis, even if it happens on a Friday at 10PM PST and by Monday I’ll be the only one who remembers this ever happened. Maybe this is the push I need in order to finally get this thing to v1.0 status.

If you do need access to a machine where you don’t have an ssh account there’s also FTPFS and others. There are a ton of FUSE filesystems and it’s now become a pretty simple task to port them to OS X. In the easiest cases it’s just a recompile.

Anyhow, big props to Amit Singh for doing a great service to the Mac community. Get MacFuse here.

The new app is called Tangerine, and it automatically analyzes your iTunes library and adds BPM info for each song. It’s not always perfect (the app’s still a beta release), but it’s quite good. It also has a very slick interface — it’s actually got the functionality of an early release of iTunes! It even has a playlist builder that lets you visualize the duration and tempo of each song. One very cool feature is a auto-generator that builds a playlist for you with one of several tempo profiles! See the screenshot below for details.

When Tangerine makes mistakes it’s likely to be either double or half the correct value, and there are easy shortcuts for doubling or halving the value it calculated. However, there needs to be a better way to validate Tangerine’s BPM calculations within the app. When I’m playing a song, for example, I’d like to see a metronome animation showing me what Tangerine thinks the tempo is. For now, all you’ve got to go on is the numerical value, and I have to confess that I don’t have an internal feeling for what 92BPM should sound like. It would also be nice to have a tap-along method for fixing the BPM of a track that Tangerine got wrong. But hey, it’s a beta release so we can cut Potion Factory some slack.

All in all this is a very nice app that I’ve been wanting for a long time. Plus, if you report a juicy bug or blog about the app they’ll give you a license when it ships (not that that had anything to do with this post ) Check it out!