fireattack

令人头疼的歌曲版本问题（二）

似乎每次写个啥必出一个“补遗”已经成为惯例了，这次甚至感觉一个补遗都不够，直接连载算了。

先说点好消息，托日本老歌论坛的福，下到了小猫俱乐部2张专辑，3专《PANIC THE WORLD》（1986年07年10日）和4专《 SIDE LINE》（1987年2月21日）的无损。通过查看各自的cue文件，可以清晰地看到3专是有FLAGS PRE、而4专是没有的。结合之前うしろゆびさされ組那边的情况（1专1986年06月05日发行有Pre-em，3专87年3月11日没有pre-em），看来就是在87年左右淘汰了pre-em这个恶心人的技术。

简单比较，可以看到之前手头那版MP3的《PANIC THE WORLD》是没问题的，和无损版听感一致。所以之前的各种对比也OK。至于《 SIDE LINE》，也和《おニャン子クラブ大全集 下》（2005年）里复刻的DISC1 SIDE LINE无二：

test
《SIDE LINE》tr. 6「ポップコーン畑でつかまえて」，实质上的“渡辺満里奈 with おニャン子クラブ”曲

看来，波利佳音至少在复刻《大全集》的专辑曲目时候，基本就是直接用了旧版CD音源（不过依然有处理过，例如那个奇怪的1400 Hz gap），主要有区别的还是各种单曲曲目（可能单曲是从当年的Analog音源重新转录）。这里先按下小猫这边的不表，回到上次也是今天的正题，うしろゆびさされ組的歌曲们。

依旧是托日本老歌论坛的福，Kuboyama大大突然复活发了好多张碟，其中就包括那套当年他放流过但我没赶上的《うしろゆびさされ組 うたの大百科》全套。

这套《うたの大百科》系列说来也颇有意思。负责企划的是一位原波利佳音的制作人須賀正人，现在独立出来开的独立企划公司。给不了解的人多说几句，波利佳音就是富士电视台旗下的日本大手音像、唱片公司之一，尤其在80s偶像方面颇具影响力，我比较厨的小猫、CoCo、斉藤由貴等等都是波利佳音旗下（因为这些都是富士台的节目或者电视剧捧红出来的）。这么一位业内，外加自身也是偶像厨的須賀，通过自己的企划公司一手打造了几个非常经典的女性偶像复刻精选系列，其中就包括斉藤由貴的CD-BOX（2003年）、多次提到过的《おニャン子クラブ大全集》（2005年）、和这个《うしろゆびさされ組 うたの大百科》（2004年）了。后来波利佳音也推出过诸如《 CoCo うたの大百科》（2008年，我买了vol.1还没舍得拆）等，也是延续了这一精神，不过就不知道須賀桑有没有还继续参与制作了。

另外值得一提的是須賀就职波利佳音时期主导了《乱马1/2》（知道为什么演唱主题曲的是CoCo了吧？都是一家人）、《我的女神》等几部富士电视台的经典动画作品，甚至化名给这些作品的角色歌写歌词。其中最出乎我意料的是一部相对冷门作品《鉄コミュニケイション》（中文：钢铁新世纪）的OPED（化名为Sora），因为这两首《my best friend》和《Dear mama》正是堀江由衣的出道曲！

combined
堀江由衣98年的出道单曲《my best friend》BK，可以看到作词为“Sora”，即須賀正人。另外作曲是川井宪次，《乱马1/2》的音乐也是他负责的

咳，跑题了。有了这套《うしろゆびさされ組 うたの大百科》，那么可以对比的版本又多了一个。而且可喜的是，这套复刻制作的质量似乎还不错，至少先大概听了下，听感没有刺耳感。当然，具体的客观对比，还是得上数学方法。把上文全部重复一遍也没啥意思，于是我决定试图列一个表格来更客观、直观地统计一下各个版本。

我短时间内能想到的方法就是对上文产生的曲线进行平均计算，然后比较数字的大小。这样可以同时定性和定量地比较高低。因为曲线的最开始几个点dB数差别甚大对平均数会有蛮大影响，高于15k Hz又会有MP3版本完全消失的问题，所以我非常随意地只选取了其中172~15073 Hz的频段。这里必须声明下这个方法显然非常不scientific（感觉频率标应该用对数，而且我不清楚直接对dB进行算术运算是否正确），但是我们追求的目标只是比我目测更客观就行了。另外，我最后统一加了80 dB，变成正数便于对比。

另外，我还下到一张99年的《おニャン子クラブ A面コレクション Vol.1》无损，里面也收录了うしろゆびさされ組的1单和2单，一并参与对比。

单曲比较

结果如下（点击看大图）：

result

这里我是尽量按照发售年份排序，不过有两个只收录一曲的杂烩精选集放在了最后。

结合上文的频率Welch图，可以观察到以下几个现象。

撇开Welch曲线的高低不论，光看曲线低频段的形状就可以区分出几个不同的版本，可以认为可能是不同母带或不同的ADC转录批次造成。而同一个版本的曲线中，又常常会有高低（尤其是高频段）的区别。这个区别可以描述成以某个中频为不动点旋转，所以高频较高的版本一般低频反而会比较低一点。

80-90年代的多张碟虽然不完全一致但是很接近，属于同样的曲线1-高：

  1. 《スーパーベスト》收录的四首单曲都和《∞》的版本无大区别
  2. 《PANIC THE WORLD》收录的1单=《スーパーベスト》版
  3. 《ふ・わ・ふ・ら》的3单=《∞》版
  4. 《 A面コレクション》的1单=《∞》版，2单=《スーパーベスト》版
  5. 两个21世纪发售的杂烩碟，也和这个曲线1吻合：
    • 《青春歌年鑑 ’86 BEST30》收录的2单=《∞》版
    • 《みんなアニメが好きだった》（日本コロムビア制作）收录的1单=《うたの大百科》版

《うたの大百科》收录的所有单曲歌曲版本和《「ハイスクール!奇面組」TVアニメ 主題歌・挿入歌集》版本完全一致。但是虽然其形状和曲线1-高一致，高度却要低一些，下称“曲线1-低”。

《おニャン子クラブ大全集》、复刻单曲这2个版本的曲线低频段明显形状不同，下称曲线2。曲线2的主要特征是：低频段低于曲线1，在~1400 Hz处会有个很明显的低谷，但之后比曲线1下降平缓许多，所以高度会很快超过曲线1，并有一个比较尖锐的听感。曲线2有时也会有高低的分别，尤其在《大全集》和复刻单曲之间。

《ザ・プレミアムベスト》会有独特的曲线3（波利佳音号称的重新mastering？），一般低频靠近曲线1、高频靠近曲线2，介于两者之间。论高低/听感的话，也是偏高的。

口说无凭，这里随便用5th来说明几个曲线版本的不同。

image

这张图里几个特征已经很明显：曲线1-高（蓝）和-低（红）形状是一致的，只是有接近等间距的高低之分；曲线2最（紫）明显的特征就是~1400 Hz处的深沟，而且虽然前面低，很快就超越曲线1成为最高的。曲线3（黄）这里基本上和曲线2类似，也有深沟（此例子中，连深沟处的dB都完全一致，但是也有不同的），但是之后并不会像曲线2上升那么快，会低一些。

听感方面，普遍规律是：

尖锐程度：

曲线2 [复刻单曲~=《大全集》]>
曲线3 [《ザ・プレミアムベスト》>
曲线1-高 [80年代专辑版]>
曲线1-低 [《うたの大百科》=《主題歌・挿入歌集》版]

几乎所有单曲A面都符合这个规律。至于B面的情况，其实在上文也看到了，非常复杂。总体趋势的话其实还是和A面类似，但是有大量的例外，例如《∞》收录的三首的表现就非常不统一。

逐个曲目来说，就是（其实上面的总结基本够了，不过还是闲着蛋疼列一下。标红的为反常的）：

1st うしろゆびさされ組

曲线1：

  • 高：《PANIC THE WORLD》，《∞》=《A面コレクション》，《スーパーベスト》
  • 低：《うたの大百科》（=《「ハイスクール!奇面組」TVアニメ 主題歌・挿入歌集》，下同略）=《みんなアニメが好きだった》

曲线2：高：复刻单曲；低：《大全集》

曲线3：《ザ・プレミアムベスト》，低频=曲线1-低，有1.4K Hz gap，3500~4000左右到达曲线1-高，后期介于曲线1-高和曲线2-低之间。

专门加一张图让各位看看曲线3的特立独行（加粗那个）。可以看到，从左边起点出发来讲，从上到下依次是曲线1-高（好多条线重合）、曲线2（天蓝+黄）、特立独行的曲线3和曲线1-低（深红）。image2

1st c/w 女学生の決意

曲线1：高：《うたの大百科》；低：《∞》，反过来了居然！

曲线2：高：复刻单曲；低：《大全集》

曲线3：《ザ・プレミアムベスト》，前期和曲线2基本吻合，5000~16000 Hz比曲线2-高还要稍微高点（导致其最终数值最大），之后跌下去介于曲线2高和低之间。

另外，这歌是少数听感反而是曲线2/3好一些的。

2nd バナナの涙

曲线1：

  • 高：《∞》=《青春歌年鑑 ’86 BEST30》，《A面コレクション》=《スーパーベスト》
  • 低：《うたの大百科》

曲线2：复刻单曲~=《大全集》

曲线3：《ザ・プレミアムベスト》，低频=曲线1-低但有1.4K gap，3500~4000左右到达曲线1-高，10000 Hz到达曲线2后基本一致。

2nd c/w あぶないサ・カ・ナ

曲线1：高：《∞》；低：《うたの大百科》，又正常了。

曲线2：高：复刻单曲；低：《大全集》

曲线3：《ザ・プレミアムベスト》，前期和曲线2基本吻合有gap，之后直到4500还和曲线1-低一致，导致其计算数值偏低。不过后面还是开始起飞，9000 Hz左右到达曲线1-高，最后终结在曲线1-高和曲线2-低中间。

3rd 象さんのすきゃんてぃ

曲线1：

  • 高：《スーパーベスト》，《ふ・わ・ふ・ら》=《∞》
  • 低：《うたの大百科》

曲线2：高：复刻单曲，低：《ザ・プレミアムベスト》（没有特别独特的曲线。后期基本和“曲线1-高”高低一致）

3rd c/w 猫舌ごころも恋のうち

这几版听感很接近。

曲线1：高：《ふ・わ・ふ・ら》；低：《うたの大百科》

曲线2：高：复刻单曲，这次前期一直比“曲线1-高”低不少，直到~7000 Hz才反超，不过后面就一骑绝尘高贼多了。

曲线3：《ザ・プレミアムベスト》，前期和曲线2基本吻合有gap（稍浅），在~7000 Hz曲线2起飞之后开始比曲线2低，反而更接近曲线1-高。

4th 渚の『・・・・・』

曲线1：高：《スーパーベスト》=《∞》；低：《うたの大百科》

曲线2：高：复刻单曲；低：《ザ・プレミアムベスト》（没有特别独特的曲线。后期介于曲线1-高和曲线2-高之间）

4th c/w のっとおんりぃ★ばっとおるそう

曲线1：高：《うたの大百科》；低：复刻单曲，这个最奇怪，复刻单曲居然是和《うたの大百科》一样的曲线形状没有1400 Hz的谜之gap，而且还反而更低。

曲线2/3：《ザ・プレミアムベスト》，很难算是曲线2还是3，倒是有Gap，之后和曲线1-高基本一致，但是稍微更平那么一点点，所以前面低于，后面高于，但是区别极小。

5th 技ありっ!

曲线1：高：《∞》；低：《うたの大百科》

曲线2：复刻单曲

曲线3：《ザ・プレミアムベスト》（大概是这么个形状：低频段=曲线1-低，1.4K Hz gap处和曲线2汇合，然后重新出发就处于比曲线2低、比曲线1-高高的中间位置）

5th c/w わたしは知恵の輪

说个题外话，这曲在大全集里的名字变成了「私は知恵の輪」（汉字私）。而且，这曲是唯一一首《「ハイスクール!奇面組」TVアニメ 主題歌・挿入歌集》没有收录的指指点点组单曲曲目，但是这歌明明是动画的插曲来着。

曲线1：（低）《うたの大百科》

曲线2：复刻单曲，比曲线1高超级多！可能是因为曲线1实际是曲线1-低的缘故吧。

曲线3：《ザ・プレミアムベスト》，其实这次三个曲线形状都差不多。介于1、2中间，但是更接近曲线1。低频：接近曲线1，gap下潜类似曲线2但是之后又回归曲线1直到5000 Hz左右，开始变得更高一点持续至终。

6th かしこ

曲线1：高：《∞》；低：《うたの大百科》

曲线2：复刻单曲

曲线3：《ザ・プレミアムベスト》，依然是：低频段=曲线1-低，1.4K 有gap [不过这次好像比曲线2晚一点] 然后重新出发。不过这次的不同之处是最后比曲线2还高不少。

6th c/w ピタゴラスをぶっとばせ

曲线1：高：《∞》；低：《うたの大百科》

曲线2：复刻单曲

曲线3：《ザ・プレミアムベスト》，还是那个老趋势，前低后高，形状上有Gap，不过这次在7000 Hz左右居然一举超过曲线2，成为最后最高的一条。

我把上面那个表格重新整理了下，用红字标注了各种异常情况，列在下面。

form3

从听感的角度出发的话，个人觉得还是80年代版最舒适。复刻单曲+《ザ・プレミアムベスト》偏刺耳（虽然可能更“正确”？），《大百科》版的虽然和80版听感区别很小，但是硬要说的话还是稍微闷了点。

其他专辑曲目

让我们再来比较一下专辑里其他非单曲曲目。主要参与对比的就是《大百科》、我手头有实物自抓的1专、3专（很可惜没有2专）、《ザ・プレミアムベスト》也零星收录了几首。另外，1专那首「SE・KI・LA・LA」在06年另一张选集《デビューアルバムに針を落として… おニャン子クラブ編》里也有收录，一并参与对比。

结果如下：

form3

令人欣慰的是，这次的结果非常consistent。总体而言的趋势，就是《大百科》版比80’原版（1专或者3专）要高一点，但是听感不至于刺耳，甚至可以说是更“清晰”了。所以个人认为这其实是个不错的版本。而《ザ・プレミアムベスト》收录的则又比《大百科》版更尖了点，则就有点过犹不及了。这里只有俩例外，一个是1-7「上手な恋の飲みかた」，一个是3-11「∞」，都是80年代版反而比较高（Again，区别极小）。这些“例外”可能并不是音源不同，而是在制作《大百科》等复刻版本的时候有根据音轨特性进行过手动微调（而非批量）造成的。

嗯，关于1-1那首的其他版本，《デビューアルバムに針を落として… おニャン子クラブ編》收录的版本和《大百科》版完全一致；《ふ・わ・ふ・ら+シングルコレクション》这张复刻我并没有，是从iTunes下的sample，也基本一致，相信如果有整轨来做频率分析的话，应该也是完全一致的一个版本。

那么这期就到此为止了，下期我们再来统计下小猫俱乐部、以及几个成员单飞的曲目（包括ゆうゆ/高井和Sony系那些，虽然Sony系的基本比较一致没什么必要啦）。另外，我发现如果用耳机去听，那些所谓的“刺耳”版本似乎并没有那么不堪，但是用我的破音响就不能忍（那高音钹的声音简直难受），这倒是出乎我的意料（感觉明明耳机应该细节更好来着）。可能只是我音响的高频段稀烂？

fireattack

令人头疼的歌曲版本问题

之前有提到之所以会去研究pre-em，正是因为某个歌曲不同版本的声音有明显差别。其中一部分，后来是知道可以用pre-em没正确deemph来解释，但是依然有些歌曲有无法解释的区别，最明显的例子就是《大全集》系列里收录一些。所以，心里多少有根刺。

这几天趁着Amazon大降价+30% Off的促销，把之前眼馋已久的《シングルレコード復刻ニャンニャン》给买了回来。

IMG_20180209_173924

这个高达126CD的box就是把从《セーラー服を脱がさないで》起，小猫俱乐部及其会员/子团体那段时期发过的所有黑胶单曲一网打尽复刻。波利佳音这次也算是用了点心，外包装（BK、封面等）也尽量还原了当初的模样，可以说是很有收藏价值。不过不得不说，我会去买这个有一半原因就是希望能给纠结已久的歌曲版本问题，或者说哪个版本才是“原版”画下一个句号（嗯强迫症害死人）——我是这么想的。然而很不幸地，整个事情不但没有变的更清楚，反而更乱了。

バナナの涙

一切的起点其实就是うしろゆびさされ組（下称：指指点点组）第二单曲的这首歌，那么先研究它。这首歌光我手头就有以下这么几个版本：

  1. 复刻单曲版：很显然我没有黑胶，所以这个就是指上图的BOX（2015）中收录的版本了。
  2. 指指点点组二专《∞》（1987）收录版本
  3. 小猫精选集《スーパーベスト》（1986）收录版本
  4. 《おニャン子クラブ大全集》（2005）DISC4 收录版本
  5. 《「ハイスクール!奇面組」TVアニメ 主題歌・挿入歌集》（2008）收录版本
  6. 《青春歌年鑑 ’86 BEST30》（2000）收录版本
  7. 《ザ・プレミアムベスト うしろゆびさされ組》（2012）收录版本，之前一直没舍得拆

指指点点组一专《ふ・わ・ふ・ら》（1986）其实也收录了这歌，但是首先这张专辑有pre-em，其次收录的其实是重新编曲的album version（一听就能听出来，比如第一句人声加了奇怪的回声效果），所以不参与下面的评比。即使如此，也有高达7个版本！这么多版本直接试听，效果肯定不好，那么先用上文提到过的多种频率分析的方法来比较。放在一起对比最好的方法是Welch’s method，效果如下（此图Window=1000，后面换用500了，更平滑）：full

可以看到，明显分割出两种版本——大全集、单曲复刻和Premium best偏上，其他版本偏下（更低沉）。另外，我对大全集版本试着进行了deem（深红线），可以看到如果真的那么做，会反而比版本2还要低一些。

不过，如果集中看中低频段：zoomin

会发现几个事实：

  1. 黄线（Premium best）其实在这个阶段更接近版本2，只有后来高频段才回上去；
  2. 橘红线（《「ハイスクール!奇面組」TVアニメ 主題歌・挿入歌集》）则其实比别人都要低很多
  3. 大全集deem版本在这里和版本2的贴合程度更高了。

那么，哪个版本更“正确”呢？只能说，连持有音源的版权方波利佳音都能搞出这么不一致的结果，实在是太难讲。从听感上来说，我依然觉得版本2（即，较为低沉的版本）效果要好于版本1（较为尖锐的版本），但是也得承认版本2也因此清澈程度有点低（感觉偏“闷”）。如果要综合两者可能介于中间的premium best版本比较好。从背后的制作来分析的话，既然波利佳音敢号称是analog复刻，那好歹应该是从黑胶母带上重新翻录的吧？按照这个理论，应该是大全集=单曲复刻最准确。但是黑胶尤其是45 rpm的（EP基本都是）本身也是有pre-emphasis存在的，谁知道波利佳音转录的时候有没有搞坏。说到底，这一切的根源，我个人觉得还是80年代黑胶/CD交接期，mastering或者转录（尤其是数字音乐）技术不成熟导致的烂摊子，所以倒也不必执迷于当年的原始版本（例如那个superbest的精选集感觉质量就很差。虽然这首问题不大，其他好几首都感觉太闷了）。

C/w曲的「あぶないサ・カ・ナ」方面也是类似情况：

abunai1

稍微有点不同的是中频段：

abunai2

可以看到，在4k-5k区间，所有版本几乎完美分割成两组；不过，这次《∞》居然是靠上的组。另外就是如果强制对大全集版（对应上面那组）进行deem，正好可以得到下面那组。

うしろゆびさされ組

指指点点组同名歌曲1单，也是最有名的一首了。跑个题，这歌的复刻版包装有双封面，关于哪边是正面我还纠结了一下，后来发现其实当年有两种设计：

ver.1

设计1是这种书页式的（图片来源），正面是动画人物，背面是无字的真人，歌词直接印在内侧（封二，参见这里）。注意条形码是在正面，这也是波利佳音当年的惯例。

另外一种设计就是硬纸袋子式（双面是黏在一起，图片来源）的双封面设计，两面都有字：

ver.2

（左：正面，右：背面；上：1单，下：2单）

歌词也因此变成一张单独的纸夹在里面。这次BOX复刻的就是这种版本。有个奇怪之处在于，一单的条形码移动到了背面。但是可以确认正面依然是左上这个有动画人物的，因为波利佳音的Logo、价格等依然印在这面的右下角。二单的条形码倒是正常在正面。另外一个有趣的是这里可以看到1、2单都是主打动画，毕竟当时指指点点组还没打出名气，要靠tie。从3单开始，虽然还都是tie的《高校奇面组》，人物开始变成封面，动画则变成了封底。

这个歌的版本可就更多了，我手头有：

  1. 复刻单曲版
  2. 一专《ふ・わ・ふ・ら》（1986）收录版本：album version+pre-em，不参与
  3. 二专《∞》（1987）收录版本
  4. 《スーパーベスト》（1986）收录版本
  5. 小猫二专《PANIC THE WORLD》（1986）DISC2收录版本，deem后
  6. 《おニャン子クラブ大全集》（2005）DISC4 收录版本
  7. 《「ハイスクール!奇面組」TVアニメ 主題歌・挿入歌集》（2008）收录版本
  8. 《ザ・プレミアムベスト うしろゆびさされ組》（2012）收录版本
  9. 之前下的某个1985 O榜Top100里的版本：来源不明，而且曲线很奇怪，不参与比较
  10. Anison选集《みんなアニメが好きだった》（2009）收录版本

先上个总图：ushiroyubi

（注意：之前有说过，《PANIC THE WORLD》版的提前下坠纯粹是MP3压缩导致的，和话题无关）

由于线实在太多基本看不清，我们得先精简一下。比较发现，

  • 主题歌集=みんなアニメが好きだった，完全一致
  • ∞=スーパーベスト=PANIC THE WORLD，基本完全一致
  • 另外，上述两个版本高频段也相互一致，但是中低频段略有区别

剩下三个21世纪的版本则明显高于80年代版本，且相互并不雷同。

那么，我们移除掉部分重复的版本，并手动对复刻单曲版进行deem再对比：

ushiroyubi2

可以看到，如果手动deem复刻单曲版，高频段会有些过低（深绿线）；但是听感上，确实和其他几个80年代版本一致。也就是说，可以认为，这里分化出的两个版本几乎就是恰好差一个deem。那么，到底是波利佳音80年代的版本deem过度，还是新千年的版本忘了deem？主观听感上来讲的话，80年代的确实偏闷（我曾一度觉得这只是这首歌的风格问题…），但是我还是觉得闷一点比尖得刺耳来得好。

顺便一提，如果把低频段放大：

ushiroyubi3

可以看到在这个频段简直是一团乱麻，各个版本几乎平均分隔开。另外有个值得一提的现象就是在约1464hz处的一个gap，这个现象在波利佳音新千年发的复刻cd里非常常见（前文也提到过），尤其是这次的box几乎每张碟都这样。感觉是使用了什么filter的痕迹，具体得需要有audio engineering经验的人告诉我了。

C/w曲「女学生の決意」：

jogakusei

……杀了我吧。

象さんのすきゃんてぃ

指指点点组的3单，参与对比的CD：

  1. 复刻单曲版
  2. 一专《ふ・わ・ふ・ら》（1986）收录版本（这次不是album version了，所以可以参与评比），deem后
  3. 二专《∞》（1987）收录版本
  4. 《スーパーベスト》（1986）收录版本，deem后
  5. 《「ハイスクール!奇面組」TVアニメ 主題歌・挿入歌集》（2008）收录版本
  6. 《ザ・プレミアムベスト うしろゆびさされ組》（2012）收录版本

共6个版本。zousan

大部分版本都基本一致。

  • 复刻单曲版（浅蓝线）和之前的一样，也是曲线上比别人都要高不少，但是人声和主要乐器听感并无大区别。
  • Premium best版（深蓝线）这次依然不走寻常路，可以看到前期靠下，5k频率左右介于中间，后面和80年代版一致。波利佳音所谓的全新digital master音源居然是真的（笑）。
  • 主题歌集版曲线整体靠下，听感亦发闷，可以认为是有问题的版本。

顺便一提，这个也证明了我对《ふ・わ・ふ・ら》进行的deem没问题，因为deem之后至少和《∞》的版本基本完全一样。

C/w曲「猫舌ごころも恋のうち」：

nekojita

除了主题歌集版惯例偏低其他区别不大。甚至连惯例偏高的复刻单曲这次也没高多少。

渚の『・・・・・』

4单。

  1. 复刻单曲版
  2. 二专《∞》（1987）收录版本
  3. 《スーパーベスト》（1986）收录版本
  4. 《「ハイスクール!奇面組」TVアニメ 主題歌・挿入歌集》（2008）收录版本
  5. 《ザ・プレミアムベスト うしろゆびさされ組》（2012）收录版本

nagisano

明显的双版本分割，八十年代+主题歌集是一个版本，Premium best和单曲复刻是一个版本。区别倒不是很大就是了。

C/w曲「のっとおんりぃ★ばっとおるそう」的情况：

otto

这个倒是意外地重合度极高，不过收录这首的80年代专辑（二专）我手头没有，所以这三个版本都是新千年的。只不过，一般主题歌集版本都是偏低的才对，这里却和Premium best一样了；复刻版的非常少见地居然是最低的。三者听感基本没区别就是。

技ありっ!

5单。

  1. 复刻单曲版
  2. 二专《∞》（1987）收录版本
  3. 《「ハイスクール!奇面組」TVアニメ 主題歌・挿入歌集》（2008）收录版本
  4. 《ザ・プレミアムベスト うしろゆびさされ組》（2012）收录版本

wazaari

符合规律的都不多说了，就是新千年版本偏高，主题歌集偏低（相对80年代版）。不过感觉这个老版有点听不清鼓点？

C/w是「わたしは知恵の輪」，手头没有二专所以依然只能比比俩新千年版，别说区别还挺大：

puzzling

 かしこ

指指点点组最后一张单曲（#6）。

  1. 复刻单曲版
  2. 二专《∞》（1987）收录版本
  3. 《「ハイスクール!奇面組」TVアニメ 主題歌・挿入歌集》（2008）收录版本
  4. 《ザ・プレミアムベスト うしろゆびさされ組》（2012）收录版本

kashiko

听感基本符合曲线。复刻版和《∞》收录版几乎没区别。《ザ・プレミアムベスト》版稍微尖一点，在架子鼓处很明显，人声倒是区别不大。主题歌集版再次比别人低好多，以后这碟可以抛弃了感觉。

C/w曲「ピタゴラスをぶっとばせ」的，也是发散得不行：

pitagoras

SE・KI・LA・LA

既然都拆了，那正好把《ザ・プレミアムベスト うしろゆびさされ組》里收录的几首专辑曲目也拉来对比下。首先是一专里的《SE・KI・LA・LA》，我有的版本就俩，不过波利佳音08年复刻过《ふ・わ・ふ・ら》（即《ふ・わ・ふ・ら + シングルコレクション》），所以从iTunes拉一个sample：

  1. 一专《ふ・わ・ふ・ら》（1986）收录版本，deem后
  2. 一专《ふ・わ・ふ・ら》（1986）收录版本，deem前（对比用）
  3. 《ふ・わ・ふ・ら + シングルコレクション》（2008）收录版本，iTunes sample
  4. 《ザ・プレミアムベスト うしろゆびさされ組》（2012）收录版本

sekilala

嗯……这个差别有点大。可以看到《Premium best》版虽然高频里没有那么过分，但是在中低频几乎和deem前的原版一样了。而且听感？刺耳的很。专辑复刻版稍微好点但是也不行。我毫无悬念选择deem后的80年代原版。虽然我一直相信现代数字科技，对所谓Analog/黑胶高质量论嗤之以鼻，但是看到这种哭笑不得的结果，也好希望自己能有台唱片机听听原版黑胶LP到底是是什么样啊！

另外注意我标的那个点。这1464 Hz的gap也太过分了吧啊喂。你们重新Mastering的时候到底发生了什么，我很在意！

∞

二专里的同名曲目，基本是高井单人曲，ゆうゆ只有部分和声。版本就俩。

  1. 二专《∞》（1987）收录版本
  2. 《ザ・プレミアムベスト うしろゆびさされ組》（2012）收录版本

inf

所以这个为什么又如此接近了……我的头很大。哦其实低频段还是稍有差距。另外这歌的频率曲线好奇怪，那个7752 Hz的山峰到底是什么。

セーラー服を脱がさないで

接下来瞅瞅本家那边，抽查几张单曲。首先是最有名的1单《不要脱我的水手服》。版本有：

  • 复刻单曲版
  • 一专《KICK OFF》（1985/1990）收录版本：这个专辑90年重发过一次，我不确定我手头的EAC是哪个版本，但是根据无pre-em来看，估计是90年代那版
  • 三专《PANIC THE WORLD》（1986） DISC2收录版本，deem后
  • 《スーパーベスト》（1986）收录版本
  • 《おニャン子クラブ大全集》（2005）DISC1（复刻《KICK OFF》）收录版本
  • 《夢カタログ+シングルコレクション》（2008）iTunes下的Sample

sailorfuku

几乎所有版本都完美收敛。

およしになってねTEACHER

这是2单。

  1. 复刻单曲版
  2. 小猫俱乐部二专《夢カタログ》（1986）收录版本，deem后
  3. 三专《PANIC THE WORLD》（1986） DISC2收录版本，deem后
  4. 《スーパーベスト》（1986）收录版本
  5. 《おニャン子クラブ大全集》（2005）DISC2（复刻《夢カタログ》）收录版本
  6. 《おニャン子クラブ SINGLESコンプリート》（2007）iTunes下的Sample
  7. 《夢カタログ+シングルコレクション》（2008）iTunes下的Sample

共7个版本。前文还测试过某个所谓的单曲版，但是来源太可疑（毕竟当年根本没发过CD才对…）这里排除（曲线和《大全集》基本一致）。

teacher

这首歌其实在上文已经分析过了，这里加入了更多的版本来对比，不过基本结论一致。当时的结论是按照尖锐程度从高到低，

  1. 《大全集》~=《SINGLESコンプリート》~=《夢カタログ+シングルコレクション》
  2. 《夢》(de-emph)
  3. 《PANIC》(de-emph) =《スーパーベスト》

《おニャン子クラブ SINGLESコンプリート》和《《夢カタログ+シングルコレクション》这俩同是21世纪的版本也都和《大全集》版基本一致（~10k Hz附近稍微高那么一丢丢）。至于复刻单曲版，则处在1和2中间（其实1和2的区别本来就很小），中低频和《夢》(de-emph)基本一致，高频则和《大全集》版更接近。

听感么，1和2都不错，3太闷。

おっとCHIKAN!

小猫4单。这歌有个逸闻，由于内容太不健康（？前几首有健康过吗XD）后来基本禁播了。

  1. 复刻单曲
  2. 《おニャン子クラブ大全集》（2005）DISC3 收录版本
  3. 《スーパーベスト》（1986）收录版本，deem后
  4. 《スーパーベスト》（1986）收录版本，deem前（对比用）

chikan

《スーパーベスト》版不deem确实太尖，可以淘汰。但是deem之后，又感觉偏闷。由于小猫当年除了这张和另外一张精选《家宝》（而从《スーパーベスト》我们已经可以看到当年的精选集CD的质量有多差了），专辑没收录过这个单曲，所以可以比较的不多，但是听感上确实是新千年的两版本好一些。

お先に失礼

小猫5单。ゆうゆ首次前排，正式跻身小猫的核心成员。接下来的6、7都有担当主唱。

  1. 复刻单曲
  2. 《おニャン子クラブ大全集》（2005）DISC3 收录版本
  3. 《スーパーベスト》（1986）收录版本

各个版本都比较接近，结果直接看图吧。osaki

恋のチャプターA to Z

再来看看河合その子那边的。需要注意，河合その子单飞的唱片公司是Sony，根据我的经验大法那边的复刻版问题会少很多。《恋のチャプターA to Z》是一单的c/w曲，也是我蛮喜欢的一首歌曲（Sonoko真的感觉比较适合这种歌曲，可惜单飞之后没这类的了）。

  1. 复刻单曲
  2. 小猫三专《PANIC THE WORLD》（1986） DISC2收录版本，deem后
  3. 《おニャン子クラブ大全集》（2005）DISC4 收录版本
  4. 《GOLDEN☆BEST 河合その子》（2002，制作：Sony）收录版本

atoz

看图说话，这才是理应有的情况！结论很明显了，前三个版本几乎完全一致。大全集稍微高了点，而且还有谜之1464 Hz gap，辣鸡（嘛其实听感倒还好）。

总结

总之，基本情况就是上述的一锅粥了。硬是要总结一下的话：

  • 早期的两张精选集（《PANIC THE WORLD》DISC2以及《スーパーベスト》），以及08年那张高校奇面组主题歌集的质量都很参差不齐，尽量避免。
  • 指指点点组的多数歌曲由于80年代版本和新世纪的几个复刻版本差别实在太大，我还是选择个人听感比较舒服的80年代专辑收录的版本。《ザ・プレミアムベスト うしろゆびさされ組》收录了几首2专《AN bALANCING TOY》的歌曲还蛮好听的，不过听感就太尖，我迟早得收一张原版的洗牌掉。
  • 小猫本家的倒是可以适当选择新千年版也没差。
  • 索尼系的那几位（その子（CBS索尼）、満里奈（Epic索尼）、美奈代（CBS索尼）等）还是尽量选择索尼自家出的复刻版。

顺便一提，之前看到说iTunes也有自带的deem功能：用iTunes读取CD的话，会自动检测preem，并在播放和转换时自动deem。HydrogenAudio维基号称是subcode级检测，但是我拿那个上次讲过的《スーパーベスト》测试了，并无法正确检测出TOC没有、subcode有的pre-em flag。不过，iTunes的CD数据库确实是吊打freedb等第三方的，比如这个BOX里的复刻CD，基本别的数据库都没有，iTunes就有。可惜我的强迫症还是导致我继续用EAC了。

fireattack

修改content-disposition解决Firefox无法直接打开种子等文件的问题

Firefox有个问题，就是对于某些文件类型，即使你在设置里设置了“始终使用XXX打开”：

001

在部分站点击下载该类型文件时仍然会出来弹窗询问。这个问题已经困扰我很多年，其背后原理其实也早已知晓：凡是response header有content-disposition: attachment的HTTP request，即便是有“始终用XXX打开”的设置，也依然会弹出下载框（仅限“Use xxx application”的情况；如果你设的是保存到本地，倒是可以免询问下载）。

根据Bugzilla的ticket，这么设是为用户的安全考虑，防止稀里糊涂就用本地程序打开了什么恶意文件。虽然我个人觉得完全站不住脚：如果网站真的想这么干，他把content-disposition设成别的不就完了？

这个问题最烦的就是种子文件，因为99%的情况我是要直接用uT打开的。常去的tracker里，只有eh的tracker有这个问题，其他几家，DMHY用的是content-type: application/octet-stream，所以根本没有content-disposition的问题；nyaa.si用的则是content-disposition: inline，也无问题。

在pre-57年代其实就有个扩展叫InlineDisposition（还有无数克隆，57能用的应该是这个），可以自动把一切content-disposition: attachment变成inline，但是缺点在于

  1. 没有filter，什么都会变成inline，包括一些网站的图片下载链接也会变成在浏览器里打开，很不方便；
  2. 会导致很多文件下载时文件名乱码——这个更烦一点。为什么？这里按下不表，后面我们会专门谈起。

所以，我也就一直这么忍了过来，就是每次在eh下种子都要多点那么一下确认。

使用Header Editor替换种子文件的 header

今天，我突然发现Header Editor这款很不错的国产插件居然也有修改response header的功能，于是稍微调试了一下，果然可以搞定eh的tracker了。具体规则么，也很简单，就是

  • Rule type：Modify response header，
  • Match type：Domain，
  • ehtracker.org，
  • Execute type：normal
  • Header name：content-disposition
  • Header value：inline

就OK。不过这有个问题：你没发现一个站搞这一出，你就得重新加一条。

通过参考HE的评论区某人的评论，我发现可以用Custom function的方式来处理：先把上面的Rule的Match type改成All，以及Execute type改成Custom function，然后输入以下代码：


for (let a of val) {
if (a.name.toLowerCase() === 'content-disposition' &&
a.value.match(/\.torrent"?$/iu)) {
let res = "inline";
console.log("res: " + res);
a.value = res;
break;
}
}

view raw

1.js

hosted with ❤ by GitHub

不过这里有个小问题，因为我们简单粗暴地把整个content-disposition header给替换成了inline，而没有保持原有的filename字段。虽然对于我们直接打开其实没有什么影响，但是强迫症作祟，我想能否用正则，仅替换最前面的“attachment”为inline，后面的还保留？

let res = a.value.replace(/^attachment/iu, "inline");

这样的形式思路应该没问题，但是实际操作中，会发现这么一改，我发现有时候会导致整个修改完全失效，又回退到原始的header。这是怎么回事呢？

Header的编码

这就不得不牵扯到一个很重要的Header的编码问题了。

拿这个 Ehtracker这个种子为例：

https://ehtracker.org/get/1111939/8ac51291db878d860b7d064be9745ae838a0b7eb.torrent

先观察原始header（这里顺便一提，用Firefox的网络控制台永远只能看到原始header，看不到插件更改之后的）：

003

奇怪，文件名部分居然是乱码？但是，在对话框或者真正保存下来的时候却正常：

004

稍加研究，原来HTTP Header的编码（曾）是限制在ISO-8859-1，直到RFC2047起才允许使用其他编码。在实践上，仍在大量使用ISO-8859-1，甚至绝大部分字段只用ASCII。

至于ISO-8859-1，也就是所谓Latin-1，你就大概理解成和GBK类似的西方的二字节编码就行。那么我们把刚才那个字段复制出来：

(C92) [比村乳業 (比村奇石)] 月曜日のたわわ そのIV (オリジナル).zip.torrent

然后用Python稍微处理一下：

mystring = '(C92) [比村乳業 (比村奇石)] 月曜日のたわわ そのIV (オリジナル).zip.torrent'
mystring.encode(encoding='iso-8859-1').decode('utf-8')

输出：'(C92) [比村乳業 (比村奇石)] 月曜日のたわわ そのIV (オリジナル).zip.torrent’

符合预想。

JS的话，原生Byte和多编码转换的支持极为贫乏，一般都得用库，但是这个特例可以用一个trick：

decodeURIComponent(escape('比村奇石'))

这个trick之所以能工作，是因为escape函数是基于RFC 1738，所以用的是latin-1 encoding来encode（是编码成百分号的URL encoding形式，例如ƒ=%83（83是16进制下该符号在latin-1的码位）；但是decodeURIComponent却是decode UTF-8 encoding下的URL encoding的字符用的，所以这个操作就相当于latin-1编码成byte再utf-8解码成字符串，也就是还原了我们的真实字符串。

上面是讲我们自个儿如何来翻译这串乱码。那Firefox自己在处理时，工作顺序大概有两种可能：

  1. 从字节码开始
    • ->直接用UTF-8解码->真实文件名字符串
    • ->同时用Latin-1解码->显示为dev tools里那串乱码
  2. 从那串乱码字符串开始
    • ->用Latin-1编码为Byte->用UTF-8解码->得到真实文件名字符串
    • ->直接显示dev tools里那串乱码

虽然浏览器最底层肯定从byte开始处理，而不是字符串，但是这里有必要区分一下两种情况——因为我们替换的时候只能替换字符串而不是byte，所以其实我们的流程更接近2，但是要倒过来：

你的原始非ASCII字符串->用UTF-8编码成byte->用latin-1解码成乱码字符串

当你搞出来这坨乱码字符串之后，替换原始header，Firefox会再按照上面流程2的分支一处理，给你搞出正确的文件名来。

如果你不这么做，直接上汉字比如

a.value = 'attachment; filename=\"汉字.txt\"'

Firefox会发现第一步用latin-1编码就失败（因为超出了latin-1的字符范围了），于是他直接catch错误跳出，完全忽视你对response header的替换，而改用回原始的header了。

至于制作乱码字符串的方法，自然也就是把前面的反过来：

unescape(encodeURIComponent("呵"))

用Python的话就是：

mystring = '呵'
b.encode(encoding='utf-8').decode('iso-8859-1')

输出是å\x91µ，复制到我们刚才的脚本里（没错，包括转义符\x91），稍微简化下：

for (let a of val) {
if (a.name.toLowerCase() === 'content-disposition') {
console.log("orig: " + a.value);
a.value = 'attachment; filename=\"å\x91µ.txt\"';
break;
}
}

然后再点击上面ehtracker那个链接试试，变成“呵.txt”了吧？

我还有个有趣的发现。上面我们看到我们是先把我们的字符串用UTF-8编码成byte，然后byte按Latin-1解码成那串乱码对吧？其实最开始的编码也支持本地locale，对我来说就是GBK：

mystring = '呵'
b.encode(encoding='gbk').decode('iso-8859-1')

这回输出变成了ºÇ，到上面的脚本里替换一下，再点ehtracker的链接，依然可以获得“呵.txt”的文件名。当然，如果你的系统不是简体中文，我就不能保证也工作了。

当然，这俩不能混用，要么就全GBK，要么就全UTF-8。否则轻则部分乱码，重则直接挂掉。

不过细心的读者可能会发现：HE工作时，他读取到的原始header里的字符串应该就是乱码字符串，如果仅仅是替换最前面的attachement为inline（都是ASCII字符），应该根本牵扯不到你这一大堆，永远会work才对啊？

咳，这个我研究了一个多小时，甚至自己写了个扩展调试才发现，有可能是因为我有另外一个扩展Download Filename Encoding 已经自己偷偷把乱码字符串给替换成正常了…所以你再直接塞回header Firefox不认。而且这俩扩展的顺序还不一定，所以时好时坏。之所以说有可能，因为有时候哪怕只要重启一下Firefox就无法重现…不过，凡是bug发生的时候，会看到那个字符串在传入HE的时候就已经是正常字符串（而不是乱码字符串）了。

Edit：经过了又长达X（X远大于我愿意承认的数量…）小时的debugging，我终于发现了根本原因：在Firefox release 57左右有一个很短暂的时期，webRequest.onHeadersReceived.addListener给callback的header是原始字符串，而不是latin-1编码的乱码字符串。这个“Bug”恰好影响且只影响目前的Firefox stable （57.0.4），所以我总是无法稳定重现（因为我平时用的是stable，测试都用beta或者Nightly…）

我用mozregression找到的Bug出现的regression window是9月7日，bug消失的fix window是9月28日。前者倒是能看到有和responseHeader有关的东西，但是后者我翻来覆去看了半天也不知道为啥会影响header的编码。嘛不管了不管了。

这里也得顺便提下，我还试了在Chrome下（WebExt确实方便，直接无缝导入Chrome，就是brower这个对象得还改名chrome），Chrome返回的content-disposition header的就不是乱码，而是真实字符串。

同理，你如果要修改的话，Chrome不需要处理，Firefox就得处理，即


let str = '英文3.torrent';
//Chrome:
header.value = `attachment; filename="${str}"`;
//Firefox:
header.value = `attachment; filename="${unescape(encodeURIComponent(str))}"`;

view raw

2.5.js

hosted with ❤ by GitHub

另外，还学了几个新东西：

一、WebExt写个扩展真的好简单……比起原来的XPI啥的。改response header就简单地加个


browser.webRequest.onHeadersReceived.addListener(function(e) {
//修改请求头
for (header of e.responseHeaders) {
if (header.name.toLowerCase() === 'content-disposition') {
header.value = '改成你想要的';
}
}
return {"responseHeaders": e.responseHeaders};
}, {urls: ["<all_urls>"]}, ['blocking', 'responseHeaders']);

view raw

2.js

hosted with ❤ by GitHub

在background的JS里就OK（权限什么的反而相对比较麻烦些）。完整代码（其实也就是这个+manifest.json）在GitHub上。

另外，测试的时候也别老操人家EH了，我做了个http mock：http://www.mocky.io/v2/5a523c8e2e0000a928c03a73

二、RFC 5987新增加了直接用UTF-8记录文件名的方法（SO讨论），语法为

Content-Disposition: attachment; filename*=UTF-8''{URL编码之后的字符串}

例如“你好.txt”就是（用encodeURIComponent帮你编码）

Content-Disposition: attachment; filename*=UTF-8''%E4%BD%A0%E5%A5%BD.txt

而且不需要双引号括起来文件名了，因为空格都被变成%20了。

用JS的话，就是


//Works in both Chrome and Firefox!
header.value = `attachment; filename*=UTF-8''${encodeURIComponent(str)}`

view raw

3.js

hosted with ❤ by GitHub

fireattack

《偶像大师 百万现场！剧场时光》的Appeal值计算公式和范例

玩《偶像大师 百万现场！剧场时光》也1个月了。这游戏里有一个很重要的元素是偶像队伍组合：根据组合不同，会得到不同的所谓“Appeal值”，然后这个值是和你最后打歌的分数成正比的。

不过奇怪的是，查了一圈Wiki，发现这么重要的值，居然没有人发过计算公式。当然，基本而言就是每个偶像卡面数据加上一些加成，但是这游戏里加成很多样，还有guest和support的设定，所以虽然知道个大概，但是具体也并不是那么清晰明了。另外，游戏里的自动选人功能也挺蠢的，有时候并不会选到最佳组合（A值最高或者单项最高的5张卡组队都不能保证是总A值最高）；我想写一个更好的组队脚本，但是首先也得要有这个公式。

于是昨天花了几个小时在excel里不断尝试，总算把这个公式给摸出来了。

excel
这都是血汗啊

计算公式

游戏里每个偶像卡分别有三个属性，Vocal（Vo），Dance（Da），和Visual（Vi）。三者之和即为Appeal值。这个卡面数据即为下称的基础值。同时，每个卡又分为三个类型，Princess，Fairy和Angel。根据Type不同，最多可能有三种加成方式：Center位技能加成，Guest Center位技能加成，歌曲类型加成。

打歌时的组队由5个自选偶像+1个Guest偶像（由其他玩家提供）+10个系统自选Support成员组成。

那么先来重点，对于每个属性，公式如下：

基础值 = 5个上场队员卡面值+Guest卡面值+10个Support卡面值/2

Bonus = 6个队员(5+guest)卡面值 * (C位技能加成[需匹配Type和属性]+Guest C位技能加成[需匹配Type和属性] + 歌曲加成[需匹配Type]) + Support卡面值*(歌曲加成 [需匹配Type])

几个注意点：

  • Guest和上场队员受到的加成一致，完全可以当做是6人组。在匹配属性的前提下，最多可以受到C位技能加成（例如：Fairy类型90% Dance值）、Guest带的C位技能加成（例如：Fairy类型90% Dance值）和歌曲类型加成（+30%总Appeal值）三者，加法叠加。也就是说，只要属性一致，最多可以获得某个属性（例如Dance）加成210%、其他属性加成30%的效果。
  • Support队员只收到歌曲类型的30%加成（当然，属性也得匹配），不受任何C位技能加成。另外，Support系统是自动根据当前歌曲类型加成之后的Appeal值中选最高的10位。所以是不会亏你的。

UI上的各个数值的解释&计算范例

其实主要内容就上面这些了，不过UI元素上很多地方都有数值显示，有时候很不一致或者误导，下面接一个例子主要讲一下每个UI元素代表什么。

选Guest的页面

选Guest界面默认显示的是Guest 基础值+歌曲Type 加成Only的总和。等待几秒会切换模式显示详情，这里分项显示的括号内为歌曲Type 匹配加成（基础值的0%或者30%），括号前为加成之后的总和。这个我觉得是有一丁点误导，因为我们前面已经说了，Guest实际并不只受到歌曲加成。

001

这里可以看到，我选了个蓝（Fairy）歌，所有30%的加成。简单验算下，Vocal的5512/1.3=4240（基础值），4240*0.3=1272（Bonus）。

主界面

002.png

主界面没什么好说的，就一个数值——合计Appeal值。这个数值等于基础值+所有Bonus之总和，也就是你的最终A值。

这里我的偶像的基础数据如下：

属性 1 2 3 4 5
Vo 1195 938 2740 1187 919
Da 671 1182 1894 931 930
Vi 902 651 3544 656 959
Sum 2768 2771 8178 2774 2808

注意我故意选了4个Princess的，方便计算（因为加成是0）。至于我的Guest的基础数据，是上面贴的那个伊织（注意这里是去掉那30%之后的真·基础值）：

属性 Guest
Vo 4240
Da 5997
Vi 7832
Sum 18069

Support界面

003.png

Support页面也是只有一个数据——总Appeal，这个数值是Support的基础值+bonus（歌曲加成[需匹配Type]）之和的50%。根据公式，Support只计算歌曲类型加成，所以这个数据是准确的。

让我们列一下我这10个Support：

属性 白石 Julia SSR 白濑 律子 昴 Julia SR 美也 Ami 静香 二阶堂 SUM
 编号 1 2 3 4 5 6 7 8 9 10
Vo 5366 7017 3354 3192 3079 4374 3771 5414 2729 3808 42104
Da 3974 3805 6193 5685 4347 5582 6951 6943 3817 2504 49801
Vi 6851 5355 4762 4264 5708 3169 5405 3743 4891 5052 49200
Sum 16191 16177 14309 13141 13134 13125 16127 16100 11437 11364 141105

嗯，因为有两个是Angel的，不受加成，所以分类计算下（已经乘了50%）：

项 属性 Support-Fairy Support-Angel Support-Sum
Base Vo 16459.5 4592.5 21052
Da 17953.5 6947 24900.5
Vi 20026 4574 24600
Sum 54439 16113.5 70552.5
Bonus Vo 4937.85 0 4937.85
Da 5386.05 0 5386.05
Vi 6007.8 0 6007.8
Sum 16331.7 0 16331.7
Sum  Vo 21397.35 4592.5 25989.85
 Da 23339.55 6947 30286.55
 Vi 26033.8 4574 30607.8
Sum 70770.7 16113.5 86884.2

最后的总和是86884.2，和UI显示的86878不超过0.01%，可以接受。至于为什么会比UI数值稍高，估计是游戏内浮点运算有截断为整数的步骤，或是显示的整数属性实际是小一点的浮点数。同样的误差在下面的Bonus计算里也有。

“i”内的合计Appeal详细

004.png

重头戏来了——点击合计A值后面的感叹号，可以得到这个详情。这里，括号前黑字为所有基础值 ，括号里蓝字为 （+所有Bonus）。上面的合计Appeal和外面是一样的，就是把这些全部加起来而已。可以看到，这里和选Guest界面的数值就有不一致之处：那里括号前面的数值是包含括号内的加成的，这里却不包含。

基础值的计算，其实就是把我上面那几个表格加起来，这里除了那种单数Support的数值除以二之后会出现0.5之外，其他可以做到丝毫不差。没什么难度。Bonus的计算，则稍微复杂点。

这里，我的C位技能是Fairy类型+30% Vi，我的Guest的C位技能是Fairy类型+90% Vi。不过成员中是Fairy类型的只有我的C和Guest他俩，各+90% Vi。另外，歌曲类型是Fairy，所以这俩人所有属性再+30%，另外support 10人中的八人也享受（且只享受）这个30%加成。至于其他4个成员和2个support，则是0加成。

所以，总体加成是：3号位和Guest：Vo+30%，Da+30%，Vi+150%。8个Support：所有属性+30%。数据实在太多，我贴个图片表格好了：

005

这里，红字为游戏UI原始数据（包括卡片数值和上面谈的UI上的数值），黑字为计算数据。

看第一个表最后三列，可以看到我的计算和UI的数值基本完全一致。

选人策略

其实选人策略根本不需要这么复杂的公式啦，估计老Producer早就会了，不过还是废话两句。

  1. 所有卡片类型和歌曲一致——30%可不能小看。
  2. 属性方面，先看自己手头有什么C位技能，如果只有一个90%那自然选那个属性的。如果有很多的话，就依次下面的步骤试试，实验的时候别忘了切Guest！
  3. 确定属性之后Guest也选那个属性+90%的（不要选所有Appeal+30%的，一般不如单属性+90%分高）
  4. 卡组一般就直接无脑系统おすすめ自动选特定类型-特定属性的5个最高就行。
  5. 有较小概率出现偏科卡，这时候要把5号位的卡换成未上场该属性卡种最高合计Appeal值的选手看一下（强调，不要相信卡面切换时的卡面差值，那个不显示加成，没有任何意义，亲自选出来一下看看总A值的变化才准）。虽然一般不会有什么提升，即使有一般也就两位数……
  6. 别忘了A值不是一切，还有技能。能全连的自然盾奶、Combo就换掉了，依然用上面的方式选人。我记得有日站说同类技能会覆盖所以不要选一样的，这个我没研究过。
fireattack

iTunes高清专辑封面获取详解

算是对前文（以及下面评论）的一点点扩充。如果只是需要获取高清封面，其实前文的内容就够了；这里是自己瞎研究的成果记录而已。

iTunes search API

之前有提到过“iTunes Artwork Finder”这个很好用的网站，其实只要稍微看一下他的源代码，就知道其原理是调用Apple或者说iTunes的一个公开搜索API（官方介绍博文）：

http://ax.itunes.apple.com/WebObjects/MZStoreServices.woa/wa/wsSearch?term={keyword}&country={country code}&entity={type}

其中country code是两位（比如日本=jp），type就是类型，专辑就是album了。

那么还以上次的那张专辑为例：

http://ax.itunes.apple.com/WebObjects/MZStoreServices.woa/wa/wsSearch?term=花ハ踊レヤいろはにほ&country=jp&entity=album

返回的结果是json（虽然莫名地是txt后缀）：


{
"resultCount":2,
"results":[
{
"wrapperType":"collection",
"collectionType":"Album",
"artistId":890777295,
"collectionId":907305525,
"artistName":"チーム\"ハナヤマタ\"",
"collectionName":"花ハ踊レヤいろはにほ – EP",
"collectionCensoredName":"花ハ踊レヤいろはにほ – EP",
"artistViewUrl":"https://itunes.apple.com/jp/artist/%E3%83%81%E3%83%BC%E3%83%A0-%E3%83%8F%E3%83%8A%E3%83%A4%E3%83%9E%E3%82%BF/890777295?uo=4&quot;,
"collectionViewUrl":"https://itunes.apple.com/jp/album/%E8%8A%B1%E3%83%8F%E8%B8%8A%E3%83%AC%E3%83%A4%E3%81%84%E3%82%8D%E3%81%AF%E3%81%AB%E3%81%BB-ep/907305525?uo=4&quot;,
"artworkUrl60":"http://is5.mzstatic.com/image/thumb/Music5/v4/56/94/1f/56941fcf-ee47-d474-7e3e-f0bea7f8da0c/source/60x60bb.jpg&quot;,
"artworkUrl100":"http://is5.mzstatic.com/image/thumb/Music5/v4/56/94/1f/56941fcf-ee47-d474-7e3e-f0bea7f8da0c/source/100x100bb.jpg&quot;,
"collectionPrice":1000.00,
"collectionExplicitness":"notExplicit",
"trackCount":4,
"copyright":"℗ 2014 AVEX MUSIC CREATIVE INC.",
"country":"JPN",
"currency":"JPY",
"releaseDate":"2014-08-27T07:00:00Z",
"primaryGenreName":"アニメ"
},
{
"wrapperType":"collection",
"collectionType":"Album",
"artistId":890777295,
"collectionId":890777292,
"artistName":"チーム\"ハナヤマタ\"",
"collectionName":"花ハ踊レヤいろはにほ(TVsize) – Single",
"collectionCensoredName":"花ハ踊レヤいろはにほ(TVsize) – Single",
"artistViewUrl":"https://itunes.apple.com/jp/artist/%E3%83%81%E3%83%BC%E3%83%A0-%E3%83%8F%E3%83%8A%E3%83%A4%E3%83%9E%E3%82%BF/890777295?uo=4&quot;,
"collectionViewUrl":"https://itunes.apple.com/jp/album/%E8%8A%B1%E3%83%8F%E8%B8%8A%E3%83%AC%E3%83%A4%E3%81%84%E3%82%8D%E3%81%AF%E3%81%AB%E3%81%BB-tvsize-single/890777292?uo=4&quot;,
"artworkUrl60":"http://is1.mzstatic.com/image/thumb/Music4/v4/dc/a5/67/dca56704-775b-03af-e030-e3d0f8db2dbc/source/60x60bb.jpg&quot;,
"artworkUrl100":"http://is1.mzstatic.com/image/thumb/Music4/v4/dc/a5/67/dca56704-775b-03af-e030-e3d0f8db2dbc/source/100x100bb.jpg&quot;,
"collectionPrice":250.00,
"collectionExplicitness":"notExplicit",
"trackCount":1,
"copyright":"℗ 2014 AVEX ENTERTAINMENT INC.",
"country":"JPN",
"currency":"JPY",
"releaseDate":"2014-07-08T07:00:00Z",
"primaryGenreName":"アニメ"
}
]
}

view raw

return.json

hosted with ❤ by GitHub

可以看到，我们关心的是artworkUrl100或者artworkUrl60这个属性。其地址是：

http://is5.mzstatic.com/image/thumb/Music5/v4/56/94/1f/56941fcf-ee47-d474-7e3e-f0bea7f8da0c/source/100x100bb.jpg

这里前面的是id等，最后这部分的“100x100bb.jpg”，其完整格式是：

{w}x{h}({resize_method}-{q}).{ext}

其中括号内为可选参数。

w和h是尺寸很好理解，那个resize_method是用来控制如何控制尺寸的，比如如果什么也不填，就会把图像不改变比例缩放到能fit进给定宽高的大小内；如果加了w参数，就fit width而无视高度；加了h以此类推。至于bb到底是什么我还没搞明白（官方文档默认就用bb但是也没说代表什么），似乎和不加没区别。至于最后的-q，是JPEG质量因子，默认不填等于80。如果要获取最大质量，只需要附加大于等于100的数字即可，例如-100或者-999。上文的评论里我有说到在iTunes web页面的图像质量稍差，就是因为那里没加专门的质量参数的缘故。

所以，我们可以用上述公式拼出自己想要的图片，例如600x0w-90.jpg（600宽，90%质量JPEG）这类。当然，我们追求最大质量的情况下，可以直接获取png格式最大尺寸，使用99999x99999.png即可。

iTunes web API

那么这个search API这边的就说完了，下面说回iTunes自己的web页面那边。和绝大部分现代网站一样，iTunes也是内容通过API的方式异步读取（MVVM，用的应该是Ember.js框架）。通过控制台很容易便找到上述专辑的API call：https://itunes.apple.com/jp/album/huaha-yongreyairohaniho-ep/id907305525?isWebExpV2=true&dataOnly=true

太长了我就不贴出来了，不过这里有一个有趣之处：这里，该专辑对应的artwork的url是

https://is4-ssl.mzstatic.com/image/thumb/Music3/v4/8e/1d/5f/8e1d5f93-917c-6c49-c331-a62830fdf0c9/AVCA-74538.jpg/{w}x{h}bb.{f}

然而专辑里每个曲目对应的url却是不一样的

https://is2-ssl.mzstatic.com/image/thumb/Music5/v4/56/94/1f/56941fcf-ee47-d474-7e3e-f0bea7f8da0c/source/{w}x{h}bb.{f}

可以看出，这个和上面用API获取到的是一样的（ID是56941fcf开头，地址含有“source”），而整个专辑的却不是（ID是8e1d5f93开头，地址含有AVCA-74538.jpg）。这个现象我在前文也有提到。虽然不是很理解为什么会有这种区别，不过这两张图是完全相同的（A vs B）。

iTunes页面添加脚本

既然我们知道两种方式获取的图像链接虽然不同但是是同一张图像，我们直接通过分析iTunes web页面上的略缩图，可以轻易生成大图的链接。这个User脚本可以给iTunes页面添加一个链接，点击就可以直接打开大图（是添加在图片左下方的X songs那里，而且是JPG，可以自行替换为PNG）。但是我发现这个脚本虽然在美国iTunes好使，在日本站不工作。究其原因，就是日站那边的API call的速度很慢，而且call回来之后他会重写页面的几乎所有元素，所以如果用脚本提前给某个元素添加了链接，会后面被API的xhr给重新改写掉。

虽然可能有更elegant的方法，不过我简单粗暴地用setTimeout()加了个延时，就好使了。另外，我也没用上面那个，而是自己手写了一个：

https://github.com/fireattack/scripts/blob/master/itunes_cover_art_click_to_show_original.user.js

区别在于这个是直接点击封面略缩图获取大图。

11/30更新：用MutationObserver重写了，现在检测到DOM变化之后会再插入一次（应该是一次就够），不用再用弱智的延时了。