关于fb2k专辑列表(Album List)分层tag的一些蛋疼小研究

专辑列表(foo_albumlist)是foobar2000原始携带的一个有关媒体库的扩展,用于将媒体库的歌曲以树状图的方式展示出来,便于挑选歌曲。对应的CUI版本是foo_uie_albumart。如图所示:

专辑列表的运作方式是,通过一系列的字段,将歌曲按照相应的tag、元数据等分割成不同的层次,形成一个树状图。下面是一个范例:

%<genre>%|[%album artist% – ]%album%|[[%discnumber%.]%tracknumber%. ][%track artist% – ]%title%

这是其自带的一个按流派分割的格式字符串。其中“|”分割了不同层次。而对于每一层次 只要某些歌曲的那些tag属性所形成的字符串一致,那么就会被分在一起。比如两首歌都具有JPOP的genre,那么他们将会分在同一个第一级;如果album artist和album都相同的话那么在第二级也会处于同一个分支中。

本次要研究的是其中一个很微小的问题。请看第一级:

%<genre>%

我们都知道%genre%表示歌曲tag中的genre属性即流派,那么这一对尖括号代表了什么呢?我曾试着将它改成%genre%,也没有发现有什么区别。但经过参阅一些文档,我基本搞清了其中的差别,故记录于此。

首先,其实可用的远不止%genre%和%<genre>%,而是有下面这么多种(为了便于说明remapping的概念,我改用artist来做例子):

%<artist>%
%artist%
$meta_branch(artist)
$meta_branch_remap(artist)
$meta(artist)

先从$meta(artist)说起,这个最简单,就是读取歌曲文件metatag中的“artist”字段,没有其他处理了。但是我们可以观察到,很多歌曲都有诸如album artist、track artist等一大串相似的字符串,有些时候可能一个歌曲只填写了album artist没写artist字段,但是很显然这里的album artist就是我们想要的,如果用$meta(artist)却只会读到?。为了解决这一问题,foobar中默认的字段读取时都有“remap”这一概念——就是依次读取多个字段以获得理想的值——

%artist% 艺术家名。依次检查下列元数据字段: “artist”, “album artist”, “composer”, “performer”。

上面这段是从titleformat_help里摘录的。所以,%artist%这种写法,实际上就相当于是$meta_remap(artist)(但是注意,这种写法实际并不存在)——除了一点点小区别,就是%artist%碰到没有值的情况下(由于有remap,所以即artist、album artist、composer以及performer这几个字段均没有值),会输出?号,也就是说它等价于$if2($meta_remap(artist),?);而上面列的那几个$meta_****(artist)系列都不会输出?值,这样意味着,对于一个没有任何艺术家信息的歌曲,那么在以类似$meta_branch(artist)这类字符串分层时,将会完全被忽略掉,而如果用的是%artist%,这类将会被统一分配到?中。

OK既然明白了remap,那么应该各位很快就会注意到另外一个词语——branch。没错,这也是本次的重点,也就是%<artist>%和%artist%的不同点所在。Branch,意为分割,分支,这里的意思是指,会将拥有多值的tag按每个值分开。相信很多人都没用过吧(包括我,这也是我为何一直没发现%<artists>%和%artist%区别的原因),foobar支持在一个字段中填入多个值(编辑的时候,用;分割),比如artist=artist1;artist2。而所谓branch,就是如果一个歌曲a有俩artist,那么在形成artist级时将会出现两个分支树一个是artist1一个是artist2,里面都含有歌曲a;如果没branch,那么将有一个分支树,名字叫做artist1, artist2,里面含有歌曲a。前者的优点显而易见——如果你有歌曲b的artist是artist2;artist3,那么将可以在artist2的分支里同时找到歌曲a和b。%<artist>%和%artist%的区别就是,前者带branch,后者不带;也就是说前者基本和$meta_branch_remap(artist)同义——依然除了一点,就是无值时的问题啦,所以准确地说,%<artist>%=%if2($meta_branch_remap(artist),?)。

OK既然搞清楚了这俩概念,那么上面那5个字符串的意思也就明了了:

%<artist>% – 按artist tag分类,含branch和remap,含空值处理
%artist% – 按artist tag分类,含remap,含空值处理
$meta_branch(artist) – 按artist tag分类,含branch
$meta_branch_remap(artist) – 按artist tag分类,含branch和remap
$meta(artist) – 仅按artist tag分类

我们来看个范例。

这里有5首歌。1有3个artist字段,2、5没有artist字段,3、4各有一个artist字段;1-3有album artist字段,4、5没有。

按%<artist>%分类——3、4分别分配到了对应的artist里,1同时出现在artist1、2、3中(branch),有album artist没有artist的2被分到了album artist的分支里(remap),而两者皆无的5被分到了?里。

按$meta_branch(artist)分类。3、4分别分配到了对应的artist里,1同时出现在artist1、2、3中。两个没有artist字段的歌曲2、5从其中消失了。

按$meta_branch_remap(artist)分类。3、4分别分配到了对应的artist里,1同时出现在artist1、2、3中,有album artist没有artist的2被分到了album artist的分支里,而由于不设空值分支,5依旧消失。

按%artist%分类。3、4分别分配到了对应的artist里,1被分配到了一个叫做“artist1, artist2, artist3”的分类中。5在?,2被remap到Album artist中。

按$meta(artist)分类。3、4分别分配到了对应的artist里,1被分配到了一个叫做“artist1, artist2, artist3”的分类中。没有remap也没有空值分支,那么2、5就只能继续玩消失。

看了这个范例,是不是很清楚了呢?不过需要补充几点:

1. 在同时有branch和remap的情况下($meta_branch_remap(artist)以及%<artist>%),remap过来的字段也会branch哦。即是说:如果一个歌曲没有artist字段但有两个album artist字段,那么将会被同时分支到album artist1和album artist2中。

2. 分支后面若有括号数字,是此分支下子分支的数量,并不是曲目数量哦(虽然很多时候是相等的)。

3. 一个很遗憾的消息——cuesheet并不支持字段多值。所以branch那些玩意玩无损的都玩不上。不得不说,无损音频+cue(无论是内嵌还是外挂)这种形式对于数据库整理实在太不方便,这不但体现在这里,还有插入专辑封面等一堆鸟事儿。

参考:

1. Foobar2000:Components/Facets (foo facets)
—因为Facets采用和album list一样的语法 故可参考其说明。
2. Foobar2000:Title Formatting Reference
3. Foobar2000:Titleformat Album List

那日所见花儿之名我们仍未知晓

好久没追番了,但是上一季的放浪息子和小圆脸让我又重新对动画拾起了信心,于是本季决定重新开始追番。一开始挑中了很多部,但是后来基本弃得只剩两多花了(顺便一提,弃掉C真的是一个英明的决定啊!)。花开雷霆崖实在是太让人失望,简直俗套的一塌糊涂,俗套就罢了,如果是校园生活的日常我还蛮喜欢的但是宾馆的梗就很没有感觉了。而剩下的那朵花,看前几集是有希望成为一部优秀的作品的,而且11话这个相对较短的集数,也是个人比较喜欢的长度,花开之所以会毁也和它非要凑够两季不无干系。之前由于ck的720P拖片所以进度一直到第四话,今天播送完结话,介于这怎么也算个剧情片,为了防止丧心病狂的剧透大潮我最后两话赶紧上rmvb连着把后面的都看了。

本片的剧情总体而言不错。一切围绕着面麻的愿望展开,但是面麻自己其实并非故事发展的中心。中心人物大概是先anaru然后雪集然后鹤子,中间穿插仁太,波波倒是算是个打酱油的。可惜第九、十集为了给最终话铺垫,剧情发展的实在太快太乱:先是乱点鸳鸯谱,然后在大家都知道面麻的存在之后,仁太就显得无比自私。面麻抓鲤鱼和拷问仁太大会这两件昨日重现的发展也不甚合理,前者对推进剧情也无甚帮助(可能只是为了给第九集制造一个泪点?参见下一段)。最后大家抬着烟花去发射的场景简直是像要活埋掉面麻一样,相当黑啊。不过最后一集倒是比想象的好——其实这么说也挺没道理的,因为最后一集大家聚在一起哭的场景实在是天雷滚滚,而且心境的转换也很突兀(另外,个人觉得波波的黑历史实在是加入得太生硬),面麻那个愿望也有点莫名其妙——但是确实出来的效果挺不错。本来有一些话想骂的话,这时候也烟消云散了,这片也算是善始善终了吧。

本片最大的败笔,就是煽情太用力。感情是需要一个沉淀过程的,作为一个催泪片,你需要做到的是在情节充分自由发展的情况下人物情感的自然流露,从而带领观众自然而然地为之动情。本片的问题不在于人物的情感表达得不自然,而在于情节安排的生硬:几乎每集都有剧中人物在哭泣的场景,而且通常是集中在末尾,一个小小的事件触动了某某人,然后就合着ED开始煽了——喂喂,你不是美剧好不好,没必要每集都要煽一次嘛,所谓张弛有度,自然只有弛了,张的时候才会更加有力;看多了只会感情上疲劳而已。

另外还有一个不得不提的就是面麻的物理干涉的问题。导演对于这个问题的处理可以说是完全前后矛盾,在前面想替他辩解的观众总是在后面被导演打脸,实在是让人无比的囧。导演又想让人注意到面麻会对现实进行干涉——因为这是第八集乃至最后的剧情需要——又不想让人对此追究问底,这本来就是不现实的。于是实现的效果就是前面前面先是让人疑问既然能做面包、吃肉干嘛不直接写字、后面观众好不容易忘记了这个问题,想可能是导演想刻意回避的时候,却又跳出来写字…真的让我整个人都233了。有人可能会说了,是面麻和仁太由于私心可以不想去证明的——没错,仁太确实有这种想法,但是别的伙伴可是非常想确认面麻的存在!既然仁太都在伙伴面前宣告了面麻的存在了,接下来要不要证明就不是你自己能控制的了,难道2-8集中鹤子说一句“既然有面麻那就让他写个字看看吧”仁太能拒绝不成?导演借角色之口吐槽说“仁太和面麻还真笨哪”想把这一问题蒙混过关,但是这挣扎完全是无用的!仁太再打酱油,对面的几个想确认面麻存在的高材生难道也是脑残么!另外一个与之相关的问题在于真相大白之后,两位女生看到空中飞盘之类的现象之后居然感~到~了~恐~惧~!没错这非常真实但是和本片的格调完全不搭啊啊啊啊啊啊导演你在这时候怎么又开始追求写实了啊啊啊啊啊啊啊

人物刻画我倒觉得是本片最大的亮点。虽然对于超和平Busters小时候着墨很少,但是至少成为高中生后的他们都树立了十分充实的性格。而且各人的行为也都非常符合他们的设定,这样性格就在不知不觉中凸显出来了。倒是有一点,就是鹤子除了一直都保持一个理性的印象以外,前几集对anaru和仁太表现出极大的厌恶,后来却迅速成为一个积极参与各种拯救面麻行动的人…这中间的转变也太快了点。塑造最丰满的当属anaru了,当然这也得益于属于她的表现时间相当多。

本片的动画制作十分上乘,无论是作画质量还有OPED的水平/搭配程度都是很值得称赞的。cv方面,总体良好,但是有些时候表达歇斯底里情绪的时候声音感觉有点不自然。总体而言,这片大概能评7分吧,应该是一个中等偏上的水平。

Word中中文引号总是变成英文字体的解决办法

有一个相信地球人都知道的word技巧:选中中英混合的文字,并设置为某英文字体,那么将只有其中的英文会变成英文字体。原因?很简单,因为那些英文字体中根本不包含中文字型…

这么做了有几十年了(大误),但是最近1、2年一直发现一个很奇葩的问题:就是全角的引号“”和省略号也会变成英文字体。那效果是非常丑的…因为英文字体中这仨符号设计的占位很短,而且尺寸也很小,大家可以自己试一下在宋体的和Times New Roman中对应的这几个符号便知。

虽然Word的字体选项设置了中文字体和英文字体的选项,但是由于不知道为啥的原因,这仨符号被视为英文字体的范畴了…所以如果你在那里面穷折腾是没有用的。

不过看了这篇文章,我终于知道了如何解决这一问题(看最后几楼,前面几楼的人都在乱扯)。原来问题出在语言设置上。系统大概会把那几个符号识别成英语(美国)语言,于是就悲剧了…于是你只需要全选全文,然后设置成中文(中国)就可以啦。顺便一提,如果你仔细观察,会发现切换语言设置之后除了这三个符号会变化之外,如果有形如”。这样的标点符号组合的话,他们之间的间距会变小哦,因为中文这样的俩符号是应该占一个字符的位置的。Word好贴心呀~

当GFW墙掉国外网站且V6同时挂掉时…

自从将Google系列网站全部通过修改hosts解析到了v6之后,在享受快速、无墙的Google服务的同时,也承担了一个巨大的风险:当ipv6挂掉时简直如同瞎子一般。为了防止这种情况,我已事先将Google.com.hk从hosts中剔除,这样即使v6挂掉,也可以用虽然有墙有关键词过滤的hk撑一段时间,搜日文的话也可以用yahooJP之类的。当然,我的俩翻墙工具——zzzcn的v6代理和GAPproxy都是基于v6的,所以也会一并挂掉,不过介于ipv6挂掉的机会并不多,这点可以忍耐。

不过随着近月来GFW越发疯狂,一旦被墙之后,居然所有的国外网站会同时被墙掉,就搞的人瞬间傻眼。于是今天对hosts和autoproxy的设置进行了一番修改。

首先是将GAPproxy转移回v4:我这里appspot.com被封已久,所以一直都是将其网址直接指定到随便的一个google的v6地址了事(顺便一提,在GAP本地端的fetch.py的地址必须用https才能正常工作,我也不知道为什么);那么现在首先要移动到v4,而且还要找一个google国内的ip,才可以防止被墙之后无法使用。我用IP138随便找了个谷歌中国的ip,203.208.46.148,可以很好地工作,速度感觉比v6还快一些,而且也不用再将fetch.py的地址加https了。

接下来是autoproxy规则的设定。autoproxy这玩意的规则有两点极为奇葩。

其一,如果你设置了一个@(排除)的规则,那么即使在全局模式下它也有效:好比我既然google系都采用了v6地址,那么可以直连,也无需autoproxy自作多情,于是我就将google.com、youtube.com之类的设置了例外(形如@||google.com)。这在大部分时候是没问题的,但是在我v6挂掉的时候,我想在全局模式时通过代理访问这些网站比如google.com,就无法做到…十分麻烦。

其二,@||google.com这样的规则,居然会覆盖到@||google.com.hk… 没错,这点太纱布了……在我看来,||google.com应该是|*://*.google.com和|*://google.com的交集才对,反正是基于顶级域名的一个玩意,不知道他为啥莫名其妙地也会包括google.com.hk这个完全不同的顶级域名…于是介于我已经排除掉了google.com,那么hk也会受到牵连,于是导致全局模式依然无法通过代理走google.com.hk,而hk的默认ip是美帝的,GFW墙国外时是没法用的…所以只好通过hosts,把hk也映射到上面提到的那个谷歌中国的IP了orz。

于是废话了这么多,v6怎么还没好啊喂!

Photoshop预设的消失与解决

装win7之前就遇到过此问题,当时没在意。今天没想到又再次遇到,总不能再重装ps吧,于是去英文网页上搜了下。果然很快就找到了答案,特此记录一下。

Adobe自己对于此问题的描述:http://kb2.adobe.com/cps/402/kb402028.html

Issue

When you load an Action, Mode, Brush,or Adjustment preset in Adobe Photoshop CS3, the Preset folder is empty.

简单的说,就是PS带了许多预设(Presets)设置,但是有些时候这些预设会莫名地消失,比如我两次遇到的都是Curve的预设(包括增加对比度,中间调较亮等几个我较为常用的预设)消失。据我观察,这个问题的造成和非正常退出有关。我每次都是在跑action的过程中由于滤镜出问题被我强制停止,然后就出现这样的结果。

至于解决办法,Adobe官方那篇文章的说法是自己手动添加Adobe\Adobe Photoshop CS5\Presets下的预设配置,但这明显不靠谱:1.你要自己手动一个个加;2.如果你用的中文版PS,加完之后会变成英文版的名字,多囧啊。

正确的方法应该是:选择菜单栏的窗口->工作区->复位基本功能即可(请注意:布局亦会复位,但是不会影响你个人添加的配置/预设如Action、笔刷设定等)。
来自adobe论坛:http://forums.adobe.com/message/3121442