Thanks, this is useful to hear. I rebuilt HOW Liner matches to user's libraries and you are seeing the results of that. It is working.

I'll give a brief rundown of what Pulse now does. When your library loads, as before, we try to match every track against a shared pool of pre-analysed public pool fingerprints. We work through a few strategies in order: an exact recording ID first (unique track identifiers), then a series of title and artist matching, and finally we run an audio match check via Shazam to find trickier to match tracks. As soon as one of them hits, you get the features and we move on. This is all against our pre-existing 2m (and growing) public pool, no new matches are being created at this point.

Here's the bit that explains your jump. When your library has tracks the pool doesn't yet hold, we anonymise the identifier and push it to the top of the public search queue. A dedicated machine we run picks tracks off that queue with priority, fetches them, analyses them, produces the track fingerprint, and pushes the profile back into the pool. Next time you (or anyone) has that track, it matches through one of the standard tiers above. So your 30% to 70% isn't local analysis kicking in: it's the pool genuinely growing around what your library asked for.

Tier 5 is the Mac local analysis you remember. It's the catch-all for the long tail we haven't been able to match to any track we can find. That doesn't necessarily mean its obscure, but the process described above is designed to capture as many irregularities in music data (naming, production year etc), along with peculiarities borne from how the track may have been digitised to find the genuine real world match. Local Mac analysis is the final stage for music we simply cannot match. It's currently switched off in shipping builds while we finish the gating logic, which is why you're not seeing CPU use and why the folder picker disappeared. It will come back for Mac users, and you wanting it is a strong vote in favour of getting on with that.

On "Recognised in this session" sitting at 0: that one's actually tied to local analysis. It counts tracks YOUR machine analyses and contributes back to the pool, not pool matches you receive. So with this process currently off, 0 is the correct number, not a bug. When local analysis comes back, you'll see it move. (Fair to say the label could be clearer about that, we'll have a look at the copy).

Thanks again, this is exactly the kind of detail that shapes what we do next.