atppp's Blog

长期上水木的人可能知道一个 bug，有些 id 如果打完整可以 u 到，但是却不能空格补全。这个 bug 在 2001 年前就存在（之前没有 cvs 可查），2004 年末就被发现而且有了补丁，补丁注释写道：“这个bug导致的问题是使用smthbbs的站上有大概1/374的id是不可以通过id补全看到的”。2005 年又有人深入的研究了这个问题并且独立给出了一模一样的补丁（dvlt @ newsmth）。但是出于种种原因，这个补丁直到最近才递交进 svn。Bug 存在近 10 年之久，修正耗时 5 年，而补丁实际上只是增加 2 个字符，真是叹为观止。

类似的事情其实也不少，比如，libid3tag 不支持重写改变了长度的 id3v2 [1]；又比如，断词换行大战。

[1] libid3tag-0.15-1b (2004), file.c:594:

/* hard general case: rewrite entire file */

/* … */

画外音：点点点……（实际上修正这个问题的补丁早已在网络上流传四年之久）

偏振太阳镜里有块竖偏振片，用来滤掉横偏振光。大部分 LCD 发出来的光是 45 度偏振的，比如 iPhone 横握和纵握都可以透过偏振太阳镜看。但是也有设计的比较糟糕的 LCD 的，比如有人这样抱怨道：

… my car stereo LCD is unreadable with my sunglasses on. I have to tilt my head 45 degrees to read it, and it makes me look like a dog that just heard a weird noise. …

“像狗一样”，回想起来我戴着偏振太阳镜就常常会那样，有的超市刷卡机也有这个问题。最近发现有些 Canon 新相机的 LCD 是竖偏振，有人说，这不挺好吗，透过偏振太阳镜看恰好是最佳角度。可是如果要竖握相机拍照，我就啥都看不见了！真不知道 Canon 怎么搞的，甚至有的相机是用的横偏振 LCD（Canon SD 系列里，至少两款是竖偏振，一款横偏振）。

由于偏振太阳镜的推广，可能会在阳光下使用的设备其 LCD 的偏振性已经成为用户体验中很重要的一个部分。45 度偏振算是一个标准的解决方案，不过很多新的设备已经开始用非偏振 LCD 了，保证戴偏振太阳镜怎么歪头都一样，比如 Garmin 比较新的几款 GPS。

背景：偏振

想象你手里有一根绳子，绳子另一头穿过一片竖篱笆栏拴在树上。如果你上下晃动绳子，绳子上的波可以顺利传播到树上，篱笆像“透明”的一样；而如果你左右晃动绳子，绳子就会撞到篱笆的竹子，波也就只能传播到篱笆为止。这两种波，我们分别称作竖偏振波和横偏振波，描述的是绳子的振动方向。光是一种电磁波，也有类似的性质，而这个篱笆所对应的，就是一种叫做偏振片的东西。竖偏振光可以顺利通过竖偏振片，而横偏振光则不行；如果把这个竖偏振片转 90 度成为横偏振片，则情况会反过来。

大部分自然光，比如阳光，是非偏振光，也就是说没有一个特定的偏振方向，经过任意角度的偏振片之后都会损失掉一半的光。而自然光在水面反射之后，则会大部分变成横偏振光。如果透过一个竖偏振片去看波光粼粼的水面，则会发现波光几乎完全消失。同样的在玻璃上反射的光线也会有类似的性质，摄影时转动镜头前的偏振片，可以用来强调玻璃上反射的景物，或者强调透过玻璃看到的景物。偏振太阳镜，基本就是墨镜 + 竖偏振片。因为地面和前车玻璃反射的阳光基本是横偏振，几乎都被偏振太阳镜滤掉，所以通常推荐在开车的时候使用这类墨镜。

Wikipedia 说：

Technological applications of polarization are extremely widespread. Perhaps the most commonly encountered examples are liquid crystal displays and polarized sunglasses.

果然，我一篇文章就涉及到了这俩。

MA561LL，健康状况直线下降……

鸡皮疙瘩，英语里叫 goose bumps（事实上很多鸟类和哺乳动物都有类似的反射机制，所以不同语言里会用不同动物），指的是人或动物受冷或者有强烈感情冲击时（如惊吓、肉麻）皮肤发紧并出现密密麻麻颗粒的现象……对于有体毛的动物，这种反射机制可以将皮肤收紧并竖起体毛，有助于保暖，同时也可以在对敌的时候显得大一些，应该是进化出来的一种保护自己的机制。但是一般认为，这种反射机制对人类已经没多大好处，体毛没了，但是调节的机制还在，属于进化遗留。

美国斯坦福大学附近曾经多次报道出现山狮，甚至有山狮在住宅区活动的报告，一度搞的人心惶惶。动物学家在告市民书中说到：“When encountering a mountain lion, it is advised to appear as big as possible. If attacked, fight back. ”同学们对“appear as big as possible”这一条一直津津乐道，其实和上文提到的鸡皮疙瘩的保护作用是类似的，块头越大其威摄力也越强。鄙实验室的路易每次讨论激光束大小的时候都要说“Size does matter.”，后来甚至在正式 poster 和 presentation 上也用超大字体写下这三个词作为副标题，搞的我等群众常常在一旁因为其双关甚至三关的含义而掩面淫笑。

1. 某次和 delphij 以及某帅哥出去吃饭，席间 delphij 说到他前一天寄出了来美之后的第一封（邮政）信。帅哥问道：是不是寄给自己，内容是 test？
2. 某次和 delphij 提到大型强子对撞机会不会把人类灭掉的问题，大神说：这其实是一个 feature。（请从宇宙宏观和进化论角度理解这句话）
3. Google map 搜索 delphij near bay area，居然真的有……

好冷……Delphij 有向 Sheldon 发展的趋势。

康神伟大。

立此存照。

按照惯例，每年夏令时开始和结束我都要在这里向大家汇报一下……

WordPress 现在貌似还要手动调夏令时。

现在美西（UTC -7）和北京（UTC +8）时差 15 个小时。

一篇有意思的文章：电脑时区选择中没有北京的问题。

这是一个纯技术笔记贴，只供我自己和某些人参考，不解决任何实际问题。

1. MP3 数据量

MPEG audio frame header 可参考比如这里。MP3 最常见的的格式是：MPEG version 1, Layer 3, 44.1 kHz，所以 frame header 的前两个字节一般是 0xFF 0xFB。

音频数据一般用 CD 音质：立体声，44.1 kHz 采样，16 bits ADC，数据量 1411 kbps。MP3 有损压缩到 192 kbps 一般足够普通音响使用，最高可以支持 320 kbps。

无损音频压缩一般可以压缩到一半（700 kbps 左右），常见格式 APE, Apple Lossless, FLAC。

2. MP3 的元数据 ID3 Tag

有两种常见的 MP3 Tag 用来存储歌曲信息：id3v1（文件末尾 128 个字节，以“TAG”开头）和 id3v2（一般在文件头，长度不定，以“ID3”开头）。id3v2 有过至少三个版本，最流行的是 id3v2.3（1999 年发布），最新的是 id3v2.4（2000 年发布）。id3 读写库：id3lib（比较老），libid3tag（from MAD）等。这些库一般优先使用 id3v2 的数据，如果某些域没有数据，再从 id3v1 里取。

id3v2 的 frame 数据长度要求至少一个字节。如果没有歌名信息，那么歌名这个 frame 应该去掉而不是留下 0 字节的歌名域（有些 mp3 管理器有这个问题）。有些 id3 读取库严格执行标准，碰到 id3v2 中出现 0 字节的 frame 不容错而是直接忽略掉整个 id3v2，造成无法读取部分 mp3 歌名（比如 libid3tag 以及基于它的 EasyTAG）。

3. ID3 Tag 的编码问题

id3v1 采用 ISO-8859-1 编码，在理论上，它是无法正确存储中文歌名的。id3v2.3 除了可以使用 ISO-8859-1 编码外，也可以使用带 BOM 的 UTF-16（原规定是 UCS-2，编码信息存储在文本 frame 数据第一个字节，id3v2.3 3.3 节）。尽管如此，很多中文 mp3 还是用 GBK 编码（并号称自己是 ISO-8859-1 编码）写入 id3v2.3，所以会和 id3v1 一样有编码问题（mojibake）。对于这类 mp3 文件，大多数 Windows 的播放器在中文区域下都可以正确显示中文歌名；但是 Mac 和 Linux 下一般要进行 mp3 tag 编码转换，比如：EasyTAG，ID3Mod，nLyrics。有些 tag 编码转换程序只能写入 id3v2.4，这个并不是最理想的，后面会解释。另外，针对 ISO-8859-1 编码的 tag，某些播放器会猜编码。歌名越长，猜中几率越高，但是一个字的歌名常常猜不对。

id3v2.4 除了可以用 UTF-16 外，也可以使用了 UTF-8 编码（id3v2.4 第 4 章）。电脑上的播放器现在应该都支持 id3v2.4，但是某些播放器（特别是便携设备上的）由于 codebase 的关系，可能还在使用只支持到 id3v2.3 的 id3 库。这些播放器一般不会直接忽略掉 id3v2.4 的 tag，但是不能读取 UTF-8 编码的歌名。这样看来，为避免编码问题，最好的做法是：用 UTF-16 编码写入 id3v2.3，并且删掉 id3v1；假如 tag 转换程序只能写入 id3v2.4，应该使用带 BOM 的 UTF-16 编码（id3v2.4 第 4 章：text encoding description byte = 0x01）。

补：Windows 资源管理器和 Windows Media Player 对 id3v2 的 Unicode 编码支持很差，上述做法不适用（谢谢 neturalyu 留言提醒）。