Engineering1 min read
How we built search that answers in 40 milliseconds
Filenames lie, packs reuse the same names, and producers type “dark 808 F# 140”. How the Prod Crate search index turns shorthand into the right sound.
Theo LindqvistEngineering Lead
The first version of search in Prod Crate matched filenames. It was fast and nearly useless. Sample packs name files things like Kick_04.wav or PL_TRAP_120_Am_Loop_7.wav, and a library of 60,000 files has hundreds that share a name.
Search the sound, not only the name
Every file is analyzed once, on upload. We detect the instrument, key, and tempo, measure length and loudness, and read whatever the pack author put in the filename and metadata. Those become structured fields next to the name, so F# means the key of F sharp, not two characters in a string.
Parsing what people type
Producers don’t write queries, they write shorthand. The parser splits “dark 808 F# 140” into the parts it recognizes: a key, a tempo, an instrument, and free text. The free text is matched against names, pack titles, and tags, and everything else becomes a filter.
- Keys match their enharmonic spellings and relative keys, so F# minor also finds Gb minor and A major
- Tempos match within 1 BPM, with half and double time ranked just below
- Instrument words map to categories, so “hat”, “hh”, and “hi-hat” mean the same thing
Keeping it fast
Each library has its own index, held in memory on the search servers and updated within a second of an upload finishing. A query touches one index and never the audio, which keeps the median response at 40 ms for libraries up to 250,000 files.
Similarity Search runs on the same index. Instead of matching text, it compares the measured shape of each sound: attack, tone, and length. That one gets a post of its own.