Keizou's Activity

〜 LifeHackの次はLifeActivityが流行るんじゃないか論 〜

もしかしたら40代後半以上の方々は通称「バトン」という若者文化を知らないかも知れない。

なんて事はないいわゆるテーマに沿ったお題に応じて次のユーザ、次のユーザへと渡していくという一種の大喜利・山の手線ゲーム的なものだ。

これがインターネットに登場したと確定的に言えるのは「チェーンメール」ブーム以降で、この文化形成へ寄与したのは現在の30代後半〜40代前半だろう。

「不幸のメール」なんてものを懐かしむ人は比較的多いのでは無いかと思う。

それ以前からBBSやチャットなどで大喜利をやっていたような気がしなくも無いが、一般的に普及したのはチェーンメールと見て良いはず。

祖を辿れば文通や和歌?

「不幸のメール」でピンと来た人も居るかも知れないが、インターネット以前の昭和40年頃に「不幸の手紙」ブームがあり、更にそれの祖を辿れば大正時代に「幸福の手紙」がある。

こういった形式の連鎖する遊びの祖を探れば、拙い知識から導き出されるのは、和歌の上の句に続いて下の句を返す「連歌」ではないか?と考えている。

そもそも和歌の歌会ではお題を設けて詠むことが通例なので、歌会の中で連作していくこと自体が祖と言えば祖なのかも知れない。

バトンが必須な若者コミュニティ

何故いきなりこんな話をしはじめたか?と言えば、このインターネットバトンは現在でも続いているからだ。

現在の若者はTwitterで、LINEで、Instagramで、TikTokでインターネットバトンを続けている。

自分自身の記憶を掘り返しても10代の頃はよく友人から送られてくるバトンを回し続けていたなという思い出があり、冷静に考えると「若者コミュニティにはバトンが必須なのではないか?」と思うようになってきた。

インターネットバトン以外にもクラスメイトの女の子がよく手紙でそういうバトンのようなものを回しており、数はそう多くは無いが自分にも届いたことがあるなという記憶も薄くある。

そう考えるとTwitterのハッシュタグも「付箋」というよりは「お題」と捉え、何故日本のインターネットコミュニティへ広く受け入れられたのか?がわかるような気がしなくもない。

若者ウケを狙うならバトンをしやすくする?

「若者コミュニティにはバトンが必須なのではないか?」という点を考えると、逆説的に「若者ウケを狙うにはインターネットバトンをしやすくする環境を提供するのが近道なのではないか?」という推測が立つ。

InstagramやTikTokが大人が気付かないうちに10代の若者の中で爆発的に普及し、気付いてみれば若者はみんな使っているという状況が生まれる背景には、もしかしたら「バトンは大人に届かないからではないか?」がある。そんな気がしてならない。

「不幸の手紙」であれ「チェーンメール」であれ気付けば若者はみんな知っていて、若者へ普及しきった段階で大人社会はその存在に気付いて問題視する。

現在世界的に問題視されている「青い鯨」もまた(その地域や特定のコミュニティに所属する)若者はみんな知っていて、その段階でやっと大人社会はそれに気付くのだ。

恐ろしい例を引き合いに出してしまったが、インターネットバトンは若者コミュニティのインフラ形態である可能性が高い。

そのインフラを意図的に整備することによって若者を呼び込めることが可能性として存在する。

何らかの「お題」を設け、それを友人へ渡したいと思わせる。それがきっと若者コミュニティのインフラなのだ。

この記事のだいたいの内容は下記の通り

強すぎるSpotify

これまで音楽聴き放題サービスは「Spotify」が圧倒的シェアを持ち、月額サブスクリプションユーザからの売上も最も高かった(広告収入を入れてしまうと当然ながらYoutubeが最強すぎる)

「Youtube Music」の直接的な前身と表現してしまうと些か語弊がある「Google Play Music」は無料枠登録者であっても5万曲分もの音楽用クラウドストレージが利用できたが、はっきり言って魅力はそこまで無かった

「Google Play Music」に月額サブスクリプションしても欧米発サービスということもあってか洋楽はそれなりに充実しているものの、邦楽に関しては音楽レーベルとの契約の兼ね合いからか邦楽Aはあるのに関連する邦楽Bはないみたいなことが結構あった

個人的には幼児を抱える我が家庭が欲するEテレ(NHK教育)系の楽曲の乏しさは本当に残念でならないのだがどうにかならないものか・・・

まぁこのあたりの事情は欧米発の音楽聴き放題サービスではありがちで、配信楽曲の傾向は「Apple Music」とそこまで違いがないし、Amazonプライムのオマケである「Amazon Prime Music」よりはマシだ(Amazon Prime Musicは邦楽も洋楽も何でアレがあってコレがないの!?ってパターン多いよね)

邦楽は本邦発サービスを

そもそも邦楽を重視して聴きたいユーザは本邦発の「レコチョク Best」や「NTTdocomo dヒッツ」を月額サブスクリプションした方が良い

ちなみにだが株式会社レコチョクはエイベックス・ソニー・ビクターが共同出資し立ち上げた会社で、本邦音楽レーベルが立ち上げたということもあり「レコチョク Best」の邦楽配信楽曲は非常に充実しており、株式会社レコチョクの現在の主要株主はNTTdocomoということもあり「dヒッツ」の配信楽曲は株式会社レコチョクから提供を受けている

つまり「レコチョク Best」≒「dヒッツ」であり、選択の仕方は何処のポイント文化圏に属しているか?で選択すると良い

「レコチョク Best」は楽天スーパーポイント・Tポイント・Pontaポイントが利用可能で、「dヒッツ」はdポイントが利用可能だ

まぁ逆に欧米発の音楽聴き放題サービスよりは洋楽に弱いので、その辺は好みの問題だろう

無法をひっくり返すYoutube Music

「Spotify」の優位性として(物凄く邦楽には弱いけれど)洋楽の痒いところまで手が届くライナップと、そのユーザ数の暴力によって実現したプレイリストの充実さが挙げられている

「Spotify」でよく音楽を聴くユーザならわかるだろうけれど「Spotify」のプレイリストはセンスの良いモノが多い

「Apple Music」もなかなかだけれど「Google Play Music」はやはり機械的に生成している部分もあるのだろうか、悪い並びではないけれど驚きも喜びも出会いもない人気曲を並べましたねというプレイリストがほとんどだ

つまり今までの「Google Play Music」は音楽好きを唸らせるパワーが足りず、5万曲ライブラリやChromecastとGoogle Homeへ無線で飛ばせるGoogle Castは便利っちゃ便利だけれど、やっぱり音楽は「Spotify」で聴きたいよねとなってしまっていた

そしてそれを解消する可能性あるのが「Youtube Music」だ

動画配信サービスの持つリスクとしてよく挙げられるものに、ユーザが好き勝手に動画をアップロードしてしまい違法性のある動画まで存在してしまうことだった

それだけならまだしもユーザはそんな違法動画のプレイリストまでモラルなんて知ったこっちゃねえ!というノリで大量に作り出してしまった

Youtubeはこれまで様々な対策を講じて来たが根本的な解決にはならず、その点に関してバッシングを受けることが少なくない

しかしながら、この多くのユーザが作り出したデータベースを何も活用しないのは勿体ないのは明白で何かに利用したくなる

そこで新たに始めたのが「Youtube Music」というわけだ

「Spotify」が持つユーザ数の暴力によって実現した充実したプレイリスト、これは既にYoutubeも持っている、違法性の塊だけれど

この違法性あるプレイリストの権利関係を解消し、プレイリストのライブラリ群を活用できるのであれば一気に「Spotify」に肩を並べられる

事実「Youtube Music」のプレイリストは何処かの誰かが作ったもので、表示されるサムネイルは明らかに公式でないモノが交じっており一瞬ドキッとしてしまう

しかし「Youtube Music」を聴いてみるとプレイリストの出来は「Spotify」と遜色なく驚きも喜びも出会いもある

そんなプレイリストが充実化した新たなGoogle系音楽聴き放題サービス「Youtube Music」へ期待感を隠しきれず、毎日の音楽リスニングが楽しくなりそうだ

Youtube Redなどで実験していたものは、そういうことだったのかと気付かされる

最後に唯一欠点があるとするなら「Google Play Music」のライブラリをインポートできないのでココを何とかして欲しいなと要望を書いて締める

はじめに

GoPro HERO7で強化された手ブレ補正機能「タイムワープ」をどうにか後処理で実現できないか?を色々試した結果、何とかモノになったのでYoutubeに公開しました。

ただ、今回のスクリプトは非常に長く使いにくいのでマニュアル未満な解説をしようかと思います。

フェイクタイムワープワンライナー

下記が今回のワンライナーとなります。

ffmpeg -threads 0 -framerate 30 -pattern_type glob -i '*.jpg' -an -s 3820x2160 -an -b 200000k -vcodec libx264 -pix_fmt yuv420p -g 1 -r 60 temp.mp4 && ffmpeg -threads 0 -i temp.mp4 -vf vidstabdetect=shakiness=8:accuracy=15:mincontrast=0.4 -an -f null - && ffmpeg -threads 0 -i temp.mp4 -vf vidstabtransform=input=transforms.trf:smoothing=30:crop=keep:zoom=15:optzoom=1:zoomspeed=5 -an -s 3820x2160 -an -b 200000k -vcodec libx264 -pix_fmt yuv420p -g 1 -r 60 EXPORT_FILENAME.mp4 && rm -rf temp.mp4 && rm -rf transforms.trf

しかし判る人には判ることとして今回のワンライナーは「Bash」向けに書かれたものでWindowsの「cmd」や「PowerShell」ではおそらく上手く動作しません(未検証)。

MacやLinux(とBash環境のあるWindows)では動作するのですが、普通のWindowsでは動作しないのでWindowsで使う場合は3回に分けてスクリプトを実行していくのが確実かと思われます。

それではスクリプトを分解していきましょう。

分解したものを1つ1つ実行していくわけです。

用意するもの

このワンライナーではデジカメで撮影した動画ではなくJPEG画像を”基本的には”使用します。

撮影方法は秒間4〜10枚の連射撮影(今回公開した動画では秒間4枚)を用います。

秒間撮影枚数を増やしたり、ボディもしくはレンズ内手ブレ補正を併用するとよりスムースな映像を得られるでしょう。

JPEG画像から手ブレ補正なしの動画を生成する

このパートではJPEG画像から手ブレ補正なしの動画を取り敢えず生成します。

ffmpeg -threads 0 -framerate 30 -pattern_type glob -i '*.jpg' -an -s 3820x2160 -an -b 200000k -vcodec libx264 -pix_fmt yuv420p -g 1 -r 60 temp.mp4

ちなみにこのパートの動画は下記の仕様で生成されています。

情報 数値
動画形式 H.264
解像度 3820x2160
入力フレームレート 30FPS
音声 なし
ビットレート 200Mbps
GOP フルIフレーム
動画フレームレート 60FPS
コンテナ形式 MP4
ファイル名 temp.mp4

この時点で非常に高い品質を得られて居ますが、(ボディもしくはレンズ内手ブレ補正がなければ)手ブレ補正のないガタガタの動画のままです。

この動画へ対して手ブレ補正処理を適用するこよによってタイムワープのような映像表現を実現します。

Tips FFmpeg以外の手ブレ補正処理

この時点で生成されている動画へ対してFFmpeg以外の手ブレ補正ソフトウェアは利用可能です。

Adobee PremiereやDavinci Resolveなどお気に入りの手ブレ補正を使って下さい。

FFmpeg以外の手ブレ補正ソフトウェア利用する場合は以下の解説は必要ないかも知れません。

Tips PNG画像をソースとする

今回のワンライナーでは'*.jpg'の部分でJPEG画像を指定しています。

例えばRAW現像ソフトウェアでより高画質を狙ってPNG画像を用いる場合は'*.png'と書き換えて下さい。

RAW現像時間が許すのであれば高画質を狙っていくのもアリでしょう。

ちなみにTIFF画像ならば'*.tif'ですしBMP画像ならば'*.bmp'です。

ただし、DNGなどのRAW画像形式には対応して居ないので必ず汎用的な画像形式へ変換して下さい。

Tips 120FPSにする

連射秒間10枚などの超ハイスピードなJPEG画像を用意し、高フレームレートである120FPSが欲しいという要望もあるかと思います。

動画フレームレートは-r 60で指定されていますので、この部分を-r 120にすると120FPSの動画が得られます。

ちなみに連射秒間10枚などの超ハイスピードなJPEG画像が用意できる環境であり、よりスムースな映像が欲しい際は-framerate 30-framerate 60にするとスムースになります。

手ブレ補正のための解析を行なう

解析を行なわなくともFFmpegでは手ブレ補正を適用することは出来ますが、より品質の高い手ブレ補正を適用する場合は解析を行なった方が良いです。

ffmpeg -threads 0 -i temp.mp4 -vf vidstabdetect=shakiness=8:accuracy=15:mincontrast=0.4 -an -f null -

このパートでは上記のスクリプトを実行する以外することがありません。

実行するとtransforms.trfというファイルが生成されると思いますが、これが解析に必要なファイルですので削除しないで下さい。

手ブレ補正を適用する

下記のスクリプトを実行すると手ブレ補正が適用されます。

ffmpeg -threads 0 -i temp.mp4 -vf vidstabtransform=input=transforms.trf:smoothing=30:crop=keep:zoom=15:optzoom=1:zoomspeed=5 -an -s 3820x2160 -an -b 200000k -vcodec libx264 -pix_fmt yuv420p -g 1 -r 60 EXPORT_FILENAME.mp4

上記のスクリプトを実行すると下記の仕様で動画が生成します。

情報 数値
動画形式 H.264
解像度 3820x2160
入力フレームレート 30FPS
音声 なし
ビットレート 200Mbps
GOP フルIフレーム
動画フレームレート 60FPS
クロップ率 15%
コンテナ形式 MP4
ファイル名 EXPORT_FILENAME.mp4

最も注目すべき点はクロップ率15%です。

後処理による手ブレ補正の仕様上どうしてもクロップせざる得ず、タイムワープのようなヌルヌルとした手ブレ補正を実現するには15%ものクロップが必要でした。

しかし、ボディもしくはレンズ内手ブレ補正があればクロップ率を下げることが可能です。

ちなみに動画が生成されればtemp.mp4とtransforms.trfはもう必要ないので削除しても構いません。

Tips クロップ率の変更

クロップ率はzoom=15で指定されています。単位は%です。

ボディもしくはレンズ内手ブレ補正がある環境ではzoom=10にしたりzoom=5にしたりすると良いでしょう。

おわりに

長い記事となりましたが、以上でフェイクタイムワープワンライナーの解説は終わりです。

今後も何か面白い発想が浮かべば色々作っていきたいと思います。

FFmpegの導入方法や解説などはわかりやすいものがネット上にたくさんあるので、解説はそちらにお任せします。

ボクがインターネットへ配信するメディア作成の経歴は動画というか実際には音声である「livedoorねとらじ」から「Flash」を経由して「ニコニコ動画」そして「Youtube」までなので、そこそこノウハウが溜まっている。

今回はそのノウハウを備忘録的に公開してみようと思う。

とりあえずやってみる

何よりも大事なのは「とりあえずやってみる」という気概が非常に大事。

やってみなければ何が成功し、何が失敗かも経験として解らないのでとりあえずやってみて考えるというのは大切なことだ。

最初は下手

ボク自身、上手いのか?と言われれば疑問だけれど、やっぱり最初は下手なのだ。

グルドンでYoutube動画を作成されている方々のクオリティと初心者のクオリティを比較しちゃいけない。

トライアンドエラーの精神で「下手だけど公開してアドバイス貰おう!」くらいの気持ちでクオリティ低くても公開してしまって良いと思う。

飽きるを考える

自己満足な趣味とは言え、一応はなんだかんだで誰かに観て貰うことを想定しているのがネット動画なので、視聴者の「飽き」を考えて動画を作るというのはやっておいて損はないはず。

ネット動画の1クリップ30秒は長い

例えば10分の動画があったとして、その内の30秒というのは全体の再生時間の1/20もの長さを持つ。

それが5分なら1/10だし、3分なら1/6もの長さだ。

30秒は日常生活や集中して仕事をしていると一瞬なのだけれど、ネット動画の体感時間の30秒は長い部類に入ると認識しておいた方が良い。

それを考えると1クリップ1分なんて永遠と思えるような時間だと想定したって大げさじゃない。

手の凝ったオープニングを載せたい

この気持ちは非常に判る。ボクも過去の動画サービスなどで長いオープニングの動画を何本も作った。

けれども手の凝ったオープニングというのは走り出しの本編まで行く再生時間が長くなってしまいがちというのを忘れてはならない。

例えばドリキンさんのオープニングは約5秒、ぴちきょさんも約5秒、Wataxxxさんも約5秒、egyoさん約6秒、短かめなオープニングのTJさん約3秒、kabaさん約4秒、長めなオープニングを持つ一ノ瀬さんでさえ約10秒です。

もっと言ってしまえばグルドン民の多くの方はオープニングを持たず、直ぐに本編へ入る方々が大半を占めています。

もちろんオープニング制作の労力もありますが、大半のグルドン民の方々は長いオープニングは飽きることを体験として知っているんです。

もしオープニングを作るとするなら5秒前後にするよう心掛けた方が良いでしょう。

5秒という魔法の時間

オープニングの話で気付いた方も居るかも知れないが、実は「5秒クリップ」というのは非常に優れた時間間隔だ。

5秒は意外と話せるし、意外と様々なモノを見せ、色々な表現を意外とできる。

人気Youtuberの福井のカズさんの動画を「5秒」を意識して観てみると物凄いことが判るから注目して貰いたい。

大半のクリップが5秒以内で終っており、5秒を超えた際の次のクリップは5秒未満の1秒や2秒のクリップを挟んで体感上の5秒を維持するよう努めている(もちろん例外はある)。

カズさんの動画が面白おかしく何故テンポが良いのか?という答えの一つが「魔法の5秒」の存在は外せない要素になっていると思われる。

コレは「リスペクト」するしかないだろう。

例えば視覚的な印象を狙ってタイムラプスを挟み込むときなど、タイムラプスクリップを5秒以内に抑えればテンポが良くなりやすい。

編集の労力低減

ネット動画において編集時間というのは悩ましい要素の一つだ。

特にグルドンのように4K動画が評価されやすい環境ではエンコード/エクスポート時間も長くなりがちで、可能ならば編集時間は短かくしたい。

そのヒントとして色々と記そうと思う。

長回し撮影しない

連撮撮影する時間を短かくまとめるのは直ぐ効果の出る編集労力の低減としてオススメだ。

そもそも動画はテキストのようにCtrl+Fなどで検索できるわけでもなく、使おうと思っていたシーンを探すことが非常に面倒くさい。

長回しするとそれだけシーンを探す労力が増えてしまうので、撮影時間自体を30秒以下くらいに抑えてしまえば、動画ファイルをビデオエディタのタイムラインに並べるだけで大体動画が完成してしまう。

あとは余計な部分をカットしたりカラーグレーディングしたり、音量調整したりするだけで良くなる。

動画ファイルが短ければ、本当に不要になった動画ファイルもカメラの機能で削除しやすいのでストレージの節約にもなりオススメだ。

音声収録の基本は声を大きく張ること

コレもカズさんが提唱していること。

収録時の声量が小さいと感じて音声編集によりゲインを上げるとサーッというホワイトノイズが今度は目立ってしまうようになる。

収録環境のガヤ音や風切り音などで声がかき消され聞こえず、音声編集によりゲインを大きくするとガヤ音や風切り音まで大きくなる。

こういうものへの解決方法にグルドン民は「指向性の高いマイクを外付けする」という方法を選びがちだけれど、そもそもの基本を言えば「声を大きく張る」ことで解決することが多い。

なぜなら、自身の声量が少し大きすぎるくらいであれば音声編集によりゲインを下げることによって、ノイズがゲインとともに小くなる。

そしてカメラのマイク感度を低くし、自身の声量を大きくするとこで、環境音を相対的に小さくしつつ自身の声を明瞭に聞かせられる。

カズさんは「Youtuberはカメラが回ると声を張るんだよねw」と笑い話にしていたが、声を張るのは意味のあることなのだ。

当然ながら「声を張る」という方法と、グルドンのスタンダードである「指向性の高いマイクを外付けする」という方法を合わせればより音質が良くなるのは言うまでもない。

カラーグレーディングやエフェクトなどを使わない勇気を持つ

モノ作りするときにどうしてもやってしまいがちなのが様々な機能をてんこ盛りで使い切ってしまわなければならないという脅迫観念だ。

初心者へぶっちゃけてしまえばそれは「次のステップ」だ。

その機能を使ってみるという心意気は非常に大事だし、実験的にむしろやってみるべきとも思う。

だけれども「使わなければならない」ことは絶対になくて、それによって編集の労力が増してしまっていると体感して理解できるレベルに陥いっているのならば、カラグレもエフェクトもしないと勇気を持って決断して欲しい。

この勇気を持つだけでかなり編集時間は減る。

手ブレするなら歩かない

VLOGと言えば歩き動画だけれども観るに堪えないほど手ブレするならば歩かないという発想を持つのも一興だ。

実際ドリキンさんなども手ブレ補正の弱いカメラやレンズを使っている際は歩き撮りのシーンが極端に減るという傾向が実はある。

後編集のソフトウェア補正で手ブレ補正をしても上手く行かなかったり、適用までに時間が物凄くかかってしまったりすることも往々にしてあるので、どうしても手ブレしてしまうのならば歩かず撮ることも視野に入れたい。

むしろこういう場合は歩き撮りを一つの演出として、見せたいメインシーンと見せたいメインシーンの間に演出として歩きシーンを置くなどという発想の転換をしてみると良いかも知れない。

手ブレする歩きは演出なのだと割り切れば手ブレを抑える編集に悩まず済み、編集時間は減る。

次のステップへ進みたい

粗方ビデオエディタの機能を試し把握しており、何となく撮影から編集そして公開までのフローやスタイルができあがってしまい「何か?面白いことはできないか?」と思ったときの話をする。

まずは他人の動画を見る

リスペクトするのは非常に大事で、良いなと思った演出はぶっちゃけパクってしまえば良いと思う。

パクるには撮影や編集の仕方を考え、そしてトレースする必要があるのでかなり勉強になる。

例えその模倣元がTV番組だろうがドラマであろうが映画であろうがアニメであろうがゲームであろうが何でも良い。他人の動画はすごく勉強になる。

意外と役立つPhotoshopのTips

印象的なエフェクトを試したいがビデオエディタの中には気に入るものが無いとき「Photoshop ○○ フィルタ」「Photoshop ○○ 風」と検索すると意外と良さげなものが見付かることが多い。

現在のビデオエディタはレイヤーを持ち、基本的なフィルタやアルファチャンネルなどを持つので、Photoshopと微妙に機能名称が違ってもPhotoshopと同じフィルタ加工が再現できることが多い。

例えば「Photoshop 古写真 フィルタ」や「Photoshop トイカメラ フィルタ」「Photoshop HDR 風」「Photoshop ゴッホ 風」などと検索しビデオエディタで再現すると勉強になる。

実は基本機能の組み合わせ

前述したとおり現在のビデオエディタはPhotoshopと近い機能を持っていたりして、便利な自動フィルタは機械的に基本機能を組み合わせているだけだったりする。

これはトランジション関連でもそうで、ある種の高度なトランジションを実現している。

つまり、編集を極めようと思えば基本機能の挙動を把握し、AとBを組み合わせればCという結果になると想像できるようになることが大事なのだ。

別にいきなり高度なことをせよということもなく、例えばグルドンで流行っているレンズを手で隠して次のシーンへ移行するという演出の際に、手で隠したクリップの後に完全黒塗りの非常に短いクリップを用意し、手で隠すクリップからトランジションで黒塗りクリップへスムースに移行させれば完全な闇が得られて自然に見えるというようなことから発想すると良いんだ。

こういう発想の先に高度な組み合わせトランジションやフィルタがあるので、少しずつ試して習得していくと上手くなる。

手で隠してブラックアウトという演出があるなら太陽を映してホワイトアウトさせる、ホワイトアウトさせる際に白塗りクリップがあれば完全な白になるのでは?とかそういう発想で良いんだ。

ただし、静止画を対象としているPhotoshop Tipsを動画に持ってくると非常に動画エンコード/エクスポートが遅くなるので多用は控えた方が良い。楽しいんだけどねw

技術的な悩み

動画編集に関わるコンピューティングのちょっと突っ込んだ話をする。

MOVファイルのプレビューが遅い

カメラに寄ってはMOVファイルを動画として生成するものがある。

しかし、ビデオエディタのタイムラインへMOVファイルを配置しシークバーを動かすと何だかカクつくような現象に遭遇することがある。

その際は素直に「MOVを使わない」と割り切り、可能な限り劣化しないようにMP4ファイルなどへエンコードした方が良い。

そもそもMOVファイルはMP4ファイルよりもデコード性能が低いので再生するのにコンピュータリソースをより多く消費してしまう傾向がある。

これはMOVの仕様上の問題で解決しようが無いのでMP4にエンコードするか、いわゆるプロキシ変換をした方が良い。

何度直しても音ズレが解消しない

瀬戸さんのリズム動画やおつかひさんが多用するBGMに合わせたシーン移行のようなことをしたいのに音ズレによってなんだか微妙になることがある。

その場合は音ズレさせたくないクリップから音を抜き出し(たいていMP3かAAC)、そしてWAVに変換をして音声タイムラインへ配置すると解決することが多い。

当然、音声を抜き出した方の動画はミュートにしておかないと音声が二重になってしまうので注意が必要(ミュート忘れは本当にありがちなミス)。

ノイズリダグション(ノイズ除去)をかけると声がケロる

ノイズリダクションはそもそも隠し味的に薄らとかけるものなので、おそらくノイズリダクションを強くかけすぎている。

これは前述した「自身の声量を上げてカメラのマイク感度を下げる」ことで解決することが多い。

十分な声量があれば、人声音域(成人男性300~550Hz、成人女性400~700Hz)以外をイコライザーでバッサりとカットしてしまい環境音を抑えるなど自由度が増す。

撮影した動画ファイルが壊れていて再生できない

成功するかどうかは半々だけれど、なんらかの形式へエンコードすることで修復される場合がある。

その際は可能な限り劣化しないような設定でエンコードすると良い。

誤ってSDカードをフォーマットした

カメラの機能でフォーマットしているのであれば、データを復旧できる可能性が高い。

しかし、フォーマットした後に撮影してしまうと復旧できたはずのデータが完全に消えてしまうので、誤ってフォーマットしたSDカードは絶対に使わないようにしよう。

ボクが使っているPC向け復旧ソフトに「PhotoRec」というのがあるので、自宅に戻った際に使い方を調べて復旧して欲しい。

基礎の基礎なノウハウ

基礎の基礎なノウハウはだいたい書けたのではないかと思う。

その他のノウハウになるとやっぱり個人の趣味趣向や撮影編集環境の違いなども出て来るとは思うので、この辺で抑えておく(光源やレンズ自体の明るさは正義みたいな話はグルドンでよく聞いてるだろうし)。

また何か思い付けば書くかも知れませんが、長文乱文にお付き合い頂きありがとうございました。

新しいiPhone Xシリーズはユーザの選択肢を狭めたからこそ、ユーザに寄り添っているのではないかと思う。

再定義を貫いた新しいiPhone X

今回のApple Special Event September 2018で一部のユーザは顔をしかめたに違いない。

そう、ホームボタンがないのだ。

Apple Special Event 2017でiPhone Xが初めて登場した際、Appleを愛してきた旧来からのiPhoneユーザは「これからのiPhoneはホームボタンがなくなるのでは?」と予想し、そしてそれは現実になった。

今回、発表されたiPhoneは「iPhone XS」「iPhone XS Max」「iPhone XR」の3機種で、そのどれにもホームボタンは搭載されていない。

これは間違いなく、前回をも超えるAppleからの「新しい時代はすでに始まっている」という強いメッセージだ。

そんな新しいiPhone Xシリーズ発表から読み取った筆者の考えについて語ろうと思う。

iPhoneという制限したスタイル

iPhoneが登場した際、世間は歓迎したムードだったのか?と言えばそうではない。

iPhoneが発表されても世間はガラパゴスケータイが主流であり、過剰にも高機能なスマートフォンというジャンル自体が理解されていなかった。

更には、スマートフォンの必要性を相当前から理解していたWindows Mobile端末ユーザやSymbian OS端末ユーザなどのアンテナの高いユーザ達の中にすら「テキスト入力用のソフトウェアキーボードのみの全面タッチディスプレイは表示領域が狭くなり利用に堪えない」と主張するユーザも居た。

しかし、現代を見れば答えは明白。スティーブ・ジョブズが提唱したスタイルはデファクトスタンダードとなり、それが当たり前のように世間は受け入れている。

ハードウェアキー支持者からするとiPhoneは制限があり使いにくいものであったはずだが、実際のところ従来の携帯電話から再定義されたiPhoneのスタイルはユーザへ寄り添うものであった。

例えば、それがiPhone 5sから大型化されたiPhone 6/6 Plusであってもそうだ。結局のところ4インチディスプレイ端末の廃止という決断が間違っていたかどうかも市場の状況を見ると判る。

Appleは常にユーザへ寄り添う努力を怠らない。ならば新しいiPhone Xシリーズもユーザへ寄り添うよう考え抜かれているはずだ。

iPhone XRの存在がAppleのレギュラーを雄弁する

実際のところ今回のAppleがどのようなスタイルでユーザへ寄り添って来たのか?はAppleの新しいiPhone XシリーズのWebページを見るとわかりやすいものが目に飛び込んで来る。

一番わかりやすいスタイルの提案は「写真」だ。注意点としてはAppleが推しているのは「カメラ」ではなく「写真」であることに注目しなくてはならない。

日本ではJ-SH04(SHARP製造/J-PHONE販売)から爆発的に普及し、今や当たり前のように根付く携帯電話による写真撮影文化だが、その多くの場合は写真撮影に対してライトなユーザが大半だ。

携帯電話は写真が撮れて当たり前のユーザを前にしAppleはライトなユーザが何も考えずとも「明く」「くっきり」「しっかり」の「写真」が撮れるスタイルを提案する。

このようなカメラ機能を最も安価なモデルへ搭載してきていることこそがAppleのメッセージなのだ。

つまり、iPhone XRとiPhone XS/iPhone XS Maxの共通項が今回Appleが提案してきているスタイルということになる。

重要なのは「写真」であって「カメラ」でない。ましてや「背面デュアルカメラ」であるはずがない。

Appleは低処理能力端末を否定する

世にある様々なスマートフォンの価格設定は処理能力によって決定されることが多い。

例えばAndroidOS端末で採用されることの多いSoCのQualcomm Snapdragonシリーズであれば高性能・中性能・低性能と3つのラインがあり、搭載されるSoCによって端末自体の価格が決定される傾向にある。

しかし、Appleは今回3機種すべてへ同じA12 Bionic SoCを搭載しながらも価格差を設けた。Android端末で言えば、どの価格帯のAndroid端末であれ高性能ラインのSoCが搭載されるということを意味する。これはAndroid端末の常識から言えばセンセーショナルなことだ。

処理能力の低さによってユーザが悩まされることをAppleは良しとはしない。そういう強い意思が感じられる。

こういう3機種の共通項をAppleはこれからのユーザへ寄り添うレギュラーなスタイルとして世界へ提案し、それこそがこれまでの不可能を可能にするAppleのミッションなのだ。


参考リンク

※このポエムはiPhoneポエムの供給量が少ないことを悲しんだGNU/Linux信者によって「少ないならApple信者を憑依させて自分で書いたら良くね?」というDIY精神で書かれました。ちなみに次はPixelかXperiaを買います。

経緯

2018/08/16現在、Hubzillaに関する日本語ドキュメントは存在せず、英語ドキュメントを読むしかないのが現状です。

自分自身の英語力と記憶力にも限りがあるため、備忘録的に記録し、そして同時に広く公開して役立てて頂こうと考えました。

ちなみにこのwrite.asというブログはFederationに対応していてMastodonなどからフォローしたり、連合に表示させたりすることが可能なので、いわゆる分散型SNSの何かを書くのに向いているかも知れません。

この記事の注意点

Hubzillaの公式ドキュメントはギークのそれにありがちな難解かつ独自の世界観に溢れた設定集であり、おおよその一般人へ理解して貰おうという気が更々ないドキュメントです。

そのためこの記事では公式ドキュメントを翻訳する記事にはせず、当方が読んで考え理解したことを記載します。

Hubzillaへ対する主観的な解釈に間違いが生じている可能性がありますので鵜呑みにはしないで下さい

参考ドキュメント

Hubzillaとは

公式ドキュメントを斜め読みするとZotプロトコルを用いた分散型の統合的なWebアプリケーションとサービスを提供する拡張可能なオープンソースフレームワークです。

一部のWebサイトでは「HubzillaはFacebook的なSNS」などと表現されていますが、それは誤りです。

SNSとしての機能はHubzillaに取ってみると一機能でしかなく、そのためHubzillaを端的に説明しようとするとZotプロトコルを用いた分散型の統合的なWebアプリケーションとサービスを提供する拡張可能なオープンソースフレームワークという表現の他に言いようがありません。

この難解な説明をより解り易く説明しようとする結果「HubzillaはFacebook的なSNS」という表現が生まれたのでしょう。しかしこれは誤りです。

用語

Zot

Hubzillaの分散型通信と機能サービスを提供するJSONベースのプロトコル。

発音はおそらく「ゾット」です……たぶん。

Hub(ハブ)

Zotプロトコルを用いた分散型の統合的なWebアプリケーションとサービスを提供する拡張可能なオープンソースフレームワークを運用するためのサーバです。

端的に言えばHub = Hubzillaサーバだと認識して間違いないはずです。

Grid(グリッド)

Hub同士が接続するZotプロトコルを用いた分散ネットワークのこと。

Gridでなければ利用が出来ないHubzillaの機能も存在します。

Channel(チャンネル)

多くのWebサービスのAccountと酷似しており、Channel = Accountと認識しても大幅に間違いでは無いですが、Hubzilla公式ドキュメントに従うとHubzillaには”一般的に言うAccount”という概念が存在せず、存在するのは個人を識別するIdentityということになっています。

Account(アカウント)

HubzillaのAccountとは特定の独立したHubへアクセスするための認証情報を指し、個人を識別するための情報ではありません。

個人を識別するための情報はChannelへ内包されたIdentityです。

Identity(アイデンティティ)

Hubzilla公式ドキュメントに明記された解説はありませんが、Hubzillaの言うIdentityとはDigital identity(デジタルアイデンティティ)のことだと思われます。

Hubzillaでは個人を識別するためにIdentityが利用され、それらの情報をまとめたものをIdentityIDと呼びます。

IdentityIDは一般的なWebサービスの個人を識別するためのAccountへ相当します。

Nomadic identity(ノマディックアイデンティティ)

複数のHubで確立されるGridで容易にChannelを認証し、必要があれば他のHubへChannelを移行することが出来る機能全般のこと。

Identityを内包するChannelは単一のHubへ強固に結び付けられてはおらず、Accountが特定のサーバに無ければ利用できない典型的なWebサービスとは違います。

HubzillaのChannelは遊牧民のようにGridを容易に行き来できます。

Clone(クローン)

他のHubへChannelを移行および同期すること。

つまり、Hub Aで作成されたChannelをHub Bへ完全に複製し、複製後のHub Aへの投稿はHub Bに同期され、Hub Bの投稿はHub Aへ同期されます。

更に、もし移行元Hub Aが何らかの理由によって停止しアクセス不能状態へ陥っても、移行先Hub Bは運用可能で、Hub Aの休眠停止時にHub Bで投稿された情報はキューに登録され、Hub Aが復帰すると自動的に同期されます。

CloneはSub Account作成ではない

CloneされたChannelが内包するIdentityは同一のあり、全く別の登録情報を生成するSub Accountとは違います。

Sub Accountに近い概念はChannel(と内包されたIdentity)情報を複数作ることです。

ここまでの理解

つまりHubzillaではサーバをハブ、アカウントをチャンネルと呼び、チャンネルには個人を識別するアイデンティティ情報が内包され、Zotプロトコルで作られたグリッド分散ネットワーク内にある他のハブへチャンネルのクローンを作れば自動同期のバックアップが取れるというわけです。

更にクローンはいわゆる複アカでないことに注意が必要となります。

機能

Hubzillaには多くの機能サービスが提供され、その全体像を把握するのは非常に困難です。

Hubzilla標準機能サービスに加え、Hubに寄っては独自の拡張機能サービスが存在し、独自の拡張機能サービスはたいていの場合ほかのHubと互換性を持ちません。

以下にHubzillaが提供するいくつかの機能の解説を記述します。

ソーシャルネットワーキング

Hubzillaが提供する多くの機能の中で最も解り易い機能。

Hubzillaのソーシャルネットワーキング機能はFacebookに酷似しており、表面的には容易に理解が可能です。

Channelの作成

Channelは前述の通り、一般的なWebサービスのAccountと酷似しています。

Channelの閲覧制限

Channelは多くのソーシャルネットワーキングサービスのAccountと同様に閲覧制限を設けることが可能です。

設定できる閲覧制限は以下の通り。

  • 本人のみ
  • 特に許可されている人物のみ
  • アドレス帳に登録された人物のみ
  • このWebサイトのみ(同一Hub内の人物のみ)
  • Gridネットワーク上の人物のみ
  • 誰でも閲覧可能(Gridネットワーク外からのアクセス可)
  • インターネット上の誰でも

プロフィールの作成

Hubzillaでは一般的なソーシャルネットワーキングサービスと同様にプロフィールを公開することが可能です。

プロフィールにはプロファイルが設定可能で、デフォルトのプロファイルは一般公開プロファイルです。

プロファイルは自由にいくつも追加することが可能で、例えば友人向けのプロファイルを作成し、プロフィール内の趣味情報を一般公開プロフィールでは映画鑑賞とし、友人向けプロフィールではアニメ鑑賞とすることも可能です。

プロフィールプロファイルの存在意義はChannel(とIdentity)の濫造を防ぐことにあります。

一般的なソーシャルネットワーキングサービスでは、例えば職場用Account、友人用Account、趣味用AccountというようにAccountの濫造がされ易いですが、プロフィールプロファイルは閲覧するユーザ属性に合わせたプロフィールの変更を可能としており、Channel(とIdentity)の濫造を防ぐことが可能です。

既存のプロフィールプロファイルの一部を再利用したい場合、プロフィールプロファイルはCloneすることも出来ます。

友人・知人を追加

Hubzillaでは多くのソーシャルネットワーキングサービスと同様に特定のユーザを登録し、管理する機能が存在します。

Hubzillaで行なわれる特定のユーザの登録・管理は一般的なソーシャルネットワーキングサービスとは違いAccountを登録・管理するのではなくIdentityIDを登録・管理します。

つまり、登録・管理するIdentityIDが同一のものであれば、特定のユーザがHub Aで活動を行なっていてもHub Bで活動を行なっていても、IdentityIDへ指向したユーザの登録・管理はHub AとHub Bを区別しません。

これは例えばHub Aで許可された閲覧権限をHub BにCloneさえしていれば特別な設定なく同一の閲覧権限をHub Bで行使出来るということです。

投稿の閲覧権限

Hubzillaでは投稿毎に閲覧権限を設定することが出来ます。

設定できる閲覧制限は以下の通り。

  • 連合 連合が組まれているネットワーク全体で閲覧可。

  • ほぼ公的 Gridネットワーク上で閲覧可。

  • 制限付き 友人(もしくは設定された人物)のみが閲覧可。

Forum(フォーラム)

HubzillaではForumを設置することが可能です。

ForumはChannelとして設置され、それはForum Channelと呼ばれます。

Forumには権限を設定することが出来ます。

設定できる閲覧制限は以下の通り。

  • ほぼ公的 Gridネットワーク上で閲覧可。

投稿のすべては一般に公開し、Forum作成者以外のユーザが参加申請を行なうと自動的にメンバーとなれる典型的なForumです。

  • 制限付き

Gridネットワーク上で閲覧可。

投稿のすべては一般に公開し、メンバーになるにはForum作成者以外のユーザが参加申請を行いForum作成者の承認によってメンバーになれます。

  • プライベート

基本的に投稿のすべては非公開であり、メンバーになるにはForum作成者による招待が必要です。

Forum作成者のみが必要に応じて一般に公開する投稿を作成でき、メンバーは一般に公開する投稿を作成できません。

順次編集してます

順次編集を力尽きて辞めました・・・