
はてなキーワード:可逆圧縮とは
グローバル単一台帳(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
議決トピックを「周波数帯」にマッピングし、参加者は帯域を“委任スペクトル”として分配。結果はウォルラス圧力で収束し、マイナー意見も連続的に次回へ重みが残る。
(安全・分散・性能) 台帳の排除で“グローバル合意”自体を縮退 ⇒スケール制約が幾何的に消失安全:ZK証明、
エネルギー消費PoS² は「社会的有益度 × 熱消費効率」で算定。熱回収データセンターほど報酬が高いPoW よりオーダー数桁効率、PoS より社会関数を内包
プライバシー vs 透明性グラフは公開。ただし各エッジは zk-STARK なので内容は非公開 /関係のみ検証可能トレーサビリティが“情報理論的に”限定される
MEV・フロントランタイムロック VDF+“ランダム束縛順序”で物理的に不可ブロック順序依存問題を根絶
量子耐性 STARK 系 + 多変数格子ベース署名 Shor破壊リスクを遮断
レガシー互換 Ethereum,Bitcoin, IPFS などへ 1:1ブリッジを Rust/WASM で提供既存資産を損なわず漸進的移行
Steward Credits (SC):PoS² に比例し新規発行。帯域・ガバナンス票・ストレージ予約を等価交換。
Energy Reclaim Units (ERU):余熱回収率に応じてクリーンエネルギー補助金と相互運用。
Knowledge Bounties (KB):AI/LLMノードが生成した有用モデル差分を関係グラフへコミット→検証トークンとしてKB が発行。
負荷の自己調整
ネットワークが過度に混雑するとSC の新規発行レートが自動減衰し、トラフィック手数料が指数的に上昇。結果、スパムは短時間で経済的自殺となる。
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∞ 上へマイグレート。
国家単位のデジタル・ソブリンティを再構成:国境・法人格の境界を越え“関係”が一次元目となるため、規制枠組み自体が協調フィードバックモデルへ。
プライバシーと公共性の再両立:透明な“関係構造”上で非公開データを安全に扱う産業API が標準化。医療・行政・金融の壁が大幅に低減。
インフラの脱炭素最適化:PoS²スコアに ERU が直結することで、再エネ比率が低いノードは自然淘汰。エネルギー政策とITインフラが実質同一の経済圏に。
7. まとめ
Web∞ は「情報の状態」を残すのではなく「変化の証明」を残す。
その結果、台帳の重力・ガス代・フロントラン・量子不安・ガバナンス停滞といったWeb3 固有の限界が、概念的に初期条件から消滅します。
エネルギー・プライバシー・スケーラビリティを同時に極小化/極大化するため、従来トレードオフと呼ばれた三角関係は “収束しない曲線” へと畳み込まれる――それが本構想の核心です。
もし実際にプロトタイプを設計するならば、zk-WASMランタイム + Fractal Mesh を Rust で最初に書き起こし、PoS² の初期指標を「再生可能エネルギー電力比+ノード稼働継続率」で暫定運用する、というのが現実的なスタートラインになるでしょう。
CD屋さんはばたばた閉店してるので見つけにくくなってるかもなあ。
私が働いてた当時は30店舗あったCD屋チェーンも今じゃ1店舗を残すばかり。
地道に検索でもして探してください。どこに住んでるかわかれば探してあげられるんだけど。
不勉強でして可逆圧縮の音楽データを売ってるところは知りません。
私は基本iTunesで、iTunesが扱っていない時にAmazonのMP3を使います。
いずれもビットレート256kbps不可逆ですが、常人が生CDと聴き分けられるとは思いません。いい音ですよ。
普段音楽はyoutube の自動再生で作業用BGMとか流しっぱにしてるだけ
だけど、気に入った曲あったのでCD買ってみようかなと思った
CDはそこまで買う方じゃない
これまで年に2つ3つ買うかどうかくらい
買ったのもyoutube で見つけたのとか、やったゲームで気に入った主題歌やサウンドトラック
その辺のCDショップなんか言ってもまず置いてないしAmazon で頼んだ
JPOPでいいのかな
なので久々に直接店で買ってみようと思った
一応都会に住んでるんだけど、駅とか賑やかなところ言ってもCDショップは見ない
ここ数年で見たのは、ちょっと田舎の方のイオンに行ったときのタワレコ?
でもここ少し前のリニューアルでマンガレンタルばかりになってCDがなくなったかもしれない
今ってCDを買うならどこがいいの?
というか店ってまだ生き残ってるの??
それともうひとつ
これまでCDを自分でリップするのがメインでデータで打ってるのは買ったことなかった
最近は電子書籍や音楽聴き放題サービスなら耳にするけど、単体で音楽を変えるサービスって特に聞かない
条件は
↑この2つさえ満たしてればいいんだけど
Amazon だとKindleの画質みたいな感じで音楽も音質イマイチそうという偏見がある
みんなどこで買ってるのー?
オススメぷりーず
今日はお出かけしてきて、そのとき駅の近くでたまたま売ってるのを見つけて今回の目的は達成できました
毎回遠出したときに買うって言うのもアレなので出来る限り近くで行きつけみたいなところが欲しいところ
地道に検索でもして探してください。どこに住んでるかわかれば探してあげられるんだけど。
たまにしかCD買わない分知ってるCDショップの名前が少なすぎて、なんて検索すればいいんだ?、っと思って増田聞いてみました
ただ一応都内
ほとんど行かないけど、新宿・池袋・渋谷・秋葉原など行こうと思えばそこまで苦労しないところ
だけど問題が交通費でCD1枚のためにそこまでいくと、Amazonで買うより1.5倍とか?になってしまうんですよねー
参考になります
なるほどー
参考になります
なお音質は特段こだわりはなく、数を取り込んだ話です。
録音形式はある程度の音質で取り込んでしまえば後で加工してしまえばいいのであまり考えない。
音質云々は割愛。
NR付きの再生機器ならテープ録音状態によっては機械的に分割処理かけてしまえば簡単に綺麗に分けられる。
ただこれが使えないテープの場合手動で分けることになるがこの場合大変。
このとき必要なのは曲時間だが、古いと曲名だけで時間は意外と載ってなかったりする。
最近はGoogle先生が気を利かしてくれて、そこそこ有名だとアルバム名で検索すると曲時間が簡単に出てきたりする。
この情報経由で動画等を検索できる便利な情報だが、この表示されている時間の情報は動画の時間等から自動生成されているらしく偶に変な情報があったりする。
これが面倒かというとそこそこ有名な曲ならば簡単だったりする。
対象の大半がCD化もされているような音源だったので(ならデジタル化する必要は?とは言わないで)Gracenoteのデータベースを引っ張ってくれば簡単。
今は既存の音源からでも検索がかけられるので、適当にアルバム単位で検索すれば大抵引っかかる。
自分の場合この作業にはMedia Goを使っているが、そのままだと引っかからない場合でもアーティスト名やアルバム名のタグ情報を入れて再検索をすればまず存在する。
多言語で出ている作品の場合、別言語にタグ情報に書き換えて検索すると引っかかったりもする。
またGoogle Play Musicの場合、あちらでデータがない曲で一度間違ったタグ情報で上げると記録されるのでタグ情報を書き換えてアップロードしてもそのままでは反映されないので注意。
後でバッチで一度に処理すれば良いという考えで保存用に関しては特にこの処理はしない。
現代のHDDやBDなら、FLAC等可逆圧縮でもかけておけば一本辺り200MB~500MB程度と大した容量にならないので普段用と別に保存してても大して逼迫しない。
保護にはBDならMultiPar等でパリティを付けて保存、ディスクの保管はBD対応した不繊布でもいいが数百本取り込んでも数枚程度なので転写が嫌ならハードケースで保存してもスペースには問題ない。
BDは今のベアディスクタイプですら10年近く経った規格でそれなりに成熟していると考えられるのと、かなり減ってきたがまだ地方だと相次いだメーカー撤退による投げ売りが偶にあるのでネットで買うより処分品狙いで買ったほうが安かったりする。(狙い目はDVDレンタル店)
データとともにカセットテープのケースやインデックスカードの画像データを保管しておくとアルバム名等を確認する際に現物をいちいち確認する手間がなくなるので捗る。
またミスで再取り込みになった時も画像を手掛かりに現物をピックアップできる。
カセットテープ本体はCISスキャナしかない場合取り込みは困難なのでインデックスカードだけでも取り込んでおくだけでもいいが、その場合音声データを取り込む前に本体のラベルとインデックスカードが正しい組になっているか確認したほうがいい。
ただ単純なインデックスカードの場合スキャナドライバの性能によるがそこまで面倒ではないものの、特別な意匠をこらされている場合この作業は凄まじく面倒になる。
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よりも綺麗(なはず)。