People kept asking if they could pay for AnandTech, and they said “we'll think about it” for years until they shut down instead because it was financially unsustainable.
For me, mostly a lot of false negatives. I have a Pixel 8, and I have no problems using the microphone normally, but somehow, Merlin requires the bird to be within a couple of meters of me and sing for quite a while before Merlin will even say “hearing a bird”. And of course, you have to be dead silent; if anyone talks or coughs, it will mess up the spectogram badly.
Given that it's colloquially “Shazam for birds” and Shazam is just amazingly resistant to noise, it's a bit disappointing :-)
I think what makes Shazam magically "just work" is that they are searching for the exact embedding of the recorded version of the song - it doesn't work for a cover version, acapella, etc even if it is very similar. (Everyone would want an app that you can hum into and it will ID the song, but I guess it's a very tough problem.)
Merlin is solving the more general problem so makes sense that it's much more finicky and less accurate.
Still, we're talking orders of magnitude here. I've fed Shazam with a stream of the cheapest lapel microphone you could get, mounted behind a rack filled with twelve very noisy servers, in a hall filled with 5000 people also all being noisy, and it would reliably recognize music from the other side of that hall before I could do so myself (I had to walk halfway there to hear “oh, yes, it's actually right”). And that's on a stream encoded with 9600bps GSM compression. With Merlin, I can hold out my phone on a silent day, hear the bird loud and clear and it will hardly register.
Shazam primarily identifies on the geometry of spectogram peaks, FWIW (I wrote my master's thesis on the DSP of music recognition back in the day; it's possible that they are doing something more fancy now, of course, but I'm not sure if they would want to). I don't know exactly what Merlin is doing.
> an app that you can hum into and it will ID the song
YouTube Music and Google Search do OK with these types. Sometimes if I know a song well enough, I will open YT Music, activate the mic search, and sing a few bars, instead of typing the song title.
According to Gemini, SoundHound is also a good app for song-hummers to try.
I'm not sure why but this seems very phone dependent. I can stand next to another person, both running Merlin in silence, and mine will pick up much more than some people's phones. My phone is not particularly new (Zenfone 8).
For any complex system, there's never one single trick or design choice that makes it fast. It's always a large amount of engineering (or exaggerations, of course).
> Yeah, it's not nearly as cool to say "I prompted a probabilistic pile of tensors and it did the hard work for me", and I think it majorly adjusts how "impressive" projects are.
Vibe-decomped projects are also… a different result.
A matching hand-decompile is useful in itself, but it also serves as a proxy for how well you understand the project; how good are the function and variable names, are the structures good, do you understand the entire flow. There are plenty of LLM-decompiles out there that just match but still every variable name is “unk14”, where every flow is total spaghetti instead of going back to something closer to what a human would have written, or even tons of __asm__ statements. The match stopped being a high-quality proxy metric for the quality of the project as a whole. (There are also LLM-assisted decompiles that are high-quality, but then usually with significant human input. And of course, you can try to ask the agent to clean up the resulting mess after you're done matching, assuming you have any tokens left.)
Of course, if you just want the binary back and collect Internet points, you don't care about any of this. But decompilation projects are often made for either a) understanding the game better (for speedruns, TASes, or just general explanation), or b) modifying it. And for both, it is much nicer to have source that is closer to the original.
> Historically there was a notion of "clean room" reimplementation
These projects start off with the original assembly code and use it actively throughout all stages. This is about as far away from clean room as you get.
These projects do not start with assembly. They start with machine code interleaved with data. Even getting to assembly through a disassembled requires some input and understanding. Usually these are raw binaries with no (or limited) metadata.
When run through a disassembler, in most cases, it’s probably the first time anyone has ever looked at the assembly (assuming PlayStation or newer). There are no comments or labels or symbols. Not what most people would consider “the original assembly”.
The term "original assembly code" is sufficient enough to communicate that the binaries that are being reversed are what is disclosed to the public intentionally.
Their comment still stands; whether it's machine code or "original assembly code" that shipped on the disk it falls under "clean room" reversing and by extension implementation.
Being available to the public if they bought the game doesn't mean it's in the public domain and you're allowed to upload a copy of it (or a derivative work) onto GitHub, though
(I like these projects but I really don't think they could defend themselves legally if you company went after them)
> I think he's saying that building a browser is not a transferrable skill, like making a generic web page is. Employers don't like specialists.
I recently switched roles, and among the seven places I interviewed, none of them seemed to see my then-current browser job as a problem, even though they were not related to browsers. (The closest one was a company implementing a HTTP reverse proxy, and I did not work on the browser's HTTP stack.)
Yes. Which matters a lot when you cannot just update OS kernels willy-nilly (most people did not have Internet connectivity, Windows Update did not exist before Windows 98).
People kept asking if they could pay for AnandTech, and they said “we'll think about it” for years until they shut down instead because it was financially unsustainable.
reply