  |
はてなキーワード: エンコードとは
NFTで管理された動画って、ダウンロードして再エンコードしたらバイト列が変わって、唯一性が保持されなそうだけど、なんでそんなにありがたがられてるの？
画像にしたって、NFTで管理された絵に1x1の透明なピクセルを追加して放流すれば、それはデータとしては異なるけど、「アート」としては同じものなんじゃないの？
アンダーソン・毛利・友常法律事務所の外国法共同事業パートナー弁護士の長瀬威志氏によると、法律上、NFTを購入したからといってその作品の著作権や所有権を取得したということにはならないとされています。
また、NFTに紐づいているアートなどの作品の画像自体は誰でもコピーして問題ありません。金融規制上の位置づけや、法的性質についてNFTはまだ問題点を多く残しています。
生配信における、会話の端々から漏れ出る中の人の人間性の表出。
その細かいキャラクター性も出来る限り設定にエンコードして、次の演者に受け継げばいい。
最近では12時間に及ぶこともざらな長時間生配信で演者が他人のキャラクター性・人間性を演じ続ける事を当然のように求めるのか・・・
いや無理でしょ
どちらかというと動画勢として活動することが多かったキズナアイやゲーム部プロジェクトでさえ中の人を交代や増加させたら大炎上したのだ。だが彼らもたびたび生配信を行い、コミュニケーションを取っていたからこそ受け入れられなかったのだと思う。
しかしキズナアイが幼い頃何をしていたとか、好きな漫画が何なのかとか知らないぜ？
キズナアイは終始、デジタルワールドにいる年齢4歳の性別なし AI として生きていて、生配信でそこから外れたことはないと思うんだけれど。
Vtuberファン側の解説はレアなので助かるが、しかし説明は的を外してると思う。
そこで、中の人が交代してしまうと、たとえ被っている絵やキャラクター設定が同じでも、リスナーが見てきた人格も記憶の連続性もないものになってしまう。それはすごく気持ちが悪い。何年も追ってきた人が、人格も記憶もないまま外見だけ同じになるというのは凄まじい違和感があるわけです。ゾンビを見ているような気分になる。おまけにコラボ配信とかでは他のVからは全くの別人格なのに「同じ人」として扱われてしまうとしたら、想像しただけでホラー映画なのだ。
バーチャルなんだから中身の実体人を取り替えてもいいだろう、いっそ本当に AI でもいいだろうと思うVtuberファンの俺からすると、この論は、人格の交代は違和感があってホラーだ、と感情を高ぶらせてるだけに過ぎないように見える。実際に生配信における人格の表出の齟齬を目撃したならともかく、中身が変わったという事実だけでなぜそこまで怖れるのか。
逆に「中の人」はそのvtuberと人格や記憶を共有しているわけで、それを全く別人とは思えるかと言ったら難しい。もちろんvtuberとして活動している間は綺麗な面だけ見せて演じていることくらいは分かるけど。それでもやっぱり絵や設定よりは人格の方に連続性を見たくなる。
なぜ見たくなるのか？ やはりこの部分も説明が欠落しているように思える。
以前、ネクロマンサーの設定を持つ Vtuber が「自分には霊感がない」と配信中に明言した事があって、俺は「えぇ…」と思ったけど、結局スルーされて騒ぎにはならなかった。
霊感がなくてもテクニックだけで死霊術は使えるのだ、みたいな解釈ができなくもないが、話題にならなかった事から考えると、設定の細かな差異も顔の違いと同じように重視しないリスナーが多いのは事実だと思う。しかしなぜ？
生配信における、会話の端々から漏れ出る中の人の人間性の表出。
その細かいキャラクター性も出来る限り設定にエンコードして、次の演者に受け継げばいい。
ミスで違和が生まれても、上手く解釈してリスナーの中で腹落ちさせてくれるはず。
バーチャルと銘打っているのだから、そのくらいは当然だと思うのだけれど…
さっぱり分からん。
クマが30匹程度では建設的と判定されないことがあるようなので、そんな時は
const MinimumRequiredLength = 30;
の部分を変えてみてください。
その際は、ドラッグし直すのでなく、
追加済みのブックマークレットを右クリック→「編集」で、30の部分だけ書き換えればOKです。
追記ここまで
https://anond.hatelabo.jp/20210803012020
に刺激を受けて作りました。
https://b.hatena.ne.jp/entry/4706344345181168386/comment/new3
で、書き込み時の自動クマ補完について書かれてたので、それを実装しました。
以下の文字列を選択して、Chromeのブックマークバーにドラッグしてください。
javascript:(function () { const MinimumRequiredLength = 30; const currentCount = Number(document.querySelectorAll(".js-bookmarkadd-comment-count")[0].innerText); if (Math.floor(MinimumRequiredLength / currentCount) !== 0) { const elem = document.querySelectorAll(".bookmarkadd-comment-form")[0]; if (elem.value.slice(-1) !== " ") { elem.value += " "; } const loopNum = Math.ceil((MinimumRequiredLength - currentCount) / 5); for (let i = 0; i !== loopNum; i++) { elem.value += "ʕ•̫͡•"; } elem.value += "ʔ"; elem.dispatchEvent(new Event("input")); } })();
「_5)」みたいな変な名前で追加されるので、右クリック→「編集」から好きな名前に変えてください。（addBearとか）
はてブのコメント書き込み画面でブックマークレットをクリックしてください。
これで追加したクマを、コメント一覧画面で削除するためのブックマークレットは、
javascript:(function () { document.querySelectorAll(".entry-comment-text").forEach(function (e) { e.innerText = e.innerText.replace(/[ʕ•̫͡•ʔ]+$/, ""); }); })();
です。
セットでお使いください。（名前はremoveBear？）
私はクマで埋めることはしないのですが、埋めたい人もいるでしょうから、道具としてはあればよいと思いました。
最後のクマだけ左頬のパーツを変えて……、など10秒くらい掛けてると思うのです。
その間、「ああ……またこんな作業をして……私ったら承認欲求の塊なのかしら、いやらしいわ」と自己嫌悪してたら可哀想なので、
少しでもネガティブな時間が短くなるよう、活用してみてください。
1についてだけ。
＞分かるけれどこれでどうやって動画や音楽のエンコードをしたり画像処理をしたりするソフトウェアになるのか
エンコードに関してはプログラムはエンコードの理論に従って作られているだけ。大事なのは研究者の考えた理論
画像処理は定型の処理の塊でこれも代替やり方は決まってる。"python 画像処理"とかでググれば多分出てくる
＞あるいはWordとかExcelとかがどうやってこんなので作られているのかが分からない
まず基本的な、ウィンドウシステムがどのように実現されているかをWin32アプリベースでも
よいので理解するべき。ユーザーのマウス操作、キーボード操作をどのようにプログラムが認識し、
処理するかが理解できる。この仕組みは基本的にすべてのアプリで共通と思われ。
＞プログラミング入門書を読んでも、一般的に知られているソフトウェアの作り方みたいな事が書いてない
多くの人が共通的な作り方に挑み敗れているわけで、プログラムは10個あれば10通りの作り方がある。
また、クラスレベルで抽象化してソフトウェア構造を整理しようとする、オブジェクト指向(最近は
クリーンアーキテクチャに昇華させる流れもあり)もあるけれど、オブジェクト指向に向かない
対象領域があったり、なんでもクラス病にかかる等して、銀の弾丸とは言い難い。
また自説だが、順次処理を基本とする、手続き型言語はデータと処理が入り乱れることになるため、
全てを設定しきることが極めて困難なため、きれいにすべてを設計するのであれば関数型言語を使う必要が
あると感じている。
＞だからそのフレームワークがどういう風になっているのかって説明からして欲しいって思う。
そのフレームワークが内包するベストプラクティスの量を鑑みれば、中身を意識せずに
＞つまり言いたいことは、実際に動くアプリケーションというのを作りたいのにも関わらず
＞プログラミング入門書は、これで判定と繰り返しという基礎ができますと言うだけ。
＞これがもう滅茶苦茶イライラする。
天才的な人はコードを書きながら、考えられるけれど、常人はまず詳細設計と言われる
フローチャートを書けるようになったほうがよい。
次に"抽象化"を覚える。"抽象化"を使うことで少なくとも、処理は全体をざっくり設計できる
＞つまり完成しているプログラムを参考にしようと思っているにも関わらずそれがないのでよく分からない。
githubに山のように転がっている。
ただそれを見て理解できるかは別問題。モチベーションを保って継続学習可能な形に
消化できる人間の登場が待たれる
「 ①IFでAかBを選択させてどっちかの設定を実行
②Whileで決められた回数分繰り返す
これでやりたいことは分かる。分かるけれどこれでどうやって動画や音楽のエンコードをしたり
画像処理をしたりするソフトウェアになるのかというのがよく分からない。」
プログラミングでやることは、その２つだけじゃなくて、もうひとつある。
③関数を呼び出すこと
Javascriptなら、console.log("Hello world")。
これは、テキストを出力するという関数を呼び出していて、関数の内部を理解しなくても使える。
オブジェクト指向も、結局はこれと同じこと。あらかじめ用意されている関数・メソッドを呼び出せばいい。
これは、大きなゲーム作成専用ライブラリで、ゲームを作るための大量のメソッドを持っている。
プログラミングで主にやる事は下記の2つ。
①IFでAかBを選択させてどっちかの設定を実行
②Whileで決められた回数分繰り返す
とてつもなく複雑で冗長な処理によって実行されている。
わかりやすいので画像処理でいうと、数十万から数百万の画素（RGBAの24bitで表される数値）を小さなブロックに分解し、数学的に周波数の重なりとして計算して変換、含まれる頻出パターンをテーブルにして圧縮伸張を行なう。みたいなことが瞬間的に行われている。
「まさかそんな事できるわけないだろ」というレベルの処理が実際に行われており、これまた直感的でない。
だからそれをどう書くんだよ。という答えはコレ。有名なjpegの実装だ。
libjpeg というライブラリを書くことはできるだろうか？画像の圧縮の理論から考え始めることはできるか？
正直無理だ。自分はプログラマだがそんなに数学が得意ではなく、頑張ったとしても下手するとコレを作るのがライフワークになってしまい、他のことができなくなる。
例えばブラウザを0から作るとして、jpegの処理以外にも画像だけでpngとかgifとかwebpとか、その他もろもろとてつもない作業が必要になる。
「とてつもなくて想像もできないので流石に無理だろう？」
いや、でも、実際動いてるのよ。ここ何十年、コツコツと積み重ねて実現している。
「積み重ね」とはライブラリであったりフレームワークであったりOSであったりする。
「どういう風になっているのか」
外部に向けたインターフェイスがどうなっているのかは理解する必要がある。「使う」ために必要だからだ。
この2つは分けて考えなければならない。
ちなみに、たとえばChromeのコアであるChromiumはのコードはコレだ。
つまり言いたいことは、実際に動くアプリケーションというのを作りたいのにも関わらず
プログラミング入門書は、これで判定と繰り返しという基礎ができますと言うだけ。
これがもう滅茶苦茶イライラする。
「これで判定と繰り返しという基礎ができます」というのが基本的な理論（定理的なもの）で、その他に必然的だが唯一無二ではないベストプラクティスというものがある（法則的なもの）。
後者をうまく説明する入門書に出会っていないんだろうな。という印象。イライラはやめよう。つかれる。
ベストプラクティスはいろいろあるのだが「層の構造にする・レイヤーに分ける」というのは重要なアイデアだ。
libjpegというのはjpegの処理を行う「ライブラリ」だ。他のアプリケーション...たとえばブラウザはこのライブラリを「使う」。
ブラウザではjpeg画像の圧縮展開というとてつもなく難しい処理を「libjpegの使い方」の理解までで済ませ、過去の蓄積であるlibjpegのコードを利用することで真の意味で0から実装しないようにしている。
この場合、libjpegが「低レベル・低レイヤー」の存在であり、中身については「使い方」つまり「仕様」の理解までしか行わないことで、実際に作りたいものを作れるようにしているわけだ。
完成しているプログラムは二例ほど挙げたがどうですかね？
複雑なことをする、特に低レイヤーのコードはとてつもなく難しい。
でも、とりあえずこんな感じのコードなら解るよね？
こういうレベルから理解して、ちょっとずつ難しい処理を学んでいくしかない。
ハードルは高いんですよ。実際。
なので、木材からだと難しいからプレハブのキット的なものを探すとか、ログハウスのカタログを読むとか、あるいは100人乗れる物置を買うのがいいかもしれない。そういうところから始める。
それらがフレームワークであったりライブラリであったりする。目的に合うものを探して、自分がやりたいことをどう実現するかとにかく考える。
「テキシコー」https://www.nhk.or.jp/school/sougou/texico/ で言われる通り、「小さく分けて考える」「手順の組み合わせを考える」「パターンを見つける」「大事なものだけ抜き出して考える」「頭の中で手順をたどる」をひたすら実行する。
unityはコードが公開されているので、本当に読みたいなら。。
オブジェクト指向は一旦忘れよう。
オブジェクト指向の「隠蔽」というのは層の構造が持っている重要な要素ではあるけど、「低いレイヤーについて考えない」のが基本的な作戦だという理解の方が重要だ。
前述の通り「できる限り作らない」んですよ。「使う」だけ。知るべきことを最小化する。
そして本当に作るべきものに関しては、利用する下のレイヤーのライブラリなりを探して・仕様を理解して、どう組み合わせてfor, if, あるいは計算させれば実現できるのかをひたすら考える。
単に翻訳がしたいのか？表示に割り込む方法を知りたい？日本語に翻訳するのは実行時なのか開発時なのか？
要求される表示エリアが言語によって異なるために、デザイン調整が必要になる問題をどうするか？
分解が甘いので何をしたらいいか調べることができないんだと思う。
ちなみに、アプリ内の文言というのはアプリの外部から変更できないように実装されている事が多いので、利用者が上書きする仕組みはかなり難しい。
AndroidなりiOSの仕様にもそのへんに割り込める機能はないはずなので、OSの開発に入っていく必要がある。結構大変だとおもう。
アプリの開発者が、そういう機能を備えた多言語化のためのライブラリを使うようになれば実現可能ではあるので、そっちの方向で頑張るのがおすすめだが、英語圏の開発者には多言語化のモチベーションが低いという基本的な問題はあるのよね。
この辺の「できる・できない・むずかしい」の判断は、いろいろな勉強をすると常識としてある程度みえてくる...気がする。
ついでに。ウェブサイトやウェブサービスの翻訳だとこういうサービスがあったりする。
ブラウザはページの描画処理のなかに割り込む余地が大きく取ってあるので、ブラウザのExtensionとかならできることがいくらかあるかもしれない。
個人的に気に入らない話はOSのアップデートは使いやすくなるからとてもいい事だからすぐにやった方がいいと宣伝されている事。
まあ、半分は嘘だよね。古いものが残っていると先に進めないんだよ...。
現在のクライアントOSは、巨大なプラットフォームのパーツの一部として理解したほうが正しくて、古いパーツが残っているとツライんですよ。
そして「サービスを受けるための道具であって、あなたが何でも好きにできる機械ではないです」みたいな世界になりつつあって、ちょっと問題と言われてもいる。
これはかなり困った傾向なんだけど、全体としての流れはあんまり変わりそうにない。
オブジェクト指向好きですな...。ここではオブジェクト指向は特に気にしなくていいですよ。
とてつもなく複雑なことをやっているために、すべてのバグを潰すことはコストが高すぎてできないんですよね。
それよりバグは未来を先取りするコストと考えて、本質的に価値のある機能を増やしていくというのが基本的な方向になっている。
だからパソコンはたまに不具合を引き起こすんです。しゃーない。
しかし中途半端に理解している老人などは、そんなことじゃ分からん。自分に分かるように説明しろと言い出す。
説明は出来る。しかし相手はイライラするし理解されない。よって説明をしてはいけないという状況に追い込まれる。
ここでどうすればいいのだと理解不能に陥る。
まあ、説明って得てして難しいよ。しゃーない。
そのとおりです。
オープンソースのプロダクトなら原理的には調べられるけどね。Androidとかはオープンになってる。
それを許容することで先に進んできているという事実は受け入れたほうがいいと思う。
「把握・理解可能な範囲」に留めていたら、数十年前のコンピュータの世界から抜け出せなかった。
deep learningの世界ではそれがより一層進むかも。この辺は詳しくないけど。
ここでの「理解」についてはそのとおり。これはもう諦めるしかない。
これが常にある。IT関連は常に新しい情報が出てくるのでそれに送れると無知になってしまう。
なんでこんなことも分からないんだとか言われ放題で、IT系の企業に努めている人は常に新しい知識を入れられる
面倒くさがらない人が向いている。
「面倒くさがり」の方が問題に気づいて「頑張って面倒じゃなくする」ことができるので、プログラマにとっては美徳なんて言われますけどね。
同時にくじけないとか諦めない、しつこいみたいな素養は必要かも。
応用まではとろうな。がんばれ。
このへん自分も知らんですよ。べつに全部知っている必要はない。
（追記: はてな記法の引用すらもさっきまで知らなかったしな！そんなもん）
層の構造をとっているということと関係があるんですが、仕様が変わると、その上に乗っているものを全部なおさないといけないんですよね。
でも革新のために互換性を捨てなければいけないケースも多い。このへんはハードでもソフトでも同じ。
そして、メンテのコストが上がっても使い続けたほうがトータルで安上がりという場合は、古いものが残ってしまう。
あるいは「（多少の問題はあっても）動いているものは変えるな」という経験則から意図的に残す場合もある。
西暦2020年にもなって、プログラミングが簡単には出来ないし、ハードウェアの規格も完全に統一はされていない。
というかプログラミング言語自体多すぎる。ソフトウェアはデファクトスタンダードのモノ程度は知っているが、
ぜんぜん完成していない荒っぽいものを目にしているのだと理解したほうが的確。
それなのに毎日理解のできないパソコンやスマートフォンを使っている。
オブジェクト指向のおかげ様だがオブジェクト指向に対して無性に腹が立つ。
自分の全く知らない場所でいけしゃあしゃあと演算を行い、そして結果を出す。それも大半が正しい結果で
利便性が抜群だ。些細なミス(バグなど)はあるが圧倒的に利便性が勝っている。
そんな道具に踊らされている自分が滑稽だ。理解できない愚かな自分は正に機械の奴隷のようだ。
本当に理解できない。辛い。
勘違いしてはいけないのは、それらはすべて先人の努力の蓄積によって成り立っているということ。
「よくわからないけど存在している道具」ではなくて、信じられないほど複雑だけど、多くの人々の行動によってなんとかかんとか実現した道具なんですよ。
「オブジェクト指向のおかげ様」じゃないんです。（もちろんオブジェクト指向というのも大きな発明の一つですが）
そしてブラックボックスとして使うのは多くの場合正しいです。そこは諦めましょう。
でもエンジニアとしての立場からは、その裏に隠れているとてつもない技術や思考の蓄積に感動してほしいなと思う。
人類がこんなもん作れたのって、かなりすごいよ？
（追記）
ttps://agk.saloon.jp/how-to-jp-series
結論をいうと対象のソフトが下記を満たすかどうかで難易度がかなり変わる。
1. 表示テキストが外部ファイルになっている or exe内部のリソースファイルから読み取られる ↔ プログラム埋め込み
2. 内部のテキストエンコード方式がUTF-8 or 16 or 32 ↔ ASCIIなど
3. フォントはシステムにあるのが使われる ↔ 外部ファイルになった画像フォントが使われる
すべてのソースが公開されていない限り、この条件を満たさないものは基本的に日本語にできない。
例えば、自分でC言語でprintfだけのHello world!プログラムを作ってみて、それをソース無しで、外からテキストを変更できるかためしてみればいい。
これは１に反するから多分簡単には出来ない。よしんば出来たとしても、Hello world!より文字数が多いテキストに変えるのはそれなりに面倒である。
こういう表示をさせるやり方としてはprintfに渡すデータを実行時にすげ替えればいい。具体的にはprintfの直前で別の箇所にジャンプさせて引数のレジスタに書き換えたいアドレスを渡して、またprintfまで戻ってくればいい。
これ以上に面倒なのが、2と3が合わさったもので、欧米はアルファベットしか使わないため、ソフトの内部コードがASCIIやCP12XXだったりする。さらにそのソフトに用意されているフォントの文字はその範囲しか存在しない。これらはどう頑張っても普通には日本語を表示することは出来ないので、かなり強引に改造するしか無い。俗に中華パッチと呼ばれているものがそれである。
具体的にはソフトのどこかで、表示させるテキスト配列から文字を１文字取得、１文字からコードポイントに変換、フォントファイルからそのコードポイントのグリフデータを取得、グリフデータを画面に表示させる処理があるため、そこに割り込む。１バイト取得している箇所を２，３バイト一気に取得して、それをなんとかしてコードポイントにして、そのコードポイントをグリフ取得の処理に回せばいい。
例えば、サンプリング定理（標本化定理）を知らなければ音声の録音も圧縮も理解できないのは当たり前。
だから、大学で情報科、もしくは電子工学や機械工学を履修するのは無駄ではない。
日本の専門学校だと給与が安い仕事の即戦力になるようなカリキュラムになりがちだから。
（専門学校が扱う職業のラインナップを見ればそれは明らかだと思う
乱暴に一言で表現するなら、この世のすべてはビット、つまり0と1で表現できてしまう。
例えば小数点以下無限に数字が続くような数字は、言い換えれば無限に情報が必要ということになる。
メモリは有限だし、たった1つのそんな感じの数字を記憶するためにどんな巨大なメモリも埋まってしまうのでは意味がない。
だから、コンピュータで浮動小数点を表現する場合、どこかで足を切らなければならない。
それによって、紙で計算すれば問題ないことが、コンピュータではおかしな結果になることがある。
しかし、これを知っていなければ科学計算はもちろん、銀行のようなお金の計算もおかしな結果になってしまう。
大学で数値計算の授業を取得するのは退屈だが、これを理解してなければ社会に出ても間違ったコードを書いてしまう。
というか、私も大学在籍中に間違ったコードを書いたことが何回かあるｗ
その原因は根源的で哲学みたいな話で、
世の中のほとんどの物事には正解がないとか、そういう話にしかならない。
良いテキストはあるわけだけど、それを読むべきタイミングもあるし、万人向けが自分に向いてるとも限らない。
本なら何冊かはドブに捨てるつもりで買うしかない
みんなが良いから読めという本も、なんとなく自分にはこれがいいんじゃないか、も買うしかない
買って家でじっくり読んで、途中でナニコレ？みたいな本だったら後悔するかもしれないけど、世の中そういうもんだから。
自分はレシピ通りに作らないでヒントにしかしないタイプなのだけど、
焼く、炒める、煮る、蒸す、みたいな方法だけ理解していれば味付けなんて適当でいいのだ。
なんらかの魚があったとして、それは食べられる魚だと分かっているが調理方法はまったく知らなかったとする。
どうするか？
とりあえず、まず口に入れられるサイズに切るべきだろう。
口に入れられないと食事にならんのだから、魚を切って骨を取る。
さばき方もググれない状況なのだから、もう適当に切断していくしかない。
鱗も大味で取るしかない。
ググらないと、とんでもないほど非効率的なさばき方をしている可能性があるが、とにかく食えればいいのだ。
腐らせては意味がない。
日本の刺身みたいな生で食べる文化はイヌイットではないが、漁師が船の上で食べることとも関係しているように思う。
何が言いたいかというと、生食は現代文明のロジスティクスは保存技術の成せるわざであって、料理の基本は何でも熱を通すべきなのだ。
切った魚を、焼く、炒める、煮る、蒸す、みたいな方法で熱を通せば料理は終わりだ。
