新しいものを表示
orange さんがブースト

で、音データがその適切な事前処理を受けているかは一般に不明なわけで、そのデータを手元で事前処理せず再生して音の劣化に文句を言うのは、「根拠もなく勝手に期待して勝手に裏切られた」状態ではないかと思うわけです。つまり外部データを無条件に信頼するプレイヤーに問題があると考えます

スレッドを表示

ていうか曲作った人(マスタリングした人)がアホな場合どうにもならない><(し、いまどきの曲作る人のおそらく9割以上がその定義上のアホだからどうすんべか?><)

orange さんがブースト

サンプル値に余裕を持たせて音データを作るのも「事前の処理」に含まれるわけで、要するに(当然ながら)元データ以上の劣化を起こさず再生するには、全体を解析しての事前処理は不可欠だと思うわけです

質問(?)の意図よくわかんないけど、どの段階でもクリッピングしちゃだめだしできる事ならば3dBFSくらい余裕を持って欲しいかも・・・><

orange さんがブースト

え、クリッピングってマスタリングの前に対処すべき話じゃないんですか。(自宅音楽制作マンより)

正確性の話で言うのであれば、最大値を超えたデータが飛んできた時点で再生を停止してエラーはいて止まるべきかも><(実際にそうしろと言ってるのではなく、データの正確性ってそういうことかも>< そもそも壊れてるんだから><)

orange さんがブースト

「これまでの音が正しくなかった」は真実ではあるけど、だったらそんなもの提示するなという気持ち(つまりリプレイゲインか再生直前事前計算をしてほしい)

スレッドを表示
orange さんがブースト

個人的には、音楽はその音量の遷移も含めて表現なので、全体としての表現の精確さを重視されるべきだとは思います(無論全体でクリッピングしている音データは論外だけど)

音関連のまともな機材であれば、緊急な対処として3をするはず><(Windowsの音エンジン(Vista以降)もそう><)

orange さんがブースト

(3) は「音楽の全体を(再生前に事前に)知っていること」が必須条件なので、音楽ファイルプレイヤーでもなければ不可能だと思いますので、まあストリーミングに対応しているプレイヤーであれば (1) や (2) を使うのも不思議ではない(そして音質劣化の事故も仕方ない)かと

ていうかそもそもデータが壊れてる><(世の中の最近のCDの大部分とか、amazon mp3で売ってるmp3ファイルのうち少なくともオレンジが買ったのの大部分><)

クリッピングは標本化の原理?><;から見ても欠損してるので最悪では?><; 2は一貫性が無くなるけど、変更時点以降は全て正しくそれ以前はすべて正しくなかったって発想になるはず><

orange さんがブースト

私が言っているのは、

(1) は影響が一部分で済み、音量に一貫性がある
(2) は波形の劣化が小さいように見えるが、全体に影響を与える(音量に一貫性がなくなる)
(3) は本来すべてのデコーダが取るべき方策に思われるが、時間がかかるし目標値の設定が必要

という話で、クリッピングが必ずしもこの中で最悪とは言えないのでは、ということです

スレッドを表示

mastodon.cardina1.red/@lo48576

3にならない実装の方が多いんじゃないの!?><(疑惑)っていう話をしてる・・・・><(3のつもりで使ってるけど、実際は mstdn.nere9.help/@orange_in_sp 
のようになっている人がかなりいるのでは?><;って言ってる><)

orange さんがブースト

マストドンのWebUIのスクロールバーが使いにくいって話をしてる・・・?><(デザインの話!?><)

(あと、今日、オレンジが何を調べてたのか?><具体的に言うと、NAudioでacmデコーダでmp3デコードする時に、デコード時のゲイン調整って出来ないのかな?><って事><(出来無いっぽい?><;))

(ミックスしたら超えるから超えないようにって意味じゃ無くて><; 一応><;)

ていうかそういうことが起きないようにヘッドルームあける(つまり元のデータとしては余裕を持って音が小さくする)必要がある><

ていうかそれってWindowsのミキサーの仕様がおかしい!!!って話題になったのと同じかも><(オレンジはおかしいのはデータのほうでWindowsの仕様の方がほぼ正しいって考えてるけど><)

これね><
dgo.xsrv.jp/alipapa/wmp/

古いものを表示
:realtek:

思考の /dev/null