アンプ出力の周波数スペクトログラム比較 ― 2025-04-13
第二世代電源で駆動したアンプと通常電源で駆動したアンプでは、その音を聞けば音の違いが明確にわかる。しかし、なかなかその現象をデジタル・ストレージ・オシロ（DSO）では捕まえられない。DSOは電圧信号しかみないためコンデンサ電圧レベルで発生している微小な電流の逆流は捕まえらえない。そのタイミングで音楽信号が欠損しているのだが、その証拠がなかなか捉えられない。
いくつかの証拠として、次のような客観的な現象は確認されている。
1．電圧降下を基準として設計された管球アンプのリニア電源を第二世代電源に替えると、真空管にかかる電圧が10％ほど上昇する。これは同じ負荷抵抗に対して整流回路を流れ出てくる電流総量が通常電源より10％多いということである。つまり変換効率が10％も高いのだ。
この現象は当店のブログ(https://practnaga.asablo.jp/blog/2024/11/04/)でもチューニング作業の途中で紹介しています。
２．左右独立したパワーメータを持つLUXのトランジスタアンプに、片ｃｈだけ第二世代電源に変えた場合、モノラル信号を左右に入れると第二世代電源側のメータの振れ幅が10％以上大きくなる。これも電流総量が増えてその分出力が上がっていることの証拠である。
これだけの物理的現象が確認されていてもなかなか波形の証拠となると捉えにくい。単純なFFTをかけても間欠欠損はつかまらない。。そこで、音楽信号が一部欠損していれば、そのタイミングで音声のパワースペクトラムが下がる。それがある程度周期的かつ継続的に発生していると周波数スペクトラムにした場合、描かれるパターンに薄いところが出るはずである。つまり3次元解析すればなんとか、という思想のもとに、ピンクノイズをアンプに入れてそれを再生した場合のアンプ出力音声のデータについて、周波数スペクトログラムを撮ってみた。（ピンクノイズは可聴範囲の音が均等にばら撒かれているノイズ信号である）
その結果が次の2枚の画像データである。
左側（普通電源） 右側（第二世代電源）での記録を比較できるように左右に並べた。
1枚目は周波数10Hｚー6000Hz の範囲で分析したもの。
（波形はクリックで拡大できます。でも小さいままのほうが差がわかりやすいかも）
いくつかの証拠として、次のような客観的な現象は確認されている。
1．電圧降下を基準として設計された管球アンプのリニア電源を第二世代電源に替えると、真空管にかかる電圧が10％ほど上昇する。これは同じ負荷抵抗に対して整流回路を流れ出てくる電流総量が通常電源より10％多いということである。つまり変換効率が10％も高いのだ。
この現象は当店のブログ(https://practnaga.asablo.jp/blog/2024/11/04/)でもチューニング作業の途中で紹介しています。
２．左右独立したパワーメータを持つLUXのトランジスタアンプに、片ｃｈだけ第二世代電源に変えた場合、モノラル信号を左右に入れると第二世代電源側のメータの振れ幅が10％以上大きくなる。これも電流総量が増えてその分出力が上がっていることの証拠である。
これだけの物理的現象が確認されていてもなかなか波形の証拠となると捉えにくい。単純なFFTをかけても間欠欠損はつかまらない。。そこで、音楽信号が一部欠損していれば、そのタイミングで音声のパワースペクトラムが下がる。それがある程度周期的かつ継続的に発生していると周波数スペクトラムにした場合、描かれるパターンに薄いところが出るはずである。つまり3次元解析すればなんとか、という思想のもとに、ピンクノイズをアンプに入れてそれを再生した場合のアンプ出力音声のデータについて、周波数スペクトログラムを撮ってみた。（ピンクノイズは可聴範囲の音が均等にばら撒かれているノイズ信号である）
その結果が次の2枚の画像データである。
左側（普通電源） 右側（第二世代電源）での記録を比較できるように左右に並べた。
1枚目は周波数10Hｚー6000Hz の範囲で分析したもの。
（波形はクリックで拡大できます。でも小さいままのほうが差がわかりやすいかも）
よく見ると少しであるが、左側の方が濃度のマダラが荒く、幾分色も薄いことがわかる。この分析は通常のFFTでは低周波数領域の分析が荒くなる現象を解消するCQTというテクニックを使って分析している。みた感じ500Hzまでの濃淡差が大きいようなので、
分析範囲を500Hｚまでに下げてみたのが２枚目である。
均一さと濃度でやはり右側のデータの方が優秀であることがわかる。。。。。
分析範囲を500Hｚまでに下げてみたのが２枚目である。
均一さと濃度でやはり右側のデータの方が優秀であることがわかる。。。。。
しかし、これらのアンプで音楽を鳴らすと、その差は明瞭にわかってしまう。
ここで欠損しているデータは音の余韻を消し、時間軸を狂わせていて、臨場感や空気感を大いに削いでしまうのである。
人間の耳の（体の）音楽に対する鋭さと雑音に対する鈍さをあらためて感じた次第。
分析プログラム(python)には次のページの内容を参考にさせてもらいました。
https://yukara-13.hatenablog.com/entry/2013/12/01/222742
ちなみに測定したWavデータは次に入れてある。
"https://www.practsoundsystem.jp/wav/normIO_Cut.wav"
"https://www.practsoundsystem.jp/wav/2ndIO_Cut.wav"
それぞれ15.4Mbのサイズがある
店のホームページ刷新しました。 ― 2024-02-07
店のホームページは20年前に知り合いに頼んで作ってもらいました。気に入っていたのですが作りの古さが気になりだしました。というのも最近ネットでHTMLを調べていたら「FRAMEを使うのは古い」とか「いまだに使っているページを見かける」とかかなり手厳しいことが書いてありました。確かに当店のページはFRAMEを使っています。まぁ20年間ほぼデザインを変えてませんから仕方ないですが。
そんなわけでHTML5.0の機能を少し齧ってTABメニューとドロップダウンの構成にしました。
スマホでの表示でも不具合にならないように、家のサーバに入れて実験・確認してからリリースしました。ロゴはトップページに入った最初の１秒間だけ動きます。なんとか起き上がるぞ、という気持ちをこめて立ち上がってくるアニメです。
まだ稚拙なコーディングですので、皆さまご覧になってご意見などあればご指摘ください。ただ、
お客様からいただいているたくさんのページが「お客様からのご報告」のタブにまとめてあるのですが、古いものでは私のプラクト開店以前のホームページ(Nagasほーむぺーじ)を参照しているものもあり、それらはリンク切れになっています。これはご勘弁ください。2000年以前のデータはもうないです(^^)
PractHomePage: https://practsoundsystem.jp
ソフト三昧の日々 ― 2023-12-09
ここ半年ほど、PostgreSQLからSQLServerへのデータ移行という仕事をいただいてやってました。
エクセルを使って設計書・手順書を作成することと、その手順に関係するSQLソースやテーブルを作成すること、そして自室に両方のデータベースを立ち上げて移行手順の検証（いわゆるデバッグ）を行うことです。
すべてリモートワークで自室での仕事でしたが、オンラインで若いエンジニアの方々と仕事することはとても楽しく充実した時間でした。
この作業においては納入先現地とほぼ同じ環境を自室に構築する必要があったのですが、SQLServerを立ち上げるためにはWindowsを起動する必要がありました。Microsoftの製品であるSQLServerにはMac版は無いからです。私はパソコンはMacと決めてますので我が家にWindowsマシンはありませんが、MacBookProには仮想環境(VMwareFusion)を入れて一応WindowsOSも入れてありました。今回これを最新のWindows11にバージョンアップしてSQLServerを立ち上げました。
この環境構築において、私の机にはWindows11の入ったMacBookPro,開発ツール類の入ったMacMini（2画面）、メールや情報検索用のiPadProと都合4つの画面が並んでいます。
パソコン2台とタブレット1台に画面4つですから、以前（会社にいた頃:Windows環境）であればそれぞれにキーボードとマウスを設置して体の向きを替えながら連携アプリの開発等をやっていましたが、それがMac環境で構築すると、この全てを1セットのキーボードとマウスで操作できました。（ユニバーサルコントロール機能は数年前から可能になってます）
今回、ここであらためてApple製品の作りの良さを感じる結果となりました。
最新の開発環境で手になれたエディタを使ってソフト作成をする、マウスを探したりキーボードを切り替えたりもしない、とても快適な環境です。今はこの環境のままでXcodeを立ち上げ、Swiftの学習を始めています。Swiftは数年前からやろうとしてて、なかなかチャレンジできずにいたものでした。まずは一つアプリを作りたいです。。
ソフトでもハードでも、とにかくモノを作ることが好きな自分にはMacが合ってます。
pd.append が使えなくなるのでその対策 ― 2023-01-31
これまでの自分のアプリを実行すると以下のワーニングがたくさん出て、いずれpd.appendは使えなくなるからそのかわりにpd.concatを使えとのこと。
FutureWarning: The frame.append method is deprecated and will be removed from pandas in a future version. Use pandas.concat instead.
私のソフトでは横に大きな(41カラム)データフレームに対して、数項目しかデータを持たな行を追加する際 pd.Serial を作ってそのカラム名をインデックスとして pd.append で行に足し込んでいた。
これと同じことが pd.concat でできるのか調べてみたらできて、案外簡単に実装できた。
訂正前
①s = pd.Series([curmon,'GAS',c[5],c[1]+'('+c[0]+')'], index=['日付','区分','出金','摘要'] , name= Cindex)
②df = df.append(s)
訂正後
① s = pd.DataFrame(data=[[curmon,'GAS',c[5],c[1]+'('+c[0]+')']], columns=['日付','区分','出金','摘要'])
②df = pd.concat([df,s],ignore_index = True, axis =0)
要は、データをシリアル化してやり、それぞれのデータをどの列に入れるかをcolumnsで指定してデータフレーム化してやると問題なく行追加できる。問題はこの訂正場所がソフト中に８箇所もあるという点。でも emacs だとそれが俊速でできてしまうという追加のお話。
まず①行目
最初に検索バッファにpd.Seriesをセットしておいて、
C-s <ret><ret> M-b M-d DataFrame C-f [ C-M-n ] C-f C-f M-d columns C-e M-b M-b M-d M-d <bs>
これで１行分完了、これを必要数繰り返すだけ。
やっていることは、検索移動とワード単位の削除や対応括弧への移動とを組み合わせてをやっているだけだけど、こうやって文字で書くと長いけど、キーは単語打ち込み以外は１０回程度なので大したことない。
２行目は固定処理なのでそのまま行を入れ替えれば終わり。
やっぱ emacs はええなぁ、使えば使うほど指に馴染む。先達に感謝。
最近のコメント