な毎か

なんて事ない毎日がかけがえないんだよなぁ…

RGRイベントレポ

自分が観察したRGR(Run Girls, Run! ランガちゃん)のイベントを中心としたレポート。RGRだけでなく、iRis等、プリパラ・プリチャン関連のイベントについても記していく。

諸イベントに参加していたら無常感が出てきた。このままだと何も考えずに終わってしまう気がしたため、忘備録として書いていく。

前提

  • 新参。WUGに関しては無知。
  • しっかり参加できていない。
  • 周りの考察よりも、自分が思ったことを優先して書く。
  • 正確ではない。間違いがあったらなるべく直す。
  • メンバーとのお話の内容は失敗続きの恥辱の極致であり、本当は公開したくない。でも、自分自身と後学のために残しておく。
  • イベント情報は@rgrinfo(と運営の@tkusano様)にだいぶ助けられている。一人では追いかけることもできなかったと思う。

2018年

初接近

ライブイベントは大好きだが、声優の接近系イベントは一切参加したことがなかった。そんな自分が初めて接近するまでをダイジェストで。まだこの頃はレポを取る意識がなかったため、だいぶ大雑把になっている。

2018年4月から始まった「キラッとプリ☆チャン」。3回目放送までに、桃山みらいちゃんが可愛いことに気づき、プリパラへの未練をほぼほぼふっとばすことができた。

5月くらいには、林鼓子さんという高校生声優がみらいちゃんの声を担当されていると分かり、大いに感心する。

5, 6, 7, 8月は漫然とアニメを見て楽しむ毎日。

プリチャン筐体の方も、7月まではアイカツ筐体をやっていて回したことはなかった。7月に初めてプリチャンを筐体で遊んだ。8月は業務が異常に忙しく筐体を回せず。8,9月は3年以上続けていた筐体を2ヶ月休んでおり、心にスキができていたと思う。

2018年9月は今思うと転換期だったと思う。

9.8に「アイカツ5thフェス」があった。このイベントはアイカツ5周年を記念していた。2月末にあった武道館ライブも含め、この日をもってアイカツは終わったと思う他なかった。だからといって他のコンテンツを見出すことができない状態で、友人とは探索を行う意図でいろんなコンテンツのライブやイベントに挑戦する方針があった。自分は探さなければならないと思いながらも、何もできず、懐古を繰り返しているだけだった。

9月の「キラッとプリ☆チャン オータムライブツアー」は、プリパラと同じノリで参加することに決めていた。が、チケット競争率が(前年までのプリパラライブツアーと比べ)異様に高く、大阪公演全落ち、しかも東京(中野サンプラザ公演)の夜しか取ることができなかった。

9.29の公演、いつものプリパラライブと同様の空気で物販待機列に入った。物販はいつもどおり楽勝で、Tシャツとタオルはすぐに抑えられた。

f:id:aikiriao:20200101232550j:plain:w300

物販を抜けた先で、おじさんがひとりでチケットを手売りしているところを目撃する。どうにも気になった自分は、探索の意味を込めて、誰とも知らないライブに行ってみようと思った。ライブのチケットを買ったときに、「見送り会」の参加券も同時に貰った。「見送り会」?なんだそれ?キャストの誰かを見送る会があるのか?という状態で、何が起こるのかさっぱり分からず、気軽に構えていた。

見送り会の集合時間まで時間があったので、その時間にアイカツ筐体に別れを告げた。どこまでも続く懐古路線には苦しめられていたので、前を向く意味でプリチャン筐体に重心を移すことを決めた。

中野サンプラザに戻って、見送り会の集合時間まで待機した。どうやら昼公演が終わった後にあるらしく、集合場所もよくわからない中で妙な緊張感だけが増えていく。そして昼公演が終わって人が流れ出てきた。人をかき分けて、優しい経験者様の案内もあって、なんとかお見送り会に集合することができた。

廊下で待っていると、奥から3人の演者が登場した。ひと目見て元気がある3人だなと思った。これが第一印象。そして何をするのかと思いきやお話会が始まった。嘘だろ!なんにも準備していないし、林鼓子さん以外の人物は顔と名前が一致してなくて誰だか分からない!どうすりゃいいんだと考える間もなく、初めての接近戦が始まった。

自分「お…おっす!(言葉にならない)」
もっちー「オッスオッス〜」
自分「夜公演、これから初参加なんですけどめっちゃ楽しみです」
もっちー「おお〜楽しんでね〜」
--
自分「桃山みらいちゃんの声がめっちゃ可愛くて、ありがとうございます」
はやまる「ありがとうございます」
自分「これからもがんばってください」
--
自分「これからライブなんですけど…」
あっちゃん「この足上げに注目してね」
(あっちゃん、キラッとスタートの足上げをその場で)
自分「ブッフォすげえ、すごい緊張します」
あっちゃん「緊張してるよ〜がんばるね」

※注記:

※上記の内容は誤りを多分に含むと思われる。緊張しすぎて記憶がおぼろげになっている。それでも、もっちーがオッスオッス〜と返したのは間違いないと思う。

初めての接近戦の後はしばらく悶絶していた。緊張のあまりしばらく動悸が収まらない状態が続き、そのまま夜公演へ。プリチャン楽曲はまともに履修できておらず、ちゃんとしたコールも打てていない。でも、さっきお話していた人物が、ステージ上で歌唱している…。

ライブが終わった後も、しばらくはお話のことを思い出して悶絶する日々が続いた。

1stツアーライブ

中野サンプラザで買ったチケットには、Run Girls, Run!という声優ユニットの1stライブツアーの東京公演と書かれていた。公式サイトを見てみると、1stツアーは東京だけでなく、まず大阪、続いて仙台公演もあるとの情報を得た。通しで行くのは金銭的に厳しかったため、11月の仙台公演に参加することを決めた。

10月はプリチャン筐体を夢中で回していて、アニメも含めて大いにプリチャンを楽しんでいた。

迎えた11.4。深夜バスで仙台に向かっていたが、向かう途中、俺はこんなことしていていいのか?アイカツから目を背けていいのか?という罪悪感に苛まれて行くことを後悔していた。仙台GIGSの待機列に入っても、俺は一体何をしているんだろうという気分にしかなれなかった。GIGSの寒い日陰の中で、自分は泣いていた。

f:id:aikiriao:20200101232720j:plain:w300

物販でライブTやタオルを一通り抑え、荒涼とした荒井駅周辺をうろついてから待機列に入った。列はA,B,Cに分かれており、Aは公式先行、Bは↑のプリチャン会場での販売、そしてC列はほぼ当日券である。自分はGIGS公式から申し込んでいたからなのかC列。

会場内は自由席という訳のわからない席振り。C列たる自分は、なんにもわからないから全く無理しないで後ろに行こうと思った。キャパは200強で半分も埋まっていない…?祝花は見た限り、写真の1つしか見つけられなかった。あれ?状態。このまま開始していいのかと思う中、ライブは始まった。

f:id:aikiriao:20200101232749j:plain:w300

ライブの内容を今思い出せと言われると厳しい。印象に残っていることを箇条書きする。

  • 振り付けが激しい。「カケル×カケル」など、特に腕をよく使う振り付けはサイリウムを振るように煽れる。
  • カバー曲パートが全方位攻撃で助からない。「寝・逃・げでリセット!」は世代直撃で号泣してしまった。
  • 途中のトークパート含めて楽しかった。何よりも、楽しさがまず先に来た。
  • 空席のおかげで却って自由に動けて楽しめた。自由に演者を見る余裕もあった。
  • プリマドンナメモリアルは映画のときからずっと評価していた。オータムではしっかり聞けなかったから、生でまた聞けて非常に嬉しかった。

ようやくこのあたりでメンバーの顔と名前が一致してくる。この時点での印象は、

  • はやまるのリーダーシップがすごい。肝が座っている。緊張を知らない。
    • 後でいろんな記事やブログを見ると実は緊張していることが分かった。しかし緊張は読み取れなかった。
  • もっちーは小悪魔的ポジション?で自由に笑いを取れる。
  • あっちゃんは可憐。長い髪をぶん回しての振り付けがダイナミック。

ライブ終了後は軽いお見送り。会場から出る人にRGRメンバーと簡単に挨拶して外に出た。

続く夜公演では、もっちーが喉をやってしまったこと(突然デスボイスになってしまった)に驚いた。MCは流石に涙ながらと行った状態だった。でも、振り付けのパフォーマンスは完璧だったし、終わってみると楽しいという気分になった。

サクラジェラートのアレンジが異様に良かったため、Google検索にかけると、編曲石濱翔の文字が。この瞬間にRGRには強力なバックがいることを確信しつつ、スライドライド(+サクラジェラート)を会場で購入した。

公演後は大きな満足感に包まれていた。仙台のタイトーステーションでプリチャンをいいだけ遊び、アーケードのすき家で、仙台に来てよかったと何度も反芻した。

2018.11.10は1stライブツアーの品川公演(@品川ステラボール)があった。こちらも自由席で、軽い気持ちで右側を抑えた。席は300程?あって半分も埋まっていないのだが、パフォーマンスの高さを再度実感している。メモ書きをしていないので思い出せる範囲で書いていく。

  • はやまるがカバーパートで昼は「Snow Halation」夜は「eternal blaze

    • かつて自分はラブライブ!を見ていた。「Snow Halation」の強さは当時から理解していたし、ラブライブ!から抜けた今は絶対に聞くことはないと思っていた。イントロが入った瞬間、崩れ落ちた。そして白→橙変化も体が覚えていた。落ちサビの「届けて切なさには…」本家ではえみつんの歌唱力が映える。はやまるもそれに対抗できるぐらいの音圧とピッチ安定度で歌いきる。
    • eternal blaze」でも歌唱力が際立つ。この頃には、はやまるは歌唱力担当なんだと直感する…がキビキビ振り付ける様子を見ていると、純粋にパフォーマーとして凄い…という畏敬の念が湧いてきた。
  • キラッとスタートのコールはほぼ完成状態にあった。ジャージャーする人多数(プリチャンライブではジャージャーはあまりいない)。自分は右側後ろ寄りなので自由に打った。自由に打って楽しめるこの環境が良かった。

f:id:aikiriao:20200101232829j:plain:w300

キラッとプリ☆チャン」がネットルール安全教室やってみた!(2018.11.17, 18@東京スカイツリータウン ソラマチ 5階スペース634)

1stツアーの興奮冷めやらぬ中で、スカイツリーにてイベントがあった。近場だからと気軽に参加しに行って、非常に楽しめた。

内容は2日ともまずプリチャンを90秒で振り返り、ネットルールを30分弱でおさらいして、フォトセッションがあって終わりという簡素なもの。2日とも当日整理券配布があったが整理券の番号は関係なく混沌とした。(先輩は前方に席が用意されていた)。出てきた衣装がKRレアのもので非常に驚いた。こんなローカルなイベントでもKRを着るのかと…。

11.17はその後1stチャンネルリリースイベントの参加券を抑えに行った。気持ちのよい快晴の中で、RGRを見れてよかった、QoLが上がっていると実感しながら秋葉原に向かった。

キラッとプリチャン1stチャンネルリリースイベント(2018.12.15@ゲーマーズ秋葉原

ラクルキラッツ(はやまる、あっちゃん、久保田さん)とMeltic StAr(もっちー、芹澤さん、若井さん)が出てきて1stチャンネルのリリイベ。ほぼ芹澤さんと久保田さんがリードする形だが、面白いし、iRisはすげえと感じる。

若井さんが「SUPER CUTIE SUPER GIRL」の楽曲構成が良い、と言っていた。あっちゃんが「キラリ覚醒☆リインカーネーション」を熱く語る場面もあった。イベント終了後に軽くお見送り。この頃は自分は「SUPER CUTIE SUPER GIRL」一択で推していたが、この後筐体で遊び続けていたら「COSMETIC SILLOUETTE」も異常なテクノ感と強さを持っていると実感している。

み〜んなでキラッとプリティーライブ2018(2018.12.9@幕張メッセ

これまでもプリパラのライブは何度か見てきていたが、プリティーライブ2018は最大規模だったと思う。セインツの3人が歌唱、WITHで異常なぶち上がり、「寝ても覚めてもDreamin' Girl」を放送で初披露したその日に歌唱(後でどこかで聞いた話、フリ合わせは1回だけだったとのこと。)、平面会場をひたすらでトロッコ演出。プリパラの華やかさに相応しいライブであり、昼公演を終えた後は最大だったと言い続けた。

全体的な感想は上記として、RGR単独ではどうかというと、オープニングアクト(あいまい…まだわーすた様がやっていたかも…)と物販の説明をしていた。

アニメJAM2018(2018.12.23@舞浜アンフィシアター

他記事でも同様の内容を書いたが、このライブによりRGRを見ていきたいと感じた。アンフィシアターを縦横無尽に、ダイナミックに動き回るRGRのパフォーマンスは他と比べて段違いだったと思う。トークはiRisさんがリードして、芹澤さん中心に十分な笑いを取った。

そしてこの頃だろうか、WUGのファイナルライブが決まって悲しむ方々を幾人も見るようになってきた。WUGについては素晴らしいファンの方々が所々で十分に語られているため、自分が語るべきではないが、少しだけ。「16歳のアガペー」は1stライブツアーのRGRにより初めて聞く有様だったが、本家が歌唱すると俯く方が多数見受けられた。楽曲にしろ、振り付けにしろ、終始しっとりしているイメージは自分の中であった。

Run Girls, Run!とクリスマスカードを作ろう(2018.12.24@アニメイト池袋)

アニメJAM2018の次の日はアニメイト池袋8F?でクリスマスカードを作ろうイベントがあった。始まる前は一体どんな形式でクリスマスカードを作るのか分からず、また接近の経験が少なすぎて、とにかく緊張していた。

何を話していたのかはメモを散逸したので思い出せず。もっちー→はやまる→あっちゃんの順だった。でも、昨日のアニメJAM良かったですが軸だったと思う。そして、はやまるとお話があったあとに笑顔で笑いかけられて、営業スマイルだとしても、自分には刺さった。尊敬している人に存在を認めてもらえる事実が単純に嬉しかった。接近の面白さはここらへんにあると思っている。

f:id:aikiriao:20200101232859j:plain:w300

(参加できず)コミケお渡し会(2018.12.29@東京ビックサイト)

クリアファイル購入者に抽選でお渡し会に参加できる企画があった。11時にavexブースに並んで2時間半ほど待機。抽選券はすでに残り少なく、直前の方が温情で1枚残すように買っていただいた。クリアファイルは買えたが抽選は落選。疲労のため帰ってしまったが、様子だけでも見に行けばよかっただろうか?

2019年

劇場版プリパラ&キラッとプリ☆チャン ~きらきらメモリライブ~ 舞台挨拶・応援上映(2018.1.4@イオンシネマ海老名)

年明け一発目は海老名での舞台挨拶。2回映画を見る機会があり、1回目終了後にトークパート、2回目は最初から出てきてそのまま席について映画鑑賞した。衣装はGo!Up!スターダムのもの。一部の先輩が同一の衣装を着ていたが、一体どこから仕入れたのだろうか。自作?

  • 全員でゲームやりたいと言っていた。スマブラを楽しみたい、はやまるは兄にボコボコにされていたとのこと。
  • はやまるが初っ端元気いっぱいだったのが印象的。他の人が話している時に、振り付けをひらひらしているのがあざとい。
  • はやまるはドラム経験を生かしてイベントをやりたいと言っていた。他にも単独イベントを希望していた。
  • あっちゃんは髪を整えた?(変えた?)ガァルマゲドン推しとコメント。ゲームが上手くなりたいともコメント。
  • もっちーは海外に行くというのと南国に行くのを希望していた。はやまるは海外ライブと言ったら台湾を希望していた。
  • トークは面白くて自分は笑いまくっていたしリアクションも取りまくった。が、会場は沸いていないのが気になった。

f:id:aikiriao:20200101232943j:plain:w300

退出時には軽いお見送りがあった。自分の前の女子にメンバーが反応してしまい、自分はスッと抜けた。また、初めて(アナログの)手紙を出した。文面は年末年始に考えたもの(恥ずかしすぎるため文面はアップできない)で、当日はプレゼントBOXがなく焦るが、スタッフさんに渡すことで事なきを得た。

(不参加)ガーリー・エアフォース先行上映(2018.1.6)

単独だけだから参加しなくて良いかと考えていたらそれは甘くて、RGRメンバー全員が参加していた。完全にミス。大後悔し、今後は単独参加でも絶対に行くと決めた。

ANIMAX MUSIX 大阪(2019.1.19@大阪城ホール

11月半ば?あたりでRGRのクラウドファウンディング企画を見つけていた。なんでも一定金額を集めることができれば新衣装を作れるというもので、ちょうど1stの余韻に浸っていた頃なので速攻で入金した。応募できるコースは2種あり、1つは19000円でメンバーとのグリーティング(グリーティングの意味は今も分からない)、もう1つは29000円でメンバーとのチェキが撮れるというもの。自分はチェキする度胸はなかったため19000円のコースで入れた。

ANIMAX MUSIXの存在自体を知らず、大した予習もしないで大阪城ホールに行ったら会場の大きさに驚いた。

f:id:aikiriao:20200101233027j:plain:w300

その場で出演者を確認すると、声優に詳しくない自分でも非常に強いメンツが揃っていることが分かった。待ち合わせ場所にいるといつも見かけるファンの方々(執筆時点ではランナーの呼称が確定しているが自分のメモ記述を優先)が集まってきた。身分証明を済ませてチケットを受け取り会場内ロビーに入って、スタッフに囲まれた空間に案内された。

その後RGRメンバーが新衣装で登場。第一印象を列挙すると、

  • はやまるのパンツスタイルが活発感を出していて素晴らしい。
  • あっちゃんはロングスカートでお嬢様をイメージとのこと。
  • もっちーは短めのスカートで可愛らしい。

その後少しトークもっちー自身がもちもちしているという発言が面白く、メモに残っている。次にメンバーとのハイタッチ。あっちゃんの手が冷たかった。もっちーとは頑張ってくださいと言って少しレスあり。お次(ハイタッチと前後するかも)にメンバーと応募者を集めて写真撮影した。最後はお見送ってもらい(一瞬で通り過ぎたので頑張って下さいというのが精一杯)ロビーから出た。スタッフに厳重に囲まれていたが、なんだか平和な雰囲気で締めくくった。

社会見学の実感を噛み締めながら、この時に初めてイベントメモを取り始めた。

そしてライブへ。上記キャンペーンを申し込んでいた方々はスタンド指定席で固まって配置され、ほとんど1stライブ衣装揃えとなった(一部ショーケースイベントのTシャツも見かけた)。

ライブは6時間という超長丁場(アイマス10th以来?)。セトリは誇張なしで9割知らかなった。終盤は体力が保たず、コールがおざなりになっていたかも。でも、小倉唯さん、三森すずこさん、鈴木みのりさん、fripsideさんを生で見れたのは非常に印象的。

RGRが出てきたときは当然周囲と盛り上がった。後にメンバーが語ったとおり、RGR勢が青を点灯することで会場が一気に青く染まった。「Break the Blue!!」は新衣装での披露で新鮮味があった。しかし、角度が悪かったのか、自分が疲れていたのか、それともステージが大きかったのか、幕張で感じた躍動感は見られず、振り付けが少しずれていた?(メモのママ)

その日は日帰りで大きな疲労の中、深夜バスで帰った。深夜バスは3列シートに限る。

Run Girls, Radio!! SPECIAL -カケル×WUG- 公開録音(2019.1.22@秋葉原ゲーマーズ本店7F)

Break the Blue!!(だったかな…)のCD購入でRun Girls, Radio!!の公録に抽選できるという情報を入手。抽選の結果当選したので業務を早めに切り上げてゲーマーズへ。座席抽選の結果2列目に配置されて、適度な緊張の中待期。

時間になると青山さんと山下さんがまず現れて前フリ。既にこの時点で青山さんのトークが面白い。山下さんは美人で驚き、そこに超巨大な沼があることを確信する。

公録中は常に笑いっぱなしだった。具体的に何が面白かったかを列挙できないが、青山さんは次々とネタを入れてくるし、テンポよく身振り手振りで笑わせてくる。RGRはどうだったかというと、あっちゃんは頑張ってコメントを差し込んでいるという印象、はやまるは最初は固かったけどすぐに慣れてトークできていたと思う。動いているところを見るとやっぱり可愛いという言葉以外が見つからない。

WUGのコンプリートアルバムのフラゲ日で、またWUGのファイナルライブが近いこともあって少しの悲壮感があったが、それはトークの面白さに吹き飛ばされていた。

わぐりすらん(2019.2.2@松戸森のホール21

avex系の声優ユニット(iRis, WUG, RGR)が一同に介するイベントがあった。松戸森のホール21はJR新八柱駅から徒歩20分程度の場所にあり、森に囲まれたホールに行けるのは遠足といった趣。

昼公演は落選したので夜公演のみの参加。昼公演の間は公園内でのんびりとしていた。ゆっくりできる良い公園だった。

f:id:aikiriao:20200101233106j:plain:w300

夜の部に入場する際にチョコレートを受け取る。時期的にはバレンタインイベントの立ち位置になっているらしい。開演すると、WUGは分からないのはもちろん、iRis楽曲も殆どわからなかった。また、プリパラライブでは全くコールを打っていないことが明らかになった。

ここに来てWUGの悲壮感は、何も知らない自分にとっても実感しやすいものになってきていた。頓死だった(最後の地方公演の後に卒業発表があった)アイカツとは異なり、終りが見えてる中でのイベントになっており、どうしても最後、最後という言葉が刺さってしまう。ゆっくりと死んでいくこの感覚は、WUGを追い続けた方にとっては想像を絶するものだったろう。

バラエティパートでは、なんでも昼公演のバラエティパートで色々あったようだが参加できておらず当然全容理解できず。

最後、青山さん、山下さん、司会の大橋さんが泣いていた。奥野さん?が言っていた「SSAの日が空いていたらそれは運命です」が印象的だった。その瞬間は空いていたのだが、後でカレンダーガールのレコードのリリイベと被ってしまった…(SSAから行った人も、田中さん含め少なからずいた)

さて、RGRはどうだったか。この日はANIMAXの衣装で登場していた。はやまるがどこかで「爪痕を残す」宣言をしていたが、全体的にのんびり楽しんでいた印象を受ける。クイズコーナーでホワイトチョコの回答を2番目に当てたあっちゃんの賢さ、センブリ茶が直撃して悶絶するはやまる、もっちーは全体的に緊張なく振る舞っていたように見受けられる。

後は明示的にファンが増えたかという印象。ANIMAXと違ってホームの印象があり、コールが全体でバッチリ打てるのは良かった。

Break the Blue!!リリースイベント(2019.2.3@秋葉原と渋谷)

わぐりすらんの次の日にリリースイベント(お渡し会)。リリイベにおけるお話は執筆時点でも緊張する。アドリブで会話できない自分は、開始前にメモ(カンペ)を用意している。

秋葉原ソフマップ①号店

参加しなかった。ミニライブがあったらしい…完全に見落としており後悔。

秋葉原とらのあなC

少々(10分程度)のトークの後にカードを配る形式をとっていた。

自分「グリペン…ガーリーエアフォース面白いっすね」
もっちー「ありがとー4話見た?」
自分「ああすっげえ良かったす…泣いちゃいました頑張って下さい」
--
自分「昨日も元気でしたね、センブリ茶ってやばいんすか?」
はやまる「すっごい苦いんだよーその後も口に残るくらい」
自分「うおーやばい…これからも頑張って下さい〜」
--
自分「昨日2回目しか参加できなかったけど、あっちゃん凄かったすねークイズの即答ぶり(高速詠唱)」
あっちゃん「いやいやそんなことないよー」
自分「これからも頑張って下さい〜」
(あっちゃんに手を振られて去る)

この時点で話題がほぼ尽きている。メモから内容を引っ張り出しながら銀座線に乗って渋谷へ移動。

アニメイト渋谷

狭いスペースでの開催。トークはなくそのままお渡しが始まった。

自分「昨日のイベントありがとうございました…2ndライブツアー今年あります?」
あっちゃん「わかんない…でもやりたい←あいまい」
自分「期待してます」
--
自分「サンシャイン出演おめでとうございます」
はやまる「ありがとうございます…(反応忘れた…)」
自分「これからも頑張ってください〜わあ〜」
--
自分「昨日着てたANIMAXの衣装可愛いっすね〜」
もっちー「ありがとうーあれ可愛いよねー」
(自分が挙動不審になっている間にもっちーに早めに手を振られて終了。)

もっちー微妙な顔をしてたぞ?また、流石に2ndライブツアーは早計だったと後悔。

この日はお話が難しすぎると感じて後悔しながら帰った。お話のネタは、どうしても○○良かったすねーが安定してしまう。自分以外の他人を見ていると褒めるのが上手いし話の構築もしっかりしている。質問系はリスキー。反応が薄かったりするとその後のフォローをする間もなく終わる可能性がある。マナーとして、一般的なイベントの予定に聞かないほうが良いということ、褒めるときはなるべく具体的に、何が良かったかを詰めることをやっていこうと思う。

自分にとってお話が難しすぎることを実感していた。リリイベとの向き合い方を考える機会となり、次回以降は1日に3箇所以上は回らないようにしようと決めた。

そしてどう進むべきか考えた末、自分が今こうしてイベに参加しているのは、間違いなくアイカツを追いきれなかった後悔があることが思い出された。その点から見ると、まだまだ走り続けたい気持ちが沸いてくる(執筆時点でもそうだ)。まだこの原理を超える思考が出てこないから、どんな目にあってもイベント参加を続けたいと結論付けた。

おそらくまだメンバーには認知を受けてないから、何してもメンバーは覚えていないはず。どんなダメージも甘んじて受けようと決心した。この時点ではRGRは自分の活動の試金石にしようという方針が立った。

この頃、スライドライドのインタビュー記事にはやまるが緊張しているように見えない理由が述べられていることを目撃する。

厚木 肝がすわっているよ。 林 緊張してもいいことないからね。

ステージ慣れもあるのか、緊張を押し殺すことができていた?

2月の特記事項としては他に以下のイベントがあった。

雪ミク2019

自分の原点はボカロ。何らかの天災が起こらない限り、メインジャンルはボカロであることは変えられない。ライブは伝説であったが、ここに書くべきではない。

プリパラフレンドシップツアー大阪(2019.2.23@Zepp Osaka BaySide)

プリパラフレンドシップツアーは競争率が異常でほとんどチケット取れず。大阪も夜の部だけを一般申込みで確保した。そうしたら最前列席(A列3番)に案内されてしまった。

最前で見るライブは目線がぶつかるので非常に緊張した(小並感)。特にWITHの3人。アサヒ、コヨイ役の方と結構視線があってレスも返してくれる…。(ありがと〜!と絶叫したらコヨイ役の方に手を振替してもらった)男だというのにだいぶ挙動不審になった。また、みかん先輩(渡部優衣)の振り付けがダイナミックで、ガァルマゲドン衣装のスカートがだいぶ動くので危なく、プリズムボイスが突き刺さる…。全体的にどこを見ればいいのか分からなかったが、楽しさが上回った。

曲目としては「Twin mirror compact」、「ぱぴぷぺ☆POLICE!」、「ギラギラ」、「でびえん」あたり。特に「パピプペポリス」は以外に以外で驚いた。朗読劇は、さすが森脇様というか狂っていたが、プリパラらしさが全面に出ていて素晴らしかった。笑いっぱなしで笑いどころとしては、あろまのキャラ崩壊、オーマイデビルx3、常時腹を空かせたみかん先輩、「迷子のショウゴ、略して迷子」、ホッケとアジでアジホッケー。

プリパラはどうであれイベントが楽しく終わるのが凄い。夜公演の1回だけで満足できた。

みんなにありがとう!ミニライブ(2019.3.1@秋葉原ソフマップ①号店、2019.3.5@アニメイト池袋本店)

ANIMAX衣装のクラウドファウンディング企画成功を受けてのミニライブ。開催はいずれも平日で、仕事終わりに向かった。結論、満足度が高かった。

秋葉原ソフマップ①号店

整理番号は120番まであったが全部埋まった。オールスタンディングで、自分は左最後方。更に後ろでジャージャーする方もあり。しかしスタッフに抑止されていた。

感想としては、パフォーマンスが非常に良かった。WUGのようなしなやかさは無いかもしれないけど、生き生きと元気よく動いている。元気な振り付けを見ていて思ったのが、疲れが取れたこと。これを正直に言おうと思ってお話した。

あっちゃん「ありがとうございます」
自分「週末のライブいいですね〜疲れが取れました」
あっちゃん「ありがとうございます〜」
自分「池袋も行きます〜」
--
自分「その衣装めっちゃかわいいっすね…(言葉が続かない)」
はやまる「ありがとー」
自分「(手で口を抑えて、言葉にならない)」
はやまる「また来てね〜」
自分「絶対行きますー」
--
自分「ガーリーエアフォース面白いっすね〜グリペンがどんどん可愛くなってて」
もっちー「そうでしょー?ありがとー」
自分「ありがとうございます」
もっちー「ばいばいー」

終わった後は良かったという気持ちが溢れた。始まる前は、ライブソロ参戦ということもあってビクビクしていたが、変えるときには楽しくなっていた。池袋のミニライブも楽しみになった。

アニメイト池袋本店

秋葉原に比べて緊張感は少なかったけど、周囲がWUGの同窓会となる中ではやはり心許ない。セトリは「カケルxカケル」、「地下鉄ラビリンス」、「Break the Blue!!」。「地下鉄ラビリンス」はわぐりすらんで聞いたことがあったのでなんとかついていけた。そのままお話。

自分「こんもちはー平日ライブいいっすねーやる気出ます」
もっちー「ほんとー?ありがとー」
--
自分「期末試験どうでした?」
はやまる「めっちゃ良かったよー生物と国語が満点」
自分「まじすか…(思わず口を手で覆う)凄えっす」
自分「また行きます〜」
はやまる「ありがとー」
--
自分「ダイヤモンドスマイルすっげえ楽しみです」
あっちゃん「(少々驚き顔で)ありがとう〜すっごい可愛く仕上がってるんだよ〜」
自分「絶対買います〜」

少しもっちーは反応薄めか?先週からの話題の使い回しが良くない?でも、こちらも終わってみると、正直良かったという印象。

f:id:aikiriao:20200101233150j:plain:w300

この頃、2018年のクリスマスイベントを踏まえ、自分の中ではやまるが優位になり始めていたと思う。堂々と生きているはやまるは尊敬できる。そんな中、3.9にははやまるが声優アワードの新人女優賞を受賞しているのを見て大いに驚く。はやまるがいなければ、アイカツ亡き後さまようだけだったかもしれない。

位置について、よーい!AJ(2019.3.24@東京ビックサイト東館)

AnimeJapan2019でのステージの一つにRGR単独のステージがあった。位置について、よーい!AJは申込み順で整理券番号が決まっていたが、気を抜いたら申し込みが遅れて番号が少々悪かった。また、この日はプリチャンのステージもあったが落選した。

f:id:aikiriao:20200101233237j:plain:w300

この日は何よりも「ダイヤモンドスマイル」の初披露があったことが大層印象的。ジャケット調の新衣装で出てきて、初めて聞いた時に(いける)と確信できた。パフォーマンスも安定感を感じるまとまりだった。が、一点だけ特記事項がある。2番の途中、それまでにこやかに歌唱していたやまるが一瞬凄い眼差しでパフォーマンスしていた。無論自分は相当驚いた。

追記:記事の中で、顔がこわばっていたかもしれないとのコメントあり。

林:これまでって「届きたい」、「追いつきたい」だったのが、「超えてみせるから」になった。強いフレーズで表現するようになったんだよね。それが強く自分の中でいいプレッシャーで。すっごくドキドキした。「ダイヤモンドスマイル」歌った時、絶対顔こわばってたんだろうなぁ。

その後はステージ上でお話。

あっちゃん&自分「ありがとうございますー」
自分「ダイヤモンドスマイル衣装も曲も最高っすびっくりですー」
あっちゃん「ありがとー(手の甲を向け、人差し指と小指を出して向かい合わせながら)ダイヤモンドだよー」(あいまい)
--
はやまる「ありがとうー(シール渡し)」
自分「新人賞受賞おめでとうございます!」
はやまる「ありがとうもっと頑張るね」
--
自分「もっちーだ(勝手に口から出た)」
もっちー「はーいもっちーだよー」
自分「(笑ってしまい、大学卒業おめでとうを忘れる)ダイヤモンドスマイル衣装可愛いっすね」
もっちー「(ジャケット強調しながら)可愛いでしょ〜」
(ここで剥がし)

イベントを楽しんでいる自分を確認する。一人だし、認知は取れていないだろうけども、それでも楽しい。新曲を聞けたり、思ったことを喋れるのは純粋に楽しいことだ。

ガーリー・エアフォースのリリイベ(2019.3.29@秋葉原とらのあなC)

もっちー井澤詩織さん、大和田さん出演のガーリー・エアフォースのイベント。もっちーは初めての司会で流石に緊張気味だった。

無学なため後で知ったことだが井澤さんも大和田さんも声優としてはキャリアが断然あり、落ち着いていた。トーク内で井澤さんがあざとく、トークもドギツめで面白い人で、ファントムぽいなあと思う。大和田さんは自身が話すように聞き手に回るのが好きそうなイメージでイーグルとは逆。でもイーグルの声が出る。

お話もあった。井澤さんはやはり圧があった。

自分「初めましてー」
井澤さん「初めましてー」
自分「演技力高くてビビりました」
井澤さん「ありがとうございますー(身を乗り出す)」
自分「(滑舌回らず)」
井澤さん「ほんとー?ありがとう」
自分「(やらかした)」
--
自分「小松に行きたくなりました」
大和田さん「ありがとうございます」
自分「何か美味しいものあります?」
大和田「(去り際)海鮮丼!」
自分「了解です」
--
自分「ありがとうございますーほんと1クール早かったです。終盤終わってしまうところ悲しくて…」
もっちー「だよねー私も悲しい…」
もっちー「2期やりたいね」
自分「2期!期待してます」

もっちーのテンションが低かったか、俺が盛り上げるのが下手だったか?でも、井澤さんが言っていたように、言いたいことは言えたから良しとする。滑舌よくしたい。

プリパラフレンドシップツアー舞浜公演(2019.4.14@舞浜アンフィシアター

この舞浜公演は、比較的安定して取ることができた。メンツは朝比奈さん、大森さん、佐藤さん、WITHの3人だったと記憶している。昼公演は最前(1-77)でやはり目のやりどころに困る。

なんと言ってもこの日はしゅうか様(朝比奈さん)の株が爆上がりした。「Ms.プリオネア」に振り付けがついたことに大きな感動を覚えた。アグレッシブに踊れていた。そして、しゅうか様の新曲「メイクマニー・メイクドリーム」が発表されたとき、呼吸が上手くできなくなった。感情的になり、しゅうか様ありがとうを叫んだ。非常に良かったため、音源化が待たれる。

ライブ以外のバラエティや朗読劇も十分に面白く、ずっと腹を抱えていた。特にプリパラ作文(あいうえお作文的)は成立するはずがない理不尽さが面白かった。(しゅうか様がしっかりリッチキャラを演じていたのが良かった。資本主義の、とか)。朗読劇もやはり書き起こしは良い。見ていて安心できる。無論、WITHも強かったことを記しておく。ギラギラ以外の曲も十分乗れる。こちらも音源化が待たれる。

Run Girls, Run!オールナイトニッポンi 公開録音(2019.4.21@ニッポン放送 LF)

公録は楽しいものという確信を得ていた自分は、抽選ということもあって必死に取りに行った。いざ当選すると緊張が止まらなくなった。話題もしっかり練っておきたかったが、一向にまとまらず焦った。当日は行き慣れない有楽町の街をさまよってニッポン放送へ。

番号はかなり良くて最前列に座り、開始直前は緊張がピークに達する。公録が始まると1時間45分に渡って自分は笑い続けていた。特に1部で呼吸ができず、生まれてはじめて笑いすぎで具合が悪くなった。はやまるに抑止されてたかも。

公録後はお話。

自分「ごきげんよう〜めっちゃ公録面白かったです」
あっちゃん「ありがとうー」
自分「もう2時間あっという間という感じで」
あっちゃん「本当に短かったよね!ありがとうーメール送ってね」
--
自分「公録面白すぎて…腹が割れました」
はやまる「ほんと?シックスパック?」
自分「(軽く仰け反ってシックスパック)もうほんとに面白かったです」
はやまる「ありがとーまた来てねー(あいまい)」
--
自分「公録ありがとうございました。もっちーめちゃくちゃおもしろかったです」
もっちー「わーありがとう」
自分「3分のやつは笑いすぎて息ができなくなりました」
もっちー「ほんとぅ?ありがとう…ばいばいー」

もっちーの反応を引き出すのは難しい。でももっちーは最後になることが多いから、最後の印象を良くするためにも考えていきたい。

ダイヤモンドスマイルリリースイベント(2019.5.12@秋葉原

自分が参加したのはゲーマーズソフマップソフマップではミニライブがあった。

ゲーマーズ秋葉原

トークは10分程度切り上げてお話に入った。

もっちー「こんもちは〜」
自分「メルテックの帰還めちゃくちゃ楽しみです」
もっちー「でしょー。楽しみにしてて。戻ってきてくれたら応援してくれる?」(間違っている可能性大。こんな長文を記憶しているはずがない)
自分「絶対応援します」
--
自分「ここんにちは〜」
はやまる「ここんにちは〜」
自分「(思わず口を抑えながら)TOKIMEKIハートジュエル最高っすね」
はやまる「わー本当嬉しいです」
自分「筐体で回しまくってます(呂律回らず)」
はやまる「ほんとーありがとーばいばいー」
--
自分「プリチャン新シーズンも楽しい!」
あっちゃん「ありがとうございます」
自分「りんかちゃんの私服可愛いっすね」
あっちゃん「ありがとう、来週絶対見てね」
自分「絶対見ます」

ソフマップ①号館

ここではミニライブがあった。左最前が空いているので座ったところ、隣の方にお話最前になるよと言われて戦慄。焦ったが、どうすることもできず公演が始まってしまった。

ライブは「ダイヤモンドスマイル」、「Break the Blue!!」、「Go!Up!スターダム」で、振り付けが超ダイナミックでRGRの強さと素晴らしさを再確信する。Break the Blue!!の最後であっちゃんが目の前でポーズを決める時に靴が摩擦でキュッ!っと鳴るのが聞こえるくらい前だった。そして結構もっちーとあっちゃんに視線貰えた…RGRは視線くれることが多い。こっちが直視してても笑いかけてくれる。こんなことはプリパラフレンドシップツアーでは絶対になかったことだ。

RGR単独でかなりの満足度があり、愉悦していたところもっちーが看板を取り出して2nd開催の発表をした。その瞬間嬉しすぎて隣の知らない人と軽く抱擁してしまった。頭が真っ白になったままお話に突入。前もって考えていたネタは全て吹き飛んだ。

自分「(震えながらカード受け取る)ありがとうございます。2ndありがとうございます。」
あっちゃん「嬉しい」
自分「絶対に生きます」
あっちゃん「ありがとう(うろ覚え)」
--
自分「2ndライブめちゃくちゃ楽しみです…」
はやまる「ありがとう〜」
自分「(会話続かず、「超えてみせるからー!」が凄いを言う暇がない)絶対行きます」
はやまる「ばいばいー」
--
自分「2ndライブ嬉しすぎて涙が…」
もっちー「おっ大丈夫?」
自分「楽しみです!絶対行きます!」

2019年は2nd中心に物事が動いていたと振り替えれる。この日から2ndに向けて生きる日々が始まった。

林鼓子「ダイヤモンドスマイル」発売記念バースデースペシャルイベント(2019.5.15@秋葉原ゲーマーズ

はやまるの誕生日ということで平日ど真ん中にイベント。この日は「ジャージ」というドレスコードがあり、高校時代のジャージを引っ張り出して向かった。会場内はジャージが多く、すこし異様だが、和やかな雰囲気だったと記憶している。席は最前左寄りでとても恵まれていた。

イベントの総括としては非常に面白かった。はやまるの体力を思い知る瞬間が多かった。歴史の授業のコーナーでははやまるの歴史をクイズ形式で、体育はtiktokでダイヤモンドスマイルの振り付けを、音楽はライブ。WUG、flipside、内田真礼を次々に歌唱し、MC後に「ThankYou Birthday」。完全に予期しておらず刺さる。ここでサプライズでゲマズからケーキ。写真撮影。最後に「ダイヤモンドスマイル」を歌唱した。

その後はお話。お話は例を見ないほど長かった(20秒以上?)けど、雰囲気が良くて自然に言葉がまとまった。

自分「はやまる誕生日おめでとう」
はやまる「わ〜本当にありがとうございます。ジャージも着てもらって…」
自分「はい、久々に着ました…本当にありがとうございます。いつも面白いこと貰ってばっかりで申し訳ないです。」
はやまる「いえいえそんなことないです。こちらこそありがとうございます。」
自分「個人的にThankYou Birthdayが刺さりました。もうなんか文字通りありがとうという感じで…」
はやまる「ありがとう、また来てね〜」

(自然に言葉がまとまったと言いながら、ありがとうございますしか言ってない)上記の内容はだいぶあやふやかもしれない。相手の発言は多分もっと違う。自分の喋りだけではなくて、相手が言っていることに耳を傾けるべきかも。

「ダイヤモンドスマイル」リリース記念『Run Girls! Run!スペシャルフリーイベント in 洗足学園音楽大学』(2019.5.19@洗足学園音楽大学

ターニングポイントだったと思う。フリーイベント(無銭)ということで、誰でも無料で入れるイベントだった。音楽大学だけあってホールは800人規模の上質な音響空間。よく響いた。

開催前日に整理券配布があったが、自分は見逃してしまい参加できなかったらやばいと戦慄する。しかし、当日1300に行っても整理券は余っていて、58番だった。無銭と言いながらも席が上等なのは素晴らしかった。待ち時間はのんびり席に座って待っていた。席は半分以上埋まっていなくて1stが思い返された。当然なのだけど、相当厳しい。

f:id:aikiriao:20200101233321j:plain:w300

イベントが始まる。ライブパート、アフレココーナー、トーク、ライブパート、トーク、ダイヤモンドスマイルといった順番。アフレココーナーでは素人(+音楽大学の学生)が声を当てて演技し、メンバーが感想を述べた。この日はあっちゃんが司会でよく喋った。アフレコでも的確に感想を出していた(例:男役を女性が演じ、クールな松田さんを見れた。例2:舌打ちをマイクに乗せるのが上手い)。

残りのメンバーはいつも通り。はやまるはいつも通りのテンションで、緊張を知らない。どんな時も堂々としている。滑る滑らないに関係なく、自分が楽しそうにしている。これは間違いなく舞台向きだ。もっちーの歌唱力の高さも少し気づき始めている。アフレコで演技力が高いことも確認した。振り付けはあっちゃんやメルテックスターに付いていけている。

最後のトークでのあっちゃんの発言が重かった。

「このホールを、もっと大きい会場を一杯にしたい。その時ここにいるみなさんと会えることを楽しみにしてます。」

この発言により、自分の中で自我が出てきたのかもしれない。会場が埋まらなかった悔しさ、焦り、他コンテンツへの妬みが、自分の中で急速に渦巻き、そんな中で必死に動き続けるRGRをしっかり見ていきたいと感じた。RGRはもっと流行って欲しい。RGRは素晴らしい。自分からしたらパフォーマンス、トーク、演技力を十分に満たしており、もっと上に行けると信じている。

i☆Ris 5th Live Tour 2019 ~FEVER~(2019.5.25@関内ホール

社会見学のため、絶対にiRis単独は見ておくべきだと思っていた。パフォーマンスは当然高い。6人だからこそできるコンビネーションが素晴らしい。一方のソロパートでも各個人の歌唱力が高いことが確認できた。

個人的には若井さんの「my bright」が曲として強かった。全体的には澁谷さんの面白さが印象に残る。言動、煽り、実は高い歌唱力に魅力がある。

曲は「endless notes」除きほとんどアップテンポで、プリパラのイメージ通り楽しい・きらびやかなものになっている。また、プリパラ楽曲の反応が良いことに気付く。iRisとプリパラは切り離せないものであることがよく分かった。

ガーリー・エアフォーススペシャルイベント(2019.5.26@ニューピアホール)

昼公演は私用のため行けず、夜公演のみ参加。会場も300人弱のキャパで小さかったかもしれないが、得るものがたくさんあって楽しかった。

f:id:aikiriao:20200101233409j:plain:w300

朗読劇では完全書き下ろし、かつ面白く仕上がっているし、アドリブもたくさんあった。トークやクイズはアメリカザリガニアメザリ)の方が上手く取りまとめており良い。井澤さんがずっとウケを取る感じ(クイズの時に観客席までいって聞くなど、相当にあざとい)。もっちーは自分から喋ることは無いければ振られた時にばっちり面白いことを言ってて◎。Lynnさんはハイテンションだけど場の空気は破壊しない柔らかさがあった。

ライブパートではまずRGRが出てきてBreak the Blue!!。ステージが横方向に長く、十分に動き回れていた。RGR単独ではないから流石に盛り上がりは小さめ、でも両隣がRGR税だったので助かったし楽しめた。その後はもっちーが捌けてはやまるとあっちゃんで繋ぎのMC。誰が推しか?でははやまるはミンファさん(愛が重いから)、あっちゃんはイーグル(顔がかわいい、スタイルがいい)だった。はやまるは早口でおたくの口調になっていた(ラジオなどでも同様の傾向が見られる)。あっちゃんはリアタイでイーグルをみて元気をだしていたとのこと。あと2ndライブの宣伝もあった。

その後はもっちー、井澤さん、大和田さんでライブ。何とこのイベントのために衣装が用意されていた。基本はRGRと同じで、白黒基調の衣装。井澤さんは長いブーツ(重いとのこと)、もっちーはRGR衣装と同程度。披露した曲は「daisy impulse」と「colorful wing」。要はガーリーエアフォース全て。

終わった後、大きな幸福感に包まれながらゆりかもめ新橋駅ホームでメモを取った。何故楽しいか。1つめはRGRがいるから。これは間違いない。2つめはガーリーエアフォースというコンテンツがあるから。GWは小松に旅した。次点で井澤さんのスタンディングプレイがあざといというのがある。ガーリーエアフォースはアニメが始まる前からOPを聞き、ANIMAX大阪を経て、このイベントに至っており、それなりの思い出が蓄積された。

東京おもちゃショー2019(2019.6.15@東京ビックサイト)

大ステージでのジュエルオーディションステージと、タカラトミーアーツブースでのキラッとこどもステージの2つを見れた。

ジュエルオーディションステージ

直前のファントミラージュのステージで親子が大変多く、社会的な死を覚悟する。

ステージが始まると、開幕「ダイヤモンドスマイル」が打ち込まれた。ハモリがやはり難しいと感じる。打てない空間のためfullが少し長く感じた。その後RGRは捌けて、あぃみぃさんがめがねぇとして、めぐさんが出てきて司会。また、佐々木さんが出てきてプリチャンの概要説明。

りんかちゃん(着ぐるみ)が出てきて、ライブをするということで何かな?と思ったらあっちゃんがKR衣装で出てきて「夢色エナジー」!頭を抱えた。りんかちゃんと一緒に踊っていた。振り付けは完璧で、足上げを軽くこなすあっちゃんにひたすら釘付けになる。続いてTOKIMEKIハートジュエル。振り付けは完璧にできている。

(註:もっちーのソロ歌唱はなし。紫藤めるの新曲はこの時点ではまだ公開されていない。)

その後はキラッツ、佐々木さん、はやまる、プリチャンガールズで「じゃんけんキラッと!プリ☆チャン」。振り付けの指導はめぐさんから頂く。サビからはKRコーデのあっちゃん、もっちー、そして佐々木さんも入る。最後は演者の皆様より挨拶があった。

感想としては、「夢色エナジー」が強かったという印象。この曲はスルメだと感じ、生歌唱を聞きたいというのが小目標となった。

キラッとこどもステージ

こちらも開幕「ダイヤモンドスマイル」。ステージはジュエルオーディションステージよりも小さいけども背景映像が同期して素晴らしく、また歌唱に余裕があった。はやまるがブレスが少なくて辛そうになりながらも笑顔を絶やさないのが素晴らしかった。

その後はもっちーが筐体を試遊。「オンリーマイジュエルコーデ」のふつうを選択。だいあ(佐々木さん)が筐体に合わせてしゃべるのが良かった。はやまるは自由にツッコミを入れ、あっちゃんはりんかちゃんらしくなだめ、もっちーは緊張気味だけど自由に筐体をやる。なんとなく、自分のやるべきことをやれている様に見えた。メンバーの関係性についてあんまり考察したことなかったけど、要観察。

ステージは両方とも30分程度だったけど満足度は高かった。

2019年7月

自分の知る限り、7月はイベントが無かった。今振り返ると、この間は2ndライブや、「Share the light」などの準備を行っていたものと推測する。

Run Girls, Run!」結成2周年記念ライブ 1,2,3ジャンプ!(2019.8.4@SHIBUYA CLUB QUATTRO

灼熱の渋谷で迎えた2周年記念ライブ。自分はこの公演に全てをつぎ込むつもりで、アナログの手紙を出し、初めてフラスタを贈った。フラスタは1stの時みたいに少なかったら嫌だなと思って出していたが、会場を見たらそれなりにあって安心できた。

物販は猛烈な暑さのビル内で待機。発汗はないがひたすらに不快指数が高く、熱中症を覚悟したが倒れるわけにはいかない。会場のフロアに着くと会場特別版のラジオが聞こえてきた。

f:id:aikiriao:20200101233451j:plain:w300

物販を抜けて、極度の緊張に襲われながらも番号順に待機する。番号は300番台と非常に悪く、会場に入ったところほとんど埋まっていた。クラブクアトロは会場左側に巨大な柱がある。昼公演はその柱の左側、つまり左端に立った。

そして昼公演が始まった…が、本当に一瞬で、儚く終わってしまったというのが第一印象だった。あっちゃんか誰かが10分間にしか感じられなかったというのが素直な感想である。

覚えている限りでコメントを入れる。開幕「スライドライト」から勢いよく入って季節曲(「サクラジェラート」、「秋いろツイード」)、次にWUG曲。個人カバーパートではやまるがLiSAの「Rising Hope」をめっちゃ上手く歌い上げる。音程(ピッチ)の安定さと音域の広さが際立ち、ボーカリストとして強いとしか思えない。その後はプリティーパート。「Make it!」、「キラッとスタート」、「プリマドンナメモリアル」。やはり「プリマドンナメモリアル」は好き。もっとコールが充実して欲しい。

ここまで来るともうラストパートで「ダイヤモンドスマイル」。あっさりと終わってしまってアンコールに入る。アンコール後は、「Break the Blue!!」がまず入って、その後に新曲告知と2ndの追加公演の発表があった。その後は演説。あっちゃんが1stツアーが埋まらなくて…とコメントしており、やっぱダメージあったんやなあと。あっちゃんの発言が鋭くなってきている。。。

最後の楽曲は「never-ending!!」で度肝を抜かれた。「never-ending!!」はプリチャン1stシーズン最後のOPで、プリチャンライブで披露することがなく、筐体でも収録されていない曲なので、永久に見ることはできないと思っていた。当然振り付けをみるのは初めてで、ろくにコールを打てなかったが、この曲のタイトルと歌詞に込めた思いは十分に伝わったと感じる。

夜公演も一瞬で終わってしまった。夢なんじゃないかと思うくらい儚い思い出だった。立ち位置は柱を避けて右側。セトリは昼公演とだいたい変わらず、昼のソロカバーパートがデュエットカバーになり、「プリマドンナメモリアル」が「Go!Up!スターダム」になったくらいか。

夜公演は「秋いろツイード」の完成度(歌唱と振り付けの安定度)が昼公演より際立った。他にデュエットコーナーの「Mermaid Festa Vol.2」が直撃する。頭は忘れていたが体が勝手にタオルを回し始め、ラブライブの記憶は体に刻まれていることがわかった。

「Go!Up!スターダム」は1stライブツアーの思い出がよぎり耐えられない。自分は1stの人が埋まらず自由にやれる感触が大好きだった。でもあっちゃんとしては許容できないといっていたし、今日のクアトロは一杯に埋まって400人は来ていた。これからRGRは大きくなることが確実である(そうだよな?)。そう考えるとなんだか、今の状態が儚いという気持ちが強く出てくる。このまま走り抜けてどこまでも遠い所まで行ってしまう気がして、あまりの無常感に堪えきれず渋谷の街を歩きながら1人で涙を零した。2ndライブは今までに無いくらいの用意をした。フラスタは気合を入れてアレンジできなかったけど、ダイヤモンドスマイルの衣装をイメージして出せたし、手紙に思いの丈をきっちり書くことができた。準備をやりきってしまっただけに、終わったときの喪失感がとんでもなく大きい。8月はイベントラッシュが控えていたが、初週にしてテンションが限界になってしまった。

2ndライブを通じて、自分はこの機会に確かなものを掴んでRGRで確信して先に進みたいと感じていた。でも、実際には確かなものなんてなくて、すごい儚いものだった(上手く表現できない)。でもはやまるを始めとしたメンバーの将来が楽しみだから見ることはやめない。

ちゃおフェス2019(2019.8.17@パシフィコ横浜

ジュエルオーディションステージでステージあり。会場1時間くらい前にのんびり並びに行った。おもちゃショーのような親子連れは少なく、伴って社会的ダメージは少なくて済んだ。

内容としては、めぐさんが出てきてすかさず「ダイヤモンドスマイル」。次いでだいあがVTuber形式で出てきて先輩とお話タイム。緊張感があった。そしたらRGRメンバーがKR衣装に着替えて筐体をプレイ。はやまるがデザインパレットを使っていた。1人ずつ生歌唱によるライブ。まずもっちーが「COSMETIC SILHOUETTE」。「スペース!スパイス!スペクタクル!」が来ると思っていただけに驚き、周囲もオーという低音が上がった。次にあっちゃんが「夢色エナジー」。待望の初生歌唱。脚上げの振り付けもほぼ正面から見れた。ゆったりとした余裕があった。次、はやまるが「TOKIMEKIハートジュエル」をにこやかに歌い上げる。最後にめぐさんが振り付け指導して、はやまる歌唱で「じゃんけんキラッと!プリチャン」が入った。こちらもにこやかに、楽しい雰囲気。

感想。「ダイヤモンドスマイル」の歌唱はハモリに揺れがあるけども余裕が出てきている。少なくともAnimeJapanにおける鬼気迫る感じはなかった。「夢色エナジー」を始めとして生歌唱がありがたかった。しかし高温を出すのがとても難しそうに思えた。9月にオータムライブがあるので、さらなる進化に期待。はやまるは振り付けがキビキビしていて、先輩と手を触り合う余裕もあって貫禄を感じた。もっちーはソロだったけど振り付け、歌唱共にレベルが高くなっていたと思う。

この日はその後に国立大ホールにてアイフレ単独ライブがあったが地獄を味わった。アイフレ単独曲は良かったのだが、全てが過去向きになっていることが分かった。曖昧な立場を取るのをやめ、アイカツとの訣別を決定した。(詳しくは書かない)

C3 AFA TOKYO(2019.8.24@幕張メッセ

2019年内でトップクラス。

8:15くらいに会場入りしたが、始発勢なども多くだいぶ後ろに並んだ。(目算、先頭から500人くらい?)整理券が取れないかもしれないと怯えていた。10:10くらいに入場したら整理券列はできておらずノータイムでA066を確保。キンプリのステージ(五十嵐さんが面白かった印象お)などを見ながら時間を潰した。

開場後、自由席となっていた。左側2列目に立ち十分に見れる状態。内容は、30分程度の時間で7曲をぶち込む超高密度イベント。セットリストは

  1. MC
  2. ダイヤモンドスマイル
  3. プリマドンナメモリアル
  4. MC
  5. Break the Blue!!
  6. スライドライト
  7. MC
  8. サクラジェラート
  9. 青春アルゴリズム
  10. カケルxカケル

セットリストが非常に良かった。「Break the Blue!!」、「スライドライト」で盛り上げた後、「サクラジェラート」、「青春アルゴリズム」で落ち着けてからの「カケルxカケル」。最後最大に盛り上がって終了した。

ステージのライトの当て方が素晴らしく、ダイヤモンドスマイルの衣装とメンバーの汗が文字通り輝いていた。当然ぶっ通しだったから後半の「青春アルゴリズム」のロングトーンでブレがあったけど、そんなのは気にならない。RGRはやっぱり若々しい勢いがあり、この勢い一点においては他のコンテンツより上手だと確信した。

終わった後楽しすぎて語彙力のないツイートを繰り返した。このような爽快感のあるイベントが、嘘のない内容が自分にとって非常に助かっている。

プリチャンオータムライブ東京(2019.9.15@舞浜アンフィシアター

オータムライブは自分の中で最大優先度を持ってチケットを確保した。メモをまとめる時間があまりなかったため思ったことを箇条書きで。また、セトリに関しては長くなるので省略。

  • はやまるは振り付けが完璧だった。キレキレ。公演後「キラッとスタート」の脚上げを真似したら脚を痛めた。
  • 他、はやまるは歌唱力、声の太さ(芯)、若くとも堂々としたMC、動いているときの可愛さがトップクラスに仕上がっていた。
  • 「My Secret heArtbeats」が素晴らしかった。間違いなく、プリチャン2019のキャラソンで1番。というかキャラソンの枠で捉えていいのか謎。オタクの好きな要素を散りばめている。
  • 「スペース!スパイス!スペクタクル!」は難しそうに見えた歌唱と振り付けをバッチリやれていた。
  • 「夢色エナジー」の昼公演で歌唱ミスがあった。(あまり不利になることは言いたくない。しかしレポートで嘘はつけない。)サビ入りで、1番で「負けない」が入ってしまい、2番では抜けてしまった。セルフコーラスも厳しく、上手くやりたかっただろうと思うと精神に来るものがある。歌唱中は限界だった(擁護にまわってしまう…)。
  • プリパラの部では、みかん先輩(渡部優衣さん)がサプライズで出てきて優勝した。ガァルマゲドンは強い。ガァルル(真田アサミさん)が振り付けをやりきれているところを見ると勇気づけられる。でじこはまだ現役です。

プリチャンオータムライブ大阪(2019.9.22@オリックス劇場

昼夜ともオリックス劇場の3階席(狭い)になんとか荷物を押し込めて見た。大枠は東京と同一なので詳細は述べない。

  • 金森まりあ(茜屋日さん)がしっかり役を下ろせていて良かった。まりあそのものになっていた。演劇は大事。
  • 全体的にパフォーマンスは安定しているように見えた。見る側も緊張感が抜けていた?
  • 「夢色エナジー」は安心して見れた。昼公演の完成度は高かった。
  • この頃には、自分の周囲の方はプリチャンをメインで推していない状態になっていた。ライブを見ても良かったとは真っ直ぐ言わない状態。また、周囲席の方が歌唱中に地蔵(全く動かない)になることが多かった。辛い。

オータムライブはあっけなく終わってしまった。自分はこの時プリチャン3rdシーズンは無いと見ていたため、これで最後のオータムライブが終わったのかと、無常感が大きく放心していた。

f:id:aikiriao:20200101233536j:plain:w300

また、アイカツが懐古路線に全ツッパしたところを見て嫌悪したアナロジーで、プリチャンライブもプリパラという呪縛に囚われている様に見えた。プリパラもアイカツと同じく、比較的長い時間(3年程度)かけて成功してしまったジャンルだ。人間は一度ロングランするコンテンツに引き込まれてしまうと、戻れなくなってしまうと思う。ノンシュガーやソラミで異常に盛り上がるところを見て、その呪縛が自分の中で認知された。

プリズム!リズム!パラダイス!リリースイベント(2019.9.28@avex本社ビル16F)

リリースイベントがavex本社ビル(表参道)であるのは珍しいらしい。自分にとっては良い社会見学になった。

整理券番号(6番で右寄り)が良くて最前席に座れた。私服で出てきた山下さん、田中さん、大森さんからは良い香りがした(ガチ)。最初にプリパラ120話と123話のオーディオコメンタリーがあった。120話はノンシュガー結成回、123話はノンシュガー漂流記。もう何年も経つが、森脇様の世界が広がるプリパラは面白かった。

その後はテーマトークコーナー。おおまかな印象として田中さんがメインで笑いを取り、山下さんは真面目よりに周り、大森さんはゆったりマイペース。プライベートな内容を排してイベントに関するところでは、オータムライブの裏話があった。「リバース・ザ・リバース」はリハまで田中さんがミスする箇所があった、山下さんと大森さんの振りが合わないときがあった、ノンシュガーの前のソラミは袖で涙なしで見れなかったこと。オータムライブ大阪で山下さん宛のフラスタ(というか動物園)がすごかったこと(確かにあれはすごい)。

最後にじゃんけんでサイン入りジャケットのプレゼントあり。無論自分は負けた。

演者以外で気になったのは、隣の方が公演中にアナログノートに必死にメモを取っていたところ。学生かと思うくらい必死だった。よく見るツイートの解像度の高い表現はこの努力から来ているものかと思い、非常に感心すると同時にレポートを書くべきかという考えが自分の中で浮かんできた。

公演はピッタリ45分で終了。終わってみると安定感のあるトークであった。

キッズカードゲームフェスタ(2019.10.6@海浜幕張イオン)

プリチャンスペシャルステージを見に行った。目的は、佐々木李子さんの「フレンドパスワード」の初披露を見るため。ハコ(開場)が非常に狭く(正方形20-30m程度?、ゲーム筐体も置いてあったからもっと狭い)、キッズスペースも狭くて身動きは取れなかった。プリチャンの前はポケモンガオーレのステージで、若手2人の園児やさんが上手くステージを運ぶ(先輩の扱いが上手い)。プリチャンのステージは11:45から始まった。

めぐさん司会で、まずはVTuberとしてだいあが出てきた。その後はララちゃん(モーリーファンタジー)とだいあちゃんが出てきてじゃんけんキラッと!プリチャン。その後筐体4段の説明があって佐々木さんが出てきた。そして、フレンドパスワードを歌唱。

流石のステージの狭さもあって振り付けはできない。完全にボーカリストとしてパフォーマンスした印象。長さはミドルサイズで、当然1番以降は聞いたことがない。歌唱の後は簡単に振り付け説明をしてから「じゃんけんキラッと!プリチャン」。なんだかんだ30分のステージだった。

確かに佐々木さんの歌唱力は高く、歌唱を見れて嬉しかった。が、視聴環境の悪さ(周りで筐体が稼働している、スピーカ配置、自分の立場所)が祟ったのか迫力というか声量が足りなかった印象。また、歌唱に手一杯だったのか先輩への会釈が足りなかったかもしれない。佐々木さん推しの方は少なからず見えたし、この場で1st単独ライブの開催告知があった。これから化けていくのかは全くわからない。

その後2回目のステージも見に行った。2回目もステージの内容は大差は無いが、「フレンドパスワード」の歌唱に余裕があり、伸びやかさがあった。1回目よりも断然後ろだったけど満足できた。

厚木那奈美バースデーパーティ(2019.10.11@秋葉原ゲーマーズ

題字通りあっちゃんの誕生日イベ。 接近系イベントは久々で楽しめるか不安があったが、始めるとすぐに面白さで一杯になり、他人を気にせず自分がいた。このときのドレスコードは「パーティに相応しい正装」ということでランガTをインナーにスーツを着ていった。会場内は就職説明会の雰囲気となった。

始まったらまずはアンケート用紙に書いた一言と質問を読み上げた(開場前にアンケートが渡されていた)。3人分で読まれることはないが、常連の皆様の文章力は高いことを再確認。その場で明快な文章を書けるのは感心する。

お次はあっちゃんがケーキを作りながら幼少期の写真を振り返り。ケーキ作り自体はあっちゃん自身が買ってきており、一見異様だが落ち着いた雰囲気。マネージャーさんとの掛け合いが面白かった。マネージャーさんの冷徹なツッコミが冴える。

その後はライブパート。プリキュア、?(失念…)、大塚愛、「ThankYou Birthday」。選曲が妙に世代直撃だし(1stの寝逃げでリセットは号泣した)、「ThankYou Birthday」はやっぱり刺さる。パフォーマンス中に笑顔を絶やさない。

最後のお話は10秒程度。話すことは「長野の奇跡」などを受けて長野関連の話題にすることに決めていた。左隣の人がお話前に手が震えていたのが印象的。やっぱり緊張するよな…。

自分「あっちゃん誕生日おめでとうございます」
あっちゃん「ありがとうー、その服ランガTシャツだね(奇襲)」
自分「そうなんすよ(狼狽)透けて見えます?」あっちゃん「うん」
自分「実は長野出身で…◯信出身なんですけど、あっちゃんは長野県の誇りです」
あっちゃん「ありがとう、長野の、長野代表になれるように頑張るね」
自分「頑張ってください、ありがとうございましたー」

あっちゃん実際に会うと顔の小ささに驚く。

f:id:aikiriao:20200101233852j:plain:w300

総括としてはやっぱり楽しかった。これくらいのイベントが2週間に1回は欲しい気分。奇襲(向こうからの話しかけ)はアドリブ力が試される。今思えば(無理だけど)、どこにでも着ていきますくらいの気概表明ができれば…と思うところ。

(イベント中止)Super☆Premium Vol.8(2019.10.12@ダイヤモンドホール

台風の影響で中止。この公演で「Share the light」が初披露される…はずだったと思われる。本当であれば、あっちゃん誕生日イベの後に名古屋に行く予定ではあった。

仙台アニメフェス(2019.10.19@夢メッセみやぎ

アニメフェスのRe:creationというイベントでRGRが出てくることを受けて参加。

夢メッセみやぎ仙石線中野栄駅から徒歩15分の会場。当日は雨が降っており寒かった。メインMCが永野さんだったり、高木さんがDJで出たりと、WUG色が強いイベントであることは間違いなかった。「Share the light」のポスターを回収しにゲーマーズブースに立ち寄ったら、DJシーザーさんが「16歳のアガペー」を流していた。

RGRのステージが始まるまでに時間があったので、それまでは他のステージを見て過ごした。開会式を回す永野さんを見てから、メインステージへ移動。ガルパン最終章OPや、真赤な誓い、そしてIAさんを初めて見た。IAさんのモデル完成度は非常に高かった。「六兆年と一夜物語」等自分でも分かる強い曲があり、次にストリート系ダンサーと合わせる演出があった。ミクさんとは明確に異なる方向に尖っていた。その後はLiaさん。「一番の宝物」などを聞く。歌唱力はやはり高い。その頃にRGRのステージの待機列に入るために途中で抜けた。いよいよRe:creationが始まる。

開始前はリハーサルを見ることができたが、RGRは非公開だった。はやまるやもっちーが声の返しについて何かコメントしていたと思われる。「カケルxカケル」でステージが見えない待機列の中、RGRファン勢でサビ入りのクラップを入れていた。「Share the light」や「キラリスト・ジュエリスト」の初生歌唱も待機列で聞くこととなった。

ステージが始まる。最初はDJから入った。WUGの曲多めだがやはりついていけない。あとはVの者(VTuber)のライブは曲は強いものの、モデルの躍動感がまったくない。ミクさんレベルまで踊れればおそらく対抗できるものと考える。

待望のRGR。目に飛び込んできた衣装がとんでもなく扇情的。上半身のラインがはっきり出て、下半身はパンツスタイルだから、目のやりように非常に困る。

「Share the light」は何度か聞いていたが田中さんの癖が非常に強く、コールが安定しない。パフォーマンスは超アグレッシブ。序盤のソロパートははやまるは安定して聞けるのはもちろん、続くあっちゃんのソロが声が細いところを含め素晴らしい。次は「ダイヤモンドスマイル」。2019年を振り返ってみると「ダイヤモンドスマイル」に尽きると感じることが多い。2番に入ったところで前に出てきて至近距離でメンバーを見れた。次は「キラリスト・ジュエリスト」。初披露ということもありやはりコール薄め。でも、リズミカルな調に合わせて『ダイヤモンド・ジュエリスト キラッキラのファイナリスト』のところではやまるが完全笑顔で振り付けしていたのが印象的。もっちーはボーカルをよくこなしていた。

MCが入って2nd追加公演の告知と、プリチャンの声を当てていることを説明。そして「タチアガレ!」が打ち込まれた。沈む方がちらほら。最後はすかさず「カケルxカケル」。「カケルxカケル」は2nd東京公演のあたりから思い出が山積してしんみりするようになってきていた。仙台GIGSから約1年。なかなかに進んでこれている印象を受ける。最後のヒキではやまるがステージに投げキッスをしていた。

RGRステージ後に印象に残っているのはPileさんか。ラブライブ!楽曲一切なしのオリジナルで確実に観客を盛り上げていた。その実力は確かだし、やっぱりラブライブ!にはオーラがあったのだ。Pileさんのファンは少なからずいた。Pileさんはライブは久々と言っていたけど、拳が入ったり、マイクパフォーマンスが上手く、アップテンポな曲が多いこともあり、観客は自然と盛り上がっていった。

イベントが終わった後は、1年前の1st仙台と同じく、仙台に来てよかったという気持ちで一杯になった。プリチャンを回して、牛タンを食べて充実したイベント行楽となった。

ANIMAX MUSIX KOBE(2019.10.26@ワールド記念ホール

今回はRGRファンのためのシートはなく、完全ソロ参戦でスタンド席に立った。ランガちゃんかわいいと発言する人が多数見受けられた。

f:id:aikiriao:20200101233823j:plain:w300

RGRは「Share the light」のfullから「キラリスト・ジュエリスト」short、その後に自己紹介を入れて「ダイヤモンドスマイル」shortを歌唱しながらトロッコでバックステージに移動した。

遠くから見ても「キラリスト・ジュエリスト」の跳ねる振り付けは楽しそうに見える。「Share the light」の冒頭ソロのあっちゃんパートがよく決まっていた(ボーカルがしっかり拾えていた)。また、はやまるはハイテンションでいっつも楽しそう。最後の全体曲でも常にタオル振ってるし、エンディングの一言挨拶のところでRASの人が挨拶する時にぴょんぴょんしてるからおそらくリスペクトしてるのかと。自分ははやまるだけ見ていることが分かった。

RGRのダンスパフォーマンスは見た中でダントツ、というか他の人は振り付けすらあまりしてなかった。そんな中ではやまるが高歌唱するから、当然強いユニットだという結論に至る。後は強い曲が降ってくれば良い。

RGR以外で印象に残ったのはやはりRAS(RAISE A SUIREN)だろう。始まる前からRASは強いというのは聞き及んでおり予習した。RASはRGRの直後に現れ、始まるとヘドバンが止まらず、会場はこの日最大級の盛り上がりに満ちた。

駒澤大学でのトークイベント(2019.11.2@駒澤大学1号館4階)

広めの講堂で開催。キャパは200人程度で、埋まったのは7割程度?最前を確保し、入場時から緊張感があった。個人としてはオールナイトニッポンi公録の様に笑い過ぎで引かれないように努力した。笑いすぎてもオーバーにならないように気をつけて目線を配った。

結論から言うと楽しすぎた。まず尺が1時間30分ほどあってボリューム大。至近距離で表情までよく見えるし、エチュード(演劇)コーナーではまずオラオラ系演じるあっちゃんが言葉を崩し、足を組んでビシッと演技しており非常に強く、その後厨二病演じるもっちーに「お前、ピンクのTシャツ着てるな?ピンクの世界から来たのか?」と弄ってもらった。この体験は初めてであり、正直クッソ嬉しかった。エチュードコーナーでは一番良かったメンバーに拍手で投票するがもっちーに1票。順番が逆だったらあっちゃんだった。はやまるは安定していた。最後の「メイド喫茶で働いているところが生徒会長にバレる」では不思議系の演技がよく吹っ飛んでいた。『生徒会長もメイドになりたいんですね』はハマっていた。アドリブでできるのがすごい。

他、会場が沸いていたポイントを思い出す限り挙げる。

  • 通勤時に聞きたい音楽は?
    • 「キラッとスタート」で全員揃う。「カケルxカケル」もありだとあっちゃんコメント。それ。
  • もっちーが幼稚園時代に演じた野菜は?
    • トマト姫が回答。はやまるあっちゃんそれぞれトマト、ミニトマトで正解。よく当たったなあと思う。
  • たけのこの里きのこの山どっち?
  • 序盤ではやまるが『そうなんだ』とコメント。会場沸く。『そうなんだ』回収ははやまるも理解している。
  • GMS学部は何の略称か?
    • もっちーはグローバルモッチースペシャル。
    • 某芹澤さんはグローバルモイスチャーシャンプー。

この日はもっちーに感謝していた。演技力はやっぱある。あんまり喋ることはないが、的確なツッコミとトーク回しができている。元からそうだったかもしれないけども磨きがかかり、年始の海老名と違って観客もそれに乗れてきている印象を受ける。メンバー全員進化している。ファンも確かに増えてきている。

Share the lightリリースイベント(2019.11.16@秋葉原

リリースイベントは約半年ぶりとなっていた。

秋葉原ゲーマーズ

接近は久しぶりな気がして異様に緊張していた。3列目あたりに着席して会場はほぼ満席。開始前はドハマリしていた「スノウ・グライダー」のフルコーラスを聞くことができた。序盤のトークはアルバムの楽曲と2ndライブについて。はやまるがあっちゃんにツインテ編んでもらってあざとい。トークは10分程度で短くまとめて、すぐにお話に入った。

もっちー「こんもちはーわあーそのTシャツ下に着てるの?(奇襲)」
自分「(カード受け取り前チャックを下ろして)そうなんすよ(狼狽)」
自分「今更なんですけどらんがばんのもっちーめちゃくちゃ面白かったです、また期待してます」
もっちー「ありがとーばいばいー」
--
はやまる「こんにちは〜お久しぶり」
自分「やっべ話すこと忘れちゃいました」
自分「(間)そうだスノウ・グライダーめちゃくちゃ強い!神!」
はやまる「それ」
--
あっちゃん「ありがとうございます」
自分「Share the lightの衣装、めっちゃ、シックで、良い!」
あっちゃん「ありがとうございます」
自分「またライブで見れるのを楽しみにしてます」
あっちゃん「またー」

お話は10秒未満?言いたいことぶっ込んだら終わってしまった。また焦りもあり、カンペを読み込んでいたのだが、はやまるの前に立った瞬間全てが吹き飛んでしまった。。。

ソフマップ①号館

整理券番号5番で右前に座る。こちらも10分程度のトークからお話10秒。

10分トークでは曲の強さについて。キラリスト間奏の重低音が広川さんサウンド。4拍子が2拍子に切り替わってダンス教師が拍とれないとキレる。プリティー田中さんはスヌーピーが好きではやまるは可愛く見えてきたとのこと。

お話はゲーマーズのときよりは緊張はなかった。

自分「(受け取り)ありがとうございます。来週の京都公演死ぬほど楽しみっす」
あっちゃん「そうだよね〜来週!」
自分「緊張しますけど楽しみにしてます」
あっちゃん「またね〜」
--
自分「(受け取り)ありがとうございますー」
自分「ツインテールめちゃくちゃ可愛いっすね…さっき言い忘れちゃったんですけど」
はやまる「ありがとう〜あっちゃんがやってくれたんだよ〜」
自分「くるくるであざといです、また」
--
自分「(受け取り)ありがとうございます〜。来週京都行くんですけど、何かおすすめのラーメンあります?」
もっちー「うーん(考える)、こってりかな」
自分「こってり、了解、また!」

あっちゃんの満面の笑顔、はやまるにお気持ち表明、森しまさんに質問できたので満足。

Run Girls, Run! 2nd Anniversary LIVE 1.2.3ジャンプ!!! 追加公演(2019.11.24@京都FANJ

この日がとても楽しみだった。ここまでイベントに参加したことはなかったし、きっと2ndライブも最高のものになると予感していた。

深夜バスで現地に入った後、まずは験を担ぐために芸能の神様が居る車折神社に向かった。

f:id:aikiriao:20200101233938j:plain:w300

それからのんびりと現地へ。よく晴れていた。京都FANJ国際会館駅から徒歩15分と結構離れた場所にあった。周囲にコンビニがあって助かった。

f:id:aikiriao:20200101234003j:plain:w300

11時に物販スタート。物販あとは近所の「とんかついなみ」で昼食。ソースがうまかった。その後京都駅に戻って荷物整理していたら余裕がなくなった。13:45に現地についてそのまま昼公演に突入した。昼はオールスタンディング席で後ろ寄りに立った。(会場前が指定席、後ろでスタンディング。キャパは300人くらい?)

セトリの概略は、「スライドライド」、季節曲、WUGパート、カバー、プリティー、「Share the light」、アンコール、「never-ending!!」と「Break the blue!!」(昼は「Break the blue!!」がトリ。夜はその逆。どこかで言っていた両A面を活かした作り。)

昼公演は、心の底から楽しみきることができなかった。確かにはやまるは高歌唱力だった。激しい振り付けもあって最終盤は満身創痍だった(汗はダラダラ、ロングトーンが途切れたり)と思う。あっちゃんは歌唱振り付けともに良かった。一方もっちーのボーカルがハウることが多く、ボリュームを下げられていた。隣の方の反応(盛り上がる曲は動きまくるが、そうでない曲は地蔵化する)を気にしすぎたのか、マイクがハウることが多かったのか、満足することができなかった。終わった後の汗がない。C3AFAで流した汗はどこに行ったのか。この瞬間、この日限りでの引退を覚悟した。

頭は疲労のためか動かず、国際会館駅内のトイレに座り込んで苦悶した。このままでは、よく分からないままに終わってしまう。どうすれば楽しめるのか、自分はランガちゃんの何が好きなのかもう一度考えた。それは、2018年から何度も見ている高いパフォーマンスの筈だ。振りを真似することに頑張りすぎていないか、もっと自然体でコールを打てないか。力まず真っ直ぐ推しを見ようと思い、リポビタンDを入れて集中して夜公演に向かった。

f:id:aikiriao:20200101234029j:plain:w300

夜公演は、開場予定時刻17:30のところを17:57に開場した。17:45には会場外からリハ入れしているところが見え、何かの異常事態を察した。1st仙台の夜公演でもっちーの声が逝ってしまった時並の危機感を覚えつつ、公演が始まった。

一転最高のライブに化けた。夜公演では音響が改善し、ハウリングが一切なくなった。リハは音響調整のために行ったと思われる。また席も良かった。指定だが隣の席が空いており、1stよろしく周りをあまり気にしないで打てた。しかもメンバーがよく見える。こうなれば後はC3AFAの2時間版。

推しを見ていると、やはり進歩している。最初から持っていた技能に+αついたように見える。はやまるの歌唱力は何度も言っているが高い。ボーカルの音圧、ベースラインの太さ、ピッチ上下どれをとっても安定していて頼もしいリードボーカルだし、ソロパートは安心して見れる。MCで「Share the light」の販促で怯えて震えるのが可愛かった。あっちゃんの振り付け、特に「キラリスト・ジュエリスト」や「ダイヤモンドスマイル」はパワフル。他のメンバーに比べて大きい体と長い髪がダイナミックに揺れる様は迫力がある。また、MCや喋りの攻撃力が上がっている。『この日のために練習してきました』や、らんがばんではやまるに言われた『長野の奇跡』を自分で言ったりと。もっちーは歌唱力とかわいさ演技が板についてきている。

夜公演終了後はもっちーのこってりを受けて、天下一品総本店を満喫。次の日も京都水族館に行くなどして京都を存分に楽しみ。帰宅。この際にレポートを残さなければならないという気持ちに駆られ、本稿を執筆し始めた。

2nd京都において、自分が思った通りに打つことが大事ということに思い至った。厄介がいようが、周りが名文を書こうが、どうあがいたって楽しむのは自分。周囲の反応を気にするのはダメで、推しの一挙一動に集中して、自分の心行くように打たなければ何も楽しめないということがよく分かった。

「カーテンコールを揺らして」リリースイベント(2019.11.30, 12.1@秋葉原

フリー入場ができると知って安易に入場したのが運の尽きだったかもしれない。とらのあなCにおいて、2nd単独ライブが半分も埋まっていないと涙ながらに告げられ安易にも限界になってしまった。その場でCDを購入した。握手して、だいあちゃん凄いなと思ってたら歌唱力高くて驚きました、1/13の2nd単独絶対行きますと話した。佐々木さんはありがとうと言うくらいだった。

次の日の秋葉原ゲーマーズでのリリイベでは泣くことはなく、安心していたらボーカルに引き込まれる。特に「freedom」。本人が降ろす曲と言っていたように、完全に別人になって歌唱していた。握手においては何きっかけですか?と聞かれてプリチャンです。と回答。

キッズカードゲームフェスタの時点では何も感じていなかったが、この2日を通じて一気に見方が変わり、解像度が上がった。

声優業界において無銭イベントは注意しなければならない。。。

京プレミアムライブ2019(2019.12.7@京都ロームシアター)

座席が非常に良く(2列目)演者がよく見えた。今見返してみると良い席のイベントは軒並み良評価で感想が長くなる。このイベントも例に漏れず非常に良かった。

2nd京都の前辺りから、Youtubeの宣伝動画を見て「スノウ・グライダー」が2019年最大楽曲であることを認識した。RGRにしては珍しい悲恋をド直球に出した歌詞。『もういいの』は突き刺さる。石濱さんの何度聞いても飽きない素晴らしいインスト。そして悲しさを全面に出したボーカルと振り付け。この曲でRGRが一人歩きし始めた印象がある。

f:id:aikiriao:20200101234111j:plain:w300

内容はANIMAXと同じくライブフェスで、多くのアニソンシンガーが登場。RGRは中盤あたりで出現。セトリは、「Share the light」、「スノウ・グライダー」、「キラリスト・ジュエリスト」、「Break the Blue!!」。

「Share the light」はよく成熟してきた印象があり、笑顔で振り付ける余裕が見られた。「スノウ・グライダー」は予見できなかった。このイベントはアニソン中心で固めているから、アニメ主題歌になっていないこの曲が歌唱される訳がないはず、かつシリアス故フェスに似つかわしくない選曲のはずである。2nd京都でしっかりと振り付けを見れなかったことを強く後悔していた。だから、会場でイントロがかかった瞬間、非常に強い衝撃を受けた。次の瞬間に足の力が抜けてしまい、偶然隣に立っていたランナーさんと同時にその場で崩れ落ちた。しばらく立つことができず、Aメロの途中から辛うじて白を点灯して必死に打った。2番は泣いていた。「キラリスト・ジュエリスト」で楽しげに振り付けるの当然として、はやまるとよく目があった…(隣の方はもっちーに手を振ってもらったりと大盤振る舞い)。

「キラリスト・ジュエリスト」の後にMC。自己紹介では興奮しすぎてしまって大声を出しまくる。もっちーに対しては隣の方がかわいいよを言いまくる、はやまるに対しては自分がオマエガイチバン!!を連呼、最後のあっちゃんは長野の奇跡ィ!を隣の方と絶叫。はやまるは京都は修学旅行以来と発言、もっちーは京都生まれだけど人力車初めて乗った、ごきげんようって感じだったとあっちゃん。そして次が最後ですと言われて心からエーッ!!イマキタバッカリー!!が出た。

最後のフォーメーションはもっちーが前に出た瞬間に隣のランナーさんと「Break the Blue!!」だと察した。その瞬間は意外な選曲だなと思ったが、簡単に振り返ると2nd京都昼公演の締めも「Break the Blue!!」だった。「Break the Blue!!」はランナーさん以外の方もノれていたように見受けられた。I'veの恩恵?

RGRの楽曲を聞くと体が全自動で動くし、終わると汗だくになる。間違いなくその日見たアーティストの中で一番だったと言わせて欲しい。カンペ一切見ずに、観客にパフォーマンスできていたのはRGRだと思う。

RGR以外で良かったのは、KOTOKOさんは当然として、スピラ・スピカだろう。MCがガッツリ奈良弁で独自のペースに引き込まれる。是非ともCDを確認したい(当日販売分を確認したら完売していた)。また、machicoさんのシリアス曲(失念…)も引き込まれた。全く知らない状態からスゲエとなるのは実力の証であると考える。

Share the lightリリースイベント(2019.12.8@ハートンホテル京都)

整理券は秋口のプリチャンオータムライブ時に大阪で回収していた。全てハートンホテル京都の1回の部屋で開催されており、いずれの回も先着順で席に入った。2回とも最前になった。。。がっつき過ぎかも。

f:id:aikiriao:20200101234135j:plain:w300

1回目

あっちゃんとはやまるの前あたりを確保。トークパートで印象に残ったのは人力車の話題。あっちゃんは(失礼だと思っていますが)下々の者を見下す感じで…や、乗る時に安全装置が必要か聞いていたという点。他には、京プレミアムライブの控室でのスイーツの話題。もっちー初抹茶おめでとう(あっちゃん:あれは座敷ではない、椅子がある)、もっちーは抹茶は寿司っぽいということ(はやまる:それは緑茶だよね)、クレープの具材がほとんどなくなってしまってクリームだけのクレープを食べていたことを面白く濃く語っていた。

お話。京プレミアムライブ良かったですを言おうと決めていた。

自分「(タオル落とす)」
あっちゃん「大丈夫ですか〜慌てないで」
自分「あっちゃんのソロパート、特にもういいのがめちゃくちゃ良いっす」
あっちゃん「それね!」
--
自分「キラリストのサビ後の振り付けめちゃくちゃ…」
はやまる「うーんこれ?(実演クネクネ)」
自分「それですそれ、ほんと可愛いですありがとうございます」
--
自分「今年の目標無敵だったと思うんですけどどうでした」
もっちー「いけたよ〜(うろ覚え)」
自分「自分の中ではもう無敵でしたよ、ありがとうございます」

2回目

もっちーの前あたりを確保。2回目はトークの他に質問タイムがあった。トークパートで面白かったのははやまるの高速指差し。右手人差し指をビシッと上げる所作(掛け声があったけど忘れた…)。あっちゃんも揃えてやってて面白かった。他には京都は体に優しい食べ物が多いよねとはやまる。そしたらもっちーがラーメンが美味いと答え、えっそれは…という感じになるが、ラーメンといったらなんだっけ…で天一という話題が挙がる。他にも京都発の店舗は餃子の王将があるとも触れていた。質問タイム(挙手制。ビビって手を挙げられず)では以下の質問が出ていた:

  • もっちーのブログに夜3時まで起きていたとあったけど何してたの?
    • シャイニングを見てた。はやまるは開始40分で寝てしまった。itとかも興味があってペニちゃん(ペニーワイズ)を隙間で見出している事が多いとのこと。
  • 今年の残りは何したいか?
    • ディズニークリスマスに生きたい。ハロウィンは予定合わなかった。(あっちゃんは言っておりそればっかり話していたらしい)
  • 声優志望です。言葉に詰まらず喋るには?
    • 自分たちも上手くない。先輩に聞くべきでは?
    • もっちー「逆に詰まることをポジティブに考えては?」拍手。
  • みらい、りんか、める3人の曲を聞ける機会はあるか?
    • 「Brand New Girls」は可愛いけどRGRの曲じゃなくてキャラクターソングだから厳しい…。
    • はやまる「ミラクルスターで歌う機会があればまた歌いたい」

お話はすんなりできた。

自分「(受け取り)ありがとうございますー、スノウ・グライダーの振り付けは凄いですけど、歌詞もめっちゃ刺さりますね…」
あっちゃん「そうだよね泣けちゃうよね(手で涙を表現)」
自分「感情移入しちゃいました…また聞きt(剥がし)」自分「またー」
--
自分「昨日のライブとても良かったです。来週の幕張!」
はやまる「おっ!」
自分「楽しみです」
はやまる「楽しみ〜(反応を忘れた。テンションが高かったのは覚えている)」
--
自分「京都すごい楽しかったです。ご飯は美味しいし景色はきれい…」
もっちー「ほんと?よかった、またやりたいよね」
自分「確かに!また行きたい!また!」

メンバー全員とまた!ときれいに引けたのが良かった。

渋谷クロスFM公開収録(2019.12.9@渋谷クロスFM

佐々木さんが路上ライブもしている中で、ラジオ収録があると聞いて見に行った。16:30くらいに現地につくと既に前番組の方が公録をこなしていた。結構そういうラジオなのか?

17:00開始10分前になるとブースに佐々木さんが入り、アコギでリハーサル。佐々木さんは小さい(失礼)のだけど、自分の意志で動いているような心の大きさを感じる。これを演技で出せているとしたら大物だと思っていたら公演が始まった。

トークは音量が小さくてスピーカー前にいたけどあまり聞こえず。最初の5分はトークで、その後にアコギライブ開始。歌唱はよく聞こえた。ワンコーラスがほとんどだけど、弾き語りといった感じでテンポが良い。トークでは先日の盛岡リリイベについて等。盛岡では冷麺(あいまい)を食したが量が多かったとの事。気付いたら30分が経過して公録は終わった。

その後はチケットの手売り。知り合いの方向けに1枚買った。チケット購入時に軽くお話。佐々木さんの近くにはリリイベの時にもいたマネージャーさん?がいた。

自分「今日はありがとうございました。」
佐々木さん「ありがとうございます。寒くなかった?」
自分「いえいえライブで温まりました…友人連れていきます。」
佐々木さん「その格好だと暖かそうだよね」
佐々木さん「何で知りました?」
自分「プリチャンです…ありきたりですけど」
佐々木さん「あー」
自分「(お釣りとチケットを受け取り)ありがとうございます。」
自分「今週末の幕張楽しみです。良いお年を!」
佐々木さん「良いお年を!」

良いお年を!とは言ったけど、その後佐々木さんは(主だったところでは秋葉原で)路上ライブを頻繁に行っていた。告知が当日に出るので、それに気付いて行っても間に合うことはなかった。一度人が集まりすぎて警察に止められたらしい。

自分としては、佐々木さんは既に相当の実力があると思っている。だから必死に売り込まなくても自然とファンは増えるんじゃないかとかなりの楽観を見ている。しかし、状況が許さないのか営業を必死に行っているように見受けられる。

プリチャンウィンターライブ2019(2019.12.15@幕張メッセ

ターニングポイント。

久保田さんがいない中でどうすんのか。期待ができない状態で突入したウィンターライブ。(ライブ当日にえも&あんなで新曲が出ていたのでこれは久保田さん来るなと錯乱していた)しかも、自分としてはプリチャンは3期はありえないと踏んでいたため(これ以上広げる伏線が無いように思えた)、ここで新作についての告知がない(つまり、プリチャンが終わる)場合は、RGR含め全て引退するつもりでいた。

プリチャンは総合芸術で、アニメ、楽曲、筐体、ライブ、中の人、同人があって初めて素晴らしいものになっていると思う。プリチャンがあったからこそRGRを見つけられたのであって、プリチャン無しではRGRを推せる未来が想像できない。

蓋を開けてみるとプリパラ名曲とプリチャンの強い曲にタコ殴りにされ続けた。ここまでのプリパラとプリチャンのチカラを結集していたのは間違いないため、セトリの順番で31曲を振り返ってみる。昼はスタンド中央あたりで全体を俯瞰する感じ、夜はフロアでトロッコを間近に見るて驚くことが多い。

楽曲 感想
キラリスト・ジュエリスト RGR新衣装のフル公開。アニマ神戸で着ていたけど上半身までちゃんと着ていたのは多分ここが初めて。遠目に見ても良い。振り付けももちろん。昼でははやまるの歌唱に少しブレあり。
Go! Up! スターダム! / ダイヤモンドスマイル 「Go! Up! スターダム!」は虚を突かれた。周りのランナーさんと声出し。「ダイヤモンドスマイル」は、自分の中で今年のテーマソングになっている。振り付けもらんがばんを通じて少しだけ追えるようになった。
開始演出
トンでもSUMMER ADVENTURE 開幕意表を突かれた。この真冬に初っ端夏。が、『は〜い』には反応できた。
ハートフル♡ドリーム MYDREAMではこの曲が一番楽しい。昼夜やってもらって感謝。パンご飯麺類と言いながら、謎の拍で指差す所作が好き。真似する。
かりすま〜とGIRL☆Year! / スパイシー♪ホット*ケーキ!!! 久々のパワフル無敵。TRIANGLE版も見たい(不可能)。2016ウィンターを忘れることができない。
ぷりっとぱ〜ふぇくと / TRIal HEART 〜恋の違反チケット〜 ぷりっとぱ〜ふぇくと(full!!)は大号泣。プリパラをさめざめと思い出す。一生聞けないと思っていた。
Brand New Dreamer / ぱぴぷぺ☆POLICE! 「Brand New Dreamer」はのんらぁらで歌ったのを初めてみたかも。開幕田中さんが腕組んで不服を表明していたのが良かった。曲自体も好き。「ぱぴぷぺ☆POLICE!」の楽しさは異常。これも2016ウィンターを思い出す…。
MC だいあが会場内の様子を映しながら場を繋ぐ。
ワン・ツー・スィーツ / TOKIMEKIハート・ジュエル 「ワン・ツー・スィーツ」は「レディー・アクション!」に並ぶプリチャンの原風景。みらいちゃんとしてのはやまるはここにある。
キラリ覚醒☆リインカーネーション / 夢色エナジー 脚上げ確認ヨシ!リップシンクだったのかな…
乙女アテンションプリーズ / SUPER CUTIE SUPER GIRL 開始直後久保田さんを懸命に探した。いない!トロッコ演出だ。ロケットハートをください。はやまるはメインステージに移動。
じゃんけんキラッと!プリ☆チャン 振り付けを思い出しながら。fullを聞いたのは初?にこやかな振り付けがとても良い。
嘘つきはTomorrowの始まり / 純(ピュ)・アモーレ・愛 昼公演で「純(ピュ)・アモーレ・愛」を聞いていないことを思い出す。ほしいなと思ったら夜公演できた。
コノウタトマレイヒ プリパラの様式美。佐藤さんの間奏演技も映える。Mon chou chouを聞きたい。。。
君100%人生 終わった後トロッコが中央で止まり、MCが入る。
Burn! Cosmic Liberty 完全新曲。たまげた。サビの転調が異常。プリチャンのデザイナーズ10で北条コスモさん間違いないなと思った。(後で違うことが分かった)
MC
Play Sound☆ 強い。圧がある。後述のLa La Meltic StArと似たVFX
シアワ星かわいい賛歌 イントロと間奏で可愛い演説があったけど覚えてない…。(後のMCでもすずちゃんに会いに行くとか言ってた。完全に降ろしてる。)
スペース!スパイス!スペクタクル! もっちーの振り付け◎。腿上げ凄い良かった。ステージ駆け回り含めて良い。
My Secret heArtbeats プリチャンキャラソン全一。振り付けが大好き。Middle Ver.なのが心残り。
ヒロインズドラマ ボーカル絶対難しいだろと思っていたが芹澤さんはすんなり歌い上げた。ライブ後に筐体等で聞いてみるとスルメ。
MC ここでプリチャン3期の告知。崩れ落ちていたら、ガァルマゲドンの高笑いが会場にこだまし、精神異常に至る。
アメイジング・キャッスル 泣いていて見れず。昼は左サイドに渡部さんがダイナミックに振り付けていた。夜はフロアで真田さんをしっかり見れた。
シュガーレス✕フレンド
Believe My DREAM! タイムを見た上では涙なしに見れない。MYDREAMのさらなる新曲が欲しい。
CHANGE! MY WORLD / Get Over Dress-code ドレシ楽曲の2トップがピンポイントで刺さる。「Get Over Dress-code」は号泣。山北さんの振り付けが完璧で映える。バックステージというのもドレシらしくて良かった。
Miss.プリオネア / メイクマニー・メイクドリーム 今年度前半を強く印象づけた舞浜アンフィシアターが思い出される。トロッコが中央で止まったところでしゅうか様新曲かとおもい限界になった(新曲はなかった)。
リンリン♪がぁらふぁらんど 複雑すぎて頭が壊れた。ファララ(佐藤さん)に合わせた。
だいあちゃんのアニメカット
フレンドパスワード 緊張気味だった?けどやっぱ上手い。最終盤で大きめの振り付けあり。(最初から徐々に動くのはキャラに合わせている?)
寝ても覚めてもDREAMIN' GIRL / COMETIC SILHOUETTE トリを務めるのはメルィックスター。登場時シルエットが映る演出が非常に格好良かった。「COMETIC SILHOUETTE」は何度も聞いているとどんどんのめり込んでいった。2018年代表曲なのかもしれない。
La La Meltic StAr プリチャン史上最大楽曲になりつつある。ゆったりとした入りからサビに向かってタメ、サビで一気に爆発する。歌詞ハメ最大。本当に大好き。先輩が仰っていたが、ボーカルが楽器になっている。
Make it! 定例の締め曲。プリパラ1stシーズンを思い出す度に熱いものを感じる。
Crew-Sing! Friend-Ship♡ 意外だった。この曲はプリズムリズムパラダイスのテーマソングであってプリチャン合同でやるとは思っていなかった。でも締まる。

2時間弱の公演で31曲なのだから超高密度で、ほとんど遊びがなかったとも言える。メインステージ、バックステージ、トロッコを間断なく使うので休みがなかった。

昼公演でプリチャン3期が告知され、安心のあまり泣き崩れた。ほんと。終わってみると安心感で満ち、『勝った』という感情が渦巻いた。何に勝ったのか。それは過去に向かったコンテンツにである。もう一年RGRを心置きなく推せる喜びを噛み締めた。

TVアニメ「ネコぱら」第1話・第2話☆クリスマスイヴ先行上映(2019.12.24@TOHOシネマ上野)

2019年最後の現地は先行上映会となった。もっちーが???役を演じるとのことで出席。上映は2回あり、それぞれ1話2話を見てから、キャストのみなさんが出てきてトークする形式。1話は既に海外でも上映したようだが、日本では初公開だったらしい。

f:id:aikiriao:20200101234207j:plain:w300

ネコぱらは完全にのんびりとしたアニメ。何も考えず見れるのを期待している。もっちー役の???はまだ台詞が僅少でどうなるかは判断しかねる。

その後キャストの3人(八木さん、佐伯さん、もっちー)が猫耳を着けて出てくる。もっちー可愛い。トークではavexの大橋さんが淀みなく司会進行。もっちーは無難なコメントを出しつつ、収録現場では優しい言葉をかけてもらったとコメント。大橋さんがほんとですかとチェックしていた。佐伯さんがかわいいよ等コメントをしたらしい。

2回目のトークで、やっと八木さんと佐伯さんの顔と名前が一致してくる。ショコラ(CV.八木さん)はまともにまとめる。バニラ(CV.佐伯さん)が限界語を散りばめるので会場が沸く。ショコラとバニラは中の人と性格が逆。佐伯さんが面白くした後にもっちーのコメント。収録現場では、もっちー伊藤美来さんに隣のマイクに案内してもらったことをコメント。これから成長していく???ちゃんを見てくださいや、???ちゃん以外の呼称がほしいとコメント。

avex picturesが出している作品でもそれなりにアウェー感があった。もっちーはまだ展開などコメントしづらい部分もあるのか、堅めだったかも。もっちーの収録現場のコメントから判断するに、まだRGRメンバーは若手になるのかと実感。

2020年

SynapstoRy~完璧になりたいピノキオ~(2020.1.4@秋葉原CLUB GOODMAN

新年一発目は佐々木さんのイベントとなった。CLUB GOODMAN秋葉原の青島食堂に向かう途中…と言えば分かる?キャパは高々80人で、用意された椅子に自由に座る。自分は申込みが遅く番号が悪かった(昼58、夜61)ため、無理せず後ろに座ってのんびり見た。

演劇ではあるが、半分朗読劇、半分ライブと言った感じ。ライブだけでなく、演劇中のBGMもキーボードとベースの生演奏があり良い。曲が入ると、サイリウム持参の方々が軽くコールを入れていた。昼夜でエンディングの内容が変わっていた。

感想。開幕人形チックに歌唱する演技力(首だけが動く仕草)は鳥肌が立つ。また、話に乗せて歌う「Empty Doll」は歌い出しで涙。歌や演技を見ると、佐々木さんは上手い、上手いと感じる。歌唱力は全くぶれなく、ピノ(ドール)役だけでなく、老婆の役も問題なくこなせるので素晴らしい。

演劇後のMCで『本当の音楽ってなんだろう、嘘のない音楽ってなんだろう』と語る部分あり。アイカツ亡き後、自分がずっと考えていた部分だったので感傷的になる。今は本当の音楽なんか分からない(分かったらそれはそれで恐ろしい)。また、『少し前は歌った後に観客が目を丸くしてしまっていた』は正に自分の今の状況である。今の所、上手い以上の感情がない。思い出を積めば良いのか?

Run Girls, Run!のらんがばん!Blu-ray発売記念イベント(2020.1.12@秋葉原UDXシアター)

らんがばん!の予約特典のイベント。会場のUDXシアターはまさにカンファレンス用途の場といった感じ。座席は2列目センター右寄り(もっちーより若干外側)。衣装はずっと「Share the light」のもの。

f:id:aikiriao:20200112234847j:plain:w300

内容は、まず8話のオーディオコメンタリ(射的、鰻掴み、怪談)をやってからミニライブ。セトリは「Share the light」、「knock out」、「スノウ・グライダー」、「カケルxカケル」。その後もっちーの生誕祭が3/16にある旨告知あり。最後にお話。

総括としてはクッソ楽しいという一言に尽きる。

オーディオコメンタリはいつものラジオと言った感じでワチャワチャ。はやまるはいつも通り積極的に実況(怪談で何でそんなことするのー!や、いっちゃん可愛い等)あっちゃんが当時の思い出を差し込む(失念)、もっちーは面白いツッコミがあったけど思い出せない。そしてそれに対して入場者は沸いていた。積極的に拍手と笑いが起こる。この点は昨年の海老名とは全く違うと思う。

ライブは着席して見ていたので落ち着いて見れた(マネ様?が下に響くとのこと。今後も使いたいので着席でお願いしますと言って会場沸く)。観賞会といった風。ステージは小さいけどダイナミックに振り付ける3人は迫力がとんでもない。特に「knock out」の途中のソロ振り付けはあっちゃん流石と思った。あっちゃんの髪は更に伸びているようで、「knock out」途中でうつむいた時に髪が地面に垂れていた。 「Share the light」の完成度は高い(前に只野さんがまだ未完成な印象があるとツイートしていたが)。最後まで凛々しい雰囲気を出し切っていた。 「スノウ・グライダー」は頭を抱えて泣いた(いつもの)。音響の帯域バランスが京より良かったし間奏の振り付けがしっかり見えた。3人がバトンリレーで互いに励ます振り付けは、すれ違いが上手く表現できている…。あっちゃんソロの『もういいの』は全力全開で出していた。CD音源そのもので非常にエモーショナル。良い。 「カケルxカケル」は流石に発熱。前で見れる喜びが大きすぎる。また、歌唱時以外ではやまるに向かって打ってたら笑顔をもらってしまい悶絶。ようやくはやまるを直視できるようになったのかもしれない。

お話は20秒程度頂く。リリイベと比べて長かった印象。

自分「(カート受け取り)あけましておめでとうございます、今年もよろしくお願いします」
もっちー「あけましておめでとうございます〜」
自分「(ロード時間)ネコぱらめっちゃいいですね」
もっちー「あー1話見てくれてます?」
自分「はい、マカロンちゃんの成長ガー」
もっちー「嬉しい、これからもっと成長するので期待しててね」
自分「絶対見ますー(剥がし)」
もっちー「ばいばいー」
--
自分&はやまる「(カート受け取り)あけましておめでとうございます」
自分「前で見てるとパフォーマンス凄くて言葉が出ないっす」
はやまる「そうですか?ありがとうございます」
自分「音泉女子高生見てます。現役JK尊いなあと」
はやまる「尊いて…(笑)」
自分「音泉祭り絶対行きますー」
--
自分&あっちゃん「(カート受け取り)あけましておめでとうございます」
自分「プリチャン3期確定しましたよね」
あっちゃん「それー!」ワチャワチャ
自分「3年目のりんかちゃんの成長がめちゃくちゃ楽しみです」
あっちゃん「ほんとだよね〜!」
(自分指差し、あっちゃんワチャワチャ)
自分「絶対見ますよー」
あっちゃん「シルクちゃんの活躍を楽しみにしててね(りんかボイス)」
自分「ありがとうございますー」

あっちゃんテンション高かった。りんかボイスありがたかった…。しかしりんかボイスも間が空いて出てしまった感じ。もうちょっと頑張って伸ばしたいところ。

他に、お話最前の方がもっちーの今年はなんですか?と聞いて、もっちーが開口一番「もっちもっちな一年にする!(あいまいかも)」と答えて会場が沸いた。もっちーはぶれない。

佐々木李子 2nd Oneman RicoRium ~ただ、君に歌いたい~(2020.1.13@渋谷WWW)

SynapstoRyの公演で2ndは大事にしたいという発言が佐々木さんだけでなくバンドメンバーからも出ていた。自分としても、無銭リリイベを経て2ndに向かって意識が動いていたので丁寧に観察しようと思っていた。

チケットは最終的に1週間前くらいにSOLD OUTしていた。オルスタで200人(先行販売の100人+一般の100人)いたと思われる。一般の前半ですでに前は埋まっていたため、右後ろ(ベースの方の後ろ)でのんびりと見ていた。関係者席(オペレータさん)の後ろに沢山の関係者が見られた。はやまるとあっちゃんがいたようだが確認できず。

会場の渋谷WWW(新しくなったパルコのすぐ近く。人通りが絶え間なかった。)は段差があって後ろでも十分見れた。開場1時間前に向かったが物販列は打ち切られた。開場後にのんびり回収できて安堵。

内容は、曲調の大きく変わる瞬間を除いてほぼ休みなくパフォーマンスしていた。印象に残った楽曲は「freedom」(映像付き)、「Empty doll」、「カーテンコールを揺らして」、「ミライドライブ」(キャラソンは却って映える)そして初めて聞いた「Good bye, Liar」。freedomはやはり降ろしてきておりパフォーマンス(ボーカル、振り付け)が凄い。「Empty Doll」とカーテンコールを揺らしては佐々木さんから出てきた歌詞と考えると伝わりやすい。

また、アンコール後の最終楽曲に「手作りの歌」を披露。これは作曲&作詞も佐々木さんで驚く。若井さんの例を含め声優はマルチタレントであることを自然と求められているらしい。

まだ、この時点でも佐々木さんは上手い以上の表現が見つかっていない。まだ思い入れが足らない。もっと見る機会を増やす必要があると思っている。と思っていたら、2月中旬にまたSynapstoRyをやるとの告知があったが、気づいたとき(告知2日後?)には完売していた。自分が追いかけられるレベルを超えてしまったのかもしれない…。

自分含め、観客の6割近くはプリチャンきっかけで来た方だった。これを見てアイカツ歌唱担当と同じくらいの危機感を感じた(勝手に歌唱担当と重ねて辛くなっていた)。プリチャン亡き後が大変である…。でもそれを見越して敢えてフレンドパスワードをやらず、プリチャン抜きの自分を見て欲しかったのかもしれない。(普通に版権問題かもしれない。考えすぎかも。)

音泉祭り2020冬(2020.2.2@なかのZERO大ホール)

音泉女子高生(OJK)としてはやまると白河みずなさんが出演されるとのことで参加。といっても一般先行は抽選漏れ、一般販売でギリギリチケットを入手した。まともにやるならばプレミアム会員登録しないとダメそう。

会場のなかのZERO大ホールはキャパ1300人ほどの会場。中野駅南口(サンプラザの逆)を出て徒歩10分位で着く。中野に行くとサンプラザしか行ったことがなかったので、他にも大きめの会場があることに驚く。

f:id:aikiriao:20200203013022j:plain:w300

音泉祭り自体は5時間半近くに渡る長丁場。覚えている限りで並べてみると、まずはゲームコーナー、次に鷲崎さんの部屋というトークコーナー、次に料理コーナー(名前を失念)、15分の休憩、音泉カラオケ大会、下野キングの部屋というトークコーナー、ことパン劇場、ライブコーナー。席は2階席の最後列(つまり一番うしろ)だったが、ライブパート除き座って見るものだったので落ち着いて見れた。

内容が非常に濃かった。笑いどころも沢山あったが思い出せないところがどうしても出る。印象に残ったことをなるべく述べていく。

初っ端ゲームコーナーではマリソニ(マリオ&ソニックのオリンピックゲー)でバトル。110mハードルで説明が入る前にレースが始まってしまい、初っ端会場が沸く。次のラグビーでは一方的な展開になること多し。最後のぷよぷよはフィーバールールで(下野さんの無理やりなハンデ命令により)なかなか盛り上がっていた。

鷲崎さんの部屋では、鷲崎さんの司会が流石に上手く、テンポよくまとめていく。音泉ジュニア枠の佐藤さん?が体当たり取材(27時間で家を作る等)が多すぎて僕を中に入れてください!と発言したのが確かに一番面白く、メダルを手にしていた。

お次の料理コーナー。1人9分間の時間が与えられ、交代して作ってもらいたい料理第4位(実はおにぎりで誰も当てられず)を作るというもの。4つの番組対抗で誰が4位を当てられるか勝負。注目すべきは吉岡さん(まゆしぃ先輩)だった。9分間に渡ってとにかく挙動不審になる。IHがつかずに狼狽したり、取っ手が取れず両手を上げたり、肉を適当に突っ込んだりと。そういえば料理ができなかったことをANNi(オールナイトニッポンi)で聞いたことがある。面白すぎてずっと見ていた。後半9分で山下さんが挽回し、創作料理を完成させる。まゆしぃ先輩の凛々しい以外の姿を初めてみた。

一旦休憩が入る。トイレに向かうなどしていたらすぐに次が始まった印象。

後半のカラオケ大会。マクロス楽曲2曲歌われ、はやまると白河みずなさんは「ライオン」を歌唱。聞いたのは2nd渋谷の夜以来かも。はやまるはボーカルラインの乗せ方、声の芯の太さ(オケに埋もれない)がダンチなのは当然として、みずなさんも歌うと上手いということがよくわかった。デュエットでハモリも安定してできていた。

下野キングの部屋では、音泉女子高生のなめこ4mm事件が取り沙汰される。また、無茶ぶりで「お兄さんに召し上がれ」シチュエーションで演技するところがあった。はやまるはお兄ィと呼びかける演技は堂々としており◎。みずなさんも松岡ハンバーグ勢が視線を向けられない(いじられていた)中でもハキハキ演技した。藤田茜さんが百人一首やりますと行ったらみずなさんが特技で食いついていた。それにはやまるも乗っかっていた。他には、どうしても山下七海さんを拝みたいという女性の音泉ジュニアの方あり。収録打ち合わせで出会ったときはずっと見ていたらしい。やっぱオーラあるんやな…。

ことパン劇場「ゴチャモン」(綴り合ってるか自信ない)は本当によくまとめたなあと思った。下野さん主人公、山下さんヒロインという配役で、ジュニア除く21人を満遍なく、番組や個人の特徴を捉えたギャグを入れて完成させていた。脚本はまゆしぃ先輩ということで、やはり驚嘆せざるを得ない…。他に驚いたのはみずなさんの演技力。ラジオの喋りと全く違い、演劇の時は力が入りペラペラにならない。声優としてのみずなさんの声を初めて聞いたかもしれない。

ライブコーナーで印象に残ったのはともりる(楠木ともり)さんの衣装が完全に魔法少女として纏まっていたところ、ことパンのテーマソング「わがままパンケーキMix」初披露で、広川さんらしいサウンドを聞けたところ(作詞はまゆしぃ先輩…やっぱすごいっすよ…)、最後に音泉ジュニアの乾杯というユニットが2019年末から練習し始めたギター楽曲を披露したこと。雰囲気は良く、ライブは技能だけで決まるものではないと再確認する。最後に下野さんも出てきて音泉テーマソングを音泉ジュニアと歌い、感想を述べて終了。音泉女子高生をこれからもよろしくお願いしますとあったので、まだ続く?

全体的に、まゆしぃ先輩がかっさらったイメージあり。料理できない(を上手く見せる)、脚本書ける、歌詞書ける、歌歌える。要はマルチタレントを実現している。

全体的に音泉女子高生は、配信と同様にはやまるがリードして存在感を出していた印象。一方のみずなさんの実力が見ることができたので、これからの配信で実力が伺える機会を楽しみにしたい。


…書こうか迷ったが書く。未来みきさんをアイカツ武道館ぶりに見た。出る度に、自分はどう反応すればよいか分からず苦悶し座り込んだ。まだ整理がつかない。アイカツでない世界で頑張ろうとするかつての覇権の一端を、どうやって見ていけばよいのか、全くわからない。真っ直ぐ見ることはもはやできなくなっている。

カラオケMAX(2020.2.8@カルッツかわさき

音泉女子高生の2人(はやまるとみずなさん)が出演されるとのことを音泉祭りにて聞き参加。会場のカルッツかわさきは南口(ラゾーナの逆)から徒歩20分ほどの場所にあった。キャパはそれなりに大きく見えた。1000人クラス?席は2階からだったが、傾斜のおかげでよく見えた。でも双眼鏡欲しいかも。

f:id:aikiriao:20200210024036j:plain:w300

カラオケMAXは小山剛志さんが司会となって、声優のカラオケを披露するイベント。今回は男性声優4人、女性声優4人、そしてはやまるとみずなさんが出演。もう11回も開催しており歴史があるようだが初参加。女性声優には若井さん(わかちー)と芹澤さん(セリコ)、そして、入場前から所々で強いと話を聞いていた磯部花凜さんがいた。

内容の概略としては、OPアクトとして音泉女子高生が「告白日和、です!」、次に小山さんが「Snow Halation」、その後は8人の声優を1人ずつ呼びながらソロ曲を披露。次にロック縛り、モノマネ縛り(1コーラスのみ)、最後にデュエットコーナーと続いた。気づいたら2時間50分が過ぎて終わっていた。

印象に残ったことを述べていく。最初の音泉女子高生はやや緊張した面持ちであることが喋りの硬さからなんとなく読み取れた。「告白日和、です!」は何年ぶりだろうか、もうわからないが、気づいたら白を点灯していた。。ハイタッチするシーンなどあり。配信内でもカラオケを増やしても良さそうに見えた。

その後は小山パパ〜の呼びかけ(犯罪では?)で小山さんが現れスノハレ。。。男性ボーカルだが堂々と、自分のものにして歌唱していた。スノハレといい、夏色えがおといい、ラブライブ!のアニメ化前楽曲は強すぎる。

歌唱は、全体的に磯部花凜さんが化け物と思わざるを得なかった。楽曲「eternal blaze」、「God knows...」、そしてモノマネでは"なりきりとして"レ・ミゼラブルの「夢やぶれて」。「God knows...」は世代直撃で死んでしまう。平野綾さんのたくましいボーカルを少し思い出すような太めの声と正確なピッチコントロールが見られた。歌唱後の喋りは噂に聞いたとおり崩壊していた。これは、計算で出せるものでは無いと思うが(挙動不審なところもある)、演劇出身と考えると、もしかしたらがある。問題は「夢やぶれて」だろう。1コーラスといいながら小山さん曰く切るところがないのでフルコーラス。これは上手いだけではない。とても伝わりやすい歌唱になっている。音程は今までに聞いた夢やぶれてそのものだった。情感を込めるためにえげつない抑揚が入るのが非常に強い。書いていて当然のことなのだが悲しい歌詞はとぎれとぎれに、楽しい歌詞は朗らかに表現できている。聞いている時は全員座っていたが、歌い終わりでスタンディングオベーションが起きた。

自分が語れたものでは無いけど、「夢やぶれて」を聞いて思うのは、これが本当の歌なのかという感情である。これはモノマネとか、なりきりや、まして遊びではないことが十分に伝わってきた。これ以外は嘘というか楽しいだけの学芸会になってしまった印象がある。歌い終わったあとはしばらく涙が止まらなかった。同時に、コンテンツ自体をどの様に見ればいいのか、どの様に楽しめばよいのか分からなくなった。楽しくやっていくことは簡単で、表面だけ見ていけば誰にでもできる。しかし、一方の本物は確実に精神を揺さぶり、自分はコンテンツを漫然と見ていていいのか、このままではいけないと危機感に追い立てられる。不安になっていたら推しを見失いかけてしまった。推しは信頼できるか。自分の中でいよいよ試され初めているのかもしれない。

演劇上がりは佐々木さんといい、化け物しかいない。これからは演劇を見るべきなのかもしれない(ちょうどアイナナで演劇があって助かった。)

他はわかちーとセリコの「いけないボーダーライン」が素晴らしいデュエットだった。全体的にハモりが完璧に決まっていた(わかちーはセリコの歌唱で、セリコは磯部花凜さんの歌唱でハモっていた)。iRisのメインとなる低めのドスの利いた低めの帯域は、この2人によって支えられていることがわかった。特にわかちーは低いパートをしっかり支える、まさに縁の下の存在。わかちーのモノマネもよくできていた。セリコもYUKIのモノマネが声優界一(わかちー談)の通りにやりきっていた。あのワガママっぽい声質が確かにバッチリ再現されていた。

カラオケMAX終了後、「夢やぶれて」にやられてずっと心が空っぽになっていた。川崎から秋葉原に出て、呆然とプリチャン筐体を回している中で「ダイヤモンドスマイル」を遊んだら、2019の思い出が走馬灯の様にめぐり、あの熱い公演の数々を思い出した。熱さとパフォーマンスならまだまだいけると再認識して、少し自信を取り戻した。

ワンダーフェスティバルでの『ネコぱら』ステージ(2020.2.9@幕張メッセ

ワンフェスはフィギュア版同人誌即売会程度の認識しかなかったが、実際に行ってみるとホビー、フィギュア、キット等、即物系ならばなんでもあるような大規模イベントになっていた。企業ブースも十分広く、参加者もかなりいたのでは無いかと思われる。

『ネコぱら』ステージは15:00〜のため、それまでは他のステージを見ていた。11:00〜はIDOLY PRIDEのステージがあった。自分は途中からクイズコーナーをやっているところを見て、初披露となるライブシーンを見ていた。プライドの名の通り、高潔なアップテンポだったと思う。

f:id:aikiriao:20200210024121j:plain:w300

IDOLY PRIDEのあとは一旦ワンフェス会場を周回。フィギュアメインということもあり、見るだけでもかなり楽しいものがある。

f:id:aikiriao:20200210024455j:plain:w300

『ネコぱら』のステージは、出演者はショコラ役八木さん、カカオ役もっちー、司会の鷲崎さんといった布陣。バニラ役佐伯さんは欠席で、2人で稼働するのは初とのこと。内容は、1〜5話の振り返り、6話の予告(アズキとココナツが凄え喧嘩します)、アフレコ裏話、グッズ紹介、告知で40分きっかり。

全体的に鷲崎さんの司会がうまく回っていた、というかぶん回していた印象。司会が上手いなあと感じたところは、

  • 1〜5話の振り返りでアフレコ裏話を振ってしまい、その後にアフレコ裏話が出ておっと、とおどけるところ。
  • 各話紹介がどうしても説明口調になってしまうところを上手く切り上げるところ(1話紹介後にネコミミ落ち着かねえな!と言って硬直しかかった空気を持ち直す)。
  • もっちーがカカオの5話の演技は言葉は少ないけど雰囲気を出せるようにしています!と言ったらいいでしょう!と言ってフォローするところ。
  • 演者の猫についての話題のツッコミ。八木さんの祖母は猫を飼っており、いつも父が八木さんに怒りをぶつけるように悪戯するように仕向けていた(鷲崎さん:最悪だな!)、最終的に階段に登るのもブロックされていたとのこと。もっちーは近くの畑(耕されている。鷲崎さん:畑だからな!)で猫が土を掘り返していて(鷲崎さん:それで終わりか?)その穴で寝ていたのを見ていた(鷲崎さん:嘘でもいいから盛れよ!)

アフレコの裏話としては、まだバニラショコラの3人でのご飯は行けていないとのこと。そして行きたいんですと言っていたが、ハラハラする。また、収録時にショコラの隣りに座って良い状況ながら、ドセン(ドセンター)はショコラが居るべきとしてカカオらしく端っこに落ち着いたとのこと。

もっちーはどうだったか。今日は緊張している感じはなく、各話エピソード紹介でスライドに書かれた内容をただ棒読みするのではなく、自分の言葉で盛りながら自由に喋れていた。また、フィギュア(ねんどろいどfigma、POPUP)が出てきた時、もっちーがカカオちゃんをその場で描いて背景にした。よどみなく筆が進んでいた。また撮影時には私の愛がこもってるんですともコメント。これからも、もっちーは緊張していなかったように感じる。

イベントは終わってみると楽しく、ワンフェス自体もよい社会見学になった。2.8の限界状態からはだいぶ開放されてきているかもしれないが、根本には棘が刺さっていると思われる。来週のバレンタインイベントに大いに期待したい。

Run Girls, Run! バレンタインイベント!!! ♡~For you~♡(2020.2.16@渋谷PLEASURE PLEASURE)

平日が渾然一体とする中で、ランガちゃんのイベントが唯一の楽しみとなっている。バレンタインイベントは京都で告知があったときから、わぐりすらんを連想して楽しみだった。今回のレポは思うところを乱雑に書きすぎた。纏まっていないかも…。

渋谷PLEASURE PLEASUREは109を少し入ったところにあるユニクロが入ったビルの6Fにある。物販は12時開始ということでゆったり行ったら10:15に現地着。20人程の方が既におり、列を作っていた。物販は11:45くらいに開始(巻いた)。グッズ新規でプレートライト(はやまる:出したかったとのこと。)、Tシャツ、トートバック等があり本格的なライブ規模の品揃えがあった。

12:10には物販列を抜けた。もう一周しようにも列が長く(地上から6Fまで伸びていた)、品揃えが多いためレジ捌けがまずそうだったため、昼食と荷物整理に向かった。13時を回ってから会場入り。昼公演はB列(2列目)左端で大変恵まれていた。公演は14:00からスタート。席は一杯に埋まっていたように見受けられる。

f:id:aikiriao:20200217231354j:plain:w300

イベントの前半はトーク(バラエティ)コーナー、後半はライブコーナーで別れていた。トークとライブの幕間にはライブの注意事項を映画前の警告のように仕立てた人形劇動画あり。

衣装は、トークパートでは昼は私服風、夜はメンバーカラーのチェック衣装。ライブパートでは、ANIMAX神戸から着始めているであろうギンガムチェック衣装。

トークパート初っ端で、はやまるは今日は喉の調子が悪いと告知。直前のさんよん(Run Girls, Run!の3人4脚自由形)でも花粉症で声を出すことすら厳しい状況だった。だから話せているだけでだいぶ復帰している印象(この頃、インフルエンザに加えて新型コロナウイルスも流行を見せており大変心配になる。自分は体調に問題はないが、マスク着用で参加。)。喋りは問題なかったけど、歌唱が素人目に見ても辛そう(一瞬かすれて、なんとか芯を入れて歌う様子)だった。でも、大きな破綻なく歌いきっていた。夜公演は昼よりもより安定した歌唱が見受けられた。声は頑張って張らずに柔らかく音程を合わている印象。しかし、明らかに辛そうにしているところを見ると、どうしても感情移入してしまって辛くなる。。。だからといって言葉には出せず、まっすぐ推しに向かってプレートをかざすしかなかった。また、イベント次日の月曜日のブログでも悔しさがあったこと読み取れた。演じている途中は泣いたり崩れたりしない強さは健在。

トークの内容に入っていく(まとまりがないかも…)。司会はもっちーメインですんなり、適宜ツッコミが入るし、無理やり進行している様子もなくてとても良かった。席は上手(観客から見て左)にもっちー、下手にはやまるとあっちゃん。OPトークで印象的だったのは、あっちゃんがチョコ貰えましたか?と問いかけて(昼は)貰えない人多数で、あっちゃんがそんな渋い顔しないでーというところ。夜はランガちゃんにもらったからなのか貰えている人ばっかりだった。

その後チャレンジコーナーが続く。ここではチャレンジに成功する度に観客に配れるチョコレートが増える。まずはあっちゃんが動物のモノマネ。もっちーが素早くパンダと言い当てる。前で見ていて分からなかったので、すぐに分かるのはすごい。次に紙飛行機を折ってステージの端から端まで飛ばせるかというのがあった。はやまるともっちーは新幹線みたいな寸胴のヒコーキで上手く行かず、あっちゃんは観客のアドバイスに従って鋭く折って先端に重心を乗せたら上手く飛んだ。観客の中で3人以下に当てはまるお題は?(いいとものやつ)もっちーが早速「四国から来た人」で2人でクリアする。続くあっちゃんはミルクココア飲んできた人は?で7人くらいで×。はやまるはゆで卵食べてきた人は?で10人近くいて×。夜公演では、あっちゃんがペンギンのモノマネ(あざとい。もっちー曰く可愛いのでもっと見たがり回答を引き伸ばされていた)、またもっちーが猪のモノマネ。

次にショート演劇。永野さん(永野さんは只野さんの隣の観客席にいたらしい)ナレーションで、昼は学校、夜は職場でチョコを渡すときの一言を披露。はやまるは放課後の教室で同級生に(夜は3番手で会議室でプレゼンの後に。「プレゼンで発表し忘れてたんですけど…」と、何か現実離れしているけど演技は自然。)、もっちーはサッカー部室で先輩に(夜は1番手で定時後の職場で)、あっちゃんは理科室で先生に(夜は給湯室で部長に)というシチュエーション。一言演技した後に、こちらからも言葉を入れるシーンもあり。昼公演では誰が一番良かったか拍手で決める方式だったが、ほぼ横並びで確定せず同着。夜公演では比較すらなく確定で72個(那奈美にちなむ)のチョコを取得。

その後は獲得したチョコをクイズコーナーで増やしていくコーナー。昼公演では、各メンバーが事前申告した得意なジャンルについての出題があり、掛けたチョコに対して得意なジャンルであれば2倍のチョコ、そうでなければ5倍もらえるルール。はやまるは音楽を選択し、音楽記号(♮)、亜麻色の髪の乙女ドビュッシー)、レッド・スペシャル以外のギター(難題)が出てきた。最後は流石に難しかったか、正解者なし。あっちゃんは理科で、太陽系の惑星で一番太陽から遠いのは?というので、はやまるが「乙女アテンションプリーズ」を歌って思い出していたのが良かった。金の元素記号については、あっちゃんが分からない(ぬけちゃった)と焦る中、ヒーロー(英雄えいゆう)だよとはやまる。最近習ったとも言っていてリアルすぎる。最後の抵抗の単位は?で、もっちーが即座にΩを書いていたけど×喰らっていた。(あっているはずだ)もっちーはなぞなぞ。イタチが横になって食べるものは?で、自分がわからず悶絶していると、板チョコという回答。なるほど。夜公演では完全にイントロクイズとなっていた。WUG、は分からなかったけど、ラブライブの「No Brand Girls」は体が反応した…。はやまるも優勝といった感じでワチャワチャ。デレマス(あんきら狂想曲)は、あっちゃんが食いつくようにスケブに書き下していた。他にも、はやまる希望のプリキュアは、ほぼあっちゃんが正答を出し信頼が高まった。はやまるともっちーはあっちゃんの回答を写しており笑えた。(はやまるがあっちゃんを写し、もっちーがはやまるを写す。)こういう不正をやっていいという場を完全に理解しており、とても楽しい。

タイムアップを見て、獲得したチョコを渡すためにメンバーが客席に来てくれた。もっちーが最初は最前列に手渡ししていたが、それ以外のメンバーがばらまく。それを見てもっちーもばらまくというのを昼夜でやっていた。夜公演では、2Fでシルクちゃんを見つけたのかあっちゃんが反応していた(1Fの深いところだったので様子は見えなかった)

f:id:aikiriao:20200217231447j:plain:w300

(左が昼公演でもっちーが撒いていたチョコ、右は夜公演ではやまるが投げていた。)

メンバーが一旦抜けた後、ライブマナー講座が場を繋ぐ。過度な応援(30cm以上のサイリウムNG、過度なコールNG、担ぐ&担がれるNG、盗撮NG)ギャグが多く笑った。盗撮NGではあっちゃんが太陽にほえろ!のメインテーマを歌い、もっちーがはやまるをしょっぴいてうぅ〜と柳沢慎吾ばりの演技をするのが面白かった。

そしてライブコーナー。2nd渋谷?から聞くようになったRGRのテーマがかかり、メンバーがステージへ。MCも短めにガンガン曲を入れてくる。セトリは、

  1. 16歳のアガペー
  2. Jewelry Wonderland
  3. MC
  4. Go!Up!スターダム(昼) / キラッとスタート(夜)
  5. スノウ・グライダー(昼) / サクラジェラート(夜)
  6. キラリスト・ジュエリスト(昼) / never-ending!!(夜)
  7. MC
  8. プリマドンナメモリアル

感想。いきなりの「16歳のアガペー」に衝撃を受ける。久々に聞いた印象がある。みんなにありがとう!ミニライブ依頼?続く「Jewelry Wonderland」は初めて聞いたが、非常にインストゥルメンタルで好きになった。MCでは、永野さん(あいちゃん先輩、ちゃんあい先生)に振り付けを見てもらったとのこと。もちろん調もあるだろうが、振り付けは心なしかしなやかに見えた。

続くMCであっちゃんが落ちサビは音数が少ないから、Mixは…(注:かなり意訳で実際の発言内容と異なる)、WUGも素晴らしいけど私達をしっかり見てください(注:かなり意訳で実際の発言内容と異なる)と呼びかける。幕間でのコールマナー動画含め、過度なコールは禁じていく方針のようだ。確かに、1st品川よる公演での「Go!Up!スターダム」の落ちサビでMixがあって辛かった。あれはやはり演者にも聞こえていたんだなと実感した。

やはり、「スノウ・グライダー」は強い。あっちゃんがセンター後ろよりに立った瞬間に背筋が凍り、イントロがかかった瞬間、泣くことしかできなくなる。はやまるは細い声を逆に活かして歌唱できていたように見える(全肯定)。2番の『もういいの』ソロで、リバーブセンドが有意に大きくなるオペレーターさんはすごいと感じれた。「キラリスト・ジュエリスト」は、幕張では遠目に見ていたギンガムチェック衣装の振り付けを、目前で見ることができてとても嬉しかった。やっぱり笑顔で振り付け跳ねている。また、「never-ending!!」もまだ振り付けを目で追うくらいのことしかできていないけど、歌詞をなぞるとだいぶ感情的になる。2ndライブツアーで一番化けてきたのはこの曲なのかもしれない。

MCがあって次が最後です、エーッ!!となってから、大トリは「プリマドンナメモリアル」。プリマドンナは大好きだけども意外だった。昼公演では心細かったけど、夜公演では近くの方がプリティーシリーズを見ているようで、久々に堂々と声出しできた。

昼公演のライブが終わって、メンバーが捌けたと同時にスクリーンが降りてきた。告知については身構えておらず、席に座ろうとしたところで3rdライブツアーの開催が告知された。呆然と立ち尽くし、気づくと、前の椅子の背に手を付いて泣いていた。本当に嬉しかったのだ。夜公演ではライブ前にメンバーから告知があった。その場で、3rdライブのテーマ『夢へのバトン』はもっちーが1stライブツアーの時から考えており、ようやく使えた案だという説明があった。夢へのバトンを皆に渡したい(曖昧かも)という意図があるとのこと。昼公演ではもっちーからの説明がなく、『バトン』というワードに過剰反応し(次世代への繋ぎを連想)限界になっていたので助かった。

まとまりがつかないけどまとめ。3rdライブは何よりも嬉しい。開催場所を見ると大阪→仙台→品川とあり、1stのリベンジを込めた公演に見受けられる。今年も自分の追いかけられる範囲でランガちゃんを見ていく1年にしたいと強く感じた。

3月〜 COVID-19の影響

緊急事態ということもあり、多くのイベントが中止になってしまった。

最初は1ヶ月程度イベントが中止になる程度と思っていたが、想定以上に中止期間が伸びそうな印象を受けた。今のうち、思ったことを書けるだけ書いておこうと思った。

自分は以下のイベントに参加予定だった。

イベント名 当初の開催予定日 執筆時点での状態
Run Girls, Run!ホワイトデーイベント!!! ~Give me~ 3/7 6/14に延期(その後中止)
TVアニメ「ネコぱら」OP・EDテーマ発売記念リリースイベント 3/8 中止
森嶋優花バースデーパーティー もちもち♡マニュアル~これからもよろしくね~ 3/16 中止
AT-X Anime Tunes 2020 3/29 延期
ナナステ☆スイーティブストーリーズ ~起源・永遠の願い~ 4/1-4/5 中止
佐々木李子 2nd Oneman RicoRium ~ただ、君に歌いたい~アンコール公演 4/11 中止
HATSUNE MIKU LIVE - UNTITLED 0 - 4/12 中止
NonSugar スペシャルイベント「約束のてへペロピタですわ!」 4/25 中止
林鼓子バースデーイベント ☆Coco's Music Journey☆ 5/16 中止

イベントを中心に楽しんでいた自分としては、今の状況は地獄だ。特に、ナナステは初の舞台ということもあり、また公演回数が多かったというのもあってショックが大きかった。また、もっちー生誕は一旦5/4に延期したのにも関わらず、緊急事態宣言の期間に入ってしまい中止になってしまった。はやまる生誕も中止が決まってしまい端的に言って悲しい。ナナステの全公演の中止が決まった4/1、流石に己だけでなく運営側にも限界を感じたため、手紙を書いた。

ナナステの中止については一言補足しておく。ナナステは当初衛生管理を徹底して公演を行う予定だった。当日参加できない方にもビデオカード配布という方針があり、自分としてはそれでよいかと思っていた。しかし、初日公演15時の最終会議にて全公演の中止が発表された。演者の皆様はゲネ(通し稽古)をしていたようで、演技の方は当然完成していただろう。

振り返ると2019年はほぼ順調にイベントに参加できていた印象がある…と思ったら、「C・S JAPAN in Osaka ~Another Stage~」、「Super☆Premium Vol.8」は中止だったことを思い出した。それでも、2019年はとても充実していた印象を受ける。

筐体も接触を避けるために遊べない状況が続いている。新段が4月から始まっているが全く遊べていない。緊急事態宣言によりゲームセンターは営業休止になっている。

今は、本当に今は耐えるしかない。3rdライブツアーだけは無事であって欲しい。1stアルバムの楽曲を携えたランガちゃんは単独としてより強度が上がっているように見受けられる。3rdライブが始まる7月下旬には落ち着いていて欲しい。それだけは切に感じている。


2020.6.11、関東は梅雨入りした。雨の中何もできないので改めて「Colorful☆Wing」を聞くと素晴らしいことを確認する。ガーリー・エアフォース含め、これまでにランガちゃんにはいろんな景色を見せてもらったし勉強させてもらってる。再起動後もしっかり追っていきたい。

大阪は新規感染者が殆ど見られなくなった。USJ再開を見るとだいぶ楽観できる。また、仙台も8月以降は解除の向きがある。東京は予断を許さないだろうが、自粛解除の流れは感じている。3rdライブの開催は、まだ断言できないが期待できる。引き続き準備をしながらも、開催を祈り続けている。


2020.6.13、3rdライブツアーの延期告知。今は何もまとまった言葉が出てこない。単純にショックだ。

2020.7.18 Hello! プリ☆チャンワールド(配信)

配信ではライブ性が無いから(リアルタイム性がなく、今この様に文章を打ててしまうから)レポを取る必要は無いはずだ。 しかし、このライブはプリチャンにとって非常に大きな意味を持つのは間違いなかったため、自己の心情の変化を記していきたい。 今日、ようやくこれでプリチャンが始まるのかもしれないと、勝手に思っている。

配信ライブの開催告知は7/3。急なスケジュールではあったが、コロナの中春から公式が準備に動いていたと推測される。 プリチャン単独ライブはおそらくかなり早い段階から企画されていたのだ。

その観点から見ても、配信というのがわかり、悔しさが先に来てしまった。 配信は今だに信じ切ることができない。 自分はアイカツの反省から、現地に一つでも多く足を運び、演者を生で見ることを非常に重視しているためである。 特に、ランガちゃんはパフォーマンスが素晴らしいので、現地は満足度が高い。

そして、どんなにバーチャルが発達しようと、少なくとも自分が生きている間は、 ライブは生じゃないと最高の体験ができないことは、多くの経験から真実だと思っている。 しかし、悔しさが先に来てしまったのは反省しなければならない。 しばらくして落ち着いてきたときに、プリチャン単独が開催できる喜びを反芻し始めた。 また奇跡的にではあるが、プリチャンが配信を題材にしているというのもあり、 配信ならではの要素があるのではないかと期待感が増して行った。

配信ではあるものの、始まる直前は緊張感があった。昼は14:00-、夜は18:00-スタート。

セトリは昼夜同じだったと思われる。MCで出てくるメンバーに変化があった。ステージ、というか箱そのものは小さいようだった。どこかの(おそらく都内の)劇場を貸し切って配信したと思われる。ストリーミングの途切れはほとんどなかったが、夜の部冒頭だけはトラフィック増加が原因なのか少し途切れた。

セトリは、(イルミナージュ・ランド除き)2ndシーズンまでの全てを出したものだったと思う。セトリに並べて感想を述べる(リアルタイムの文章がほぼそのままなので雑…)。

楽曲 感想
開幕MC 開幕佐々木さん+だいあぱんの衝撃。応援コメントを何件か読み上げた
SUPER CUTIE SUPER GIRL 初手SCSG、ステージが以外に小さいことに気づく。にこやかな歌唱が映える。そして足使い、はやまるにあっちゃん完璧。
寝ても覚めてもDREAMIN' GIRL 昼はセリコが開幕の「すーきーなー」をずらして演者視聴者ともに笑う(後半のMCでカバーしていて流石と…)。
MC 昼ははやまる+佐々木さん。夜はそらまる+茜屋日さん。画面の両端に立って最大限のソーシャルディスタンスで司会。夜は、ソーシャルディスタンスの見えない壁さんに笑った。
動画
レディー・アクション! 原点。死亡。 一瞬動画で映っており来たら怖いなあと思ってたら死んだ。2018オータム以来なのかもしれない。夜は最後のフゥー!の決めポーズで脚がギリギリ当たらないくらいの距離をぴったりとっていた。完成度が高い。
ワン・ツー・スウィーツ 涙で何も見えない。桃山みらいにドハマリする元凶。はやまるの振り付けは完璧。ほぼほぼfull尺。夜は完璧なコンディションだったと思う。振り付けも最強。このあたりで、はやまるの調子が良いのではと推測し始める。
キラリ覚醒☆リインカーネーション 振り付けによる表現力、そして高い脚上げ…このあたりでカメラが寄ってるから振り付けがよく見れることに気づく。
スキスキセンサー プリチャンの口火を切った曲と自分は認識している。久保田のさんも振り付けをキビキビと決める。それでいてボーカルがぶれない。表情のつかいかたが完璧。笑顔がくずれない。プロだろ(プロ)
MC 昼はシルクちゃんを持ったあっちゃん、もっちー、セリコ、わかちー。徹底的にシルクちゃん推し演技。夜は販促、みらいさらで楽しく。さらがメルパン人形を見て壊れる 「あ”あ”あ”あ”(イケボ)」のが最高。ほんま最高。
Play Sound☆ 完成度が死ぬほど高い。ボーカルの安定がとんでもない。カラオケMAXでも感じたがiRisのドスの聞いたVo.は当然安定している。夜はヘドバンが止まらなかった。
スペース!スパイス!スペクタクル! 驚き、そうか、めるは1年目ソロ無いんだと気づく。振り付けがちょこちょこしていて◎。夜はカメラに寄せてもっちーが朗らかになっているのが良かった。
ヒロインズドラマ 淡々と歌ったら単調になってしまうが、そうならない。カメラの向こう側に演技してる。夜はセリコのプロポーションと表情が映えていた。このあたりで夜のカメラマンの実力が異常であることがわかり始めてくる。
My Secret heArtbeats プリチャン内でトップクラスに好き。作品に寄り添った最大のキャラソン。間奏MC「今はみんなに会えないけれど、みんなの心に届くように歌うよ…(イケボ)」夜は「画面の前の君に向けて、心を込めて歌うよ(イケボ)」、「ありがとう(イケボ)」強い。
MC セリコとみゆたそが出てきておっとなる。2019ウィンターでのやり残しをついに見れる時が来た
ツヨキ!ツインテールズ! 曲の前フリのセリフ部分が感情がとても入っていてよい。そしてサビ入りが好き。夜は寸劇が長めに入っていておもしろかった、煽りあい好き。
動画
イルミナージュ・ランド 初披露、新衣装。 熟練度がすでに高い印象。2番はもっちーが一部アドリブ(高域振れ)あり。伸びやかに歌う早まるに安心する
MC ランガちゃんのMC。多少冗談を入れたり、ランガちゃんらしい話の持ってきかたができていたように見える。
キラッとスタート あっちゃんの振り付けが細部まで拘ってできていたように見受けられた。夜で振り付けでエアギターやってたけど今まであったっけ?要確認。
フレンドパスワード 感情豊かに歌い上げている。堂々としている。大きなオーラと感情を感じる。夜は伝えようという強い気持ちが入っているのを感じた。そのためか表情が真っ直ぐだ(媚びていない)。非常に真っ直ぐな視線が印象に残った。
シアワ星かわいい讃歌 やっぱまりあを降ろせているところを見て安心できる。
キューティー・ブレイキン そらまる先生髪の毛が短くなっておりかなりかっこいい。やはり7年前のラ!の時代から変わらない畏敬の念が湧く。夜はラップパートが自明に安定。
短い動画 アンジュさんの動画、やっとこのときがきたか…という感動。
フォーチュン・カラット プリチャンでずっと見たかった景色。 衣装すげえ…そして振り付けを可能な限りやり込んでいてくれて本当にありがたい…………。夜は限界に入った。美しい、みもりんはすごい、すごいねん…7年前と考えることが一緒。憧れ。落ちサビの聞かせるパートが神。振り付け一切なしで訴えかける歌い方。神話だった。
動画 虹ノ咲さんの振り返り。色々あった2019年…。
MEMORIES FOR FUTURE アニメ本編では佐々木さんが圧倒してる感じだったが、配信でははやまるの低音域が安定していて安心して聞けた…季子さんとも完璧に合っている…。完全にミュージカルと化したプリチャンだった。前と後の動画が2ndシーズン振り返りが素晴らしい。夜は音量のバランスが取れてるし、振り付けの息ばっちり。はやまるはダイーヤーモーンドー(高跳び)も難なく出せていた。
インディビジュアル・ジュエル 懐かしくなり2019オータム大阪に思いを馳せた。ああ、間違いなく楽しかった。
COMETIC SILHOUETTE 安定感が段違い。振り付けが豪華。夜はカメラが見るべきポイントを抑えてくれるのでリアルタイムPVとなっていた。
La La Meltic StAr プリチャンの到達点。嘘のない曲と振り付け、歌唱。これが全て。夜は顔によるカメラワークが異常にあざとい。わかちーを下からえぐり、それを受けたわかちーも下目にニヤッとするのが強すぎる
乙女アテンションプリーズ 聞いててやっぱ久保田さん必要やわと強く実感…満足度が違う。キラッツが揃う喜び。
ロケットハート この曲を聞けるのをずっと待っていた…。まだintro.の浮遊感が再考以上の感想が出てこないけど、本当にすき。キラッツのバランスのよさがよくよくわかった!はやまるのボーカル、あっちゃんの振り付け、久保田さんのトータルなあざとさ。
MC ゲームプリチャンの宣伝コーナー。筐体。プリたまGO。
MC 1人ずつ挨拶のコーナー。だいあ、アンジュ、まりあ&すず、メルティック(開幕歌唱ミスをカバーする一面)、キラッツ
ダイヤモンドスマイル トリはダイヤモンドスマイル!全員出てきた。メルティックとリングマリィは観客席で歌唱。

配信はぴったり2時間で終了した。

夜はカメラワークがよりえげつなかった印象がある。そしてそれに合わせてしっかりアピールするiRisメンバーと、しっかりパフォーマンスをこなすランガちゃんが大変素晴らしかった。

配信だからこそ実力がわかってしまう部分が多かった。Vo.差し替えは一発で分かるし、カメラは寄ってるので振り付けにごまかしが効かない。表情もかなり重要。その意味で、iRisメンバーはこの環境をかなり活かしてパフォーマンスできていたと思う。その一方で、佐々木さんの媚びずに真っ直ぐな視線を与える歌唱(とMC)もかなり印象的だった。

夜のMCは少し記憶に残った。佐々木さんは(ライブとかでよく見るように限界になりながらも)不安だったけど、画面越しでも伝わったよという発言あり。メルティックは2019冬はトリでバキバキに緊張したけど、今回は裏でも楽しめたということ、キラッツはシルクちゃんをリボンに差すなど、ふざけていてよかった。

プリチャンの最大限の誠意を感じている。イルミナージュ・ランドを除き、2ndまでの全てを出してきている。一切遊びがない"プリチャン"のライブだった。楽しかった。グッズ買いに行こう。

現地が最大なのはひとまずおいて、配信は素晴らしい完成度だったと思う。告知はなかったけど、ウィンターは生で見れることを信じて先に進む。

2020.7.25 リコリウム 〜君と私の居場所〜 (配信)

この日の昼にはランガちゃんのネットサイン会があった。1部(12:00-)に応募しており、滞りなくサインを貰えた。しかし貰えるまではたいそう緊張していた。

19:00-からは佐々木李子さんの単独配信ライブ。秋葉原CLUB GOODMANさんが閉店ということで、それのお礼を込めての興行となっていた。無論、GOODMANさんから配信。

今回は印象に残ったことを述べていく。 ボーカルとバックバンドのバランス調整が完璧だった。バンドならではの生演奏、照明演出(「tell you, tell me」等の激しい演出もバッチリ)も大変素晴らしく、見ごたえがかなりあった。セトリの組み方も見事だった…開幕「カーテンコールを揺らして」でバッチリ掴み、毛蟹さん(作曲者)無双から「Freedom」、「Empty doll」等強い曲があった後に、 限界になりながらもGOODMANさんへのお礼をMCし、お礼の一曲として「Departure」を歌唱。。。「Departure」で泣きながらもなんとか歌い切る佐々木さんが素晴らしかった…感情豊かだなあと感じる。

自分は「Empty doll」あたりで泣き始めている。感情の表現力はもちろん、先週のプリチャン単独でも思ったが、まっすぐな視線から放たれるボーカルがまた違った意味で素晴らしい。「酩酊」から「Walkin' Walkin'」など、曲調が広いことも大層印象的だった。「フレンドパスワード」はピアノアレンジで聞けるなど、生バンドの演奏はやはり満足度が高い…。

配信は90分ピッタリで終了。11月にまたイベントがあるようなので、現地イベントであることを期待している。配信を見ると現地に行きたくなる…。

2020.8.1 キラッとプリチャン♪ミュージックコレクション Season.2 発売記念イベント(配信)

配信で書く必要はないかと思っていたが、案外情報量が多かったので記録していく。

1回目(12:00-12:45)

出演者ははやまる、茜屋さん、徳井さん(そらまる先輩)。このメンバーはプリチャンラジオ以来のはず。MCはavexのツルタさん。最初に軽く出演者紹介があって、次に68話のオーディオコメンタリー、最後にコメントと感想を述べ、45分で終了。

全体的な印象は本当にゲーマーズ主催のイベントといった感じ。それを観客抜きで、静かな空間でやっているイメージ。でもはやまるとか音割れするくらいの実況があってよかったし、積極的にコメント入れられててもう、十分にイベントをこなせていたと思う。

自身、生オーコメは2019年のノンシュガー(avex本社)以来だった。68話をのんびり見てみると情報量が多い。ファントミコラボ、髭はやしシルクちゃん、ギャグで立ち回るメルティックとえもちゃん、自然にストーキングする虹ノ咲さん、うさぎのぬいぐるみを入手して崩壊するさら様、突然会場に現れるまりあ、桃山みらいの肩にさりげなく手を乗せるさら様…プリチャンは細かいところに注視していくと、やはり狂気が顔を覗かせる。この回は主線のまりあとすずを含め、他人を思いやる"いい人"しか出てこないのが良い。というコメントがそらまる先輩からあった。

以下、細かい点を箇条書していく。

  • ダイヤモンドスマイルを前の配信ライブで全員で歌えたのが感慨深かった(はやまる)ダイヤモンドスマイルの振り付けやってみたい(そらまる)
  • EDのじゃんけんキラッと!プリチャンで小さく振り付ける(はやまる)
  • てぇてぇ(茜屋さん)→TATA ティーエーティーエー(そらまる)
  • ロケットハートや乙女アテンションで英語発音指導があった。Show timeはなるべく寝ていティブに、123レッツゴォウは「ゴォウ」とゴツく(はやまる)
  • こわしーてー←V系みたいに歌唱スべしと指導(そらまる)

2回目(14:00-14:51)

2回目の方が少し長かった。出演者紹介の後、すぐにオーコメ。オーコメはなんと大阪公演から以下の8曲。

オーコメ中はそらまる先輩を中心に鋭いコメントをたくさんいただく。印象に残ったのを箇条書きで見ると

  • ティエティエ(多数)
  • (セリコが)カメラの鬼、カメラがセリコに合わせている
  • TOKIMEKIの両肘が上下する振り付け、実は家でもやってる(そらまる)
  • TOKIMEKI、かわいい動きにするのがむずかしい、気づくとバキバキになる(はやまる)
    • 元気で良い、キレキレで良い、あどけなさも残しつつ(そらまる)
    • こなれてるとスーパースターさんになってしまう(そらまる)けど、親近感もありつつ(茜屋さん)
  • シアワ星の振り付けは意外に細かくて難しい(茜屋さん)
  • インディビジュアル・ジュエル最後のブレイクは「カンカンカン」とカウントする(茜屋さん)
  • 寝ても覚めてものサビ入りの振り付けやりたい(そらまる)
  • 乙女アテンション、どてんかいめいガッツ←力はいる(はやまる)
  • 喋るときが一番緊張する(はやまる)
  • キューティ・ブレイキンの公演中、ステージ袖で踊ってた(茜屋さん)
    • ステージ裏面白いことになってるから映像化して欲しい(はやまる)
  • インディビジュアル・ジュエルは最終リハで全員合わせる(そらまる)、キラスタもゲネプロで合わせる(はやまる)
  • Melticはずるい(3人)

寝ても覚めても、この一曲とってもセリコの目線の使い方と表情が全く違うことに気づく。やっぱ強いわ…

2020.8.29 a-nation online 2020(配信)

white stageという無料(LINE LIVE)で視聴可能なステージで出演。 視聴者が50000人を超えていてビビる。

ストリーミングが全く途切れなかったり、ステージごと切り替えることで無駄を省いたりとavexらしい大手の強さが垣間見れる。各アーティストで15分程の尺があり、おおよそ3曲ずつのセトリで回していく。avexの先端を担うアーティストだけあって、ジャンルはバラバラだったが実力は高い。そして先鋭ならではの緊張感がある。

開始前、なんとなく水着とスイカをやるのではないかと緊張していた。 14:20からほぼ予定通り開始。衣装はプリチャン単独で初披露したイルミナージュ・ランドの衣装。

セットリストは以下の通り。

  • イルミナージュ・ランド
  • MC、メンバー紹介
  • Break the Blue!!
  • キラッとスタート

3曲入れてちょうど14:35。公演中に視聴者は60000人を超えていた。

全体的にC3AFA TOKYOを思い出すような生歌唱と振り付けの勢いがあった。それまでのアーティストがDJ、バンド、ボーカリストだったため、ダイナミックに動き回るランガちゃんは映えたと思う。 特にBreak the Blue!!の完成度が非常に高かった。振り付けが各個人で全力で振るのではなく、全体として腕の動きが揃っていたのがかなり良かった。 カメラを向けられた瞬間に笑顔が出るもっちーとはやまるがあざとい。 そしてどんなに振り付けが激しくても歌唱がぶれないはやまるが強すぎる。

歌って踊って凄い、かわいいというコメントがMCから述べられていた。 水着とスイカをかなり警戒していたが歌われずセーフ?

ランガちゃんの直後はわーすた様が出演。強い。

2020.9.7 3rdライブツアーの中止告知

21:30 3rdライブツアーの中止告知を確認した。 来年頭で調整している中で結果開催できなくなったということで、今年中の対面イベント開催は非常に難しいことが分かった。

自分は"現地"でのイベントを非常に大事にしている。2020年内は一旦更新を停止する方向で考えている。


と思ったけどやめた。9.9の19時から配信ライブの告知があった。 中止告知や札束での殴り合いを見ていたら意気消沈して消え去りたい気持ちが大きくなったが、後半の雑談を見ていたら、楽しまないのは損ではないかという気持ちになってきた。

配信ライブでは全公演セトリと衣装を変えるとのこと。アーカイブも残らないらしいので、レポートを集中して取ろうかと思う。

2020.9.20 Pripara Friendship 2020 パラダイストレイン!(配信)

当日はプリチャンでオールスター回。脚本はカオスで混乱していたが、ライブシーンで大好きな「プリマドンナメモリアル」が入り、全てを持っていった。地上波で放送するのがもったいないレベル。劇場版をやってほしい。

そして15:00からプリパラ配信ライブ。前日ににの役の大地葉さんが体調不良という告知があった。配信はプリチャン単独と同じくぴあLIVE STREAM。14:30から告知動画配信開始。

始まる前、緊張はしているが、どうにも気持ちがふさぎ込んでいた。告知(プリチャンアルバム+iRis+RGR)動画を3周したら開始。

収録会場は、間違いなくアンフィシアター。

楽曲 感想
ホワット・ア・ワンダ・プリワールド 総キャスト。上からのカメラアングルが珍しくて感動がある。
OPムービー いつものキャスト紹介
ゴー!ゴー!ゴージャス! | 開幕、セレブリティーな流れ。掛け合いでのカメラの射抜き方がよい。手前しゅうか様、奥ちりの画。
Ha Cha Me Chaテレパシー 仲間が増えた…のところで、途中から山北さん(シオン)が乱入。そのままふわりとらぁら追加。(夜)完全にレオナ入ってる。あ!仲間ができた!でCGのようにでてくるのがおもしろい(煌めきが形になったように見える)
トンでもSUMMERアドベンチャー (夜)佐藤さんの表情が柔らかくなってきたかも。昼とかここまで必死にやってる感じだった。涙をこらえていたのかもしれない。。。 配信では表情が目立つ。。
MC 山田さん、伊達さん、朝日奈さん。夜はWITHで。コメント欄がIIZEだらけ。
コノウタトマレイヒ 佐藤さんがライブ初めて出てきたときの衣装(チロリアンフルールコーデ)で歌唱。
ハートフルドリーム 伊達さんと山田さんでやった。にのだけ抜いてやった感じ。だが、にのパートを伊達さんが歌い切る。
Miss.プリオネア / メイクマニー・メイクドリーム 朝日奈さん髪の毛を紫にしておりしゅうか感がとてもある。立ち姿が麗しい。(夜)格好いい。とにかく。横から撃ち抜くカメラがおかしい。表情まで格好いい。「掴み取るだみゃあ!!!」は文字通りの大絶叫。カメラが寄っているのもあって迫力があった。他に細かいところで、右足でテンポを刻んでいるのが格好いいと思っている。
ま〜ぶるMake up a-ha-ha / Brand New Dreamer 茜屋さん芹澤さんVer.、しかもfullを聞くのは久しぶりのはず。夜はのんらぁら。ありありと122話が思い返される。
CHANGE! MY WORLD / Non Dress code これも久しぶり。メイキングドラマでドローン空撮!昼もそうだったけどめちゃくちゃ久しぶりにメイキングドラマがあった。カメラが追うからそれほどシュールにならない。
リバース・ザ・リバース / かりすま〜と☆Girl 田中さんが可愛い…振り付けはそうだ、キラスタと同じだったんだ…いろいろなことを思い出し始める。。。
純・アモーレ・愛 / 嘘つきはのtomorrowの始まり (昼)いつも何かいうところで、自分のスタンドグラスを黙って見つめる演出がすげえ格好いい。カメラには背中しか映らない。
パルプス・ノンフィクション ふわりの新曲。コノウタトマレイヒを聞きながら、ふわりの新曲がほしいとおもっていた。ちょうど今日。そして死んだ。カメラさんが寄ったときに手が震えている事がわかった。アレンジがとてもいい・・・一発目でわかりやすく死ねる・・・。
MC ドレシメンバーで物販紹介。夜はノンシュガー。ペッパーが雨乞いしたり、じゃんけんしたりとカオス。
Giraギャラクティックタイトロープ 端的に言って完成度が高い。後ろの映像とのシンクロが完璧。
スーパーダーリン / hey say 俺の…全宇宙!ジャニーズばりのカメラワークで、正面から狙いまくる。(夜)PVにまんま使える映像技術、カメラワーク、パフォーマンス。WITH単独に行きたくなる。
神曲 / アメイジング・キャッスル 軽快に動き回るアサ姉に元気をもらい続ける。(夜)はちゃめちゃな振り付けがよい・・・・2番モニターの前の歌ってるし…
シュガーレスフレンド / スパイシーホットケーキ 強い曲が連打されている。プリパラは強い。(夜)間奏で約束のテヘペロピタと言った…来年やなあ…
Believe My Dream / ピュアハートカレンダー 涙が止まらない。2人しか写っていないマイドリ、だけども健気にやりきるマイドリに対してどうしても同情を禁じえず涙が止まらなくなった。(夜)山田さん振り付けとてもよかった。キレキレになってた。
ラン♪for ジャンピン! / Get Over Dress-code 続けて強い。山北さんのコンディションが高すぎてまじで素晴らしい。ずっちゃんの画面外で掛け声だしてるの、iRisそのものので強い。(夜)CDを完全に超えていった。ドロレオのハモリ、さき様の絶叫。神アイドルになりたい、という伴奏コメントも泣ける。最大。
HAPPYぱLUCKY! / トライアングル・スター ほぼノータイムでつないでくる。そふぃ様は初曲以来か?(夜)めちゃくちゃ久々にfullだったかもしれない・・・・・・
情報告知 そらみメンバーで。プリチャン単独と本日のライブをBDの販売決定。新アプリ「アイドルランドプリパラ」の告知
感想コメント やはりしゅうか様の立ち姿が麗しい。「磨いておくように」と言われる。山田さんが今までで一番喋ってた。ガァルマゲドンは演技をやりきってそのまま退場していった。面白かった。ドレシも入退場からガァルマゲドンを真似して続く。(夜)しゅうか様、ぽわん持参。夢川、3年くらいしゅうかとのデュエットが欲しいなあと言ってる、まじか。9.20はトリコロール結成の日。。。。新曲を待ってる人がいて。。。というコメント。佐藤さんが泣いてしまう・・・・
Crew-Sing! Friend-Ship make it!かと思った。退場時、カメラに向かって一言ずつ。しゅうか様、ひびき様は無言で投げキッスもあり。麗しい。

昼公演は15:05くらいから始まり、16:55くらいで終わり。約2時間。配信途切れは殆どなかった。たまにブロックノイズが乗るくらい。 夜公演は告知が2周してアルバムが終わったところで定刻2分前で開始までしばらくお待ち下さいの画面がでる。ほぼ定刻スタートだった。

客席に大きめのモニターが設置されており、そこにカンペに映されていて笑う。ドローンで空撮したりカメラマンが寄ってたり。演者の替わりにカメラでダイナミックにしている部分もたくさんあった。広いステージをより使ってた印象。

終わった後、楽しいという感情だけが残った。これはいつものプリパラライブで受けた感情そのものだ。

告知も含めて、プリパラには勢いがある…。来年以降のコンテンツ継続も約束されたし。プリチャン、そしてランガちゃんはどうなるだろうか。9/27の告知を心して待つ。

ロスレス音声コーデックの開発メモ

ロスレス音声コーデックの開発メモ

技術書典7に向けたロスレス音声コーデックの作成日誌。

要件

  • ロスレス
  • 16bit, 24bit深度
  • 192kHz
  • 16ch
  • ストリーミング
  • ブロック単位に分ける
  • 各ブロックの破損確認(CRCでOK)

まずは、16bit, 48k, 1ch, ブロック単位分割でできるのが良いのでは?

比較研究

色々なロスレス音声コーデック

手法妄想

2018.10.6

  • MPEG4-ALSを真似てPARCORとLong-term PARCORを組み合わせる。Long-term PARCORは最初のPARCORの誤差をFFTしてピークに出た周波数に対応するラグで予測する。

  • FLACはどうもゴロム符号化(→ライス符号化だった。高速化の為)を使用している。より良いエントロピー符号化を使用すべき。

  • 高次の自己相関を使えないか?高橋治久教授の。

  • LPCの計算はつまるところ標本自己相関の計算負荷に尽きる。ウィーナ・ヒンチンの定理を使用して早くできないか?真のパワースペクトルは計算できないことは知っているが、ゼロ埋めか平均回数を多くすることで近似精度を上げられないか?

  • この話はエンコード時にのみ起こる問題なので、置いといていいか。

日記

2018.10.14

下回りの整備をしていた。wavファイル読み込みモジュールと、LPC解析(+PARCOR係数計算、音声合成)まではいけている。

次にやるべきは単純なロスレス音声コーデックを作ること。ブロック分割しないで係数を出し、係数と予測誤差を記録してみる。恐らく量子化誤差が大きな敵になるであろう。

2018.10.21

家に帰って早速エントロピー計算モジュールとLPCのnan問題にあたっていた。エントロピー計算モジュールはOK。頻度の計算に二分木を使用。nan問題はfloatの精度の問題だった。サンプル数を増やしたとき、自己相関関数の値に誤差が出ているのが原因。内部的な結果は全てdoubleで持つように修正することで解決。

floatを簡単に整数量子化して予測するルーチンも完成している。 改めて単純なロスレスコーデックを作るべし。

2018.10.23

音声処理とDSPという本を読んでいたら、LSPはPARCORと比べ(ロッシーだけど)60%の情報量圧縮ができるとの文面あり。 恐らく量子化感度に鈍いというのと補間が効くのが理由?LSPも試してみたい。

2018.10.28

音声符号化(守谷)をチラチラ見ている。面白い結果が少し出ているので精査したい。特にPARCOR係数から予測利得(予測によって残差利得がどれくらい減ったか)が勘弁に計算できるのは大きい。係数評価に使えそう。

いつもの海ベローチェで作業。一番簡単なロスレスコーデックが完成した。

仕様:

  • 入力wav全体を一つのPARCOR係数で予測符号化
  • PARCOR係数の次数は10, 係数は全て[-1,1]の範囲で16bit線形量子化(符号化する時は浮動小数点数を15bit左シフト)
  • 残差は適応型ハフマンで符号化

フォーマットは以下:

サイズ(bits) 内容 補足
32 シグネチャ "SolA" Soleil Aikatsuの略(Sound of lossless Audioの略)
16 フォーマットバージョン番号 バージョン1では1。フォーマットに変更がある度に上げる
8 チャンネル数 足りるでしょ…(怠慢)
32 サンプル数 全チャンネルでサンプル数は同一とする
32 サンプリングレート 足りるでしょ…(怠慢)
8 サンプルあたりビット数 wavに戻すときに必要
8 符号化(復号)に必要なビット数 適応型ハフマンの初期化に必要
チャンネル数 * 16 * 11 PARCOR係数 各チャンネル毎のPARCOR係数[-1,1]の数値を16bit固定小数点数で符号化
不定 ハフマン符号化された残差 チャンネルインターリーブではない。1ch目の符号化された信号列先頭, ..., 1ch目の符号化された信号列末尾, 2ch目の符号化された信号先頭, ..., 2ch目の符号化された信号末尾,...という並び。

ブロック化するにあたり、ストリームを意識するのでCRCチェックを入れたい。ファイル全体ではCRC32でいいけど、データブロックの破損チェックはCRC16でいいかなと。

CRC16の実装で大ハマリ。CRC16には各種の規格がある...とりあえずCCITT-FALSEの実装を目指す... HCAはCRC16-IBM(多項式0x8005)だった。揃えるべきかも。

色々CRC16について見ていて、良質な纏めは以下(それ以外は どの CRC16を実装したのかわからない):

Linuxは流石に嘘ついてなさそうだからリファレンスに:

2018.11.3

version2.のフォーマットを以下のようにしてみた。(ドラフト)

SolAヘッダ

サイズ(bits) 内容 補足
32 シグネチャ "SolA" Soleil Aikatsuの略(Sound of lossless Audioの略)
32 一番最初のデータブロックまでのオフセット(自分除く) 240bit = 30byteSのはず
16 フォーマットバージョン番号 2
8 チャンネル数 足りるでしょ…(怠慢)
32 全サンプル数 足りるでしょ…(怠慢)
32 サンプリングレート 足りるでしょ…(怠慢)
8 1サンプルあたりのビット数 wavへの復元で必要
8 符号化(復号)に必要なビット数 適応型ハフマンの初期化に必要
8 PARCOR係数次数 全ブロックで同一
32 SolAブロック数
32 SolAブロックあたりの最大サンプル数 ビットレート実現のため末尾以外は最大サンプル数に揃える。
32 ヘッダ以降のCRC32値
32 ヘッダのCRC32値(自分除く)

SolAブロック

サイズ(bits) 内容 補足
8 同期コード0xFF
32 次のデータブロックまでのオフセット
16 これ以降のフィールドで、次のブロック先頭までのCRC16値
32 このブロックのサンプル数
16 * チャンネル数 * PARCOR係数次数 PARCOR係数
不定 適応型ハフマン符号化された残差 チャンネルインターリーブではない。1ch目の符号化された信号列先頭, ..., 1ch目の符号化された信号列末尾, 2ch目の符号化された信号先頭, ..., 2ch目の符号化された信号末尾,...という並び。

フォーマットはOK。やるべきはメモリ上での解析実装かも。 メモリ上に読み込まれた要素に対してヘッダの解析とブロックのデコードを行うように実装する。そうなると適応型ハフマン、もしくはBitStreamをメモリ上で動かす必要がある。できるか…?

MemoryBitStreamを作るか、BitStreamを機能拡張するかに分かれる。恐らくBitStreamを機能拡張して、今までと同じ操作で透過的にメモリに書き読みできるのがスマート。この期にテスト追加しとく。

2018.11.25

メモリ上の書き込み/読み込み形式で復号ができず(同期コードをうまく発見できない不具合あり)、ひとまずファイル書き込み式で実装した。それでも復号に失敗するときがあり、原因を追っていたところ適応型ハフマンの量子化ビット数が足りないことが原因であることがわかった。

適応型ハフマンのビット数を増やすことで復号が上手く行くことを確認した。が、符号化のサイズと負荷が激増。ハフマン木が大きくなったのが原因。各ブロックごとに最大誤差を求めてビット数を変える事が考えられるが、それは等ビットレート(負荷変動最小化)に反する。

こうなるとやはりゴロム(ライス)符号化を試さざるを得ない印象を受ける。バージョン3としてゴロム符号化を使う。

version3のフォーマットは以下:

SolAヘッダ

サイズ(bits) 内容 補足
32 シグネチャ "SolA" Soleil Aikatsuの略(Sound of lossless Audioの略)
32 一番最初のデータブロックまでのオフセット(自分除く) 240bit = 30byteSのはず
16 フォーマットバージョン番号 3
8 チャンネル数 足りるでしょ…(怠慢)
32 全サンプル数 足りるでしょ…(怠慢)
32 サンプリングレート 足りるでしょ…(怠慢)
8 1サンプルあたりのビット数 wavへの復元で必要
8 ゴロム符号のパラメータ 全ブロックで同一。負荷が変わらないのならば、ブロックごとに変えることも検討。
8 PARCOR係数次数 全ブロックで同一
32 SolAブロック数
32 SolAブロックあたりの最大サンプル数 ビットレート実現のため末尾以外は最大サンプル数に揃える。
32 ヘッダ以降のCRC32値
32 ヘッダのCRC32値(自分除く)

SolAブロック

サイズ(bits) 内容 補足
8 同期コード0xFF
32 次のデータブロックまでのオフセット
16 これ以降のフィールドで、次のブロック先頭までのCRC16値
32 このブロックのサンプル数
16 * チャンネル数 * PARCOR係数次数 PARCOR係数
不定 ゴロム符号化された残差 チャンネルインターリーブではない。1ch目の符号化された信号列先頭, ..., 1ch目の符号化された信号列末尾, 2ch目の符号化された信号先頭, ..., 2ch目の符号化された信号末尾,...という並び。

ゴロム符号で復号が失敗する…ワイル符号で上手く復号できることから、ゴロム符号にバグがあるとしか…デバッグ中。…してたら、Golomb_GetCodeの結果を一回変数に受ける必要があるみたい。完全に謎。

        uint64_t bitsbuf;
        bitsbuf = Golomb_GetCode(strm, golomb_m);
        residual[ch][smpl] = UINT32_TO_SINT32(bitsbuf);
        residual[ch][smpl] = UINT32_TO_SINT32(Golomb_GetCode(strm, golomb_m));

→マクロに展開すると展開された分読んじゃうから。

また、ワイル符号の圧縮率が悪い!これはブロック先頭部分の誤差を出力しているからかも...→やったけど微減。

2018.11.29

ゴロム符号を使ったときのバグを直した。それでエンコード時のエントロピーを見ていたら、エントロピーの減少を確認したが、まだ削れそうな予感がある。

Monkey Audioでは単純な差分符号化を行っている...参考にして、差分符号化でエントロピーが減るか観察してみる。

→手元のデータではエントロピーが増えた。。。

ゴロム符号パラメータの最適化手法を探した。

どうも次の式を満たす最大の$k$が最適パラメータのようです($2k$をパラメータに使う。ライス符号のみで有効なので注意。):

$$ 2^{k} \leq \mu + f^{\ast} $$

$\mu$は非負整数の平均、$f^{\ast}$は理論(実験かも…)によって求められた0.382という値で、49/128, 34/89, 3/8で近似できる。$f^{\ast} = A / B, \mu = S / J$とおく($S$:和、$J$:標本数)と、不等式は、

$$ JB \times 2^{k} \leq BS + JA $$

と書ける。$k$は次のプログラムで求まる

for (k = 0; ((J * B) << k) <= B * S + J * A; k++) ;

$f^{\ast} = 49/128$とすれば、$A=49,B=128$より、

for (k = 0; ((J * 128) << k) <= 128 * S + J * 49; k++) ;

さらに128をシフトに置き換えて

for (k = 0; (J << (k + 7)) <= (S << 7) + J * 49; k++) ;

(他にもDNNでパラメータ調節するのがあったけど死ねとしか思えなかった。)

ライスでは2の冪が前提だが、ゴロムでは次でいけるのでは?(理論的根拠なし):

for (k = 1; ((J * k) << 7) <= (S << 7) + J * 49; k++) ;

早速試してみる。ブロックごとにゴロム符号パラメータを調節してみた。単純なサイン波はあんまり結果が良くないように見える。と思ったら、実践的音声でかなりのパフォーマンス改善が見られた…嘘だろ…?エンコード速度が激減し、エントロピーもいきなり8(理想値)に近くなった。

俺の声では

-rw-r--r--@  1 *  staff     50360 Nov 30 00:05 kisaragi_chihaya.ape
-rw-r--r--@  1 *  staff     60808 Nov 26 23:26 kisaragi_chihaya.flac
-rw-r--r--@  1 *  staff     54369 Nov 30 00:05 kisaragi_chihaya.sol
-rw-r--r--@  1 *  staff    109612 Nov 26 23:26 kisaragi_chihaya.wav

桃山みらいのワン・ツー・スウィーツでは

-rw-r--r--@  1 *  staff  38305036 Nov 30 00:04 one_two_sweets_offvocal.ape
-rw-r--r--@  1 *  staff  40645286 Nov 30 00:03 one_two_sweets_offvocal.flac
-rw-r--r--@  1 *  staff  43886946 Nov 30 00:03 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  54566444 Nov 30 00:03 one_two_sweets_offvocal.wav

山下達郎のSPARKLEでは

-rw-r--r--@  1 *  staff  28436216 Nov 30 00:01 SPARKLE.ape
-rw-r--r--@  1 *  staff  30704598 Sep 17 16:06 SPARKLE.flac
-rw-r--r--@  1 *  staff  34847916 Nov 30 00:01 SPARKLE.sol
-rw-r--r--@  1 *  staff  49080364 Sep 17 16:06 SPARKLE.wav

短いモノ音声でflacに勝った。工夫を重ねていきたい。 ステレオはmonkey audioがやっているようなMS変換が有利に働くかも。

ひとまずVersion.3は可変ゴロム符号デコーダを作ったらfixとしたい。

2018.11.30

結果からも明らかだったけど、上の論文曰く、平均が1未満のときはランレングス符号化が効率的。

ゴロム符号のパラメータを入れたフォーマットは次:

SolAヘッダ

サイズ(bits) 内容 補足
32 シグネチャ "SolA" Soleil Aikatsuの略(Sound of lossless Audioの略)
32 一番最初のデータブロックまでのオフセット(自分除く) 240bit = 30byteSのはず
16 フォーマットバージョン番号 3
8 チャンネル数 足りるでしょ…(怠慢)
32 全サンプル数 足りるでしょ…(怠慢)
32 サンプリングレート 足りるでしょ…(怠慢)
8 1サンプルあたりのビット数 wavへの復元で必要
8 PARCOR係数次数 全ブロックで同一
32 SolAブロック数
32 SolAブロックあたりの最大サンプル数 ビットレート実現のため末尾以外は最大サンプル数に揃える。
32 ヘッダ以降のCRC32値
32 ヘッダのCRC32値(自分除く)

SolAブロック

サイズ(bits) 内容 補足
8 同期コード0xFF
32 次のデータブロックまでのオフセット
16 これ以降のフィールドで、次のブロック先頭までのCRC16値
32 このブロックのサンプル数
16 * チャンネル数 * PARCOR係数次数 PARCOR係数
16 * チャンネル数 ゴロム符号のパラメータ
不定 ゴロム符号化された残差 チャンネルインターリーブではない。1ch目の符号化された信号列先頭, ..., 1ch目の符号化された信号列末尾, 2ch目の符号化された信号先頭, ..., 2ch目の符号化された信号末尾,...という並び。

デコーダやっつけで作ったけどだめだ!なぜかデコード結果が一致しない!サイズは一致するけど途中で差分が出る!

2018.12.1

PARCOR係数の非線形量子化に先立ち、いろんな音のPARCOR係数分布を見てみた。

f:id:aikiriao:20190929123143p:plain

f:id:aikiriao:20190929123232p:plain

f:id:aikiriao:20190929123256p:plain

見れること
  • 1次成分は1の近傍になる
  • 2次成分は-1の近傍になるが、偏りは1次ほどではない
  • 高次になるに従い、ほぼ振動しながら0に近づく。

--

バグを直す。追っていたところ、

  1. 予測誤差計算時に32bit整数でオーバーフローしていた
  2. 計算時に一旦64bit整数に受けることで修正。
  3. 予測誤差先頭出力時に入力wavと同一bit数を超える数値が出ていた(16bit wavで69410を出そうとした)
  4. 差分は2倍の値域が出るので+1bitして出力することで修正。

2.については、修正できたが先頭を(ゴロム符号化しない)生のビットで出力すること自体細かな最適化にしかなっていないので、一旦先頭を生のビットで出力するのをやめることにした。これにより圧縮率は悪化するが、それほど大きなダメージではない。

圧縮効率を上げるアイデアを挙げると:

  • PARCOR係数を非線形量子化する
  • 分布を見れば分かるようにPARCOR係数の分布には偏りがある。偏りに合わせて非線形量子化すれば予測精度が高まる。『音声の高効率符号化』では等ひずみとなるビット数がかなり減ったとのこと。
  • ビット割当ても低次係数には多く割り振る。

  • MS処理を行う

  • M = L + R, S = L - R として処理する
  • Mでは逆相関が除去され、Sでは正相関が除去される。

  • 無音部でランレングス符号化を使う

  • ゴロム符号のパラメータ計算のときに正値化した差分信号の平均を計算する。平均が1より小さければ無音のはず。ランレングスで符号化する。
  • ビットレート原則が崩れるかも...

  • ロングターム(ピッチ情報)を使う

  • ピッチ解析を行い、その長さによる予測符号化を行う。MPEG4-LSで使われている手法。

ロングタームは少し重たそうだけど、他はすぐにやれそう。12/2はPARCOR係数の非線形量子化に取り組む。

2018.12.2

非線形量子化を検証中...しっかしまだ非線形量子化のイメージが掴みきれてない。gnuplotでグラフを出してみる。

f:id:aikiriao:20190929123320p:plain

set samples 41
set xtics 0.2
set ytics 0.2
set grid
set xrange[-1:1]
set yrange[-1:1]
plot tanh(x * pi) w p, atanh(x) / pi w p, asin(x) / (pi/2) w p, sin(x * (pi/2)) w p, x w p

求まった係数値$x \in [-1,1]$に対して、$\tanh^{-1}(x)$を計算すると$-1,1$の近傍で粗くなるようにしか見えない...(それどころか$\tanh^{-1}(1) = +\infty$だし...)もしかして$\tanh(x)$の誤りでは...?

→いや、合ってる。$\tanh^{-1}(x)$で変換をかませると、$0$近傍の値はほとんど同じになる。すなわち近い値が割り当てられやすくなる。逆に$-1,1$近傍では急激に値が変化するから少しの$x$のずれで全く違う値が割り当てられる。即ち$-1,1$近くの情報量が多くなる。

rubyで符号化関数を試作してみた。

# f_valは[0,1]の値を期待
def encode(n_bits, f_val)
    max = (1 << n_bits) - 1
    return max if f_val >= max.to_f / (1 << n_bits)
    return ((max * Math::atanh(f_val)) / Math::atanh(max.to_f / (1 << n_bits))).to_i
end

→除算を行っているので桁落ちが無視できない...

1近傍で$+\infty$にすっ飛んでるのが危険。$\tanh(\pi x)$のテーブルを作っておき、範囲検索で正規化値に該当するインデックスを符号化するのが良さそう。

# テーブル作成
table = Array.new(65536).map!{ 0.0 };
0.upto(65535) {|i| table[i] = Math::tanh(Math::PI * i.to_f / 65536); }
# 符号化関数
def encode(table, f_val)
    raise if f_val > 1.0
    inx = table.index {|v| v >= f_val }
    return (table.size-1) if inx.nil?
    return inx
end
# 復号関数
def decode(table, code)
    return 1.0 if code >= table.size
    return table[code]
end

$1$近傍で取りこぼした(区間$[65535/65536,1.0]$の値)値が多いけど、これは量子化故仕方がないよな...?

irb(main):294:0> 0.upto(10) {|v| puts "#{v.to_f/10}- #{encode(table, v.to_f / 10)}" }
0.0- 0
0.1- 2094
0.2- 4230
0.3- 6457
0.4- 8838
0.5- 11459
0.6- 14460
0.7- 18093
0.8- 22918
0.9- 30712
1.0- 65535

0.9から1.0の間に約35000個割り当てていることが分かる。

さて、C言語での実装を考える。標準ライブラリ関数のtanhはプラットフォーム依存でどんな結果を返すか分からないので、自前でtanhを実装したい。自前tanhは奥村先生の「標準アルゴリズム辞典」を参考にしようと思ったが、実装内部でexpを使っているので結局プラットフォーム依存であることを免れない。

やはりテイラー展開を使うしか...いや$0$近傍以外での誤差がやばいし。

悩んだところ、tanhの返す値が$1/65536\approx 1.526 \times 10^{-6}$より大きな誤差となるプラットフォームは少ないと考え、ナイーブにtanhでテーブルを作ることにした。

tanhの$-1,1$付近の誤差がでかいことに悩んでたら、tanhってそもそもシグモイド関数と同じように$-1,1$に漸近するするだけで通過しないことに気づいた。それじゃだめだ。変換関数を再検討。必ず$(-1,-1), (1,1)$を通るようにしたい。

2018.12.4

悩んでいたら、良いページがあった

結論、以下の曲線で決まり。$a$をパラメータとして、

$$ t(x) = \frac{1}{2} \left[ 1 + \frac{1 - \exp(-ax)}{1 + \exp(-ax)}\frac{1 + \exp(-a)}{1 - \exp(-a)}\right] \ y(x) = 2t^{2}(x)(3 - 2t(x)) - 1 $$

f:id:aikiriao:20190929123351p:plain

aは3か4かなあ。→-1,1の近傍で32bit数値に差が出る3.0を採用。極端だから2.0に訂正。(2018.12.4)

テーブル引きによる非線形変換を使うために、PARCOR係数の計算実装を見ているが、固定シフトPARCOR_COEF_FIXED_SHIFTが15よりも大きいと戻らない現象を観察している。これは多分16bit値を15bitよりも大きく左シフトすると32bit値として表現できないから...。 フィルタ計算のときには64bit値で持つ必要があるかも。

2018.12.4

係数シフト量PARCOR_COEF_FIXED_SHIFTを大きくする修正。大きくして戻らなくなった原因はPARCOR係数の出力ビット数。今までは16bitで出していたが、それでは15bit(+符号1bit)までしか記録できない。

修正して様子を見たところ5分尺データの圧縮率が改善した。(逆に短いデータでは悪化)。これはPARCOR係数の精度改善とその保存コストのトレードオフだろう。

非線形変換しようとしているが足踏み。テーブル引きにすることを考えると、PARCOR_COEF_FIXED_SHIFTビットサイズのテーブルを保存する必要がある...。31bitだと超巨大になる。

これに対するアイデアは、16bitで記録するけど、テーブルによって32bit値に拡張(補完)するというもの。(非線形変換しないときは線形補間;単純な左シフト)だから記録に使うビット幅(16bit)と計算時にシフトする量(31bit)に違いが出る。というかこれしかいい方法がなさそうに見える。

テーブル引きによる方法と、生の31bit保存でどちらが圧縮率が良いかは検証する必要がある。

2018.12.5

非線形テーブル対応。効果あり。

-rw-r--r--@  1 *  staff     54344 Dec  6 00:05 kisaragi_chihaya.sol
-rw-r--r--@  1 *  staff  33292840 Dec  6 00:07 SPARKLE.sol
-rw-r--r--@  1 *  staff  42188584 Dec  6 00:05 one_two_sweets_offvocal.sol

早速単純な31bitシフト時と比較する。結果、非線形テーブルの方が良い結果:

-rw-r--r--@  1 *  staff     54653 Dec  6 00:17 kisaragi_chihaya.sol
-rw-r--r--@  1 *  staff  33424610 Dec  6 00:16 SPARKLE.sol
-rw-r--r--@  1 *  staff  42335099 Dec  6 00:17 one_two_sweets_offvocal.sol

最初に算出されるPARCOR係数がfloat精度なのがまだ気になる。。→取り急ぎdoubleに変えたけどさしたる変化なし(それどころかSPARKLE.wavは1バイト増えた...)。もしかして[-1,1]のfloatは情報が落ちないのか?でも、精度的には嘘がないので今後はdoubleでいく。

次はMS処理、もしくはランレングス?MS処理は劇的に効きそう。

2018.12.16

本日はMS処理を入れてみる。これで数MBは削れてほしい…。MS処理はブロック毎に変えることはしない。全体で同一の処理方式を取るようにする。ヘッダに修正が入る:

SolAヘッダ

サイズ(bits) 内容 補足
32 シグネチャ "SolA" Soleil Aikatsuの略(Sound of lossless Audioの略)
32 一番最初のデータブロックまでのオフセット(自分除く) 240bit = 30byteSのはず
16 フォーマットバージョン番号 4
8 チャンネル数 足りるでしょ…(怠慢)
32 全サンプル数 足りるでしょ…(怠慢)
32 サンプリングレート 足りるでしょ…(怠慢)
8 1サンプルあたりのビット数 wavへの復元で必要
8 PARCOR係数次数 全ブロックで同一
4 チャンネル毎の処理方法 今は何もしないか、MS処理するかのどちらか
32 SolAブロック数
32 SolAブロックあたりの最大サンプル数 ビットレート実現のため末尾以外は最大サンプル数に揃える。
32 ヘッダ以降のCRC32値
32 ヘッダのCRC32値(自分除く)

やった…が速報で結果が渋い…。ロスレスになったら結果をば…。 と思ったら元に戻らず、ハマる。間違いなくどこかでクリップしているのが原因だが、根本原因が追えず。これからピアノ。

2018.12.19

MSを使ったときに戻らない原因を調査。簡単なループのミスだった。。。(Sideが決まる前に出力計算していた)

ロスレスになったけどいかんせん圧縮率が悪化。理由はMidをL+Rで作っているからでダイナミックレンジが広がって結果誤差増大につながったものと思われる。

対応は、wavpackが如く、Mid=(L+R)/2とする。これにより最下位1bitの情報が落ちるが、Side=L-Rの結果から、Sideの最下位1bitがMidの最下位1bitと一致することを用いてもとに戻せる。次はこれを試す。

後、高次のPARCOR係数も非線形量子化したい。

2018.12.22

秋葉原製作所なるところで作業してみる。3時間で1250円。 MS処理をうまくやるのが今日の目標。

M=(L+R)/2としたときにどうしても戻らなく、苦戦していた。flacのエンコーダソースを見ていたところ、全てをシフト演算でやりきっていたので真似をしたら何と元に戻った。原因は除算による0方向の丸め

            for(i = encoder->private_->current_sample_number; i <= blocksize && j < samples; i++, j++) {
                encoder->private_->integer_signal[0][i] = mid = side = buffer[k++];
                x = buffer[k++];
                encoder->private_->integer_signal[1][i] = x;
                mid += x;
                side -= x;
                mid >>= 1; /* NOTE: not the same as 'mid = (left + right) / 2' ! */
                encoder->private_->integer_signal_mid_side[1][i] = side;
                encoder->private_->integer_signal_mid_side[0][i] = mid;
            }

NOTE:に注目。実例で行くと、L=-741, R=322, M=L+R=-419のとき、(L+R)/2=-209だが(L+R)>>1=-2100xFFFFFE5D(-419) >> 1 = 0xFFFFFF2E(-210)となるから、下位1bitをSideから補えば元に戻る!

特に著しいのはL+R=-1のときで、(-1>>1)=-1だからMの符号の情報が飛ばないのがうまくいく理由。単純な除算だと(L+R)/2=0のときにMの符号が分からなくなってしまう。

早速修正を取り入れる:

-rw-r--r--@  1 *  staff  41939426 Dec 22 18:02 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  32534982 Dec 22 18:04 SPARKLE.sol

数百KB単位の削減になった。

2018.12.27

ロスレス音声ではLSPが気になる。試すだけはしてみないと。

2019.1.2

実家でLSP係数の計算を試している。と言っても理論抜きでLPC係数からLSP係数に変換するのを試している。

LSP係数は多項式P,Qの根を求めることで得ている。ここではDFTした結果のゼロ点を探すことでLSP係数を求めている。

LPC <-> LSPの相互変換はできた感じ。しかしワーク領域がでかい(FFT使うから)ため、変換用ハンドルを新しく作った。

さて、これからやりたいことを列挙すると次のようになる:

  • 窓を試す
  • LPC, PARCOR係数を求める際に窓をかけてから処理を行う。
  • 解析精度が上がることで誤差が減るかも。

  • 高次係数も非線形量子化する

  • ゴロム符号パラメータをサンプル単位で変える

  • wavpackではこちらの方式でやっている。試す価値はある。

  • LSP係数で保存する

  • LSP係数は誤差の感度が低く、PARCOR係数と比べて等ビットレートでより良い音質を実現しているとの報告がある。
  • LSPの前向き誤差計算は複雑なので却下。ここでは、LSP係数<->LPC係数の相互変換を使って、係数保存の際にLSP係数を使用することを考える。

  • 無音部でランレングス符号化を使う

  • ゴロム符号のパラメータ計算のときに正値化した差分信号の平均を計算する。平均が1より小さければ無音のはず。ランレングスで符号化する。
  • ビットレート原則が崩れるかも...

  • ロングターム(ピッチ情報)を使う

  • ピッチ解析を行い、その長さによる予測符号化を行う。MPEG4-LSで使われている手法。

2019.1.5

本日はいつもの海沿いベローチェで作業。窓掛けを試すのと、LPCモジュールの出力一致確認をおこなうテストを追加したい。

窓掛け…簡単にハン窓で試したら効果あり!

-rw-r--r--@  1 *  staff  41586969 Jan  5 15:38 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31990780 Jan  5 15:39 SPARKLE.sol
-rw-r--r--@  1 *  staff     54991 Jan  5 15:44 kisaragi_chihaya.sol

ブラックマン窓の結果は以下。ハン窓より軒並み悪い。

-rw-r--r--@  1 *  staff  41595943 Jan  5 15:49 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  32015488 Jan  5 15:50 SPARKLE.sol
-rw-r--r--@  1 *  staff     55317 Jan  5 15:50 kisaragi_chihaya.sol

再び数百KBの削減(短い音声では増加...)。結果をまとめると:

窓の種類 ワン・ツー・スウィーツ SPARKLE 俺の声
矩形窓(窓なし) 41939426 32534982 54345
ハン窓 41586969 31990780 54991
ブラックマン窓 41595943 32015488 55317
サイン窓 41575639 31957294 54468
Vorbis 41580579 31975238 54785

サイン窓を採用する。Princen-Bradley条件(完全再構成条件)を満たす窓が良いのか?

テスト書こうと思ったけど時間が中途半端(19:00閉店で今17:42)。PARCORの高次係数の非線形量子化を検討する。

単純には低次非線形量子化関数の逆関数でいいかなと思ったけど、非常に複雑になりそうだったから一旦やめて、単純な関数から見る。

余談:その後プレエンファシスを試すも性能悪化。

-rw-r--r--@  1 *  staff  47930310 Jan  5 22:49 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  36947366 Jan  5 22:54 SPARKLE.sol
-rw-r--r--@  1 *  staff     65086 Jan  5 22:59 kisaragi_chihaya.sol

2019.1.8

高次成分の非線形量子化を試みる。変換曲線は、ロジット関数をベースに、必ず$(-1,-1), (1,1)$を通過する曲線を作る。作り方は、まず$2 * sigmoid(x) - 1$として値域を$(-1,1)$に制限してから、$sigmoid(1)$で割ることで$(-1,-1), (1,1)$を通過するようになる。この関数は$a$をパラメータ、$B=\frac{1 + \exp(-a)}{1 - \exp(-a)}$として、$y = B \frac{1 - \exp(-ax)}{1 + \exp(-ax)}$。これを$x$について解けば、得られた曲線式は、$y = \frac{1}{a} \left{ \log(B + x) - \log(B - x) \right}$。

いろんな$a$に対してグラフを書いてみると:

f:id:aikiriao:20190929123415p:plain

a=4,5,6あたりが狙い目?ひとまず5で様子見。

2019.1.9

高次成分もロジット関数で非線形量子化したけど...効果が限りなく薄いどころか効率悪化も見られた...

-rw-r--r--@  1 *  staff  41575637 Jan 10 00:34 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31957302 Jan 10 00:34 SPARKLE.sol
-rw-r--r--@  1 *  staff     54469 Jan 10 00:35 kisaragi_chihaya.sol

そもそも、高次成分も精度良く記録する方針が間違ってる?低次成分に多くのビットを割り当てた方が良い方針かも。一旦高次の非線形量子化は取り下げる。

2019.1.10

低次係数に32bitを割り当ててみる。...書いていて思ったが、そろそろ圧縮の検証(元に戻るか?+圧縮率計測)プログラムを作るべきかも。

32bitの結果...悪化。

-rw-r--r--@  1 *  staff  41615559 Jan 10 23:02 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31993291 Jan 10 23:06 SPARKLE.sol
-rw-r--r--@  1 *  staff     54554 Jan 10 23:08 kisaragi_chihaya.sol

厳しい。ビット割当の試作は一旦置いておく...。

ゴロム符号のパラメータをサンプル単位で切り替える対応をやってみる。更新式はwavpackのものをぱくって、以下のようにした。

    /* 各チャンネルごとにゴロム符号化 */
    for (ch = 0; ch < num_channels; ch++) {
      uint32_t golomb_param = golomb_m[ch];
      uint32_t res_code;
      for (smpl = 0; smpl < num_encode_samples; smpl++) {
        res_code = SINT32_TO_UINT32(residual[ch][smpl]);
        Golomb_PutCode(strm, golomb_param, res_code);
        if (res_code >= golomb_param) {
          golomb_param += (golomb_param + 127) >> 7;
        } else {
          golomb_param -= (golomb_param + 126) >> 7;
        }
      }
    }

wavpackでは、更に急激な誤差変動対策が入っている。連続した1は15個までしか続かないようになっている。それ以上はElias符号化する。)

すると、やはりというか…性能改善。長い音源で500KBくらい減っているし、短い音源でも効果あり。 FLACとかMonkey's Audioの適応式も見てみたい。後少し気になったのが符号付き整数を符号なしに変換する式。偶数が正で奇数が負の式だけど、もしかしたら幾何分布に従ってないかもしれない。上手く変換すれば減りそう...というか、符号ビット+絶対値(負数は+1して符号反転すると◎。wavpackに書いてあった)の方が絶対値の頻度的に有利かも。

2019.1.11

ワン・ツー・スウィーツの1ch目の500000-550000サンプルにおける符号の頻度を調べてみた。

f:id:aikiriao:20190929123436p:plain

青線は偶数を正、奇数を負とする変換、橙線は絶対値(負数は+1して符号反転)して得られた分布。橙が有利なのは以下の点で明らかだろう:

  • 小さい値の頻度が高い
  • より幾何分布に近い

これに符号ビットを1bit付加しても、おそらく効率よく圧縮できるだろう。3連休はこれを試す。

...やっつけで、符号1bit+絶対値でやってみたのだが、増加...

-rw-r--r--@  1 *  staff  41280406 Jan 12 00:28 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31399579 Jan 12 00:28 SPARKLE.sol
-rw-r--r--@  1 *  staff     53348 Jan 12 00:29 kisaragi_chihaya.sol

符号bitの1bitが馬鹿にならないかも。ワン・ツー・スウィーツは2x13641600=27283200サンプルあるが、全てに符号bitをつけると27283200bit = 3410400byte。約3.4MBが符号ビットになっているので、符号ビットの圧縮が次?2値符号化だからランレングスする? 符号ビットを抜いたら37870006バイトで整合性あり。

TODO:

  • 符号ビットのランレングス?符号化
  • 上のグラフから分かると思うけど、絶対値のピークは0でないことがわかっている(→大嘘ヒストグラムの作り方を間違っていて0が抜けていた。0にピークがある。)。ピークを0にシフトして符号化する。シフトして負になる部分は別の符号を使う。

2019.1.12

符号ビットの圧縮を試す。ランレングス的に、符号の切り替わりのときだけ1を出力するようにしてみる。そうすることで確実に減る(減らないのは正負が交互に出るときだけ)。

すると、flacを超え、当初の目的であるワン・ツー・スウィーツ40MBを切った。

-rw-r--r--@  1 *  staff  39463779 Jan 12 15:39 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  29681677 Jan 12 15:40 SPARKLE.sol
-rw-r--r--@  1 *  staff     50121 Jan 12 15:42 kisaragi_chihaya.sol

短い素材についてはMonkey's Audioを超えている。また、符号ビットはワン・ツー・スウィーツで1593773byteになっており半分以下になっている。

復号ができればいけるが、ゴロム符号に上記のビット列を入れたときにどうするか...。ゴロム符号前半のunary符号部分で切り替わりを表現する?

考えたが、どうやってもunary符号部分が不定な0の連続になっているので、切り替わりの1を挟む余地が無いことに気付いた。PackBits的にやらざるを得ない...やったら増えた。最大ランレングス長を3としたPackBitsでこんな感じ。

-rw-r--r--@  1 *  staff  42793987 Jan 12 17:50 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  32595117 Jan 12 17:50 SPARKLE.sol
-rw-r--r--@  1 *  staff     55704 Jan 12 17:49 kisaragi_chihaya.sol

うーん、厳しい。ゴロム符号のアレンジでなんとかならないか...

困ってMonkey Audioのソースを見る...と、レンジコーダ使っていることに気づく。それじゃあデコードが遅いではないか...。

2019.1.13

wavpackの論文を読んだら以下の示唆があった。

  • 中央値の更新式
  • 固定小数を使うことで平滑化し小さい値でのジャンプを防ぐ。
  • 今の中央値の更新式は最適か?検討が必要。
  • Recursive Golomb Coding
  • エンコード値のunary部が2より長い(現在の中央値を超えた)場合は、エンコード値から中央値を引いてこれを新しい中央値としてゴロム符号化する。新しい中央値も適応的に変える。
  • これは減りそう...

Recursive Golomb Codingの手順:

  1. パラメータ配列m[MAX_QUOT]を用意
  2. 符号ビットを1bit出力
  3. abs <- 絶対値
  4. quot <- abs / m
  5. quotをunary符号出力
  6. for q 0 to MAX_QUOT
  7. if (abs < m[q] or q >= MAX_QUOT) break
  8. abs <- abs - m[q]
  9. end for
  10. abs % m[quot]をゴロム符号と同様に出力
  11. mの更新

中央値の更新式を固定小数化することで微減。

-rw-r--r--@  1 *  staff  41276050 Jan 14 00:23 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31390861 Jan 14 00:23 SPARKLE.sol
-rw-r--r--@  1 *  staff     53282 Jan 14 00:23 kisaragi_chihaya.sol

wavpackでは4bitを小数部に使っている。自分は12bitを割り当てている。4bitの方が追従が良く、よい結果を出している感触があるが、精度重視で12bitにしてみた。

(記憶に行き違いがないか、念の為記録)符号bit+絶対値ではなく、偶数を正に、奇数を負に割り当てる方針で行くと、以下のように微増する:

-rw-r--r--@  1 *  staff  41349156 Jan 14 02:24 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31557247 Jan 14 02:26 SPARKLE.sol
-rw-r--r--@  1 *  staff     53354 Jan 14 02:26 kisaragi_chihaya.sol

2019.1.14

符号ビットはランレングスで圧縮できそうだという信念の元、ランの長さをγ符号あたりで符号化することを検討中。

色々ガチャガチャやり始める前にランの長さの統計を取る。

f:id:aikiriao:20190929123450p:plain

これ、1/(2x)と比較すれば分かるが、一様乱数列のランレングスでは...

(ランの長さnは同一符号がn連続していることを示す。ランの長さ1は連続していないことを示す。)

さらに平均ラン長を計算してみると…(長さ64以上のランは除外)

入力音声 平均ラン長
ワン・ツー・スウィーツ 2.055
SPARKLE 2.260
俺の声 1.976

約2。これは何を意味するか...

これによると、一様乱数列の平均に一致している…。

γ符号の実装に2時間ほど持ってかれる...GetBitsの引数が64bitで型が合わずメモリ破壊を起こしていた。

実装できてランレングスをγ符号で出すようにした。が、増加...

-rw-r--r--@  1 *  staff  41783849 Jan 14 17:41 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31753911 Jan 14 17:41 SPARKLE.sol
-rw-r--r--@  1 *  staff     54026 Jan 14 17:41 kisaragi_chihaya.sol

うむ、厳しい。いや、長すぎるランを出している可能性がある。その回避を打ってから次を考える。

悲しくなってナイーブに符号ビット0,1の頻度を計測したら僅かながら偏りがあった。 さらに2bitパターンにしたら更に偏りが大きくなった。

早速8bitパターン化して頻度を見たところ、音源に依存せず現れないパターンを観測した。(どうしてその様なパターンが表れるのかは。あとグラフは中心で対称になっていないか?)

f:id:aikiriao:20190929123511p:plain

8bit使ったときのエントロピーは以下:

音源 8bit符号ビットパターンのエントロピー
ワン・ツー・スウィーツ 7.827755
SPARKLE 7.772168
俺の声 7.752156

ハフマン等で上手く割り当てれば3%くらい減らせる余地がある。費用対効果的にきついか?これは最後の手段として取っておこう。先に、効果の有りそうなRecursive Golomb Codingに手を出す。

2019.1.15

Recursive Golomb Codingに実装着手。アルゴリズムを紙に書いて終わり。

2019.1.16

Recursive Golomb Codingのテストを書きながら実装中。大阪行きながら実装できるとベストだが…大阪で実装する余裕はあるだろうか。大阪にはルベグ積分だけ持っていこう。

2019.1.17

Recursive Golomb Coding実装...と行きたいけど寄り道。

shotenの論文を読んでたら、ゴロム符号の商部分はアルファ符号よりもガンマ符号で出したほうが良いとの記述あり。早速試してみたがサイズ増加。ガンマ符号の実装が誤っている可能性がまだあるため、あとで再度検証したい。

また、shotenではまず入力データから平均を差っ引くというのを見た。これはもしかしたらLPC解析時に効くかもしれないと思って、窓掛け前に平均除去を入れてみた。結果はさしたる変化なし。(増えるケースもあった) 念の為窓掛け後に平均除去を入れたら、窓掛け後のほうが性能が良かった。

音源 変更前 窓掛け前に平均 窓掛け後に平均
ワン・ツー・スウィーツ 41276050 41275937 41275904
SPARKLE 31390861 31392892 31391996
俺の声 53282 53283 53282

FLACの実装を見ているとテューキー窓を使用していた。試す価値はあるかもしれない。

次数を増やしたら1MB近くの減少が観測された。その際に自己相関計算時のバグが見られたので修正(float同士の乗算により精度が落ち、PARCOR係数の絶対値が1よりも大きくなった。もっと言うとwavからデータを取るときにdoubleにすべき。)。またブロックサイズを変更することでかなりのパフォーマンス差が見られた。…しかしこれらは最後の手段。高次のPARCOR係数の傾向を見ておくのは良いことかも。

全く集中できなくてネットをウロウロしていたらexp-golomb符号(Elias-Teuhola符号)が目に止まった。H.264に使われているらしい。

中央値の逐次計算手法:

そして、依然として絶対値+符号ビットじゃなくて正を偶数、負を奇数に割り当てた方が圧縮率が良い...。一体どういうことだろうか。符号ビットも混ぜて符号化できるから効率が良い?

一旦立ち返って符号語の分布を見てみるべきかも。幾何分布の尤度を計算して当てはまりを見るのも良い。

-rw-r--r--@  1 *  staff  41242708 Jan 18 01:05 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31367692 Jan 18 01:06 SPARKLE.sol
-rw-r--r--@  1 *  staff     53246 Jan 18 01:06 kisaragi_chihaya.sol

最適なゴロム符号パラメータの決定法の資料があったぞ...

2018.1.18

1時間ほど作業ができるので誤差分布の統計を取る。

まずは符号語の分布。

f:id:aikiriao:20190929123528p:plain

u2が正を偶数、奇を負とする符号語、absが絶対値…ってなんだこりゃ。正負で分布が違うように見えるのだが

正負が非対称になっている可能性があるので、誤差のヒストグラムをそのまま出したところ…

f:id:aikiriao:20190929123542p:plain

0は最頻値(俺の声では最頻値すらずれている)だけど、平均がずれて存在している…?どういうこと?予測の間違い?

2018.1.20

秋葉原製作所。平均がずれているのはかなりクリティカルだと思っている。PARCOR係数の次数を変えて観察してみる。音源はSPARKLE(上のグラフで山がわかりやすかったから)

f:id:aikiriao:20190929123559p:plain

0がピークであることは変わりない。次数を増やすと山が正側に動いていく。差分生成のときに引き残しが発生している?実装を調査。

SPARKLEに対して整数版の関数を使用すると、確かに正にずれているのが確認できる。

residual sum:107071606 count:24540160

というか、和が減る瞬間がない。。。次数10のときの誤差の和をグラフにすると、

f:id:aikiriao:20190929123617p:plain

傾きを見れば分かるが、サンプル当り平均4の正の誤差が出ている。グラフを見るにどうもこれは音源に依存しないようだ。

浮動小数点版の予測関数を使い、誤差の和と平均を取った。これでも正にずれている。

residual sum:7.148294 sum(fix32):15350843823 count:24540160 mean:0.000000 mean(fix32):625

気になったのは係数の非線形量子化非線形量子化して再度floatに戻すと誤差が出るのでは?と思い誤差の和を計測したら、誤差は正で(仕様。必ず大きい方に割り当てているから)和を取ると結構シャレにならない大きさになっていた。(SPARKLE, 次数10)

err_sum:1.306255e-01

2分探索で無条件にtable[index] <= valを満たす値を割り振るのではなく、table[index+1]の方が近ければそちらを割り振るように修正したところ誤差値は改善(誤差分布にさしたる変化なし):

err_sum:-6.461394e-02

根本的にズレを直すにはアルゴリズムを見直すしか無い?

実装を次のように、係数の符号を反転して計算してみると山が反転...アルゴリズムに問題ありなのは間違いなさそう。

    /* 前向き誤差計算 */
    for (ord = 1; ord < order + 1; ord++) {
      int32_t gamma = -parcor_coef[ord];
      mul_temp = (gamma * backward_residual[ord - 1]) >> coef_quantize_shift;
      forward_residual[ord] = forward_residual[ord - 1] + mul_temp;
      // mul_temp = (parcor_coef[ord] * backward_residual[ord - 1]) >> coef_quantize_shift;
      // forward_residual[ord] = forward_residual[ord - 1] - mul_temp;
      assert(forward_residual[ord] <= INT32_MAX);
      assert(forward_residual[ord] >= INT32_MIN);
    }
    /* 後ろ向き誤差計算 */
    for (ord = order; ord > 0; ord--) {
      int32_t gamma = -parcor_coef[ord];
      mul_temp = (gamma * forward_residual[ord - 1]) >> coef_quantize_shift;
      backward_residual[ord] = backward_residual[ord - 1] + mul_temp;
      // mul_temp = (parcor_coef[ord] * forward_residual[ord - 1]) >> coef_quantize_shift;
      // backward_residual[ord] = backward_residual[ord - 1] - mul_temp;
      assert(backward_residual[ord] <= INT32_MAX);
      assert(backward_residual[ord] >= INT32_MIN);
    }

f:id:aikiriao:20190929123633p:plain

入力データとしては16bit幅しか無いデータを入れているので、固定小数的に怪しい(小数部の余裕がない)と思い、入力データの左16bitシフトを入れた:

  /* 誤差計算 */
  for (samp = 0; samp < num_samples; samp++) {
    /* 格子型フィルタにデータ入力 */
    forward_residual[0] = (int64_t)data[samp] << 16;
    /* 前向き誤差計算 */
    for (ord = 1; ord < order + 1; ord++) {
      mul_temp = (parcor_coef[ord] * backward_residual[ord - 1]) >> coef_quantize_shift;
      forward_residual[ord] = forward_residual[ord - 1] - mul_temp;
      assert((forward_residual[ord] >> 16) <= INT32_MAX);
      assert((forward_residual[ord] >> 16) >= INT32_MIN);
    }
    /* 後ろ向き誤差計算 */
    for (ord = order; ord > 0; ord--) {
      mul_temp = (parcor_coef[ord] * forward_residual[ord - 1]) >> coef_quantize_shift;
      backward_residual[ord] = backward_residual[ord - 1] - mul_temp;
      assert((backward_residual[ord] >> 16) <= INT32_MAX);
      assert((backward_residual[ord] >> 16) >= INT32_MIN);
    }
    /* 後ろ向き誤差計算部にデータ入力 */
    backward_residual[0] = (int64_t)data[samp] << 16;
    /* 残差信号 */
    assert((forward_residual[order] >> 16) <= INT32_MAX);
    assert((forward_residual[order] >> 16) >= INT32_MIN);
    residual[samp] = (int32_t)(forward_residual[order] >> 16);
  }

分布はほぼ対称になり、0の頻度が向上。が、裾の減衰が遅くなって音源依存で圧縮率が悪化した。(SPARKLEは改善、ワン・ツー・スウィーツは悪化)

f:id:aikiriao:20190929123648p:plain

固定小数の扱いがまずそう。丸めを忘れている:

丸めを入れたところ、山のピークは0に近づいた。微妙にサイズは増加。

f:id:aikiriao:20190929123701p:plain

丸め+16bitシフトではSPARKLE、ワン・ツー・スウィーツ共に30KBほどサイズ減少。

f:id:aikiriao:20190929123717p:plain

-rw-r--r--@  1 *  staff  41219742 Jan 21 01:23 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31336925 Jan 21 01:19 SPARKLE.sol
-rw-r--r--@  1 *  staff     53089 Jan 21 01:24 kisaragi_chihaya.sol

もう一度誤差平均を見てみよう。

2019.1.22

先輩社員のアドバイスにより、16bit左シフトは必須であることが分かった。小数点が揃わず意図しない計算になっていた。間違いをなくすために32bit固定小数点型を使うべきとも。

今一度誤差平均を計算してみる。

音源 誤差平均
ワン・ツー・スウィーツ -0.455
SPARKLE -0.474
俺の声 -0.442

2019.1.23

そして、整数版LPC予測合成関数で、データの固定小数ビット幅を可変にできるようにしているが、テストが失敗している…。修復には時間がかかりそう。

2019.1.24

FLACのエンコーディングオプションを見ると-rでライス符号の分割数を決めている。これはwavpack再帰的ゴロムと同義では?

帰りが遅くなり何も手が付かない…昨日との落差がありすぎてつらい…。

で、気付いたのだけど32bit整数だと最大INT32_MAX - INT32_MINの誤差が出るはずで、それは32bit整数では表現できない。だから、表現する固定小数ビット数を30bitに、整数ビット数を2bitに妥協することにした。

2019.1.26

ピアノもコーデックも進まなかったが、ようやく自由になる。

LPCのライス符号の分割は、網羅探索のことだった。指定した最小分割数から最大分割数でライス符号パラメータを変更してエンコードし、最もサイズが小さくなった分割を採用する、というもの。エンコード速度は犠牲になるけど、確かにデコード速度は早くなる発想だわ…。

2019.1.27

秋葉原製作所5時間コース。なんとしても今日で直す。 なんとなく起きていることは分かった。

No. データbit(整数部, 固定小数部) 得られた誤差の右シフト量 係数bit(整数部, 固定小数部) 結果
(1,31) 0 (1,31) NG。フィルタ値が[-1.0, 1.0]を超えるケースがある
(1,31) >> (32-データのビット幅) 0 (1,31) OK。元に戻る
(1,31) >> (31-データのビット幅) 0 (1,31) OK。元に戻るが、圧縮率が悪い
(1,31) >> (31-データのビット幅) 1 (1,31) NG。②より圧縮率良いが、誤差の最下位ビットが吹っ飛ぶので元に戻らない
(1,31) >> (33-データのビット幅) 0 (1,31) NG。④よりさらに圧縮率が良いが、データ側の最下位ビットが吹っ飛ぶので元に戻らない

これらの結果より、

  • 誤差のbit数は入力データのbit吸うと同一である必要がある。
  • 誤差を右シフトすると情報が失われる。左シフトすると無駄な情報が増える。

ことが分かるし、②以外の形態にするのは無しという方針で。また、2019.1.20の計算中の左シフトも、誤差記録時に右シフトしたときに情報が失われて、デコード結果が元に戻らないから採用できない。

でも結局誤差分布の偏りは解消されない…。

有力なヒントは、PARCOR係数の符号を反転させると山が反転することだろう。アルゴリズム内になにかの原因があるはず。 →原因が見えてきた。今の演算では32bit精度が求められる状態になっているのでは。32bitの最下位桁のずれがダイレクトに誤差になっている。

また、色々試していて非線形量子化が原因かと思って非線形量子化をやめてみたら、誤差の分布があまり変わらず、しかもなぜか圧縮率が向上した…そんな馬鹿な…。1MB程度の差が出るはずなのに。。。

これで5時間タイムアップ。今の作業項目をまとめるとこんな感じ:

直近のTODO:

  • 誤差の分布が非対称になる現象の調査
  • 非線形量子化が効いていない原因の調査
  • ゴロム符号を再帰的にする
  • ゴロム符号のパラメータ決定を変更。→統計論的に最適な $\log_{e} 2 E[|res|]$ を使う。
  • テューキー窓の使用
  • 無音部でランレングス符号化を使う
  • ゴロム符号のパラメータ計算のときに正値化した差分信号の平均を計算する。平均が1より小さければ無音のはず。ランレングスで符号化する。
  • ビットレート原則が崩れるかも...

  • ロングターム(ピッチ情報)を使う

  • ピッチ解析を行い、その長さによる予測符号化を行う。MPEG4-LSで使われている手法。

帰って、誤差分布のズレがどうしても諦められず追っていた。積和の途中でビット幅を広げるのを試したけど、結局、誤差を右シフトする必要があって情報が落ちてしまう。

で、今は前向き誤差を出すときに減算を重ねた結果正のオフセットが出ていることから、じゃあ丸め分大きくしてやるぜで試したら誤差分布が対称になった。

    /* 前向き誤差計算 */
    for (ord = 1; ord <= order; ord++) {
      mul_temp = (parcor_coef[ord] * backward_residual[ord - 1]) >> 31;
      forward_residual[ord] = forward_residual[ord - 1] - mul_temp;
    }
    /* 前向き誤差計算 */
    for (ord = 1; ord <= order; ord++) {
      mul_temp = parcor_coef[ord] * backward_residual[ord - 1];
      mul_temp = (mul_temp + (1UL << 30)/* 丸めhalf */) >> 31;
      forward_residual[ord] = forward_residual[ord - 1] - mul_temp;
    }

これが根本原因なのかはまだ分からない…。結果は以下でちゃんと戻ることは確認済み。

-rw-r--r--@  1 *  staff  41216562 Jan 28 01:05 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31339500 Jan 28 01:06 SPARKLE.sol
-rw-r--r--@  1 *  staff     53097 Jan 28 01:05 kisaragi_chihaya.sol

分布はこんな感じで、概形としては理想と考えられる。

f:id:aikiriao:20190929123732p:plain

2019.1.28

何故丸めが必要なのか。以下のサイトでは0.5足してからFIRの積和演算をしている。

丸めはどうも加算する方向しかだめなようだ。丸めには色々方法があるらしいが、今回の原因となっていていたのは、

の、

truncate(1.25) = 0x0001 = 1

truncate(1.5) = 0x0001 = 1

truncate(1.75) = 0x0001 = 1

truncate(-1.25) = 0xFFFE = -2

truncate(-1.5) = 0xFFFE = -2

truncate(-1.75) = 0xFFFE = -2

For the positive numbers, the result of truncation is that the fractional part is discarded. The negative number results are more interesting. The result is that the fractional part is lost, and the integer part has been reduced by one. If a series of these numbers had a mean of zero before truncation, then the series would have a mean of less than zero after truncation. Rounding is used to avoid this problem of introduced bias and to make results more accurate.

にあるように、どうも負方向に寄ってしまうのが原因らしい(-1.5の例を注目)。特に3と-3を小数部を2bitとして2bitシフトしてみると、3>>2=0に対して-3>>2=-1。だから右シフトでは-1のオフセットが乗ってしまう。だから小数部で加算することで精度を上げることができていたと想像する。3,-3の場合だと1を加算することになるから、(3+1)>>2=1(-3+1)>>2=-1だから精度が上がっている。

良い窓関数を探そうとして会社の『音声のディジタル信号処理(下)』を読んでいたら、格子型フィルタのより効率的な構成が見つかった。何でも乗算回数がN回(今2N回)で済むらしい。

頭にいれるだけ入れておく。

2019.1.29

窓関数をテューキー窓に置き換える前に資料を覗く。

要はテューキー窓は矩形窓に近く、過渡的な信号に強いようだ。

早速0.5を設定して試してみる。うーん。ワン・ツー・スイーツ以外ではサイン窓の方が性能が良い。

-rw-r--r--@  1 *  staff  41214648 Jan 29 22:15 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31342212 Jan 29 22:16 SPARKLE.sol
-rw-r--r--@  1 *  staff     53141 Jan 29 22:14 kisaragi_chihaya.sol

ゴロム符号のパラメータを log_{e}2E[|res|] に変えてみると、悪化。

-rw-r--r--@  1 *  staff  41258145 Jan 29 22:53 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31420823 Jan 29 22:54 SPARKLE.sol
-rw-r--r--@  1 *  staff     53145 Jan 29 22:54 kisaragi_chihaya.sol

今の手法の方が良かった。

また、改めて符号1bit+絶対値符号すると性能が悪化する。何故?符号bitは実は冗長?

小手先のアイデアは通用しなさそう。さて、再帰的ゴロムの実装に戻ろう。

2019.1.30

FLACのソースを読んでたらLPC乗算時の右シフトは、積和演算の後に行われていた。

 /* Here's a slower but clearer version:
   for(i = 0; i < data_len; i++) {
       sum = 0;
       for(j = 0; j < order; j++)
           sum += qlp_coeff[j] * data[i-j-1];
       residual[i] = data[i] - (sum >> lp_quantization);
   }
   */

最後に右シフトするので精度が高いはず。 これはLPCが予測誤差算出と復号を同一のアルゴリズムできるから?PARCORでできない理由があるだろうか。 また個人的には非線形量子化があんまり効いていないように見えるのが引っかかっている。

2019.1.31

再帰的ゴロムの実装。テスト追加しながらやっている。まだ実装途中だが、時間があれなので練る。

2019.2.1

中央値mはE[|X-m|]を最小化することが知られている。適応的に求められないか? LMSは適応的に求められる手法が良く知られているが、絶対値はそうはいかない。

2019.2.16

再帰的ゴロムが何となく動き始めている。次のように符号を割り当てると考えたらうまく行った:

値域 符号
0 <= val < m 1 (val % m)
m <= val < m + m' 01 *1 をパラメータ(m + m')でゴロム符号出力)

パラメータの変動を見ていたら、現在値より大きいか小さいかだけで更新値を決めるので追従が遅い。

やっぱり中央値の逐次修正を改善したい。幾何分布の性質に注目すると、p>=0.5では、必ず平均値が中央値よりも小さくなる結果が見えている。下限を平均値、上限を平均+分散の平方根として、どうにか逐次推定できないか?

2019.2.17

再帰的ゴロム符号にテスト追加。また、符号割当をループの形で書き直す。 →OK。良好に動いている。で、パラメータを増やしていくと、増やしただけ良くなっていく傾向が見られる。(当然、大きすぎる値は増加に転じる)

さっそく再帰的ゴロム符号を組み込んだが…結果悪化…。まだ整理しきれてない・あがける部分はありそうなので、一週間粘ってみる。

2019.2.18

再帰的ゴロム符号の実装を修正。修正前は全パラメータの和に達したらパラメータ和のゴロム符号をしていたが、そうではなく、末尾のパラメータを使用してゴロム符号化するようにした。

それでパラメータ段数を8にしたら、全体的に減少。長い音声では百KBオーダーで減少が見られた。

-rw-r--r--@  1 *  staff  41085053 Feb 20 02:05 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31287228 Feb 20 02:09 SPARKLE.sol
-rw-r--r--@  1 *  staff     53068 Feb 20 02:10 kisaragi_chihaya.sol

まだ改良点がある。パラメータ数で剰余部のアルファ符号は打ち切りができるはず。他にもパラメータ初期値のとり方でだいぶ性能が違っていた。また、パラメータ末尾で符号化するときには、ゴロム符号を使わず、その場で商を計算してアルファ符号化すべきかも。

2019.2.20

再帰的ゴロム符号の改良に取り掛かる。末尾パラメータ符号化の際に1bit減らした。長い音声では十KBオーダーで減少。

パラメータは末尾の利を活かすべく(というか今まで損していた)少なめの3つとしている。パラメータ初期値でだいぶパフォーマンスが異なるのが気になる…。更新式も再考の余地がありそう。

-rw-r--r--@  1 *  staff  41032143 Feb 21 00:19 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31245120 Feb 21 00:21 SPARKLE.sol
-rw-r--r--@  1 *  staff     52997 Feb 21 00:22 kisaragi_chihaya.sol

後、確実に減らせるのはランレングス分。

2019.2.21

パラメータが小さければランレングス符号化するように修正。当然減る。

-rw-r--r--@  1 *  staff  41006713 Feb 22 00:56 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31233963 Feb 22 00:56 SPARKLE.sol
-rw-r--r--@  1 *  staff     52997 Feb 22 00:56 kisaragi_chihaya.sol

減らすアイデアあり。末尾のパラメータで符号化するときに、商部分が大きくなりすぎることがある(32より大きいものがたくさん出てきた。アルファ符号を使うからかなりのロス)から、長過ぎる商はガンマ符号化する。(wavpackと同じアイデア) あと、PARCOR係数最初の1つ目は1.0fなのに符号化しているのがもったいない。2つ目以降を符号化するように修正したい。

2019.2.24

圧縮も佳境だ。 まずは、商部分が長すぎる場合はガンマ符号を使う修正。長い音源で十KBオーダーで減少。wavpackに倣って商が16以上ならばガンマ符号化している。

-rw-r--r--@  1 *  staff  40967452 Feb 24 14:19 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31133035 Feb 24 14:26 SPARKLE.sol
-rw-r--r--@  1 *  staff     52962 Feb 24 14:27 kisaragi_chihaya.sol

さらに、係数先頭が0であるからそれを保存しないようにして、係数先頭1つ分の保存を省いた。微減。

-rw-r--r--@  1 *  staff  40954128 Feb 24 15:10 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31121051 Feb 24 15:11 SPARKLE.sol
-rw-r--r--@  1 *  staff     52934 Feb 24 15:10 kisaragi_chihaya.sol

あと、桜川駅から大阪港までバスで行く途中で思いついたけど、自己相関の計算で情報落ちが起きているから、それを軽減するように修正しよう。→確かに情報落ちは起きていたけど、積み残しは10^-16程度で圧縮率改善には至らず。

また、LSPで係数保存してLPCで予測・合成すれば、計算負荷は低く、かつ精度良くやれそう。これは次世代バージョンでのアイデア

2019.2.26

PARCOR係数の不均一なビット割当てを試そう。

非線形量子化は切ったほうが性能が高いことが分かっている。この機会に非線形量子化を廃止した。

非線形量子化を切った結果:

-rw-r--r--@  1 *  staff  40954119 Feb 26 23:12 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31121021 Feb 26 23:13 SPARKLE.sol
-rw-r--r--@  1 *  staff     52936 Feb 26 23:09 kisaragi_chihaya.sol

不均一なビット割当てをやってみた。減る。係数ビットは増やすことで予測精度向上を狙うのではなく、ビット数を減らして係数ビットの領域を減らす意図でいくと良い感じ(体感16bitよりも大きいビットでは、予測精度が向上するメリットよりもビット数を増やすことによるデメリットの方が大きくなる)。以下の結果は、4次成分まで16bit, それ以降を8bit割り当ててている。また、double->int32_tの際ににroundを使用したら結果が改善したことを注記しておく。

-rw-r--r--@  1 *  staff  40907480 Feb 27 00:16 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31079276 Feb 27 00:17 SPARKLE.sol
-rw-r--r--@  1 *  staff     52832 Feb 27 00:15 kisaragi_chihaya.sol

残りの策は…ロングタームか。 後、格子型フィルタの計算負荷をアルゴリズム的に少しでも下げたい。1乗算型を実装したい。

共分散法もやろうかと考えたけど、ここ によると、共分散では不安定になることがあり、またPARCOR係数を求めることができない。

2019.3.2

秋葉原製作所。ロングタームの実装に手を出す。まずはピッチ予測を試す。残差信号の自己相関(もしくは相互相関)を計算してargmaxを取得し、それをピッチとする。

自己相関の計算にはパワースペクトルを使用する(ウィーナー・ヒンチン)。ピッチ検出のやり方はよーく知られている この手法。 かなーり適当にピッチ検出を作ったけど、それなりの結果が出ている。

2019.3.3

ピッチ解析結果からロングターム予測を試してみる。そして、元の誤差から減少するのかどうか簡単に検証してみた…結果は、なんと減ったよ。。。

  • ロングタームを使用しない場合に比べて、ロングターム予測(1タップ)を使用した場合は誤差のRMS値がほぼすべてのフレームで減少。(増えてしまったフレームは1,2ほどしかない)
  • RMS値は音源依存で減少。SPARKLEはRMS値で5、ワン・ツー・スゥイーツは15、俺の声は2減るという結果。それすなわち、1サンプルあたり平均でそれだけ誤差が減っているということ…?当然かも知れないけど、凄いのでは?

この検証結果から、ロングタームを採用する方針に動きたい。減るのは間違いなさそうだ。

MPEG-4 ALSのエンコーダを入手した。ここ からexeが手に入る。 圧縮率はFLACより良くて、Monkey's Audioよりは悪いくらい。(最大圧縮-7でもMonkey's Audioのinsameより悪いし実行時間が長すぎる。高圧縮にするときはギルバート・ムーア(算術)符号使っているのではなかったのか?)

2019.3.5

LPCモジュールにロングタームを追加する。処理自体は大体まとまっているから、APIをがっちり固めて、単体でテストできるようにする。

/* ロングタームの最大タップ数 */
#define LPC_LONGTERM_MAX_NUM_TAP (5)

/* ロングターム計算ハンドル */
struct LPCLongTermCalculator;

/* ピッチ解析結果(内部) */
struct LPCLongTermPitchCalculationResult {
    uint32_t    pitch_num_samples;                          /* ピッチに該当するサンプル数 */
    double      ltm_coef[LPCLONGTERM_MAX_NUM_TAP];          /* ロングターム係数 */
    double      head_acf[LPCLONGTERM_MAX_NUM_TAP];          /* 自己相関の先頭からの並び */
    double      around_pitch_acf[LPCLONGTERM_MAX_NUM_TAP];  /* ピッチ周辺の自己相関。タップ数0ならば先頭にピッチの自己相関、3ならば-1,0,1、5ならば-2,-1,0,-1,2が並ぶ */
};

/* ロングターム計算ハンドルの作成 */
struct LPCLongTermCalculator* LPCLongTermCalculator_Create(uint32_t fft_size);

/* ロングターム計算ハンドルの破棄 */
void LPCLongTermCalculator_Destroy(struct LPCLongTermCalculator* ltm_calculator);

/* ロングターム係数の計算(内部的にピッチ解析が走る) */
LPCApiResult LPCLongTermCalculator_CalculateLongTermCoefficients(
    struct LPCLongTermCalculator* ltm_calculator,
    const int32_t* data, uint32_t num_samples,
    uint32_t* pitch_num_samples, double* ltm_coef, uint32_t num_taps);

/* 残差信号の計算 */
LPCApiResult LPCLongTerm_PredictInt32(
    const int32_t* data, uint32_t num_samples,
    uint32_t pitch_num_samples, 
    const LPCFixedFloat1_31* ltm_coef, uint32_t num_taps, int32_t* residual);
    
/* 残差信号から音声合成 */
LPCApiResult LPCLongTerm_SynthesizeInt32(
    const int32_t* residual, uint32_t num_samples,
    uint32_t pitch_num_samples,
    const LPCFixedFloat1_31* ltm_coef, uint32_t num_taps, int32_t* output);

2019.3.6

上記API案に従って、既存の実験的実装を関数化。テストを作って、週末辺りに組み込みたい。

2019.3.8

秋葉原製作所で2hほど作業。

ロングタームは自己相関に基づいてやってるけど、よく見なくても、低次の自己相関値の方が大きくないか。最悪、直前の値で予測してもまだ減るんじゃないかと思っている。要自己相関確認。

2019.3.9

秋葉原製作所5hコース。意外に人がおる。

ロングタームのテストを作りきって元に戻ることを確認次第、組み込む。 2hほど作業して自己相関のピーク検知を微修正。はよ予測合成テストに入らんと…。 →17:40予測までOKぽい。組み込む。

フォーマットに変化もある点に注意。

急ぎ実装で軽く試したら、微妙。というか長い音声ではガッツリ悪化。

-rw-r--r--@  1 *  staff  41123054 Mar  9 19:22 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31461853 Mar  9 19:20 SPARKLE.sol
-rw-r--r--@  1 *  staff     52811 Mar  9 19:22 kisaragi_chihaya.sol

ピッチ周期を見ていると短い結果(10未満)があまりにも多い。短いピッチは有用な結果ではないとして切り捨てるのが良いか?(俺の声はピッチ周期10以上が多かった。)

そこで、以下の修正を取り込んだ所、安定して減るようになった。

  • 短いピッチを切り捨て
  • 3以上の周期を採用するように変えたら良くなった。
  • 2以下だと悲惨。
  • 「最大の自己相関値から何割以上の自己相関値をピッチとするか」をやめ、単純に最大の自己相関を与えるラグを採用する

あと、自己相関値自体も判定材料にできそう。

ひとまず、上記の修正を取り込んだところの結果を見ると、

-rw-r--r--@  1 *  staff  40862203 Mar 10 01:16 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31056950 Mar 10 01:17 SPARKLE.sol
-rw-r--r--@  1 *  staff     52810 Mar 10 01:17 kisaragi_chihaya.sol

もう少し試行したら、実装をまとめ始めてもいいかな。3月中にα版がまとめられると良い。

2019.3.10

再度秋葉原製作所。今日で圧縮率改善の試みに一旦ケリを付けておく。並びに、オンメモリ書き出し対応時に必要な変更点についてまとめていきたい。

日記を見返してみたが、当初の圧縮率改善の試みはほぼ消化できているようだ。LSPを試すという点が残っているが、以下の点で見送る予定。

  • フィルタ計算がPARCORに増して複雑
  • LSPで保存してLPCで計算する方法は以下の難点がある
  • フィルタ計算時に変換時のLPC係数に応じて量子化が必要。複雑になる
  • そうして得られたLPC係数は、結局指定次数で得られたLPC係数と変わらないのでは(=FLACと同程度にしかならない)

だから、PARCOR係数の格子状フィルタで戦うのが正攻法だと考えている。


オンメモリ書き出しへの変更点要点

  • ソースは独立して切る。新規に書き起こす。無駄な部分を消す。
  • バージョンは5
  • 再度バイナリフォーマットを考察
  • ブロックサンプル数等、1部フィールドのサイズ見直し
  • エンコードパラメータの整理
  • プリセットを作成。
  • 低圧縮率でデコード早い ? 高圧縮率でデコード遅い
  • シグネチャSL*に変える。
  • 拡張子は.sla。Sound Lossless Audio(良好なロスレスオーディオ)の略。あるいはSHINING LINE*。
  • メモリ領域読み書きに変える。
  • オンメモリ対応のため。
  • 高速化にもなるはず。
  • ひとまずBitStreamのメモリ版に変えるが、将来的には高速なビット読み書きモジュールを使用する。
  • エンコード・デコードの関数化
  • ストリームエンコード・デコードハンドル作成関数
  • エンコードサイズの計算関数
  • ストリームエンコード・デコード関数
  • ゴロム符号パラメータの更新式を再度検討
  • 高速化
  • 格子型フィルターを1乗算型に変える
  • 負荷測定
  • 性能検証
  • 比較プログラムの作成。
  • 様々なwavに対してエンコード・デコードし性能(圧縮率と速度)比較
  • TAKと戦っておきたい。

ゴロム符号パラメータの更新式をwavpackに寄せる修正を忘れていた…。

→取り急ぎ試したが悪化。しかし、更新式で定数を足す際に固定小数化せずに足したら性能が良化したので取り込む。

/* 修正前 */
#define SOLAGOLOMB_PARAMETER_UP(param_array, order)  {\
  ((param_array)[(order)]) += ((((param_array)[(order)]) + SOLAGOLOMB_FIXED_FLOAT_TO_UINT32(127)) >> 7);  \
}
/* 修正後 */
#define SOLAGOLOMB_PARAMETER_UP(param_array, order)  {\
  ((param_array)[(order)]) += ((((param_array)[(order)]) + 127) >> 7);  \
}
/* 修正後2 */
#define SOLAGOLOMB_PARAMETER_UP(param_array, order)  {\
  ((param_array)[(order)]) += ((((param_array)[(order)]) + SOLAGOLOMB_UINT32_TO_FIXED_FLOAT(127)) >> 7);  \
}

何故良くなったのかは謎...と思ったら間違えてんじゃん。バグや。SOLAGOLOMB_FIXED_FLOAT_TO_UINT32だと固定小数として計算しちゃう。やりたいのは定数を固定小数にすること。そこで、修正後2に変えたら性能が悪化...。

更新式については、バグを疑いつつ検討したい…。重要な割にあまり考え抜いていないところだし…。

ロングタームの最後の試行。以下を試したい

  • タップ数を増やす
  • 3次の場合は連立方程式を解く必要あり。手が伸びてない。
  • 減らした誤差に対して更にピッチ解析を行う
  • →繰り返せば繰り返すほど減ってる…。

N次方程式を解くソースがどこかにあったはず。

→あった。関数内でmallocしているから、手直しして使おう。でもなんだか結果が合っていないように見える…。

2018.3.12

いっそPARCOR予測を多段適用すべきでは。フィルタの直列連結とどちらが良いか検証の価値はあり。

2018.3.16

平日あまり動けず。PARCORの多段適用を試している。まず、誤差に対してもう一度同一係数で予測をかけたらサイズが爆増した。とりやめ。

実際に誤差に対してPARCOR係数を再度求めてみた...係数を符号化しない状態で、長い音源で1MBクラスの減少が見られた。(以下の結果は次数10のPARCOR係数を2段入れている。)

-rw-r--r--@  1 *  staff  39845536 Mar 16 15:02 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  30154328 Mar 16 15:03 SPARKLE.sol
-rw-r--r--@  1 *  staff     52720 Mar 16 15:03 kisaragi_chihaya.sol

素直にPARCOR係数を20次数にした方が結果が良かった。結果は以下:

-rw-r--r--@  1 *  staff  39767592 Mar 16 15:07 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  30135816 Mar 16 15:08 SPARKLE.sol
-rw-r--r--@  1 *  staff     52588 Mar 16 15:08 kisaragi_chihaya.sol

また、PARCOR係数を観察してみると、低次係数が小さくなっていた(普通に解析すると低次係数は1,-1の近傍にある)。有効なフォルマント情報が抜き出せなかったものと想像している。

PARCORを使うことで、次数を増やしても健全にサイズを減らせるようだ(FLACは次数を32まで選択できるが、最高圧縮時-8でも次数を12としている。LPC係数の鋭敏性と、次数上昇による量子化が大変だからだと推察。)。だから、このコーデックではPARCORを大きめにとる。フィルター計算は1乗算型でしっかり高速化するつもり。

次数によってどれくらいサイズが変わるのか知りたくない...?知りたいでしょ。じゃあ出してみるわ。ひとまず30まで。ロングタームはOFFにしとく。

f:id:aikiriao:20190929123751p:plain

20前半辺りまでは単調に減るけど、それ以降はあまり減らず、増えたりする。

あとはゴロム符号の更新式を考察したらまとめましょう。

2019.3.17

秋葉原製作所5時間コース。ゴロム符号のパラメータ適用式を見直し。少なくとも自分にとって説明できるものにしたいし、まだ改善できる気がする。

以下のp55にゴロム符号のパラメータ設定について記述あり。

  • JPEG2000の解説%20JPEG2000%20Image%20Compression%20Fundamentals,%20Standards%20and%20Practice%20%202002.pdf)

非常に簡単で、k = ceil(log2(平均/2))としてパラメータm = 1 << kとするもの。常にライス符号を使うことになる。

試してみる。まずは、パラメータを変えないでやる場合と上式を使用する場合で比較する。

結果:

  • パラメータ固定よりも上記の更新式のほうが性能が良い(←これは前から知ってた)
  • wavpackの更新式よりは良くなかった(←これも前見た気がする)

で、パラメータの変化を見たところ、wavpackは値の変動に素早く追従しているが、平均値は追従が遅いように見える。

色々あがいているが、平均を使うやり方では、どうもwavpackに勝てない。wavpackのパラメータ変化が理想として、それに近付くにはどうしたらいいか、で考えている。

信念としては、wavpackの更新式が最適とは思えない。統計的な裏付けがほぼ無いし。

指数平滑移動平均を使ったら、wavpackの更新式による結果を超えた。(しかもライス符号で!)

-rw-r--r--@  1 *  staff  41129982 Mar 17 18:06 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31271982 Mar 17 18:06 SPARKLE.sol
-rw-r--r--@  1 *  staff     52970 Mar 17 18:06 kisaragi_chihaya.sol
-rw-r--r--@  1 *  staff  41028253 Mar 17 18:08 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31110736 Mar 17 18:08 SPARKLE.sol
-rw-r--r--@  1 *  staff     52771 Mar 17 18:08 kisaragi_chihaya.sol

このときの更新式は以下:

/* meanはSOLAGOLOMB_UINT32_TO_FIXED_FLOAT(init_golomb_m)で初期化 */
uint32_t golomb_m2 = MAX(SOLAGOLOMB_FIXED_FLOAT_TO_UINT32(mean), 1);
Golomb_PutCode(strm, 1 << CodingUtility_Log2ceil(golomb_m2 >> 1), abs); /* 固定小数で/2しているから、0.5足したほうがいいかも */
mean = (15 * mean + SOLAGOLOMB_UINT32_TO_FIXED_FLOAT(abs)) >> 4; /* mean <- 15/16 * mean + abs */

15/16 = 0.9375がミソ。 他に良いパラメータをあさってみると、119/128 = 0.9296875238/256 = 0.9296875で結果が良い。平滑化係数を0.93とするとよいのか?

平滑化係数はデータから推定できるようだ。自己相関を使う(!)。簡単に試してみたけど、得られた平滑化係数が[0,1]からはみ出ることが多かった。(要請する制約に入らないこと多数)。

  {
    uint32_t  j;
    double    auto_corr[2];
    double    rho_1, alpha, b;

    /* 1次までの自己相関計算 */
    for (i = 0; i < 2; i++) {
      auto_corr[i] = 0.0f;
      for (j = i; j < num_data; j++) {
        auto_corr[i] += (double)data[j] * data[j - i];
      }
    }

    rho_1 = auto_corr[1] / auto_corr[0];
    rho_1 = (rho_1 >= 0.5f) ? 0.5f : rho_1;
    rho_1 = (rho_1 <= -0.5f) ? -0.5f : rho_1;
    b     = (1.0f - sqrt(1.0f - 4.0f * rho_1 * rho_1)) / (2.0f * rho_1);
    b     = (b >= 0.0f) ? 0.0f : b;
    b     = (b <= -1.0f) ? -1.0f : b;
    alpha = b + 1;
    if (alpha != 1.0 && alpha != 0.0f) {
      printf("%e \n", alpha);
    }
  }

1パラメータに対して性能向上が見られたので、再帰ゴロム符号に適用していきたいが、やっつけでやったら事故った(ゼロ除算がどこかで起きている)。ちゃんとした形に整備して、性能が上がるか見ていく。

家に帰って作った。結果は次:

-rw-r--r--@  1 *  staff  40937961 Mar 17 23:56 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  31060591 Mar 17 23:58 SPARKLE.sol
-rw-r--r--@  1 *  staff     52656 Mar 17 23:58 kisaragi_chihaya.sol

観察した結果は次:

  • パラメータ数は2がベストだった。パラメータ更新は119/128を使った。
  • ライス符号が前提になるからか全体的に性能は悪化。
  • しかし振幅が小さい場合は減る方に動いた。大きいほど悪化。
  • 俺の声は減った
  • SPARKLEは少し悪化
  • ワン・ツー・スゥイーツは結構悪化

これは、最終的にライス(負荷)を使うのか、それともゴロム(圧縮率)を使うのかに分かれると思う。圧縮率を改善する取り組みに反するけど、ライス符号形式を推したい。なぜなら説明できるから。

デコーダ作って戻ることを確認したら、実装整理、すなわちバージョン5に入る。

2019.3.18

wavpackが符号bit+絶対値で分けていたのが依然として気になっている。-1が0に行くのは大きい。最後に試しておきたい。

→あんまり効果なし。1bit確定で消費するのがあまり望ましくないと考える。

デコーダも苦戦。パラメータの更新が難しくなっている。春分の日一杯でできるかどうかというところか…?

2019.3.19

デコーダデバッグ中。OK。戻ることを確認。テスト追加。

DreamGoesOnの圧縮率がどうもalsに比べて低くて、符号の頻度を見たら負方向に偏っていることが分かった。

どうも音源依存で偏りが発生しているようだ…。voice48aも正に偏っている。

SPARKLE, ワン・ツー・スゥイーツは偏っていない。一回ロッシー圧縮するとだめ? →ワン・ツー・スゥイーツを一回mp3(96Kbps)にしてwavに戻して試してみたが、分布の偏り見られず。

ffmpeg -i one_two_sweets_offvocal.wav -ab 96k -f mp3 one_two_sweets_offvocal.mp3
ffmpeg -i one_two_sweets_offvocal.mp3 -f wav one_two_sweets_offvocal_frommp3.wav

エンコードパラメータが小さくなるフレームがあることに気づいた。それで、元波形の先頭(イントロ前)を見た所、微弱な信号が入っていることがわかった。(ワン・ツー・スゥイーツではしっかり0になっているが、DreamGoesOnは無音にならずわずかな信号が流れている。)

f:id:aikiriao:20190929123806p:plain

上がDream Goes On、下がワン・ツー・スゥイーツ。時間が示すように先頭部分。16bit PCMにして3程度の振動が入っている。

こういうフレームはランレングスでやってしまうべきかと思う。ランレングスの判定基準を甘くしよう。

2019.3.20

通勤中に思いついたこと:

  • 自己相関はピークをとらずに、単に最大値をとればよいのでは
  • 実質今その実装。簡略化する。

  • 各ブロックの立ち上がりでパラメータが大変動する。先頭は単純符号化でよいのでは

  • もしくは、先頭部分だけの平均を計算しておく。

  • 30以上の高次係数は4bitとかで良さそう

  • →悪化傾向。16,20以降の係数を4bitにしたが悪化。

  • ライス符号化のパラメータはlog2(e)使うやつじゃなくて良かったか

  • m = log2*2 という式
  • Wavpackが言及したDataCompressのp67周辺の記述。

2019.3.21

3.20の夜は疲れて何もできず。寝不足か。

アニソンAnother stageの中止発表を受ける。急いでキャンセルしたい。

その他は今日はランレングスの調整から始める。

  • 閾値を上げるのは効果あり。
  • 残差分布はほぼ対称になった。
  • パラメータをいっそ平均に変えるのも効果あり。
  • ランレングス中で適応的ライス符号を使うのは悪化。
  • ランレングスのときのゴロム符号パラメータは平均をそのまま使う。

ゴロム符号の初期パラメータは先頭だけから求めることをする。 →16bitを越えてしまった。やっつけで16bit上限を設けたら性能が悪化。どうゆうことだ…。

モジュール簡略化のため、ゴロム符号パラメータはヘッダに含めないようにする。 →やった。

最後、DreamGoesOnがデコードアサーションしている(ゴロム符号パラメータが0になった)ので、修正してまとめていきたい。他のファイルはもとに戻る。ピッチ検出に失敗するのがトリガー? →イチローの引退会見を横目にデバッグ。どうも4537回目のブロックデコードで20bitずれている。(20bitの空白ができていて、20bit空読みすると完全一致になる。)ランレングスを読みそこねている?

無音部分(ランレングス)の圧縮率が悪いかも。他コーデックを参考にすべきか...

  • 最大ランレングス長さ(を表現可能なビット長)を先読みで解析しておく…?
  • PARCOR係数を出す前に、エンコード対象のデータ列が本当の無音(0列)か否かを判定する。

2019.3.22

バグ直し。 デバッグ中に気づいたけどランレングスのときにあまりランで出力できていない(ほとんど非ラン)…。閾値はもっと厳しくしていいのでは…。あと、まじの無音(0だけ)は特別な符号で表すだけでいいと思った。

バグ退治。エンコード時、ランレングスで最大長出力時に誤りがあった。

      /* 非ラン分出力 */
      while (notrunlength >= MAXLENGTH) {
        /* snip... */

MAXLENGTH = (1 << length_bits) - 1だから、ピッタリnotrunlength == MAXLENGTHの時に、本当は何もしなくても出力できるのに、分割出力してしまう。正しくはこちら:

      /* 非ラン分出力 */
      while (notrunlength > MAXLENGTH) {
        /* snip... */

日記を見返していたら、最適なライス符号パラメータの式あるやん…平均に0.382(49/128)足すだけでいいじゃん。。。→簡単に適応的なやつに試したけど悪化。しかもゴロム化するのでやめとく。

2019.3.23

残りTODO:

  • 引き続きランレングスの吟味。
  • できれば完全無音のブロックをもっと少ないビットで符号化したい。

    • やった。無音フレームか否かを識別するフラグを追加。やらしいのは、係数による結果だと誤りが出る所。入力が全て0かを判定して行う必要がある。
    • ワン・ツー・スゥイーツやSPARKLEなどの純正マスタリング音源に効果あり。(リアル無音なんか自然ではほぼ作れないから、当然ではある...。)
  • ランレングスいらねえんじゃね…。

    • ラン長が短すぎる。手元のDreamGoesOnやVoice48aでは最長12とか。
    • 無音に近い場合は、パラメータを適用変化させないほうが良い?以下の表参照。→分散が小さく分布変動も小さいから、固定したほうが有利かも。
    • と思って固定パラメータ出力したら増えた…?なぜ?ほぼラン出力できてないのに増えるのはおかしいと思う。もうちょっと精査する必要あり。
    • → returnし忘れていた。ただのしょうもないミス。
音源 ランレングスあり ランレングス無し ランレングス無し(固定ゴロム符号)
voice48a 789104 788643 788617
DreamGoesOn 23927826 23962467 23922982
  • ロングタームをピークではなく単純最大に置き換える

パラメータ固定小数を整数に戻すとき(右シフト時)、0.5を足して丸めるようにしたら性能改善。固定小数は丸めが大事だ…

2019.3.25

あーLMS(適応的アルゴリズム)を忘れていた…試したい…。 image_comp/LMS/lms_test.rb でテスト可能。

試してみる。すると、かなり減るように見えるぞ、おい。誤差の分散(と標準偏差)をプロットしてみたけど、増えることはなく、減っている。次数を増やすと減少が鈍るけれども、増えないだけでも有益に思える。次数を増やしても、振幅が小さめのボイスデータはかなりへる傾向が見られたので結構有益かも。

今はdoubleで演算していたけど、固定小数に置き換えたときにどうなるか。それを含めてやはり試してみたい。

2019.3.26

LMSのモジュール化を試みる。APIは極めて簡単に作れる。

/* NLMS計算ハンドル */
struct NLMSCalculator;

/* NLMS計算ハンドル */
struct NLMSCalculator {
    LPCFixedFloat1_31   alpha;          /* ステップサイズ */
    LPCFixedFloat1_31*  coef;           /* 係数 */
    uint32_t            max_num_coef;   /* 最大の係数個数 */
};

/* 計算ハンドルの作成 */
struct NLMSCalculator* NLMSCalculator_Create(LPCFixedFloat1_31 alpha, uint32_t max_num_coef);

/* 計算ハンドルの破棄 */
void NLMSCalculator_Destroy(struct NLMSCalculator* nlms);

/* 予測 */
LPCApiResult NLMSCalculator_PredictInt32(
    struct NLMSCalculator* nlms, uint32_t num_coef,
    const int32_t* data, uint32_t num_samples, int32_t* residual);
    
/* 合成 */
LPCApiResult NLMSCalculator_SynthesizeInt32(
    struct NLMSCalculator* nlms, uint32_t num_coef,
    const int32_t* residual, uint32_t num_samples, int32_t* output);

alpha0.01f(32bit固定小数で=0x0147ae14)あたりに固定したい。

2019.3.27

上記のとおりに実装。LPCが膨れるので、そろそろ整理したい所。predictor.cにリネームしようかな。

16bitの振動する信号に対しては予測が動いている。定数入力に対して係数が更新されない…(分散が0だから?)。24bitはダメダメ。これは溢れが起きているかも。どうも19bitまでは良くて、20bitからだめみたいです。

TODO:LPC/PARCORの24bitテスト。

2019.3.28

周りが焦らなくて焦る。木村監督は叩かれてる。

24bitでだめなのは、やはり桁あふれだろうということで真面目に乗算の度にシフトしていた。すると、誤差がいつまでも残るようになった。それはいやなので、alpha抜き(alpha=1と同じ)で計算してみると収束が非常に良くなった。これで行こう。

→更新式がまだ溢れている。結果は正しくなっているけど。。。

2019.3.29

NLMSの更新式間違ってるわ。分散じゃなくて、単純に入力の2乗(パワー)で良かった。したら白色雑音意外は収束するようになった。よし、使える。

PARCORの24bit版テストを追加。テストは通っている。

2019.3.30

秋葉原製作所2時間。GWは小松に行こう。NLMSの更新式で整数除算を使うので、速度が気になっている。以下のサイトが有効かも。

...適用は難しいことがわかった。32bit精度演算だと、最後の計算で右62bitシフトが必要になる。これはつまり128bit精度で途中結果を持たないと行けない…

単純なビットシフトに置き換えてしまって良いように思える。ほか、うろついてたらlog2の切り捨ての計算方法があった。

シビアに高速化できそう。もしかしたらハッカーのたのしみに載ってそう。

高速化はおいておいて、NLMSを取り込んでいく。→取り込んだ。次数はとりあえず10。全体的に減少が見られる:

-rw-r--r--@  1 *  staff  40586832 Mar 30 14:32 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  30960017 Mar 30 14:30 SPARKLE.sol
-rw-r--r--@  1 *  staff     52560 Mar 30 14:33 kisaragi_chihaya.sol

PARCOR係数の次数を増やすとNLMSによる恩恵が少なくなるが、それでも減る。以下の結果はPARCOR係数を20にしたときの結果:

-rw-r--r--@  1 *  staff  39715652 Mar 30 14:37 one_two_sweets_offvocal.sol
-rw-r--r--@  1 *  staff  30101640 Mar 30 14:36 SPARKLE.sol
-rw-r--r--@  1 *  staff     52332 Mar 30 14:35 kisaragi_chihaya.sol

以上で圧縮技術の駒は揃っただろう。NLMSについて気になるのは、次数と残差計算の順番。PARCORによる残差は最初に出すとして、NLMSとロングタームはどちらを先に入れるのが良いか。これらを検証したら切り上げる。

残差計算の順番は、なんと、順番に依存しない(変わらない)ことがわかった...。サイズは厳密に一致。これはNLMSの短期予測の結果はロングタームの結果に何ら影響を及ぼさないことを意味しているのだろうか。。。

次数について見ていく。PARCOR係数は10、ロングタームありでの比較:

NLMS次数 ワン・ツー・スウィーツ SPARKLE 俺の声
未適用 40978249 31055202 52577
1 41098033 31274844 52572
5 40800621 31090112 52563
10 40586832 30960017 52560
15 40499597 30931506 52559
20 40483976 30921234 52558
25 40465348 30915117 52557
30 40450833 30910096 52553
50 40397208 30896233 52535
100 40326600 30863911 52532

計算負荷高い。サンプル毎に係数更新しているのが結構効いてるかも…(係数更新で除算使ってるし)。でも次数を増やしても悪化しないのは都合が良い。プリセットの設定がしやすい。

2019.3.31

起床事故。12:00に起きる。マジカルミライの予約してたら14:00。その間に除算を減らした。NLMSは処理を共通化できる。やっておきたい。

あと、今日はversion.5に向けたモジュールソース分割を考えて、手をつけていきたい。秋葉原製作所16:00-21:00の予定。

17:15 NLMSの処理共通化完了。


オンメモリ書き出しへの変更点要点(改訂版)

  • ソースは独立して切る。新規に書き起こす。無駄な部分を消す。
  • シグネチャSL*に変える。
  • 拡張子は.sla。Sound Lossless Audio(良好なロスレスオーディオ)の略。あるいはSHINING LINE*。
  • バージョンは1
  • 再度バイナリフォーマットを考察
  • ブロックサンプル数等、1部フィールドのサイズ見直し
  • エンコードパラメータの整理
  • プリセットを作成。
  • 低圧縮率でデコード早い ? 高圧縮率でデコード遅い
  • メモリ領域読み書きに変える。
  • オンメモリ対応のため。
  • 高速化にもなるはず。
  • ひとまずBitStreamのメモリ版に変えるが、将来的には高速なビット読み書きモジュールを使用する。
  • エンコード・デコードの関数化
  • ストリームエンコード・デコードハンドル作成関数
  • エンコードサイズの計算関数
  • ストリームエンコード・デコード関数
  • 高速化
  • 格子型フィルターを1乗算型に変える
  • 負荷測定
  • 性能検証
  • 比較プログラムの作成。
  • 様々なwavに対してエンコード・デコードし性能(圧縮率と速度)比較
  • TAKと戦っておきたい。

18:46 気になっていたバイトアラインを退治。サイズは1kほど増えたが、汎用性のためには全く問題なし。よし、19:00から思い切ってソース切るか。

20:48 エンコーダ・デコーダ以外はソースを切った。エンコーダデコーダAPIを検討する必要がある。

これは平日に投げよう。21:00になった。

2019.4.2

有給とって作業。なんとしても、今日中に第一版を上げたい。仕様を紙に書いたので、まずはここに複写する。

SLAヘッダ

サイズ(bits) 内容 補足
32 シグネチャ "SL* " Sound Lossless Audio, あるいはSHINING LINE*
32 一番最初のデータブロックまでのオフセット(自分除く) RIFF等の慣習に従って32bit
16 これ以降のフィールドで、ヘッダ末尾までのCRC16
32 フォーマットバージョン番号 1
8 チャンネル数 足りるでしょ…(怠慢)
32 全サンプル数 足りるでしょ…(怠慢)。ストリームエンコード時は未定義=0xFFFFFFFF
32 サンプリングレート 足りるでしょ…(怠慢)
8 1サンプルあたりのビット数 wavへの復元で必要
8 PARCOR係数次数 無音ブロック以外の全ブロックで同一
8 ロングタームタップ数 ブロック毎に異なる
8 NLMS次数 無音ブロック以外の全ブロックで同一
8 チャンネル毎の処理法 無音ブロック以外の全ブロックで同一
32 SLAブロック数 ストリームエンコード時は未定義=0xFFFFFFFF
16 SLAブロックあたりの最大サンプル数
32 最大ブロックサイズ[byte] 最低ビットレートの計算に必要。ストリームエンコード時は未定義=0xFFFFFFFF

ヘッダサイズは38byte。

SLAブロック

サイズ(bits) 内容 補足
16 同期コード0xFFFF アルファ符号は最大で15個までの連続した1を出すから。
32 次のデータブロックまでのオフセット
16 これ以降のフィールドで、次のブロック先頭までのCRC16値
16 このブロックのサンプル数
1 * チャンネル数 無音ブロックか否か?
16 * チャンネル数 * MIN(4, PARCOR係数次数) + 8 * チャンネル数 * MAX(PARCOR係数次数-4, 0) PARCOR係数 最初の4次までは16bit, 残りは8bitで符号化。非線形量子化は行っていない。
1 * チャンネル数 + 26 * ロングターム有りch数 ロングターム係数 ロングタームを使用していないチャンネルは0が入る。1の場合、最初の10bitでピッチ周期、次の16bitで係数が符号化されている。
不定 再帰的ライス符号化された残差 チャンネルインターリーブではない。1ch目の符号化された信号列先頭, ..., 1ch目の符号化された信号列末尾, 2ch目の符号化された信号先頭, ..., 2ch目の符号化された信号末尾,...という並び。

15:56 ヘッダを書き下すところまではOK。現段階では壊れたところは見当たらない。実装を埋めていく。今日でとりあえずの第一版を上げて、レビューを受けたい。間に合ってくれ…!

19:34 エンコーダのやっつけ版ができた。まだコンパイル・テストはしていない。コンパイルを頑張って通すようにして、デコーダに手を付ける。

25:00 なんとかエンコード・デコードができるもの(alpha版1)を作成。

2019.4.3

先輩に見て頂いているが、いろんな問題が見つかっている。

  • M_PIが未定義で怒られる

  • プラットフォームによって圧縮率が異なる

  • まず気になるのはfloatが一部混入している所。思い切ってdoubleにしよう。
    • Rpiでは関係なかった…原因を追っていたら、C89ではroundが定義されていなくて、係数が全部0になっていた。。。std=c99にしたらOKだったけども…。下の独自実装を使う。
  • splintにかけたら負数の右シフトはやべえぞとあった。確かに。算術シフトとは限らないので静的アサートしよう
  • ハッカーのたのしみを引用すると、算術右シフトをやるには以下の式:
/* 算術右シフト(有効範囲:0 <= rshift <= 32) */
#define SHIFT_RIGHT_SIGNED(sint, rshift)    (int32_t)((((uint64_t)(sint) + 0x80000000UL) >> (rshift)) - (0x80000000UL >> (rshift)))
  • デコードに失敗するケースがある

  • テスト追加(移植)

  • 簡単に負荷を測ったところ、RecursiveRice_PutQuotPartの負荷が高かった。パラメータは絶対2の冪だから、決め打ち(ライス符号化)でいいのでは。

double round(double number)
{
    return (number >= 0) ? (double)((int)(number + 0.5f)) : (double)((int)(number - 0.5f));
}
double round(double f)
{
    return (f >= 0.0) ? floor(f + 0.5f) : -floor(-f + 0.5);
}

もう少し警告をうるさくしたいので、オプション探索中。splintもかけたいし、gcc -Wall -Wextra -Q --help=warningsで有効になっている警告を表示できる。

コマンドラインパーサを作る時が来たかも。getopt_longGNU拡張) を自前で実装したもの

性能計測してたら、nlz5の呼び出し回数が多いことが分かった。もしかしたら高速化した方がいいかも。ビットカウント問題に帰着する方法が一番速そう。

2019.4.5

準備で4.4は何もできず。思いついたのはceil(log2(x))は2のべき乗切り上げに変えられるということ。

2019.4.6

4.5は2時間半しか寝てないので今日は12時間寝た。週末はテスト追加と、上記の修正を入れていきたい。

テスト追加はOK。はやめにrepo.作る。-Wpedantic -Wformat=2 -Wconversionをつけて警告を潰す。

14:09 飯食いながら警告を潰した。15:00から2回目なのでここで切り上げる。

macで性能計測する方法がわからなかったので調べた(gprofが使えなくて悲しい)。instrumentsを使う。

$ instruments -t "Time Profiler" ./sla -c voice48a.wav voice48a.sla

実行の結果できあがった.traceファイルを開けばプロファイル結果が見られる。

最適化を気にし始める:

これ以上は、多分根本的に戦って行かないとだめかも。一旦最適化はおいて、CRC16等の機能追加に入ろう。と思ったらCRC16壊れてる。うーんやり直し。秋葉原製作所3時間タイムアップ。

家で作業。CRC16のリファレンスを入手するのにすげえ苦労した。pythonpycrcを使う。

python3 pycrc.py --model=crc-16-ccitt --xor-in=0xFFFF --check-file foo.txt

CRC16の組み込みOK。同時にブロックの次のオフセット記録もOK。未テストだからテスト突っ込みたい。

あとは、いよいよPARCORを1乗算型に変えるかな…

2019.4.7

コンパイラmacclangからgcc-8に変えたら警告がドバーッと出たので消していく。気になるのは論理定数を導入したほうが良さそう(列挙型で良い)。あと1乗算型変更が着手を今日のメインとしたい。できるか…?

CRC16は、CCITT-FALSEよりCCITTにしたほうが良いな。Linuxカーネルでよく使われるのはCCITTだし。と思ったらやめた。CCITT-FALSEでいく。Linux内部でも実装がブレブレ。初期値の与え方、結果の反転のやり方が使用箇所毎に違う。

そして、今assertを消そうと思って-DNDEBUGを入れたら圧縮結果が変わった。これは最適化時に何かが起きている。

→原因が判明。assertマクロ自体(void)0に置き換えてしまうから、なにか副作用のある処理をassertしていると、最適化により処理自体が消されてしまう。SLABitStreamを使うところでassertsしているところが多数あってassertを消すと挙動が変わっていた。

SLABitStream_GetBit の負荷が高い。アルファ符号を取得するときに頻繁に呼ばれる。アルファ符号向けにランレングスを取得する関数を追加すべきか…?

NLZの高速な計算手法があった…もはや黒魔術。

分岐無しで自明に早いので取り込んでいる。

やりたいこと一つ出てきた。ヘッダのエンコードとデコードはハンドル無しでやるべき。(ハンドルがない状態で呼ばれるかもしれないから)。だから、バイト列の読み書きモジュールを新規に追加したい。おそらくヘッダ実装で間に合うはず。

うーん、CRC16の選択にまだ迷う。CCITT-FALSEはCCITTのミスみたいな記述があるし…。

やっぱり社内と統一をとるため、CRC-16/ARCにしようか。

あと、窓関数の変更対応ができてなくてサイン窓固定になってる…変えなきゃ…

2019.4.9

週末は完全に予定が入っているのでなんとか進めたい所。GWの予定も考えていかないと。

CRC16をIBM(ARC)に変えた。

特許調査始めないとダメかも…

  • 特開2013-120225(P2013-120225A)

2019.4.11

特許を見始めているが、権利一体の原則の見地から見ると、おそらく抵触しないのではという感覚。油断せず継続調査。

ヘッダのエンコード・デコードをハンドル無しで行うように修正。 あと、入力が32bit整数ににスケールされている整数というのはなんとなく格好悪い。(例:16bitの65535が32bitのINT32_MAXになっている)

GWでは格子型フィルター演算の高速化・圧縮率改善の最後のあがきをすべきか。ロングタームが1tapしか使えないのがやだ。TAKのサイト見てたら前処理でフィルター入れているとのこと…やってみたい。

2019.4.14

4.14は夕方から秋葉原製作所3hコース。やるべきは、エンコード・デコードのテスト追加か。Create関数をワーク渡しにするのはまだ先としたい(メンバ追加はやりそうだから)。

2019.4.17

15,16はテストを少し追加していただけ。1乗算型PARCORの実装方法をついに見つけた。「音声のディジタル信号処理(上)」のp96だ。

2019.4.18

1乗算型にしようとしてみるがどうもならない。最初に実装した形がそもそも違うように見える…

2019.4.19

TAKの圧縮率にビビる。というか、これもうTAKの勝ちでは…。 TAKは線形予測の前に何かしらのフィルターを使用しているが、もしかしたら、NLMSかも?

下の結果は-p4(最大圧縮率)を使用。

-rwxrwxrwx 1 kiriao kiriao 38580251 Apr 19 18:52 one_two_sweets_offvocal.tak
-rwxrwxrwx 1 kiriao kiriao 28597636 Apr 19 18:52 SPARKLE.tak
-rwxrwxrwx 1 kiriao kiriao    50358 Apr 19 18:52 kisaragi_chihaya.tak
-rwxrwxrwx 1 kiriao kiriao 21068517 Apr 19 18:54 Dream_goes_On.tak
-rwxrwxrwx 1 kiriao kiriao   753612 Apr 19 18:52 voice48a.tak

日に日に乗算結果を64bitで受けている現実が気になってきている。TAKは14bitだという。SSE化を見越した時に有利なのはどちらかは明らかだ。

TAKを越えない限り商品化は厳しいと思う。

2019.4.20

TAKに追いつきたい。まずは今のソースをgitに登録する。→やった。

  • 可変ブロックサイズ対応
  • PARCOR係数から残差電力を求められたはず。これで(もしくは符号長から)、最も残差電力が小さくなるブロックサイズを決める。
  • フィルタ処理の追加
  • TAKでは線形予測の前にフィルタを入れている。ローパス、ハイパス、NLMSを入れてみてどうなるか見る。
  • 平均が小さい時にLZ符号化を試す
  • やってみたけど芳しくない。増える傾向。一方で適応的ハフマンを使ったら圧縮率がわずかに上がった。でも多分、幾何分布に従うことを考えて静的でも良いかもしれない。この結果は参考にしたい。

まずは可変ブロックサイズ対応の前段階として、PARCOR係数による残差電力が実際の残差電力と一致するか観察する。 →そこそこ一致。傾向は合ってるかも。計算は0次自己相関*Π(1-PARCOR^2)でやった。誤差が出ているのはfloatじゃないのが問題かも。理論はおそらく正しい。

以下にその説明有り。

得られたPARCOR係数から残差電力を計算する関数を追加しておく。しかし係数の当てはまりの良さを考えるなら、Π(1-PARCOR^2)(分散比。分散をどれだけ減らせたのかの比。)だけで良いはずなのでこれを計算する関数を追加した。エンコーダはこれを使って最小の残差を与えるブロックサイズを探す方針。

次は、というか今日のメインとして、線形予測前にフィルタを突っ込んで見る。あと30分しかないけど!

→NLMSを突っ込んだが悪化。FIRローパスは短い音声で大悪化、長い音声でほんの少し減少。他にできることがないか探してみる。

2019.4.21

可変ブロック対応に当たり、上の論文を読んでいたら、ラプラス分布を仮定したときの符号長推定について書いてあった。これは大変に有益。これを使い、サンプルあたりの符号長としてブロックサイズを決めてみたい。

16bit整数として計算したときに、かなりの精度で予測できていることが分かった。計算量的にも大きくないから、取り入れていく。

なんだか実験がうまく行っていて、残り1時間あるからエイヤで組み込んでしまうか。

なんか組み込めた。そして減った。観察の結果は次:

  • SPARKLEと俺の声は減った。しかし、ワン・ツー・スゥイーツでは増えている。
  • 窓をかけてPARCOR係数を計算して推定を行うと、圧縮率が悪化する。
  • 最大ブロックサイズを10240(232ms @44.1kHz)まで伸ばすべきかも。
  • 無音時にどうなっているか怪しい。

バグの調査が甘い(一応戻ることは確認している)が、速報値は以下:

-rw-r--r--@  1 *  staff  40672844 Apr 21 20:45 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  30850345 Apr 21 20:51 SPARKLE.sla
-rw-r--r--@  1 *  staff     51915 Apr 21 20:48 kisaragi_chihaya.sla

家帰って試行錯誤。まずはfloatの正規化が抜けていたのでpow(2,-31)をかけた。また、最小ブロックサイズを小さくしすぎると(1024とか)ワン・ツー・スゥイーツの性能が悪くなった。逆に長くすると(4096とか)俺の声が悪化。

一つバグがあって(符号長のチャンネル平均が取れていなかった)潰したところ、性能改善。

-rw-r--r--@  1 *  staff  40245317 Apr 22 00:02 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  30800189 Apr 22 00:03 SPARKLE.sla
-rw-r--r--@  1 *  staff     51776 Apr 22 00:03 kisaragi_chihaya.sla

最大ブロックサイズを16384までしたところ次の結果:

-rw-r--r--@  1 *  staff  40148214 Apr 22 00:30 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  30783283 Apr 22 00:32 SPARKLE.sla
-rw-r--r--@  1 *  staff     53486 Apr 22 00:31 kisaragi_chihaya.sla

たぶん最適割り当て問題になっている。今は、現在与えられたサンプル列を一番小さく符号化できそうなブロックサイズを使用している。これはグリーディな方法と言える。もしかしたら、エンコードすべきブロックの内容の先読みなり最適割り当てを行ったほうが性能がいいかも。当然良いはず。最大ブロック数分サンプルを見て、その中で最適な分割を探す問題とする。

非線形量子化、危ないけど導入すべきか…あと線形予測前のフィルターも気になる…。TTAを参考にすべきか。

2019.4.22

TTAのソースの可読性が著しく低い(愚痴)。filter関数ですべてをやり切ってるけど、何やってるかさっぱり。コメントもない。 へらへらしていたら、Levinson-Durbin法とは別にBurg法というものがあることを知った。周波数分解能が高い(他に問題もある)らしい。

家帰って実装をしてみた。C++実装をもろ写経。予測してみたけどいい感じ(LPCより予測精度が高い)。 問題はPARCOR係数の解釈があっているかどうかというところ。

2019.4.23

Burg法実装がプロトタイプでできたので組み込んで様子を見る。三角関数の重ね合わせではLevinson法よりも予測精度が良かったけど、実wavに対しては良くならなかった。(窓を外しても、サイズを固定にしてもだめ)全体的にサイズ増加。何がいけないのかもよくわからない…。

改めて残りの減少ネタ。上から優先順位高い方:

  • float → double
  • ブロックサイズ決定を最大ブロックサイズから初め、最大ブロックサイズの中の小分割の中で一番サイズが小さくなるものを採用する
  • エンコード高速化(最大ブロックサイズ毎で処理が独立になるので並列実行可能)にもなるので、こちらで行きたい。
  • ロングタームを3次以上に対応させる
  • 平均(もしくは最大値が0xFF以下)が少ないときの符号化をハフマンに
  • 分散が異なるラプラス分布(もしくは幾何分布か?)のハフマン符号テーブルを作っておく。
  • 線形予測前のフィルター処理
  • TAKのページを改めて見ると、2つのフィルターを本チャンの線形予測フィルタの前に入れることができるとのこと。
  • 一つは窓関数かもしれない。もう一つは一体何だ?プリエンファシスでは無いと思う。
  • 平均除去とか?
  • ブロックサイズ推定を実測してみる
  • 窓関数の再考
  • sin窓を今だに使い続けている
  • Lanczos窓とかどうだろうか

2019.4.25

小松観光計画

基本はGAFの聖地を優先。しかし一日で回りきれそう。空いた時間は風呂にしたい。

日付 何するか
4/27 - コーデック圧縮率向上施策考案
- コーデック評価スクリプト作成
- デコードテスト追加
4/28 - プリパラフレンドシップツアー
- 秋葉原で一泊
4/29 - 絵師百
- 深夜バス乗車(渋谷)
4/30 - 小松駅着。ロッカーに荷物を入れて聖地巡礼開始。
- 本屋→神社→安宅→小松基地
- 昼は8番ラーメン
- 夜は海鮮丼。駅前に戻って松屋旅館へ。
5/1 - 温泉につかりながら作業
- 加賀の宿 柴山温泉 ホテル翠湖で一泊。
5/2 - 温泉につかりながら作業
- 金沢18:09発の新幹線で移動→19:59佐久平着。

2019.4.26

ラプラス分布の最尤推定について。なんと、平均が0ならば単純な絶対値の標本平均が分散になる。

2019.4.27

コーデック評価スクリプトを昨晩にやっつけで仕立て上げた。ほしいのは以下の表。CSVで出せると良い。

圧縮率
波形 / コマンド 元波形[byte] flac -8[byte] flac -8[%] wavpack -hh[byte] wavpack -hh[%] ...
いばらの女王 20000000 12000000 50% ... ...
ハローハロー 22000000 14000000 63% ... ...
累計[%] 42000000 26000000 62% ... ...
デコード速度
波形 / コマンド 元波形[ms] flac -8[ms] flac -8[x] wavpack -hh[ms] wavpack -hh[x] ...
いばらの女王 2000 20 100 ... ...
ハローハロー 2200 22 100 ... ...
累計[%] 4200 42 100 ... ...

秋葉原製作所5hコースで作業し、上記の表に該当する結果は得られた。軽く自分の声で試してみると、やはりまだ圧縮率が悪い。。。tta,wavpackよりも下。振幅が小さいデータに対する圧縮率が悪い傾向がある。

2019.4.29

今日は22:45渋谷発小松行きに乗るまでで作業する。やることはラプラス分布の最尤推定の当てはまりがどれくらい良いか確かめること。

見ているけどラプラス分布で当てはまりはあまり良くない…。正規分布はひどい(0近辺の当てはまりが絶望的)。幾何分布が一番当てはまりが良い印象(SPARKLEはよく当てはまるが、それ以外の音源で微妙…)。やるとしても幾何分布か…。

そもそも、符号化手法を考え直すべきか…。適応的に分布が小さくなっていたらランレングスに切り替える符号化有り。

wavpackの動作原理はわかっている(つもり)だから、TTAのソース読もうか…

__forceinline void tta_encoder_put_value(TTA_adapt *rice, TTAint32 value) {
    TTAuint32 k, unary, outval;

    outval = ENC(value);

    // encode Rice unsigned
    k = rice->k0;

    rice->sum0 += outval - (rice->sum0 >> 4);
    if (rice->k0 > 0 && rice->sum0 < shift_16[rice->k0])
        rice->k0--;
    else if (rice->sum0 > shift_16[rice->k0 + 1])
        rice->k0++;

    if (outval >= bit_shift[k]) {
        outval -= bit_shift[k];
        k = rice->k1;

        rice->sum1 += outval - (rice->sum1 >> 4);
        if (rice->k1 > 0 && rice->sum1 < shift_16[rice->k1])
            rice->k1--;
        else if (rice->sum1 > shift_16[rice->k1 + 1])
            rice->k1++;

        unary = 1 + (outval >> k);
    } else unary = 0;

    // put unary
    do {
        while (enc_fifo_bcount >= 8) {
            write_byte(enc_fifo_bcache);
            enc_fifo_bcache >>= 8;
            enc_fifo_bcount -= 8;
        }

        if (unary > 23) {
            enc_fifo_bcache |= bit_mask[23] << enc_fifo_bcount;
            enc_fifo_bcount += 23;
            unary -= 23;
        } else {
            enc_fifo_bcache |= bit_mask[unary] << enc_fifo_bcount;
            enc_fifo_bcount += unary + 1;
            unary = 0;
        }
    } while (unary);

    // put binary
    while (enc_fifo_bcount >= 8) {
        write_byte(enc_fifo_bcache);
        enc_fifo_bcache >>= 8;
        enc_fifo_bcount -= 8;
    }

    if (k) {
        enc_fifo_bcache |= (outval & bit_mask[k]) << enc_fifo_bcount;
        enc_fifo_bcount += k;
    }
} // tta_encoder_put_value

おそらく2つのライス符号パラメータで再帰ライス符号になっている。値が小さいときの処理は特にしていないように見える(固定フィルター(31/32) *(前サンプル)のあとに謎の適応フィルタを入れている。 固定フィルターはプリエンファシスだ。そういえば整数で試してなかった。俺も試すべき)。

#define PREDICTOR1(x, k) ((x * ((1 << k) - 1)) >> k)

/* ...snip... */

        // compress stage 1: fixed order 1 prediction
        temp = curr;
        curr -= PREDICTOR1(enc->prev, 5);
        enc->prev = temp;

FLACについても、値が小さいときの処置は特に無い。wavpackも多分無い(読んでみようと思うが…)。

2019.4.30

小松観光。ガーリー・エアフォースの聖地を一通りあさった。今日はあんまり何もできないだろうけど、明日明後日は場所を変えて作業するつもり。5/3からは実家にて作業予定。

上記のプリエンファシスを試してみる…と100KBクラスで減少した。効果あり。

-rw-r--r--@  1 *  staff  40129181 Apr 30 23:07 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  30704135 Apr 30 23:06 SPARKLE.sla
-rw-r--r--@  1 *  staff     51787 Apr 30 23:07 kisaragi_chihaya.sla

実装を整理(関数化)して就寝。令和が始まった。 振幅が小さい音声の圧縮率がwavpack, ttaと比べて低いのが気になる。

2019.5.1

15:00ホテル翠湖にチェックイン。wi-fiが飛んでいないので、オフラインで作業する。

テーマを1つ決めて試してみたい。昨日今日でやろうと思ったのが、非線形量子化。以前試した時はむしろ悪化する事がわかっていた。そこで、今回は2次成分までをarcsinによって非線形量子化してみた。

結果は、微減(俺の声は1バイト減少、SPARKLEは数百バイト減少、ワン・ツー・スィーツは数十バイト減少)。16bitも割り当ててあれば線形量子化でも十分ということを示している結果だと思う。本を読んでいると、ビット割当数は4-12bitと低くなっている。如何に低いビット数で同一の結果が出せるか…というところに着目すると、非線形量子化は効いてくるらしい。もし、極限までサイズを減らすことを考えるならば、非線形量子化を適用して良いかもしれない。が、処理の単純化(サイズ削減が処理の複雑化に対して見合ってない)と、減らせるサイズが高々数KBで本質的にサイズ削減になっていないので、16bitで良いと思う。

非線形量子化があまり美味しい策では無いことが分かった。本日は、ブロックサイズ決定の処理を

  • ブロックサイズ決定を最大ブロックサイズから初め、最大ブロックサイズの中の小分割の中で一番サイズが小さくなるものを採用する
  • エンコード高速化(最大ブロックサイズ毎で処理が独立になるので並列実行可能)にもなるので、こちらで行きたい。

に変えてみる。これ、一見減らないように見えるけどどうだろうか。FLACはこれとほぼ同じやり方をしている。wavpackTTAのブロックサイズ決定方式を見て、風呂に入る。

  • TTAはサンプリングレート依存で決まる固定サイズっぽい。(かなり大きい。フィルターがLPCじゃないから、20ms程度にしなくてもOKなのかも)
typedef struct {
    TTAuint32 format;   // audio format
    TTAuint32 nch;  // number of channels
    TTAuint32 bps;  // bits per sample
    TTAuint32 sps;  // samplerate (sps)
    TTAuint32 samples;  // data length in samples
} TTA_ALIGNED(16) TTA_info;
#define MUL_FRAME_TIME(x) (256 * (x) / 245) // = x * FRAME_TIME

/* ...snip... */
    dec_flen_std = MUL_FRAME_TIME(info->sps);
  • wavpackはサンプリングレートとチャンネル数依存ぽい。けど謎ルール。。。コメントに妥協しているみたいなことが書いてある。計算の結果wpc->block_sizeにブロックサイズが入り、処理途中に変更することはない。
int WavpackPackInit (WavpackContext *wpc)
{
    if (wpc->metabytes > 16384)             // 16384 bytes still leaves plenty of room for audio
        write_metadata_block (wpc);         //  in this block (otherwise write a special one)

    // The default block size is a compromise. Longer blocks provide better encoding efficiency,
    // but longer blocks adversely affect memory requirements and seeking performance. For WavPack
    // version 5.0, the default block sizes have been reduced by half from the previous version,
    // but the difference in encoding efficiency will generally be less than 0.1 percent.

    if (wpc->dsd_multiplier) {
        wpc->block_samples = (wpc->config.sample_rate % 7) ? 48000 : 44100;

        if (wpc->config.flags & CONFIG_HIGH_FLAG)
            wpc->block_samples /= 2;

        if (wpc->config.num_channels == 1)
            wpc->block_samples *= 2;

        while (wpc->block_samples > 12000 && wpc->block_samples * wpc->config.num_channels > 300000)
            wpc->block_samples /= 2;
    }
    else {
        int divisor = (wpc->config.flags & CONFIG_HIGH_FLAG) ? 2 : 4;

        while (wpc->config.sample_rate % divisor)
            divisor--;

        wpc->block_samples = wpc->config.sample_rate / divisor;

        while (wpc->block_samples > 12000 && wpc->block_samples * wpc->config.num_channels > 75000)
            wpc->block_samples /= 2;

        while (wpc->block_samples * wpc->config.num_channels < 20000)
            wpc->block_samples *= 2;
    }

wavpackの予測はsign-sign LMSに基づいているらしい。

3番目の記事を読んでいたら、Signed LMSは絶対値誤差の最小化に基づいているので、もしかしたらライス符号化に適しているかもしれない。実装は簡単なので早速試したところ、俺の声は1バイト減少したが、SPARKLEとワン・ツー・スィーツは悪化。これは、大振幅音源に弱いという、wavpackと同様の傾向を示している?

ちょっと待て、sign-sign LMS...性能高いのでは…?今までのNLMSの性能を超えている(タップを増やした時のサイズ減少が大きい)。ちょっと冷静になるために風呂に入る。確かめること:

  • 係数の重み
  • 高次数にした時は重みを小さくしないと性能悪化に転じる。
  • 高次数で小さくなるような重み付けをすると性能改善が見られた。次数を増やすと性能悪化することもあった。次数に応じた重み付けを定式化できると良さそう。
  • カスケード接続は有効か?
  • 一部有効だった。(次数20を1回適用するより、次数5を4回適用したほうが減る。しかし、1つあたり次数を1,2等減らしすぎると悪化する。これはNLMS(正規化LMS)では見られなかったことだ。)

冷静になってwavpackの実装を見ている。decorr_tables.hにテーブルが示されているが固定値のマジックナンバーにしか見えない…。

sign-sign LMSが有効で、NLMSよりも良い結果が出せることが明らかになったため、NLMSをsign-sign LMSに切り替える。同時にカスケード数をパラメータ化する。

軽く負荷を測ったらLMSの係数更新で結構食ってた。でも、係数更新は符号だけできまるから、テーブル引きに変えられるはず。→2019.5.2の朝にやった。x400がx200になった。しかしまだ負荷が高い状態。

2019.5.2

金沢に移動。特急券の時間を変えてもらって16:09発の新幹線に乗った。17:56佐久平着までに進められるだけ進める。やりたいのは、上記の高速化。

『音声の線形予測』を読んでいると、1乗算型を実現するのは困難であることが分かる。1乗算型は通常の格子フィルタをKelly-Lochbaumモデルに変形してから導き出すが、それを行うと、追加でタップパラメータを計算する必要が出てくる。タップパラメータの計算精度を担保するのは難しい上に、(次数分の)追加の記憶容量が必要になるので到底許容できない。

2019.5.3

実家にて作業。RGRいわきはしゃあない。圧縮をどうしても優先したかった(人生に関わることだから)。本日は以下の作業を行う予定:

  • float → double
  • ブロックサイズ決定を最大ブロックサイズから初め、最大ブロックサイズの中の小分割の中で一番サイズが小さくなるものを採用する
    • エンコード高速化(最大ブロックサイズ毎で処理が独立になるので並列実行可能)にもなるので、こちらで行きたい。

float -> doubleはエイヤでやる。なまじ高速化を意識するから気持ちが悪いことになっているのだ。doubleでちゃんと動くものを作って(アルゴリズム的に高速化して)、後で実装レベルの高速化を行えば良い。 →やった。

ブロックサイズ決定の前に、今の圧縮結果をメモしておく。

-rw-r--r--@  1 *  staff  39849911 May  3 12:37 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  30014592 May  3 12:37 SPARKLE.sla
-rw-r--r--@  1 *  staff     51122 May  3 12:36 kisaragi_chihaya.sla
-rw-r--r--@  1 *  staff    777422 May  3 12:40 voice48a.sla
-rw-r--r--@  1 *  staff  23332503 May  3 12:39 Dream_goes_On.sla

当初の目標(ワン・ツー・スィーツで40MB切る)は既に達成済みではある。長尺の音声ではwavpack(-hhの最高圧縮), ttaよりよい圧縮率を出している状況。しかし眼前にはTAKがいる。

最大ブロックサイズの小分割の件、等分割による実装はできたが、圧縮率が悪化。当然な気がする。以前は現段階での最小推定値を常に使用していたのだから。最大ブロックサイズ内の分割についていい方法は無いか考えていたら、どうも最短経路問題に帰着できそうな気配。符号長さが辺の重みになる。ダイクストラ法が適用できる。

22:45 ダイクストラ法のコア部分は多分できている(テスト中)。風呂入っている時に、アルファ符号取得の高速化は8bitパターンの結果を全てキャッシュしておけば良さそうだというのを思いつく。

static const uint8_t zero_runlength_table[0xFF] = {
    /* 0 -> 8 */ 8, /* 1 -> 0 */ 0, /* 2 -> 1 */ 1, ...
};
run = zero_runlength_table[bitsbuf];
/* もし8ならばまだ続いているので再度読み込む */

25:30 やっつけでなんか動いているけど、結果はあまり良くない。等分割よりはすこし良くなった程度。しかし、一つ工夫を考えられた。探索範囲を広くとってその中で探索する。その時大事なのが最大ブロックサンプル数=探索範囲とせず、最大ブロックサンプル数<探索範囲とすること。こうすることで、より広い範囲の探索で最適な割り当てを探れるようになるはず。

26:20 上記の修正を当てようとしてバグを踏んでる。エンコードコンフィグの最大ブロックサイズを探索範囲より小さくし、最大ブロックサンプル数<探索範囲としたときにバッファオーバーランしておかしなことになってる。探索範囲もコンフィグから指定できると良い。

2019.5.3

デバッグ作業。無音に近い時に推定符号長が負値になってダイクストラ法がうまく動かないバグがあった。

とりあえず動いているようだけども結果は良くない。短い音声では良くなったが、長い音声で軒並み悪化。あがいてプリエンファシスをかけた音声に解析を行うけども結果は悪化。

振幅が大きい音声では、どうも長めにブロックサイズを割り当てた方がサイズが減るようだ。(最低ブロックサイズを増やしたところ比較的性能向上)LMSがいい味出していて、収束して圧縮が効いてくるまでに長いブロックサイズを必要としているように見える。

しっかし原理的にはその場で最短符号を探すよりも、広い範囲での最短符号を探したほうが絶対良いと思うのだが…実装ミスを疑う。

あとは、探索範囲を広げてみる。→傾向は上と同じ…最低ブロックサイズに引っ張られている。原理的に減るはずなのに、おかしい…。

推定コード長にブロックヘッダサイズを付加することで多少安定した。それでも傾向はほぼ同じ。もしかして原理的に減らないのかもしれない。グリーディな方法と選ばせるのが良いか?

→最大ブロックサイズを16384から12288に変えたら、比較的結果が安定した。16384では長すぎる?

-rw-r--r--@  1 *  staff  39868406 May  4 18:54 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  30161132 May  4 18:54 SPARKLE.sla
-rw-r--r--@  1 *  staff     50984 May  4 18:53 kisaragi_chihaya.sla
-rw-r--r--@  1 *  staff    772613 May  4 18:54 voice48a.sla
-rw-r--r--@  1 *  staff  23259269 May  4 18:55 Dream_goes_On.sla

短くかつ振幅が小さい音源の性能が改善したが、振幅の大きい音声(特にSPAKLE)は悪化。

いろいろあがいていたら20:30。終わりが見えてきている。ブロックヘッダサイズを大きくとったら全体的に性能が安定した。どうやら、パスを長くした時のペナルティを多くしたほうが性能が安定するようだ(実際、ブロックサイズを細かくしすぎると、ブロック先頭の残差増加や、LMSが収束しない等が発生してサイズが増加する)。ペナルティサイズを350byteにした時の結果は以下:

-rw-r--r--@  1 *  staff  39761815 May  4 21:38 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  30049221 May  4 21:38 SPARKLE.sla
-rw-r--r--@  1 *  staff     51077 May  4 21:39 kisaragi_chihaya.sla
-rw-r--r--@  1 *  staff    773953 May  4 21:39 voice48a.sla
-rw-r--r--@  1 *  staff  23297954 May  4 21:39 Dream_goes_On.sla

全部下がったわけではないが、性能は安定しているようだし、これで一旦Fixとしようか。(グリーディな方法と比較したところ、自分の声シリーズで0.2%改善、アイカツ楽曲で0.1%悪化。今の状態でバランスが取れたし、また並列エンコードへの道が見えたからこれでFixとする。)

→コードを整理してコミット。

時間がかかるようになっているので、ネックになっているところを調べたら自己相関が馬鹿になっていなかった。自己相関を簡単に高速化した。

  /* (標本)自己相関の計算 */
  for (delay_time = 0; delay_time < order; delay_time++) {
    auto_corr[delay_time] = 0.0f;
    /* 係数が0以上の時のみ和を取る */
    for (i_sample = delay_time; i_sample < num_sample; i_sample++) {
      auto_corr[delay_time] += data[i_sample] * data[i_sample - delay_time];
    }
  }

上記の計算だと積算で使用する項に重複が出る。重複を排除したのが以下の計算(『音声の線形予測』とFLACを参考にしている)。重複する項をtmpに受けて積和演算を行っている。

  /* 係数初期化 */
  for (lag = 0; lag < order; lag++) {
    auto_corr[lag] = 0.0f;
  }

  /* 次数の代わりにデータ側のラグに注目した自己相関係数計算 */
  for (smpl = 0; smpl <= num_sample - order; smpl++) {
    tmp = data[smpl];
    /* 同じラグを持ったデータ積和を取る */
    for (lag = 0; lag < order; lag++) {
      auto_corr[lag] += tmp * data[smpl + lag];
    }
  }
  for (; smpl < num_sample; smpl++) {
    tmp = data[smpl];
    for (lag = 0; lag < num_sample - smpl; lag++) {
      auto_corr[lag] += tmp * data[smpl + lag];
    }
  }

根本的にはFFTを使うべき…。

2019.5.4

明日の帰りが早いこともあるので今日は大きな実装変更はしない予定。エンコード負荷が気になるので計測と可能ならば手直しを入れる。

ロングタームの3,5,...対応はまだ後回し。

負荷結果をざっと見ると、負荷が大きいのは自己相関計算に尽きる。

  • 最適分割探索の際の係数計算における自己相関
  • ロングターム係数計算時のFFTによる自己相関

SIMD, OpenMPで頑張るのはまだ先の話。(俺がやるべきでも無いと思う)

LMSの更新量の重みを上げた(右シフト9から右シフト7に変えた)ところ性能が上がった…。(右シフト6では悪化に転じた。)

-rw-r--r--@  1 *  staff  39571790 May  5 16:31 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  29824752 May  5 16:30 SPARKLE.sla
-rw-r--r--@  1 *  staff     50937 May  5 16:30 kisaragi_chihaya.sla
-rw-r--r--@  1 *  staff    770970 May  5 16:32 voice48a.sla
-rw-r--r--@  1 *  staff  23047704 May  5 16:34 Dream_goes_On.sla

まだSign-Sign LMSには謎が多い。一回腰を据えて適応フィルタの理論を読むべきか。→日本語版が法外に高いので英語版を購入。

Sign-Sign LMSの計算途中で、係数が32bitの範囲でオーバーフローしていることが分かった。係数を32bitにしたら圧縮性能が堕ちたので判明。FIRフィルターだから係数の範囲は予測できない…。どっかで制限をかける等できれば…。

2019.5.5

昨日の自己相関の計算が遅い件について、もう少し早いアルゴリズムが『音声のディジタル信号処理(上)』の172pあたりに書いてあったので実装中。

→実装したが速度に納得できず、しかも複雑になっている。本に書いてある計算式は変形自己相関で、データのインデックスが飛び出ることを許す式になっている。(平均を常にNで割って行える式)なので自前で簡潔な実装にしようとしたところ、案の定ハマる。

RL見なければいけないので一旦置く。。。

2019.5.7

5.6は実家から返りながら上の自己相関計算の高速化をやっていた。変形自己相関ではない方法で計算する実装は2019.5.7にできた。テストもOKで、2倍とは行かないまでもSPARKLEで自己相関計算負荷が44%が39.8%になっているのは確認した。有意に早くなっている。

2019.5.13

いよいよ手詰まりとなる。(ロングターム係数を増やすのはまだだが)

TAKのデコーダ実装がffmpegに含まれていた:

といっても新しいバージョンではデコードできないとのこと。。。(パッチも当てられていない…)。読んでいるが、謎のテーブルを使用しているのが目につく。(TAKの公式ページではハフマンとライスを組み合わせたものと言っていた。だから、ライス符号パラメータをインデックスにした静的ハフマン符号ではないかと予測する。)

ロングターム係数の次数を増やして、効果を見て区切りかな。 他に気付いている点は、格子型フィルタの前向き誤差は実はメモリに持たなくても実装できる点くらいだろうか…

2019.5.18

平日は時間あまり取れず。やっつけでLU分解のソースを移植したくらい。LU分解では処理中にワーク領域を必要としていたので、ハンドルをもたせた。また、計算時のユーティリティだから、SLAUtilityに置く。

→15:20 LU分解によるソルバー追加完了。あとは解いて様子見。

思いつきでPARCOR音声合成の僅かな高速化。実は合成時は前向き誤差を保存する必要はない。

    /* 誤差入力 */
    forward_residual[order] = (int64_t)residual[samp];
    for (ord = order; ord >= 1; ord--) {
      /* 前向き誤差計算 */
      mul_temp = SLAUTILITY_SHIFT_RIGHT_ARITHMETIC(parcor_coef[ord] * backward_residual[ord - 1] + half, 31);
      forward_residual[ord - 1] = forward_residual[ord] + mul_temp;
      /* 後ろ向き誤差計算 */
      mul_temp = SLAUTILITY_SHIFT_RIGHT_ARITHMETIC(parcor_coef[ord] * forward_residual[ord - 1] + half, 31);
      backward_residual[ord] = backward_residual[ord - 1] - mul_temp;
    }
    /* 合成信号 */
    assert((forward_residual[0] <= INT32_MAX) && (forward_residual[0] >= INT32_MIN));
    output[samp] = (int32_t)(forward_residual[0]);
    /* 後ろ向き誤差計算部にデータ入力 */
    backward_residual[0] = forward_residual[0];
    /* 誤差入力 */
    int64_t forward_res = residual[samp];
    for (ord = order; ord >= 1; ord--) {
      /* 前向き誤差計算 */
      mul_temp = SLAUTILITY_SHIFT_RIGHT_ARITHMETIC(parcor_coef[ord] * backward_residual[ord - 1] + half, 31);
      forward_res += mul_temp;
      /* 後ろ向き誤差計算 */
      mul_temp = SLAUTILITY_SHIFT_RIGHT_ARITHMETIC(parcor_coef[ord] * forward_res + half, 31);
      backward_residual[ord] = backward_residual[ord - 1] - mul_temp;
    }
    /* 合成信号 */
    assert((forward_res <= INT32_MAX) && (forward_res >= INT32_MIN));
    output[samp] = (int32_t)(forward_res);
    /* 後ろ向き誤差計算部にデータ入力 */
    backward_residual[0] = forward_res;

前向き誤差がキャッシュされるので当然早くなる。SPARKLEで100ms(全体で15.8%→10.7%)程の改善。遊んでないで、ロングタームに戻ろう。

ロングターム実装OK。早速、タップ数を上げて試してみる。

-rw-r--r--@  1 *  staff  39556836 May 18 16:57 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  29836474 May 18 16:56 SPARKLE.sla
-rw-r--r--@  1 *  staff     50923 May 18 16:58 kisaragi_chihaya.sla
-rw-r--r--@  1 *  staff    770757 May 18 16:55 voice48a.sla
-rw-r--r--@  1 *  staff  23064285 May 18 16:58 Dream_goes_On.sla
-rw-r--r--@  1 *  staff  39568754 May 18 17:02 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  29847311 May 18 17:03 SPARKLE.sla
-rw-r--r--@  1 *  staff     50930 May 18 17:01 kisaragi_chihaya.sla
-rw-r--r--@  1 *  staff    771036 May 18 17:01 voice48a.sla
-rw-r--r--@  1 *  staff  23064514 May 18 17:03 Dream_goes_On.sla

上げたら悪化(効果はあまり大きくない)。これはもしかしたらロングターム係数失敗回数が多くなっているのかもしれない。簡単に調べたところその通りで、SPARKLEでは、タップ数3で406回、タップ数5で742回失敗していた。係数が安定するまでタップ数を落とすのがいいかも。(とりあえず今は、係数が発散していたらタップ数を強制的に1にしている。)また、ロングタームを複数回適用するのも有りかも。(効果は薄そう…一番のピッチをロングタームで潰しても少ししか効果がなかったし…)

実装をまとめた。これにてベータ版としたい。もう1MB減らすアイデアがあればTAKを倒せるが…。

2019.5.19

以下の論文を読んでいた:

要は、LMSの計算の係数更新で、最も近い2の冪数に変えて演算するように変えたもの。今はSign-Sign LMSだが、筆者は論文の中で、それは非常に荒く量子化した状態と同じと言及していた(理論的には、絶対値誤差を最小にしているのだが…)

そこで、Sign-Signをナイーブにやるのではなく、負荷は上がるけど誤差項のみlog2を取るように変えてみた(注:上の論文とは違う。論文では最も近い2の冪数にしていたが、こっちは単純にlogをとっている)ら、ほとんどの音源で性能が向上。

-rw-r--r--@  1 *  staff  39555825 May 19 18:45 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  29780060 May 19 19:04 SPARKLE.sla
-rw-r--r--@  1 *  staff     50879 May 19 19:02 kisaragi_chihaya.sla
-rw-r--r--@  1 *  staff  23082381 May 19 18:47 Dream_goes_On.sla
-rw-r--r--@  1 *  staff    770037 May 19 18:53 voice48a.sla

(Dream goes onで性能悪化している。それ以外は向上。)

どうするか。これ取り込んでFixとする?→取り込み、更新をテーブル引きにした。これで一旦beta版としよう。

2019.5.21

LMSの係数更新って毎サンプル行う必要はあるのだろうか。更新間隔を間引いてもいいのかも?

VSで負荷計ったら、復号処理でアルファ符号を取得するところが遅いことが分かった。やはりバイトパターンテーブルからランレングスを取るのがいいかも。やってみる。

他にも自己相関の加算対象はオート変数が良いかも。

2019.5.23

コマンドラインパーサを作りたい。業務が終わらんくてあんまり作業できてない。

なんとかアルファ符号取得時にテーブルを使用するように変えて、速度向上。もう一度負荷計測したら、GetBitsとそのLog2Ceilで負荷がかかっていた:

  /* ライス符号の剰余部分取得 */
  ret = SLABitStream_GetBits(strm, SLAUtility_Log2Ceil(m), &rest);

この引数で渡しているmは2の冪数だから、高速にlog2できないか?

2019.5.25

みなとみらい(ランドマークプラザ)のコメダ。 今日はlog2ceilの高速化をまずやってコマンドラインパーサの仕様を考える。log2ceilの高速化まあOK。要はテーブル引き。効果はわずかだが、確かに早くはなっている。

コマンドラインパーサの仕様を考える。まず汎用に使いたいので名前はcommand_parser.[ch]とする。ヘッダは、

#include <stdint.h>

/* 最大の文字列バッファサイズ */
#define COMMAND_PARSER_MAX_STRING_BUFFER_SIZE   256

/* 取得結果 */
typedef enum CommandPaeserResultTag {
    COMMAND_PARSER_RESULT_OK,                             /* 正常終了 */
    COMMAND_PARSER_RESULT_INSUFFICIENT_FILE_BUFFER_SIZE,  /* ファイルバッファサイズが足らない */
    COMMAND_PARSER_RESULT_NOT_SPECIFY_OPTION_TO_ARGUMENT, /* 引数の指定が必須のオプションが指定されていない */
    COMMAND_PARSER_RESULT_NOT_SPECIFY_MANDATORY_OPTION,   /* 指定が必須のオプションが指定されていない */
    COMMAND_PARSER_RESULT_UNKOWN_OPTION,                  /* 定義にないオプションが指定された */
} CommandPaeserResult;

/* 論理定数 */
typedef enum CommandParserBoolTag {
    COMMAND_PARSER_FALSE = 0,   /* 偽 */
    COMMAND_PARSER_TRUE,        /* 真 */
} CommandParserBool;

/* コマンドラインパーサ仕様 */
struct CommandParserSpecification {
    char                short_option;       /* [in] 短いオプション文字列 */
    const char*         long_option;        /* [in] 長いオプション文字列 */
    CommandParserBool   need_argument;      /* [in] オプションに引数は必要か? */
    CommandParserBool   mandatory;          /* [in] 引数の指定は必須か? */
    const char*         description;        /* [in] 引数の説明 */
    char                argument_string[COMMAND_PARSER_MAX_STRING_BUFFER_SIZE]; /* [out] 得られた文字列 */
    CommandParserBool   is_acquired;        /* [out] オプションが指定されたか? */
};

/* 引数説明の印字 */
void CommandParser_PrintDescription(const CommandParserSpecification* cps);

/* 引数のパース */
CommandPaeserResult CommandPaser_ParseArguments(
    int32_t argc, const char** argv,
    struct CommandParserSpecification* cps,
    char** filename_list, uint32_t filename_list_size);
struct CommandParserSpecification arguments[] = {
    /* 入力ファイル: ショートオプション'i', ロングオプション"input", 引数必須, 指定必須 */
    { 'i', "input", COMMAND_PARSER_TRUE, COMMAND_PARSER_TRUE, "input file", "" },
    /* 出力ファイル: ショートオプション'o', ロングオプション"output", 引数必須 */
    { 'o', "output", COMMAND_PARSER_TRUE, COMMAND_PARSER_FALSE, "output file", "" },
    /* 最適化オプション: ショートオプション'p', ロングオプションなし, 引数必須 */
    { 'p', NULL, COMMAND_PARSER_TRUE, COMMAND_PARSER_FALSE, "optimization level", "" },
    /* 情報表示: ショートオプション'v', ロングオプション"verpose" */
    { 'v', "verpose", COMMAND_PARSER_FALSE, COMMAND_PARSER_FALSE, "verpose information", "" },
    /* サイレントモード: ショートオプション's', ロングオプション"silent" */
    { 's', "silent", COMMAND_PARSER_FALSE, COMMAND_PARSER_FALSE, "silent mode", "" },
    NULL    /* 最後はNULLターミネート */
};

Log2Ceilの負荷が高い。LMSでLog2Ceilをサンプルごとに読んでいるがこれが大きな負荷になっている…(SPARKLEでは2.7秒の処理時間の内150ms使っている)。負荷を取るか、圧縮率を取るか…。

2の冪に対するlog2呼び出しは明らかに一箇所からしか呼ばれないので、Utilityにある必要はないように見える。インライン関数展開されることを期待する意味も込めて、Coder側に移動して良いかも。→やったら最早負荷リストに乗らなくなった。

2019.5.26

コマンドラインパーサを作成する。

一応仕様は見えたけど、いきなり大きく作ると混乱しそうだから、まずはショートオプション対応版をつくる。

16:57 ロングオプション対応含めだいたいできた。エラー発生時にエラー出力するかどうかが迷いどころ。もう少し整理したらmain.cに取り込んでいく。

2019.5.28

コマンドラインパーサを追加。テストも追加。mandatoryは邪魔(-oを必須にしていたが、それだと-hだけでもエラーになってしまう。また、必須の判定はユーザがやればいい。)だし、-i, -o は指定必須だからオプションじゃなくていいかな。

2019.5.29

bonkなるフォーマットはPARCORを使っているようだ。ソースも短いので見てみる。→レビンソン-ダービン法をめちゃくちゃ改善しているようだった。読み解けない…

2019.6.1

6月は32bit演算対応を模索したい。最終的にSIMD化するときに、原理上ワード長で速度に差が出ると感じている。あと適応フィルタの本を読んで、LMSにさらなる改良を加えたい。これが落ち着いたら、チャレンジ奨励に出しましょうかね。

bit幅の変動を観察していたら、まずPARCOR予測の入力がすでにbit幅が17bitになっていることが分かった。原因を見ていたらMS処理のところでsideが引き算になっていて、これによりbit幅が増加していた。(例えば、Lchが30000、Rchが-30000のとき、side = L - R = 30000 - (-30000) = 60000。60000は符号付き16bitで表現できない。)

いろいろとbit幅増加要因がありそうなので、データ加工フローを見直してみる。以下の結果は符号ビットを含めている。

  1. 入力データ:16bit
  2. MS処理のsideの引き算処理:17bit
  3. プレエンファシスフィルタの最大予測誤差を加味:18bit
  4. プリエンファシスにより大体の音声で絶対値は小さくなる、が、例外あり。
  5. PARCOR
  6. ロングターム
  7. LMS
  8. エンコード

予測フィルタに入る前までに幅が18bitになっている。 予測は最大16bit幅で行うから、18bitで入ってきた場合は、2bitの切り捨てを入れないといけない。無条件に2bitの切り捨てを行うと、誤差は増える方向にしかいかない。

おそらく必須になるのが、入力データをもれなく表現できる最小ビット幅の計測関数。やることはデータのABSの最大値を探してそのlog2ceilをとって+1する。(最後の+1は負値対応)

  1. 入力データ:16bit
  2. MS処理のsideの引き算処理:17bit
  3. プレエンファシスフィルタの最大予測誤差を加味:18bit
  4. PARCOR:積和演算を15bit幅で行い、予測時に元のデータのビット幅に合わせる:19bit?
  5. 元のデータのビット幅をXbitとしたら、X>15ならばフィルタ入力時に(X-15)ビット算術右シフトする
  6. 予測として得られた15bitデータを(X-15)ビット左シフトする。((X-15)が負ならば(15-X)算術右シフト)
  7. ロングターム:積和演算を15bit幅で行い、予測時に元のデータのビット幅に合わせる:20bit?
  8. LMS:積和演算を15bit幅で行い、予測時に元のデータのビット幅に合わせる:21bit?
  9. エンコード

別件で一点。ライス符号のパラメータが変化するところはあまりないのに、今はサンプル毎の更新処理を入れている。だから、パラメータが変化するところだけをマークして、パラメータが2倍になるのか1/2になるのかがわかれば原理的に早くなる。

2019.6.2

秋葉原製作所5hコース。今日は引き続き、積和演算の32bit化を検討する。

重要なのは積の瞬間に32bitの表現範囲を超えてしまうこと。だから積の瞬間だけ後ろ向き・前向き誤差を16bitに丸めれば良い。

問題は右シフト量をどうやってデコーダ側に渡すかという点。予測/合成関数の引数に右シフト量を追加するか?予測/合成を呼び出す側でシフト量を確定させてやれば良いのかも。

エンコーダ側で、なんとなく32bit積算ができた(無論サイズ悪化)ので、まずはテストに合格することを目標にする。テストにビット幅計測を追加する必要がある。

単体テストに追加してOKの様子。ミソは、入出力データには一切手を入れずに、乗算の精度だけを落とすということ。入出力データを右シフトすると復元できなくなる。ついでにUtilityにデータのビット幅計測関数を追加。

データのビット幅が16bitを超えていたら、PARCOR係数側を右シフトするようにした。これにより、演算時の後ろ向き・前向き誤差の右シフトが不要になった。(ここで、PARCOR係数の非線形量子化が活きてくるんだなあ…と直感。)

一旦小休止して、テストから本チャンへの移行を試みる。テストが通っているから、演算にはセーフなはずで、大事なのはエンコーダ・デコーダにビット幅を示すフィールドが追加されること。

PARCOR係数さえ正しくシフトしていれば良いことが分かったので、もはや予測ルーチンでは右シフトを行う必要が無いのでは。エンコーダ側でビット幅を計測、係数を右シフトして関数実行する形にしてみる。改めてテストが通ったら本チャン組み込み。

本チャン組み込みをした。テストは通っているし、手元の音源で元に戻るので一旦安心してしまって取り込む。なお、係数右シフト量を新規にブロックヘッダに追加している。そのため係数の精度悪化も合わせてサイズは増加している。

2019.6.3

暑さのせいか体力が持たない。LMSの32bit演算化を試みている。

  • 24bit Wavを食わせたら落ちたので原因を見ていたらサイズオーバーしていた…。また、俺の声24bitでも圧縮率が非常に悪い(ちょっと調べたらmonkey's audioも悪かった。FLAC以下の性能)。最小値ぶん右シフトするなりの対処はいるかも。
  • もしかしてと思って白色雑音を入れたら16bitでも例外発生。これは対処しないとだめだね。

2019.6.4

歯医者。力尽きて寝ていてあまり作業できず。

サイズオーバー対策は、やはり確保するメモリを増やすしかない。また、EncodeBlock内でエラーチェックを強化する。

白色雑音は、EncodeBlock内でPARCOR係数計算後、分散比を見て予測するか否かをチェックする。分散比が閾値以下になっていなかったら、圧縮不可能として、生データを書き出す。

24bit対策は、まず原因調査しないと。そもそもあまり減っていないのがきになる。

また、コマンドラインパーサで文字列デフォルト値は書き変わってしまうためやめよう。全てdescriptionで説明しよう。

2019.6.8

平日ろくに動けず。以下の作業をやっていく:

  • LMSはまず動いているか?16bitでオーバーフローなしで動くことを要確認。
  • LMSのカスケードは廃止。
  • mainの修正:文字列デフォルトを使わない。

32bitに対応すると、LMSはやはり16bit整数以上で乗算時にオーバーフローする。

  • 係数:無制限に上がる/下がってしまう
  • 入力信号:入力が16bitでない可能性がある。

PARCORでは入力のビット幅に合わせて係数を右シフトしてしまうことで問題なかったが、LMSではそうもいかない。係数はいくらでも増減する。また、右シフト量はLMSの事前に計算して、記録しておかないとだめ。係数の値を見て右シフトするのは負荷が高い。積和演算の途中で32bit範囲を超える可能性がある。

上記の困難点が見えたので、LMSの32bit化は一旦断念する。

コマンドラインパーサを整理。デフォルトを廃止。同時に、APIを呼ぶときにいちいちスペックとスペック数を渡しているのがめちゃくちゃ冗長。ハンドル化するか、スペック数をなくして仕様リストをNULLターミネートする形に持っていきたい。→OK。NULLターミネートに変えた。

LMSのカスケードを廃止する…けど温情でもう少し観察してだめなことが分かったら廃止する。

-rw-r--r--@  1 *  staff  39558053 Jun  8 20:13 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  29781967 Jun  8 20:14 SPARKLE.sla
-rw-r--r--@  1 *  staff     50878 Jun  8 20:14 kisaragi_chihaya.sla
-rw-r--r--@  1 *  staff  23078354 Jun  8 20:12 Dream_goes_On.sla
-rw-r--r--@  1 *  staff    770097 Jun  8 20:14 voice48a.sla
-rw-r--r--@  1 *  staff  40076780 Jun  8 20:17 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  30057429 Jun  8 20:16 SPARKLE.sla
-rw-r--r--@  1 *  staff     50889 Jun  8 20:15 kisaragi_chihaya.sla
-rw-r--r--@  1 *  staff  22957174 Jun  8 20:18 Dream_goes_On.sla
-rw-r--r--@  1 *  staff    770666 Jun  8 20:16 voice48a.sla
-rw-r--r--@  1 *  staff  39573905 Jun  8 20:21 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  29785000 Jun  8 20:20 SPARKLE.sla
-rw-r--r--@  1 *  staff     50780 Jun  8 20:22 kisaragi_chihaya.sla
-rw-r--r--@  1 *  staff  22879755 Jun  8 20:22 Dream_goes_On.sla
-rw-r--r--@  1 *  staff    768107 Jun  8 20:22 voice48a.sla
-rw-r--r--@  1 *  staff  39174228 Jun  8 20:09 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  29607357 Jun  8 20:08 SPARKLE.sla
-rw-r--r--@  1 *  staff     50827 Jun  8 20:07 kisaragi_chihaya.sla
-rw-r--r--@  1 *  staff  22656860 Jun  8 20:10 Dream_goes_On.sla
-rw-r--r--@  1 *  staff    768789 Jun  8 20:10 voice48a.sla
-rw-r--r--@  1 *  staff  40024904 Jun  8 20:26 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  30040884 Jun  8 20:25 SPARKLE.sla
-rw-r--r--@  1 *  staff     51036 Jun  8 20:27 kisaragi_chihaya.sla
-rw-r--r--@  1 *  staff  34086796 Jun  3 00:42 DiamondSmile.sla
-rw-r--r--@  1 *  staff    772863 Jun  8 20:27 voice48a.sla
-rw-r--r--@  1 *  staff  39280231 Jun  8 20:30 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  29776691 Jun  8 20:31 SPARKLE.sla
-rw-r--r--@  1 *  staff     51114 Jun  8 20:32 kisaragi_chihaya.sla
-rw-r--r--@  1 *  staff  22631773 Jun  8 20:31 Dream_goes_On.sla
-rw-r--r--@  1 *  staff    773745 Jun  8 20:32 voice48a.sla
-rw-r--r--@  1 *  staff  39356907 Jun  8 20:35 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  29691217 Jun  8 20:34 SPARKLE.sla
-rw-r--r--@  1 *  staff     50837 Jun  8 20:33 kisaragi_chihaya.sla
-rw-r--r--@  1 *  staff  22479866 Jun  8 20:36 Dream_goes_On.sla
-rw-r--r--@  1 *  staff    768416 Jun  8 20:33 voice48a.sla
-rw-r--r--@  1 *  staff  39280231 Jun  8 20:41 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  29776691 Jun  8 20:42 SPARKLE.sla
-rw-r--r--@  1 *  staff     51114 Jun  8 20:43 kisaragi_chihaya.sla
-rw-r--r--@  1 *  staff  22631773 Jun  8 20:38 Dream_goes_On.sla
-rw-r--r--@  1 *  staff    773745 Jun  8 20:42 voice48a.sla

ん?次数10/カスケード2が良い?ごめんやっぱ廃止できない。プリセットを修正。

2019.6.9

日曜日のTODOは、

  • 白色雑音対策
  • 分散比を観察(実際に白色雑音で高くなっているか?)
  • 圧縮しないモードを追加
  • 24bit対策
  • 最小値の算出機能追加
  • 一般の24bitデータ対策

もしかしたら24bit対応で絶望して結局PARCORも64bitになるかもしれない。

14:00に秋葉原製作所in。まずは白色雑音対策を打つ。6.8の夜の観察により、白色雑音では推定圧縮率((1サンプルあたり推定符号長)/(元データのサンプルあたりビット数))が0.98位になることを確認:

0.980077
0.980992
0.980059
0.980983

他のデータでは0.90を超えることは稀であることを確認している。

f:id:aikiriao:20190929123826p:plain

雑に見積もって0.95以上ならば圧縮不可能と判定していいと考える。

→対策を行った。推定圧縮率が閾値以上ならば生データを書き出すように修正。これに伴ってブロックデータタイプを新しく導入。今の所、圧縮済みデータか、無音か、生データの3種類が存在する。

さて、いよいよ24bit対策に入る。

24bitデータを食わせると、以下のアサートを吐いて死んでしまう(少し気になって8bitも試したけど大丈夫だった。FLACよりよい結果が出ている。):

Assertion failed: (init_param < (1UL << 16)), function SLACoder_PutDataArray, file SLACoder.c, line 462.

→これは初期パラメータのサイズ不足。24bitデータならば24bitレンジで初期値が出る。元データのビット幅を引数として渡し、そのビット数で符号化するように修正すれば良さそう。ひとまず24bit符号化して回避。

Assertion failed: (encoder->parcor_rshift[ch] < (1UL << 3)), function SLAEncoder_EncodeBlock, file SLAEncoder.c, line 610.

→ビット幅が24のときに、右シフト量が24-16=8になる。8は3ビットで保存できない。と思ったらビット幅が25とか出てきた。これは明らかなバグ。ワン・ツー・スイーツでも17が出ている。→バグじゃなかった。プリエンファシスで16bit幅を超えてる!

16bitwavを左シフトして作ったダイヤモンドスマイルの結果がかなり悪い。右シフト量が大きくて、PARCOR係数の精度がひどいことになっている。データ側のシフトに切り替えてみたが、状況はあまり変わらず悪化。(係数を右シフトするよりは圧縮率はよかった。ただし実装が複雑化。関数引数に変化あり。速度は自明に低下。つらい。)

FLAC, wavpackはおそらく最小値を見ていて、その分右シフト処理をしている。Monkey's Audio, ttaはそのまま圧縮しにいって減らせている(謎)。

64bit演算にしてみて様子を見る。。。様子は変わらず。

バグだった!ライス符号パラメータがオーバーフローしていた!8bitの固定小数を使っていて、かつ119を掛ける時があって、24bitdデータを突っ込むと、確かに32bitだとオーバーフローする!直したら(パラメータを64bitにしたら)一気に減るようになった。

しかしまだ最小値の対処が抜けている。これを対処することでFLAC, wavpackを倒せる予定。

また、24bitエンコード時は高次係数も16bitを振った方が良さそうな印象。(また、右シフト量に応じた係数記録をすべき)

2019.6.11

最小値の対処を入れる。→やった。まだテスト実装だから、ビット幅計算関数を別途作成すべき。

ダイヤモンドスマイルの圧縮率、wavpackにおいて負けとる。

いろんな短い波形のエンコードデコードテストがやりたい…

2019.6.12

最小値対処を入れる。設計にはだいぶ迷った。

  • 各ブロックで解析を行って、ブロックヘッダに書いておくのを考えていたが、それは明らかにもったいない気がした。
  • なぜなら左シフトされて入っているデータはレアケースだと思うから。
  • なのでヘッダに入れることにした。最初に全体を解析して、左シフト量を計測しておく。また、概念的に近いと考えてWaveFormatに左シフト量のメンバを追加。
  • EncodeWhole時にしかヘッダに情報を入れない。
  • EncodeBlockを個別に呼び出したときは効果なし。
  • ユーザは左シフト量メンバをいじれない。

TODO:

  • 24bitエンコード時は高次係数も16bitを振る。
  • 右シフト量に応じた係数記録をする
  • 係数量子化、最初にpow(2, 16)すべきでは?精度が落ちてる。この機会に整理。

  • いろんなwavのエンコードデコードテストを追加

  • とにかく一致確認を行う。ユニットテストとは分ける。
  • 無音、サイン波、雑音、定数、ナイキスト振幅などなど…
  • 8, 16, 24bit, 8bit<<16, 16bit<<8

2019.6.13

何もできず。FLACのexe(実行可能形式)はGPLだけど、リンクしない限りは公開義務は発生しない。つまり、使うだけならOK。

2019.6.14

Adaptive filter theoryをパラパラ見ているけどSign Sign LMSの記述がどこにもない。やはりwebを見る。

あまりいい情報はない。

高速化で気になっていたのは、係数更新時のバッファアクセス。毎回andは取りたくない…直線アクセスできんのかと思っていたら、あった

2019.6.15

ついでに久々に海ベローチェに来た。今日はここで作業して大井町寄って帰る。

ビックサイト行く途中で、IIRも適応的にできたことをAdaptive filter theoryの本に思い出させてもらった。そういえば適応ノッチフィルタの応用例があった。

適応IIRが先か、フィルタ処理高速化が先か…。圧縮率改善を先に頑張ったほうが良さそうだから、適応IIRを試してみよう。

やっつけで実装してみた(更新式はsign-sign)けど、なかなか性能が良い。(バグあるかも)

-rw-r--r--@  1 *  staff  39558053 Jun  8 20:13 one_two_sweets_offvocal.sla
-rw-r--r--@  1 *  staff  29781967 Jun  8 20:14 SPARKLE.sla
-rw-r--r--@  1 *  staff     50878 Jun  8 20:14 kisaragi_chihaya.sla
-rw-r--r--@  1 *  staff  23078354 Jun  8 20:12 Dream_goes_On.sla
-rw-r--r--@  1 *  staff    770097 Jun  8 20:14 voice48a.sla
-rw-r--r--@   1 *  staff   39417404 Jun 15 17:12 one_two_sweets_offvocal.sla
-rw-r--r--@   1 *  staff   29704724 Jun 15 17:13 SPARKLE.sla
-rw-r--r--@   1 *  staff      50819 Jun 15 17:13 kisaragi_chihaya.sla
-rw-r--r--@   1 *  staff   22925409 Jun 15 17:13 Dream_goes_On.sla
-rw-r--r--@   1 *  staff     769208 Jun 15 17:14 voice48a.sla
-rw-r--r--@   1 *  staff   39339579 Jun 15 17:29 one_two_sweets_offvocal.sla
-rw-r--r--@   1 *  staff   29652750 Jun 15 17:28 SPARKLE.sla
-rw-r--r--@   1 *  staff      50818 Jun 15 17:30 kisaragi_chihaya.sla
-rw-r--r--@   1 *  staff   22852870 Jun 15 17:29 Dream_goes_On.sl
-rw-r--r--@   1 *  staff     769343 Jun 15 17:30 voice48a.sla

予測出力を入力するか、残差を入力とするかで実装が少し変わる。理論的なところでは、予測出力をIIRの入力とするものは出力誤差法(Output Error Method)と呼ばれるらしく(不安定、かつ局所最適に陥るそうだ。)、また、残差をIIRフィルタの入力とするものは該当する手法がない。何をしてるんだろう。。。

不安定さはステップサイズを小さくすることで防ぐしかないらしい(本によると)。

局所最適は等誤差法(Equation Error Method)で防げる。これは、希望出力をIIRの入力とするもの。この場合希望出力は無音になるな…

係数を64bitにしたら、残差IIR入力時に発散している(32bit整数を超える)ことがわかった。見たところ、定数予測のところで残差がいきなり発散していた。不安定なモードに入ったらしい…。発散するのは一般的によろしくないので、残差入力は取りやめる。

IIR対応により負荷が増えた。次数分のIIR計算を行うから2倍と言ってもいい。同等の計算負荷の次数を5にしてもFIR10より結果が悪い。昨日見たバッファアクセス高速化でどれだけ良くなるか…。後、log2演算の負荷がたかい。

ちょっと思ったこと:エンコードパラメータの再度精査。

2019.6.16

昨日バッファアクセス最適化を実装したけどバグがあるので、まずそれを直す。その後にエンコードデコードテストを行う。

6/8の結果に戻らずに苦戦していたが、6/8から6/16の間にフォーマット変更が入っているからもとに戻すのはだいぶ厳しそうなのでやめた。負荷の増減を見る。

OKで、インデックス参照は確かに早くなったが誤差レベル。 LMSの負荷が高すぎる…SPARKLE.wavのデコードで3秒のうち1秒がLMS...

LMSの高速化がどう考えてもキモだ。log2を諦めるか?

16:16 2時間半経った。高速化は一旦置いてテスト作成に入る。

19:13 ぐえー疲れた。テストはなんとか作った。しかし、左シフト量のオフセット計測の実装が怪しい感じ。

2019.6.17

テストを作り上げていく上でバグが2つ潰せた。

  1. 左シフト量の計算ミス
  2. 負の最大値(8bitでの-128)を符号なし化すると256になって8bitで符号化できない

2019.6.19

さらにバグつぶし。もっとテストケース増やそう。

  1. ステレオ白色雑音のデコードに失敗する
  2. MS処理が働き、Mはガウス分布に近づくので圧縮、SはL-Rによりビット幅が増えて圧縮できず生データが入っていた。
  3. 生データを係数領域に出力してしまい、デコード時にMチャンネルが残差と思ってデコードしてしまった。

2019.6.20

バグつぶし。チャープ信号追加で以下のバグがわかった。

  1. PARCOR係数がroundの結果正の最大値+1(=-1)になる場合がある。
  2. クリップにより対処
  3. 推定符号長が負になる
  4. パワーが極端に小さいときに起こる。1bit/1sampleで符号化できるとした。

2019.6.21

修正をまとめた。また、SLAUtility.cに機種依存文字が入っていたので消した。

2019.6.22

技術書典むけプロット:

あらすじver.0.1.1

0. まえがき
ロスレス音声コーデックを作ってみませんか。
ロスレス音声コーデックと言えば、FLACがまず思い浮かべられると思いますが、実はFLACは
他のロスレス音声コーデックに比べて圧縮率が悪いという欠点があります。(展開速度は速いですが!)
本稿では "FLACを超える圧縮率を持つロスレス音声コーデック" の作成を目標として、
その基礎理論と実装を説明していきます。

0-1. そもそもロスレス音声コーデックとは?

1. 基礎理論編
ロスレス音声コーデックは大体以下の構成を持ちます。

+----------+       +---------+       +----------------------+       +----------------+
|          |       |         |       |                      |       |                |
|①入力wav +---+-->+ ②予測  +---+-->+ ③エントロピー符号化 +---+-->+ ④出力バイナリ |
|          |   |   |         |   |   |                      |   |   |                |
+----------+   |   +---------+   |   +----------------------+   |   +----------------+
               |                 |                              |
               |                 |                              |
               +                 +                              +
            pcmデータ         残差信号                       ビット列

①入力のwavを取得する。
 音声信号データはPCMで符号化されている
②入力の音声データパターンを解析して、音声の予測を行う。
 予測信号と元の信号の差を残差という。予測が正確ならば、残差は小さくなり、
 ③のエントロピー符号化でより小さく圧縮することができる。
③残差信号をビット列に符号化(エンコード)する。
 "エントロピー符号化"は、入力データの"確率分布"に基づいて、出力ビット列が
 短くなるように符号化を行います。
④出力バイナリデータが得られます。

復号(デコード)時は④→③→②→①の手順で処理を行い、元の入力wavを得ます。

②、③の性能が個別に高ければ高いほど、より良い圧縮率を達成することができます。
本章では、②、③の基礎理論である予測とエントロピー符号化を紹介していきます。

1-1. 予測
  1-1-1 予測とはどういうことか
  1-1-2 線形予測の理論と実装
    (1サンプル間の予測から線形予測まで。頻度分布を見せる。)

1-2. エントロピー符号化
  1-2-1 符号化とはどういうことか
  1-2-2 情報量とエントロピー
    (エントロピー計測プログラムを載せる)
  1-2-3 エントロピー符号化の例
       - α、γ、σ符号とその確率分布
       - Golomb-Rice符号

2. 実装編 -FLACを超える圧縮率を持つコーデックを作ってみる-
2-1. 固定小数演算PARCOR予測フィルタ
2-2. 残差符号化
  2-2-1 残差の確率分布分析
  2-2-2 ビットライタ、ビットリーダの実装
  2-2-3 負値の扱い
  2-2-4 ライス符号化パラメータの調整
2-3. wavファイルの読み込み

Appendix. 失敗編
A-1. 他の予測手法
 A-1-1. Burg(共分散)法
 A-1-2. 1乗算型PARCOR格子フィルタ
A-2. 他のエントロピー符号
 A-2-1. ランレングス符号化
 A-2-2. ハフマン、適応的ハフマン
 A-2-3. LZ系
A-3. その他
 A-3-1. PARCOR係数の非線形量子化

texの環境を整えてガリガリ書いていく。

ボイスデータをevaluateしていたらエンコードエラーがじゃんじゃん出てくる。その対策中。LPC係数計算中にfabs(gamma) >= 1.0fになるケースがある...確認したケースではサンプル数が少ない&パワーが小さいのが原因。

  1. wavのfmtチャンクが拡張されている(サイズが16より大きい)ときにエラーを出していたが、スキップするようにした。(おそらく有効なデータは入っていない)

  2. 入力サンプルがPARCOR係数次数よりも少ないときは無音として扱うようにした。

  3. 入力サンプルが次数よりも大きく、自己相関が小さい場合は未対応。まだエンコードに失敗しうる。

上記2点の修正を入れたところ、使用している評価データに対してはエンコードできるようになった。

TTAは読み込めないwavがある(おそらくfmtの拡張に対応していない)し、Monkey's Audioはクラッシュするwavがある…。

今夜、FLAC vs WavPack vs SLA 予定。

手元の音源4091曲で圧縮率を比較:

手法 圧縮率(圧縮後/圧縮前 * 100)[%] CPU負荷 [%]
FLAC -8 53.40 0.720
WavPack -hh 48.00 0.976
sla 45.86 1.24

2019.6.23

久々に何も進めない休日。直近のTODOがない。執筆に励むべきかも。

2019.6.25

2019.6.27

uint32_t SLAUtility_Log2CeilFor2PoweredValue(uint32_t val);が定義されていない。宣言だけあるので宣言を消す。→消した。

wineを使って、TAKとMP4ALSを評価に追加した。圧縮率はTAKが一番。しかし人間の声ではSLAが何故か一番良かった。無音区間をうまく捉えられている?また、MP4ALSと比べたところ、僅かにSLAが上回っている。

小粒な修正。

  • VSでビルドが通るように修正。(。*/エンコードでアウトだった。半角空けて。 */として対処。)
  • バージョン文字列を文字列に変更。(フォーマットバージョンは整数。)
  • シグネチャSL*からSL*\0に変更。(テキストファイルとして開いた時の事故を防ぐ目的)

プリセットを変更した。負荷として、LMSよりPARCORは負荷増加しにくいので、PARCORにより多くを割り振るように変更。

2019.6.29

アプリに組み込んだときに、負荷変動がやばい。SLADecoder_DecodeBlockはブロックサイズ単位でデコードするが、それが例えば16384サンプル単位だと、16384サンプル周期でスパイクが発生する。これでは実用に耐えないので、より小さなブロックサイズ、例えば512サンプル単位でデコードできるようにしたい。

対応策を考えている。今有力なのは、SLADecoder_DecodeSubBlockという関数を新規に追加すること。SLADecoder_DecodeSubBlockの仕様は次の通り:

  • ブロック先頭のときは、パラメータを読み取って指定サンプル分デコード。
  • ブロック途中のときは、継続して指定サンプル分デコード。その際に次のブロックに入ったら、改めてパラメータを読み取って指定サンプル分に達するまでデコード。
  • 今読み取っているブロックのサンプル数をカウントすればやれそう。

負荷が変動するのは、ヘッダのパラメータの読み取り分(微小)と無音/生データデコード時(それなり)

おそらくこの関数はシークを実現するときも必要になるはず。SLADecoder_DecodeSubBlockの名前はあんまり良くなさそう。任意位置から任意サンプル分だけデコードできるので、もっと別の名前が良い。

同時に、ブロック途中で再度デコードを行っても問題なくデコードできるように下地を作る。

  1. ライス符号の初期パラメータをブロックヘッダに持たせる
  2. 再帰的ライス符号のパラメータをコーディングモジュールの外から渡すように変える。
  3. パラメータの初期化をPutDataArray, GetDataArrayで行わない。
  4. →やった。ここで気付いたけど、コーディングモジュールをハンドル化したほうがよい。
  5. 予測モジュールのリセット関数を用意する。
  6. 各予測モジュールと、エンコーダ・デコーダに追加
  7. 予測/合成時に、リセットを行わないようにする
  8. ブロックヘッダ先頭だけでリセットを行う
  9. →試そうとしてきつい。予測/合成が始まるデータのインデックスに初回と2回目以降で差異がある。リセット関数でフラグを立てるか。
  10. プリエンファシス・デエンファシスも状態を持たねばなるまい。モジュール化するし、Predictorに移動する。
  11. 合成予測ハンドルをチャンネル数分だけ持つように変える。
  12. LMSカスケードを廃止。ハンドルが増えるし、何より圧縮に寄与しないから。
  13. →やった。

2019.6.30

湿度のせいか、集中力が保たない。しかし大事なところなので頑張る。

  1. ブロックヘッダのエンコード・デコードを行う内部関数を新規追加
  2. エンコード側は難しいことがわかったのでデコード側のみ実装。(ブロックサイズ, CRC16がブロックエンコードが終わらない限り確定しないため)
  3. 先輩社員提案仕様を形にし始める

2.に取り掛かっているが、残差デコードで一点問題が。残差はチャンネルインターリーブでエンコード/デコードしないとブロックの途中でデコードを中断できない。→やった。

予測ハンドルリセット時、フラグでなく入力サンプル数カウントを0にした方が素直かも。

2019.7.1

実装整理。とにかく、ストリーミングデコードが完成しない限りはだめだ。

2019.7.2

『ディジタル音声処理(古井貞)』に1乗算型の構成が書いてあった。。。。再度試してみたけど一致せず。うーん。諦めか?

戻ってストリーミングデコードへ向けて頑張る。

2019.7.3

データ追加・回収系のテストを追加。同時にLMSに関する良いリンクを見つける。

Sign-Signはやりすぎ…?入力信号のsignを取って、残差との乗算で更新してみる。→劇的にだめだった。とりやめ。

あと、ループアンローリング時は、和の変数も分けた方が良さそう。和の依存関係がなくなるからよい。

int sum1, sum2, sum3, sum4;

for (int i = 0; i < nsmpl/4; i++) {
 sum1 += i;
 sum2 += i;
 sum3 += i;
 sum4 += i;
}

int ans = sum1 + sum2 + sum3 + sum4;

シフト演算も劇的に速いわけではない。注意。Log2Ceilも割と重いと思う。

2019.7.6

ストリーミングデコードのテスト追加して細々としたバグつぶし中。

2019.7.7

まだバグあり。波形依存でもとに戻らない。2時間がかかったが、ロングタームが悪さしていることがわかった。更に追いかける。

  • ロングタームとLMSが最初のバッファリング中のところでデコードが途切れるとバッファが不正になっていた

  • 必要バイトの最小値を最小ブロックヘッダ値に設定

だいたいバグは潰したけど、まだ構造的に未完成。データの受け渡しキューを綺麗にしたい。

2019.7.9

やはりデータコピー(memmove)負荷が大きい。データパケットキュー構造を作っている。

2019.7.10

技術書典参加確定。 パケットキューを作った。SLAUtilityに追加。それに合わせてAPIを見直し。

2019.7.11

パケットキュー差し替え時のバグとり。とりあえず動いているようだが、ダブルバッファリングに変えたい。

  • シグネチャSLA*\0からSLA*\1に変える。\1はSOH(Start of Header)。\0だとSL*の繋がるイメージに反するから。→やった。

2019.7.13

とどめの3連休としよう。

  • 最悪ビットレート値をヘッダに記録する→やった。
  • Par (タイポ)→ Per→やった。
  • 連続バッファをダブルバッファリングに変える
  • 実は難しいことがわかっている。ブロックデコード終了直後にデータ追加が入ると、ブロックサイズが前のブロックのママになってしまう。
  • 制御が複雑になるので一旦ペンディングとする。

2019.7.14

13:30起床。体が動かん。TODOなるべく早めにこなして、原稿執筆にはいる。

TODO:

  • ストリーミングデコーダ作成直後にブロックサイズが不定になっている。
  • フォーマット設定したかどうかのフラグをもたせる。
  • フォーマット設定する前はサイズを最悪値で見積もっておく。
  • →やった。が、デコード開始直後は最大ブロックサイズ分突っ込んでおかないと失敗するケースあり。データ不足が発生していると想像。
  • 異様に圧縮率がよい高崎データが元に戻っているのか精査
  • →わかった。wavファイルの末尾にbextチャンクが入っていた。そのチャンク情報をslaは捨てていたため、小さくなっていた。他のコーデックは律儀に保存していた。
  • Broadcast Wave Format
  • 捨てた分のチャンクサイズを足すと、やはりTakを下回る。
  • TTAの原理
  • 残差でsignを取るのは負荷が高いから試していない。
  • →うーん。微妙。減ったり増えたり。安定しないの取り下げ。TTAで気になるのはステップサイズを可変にしている記述があった。論文はロシア語で読めないのでソースを見てみる。
  • 全体的なコードリファクタ、テスト追加

これはTODOではなくちら見でOK

永遠に上っ面の知識の吸収を続けるのか、それとも研究をしっかりやって将来的な発展に結びつけたいのか。かけた時間が時間なので、引くに引けない状況になってしまった。

TTAのソース(フィルタ処理)を読んでいる。

static __inline void hybrid_filter_enc(TTA_fltst *fs, TTAint32 *in) {
    register TTAint32 *pA = fs->dl;      /* pA: 入力バッファ */
    register TTAint32 *pB = fs->qm;      /* pB: 乗算係数     */
    register TTAint32 *pM = fs->dx;      /* pM: 係数更新量   */
    register TTAint32 sum = fs->round;   /* 丸め定数で初期化 */

    /* 係数更新: 残差fs->errorの符号で変える */
    if (fs->error < 0) {
        pB[0] -= pM[0]; pB[1] -= pM[1]; pB[2] -= pM[2]; pB[3] -= pM[3];
        pB[4] -= pM[4]; pB[5] -= pM[5]; pB[6] -= pM[6]; pB[7] -= pM[7];
    } else if (fs->error > 0) {
        pB[0] += pM[0]; pB[1] += pM[1]; pB[2] += pM[2]; pB[3] += pM[3];
        pB[4] += pM[4]; pB[5] += pM[5]; pB[6] += pM[6]; pB[7] += pM[7];
    }

    /* フィルタ出力計算 */
    sum +=  pA[0] * pB[0] + pA[1] * pB[1] + pA[2] * pB[2] + pA[3] * pB[3] +
        pA[4] * pB[4] + pA[5] * pB[5] + pA[6] * pB[6] + pA[7] * pB[7];

    /* 入力バッファ[0..3]の更新 0が最も古いデータとなる */
    pM[0] = pM[1]; pM[1] = pM[2]; pM[2] = pM[3]; pM[3] = pM[4];
    pA[0] = pA[1]; pA[1] = pA[2]; pA[2] = pA[3]; pA[3] = pA[4];

    /* 新しめの係数更新量[4..7]の更新 */
    pM[4] = ((pA[4] >> 30) | 1);      /* sign(pA[4])(0のときは1)     */
    pM[5] = ((pA[5] >> 30) | 2) & ~1; /* 2 * sign(pA[5])(0のときは2) */
    pM[6] = ((pA[6] >> 30) | 2) & ~1;   /* 2 * sign(pA[6])(0のときは2) */
    pM[7] = ((pA[7] >> 30) | 4) & ~3; /* 4 * sign(pA[7])(0のときは4) */

    /* 元のソース
    pA[4] = -pA[5]; pA[5] = -pA[6];
    pA[6] = *in - pA[7]; pA[7] = *in;
    pA[5] += pA[6]; pA[4] += pA[5];
    */
    pA[4] = -pA[5];         /* pA[4] = -直前の3階の差分 */
    pA[5] = -pA[6];         /* pA[5] = -直前の2階の差分 */
    pA[6] = *in - pA[7];    /* pA[6] = 入力 - 直前の入力(1階の差分) */
    pA[7] = *in;            /* pA[7] = 入力データ */
    pA[5] += pA[6];         /* pA[5] = 1階の差分 - 直前の2階の差分(2階の差分) */
    pA[4] += pA[5];         /* pA[4] = 2階の差分 - 直前の3階の差分(3階の差分) */

    /* 入力をインプレースで残差に差し替える */
    *in -= (sum >> fs->shift);
    fs->error = *in;
} // hybrid_filter_enc

いろんな工夫が見られる。

  • 入力信号バッファの先頭4つには差分値が入っている
  • pA[7]: 生の入力信号
  • pA[6]: 1階の差分(現在の入力 - 直前の入力)
  • pA[5]: 2階の差分(1階の差分 - 直前の1階の差分)
  • pA[4]: 3階の差分(2階の差分 - 直前の2階の差分)
  • pA[3]: 直前のpA[4]
  • pA[2]: 直前のpA[3]
  • pA[1]: 直前のpA[2]
  • pA[0]: 直前のpA[1]

  • 各係数の更新量pMは次のように決まる。(ただし、signは符号関数。sign(0) = 1):

  • pM[7]: 4 * sign(pA[7]) = ((pA[7] >> 30) | 4) & ~3
  • pM[6]: 2 * sign(pA[6]) = ((pA[6] >> 30) | 2) & ~1
  • pM[5]: 2 * sign(pA[5]) = ((pA[5] >> 30) | 2) & ~1
  • pM[4]: sign(pA[4]) = ((pA[4] >> 30) | 1)
  • pM[3]: 直前のpM[4]
  • pM[2]: 直前のpM[3]
  • pM[1]: 直前のpM[2]
  • pM[0]: 直前のpM[1]

今更ながら示唆がある。

  • フィルタ係数と言うよりは、微係数を適応的に変化させている
  • 予測も微係数を用いて行う。これは…何らかの補間手法では?
  • 入力は過去に行くほど影響度が小さくなっている
  • 係数更新量も過去に行くほど小さくなっている
  • 更新量は小さいように見えるが、TTAは1秒分のデータをブロックエンコードするので、十分に収束するものと想像
  • 係数更新が一番最初にきている

ここまで読めたのだから、取り込んでみた。が、性能が悪い。シフト量が鬼門で、どの値に設定すれば良いのかさっぱり。長尺データはそれなりの結果を出している(既存よりは低い)。係数更新が一番最初に行われるのもだいぶミソだ。予測後に更新したら性能が落ちた。

取り下げるけど、示唆が3点。

  1. 係数更新のタイミングを予測前にする
  2. やったら爆裂に悪化。定義からはずれたと思う。やめ。
  3. 古いバッファデータの更新量を小さくする
  4. 係数シフトを乗算右シフトに含める
  5. これを参考にして、LMSの乗算時右シフトを10bitにしたら32bit整数で計算が完結した。
  6. 圧縮率を犠牲に、32bit演算化の道が開けた感がある。
  7. しかし、24bit WAVを使用したとき、加算対象の変数を64bitにしたときと32bitnにしたときで差が出る…原因を追う。

2019.7.15

秋葉原製作所8時間取った。ほぼ最後の追い込み。最後の課題はLMSの32bit化。

変更前(64bit演算、重みシフト10bit)の結果をメモしておく:

音源 圧縮後サイズ
A112b.wav 156819
ワン・ツー・スゥイーツ 39496924
SPARKLE 29499550
俺の声 50884
  • 乗算時にオーバーフローは発生していない(テスト確認済み)

32bitだとどうにも性能が悪い問題があった。これは、固定小数の精度が悪いのが原因(オーバーフロー以外で悪化する原因はこれしか考えられない)。64bit時は30bitも割り当てているから当然。

係数の更新量テーブルを見直して、更新量を一律1bit右シフトしたら性能がそれなりに良化した。乗算時にオーバーフローしていないかチェックして、問題なければ...と思ったら、24bit音源で2%程の大幅悪化が見られた。

どうするか…24bit対策するか…

ひとまず今の更新量テーブル見直しの結果は以下:

音源 圧縮後サイズ
A112b.wav 156667
ワン・ツー・スゥイーツ 39441828
SPARKLE 29468749
俺の声 50985

アイカツ音源で0.3%の悪化。うーん。手元のデータに都合が良すぎるのか?

設計上のジャッジを下さねばなるまい。...やはり、圧縮率は落ちるが、速度向上、より広い移植性を目指して32bitでやるべきでは?→やった。

splintを全体的に行ってコード整理を行う。

このタイミングでMP4ALSのソースを見つけてしまった…。一応追加。しかし、Hydrogen Audioでの扱いを信じることにする。

帰った後でソースを見直していたらロングタームの予測変数が32bitになっていてオーバーフローで圧縮率を悪化させていた…。64bitに直したら、圧縮率を犠牲にしないで32bit化することができた。

*1:val - m) % m') m + m' <= val 001 (((val - (m + m'

*2:loge2)E(|e|

x86(i386)向けのOS作成日記 - メッセージ1

2018.1.13

年明けは仙台とTDC(Tokyo Dome City)でアイカツライブ。特筆すべきは仙台の紳士淑女では紳士の中で最前だったこと、そして満足度が高かったこと。So Beautiful Storyは泣かせに来ていた。仙台は牛タン、そして寿司が美味かった。TDCではソレイユの3人が出てきて、Good Morning My Dream→Trap of Love→ショコラショー・タイムfull→カレンダーガール(!!)。これを見たら泣かざる(カレンダーガールは無理だし、やらないと思っていた)を得ないし、アイカツが終わったことを実感せざるを得なかった。あとは荒野の軌跡で歌詞飛びがあったのがポイントだろうか。アイカツのライブでは明らかな失敗は初めて経験した。

最初の作業は多摩近くで。まずやるのはメッセージキューの設計/実装。

メッセージモジュールの設計

構造体

まず、メッセージの構造体Messageは次のようにする:

#define MAX_MESSAGE_STRING_LENGTH 128 /* 適宜 */

/* メッセージ構造体 */
struct Message {
    uint32_t type; /* メッセージを識別する番号 */
    /* メッセージ本体           */
    union {
        uint32_t   uint32;
        char       string[MAX_MESSAGE_STRING_LENGTH];
    } u;
};

typeでメッセージを識別する番号を入れ、共用体uでメッセージ内容を入れる。メッセージの領域管理を簡単にするため、メッセージ本体にはポインタを使用していない。 Linuxとかだと構造体を置き換えることで多様なメッセージを使用可能にしているみたいだが、そうしない(構造体のメンバ並びかえが怖いため)。 また、この構造体はヘッダに公開する。

これらのメッセージをまとめるメッセージ・キューの構造体は次:

#define MAX_NUM_MESSAGES_PAR_CUE    128    /* 適宜 */
#define NUM_MESSAGE_CUES           16 /* 適宜 */

/* メッセージのリスト(今は線形リスト。後に拡張するかも) */
struct MessageList {
    struct Message     message;    /* メッセージ */
    struct MassageList*    next;       /* リストの次の要素 */
};

/* メッセージキュー */
struct MessageCue {
    uint32_t           cue_id;         /* メッセージキューのID  */
    struct MessageList*    msg_list;       /* メッセージリストの先頭 */
    uint32_t           size;           /* リストのサイズ */
    uint32_t           free;           /* 空きサイズ */
    uint32_t           flags;          /* 内部状態フラグ */
    struct MessageList meg_pool[MAX_NUM_MESSAGES_PAR_CUE]; /* メッセージリストの領域 */
};

/* システム(OS)向けにはキューリストは固定長の配列で持つ */
static struct MessageCue st_system_message_cue[NUM_MESSAGE_CUES];

メッセージのリストMessageListは配列ではなく線形リストとする。メッセージリストの途中から変更する可能性があるため、メッセージは普通のキュー(FIFO)にはならないからである。

メッセージキューにはIDを設けておく。(優先すべきメッセージとそうでないものを区別するため)

API

ユースケースを考え、一般的な使用順序でいくと...

キューの新規作成
int32_t MessageCue_Create(uint32_t cue_id, uint32_t cue_size);

キューIDとメッセージリストのサイズを指定してキューを新規作成する。キューIDの重複があったり、キューサイズが大きければ失敗。

メッセージの送受信
int32_t Message_SendMsg(uint32_t cue_id, struct Message* message);
int32_t Message_ReceiveMsg(uint32_t cue_id, uint32_t msg_type, struct Message* message);
int32_t Message_ReceiveMsgNonBlock(uint32_t cue_id, uint32_t msg_type, struct Message* message);

指定したキューIDのキューに対してメッセージを送受信する。 メッセージはメッセージの種類とその先頭ポインタ、そしてメッセージ構造体自体のサイズを渡す。 受信側ではmsg_typeの送信を待ち、キューから一番古いmsg_typeを持つメッセージを取り出す。 Message_ReceiveMsgはブロックして指定したタイプのメッセージの到着を待つ。Message_ReceiveMsgNonBlockは現在のキューに指定したタイプのメッセージがなければ即時に終了してエラーを返す。

2018.2.17

多摩近くで再開。いろんなことが起こりすぎて作業着手できなかった。

今一番心にあるのはアイカツ歌唱担当の卒業。これにより、少なくとも初代アイカツが非可逆的に失われることになる。アイカツについては別の記事にまとめておく。

仕事面でも案件を回しきれない日々が続いた。家に帰ってもピアノと絵に手が付かない毎日。理論勉強もあまり進まない。というか、色々なことに手を出しすぎだ。タスク一覧を挙げてみる:

  • 仕事:継続するか?やりたいこと出来ているか怪しい。耐えてるだけでは。
  • ピアノ:週2でやれれば良い方。。。上達が薄い気がするし、作曲に移れない
  • 絵:一ヶ月やれてない。模写だけでも良いからやりたい。
  • OS自作:この日記を書くまで止まってた。
  • その他の趣味プログラミング:圧縮(アーカイバLZMAプロトタイピング)やりたいけどできてない。
  • アイカツ:稼働終了に伴い平日プレイ回数増加中
  • 理論:群論(見える群論)、超関数(これなら分かる工学部の数学)について見ているだけ…まとめたい

メッセージを思い出しながらコーディングしてみる。 外部仕様自体は2018.1.13で決めてあったので、気軽にコーディングした。

2018.2.18

武道館公演まで時間がない。

アイカツのCOMPLETE CD-BOXを取り込みながらメッセージモジュールのテストを書く。

書いていて思ったがノンブロッキングな受信関数は関数で分けるべきでは無いのでは?受信と行っても様々なモード(例:キューから取り除かない、見るだけとか存在確認だけ等)があるので、モード引数をつけるべきでは。

また失敗時のエラー原因をマクロ定数化すべきと思う。

実装を再検討し、完成次第ここに書こう。

2018.2.21

アイカツを見ながらテストケースを追加し、仕様を固めた。(精神が限界。アイカツが本当に終わろうとしている。)

メッセージ

メッセージ構造体は公開する。ユーザはこの構造体にメッセージを詰め、APIの引数に渡す。

/* メッセージ構造体 */
struct Message {
    uint32_t type; /* メッセージを識別する番号 */
    /* メッセージ本体 */
    union {
        uint32_t   uint32;
        char       string[MAX_MESSAGE_STRING_LENGTH];
    } u;
};

メッセージキュー

メッセージを束ねるメッセージキューは次の構造体。

/* メッセージのリスト(今は線形リスト。後に拡張するかも) */
struct MessageList {
  uint8_t               flags;      /* メッセージ状態 */
  struct Message       message;    /* メッセージ */
  struct MessageList    *next;     /* リストの次の要素 */    
};

/* メッセージキュー */
struct MessageCue {
    uint32_t           cue_id;         /* メッセージキューのID  */
    struct MessageList *msg_list;      /* メッセージリストの先頭 */
    uint32_t           size;           /* リストのサイズ */
    uint32_t           free;           /* 空きサイズ */
    uint32_t           flags;          /* 内部状態フラグ */
    struct MessageList msg_pool[MAX_NUM_MESSAGES_PAR_CUE]; /* メッセージリストの領域 */
};

メッセージリストの配列は、静的に持つ。(もしかしたら動的にアロケートできるかも。。。簡単にするために固定長配列。)

キューはグローバルな静的領域に確保する。

/* システム(OS)向けにはキューリストは固定長の配列で持つ */
static struct MessageCue st_system_message_cue[NUM_MESSAGE_CUES];

メッセージキューモジュールの初期化

全てのメッセージキューを無効値で埋める。この後にメッセージは送信可能になる。

/* メッセージキューモジュール初期化 */
void MessageCue_Initialize(void)
{
  uint32_t i_cue, i_msg;
  struct MessageCue *p_msgcue;

  for (i_cue = 0; i_cue < NUM_MESSAGE_CUES; i_cue++) {
    p_msgcue           = &st_system_message_cue[i_cue];
    p_msgcue->cue_id   = INVALID_CUE_ID;
    p_msgcue->flags    = 0;
    p_msgcue->msg_list = NULL;
    for (i_msg = 0; i_msg < MAX_NUM_MESSAGES_PAR_CUE; i_msg++) {
      p_msgcue->msg_pool[i_msg].next = NULL;
    }
  }
  
}

メッセージキューの作成

静的領域から取得するが、ワーク領域を渡して動的確保しても良いかも。 (動的確保するメリットが薄いが…)

/* メッセージキューの作成 */
int32_t MessageCue_Create(uint32_t cue_id, uint32_t cue_size)
{
  uint32_t i_cue, i_msg;
  struct MessageCue *p_msgcue;

  /* 最大メッセージ数を越えていたらエラー */
  if (cue_size > MAX_NUM_MESSAGES_PAR_CUE) {
    return -1;
  }

  /* 無効なキューID */
  if (cue_id == INVALID_CUE_ID) {
    return -2;
  }

  /* 指定したキューIDは既に使われていないかチェック */
  for (i_cue = 0; i_cue < NUM_MESSAGE_CUES; i_cue++) {
    if ((st_system_message_cue[i_cue].flags & MESSAGE_CUE_FLAGS_INITIALIZED)
        && (cue_id == st_system_message_cue[i_cue].cue_id)) {
      return -3;
    }
  }

  /* 使用可能なキューがないか探索 */
  for (i_cue = 0; i_cue < NUM_MESSAGE_CUES; i_cue++) {
    if (!(st_system_message_cue[i_cue].flags & MESSAGE_CUE_FLAGS_INITIALIZED)) {
      break;
    }
  }

  /* キューが全て使用済みだった */
  if (i_cue >= NUM_MESSAGE_CUES) {
    return -4;
  }

  /* 適宜初期値をセット */
  p_msgcue           = &st_system_message_cue[i_cue];
  p_msgcue->cue_id   = cue_id;
  p_msgcue->size     = cue_size;
  p_msgcue->free     = cue_size;
  p_msgcue->msg_list = NULL;
  for (i_msg = 0; i_msg < MAX_NUM_MESSAGES_PAR_CUE; i_msg++) {
    p_msgcue->msg_pool[i_msg].flags = 0;
    p_msgcue->msg_pool[i_msg].next  = NULL;
  }

  /* 初期化フラグを立て、無事に処理を終了 */
  st_system_message_cue[i_cue].flags |= MESSAGE_CUE_FLAGS_INITIALIZED;

  return 0;
}

メッセージキューの破棄

指定したキューIDを持つメッセージキューを削除する。

int32_t MessageCue_Destroy(uint32_t cue_id)
{
  uint32_t i_cue;
  struct MessageCue *p_msgcue;

  /* 無効なキューID */
  if (cue_id == INVALID_CUE_ID) {
    return -1;
  }

  /* 指定したキューIDを持ち、初期化済みのメッセージキューを探索 */
  for (i_cue = 0; i_cue < NUM_MESSAGE_CUES; i_cue++) {
    p_msgcue = &st_system_message_cue[i_cue];
    if ((p_msgcue->cue_id == cue_id)
        && (p_msgcue->flags & MESSAGE_CUE_FLAGS_INITIALIZED)) {
      break;
    }
  }

  /* 探索に失敗した */
  if (i_cue >= NUM_MESSAGE_CUES) {
    return -2;
  }

  /* 無効値にクリア */
  p_msgcue->cue_id   = INVALID_CUE_ID;
  p_msgcue->msg_list = NULL;
  p_msgcue->size     = 0;
  p_msgcue->free     = 0;

  /* フラグを落とす */
  p_msgcue->flags &= ~MESSAGE_CUE_FLAGS_INITIALIZED;

  return 0;
}

メッセージの送信

メッセージを指定したキューIDのメッセージキューのリスト末尾に追加する。

第二引数がポインタである必然はない…。構造体の実体でも全く問題ない。 (もしメッセージを抽象化するならポインタにするべし。)

もう一点気になるのは、エラーコードは内部的でもいいので決めておくべきか…。

/* メッセージを送信 */
int32_t Message_SendMsg(uint32_t cue_id, const struct Message* message)
{
  uint32_t i_msg;
  struct MessageCue  *p_msgcue;
  struct MessageList *p_msg, *p_newmsg;
  
  /* 無効なキューID */
  if (cue_id == INVALID_CUE_ID) {
    return -1;
  }

  /* メッセージキューの検索 */
  if (messagecue_searchcue(st_system_message_cue, cue_id, &p_msgcue) != 0) {
    return -2;
  }
  
  /* メッセージキューが初期化済みではない */
  if (!(p_msgcue->flags & MESSAGE_CUE_FLAGS_INITIALIZED)) {
    return -3;
  }

  /* メッセージキューが一杯 */
  if (p_msgcue->free == 0) {
    return -4;
  }

  /* 空いているメッセージを探索 */
  for (i_msg = 0; i_msg < p_msgcue->size; i_msg++) {
    if (!(p_msgcue->msg_pool[i_msg].flags & MESSAGE_FLAGS_USED)) {
      p_newmsg = &p_msgcue->msg_pool[i_msg];
      break;
    }
  }

  /* 指定したキューIDが見つからない */
  if (i_msg >= p_msgcue->size) {
    return -5;
  }

  /* メッセージの新規作成 */
  p_newmsg->flags   |= MESSAGE_FLAGS_USED;
  p_newmsg->message  = *message; /* 構造体コピー */
  p_newmsg->next     = NULL;

  /* メッセージをキュー(リスト末尾)に追加 */
  p_msg = p_msgcue->msg_list;
  if (p_msg == NULL) {
    /* 初回時は先頭に配置 */
    p_msgcue->msg_list = p_newmsg;
  } else {
    for (p_msg = p_msgcue->msg_list;
         p_msg->next != NULL;
         p_msg = p_msg->next) { ; }
    p_msg->next = p_newmsg;
  }
  
  p_msgcue->free--;

  /* 受信待ち状態に遷移 */
  p_newmsg->flags |= MESSAGE_FLAGS_WAITFORRECIEVE;

  return 0;
  
}

メッセージの受信

フラグrecvflagsに従ってキューからメッセージをキュー先頭から取り出す。 フラグにはキューから取り出さずコピーするMESSAGE_RECEIVE_FLAGS_COPYと、メッセージをブロックせずに受信するMESSAGE_RECEIVE_FLAGS_NOWAITがある。

MESSAGE_ERROR_NOMESSAGEだけは外部公開してある。(ただしその値が-4...-1あたりに再定義したいが、内部コードが汚くなる)

/* メッセージ受信 */
int32_t Message_ReceiveMsg(uint32_t cue_id, uint32_t msg_type, struct Message* message, uint32_t recvflags)
{
  struct MessageCue *p_msgcue;
  
  /* 無効なキューID */
  if (cue_id == INVALID_CUE_ID) {
    return -1;
  }

  /* メッセージキューの検索 */
  if (messagecue_searchcue(st_system_message_cue, cue_id, &p_msgcue) != 0) {
    return -2;
  }

  /* メッセージキューが初期化済みではない */
  if (!(p_msgcue->flags & MESSAGE_CUE_FLAGS_INITIALIZED)) {
    return -3;
  }

  /* メッセージの受信待機(待たない時は1回で終了) */
  do {
    if (message_searchfromcue(p_msgcue, msg_type, message, recvflags & MESSAGE_RECEIVE_FLAGS_COPY) == 0) {
      return 0;
    }
  } while (!(recvflags & MESSAGE_RECEIVE_FLAGS_NOWAIT));

  /* メッセージが見つからない */
  return MESSAGE_ERROR_NOMESSAGE;

}

懸念

  • 送受信の排他を行っていない。 ミューテックスセマフォを用意していないから、用意のしようがない。OS自作ではどうやって排他を実現していたっけ…

アイカツの振り返り

アイカツの振り返り

執筆期間

2018.2.5 @福岡→羽田空港行き機内 13:46書き始め - 2018.2.11 @札幌→羽田空港空港行き機内 + 2018.3.4. 武道館後 + 2018.9.10 アイカツ5thフェスティバル後 + 2018.11.7 仙台GIGSライブ後 + 2018.12.24 アニメJAM2018後 + 2020.8.10 アイカツプラネット発表後

概要

 この文書は自分が観測したアイカツの履歴を示すものである。 この文書は誰に当てたものでもなく、自分の忘備録として、なるべく網羅性を求め、自分が何を思ったかを記載した。 その為冗長で読んでいてもつまらないだろう。また、アイカツに関するネタバレを含むため未視聴者はおすすめしない。諸イベントの開催場所や日時が間違っていたら都度修正を行う。

アイカツ以前

 大学時代は様々なジャンルを転々とした。アイドルマスター関連動画をニコニコ動画で見たり(いわゆるニコマス)。ラブライブ!を選択しライブ(現地には結局行けず、ライブビューイングのみ)を見ることがあった。ラブライブ!の アニメは瞬間風速的に評価できるものだったが、ライブビューイングにおける観客のマナーに辟易してしまい、4thライブをもって距離を置くことを決めた。(コンテンツ自体は好きです)

 そもそもライブに行くことの障壁がないのは、初音ミクマジカルミライに参戦できている事、またその原因になっている八景島イベント(39's CARAVAN presents 夏祭り2012 in 横浜・八景島シーパラダイス:2012.9.13-9.23) の影響が非常に大きい。

「なんだかすごい幼女向けアニメがあるらしい」

 2014年 - 大学修士1年の時にアニメを見始めている。実際には2013年からアイカツというとんでもない 幼女向けアニメが存在していることについてはTwitterはじめ口伝でもかなり伝わっていた。だからといって 即座に1話から見始める事はしなかった(ただの自分の怠慢である)。 見る見る言いながら、結局見始めたのは2014年の5月前あたりになっている。 ここで見始めるにあたっては「大スター宮いちご祭り(劇場版アイカツ)」に伴う無料放送の解放の影響が強い。 友人はここでリアルタイム放映に追いつくところまで視聴している。

 アニメ自体は非常に面白く、すぐに受け入れられた。また早い段階で霧矢あおいさんを安定して見続ける体制ができた。 が、肝心の視聴スピードが遅かった。 「とりあえず50話まで見なさい」の格言(当時からそのセオリーが存在していた)に従い、まずは50話の視聴に到達したのが映画前後。「大スター宮いちご祭り」までに110話程度が目標だったが、結局追いつかず。今でも忘れないが2014/12/13に渋谷の宮益坂下のTOEIで見た。 開始前には先輩(幼女のことをこう呼ぶ)の音楽合唱があり、開始直後のSHINING LINE*、自分は聞いたこともないのに泣いていた。

50話の後

 50話の後、1,2ヶ月視聴を停止した。 50話は当時の自分には全く新しい衝撃であり、50話で区切って視聴を停止したいと切に感じていたのである。 特にカレンダーガールという楽曲は、視聴開始直後と比べて受ける印象が全く変わってしまった。また、脚本としても序盤の勢い、心を動かす台詞と脚本、そして終盤の伏線回収は大変素晴らしく、 この時点でアイカツは名作の1つに並べられるものになっていたと思う。

「125話で確実に死ぬから見たほうが良い」

 この言を友人に貰い、春先に視聴を再開している。 51話以降はドリアカ(ドリームアカデミー)の出現があった。当時はマジキチであるとの印象が強く、正しくアニメを認識できていたか怪しい。ただ、楽しく視聴を継続できていたのは間違いない。 71話での「きらめきはアクエリアス」で自分でも驚くくらいの涙が出た。俺は霧矢あおいというキャラクターが本当に好きになっていたと確信できていたのである。 76話以降は最も熱いアイカツが展開されていたと思う。まずOP/ED(SHINING LINE*/Precious)が初見でまずいと確信できるものだった。 101話に到達したのは2015年5月。100話でのWMのPreciousは今でも強い印象になっている。これを超えるライブ演出は 今だに表れていない。ライブ演出という意味では、サムライピクチャーズには本当の本当に感謝したい。

 102話以降、世代交代の強い動きが作用していた。76話から入念に仕込まれていたあかりちゃんが万を持して主人公になった。 120話まではスミレちゃんやひなきちゃんの紹介、そして留学組の藤原みやびさんが登場していたのが記憶にある。 特に薄紅デイトリッパーは初聴で名曲と確信している。 いよいよ到達した125話。あまりにも示唆的な言葉が多く、完全に全年齢対称とも言える完成度だったと思う。 2番まで流してからのED楽曲は完全に常軌を逸していた。この時点で自分はソレイユしか見ていけないと確信してしまった。

2015.5.31. ダイバーシティ東京(お台場)で初めて無銭を見る(左側後方)

 125話を見た前後の所で初めて無銭(お金を一切払わないからこの名前がついている)ライブに行った。 この日で完全に人生が壊れてしまった。 リハーサルで現れた瑠香さんを見て、同行していた友人と同時に漏らした言葉が「キラキラしている...」。 (※この日のこの瞬間までデレマス等でキラキラしているという発言が多々見られたが、自分は理解できていなかった。瑠香さんのキラキラを見て初めて言葉の真意を自分で消化できたのである) 初夏の暑い日の照り返しを受けて、スクールドレス(のスパンコール?)が本当に輝いていたのである。 そして流れ出したLet's アイカツ!。瑠香さんのダンスのキレが今まで見たどの声優ライブを完全に超えており、たいへん大きな衝撃を受けた。 個人的に既にこの曲は耐えられなくなっていたが、実際に聞いた所、やはり泣いてしまった。 観衆はかなり少なかった(200人程度?)と記憶している。なので階段で踊る皆様をしっかり見ることができた。 無銭開始直後、BGM(芸能人はカードが命!)が流れたときに先輩が階段を駆け登っていたのが懐かしい。その日は1話のいちごちゃん宜しくすぐに寝ることができなかった。

 そしてこれを契機にして、無銭イベントにも積極的に参加するようになってしまった。 その後に開催されたスカイツリーの無銭にも訪れたが、雨天中止を受けてしまっている。 (だがそこのスカイツリーのショップで学生証ICカードとソレイユグッズを購入できたのが満足であった)

2015.6.28 Shining Star* @NHKホール(2階席右側前方)

 2015年の6月にはNHKホールでのShining Star*を紳士淑女席で見に行っている。 今見返すとこのライブで、執筆時点までの軌跡が決まってしまっていたらしい。 しかしこの日のライブに行くあたりまで、歌唱担当と声優の区別すらまだ曖昧だったことについては特筆に値する。 いちごちゃんではほぼ明らかなのに、歌唱時は声が変わるんだなあ程度にしか捉えていなかった。 そのライブで印象に残っているのは笑顔のSuncatcher(巨大風船演出は今でも脳裏に焼き付いている)。今では化物クラスの楽曲である。

 一方の2015.7.10。ようやく放送に追いついた。足掛け1年以上掛かっていた。141話である。 リアルタイムで見れてしまうと展開を追う喜びができる。

アイカツミュージックアワード

 2015.8.22公開の「アイカツミュージックアワード みんなで賞を貰っちゃいまSHOW」を見に行っている。確かバルド9。 映画だと言うのにスマホの光全開で、みんなでおうえんアプリを使って楽しめたのが相当印象に残っている。 「みんなでおうえんアプリ」は、今はもはやサービス終了しているが、当時はテレビソングをキャッチしたり、イベントに出向くとあかりちゃんから電話が掛かってくる事があった。(ライブイリュージョン 三大チームドリームマッチでも!) 幼女先輩も大量に見ている中、ダイヤモンドハッピーで初めて号泣することに気付いていた。 この頃には、アイカツ楽曲は明るくても泣かせる威力を持っていることを実感させられている。

f:id:aikiriao:20180221214314p:plain:w300

 この頃には喜んで芸カに赴く事が多く、どのイベントでもアイカツを十分に楽しめる体制が出来上がっていた。

2015.11.21 AIKATSU☆STARS Lovelly Party! @中野サンプラザ(右側後方)

 非常に自然な流れでAIKATSU☆STARSの単独ライブにも行くことが出来ている。 ただ、大きな箱を使用しているライブとしては、AIKATSU☆STARS単独で大丈夫か?という不安は拭えなかった。 まだ、NHKホールで見ていたオープニングアクトとしての印象が強かったのが原因だと思う。 だがライブが始まってみると、自分の知らないコールが多数発生し(Chica Chicaやランランドゥランランは特に驚いた)、 相当な盛り上がりを見せていた。自分はラ!の反省からコールの予習はしないが、雰囲気としては非常に楽しめていた。 そしてLovelly Party!の最後にはムービでアイカツMF(Music Festa)2016の開催が知らされる。今までのアイカツの総決算としてのものであるのは明らかで、絶対行こうと決めていた。

...悲しいかな当時はアイカツが終わることすら全く気付かず、純粋に楽しむつもりで構えていた。

f:id:aikiriao:20180221214611j:plain:w300

f:id:aikiriao:20180221214640j:plain:w300

2016.2.22 までの動き

 いよいよドームシティライブを控えた。それまでに真に様々な動きがあった。私として印象に残っているのは、 「アイカツイリュージョンライブ 三大チームドリームマッチ」である。研究室の都合で福井県に行く予定があったため、 大阪公演に行くことができたのである。それでは、Evernoteの感想をそのまま抜き出そう:

・1/9(土)7:20 難波パークス前に着。まずは堂島リバーフォーラム(福 島駅)へ。場所を抑えてから、西宮神社(福島駅)へ行くとすごい祭が…祭りで食べあるきに興じ、甲子園球場に行って昼辺りに福島駅へもどる。
                   物販が14:30-から。余裕で買えると思ったらペンライト買えず。油断したか…?
                物販のミスで絶望していたら16:00の開場直前に入場してしまう(油断ミス②)
                    さてライブ本番。モデルはアーケード順序。          
                         ・古い曲を多めにやってくれた(signalize, take me higher等)
                         ・あおい姐様が好きすぎて辛くなった。特にprism spiralやってくれて感極まる。泣く
                         ・アンコール前はshining line*(full). もちろん泣く
                         ・アンコール後のカレンダーガールで死亡

f:id:aikiriao:20180221214718j:plain:w300

f:id:aikiriao:20180221214737j:plain:w300

f:id:aikiriao:20180221214754j:plain:w300

f:id:aikiriao:20180221214810p:plain:w300

2016.1.30のラクーア無銭も大変素晴らしいセトリだった。自分個人のtwitterの感想が限りなく薄く、改めて自らの受容態度が疑われる。 サマーマジックのみきさんサプライズが今でも印象に残っている。

2016.2.22

 アイカツの放送終了とアイカツスターズの放送開始が発表される。 予想が外れた事が辛かった。今となってはチラシの裏以下の最低の予測であるが、200話まで続き、ルミナスがソレイユを倒してから終わるものだと、それしかないと予想していたのである。

急遽友人宅でアイカツの復習を行っている。1話から76話あたりまで、飛ばしながらも視聴していた。

f:id:aikiriao:20180221215051j:plain:w300

f:id:aikiriao:20180221215106j:plain:w300

いばらの女王

 私がアイカツで最も強い衝撃を受けた回は176話「いばらの女王」である。 この話と曲は受ける印象が時期によって全く違う。 …何度も口にはしていたが、176話以前ではあかりジェネレーションを平然と叩くことが多かった。いちご世代と比べてスポ根が無いとか、仲の良い身内でゆるく高めあっているイメージしか無かった。だから2016.2.22にアイカツ終了の報が出ても「致し方ないか…」という気持ちが先行していた(あまり言いたくないけど売上も落ちていたようだし)。

 はじめていばらの女王を聞いたのは2016.2.12、確か大洗旅行に向かう電車の中である。印象としてはふ〜ん…途中の転調があるけどボーカルが平坦な(コーラスなしでどこか寂しい)曲だなあとしか思っていなかった。アニメの「私の見つけた最初の風!」でもスミレちゃんへの印象は薄いものだった。

 そんな甘えをアイカツは許してくれなかった。 176話「いばらの女王」を初めて見たのは、キンプリ(名作)を川崎チネチッタで見た後だった。 深夜で0:00AMを回った当たりで視聴し始めたが、そのシーンで思わず顔を覆い、嗚咽し蹲った。 顔が汚れたために風呂に入り直したが、風呂の中でも涙が止まらない始末。 それまでのゆるい(甘いと思っていた)思い出がすべてひっくり返って自分を攻撃していたのである。 改めて、自分の視聴態度の低さや考察の弱さに嫌気もさした。 (ここまで鮮烈に刺さったのは、TLでネタバレを踏まなかったのも幸運だったのかも知れない。)

 176話に至る経緯を振り返ってみると、アイカツ史上最大に常軌を逸している。 あかりジェネレーションのBD-BOXが出たら、スミレちゃんの挙動をしっかり見ていたいと心から感じている。 また楽曲も(人づてに聞いた話だが)エフェクト一切無しでボーカル一本で歌の道を行く事を表現しているものだと聞き、恐ろしいほどの狂気を感じた。スミレちゃん、ひいてはアイカツがこんなに奥行きのあるコンテンツなのかと もう一度感服し、この時最大に放送終了を惜しんだのである。

またこの頃になると、アニメライブシーンの直前になると極度の緊張に陥って過呼吸気味になることが多かった。アニメを見ていてこのような症状を起こすのは、当然今を持ってアイカツ以外に存在しない。

Aikatsu Music Festa 2016 @東京ドームシティ(2日目:右前, 3日目:左前)

 2016.3.20(いばらの女王放送から3日後!)、MF2016の2,3日目に参加した。 初日に参加できなかったのは友人の研究都合である。これに関しては後悔していない。 (Wake up my Musicが見れなかったのは...後悔) どうであれライブに参加できていることが最上である。...が、オールスタンディング席には正直辟易した。 2日目のオールスタンディング環境で家虎・円陣・割込みを経験したからである。(ぶつかり跳ね飛ばされ) ラ!でも経験していた事だが、自分はライブをどの様に楽しめば良いのか、また怪しくなってしまった。 そんな愚痴はいいにして、集大成のライブだったことは間違いない。

f:id:aikiriao:20180221215412j:plain:w300

f:id:aikiriao:20180221215429j:plain:w300

 2日目で特筆すべきは「ハートのメロディ」と「いばらの女王」。「ハートのメロディ」はそれまで全くなんとも思っていなかったが、イントロの瞬間に意味の分からない涙が出た。1番の間もずっと蹲りっぱなし。 「いばらの女王」は176話を踏まえた上では語るべくもない。「スミレちゃん良かったよー!」を言葉にならない言葉で叫ばざるを得なかった。

 3日目は「あおいいちご」が全てを持っていった。アイカツライブで顕著なのだが、ライブを見た後セトリや起きたことををほぼに忘れてしまう。3日目は正直、あおいいちご以降の記憶がない(大号泣しながらカレンダーガールのCメロ「思い出は未来の中に探しに行くよ約束」 をワイパーしているのは朧気ながら覚えている)MF終了後、調布市の友人の家に行き、DCDアイカツ筐体を始めることを覚悟した。(当時の自分としては大変な覚悟が要った。 学生証ICカードは上述のスカイツリーで購入していたが、どうしても始めることができなかった)遅きに逸した始まりだったが、非常に楽しむことができた。

f:id:aikiriao:20180221215457j:plain:w300

2016.3.31 アイカツ放送最終日

 この日にアイカツの最終放送日があった。完全に私事だが2016.4.1に入社式があったので、学生としての、最大の区切りをつける覚悟で視聴した。 最終話はスッキリした脚本に感服した。ほとんど泣くことはなかったが、ライブシーンで流れたカレンダーガールだけは別。 アイカツはカレンダーガールに象徴されるのだと理解し、泣いた。 これで完全に区切りがついたものと考えた。が、これから始まる終わりへの2年間の始まりに過ぎなかった。

2016.5.18 DCDアイカツ稼働最終日(※公式での最終稼働日の発表なし)

 この日までDCDアイカツ筐体を1日3時間程度(2000円が無くなるまで)プレイしていた。失われた思い出を取り戻すのに必死で、長時間のプレイでも全く苦にならなかった。秋葉原のカードショップにも毎日赴き、カードを購入し続けた。 最初は大井町イトーヨーカドー最上階のゲーセン(今は閉店...)で遊んでいたが、筐体が減るに連れプレイできる場所が限られ、最後は秋葉原セガ新館に落ち着いた。カレンダーガールをやることがとても多く、最終日の5.18はセトリを組んでプレイ。最終プレイはアイカツメモリアル2013の最終話「思い出は未来の中に」。毎日プレイしていたのに涙が止まらなかった。 同時に2016.4.27のDCDアイカツスターズの稼働初日(先行稼働日)にも立ち会っている。

f:id:aikiriao:20180221215538j:plain:w300

f:id:aikiriao:20180221215558j:plain:w300

f:id:aikiriao:20180221220035j:plain:w300

f:id:aikiriao:20180225211702j:plain:w300

f:id:aikiriao:20180221220105j:plain:w300

f:id:aikiriao:20180221220125j:plain:w300

2016.8.17 劇場版アイカツスターズ

 正直、アイカツスターズのアニメは評価しかねる状態が続いていた。推しが決まらないのはその証左だろうか...。 アイカツには50話をもって完成したのでそれまで最終評価は見送りたいとしていたが、どうしてもアニメを好意的に見ることができず、中途半端な気持ちのままだった。

 劇場版で一応の方針決定が出来るだろうと考え、何度も劇場に足を運んだ。が、何も結論が出ないどころか見れば見るほど作品の魅力が分からなくなっていくばかり。この時点で、アイカツとアイスタは完全に違うものであり、アイカツという概念は受け継ぐのが難しいものだと結論している。 劇場版アイカツスターズに合わせていちごちゃんあかりちゃんが筐体でプレイできるようになったのは嬉しかった...と同時に懐古しか出来ない自分が苦しかった。 2016.8.27にはアイカツスターズのライブ付き上映会に赴いてスターズのメンバーを久々に見ている。

f:id:aikiriao:20180221220710j:plain:w300

2016.9.24 DJライブに初めて参加 @大阪ピカデリー(左側後方の座席)

 秋葉原アニONというカフェでアイカツ楽曲をDJするイベントが開催されており(歴史があるそうだが初参加だった)、そこでアイカツ楽曲を中心に懐古しながら楽しんでいた。

 大阪でDJイベントがあるとの情報が入り、謎の行動力で、DJライブのためだけに大阪に赴いた(今考えると異常)。 DJライブでは、会場の雰囲気には驚かされたものの、始まると皆思い思いに楽曲を楽しんでおり、ライブに参加したような感触がした。そして終盤に流されるカレンダーガールとSTART DASH SENSATIONに必ず泣かされた。 (この頃にSTART DASH SENSATIONが大変危険な楽曲であることを理解している) この頃のその他の特筆事項としては、Dreaming birdに衝撃を受けて何度も筐体で遊んでいる。

f:id:aikiriao:20180221220734j:plain:w300

2016.10.1 池袋サンシャイン無銭(3F観覧席の立ち見)

 アイカツを見ていない人を強引に連れていきサンシャインで開催された無銭を見た。 早朝に行った段階で既に場所取りが発生していた。ライブが始まる前に硝子ドールが流れて驚きの声が上がった事と、公演中はスタートライン!の噴水が完全一致で印象には残っているものの、それ以外が何も記憶にない。。。 この日、アイカツMF2017の開催決定があった(ライブ中では映像が運用ミスで流れず、撤退が早すぎた為その後のTLから判明)。

f:id:aikiriao:20180221220800j:plain:w300

 その後、2016年が終わるまでさしたる行事にも参加していなかったと感じている...(DMMシアターでのライブイリュージョンは見ている。So Beautiful Storyには泣かされた。)MF2017に向かって耐えながらアイスタを見る日々が続いた。 アイスタの筐体は過疎状態が進んでいた。常時満席となったプリパラ台を横目に、黙々とPRコーデを収集する日々だった。 アイスタについてはマイページの機能削減が著しく、またストーリーモードが薄くて(というか、無い)辛かったが、こちらも我慢しながら、 アイカツDCDでやりきれなかった分として、努めてプレイを続けていた。

2017.2.18周辺 懐古の日々

 さしたるイベントも無かったが、Twitterを見る限りではアイカツをずっと懐古する言動しか見られない。 新宿マルイで行われたDCDアイカツの復活稼働には長蛇の列。早朝に向かって整理券を入手しないとプレイできない状態だった。 たった1回の機会のプレイでは、やはり2013メモリアルの「思い出は未来の中に」。

2017.3.25,26 MF2017 @パシフィコ横浜(1日目:左後、2日目紳士淑女:2階席右中、2日目:右前)

 MF2017は初日はアイスタ、2日目はアイカツ(昼は紳士淑女)で分かれていた。 この頃にはすでに懐古するだけの存在になっていた自分は、2日目しか期待していなかった。(関係諸氏には怒られるかもしれないが、私は真にこう思っていたのである。自分が確かにこう思っていた事実は明らかにする必要がある。) 初日のアイスタ回。この瞬間既にお台場無銭から1年半が経過していた。メンバーの確かな成長(歌とダンス)を肌で感じることができた。 特筆すべきはななせさんのMiracle Force Magicだろう。映像演出も合わせてたいへん格好良かった。

2日目紳士淑女回

激震が走る。アイカツパートに入ったと思ったら

  • カレンダーガール: レコードが回転するEDが流れ、蹲る
  • SHINING LINE*: 再び涙があふれる
  • START DASH SENSATION: 涙が流れる
  • Let's アイカツ!: 泣く
  • ダイヤモンドハッピー: 動けなくなる

限られた時間で与えられたこれ以上のセトリを、本稿を書いている時点では私は知らない。 紳士淑女終了後、友人の右隣に座っていた太めのスーツ姿のサラリーマンが目頭を抑えて号泣していたのが全てを物語っていた。紳士淑女の出席者のほとんどが泣いていたと思う。

2日目夜公演

会場に入る前に友人とある予測を立てていた。

「萌菜さんは絶対に来る。」

何故か。センチメンタルベリーやきらめきメッセンジャーで萌菜さんがまだ歌っていたからである。 しかし、このような予想をたてて決め打ちしてしまった事は今思うと最大の愚行だった。

 ライブは滞り無く始まるが、なかなか現れない氷上スミレちゃんとみくるさん。そして訪れたキラキラ宣言。フォトカツ8という投票による上位8名の発表があり、その中に氷上スミレの存在を確認した。 心の中でガッツポーズを決めた次の瞬間にメンバーが見える。林檎が見える。 次の瞬間、蹲り前を見ることができなくなってしまった。 歌唱担当が失われることがこんなに辛いことだとは、全く知らなかった。

 ライブのその後の記憶はほとんど存在しない。辛うじて覚えているのはSTART DASH SENSATIONで瑠香さんの歌唱が途切れ嗚咽したこと、 そしてやはりカレンダーガールでボロボロに泣いた事である。ライブでショックを感じたのは初めてだった。 予想が外れたからだろうか、それとも本当に歌が聞けないことだろうか。分からないが最早、このコンテンツは 楽しめるものではなく、心に深く突き刺さっているものになっていた。

会場内ではDCDアイカツ筐体も稼働していた。

f:id:aikiriao:20180221221242j:plain:w300

2017.4.16 ラゾーナ川崎プラザ無銭(午前公演:1階左後方, 午後公演:3階)

 無銭の聖地とも言われるラゾーナ川崎に赴いて無銭を鑑賞(自分は初めて行った)。 発表されたばかりの新OP「Bon Bon Voyage!」が紛れもない名曲だった。また、りささんが加入したからか、地理が良いのか、かなりの人手だったように記憶している。

f:id:aikiriao:20180221221440j:plain:w300

2017年の夏 アイカツDJライブツアー

 アイカツDJライブツアーが全国ツアーを敢行していた。仙台は流石に無理があったが、大阪・名古屋・渋谷公演に参加する意向を固めることが出来た。大阪は会場すらも前年度と同じだったが、喜んで向かった。

  • 2017.5.27では大阪

  • 2017.6.17では名古屋(友人は都合で途中退席)

    • 上記2公演では終盤でカレンダーガールとSDS(START DASH SENSASTION)が使用されるのが本当に辛い。なんだろうか、 泣くためだけに公演に言っていた感すらある。

f:id:aikiriao:20180221221744j:plain:w300

  • 2017.7.23では渋谷WOMB
    • WOMBではPandaBoyさん(Kira・pata・shiningとED曲MIXの作者だ)が参加。Kira・pata・shiningは重低音が強く、 ヘドバンが止まらない。

f:id:aikiriao:20180221221816j:plain:w300

f:id:aikiriao:20180221221833j:plain:w300

2017.7.8 ラクーア無銭(午前公演:2階右後方, 午後公演:右最前)

 執筆時点で最高の無銭だったと言わざるを得ない。 理由は旧アイカツ曲をやってしまったから。 これは反則行為であり、ある意味、この時点で何かを察するべきだったのかもしれない。

 午前の公演ではみきさんとみほさんが旧カツ衣装で飛び出て、その場で嗚咽した。「Poppin' Bubbles」が響き渡り、振り付けもろくに出来ないまま俯いた。

 午後ではオールスタンディングとなっていた。整理券番号19を引いて最前に来てしまった。演者の表情すらも見えてしまう距離で、開幕の「Lovely Party Collection」、そして「フレンド」が続いて動けなくなってしまった。 最後にツアーとアイカツ武道館開催の発表があり、STAR☆ANISメンバーも全員出てきて「アイドル活動!」。 これらは今書いていて、嘘みたいな事だと思うが、実際にこれらが行われたのである。

f:id:aikiriao:20180221221918j:plain:w300

f:id:aikiriao:20180221221853j:plain:w300

2017.9.10 ラゾーナ川崎プラザ無銭(午前公演:2階左?, 午後公演:2階左)

 日の傾きも早くなってきた川崎で無銭がもう一度あった。2017.7.8 のような異常なセトリは見られなかったが、「Bon Bon Voyage!」が印象的であり、2017年のアイスタの夏はこのBon Bon Voyage!に代表されていたと思う。

2017.11.23 掛川ポップカルチャーサミット

 ふうりさんが来られるとの情報を得ていたので、決め打ちで参加を決意。イベント開催週には霧矢あおいの新曲「ショコラショー・タイム」が発売されていたので、大きな期待の中で深夜バスで臀部を破壊しつつ掛川へ。 リハーサルでふうりさんは「stranger alian」。おそらく生で聞いたことが無かったので、動けなくなってしまった。 本番でも期待しているのはふうりさんだけ…(静岡まで来て最悪の態度である)。そして「芸能人はカードが命!」 が流れてアイカツが始まり、ふうりさん瑠香さんが出てきて頭を抱える:

  • アイドル活動!(Rock ver)
  • ショコラショー・タイム(full): 発売(発表)直後にやってくれるアイカツ特有の速度。喜びしかない
  • Blooming♡Blooming: 泣かざるを得ない
  • オリジナルスター☆: 動けなくなる

掛川は日帰りだった(さわやかや浜松には行った)が、充実した1日であり、ツアーに向けた心意気は十分だった。

f:id:aikiriao:20180221222657j:plain:w300

f:id:aikiriao:20180221222550j:plain:w300

2018.1.5 - 2.4 Music of DREAM!! ツアー

自分が参加したのは次の3公演:

  • 仙台(2018.1.5 イズミティ21. 紳士淑女は右前, 夜は右中): ゲストはリス子さん
  • 東京(2018.1.9 東京ドームシティ, MF2016と同様. オールスタンディング最後方): ゲストはソレイユの3人(わか・ふうり・ゆなさん)
    • アイカツミュージックフェスタ for familyがあったが、高校生以上は単独入場禁止(中学生以下同伴で入場可能)。見れず。
  • 福岡(2018.2.3 福岡国際会議場. 紳士淑女左中, 夜は右前H席): ゲストはわかさん

セトリはほとんど共通だったが、各公演を経る度に確実に演者の歌唱が安定していった。ツアーは焼き増しではないことがはっきりした。

それでは仙台から特記事項を列挙する:

仙台

 ライブが始まる前にアイカツの楽曲をfullで一曲流す行為が行われていて、穏やかではなかった。仙台でははろー♪Winter Loveだった。

 紳士淑女の席は幼女先輩のすぐ後ろで、理論上は最前にいることが出来、落ち着いた態度でライブが始まった。何よりも衝撃だったのは「So beautiful story」(せな・ななせ)。つまりゆめちゃんと小春ちゃんのSo beautiful story。この曲はDMMイリュージョンライブが契機になりアニメで歌唱された奇異な経緯を持つ曲たが、誰でも思い入れがある曲だと思う。アイスタの楽曲で泣いたのはこれが初めてだったと思う。

 リス子さんが出てきてMove on now!(夜ではななせさんが出てきた。私のMove on now!参照)が歌われたのは想定内。オトナモードが歌われたのは想定外。(萌菜さんのコーラス入り...)。アンコール後はダイヤモンドハッピーを流すという背徳行為。

 仙台公演が終わった後、大阪・名古屋公演も絶対行きたいと感じたが、大阪は日程(日曜で有給取りまくっていたので)、名古屋は地理(瀬戸市)のため断念。行くべきだったとは思う。(特に名古屋公演では薄紅デイトリッパー、恋するみたいなキャラメリゼが予定通り歌唱されていた。熱い。)

東京

 仙台公演から間を開けずして東京公演。かつてのMF2016でオールスタンディングは避けたいと思っていたが指定席が取れなかった。整理券番号が1500番中1400番台だったため、頑張らず最後方に立った。演者はもちろん殆ど見えないが、MF2016よりはひどいことにはならなかった。

 ライブ前のアイカツ楽曲は笑顔のSuncatcher。選曲が意味不明、ただ蹲ることしかできなかった。ソレイユは次の曲を歌った:

  • Good morning my dream
  • Trap of Love
  • ショコラショー・タイム(full)
  • カレンダーガール

 ダイヤモンドハッピーはスターズが歌うから、何を歌うのか予想ができなかったがGMMD(Good morning my dream)。125話を思い出してひたすらに辛くなる。カレンダーガールは予期していなかった。これを流したらアイカツは終わりだと豪語していたが、そのとおりになってしまった。カレンダーガール後は呆然と立ち尽くした。

 東京公演で他に特記すべき事項は荒野の奇跡だろう。1番サビで2番サビを入れてしまう非常に珍しいミス。だが自分はアレンジが入ったのかと混乱していた(周りの人々は何も気付いていない様子)。2番サビでは同様のサビをもう一度、ラスサビではラララの歌唱で切り替える事態。思わず頭を抱えたが、歌唱完了まで堂々とやり抜いた姿が鮮烈に残っている。(その後りささんのMCで舞台裏で泣いていたことが示唆されたが...)176話と重ねるのと同時に、公演直後に萌菜さんのアニソンOP起用の報に当たる。完全に動けなくと同時に、ここまで自分は演者に思い入れてしまっていたのに自分で驚いた。

f:id:aikiriao:20180221223017j:plain:w300

福岡

 少し間が空いた2.3に福岡公演。深夜バスは(日程的・体力的に)つらいということで飛行機移動を選択。といってもAM6:15の便に乗るために、早朝AM2:00に起床していた。わかさんが来るとのことでDancing in the rainとgrowing for a dreamを聴き込む。博多駅から国際会議場までの交通アクセスが悪かったことは印象に残っている。徒歩だと30分ほど歩くのでバス(西鉄, nishitetsu)で移動。

 公演はかつてない安心感があった。歌唱は安定していたのは上記のとおりだが、視聴側としても楽しむ余裕があった。それでも8月のマリーナのソロの気迫の熱唱は喝采ものだった。(個人的にスターズ楽曲で8月のマリーナはトップクラスに好きである。)また、Message of a Rainbowでは有志支持により、サイリウムの虹が出来た(H席の担当は緑)。その瞬間せなさんの歌唱が確かにブレていた。

 わかさんはDancing in the rainとgrowing for a dream, ここまでは予想通りだったが、夜公演ではるかさんも出てきて「星空のフロア」。歌われればもはや当然なのだが、予測が出来ておらずやっぱり頭を抱えて蹲る。

f:id:aikiriao:20180221223041j:plain:w300

2018.2.4 福岡にて

 福岡公演が終わった2018.2.3は中洲の屋台や美味しいモツ(ニラ山盛り)を食べて大いに満喫する。アイカツのライブとしては久々に手放しで楽しめるものであったため、力が抜けて喜んでいた。

 迎えた2018.2.4。その日は一日福岡観光に当てることにしていた。雪の舞う福岡市内で、まず太宰府を見学して、次にのんびり中の島水族館へ向かった。 中の島水族館は16:30で最終入場となっており、間に合わず笑いながら福岡市内に戻った。一方この日はアイカツ新シリーズのアイカツフレンズの発表会(+アイスタ全国大会)があった。シリーズの概要発表があるのはもちろんだが、それ以外にアイカツフレンズには大きな懸念点があった。

  • 歌唱担当に声優を当てる可能性がある

アイカツフレンズが始まる2017の10月当たりには次世代 "声優" オーディションが開催されていた。そのため、歌唱担当と声優は分けず、声優に一本化する のではないのか、そして、今までの歌唱担当の皆様とはお別れになるのではないかという憶測があった。そして、その憶測は当たってしまった。

STAR☆ANISとAIKATSU☆STARS!は「アイカツ!ミュージックフェスタ inアイカツ武道館!」をファイナルライブとしアイカツ!シリーズから卒業します。これまでたくさんのご声援ありがとうございました。これからはメンバーそれぞれの未来に向かって頑張っていきます。応援よろしくお願いします

MF2016で既にSTAR☆ANISは卒業してもおかしくない印象があった。が、AIKATSU☆STARSの皆様も同時に卒業するというのは寝耳に水であった。我々は卒業の報を福岡市内の焼き鳥屋で触れた。情報に触れてからは焼き鳥の味は失われてしまった。その後はホテルに戻り、終始無言でMF2017の2日目を視聴。涙が留まること無く出続け、目が腫れていた。(註:この頃、旅行先のホテルの夜はライブBDを視聴する奇妙な習慣があった。アイカツだけでなくミクさんやプリパラの公演も見ている。2.3の夜はMF2017の紳士淑女回を見た。セトリの異常性を改めて確認している。)

 その後の東京帰宅までの流れは正直朧気である。みきさんが言っていたとっとーと(お菓子)を買ったり筐体を回していたことくらいしか記憶にない。家に帰っても気持ちに隙ができると涙が止まらない毎日が続いた。

2018.2.11 新千歳→羽田機内にて 初星宴舞も

 今は2.9,10,11の雪ミクライブ(別件だが八景島のBD映像を見て初心を思い出すことができたのは大変貴重であった。ライブへの抵抗感は八景島でふっとんだ といっても過言ではない。後で買おうと思う。)を満喫して飛行機に乗り、帰途についている。友人は会社の同期と面談を行うことで精神的には楽になって いるが、自分は正直整理がつききれていないのが現状である。今の気持ちを正直に述べると、 「声優を歌唱担当に使おうがアニメが面白ければ見る。ただ、歌唱担当とのお別れはあまりにも辛い。」 である。ただ、田所あずささんや大橋彩香さんを起用したことでイベント競争率は激増になったのは間違いないことであり、無銭の開催が危ういのが非常に辛い。

 その後無理やりアイマス765新年ライブ(初星宴舞)のアンコール上映を品川に見に行った。MCが面白いのは折り紙付きだが、思い出が足りないのと(ゲンキトリッパー等は例外)、この後も続いていくコンテンツであることが見えて、アイカツを応援する立場の自分から見えてしまって辛くなってしまった… もう、正常な目でコンテンツを見る事もできないのか。

これから

 後は2.27,28の日本武道館を残すのみとなった。 今や、自分にとってアイカツは歌唱担当なしには語れない存在になっている。また、アイカツによって幼女向けというくくりは最早意味を成さないことが明らかになった。アイカツのアニメは2016.3.31に確かに終了していたし、アイカツスターズは正直な所評価できなかったから、本当は2016.3.31に全て終わっていたのかもしれない。少なくとも延長戦として2016年から2018年まで続けてきた気持ちはある。筐体も旧DCDアイカツ筐体の義理として(筐体は遊べるときに遊べるだけ遊ぶべし)やっているが、十分にやりこんだ感触があり、アイカツフレンズは恐らくやらないだろうという予感がある。

 以上を振り返った上でこれからを考えると、具体的なものは何も浮かばない。 面白かったプリパラも2018春で終了し、新世代への交代が決定している。プリキュアについては年次の世代交代が発生しており、新しいスタートを既に切っている。周囲の動きはともかくとしても、自分としてはどうするかを考えると、新世代のアニメは見るだけ見て、あとはのんびりプリリズ(プリティーリズム)を視聴しようかと考えている。

追記:2.28,29 アイカツ武道館 @日本武道館(1日目アリーナD68, 2日目アリーナA68)

この日が来てしまった。 この日に備えて(わかさんからアニメを見たほうが良いとの示唆が合ったので)125話までアイカツを見た。

1stシーズンは名作であるのは間違いなく、2ndシーズンは熱く、そしてあかジェネは今見返すと泣けるシーンしか無かった。(特に96話「秘密の手紙と見えない星」は…)

ホテルは学生時代に住んでいた調布市を選択。

始まる前は何が起こるか分からず、分からないことによる恐怖しかなかった。考えれば考えるほど絶望する方向にしかいかなかった。

物販の待機列ではずっと限界であり、言葉が少ない。 物販は事前物販を使用していたので買えないかも知れないという懸念がないのは助かった。(ライブTシャツのSサイズとサイリウムの完売は早かった。11時待機列入りで間に合わず。)

飯田橋デニーズでいちごパフェを食し、会場入り。大量に用意されたフラスタに驚き、入場待機列に入る。 この時点で足の震えが止まらず、呼吸が上手くできなくなってしまう。このような不調をきたすのは人生で初めてだった。

会場に入る。68とは言え前から10数行目くらいに配置され、かなり前に体感される。アリーナは平面なので演者が見えるか不安だったが、問題なかった。この席はコールがほとんど聞こえず(コール打っている人が少なかった?)、自分で思うままのコールを打った。

ライブは定刻通りスタート…full曲を連打している状態から、チュチュ・バレリーナが流れて音量が上がり、芸能人はカードが命が聞こえてきた。

最初はアニメのOP/ED曲を連打。アイドル活動とスタートライン、オリジナルスター☆彡、…、メンバーはSTAR☆ANISもAIKATSU☆STARSもごちゃまぜ。フォーメーションがめぐるましく変わっていく。

Signalize!で次の歌詞が頭に浮かび、そして実際に歌唱され涙が出た。

やがて生まれ変わる世界を感じる予感の中で移り変わる世界を求める旅だね前進だ

アイカツが新世代に交代しようとしている中で、この歌詞が、5年前から用意されていた歌詞がどうしようもなく刺さった。

アイカツメロディ!の後のスタージェットはせなさんソロでfull。スタージェットはMF2017でやっていなかったのでやって欲しいと感じており、実際に歌唱していただき、しかもソロの見せ場があって大変ありがたかった。

ドリームアカデミーのPVが来て「お、ハッピィクレッシェンドか?」と思わせといてKira・pata・shining。このガンギマリ感、WOMBで感じたものと同じだった。ここから先はshortが多かったが、繋ぎが複雑でかつ高速だった。

オーロラプリンセス、lucky train!、ミエルミエール、薄紅デイトリッパーは新PR衣装が出てきた。。。この期に及んで、武道館のためだけに用意された衣装に、製作者側の並々ならぬ努力を感じた。

早くも終盤に差し掛かる。エピソロ→Take Me Higherサイリウム色そのままでThe only sunlight。その直後テテテテテテテ…で蹲りチュチュ・バレリーナが放たれた。この楽曲は間違いなくAIKATSU☆STARS!の必殺技だろう。STARS!のメンバーの瑠香さんがPR衣装に変えておりこの時点で頭を抱え、そしてSTART DASH SENSATIONが打ち込まれる。

START DASH SENSATIONはMF2017で瑠香さんが号泣してしまい歌唱が止まったことがまだ記憶に新しいが、ソロで歌うとなると絶対去年の焼きましになってしまうのではないかと動揺していた。瑠香さん歌唱の後ろではMF2017と同じあかりちゃんの成長を示す動画が流され、我々は1番の途中で号泣し始めている。だが瑠香さんは歌いきった。本当の熱唱である。

歌唱が終わると自然と「ありがとう」を言わざるを得ない状態になった。間違いなく、この日の一番の見所であり、瑠香さんという本当のアイドルの存在感を再確認した。

後は最終盤。ランランドゥランラン→ダイヤモンドハッピー(ソレイユVer.楽しかった)で完全に楽しむ状態になる(体力はもう限界。) ドラマチックガールで泣き始め、AIKATSU GENERATIONでほぼ泣き通し、最後の曲、SHINING LINE*では必死に振り付けを追いかけた。

アンコールに入る。カレンダーガールを最大限危惧していたが、まずはGood morning my dreamから入った。Fullは珍しく、また、125話を見た身からするとすでにカレンダーガールが予兆され限界となる。そしてカレンダーガールがきた。カレンダーガールは私のなかではアイカツ史上最大楽曲であり、アイカツはカレンダーガールとも捉えている。その大きな価値故に心はこらえることができず、1番の途中から終わるまで泣きっぱなし。次のMCでもタオルで顔を覆い、泣き続けた。MCでは各個人、とくにゆなさんが大事なことを言っていたのに記憶がない…

最後の楽曲はLet's アイカツ!。Let's アイカツ!は本当に好きだ。初めて聞いた瞬間からキャッチーな名曲だと思い、聞き続ける度に涙を零すようになった。初めてダイバーシティ東京の無銭に行った時に泣き、そして今に至っている。

Let's アイカツ!で確かに泣いたが、心はスッキリした。なんだろうか、最後のMCで楽しい!と誰かが言ってくれたからだろうか、1週回ってしまったのか分からないが、終わってみると楽しいと言う気分が溢れた。とても次の日の最終日に終わるとは思えない状態で会場を後にした。

調布についてからは劇場版アイカツを見て(開幕のSL*と終盤のLet's アイカツで泣いた)ラジカツでわかさんが輝きのエチュードを推していたのを聞きながら、この文章を急ぎしたためている。

今の気持ちからすると、2日目は輝きのエチュードが主軸(見せ場)になるだろうと予測する。それの前後をどうフォローするか大変見ものである。とにかく今は楽しい。終わってほしくない。

2日目

2日目は物販もないので、調布でアイカツ筐体回してから、のんびり都内へ。近場のジョナサンでいちごパフェを食してから15:30くらいに現地入り。(いちごパフェの売れ行きがすごかったらしい)

しかし入場前は今まで経験したことがないくらいの限界をきたす。とにかく終わってほしくないと念ずることしか出来ず、足に力が入らない状態だった。入場後は時間が早く進んだ。念入りにトイレに入り、定刻でスタージェットが流れてマスターボリュームが上がりライブスタート。

...セトリのまとめは後でやる。

アンコール時、「もうこれが最後か」という心が一瞬浮かんだ瞬間に今までにないくらいの涙が溢れ出た。こんなに泣いたのは小学生以来かもしれない。嗚咽し、呼吸も出来ない状態で蹲っていた。周囲は「アイカツ!アイカツ!」の大合唱。この期に及んでアイカツ!を叫ぶことが出来ない自分がもどかしかったが、身体が言うことを聞かない。。。

アンコール後はSTARDAM!からのカレンダーガール。。。カレンダーガールはなんとかイントロのデーンは耐えたが、「そろそろヤバっ 行ってきまーす!」で完全に崩れ落ち、涙ながらにこらえてふうりさんを見ようとしていた。

そして総まとめのMCに入る。ゆなさん中心に心のこもった演説が入り、涙が堪えられない。

最終楽曲は予測通りの「アイドル活動!」。この曲を最後に選んでくれて本当に感謝している。私はカレンダーガールが大好きだが、これを最後に持ってくるとどうにも湿っぽくなってしまう。明るい終わりにするためにはアイドル活動!しかない。

演者さんがステージから消えた後、そのまま椅子に座り込み大号泣した。全く身体は動かず、涙がひたすらに出続け、嗚咽が止まらなかった。左隣の方も大号泣しており、もう、だれも救いようがない状態になってしまった。しばらく泣いていたらスタッフさんから声を掛けられ撤退せざるを得ない状態になった。左隣の方と「アイカツが好きでよかったです」と挨拶できたのは良かった。これで私的に完全に区切りが付き楽になった。

その後は本当に晴れ晴れとした気分で武道館を後にしている。憑き物が取れたようだった。呑みなんか出来るはずがないと思っていたが、明るい気分だったので軽く呑む事ができた。

その際に初めて無銭に行った時の記録を振り返った。無銭の様子は写真に収められており、確かに、階段で踊るアイドルが存在していた。

追記:アイカツ5thフェスティバルまで

武道館終了後の約半年、その間にアイカツスターズのアニメ終了、筐体の終了、そしてアイカツフレンズの放送開始があった。 その間自分は中途半端な立場を取ることしかできなかった。まずはアイカツ5thフェスティバルに至るまでの経緯を振り返る。

アイカツスターズの終了はあっさりと通り過ぎた。アニメ終盤の取りまとめはさっぱりとして良かった。また、スターズ筐体の終了に立ち会った。最終日の4.4の夜は、初代DCDと同じく、セガ3号館でセトリを組んで黙々と回していた。22:00(うろ覚え)の長期メンテに入ると同時に学生証が使えなくなり、アイカツスターズの終わりを身をもって受け、やはり武道館までの思い出が巡って、もはや誰もいないゲーセンで閉店まで涙を流した。

f:id:aikiriao:20180910140845j:plain:w300

アイカツフレンズの筐体開始前(3.28)にオリジナルアイカツパスが届いた。これはアイカツスターズで筐体をプレイしていた5000人の人に抽選で配布される学生証みたいなもの。自分はこれに大層喜び、アイカツフレンズに対しても継続していく立場をとった。

f:id:aikiriao:20180910140550j:plain:w300

また無銭にも訪れた。4.28のエアポートウォーク名古屋での無銭に出向き、新しい声優陣の初公演舞台を見ることができた。しかし、パフォーマンスはこれまで見ていた歌唱担当の方たちと比べるべくもないわけで、友人とその会社の同僚で大いに叩いてしまった(2018.9の執筆時点ではかなりの成長を感じている)。また1週間後にラゾーナ川崎プラザでBelieve itがあったそうだが都合がつけられず見れていない。

f:id:aikiriao:20180910140642j:plain:w300

4.28の無銭の後はそのまま宝塚に赴き、テヅカツ!(アイカツ手塚治虫のコラボ)を見に行った。遠かったが、非常に見る価値があった。いちごの部屋を見てただただ立ち尽くしたり、歌唱担当様の衣装を見て感傷に浸っていた。そして初代アイカツ筐体があったので、「思い出は未来の中に」とprism spiralをプレイ。カードを持っていったら、現地の幼女先輩に見ものにされた…が、まだ初代アイカツの記憶が残っていることに感動を覚えた。(幼女先輩が最近初代アイカツの筐体を見なくなったと言っていたのがすごい辛かった)。また、宝塚でアイカツフレンズ筐体の初プレイを経験した。(それまではスターズの喪に服していた)

f:id:aikiriao:20180910140712j:plain:w300

アイカツフレンズのアニメは、端的に言うと執筆時点でも面白いと思っている。キャラの推しができなかったり、強い曲がまだないのが厳しい。しかしアニメのストーリー(執筆時点で言うと19,20話)は初代を彷彿させるものがあり、その部分は本当に嬉しく感じている。周りの反応を書くべきではないかもしれないが、Twitterを見ているとアイカツフレンズからアイカツを見直し始めている人が多く見受けられる(客観性なし)。 (プリチャンは始まる前はプリパラを返してくれとしか思えなかったが、2〜3話で桃山みらいにハマり始めてからはもう何も不安要素がない。)

2018.6.8は遠藤瑠香さんの舞台「レンアイドッグス」を見に行った。アイカツは一切関係ない。しかし、瑠香さんのその後の様子がどうしても見たかった。劇場は驚くほど狭く、100人入れたか入れないかぐらいのキャパしかなかった。しかも舞台は人生で始めて見た。が、非常に脚本が面白く、終始笑い続けていた。瑠香さんは他の演技力の高い人々に囲まれながら、主役の演技をやり抜いていた。ライブステージだけではない、瑠香さんの新しい道を垣間見れた気がした。

f:id:aikiriao:20180910140733j:plain:w300

 この頃には、友人とその会社の同期は何度も元歌唱担当様との接近戦(握手会、お渡し会、チェキ等)をこなしていた。無論認知(顔を覚えてもらうこと)も得ている。執筆時点まで、自分は接近戦は一度もやらなかった。これはおそらく意固地になっているだけで、一回経験してしまえばもう何度も接近戦をやり始めるだろうと思う。でも、これ以上接近するのはアイカツから離れてしまう気がしているし、おそらく今後とも接近戦はないと思う。

2018.7.11。フォトカツの運用終了。フォトカツは初代アイカツの最後のコンテンツ供給源だった。自分は2016の段階で誤ってデータを消去してしまいそれ以降まともにやらなくなっていたが、アカウントは再度作成していた。恐らく、この日をもって初代アイカツのアクティブなコンテンツは終了したと思う。

f:id:aikiriao:20180910140755j:plain:w300

2018.8.18は2度目の無銭がエアポートウォーク名古屋で行われた(8.11には甲府で無銭だったがコミケ参加のため向かえず)。一回目の公演で整理券番号30を確保し、優先観覧エリアの最前に立った。(https://twitter.com/aikatsu_dcd/status/1031017692252127232)。相も変わらず曲数は少ないが、6cm上の景色をfullで聞いたとき、1年前にラクーアで聞いた1,2,3 sing for you!のfullソロに何かを重ね、成長した雰囲気を確かに感じた。確実に成長し、何かが変わり始めている。

f:id:aikiriao:20180910140810j:plain:w300

追記:9.8,9 アイカツ5thフェスティバル @幕張メッセイベントホール(1日目アリーナC2ブロック5, 2日目アリーナB3ブロック85)

9.8はこのフェスで一体何をやるのか、歌唱担当が揃わない今一体何ができるのか不安で仕方がなかった。不安をよそに物販列に並んだ所、6時間の待機を強いられた(9:45列入り、15:52列出)ため、精神的体力的に余裕がなく、余計なことを考えず済んだため却って都合が良かった。

フェスが始まる。出演者紹介のあった後に流れたSHINING LINE*。当然嗚咽する。「もう最後かもしれない…」を通り越し、もう何も考えることができていない。その後にシリーズ毎に生アフレコとトークコーナーがあった。保村真さんのやや無理やりなフリに全員がついていく感じで、面白さはあった。シリーズの入れ替わり時に曲を挟んできたのが大きなダメージになった。lucky train!や1,2,sing for you!、オリジナルスター☆彡が涙無しで見れないのは勿論、Blooming♡Bloomingもfullで打ち込まれたのが辛かった。歌唱担当の皆様のパフォーマンスは、やっぱり高いのだ(もはや書くに値しないが、当然カレンダーガール(わかさんソロ)で大号泣している)。

その後は夢のような時間が続いた。M4の僕らの奇跡や、アリスブルーのキスは、ようやく実現できたんだと嬉しくなった。Passion flower(みほさんと斎藤綾さん)、MY SHOW TIME!(ななせさんと高田憂希さん)、The only sun light(日笠陽子さん)、硝子ドール(沼倉愛美さん)…。きっと、誰もが一度はやってほしいものだったと思う。

そして、自分には、これを以て歌唱担当様から声優へのバトンタッチとするとのメッセージとしか思えなかった。アイカツは歌唱担当ありきでここまでやってきていた。歌唱担当に声優を使うことは、歌唱担当の存在意義が脅かされる。これで、何もかもが、他コンテンツと同一という元の鞘に収まった…。それを直感してから、もう席で泣いていることしかできなかった。ああ、自分の大好きだったアイカツは本当はとっくに終わっていたんだなあ、武道館で全て終わっていたんだなあと思うことしかできなかった。

初めてダイバーシティ東京に行ったとき、声優との区別すらついてなかった自分が、歌唱担当の存在を知って、ここまで好きになるとは思っていなかった。そして今、歌唱担当が失われたことが改めて実感されて非常に辛い。

その後はアイカツフレンズの曲が一旦入った。Believe itは当然好きだし、6cm上の景色は最近とみに評価し始めている。しかしコールを打つのが初めてだったからなのか、若干突き抜けなかった。しかしこれらの曲には未来があるので、その先で存分に盛り上がることができると信じている。

Pretty Prettyで下地紫野さんが出てきたときにガッツポーズした(下地紫野さんがふうりさん並に小さくて驚いている)。これもずっとやってもらいたかった要素の一つ。そして、この曲はこれで完成したと言えるだろう…と思っていたらすかさずSTART DASH SENSATION(るかさんと下地紫野さん)が打ち込まれた。無論泣いてばかりいたが、この曲の2番が大変だった。この曲の2番といえば氷上スミレちゃんに対するメッセージが込められているが、今回は…歌唱担当から声優へのメッセージになっていたの理解した。カメラワークがえげつないので、映像化が待たれる。既に限界となりながらも素早く輝きのエチュード(るかさんと諸星すみれさん)が入る。驚いたのは、諸星すみれさんの歌唱力。アイカツフレンズで歌唱を行うことのなかったすみれさんが、堂々と歌っていた。そして舞台には、わかさんと諸星すみれさんに加え、いちごちゃんがスクリーンに映し出されていた。個人的に大好きなアイカツ回「ドッキドキ!!スペシャルライブ」が映し出され、感極まった。

最後はダイヤモンドハッピーからのアイドル活動。盛り上げて終わらせてくれるのがありがたく、アイドル活動では出演者全員が出てきていた。アンコールはなかったが、充実感があり、上述の歌唱担当から声優へのバトンという告知を理解してからは、もう何も頑張らなくて良いという開放感に包まれていた。

2日目(2018.9.9)

9.9の朝はもなさんのソロライブを見に行った。これは友人の機転によるもの。久しぶり(コミケ以来?)に見たもなさんは確かな輝きがあった。しかしその輝きは、るかさんのようなアイドルとしての輝きではなく、真にボーカリストとしての輝きになっていたと思う。歌唱力については言うまでもなく良い。陳腐な表現で申し訳ないが、優しい声質はそのままに、MF2016のときと比べ表情と言うか、表現力が確かに上がっていたと思う。確かな進歩が見られる機会だった。

もなさんのライブ後、急ぎ幕張に戻って2日目の公演へ。2日目の記述に関して、大雑把に言ってしまえば、内容と思ったことは上記初日とほぼ同様である。何を伝えたいのかは9.8の公演でほぼ明らかになったので、開演前の心は穏やかだった。

しかし序盤、Music of Dream!!!がfullで打ち込まれ、自分はそこで嗚咽し始める。恐らく武道館でやられた人が多いと思われるこの曲は、自分は武道館でやられることがなかったが、この2日目の公演で、もう最後なんだと思い、嗚咽が止まらなくなった。

大枠のセトリに大きな変更はなかったが、Presious(りすこさんと寿美菜子さん)、dreaming bird(ななせさんと上田麗奈さん)、アイドル活動!ver.Rock(石原夏織さん)があり、何より個人的に嬉しかったのは薄紅デイトリッパー関根明良さん)。やるとは微塵とも思っておらず、思わず頭を抱えた。

また個人的に大評価していた「Girls be ambitious!」をfullでやってもらえたのが嬉しかった(DigzのSHOWさん好きなのが明らかである)。

2日目が終わった後は、友人は帰りを急ぐために席で別れた。その後一人でしばらく嗚咽し、寸分考えた後に、アイカツが終わったなあという実感が湧いてきていた。駅の混雑を嫌い、散歩がてら新習志野駅までのんびり歩いていたら、その日京葉線が終日運休となったため、そこから津田沼までバスに乗り、東京に出て帰った。一人でのんびり考える内に、このブログを更新する必要があると思い、頭の中でとりとめもなく整理し始めた。

このフェスを通じて、アイカツの歌唱担当から声優へのバトンが渡されたと思う。それに加え、アイカツを見ている人も世代交代なのかもしれない。初代アイカツ曲に反応できていたひとはいくばくかだろうか。自分はアリーナに居たが、少なかったのではなかろうか。これからは声優一筋の時代が来る。それはアイカツ以外のコンテンツが辿っている道と全く同様で、盛り上がっていくだろう。しかし自分はそこにいない気がしている。

ここまでで、アイカツの第一部が終了したと思う。振り返って見ると半分以上泣いてばっかりだったが、これまでに十分にアイカツには感動をもらっている。このように自身の考え方に作用するアニメ(コンテンツ)は当然珍しく、少なくとも向こう10年は現れる気がしない。アイカツ(フレンズ)がこれから面白くなるかどうかは全くわからない。無銭はこれからの成長を期待して見ていきたい。筐体は8月が忙しすぎて1ヶ月空けてしまった。再開するかどうかはわからない。

追記:2018.11.7 仙台GIGSでのライブ後

2018.11.4に、Run Girls, Run!の1stライブを見に仙台に赴いた。なぜ行くことになったのかは、キラッとプリチャンオータムライブ(2018.9.29 @中野サンプラザ)で見送りを経験した影響が全てである。。。

1月のツアー以来の仙台。居ても立ってもいられず、イズミティを見に行った。

f:id:aikiriao:20181108002336j:plain:w300

そこにはかつて追いかけていた眩しさや楽しさはなく、どうしようもなく佇むしかなかった。

思ってみればアイカツ多角化するコンテンツの覇者だった。アニメ、ゲーム、楽曲、ライブ、イベント、同人、全てが一級品だった。このような全てが品質高く収まっているジャンルは奇跡に近く、どうも意図的に作れるものではないと直感している。

自分はそんなアイカツが大好きだった。141話でリアルタイム開始の新参もいいところだが、何もかもをまっすぐに楽しませて貰った。放送終了後からはずっと泣いてばかりいる。今に至るまで自分に突き刺さり続けるジャンルは、少なくとも向こう10年は存在し得ないだろう。

…5thイベントを通じ、このアイカツがどうしようもなく終わったと感じざるを得ず、今は他のコンテンツを探し始めている。その折にプリチャンに出会った。今はプリチャンに重心を移しつつある。

これからはアイカツから完全に離れるのは不可能だと思うが、アクティブに受け取るものはプリチャンが多くなる可能性が大きい。全ての決着がつくのがアニメJAM2018となりそうだ。

アニメJAM2018まで

アニメJAMまでに、色々なイベントを挟むことで自分の方針が決まっていった。

2018.11.10は品川ステラボールでRGR 1stの東京公演。人が埋まることはないが、やはり確かなパフォーマンスと、MC力を感じている。非常に驚いたのは林鼓子さんの「eternal blaze」。少なくとも自分には明るい未来が見えた。ほぼ、プリチャンに傾くことを決め、さらにはRGRのイベントを見ていきたいと感じる。

2018.11.17,18はスカイツリーで『「キラッとプリ☆チャン」がネットルール安全教室やってみた!』を見る。イベント自体は30分程度で終わるものであったが、演者を見たときの多幸感が拭えない。

この時点で、これ以上書くことはない程に方針が決まってしまった。非常に簡単なことで、会えば堕ちるだけの話だったのだ。おまけにRGRはパフォーマンスが高い。自分の中で、曇りなく推していける土壌が急激に形成されていった。つまり、RGRのラジオやCDを聞くようになり始めた。

2018.11.23はラクーアにおけるアイカツフレンズの無銭。新PR衣装の公開があり、しかも当時の楽曲を余すところなく歌唱してもらった。アイカツフレンズとしては非常に満足感の高いライブだった。特に印象的だったのは二宮さんの成長。歌唱力が5thと比べて明らかに伸び、ダンスにおいてもダイナミックさが出るようになっていた。

その後のMia REGINA無銭は非常に素晴らしかった。3人でありながらステージを広々と使い、しかも歌唱はハミングハモリ自由自在。アイカツから解き放たれた、プロとしてのミュージシャンのパフォーマンスを堪能できた。

2018.12.9は幕張メッセで『み〜んなでキラッとプリティーライブ2018』。プリティーシリーズ総体として、最大規模のライブを打ってきた。メッセの平らな開場をひたすらにトロッコで演出していたのが印象的だった。直前で見ていたオーロラドリームの「Dream goes on」がどうしても刺さった。RGRの皆様のパフォーマンスは大きな会場でも健在。また、プリチャン単独でも「SUPER CUTIE SUPER GIRL」や「COMETIC SILHOUETTE」等の強い曲が次々と打ち込まれ、inst.を文字通り享楽していたら楽曲が終わってしまう状態だった。

このライブで何よりも嬉しいと感じたのはプリチャン2期の発表である。もう、これだけ見ていけば良いという安心感が自分の中で確定した。並びに、これが間違いのない決定打となり、プリチャンを中心に見ていく事になった。続く2018.12.15はプリチャン2ndのリリースイベントに参加している。芹澤さんのトーク力に驚かされた。

追記:2018.12.23 アニメJAM2018

アイカツとプリチャンが同じステージに立つのはアニメJAM2018がはじめての筈で、自分にとっては同じ舞台でライブすることで両コンテンツの比較を行うつもりで赴いた。

が、上記のとおり状況は既に極まり、内心プリチャンに重心を移すことを決定し、ライブは追試のつもりで観察する予定となっていた。

イベント前半ではクイズ大会。前半戦のトークではやはり芹澤さんの存在感が大きい。大物の風格が既に現れており、今後さらに大きなステージに行けることを予感させられていた。さらに久保田さんがツッコミに入り、プリチャン内部で十分に笑いが取れる状況。アイフレは…。いや、もう語るのはやめよう。

ライブステージでは、凄惨な比較となってしまった。LiaさんやZAQさん、そして松本梨香さんといった実力派、WUG(初めて見た…女性ファンの多さと一体感に驚かされる)、iRis、わーすた…。これらのライブパフォーマンスと見比べると、どうしても、どうしても、曲・歌唱・ダンス・コール全面で学芸会に見えてしまう大好きだったジャンルが非常に辛く、自分は泣いた。もう一年アイスタがやってくれるか、もしくはアニメJAM2017でアイスタが出てくれれば…。瑠香さんならばこの場に一石を投じることができるのに、できない現実があまりにも辛い。

そして、アイカツから急激に心が離れていく自分を見たときに、これ以上アイカツのイベントに参加することはできないと思った。ランティス祭り2019でメンバーは出てくるが、それは懐古にしかならないことが見えているため、行かないことに決めた。

上記の事情があるため、私のアイカツを追いかけた道はこれで閉ざされてしまった。振り返りについては筆を置き、2019年はRGRを追いかけていくつもりである。

2020.8.10 アイカツプラネット発表会

これまでの間非常に色々なことがあった。 2019.8.17で受けた過去向きすぎる動きに対して怒り、アイカツとは距離を取ることに決めていた。それ以降アニメは見れていない。

今日、新シリーズ発表の動画が偶然目に止まった。動画を見たらかなり考えが変わったので、その記録だけする。

新シリーズの演者のパフォーマンスがとても良いことがわかった。自分はどうやらライブパフォーマンスを重視しているようで、その一点において良いと思えたのがかなり強い。

あとは脚本やら作編曲やら細かいが本質的な要素が求められてしまう…が、少なくとも、 「現地で満足できそう」という一点において品質が担保されていることは個人的には非常に嬉しかった。

来年以降、現地で盛り上がれることを期待したい。新シリーズは見ていきたい。

x86(i386)向けのOS作成日記 - タイマ1

2017.12.3

プリキュアを見た。面白い。今日はアイカツイリュージョンライブの2日目にも参加するため、横浜のコメダで作業。

だいぶ遅れたけど、EFLAGSCR0のビットフィールドをまとめる。レジスタが綺麗にまとまっていた。

EFLAGS

EFlagsレジスタ 全32bitで構成されれるレジスタで、各種演算結果、制御フラグ、システムフラグなどが格納される。

S ステータスフラグを表す。 addやsubなどの演算結果の状態を表す。 C 制御フラグを表す。 制御フラグは、bit10のDFのみに該当する。 X システムフラグを表す。 OSやアプリケーションの動作を制御する。 このフラグはアプリケーションが変更してはいけない。 予約 干渉してはいけない領域。セットするときは、必ず読み込んだ値をセットすること。

bit 種別 Flag 名前 説明 関連命令
0 S CF Carry Flag キャリーフラグ 最上位ビットでキャリーかボローが生じたときに1がセットされる。 stc, clc, cmc
1 1 予約
2 S PF Parity Flag パリティフラグ 演算結果の最下位バイトで、値が1のビットが偶数個なら1がセットされる。
3 0 予約
4 S AF Auxiliary Carry Flag 補助キャリーフラグ ビット3でキャリーかボローが生じたときに1がセットされる。BCD演算で使用する。
5 0 予約
6 S ZF Zero Flag ゼロフラグ 演算結果が0のとき1がセットされる。
7 S SF Sign Flag 符号フラグ 演算結果の最上位ビットがそのままセットされる。
8 X TF Trap Flag
9 X IF Interrupt Enable Flag 割り込み許可フラグ 1のときは割り込みを許可し、0なら割り込みを禁止する。 sti, cli
10 C DF Direction Flag 方向フラグ ストリング命令を上位に向かって処理(0)するか、下位に向かって処理(1)するかを制御する。 std, cld
11 S OF Overflow Flag オーバーフローフラグ 最上位ビットが変化した場合に1がセットされる。
12 X IOPL I/O Privilege Level I/O特権レベル
13
14 X NT Nested Task Flag
15 0 予約
16 X RF Resume Flag
17 X VM Virtual-8086 Mode 仮想8086モード
18 X AC Alignment Check アライメント・チェック このフラグとCR0のAMフラグを1にセットすると、アライメント・チェックが有効になる。有効にすると、CPLが3のときのみアライメント・チェック例外を発生させることができる。
19 X VIF Virtual Interrupt Flag
20 X VIP Virtual Interrupt Pending
21 X ID Identification Flag 識別フラグ このビットを変更することができれば、CPUID命令を実行することができる。
22-31 0 予約

CR0

bit Flag 名前 説明
0 PE Protect Enable プロテクトモードを有効にする。
1 MP Monitor Coprocesser
2 EM Emulation
3 TS Task Switch
4 ET Extension Type 拡張タイプ。最近のCPUでは、1で予約されている。
5 NE Numerical Error
6-15 予約
16 WP Write Protect
17 予約
18 AM Alignment Mask このフラグとEFLAGSのACフラグを1にセットすると、アライメント・チェックが有効になる。有効にすると、CPLが3のときのみアライメント・チェック例外を発生させることができる。
19-28 予約
29 NW Not Write through
30 CD Cash Disable
31 PG Paging 1にセットすると、ページングを有効にする。PEフラグ(CR0-0)がセットされていないと、このフラグも有効にならない。

今日はまずメモリ管理を双方向リストではなく、線形リストに置き換えられないか検討する。 その後PITに触れていく。

メモリ管理構造体の線形リスト化

双方向リストにしてしまったのでめちゃくちゃ複雑になっている。もっと簡単に出来るはず。 →線形リストにした。おまけに、ハンドルを引数に操作するAPIを追加した。(システムはstaticなメモリ管理構造体を暗黙で使用する)

2017.12.16

12.9は大洗、12.10はプリパラwinter live、12.11は有給で満喫。

大洗は例のごとくあんこう鍋目当てで行ったけど、最初(2016年冬)に行った旅館が一番うまかったので合意。観光としては水族館に行ったり(水しぶきが凄い)、海を見たり(水平線が盛り上がって見えるのが大変綺麗)、海鮮市場でいいだけうまいものを食べたり(あんこう汁が一番うまかったかも。次いで磯前神社の道の向かいにある食道での生しらす丼か)。

プリパラwinter liveは、今年トップクラスに面白かった。メイキングドラマをほとんど省いて高速で曲が打ち込まれ、2時間半程度で32曲も出してきたのだ。。。WITHの盛り上がりは素晴らしいし、夢川ゆいちゃんはかわいいし、ノンシュガーは凄いし。。。いよいよプリパラに傾くときが来たのか。

PITによるタイマモジュール実装

タイマは最初から線形リストでの実装を行う。つまり、最も近いタイムアウト順に並べたキューを作成する。

#include "defines.h"
#include "asmfunc.h"
#include "interrupt.h"
#include "fifo.h"

/* PIT(Programmable Interval Timer)の設定ポート */
#define PIT_CONTROL                     0x0043
#define PIT_COUNT0                      0x0040

/* 8254の動作周波数=1193180Hz */
#define I8254_CLOCK_HZ                  1193180

/* 同時に管理可能なタイマの最大数 */
#define MAX_NUM_TIMER                   500                  /* ユーザが使用可能なタイマ数 */
#define MAX_NUM_INTERNAL_TIMER          (MAX_NUM_TIMER + 1)  /* システムが使用するタイマ数; 番兵の分を追加 */

/* タイマ管理モジュールの状態ビット */
#define TIMERCONTROL_FLAGS_INITIALIZED  (1 << 0) /* 初期化済みか? */

/* タイマの状態フラグビット */
#define TIMER_FLAGS_ALLOCED             (1 << 0) /* 領域が確保されているか? */
#define TIMER_FLAGS_WAITFORTIMEOUT      (1 << 1) /* タイムアウト待ち状態か? */

/* タイムアウトカウントの無効値 */
#define TIMER_INVALID_TIMEOUT_VALUE     0xFFFFFFFFFFFFFFFF

/* タイマの線形リスト */
struct Timer {
  struct Timer*   next;
  uint64_t        timeout;  /* タイムアウトまでのカウント */
  uint32_t        flags;    /* 状態フラグ */
  struct FIFO32*  fifo;     /* FIFO */
  uint32_t        data;     /* タイマを識別するデータ */
};

/* タイマ管理構造体 */
struct TimerControl {
  uint8_t         flags;                              /* 状態フラグ   */
  uint64_t        timer_count;                        /* カウント */
  uint32_t        timer_count_period_ms;              /* カウントの上昇周期[ms] */
  struct Timer*   timer_top;                          /* タイマリスト先頭 */
  struct Timer    timer_list[MAX_NUM_INTERNAL_TIMER]; /* タイマの領域 */
};

/* システムが管理するタイマ */
static struct TimerControl st_system_timer_control;

/* PITの割り込みハンドラ */
void pit_inthandler(int *esp)
{
  struct Timer*        p_timer;
  struct TimerControl* timerctl = &st_system_timer_control;

  /* 割込み完了を通知 */
  pic_pit_eoi();

  /* タイマのカウンタを更新 */
  timerctl->timer_count++;

  /* 次のタイムアウトまでは何もしない */
  if (timerctl->timer_count < timerctl->timer_top->timeout) {
    return;
  }

  /* タイムアウト時間を過ぎたタイマをまとめてタイムアウト */
  for (p_timer = timerctl->timer_top;
       p_timer->timeout <= timerctl->timer_count;
       p_timer = p_timer->next) {
    p_timer->flags &= ~TIMER_FLAGS_WAITFORTIMEOUT;
    FIFO32_PutData(p_timer->fifo, p_timer->data);
  }

  /* 先頭を更新 */
  timerctl->timer_top = p_timer;

}

/* タイマモジュール初期化 */
void TimerControl_Initialize(struct TimerControl* timerctl)
{
  uint32_t i_timer;
  struct Timer* timer_sentinel_p;
  
  /* 初期化済みの場合は何もせず即時リターン */
  if (timerctl == NULL
      || (timerctl->flags & TIMERCONTROL_FLAGS_INITIALIZED)) {
    return;
  }
  
  /* タイマ管理構造体を初期化 */
  timerctl->timer_count           = 0;
  timerctl->flags                 = 0;
  timerctl->timer_count_period_ms = 0; /* (仮) */

  /* 全タイマを初期化 */
  for (i_timer = 0; i_timer < MAX_NUM_INTERNAL_TIMER; i_timer++) {
    struct Timer* p_timer = &(timerctl->timer_list[i_timer]);
    p_timer->timeout = 0;
    p_timer->flags   = 0;
    p_timer->fifo    = NULL;
    p_timer->data    = 0;
  }

  /* 番兵を立てる */
  timer_sentinel_p = &(timerctl->timer_list[0]);
  timer_sentinel_p->timeout            = TIMER_INVALID_TIMEOUT_VALUE; /* タイムアウトは無効値 */
  timer_sentinel_p->flags             |= (TIMER_FLAGS_ALLOCED | TIMER_FLAGS_WAITFORTIMEOUT);
  timer_sentinel_p->next               = NULL;                        /* 必ず末尾 */

  /* 番兵を先頭にセット */
  timerctl->timer_top          = timer_sentinel_p;
  
    /* 初期化フラグを立てる */
  timerctl->flags |= TIMERCONTROL_FLAGS_INITIALIZED;
  
}

/* タイマモジュール終了 */
void TimerControl_Finalize(struct TimerControl* timerctl)
{
  uint32_t i_timer;

  /* 終了済みならば即時リターン */
  if (timerctl == NULL
      || !(timerctl->flags & TIMERCONTROL_FLAGS_INITIALIZED)) {
    return;
  }

  /* 全タイマを初期化 */
  for (i_timer = 0; i_timer < MAX_NUM_INTERNAL_TIMER; i_timer++) {
    struct Timer* p_timer = &(timerctl->timer_list[i_timer]);
    p_timer->timeout = 0;
    p_timer->flags   = 0;
    p_timer->fifo    = NULL;
    p_timer->data    = 0;
  }

  /* 初期化フラグを落とす */
  timerctl->flags &= ~TIMERCONTROL_FLAGS_INITIALIZED;
}

/* システムタイマモジュール終了 */
void SystemTimerControl_Finalize(void)
{
  TimerControl_Finalize(&st_system_timer_control);
}

/* システムタイマモジュール初期化 */
void SystemTimerControl_Initialize(uint32_t timer_interval_ms)
{
  /* 
   * 設定カウント値countの計算
   * 設定カウント値countと実際の割込み頻度f[Hz]は次の式を満たす:
   * f = I8254_CLOCK_HZ / count
   * よって count = I8254_CLOCK_HZ / f
   */
  uint16_t count = (I8254_CLOCK_HZ * timer_interval_ms) / 1000;

  /* 割込み周期設定 */
  io_out8(PIT_CONTROL, 0x34);
  io_out8(PIT_COUNT0,  count & 0xFF);         /* カウント値の下位8bit */
  io_out8(PIT_COUNT0,  (count >> 8) & 0xFF);  /* カウント値の上位8bit */

  /* システムのタイマ管理構造体を初期化 */
  TimerControl_Initialize(&st_system_timer_control);

  /* カウント周期を保存 */
  st_system_timer_control.timer_count_period_ms = timer_interval_ms;

  /* PITの割込み許可 */
  pic_pit_enableint();
}

/* 新規にタイマを割り当て */
struct Timer* TimerControl_AllocTimer(struct TimerControl* timerctl)
{
  uint32_t i_timer;

  /* モジュール初期化前は割り当て禁止 */
  if (timerctl == NULL
      || !(timerctl->flags & TIMERCONTROL_FLAGS_INITIALIZED)) {
    return NULL;
  }

  /* 割り当て済みでないタイマを探す */
  for (i_timer = 0; i_timer < MAX_NUM_INTERNAL_TIMER; i_timer++) {
    struct Timer* p_timer = &(timerctl->timer_list[i_timer]);
    
    if (!(p_timer->flags & TIMER_FLAGS_ALLOCED)) {
      p_timer->flags |= TIMER_FLAGS_ALLOCED;
      return p_timer;
    }
  }

  /* 見つからなかった */
  return NULL;
}

struct Timer* SystemTimerControl_AllocTimer(void)
{
  return TimerControl_AllocTimer(&st_system_timer_control);
}

void TimerControl_SetTimeout(struct TimerControl* timerctl, struct Timer* timer, uint64_t timeout)
{
  uint32_t eflags;
  struct Timer* p_timer;

  /* 引数チェック. 0カウント後のタイムアウトは許容しない */
  if (timer == NULL || timeout == 0) {
    return;
  }

  /* タイマ管理構造体からの相対時間でタイムアウトを設定 */
  timer->timeout = timeout + timerctl->timer_count;
  
  /* EFLAGSを退避 */
  eflags = io_load_eflags();
  /* 割り込み禁止 */
  io_cli();

  /* リストの先頭に入れる */
  if (timer->timeout <= timerctl->timer_top->timeout) {
    timer->next                  = timerctl->timer_top;   
    timerctl->timer_top          = timer;
    goto EXIT;
  }

  /* リストの挿入位置を探索 */
  for (p_timer = timerctl->timer_top;
       p_timer->next != NULL;
       p_timer = p_timer->next) {
    if (timer->timeout > p_timer->timeout
        && timer->timeout <= p_timer->next->timeout) {
      timer->next = p_timer->next;
      p_timer->next = timer;
      goto EXIT;
    }
  }
  
EXIT:
  /* 待ち状態にセット */
  timer->flags  |= TIMER_FLAGS_WAITFORTIMEOUT;  
  /* EFLAGSを復帰 */
  io_store_eflags(eflags);
}

void SystemTimerControl_SetTimeout(struct Timer* timer, uint64_t timeout)
{
  TimerControl_SetTimeout(&st_system_timer_control, timer, timeout);
}

/* タイマを未割り当て状態に */
void Timer_Free(struct Timer* timer)
{
  if (timer == NULL) {
    return;
  }

  /* 一旦破棄したタイマが再割り当て後に即時に動き始めるのを防ぐため、
   * タイムアウト待ち状態フラグも落とす */
  timer->flags &= ~(TIMER_FLAGS_ALLOCED | TIMER_FLAGS_WAITFORTIMEOUT);
}

void Timer_Initialize(struct Timer* timer, struct FIFO32* fifo, uint32_t data)
{
  if (timer == NULL) {
    return;
  }

  timer->fifo = fifo;
  timer->data = data;
}

メモリモジュールの時と同じく、システム用のタイマ構造体をstaticに確保している:

/* システムが管理するタイマ */
static struct TimerControl st_system_timer_control;

システムとしては、このstaticなタイマ管理構造体を介して処理を行う。 他は自作OS本と比べて目新しい所は無いかも…番兵を立てた線形リストが分かりやすいし、簡潔だし、それなりに早いので…。

今日は案外早くキリが付いた。残件としては、

  • システムが使用するFIFOの共通化
  • →少し重め。新しくヘッダを切って(もしくはdefines.hか?)、どの整数番号がどのメッセージに該当するのか特定できるようにすべし。
  • もしくは、メッセージキューを作る?←最終的にこっちに持っていきたい。メッセージタイプとその実体(union)からなる構造体。
  • マウスとキーボードデータのデコード
  • →こっちをやる。
  • やってて気付いたけど、デコードしたデータをFIFOに載せる事を考えると、やっぱりFIFOでメッセージを飛ばしたくなる。上の対応がなるべく早く求められる。
  • マウスのデコーダはやっつけ実装。
  • キーボードは、コードから文字の変換テーブルだけ作成。まだled(CapsLock, NumLock, ScrollLock)とかに対応できていない。344p周辺を読まねば。
  • テストでポート入出力命令を使えるようにする
  • コンソールのテストを行うのに必須。擬似的にやれないか探る。
  • io_in系は内部的なFIFOを使うのが良さそう。予めinされる予定のデータをFIFOに詰めておいて、io_inを呼び出すと順番に出てくるイメージ。
  • io_out系は関数ポインタが良さそう。データ毎に場合分けをした処理を行う。関数ポインタを書き換えることで対応を変える。

メッセージキューの置き換えまでできたら、次はマルチタスクか。実際着手できるのはいつになるのか…

x86(i386)向けのOS作成日記 - メモリマネージャ2

2017.11.19

今日はメモリマネージャを実装したい。(上記1,2,3の調査はやりたいけど資料を持ってくるのを忘れた...) 最初は本の通りに実装するけど、やっぱり線形リストに実装し直したい。

リストの除外操作が含まれるので、やっぱり双方向リストにする。

2017.11.21

メモリ操作のデバッグが辛すぎるので、開発効率を上げるためにも簡易テストモジュールを作った。 github.com

2017.11.23

勤労感謝の日。 簡易テストモジュール自体を修正しながらメモリ管理のテスト。双方向リストで書き直してみた。 結果汚くなってしまった感触が…。また、テーブルサイズも増えた…。

/* メモリ空き情報(双方向リスト) */
struct MemoryFreeInfo {
  struct MemoryFreeInfo *next; /* 次の情報 */
  struct MemoryFreeInfo *prev; /* 前の情報 */
  uintptr_t address;           /* 空きの開始アドレス */
  uintptr_t size;              /* 空きサイズ        */
};

/* メモリ管理構造体 */
struct MemoryManager {
  uint32_t flags;                  /* 各種状態フラグ */
  uint32_t num_free;               /* 空き情報個数 */
  uint32_t max_num_free;           /* 現在までの最大空き情報数 */
  uint32_t lostsize;               /* メモリ管理から外れたサイズ */
  uint32_t num_losts;              /* メモリ管理から外れた空き情報数 */
  struct MemoryFreeInfo *free_top; /* 空き情報リスト先頭 */
  struct MemoryFreeInfo free_info[MEMORY_MANAGER_MAX_NUM_FREEINFO];
                               /* 空き情報のメモリ領域 */
};

/* 常識的に考えてメモリ管理構造体は一つしかないはず */
/* スタティック変数で割りあてる */
static struct MemoryManager st_memory_manager;

確保ルーチン。配列をリストに置き換えた位でさしたる変化なし。

/* メモリ確保 */
void* MemoryManager_Alloc(uintptr_t size)
{
  uintptr_t addr;
  struct MemoryFreeInfo *p_free;

  /* 初期化前ならばNULLを返す */
  if (!(st_memory_manager.flags & MEMORY_MANAGER_FLAGS_INITIALIZED)) {
    return NULL;
  }

  /* サイズ0を要求してもNULL */
  if (size == 0) {
    return NULL;
  }

  /* 最初に見つけた空き領域に割り当てる
   * これはアルゴリズムを考察しても良いかも */
  for (p_free = st_memory_manager.free_top;
       p_free != NULL;
       p_free = p_free->next) {
    if (p_free->size >= size) {
      /* 十分な大きさの空きを発見 */
      addr = p_free->address;
      /* 空き情報を更新 */
      p_free->address += size;
      p_free->size    -= size;
      /* サイズがなくなったのでリストを前に詰める */
      if (p_free->size == 0) {
        st_memory_manager.num_free--;
        /* リストから要素を除外 */
        if (p_free == st_memory_manager.free_top) {
          st_memory_manager.free_top = p_free->next;
      if (st_memory_manager.free_top != NULL) {
        st_memory_manager.free_top->prev = NULL;
      }
        } else {
          p_free->prev->next = p_free->next;
      if (p_free->next != NULL) {
        p_free->next->prev = p_free->prev;
      }
        }
        /* 空き情報を無効化 */
        p_free->next    = NULL;
    p_free->prev    = NULL;
        p_free->address = 0;
      }
      return (void*)addr;
    }
  }

  return NULL;

}

領域解放ルーチン。条件判定はもしかしたら冗長かも。

/* 領域の解放 */
int32_t MemoryManager_Free(uintptr_t address, uintptr_t size)
{
  struct MemoryManager  *memman = &st_memory_manager;
  struct MemoryFreeInfo *p_free, *p_insert;
  
  /* 初期化前ならば失敗 */
  if (!(memman->flags & MEMORY_MANAGER_FLAGS_INITIALIZED)) {
    return -1;
  }
  
  /* サイズ0の登録は許容しない */
  if (size == 0) {
    return -2;
  }

  /* 初回時は、リストを生成して終了 */
  if (memman->free_top == NULL) {
      p_free           = &memman->free_info[0];
    p_free->address  = address;
    p_free->size     = size;
    p_free->next     = NULL;
    p_free->prev     = NULL;
    memman->free_top = p_free;
    memman->num_free++;
    return 0;
  }

  /* アドレス順に整列させるため、挿入位置を探索 */
  for (p_insert = memman->free_top;
       p_insert->next != NULL; 
       p_insert = p_insert->next) {
    if (p_insert->address > address) {
      break;
    }
  }

  /* リストに1つの要素しかない時の判定 */
  if (p_insert->prev == NULL && p_insert->next == NULL) {
    if (p_insert->address + p_insert->size == address) {
          p_insert->size += p_insert->size;
      return 0;
    } else if (address + size == p_insert->address) {
      p_insert->address = address;
      p_insert->size    += size;
      return 0;
    }
  }

  /* p_insert->prev->address < address < p_insert->address */

  /* 前の空き領域と纏められるかチェック */
    if (p_insert->prev != NULL
      && p_insert->prev->address + p_insert->prev->size == address) {
      /* 前の空き領域と纏められる */      
      p_insert->prev->size += size;
        if (address + size == p_insert->address) {
          /* 後ろも纏められる */
          p_insert->prev->size += p_insert->size;
          /* p_insertの要素を削除 */
      p_insert->address    = 0;
      p_insert->size       = 0;
          memman->num_free--;
      if (p_insert->prev != NULL) {
        p_insert->prev->next = p_insert->next;
      }
      if (p_insert->next != NULL) {
        p_insert->next->prev = p_insert->prev;
      }
      p_insert->prev       = NULL;
      p_insert->next       = NULL;
        }
      /* 成功終了 */
      return 0;
    }

  /* 後ろの空き領域と纏められるかチェック */
    if (address + size == p_insert->address) {
      /* 後ろと纏められる */
      p_insert->address = address;
      p_insert->size   += size;
      return 0;
    }

  /* 前にも後ろにも纏められない */
  if (memman->num_free < MEMORY_MANAGER_MAX_NUM_FREEINFO) {
    uint32_t i_free;
    
    /* 新しい単独の空き情報要素を探索 */
    for (i_free = 0; i_free < MEMORY_MANAGER_MAX_NUM_FREEINFO; i_free++) {
      p_free = &st_memory_manager.free_info[i_free];
      if (p_free->prev == NULL 
        && p_free->next == NULL
        && p_free->address == 0
        && p_free->size == 0) {
      break;
      }
    }

    /* 末尾まで達してしまった -> 失敗 */
    if (i_free == MEMORY_MANAGER_MAX_NUM_FREEINFO-1) {
      return -2;
    }

    /* 新しい単独の空き情報を作成 */
    p_free->address = address;
    p_free->size    = size;

    /* リストに追加 */
  p_free->next   = p_insert->next;
  p_insert->next = p_free;
  p_free->prev   = p_insert;

    /* 空き情報の最大数を更新 */
    memman->num_free++;
    if (memman->max_num_free < memman->num_free) {
      memman->max_num_free = memman->num_free;
    }

  return 0;
  }

  /* 後ろにずらせなかった -> 失敗 */
  memman->num_losts++;
  memman->lostsize += size;
  return -4;
  
}

x86(i386)向けのOS作成日記 - メモリマネージャ1

芸カ参加。サークル参加者に欠席多し、一般参加者も減っている感触。それを受けたのか分からんが次回開催は蒲田らしい。

現在はメモリ管理マネージャを実装中。最初はメモリ領域テストから:

#define EFLAGS_AC_BIT     0x00040000
#define CR0_CACHE_DISABLE 0x60000000

/* start - end間で使用可能なメモリサイズを計測 */
static uintptr_t memory_testsize(uintptr_t start, uintptr_t end);

uintptr_t Memory_Test(uintptr_t start, uintptr_t end)
{
  uint8_t is_486flag = 0;
  uint32_t eflags, cr0;
  uint32_t memory_size;

  /* 386 / 486以降なのかの判定 */
  eflags = io_load_eflags();
  eflags |= EFLAGS_AC_BIT;   /* ACビットを立てる */
  io_store_eflags(eflags);

  /* 386ではAC=1としても元に戻ってしまう */
  eflags = io_load_eflags();
  if ((eflags & EFLAGS_AC_BIT) != 0) {
    is_486flag = 1; /* フラグが立っていたら486 */
  }

  /* ACビットをクリア */
  eflags &= ~EFLAGS_AC_BIT;
  io_store_eflags(eflags);

  /* キャッシュ禁止 */
  if (is_486flag != 0) {
    cr0 = load_cr0();
    cr0 |= CR0_CACHE_DISABLE;
    store_cr0(cr0);
  }

  /* メモリサイズ計算サブルーチン呼び出し */
  memory_size = memory_testsize(start, end);

  /* キャッシュ許可 */
  if (is_486flag != 0) {
    cr0 = load_cr0();
    cr0 &= ~CR0_CACHE_DISABLE;
    store_cr0(cr0);
  }

  return memory_size;
    
}

static uint32_t memory_testsize(uint32_t start, uint32_t end)
{
  uintptr_t i, *p;
  uint32_t tmp_old;
  uint32_t pattern     = 0xAA55AA55; /* 書き込み確認するパターン */
  uint32_t pattern_rev = ~pattern;   /* パターンのビット反転    */

  /* 4KBずつ走査 */
  for (i = start; i <= end; i += 0x1000) {
    p   = (uintptr_t *)(i + 0xFFC); /* 4KBの内、末尾4バイトを見る */
    tmp_old = *p;                   /* 前の値を保存 */
    *p  = pattern;                  /* パターンで書き込む */
    *p  ^= 0xFFFFFFFF;              /* それを反転して代入 */
    if (*p != pattern_rev) {        /* 反転結果と一致するか? */
      *p = tmp_old;                 /* しなければ元に戻して終了 */
      break;
    }
    *p  ^= 0xFFFFFFFF;              /* もう一度反転 */
    if (*p != pattern) {            /* 元に戻るか? */
      *p = tmp_old;                 /* 戻らなければ終了 */
      break;    
    }
    *p = tmp_old;                   /* 元の値に戻す */
  }

  return i;
}

メモリ反転書き込みが失敗したところまでの領域が有効とみなされる。

なぜ反転書き込みテストが有効なのかは未知。(全体の)メモリ範囲外に書き込んだら一体どうなるのか…調べる必要はある。

呼び出し側(kernel_main.c)は次の通り:

  /* メモリサイズテスト */
  memory_size = Memory_Test(0x00400000, 0xBFFFFFFF);
  my_sprintf(str_buf, "Memory:%dMB", memory_size >> 20); /* MB単位に直す:2^20 */
  putfonts8_withback(binfo->vram, binfo->scrnx, 8, 41, COL8_FFFFFF, str_buf, COL8_000000);

コンパイル時に-O0だと正しく32MBとの結果が返ってくる(32MBになっているのはqemu-m 32に依る)。だが-O1, -O2, -O3, -O4だとやっぱり駄目で3072MBの結果が返ってくる。OS自作だとアセンブリを書くことで対処していたが、ここでは少しvolatileで対処できないか探ってみる。

この場合だと、*p周りで最適化が働いてしまって(*pの読み出しに副作用がないとしているから)望む結果が得られない。そこで、*pvolatile属性を付与した所、最適化オプションを付けても問題なく動作するようになった。

  volatile uintptr_t *p;

でも、実はvolatileを正しく理解していないフシが有る…(取り敢えずつけとけば最適化抑止できるんでしょ?位の感覚。)

qemuのメモリサイズと最適化オプションを色々変えても正しくメモリサイズを計れるようになったので、ここで今日の作業は打ち切る。しかしまだ不明確な点が3つ。要調査。

  1. メモリ反転書き込みでなぜ正しく有効なメモリサイズが計れるのか?
  2. EFLAGS_AC_BIT, CR0_CACHE_DISABLE: EFLAGSCR0のビットフィールドをまとめる。初めて読む486に書いてあるはず。
  3. 上記volatileに関する事項。voltile記憶クラス指定子とは一体何か?

後、機能要望として、キーボードとマウスの取得したコードのデコードを行いたい。