https://twitter.com/_elbown/status/1114571056851775488 #tw #これすき

ほとんどいたるところ顔面、ナンセンスすぎて爆笑した

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

あれ、 UTF-8 だと最大6バイトだった気がするんですが

正確には Unicode の code point ひとつを表現するのに UTF-8 で 1〜6 code unit 必要だった気がする

いやこれ大嘘だった、 Unicode の code point が U+10FFFF までしか存在しないので UTF-8 では 4 code units で済むのか、なるほど

アニメ「フルーツバスケット (2019)」第2話 みなさんが動物なんです！ | Annict
https://annict.jp/works/6355/episodes/110558

タイトル見て「もしかして、けものフレンズ2の13話が存在したのか！？」と思ってしまった

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

wav は png というより bmp では……
(非劣化のデータが欲しいというのはわかる)

このアカウントは、notestockで公開設定になっていません。

実際のところ、 wav はエラーチェックがないのに対して flac はエラーチェックが存在するので、データとしては wav より flac を持っていた方が安心です

ただし flac では 32-bit integer でサンプリングされた音を保持できない規格になっているので、そういうデータがあれば wavpack の非劣化の方を使うなどする必要があります (というか実際私はそういうファイルに出食わしたので flac と wavpack 両方とも使っている)

https://m.aqr.af/@Aqraf/101880337121619857
こういう場合は flac にできないので wav になりがちなのは仕方ない
(本当は wavpack 対応してもらえるといいんだけど、まあ正直マイナーな形式には違いないので)

WavPack - Wikipedia
https://ja.wikipedia.org/wiki/WavPack

WavPack はいろいろ面白くて、可逆圧縮と非可逆圧縮どちらも可能で、非可逆圧縮のファイルと補完ファイルを一緒に使うことで元データの完全再現が可能というハイブリッドな用法ができます (使ってる人を見たことがない)

ハイブリッドな圧縮、「非可逆なファイルはポータブルプレイヤーに転送する、 PC にはそのファイルに加えて補完ファイルを一緒に持っておく」などすると、小さなファイルと完全なファイルを別々にエンコードする必要がなくなる、などのアレです

このアカウントは、notestockで公開設定になっていません。

あれ、そうだったっけ？

たしか Xiph かどこかの誰かが「flac はエンドユーザ用のコーデックなので、編集者が使うレベルの 32-bit 対応なんかわざわざ入れる予定はないで」みたいなことを書いてたのを見た記憶があるような

このアカウントは、notestockで公開設定になっていません。

これはほんまこれ

このアカウントは、notestockで公開設定になっていません。

[Flac-dev] 32-bit float?
http://lists.xiph.org/pipermail/flac-dev/2007-April/002185.html

32-bit integer 可能っぽいですね

https://mstdn.nere9.help/@orange_in_space/101880353375228315
これはダウトで、極めて不思議な話ではあるんですが普通にファイル壊れる (そして flac のチェックサムで検出される) ことがあります (本当に不思議)

あとはエンコーダやタグ編集ソフトとかのバグで壊れたとき……みたいなレアケースも考えられるっちゃ考えられる (つまり「物理破壊ではなく論理破壊への耐性」とでも言えば良いのだろうか)

自分で書いといて何だけど物理とか論理とか意味わからんので無視して

㊰なので雑発言になってしまった

AB テストしたことがないどころか普段から 1k yen のｲﾔﾝﾎﾎ使ってるので

可逆圧縮を好むのは単純に「取り返しのつかないことになりづらい」という理由ですね。
私が非可逆な操作を行うことに多大なストレスを感じる性質なので。

まあ海苔は形式以前の問題で論外だよなぁ

でもよく考えると float って本当に音を表現するのに適しているのかよくわからんな

基本的に IEEE 754 とかの浮動小数点数では、小さな数ほど精度が良くて、大きな数ほど精度が悪いという性質があるわけですが、音楽において音波のピーク部分の山の頂点と圧力ゼロ部分の激しい傾斜、どちらに精度が欲しいかというと当然山の頂点の方 (なぜならそちらに誤差があるとノイズとして高周波成分が生えてくるから) なので、 float が持つ精度の減りかたと欲しい精度の乗り方が逆なんですよね

小さい部分が表現しやすいのはたしかに良い性質なんですが、大きな音を表現するとき、雑で良い部分の精度が高くなって、綺麗に表現されてほしい部分 (山の頂点付近) で精度が低くなるというのは、なにか別の小数点数表現が必要とされているような気がしないでもないですね (気にしすぎかもしれない)

まあこれたぶん深く考えていくと最初からフーリエ変換して周波数成分だけ持っとけという話になって、最終的に mp3 (without 高周波カット) はいいぞ的な話になりそうなんですが

https://mastodon.cardina1.red/@lo48576/101880401145237418
山の方が精度欲しい理由、「傾斜の激しいゼロ付近のサンプル点は、山の頂点付近に比べて数が少ないから」と表現するべきかもしれない

音楽にはあまり詳しくないので私のよく知らない性質とかあるのやもしれないけど

まあそりゃ正論なんですけど、「馬鹿デカい音で録音するな」が通るならそもそも float そんなに必要なさそう (よほどのダイナミックレンジが欲しい音楽を除けば)

ボレロとか最初はめっちゃ小さいのに最後は結構大きくなるので、ああいうのは float とか使うといい感じになるのかなという気持ちがなくもない

本来それこそ scale factor としてのリプレイゲインによって解決されるべき問題なんですよね…… (元の音はクリップしない範囲でとにかく大きくしておいて、本来意図された縮小スケール情報と再生側でのボリュームをそれに掛けることで最終的な音量を得る)

まあそれが float じゃんといえばまったくその通りなんですけど

サンプル単位でやるか音楽データ単位でやるか程度の差ですね

海苔で局部に貼るアレを連想するのは訓練されたオタクだけ

サンプル単位でスケールファクタを用意したとして、結局いずれにせよ最終的にデータ全体にかかる係数は必要になるというのはまあハイという感じ (救いがない)

まあ ototoy はオタク楽曲のハイレゾ配信が多いので個人的にオヌヌメしていきたい

DRM を許さない勢力なので

そうなのか、 24-bit integer は IEEE 754 の 32-bit float に劣化なく入るのでそれなら普通に 32-bit float 使えばいいですね

ｴﾖｹﾞのサントラ買ったら CD と思いきや DVD で、 24-bit integer の wav ファイルと 32-bit integer の wav ファイルが混在していた経験があります

flac に変換しようとしてエラーが出ることで気付いた

私は cdparanoia で取り込んで CLI で flac にしたのち fb2k でタグ編集という流れが多いですね

まあ最近 ototoy でﾎﾟﾁｰする割合が極めて高いのでもうリッピングとか久しくしてないけど

PRINCESS CONNECT! Re:Dive ORIGINAL SOUNDTRACK - OTOTOY
https://ototoy.jp/_/default/p/316251

これほしい

fb2k 、基本的に便利なんだけど、なんか metaflac でリプレイゲイン付けたときと fb2k で付けたときだと、後者の方が大きな音になるんだよね……一応目標値設定は 89 dB にしてあった気がするんだけど

昔は flac + CUE してたんですが、ラップトップをメインで使うようになって、おたくソングのアルバムだと謎のボイスドラマが入ってたりするじゃないですか、あれを除外したいなどの需要が出てきたので楽曲単位でファイルにするようになりました

たぶんこれ正解で、制限のあるデバイスで持ち運ぶならエンコードしなおせという話はある

私の場合だと、ラップトップでの BGM 再生に MPD (Music Player Daemon) を使っているので、プレイリストを雑に共有するにはファイル名などの変更が一切ないのが都合が良いんですよ

作業用 BGM 再生を MPD でやるの、結構硬派じゃないですか (どうでもいい)

fb2k は Linux native なバージョンがあればなぁ……

あと OSS 化するつもりもないという話を昔読んだので、まあ期待してない

このアカウントは、notestockで公開設定になっていません。

㍂

Opus 使いてえな……

Opus はリプレイゲイン周辺の仕様と実装がどうにもな……

Opusの音量周りがとてもつらい - Qiita
https://qiita.com/obsolete-standard/items/cbde7257ab2e8c39a265

はいこん氏の記事

音楽を再生していて突然1曲だけ大きかったりすると許せない (そういう意図の曲なのであればまだしも、意図でなく実装や規格の問題だと絶対許せない)

wavpack とか一応リプレイゲイン設定したはずなんだけど大きくなりがちなのでそのうち理由を追求してみたい (放置フラグ)

わかるなぁ、 1 TB ストレージのラップトップ使うようになってから flac を持ってくることに躊躇いがなくなった

曲が (リプレイゲインを適用してなお) 極端に小さかったり大きかったりすると、プレイリストに入れなくなるのでマジで聞かなくなる

このアカウントは、notestockで公開設定になっていません。

電子書籍みたいだな >オンラインインストールできなくなったインストーラ

LAME が "LAME Ain't an MP3 Encode" なのも特許関連の理由だったはず (「これはソフトウェアじゃなくてパッチやでwww」という抜け道を使っていたとか)

LAME ‐ 通信用語の基礎知識
https://www.wdic.org/w/TECH/LAME

> そもそも、mp3エンコーダーというものは著作権とFraunhofer-Gesellschaft(FhG)などの特許の問題が常に存在する非常に厄介なものである。LAMEも当然例外ではなく、当初はISOのコードの配布制限と特許問題を避ける目的で、ISOのサンプルコードに対するパッチ、という扱いにして配布されていた。かなり黒に近いグレーな存在ではあったが、FhGからの文句は無かったようだ。

オープンな規格と OSS を使っていきたい

可逆音源: FLAC
非可逆音源: Opus
可逆動画: FFV1
非可逆動画: AV1
可逆画像: PNG
非可逆画像: AVIF (AV1 Image File Format)

という感じの未来を望んでいる

このアカウントは、notestockで公開設定になっていません。

webp ってｺﾞﾝｺﾞﾖのオレオレフョーマットじゃないんですか
AVIF は AOM なので

個人的には後者の方を信用したい

これは聞いたことなかったわ (全く使うつもりがなかったので)

FFV1 も IETF で標準化されるし、やっぱり標準は大事

PNG は ISO/IEC だし

アップローダ、 firefox send はいかがでしょう (任意のブラウザから使える)

Firefox Send
https://send.firefox.com/

Mozillaが無料の暗号化ファイル共有サービス「Firefox Send」を開始 | TechCrunch Japan
https://jp.techcrunch.com/2019/03/13/2019-03-12-mozilla-launches-its-free-encrypted-file-sharing-service-firefox-send/

ファイルの継続的公開ではなく、交換用のサービス

Firefox Send 、実は Android アプリが存在する (beta だけど)

k8s の numeronym では。知らんけど

GitHub - rancher/k3s: Lightweight Kubernetes. 5 less than k8s.
https://github.com/rancher/k3s

オタクは再帰が好きなので

ほんまやw

このアカウントは、notestockで公開設定になっていません。

！！！完全に理解した！！！！！

FBX SDK を使うために gcc-4.9 をｲﾝｽｺすべきか否か、大変悩んでいる (嫌なんだけど)

バックドアを含むバージョンのbootstrap-sassパッケージがRubyGemsで見つかる | スラド セキュリティ
https://security.srad.jp/story/19/04/07/0053218/

おや