【エンコード日記】AACのお作法講座（汚作法かもしれない‥orz）

↓3)記稿.2024/06/29

＞　ググってみても、スタンダードに用意されているAACは欠陥品である（基本事項）


　‥そこで、エトセトラなAACが名乗りを上げている
　それとて名称は違えど、中身は全部AAC規格そのものらしい
　内部の細かいカスタマイズ×調整が違うとしているのが売りで、それぞれに個性が異なる
　好きなのを選べと言わんばかりなのが、如何にも競争原理で刺激的でしょう‥みたいな

　　素人からしたら敷居が高いだけの意図不明な規格群にしか見えねぇ
　　（ライセンス問題が、それぞれに異なっているくさいのも‥素人には悩ましい）


＞　それが現状‥と言うことらしいのだが、意味が分からない
＞　デジタル放送の初期の頃からAACだったじゃん、その当時から欠陥品だったの？？


　‥どうにも、日本の家電が凋落した時代の象徴だったとしか言いようがねぇｚ‥


＞　まぁその辺の裏事情なんざ、ここではどうでも良い
＞　今は、スタンダードなＡＡＣとして確かそうな変換手法とやらが先だ
↓/続きを読む/↓

【エンコード日記】Ｂ繰羅の正体を見たり‥其の一

↓4)記稿.2024/06/28

＞　1920×1080（16：9）内部ピクセル化の中身は、SDに非ずHD品質なりや‥（謎）
＞　テレビUSB挿し用途なのだから、ビットレート（12500）は、まだまだ多い


　‥そこでｂフレームの導入をしつつも、キュルキュル感を保持したい
　（ｂフレームを導入するのだから、20％カットはイケるはず）

　‥ビットレート（10000）だ
　　（これでやっと25分ものが２ＧＢを切る程度か‥映画版を4GBに収めるにはまだまだ遠いｚ）
　　（ピクセル化フィルターを当てていると、品質０での確認が不能で困る‥まぁしょうがない）
　　（お約束のソースを引っ張り出して、拡大比較せざるを得ず）


＞　結論から述べると


　‥ビットレート謎比の焦点は｛1：1.44：2.56｝よりもう少し上だった
　｛１：２.25：４｝にすると、subme（7）に対して丁度良さげだな‥‥

　　‥すると、2.25倍する際に不都合な数値が、ぽろぽろと出てくるどえむ
　　（なので、始めから誤差の無い比率計算が求められてきます）
　　（なので、以前の数値は感覚だけ残して、白紙どえす）

　FHDの基本となるマクロブロック数（8160）
　HDの基本となるマクロブロック数（3600）
　この二つを掛けて共に割り切れる都合良さげな数が（122400）どえす

　それで、7500，10000，18500，30000‥に近い値を狙って比率割り算出していくと


＞　‥にしても、結局は、お約束なビットレートが基準に落ち着いてしまったｚ
＞　‥にしても、（122400）は謎めいた数値なんだニャン


　÷1.111111‥　→｛110160：247860：440640｝
　÷2　　　　　　→｛61200：137700：244800｝
　÷2.222222‥　→｛55080：123930：220320｝
　÷3　　　　　　→｛40800：91800：163200｝FHD静止画像の美麗適解（Hi10）
　÷3.333333‥　→｛36720：82620：146880｝
　÷４　　　　　　→｛30600：68850：122400｝
　÷4.444444‥　→｛27540：61965：110160｝
　÷5　　　　　　→｛24480：55080：97920｝
　÷5.555555‥　→｛22032：49572：88128｝
　÷5.666666‥　→｛21600：48600：86400｝HD静止画像の美麗適解（Hi10）
　÷6　　　　　　→｛20400：45900：81600｝
　÷6.666666‥　→｛18360：41310：73440｝
　÷10　　　　　　→｛12240：27540：48960｝
　÷11.111111‥　→｛11016：24786：44064｝
　÷11.333333‥　→｛10800：24300：43200｝
　÷12　　　　　　→｛10200：22950：40800｝
　÷13.333333‥　→｛9180：20655：36720｝
　÷16.666666‥　→｛7344：16524：29376｝
　÷22.666666‥　→｛5400：12150：21600｝
　÷24　　　　　　→｛5100：11475：20400｝
　÷30　　　　　　→｛4080：9180：16320｝


　‥なんだかとても頭の中が真空管に埋もれてしまいそうな数値で割り切れてゆう
　（これぞインターレースを実現せしめし舞台裏でしたん‥みたいな）
↓/続きを読む/↓

【日用エンコード】我が名はシンＱ郎。ピクセル化1080ｐにてテレビUSB挿し爆Ｑを極めし者？

1)記稿.2024/06/26

＞　８ビット×拙いｒｅｆ値でさぁどうしよう
＞　そこで動画フィルターの項目にある「ピクセル化」をピックアップ！
＞　デフォルトの｛2，2，平均｝をそのまま使います（最小と最大あるけど選べまてん）


　‥すると、解像度は1920×1080なのに
　中身は‥960×540‥としたハーフFHDに様変わるどえむ
　これにシンＱ郎が加わると、なんちゃって480インターレース解除風‥みたいな

　（もう、テレビUSB挿し×爆Ｑサーチ最優先には、これっきゃねぇ）


　‥だがしかし、PCM音声を一気にAACに変換すると高音部でノイズだらけにしか聞こえない
　DVDのAC3からの変換には問題無いのに、PCMからだと高音部でノイズだらけになる
　どれで組み合わせてみても全滅せり

　仕方がねぇので、一旦ＡＣ３にしてからＡＡＣにせざるを得ず（やや面倒くせぇ）
　（そういう隠れたお約束な仕様なのだろうか？？？）

　　‥まぁ、俺はＡＣ３派なので、保存環境としては、全然かまわないんだけど
　　テレビUSB挿しとしても全然そのまま回せるので問題ありません
　　（Chromebook用途だと、鳴らない仕様なので、変換の用有りどえす）


＞　E-AC3からもありか‥調べてみたら、ＡＣ３を介するのが一番に安全ぽい
＞　‥ＡＣ３（576）→ＡＡＣ（576）という具合に‥×１倍にて掛け渡すのが良さげらしい
↓/続きを読む/↓

【テレビUSB挿し】ref値を低くすると、ビットレート謎比も連れて下がる件

記稿.2024/06/24

＞　DVD16：9比の特撮動画をｉ解除（23.976p）再エンコードして、テレビUSB挿ししたら
＞　ref（11）でも重かったので、しぶしぶref（5）に下げた（GOP長‥12）


　‥そしたら、画質はちびっとQP値が上がったぽく見えるが
　逆にキュルキュル感が上がったので良しとしよう（て‥それ更にキーフレーム増えたんかい？？）


　‥それで、夜空星空とした実写映像を再エンコードしていると
　距離感が不可解しいのに気が付いた（ビットレートを増やしても品質が上がらない）

　　まずは、撮影自体が30フィールド構成くせぇソースに対しては
　　ｉ解除しつつもフレームレート（29.97）を保持×８ビット×GOP長（15）×ref（6）
　　次に、ビットレート謎比に着手した（悩ましい‥数がデカすぎるのも悩ましかったけどな）


＞　｛１：1.44：2.56｝＝｛1：1.2^2：1.6^2｝
＞　↑にすると、↓のビットレート謎比を、８ビットで扱えるものとして良さげ？？（調査中）


　（つまり、10ビットにすればさらに縮む？？‥それはそれで悩ましい‥）
　（ビットレート値を25の倍数にしないと割り切れないどえむ）


BD1920×1080（16：9）
｛15000：21600：38400｝（1024×576）ダウンコン‥8ビットなんて無理ッ
｛18750：27000：48000｝（1280×720）ダウンコン‥10ビットで［25600：36864：65536］にしないと無理っぽ
｛30000：43200：76800｝（1920×1080）‥8ビット×短いref値なんて無理くさっ


※　FHDサイズに関しては、テレビUSB挿しなんて考えなくて良いのだから
［30000：270000：480000］×10bit×フレムレート（59.94）×GOP長（30）×ref（14）で最高!!!‥（BDts用途）


BD1440×1080（4：3）‥1920から黒帯左右（240）カット×塩改造（1.363636）
｛12500：18000：32000｝（720×528）←ダウンコン自体が（没）
｛15625：22500：40000｝（1080×792）←ダウンコン自体がｉソースに由っては怪しい
｛28125：40500：72000｝（1620×1188）


DVD480（4：3）‥全部盛り塩改造（1.363636）
｛_6250：_9000：16000｝（720×528）
｛_7500：10800：19200｝（720×528）
｛12500：18000：32000｝（1080×792）


DVD480（16：9）‥端切り落としアプコン
｛10000：14400：25600｝（1024×576）
｛12500：18000：32000｝（1280×720）


BD480（4：3）‥全部盛り塩改造（1.363636）
｛調査中｝（720×528）
｛調査中｝（1080×792）

【エンコード日記】AACの音質を上げても再生負荷がトンデモねぇ

記稿.2024/06/24

＞　例えば‥調子こいて↓にすると、AC3→AACの再変換の際に‥まぁ好い感じなんですが‥
＞　音声再生だけの負荷が4コアDDR3マシンにて、軽く25％も持って行かれます（没）


サンプルレート：64000
チャンネル：stereo
レート制御モード：平均ビットレート
ビットレート：1344（334×4，448×3）
オブジェクトの種類：Main
SBR/PSシグナリング：暗黙的な後方互換性のあるシグナリング

TNS：□
Mid/Side：オン


＞　そこで低負荷でそつなく聞こえる塩梅にせなぁならんので↓になりました
＞　再生負荷が一気に一桁％に下がります


サンプルレート：48000
チャンネル：stereo
レート制御モード：平均ビットレート
ビットレート：334，448（192→334，224→448，AC3のそれ×1，640→320）
オブジェクトの種類：LC
SBR/PSシグナリング：自動

TNS：□
Mid/Side：オン


＞　感想としては


　‥Mainと暗黙的な後方互換性のあるシグナリングが相乗効果を得るように思われますが
　‥LCを選択する際にはあまり意味が無いような（後方参照しないモードだって言うし）
　だからといって「自動」にオフとした機能があるのかどうかなんて知らんがな（気やすめ）


　‥音楽だけ聴くわけでも無いので、全体で換算すると
　再変換の際には、ビットレート（334）が適当に思いますが
　負荷バランスを考えると、ビットレート（448）は次点ぐらいでしょうかね
　DVD辺りでは、AC3（448）なんてざらですけど、その際は×1倍とするのが無難かなっと‥

　（ChromebookだとAACが標準で、それの対応を考慮した調整どえす）


＞　実用で見ると‥技術更新なんざ、あるようでいて無ぇと思わざるを得ず
＞　（なので、ひと度スタンダードに躍り出ると、四半世紀に亘る利権どえす）


　‥考えたら
　後方参照ってｂフレームと同じ理屈に成るのだから
　Mainを用いてしまうと、編集しにくいだけ草‥（そういう意味でもLC一択でしかねぇ）

【エンコード日記】DVDハイジを（≒24ｐ）に切り替えるとガコパン抑制バッチリに‥orz

↓1)記稿.2024/06/23

＞　DVDハイジを8ビット出しして、テレビUSB挿ししたら、パンだけガコガコだった‥
＞　どうにもさすがに‥ref（14）が重いらしい
＞　となると、フレームレート（59.96）→（23.976）に切り替えざるを得ず


　‥あれ？‥今度はちゃんと回ってる‥（チッ）
　　だがしかし、720×480（1.363636‥）だと‥顔がちょいと横長になる‥（未対応かよ？？）

　　そこは、720×528（1.363636‥）にすると問題無し

　　　avidemuxを使うと一話ごとにサクッと切り出せる
　　　だが、HDテレビUSB差しは「mp4」しか認識しねぇ（お間違いなく）

　　（一話当たり1.4GB前後に‥BD480と較べても同等ぐらい程度サイズになるらしい‥）


＞　エンコード時間がさらに一時間も縮まるのに、なんだかうれしくねぇｚ


　‥24枚構成でもビットレートにしっかりと厚みがあると、諸々動きに問題箇所が減るんだな

　‥しかもテレビUSB挿しだと好逸ダイナミック適応になってて、スゲー綺麗ッ
　‥しかもテレビUSB挿しだと好逸ダイナミック適応になってて、スゲー綺麗ッ
　‥しかもテレビUSB挿しだと好逸ダイナミック適応になってて、スゲー綺麗ッ

　　（VLCプレイヤーでの視聴がクソに見えてしまうのだぁ‥10ビット出しに意味ねぇ‥みたいな）
　　（やはり、テレビに直に挿し込み視聴こそが王者か‥‥）


　‥テレビUSB挿しでの５段階サーチの利きが猛烈に良い （これぞビデオなり!!!）
　そこはさすがに「シンＱ郎」なんだけどさぁ‥わさb抜き×ＧＯＰ長（１２）×ｒｅｆ（１１）‥
↓/続きを読む/↓

【エンコード日記】BD1080[４：３]の1．363636化について‥（塩っぺぇz）

記稿.2024/06/22

＞　まずはお復習いから
＞　704×528（アスペクト比：1.333333‥）
＞　720×528（アスペクト比：1.363636‥）


　‥あ、今気が付いた
　だったら、はじめっから「720×528」で（4：3）全部盛りエンコードすりゃ良いじゃん
　どうせ内部拡張しちゃってるくせぇし
　だったら始めからそれに合わせてビットレート振れば、より安定的になるはず‥‥

　720÷16＝45　528÷16＝33
　45×33＝1485

　1080÷16＝67.5　→（68）　792÷16＝49.5　→（50）
　68×50＝3400


＞　1080×792‥‥駒辺りマクロブロック数（3400）
＞　｛12500：112500：200000｝‥←推奨基準


　1485÷3400＝0.4367647058823529
　12500×0.4367647058823529＝5,459.558823529411≒5476（74^2）


＞　720×528｛5476（74^2）：49284（222^2）：87616（296^2）｝


　「ヱ☆はいるの？？」
　「まじイケそうなんですけど‥‥（どんだけ〜）」

　　（クックク‥ついに容量勝負でDVDにぷち勝利せり‥みたいな）
　　（逆テレシネのフィールドマッチング様様でーす　m(_ _)m　m(_ _)m）


＞　｛6250：56250：100000｝‥←「まんが日本昔ばなし」桃太郎なら余裕（３駒アニメ用途？）
＞　｛7500：67500：120000｝‥←ここ推奨だけど８ビットでＯＫくさっ
＞　｛9375：84375：150000｝‥←ここBD480推奨どえすが確認の用有り（Hi10）


　704×1.5＝1056，480×1.5＝720，720×1.1＝792
　1056÷792＝1.333333‥
　1080÷792＝1.363636‥

　1440÷1056＝1.363636‥

　1440×1.125＝1620
　1056×1.125＝1188
　1620÷1188＝1.363636‥
　1188÷1080＝1.1

　1620÷16＝101.25　→　（102）
　1188÷16＝74.25　→　（75）

　102×75＝7650‥（一コマ辺りマクロブロック基本数、1632×1200とした内部計算に）

　1920×1080‥‥駒辺りマクロブロック数（8160）
　｛30000：270000：480000｝

　7650÷8160＝0.9375　30000×0.9375＝28125


＞　1620×1188‥‥駒辺りマクロブロック数（7650）
＞　｛28125：253125：450000｝‥←推奨基準


　‥いやぁとても塩っぱい値どえす
　ちなみに、フィルム現存されておらずに奇しくもビデオからのコンバートくさいソースになると
　1440÷1056＝1.363636‥とした怪しい事情含みになっているので
　クリップを左右（240）でカットしても、左右上下にまだ黒帯を余していたりしますが
　比率重視なのでノンタッチの問答無用で左右（240）カットに留めましょう

　中には、↑の例に同じく
　変則的にまんま横解像度1620（黒帯幅あり）なんてソースも有りますが
　その際は左右（150）カットして1620×1188（1.363636‥）で押し切る感じでしょうか‥
　（誤差が真っ赤になりますが、まぁ謎が一つ解けたと思えばそれで好いのだから気にせず）

【エンコード日記】シン全部盛り（不採用解像度にされし数値？？）

↓1)記稿.2024/06/21

＞　爆速にてDVD「アルプスの少女ハイジ」のシンＱ郎版エンコードを終えた
＞　５〜６倍比ぐらいハエェエエ（720×480）
＞　始めからsubme（７）にしときゃ良かったのだろうか？？‥（人生塞翁が馬）


　‥ちなみに、XMediaRecodeは、ＡＭＤのハードウェアエンコードに対応している
　AMDのグラボを挿し込んであると自動で↓二つの選択欄が降りてくる
　　コーデック：MPEG-4 AVC/H.264（AMD AMF）
　　　　　　　：HEVC/H.265（AMD AMF）

　（HEVCの方には対応していないグラボでも‥そっちも表示してしまっていいんかい？？）
　（CPUとの掛け合わせ計算なので、部分的に代用させるのでかまわないとか？？？）

　‥ある程度のビットレートを盛れば、出来上がり画質の方は悪くなさそうだが
　　どうにも、キーの入り方が好かん、そのせいか、動き方も好かん
　　（そこはHEVCにしてやらかせば無視できそうかな？？‥HEVCは其処までの器用さに無ぇし‥）
　　（AVCはレシプロ機、HEVCはジェット機‥肉体駆使して乗りこなしたいのはレシプロまで‥）


＞　‥で、アスペクト比（1.363636）打ちの件なのだが
＞　（1.36296296296‥）と同じくガコガコパンをサクッと改善せりと思いきや


　‥予想していたセルアニメ手作業ビギナーとベテランとの差がよりクッキリと明らかに
　　第一話での諸々パン‥かくっかくっ‥は、まぁしょうがねぇらしい（或る意味の当然さ）
　　（1.36296296296‥）の方が、通常パン動作には強げにあるっぽいが
　　第三話360度怒パンを過去比較するに‥（1.363636）の方が全体バランスが良い


　‥で、計算してみた

　704×1.363636‥＝960
　720÷1.363636‥＝528
　704÷528＝1.333333‥（まさに有効画面としてのドンピシャ）

　∴　720×528としたピクチャーサイズを得る


＞　528÷480＝1.1（アナログテレビのドット縦横比？）‥ここが肝らしい
＞　ここの1.1倍比さえ抑えておけば、拡大比も割り出せる


　704×1.5＝1056，480×1.5＝720，720×1.1＝792，1056÷792＝1.333333‥
　704×2＝1408，480×2＝960，960×1.1＝1056，1408÷1056＝1.333333‥

　_792×1.363636‥＝1080　∴　1080×_792　＆　アスペクト比（1.363636）
　1056×1.363636‥＝1440　∴　1440×1056　＆　アスペクト比（1.363636）


＞　この手の塩っぱい拡大サイズ値を、シネスコサイズ派のハリウッドがゴネてたくさいどえす
＞　（向こうはリビングに、シアターを置きたかったのさ）


　‥まぁそんなのどうでもええ
　基本的にDVD480ｉの品質は、ＨＤ止まりなので、横解像度（792）を狙います
　ＨＤテレビの解像度は（1366×768）なので縦に24ドット分不足しますが、まぁ気にしない

　切り落とし残り分の横解像度（1056÷16＝66）さえ割り切れていれば問題にせず

　1080÷16＝67.5→（68）　792÷16＝49.5→（50）　
　68×50＝3400（駒1枚当たりの16×16マクロブロック数）


＞　1080×792｛12500：112500：200000｝になるようです


　‥クックク
　　仮面ライダーOPのサイクロン号のタイヤ怒アップ画面が、漸くにして「真円」に見えたｊ
　　一号ライダーこそが、如何に1.333333のみとしては間違いかを証明している
　　（なので、ＵＨＤ版がでようと、エンコードし直さないと没かも？？）

　‥そういう意味では、1.36296296296‥も思慮不足でした
　　申し訳ございませんでした　m(_ _)m
↓/続きを読む/↓

【エンコード日記】アスペクト比：1．363636‥からのシン・全部盛り？？

記稿.2024/06/20

＞　BDの480サイズ（４：３）には、480ｐ（≒30p）と480ｉ（≒30i）が存在する
＞　さらに、そのアスペクト比（クロップ表示）には、1.333333と1.363636が存在する（謎）


　‥どうしてそうなるのか？
　よく解らずも、パンのカク付きを無くすのに効果的なアスぺクト比を
　「1472×1080」から1.36296296296‥とした

　　（結果‥「アルプスの少女ハイジ」ＯＰの壮絶なるガコガコパンに絶大な改善をもたらし）
　　（諸々手持ちソースに潜む、パン動作時にお約束だったカク付きを改善せしめたり‥）
　　（720×480（4：3）とした全部盛りの際には、悪くない選択支を得た）


　‥でもどうして「1.363636」なのか、ちょっと思い出しお復習いして見ると
　960÷704＝1.363636‥‥（これとした算出以外にありえず）

　「え？」‥じゃなに‥1.363636とした表示が出る奴は
　解像度（720）からのダウンコンになるわけ？？（ワケガワカラン）

　　1.36296296296‥と較べると、1.363636としても似ているのだから
　　二択の結果のそれだというのだろうか？？‥
　　それで考えられるとしたら、当時のパソコンの解像度がその程度だったから
　　「1.363636」の方の馴染み具合の良さうんぬんとした理由になってくるｚ
　　元々の合成レベルの解像度がその程度だったから、現場で考慮した結果
　　‥と言う奴なのだろうか？


＞　そう考えると、パソコンの無かった時代のセルアニメ（4：3）作品の1.333333の時のみ
＞　「1.36296296296‥‥」とした方が良さげだな‥そういう見方にもなるのだが‥


　DVD（4：3）も含めて全部盛りのまま
　カスタム（1.363636）を打ち込むと
　アスペクト誤差：-2.2727‥を得る（オリジナル＝1.363636なら誤差0）


　（所謂、端をカットすると表示される値どえす‥あれ〜‥完全に見落としてたｊ‥orz）


　お約束な毎度のサンプルからの比較でも良好だ‥というより
　むしろ完璧だ‥ソースの動きを余すこと無く追随しているとしか思えない‥
　その上で、パン動作のカク付きをも解消せり‥‥もしかしたら「1.363636」が正解かも‥‥

　　取りあえず、ド本命の「アルプスの少女ハイジ」を出して見なぁなんとも言えん
　　ソースがオープンGOPだと、途中で切っての一時出し等が無理なのでとても手間‥‥

｜霧晴れて時代をつむぐ鐘の音 繋げる変化と私の気づき

　霧も晴れると、霧中の時とは打って変わって、気が付かんかったことが見えてくゆう
　（そういう時代ですよ、ほんとにもう、気になったなら直ぐにも疑ってチェックしよう！）

【ぶれ駒レスｉ解除】XMediaRecodeの「逆テレシネのフィールドマッチング」が素晴らしい

↓3)記稿.2024/06/19

＞　ありがとうございます　m(_ _)m　m(_ _)m
＞　ぶれ駒レスｉ解除に、見事成功しておりまして、とても素晴らちぃいい


　→開発元（Updated on 2024年6月10日）
　→↑のデフォルトをぷちカスタマイズしてあるっぽいのがXMedia Recodeのそれで
　　項目カットのそこん所が、どうなっているかなど知る由もなし
　　（説明読んでも分からんので、デフォルトのまま用います）


　‥だが、24枚化には成功せるも、動きがぎこちないどえむ
　でもまぁそこは、リニア混合×60枚化やらかすのだから不問としておきませう（解決済み）

　　（これで漸く、セルアニメの多重撮り箇所を断定的にキュルキュルにてチェックできるｚ）


　フレームレート：59.94 ； 23.976
　GOP長　　　　：30　　； 12
　ｒｅｆ　　　　：14　　； 11
　先読み　　　　：999　 ； 999

　　‥同じCRF（0）わさb抜き仕様でも、違いは発生するかもどえす
　　なので、まずは、そこの違いの有る無しの確認が必要どえむ
　　（とくに‥８×８とすべきか、４×４まで使い込むのか、そこの判断や如何に‥）


＞　‥そして、知ってしまった‥
＞　カラー優先度×行列係数×転送特性としたトリオを
＞　「指定なし」にすべきだったと‥orz


　　‥指定したままだと、映像メニュー発色に影響を及ぼし、切換余裕に乏しくなる草
　　（キュルキュルとせるはずの動きがもっさりしてしまったりと‥なんか違う‥）

　　「ぶれ駒レスｉ解除」としたその印象に、デカく異なる何かがあるのだろう


　‥切換オンオフとした間違えはやらかしたくねぇので「指定無し」の一択になるっぽ

　　ソースで指定付いてる奴は、マスターソース比較での色安定を図るための結果らしい
　　（DVDとの違いやら取り扱いをはっきりさせる意図だったりするのかも‥？？）


＞　圧縮度合いを述べると‥ぶれ駒レスｉ解除の結果、1.125倍前後とした減量に成功せり
＞　（細かく述べると‥1.152になる‥）
↓/続きを読む/↓