This account is not set to public on notestock.
Posting らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)
This account is not set to public on notestock.
This account is not set to public on notestock.
こんな馬鹿なことばかり言ってるとそのうち殺されそう
This account is not set to public on notestock.
長音符だけ全角なのがパッチ未適用 libskk 感を醸し出していて笑ってしまった
improve hankaku katakana conversion · Issue #51 · ueno/libskk - https://github.com/ueno/libskk/pull/51
これが merge 済なので、 libskk-1.0.4 以上では治るはずです(いつリリースされるか知らないけど)
上り80km/h (中央線)(適当)
This account is not set to public on notestock.
用を足しても手を洗わない輩(中年や老人に多い)、社会の害なので外を出歩かないでほしい
replay gain 適用するとクリッピングしなくなったデータ知ってるし、やっぱりあれデコード先の型とかの問題なんですかね
たとえば float64 のデータを int32 にデコードするとかだと、元データはクリッピングしてなくてもデコード後にクリッピングするし、リプレイゲイン適用によってクリッピングを防ぐこともできるはず
s/クリッピングするし/クリッピングしうるし/
有限精度のデータであればどんな原理であれクリッピングは発生しうるわけですが、たぶんそこまでｸｯｯｯｯｿ巨大なサンプルは普通入ってこないということでは(しかも浮動小数点数とかであれば尚更)
元音源が本当にクリッピングしているのであれば、小さくしたところでノイズが目立たなくなるだけでクリッピングはなくせないし、元データにもいろいろあるのだろうというテキトーな想像をしている
たとえば WAV であっても内部表現は float であったりすることもできるはずで、非可逆音源であることとサンプルを表現するデータ型がスケールすることは別の話では
非可逆音源ってPCMそのまんまじゃなくDCT？＞＜してるデータじゃん・・・？＞＜
周波数成分ごとにデータ持ってるなら尚更、修正不可能なクリッピングって発生しづらいのでは……？
修正不可能な形で発生するにしても周波数ごとのクリッピングだろうし、つまり「特定の音域が本来よりも多きくならない」というような形で現れるのでは
そうであるとすれば、メジャーな非可逆圧縮の(一般的な想像のような現象としての)クリッピングは、フーリエ変換されたデータから時間・サンプルの PCM 的データに変換する段階で、変換先のサンプル型の範囲(たとえば int )に収まらないことが原因で発生すると考えるのが自然
であれば、そういった原因で「クリッピング」しているデータは、変換の段階で replay gain でスケール落としてやれば、 PCM の意味でのクリッピングを回避できるのは原理的に当然のように思われる
これ私が文脈ちゃんと読んでなかっただけかな
そういえばmp3の仕様？＞＜で微妙に意味がよくわかんないんだけど、なんでamazon mp3で売ってるmp3なファイル、ゲイン値（？）がとんでもない事になっててそのままだとクリッピングするの？＞＜ 規格的におかしくない・・・？＞＜
mp3ってそのままでコードするとクリッピングするデータが作れてしまうの規格上おかしくないの？＞＜って話を何度か書いてて
（ https://mstdn.nere9.help/@orange_in_space/99660379898354133
）、先ほど気づいたんだけど、foobar2000でデコードするとクリッピングしない・・・＞＜（なぜ？＞＜；）
「replaygainとかいうのあるらしいけどさ＞＜ デコード時にクリッピングしてるデータをデコードした後から音量下げても何の意味も無いじゃん？＞＜ どういう事？＞＜」って思ったんだけど、foobar2000はそうじゃ無いっぽい・・・？＞＜（ていうかデコーダのつくりが特殊？＞＜）
（Windows標準のACMデコーダ（DirectShow経由でも）とかWinampの標準デコーダでは普通に（？）クリッピングする＞＜）
少なくともNAudioで作ってるアプリをreplaygainに対応した言って相談してた人への返答はこれになってた＞＜
「replaygainとかいうのあるらしいけどさ＞＜ デコード時にクリッピングしてるデータをデコードした後から音量下げても何の意味も無いじゃん？＞＜ どういう事？＞＜」
デフォのスケール(倍率)が大きいのは WAV とかのリプレイゲイン非対応プレイヤーが多いような形式と合わせるためではという気持ち(実態を知らないので適当)
ていうかわかりやすくfloat(32bit PCM)で例えると、普通にデコードしたら「1.0超えちゃった」って時に、「まあいいか1.0で」になってる＞＜；（＝それをデコード時のクリッピングと言う かも？＞＜） のでおかしい＞＜；と言ってる＞＜
まあデコード側で動的にサンプル見てやってダイナミックゲインかければ再生時にクリッピング阻止できるかもしれないけど、それやると曲全体として一貫した(本来想定されている)ラウドネスにならないのではという気持ちがあるので、そういうアグレッシブな最適化はデフォでしてほしくない
特に耳が良いわけでもないけど情報の欠損や汚染を拡大する処理にはうるさいオタクです
喩えて言うならドット絵を jpeg で保存するようなもので、「見た目わからなければいいでしょ」とかそういう話ではなくて、元のドット絵という情報を劣化させるコーデックを使っていること自体が気に入らないという、そういう話
ていうか、サンプリングなんだから「音量なんて雑な発想でスケール決めるな＞＜＃ データ上は最大値が1.0（に対してさらにヘッドルームあけた状態）になるようにしろ＞＜＃ 」って言ってる＞＜
これやると、ごく一部で超うるさくなるけど全体としては静かな音データとかでアレな感じになるのでは
たとえば経験としては、『ボレロ』とか最初の方クッソ静かなので安直なリプレイゲインをかけてしまうとマジで囁きレベルの音になる
わりと意味がわからないけど、それって、謎の音がでかすぎるデータをDACに入るまでそのまま届けろっていってるのと変わらないよ？＞＜； しかも、はみ出てる（クリッピングしてる）から、元の波形とは違う波形だよ？＞＜；
訂正＞＜；
クリッピングってデータの欠損だよ！！！＞＜； 絵で24bitカラーで例えるなら、RGB各色が0xffを超えたり0x00を下回ったりしてる状態だよ？＞＜；
音がクリッピングするほどデカいのは、「リプレイゲインが適切でない」「デコーダが適切なリプレイゲインを適用しない」の2つがおそらく根本的な原因であって、前者についていえば仕様のデフォルト値を使っていることが悪いし、後者についてはデコーダが悪いので、いずれにせよ元データは(リプレイゲイン設定を除き)悪くないのではという気がする
で、リプレイゲインというのは(一般には)ユーザが基準ラウドネスを決める権利を持っているわけで、勝手に定めることはできない(無論、デフォルトで用意した値を突っ込んでおけという意見には一理あるかもしれないけど)
なにか食い違っている気がする…… orange 氏は mp3 の規格が悪いと主張していると思っていたんですが、もしかしてデコーダが悪いと主張していますか
リプレイゲインが設定されていればデコーダはそれを尊重するべきだし、されていなければ(たとえクリッピングしようと)そのまま素朴に出力するべきだと考えているので、私としては「リプレイゲインの設定されていないデータを聞こうとするのが悪い」という主張になります
ｱﾏﾖﾝで聞くに耐えないということであれば、 Amazon (あるいは任意のストリーミング業者)側で適当なゲインが設定されていないのが悪いという話に
「デコードしました！ 正弦波がはみでて矩形波みたいになっちゃった！ まあ音を小さくすればいいか」
よくねーよ＞＜； ってなるじゃん？＞＜
両方おかしいと言ってる＞＜（あえて言うならエンコーダがおかしい＞＜（デコードした時に最大値を超えるデータになってしまったのであればエラーを吐くべき かも＞＜））
replaygainってあくまで追加情報タグとしての規格であって、mp3そのものの規格ではないんでしょ？＞＜
リプレイゲイン、言ってみれば「聴者環境で適用すべきゲインのキャッシュ」であるわけで、これが存在しないのであればデコード側の環境で適切に事前計算すべき(何故なら、どのラウドネスを目標にどういった戦略でゲインを適用すべきかは聴者や目的で異なるため)なので、「デコーダが目標や戦略を知っているのであれば、リプレイゲインがなくとも(あるいはあっても)適切に自前でゲインを計算したうえでデコードすべき」ということは言えそう
だとすれば、「ゲイン調整のための目標や戦略を受け取れないデコーダ」は素朴なデコードをするのも致し方なし(ただしゴミ)という結論も導けるか
This account is not set to public on notestock.
This account is not set to public on notestock.
機械「だじゃれを言ってください」
本人「だじゃれを言うのはだれじゃ」
機械「過去のだじゃれ品質から本人と特定しました。ロックを解除します」
This account is not set to public on notestock.
This account is not set to public on notestock.
何を指摘しているかと言うと、おそらくreplaygainを活用している人のうちのある程度の人（一般的なデコーダを使い、デコード後に音量調節する仕組みのプレイヤーを使ってる人）は、無意味にぶっ壊れてクリッピングしてる音として聞いてるのに「ちょうどよく音量調節されて便利だな・・・」とか間抜けな事を言ってる事になるよ！＞＜ と指摘してる＞＜
そんな間抜けなプレイヤーあるんですか？(それは根本的に仕組みが駄目という感じ)
デコード時に既にゲイン調整(クリッピングの有無は問わない)がかかってるのに更に後で(クリッピング阻止目的で？)音量調整かけるの、二重に同じ変換かけてるだけでは
一般的なメディアプレイヤーの類は、デコード後に音量調節してるのが普通だよ＞＜；
それって後ろの段の音量調整は単に耳に合わせるためのものであって(つまり著しい劣化を含んでいなくて)、クリッピング阻止を目的とした調整は前段のデコード時ゲイン適用で行われているだけなので、後段は実際存在しないものと考えて差し支えないのでは？
たとえば客観的に100の大きさがあったサンプルを、耳の良い人が0.1倍の音量調整で主観的に10の大きさで聞くように、耳の悪い人が1倍の調整で主観的に10の大きさで聞くためのものが後段の音量調整であって、クリッピングの有無(やその責任)は後段には全く関係ないように思われるので、何故その話が出てきたのかわからない……
replaygain対応の実装として一般的にはどうなのか？＞＜は知らない＞＜（少なくともNAudio(ライブラリ)の使い方相談してる人への返答は後から調節せよって一般的な実装だった＞＜）
もしかして、フォーラムの人が「クリッピング防ぐために後段で音量落とせ」と言ってたという話ですか？(その事実は全く把握してなかった)
ずっと前段の話をしているのだと思っていた……
自堕落な技術者の日記 : 最近の証明書の話題(1) 韓国政府PKIのマズいワイルドカード証明書発行 - livedoor Blog（ブログ）
http://blog.livedoor.jp/k_urushima/archives/1839344.html
すげえな……
デコードはクリッピングしても元のデータの通りにすべき！とか言っても、この画像の波形を音量調節された440Hzの正弦波！とか言ってるのと変わらない＞＜； どこが正弦波やねん・・・＞＜
それは単に波形を大事にするか、(他の部分や他のファイルも含め)相対的な音量を大事にするかの違いでは(まあ前者の方を大事にしたい人が多いであろうというのはわかる)
規格上の最大値である1.0を超えるデータが来てしまった時に、そのままカットする（クリッピング）か、スケールを変える（例えば飛んできたのが2.0（でかすぎ＞＜；）だったら半分にする）のどちらかしか不可能でしょ？＞＜； どうするの？＞＜；って言いたい＞＜；
たとえばストリーミングしているとき、途中からクリッピングしそうになったらデコード時のスケールを変えることは可能かもしれませんが、それ以前とそれ以降で同じ曲ファイルなのにスケールが違うという現象を招きますよね？それって場合によってはクリッピングよりも忌避される劣化では？
https://mastodon.cardina1.red/@lo48576/99849621139539427
……ということを、この投稿では言っています
私が言っているのは、
(1) は影響が一部分で済み、音量に一貫性がある
(2) は波形の劣化が小さいように見えるが、全体に影響を与える(音量に一貫性がなくなる)
(3) は本来すべてのデコーダが取るべき方策に思われるが、時間がかかるし目標値の設定が必要
という話で、クリッピングが必ずしもこの中で最悪とは言えないのでは、ということです
無論 (2) でクリップしそうな範囲だけスケールを変えることも可能ですが、それでも音量の一貫性が失われる点については違いないので
ていうかそれってWindowsのミキサーの仕様がおかしい！！！って話題になったのと同じかも＞＜（オレンジはおかしいのはデータのほうでWindowsの仕様の方がほぼ正しいって考えてるけど＞＜）
ていうかそういうことが起きないようにヘッドルームあける（つまり元のデータとしては余裕を持って音が小さくする）必要がある＞＜
https://mastodon.cardina1.red/@lo48576/99849782302573154
3にならない実装の方が多いんじゃないの！？＞＜（疑惑）っていう話をしてる・・・・＞＜（3のつもりで使ってるけど、実際は https://mstdn.nere9.help/@orange_in_space/99849722182512805
のようになっている人がかなりいるのでは？＞＜；って言ってる＞＜）
(3) は「音楽の全体を(再生前に事前に)知っていること」が必須条件なので、音楽ファイルプレイヤーでもなければ不可能だと思いますので、まあストリーミングに対応しているプレイヤーであれば (1) や (2) を使うのも不思議ではない(そして音質劣化の事故も仕方ない)かと
クリッピングは標本化の原理？＞＜；から見ても欠損してるので最悪では？＞＜； 2は一貫性が無くなるけど、変更時点以降は全て正しくそれ以前はすべて正しくなかったって発想になるはず＞＜
個人的には、音楽はその音量の遷移も含めて表現なので、全体としての表現の精確さを重視されるべきだとは思います(無論全体でクリッピングしている音データは論外だけど)
「これまでの音が正しくなかった」は真実ではあるけど、だったらそんなもの提示するなという気持ち(つまりリプレイゲインか再生直前事前計算をしてほしい)
サンプル値に余裕を持たせて音データを作るのも「事前の処理」に含まれるわけで、要するに(当然ながら)元データ以上の劣化を起こさず再生するには、全体を解析しての事前処理は不可欠だと思うわけです
で、音データがその適切な事前処理を受けているかは一般に不明なわけで、そのデータを手元で事前処理せず再生して音の劣化に文句を言うのは、「根拠もなく勝手に期待して勝手に裏切られた」状態ではないかと思うわけです。つまり外部データを無条件に信頼するプレイヤーに問題があると考えます
ていうか曲作った人（マスタリングした人）がアホな場合どうにもならない＞＜（し、いまどきの曲作る人のおそらく9割以上がその定義上のアホだからどうすんべか？＞＜）
で、そのアホが作った壊れた音データに、データ上の正確な音量も何も無いだろと言いたい＞＜
それはモザイクを外そうとするようなもので、そもそも「元から壊れたデータを耳障りよく再生したい」という幻想を捨てるべきな気がする(壊れたデータを"正しく"再生する方法などない)
っていうか純粋なPCMなデータに絶対的な音量なんて無いんだし＞＜ さっきから書いてる文脈上のアホは、PCMで表現されているデータの各サンプルが最大値に近い（というか超えている）データが、絶対的な意味で音が大きいデータと勘違いしてるっぽいけど＞＜
これは個人的な考えなんですが、任意のデータについて「根本的に壊れていてもどうにかリカバーしたい」というのは闇への直通経路だと思うんですよね。たとえば木構造を為していない HTML もどうにかリカバーとかしないでさっさと蹴飛ばしてほしい
間違ったデータが致命的エラーにならないから、いつまでもデータ作る側が間違ったものを吐き続ける
robustness principle を実践するには人間は愚かすぎる
「これ間違ってるんじゃない……？」って優しく言ってくる警告に多くの人が耳を貸さないことは、警告を無視するプログラマなどからも簡単に推察できるし、そもそも lint や validation なんて一般人は通さないだろうし、「これは間違いだよバーカ！！！！」って現実を突きつけてやらないと大抵の情報発信者は正しい形式の情報を吐かない
replaygainで下げる方向の情報を各必要があるデータの大半っておそらくだいたい壊れてるデータ（それで言う弾くべきデータ）なのでは・・・？＞＜；
replay gain で治るデータ、 fundamentally broken ではないという印象(それでもクソには違いないし、壊れているという点には同意)
replaygainをクリッピング検出したらエラーはいて止まるようにしよう＞＜（？）
クリッピング防止でのリプレイゲイン計算、目標ラウドネスより低い音量で結果を出すことがしばしばあるので、実際これは欠陥データと言いたい気持ちはある(ただ目標ラウドネスの基準の問題であるとも言えるので難しい)
This account is not set to public on notestock.
クリッピングといえば、ラブライブの曲とかは「海苔」なんて呼ばれてたりしましたね
ていうか海苔波形、わりと世の中の90年代以降の商業的な音楽の標準状態・・・＞＜
This account is not set to public on notestock.
zsh で set -u してたら prompt コマンドが駄目だった
なんか TL にいない間に面白い話が？
本当はトゥートにもライセンスを明示しないといけないんだろうなぁとは思っている。bioの文字数が・・・。
This account is not set to public on notestock.
仕組み的に複製・再公開されるとわかっているプラットフォームにコピー禁止のデータ流すの、当たり屋かよ
どうしても制約の強いライセンスを適用したいのであれば、先にソフトウェアかプロトコルを弄って原理的に可能にしてからだろというお気持ち
This account is not set to public on notestock.
これっぽさ＞＜
https://mstdn.nere9.help/@orange_in_space/99263490696565281
（検索できるようになってすごく便利！＞＜ ありがとう＞＜＞＜）
プロトコルやソフトウェアによる対応の準備段階として、機械可読な形でライセンス情報を含められるようにするべき、というのには私も同意したい
ここでいうコピーって、インスタンスの表示用に取り込まれるやつは別ですよね？わたしはカスタム絵文字として新たに登録されるやつを想定してコピーと呼んでいました。
どこまで引用の範疇になるのか、或いは他インスタンスの投稿を正確に表示するための画像のコピー保存と限定的な再配信さえ引用には含まれないのか、よくわからん(法律案件)
This account is not set to public on notestock.
「未知のライセンスには保守的に応じる」というだけでも拡張性と実用性は十分担保できそうだと思っている(どうせ皆が必要としていれば、ライセンスユーザの誰かがプルリクとか投げるだろうし)
Mastodonでシステム的にカスタム絵文字のコピーが可能であったとしても著作権を放棄しているとは言えないだろうし(まぁ明示してない方がアレというアレはある)、どちらかというとMastodonにおいてのみ使用可能であるようなライセンスが自動的に付与されてるくらいがいい気がする
MastodonというかまぁなんかこうAPで配信されてる感じでよしなにやってる感じの
カスタム絵文字、そもそも AP じゃなくて Mastodon の独自拡張では(知らんけど)
This account is not set to public on notestock.
This account is not set to public on notestock.
"Mastodon は営利的な SNS ではありません。広告や、データの収集・解析は無く、またユーザーの囲い込みもありません。"
って全体的にGPLと矛盾する上で
"データの収集・解析は無く"
って日本の著作権法にも矛盾するんじゃないのかな感・・・＞＜
Mastodon とは upstream のみを指し、 fork され改造されたものを「Mastodon」は指していないのでは(適当) (GPL にブランドの条項があるか覚えてない)
「グーグルで検索したら出てきた写真だったから著作権フリーだと思った」という何度か見た言い訳五十歩百歩というか同じかも＞＜；
This account is not set to public on notestock.
This account is not set to public on notestock.
「海賊版を止める最適の方法は、DRMの最適化じゃない。ただ海賊版よりももっと良いサービスを提供するべきなんだ。」
-ゲイブ・ニューウェル Valve Softwere 業務執行取締役
第零の自由と矛盾する文言が表示されるソフトウェアって、それがライセンスその物ではなくても（つまり単にGPL（系）に矛盾する嘘をついている状態でも）、GPL（系）を満たしてると言えるのかな？＞＜って謎が＞＜
例えば「このソフトウェアはGPLではありません」って注意書きがあちこちに書いてあるGPLなソフトウェア（ソースコードでも実行状態でも）ってGPLとして問題あるのか無いのか・・・？＞＜；
裁判的な観点で言えば、保守的に解釈するべきなのかもしれない(適当)(法のプロ👏じゃないので何もわからん)
つまり矛盾があれば一番保守的な解釈を選択する(のが無難)
「トラヒック」、特定の企業や界隈でよく使われている印象(由来や意味の違いはよく知らない)
This account is not set to public on notestock.
foobar2000 のリプレイゲイン解析、なんか変なんですよね。
同じ目標値 (89dB かな？) にしてるはずなのに、 mp3gain とか aacgain とか wvgain とかでやるよりも大きな音量になる
脆弱性公表をきっかけにbeepパッケージの不要論が出る | スラド セキュリティ - https://security.srad.jp/story/18/04/13/0353226/
わーお
This account is not set to public on notestock.
次世代動画コーデック「AV1」、H.264やVP9を上回る圧縮率を示す | スラド IT - https://it.srad.jp/story/18/04/13/0432250/
手軽なファイルの共有、 firefox send などがある (firefox 以外でも使える単なる web サービス)
This account is not set to public on notestock.
動画は大抵のユースケースで再生回数の方が長いという仮定のもとで有用だと思うのではやくデファクトスタンダードになってほしい
再生回数が多くならない用例として、個人用のｽﾏﾋｮで観るためのエンコードなどがある
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
最初のエンコードは低圧縮で高速、それを使った2周目のパスは高圧縮、みたいなのがいいんですかね。そんな都合の良いコーデックがあるのか知らないけど
This account is not set to public on notestock.
絵文字登録画面に「私はこの画像が文脈に関係なく無料で複製され再頒布されることに同意します」みたいなしょーもないチェックボックスでも用意すればいいんですかね(しょーもない)
しょーもないが、それを明示されないとわからない人がいるのであれば仕方がない
This account is not set to public on notestock.
This account is not set to public on notestock.
法整備をするのはいいんだけど、その"緊急避難"の法解釈としてブロッキングするのは筋が通らないから昔から立法したほうがいいしこうれこれこうすれば立法できるかもよっていうやりとりをしていたにも関わらず、それをやらずにアレなので、まぁ批判されるよねって感じ
海賊版サイト「ブロッキング要請は法的に無理筋」東大・宍戸教授、立法を議論すべきと批判 - 弁護士ドットコム https://www.bengo4.com/internet/n_7683/
まぁこれって感じ
理系のオタクジョークという感じだ
