Skip to main content

记忆中的音乐寻宝

编程的各个环节中,我最喜欢的恐怕是调试,尤其是调试不熟悉的代码,比如逆向工程。从某些方面来说,调试就是侦探的工作,慢慢收集线索,整理思绪,利用推理和想象力找到真相。我很享受收集情报,然后逐渐从无序变成有序的过程。

而音乐搜索则对我一直是一大难题,想起一段熟悉的旋律,或者听到陌生而优美的曲子,我总是很急迫的想知道曲子是什么,找到完整的曲子,或者乐谱。但是音乐搜索恰恰又很困难,有歌词还稍微好一点,没有歌词有主旋律也可以试试哼唱检索。但是一些多声部,或者复杂一些的曲子就没办法了。随着时间推移,有时连旋律都忘了,只记得“有那么一段优美的旋律,而我不知道它叫什么”,如鲠在喉。

前阵子同事跟我提到Google App的音乐搜索功能,虽然之前也知道这个功能,但其实都是偶然触发,并没有想搜音乐。后来去麦当劳时,觉得BGM挺好听,就用Google App搜了一下,虽然由于周围环境噪音的原因总是不能捕捉到声音,不过最后我像傻子一样把手机高举过头顶,还是一次就找到了结果:  Lianne La Havas - Lost & Found
话说到这,就刚刚我又想起另一个麦当劳放的曲子,由于有歌词,没花多久就找到了: Alex Winston - Sister Wife

前几天别人发我一个Youtube视频,我对BGM很感兴趣,也是很容易就搜到了:Dr Dre - The Next Episode。跟她提起这个音乐时,我猛然想起自己的一个“有那么一段优美的旋律,而我不知道它叫什么”的回忆。然而我已经完全不记得曲子的旋律,以及在哪里听到这个曲子了。当然一旦听到曲子我肯定能发应过来。我总觉得人的记忆是单向hash,比如四句的唐诗,给出第二句背第三句就很容易,反过来就难很多。

决定试一下再次挑战,因为我觉得如果能再次找到这个音乐,Google App八成能搜出来名字。

一开始发散思维,回想是哪里听到的。这是最难的一步。冷静了一会儿想到那是一个找不同的游戏。于是第一反应是去Kongregate上找,搜到的找不同游戏只有三个(别的都不太像),为了找到BGM也只能全都通关一遍。好在游戏都不太长,并且游戏也不错。顺便也搜了一下游戏的BGM,很有趣。不过不幸的是那段音乐不在这几个游戏中。

说到这种枚举的事情我也不是第一次做了。小时候玩的FC游戏Moon Crystal也是这种情况,后来上大学以后去梦幻岛翻遍FC游戏截图才找到。小学或者是中学时也有跑遍书店找一本语文参考书的经历。看来我不是一般的偏执。

排除了Flash游戏,于是想到Windows App,搜了一下购买历史无果。

于是想到iPad,按照difference, spot, find这类关键词搜,然后看到找不同的游戏就下载ipa然后扒开看。然后,第二个游戏就是我要找的!

原来是2012年2月我下载了一个ipad的找不同游戏,叫做 Find the Difference for iPad, 其中有一段BGM我很喜欢,用midomi/SoundHound只搜出一个结果,但是不是这首曲子,而是另一首,只是中间有几秒钟插入了这一首。扒开IPA文件找到了音乐文件,也没发现有用的信息。虽然痛苦也只能不了了之。而直到今天早些时候,我对于年份,app以及旋律都没有印象了。

兴奋之余,赶紧拿出Google App搜索,不过搜了几次给出的结果都不一样,其中大概一半完全没关系,而另一半确实是这个曲子,不过长短和名字都不一样:

Im Bett Bleiben by Weckertöne (闹铃)
Royalty Free Music Crew - I Don't Want to Leave You
Beardyman - Nothing To Undo (这个就是之前用midomi搜出来的)

而后从youtube评论又找到了其他名字

Buddy (iMovie曲目)
Bobby Cole - Martini Jazz

Bobby Cole还有一个曲子叫Cocktail Sipping Jazz,听着有点相似,不过并不相同,速度也更快。

所以最后结论是这首曲子(原始)叫做Martini Jazz,乐谱还没找到正式的,倒是有Buddy听写谱,这个之后再说吧。目前已经够我兴奋一阵的了。

回顾一下搜索的过程,尤其是我的记忆的模糊情况和推理都很有趣。万幸是我想到了找不同游戏,要不然其他都是扯淡。另外就是Google音乐搜索真不错!





Comments

Popular posts from this blog

A Rocky Migration: Moving from docker-compose to Podman and gVisor

I've been running a few containers for several years. They were all running under rootless Docker with a single user. Initially, I planned to  migrate the containers to VMs , but I couldn't get a stable workflow after about two months of effort. Later,  gVisor caught my attention , and I decided to migrate to Podman with gVisor instead. The new plan is to run each container with  --userns=auto  and use Quadlet for systemd integration. This approach provides better isolation and makes writing firewall rules easier. I'm now close to migrating all my containers. Here are a couple of rough edges I'd like to share. Network Layout I compared  various networking options  and spent a few hours trying the one-interface-per-group approach before giving up. I settled on a single macvlan network and decided to use static IP addresses for my containers. To prevent a randomly assigned IP address from conflicting with a predefined one, I allocated a large IP range for my ...

Exploring Immutable Distros and Declarative Management

My current server setup, based on Debian Stable and Docker, has served me reliably for years. It's stable, familiar, and gets the job done. However, an intriguing article I revisited recently about Fedora CoreOS, rpm-ostree, and OSTree native containers sparked my curiosity and sent me down a rabbit hole exploring alternative approaches to system management. Could there be a better way? Core Goals & Requirements Before diving into new technologies, I wanted to define what "better" means for my use case: The base operating system must update automatically and reliably. Hosted services (applications) should be updatable either automatically or manually, depending on the service. Configuration and data files need to be easy to modify, and crucially, automatically tracked and backed up. Current Setup: Debian Stable + Docker My current infrastructure consists of several servers, all running Debian Stable. System Updates are andled automatically via unattended-upgrades. Se...

mkosi: First Impressions

I stumbled upon the Gentoo wiki page for systemd-nspawn , which in turn led me to nspawn.org , mkosi , and later systemd-sysupdate . mkosi quickly caught my eye because it's almost exactly what I wanted to build myself, as mentioned in a previous post . So, I decided to spend my "sysadmin fun quota" on it. Overview mkosi is similar to docker build or podman build , but it's designed for creating full OS images. It focuses on development and testing. For example, much like nix-shell , mkosi can quickly launch a sandboxed shell with a specific distribution and selected packages installed. The systemd project itself uses mkosi for testing across different distros. The re-introduction article  is a great read. Speed Note that this is by no means a rigid benchmark. My setup is an SSD with LUKS and an ext4 filesystem (without reflink support). Building Container Images mkosi is pretty fast. A simple mkosi command creates a fresh Debian image. I used the --incrementa...