Movatterモバイル変換


[0]ホーム

URL:


はてラボはてな匿名ダイアリー
ようこそ ゲスト さんログインユーザー登録

「可逆圧縮」を含む日記RSS

はてなキーワード:可逆圧縮とは

2025-04-25

Web∞(ウェブインフィニティ

1.根本原理 ――「状態」よりも「関係」を記述する

旧来(Web3)Web

グローバル単一台帳(Blockchain/DAG)相互検証可能な“関係グラフ

ノードは「だれが・いつ・どうつながったか」という変化の射だけを署名し、トポロジ全体が履歴になる

オンチェーン状態 ≒ 直接資産状態ローカル資産導関数

資産契約は、関係グラフ上の経路依存量として再構成スナップショットクライアントが“可逆圧縮”で再計算可能

Proof of X (Work, Stake,etc.) Proof of Stewardship (PoS²)

ネットワークが望ましい 複雑性 を維持するよう行動した度合い」をメタリック関数で動的スコア化し、報酬ガバナンス権・帯域を同時に発行

要旨

もはや「台帳」すら保存しない。各エッジは STARK圧縮された更新証明を持ち、グラフの梁(フレーム自体履歴になる。再構築は局所的に O(log N) で済むため、グローバル同期のボトルネックが消える。

2.プロトコル

Fractal MeshTransport (FMT)

自己類似ルーティング – トポロジ全体をフラクタル自己複製。局所障害は“自己相似”パターンに吸収されるため、DDoS が形骸化

アイデンティティ内包アドレスDID楕円曲線座標に埋め込み、パケット自体署名暗号化ルーティングヒントを同封。IPv6 の後継としてレイヤ 3.5 に位置づけ。

HoloFabric Execution

ゼロ知識 WASM(zk-WASM) –任意言語を WASM にコンパイル→ zk-STARK で実行トレース証明 → “結果のみ”関係グラフへ。

コンパイラ内蔵 MEV抑制計算結果が他ノードから解釈不能になるタイムロック VDF を伴い、価値抽出物理的に遅延。

TemporalStream Storage

余剰ストレージの“時価マーケットノード自己の余剰SSD/HDD を分単位オークションデータは Reed–Solomon+重力波ハッシュ空間で erasure coding。

リテンション ≒ 信用 – 長期ホスティング実績はPoS²スコアへ累積。攻撃ノード経済的に即時蒸発

Liquid Fractal Governance

議決トピックを「周波数帯」にマッピングし、参加者は帯域を“委任スペクトル”として分配。結果はウォルラス圧力収束し、マイナー意見連続的に次回へ重みが残る。

3. 主要イノベーションと“上位互換ポイント

課題Web∞ が取るアプローチ上位互換

スケーリング三角形

安全分散・性能) 台帳の排除で“グローバル合意自体縮退スケール制約が幾何的に消失安全:ZK証明

分散フラクタル Mesh、

性能:局所再構築 O(log N)

エネルギー消費PoS² は「社会的有益度 × 熱消費効率」で算定。熱回収データセンターほど報酬が高いPoW よりオーダー数桁効率PoS より社会関数内包

プライバシー vs 透明性グラフは公開。ただし各エッジは zk-STARK なので内容は非公開 /関係のみ検証可能トレーサビリティが“情報理論的に”限定される

MEV・フロントランタイムロック VDF+“ランダム束縛順序”で物理的に不可ブロック順序依存問題を根絶

量子耐性 STARK 系 + 多変数格子ベース署名 Shor破壊リスク遮断

レガシー互換 Ethereum,Bitcoin, IPFS などへ 1:1ブリッジを Rust/WASM で提供既存資産を損なわず漸進的移行

4.インセンティブエコノミクス

マルチリソース報酬

Steward Credits (SC):PoS² に比例し新規発行。帯域・ガバナンス票・ストレージ予約を等価交換

Energy Reclaim Units (ERU):余熱回収率に応じてクリーンエネルギー補助金相互運用

Knowledge Bounties (KB):AI/LLMノードが生成した有用モデル差分関係グラフコミット検証トークンとしてKB が発行。

負荷の自己調整

ネットワークが過度に混雑するとSC新規発行レートが自動減衰し、トラフィック手数料指数的に上昇。結果、スパムは短時間経済的自殺となる。

5.実装ロードマップ(想定)

Year 0–1:最小核 – zk-WASMVM + Fractal Meshover QUIC。

Year 1–2:PoS² / ERU メトリクス実証、EVM相互運用ブリッジ稼働。

Year 2–4:Liquid Fractal Governance によるプロトコル進化コミュニティへ全面開放。

Year 5+:全世界ISPピアリング既存Web転送層を徐々にWeb∞ 上へマイグレート。

6. 予想される社会的インパクト

国家単位デジタルソブリンティ再構成国境法人格境界を越え“関係”が一次元目となるため、規制枠組み自体協調フィードバックモデルへ。

プライバシー公共性の再両立:透明な“関係構造”上で非公開データ安全に扱う産業API標準化医療行政金融の壁が大幅に低減。

インフラの脱炭素最適化PoS²スコアに ERU が直結することで、再エネ比率が低いノード自然淘汰エネルギー政策ITインフラが実質同一の経済圏に。

7. まとめ

Web∞ は「情報状態」を残すのではなく「変化の証明」を残す。

その結果、台帳の重力・ガス代・フロントラン・量子不安ガバナンス停滞といったWeb3 固有の限界が、概念的に初期条件から消滅します。

エネルギープライバシー・スケーラビティを同時に極小化/極大化するため、従来トレードオフと呼ばれた三角関係は “収束しない曲線” へと畳み込まれる――それが本構想の核心です。

もし実際にプロトタイプ設計するならば、zk-WASMランタイム + Fractal Mesh を Rust で最初に書き起こし、PoS² の初期指標を「再生可能エネルギー電力比+ノード稼働継続率」で暫定運用する、というのが現実的スタートラインになるでしょう。

Permalink |記事への反応(0) | 10:28

このエントリーをはてなブックマークに追加ツイートシェア

2023-03-09

anond:20230309170116

可逆圧縮だったか

Permalink |記事への反応(0) | 17:08

このエントリーをはてなブックマークに追加ツイートシェア

2022-01-20

anond:20220120083236

可逆圧縮すら、何かしら情報が欠落している可能性を捨てきれない。

無修正AVにすら、ぼかしが入っていたし。

Permalink |記事への反応(1) | 08:43

このエントリーをはてなブックマークに追加ツイートシェア

情報系詳しい人なら

そもそもJPEGですら補完してるから本当の情報かどうかは分からないってのを知ってるはず

AI超解像は流石にやり過ぎ感あるけど

真に信用できるのは可逆圧縮のみ

Permalink |記事への反応(1) | 08:32

このエントリーをはてなブックマークに追加ツイートシェア

2020-06-03

マジでキチガイじみてるからやめろ→マジキチマジでキチガイ

略した結果意味が抜け落ちるってなんだよ可逆圧縮しろ

Permalink |記事への反応(2) | 12:57

このエントリーをはてなブックマークに追加ツイートシェア

2018-11-20

anond:20181120213253

圧縮圧縮ならともかく

可逆圧縮非可逆圧縮を聞き分けられるとはかなりの達人だな

Permalink |記事への反応(0) | 21:37

このエントリーをはてなブックマークに追加ツイートシェア

圧縮音源で音質が悪化するとか言ってるバカに物申す

かに音が違うのは分かるよ

聞き分けることも出来るよ

だけどさ、なんで悪化するって決めつけてるんだ?

音質なんて個人の好みに過ぎないのだから可逆圧縮が好みのやつもいれば非可逆圧縮が好みのやつもいて当然だろう

それを音が変化するというだけでクソゴミ扱いするオーオタは馬鹿か?

Permalink |記事への反応(4) | 21:32

このエントリーをはてなブックマークに追加ツイートシェア

2017-05-20

http://anond.hatelabo.jp/20170520011248

CD屋さんはばたばた閉店してるので見つけにくくなってるかもなあ。

私が働いてた当時は30店舗あったCD屋チェーンも今じゃ1店舗を残すばかり。

地道に検索でもして探してください。どこに住んでるかわかれば探してあげられるんだけど。

不勉強でして可逆圧縮音楽データを売ってるところは知りません。

私は基本iTunesで、iTunesが扱っていない時にAmazonMP3を使います

いずれもビットレート256kbps不可逆ですが、常人が生CDと聴き分けられるとは思いません。いい音ですよ。

データ売りがまったくないものAmazonCD注文。

東京都下在住ですが地元の駅にCD屋が残っているかどうかすら把握してません。

Permalink |記事への反応(0) | 01:45

このエントリーをはてなブックマークに追加ツイートシェア

CDってどこで買えばいいの?

普段音楽youtube自動再生作業用BGMとか流しっぱにしてるだけ

だけど、気に入った曲あったのでCD買ってみようかなと思った

CDはそこまで買う方じゃない

これまで年に2つ3つ買うかどうかくらい

買ったのもyoutube で見つけたのとか、やったゲームで気に入った主題歌サウンドトラック

その辺のCDショップなんか言ってもまず置いてないしAmazon で頼んだ

今回のはけっこう一般的もの

JPOPでいいのかな

なので久々に直接店で買ってみようと思った

思ったのはいいけど、ここ数年CDショップをほぼ見ない

一応都会に住んでるんだけど、駅とか賑やかなところ言ってもCDショップは見ない

ここ数年で見たのは、ちょっと田舎の方のイオンに行ったときタワレコ

それと地元TSUTAYAみたいなところのレンタルコーナー

でもここ少し前のリニューアルマンガレンタルばかりになってCDがなくなったかもしれない

今ってCDを買うならどこがいいの?

というか店ってまだ生き残ってるの??


それともうひとつ

データで買うならどこがいいの?

これまでCD自分リップするのがメインでデータで打ってるのは買ったことなかった

最近電子書籍音楽聴き放題サービスなら耳にするけど、単体で音楽を変えるサービスって特に聞かない

条件は

↑この2つさえ満たしてればいいんだけど

知ってるのはiTunesAmazon くらい

iTunesアップル製品使わないから使わないし、

Amazon だとKindleの画質みたいな感じで音楽も音質イマイチそうという偏見がある

みんなどこで買ってるのー?

オススメぷりーず

追記しました

アドバイスありがとうございました

今日はお出かけしてきて、そのとき駅の近くでたまたま売ってるのを見つけて今回の目的は達成できました

最近は驚くくらいにアニソン割合が多いですね

毎回遠出したときに買うって言うのもアレなので出来る限り近くで行きつけみたいなところが欲しいところ

地道に検索でもして探してください。どこに住んでるかわかれば探してあげられるんだけど。

たまにしかCD買わない分知ってるCDショップ名前が少なすぎて、なんて検索すればいいんだ?、っと思って増田聞いてみました

ネットに詳しい住所書くのは怖いのでやめておきます

ただ一応都内

ほとんど行かないけど、新宿池袋渋谷秋葉原など行こうと思えばそこまで苦労しないところ

だけど問題交通費CD1枚のためにそこまでいくと、Amazonで買うより1.5倍とか?になってしまうんですよねー

Amazonは256のMP3なんですね

参考になります

いまはAmazonのほうがいいかな。iTunesはなんか使い勝手も悪いしソフトが重すぎる

なるほどー

参考になります

CD普段渋谷GUHROOVYってお店で買ってる

GUHROOVY・・・ 初めて聞く名前

渋谷に行ったときにはよってみようと思います

Permalink |記事への反応(3) | 01:12

このエントリーをはてなブックマークに追加ツイートシェア

2016-05-13

http://anond.hatelabo.jp/20160513174929

iTunes なんかは初期設定のままなら、可逆圧縮コーデック使ってないか

Permalink |記事への反応(1) | 18:37

このエントリーをはてなブックマークに追加ツイートシェア

2016-04-19

カセットテープを大量にデジタル化した時のメモ

色々あって大量のカセットテープデジタル化した時のメモ

なお音質は特段こだわりはなく、数を取り込んだ話です。

再生機器や録音機器

再生機器NR付きの方が後々楽(後述)。

録音形式はある程度の音質で取り込んでしまえば後で加工してしまえばいいのであまり考えない。

音質云々は割愛

後処理

曲分割

ある意味一番時間がかかるのがここ。

NR付きの再生機器ならテープ録音状態によっては機械的に分割処理かけてしまえば簡単に綺麗に分けられる。

ただこれが使えないテープ場合手動で分けることになるがこの場合大変。

このとき必要なのは時間だが、古いと曲名だけで時間は意外と載ってなかったりする。

最近Google先生が気を利かしてくれて、そこそこ有名だとアルバム名で検索すると曲時間が簡単に出てきたりする。

この情報経由で動画等を検索できる便利な情報だが、この表示されている時間情報動画時間から自動生成されているらしく偶に変な情報があったりする。

タグ付け

これが面倒かというとそこそこ有名な曲ならば簡単だったりする。

対象の大半がCD化もされているような音源だったので(ならデジタル化する必要は?とは言わないで)Gracenoteのデータベースを引っ張ってくれば簡単。

今は既存音源からでも検索がかけられるので、適当アルバム単位検索すれば大抵引っかかる。

自分場合この作業にはMedia Goを使っているが、そのままだと引っかからない場合でもアーティスト名やアルバム名のタグ情報を入れて再検索をすればまず存在する。

言語で出ている作品場合、別言語タグ情報に書き換えて検索すると引っかかったりもする。

またGoogle Play Music場合、あちらでデータがない曲で一度間違ったタグ情報で上げると記録されるのでタグ情報を書き換えてアップロードしてもそのままでは反映されないので注意。

ノーマライズ

後でバッチで一度に処理すれば良いという考えで保存用に関しては特にこの処理はしない。

保存等

現代HDDBDなら、FLAC可逆圧縮でもかけておけば一本辺り200MB~500MB程度と大した容量にならないので普段用と別に保存してても大して逼迫しない。

これが今デジタル化しようとしたきっかけの一つ。

保護にはBDならMultiPar等でパリティを付けて保存、ディスクの保管はBD対応した不繊布でもいいが数百本取り込んでも数枚程度なので転写が嫌ならハードケースで保存してもスペースには問題ない。

BDは今のベアディスクタイプですら10年近く経った規格でそれなりに成熟していると考えられるのと、かなり減ってきたがまだ地方だと相次いだメーカー撤退による投げ売りが偶にあるのでネットで買うより処分品狙いで買ったほうが安かったりする。(狙い目はDVDレンタル店)

流れ作業で行う場合

データとともにカセットテープのケースやインデックスカード画像データを保管しておくとアルバム名等を確認する際に現物をいちいち確認する手間がなくなるので捗る

またミスで再取り込みになった時も画像を手掛かりに現物ピックアップできる。

カセットテープ本体はCISスキャナしかない場合取り込みは困難なのでインデックスカードだけでも取り込んでおくだけでもいいが、その場合音声データを取り込む前に本体のラベルインデックスカードが正しい組になっているか確認したほうがいい。

ただ単純なインデックスカード場合スキャナドライバの性能によるがそこまで面倒ではないものの、特別意匠をこらされている場合この作業は凄まじく面倒になる。

結論

自分のような勿体ない症のような人以外は特別もの以外はカセットテープデジタル化は止めておいたほうがいい。

Permalink |記事への反応(0) | 00:38

このエントリーをはてなブックマークに追加ツイートシェア

2012-05-04

http://anond.hatelabo.jp/20120504015320

映像可逆圧縮は無理だろ。いくらなんでも容量が足りない。

Permalink |記事への反応(0) | 02:09

このエントリーをはてなブックマークに追加ツイートシェア

2012-05-03

http://anond.hatelabo.jp/20120503020747

よく知らんのだが、じゃあDVDを「D4からのアップコンバート」したBDと同等の画質で鑑賞する手段ってあんの?

あと、

それに非可逆圧縮の奴が販売されてるのにはかわりがない。

そもそも映像メディア可逆圧縮方式で販売されてた事ってあったの?

Permalink |記事への反応(1) | 02:23

このエントリーをはてなブックマークに追加ツイートシェア

2011-10-15

生で

いい加減mp3だのaacだの、劣化した音楽を販売するのはやめて欲しい

無圧縮の音源クリエイターけが吸える甘い蜜だとでも言うのか

アーティストたちは彼らに聴かせるために音楽をやっているのかと問いたい

圧縮したければこっちで勝手にやるから、せめて可逆圧縮形式で販売を!

Permalink |記事への反応(1) | 19:20

このエントリーをはてなブックマークに追加ツイートシェア

2008-06-23

http://anond.hatelabo.jp/20080623004418

同じだけのデータサイズに収録できる情報量は、どういうサンプリングの仕方をしたって同じでしょ

24bit96kHzと16bit44.1kHzではデータサイズが違う。画像で言えば解像度の違いってところか。

そんで、同じ形式の生データならともかく、圧縮するのであれば、アルゴリズムによって同じデータサイズでも情報量は変わるでしょ。可逆圧縮の例の方が解り易いけど、zipよりもbz2の方が圧縮率は高くて、1MBのzipと1MBのbz2を解凍したら後者の方が大きいものが入ってる(だろう)。

10MBの画像データ(tiff)があって、それを2.5MBに収めようと思った時に、tiffのまま解像度を半分にする(ピクセル数を1/4にする)か、JPEG2000で圧縮するか。後者の方がたぶん綺麗だよね?

2.5MBに成るように解像度を下げたファイルをさらにJPEGで圧縮したら、2.5MBtiffよりも画質が悪いのは当然だけど、10MBtiffを2.5MBにJPEG圧縮したなら、そっちの方が2.5MBtiffよりも綺麗(なはず)。

Permalink |記事への反応(0) | 08:08

このエントリーをはてなブックマークに追加ツイートシェア

 
ログインユーザー登録
ようこそ ゲスト さん
Copyright (C) 2001-2026 hatena. All Rights Reserved.

[8]ページ先頭

©2009-2026 Movatter.jp