DVD的名义时长和实际时长的不一致

之前提过,我发现直接播放DVD(ISO)和先remux或者压制之后的视频的名义时长不一样。

两者的区别很小,但是正好是一个1000/1001——比如手头这个视频,直接播放DVD显示01:20:03,但是压制后就显示01:20:08。此现象可以在几乎所有播放器重现(我测试了:Pot,MPC-BE,SMPlayer(mpv核心))。

我之前默认分开播放两者时,会分别真的遵照这个不同的时长来播放,从而得出了DVD会实际按照24/30fps播放、而压制之后会按照23.976/29.97fps的速度来播放的结论。但是真的如此吗?还是要实测才知道。

我用的测试方法如下:

  1. 用同一个播放器播放两个视频,手动不停暂停调整到保证两者的播放in sync或者基本 in sync。观察两者的时间区别(如果有)。
  2. 找一个比较好计算的时间点开启一个秒表(我用的手机)作为第三参照。
  3. 放置视频播放至少40分钟以上。再次对比视频实际内容和时间轴。

今天要写的是测试1,使用MPC-BE(我对Pot的标准程度始终无法信任…)。

首先我们打开上述视频,然后截个图记录。上图是直接播放DVD,下图是我自己rip的版本。

001.png

首先可以看到,两者的总时长如上所述,错了5秒。我从30分钟左右开始,调整到两者视频内容基本一致(最多错4-5帧,也就是+-200ms以内)。这里可以看到,从我选的这个时间点两者的时间已经有所不同了,但是相差只有1-2s左右。另外秒表我用的手机,这里没有拍进来,我是从上面的视频的00:31:00开始计时。

经过大约40多分钟的放置play,我们来看看结果。

首先是视频内容:两者依然基本是in sync的,虽然可能稍微差了那么一点点,但是最多也只有几百ms的区别。这证明,两个视频的实际时间/播放速度是一致的,否定了上面说的“播放fps不同”的假说。那么名义时间呢?显然时间不可能还保持只有1s的差距,否则最后结束时间差的那5秒哪里去了!

事实上,正是如此——但是出乎意料的是,这两个视频居然都没有和我的秒表一致!

 

003

可以看到,本来我的秒表是和上面的视频(DVD)的秒位应该是一致的,但是现在上面的要慢高达2秒;而下面的视频(rip)则比比秒表慢了2秒左右(一开始就慢1秒多,所以间隔基本没变)。

两个视频的名义时间的差距,算上最开始就慢了1秒多,相当于在43.5分钟内又多偏移了3秒左右,倒是基本符合1001/1000差:

2612.7*1001/1000-2612.7~=2.613
2612.7-2612.7*1000/1001~=2.610

(正算反算都是2.61秒左右)

也就是说,虽然视频实际播放的速度一致,但是显示的名义时间却至少有一个不是准确的,甚至两个都不准(不说死是因为我无法确认我手机秒表的准确性)。

硬要选一个的话,下面的视频的名义时间比较接近我的秒表。下面的视频是rip过的MKV,每帧的timecode是写死的可以提取出来,最次也可以根据帧数反推——如果播放名义时间符合实际时间,证明确实是23.976fps在播放,而不是24。

介于两个视频的实际播放速度一致,如果认同下面视频名义时间准确(=实际播放时间)这个结论,就可以推出:对于DVD,播放器仅仅是是按照30/24的速度来计算以及显示总时长/当前时间的,播放时并不按照那个。

 

改天再用其他播放器再测试一个视频好了,这次准备使用Pot,使用电脑上的秒表软件而非手机,另外准备使用一个真·30fps的视频测试(这次测试这个视频是film的,24fps)。

 

现在我很好奇的是,如果把DVD放在物理DVD播放器接电视播放,会怎样呢?

ffmpeg静态图转视频

注意:本文部分内容之前发表在此文。但是经过补充后单独成章比较好,就移动到这边来了。

将一张图片转成视频的基本命令很简单:

ffmpeg -loop 1 -i {img} -t {dur} -vf format=yuv420p output.mp4

默认的fps是25,可以用-r指定成别的。这里重点注意-vf format=yuv420p部分,这个保证视频会被正确转换为最常见的YUV420格式,否则会使用YUV444格式。这个等效于-pix_fmt yuv420p

同理,如果需要其他格式(YUV444、YUV422之类),只需要替换成其他的pixel format即可。如果想要full range,可以使用yuvj420p

但是仅仅这样做,有两个问题。

选择的正确RGB->YUV转换矩阵

第一个问题是RGB->YUV的转换矩阵。ffmpeg默认是使用BT.601矩阵来进行这个转换的,如果你的输出视频是SD分辨率,这并没有问题。但是如果是HD视频,HD默认的标准是BT.709,所以这样就不对了。最明显的就是纯红色255, 0, 0会变成255, 25, 0。

解决办法,首先自然可以给输出结果显式加上BT.601的metadata:

-color_primaries smpte170m -color_trc smpte170m -colorspace smpte170m

(NTSC和PAL还略有不同,参见此文。)

但是,不推荐这种做法。有的滤镜/渲染器根本无视元数据。HD视频还是老老实实用BT.709就好。所以最好的办法是进行正确的BT.709转换。

ffmpeg有N个video filter可以实现这个,最常见的是scale

ffmpeg -loop 1 -i {img} -vf scale=out_color_matrix=bt709,format=yuv420p -color_primaries 1 -color_trc 1 -colorspace 1 -t {dur} output.mp4

其中-vf scale=out_color_matrix=bt709部分是把图片转换成BT.709(Rec. 709的另外一个名称)。因为我们还有个format的vf,直接把两者用逗号串起来(filter chain)。

后面的-color_primaries 1 -color_trc 1 -colorspace 1的是在元数据里标注。如果用x264编码(默认如此),也可以直接用-x264opts colormatrix=bt709。当然,如上所述,如果是HD视频可以略去不写(不推荐)。

除了-vf scale,还可以用:

  • -vf colormatrix=bt601:bt709,format=yuv420p:从命令来看,感觉实质是先转601再转709。
  • -vf colorspace=iall=bt601-6-625:all=bt709:format=yuv420p :同上。另外注意,这里的formatcolorspace这个vf的一部分(冒号分割而非逗号),而不是再调用format
  • -vf zscale=matrix=709,format=yuv420p:这是一个比较新的filter,来自zlib

几个讨论可以参见这帖这帖

swscale的颜色误差bug

我之前一直是使用上述的-vf scale来转的,但是总是发现颜色有点偏——白色(255, 255, 255)会变成略微发黄的颜色(252, 255, 252),我以为这仅仅是精度不足的缘故也没太在意。直到有一天无意发现,如果我先将输入的BMP图片另存为PNG格式,就不会发生偏色。这完全不make sense!于是我报到了ffmpeg

经过快2个月无人问津后,我忍不住去ffmpeg的emaillist发了个帖,果然引来了玉——除了一些workaround之外(下述),最重要的是有人指向了真正的bug:#979

简单来说,swscale这个库(libswscale)——包括scale滤镜——有一个奇怪的bug:从bgr24转换为YUV会有色差,但是rgb24就不会(两者应可以无损转换)。上面BMP和PNG结果不同也是因为PNG用的是rgb24的pixel format,而BMP是bgr24。

既然知道了问题所在,我们只需要先转换一次即可,把上面的vf前再串一个format

-vf format=rgb24,scale=out_color_matrix=bt709,format=yuv420p

就可以啦!那么上面提到的其他几种转换滤镜,有没有同样的问题呢?

  • colormatrix:同样的bug,这个filter应该也是基于libswscale。
  • colorspace:如果你使用上述的方式,使用colorspace内置的format参数来转换成yuv420p而不是串一个format vf,可以避免这个bug。
  • zscale:无此bug。

另外,这个bug还可以通过添加scale的flag,accurate_rnd(精确rounding)来修复(这里还加上了另外一个增加精度的flag,full_chroma_int,不过这里accurate_rnd其实就够):

-vf scale=out_color_matrix=bt709:flags=full_chroma_int+accurate_rnd,format=yuv420p

当然,这并不是说这个bug仅仅是精度的问题:否则无法解释为什么rgb24就无问题。

另外,colormatrix之类的vf虽然没有flags参数,但是你可以增加-sws_flags accurate_rnd,也可以修复问题。

ユメシンデレラ (麻倉もも) 封面的情况

短文,算是上文的简单实践。主要是这次有个细枝末节的问题,写给care的人看。

首先先讲推荐使用的版本1:

颜色正确的sRGB版本。可以在官网discography(仅限限定和Anime盘,通常盘见下述)下载600px的。图像直链地址(右键复制):

或者在Sony Music Shop下载:

三个版本都有,但是只有500px,而且Anime盘下面多了个copyright标记。所以除了通常盘,还是用上面的吧。

(顺便一提,一般而言,索尼Music Shop的颜色都是比较靠谱的。官网是这次恰好是正确的,之前经常错)。

Sony Music Shop还附赠一张尺寸不算小的公式照:

注意有内嵌的Adobe RGB ICC和部分EXIF。拍摄日期可以看到是19年6月25日。

camera

至于在CD内容宣布的info帖子里的图,则是你的老朋友——Adobe RGB直接丢ICC而不是正确转换成sRGB的版本。自然不推荐,如果一定要使用,手动下载修改ICC为Adobe RGB,并使用兼容的图像软件查看(显示效果应该与上一组一致)。

贴个范例,注意和上图对比,明显肤色饱和不足:

顺便一提,荒乙的官网也是用的版本1(正确的sRGB),不过对封面进行了剪切,真人的上下切掉一点,Anime盘左右切了点。

这次案例的奇怪之处在于,存在一个版本2。

基本所有的数字平台(自然只有通常盘),包括mora、iTunes等等,以及官方discography(仅限通常盘)都是用了一个单独的的版本(下图为官方discography的600px版,可以在mora下载的音频文件中提取1400px的版本、以及在iTunes下载3000px的版本(但是明显是upscaled的,所以毫无意义)。

这个版本和上面的版本无论正确的还是错误的都不一样,主要区别在于Red通道下沉,因此明度要低不少、但是对比度更高,比如蓝色更深沉。和版本1差的也不是一次简单的sRGB<->AdobeRGB转换。

我暂时搞不清楚是因为其他什么别的色域转换导致,还是干脆就是不同的调色版本。不过如果要从2手调到1倒也不难,level里总体gamma搞个1.12、然后R通道单独加1.08左右gamma就能实现。

其实这个版本2,三种都有,我在ナタリー的访谈中找到了全套,800px:

注意,要点击查看大图(比如第一张是p_lim.jpg)。

外面的小图:

文件名是pc_item_lim.jpg,反而是和上面版本1一样的版本,这就更诡异了。

 

个人用视频播放器最新设置方案

本文是前文,外挂LAV+开启PotPlayer转换滤镜时的最佳设置方案的追记或者说更新。

本文大纲:

  1. 重新总结下视频播放中Pot无法胜任的部分和原因;
  2. 我现在如何设置PotPlayer来workaround这些问题;
  3. 我的备胎播放器;
  4. 为什么如此忍辱负重也无法抛弃PotPlayer。

视频播放的几个转换

视频播放,宏观上通常需要经历这么几个的转换步骤到输出(不按顺序,也不一定都有):

  1. 解码
  2. 色度抽样还原 (420或者422->444)
  3. 缩放
  4. YUV->RGB
  5. 降位深(10bit -> 8bit)
  6. 反交错

解码没什么好说的,其他大部分逐条说一下。

色度抽样还原

色度抽样还原 (420->444) 就是把被缩放到(面积)1/4大小(420)或者一半大小(422)的U、V channel放大到原始尺寸,和缩放本质没有区别。无非就是点对点播放时,Y通道不需要缩放而色度通道依然需要而已。

这个工作LAV、Pot和渲染器都能做,做的最好的是MadVR这个大家都知道了,LAV可以接受,Pot如果如上文所说,如果使用了转换滤镜(下边凡是提到Pot,都是指如果使用了Pot的转换滤镜)会默认强制将420的转换一次422且使用最差的硬差值算法,勾选“高质量转换”可以改善但仍然一般——推荐不在Pot进行。

缩放

都能做,MadVR最佳。

YUV->RGB

都能做。这个的质量问题我不是很敏感,但是Pot有诸多BUG。不推荐在Pot进行YUV和RGB的转换(一般也不会)。

降位深(10bit->8bit)

都能做,但是如果被Pot降位深会完全无任何dithering,效果完全不能忍,巨大banding,故实际上必须要在LAV或者MadVR进行。

反交错

都能做,但是LAV和MadVR的算法好一些。Pot有一堆选项,但是却没有感觉特别好用的。我个人对于反交错的要求其实不多,就一条:真·交错内容一定要还原成原始拍摄帧率(60 / 59.94 fps),否则流畅度不能忍。这点MadVR和LAV的3种算法都能做到,如果用Pot,要选2x frame的,我现在选用的是“motion adpative (2x frame)”这个。

另外对于IVTC的内容,即时反交错的效果都差强人意,但是Pot的更差些。

具体设置方案

那么有了上面那些预备知识,我们可以来对比下几种设置方案。当然,我们只考虑高画质的方案。

LAV->Pot(禁用转换滤镜)->MadVR

分工:

  • LAV:解码
  • Pot:什么也不做
  • MadVR:色度抽样还原、缩放、YUV->RGB、降位深、反交错

设置方法:

  • Pot里转换滤镜disabled
  • LAV全默认设置

另外,可以通过修改LAV的输出或者反交错选项来把部分工作移动到LAV中(比如如果你比较喜欢LAV的反交错滤镜),但是整体区别不大。

优点:最高画质设置,完全不会被Pot劣化。

缺点:导致Pot非常容易崩溃——尤其是播放TS文件的时候(原因不明),这也是为什么会纠结这一切的原因。

LAV->Pot(开启转换滤镜)-> MadVR

分工:

  • LAV:解码、降位深、反交错
  • Pot:什么也不做
  • MadVR:色度抽样还原、缩放、YUV->RGB

也就是前文提到过的方案。首先,我们知道一旦开启了转换滤镜,由于Pot内部处理精度只有8bit且没有dithering,所以降位深必须在Lav做好。事实上,由于Pot的转换滤镜根本不接受10bit的输入,Lav那边会自动diether成NV12再输入Pot,所以无需专门设置。

至于反交错,Pot有个弱智问题就是一旦进入了他的转换滤镜,无论你的反交错是enabled还是disabled,后面都会强制输出deinterlacing=off的flag,导致无法在MadVR中进行。所以必须在Lav或者Pot自身里完成反交错才行。这两个选的话,当然是Lav的好些。

设置方法:

Lav:选一个反交错滤镜开启,其他默认。

Pot里:

  • 开启转换滤镜
  • Video->colorspaces中,选择NV12或者其他4:2:0的色彩空间
    • 目的:防止Pot自做多情的420 to 422转换
  • “Direct conversion”选择“Enable: change default output color space”
    • 目的:直通YUV422/444/RGB内容到MadVR
  • 反交错:disabled

优点:由于大部分MadVR的优势部分依然是在MadVR进行,所以基本可以维持最高画质。非YUV420的内容会直传MadVR所以不会被Pot劣化。

缺点:依·然·会·崩·溃。

Pot(解码+转换滤镜)->MadVR

分工:

  • Pot:解码、反交错
  • MadVR:降位深、色度抽样还原、缩放、YUV->RGB

在上面那个方法依然会导致Pot不时崩溃的情况下,我开始思考:能否完全绕过Lav,直接用Pot内置解码?对于我来说,解码器的质量并不是关键的,因为解码本身是个deterministic的过程(而且Pot其实就是用的ffmpeg,质量不会有大问题)。但是通过使用Pot自带的内部工作流程,应该会明显改善崩溃问题。

我的第一直觉是这个流程对10bit会不行——从上文可知,Pot的转换滤镜甚至不接受(LAV的)P010的输入,怕不是直接就给我砍成8bit了?结果不试不知道:在开启“Direct conversion”的前提下,Pot用内置解码器居然反而可以直通P010到MadVR!

blog01

那么赶紧来试一下其他几种色彩空间:

YUV422:YUY2直通MadVR; YUV444:AYUV直通MadVR。

很完美!当然,对于YUV420的视频,Pot那个自作多情的伸张成422的问题依然存在,所以手动设置色彩空间为NV12依然是必要的。

设置方法:

Pot里:

  • 开启转换滤镜
  • Video->colorspaces中,选择NV12或者其他4:2:0的色彩空间
    • 目的:防止Pot自做多情的420 to 422转换
  • “Direct conversion”选择“Enable: change default output color space”
    • 目的:直通YUV422/444/RGB内容到MadVR
  • 反交错:enabled,选一个喜欢的。个人用motion adpative (2x frame)

优点:终于不会崩溃了!另外,除了反交错由于Pot的限制必须在Pot进行无法达到最高质量以外,其他的转换都正常在MadVR进行,接近完美。

缺点:反交错效果略微差点。

另外,稍显遗憾的是,无论是上面哪种方案,之前提到的截图问题都存在。我以为改用内部解码器就能解决这个问题呢,看来似乎只要用MadVR就会这样?

音频解码

音频解码可以继续用LAV,或者也换回Pot自带,我感觉区别不大。因为这个并没有太多可以搞糟的部分嘛。

唯一一个需要注意的是5.1->2.0转换。LAV默认的设置是这样的:

QQ图片20190713212105

也就是说,Center和Surround都会降低到71%、LFE直接完全关闭之后再mix到Front——据LAV的作者在Doom9说,这是标准里写的。那么我们把Pot也改成一致的呗:

QQ截图20190713212326

这里我改了几个地方:

  1. mixer level改成了和LAV默认一致。
  2. 关闭了Expand stereo to center 和expend stereo to surround。这两个选项其实是把2.0映射到5.1才有必要的,但是Pot的实现很怪,是先把2.0用这个映射到5.1,再用下面的mix level mix回2.0。如果下面全是100的情况下自然是完全一样,但是我们都改成非100了,还保持这两个勾中会导致音量变低,所以去掉。

这么改完听5.1音轨,发现LAV的声音还是会小一点(mix倒是听上去完全一样了),研究了下发现是LAV里那个”prevent clipping”选项导致的(自动降低了音量防止削波也就是爆音),我音量因为一般都不拉满所以其实无所谓,可以自行调整。

嘛,这个改不改其实区别不大了,因为一般有5.1音轨的视频大多会有官方混音好的2.0,2.0的设备就应该听那个才对。

备胎播放器:mpv->SMPlayer

在Pot频繁崩溃我却不知所措(笑)的期间,我使用mpv当做备胎播放器,尤其是用来播放ts文件。

mpv是个非常优秀的跨平台开源一体化播放器,渲染质量很高功能也很全。尤其是不依赖太多外部程序(比如LAV、MadVR)这点非常好。而且mpv那种seek时丝般顺滑、毫无delay的感觉和极速的启动速度实在太美。可以一键开启手动反交错(默认是D)这点我也很喜欢。

但是作为一个命令行为主的工具,其用户体验并不是特别好。本人并不排斥CLI工具或者手动修改config文件,但是如果需要经常或者大量调整这些东西,还是非常难受的(尤其是大多时候还得去翻doc,而不是有intuitive的选项可以直接找到想要的设置)。另外,自带的那个简陋的UI也有诸多不便。

于是我去找了下mpv的套壳播放器。很快,我就找到这款叫SMPlayer的软件。虽然UI比MPC-HC还要丑几个档次,但是至少完美保留了mpv的优点,定制快捷键很方便(我基本全改成和Pot一样了w),有基础的选择音轨、章节功能,作为主要拿来看ts的备胎,我也不能要求太高了。

为什么Pot不可替代

个人对Pot的依赖,有部分是来自于迁移成本太高(我建立了大量播放列表),但是主要还是UX体验太好。

就拿一点来说,事实上也是我每次用其他播放器都感觉极其不便的一点:章节选择。Pot可以:

  • 在进度条显示章节marker
  • 且悬浮会有章节名称的Tooltip;
  • 一键(H)开启章节列表选单,然后在列表中自由选择想要的章节;
  • 可以用快捷键(默认是Shift+PageDn)来快速跳转下一章节。

上面的这些功能,不少播放器都有某种程度的支持(比如mpv的进度条有章节marker,大部分播放器的menu里都有章节选择),但是能完美做到上面所有的?并没有。

尤其是一键开启这里——我之前多次提过,快捷键是否“快捷”和是否有快捷键一样重要。比如你想在SMPlayer里选章节?倒是可以,先点browse,再点chapter,然后选,这至少需要3-5秒,中间还要不断移动鼠标光标到很小的目标上。这个方便程度和直接按H是天上地下的。同理,在Pot里按A选音轨、L选字幕、都是极其经常需要用到的,单键快捷键比起组合键或者菜单的优势非常明显。

而且万一视频没有章节,想自己添加?小case:按下P即可添加bookmark。而且这个bookmark在以后使用上,和章节完全没有区别:你依然可以按H查看、按Shift+PgDn来跳转、在进度条上看到marker。另外,通过设置选项之后,bookmark完全可以做成外挂的,这样即使视频文件移动了也能保持所有的bookmark。(参见前文的相关内容)。

注意,bookmark这个功能不是Pot独有的,我能想到不少播放器都有这种功能。但是能做到如此方便、让人去愿意去用,才是其独到之处。

同理,我们来比较下“跳转功能”。在Pot里,按下G会出现跳转框:

QQ图片20190713205207

同样地,在SMPlayer可以用ctrl+J出现跳转窗口:

QQ图片20190713205308

看出两者的区别了吗?姑且不论Pot多了个按帧跳转的功能,但就按时间跳转,Pot就多了:

  1. 精确到毫秒
  2. 直接默认选中全部时间,所以配合ctrl+V等于多了个快速的选中当前时间的功能。

当然公平起见,我们也举个比较接近的例子,MPC-BE的(ctrl+G):

004

基本和Pot很接近了,但是还缺少一个自动hightlight时间的功能,所以不能直接ctrl+V选择当前时间,得先ctrl+A一下。

再来说说缩放:调整视频canvas大小是个很常见的操作,在Pot里你可以:

  • 按123选视频原始大小的50%、100%、150%大小;
  • 按atrl+1/2/3/4按当前桌面百分比大小来缩放;
  • 全屏时依然可以按上述快捷键,来直接窗口化并缩放到对应大小,而不用先退出全屏;
  • 拖拽改变大小时,窗口frame保持比例,不会出现黑边;
  • 在同一个窗口打开新视频时保持窗口大小(可设置)。

等等等等。上面后四条都是非常好用的功能。

播放列表方面我别的播放器的用的不多所以也没有对比不太好吹,至少可以做到只选取视频的部分加入播放列表:

QQ图片20190713211402

Pot不是一个完美的播放器,但是就是这种UX上的attention to detail,让人爱不释手。

结语的一些碎碎念

我发现x264好像根本不支持RGB空间。我刚测试才发现,之前自己用ffmpeg做的“RGB24测试视频”实际是YUV444的…

PotPlayer的崩溃问题我感觉和他的I/O buffer有关。因为我发现在我的5400rpm硬盘上开启bitrate特别大的文件(比如ts)时或者拖拽进度条时最容易崩溃。

Lantis祭一些统计

统计范围:

2009:仅统计9月26日・27日的主公演;

2014:仅统计9月13日 – 15日的关东公演(特别说明的除外)。

艺术家

三届全勤

ALI PROJECT / CooRie / GRANRODEO / JAM Project / yozuca* / スフィア / 妖精帝國 / 小野大輔 / 新谷良子 / 森久保祥太郎 / 橋本みゆき / 畑亜貴 / 結城アイラ / 緒方恵美 / 美郷あき / 茅原実里 / 飛蘭 (Faylan) / 栗林みな実 (Minami)

三届全勤但14年未参加关东公演的:eufonius / LAZY / 速水奨 / 鈴村健一

yozuca*和CooRie主唱rino每届都有コラボ,09年是yozuca*×CooRie名义,14、19是yozurino* (yozuca・rino)名义。

两届

注:凡是参加09和19的都参加了14。

2009 & 2014:

  • Ceui
  • marble(停止活动)
  • 伊藤真澄 (伊藤真澄名义基本停用,顺便一提他老公是烂铁副社长伊藤善之)
  • 麻生夏子(14年Lantis祭乃退隐演出)

2014 & 2019:

  • AiRI
  • ChouCho
  • fhána
  • milktub
  • nano.RIPE
  • OLDCODEX
  • SCREEN mode
  • STEREO DIVE FOUNDATION
  • ZAQ
  • アイドルマスターミリオンライブ!ミリオンスターズ!
  • 伊藤かな恵
  • 佐咲紗花
  • 大橋彩香
  • 小野賢章
  • 田所あずさ
  • TRUE

曲目

三届连续演唱

GONG JAM Project (09&19) / JAM Project×StylipS (14)
MARCHING MONSTER 新谷良子
mind as Judgment 飛蘭 (Faylan)
modern strange cowboy GRANRODEO
Rumbling hearts 栗林みな実 (Minami) (09&19) / GRANRODEO×栗林みな実 (14)
原唱、作词:栗林みな実
作曲之一/编曲:飯塚昌明@GRANRODEO
SKILL JAM Project
空耳ケーキ 伊藤真澄 (09) / 伊藤真澄×畑亜貴 (14) / 畑亜貴×eufonius (19)
原唱:Oranges & Lemons=伊藤真澄・上野洋子
作词:畑亜貴

两届,非同艺术家演唱

Title Original artist(s) Artist(s)
Super Noisy Nova スフィア 09: スフィア
14: CooRie
サクラサクミライコイユメ yozuca* 09: yozuca*×CooRie
19: yozurino* (yozuca・rino)
ハナマル☆センセイション Little Non 09:Little Non
19:アイカツスターズ!
ヒャダインのカカカタ☆カタオモイ-C ヒャダイン 14: ヒャダイン & ヒャダル子(麻生夏子)
19: bamboo×AiRI
もってけ!セーラーふく 泉こなた(平野綾)、柊かがみ(加藤英美里)、柊つかさ(福原香織)、高良みゆき(遠藤綾) 14: StylipS
19: NOW ON AIR
侵略ノススメ☆ ULTRA-PRISM 14: ULTRA-PRISM
19: アイカツ!
残酷な天使のテーゼ 高橋洋子 14: 緒方恵美×ヒャダイン
19: 緒方恵美