Filed Ohm analyses thirty seconds of every song

Every song Ohm plays is matched to the next one based on thirty seconds of it, and those thirty seconds aren’t always representative. Ohm doesn’t analyse the full songs you play, but Apple’s thirty-second preview of them. So whether the next song fits depends on what those thirty seconds do and don’t capture, and I’ve had to learn exactly where that goes wrong.

Why it’s thirty seconds

When I tested it in June on an iOS beta, the full track wasn’t available. For a song streamed from my Apple Music library, the phone’s file reference came back empty, so there was no audio to hand to Apple’s analysis framework. The framework wouldn’t read a preview straight from Apple’s web address either. It only worked once the file was downloaded. And it runs only on Apple hardware, not on Ohm’s Linux server. This is by Apple’s design via FairPlay, their DRM technology. So I set up a Mac to download each preview, analyse it and delete it.

The previews are reliably thirty seconds long. Across 13,767 of them, the median was 30.000 seconds, and 99.4% were within a tenth of a second of that. Nearly all the shorter ones were whole tracks under thirty seconds.

Which thirty seconds

The thirty seconds you get aren’t fixed by the song. Apple attaches a preview to each release: the album, the single, every compilation. The same recording can have a different preview on each. That means two listeners with the same song in their libraries, one from the single and one from the album, can have it analysed from different thirty seconds.

Frank Ocean’s Biking shows the limit. In its preview, Apple’s framework detects vocals and other instruments, in D major at 74 BPM, but no drums and no bass. Anyone who knows the song knows both come in later. So the song I’m matching on is sparser than the one listeners actually hear.

Readings that don’t hold still

The biggest surprise was that some readings aren’t stable even on the same thirty seconds. I read the same 100 previews four times. The key never changed, and tempo, beat and section loudness stayed within 0.01 on 93 to 98 of them. Overall loudness didn’t hold. 14 of the 100 came back with two different values, and the second was 0.4 to 7.2 dB louder than an independent loudness meter reads.

That matters for the product. A score built on overall loudness could move a song from calm to intense between two reads, with nothing about the song changing. So I can’t trust a single read of overall loudness.

The framework’s sense of which instruments are playing also follows volume. Turn a preview down 10 dB and every instrument reads as less active. Left alone, that would make quietly mastered songs look sparser than they are. So I level every preview to the same loudness before reading the instruments.

How I use it

I measure how close two songs sound by the instrument activity in their levelled previews. Between one song and the next, I avoid big jumps in tempo, pace or how much singing there is, because those are the jumps a listener notices. Both rules work on the preview, not the whole song. This is just one approach to doing more with less.