« 2024年7月 | トップページ | 2024年10月 »

2024年9月

2024年9月27日 (金)

SSDACをパソコン上のPythonで実装する ②

【今回の結論】
・WAVファイル再生時の前処理として、スーパーサンプリングを応用したアップサンプリング処理をしておけば、通常のオーバーサンプリングDACによる再生においても、プリエコー、ポストエコーによる音質への悪影響をSSDACと同程度に軽減できる。


前回の記事では、Windows上でPythonを使ってSSDACを実装し、補間の様子をグラフで確認しました。
今回はPythonで実装したSSDACで、実際のWAVファイルを処理して、結果を同じくWAVファイルで取り出し、効果を確認、検証します。

なお今回も前回に引き続き、PythonによるSSDACの実装コードを公開します。今回は任意WAVファイルに対して、任意のスーパーサンプリング倍率処理を施したWAVファイルを出力するもので、名称はSSSRC(スーパーサンプリング・サンプリングレートコンバータ)です。

SSDAC(スーパーサンプリングD/Aコンバータ)の目的は何かというと、過渡的な信号を再生する際に、従来から行われているオーバーサンプリングで原理的に発生するプリエコー、ポストエコーというノイズを抑えることです。

図1に、一般的なDACデバイスを使用して過渡的な信号を再生した場合の典型的なプリエコー、ポストエコー発生の様子を、図2にSSDACを使用してプリエコー、ポストエコーが抑えられた波形を示します。

Ess_20240926181001
図1.ESS9018K2Mによるポストエコー、プリエコー


Tek0053_20240926181001
図2.スプライン関数補間により、プリエコー、ポストエコーが抑えられる


図1に示すように、従来のオーバーサンプリングデバイスではプリエコー、ポストエコーが発生し、その周波数はサンプリング周波数の半分です。たとえばCD音源の場合はサンプリング周波数が44.1kHzなので、プリエコー、ポストエコーの周波数は22.05kHzです。ヒトの可聴周波数帯域は20kHz上限といわれていますから、22.05kHzのノイズが直接聞こえることはないと思われますが、CDには20kHzまでの信号が記録されていて、たとえば記録上限の20kHzの音が再生されたとき、これが22.05kHzのプリエコー、ポストエコーと干渉して、その差分すなわち2.05kHzのビートが発生する可能性があります。このようにプリエコー、ポストエコーが発生すると、音源に含まれるすべての周波数帯域との間でビートが発生することになり、これが聴感に影響を与えます。
このようなことが起こらないように、プリエコー、ポストエコーの発生を抑えつつデータ補間を行う事を目的に考案されたのがSSDACで、同じ過渡的な信号をSSDACで再生すると、図2に示すようにプリエコー、ポストエコーが抑えられます。

ところで、上に述べたプリエコー、ポストエコーは、22.05kHzという、再生周波数上限の20kHzに近い周波数で発生することによって聴感に悪影響を与えますが、プリエコー、ポストエコーの周波数が十分高ければ、具体的にはたとえば44.1kHz、あるいはそれよりも高い周波数であれば、もし発生しても聴感上の影響はかなり小さくなるだろうと思われます。それはつまり、音源のサンプリング周波数が88.2kHzまたは96kHz以上であれば、プリエコー、ポストエコーの周波数は44.1kHzまたは48kHz以上となり、聴感への悪影響は些少であるということです。

そうすると、44.1kHzサンプリングのCD音源信号を、88.2kHzサンプリングに変換してから通常のDACで再生すれば、プリエコー、ポストエコーの影響は無視できるのではないかと考えられます。
それならばSRC(サンプリングレートコンバータ)であらかじめサンプリングレートを88.2kHzに変換しておけばよいのではないかということになりますが、これでは意味がないのです。なぜなら、SRCの原理はオーバーサンプリングと同じで、インターポーレーション後にFIRフィルタ処理を行うため、SRCの行程でプリエコー、ポストエコーが付加されてしまうからです。

そこで、2倍のスーパーサンプリング、つまりスプライン関数でデータ間1点の補間を行えば、プリエコー、ポストエコーの発生を抑えた2倍アップサンプリングが可能で、この2倍アップサンプリングデータを通常のDACで再生すれば、プリエコー、ポストエコーの影響が些少な再生が可能であると考えられます。

以上のような考察に基づいて、以下の検証を行います。

【使用音源】
a. 1kHz方形波をCDフォーマット(44.1kHz16bit)で録音したWAVファイル→元音源
b. 元音源を2倍スーパーサンプリングによってアップサンプリングしたもの→2XSS音源(88.2kHz32bit)

【評価内容】
①元音源をソフトウェア(TASCAM Hi-Res Editor)によって352.8kHz32bitにアップサンプリング
②2XSS音源をソフトウェア(TASCAM Hi-Res Editor)によって352.8kHz32bitにアップサンプリング
③上記①、②の再生波形において、プリエコー、ポストエコーの発生を比較

【評価結果】
まずは図3に元音源(1kHz方形波44.1kHz16bit sampling)の波形を示します。
ここでは補間の様子がわかりやすいように、すべての波形はデータの散布図として表示します。波形の表示にはaudacity2.4.2を使用しました。

Sq1k_org
図3.元波形(1kHz方形波 44.1kHz16bit)

この元波形を、TASCAM Hi-Res Editorを使用して352.8kHz32bitにアップサンプリングしたものを図4に示します。

Sq1k_352
図4.352.8kHz32bitにアップサンプリング


図4では、プリエコーポストエコーが発生しているのがわかります。これは一般的なDACデバイスによってオーバーサンプリング再生を行った場合と等価な結果です。


次に、元波形に対して今回作成したpythonによるSSSRCを使って2倍のアップサンプリングをした波形を図5に示します。

Sq1k_ss2x
図5.SSSRCによる2倍アップサンプリング波形

スーパーサンプリングによる補間によって、立ち上がり前後でオーバーシュートが発生する典型的な波形になっています。これは図2で示したSSDACによる波形と等価です。
これは元の波形のフォーマットを44.1kHz16bitから88.2kHz32bitにアップサンプリングしたものであると考えることができます。

次にここで得られた88.2kHz32bitサンプリングの信号を、TASCAM Hi-Res Editorを使って352.8kHz32bitサンプリングにアップサンプリングした波形を図6に示します。

Sq1k_ss2x_352
図6.SSSRCで2倍アップサンプリングしたものを、352.8kHzにアップサンプリングしたもの

これは興味深い結果で、44.1kHzのプリエコー、ポストエコーが新たに付加されることを予想していましたが、予想に反して新たなプリエコー、ポストエコーは付加されず、SSSRCによる2倍アップサンプリングの波形(エンベロープ)がそのまま出てきました。

つまり、SSSRCで前処理として2倍アップサンプリングしておくことによって、一般的なオーバーサンプリングDACデバイスにる再生においてSSDACと等価な結果が得られるのではないか?ということです。

もちろん前処理は2倍に限らず任意のアップサンプリング倍率を選ぶことができますが、ソフトによる処理では倍率が高くなるほど処理時間が増加し、生成されるファイルが大きくなります。
今回のSSSRCでは、5秒のWAVファイルを2倍アップサンプリングするのに1分40秒かかりました(^-^;


【SSSRC(スーパーサンプリング・サンプリングレートコンバータ)ソースコード】
今回もPythonによりコードを作成したので公開します。
コードの内容は前回発表したSSDACの実装とほとんど同じで、今回は補間してできあがったデータをWAVファイルとして出力する部分を追加しました。

ダウンロード - 20240924python_ssdac101.py

興味のある方はダウンロードしてご覧ください。
以下は要点です。

19行目
data_dir = 'C:\\Local_Files\\Python'
これは加工する元WAVファイルの格納ディレクトリです。

20行目
fname = '1k_1s.wav'
加工するターゲットファイルです。

26行目
ss_ratio=2 #スーパーサンプリング比
スーパーサンプリング倍率を設定します。2^nの数値を設定します。上限はありませんが、大きくするほど仕上がりのファイル容量は大きくなります。

75行目
wavfile.write(fileName, samplerate*ss_ratio, (y_all*47662).astype(np.int32))
演算したデータをWAVファイルに書き込みます。ファイル名は演算開始時刻にしており、できあがったWAVファイルの生成時刻との比較により演算に要した時間がわかります。
y_allは16bitフルスケールの整数からfloatで計算しているため、これを32bit整数に拡張してファイル出力します。スーパーサンプリングによる補間によって、信号ピークは最大1.375倍になるので、65536/1.375=47662を乗じて、フルスケールになるように調整します。

78行以降
グラフ表示部分をコメントアウトしています。

※できあがりのWAVファイルは、このソースファイルと同じディレクトリに生成されます。


【今後の予定】
今回のPC上のPythonによる実装では、多大な処理時間がかかり実用的ではないため、C#などのコンパイラによる実装で処理時間を短縮し、より実用的なものにしたいと思います。


そういうわけで、ソフト処理によってより簡単にSSDACの効果を体感できるということがわかりましたので、より多くの方々にSSDACの音を楽しんでいただきたいと思います(^-^)

【おまけ】
今回公開したPythonのファイルはWindowsパソコン上で実行できます。
もっとも簡単な方法は、Anaconda3をインストールして、同梱のSpyderを起動、pyファイルを読み込んで実行ボタンを押せば実行できます。
Anaconda3はこちらからメールアドレスを入力すればダウンロードできます。
実行結果にグラフが含まれる場合は、Spyderの右上窓のPlotsタブに表示されます。
コマンドラインでのPython実行は右下窓で実行できます。
Pythonが初めての方もぜひ遊び感覚でいじってみてくださいね(^-^)

関連記事
SSSRC( スーパーサンプリング・サンプリングレートコンバータ ) ソフトウェア公開



| | | コメント (0)

2024年9月20日 (金)

格安タブレット TECLAST P85T の不具合と対処方法

20240920p85t

Amazonで格安タブレット TECLAST P85Tが9500円ほどで売られていたので購入した。
ところが使ってみると、スクショが撮れないという不具合が発覚し、返品、買い直しなどを経て、最終的にはファームウェアアップデートによって解決したが、最初の購入から問題解決まで1ヶ月以上を要してしまった。その顛末を書いておく。

そもそもスマホは使わない主義なので、携帯電話は二つ折りのガラケー(正確にはガラホ)を使っていて、ネット閲覧やメール用にタブレットを持ち歩いている。それはなぜかというと、スマホの小さな画面を見るのはつらいし操作がしにくいということ、それと電話とネットが一緒になっているスマホの通信料金体系がわかりにくく、割高になるような感じがするからだ(もしかしたら最近は格安SIMなどでかなり安いのかもしれないが)。

ぼくにとってタブレットは2年から3年で買い換える消耗品の扱いなので、だいたい1万円~1万3千円程度までのものを買うようにしている。ストレスなくメールができてネットブラウジングができるだけでいいので、それほど高性能なものは必要がないのだ。
タブレットのいちばん大きな問題は、だいたい3年もすれば電池が寿命になることで、多くのタブレットはユーザーが自分で電池交換できるように作られていないので、ここでタブレットを買い換えるか電池交換に出すか、ということになる。電池交換は、交換業者に出すか、メーカーに出すかということになるのだが、電池交換費用は安い業者で最低1万円、国内メーカーに出すと2万~3万円かかる。
またタブレットは持ち歩くので、落として壊してしまうこともある。
そう考えると、平均して2~3年しか使えない消耗品にいくら出せるか?ということになり、ぼくとしては1万円台前半のタブレットを使い捨てるのが妥当だと考えている。

そんなわけで、2024年7月に、それまで使っていたタブレットが壊れてしまい、タッチスクリーンの左側が反応しなくなってしまったので、買い換えを検討したところ、AmazonのタイムセールでTECLASTのP85Tという機種が9500円程度で売られていて、値段的にもスペック的にもよさそうだったので購入した。ケースは金属でできていて塗装もきれいで高級感があり、満足して使っていたが、使い始めて間もなく不具合を発見した。システム機能のスクリーンショットが使えないのだ。

スクリーンショットのボタンをタッチすると、「システムUIが繰り返し停止しています」というエラーが出て、スクショが撮れないばかりか、勝手に再起動してしまう場合すらある。

TECLASTのホームページからサポートにこの問題を報告したところ、ファームウェアのアップデートをするように、という内容の返信が来たので、ファームウェアのダウンロードサイトを見に行ったが、該当製品ID”P3M5”のファームウェアが上がっておらず、そのように指摘すると、何日かしてファームウェアがアップされていた。このときのファームウェアバージョンはROW_V1.01_20240618というもので、これでやっと解決する!!と嬉々としてダウンロードしてアップデートしたが、問題は解決しなかった。バージョンをよくよく見ると、もともと入っていたファームウェアバージョンと同じであった。そこでまたサポートに報告すると、返金に応じるので返品してくれということだった。

この機種はスクショの問題以外は文句はなく、気に入って使っていたし、同じ価格帯の機種がなさそうだったので、できれば直して使いたかったのだが、ひょっとしたら個体の不具合なのかもしれないと淡い期待を抱いて返品し、返金されたので再度同じものを購入したが、まったく同じ不具合が出た。そこでまたサポートに不具合報告と、改善の予定があるのか問い合わせてみたが、返品してくれの一点張で、らちがあかないので、そのうちファームウェアでの改善があるであろう事を期待して、しばらく使っていた。

それから2週間ほど経ったある日、ファームウェアのダウンロードサイトをのぞいたら、新しいファームウェアがアップされていた。バージョンはROW_V1.02_20240724。今度こそ!!と期待を込めてアップデートしてみたら、スクショが撮れるようになった\(^o^)/

そんなわけで、無事にまともに使えるようになったのだった。
ところで、ファームウェアのダウンロードサイトには
ROW_V_x.xx
EEA_V_x.xx
という2種類のファームウェアがアップされていて、何がちがうのかと思ったら、EEAは欧州向けで、ROWがグローバル版らしいのだが、違いはよくわからない。もともとROWが入っていたので、アップデートもROWにした。

ファームウェアアップデートの具体的な方法は、サイトの説明を参照してほしいが、ひとつだけ注意してほしいことは、アップグレードチュートリアルの説明では、ファームウェア書き込み時に”Wipe part”を選択するように書かれており、この通りにやると、すべてのインストールアプリとデータが削除されてしまう。アプリとデータを残してファームウェアだけアップデートするには”Wipe part”ではなく”Keep data”を選ばなければいけないので要注意だ。

今回問題となったスクリーンショットの機能は、おそらく使う人があまり多くはないため見落とされていたのだろうと思うが、ぼくは詰め将棋のアプリで難しい問題があったときにスクショを取っておくようにしていることから、今回の問題に気が付いた。

問題が解決した今はお気に入りのタブレットになりました。ブルーの筐体を選んだので、カバーをピンクにしたら、映えてなかなかよい感じです(^-^)


| | | コメント (0)

2024年9月 6日 (金)

EOS MとAi Nikkor 50mm f1.8

 2012年に購入したEOS Mを久しぶりに引っぱり出して、さらに30年近く前に買ったAi Nikkor 50mm f1.8を装着して、散歩がてら街の写真を撮ってきた。
ネットで誰か(おそらくプロの写真家の方)が、今のデジカメに昔のレンズを付けて撮るのがなかなか良いとつぶやいていらしたので、なるほどと思い真似してみたのだ。

なぜEOSにNikkorなのかというと、もともとフィルム時代はNikon F3ユーザーで、レンズも数本もっていたのだが、懸賞でEOS M用のタムロンズームレンズが当選したので、そのレンズ用にEOS Mを買ったというのが事の経緯だ。とはいえ、サブ機として頂き物のCANONのAE-1と数本のレンズももっていて、どちらかといえばAE-1に使っていたレンズをEOSにつける方が筋が通っているように思うが、F3用の50-200mmのズームをもっていて、これとテレコンとEOS Mで月の写真を撮ってみたいと思い、EFレンズとAi Nikkorのアダプタを買ってもっていたからだ。

そういうわけで、EOS MにNikkorを装着するとこんな感じになる。

Eosnikkor
写真1.Ai Nikkor 50mm f1.8を装着したEOS M

この通り、レンズの存在感がすごい(^-^;
EOS Mがとてもコンパクトなのが際立つ。

出かける前に、部屋の中やベランダでテスト撮影してみた。

Bungu
写真2.ペン立て

Kitchen
写真3.キッチン

Asagao
写真4.あさがお

まったくなんでもないペン立てやキッチンも、良い機材で撮るとなんだかドラマチックな感じがする(^-^)

35mmカメラでの50mmレンズは、APS-CサイズのEOS Mでは1.5倍の75mm相当になるので、ふだん広角のコンデジに慣れているとずいぶん望遠気味な印象になる。ズームで調整はできないので、足で距離を調整するしかない。

どうやら写真はちゃんと撮れるようなので、街に出てみた。


Sarusuberi1
写真5.日影の百日紅


Kinomi
写真6.ヤブカラシ


Hibiscus
写真7.ハイビスカス


これらは近所の図書館までの道で見た光景だ。オートフォーカスが使えないのでマニュアルでピント合わせをするのだが、外の明るさでカメラの液晶を見てピントを合わせるのはなかなか難しい。老眼なのでなおさらだ(^-^;
全体的にピントが甘めになってしまった……
でも、ピントを合わせて、バシャン!!とシャッターを切ると、そうそう!こういう感じだった!!という思いがよみがえる(^-^)


Library
写真8.図書館の建物


Komorebi
写真9.木漏れ日


Hibiscus2
写真10.ハイビスカス2


そういうわけで、図書館まで散歩して写真を撮って帰ってきた。
機材が良いとずいぶんドラマチックに撮れるものだ。

でも実際に目で見る光景こそがドラマそのものである、というのが真実なので、
見慣れた光景にも注意を向けて、いつも何かを感じ取れるように過ごしていけたらいいなあ、と思います。


| | | コメント (0)

2024年9月 5日 (木)

aliexpressで購入したCP2112欠陥基板

SiliconLabsのCP2112というデバイスがある。これを使うとマイコンの介在なしに、パソコンのUSBポートから、C#などのコードを使って直接I2CデバイスやGPIOの制御ができる。このデバイスとUSBコネクタとピンヘッダが搭載された基板が販売されている。

サンハヤト

Amazon

AliExpress

この中でサンハヤト製がいちばん信頼が置けそうだが少しお高めだ。アマゾンで売っているものはサンハヤトの半額以下で、お試しに購入するにはよさそうだが、アリエクではさらにその半額に近い値段で、しかもUSB-Cのものがあるので、アリエクのUSB-Cのものを3つ購入した。

テスト用のアプリは、本家SiliconLabsのサイトから、
Legacy: CP2112 Software Development Kit for Windows XP and Vista
をダウンロードして使う。XP and Vistaと書いてあるが、windows11でも使えるようだ。
また、上のサンハヤトのサイトからは、C#で書かれたサンプルプログラムが入手可能だ。

さっそくSiliconLabsのテストアプリをつかって、とりあえずGPIOのON/OFF動作を見てみたが、どうも様子がおかしい。
動いているようではあるのだが、ハイレベルが2Vちょっと、ローレベルがマイナスになったりしていて、しかもすごいノイズが乗る。
電源のラインをみると、これも2Vくらいしかなく、どうも様子がおかしいので、回路を追ってみたところ、なんとGNDパターンがGNDにつながっていない(^-^;
写真1のように、GNDをジャンパ線で接続したら正常に動作するようになった。写真2は基板裏面の様子。

Cp2112_a
写真1.GNDジャンパ接続の様子

Cp2112_b
写真2.基板裏面

このデバイスは、I2CのほかにGPIOが8本使えるが、この基板のシルクを見るとGPIOはIO5~IO7の3本しか出ていないように見える。
回路を追ってみると、IO0とIO1は基板上のLEDに接続されていて、外部には引き出されていない。IO0とIO1はそれぞれTxToggleとRxToggleという機能が使えるようになっており、これは通信時のデータアクセスランプとして使う機能のようだ。IO2~IO4はどうなっているかというと、それぞれMAK、INT、RSTのシルクの端子に接続されていた。つまりIO2~IO7は外部に引き出して使うことができる。デバイスのRST端子は4.7kでプルアップされていて、外部には出されていない。

そういうわけで、どうやら無事に使えるらしいことがわかった。
アリエクはまあ、こういうことが時々あって、やれやれ、という感じだ……(^-^;

| | | コメント (0)

« 2024年7月 | トップページ | 2024年10月 »