五月上旬日本看live记录 Part 2

坏了,一不小心就拖延了这么久,中间都又去过一次日本了,得赶紧把这个写完!

书接上回

5月3号

其实开头应该是5月2日晚上回宾馆后。虽然很困,但是还是强顶着干了这次旅行每晚都要干的事情——刷 TimeTree 和 https://liveidol.blog/live/ ,找一找明天要看什么。因为很多 Live 即使没有卖完,也是会在前一天 23:59 截单的,当天券可能会涨价甚至就没有,所以一般尽量在半夜12点之前刷一下,以防错过。

其实5月3日之前有大概看过,能看得不多,而且FZ的 live 开得早。结果一翻就想起之前已经看到过、但是早已经忘记了的 PEAK SPOT (下称PS) 的合同 live,PEAK SPOT JOIN Vol.8 就是今天,而且是12:30就开始,那还有啥犹豫的就它了。

对于要买什么类型的票,我一般对于地偶 live house 的演出,原则是基本都买S,哪怕很晚才买。因为主要是1) 来都来了,票价的一点差价(几千日元)和来日一次的代价相比实在是太少了,而且和HK比起来日本的票价实在太便宜了。2) 很多场次的前方area确实还是蛮大的,即使是最后入场,也能比普通票靠前蛮多(事实上,S票如果不能前两三排,在最后站位比较宽松的地方反而会比较舒服,视野也更好)。

所以这次虽然票价相当贵(9000日+手数料),还是买了S,这个后面就有点后悔了按下不表。

时间来到5月3日清晨。今天的行程很简单,就是看上面这个PS社内拼盘和FZ的代代木演出,ASOBISYSTEM全家桶。早上9点出头就出门了,想直接去代代木看看,顺便看看物贩几点开门想早点去买FZ的抽选碟。

我对代代木还是有很深感情的,第一次看三偶就是在去年3月来这里看了IDOL RUNWAY COLLECTION 2025

初见了FZ、CS、高猫,还有当时还是只能担当 Opening Act 的SS和Rain Tree,从此食髓知味。当时因为要赶场TrySail十周年,所以看完FZ就狂奔离开了,没看成大轴的日向坂(刚看了下HP,居然还有糯米,但是我完全没印象了。难道糯米也在FZ后面吗?还是我单纯不熟根本没记住)。

故地重游,在10点前就到了,根本没几个人:

稍微晃了一圈,物贩摊位包括抽CD(上图左下)都要到中午12点才开,那我肯定等不了那么久了。

就是这个万恶的抽选会。大家肯定都是想要见送会和囲みチェキ

于是稍微晃了下,就直接去下一站惠比寿。

为了方便看 live house,我这次专门带了个小的斜挎包,所以先在惠比寿站把双肩包(要带望远镜和FZ的大灯,这个省不了)存了下(没存原宿是因为找不到 locker)。

惠比寿其实还是有3、4家相当有名的 live house的,不过我之前只去过FZ出道的那个恵比寿CreAto,这次可以解锁下LIQUIDROOM了。两者离得蛮近,我提前一个多小时就到了,这时门口还基本没人(导致我还以为来错了)。

有趣的是,这个隔壁就是那个著名的四边形过街天桥:

N年前kraz访谈里拍过的,我当时人肉过:

大概提前1小时开放入场,这个 live house 大堂(相对)很大,还有沙发,带着很舒服。很快进场:

这个场馆不大。在横向不宽的前提下,后买的的S票就很垃圾了,和A的区隔很小,甚至没有A区前方可以站在一个台阶上视野好(不过想了下,我如果昨晚临时买A票,那显然也不可能站到A区前方。所以可能我应该自己主动拿S票去站A区的)。不过总体而言,不太影响看,就是撮可难受点。

那么说说 live,或者说 PEAK SPOT 吧。先给不了解的科普一下,PEAK SPOT是KAWAII LAB. (下称:KL) 母公司 ASOBISYSTEM 在一年多前发足的一个新的 brand,运营是一个叫做 ASOBINEXT 的分支在搞。这个 ASOBINEXT 其实早就有啦,应该是比 KL 还要早的。旗下有很多研修生,有点类似于青训队,在大阪等地也有一些人员变动很频繁的组合在运作,不过名气非常低。

这个 PEAK SPOT 算是 ASOBINEXT 正式开搞的“旗舰级”地下偶像了,第一个队伍就是 fav me。当初我正处于和KL的蜜月期,对于这个虽然不直接属于KL但是关系异常密切的分家还是满关注的,尤其是 fav me 的成员成分不一般,有两个 KAWAII LAB. MATES 毕业生(包括阿部かれん,其前世包括ハコイリムスメ,我因为某些机缘巧合N年前一直关注的一个日本地偶团),因为真っ白なキャンバス而声名远扬的小野寺梓,还有也算有点名气的澪川舞香、中本こまり等,可以说是关注度蛮高的。

fav me的前几首歌我都有认真听过,现地的话也参加过 TIF 和前文提到过的一个单独 event。刚建团是推こまりん但是现在推まかしゃん(对不起)。fav me的发展虽然远不能和KL的亲儿子团比,尤其是小野寺梓的粉丝似乎没带过来多少的感觉,但是我感觉稳扎稳打,在地偶中也算中坚了,ASOBISYSTEM 资源倾斜就算不高,也是足以吊打一众无名小公司的。

相比之下,PS的第二团Toi Toi Toi就要惨很多了。这个团其实比fav me要早,是 Abema 一个朝倉未来当P的选秀节目Dark Idol搞出来的产物。这个团在节目结束后一直处于一个很尴尬的境界,后面朝倉未来也退出,一番操作后在25年4月前六本木著名夜店バーレスク東京出身的もも(新名义:さくらもも,5/6麻仓桃w)加入作为粉担(同时有一名成员石川侑依退出),以TTT的名义在PS出道。

这个团出道后在我印象中一直不温不火,至少和fav me比要差了不少。我其实之前也有去看过一次无料 one-man,感觉还蛮好看,水色担当杏香现场当时也超喜欢;不过后面也没有再关注。

直到去年年底,TTT突然宣布要加两位新人,萩田こころ和山田せいあ,两位都是有一定资历的前世的,其中前者こころ酱我之前在抖音就一直fo,之前知道她从上一个团iSPY [*]毕业还唏嘘了一阵,没想到居然加入了ASOBISYSTEM,双厨狂喜了。为了迎接两位大牛(?),团内颜色甚至还进行了重新分配,kokoro拿到了正统红色,另外一位也拿到了蓝色这个重要颜色,可以说是很重视了。加了kokoro之后,TTT对我来说看点又多了一分,不过话虽这么说,也并没有真的再关注过太多(摊手)。

[*] 这个团在她毕业之后没几个月后解散了,一人引退,两名成员加入了新团i’Rank,另外两名以Support成员暂时在新团代打至1st live(今年四月)。现在老X号直接改成了新团继续用:https://x.com/irink_official

第三团 log you,去年10月成立。

这个团的成立其实超突然的,因为实在没想到PS居然这么短的时间内,还有精力开第三团。成员也有一个MATES出身 (月代来実),而且是ASOBISYTEM元组地偶团IDOLATER的唯一残留人员(ayu@SS已经再出道不算),超元老。其他的成员也全是业界老狗,而且履历多样性极高,有快30的,有干了7年AKB然后隐退3年多后复活的,有韩团出身的……

不知道为什么,我相比纯素人反而对有前科的人比较感兴趣,所以这个团一开始就蛮关注,而且这几位真的都很可爱呀!也很努力地在各种SNS PR,快30的山下うみ酱那个方言的黄段子(最开始发的是未消音版,可惜删了……)真的笑死我了。红色、紫色也很可爱。

不过我最喜欢的还是一见钟情的绿担井出叶。Bob头,矮矮的,看着傻傻的,笑起来超治愈!而且又是STU48出身!这下我推的有三个前STU48了(爱弓@JOY、みも@ドレスコード),怎么回事啊..

咳,跑题有点远,说下Live本身吧。实话说我后面因为看的团太多已经没太多精力去关注PS,fav me后面出的歌都没怎么听过,另外两个团就听得更少。不过Live还是蛮开心的。顺序是 log you -> TTT -> fav me,很常规按照资历倒序。衣装交换是最大看点,log you穿的TTT,TTT穿的fav me,fav me穿的log you。

上来 log you,反正我知道肯定会唱我最爱的あんぐりーガール(因为歌太少w),所以歌单没什么好担心的。可惜这次我在后面,也不是只有我打绿色棒子,不能像上次一样爽吃kanau几乎所有レス啦!

第二组TTT,歌曲我基本只听过两三首,喜欢的是同名曲,甚至不记得当时唱没唱。人员本来就不熟悉,现在还衣装交换成 fav me 的担当色服装(但是颜色打混),这不是坑我嘛,我都分不太清谁是谁啦。Kokoro第一次亲眼看,唱歌还蛮有水平的,不过不知道算不算的上歌担。杏香依然很可爱。

然后就是我理论上最熟的fav me了。但是没想到,这次的歌单新歌还蛮多的,我miss了一大半,丢人了。但是我靠穿 log you的衣服太好看了吧!尤其是こまりん穿叶酱的衣服,贝雷帽那个,太无敌了,尤其搭她现在的短发发型。相比之下,まかしゃん的水色感觉就不如红色好看了,但是侧马尾还是很棒的!

看完就是紧张刺激的特典会。按照工作人员指示分别在三个地方排队,我看时间还剩得很多,就没有那么在乎优化,直接去先排了log you。log you显然是最凉的,上来买券排队感觉不到100人。买完居然就在旁边直接排队,挤成一坨,不知道整列的staff怎么想的……

没记错log you一次能用2张,我一般都只排一轮,所以直接买了叶酱2张,拿到2-3号。1号被前面的一个买多人的哥们买走,他去排别人了,所以我又又又排到了第一个。唉虽然之前就发现了,但是宝宝你太凉了。。

说的什么现在已经忘了,总之很快就拍完了。虽然比KL肯定长的多得多,但是PS的谈话时间还是比一般地偶短。而且只卖无签券一种,不能靠小偶像写超慢拖时间(喂)。这点上还是没办法,大公司嘛,不够地下。

对了我拍完的时候物贩桌的队伍居然已经消化的差不多了,可以随时买。

log you是单独在lobby开的,另外两组都在另外一个屋(舞台那个?记不清了),我就过去看看。结果发现 TTT 的特典桌居然有超长的队——有这么火?!fav me那边反而没有很长。现在想想,可能只是她们这边开得晚了?总之稍微小排了一会,买了kokoro x2 和fav me的まかしゃん和こまりん——毕竟这边更贵3000一张,而且我记得也是只能用1张。

没记错的话,是先排了kokoro,她的队伍很短,我去的时候只有2人。TTT这边队伍最长的自然是momo,都拍到外面去了;我记得还有一人也不短,不过已经忘了是谁。没想到这边,kokoro也只能一次用一张(不知道是全团都这样,还是她算火所以限1),我就loop了次,反正也没几个人。

聊天的话,提到了之前就很喜欢看她的Tiktok,能加入ASOBISYSTEM真的很激动,她蛮开心的。还提到了成员色,我突然忘了她前团是什么颜色了(毕竟我没现地看过),她自己说了白色。另外夸了下她唱歌厉害。大概就这些了。

对了kokoro履历上是写澳大利亚黄金海岸出身的,但是不知道具体在那边生活了多久英语什么水平(好像没在TT啥的拿这个当卖点出过视频),所以我也没主动说英语。虽然估计应该是可以秒杀大部分小偶像啦。

fav me那边komarin队伍中等(十几人?)。就夸了下(叶酱的)衣服就很快结束了。

まかしゃん那边队就长多了,但是因为剥的快所以也很快就到。没记错的话好像基本是她在说话w

本来就完事了,不过因为我在 ins 发了下,有个朋友让我帮她拍一张 log you 的紫担松本玲奈的切。玲奈现在已经毫无疑问是 log you 最火的,也很好理解,外型top,唱歌厉害,特典会对应也很棒。我第一次切 log you 的时候也顺便切了一下她,印象也是蛮深刻的。不过她说话嗓门很大,有点傻大姐,这点倒是满出乎我意料。我本来是要买2张,帮朋友一张自己一张(因为我知道她一直和别人不一样是限1,不想 loop 那么多次),结果我忘了 log you 一张只要2000了掏了6000出来,那就顺水推舟买了3张。

其实这个时间,log you 这边基本都没什么人了,即使是玲奈也只有10人左右在排队,所以 loop 三遍也不是很慢。我先拍了一张横 solo,她摆了那个我推的猫儿造型,因为太可爱了我自己私吞了(本来是准备给朋友),又拍了一张合影。说了什么我基本都忘了,反而更记得cheki staff非常友善,一点也不 push 而且很友好地问你各种需求比如横竖之类的,非常舒适。

最后一张我提了是帮朋友xxx代切的(其实我不知道代切到底怎么说……),她很激动地说了一堆让我帮忙转达谢意之类的。我自然也传达给了朋友,她还故作惊讶地说没想到玲奈还记得的我!拜托你们每次都拍几十张谁会不记得啦!

该说不说,其实我还是比较喜欢玲奈黑发时期的清纯造型!

虽说人不多,但是 loop了三轮时间也所剩无几,我于是头也不回地离开了 Liquidroom,往代代木体育馆移动了。

今日战果。对了,我记得PS的团都是应该要戴口罩的,但是我和一开始和 log you 以及 TTT 拍摄没戴,好像也没人说我……虽然到了 fav me 我还是很自觉地戴上了。

刚出原宿站,就发现代代木第一体育馆门口那天桥居然都堵死了,人确实多!

本来没准备赌碟的,没想到时间还很余裕,去买了一直没买到的手灯配件(里面的“KAREN”字样替换件)之后,还是忍不住来买了10张(当然有先确认S、A等大赏还都有剩)。

刮刮乐前9全是sorry,最后一张终于中了个C——无签的随机旧cheki,抽中了副推 amaneki,还算不错。

在CD booth门口一堆人举着自己抽到的cheki交换,但是没看到可怜——而且可怜本来就是最抢手的,估计也换不到。

升舱的座位,是Arena B2,离主舞台不算近,但是离中央舞台还是可以的,还算能接受吧。只可惜在block深处,花车就没什么指望了。另外因为鱼虾哥没来,所以我旁边多一个位置可以放东西,助かる。

不过还没开场,就发现最绝望的事情:好不容易有了完全体的棒子,结果居然没电了!FZ这个白痴棒子的开关是不用长按就能开的,一定是放在书包里碰到了。我恰恰这次没带备用电池,没办法,只能挥舞黑棒子了。

顺便一提,我之前电池放在里面没拿出来结果垃圾电池漏液了,导致里面都锈了,我扣了好久绿色的东西才能用TAT

撮可歌曲,她们是从主舞台移动到中央舞台,我最近的时候就这样:

另外,从一开场就很在意的就是 amaneki 的大腿上贴满了胶带和Kinesiology Tape,看着心疼死了。

(果不其然之后没过几天,官方就发公告她腿部疼痛,之后部分演出要坐着表演(再之后某场 Yui 也出过状况需要坐着演出)。唉还是太压榨了。这些人毕竟都是从业10年的奔三偶像了。)

演唱会本身嘛,我已经忘得七七八八了!毕竟已经过去一个多月了…但是好看还是好看的。虽然比起之前SSA和东蛋,只是一场常规的巡演,没什么特别炫酷的演出,但是很扎实,曲单也不错,这个程度的live我个人是完全可以接受的。

虽然现在对FZ的感情淡了,但是这样的Live每隔几个月看一次,我还是会很开心的。在代代木结束后不久FZ又电击宣布了秋巡(美咲:巡演结束后会怎样?巡演会开始。),这次是真的下到各种地方县了,几乎全是几千人的hall公演,不过东京还是要大一些,是开我去过一次的(去年的larme fes,也算是看FZ)東京ガーデンシアター,开2天,日期正好和kyuruchan的K-A在一个周末(11.14-15),我就抽了不冲突的周日,成文之时已经顺利当选~(抽地方场的同好,落得则很惨痛)。我们11月再见!

Live结束后,和几个香港的朋友碰了个面拍了个合影。细包大佬送我了很多FZ一番赏的可怜谷子,甚至包括B赏,超级感谢!!!他是找香港代理直接买了一箱,这个我本来是准备来日本随便抽点玩玩,结果出了之后都来了日本两次了,却根本找不到任何店还有在卖的!本来就根本不准备再要了的。Again,感谢!

live结束后依然有很多人在抽碟。难道现在还能抽见送会??

打上我就没和香港的朋友一起了,主要粤语太差聊起来不得劲,当然更重要的是今天还有最后的重头戏,给刚从美国来日的小棋接风!

在原宿站门口居然又碰到这个地底团发传单。这个团我上次和昨儿在有明看JOY就碰到了,当时我还吐槽为什么七色熊猫只有5个人。她们是故意在天偶开 live 的地方发?很会想点子哦。

小棋住的地方和我不远但是都是要地下铁到达,而且是不同的线路。经过各种研究决定还是在秋叶原吃饭得了,毕竟时间也不早了。具体发生了什么已经忘了只记得在秋叶原外面晃荡了半天最后吃了Coco’s。

Coco’s确实贵,味道是要比萨莉亚好一点。聊的东西已经忘啦!只记得小棋的dirnk bar不带soup bar,结果他还是去盛了,然后把碗放在我这边(x

忘了拍照片,拿这个凑合下……绝对不是在讨债什么的

明天是最紧张刺激的 H社 Fes 前排管理局,和小棋说好了立川的见面时间地点就分头回家,好好休息迎接最地狱的一天。

虽然本来想一次写2天,但是这个已经太长,那么下期再见!

五月上旬日本看live记录 Part 1

我想起个更帅的标题的,但是想不出XD

从来没有写游记的习惯,但是这次因为在十天的时间内看了无数场live,认识了很多新的好女孩(大雾),不记录下真的记不住,所以写个流水账记录下。

出发前

这次会去这么久,主要是因为百13的日期定在了很尴尬的5.5-5.6(星期二、三),我这边又没有劳动节假期,请三天到周三还不如直接请五天连上两个周末,甚至可以多连上上周五 (5.1) 的一天假期。

定了行程区间后,很快就安排上了一些旗舰活动:水果拉链(下称FZ)在整个黄金周都在国立代代木第一体育馆办巡演,日期是2,3,5,6。后两者和百万冲突,所以我自然只申请了2、3。虽然现在已经没有当年那么关注FZ了,但是大型live还是要看的,毕竟FZ是我歌曲最熟悉的团体,live是没有盲区的怎么看都爽。

结果申请完没多久就遭受重大打击:我另外一个超级喜欢的团体きゅるりんってしてみて(下称kyuruchan)居然也要在5.2/5.3搞巡演final,而且是(本团)史上最大的幕张Event Hall!这肯定是要去的,但是fz的我已经信用卡申请过了,只好这边也硬着头皮申请了两天便利店付款,打算选一天能中高级票的。

结果嘛就是两天都中了普通票(+谷子,也一万多了),介于FZ之前申请的时候第二天(3号)是和鱼虾哥连番的,我自然选择了第一天去看kyruchan,第二天和鱼虾哥继续连番(当然他最后鸽了)。第一天的FZ的票其实也中了,因为就没有完售自然也没有resale,最后就只能浪费掉了。

旗舰活动安排完毕,接下来就是安排别的活动了。虽然5.1-5.10有长达10天,但是几乎所有的大型活动都集中在黄金周这五天也就是2-6。比如有几个我特别想看的:nonfic五周年、高猫巡演Final,分别在5、6号都和百万撞了只能遗憾放弃。另外黄金周最大地偶拼盘也在2-3号,也没去成。

而且由于大型活动都在这时候消化完了,后面的日子就没什么高级活动了,尤其是7号和8号这两天上班日,更是少得可怜。中间空着的4号,倒是蛮早就宣布了Heroines(下称H社)会开Fes,而且还是7周年名义,这个自然是要抢的,而且还可以带小棋一起看。我通过超快手速(大雾)抢到两张S-1X票,也是第一次可以前管一下H社大型Fes了。

再往后的日期也就是周末的9-10号,中型拼盘倒是不少,不过每边儿能看的稀稀拉拉几个,搞得我反而选择困难了,而且时间多少有些冲突。最后,我只确定了去看10号的最终未来少女的定期one-man(好久没见刘甜了!),和在出发前几天大致确定9号上午去看OnePhony的リリイベ(有个全团合影的特典很吸引我),具体细节就先按下不表。

5月1号

经典UO624早上四点多来到HND。又是在机场墨迹2小时睡也睡不着,而且这天下超大雨,非常之冷,我带了全短袖+一个薄外套,鞋子也是完全不防水的,上来就有点虚。对了关于这天要看的活动,其实很早就知道这天有H社的体育祭,理论上肯定是看这个,毕竟全团出演,包括我的大量推。但是看过SC的体育祭(直播)之后对于这种本格(即:没有唱歌)体育祭实在是兴趣缺缺,我一直到了日本,也在纠结要不要去(而且我知道这玩意票卖的非常差,所以不担心买不到)。

但是不知道是这天日子本来就不好(黄金周前最后平日),还是大家主动给业内一霸H社让路,我居然找不到这天任何一个稍微有一丁点兴趣的偶像活动。

唯一能作为候选的是二偶的ピュアリーモンスター 結成9周年記念ライブ(晚上@惠比寿),可以去看看我只在网上看过的新老婆菅原もも到底是不是真的好人。而且好歹也是周年live嘛,也算隆重。

不过经过长期纠结,以及上次去看 IBERIs& 感觉一般的体验,感觉作为乐曲派,完全没听过歌的团直接上one-man还是有点不太行,还是决定去看H社体育祭了,至少人熟悉。

那么买什么票呢?

前方席最有意义的自然是特典会,但是我对非伴随live开办的特典会没什么特别大的兴趣(比如各种大特典会),外加票价实在离谱,还是决定坚定之前的想法,只买最便宜的票(倒是需要配信留档,所以会买+ppv的)。

这么说本来应该买B的,结果最后“来都来了”,还是加了五千买了A票。事后证明这个选择很错误!

前面提到不参加特典会,还有除了票价贵还有个理由就是太耽误时间了。实话说每次看完live都要再花一个多小时参加特典会次数多了就很烦,之前看港偶那特典会更慢,动不动就搞到11点之后,受不了。这种前特,估计至少要提前来个2-3小时都不止,就更难受了。决定了不参加了就舒服了,这一天剩下的时间都是空的,于是就八点多慢慢地去神田秋叶原的东横INN(坚决不坐KK了上次挤死我,必须monorail)放行李顺便坐一会,然后九点多往秋叶原移动。

之前每次去秋都要硬等到10点甚至11点才有东西逛,这次9点多于是直接去donki逛一下,一会到10点去大相机帮朋友看看陀螺(早被搬空了,屁都没有)。结果在donki里居然看到一个外国妹妹带了个(FZ)可怜痛包!

10点经过A店才发现A店原来平日10点就开门了,很好,不过看了一下发现麻仓桃的碟不出意外又售罄了。G店倒是依然11点,在atre磨蹭了一会进去买mct碟,还有,买到,拍了下她的展示衣服。

接下来今天唯一的任务就完成了,我就去吃了个饭(好像是吃的之前72哥带我去过的武膳,不确定是不是这天……),然后就去找了个咖啡馆休息一下。这时候困劲儿上来了直接睡着,然后过了不知道多久被店员搞醒。我看了下时间还没到我能坐的2小时限制,可能是因为我睡着在打呼噜吧!尴尬。之后就去 Trio DX逛逛,结果又碰到那个痛包妹子,这次还有很多老外同行。惯例掏出我的 list (例图见下,类似的有N张)开始翻可怜的生写,这次意外地有不少新货,一不小心就买了几十张花了六千多。但是补全了很多,很开心!

接下来随便逛了下mandarake啥的,就离开秋叶原了。这会儿已经不下了,所以温度还好。上午大雨可把我冷死了!鞋也全湿。时间充裕,回了趟酒店洗了个澡换了衣服尤其是袜子,舒服多了。之后就往东京体育馆移动了。五点出头到达。

场贩自然早已经没人排队,虽然也没什么想买的,就买了根毛巾纪念。好歹是体育祭!

H社的女粉还是蛮多的。感觉现在地偶稍微比较火的,女粉都很多,只有那些地底的还是大叔观众为主。

刚开门我就进场了,进去就笑了,人比我想象的还要少:

下面的红色座位就是SS和S了,这个后面倒是坐满了,但是上面的Stand嘛,就只开放了红色座位上面对应的那些block且只有一层,而且即使这样也是坐的稀稀拉拉。最搞笑的是,A和B的区别就是,A是前三排,中间大概是空出了第四排,然后B是五排往后。实际距离根本没什么卵区别!

我是第三排,但是两边都是妹子,我觉得这么少人也没什么和别人挤的必要,于是运用老中灵活思维,全场都坐在空着的第四排,一人独占很舒服。

C-3-15就是我的座位

对了,S、SS票的分区是按照你推的Team自己选的,我们低人权座位就是随机分配,我是分到了Team God(话说,解说每次都会念“Team God チーム”,笑死我)这个象限,我看大家也都很自觉地支持这个组。我推比较多所以哪个都不是很有所谓,God有 iON 的 Kurara、iLIFE 的 Noa、Miki,还行啦。

体育祭本身嘛,感觉还行吧,没有期望就不会太失望。

真的要让我锐评的话,就是有几个运动设计的有点有待优化。

比如那个之前直播版的大运动会就办过的buble相扑(就是穿着充气服互撞),很多很菜的选手一碰就倒,直接重心降低瘫在地上,别人根本推不动,就这样浪费了巨多时间。明显应该设定倒地超过多少秒直接判负的读秒机制。

推球接力第一组出现了居然不在同一边结束的bug,应该是某组少走了半个回合,但是也不知道是谁。

障碍+借物跑是笑点比较多的,有一个环节是用脸在一盆面粉里找一颗糖(就是用脸滚,然后嘴把糖叼出来),一般大概十几到几十秒可以搞定(如下所示)。

结果Ririたん硬是在里面滚了几分钟也没找到,另外三个队其他所有环节都搞完了。。惨就一个字。最后脸部全白,很好笑(到最后也没找到!是裁判给放行了。事后Staff自己还在里面找了半天XD)

对了这个环节可以摄影,不过我好像按错按钮,好几组都没拍全。比如那个借物,是找一个staff藏在观众席上,前几轮都是在下面的s票区域,有一组给我们低人权福利,上了山,我没记错的话应该是miki上来的,离我们很近,但是我好像没拍到,残念!

最好看的居然是最朴实无华的最后的本格全员接力。气氛很热。我推的好多人(kurara、mimo@dress code)都超级快,厉害!Team God也一度领先许多,甚至套圈了最慢的队。可惜后面有个交接失误,外加有几个很菜的大姐(x),最后好像第二或者第三。最后统计分数,没记错的话Team God总分倒数第一,嘛嘛。

对了,这个场子空调开得很足,外加本来观众人就少,以及这天天气本来就差,快把我冻死了,中间实在顶不住穿了外套(本来穿着nene酱的推しT),即使这样都有点缓不过来。还有这个场馆的大屏幕滞后也太多了,感觉比声音慢了有0.5秒XD

正片结束就是可摄影见送会环节了。组织还是比较有序的,观众们是先被拉到场外列队(S好像就直接场内),见送的地方则是在会场的一个附属大平地小馆内进行,偶像一百多号人,用栅栏分开四组分开,工作人员依次带队观众进场。S票自然就是看自己对应的,我们AB票反而可以选一组看。我当时一时想不到应该看哪个,就还是继续排了Team God(虽然也都差不多,推都分散在各个队了)。话说有あいす那队超级长。正片的时候我又犯了之前排 Rain Tree 见送会的错误,走太快了,几十号人居然只拍了33秒。虽然队伍确实一直这个速度啦,人太多了工作人员剥的速度还是很快的。

Team God最推,kurara酱!

这一天就这么结束了。晚饭吃的啥忘了,好像拉面吧在浅草桥那块。然后早速休息了困死我!

5月2号

如上所述,今天要看的就是kyurun的one-man。

我抽物贩券抽到了200这么靠前的位置,我自然只能上午就过去。因为昨天有点累,外加在超极不方便的幕张,我考虑再三决定不再安排别的活动了。

这天其实大型拼盘很多,最重要的自然就是上面提到过的: IDOL SUMMER JUNGLE GOLDEN 不过我算了下,从幕张过去要一个小时出头(其实幕张去很多地方都是这么久,比如涩谷、品川等,还挺巧合的),赶过去看2个小时也看不到傍晚的大团,就放弃了。

11点开始物贩,我大概10点半到了幕张。在 event hall的门口呆了一会才发现,物贩地点居然是在后面蛮远的一个地方(而不是之前 lisani live那样就在正下方的大空地处),故移动之。

虽然之前就已经发现了,但是kyururin的女粉实在是太多了,比例上应该有80-90%左右。即使是男粉,也大多是精致男粉。另外对应到人的话,amu酱粉丝总数最多自不用说。yane男粉比例是最高的,yuna酱女粉多(这个确实没想到),我推Uta整体粉丝比较少(泣

Kyuruchan这次也出了FZ那样的大灯,不过没有遥控,我也已经有个官棒了,就没有买,主要我棒子实在太多了。。我买了 uta的推T、推扇、推巾(这个必备,kyuruchan有首我超爱的毛巾曲)、立牌啥的,几张歌名贴纸(很喜欢),别的好像也没买什么。哦对了,每人是可以购买一张指明人物的random cheki的,2000日元,这个绝对是福利了,因为现在kyuruchan的特典会绝对是地狱难度,每次都要提前抢票才能参加。上次kyuruchan来香港的时候本来是个绝佳机会,我每个人都排了特典会,可是!我推Uta酱并没有来。。这次也算某种意义上弥补了吧。

不过很有趣的事场贩现场所有的说明都没有提及这个东西的存在,如果没有提前在官推看到,可能就错过了呢。

怎么有点像……女主持

物贩开放窗口蛮多的,但是排队还是很久,我才200番,买完就11:30左右。莫名其妙就花了一万多(笑)。哦对了,还有kuji和扭蛋,kuji 800一次,我感觉(安慰奖)奖品挺垃圾的,就没买。扭蛋500就买了4发抽着玩,全是小垃圾反正。

然后今天是真的晒啊,我这么待了1小时左右已经感觉到满脸都在疼了,一会第一件事就是去买了防晒霜。之后也每天都认真涂,于是这次完全没有晒伤(虽然感觉脖子还是黑了不少)。

既然已经决定不再往市里跑,时间就很充裕了。我稍微休整了一下,就走到附近的AEON吃饭顺便逛逛商场。这里上次来看lisani live的时候已经逛得很仔细了虽然。我在food court逛了半天结果又吃了和上次一样的印度咖喱。结果接下来就有插曲了!我在一楼准备去厕所换衣服的路上,突然发现中间有个舞台有表演(可拍照):

是一个叫做ドットビーピーエム的地偶的ririibe。推特快速浏览了下成员,发现居然有个(蓝发,日南千穂)写会说中文。我在台下看完演出,顺便看了下特典会规则,好像有初见无料,就决定白嫖一下。实际买了碟排特典会的人不多,可能只有个位数,不过每个人都拿了十几张准备大 Loop 的样子。特典会很快就准备完毕,我拍的成员 Chiho 酱直接没人,我于是就去拍了一张。这里还出现了因为我在群里说了所以小棋去fo人家人家以为我是小棋的笑话。她说她在台湾生活过所以会说中文,中文确实很好,不过也没细聊就是了。

然后我刚准备走,发现她们今天这个活动居然还有Guest:

这个叫 YUM!-TUK! 的组合调研了一下。还挺复杂的。这本来是一个5人地偶组合(由著名杂志《JUNON》发起),结果就在不久前突然决定发起名为“YUM!-TUK! RE:CONNECT”的分头打钱的操作:其中三个人远征印尼(??)以“YUM!-TUK! ID”的名义活动,剩下两人留日,以RIR!-MAR! from YUM!-TUK!的名义继续活动。这次来guest就是这两人(其实那仨人直到后面的5月14日才正式赴印尼)。

虽然我来的时候她们的live已经过了,所以没看着。但是我瞅了一下,这个也是有特典会并且有新规无料的,于是去厕所换了件uta酱的推T先,就来排队了。因为这个组合的粉绿衣服真的很好看!

这边的队伍意外地蛮长,估计有快10人。不过staff看我拿的初见券,直接过来问我要拍哪个人(让我指,知道我也不知道名字XD)。我就随便选了茉莉果(图上右二,另外一位是图上右一),感觉更可爱一点右边有点长江,结果发现其实前面所有人都在拍另外一位的梨々花,于是我直接就去拍了。和她一说话,就发现她冷冷的难怪粉丝少,不过一点点的盐对应我也很无所谓啦。走之前我还再次问了下她的名字,她还很认真地把读音和汉字都描述了一遍(读作Marika,写作茉莉果),好感+1。

怎么有点像某位故人

经过此插曲,时间过得很快,差不多可以入场了。

几天前就已经开座位,知道自己开到了非前排席座位中一个小神的席位:stand最前排、最靠舞台侧的一个座位(如图所示):

实际入场发现,我左边那个位置没人来,再往左所有的列则是不开放的,也就是说我这个就是实质stand最靠近舞台的一个座位,爽爆。我终于可以像大家一样在护栏上挂推巾了→被Staff骂了。

说说live本身吧——一个字:强大。歌单参见这里:https://www.livefans.jp/events/1897961 (和Day2基本一样,只有安可最后三首歌换了一首复读前面rearrange ver的,并调整了顺序)。

kyuruchan的歌曲我的熟悉程度虽然还达不到FZ的水平,但是至少名气比较大的那十几首歌还是听的很多的。而且kyuruchan算是转型过,早期歌曲其实不怎么唱了。这次作为团体的集大成live,那自然是应唱尽唱,听过的没听过的全都唱了。Kyururin我之前看过几次拼盘还有一次FC Event,唱的歌数量都有限,这次一本满足。而且不知道是不是错觉,感觉唱功比原来好多了。

歌曲表演本身好像除了好棒也说不出什么,但是MC我确实想吐槽下:这几位姐不知道是不是平时很少有这么长的MC,每次都感觉不知道该说什么,对话非常脱线、容易卡壳,其中重点点名amu酱,全程MC有一种喝高了的美,乐死我了。上次看到这么搞笑的MC应该是去年看的fav me的某次活动,也是因为MC时间较长,导致疯狂事故,估计地偶出身的在MC这块的训练都不太足。

有 W Encore。在最后(?)的MC的时候每个人发言,平时都酷酷的Uta酱还是露出了软弱的一面,我记不清是谁发言的时候(Yuna?),说了一些不要哭之类的话题,结果自己没哭把听的Uta整哭了,她还很撒娇地捂住耳朵说“不听不听”,很温馨。

这里多废话几句吧。刚开始看Kyuruchan的时候决定推Uta纯粹是觉得她颜最好,但是现在全方位地喜欢(当然其他人也很喜欢,尤其是Yuna、Amu)。作为一个靠SNS尤其是短视频导致爆火的团体,Uta酱其实挺异色的:她基本不怎么玩SNS,推特可能几天也不发一条,Ins和Tiktok也是基本不怎么更新,基本不会顺着团队政策天天刷最新歌曲的舞蹈,偶尔发发也是自己遛狗遛猫的照片什么的,感觉是那种工作和生活分得很开的人,这也是我很喜欢的一个点。虽然在三偶、地偶的语境讲这个有点搞笑,但是我其实还是挺喜欢有一定距离感的偶像;而且单纯“少轰炸一些SNS信息”这点本身就非常值得大感谢一番了:看得团太多,每个都这么搞真的信息非常过载,我现在对于偶像团,真的只想关注她们的演出信息,而不是不停地在X上刷同一个梗(这里点名批评某街道……)。

Kyuruchan的歌曲在我看来,属于神级。我当年入坑是靠一首ヤマモトショウ桑的,也可能是她们最著名的歌之一的(准)同名歌曲《きゅるりんしてみて》,此曲至今也是我最喜欢的歌。作为写出FZ几乎所有成名作的Shou桑实力真的没的说,麻仓桃我最喜欢的歌也很意外地是他写的。Shou桑作曲编曲不提,写词也别有一番魅力,我是不知道他一个大老爷们是怎么能写出这些非常电波看似前言不搭后语但是又完全能懂的少女感的歌词啦……《わたかわ》也是(与此同时,这些歌词想翻译得信达雅,实在是很难。不过说来,きゅるりんってしてみて连组合名都没有一个很好的中文翻译!)

哦对了,在MC的时候amu还提了当初知道这首歌还吐槽,这种同名歌曲不是一般都是快解散了才会出嘛!笑。

我记不清这个环节是不是讲每个人最喜欢的歌了,似乎是?我依稀记得Uta酱是说了《絶対無敵ラブソング》的,这首歌也是我接触kyuruchan后期开始喜欢的一首歌,歌名就透出一股无敌的味道,这歌主要是Bメロ和副歌部分都太爽快了,也和kyuruchan大部分歌风格不一样。

其他歌曲的话,最让我惊喜的是《可愛さ圧倒的なんばーわん!》这首初创时期(21年,五人时期)的歌曲也唱了。同样地,这首歌也是风格和现在区别很大(更传统王道系),我也是很后面才听过,但是一听就很喜欢了。

許してにゃん!

不但唱了还是第一次encore的大轴曲,很舒适(不过后面我才发现,出道专里其他的所有歌都是以成员solo+集体的形式串烧演唱了,就差这个。所以也算是有伏笔了。)

(当年的uta和现在几乎没区别,但是amu简直就是别人wwwwwwwww声线都不一样啊喂

另外这首歌真的很需要兎遊たお的声线……呜呜可惜不能同富贵)

除了这些,kyuruchan的好歌实在太多了,可以说良品率极其惊人,基本所有发数字单曲的都在水准之上。让我硬再选一首,我会推荐《♡♡♡わんだーらんど》——振付超级可爱,还有kyururin歌中少有的跳(虽然基本没多少观众跟跳,唉精致女粉),歌曲更是无敌洗脑。诶话说,kyuruchan现在绝对是JKJD在学院祭翻跳最多的组合了吧!天天刷到。

(这个后出的 performance video 的制服简直无敌了!)

哦对了,回到演出,我那个位置不用说离花车超级近的,很可惜没有收到任何res……撮可花车曲的时候,uta酱从我身边过的甚至没有转过来,哭哭

拍舞台的撮可我自然就爽爆了,老子都不用站起来就能随便横拍

stand席气球彩带自然一个都没有,不过离场时门口发气球,没拿到黄色随便拿了个Yane酱的。我之前看大帅练出来的娴熟手法秒放气震惊周围樱花妹(大雾)

看完我发现从幕张撤退如果完全可以走一段路(直接往北走到センターストリート那条路)坐巴士然后上总武线(当然人多可以打车),巴士上都没有几个人,大部分人还是就近坐京叶线的。感觉很方便,京叶线东京转车过于变态。

回秋和72哥 ljt rpb吃了群友指定松饼屋(没吃晚饭所以多吃了一份意面)然后就回宾馆结束第二天!

《再战视频渲染器:nVidia D3D11的BUG和应对方案》的小更新

短文。快速描述一下前文成文之后的一些变动。

直接concat HLS切片产生的TS用ffmpeg重封装后的视频,使用内置解码器播放拖进度条会卡顿

这个是最离奇的问题,而且我觉得99%的人都不会遇到,但是还是描述一下。这个问题和 PotPlayer 更新无关,因为用23年的旧版本也会复现。但是我只是在最近才注意到这个问题,因此我只能怀疑是显卡驱动什么的触发了这个bug了。

首先Pot复现需要的设置:只要用Pot全默认就好,或者更具体说只要使用内置的AVC解码器就会出现。如果用硬解,则更为明显。

出现问题的片源:这个则比较复杂。简单来说,就是对于HLS下载的ts切片,通过 binary concatenation 的方式合并(也是我最常用的方式),然后再用 ffmpeg 转一遍MP4或者MKV之后的文件。我经常这样处理我下载的 livestream,因为直接合并出来的TS文件本身播放时经常有奇怪的bug,转一遍mp4解千愁,连拖动进度条都会顺畅许多。其实mkv更好,但是mkv由于有时间戳精度的问题毫无意义的完美主义比较抗拒。其中许多视频由于HLS切片的方式,本身就有各种时间戳(TS)的问题,转换时ffmpeg会抱怨诸如:

[mpegts @ 000002a34ea91500] Invalid timestamps stream=1, pts=3060, dts=9000, size=148
[mpegts @ 000002a34ea91500] Invalid timestamps stream=1, pts=9000, dts=11970, size=113
[vost#0:0/copy @ 000002a34f474ac0] Invalid DTS: 9000 PTS: 3060, replacing by guess
[mpegts @ 000002a34ea91500] Invalid timestamps stream=1, pts=15030, dts=20970, size=116
[vost#0:0/copy @ 000002a34f474ac0] Invalid DTS: 11970 PTS: 9000, replacing by guess
[mpegts @ 000002a34ea91500] Invalid timestamps stream=1, pts=20970, dts=23940, size=106
[vost#0:0/copy @ 000002a34f474ac0] Invalid DTS: 20970 PTS: 15030, replacing by guess
[vost#0:0/copy @ 000002a34f474ac0] Invalid DTS: 23940 PTS: 20970, replacing by guess
[mpegts @ 000002a34ea91500] Invalid timestamps stream=1, pts=27000, dts=32940, size=114
[mpegts @ 000002a34ea91500] Invalid timestamps stream=1, pts=33030, dts=36000, size=122
[vost#0:0/copy @ 000002a34f474ac0] Invalid DTS: 32940 PTS: 27000, replacing by guess
[mpegts @ 000002a34ea91500] Invalid timestamps stream=1, pts=39060, dts=45000, size=115
[vost#0:0/copy @ 000002a34f474ac0] Invalid DTS: 36000 PTS: 33030, replacing by guess
[mpegts @ 000002a34ea91500] Invalid timestamps stream=1, pts=45000, dts=47970, size=113
[vost#0:0/copy @ 000002a34f474ac0] Invalid DTS: 45000 PTS: 39060, replacing by guess

云云。转换出来的文件自然也会有dts/pts不太连续的问题:

可以看到,这个文件不但PTS不连续,甚至会有重复的 packets;比如0.066秒就有两个。片源(eplus streaming+)估计切片的方式有点不标准,切割点前后估计有重复的数据包。事实上,如果用 mkvmerge transmux 一次,体积可以缩小27%!

但是正常来说,即使是这样的文件,也不是不影响正常播放的。

但是这次的问题恰恰就出在这样的文件:如果用Pot播放并快速地在进度条上seek,会发现每次seek完(关键帧seek)的前100毫秒左右播放时会出现卡顿、慢动作、快动作等反常现象。

另外注意制作测试视频时,只要使用 ffmpeg -c copy,不管是输出mp4还是mkv都会有问题。但是原始的.ts反而不会,或者ffmpeg输出也是.ts也不会。用 mkvmerge 输出 mkv 也不会。

如果改解码器为LAV,或者使用内置,但是修改为这个“System MFT Decoder”:

此BUG都会消失。而且这个bug只有在片源比较长(比如2hr+)的时候才会很明显,从中间切十几分钟几乎感知不出来,所以也很难做一个最小重现的示例片源。

但是这个“System MFT Decoder”又会有一个其他的bug,就是之前 Pot 其实一直会有的,播放TS封装的H.264/Main时,会导致视频比例显示不对(1920x1080p的视频显示为1920×1084)。这个BUG在用默认的Built-in FFMPEG Decoder的时候已经修复,但是看上去没有修复几乎没有人用的System MFT Decoder的情况。

为了规避这个bug,我现在又全盘换成了LAV解码器了(参见上文LAV方案的2)。

但是用LAV解码器通到Pot,并且使用D3D11渲染器时,又有个另外的BUG:就是对于没有色彩信息bitstream tag的视频(也就是用mediainfo查看信息,看不到诸如“Color range : Limited”这样的信息的),在240305版本后,会默认被视为PC range(然而实际上99%的情况都是Limited range的),导致显示变灰。关于这个问题,我几个月前已经发邮件给作者了,但是他坚称这不是bug,而且“don’t comment any further on this matter, and if you think current is problem, just use another program”。我也是很无语,那如果要用LAV的时候,请改回使用EVR渲染器(或者默认的auto)吧。

Pot最新版使用D3D11解码+D3D11渲染10bit视频时又没有dithering了

之前说过 PotPlayer 使用 D3D11 硬解码 + D3D11 渲染器时,虽然依然有发绿的 bug,但是至少 10to8 是有 dither 的。

然而我在 231220 到 240509 这两个版本之间,PotPlayer 不知道修改了什么,导致这个 dither 没有了,于是瞬间有了巨明显的 banding 问题:

请看这个对比。左边是 231220 版本,右边是最新的 240827。图片经过对比度增强。可以看到人嘴附近,从之前的几乎看不到 banding 变成了非常明显的 banding。

对比两者的 OSD,可以看到区别在于之前的 BackBuffer 这一层是工作在BGRA,也就是说已经进行了有 dither 的10to8才到 BackBuffer;现在则是 RGB10A2。也就是说 10to8 的步骤发生在了这后面的BackBuffer 到 Display 之间;而这一步是没有 dither 的(也符合上一文的分析)。其具体原理我就说不清楚了,因为我根本不知道 BackBuffer 是个什么东西。

我不知道为什么会有这样的改动。介于开发作者回邮件的态度我也不是很想给他再写信了,反正我个人也不用这个组合。

顺便贴一下从我测试的最早的 bad 版本 240509 到最后一个 good 版本之间的 changelog:

[240509]
----------------------------------------------------------
- Fixed an issue where the screen did not appear when playing some MP4 files
- Improved built-in D3D9 renderer stability
- Fixed an issue where files in compressed files could not be played properly
- Fixed an issue where the screen was broken after navigation when playing certain MPEG 2 with DXVA

----------------------------------------------------------
[240305]
----------------------------------------------------------
+ Added NVIDIA RTX Video HDR function
+ Added ability to move files to playlist

- Fixed an issue where damaged WAV files could not be played
- Fixed an issue where the screen was broken when playing certain MPEG4 codecs
- Fixed an issue where the screen did not appear when playing certain WMV videos
- Fixed an issue where certain SRT protocols did not work
- Fixed an issue where an error occurred when playing certain TS files
- Fixed an issue where an error occurred in certain situations when playing some VP8/9 codecs.

nVidia 修复了缩放糊的BUG

上文提过最离大谱的是 nV D3D11 video processer 缩放的 bug,更具体地说就是如果缩小到小于原始大小50%(长度比?)时会出现整个画面完全糊掉重影的现象。

果然这么过分的 bug 还是相对比较快地修复了。在 nV 驱动 560.70 的 changelog 中,有这么一条:

  • [OBS] Scaling 10-bit HVEC or AV1 content down below 50% in viewport shows corruption for some configurations [4496901]

说的就是这个bug啦。

再战视频渲染器:nVidia D3D11的BUG和应对方案

没想到又要再搞这个话题(叹气)。

在上一篇(PotPlayer无MadVR设置方案),因为我当时使用一台没有独立显卡的电脑,完全跑不动 MadVR,所以我研究了下 MadVR 之外的渲染器的方案,很欣喜地发现 D3D11 的效果其实很不错,故用之。

最近,添了一张 nV 4系的显卡,理论上很简单,只要再回到上上文用 MadVR 的方案不就行了呗?呃,其实用习惯了D3D11,发现MadVR有些小问题还能挺烦的:

  1. 估计是因为MadVR“太重”的缘故,在用它的时候,拖拽视频进度条有时候还是不够流畅。尤其是反向拖动的时候。实话说并不是很严重,一般来说你拖动前几次都非常流畅,但是如果你狂拖进度条几十次,前后来回(一般是找某个场景的时候),就会出现卡顿现象。
  2. 在开启反交错(双倍帧率)的时候,无论是LAV中开启还是Pot开启还是MadVR开启,在暂停的时候都会跳帧(画面往回跳一帧)。这个真的是个非常非常小的问题,但是强迫症很难忍受。

另外,每次放个高清视频动辄50%的GPU占用率感觉还是挺没必要的,不够环保。

那有人会问了,好吧,那你直接换回你上文说的D3D11渲染器的方案不就行了?没错,我就是这么干的。结果一干就出事了:nVidia GPU下的的D3D11,和iGPU的行为完全不一样,甚至有很多BUG!下面详述。

在开始之前,我先提一下另外一个渲染器,MPC Video Renderer(下称MPC-VR)。这个渲染器根据我的理解并不是MPC的一部分,但是是针对给MPC-BE使用为第一目标而开发的(反正他们的开发者都是那一堆人就是啦)。我第一次知道这个东西是之前搜索如何在视频播放器中调用nV的超分辨率功能时看到的。但是除了这个功能(和本文无关,后面附录谈一下)之外,这也是一个蛮优秀的渲染器,安装之后PotPlayer里也能调用(但是有坑,后谈)。

这个渲染器其实是一个很轻量的渲染器,其主要目的是方便你调用显卡自带的渲染器,再加上了一些很少的HDR相关和部分放缩算法调整,总体上而言和Pot用EVR-CP时,自带的一些设置选项差不多:

但是对于本文的目的就非常合适:非常便于我们测试各种DXVA2/D3D11相关的参数。

另外我们可以同时在MPC-BE和Pot中使用,这样可以控制变量,防止被一些PotPlayer自身引入的、而不是nVidia驱动的BUG干扰。而且其有极其详尽的OSD信息。

nVidia的D3D11视频处理器对于P010格式的BUG

要触发BUG,首先视频格式是 P010(一个10-bit的YUV格式,几乎所有的10-bit和HEVC和H.264解码后都是这个格式)。根据MPC-VR判断,这个错误其实发生在“D3D11 video processor”这一层。使用上图所示的默认设置就可以触发。如果用PotPlayer,最简单使用D3D11硬解+D3D11渲染器即可触发(不过还有一些其它条件)。

BUG1:整体颜色发绿

左为使用MPC-BE的默认渲染器(EVR-CP),右为Mad-VR

图片经过对比度、亮度加强。可以看到,右侧的使用MPC-VR明显有绿色的色调。

如果在MPC-VR的设置中进行以下任意修改:

  1. 去掉 Use Direct3D 11,也就是用 DXVA2(D3D9);
  2. 或在 DXVA2 and D3D11 video processor 中去掉P010/P016

这个BUG立刻就不见了。所以我的推测,这个BUG出现在 P010 转换到 R10G10B10A2_UNORM 这个YUV转RGB的过程中。因为如果用 D3D9,是转换成 A2R10G10B10 这个格式:

再放一张PotPlayer的绿图。作为对比的左边是使用 Intel iGPU 同样设置的结果。可以看到,颜色没有任何问题(但是有很严重的banding,这个下面单独说)。

左为使用Intel (正常),右为使用nVidia (发绿),其他设置完全一致

其实用Pot的时候(MPC-BE+MPC-VR不会),还有其他一种情况也会触发发绿BUG,就是使用D3D9解码+D3D9渲染器。但是使用D3D9解码+D3D11就不会:

左为D3D9+D3D11 (正常),右为D3D9+D3D9 (发绿)

虽然不是很确定,但通过观察 Renderer OSD里列出来的格式,我们可以揣测一下发生了什么。可以看到左边是从P010(被Pot自己?)先转成了RGB10A2才进的 Video Processor,所以规避了BUG;而右边则是很奇妙地直接P010一把梭转成了XRGB(一种4:4:4的RGB格式),可能这个过程中也触发了类似原理的变绿的BUG。

OK,所以为什么会这样?其实我很多年前就发现 nVidia 和视频相关的技术栈会有发绿的问题,当时是发现用 ShadowPlay 录制视频,有时候会发绿。虽然没有任何证据,但是我强烈怀疑这个bug和我之前在ffmpeg静态图转视频这篇blog里提过的、ffmpeg的swscale组件的一个有十几年的bgr->yuv颜色和rgb->yuv颜色不一致的BUG有关(虽然我们这里的 bug 是反向转换)。

更两人恼火的是我不知道应该去哪里汇报这个BUG。这种应该是得自己写一个不牵扯到视频渲染等一系列客户端软件layer、而是直接调用 Windows的 D3D11 API 的最小实现,再去nVidia Developers 相关论坛或者 bug tracker 汇报才会比较被重视,但是我实在没这个水平,更完全不懂C++,不知道从何下手。而且我想各种第三方渲染器的开发者应该早就知晓此问题了,但是也没有搜到比较任何相关的 documentation。比如我在MPC-VR的issues中发现了至少三个相关的问题:

https://github.com/Aleksoid1978/VideoRenderer/issues/48

这个完完全全就是这个BUG!开发者提到:

To convert from NV12 and P010 to RGB you use D3D11 VP. This conversion is controlled by the driver manufacturer and MicroSoft.
But you can disable NV12 and P010 options and convert with our shader.

v0lt

因此,提问者在关闭了 D3D11 的 Video Processor 选项(上述)之后就规避掉了bug,TA也就没有再深究。

https://github.com/Aleksoid1978/VideoRenderer/issues/98

这个虽然是HDR视频,但是我怀疑也是同样的问题,因为也是P010格式的。

https://github.com/Aleksoid1978/VideoRenderer/issues/22

这个其实是最有趣的:提报者(后来才知道,原来是某群群友)使用的其实并不是原生的 D3D11 VP,而是 MPC-VR 自带的 Shader 来做 Video process,但是居然出现了同样的bug!MPC-VR后面修复了这个BUG,理论上可以根据改动一窥端倪;但是我完全搞不懂是怎么修复的:因为并没有链接到对应的commit,根据评论中提供的2个分别反馈为bad和good的测试版本的commit hash,应该是这个diff——但是感觉完全没有相关的啊?!线索断了。

BUG2:Downscale时整个画面边糊出现重影

如果说上面那个BUG可能不是太明显,有的人估计看不出来的话,那么下面这个就非常离谱了。当使用 nVidia 的 D3D11 Video Processor(VP)进行 resize 时,如果是缩小,则整个画面会变得非常模糊且出现重影,这点在比较锐利的线条尤其是硬字幕的时候非常明显:

我相信不瞎的应该都能看出来吧!要规避这个BUG,除了上面的说的完全禁用D3D11 VP的办法之外,也可以在MPC-VR中单独关闭“Use for reszing“,或者在Pot里把 resizer 改成其他任意的。再次强调,这个BUG依然是只有P010格式的视频会触发。

实话说,很难相信这么明显的bug会一直没人修复!有点怀疑是不是最近的驱动才引入这个bug的。我又去MPC-VR的repo瞅了下,确实有两个汇报(第一个第二个),都是比较近期的。

再测 nVidia 语境下的 D3D11 渲染器的质量

OK,BUG说完,让我们来回到这一切折腾的起因——渲染器的质量。先回顾一下:

  1. MadVR质量最好/最可控,但是太重,在Pot调用时连带还有一些UX上的小毛病;
  2. 之前惊喜发现 D3D11 video renderer (Intel) 的效果其实非常好,尤其是缩放锐度和 halo 都很不赖,故用之。不过,10bit视频是直接截取,所以有非常明显的 banding 的问题,所以我们采用一些措施来尽量软解,靠前面的解码器部分来给我们dither到8bit再渲染(如果硬解会 P010 直通到 renderer)。主要的难点是Pot很弱智的内置解码器HEVC强制硬解,需要调用LAV来克服。

所以我们现在需要重新调研一下 nVidia 的D3D11(以及D3D9)在缩放和10 to 8这两个重点上的表现,毕竟已经知道了和 Intel 完全不同。当然还有 HDR tone-mapping 的问题。

不过我们先试试MPC-VR这款不错的渲染器在Pot上表现如何。如果不错,我们完全可以改用这个。很可惜,虽然没有上面提到的MadVR那些UX上的小bug,但是有个更离谱的:在调整播放窗口大小(包括切到全屏)时,会非常的卡,外加闪烁。同样,这只是个一个非常小的问题,但是我表示不能接受,故放弃。

缩放

OK,那么我们就来比较最常见的4:2:0 8-bit的1080p视频缩放到1440p的表现吧:

呃,这一比就比较尴尬了——nVidia的渲染效果比Intel差了不是一点半点。锐度不如而且 ringing 更大。

D3D9(DXVA2)和基于D3D9的EVR则更差,整体又多糊了一档;而且还有很奇怪的图像整体向左偏移约1像素的问题(假设MadVR为 ground truth),不过这个倒是不影响观看。加强对比度后对比:

当然,我们可以在 Pot 选用其他的基于 shader 的 resizer,但是那些效果也都挺差的,毕竟都是一些比较基础的算法。

10 to 8

上文提过, Intel 的渲染器上文有提到过完全没有 dithering,所以如果在那里进行10转8,会出现非常严重的 banding。这点 nVidia 这边终于有改善了!如果用 D3D11 renderer,会有 ordered dithering,而且还是渲染像素级的(非原始分辨率级),效果很好:

但是!别忘了我们上面提到的发绿的BUG!(其实这图里都能看出来绿了。)所以说,这个我们其实还是享受不到,还是得老老实实把 P010的解码设置为软解,让解码器输出NV12(也就是已经降过位深),然后再给 D3D11 VP/VR。

那么在nV下,其他几款渲染器效果如何呢?直接上结论,结合上面的BUG一起说:

  • D3D9解码+D3D9渲染:发绿,downscale重影,banding
  • D3D11解码+D3D11渲染:发绿,downscale重影
  • D3D9解码+EVR-VP渲染:完全OK!

怪了,说好的 EVR-CP 是基于 D3D9 的呢,怎么现在居然有 dithering 了?虽然不是工作在渲染分辨率(而是视频分辨率),但是效果完全OK啊!

从 OSD 可以看到其格式流程是 P010 先到 A2RGB10 进 Mixer,然后在 RGB 空间 dither 到 XRGB 进行后面的步骤。

也就是说,如果不是缩放质量太差,我们甚至可以换回 EVR-VP 了。

另外还有一点,上文提到修改内置解码器设置中,把 HEVC 的解码器改成 ffmpeg.dll 来强制软解,很可惜现在已经没有这个选项了!所以说现在没有任何办法可以关闭 Pot 对 HEVC 的硬解(也就是会导致10-bit输出 P010 导致 BUG),所以 HEVC 必须得调用外部的 LAV。

所以,最后下来,我的配置其实和之前差不多:

Pot 内置解码器设置中不开启硬解(但是先勾选一下然后勾选下面的D3D11后再取消以防万一:

对于HEVC,手动设置LAV为编码器,来规避P010直通D3D11 renderer导致的BUG:

使用内置解码器的时候(所有非HEVC的格式),其实都等价于会自动使用转换滤镜。对于调用LAV的情况(HEVC),开不开出来的结果对于D3D11渲染器其实都没差,我就开了。

不过要注意,如果 LAV 勾选了 P010、且开启转换滤镜的时候,LAV播放10-bit 会出P010给D3D11,导致触发 BUG。而且不管你在 Pot 的 Colorspaces 那里怎么设置都不行。如果真的不想开转换滤镜,那一定要进 LAV 把 P010 输出取消勾选。这点我们下面详细总结里会再赘述一遍。

BT.2020/HDR

设置完后,我们再去验证一下几个非标情况的播放结果。首先是 HDR——其实这个东西我也不是很熟,纯粹靠自己瞎看了。说错了请指教。

因为我的屏幕是SDR,所以需要tone mapping到 SDR。如果用MPC-BE先做个简单测试,会发现播放的时候其实MPC-VR端收到的 Transfer Function 变成了BT.709了(但是 Matrix 和 Primaries 还是 BT.2020):

MPC-VR OSD

EVP-CP的话则是显示了两个BT.709,搞不清楚哪个是哪个。

EVR-CP OSD

这个转换是完全不可控的,似乎也没有任何选项,无论硬解软解都会转换。当然我也不是想折腾,毕竟颜色是对的就行了。

而如果你用 MadVR,则是显示了两个BT.2020:

而且颜色是错的,你需要单独设置MadVR显示器校准那边才能把颜色给整对。而且MadVR那边的设置非常迷惑,我之前提过一次

(题外话,在MPC-VR的repo里有搜到有人说 VR 的 OSD 显示的 Primaries 和 Matrix 是和 MediaInfo 正好反了但是开发者不置可否,介于这三个东西经常有各种奇怪的别名,我不好说也不深究了。)

同理,用 Pot 调用各种渲染器也有这个类似的操作,但是有的时候没有 MPC-BE 那么灵光。比如,如果用LAV 输出 NV12(输出 P010 同理)然后喂给 MPC-VR:

可以看到和 MPC-BE 不同,这里 MPC-VR 是收到了 BT.2020 transfer function。然后出来的颜色也不对。虽然 MPC-VR 里有转换 SDR 的选项:

但是我折腾了一万年也没整明白怎么能触发他(触发了的话 OSD 中应该会有一行后处理:转换到 SDR 云云)。不过,如果我把 HEVC 的解码器改回内置(并被 Pot 强制硬解),则一切就又正常了,和 MPC-BE一致:

搞不懂啊搞不懂。还好,用 D3D11 renderer 的话没这毛病,无论什么解码器,都可以正常转 SDR。

另外有个细节,如果 resizer 选的是 auto,这里这个测试用的 4K BT.2020 视频无论解码器用的啥(Pot 自带硬解,LAV 各种格式输出,etc.),resizer都会变成 Texture Bilinear 而不是一般常见的 D3D11 Video Processor,也就是类似 EVR-CP 的画质。当然你可以手动选回去(我有想是不是因为视频是4K的缘故,但是另外找了一个 4K BT.709 的视频,没触发)。

Full range, 4:2:2, 4:4:4 等各种情况总结

还是直接先上表吧!

这次和上次的比稍微复杂了点,多加了几列,有两列还调换了下顺序,如果要对比请注意。标注思路还是一样:绿色 good,黄色可忍,红色不能忍。EVR Vista 啥的那个就不测试了,反正没人会用到。

我上次的表格没有区分是否勾选Pot的视频“转换滤镜”,后来发现这个对于LAV的还是有些区别的,故加上。

第四列那个再罗嗦一次,就是这个选项,名字太长了:

中文是叫:

下称“直接转换输出色彩空间”。其大概意思就是,如果条件允许绕过Pot自带的转换滤镜,直接从解码器通到渲染器。因此,3、4列也不是所有组合都会有区别,简单来说:

  • 使用内置解码器时,相当于始终启用了“转换滤镜”。实际上是否能跳过,取决于“直接转换输出色彩空间”是否启用。
  • 使用 LAV 等外部解码器时,只有开启转换滤镜时,开启“直接转换输出色彩空间”才有意义。因为如果不开启转换滤镜,其实就相当于可以直接转换输出色彩空间。唯一的区别就是,如果使用开启转换滤镜+直接转换输出色彩空间的组合时,Pot 不会接受LAV的P010输出为输入(所以 LAV 会变成NV12 喂 Pot),但是不开启转换滤镜则可以。

那么让我们仔细端详下这个表。

可以看到,D3D9对于 full range 的视频束手无策,总会clip,我们先一票否决。

使用内置解码器时:

对于422和444只能软解。如果不开启直接转换输出色彩空间,因为转换滤镜的缘故会用NV12,所以自然损失了不少 Chroma 空间的质量;即使开启,renderer最大也只吃422,所以444还是会损失。

对于视频本来就是8 bit YUV的,无论软硬解都OK,反正都是NV12。对于10-bit则比较tricky。如果是软解(H264的情况),内置的 ffmpeg 解码器会帮你 dithering 后 NV12 输出,除非开启了直接转换输出色彩空间,则会直通 P010。而硬解怎么搞都是 P010 ——别忘了,如果是 HEVC,Pot 的内置解码器是强制硬解的。

如上文所述,我们的渲染器碰到 P010,EVR-CP 是很OK的,D3D9、D3D11 都有严重的问题。所以如果和我一样要用 D3D11,就得不开启直接转换输出色彩空间来保证软解时输出正确。至于硬解的情况?我们直接选择 HEVC 的解码器为 LAV 来解决。

再来看看LAV:

基本来说,使用“禁用转换滤镜”和”启用转换滤镜+同时开启直接转换输出色彩空间”这两个组合都可以完美处理所有格式:对于 10-bit,如果是 D3D11 渲染器的情况,要手动取消掉 LAV 里的 P010 输出,在 LAV 中直接 dither 到 NV12。

如果使用转换滤镜但是却不开启直接转换输出色彩空间,因为Pot的转换滤镜只能工作在 NV12,这两种色彩空间,所以即使是10-bit 视频,也是会直接找 LAV 要 NV12,即使你 LAV 没有取消 P010 输出。所以很OK。但是副作用是,无法正确处理442和444的视频,这个和上面原因类似,就不赘述了。

介于我们想用 D3D11 渲染器,然后还要应对 P010 的BUG,我们其实有以下几种选择:

  1. 全局使用 LAV + 禁用转换滤镜 + LAV 中禁用 P010:所有格式都OK。缺点是如果其他情况调用LAV时无法用 P010。
  2. 全局使用 LAV + 转化滤镜 + 直接转换输出色彩空间:所有格式都OK。
  3. AVC使用内置(软解),HEVC 使用 LAV,同时禁用“直接转换输出色彩空间”防止内置软解直通 P010:422、444效果差。

理论上自然应该用2,但是因为某些很纠结的原因(主要是用内置滤镜比较流畅),我实际上是用的3……呃。我就是有毛病我承认。

再看看默认的 EVR-CP:

其中真·默认设置的是倒数第二行。可以看到,效果还是挺不错的(和我改了半天的结果基本一样)。

也就是说,如果不在意缩放画质(这个其实也可以修改算法来稍微改善),Pot的默认设置现在已经完全可以用了,因为实际上他现在已经解决了 banding (or lack of dithering) 这一大痛点。我突然感觉到一阵空虚:我干嘛要折腾这个!

附录:nVidia RTX Video Super Resolution

顺便提一嘴这个(下称VSR)。毕竟我最开始折腾有这个的因素。目前为止支持这个的播放器还不是很多,Chrome 是原生支持的,什么都不需要设置。VLC有个专门的魔改版,但是这个版本有个非常恶性的bug,播放一切非16:9等非标准宽屏分辨率的视频时会显示比例错误

说个题外话:这个BUG已经提出了9个月了,但是根本没人修复。对于这种大型知名开源项目,经常看到这种核心功能还算维护的OK、但是稍微非核心功能的、即使是严重bug也没人修复的窘状。但是与之相反,有些明明理论上规模相当的项目,比如MPV,就有非常充裕的核心开发者和路人在进行快速迭代。搞不懂这是什么原因,是项目太老不够吸引新人?还是PR审核太慢,久而久之就没有人愿意参与?(嘛,想起 ffmpeg 现在还得在 mailing list patch……)哦,对于 VLC 这个特例,丫的 repo 和报错网站(https://code.videolan.org/)居然需要审批才能注册账号,这能好吗?

对于 MPC-VR,已经很早就加入了对VSR的支持,勾选一个选项即可(必须得用D3D11,所以连带着上面各种BUG)。另外还有个fork据说是加强了对HDR的支持,不过我没试过。

至于Pot这边,虽然已经加上了选项:

(要启用D3D11渲染器才能选)但是我这边实际上并不好使,无法调用到 VSR。更离谱的是,如果我改用MPC-VR 渲染器,然后再里面勾选,在 Pot 里还是无法触发 VSR。所以我放弃了。(我有发邮件问作者,但是他说他没问题。)

效果方面,我只测试了开到4(最大):denoise 的强度还是蛮高,对于那种 compression artifact极多的超低分辨率视频效果还行:

但是看 720P 或者 1080P 之类的本身就不是很模糊的视频就油画感很强了,感觉没有必要,不如传统缩放算法。

哦对了,这个 VSR 对于小于 360P(以及大于 1080P?)的视频是无效的,这是 nV 那边写死的,不是播放器/渲染器的问题。

解压缩用 ANSI (GBK) 编码密码的 zip 文件

之前在某处下了个 zip 包,有汉字密码,试了下果然解压密码错误。我用了 WinRAR 和 7z 都不行。因为我的系统是英文,而且很多 zip 都有文件名用 ANSI 编码的问题,我大胆猜测是和密码的编码有关。

果然,随便找了台中文 Win10 系统的电脑测试下,就可以随便解压了。

但是,如何在英文 Win (系统编码: cp1252) 或者纯 Unicode 环境下(例如 *nix)解压这个压缩文件?我随便找了下,居然常见的解压软件或者 CLI 工具,例如 Linux 自带的 unzip,7z,WinRAR,居然全都不支持设定密码的编码或者直接 binary 输入密码?!这也太菜了吧。

使用 Python 处理

在 SO 系网站搜到这个问题,提到可以用 Python 自带的 zipfile 模块来解码,因为这个模块本身的 pwd 就是二进制输入。你自行随便怎么 encode 都行。这个思路是对的但是没想到 Python 的 unzip 根本不支持这个压缩包:

from zipfile import ZipFile

with ZipFile("XENOGLOSSIA.zip", "r", metadata_encoding="gb2312") as myzip:
    myzip.extractall(pwd="射命丸文".encode("gb2312"))

# NotImplementedError: That compression method is not supported

那么怎么检测具体一个压缩包的压缩方式呢?在 WinRAR 里其实就可以看到信息是 DEFLATE + AES:

Python 的 zipfile module 显然是支持 Deflate / store 的,那么不支持的应该就是 AES 了。

事实上我自己用 WinRAR 又重新压了一个果然也是 AES 无法解压,那么到底什么样的密码加密 zip Python支持?仔细定睛看了一下,WinRAR 在压缩时有个选项是

果然勾上之后生成的压缩包 zipfile 就可以解密了。

使用 pyzipper

我按图索骥,用这个报错信息搜索,很快就找到了一个第三方库叫 pyzipper,增加了对 AES encrypted zip files 的支持。试了下果然好用,解压文件本身没问题了!

但是这个库其实是 fork 了 Python 3.7 的 zipfile 然后修改的,所以代码很陈旧,不支持 pathlib 还是小问题,比较遗憾的的是它不支持 Python 3.11 才有的文件名编码指定的功能(也就是上述代码中出现的 metadata_encoding)。这个功能其实 WinRAR 等工具现在也都有了,但是他们没法处理这狗血的 GBK 编码的密码……

如果看一下源代码,其实也超简单,ZIP 有个 flag 可以指定是否是 Unicode 文件名 (_MASK_UTF_FILENAME),如果没有这个 flag 则默认使用 cp437 来编解码文件名。所以,可以简单修改这部分的 pyzipper 的源代码来 match 最新的 zipfile:

            if flags & _MASK_UTF_FILENAME:
                # UTF-8 file names extension
                filename = filename.decode('utf-8')
            else:
                # Historical ZIP filename encoding
                filename = filename.decode(self.metadata_encoding or 'cp437')

不过要去修改第三方库自然太不优雅了,我们自己脚本里写个后处理吧:

from pathlib import Path
import shutil

import pyzipper

def extract_encrypted_ANSI_zip(zipfile, password, encoding='gbk', create_new_folder=True):
    zipfile = Path(zipfile)

    output_dir = Path.cwd() / zipfile.stem if create_new_folder else Path.cwd()

    # create a temp folder to extract into, so we can fix the filenames before moving them to the output folder
    temp = Path('temp')
    while temp.exists():
        temp = temp.with_name(temp.stem + '_')

    temp.mkdir()

    with pyzipper.AESZipFile(str(zipfile), 'r', compression=pyzipper.ZIP_DEFLATED, encryption=pyzipper.WZ_AES) as extracted_zip:
        extracted_zip.extractall(str(temp), pwd=password.encode(encoding, errors='replace'))

    all_files = [f for f in temp.rglob('*') if f.is_file()]
    for f in all_files:
        relative_path = f.relative_to(temp)
        old_path = str(relative_path)
        new_path = old_path.encode('cp437', errors='replace').decode(encoding, errors='replace')
        if new_path != old_path:
            print(old_path, '-->', new_path)

        f2 = (output_dir / new_path)
        f2.parent.mkdir(parents=True, exist_ok=True)
        try:
            f.rename(f2)
        except FileExistsError:
            print(f2, 'already exists')

    shutil.rmtree(temp)

extract_encrypted_ANSI_zip('XENOGLOSSIA.zip', "射命丸文", 'gbk')

这套方案我已经补充到之前的 superuser 的答案中了。

主题已经解决,让我们来聊两个支线任务。

如何检测 zip 文件类型

前面说过 zipfile 无法处理 AES 加密的文件,那么如果没有 WinRAR,我们怎么知道它是 AES 加密的?

第一时间想到的自然是 unzip,但是我用 unzip 去分析:

$ unzip -lv XENOGLOSSIA.zip
Archive:  XENOGLOSSIA.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
       0  Stored        0   0% 2023-09-16 21:37 00000000  XENOGLOSSIA/
 2010985  Unk:099 1972819   2% 2023-09-16 19:56 00000000  XENOGLOSSIA/img0001.jpg
 1585979  Unk:099 1557941   2% 2023-09-16 19:57 00000000  XENOGLOSSIA/img0002.jpg

他居然给我显示 unknown…… 随便搜了下搜到这个答案,说是“If you have a very new version of unzip available and it displays AES_WG in the Method column, you file is AES encrypted”。但是我的 unzip 已经是 6.00 最新了呀?

这个问题我在用 Linux 经常遇到,很多系统自带的命令行工具经常会有不 consistent 的行为,然后根本不知道无从下手也不知道怎么升级,有什么头绪吗?

Anyway,作者提出了另外一个方案,就是他自己写的工具 zipdetails,可以显示更详细的信息,也可以看到文件是 AES 加密的:

E4FB4D0 LOCAL HEADER #79      04034B50
E4FB4D4 Extract Zip Spec      33 '5.1'
E4FB4D5 Extract OS            00 'MS-DOS'
E4FB4D6 General Purpose Flag  0001
        [Bit  0]              1 'Encryption'
E4FB4D8 Compression Method    0063 'AES Encryption'
E4FB4DA Last Mod Time         57309EAB 'Sat Sep 16 19:53:22 2023'
E4FB4DE CRC                   00000000
E4FB4E2 Compressed Length     0000F7A2
E4FB4E6 Uncompressed Length   0001046F
E4FB4EA Filename Length       0015
E4FB4EC Extra Length          002B
E4FB4EE Filename              'XENOGLOSSIA/����5.jpg'
E4FB503 Extra ID #0001        7075 'up: Info-ZIP Unicode Path'
E4FB505   Length              001C
E4FB507   Version             01
E4FB508   NameCRC32           91103119
E4FB50C   UnicodeName         XENOGLOSSIA/封面5.jpg
E4FB523 Extra ID #0002        9901 'AES Encryption'
E4FB525   Length              0007
E4FB527   Vendor Version      0002 'AE-2'
E4FB529   Vendor ID           4541 'AE'
E4FB52B   Encryption Strength 03 '256-bit encryption key'
E4FB52C   Compression Method  0008 'Deflated'
E4FB52E AES Salt              DA 75 2F E1 51 36 C2 1A 4A 31 45 14 AE
                              CB 74 E4
E4FB53E AES Pwd Ver           F5 98
E4FB540 PAYLOAD
E50ACC6 AES Auth              9F 3F CC 5A 73 F5 2F 37 BB F2

ZIP 文件名的编码方式

通过使用这个工具,其实也顺便解决了另外一个支线任务:就是我之前就有发现,虽然这个压缩文件用 pyzipper 解压出来文件名是乱码(因为是 GBK 编码),但是在 WinRAR、7z 或者 unzip list 的时候都可以看到正确的文件名。当时就很好奇 why。

原因就在上面这里:这个压缩包其实每个文件的元数据里都有个 0x7075 的 extra field 叫做 Info-ZIP Unicode Path ;顾名思义,这个字段里提供了 Unicode 文件名。Winrar、unzip 等软件都能读取到它来替换掉有编码问题的文件名。但是 zipfile 亦或 pyzipper 就没有对其的支持了。

最后总结:哥们你 tm 别压缩成 zip 格式+中文密码了好吗!

哦对了,还有个笑话(彩蛋?)。

您猜我在这英文 Win10 系统里,用 WinRAR 生成一个带密码的 ZIP 压缩包,但是输入中文密码……会怎么着?

……

…………

嘿,您瞧,这密码=“密码”,变成了密码=“??”了,完全能正常解压呢!感情您就是简单一个 pwd.encode('cp1252', errors='replace') 是吧!