This article is categorized as "Garbage" . It should NEVER be appeared in your search engine's results.Table of Contents
相关参考书籍
备注：本笔记中出现的页码和章节，如无特殊说明，均来自《Fundamentals of ...》.
乐理术语中英文对照
vibrato：颤音，出现在《Fundamentals of ...》P126
portamento：滑音，出现在《Fundamentals of ...》P126 
chromagram: （暂无翻译），A chromagram presents the energy that is contained in the twelve pitch classes over time. （ref），以及wikipedia.
服务器炸了
服务器炸了！libwebp发布了v1.23，赶紧去更新一波。在性能过低的服务器上编译docker libavif和libwebp，内存占用太多，疯狂swapfile iowait，最后发现无论是nginx还是ssh（这些进程理论上优先级都很高）都无法响应，只能进入紧急救援模式然后把数据捞出来，然后重装系统。
MariaDB的编译版和二进制发行版性能
听起来像是暴论：MariaDB的编译版比二进制发行版性能要高不少！
注：二进制版和编译版的版本（10.6.8）、my.cnf配置、服务器配置（包括swap大小）、运行环境完全一致。
服务器崩了以后需要重装所有Wordpress相关的环境，为了节省时间使用了MariaDB的二进制发行版。二进制发行版能正常使用，但性能却离谱的低：最慢的时候打开wp-admin相关的页面需要花3～4秒甚至无响应，感觉就像回到了FastComet；preload的耗费时间增加了15～20秒；性能监控页面到处都是高负荷的iowait . 后来更换了编译版的MariaDB，性能一下子就回到了之前的正常水平。
使用最多最顺手的Linux swap教程
使用的最多最顺手的Linux swap教程：🔗 [How to increase swap space? - Ask Ubuntu] https://askubuntu.com/questions/178712/how-to-increase-swap-space
# 先检查当前swap
$ swapon -s
# 然后关闭所有swap
$ sudo swapoff -a
# 然后删除swapfile
# 比如在之前的$swapon -s命令中检查出/swapfile
$ rm /swapfile
# 然后开始创建新的swapfile
# 如果这条命令行不通（一般来说RAM<1GB无法执行这个命令）
$ sudo dd if=/dev/zero of=/swapfile bs=1G count=8
# 就执行这条命令
# count=4M=创建4GB swapfile
$ dd if=/dev/zero of=/swapfile bs=1024 count=4M
$ sudo chmod 0600 /swapfile
$ sudo mkswap /swapfile # Set up a Linux swap area
$ sudo swapon /swapfile # Turn the swap on
# 最后让swapfile开机启动
# 参考了：https://www.cloudbooklet.com/how-to-add-swap-space-on-debian-11/，并测试过一遍
# vim /etc/fstab，把原来的swap换成新的。
# example:
# /swapfile swap swap defaults 0 0
# 仔细观察磁盘信息，不要把最大的那块ext4也去掉了！如果还需要修改swappiness：
cat /proc/sys/vm/swappiness
sudo sysctl vm.swappiness=10
cat /proc/sys/vm/swappiness
如果需要开机生效：
sudo vi /etc/sysctl.conf
在末尾添加（或修改）：vm.swappiness=10解决”PHP Warning: Undefined array key”问题
解决"PHP Warning: Undefined array key"问题
🔗 [[Solved] Warning: Undefined array key - Exception Error] https://exerror.com/warning-undefined-array-key/
F-measures统计方法
就是TP FN FP FN的那一系列统计方法。也叫F-score，见：🔗 [F-score - Wikipedia] https://en.wikipedia.org/wiki/F-score
完全记错了Harmonic series的频率
补充知识：（书P241开始）5.1.1.2 Frequency Ratios
首先我发现我完全记错了一个重要内容：harmonics series的频率序列，补充笔记见：🔗 [2021-12-31 - Truxton's blog] https://truxton2blog.com/2021-12-31/ 的末尾。从大概这个地方开始。
Logarithmic Compression
补充知识：（书P125开始）3.1.2.1 Logarithmic Compression
首先是2个互联网资源，不一定和本话题相关，当作额外材料：
🔗 [在统计学中为什么要对变量取对数？ - 知乎] https://www.zhihu.com/question/22012482 🔗 [压缩数据用指数曲线好，还是对数曲线好？ - V2EX] https://v2ex.com/t/647043
首先回忆dB的计算公式，应该是类似这个样子：[mathjax]E_{d B}=10 \log _{10}(E)[/mathjax].
然后开始介绍logarithmic compression，它长得和dB的公式有点“相反”：
紧接着需要理解这张图：
c d e三张图的效果是怎么来的呢？
接下来学习logarithm compression的实际作用
书中P127页简要介绍了几种实际作用（部分作用在书本后面会实际提到，比如chord detection enhancement），这里暂时只明白了1种：应对乐器调音frequency shift带来的识别不准确问题（比如巴洛克调音可能会让A4<440Hz，部分现代管弦乐器可能会让A4>440Hz）.
最后：logarithm compression又被称为spectral smoothing；与此对应的是temporal smoothing .
今天从哪里开始？
2022-07-12和2022-07-14的笔记有未完成的内容：
chord detection（主要集中在后续处理的问题上）
今天试图在这个问题里继续
大概是从这个地方开始：
Chord识别的界限模糊问题
总的来说有以下2个因素带来和弦识别错误的问题：
1，弦乐器本身的固有性质（harmonic series partial），见：🔗 [2021-12-31 - Truxton's blog] https://truxton2blog.com/2021-12-31/
2，部分和弦之间的频率界限模糊（major–minor confusion），见P262的内容
乐器调音带来的问题
最重要的一句话：
Orchestras are sometimes deliberately tuned with a tuning frequency that lies above or below the usual 440 Hz.
《fundamentals of ...》5.2.3.3 Tuning
特殊乐谱问题
有的时候我们也想在这样的乐谱里识别和弦：
正常情况下识别和弦都会将音频信号拆分为（很短很短，比如30ms）的连续frames进行分析识别，但某些作品里的和弦被拆得很长很长。
解决方法之一是将音频信号拆分为较长的连续frames进行分析识别.
应对和弦识别问题的方法
书P266开始，针对上面提到的和弦识别的一系列困难，提出一些解决方法
考虑真实乐器带来的harmonic partial
加强策略：考虑真实乐器带来的harmonic partial
我们已经知道，chord detection的基本模式就是匹配频谱图和「一个事先准备好的和弦库」。如果和弦库质量越好，理论上识别的准确率就越高。
首先是我们的原始chord库：
它的缺点在于：没有考虑到真实乐器演奏带来的harmonic partials，是一个binary value（意思是对于一个note只会分配「0：毫无关联」或者「1：完全关联」），而不是像下面改进方法所说的一个“12维向量”。
补充：上面这张图的右边部分图片很容易第一眼看错。y轴实际上是12平均律，x轴是24个和弦模版，可以看出每一列（每一种三和弦）有且只有3个音符，恰好对应三和弦组成的3个基本音符，不能再丰富了。所以说上面这张图并没有考虑harmonic partials。
遇到了一个没见过的公式：
看起来有点陌生，为什么会这样呢？这是因为阅读的时候没有仔细阅读「5.1.1.2 Frequency Ratios」. 现在将这部分知识补充在本笔记前面。
在纠正了一个重要概念记忆错误以后，[mathjax]\mathrm{C}, \mathrm{C}, \mathrm{G}, \mathrm{C}, \mathrm{E}, \mathrm{G}, \mathrm{B}^{b}, \mathrm{C} \text {. }[/mathjax] 这个序列是可以理解的了。
所以很自然地，公式5.13也理解了！
另附：P266提到了，《Fundamental of ...》书中的某些例子会取[mathjax]\alpha=0.9[/mathjax] .
所以说这部分提到的改进方法就是：考虑真实乐器演奏带来的harmonic partial，使用12维向量代替原来的1维数值。
如书本P266所说，一个chroma C可以用以下12维向量表示（也被称为chroma feature）：
[mathjax-d]\mathbf{t}_{\mathrm{C}}^{\mathrm{h}}=\left(1+\alpha+\alpha^{3}+\alpha^{7}, 0,0,0, \alpha^{4}, 0,0, \alpha^{2}+\alpha^{5}, 0,0, \alpha^{6}, 0\right)^{\top}[/mathjax-d]
使用真实采集的数据进行训练
加强策略：使用真实采集的数据进行识别
典型的机器学习-监督学习方法，简单粗暴，有很多优化算法的发挥空间。
一张对比图，其中用到了logarithmic compression和smoothing算法（smoothing似乎还没学？）
Spectral Enhancement
加强策略：Spectral Enhancement
这部分内容似乎涉及到不少没学过的东西，先补全一些前置知识。
补充知识：Logarithmic Compression，写在本笔记前面
现在已经基本理解了Logarithmic Compression，
那么spectral enhancement的主体内容就结束了：logarithmic compression就是要介绍的东西。
Prefiltering
加强策略：prefiltering
不要看错了！HMM相关的内容是postfiltering
首先是这句话：
然后开始介绍temporal smoothing：
简单的说，就是用一个像STFT那样的滑动窗口从头滑到尾，然后给滑动窗口里的数值序列做平均...当然zero-padding是需要的。
这种方法往往又被称为interpolation，“插入平滑”。它有一些缺点，所以有的时候会提到它的改进算法：content-sensitive semantic smoothing，见：🔗 [2022-07-19 - Truxton's blog] https://truxton2blog.com/2022-07-19/
这种方法看起来非常简单高效，事实上也是如此。但是它还是有一些缺点，比如不能很好的应对beat-synchronous chroma . 如何更好应对beat-synchronous chroma的内容放在书本第6章beat detection的部分。或者见这个总结：🔗 [discrete signals - What is beat-synchronous chroma? - Signal Processing Stack Exchange] https://dsp.stackexchange.com/questions/41598/what-is-beat-synchronous-chroma
为什么会有beat detection这个研究方向？
为什么会有beat detection这个研究方向？
在阅读这个链接的时候发现的解释：
...
Since chromagrams are used for music applications, it is sometimes desirable to have a musical time axis, e.g. in beats. Since the tempo of music can change, the physical time span of an beat can vary. For converting physical to musical time, you could annotate the beat positions within the music or apply an automated procedure, kown as beat tracking.
...
https://dsp.stackexchange.com/questions/41598/what-is-beat-synchronous-chroma
后续
接下来就是postfiltering的内容了！今日笔记就写到这里。
