【Linux系】PCオーディオ談話室【AU】Part8
■ このスレッドは過去ログ倉庫に格納されています
ここはLinuxOSをプレーヤーとして直接音楽を再生することに関心のある人が、ピュアオーディオ的視点でLinuxOS及び接続機材・ソフト・設定等について 語り合うスレです。
LinuxOS以外のプレーヤーで再生したい人は各種専用スレでお願いします。
前スレ: 【Linux系】PCオーディオ談話室【AU】 Part6
https://lavender.5ch.net/test/read.cgi/pav/1462539988/ >>562
先頭のpが抜けてました
つまりpcm.binauralです >>559
なんと!・・・、暫し間を取ったが、折角なんでやってみましたよ。
ガイドどおりで一発で鳴りましたよ。
バイノーラルはよくわからんです。
test.flacってバイノーラル録音のが付属しているのかと思ったが違うんだな。ステレオファイルを低域周波数音に遅延作ってぽく聴こえるようにするエフェクタってか。
DeadBeeFにも紛らわしいbs2bってpluginがあるが機能的に別物だね。
よくわからない原因かもしれんが、音量調整がまるで出来ずに困ってる。
常用PCで先日鳴らした際はPCのアナログカード(card0)でcmusの音量調整は効いていた気がする。
音楽用PCにssh -Xで入り、DDC(card1)経由で再生するとcmusでも音量調整が効かないね。
.flacはyoutube経由で手に入る"No Sanctuary Here - Chris Jones"流したが、再生終了後に7箇所クリップしてるよ下げるか訊いてきたが答え方がわからん。
SoXのオプションのout effectのgainだかvolが使えそうだが、指定方法がいまいちわからん。マニュアルてかヘルプが長大かつ散っているのでなかなか辿りつけない。
SoXのQuality設定もパット見わからんし、cmus-remoteやらcmusでSoX使う設定も、なにせ、降って湧いたものだから情報不足だね。
一方、DeadBeeF用のpluginのbuildは、githubのissueにあった、libsox*を入れてmaster.zipのgoをやったが、DeadBeeFが/optにないと頓挫中、/usrの方にインストしてある。なぜ?
常用PCでは/opt/deadbeefに入っていて、deadbeef.hもあるんで何故インストール構成が違うか思い出せない。
まあ、lyricsプラグイン使いたかったんで0.72のままなんだが、、、。古いのが/optで新しいのが/usrって、なんか変だね。
音楽用PCのDeadBeeFをremoveして、starw-boxのppa入れ直したが、また/usrにインストされた。
.debファイルからなんかしないとインスト先は指定できないんだっけか?
なんか知ってます? >>564
当方もppa経由で/usrの下にインストールされてますがおっしゃるようなエラーは出なかったと思います
取り敢えずMakefileの中の以下の部分を変更してみてはどうでしょうか
-I/opt/deadbeef/include を削除
-I/usr/include/deadbeef を代わりに記入
あとプラグインの置き場所が予め存在しないとエラーとなるので
mkdir -p ~/.local/lib/deadbeef を実行しておいて下さい 書き込み規制に遇ってました
>>564
あと>>529はdeb-srcの間違いでデッドビーフダッシュピラグインズダッシュデヴをインストール >>564
まずDACがalsamixerで音量変更できるか確認
カード側での音量変更はALSAで可能とは限らない
不可の場合ALSAプラグインにsoftvolと云うのがある
cmusもsoftvolに対応していたと思うが使ったことがない pcm.zero {
type rate
slave {
pcm "hw:1,0"
rate 192000
format S32_LE
}
converter "samplerate_order"
}
sox nsh.flac -b32 -twav - | sox - -twav - gain -1 | sox - -r1536000 -twav - | aplay -v -Dzero 32ビットにフォーマット変換してダイナミックレンジを確保
クリッピング回避の為ゲインを−1db下げる
1536khzでリサンプリングする
192khzまで間引き再生
間引きの為 libsamplerate の samplerate_order を使う仮想デバイスを定義した >569
素直に192khz/32bitにアップサンプリングじゃだめなの? >>570
別に意味ありません
ただこういうのも有りかなと遊びだし
sox test.m3u -b32 -p | sox - -p gain -1 | sox - -talsa hw:1,0 rate -v 192k
これでm3u形式プレイリストを very high quality で192kにアップサンプリングして再生します >>566
書き込み規制なんてまだあるんだ。
つまらん拘りでlibsoxrはDeadBeeFを/optに入れ直してからにしようかと思いになってた。
Gdebi pacage installerっての使うと.debがあれば/optに入れてくれるらしい。
で、.deb探しているんだけど見つからない。そもそも、32bit版提供止めちまったらしい。
んで、SourceForgeの作者ページ?からdeadbeef-staticdeps-master.zip落としてきて、32bitで出来るか眺めてた。
なんか出来そうなのかな?ってとこだった。
さて、ここでレス進んだの見たわけだ。
まず、>>568のconverterはlibsamplerate使うね。"samplerate_best"にしたらDeadBeeFのSRC Sinc_Bestとtopで見るCPU率同じ、コマンドライン見たらlibsamplerate使ってるとあった。
で、SoXのコマンドライン・オプション見てたら全然わからん。--play-rate-argとかあるが、SOX-OPTとかexportしろとかあるが、めんどいなあ、と思ってた。
SoXのマニュアルサイト見てると、どうも、コンポーネントとしてプログラムに組み込むことが主目的みたいだね。ディザをどうのこうってのもあるし、コマンドラインで鳴らすってのに配慮がない。
昔ながらのunix系にある記載スタイルかな。書き方解り難いだろうが、やってみて癖を理解しろって感じだね。
さじ投げようとしたら、sudo apt install deadbeef-plugins-devで、DeadBeeFのSoXプラグインが入っちゃったのでaplayで比較は棚上げする。
/usr/include/deadbeefなんて作りやがった。soxr.cでは、deadbeef/deadbeef.hって指定だから通せたんだね。
音量は、| sox - -twav - gain -1 |で出来たよ。gain -15でDeadBeeFとaplayで合わせられたけどね。
このパイプのチェーンでの指定が「Soxを使い予め変換を済ませて」ってことだったんだね。
つづく つづき
さてさて、DeadBeeFでのSRCとSoXの比較だ。
確かにSoXだとCPU使用率は低いね。
たぶん、理由はアルゴリズムがlinerだからだろう。"Very High"でもFilter-order/Bit-precisionが多いだけだからかな。
SRCは前後比較で頃合い見つけるってロジックが入っているらしいから、その分CPU食うんだろうね。
違いは、煩いアニソンみたいな高域とかいろんな音が入り乱れて単なるノイズみたいになっている部分が整理・分解できるかってところみたい。
完璧にスッキリさせられるわけではないが、結構違いはわかると思う。
つうことで、当方音楽用PCでは頃合いのCPU使用率なんでSRCを使うかな。 規制の理由が判らないので弱りました
あと自分なりに体験しSRCと結論されたのは良いことだと思います
こちらも偶然あなたのレスを読んで暇潰しに始めたことが案外おもしろく新しいことを知る機会になったので感謝してます
蛇足としていくつか
SoXのアルゴリズムはSRCも使っている方式にFFTオーバーサンプリングを組み合わせたもので実装はマルチスレッドに対応しています
samplerate_orderを選択するとALSAはlibsamplerateにゼロオーダー法を使うよう指示します
ゼロオーダーは補完計算をせずアップなら複写ダウンなら間引くというもので今回すでにSoXが1.5Mhzにアップサンプリングした後なので敢えて使いました
「あらかじめ…」といったのはプレイヤーのプラグインで変換し出力先にはコンバージョン無しを選ぶべきといった意味でした
bs2bはどちらもアップストリームは同じです SoXのマニュアルを読み直すと内部データはいつでも符号付き32ビットとある
またレート変換もロングオプションの場合はプラグイン扱いとある
したがってパイプを省略して>>571は
sox test.m3u -32 -talsa hw:1,0 gain -2 rate -v 192k
として良い hw:1,0というのは仮想デバイスhwに二つの引数1と0を与えて使用するという意味
ハードウェア直でカード番号とデバイス番号指定する時に使う
SoXのレート変換にはまだエイリアシングの入切とフェーズレスポンス及びバンド幅の指定が可能でさらに後段にローパスフィルタープラグインを加えたりも出来る
最近耳が悪くなってるなと思っている自分は-b75とか付けてもいいかもしれない
あと非公式にDSD対応のパッチを当てた物がある
sqeezelite LMS mpd その他で採用されているようだ >>575
32の前にあるべき b が抜けていた
-b32 DSDソフトもミキシングとマスタリングはPCMで行われるものがほとんどの筈だ
メーカーがDSDに変換したものを購入するかユーザーがPC上で自ら変換するか
自分達で変換する方が可能性が有りそうに思う
でなけれはPCオーディオってなんだという気がする
アプリは今フロントエンドとしての使い勝手を競っている状況のようだがリサンプラーの時代が来て欲しい なんらかのきっかけの発端になったのなら喜ばしいことです。
こちらも新しいことを知ることが出来ましたので同様に感謝ですね。
さて、蛇足の部分ですが、SRCサイトで言及されていたんだけど、SoXって一旦アナログに戻してリサンプルってあるんだよね。
当方の頭ではデジタルしか扱えないCPUでどうアナログ扱うんだろと理解が及ばないんだが、FFT使うってことを指すのかな?
さてのさて、おたくはyoutube-dl扱えますか?
非線形ジェニアック
https://www.youtube.com/watch?v=coBZrVo3vtM
これ盛大にclipしてるソース(DeadBeeFのgain scannerで見ると-10.26)の先に言及した類いのアニソンで、素で鳴らすと高域ぐちゃぐちゃと感じる。44.1kHzからyoutubeなのか48kHzにただupsamplingしてるだけだからだろうか。
元がどう鳴るはずのものかは知らないが、聴きやすくなるのはどっちかって観点。
DeadBeeFでは、SRC:Best_Sincで、ScanしたGainをタグに書き込んだが、設定>再生のProcessingは'Only prevent clipping'だけにした。
SoXでは以下、SoXが.opus扱えないんで、opus-tools入れて以下でならした。clipは-3辺りでしなくなる。
opusdec --gain -10.26 --float --force-wav '/tmp/TmpWork/非線形ジェニアック-coBZrVo3vtM.opus' - | sox - -twav -b32 -talsa hw:1,0 rate -v 192k
opusdecの--gainだとなかなか音量合わせが難しい。
aplayで鳴らそうと思ったが、pipeを| aplay - -v -D48bestとしてもフォーマットが判らんと鳴ってくれなかった。
pcm.48best {
type rate
slave {
pcm "hw:1,0"
rate 192000
format S32_LE
}
converter "samplerate_best"
} あ、>>579は>>574へ
>>578
DSDってよく判ってないが、ファイルサイズのデカさで拒絶状態。
.apeのようなlosslessでそこそこ高圧縮か、.opusのようなlossyでも高品位な圧縮形式が出てこなきゃ縁のないものだな。
音楽って個々の音の緻密さってわけではないし、楽しむ観点では、44.1kHzでもなんら問題ない。176.4kや192kで得られる緻密さでもう耳はアップアップだ。もういらん音表に出すなった感じ。ただ、16bitのダイナミックレンジは不足かなって感じではある。
恥ずかしながら、今回初めてgainってのをいじった。これまでは何も調べず音量ノーマライズやそのための手元でコンプするようなものと思ってた。clipってのもソースの問題だと思ってたな。
>自分達で変換する方が可能性が有りそうに思う(改行)でなけれはPCオーディオってなんだという気がする
gainスキャンもPCオーディオならではじゃないかな。
>アプリは今フロントエンドとしての使い勝手を競っている状況
なんか、アプリでも音弄りはあるようだね。やはり音はどのアプリでも同じではないらしい。
聴こえるはずのない周波数を再生しているとアプリが表示してるってことからこんなこと調べる人もいる。
https://poor-user.blogspot.com/2020/08/blog-post.html
PCオーディオは未踏領域がまだまだあり可能性大きいと思う。
リサンプリングも当方が目的とする混濁部の整理がもっと上手くなってくれると嬉しい。
妄想してるのが、テスト音源作って、それを個々人環境で鳴らしてマイクで計測てか録音、それをソースと比較して、セット個々の最終特性を補正するイコライジングパターンを自動で作ってくれるなんての。 >>579
youtube-dl -f 251 URL そして ffmpeg -i xxx.webm -vn -acodec copy hisen.opus 該当ファイルを hisen.opus として入手
opusdec --float --force-wav hisen.opus - | sox - -n stat 統計を取り263サンプルでクリップを確認
opusdec に gain -1 を付けるとクリップは1ヶ所となったので gain -2 でsox に渡しリサンプリングを実行してみる
opusdec --float --gain -2 --force-wav hisen.opus - | sox -V - -e signed-integer -b32 hisen.wav rate -v 192k
クリップはopusdec sox どちらに於いても発生しなかった
wav がコーデックではなくコンテナだとは知りませんでした
浮動小数点のまま wav に格納されたのが aplay で再生できなかった理由のようです
-e signed-integer フラグで符号付き整数を指定すると再生できました >>580
概ね同意です
DSDかPCMかというのは種々のDACに使われているDA変換チップとの相性の問題で一般化は出来ないのではと考えています
むしろ過去のCD音源をどう活かすかに興味があります何故ならサンプリングの理論上ではCDDAで本来はのアナログ波形を再現可能とされているわけですから、、、
現実には再生に無限の時間が必要だろうし何処迄行ってもデジタルのPC内では完結することはない話ですがやれることは有るはずです
さて紹介されているページを覧ましたが判断を下すのに必要な情報が欠けているように思います
元データが変形したのはフィルターを掛けたためあるいはリサンプリングのエイリアスと考えます
設定でオフにしてそれでも変形するならアプリが黙って色付けしているということですから良心的とは言えないでしょう
(そんなことをする理由は思いつきませんが、、、アプリで音データは変わらないという立場です)
その辺りが参照先ページでは判然としませんでした
例えばALSAは設定を変えずに使うと libspeex を使って48Khzにリサンプリングします( speex はspeaks の洒落で電話用)
またマイク端子がある場合これもオフになっていないとノイズの発生源になりえます
直接ハードウェアが対応している形式でhw仮想デバイスに出力するのが一番手っ取り早く安心できる方法かなと思います
ただ以上は思いついたことをそのまま述べただけなので実験は必要ですね
それと最後におっしゃったフィードバックのアイデアいいですね あと>>562で仮想デバイス内でのfloat/integer変換を使ってます
ただ入力に合わせて変換するしないを分岐する方法があるかは知りません >>582
標本化定理(サンプリング定理)によりサンプリング周波数の半分(22.05kHz)以上の
帯域を切り捨てているから絶対に元の音にはならないわけだが (もちろんそれ以下の低い成分しかない音は再現される) >>584
可聴域外の音波は音と呼べるかどうか
現実世界では可聴域外の音波がその外の音波と干渉しあって音環境とでもいうべきものに変化をもたらしうる
しかし記録媒体の再生に於ては関係無いし無視しても良いのでは? >>582
紹介したサイトへの突っ込みはなんらかはあると思ってました。ただ、
>元データが変形したのはフィルターを掛けたためあるいはリサンプリングのエイリアスと考えます
当方には、リサンプリングなりフィルター掛けたとは読めないんだけど、どこだろう。
>アプリで音データは変わらないという立場です
多分、音データ扱うロジックは汎用というか共通ライブラリを使うはずという認識だろうと推察しますが、パラメーターの渡し方とかもありますし、どれも画一とは限らないですよね。
ボトムで設定とかで追い込まないと変な音出すアプリはあったりしておかしくないと思ったりします。
フィードバックのアイデアですが、続きがありまして、先のアイデアは出し側の調整です。
続きとして、受け側の調整というものも組み合わせないと、正しくイコライジングした音に違和感を感じるかも知れないという観点からです。
受け側の調整とは、周波数ごとの聴こえ方、つまり、個々人の当ラウドネス曲線を調べ、それを元に出し側のイコライジングパターンをさらに調整してパーソナルな最適f特システムに仕上げるって感じでしょうか。
それぞれを明らかにして自分のシステムや自分自身を認識できるだけでも、聴き方が変わるんじゃないかなと思います。
オーディオ機器業界からはまず出てこないでしょうから、PCオーディオの真骨頂じゃないかなと妄想だけ広げてますです。
ときに、cmusですが、どうしても再生開始時点で乱れやノイズが入りますね。
先の.opusファイルの場合、binaural設定のasoundr指定で鳴らすと音が出る直前にパツンと心臓に悪い大きな音が入ります。
なんかありますかね。
また、先の.opusファイルに対する、SRCとSoXでの聴感上の違いは感じましたでしょうか。
高域での混濁具合です。
SRCの方はDeaDBeeF使えればいいんですけどね。
あと、出力デバイスを"without any conversions"とありましたが、SRC効かせるなら"with all software conversions"でないと裏で弾かれますので確認下さい。 >>587
cmus の初再生時のクリックですが修正不可です
2014年に問題は認識されて2017年にパッチが作られた
そこで2019年の最新版のソースを認した所マージされていないようです
当方では samplerate_fast で精一杯なので Sox/SRC の比較はできません耳も悪いし、、、
音波が耳に届く(耳の形で特性が変わる)
耳の穴の中での反響共鳴吸収が起こる
結果スペクトルの分布が変わる
蝸牛器官にてスペクトル分解され脳にデジタル信号が伝達される
以上を踏まえヘッドフォンと外耳の型取りをした特注イヤープラグを組み合わせたもの
ヴィデオのカラーバー画像に相当する音源
これら二点を用意しイコライジングする
楽しくなさそうなんだが、、、 >>587
まず alsacap を用いてカードの仕様を確認
without any conversions で出力して下さい
また linux の音の良し悪しですが実験に良さそうなプレイヤーを見つけました
使い方はソースを読んで下さい (200行もありません)
当方では問題なくコンパイル出来ました
wwwドットkatsusterドットnetスラッシュindex.php?arg_act=cmd_show_diary&arg_date=20140212 >>588
cmusの件、不可避ですか、残念。
>当方では samplerate_fast で精一杯なので
ちょっと半信半疑ですが、これも残念。
>耳も悪いし、、、
当方も、悪いわけではないのですが、耳鳴りがね、特に高域が、、、。
んで、高域具合をどなたかにでも、聴き比べて貰いたかったんですがね。これも残念ですね。
イコライジング環境は大層ですね。
こっちの当ラウドネス曲線調べるのも結構難しそうなんですがね。 >>589
親切なのか意地悪なのか、何か試されてるのか、、、んんー。
alsacap探し出してmakeしましたよ。
得られる情報は既知の範囲ですね。
>without any conversions で出力して下さい
alsaがリサンプラー:libsamplerateやサンプルフォーマット:S32_LEだからそういうんでしょうね。
でも、DeaDBeeFだと音おかしいんだよね。ま、比べてみて下さい。
urlのサイトはお勉強になりました。特にcatで得られる情報。
でもね、提供するのが.cファイルだけって、んん、gccなんか使えない。
一応、ソース見て初めの方のusage見る限り、aplayやらじゃだめなのかって感じです。
サイトの注釈、cmusと同様冒頭ノイズ入りますって、ちと遠慮ですね。コンパイルも出来なかったし。
$ gcc -o ./20140212_alsa_play.c -lasound
/usr/lib/gcc/i686-linux-gnu/7/../../../i386-linux-gnu/Scrt1.o: 関数 `_start' 内:
(.text+0x28): `main' に対する定義されていない参照です
collect2: error: ld returned 1 exit status
エラーの意味がわかりません。ってか、コマンドがこれでいいのかも不明です。
ときに、係わったついでに、SRCとSoXのりサンプラー比較してみてくれませんか?
ああ、wiki見ると書いてあるけど、ALSAでmidiが扱えるのって、生い立ちが元々Gravis Ultra Soundってサウンドカードのデバドラとして開発されたからね。
通称GUSは高品位な音とそれこそmidi特化といえる位充実してた。それ使うためにかなり開発にリキが入ってて生き残ったんだろうね。
当方も、Gravis Ultra Sound Maxっての使ってTimidityでmidi聴いてた。当時はLinuxなんか使えるレベルでなかったから、ほぼDOSだったけどね。 >>591
目が覚めたのでデッドビーフを起動してみました
コンバージョン無しで正常に再生されましたがハードウェアに直接アクセスしている場合環境依存であることは言うまでもありません
デッドビーフの設定の内サウンド欄はデバイスとデバイスに与えるヘッダー情報を設定しているようです
ビット深度を決める元になるのは音源と設定とデバイス側の情報の三つあります
設定で16ビットを24ビットに変換等となっているとまずデバイスが24ビットに対応しているかチェックします
当方では対応していなかったのでより深い32ビットに設定します
次に音源をチェックします
OPUSは非可逆圧縮なのでビット深度の概念がありませんのでデコーダー依存となり符号付き16ビットになる
そのままSRCを通ります
するとデバイス側の32ビットと合わないのでデバイス側を16ビットに変更して再生するようです
このときコンソールにメッセージを出します
以上寝ぼけ眼の報告でした >>592
withとwithoutでの動作、大凡の見当どおりだと思います。
当方の環境はDDC→DACです。
DDC:M2Tech hiFace Two
DAC:Musical Fidelity V-DAC
どっちも、何で入れても出しを192kHz/24bitにするらしい、DDCは192kHz/24bitで入れてくれるといい仕事しまっせという記載がある。
だからDeaDBeeFで16bit→24bitで192kHz or 176.4kHz/24bitにしてるわけです。
機器の機構使うよりPCでの処理の方がよいだろうという期待もあります。
問題は、24bitで欲しいといっているDDCのサンプルフォーマットにS24_LEなりがないことですな。
DeaDBeeFの16bit→24bitコンバージョンが意味のあるコンバージョンなら、16bitに戻されるのは困るわけです。
実際再生印象は異なると感じます。
24bit→32bitは多分下位8bit分"0"を足すだけでしょうが、16bitにするとDeaDBeeFでのコンバージョンが無駄になるような気がするんですね。
ただ、面白いのは、opusdec使った時のコンソールメッセージに25bitと出たんですね。
youtubeからのファイルは48kHz/32bitとありますが、それはコンテナの値で内部データは別って話なんでしょうね。
youtubeの32bitって元はCDだろうから単純に16bit分ゼロ埋めしただけと思ってましたが、25bitもあればそれは音としていいわけですね。
いろいろ弄ってると面白いコマが飛び出してきますね。 >>593
alsacapの件はmakeした記憶が全く無かったため失礼しました
DDCにS24_LEが無いというのはどうやって確認したんでしょうか
25bitというのはfloatの有効桁数です
ユーチューブからのファイルが48kHz/32bitというのは何を指しているんでしょうか
デッドビーフ内でopus出力は16ビットで処理されSRCもそれを引き継ぎ16ビットで処理をされている
DDCは想像ですが受け取った16ビットの下位に00000000を付け足して処理するでしょう
つまり変化は生まれない
opusに関してはプレイヤーとは別にリサンプリング処理を行ったほうが有利でしょう
ただユーチューブのビットレートでは細部は失われていると思います >>594
あれ? alsacapの人とcmusの人は同じ? IDが違うだけ? ま、いいか。
>DDCにS24_LEが無いというのはどうやって確認したんでしょうか
DDCに「ない」は不適切かも知れません、ALSAが認識するデバイスのSample formatの項目にリストされていないということです。
alsacapでもリストされません。windows用のdriverにはあるのかもしれません。
>ユーチューブからのファイルが48kHz/32bitというのは何を指しているんでしょうか
youtubeから楽曲downloadで指定した-f 251が48kHz/32bit 160kbps max のopus形式に変換されたファイルだということです。
mpvというplayerで再生中に shift+i とすると、フォーマット形式や再生中のbitrate等々の情報が得られます。
>デッドビーフ内でopus出力は16ビットで処理されSRCもそれを引き継ぎ16ビットで処理をされている
ここの処理シーケンスてか処理フローはよくわからないですね。
ただ、32bitのファイルですから以下の通り16bitで処理はないのだと思ってます。また、16bitファイルも16bit→24bitを指定すればDeaDBeeFがリサンプラーに渡す前に24bitか32bitにしてるようです。
youtubeから-f 251で落としたファイルyoutube.opusとして、
opusdec ./youtube.opus decode16.wav とデコードすると47,841,356Biteの16bit形式のファイルが得られます。
これをDeaDBeeFで、再生し/hw_paramsで見ると以下です。リサンプリングのオン/オフは影響を受けませんですね。
16bit→24bit:off は、format S16_LE
16bit→24bit:on は、format S32_LE
一方、
opusdec --float ./youtube.opus decode32.wav とデコードすると95,682,692Biteの32bit形式のファイルが得られます。
これは当然4パターン総てS32_LEですね。youtube.opusそのままでも同様です。
また、続く 続き
>opusに関してはプレイヤーとは別にリサンプリング処理を行ったほうが有利でしょう
そう考えられる根拠が不明なのでなんともいえません。
>ただユーチューブのビットレートでは細部は失われていると思います
まあ、著作権絡みの網抜けで部分的に音量弄るってのは聞きますね。
ただ、-f 251のbitrateは160kbpsで、実際、mpvのshift+iで見てるとそのとおりですから細部の喪失ってのはそうないと思います。
CDをまんま.opusにしてもbitrate 160kbpsであれば、スペクトラムで比較してほぼ欠落がないと云われてますね。
cmusでの音量コントロール、sshで入ってるので別のsshセッション作って、以下で出来ましたね。
alsamixer -D hw:1
ただ、これで音量弄ると当然てば当然ですが、DeaDBeeFなどにも影響してしまいますね。 >>596
規制で回線を変えました
S32がS24と考えてください(偶数バイトで処理するため)
いまmpvでかくにんすると format: floatp と出ました
24変換onで32になるのはplughwが変換するためです
結局ゼロが16個付いただけです
予めリサンプルすべきと考えるのは16ビットに丸められるのを回避出来るからです
目安として160kを48kで割ってみて下さい(実際は130k程)
どう思われますか?
alsamixerで音量変更出来るならcmus自身でも可能なはずだと思います 繰り返しになりますが非可逆変換の場合ビット深度というものは無いと考えて下さい
例外はあるしopusの資料はチェックしてませんので間違いかもしれませんが… もう一度読み返して前提が根本的に噛み合っていない点があるのに気付きました
当方ではYoutubeからのopusファイルは16ビットだということです
>>581のやり方に問題が有るのでしょうか? >>599
訂正します
リサンプリング無し
24ビット変換オフ
コンバージョン無し
hwparamsがS32_LEになりました
いままで述べたこととは矛盾するのでもう一度最初から考えます >>599
ちょっとレス飛ばして、先にレスします。
明日ってか本日タイトなんで就寝しようとしたんですが、寝付きが悪いので入れておきます。
ダウンロードのやり方に問題はないと思います。
32bitと云うのは、当方はDeaDBeeF 0.7.2も使っていて、そっちで再生中の最下部に表示される再生中ファイルの情報項目にビット数が表示されること。
リサンプルとか全オプションを外して再生した場合の/hw_paramsでS32_LEを確認したからです。
1.8.3ではビット数の表示がないですね。ちょっと表示するオプションがあるのか不明です。GTK表示設定辺りか?
上記方法でしかビット数を見たことがないです。(ただし、youtubeのヘルプだかの記述で48kHz/32bitと見てました)
しかし、今以下二通りやってみました。
手元PC内臓アナログデバイス経由のmpvで.opusを再生させて/hw_paramsを見たらS16_LEですねぇ。
同様に、音楽PCでcmusをtype hw:1.0とDDC経由だけにしての再生で/hw_paramsを見たらS16_LEですねぇ。
なんなんだろう。
当てずっぽうですが、oggコンテナってのに乗ってるってことなので、その関係かも。 opusdec に --float オプションを有するのは丸め誤差無しでデータを渡すために付いているのでしょう
SRCの公式サイトで API を見ると float/integer の変換も提供しています
これらから libopus libsamplerate 共に内部では有効桁数25bitのfloat型で処理していると考えます
するとDeaDBeeFがS32_LEで再生するのは当然であった訳です
ただターミナルでのメッセージにて DeaDBeeF が32bitのデバイスを見つけられないと出るのが分からない
24bitのwavなど作って実験中ですが多少DeaDBeeF側にバグがあるように思います
(同じ入力に対する反応が一つ前の再生によって変わり再生しなかったりする)
あくまで途中経過報告です opusの仕様( RFC 6716 )を見たところ処理は整数で行うしかし最終段は整数でも浮動小数点数でも良い
又その後のリサンプラーは non-normative つまり実装に任せるとなっています
opus-codec.org による実装APIを見たところ読み出しは16ビットと浮動小数点数と2つの関数が用意されています
opusdec のソースを見たところ speex_resampler.h がインクルードされています
DeaDBeeFのopusプラグインのソースを見たところ op_read_float が使われています
SRCのAPIを見たところデータ構造体の定義内に以下の項があります
float *DATA_in, *DATA_OUT;
つまり浮動小数点数へのポインタです >>601
今cmusで音量変更できないと言われた意味が分かりました
次でhwデバイスを選んでいてもマスターボリュームと+-ボタンが連動します
:set mixer.alsa.channel=Master
今までメディアキーを使っていたので気づきませんでした ソースをそのように読めるっていいですね。何かこっちの分野で作られているのですかね。
>>597 >>598 が
>>603 で修正されたと捉えて良さそうですね。
16bit→24bitの効果は、QualityがSinc_Fastestのアップリサンプルでも音は変わる印象を確認して欲しいとかのレスを入れようとしていました。
24bit枠に拡張なら24bit使ってるんだろうなと感じる変化に聴こえます。
リサンプリングってのは、「作り直し」って期待的認識です。
非可逆圧縮音源もデコードしたところから、bit拡張すれば、その拡張したbit数に合わせて作り直すんだと思っているんですね。
音量の件、カラクリは見当がついていたんですが、そう表現できなかったんですね。以下で音量調節はでけました。
:set mixer.alsa.channel=master
:set softvol=true >>606
眠い時にやったことは全て詰めの甘いスレ汚しになってしまった
結局あなたの耳が正しかった
ごめんなさい >>607
おや?
あやまる話でもないでしょ。いろいろ見識人がったしスレ汚しではないし。
当方の耳褒められた?のは嬉しいですけどね。 >>608
今アプリで音が変わるか実験始めたところなんですけど、、、
変わった!みたい、、、
DeaDBeeF aplay sox Audacityはアウト
Audacious cmus あと>>589で言及したものはオッケー
ただどこで見落とし勘違いがあるか不安と楽しい喜びを感じている
pcm.!default {
type copy
slave.pcm "tee:'hw:1,0',/tmp/tee"
}
これでdefaultに出力するとtmpディレクトリーにteeというファイルができる
rawファイルです
Audacityで18.5kHzサイン波(ステレオ)のwavファイルをつくりそれぞれのプレイヤーで再生した gentoo player、ver3.0リリースに伴い全機能使うには有料になったのか
ver.3.0で音質良くなってるのかね? 873 名無しさん@お腹いっぱい。 sage 2020/10/04(日) 00:33:25.21 ID:gewyZDDb
みみず、今度はGentoo Playerが有料になったのに立腹して作者にクレームか
作者の謝罪メールを公開とか、益々イカれて来た 何故かうちの環境だとDeadBeefでDSD再生出来ない。 PulseAudio通すと48KHzにリサンプルされるはずなんだけど、
Spotifyは44.1KHzで出力されてる。Alsa直結なんだろうか? voyageでUSBDAC認識しないのってPC古いせい? >>614
> 認識しない
という表現が分からない。
lspciやlsusbコマンドで表示されないとかなら兎も角。 >>615
そう、それです!
表示されません!
それが言いたかった!
では、引き続きよろしくお願いいたします。 >>612
あー、トンチンカンなこと云ってたら、ごめん。
詳しくもないんだが、DeaDBeeFはDSD読み込めないんでないかい。
ChangeLogに1.8.0で、「added wavpack version 5 support with DSD」ってあるし、ffmpegプラグインにdsfの記載もあるんだがな。
現状、DoPを受けられるDACに渡せるだけみたいだな。
https://github.com/DeaDBeeF-Player/deadbeef/issues/1653
DoPにすると一応プレイリストには入れられるってことかな。
作者には、昨年2月の時点でDSDに取り組む計画はないようなこと云ってるね。
ASCIIの記事によると、DSDの5.6MHzを例にかな?
「DSD over PCMという意味で、おおざっぱに説明すると、DSD信号を「176.4kHz/24bit(16bitがオーディオデーターで8bitはDSDマーカー)のリニアPCM信号」だと偽って、無理矢理USB出力してしまうもの。 」
(https://ascii.jp/elem/000/000/769/769050/5/)
だから、48kHzでなくて44.1kHzであってるんでないかな。
2.8MHzの.dsf拾ってきてNotePCのアナログ(AD1985)出力でmpvに食わせても、44.1kHz/16bit再生だな。 Linux版もあるのでこっちにもコピペ
Album Playerというのを最近知った
Linux版とWindows版がある
Windows版を試したがかなり高音質だ
インストールしなくてもいいからすぐ試せる
ダウンロードはここから
↓
http://vv.uka.ru/aplayer_eng.html すまん
Album Player for Linuxのダウンロードはこっちだった
↓
http://albumplayer.ru/linux/english.html PulseAudioいじらないといけないのがめんどい Album Player for Linux
ロシア製ソフトだからウィルスの心配しないといけないかな?
ウィルスが混入されていたら困るな >>622
カスペルスキーでチェックすれば問題無しw ロシア製ソフトのウィルス・チェックは
ロシア製セキュリティーソフトでチェックすればいいんかい
なるほど、うまいジョーク
てか、それ一理あるな 結局PCオーディオ関係スレは何処へ行ってもミミズがいる
とてつもない絶望感を感じますね みみずの糞を嗅ぎまわってそこらじゅうのスレで悪臭をばらまいているJPLAY元デスク岩橋がここでも糞しとる JPLAYスレが満杯で行き場が無くなった窪田洋みみず工房主
ここは痴呆老人の集会所ではありません
一行も自分でプログラミングできないのに薀蓄タレるのはご遠慮ください 新しくAlbum Playerスレが立って、みみず禁止だってさ
これは賢い方法だ
無関係のレスはみみず窪田洋が書いたのが一目瞭然というわけ
自ら交番に出頭みたいなもん JPLAYがなんかゴタゴタしてんのはTwitterでうっすら見聞きしたがここで書かれてることが何なのかさっぱりわからん 脅迫まがいのことしてた日本代理店が辞めさせられたの根にもって荒らしてる
IDコロコロしてるけど全部ひとり あいつは自分が糞しておいてその糞をミミズがした糞だとミミズをののしる変態だ
まさに糞のような奴だよ JPLAYスレは早速表示されなくなってるな
2日で消えちゃうのか
https://i.imgur.com/7ezPJPy.jpg みみずが自分のブログでAlbum Playerの連載を始めたわ
初回は単なる紹介とくだらん脱線だけで、使い方は次回
みみず信者がこれを読む→他にもないかググる→
【みみず厳禁】のスレタイを見つける→他のスレも見る→
陰湿なasoyaji叩き等、数々の悪行と二重三重人格を知る ピュアAUで「みみず厳禁」の文字は、特に勢いがいいスレじゃないから、かなり長期間目立つ
jplayで検索すると、jplay凌駕で引っ掛かる
スレ主はSEOのプロかよ bluetooth receiver やってみたくて、aptx-hd sink まで対応できた
https://github.com/EHfive/pulseaudio-modules-bt
pulseaudio の有名なこれでやった
pulseaudioの音が悪いことの一つがresamplingが走ってしまうことろのよう
pulseaudioではbluetoothを一度monitorでsink inputを作ってそこからhw source outputに入れなおす構成になるんだけど
このmonitorが設定にかかわらずresampleしている
根本原因としてmonitorが汎用的にvariable rate対応しているため
このvariable rate対応をコードをいじって無理やり外すと、resampleせずにそのままデータを渡せた
個人的にbluetooth環境はこれで満足できる
pulseaudioはかなり安全側というか便利側に振ってあるので、高音質は難しいと感じた
勉強になったけど ここのプレイヤーのおススメはなんでしょうか?
OSはPenMの古い古いPCなので Lubuntuしか入りませんでした
昔Vineだったかは入れたんですが、今回はこれです 作者の日本人に対する印象はどん底へ
905 名無しさん@お腹いっぱい。 sage 2020/10/08(木) 13:08:32.37 ID:euDpG5mb
Gentoo Playerの中の人の怒りが....に込められている
komaとknkn59もミミズもろともbanだな
ミミズに余計な餌を与えた当然の報いと言えよう
そもそもkomaがGentoo Playerが有料になったと騒ぎ立てたのが発端だ
ミミズが速攻で反応して、中の人に送った内容はこんな感じ
「お前のソフトは無償だったから使ってやったのに、急に年間29ドルも取るって何様のつもりだ」
「komaが作ったガラクタ電源を恵んでやるからPink Faun I2Sカードをサポートしろ」 linuxをメインで使い始めてもう一年半たったたけれど、MPDとかラズパイとかしなくても
十分良い音出る。なのになんでここの人たちはデスクトップOSとしてlinux使わないの?
PCモニター小さくてデスクトップオーディオになるからそうしてるの? コテハン付けてる時点でガイジ確定なんだよなぁ
雀の涙とか結構前からNG入ってるわw Ubuntu 20.04 MPD + Cantataで、「MPD仮想ファイルシステム」で、「フォルダなし?MPDが正しく設定されていないようです」
というエラーが出ます。音楽フォルダーは起動ディスクとは別の内蔵HDDで、fstabでOS起動時に自動的にマウントするように
設定してあります。mpd.confにはそのフォルダーを設定しています。
何がいけないのでしょうか? 現状だとLinuxでDSDをネイティブ再生出来るのはMPDしかない。 >>650
deadbeefでCDデータ聴いてもDACには48kって表示されるからおかしいなと思って調べたら デフォルトでDSPが入ってて48000にアップされてた >>650
そこに書いてあるALSAプラグインーリサンプリングのチェックを外したら
音がクリアになった
前から音がおかしいなと思ってたんだけど
いろいろイジらないと普通に鳴らないdeadbeefってクソじゃないのか >>654
>>655
設定もろくに見ない貴方達が 質問をさせてください。
ubuntuでpalseをアンインストールしない状態でChoromeにALSA出力させることは可能でしょうか?
一台はPalseを削除してUSBDACの優先順位を一番に持ってきてChoromeで音を出せていますが、これだとAudacityがALSA表示されないためつかえません。(他の原因かもれませんが)
一台古いPCを貰ったのでUbuntuを入れてPalseをそのままで使う予定ですが、ChoromeALSAをやりたい。
優先順位を一番にしてFireFoxとChoromeを安いヘッドホンで聞き比べしたのですが、同じにきこえます。
やはりPalseが入っているとそちら優先なのでしょうか?(違いが分からなかった可能性も含めて)
ChoromeALSA強制の設定ができるなら知りたいです。宜しくお願いいたします。 >>657
結論言うと普通はPuleseAudio入ったままでALSA強制はchromeでは出来ないよ
昔Firefoxで強制ALSAに出来る方法はあったけれどもう封じられてる。chromeも同じかもね
そもそもソースのサンプルレートに対してPulseAudioとALSAまで間でサンプルレートが一致していれば
強制変換は起きないし劣化もない。48系と44.1系が混在しているソースならば、PulseAudio上で
かなり高品質なリサンプリング処理が聴感上無劣化で処理できるから設定詰めれば良いんでないかな〜 ありがとう
無理そうですか
最後の設定を詰めれば?というとは例えばどういう事で? >>658
なんとなくですが、分かりました
例えば44.1しか再生しない環境なら、ALSAの設定を44.1にしてしまった方が音質としては正解ということでしょうか?一例ですが >>658
Chromeは直接Alsaを叩けないっていうことですよね。 DaphileはALSAも否定しているな。Kona Linuxと真逆の考え方だ。 ■ このスレッドは過去ログ倉庫に格納されています