重複している項目(複数登場する項目)を見つけ出す簡単な方法

最近ふと思いついた事ですがプログラマーなどでは常識な重複項目を見つけ出す方法についてです。

（重複排除のアルゴリズム）

非常に短い説明文で済みますのでお付き合いください。

・まずは重複があるかどうかを調べる一覧をソート(大きい順、小さい順どちらでもOKで並べ替えます)します。

 Excelなどでしたらソートは簡単だと思います。

 連絡先などでしたらメールアドレスや電話番号の並び順でソートするといいかもいいかもしれません。

・この状態で重複している項目がある場合は隣同士に並んでいることになりますので同じ物が並んでいないか先頭から順に調べます

・もし隣同士に並んでいる重複項目を見つけたら要らない方を削除したり1つの項目にまとめたりします。

とこんな感じです。

重複して並んでいる項目の数を数えればそれぞれの項目ごとの出現回数を数える事などにも使えます。

応用編としてはこれで重複してほしくない住所録一覧を作った時にソートする項目の選択で「電話番号」などを使ってみた場合に、例として一世帯の家族がみんな固定電話で登録されているような場合は同じ「電話番号」が重複して見つかりますのでこのような場合は「電話番号」だけでの個人の特定はふさわしくないと確認できたりします。

同じように上記の住所録での「電話番号」＋「生年月日」で個人の特定はどうでしょう？

このような場合でももし同一家族に双子の方がいらっしゃったら「電話番号」＋「生年月日」も同じになりますので＋で「氏名」も入れておいたほうがいいかもしれません。

重複項目の検出方法はソートさえできれば見つけ出す原理は簡単ですので日常生活にお役立てください。

インテルN-100のミニPCはメモリ搭載最大容量が16GBまで？32GBまで？

インテルN-100のミニPCはメモリ搭載最大容量が16GBまでと言われていましたが最近の記事を見ると32GBまで認識すると言われています。

そこで以前インテルN-100のミニPCを購入した記事を書きましたがその際に使ったアマゾンで買った「TRIGKEYのGreen G5」ミニPCに32GBのメモリを装着してWindows11で認識されるか実験をしてみました。

装着の実験で利用したメモリは32GBのSO-DIMMで13980円のです「プリンストン ノートPC用 メモリ Micron純正 32GB DDR5 4800(PC5-38400) SODIMM CL40 262pin 1.1V HBN4800-32G」

バルク品ですがcrucialの物より安く購入できたのでこちらにしました。

DDR4のSO-DIMM品だとさらに安く購入できますが流用があった時のためにとりあえずDDR5-4800の物にしておきました。

「TRIGKEYのGreen G5」ミニPCの底蓋のネジを外しSSDベイ兼用の底蓋を外してSO-DIMMのメモリモジュールを交換して電源ON。

Windows11が起動したので「設定」→「システム」→「バージョン情報」を見てみるとメモリ搭載量は32GBで認識されています。

また「タスクマネージャー」を開いてみてもメモリの搭載量が32GBになっていました。

これはいいですね、仮想メモリサイズは0KBで利用しているのでメモリ16GBだと多少窮屈なのですが32GBあれば大抵の利用状況でも余裕が出てきます。

インテルN-100のミニPCを購入する場合は通常メモリを32GBで購入できませんのでその場合は8GBモデルを選択して32GBの物に交換すると安く上がりますね。

USB Type-Cハブ(USB PD)で充電器容量によってバスパワーが給電される条件

PCに「USB Type-Cハブ」を接続して「USB Type-Cハブ」の「USB PDポート」(USB Type-Cの充電器を接続する)からハブのポートにバスパワーで給電させようとした時のすったもんだした時の記事です。

PCでUSBポートから結構大きめの電力を使うUSB外付けのNVMeなSSDケースを使う際に電力不足でうまく認識されない場合があったので「USB PDポート」(Type-Cの充電ポート)を使ってハブから給電したUSBポートに接続して安定して認識させて使おうとしたことが発端です。

ここで使用した「USB Type-Cハブ」はUGREENのハブでアマゾンでクーポン価格で7000円程度の物でした。

このハブのUSB PDの給電の仕様はハブへの入力が100WでPCへの給電は85Wという仕様です。

手持ちのUSB PD充電器は65Wの物と100Wの物を用意しています。

結論を先に書きますがこの「USB Type-Cハブ」は「入力が100W」(20V5A)できないとハブのためのバスパワー15W分を使わないような設計になっていました。たとえPCへの給電をしなくとも65Wの充電器ではハブのためのバスパワーは使わないようです。

まずは電力不足になるUSBのSSDケースをPCの各種USBポートに直接接続してみて電力不足になるポートと電力が間に合うポートに切り分けてみます。

電力不足になるUSBのSSDケースを「USB Type-A」ポートに接続してみると微妙に電力不足になるようで認識されなかったりUSB2.0規格の速度で接続されたりします。

電力不足になるUSBのSSDケースを「USB Type-Cハブ」無しで直接「USB Type-C」ポートに接続すると電力は間に合うようで無事に認識され、「USB3.1Gen2」のフルスピードで接続できました。

次に「USB Type-C」ポートは比較的給電能力が高いようなので「USB Type-C」ポートに「USB Type-Cハブ」(USB PDでの給電無しセルフパワー)を接続して「USB Type-Cハブ」のUSBポートに電力不足になるUSBのSSDケースを接続してみますが電力不足で認識されません。

電力不足になる推測ですが「USB Type-Cハブ」には「1GBpsのEthernetポート」と「SDカードリーダー」も付いているのでハブ機能以外にもある程度電力を使ってしまうための様です。

次に「USB Type-Cハブ」の「USB PDポート」に「USB PD 65W充電器」を接続しての実験です。「USB Type-Cハブ」のUSBポートに電力不足になるUSBのSSDケースを接続してみますがまた電力不足で認識されません。

ちゃんとUSB PDで給電されているか確かめるために試しにPCへ給電してみますが確かにPCへの電力供給はされています。（PCは65Wの充電器で動作可能な機種）

次に「USB Type-Cハブ」の「USB PDポート」に「USB PD 100W充電器」を接続しての実験です。「USB Type-Cハブ」のUSBポートに電力不足になるUSBのSSDケースを接続してみた所無事に電力が足りたようで認識されましたし「USB3.1Gen1」の規格の毎秒400MB/秒程度の速度で接続されました。

というわけで他の「USB Type-Cハブ」でも大体は同じような動作をすると思いますのでハブの入力が100Wと記述されていたら100W以上の充電器とケーブルを用意するのが正解の様です。

あーアマゾンのセールの期間内の前に判明していればよかったですね。残念。

新しいRTL-SDR Blog V4と従来のRTL-SDRを比較してみました（消費電力編を追加）

新しい「RTL-SDR Blog V4」でAM放送や短波帯の受信をしてみての従来の「RTL-SDR Blog V3」と「Nooelec RTL-SDR v5」との比較です。

受信感度は大体「RTL-SDR Blog V3」＜「Nooelec RTL-SDR v5」＜「RTL-SDR Blog V4」

となるようで、「RTL-SDR Blog V4」だと選択した周波数の受信周波数帯域外からの混信が非常に少ないのでありがたいと言う点が特徴でした。

今回はHF帯受信での消費電力比較についてです。

大体の傾向は「消費電力＝発熱」という事なのですが「RTL-SDR Blog V4」は低消費電力設計と言う割にはHF帯受信時に「RTL-SDR Blog V3」と「Nooelec RTL-SDR v5」の「ダイレクトサンプリングモード」動作と比較して発熱が多かったので変だなぁと思い消費電力を計測してみました。

AM放送や短波帯の受信での発熱の消費電力の感覚では

「RTL-SDR Blog V3」より多少発熱が多いのが「Nooelec RTL-SDR v5」で

「RTL-SDR Blog V4」は「Nooelec RTL-SDR v5」と比較してもかなりホカホカします。

「RTL-SDR Blog V4」は「ダイレクトサンプリングモード」動作がサポートされていないので「Quadratureサンプリングモード」での計測のみです。

また「Quadratureサンプリングモード」での実用的な受信動作は24MHz以上なので短波帯域での計測は行っていません。

「RTL-SDR Blog V3」と「Nooelec RTL-SDR v5」の「ダイレクトサンプリングモード」の消費電力の計測は以前にも行ったのですが以前の時とはUSBテスターが異なるのと「Quadratureサンプリングモード」での計測もあるので計測しなおしました。

「RTL-SDR Blog V4」は受信周波数の「アップコンバーター」が追加されていて「0-24MHz」の帯域は自動的に「アップコンバーター」動作での受信に切り替わるという事なので受信周波数は「ダイレクトサンプリングモード」での比較用に「9MHz」と「Quadratureサンプリングモード」での消費電力参考の比較用に「100MHz」を受信しています。

----- ここから消費電流の一覧 -----

RTL-SDR Blog V3 の消費電流(ダイレクトサンプリングモード「9MHz受信」)
0.045A-差し込んでから「bias_tee_off.bat」を実行「4.626V」
0.090A-rtl_tcp-起動初期アイドリング状態で利用中「4.556V」
0.081A-rtl_tcp-サンプリングレート0.25Mで利用中「4.574V」
0.083A-rtl_tcp-サンプリングレート0.900001Mで利用中「4.565V」
0.083A-rtl_tcp-サンプリングレート1.024Mで利用中「4.565V」
0.085A-rtl_tcp-サンプリングレート1.4Mで利用中「4.565V」
0.087A-rtl_tcp-サンプリングレート1.8Mで利用中「4.565V」
0.087A-rtl_tcp-サンプリングレート1.92Mで利用中「4.556V」
0.089A-rtl_tcp-サンプリングレート2.048Mで利用中「4.556V」
0.089A-rtl_tcp-サンプリングレート2.4Mで利用中「4.556V」
0.089A-rtl_tcp-サンプリングレート2.8Mで利用中「4.556V」
0.089A-rtl_tcp-サンプリングレート3.2Mで利用中「4.556V」

(参考)RTL-SDR Blog V3 の消費電流(Quadratureサンプリングモード「100MHz受信」)
0.255A-rtl_tcp-サンプリングレート2.048Mで利用中「4.310V」


Nooelec RTL-SDR v5 の消費電流(ダイレクトサンプリングモード「9MHz受信」)
0.056A-差し込んでから「bias_tee_off.bat」を実行「4.609V」
0.123A-rtl_tcp-起動初期アイドリング状態で利用中「4.512V」
0.107A-rtl_tcp-サンプリングレート0.25Mで利用中「4.530V」
0.111A-rtl_tcp-サンプリングレート0.900001Mで利用中「4.521V」
0.113A-rtl_tcp-サンプリングレート1.024Mで利用中「4.521V」
0.115A-rtl_tcp-サンプリングレート1.4Mで利用中「4.521V」
0.115A-rtl_tcp-サンプリングレート1.8Mで利用中「4.521V」
0.117A-rtl_tcp-サンプリングレート1.92Mで利用中「4.512V」
0.117A-rtl_tcp-サンプリングレート2.048Mで利用中「4.512V」
0.119A-rtl_tcp-サンプリングレート2.4Mで利用中「4.512V」
0.119A-rtl_tcp-サンプリングレート2.8Mで利用中「4.512V」
0.119A-rtl_tcp-サンプリングレート3.2Mで利用中「4.512V」

(参考)Nooelec RTL-SDR v5 の消費電流(Quadratureサンプリングモード「100MHz受信」)
0.282A-rtl_tcp-サンプリングレート2.048Mで利用中「4.284V」


RTL-SDR Blog V4 の消費電流(Quadratureサンプリングモード「9MHz受信」)
0.054A-差し込んでから「bias_tee_off.bat」を実行「4.618V」
0.255A-rtl_tcp-起動初期アイドリング状態で利用中「4.319V」
0.246A-rtl_tcp-サンプリングレート0.25Mで利用中「4.328V」
0.250A-rtl_tcp-サンプリングレート0.900001Mで利用中「4.328V」
0.251A-rtl_tcp-サンプリングレート1.024Mで利用中「4.319V」
0.251A-rtl_tcp-サンプリングレート1.4Mで利用中「4.319V」
0.255A-rtl_tcp-サンプリングレート1.8Mで利用中「4.319V」
0.255A-rtl_tcp-サンプリングレート1.92Mで利用中「4.319V」
0.255A-rtl_tcp-サンプリングレート2.048Mで利用中「4.319V」
0.257A-rtl_tcp-サンプリングレート2.4Mで利用中「4.310V」
0.257A-rtl_tcp-サンプリングレート2.8Mで利用中「4.310V」
0.257A-rtl_tcp-サンプリングレート3.2Mで利用中「4.310V」

(参考)RTL-SDR Blog V4 の消費電流(Quadratureサンプリングモード「100MHz受信」)
0.248A-rtl_tcp-サンプリングレート2.048Mで利用中「4.328V」

----- ここまで消費電流の一覧 -----

以上の計測結果から分かった点を以下に挙げます。

以下サンプリングレート2.048M時の有効な受信周波数時の消費電力

「RTL-SDR Blog V3」「9MHz受信」「ダイレクトサンプリングモード」0.089A

「RTL-SDR Blog V3」「100MHz受信」「Quadratureサンプリングモード」0.255A

「Nooelec RTL-SDR v5」「9MHz受信」「ダイレクトサンプリングモード」0.117A

「Nooelec RTL-SDR v5」「100MHz受信」「Quadratureサンプリングモード」0.282A

「RTL-SDR Blog V4」「9MHz受信※1」「Quadratureサンプリングモード」0.255A

「RTL-SDR Blog V4」「100MHz受信」「Quadratureサンプリングモード」0.248A

※1：9MHz受信をしているのは受信周波数の「アップコンバーター」で内部での実際の「Quadratureサンプリングモード」での受信周波数は24MHz以上の有効な受信周波数に自動調整されている。「100MHz受信」時よりも「アップコンバーター」動作のためわずかに消費電力が多いと推測。

・HF帯受信時に「RTL-SDR Blog V3」と「Nooelec RTL-SDR v5」の「ダイレクトサンプリングモード」は発熱がかなり小さい

「ダイレクトサンプリングモード」（HF帯受信時）の消費電力は「Quadratureサンプリングモード」（24MHz以上）に比べて半分以下で発熱もかなり小さい。

「RTL-SDR Blog V3」と「Nooelec RTL-SDR v5」はHF帯受信時に「ダイレクトサンプリングモード」で動作させると発熱が非常に少なくて済むが「RTL-SDR Blog V4」は「Quadratureサンプリングモード」での動作のため発熱量は倍以上ある。

この消費電力の差が発熱の原因だが機構上仕方がない。

・「RTL-SDR Blog V4」での「0-24MHz」HF帯受信時の「アップコンバーター」動作の消費電力増は微々たる程度で済んでいる

「RTL-SDR Blog V4」でのHF帯受信時の「アップコンバーター」動作で増加している消費電流の差は0.007A程度の差(5V換算で35ミリワット程度)で発熱の程度はほとんど変わらない程度のよう。

・「RTL-SDR Blog V3」と「RTL-SDR Blog V4」での「Quadratureサンプリングモード」動作は微妙に「RTL-SDR Blog V4」の方が消費電力が少ない

「RTL-SDR Blog V3」と「RTL-SDR Blog V4」での「Quadratureサンプリングモード」の「100MHz受信時」の消費電力の差は「RTL-SDR Blog V4」の方が微妙に少なくなっているが微妙なので劇的に減少しているという訳ではないよう。

結果としては「RTL-SDR Blog V4」でHF帯の受信時は消費電力が大きい「Quadratureサンプリングモード」の発熱になるので仕方ないがヒートシンクを付けての運用が良さそうと思います。

RTL-SDRドングルで新しいRTL-SDR Blog V4を試してみました

2023年の夏ごろからリリースされた新しいRTL-SDRドングルの「RTL-SDR Blog V4」を試してみました。

●ここに「RTL-SDR Blog V4」ドングルの仕様などが書いてある「RTL-SDRブログV4ドングル初期リリース!」

以下は上記サイト内の「RTL-SDR Blog V4」の新しいハードウェア機能の概要

・ダイレクトサンプリングモード(500KHz-28MHz)の廃止と(500KHz-28MHz)周波数の受信用に自動切換えされる内蔵アップコンバーターを新規に装備した

今までダイレクトサンプリングモードで受信していた周波数の(500KHz-28MHz)はQuadratureサンプリングモードで受信することになり、(500KHz-28MHz)の周波数選択時は新しいドライバー利用により自動的に内蔵アップコンバーターに切り替わって受信されるようになった。

Quadratureサンプリングモードでアップコンバーターの出力を受信することになったため、HF帯(0-28MHz)受信時のゲイン調整ができるようになった。（チューナーAGCを使うとゲインが高すぎる設定になりがちで手動設定することに落ち着く）

今までのダイレクトサンプリングモードでの受信に切り替えてもダイレクトサンプリングモードが廃止されたので正しい受信は出来なくなっている。

・HF帯(0-28MHz)・VHF帯(28MHz-250MHz)・UHF帯(250MHz-1.766GHz)毎にアンテナ入力が分離されていてそれぞれ入力周波数帯のバンドパスフィルターが付いているので他の帯域での強力な電波の放送局などの妨害を減らせている。

・電源からのノイズ低減設計と消費電力や発熱の削減

・広域受信アンプなどへのアンテナ線への給電時にLEDが点灯してケースの穴から識別できるようになった

という事が自慢だそうです。

●ドライバーなどのインストール方法などの解説はここ「RTL-SDR ブログ V4 ユーザーガイド」

SDR#(Sharp)でのインストールは最新版のリリース1920だと「install-rtlsdr.bat」を実行するだけ。

リリース1919以前だと「RTL-SDR ブログ ドライバー GitHub リリース ページ」から「Releases.zip」をダウンロード・展開して「x86」ディレクトリ内から「rtlsdr.dll」「msvcr100.dll」「pthreadVC2.dll」をSDR#(Sharp)のディレクトリにコピーして上書きしておく。

もしリリース1920の環境のディレクトリがある場合は「rtlsdr.dll」「msvcr100.dll」をリリース1919以前のディレクトリに上書きコピーしても良い。（こちらの方が簡単）

「Releases.zip」を展開したディレクトリ内の「x64」ディレクトリ内のファイルを任意のディレクトリにコピーしておけばそこで「rtl_tcp.exe」なども実行できる。

●実際に「RTL-SDR Blog V4」ドングルでQuadratureサンプリングモードでSDR#(Sharp)での電波を受信してみての感想

ーUSB接続での受信時不具合

サンプルレートが「0.900001MSPS」「1.024MSPS」でのみ「AMモード」のデコード音声に低音のノイズが混在して非常に聞きにくかったです。

他のサンプルレートでは低音のノイズはありません。リリース1919とリリース1920・リリース1910で試してみましたが同じ現象でした。

ーrtl_tcp(64bit版)モードでの受信時状況

全てのサンプルレートで「AMモード」のデコード音声を聞いてみましたが特に不具合はありませんでした。

以下の受信状況比較は面倒なので「rtl_tcp(64bit版)モードでの受信時状況」でHF帯の受信状況を比較しています

「RTL-SDR Blog V3」は「direct samplingモード

「Nooelec NESDR SMArt v5」は「direct samplingモード」

「RTL-SDR Blog V4」は「Quadrature samplingモード」

での「rtl_tcp(64bit版)モードでの受信時状況」比較です。

「RTL-SDR Blog V4」は「Quadrature samplingモード」での受信なので「RF Gain」を手動で混信のない程度に調整します。「Tuner AGC」をONにもできるのですがそうすると混信が出てしまう程度に受信ゲインが高くなるようなので手動で調整します。

そうした場合の耳で聞いたSN比は

「RTL-SDR Blog V3」＜「Nooelec NESDR SMArt v5」＜「RTL-SDR Blog V4」＜「TECSUN PL-310ET」

のような位置づけになる感じです。

受信アンテナはMLA-30マグネティックループアンテナで聞いています。

日中のあまり受信状態が良くない時間帯の11MHz近辺の放送を聞いてみましたが手持ちのポータブルラジオ「TECSUN PL-310ET」だとまぁまぁ良く聞こえ、次に「RTL-SDR Blog V4」だと聞き取れるくらいです、「Nooelec NESDR SMArt v5」では聞き取りにくく「RTL-SDR Blog V3」ではほとんど聞こえない位です。

「RTL-SDR Blog V3」と「Nooelec NESDR SMArt v5」は「direct samplingモード」のせいで「0-14.4MHz」の帯域と「14.4MHz-28.8MHz」の帯域が混信してしまいますが（サンプリング周波数が28.8MHzなので半分の14.4MHz-毎に繰り返し混信）「RTL-SDR Blog V4」はアップコンバーターでの受信のため14.4Mhz近辺の受信も安定しているようです。

「RTL-SDR Blog V3」よりは受信感度が良くなっていますが「Nooelec NESDR SMArt v5」よりSN比がいいかと言われると同じような感じです。

他に「RTL-SDR Blog V4」の良さそうな点はHF帯受信時にVHF帯やUHF帯の大きい出力の通信の影響を受けて受信感度が下がりにくいという事でしょうか？

他に今までのチューナーチップの「R820T」は値上げでこれ以降価格が高くなるとのことですが、「RTL-SDR Blog V4」のチューナーの「R828D」は低価格なので安く販売できるとの事でした。

記事の執筆時点でのアマゾンの販売価格はそれぞれ
「RTL-SDR Blog V3」はアマゾンで5980円でした。

「Nooelec NESDR SMArt v5」はアマゾンで5495円でした。

「RTL-SDR Blog V4」はアマゾンで6480円でした。

という事で従来のドングルは在庫があるのか多少安めの様でした。

この時点では「RTL-SDR Blog V3」はあまり購入する価値はないかとも思います。

購入するならば「Nooelec NESDR SMArt v5」か「RTL-SDR Blog V4」のどちらかがいいですね。

危険：あ！偽のアマゾンサイトに誘導されたけどかなり巧妙

以下のサイトのURLドメインは偽のアマゾンジャパンのサイトです「dtioykqj1u8de.cloudfront.net」←httpsなどのURLを付けてアクセスすると色々混在して危険なので怖いもの見たさでもお勧めしません

googleの検索結果に(偽)アマゾンの商品のヒットした商品の結果が出ていて、本物のアマゾンジャパンの物と寸分違わないようなレビューなどもコピーされていたサイトに誘導されました。

いつものように商品をカートに入れると「開こうとしているのはアマゾンのページではありません」と出るし、「ログインされていません」と出てきます。

おかしいと思いブックマークにある本物のアマゾンジャパンを開いてみるとちゃんとログインされています。

！？あ！巧妙に作られている見分けがつかない「偽アマゾンジャパン」かと思いURLを確認するとドメインが「dtioykqj1u8de.cloudfront.net」(←偽サイトのドメインのサイト)になっています。

↓偽アマゾンジャパンのスクリーンショット

本物のアマゾンジャパンのドメインのサイトは「www.amazon.co.jp」(本物のアマゾンジャパンのサイトhttps://www.amazon.co.jp/)

偽アマゾンジャパンのスクリーンショットを見てみるとログインしていない時のお届け先部分にもアクセスの許可が必要な位置情報からとったものではなくネットのアクセス履歴から分かる推定の住所なんかが出てて本物っぽくて悪質です。

尚、偽アマゾンジャパンのサイトをInprivateモードで開いてみると一部アクセスが拒否されて開けていない部分なんかもありました。

偽サイトを開いてみるのは本物と偽物の表示を混同してしまうリスクがあったりもしますのでくれぐれもご注意を。

念のため利用履歴などからも偽URLの削除などを実施して間違えてアクセスしたりしないようにしましょう。

皆さん気をつけましょう（危なっ）

windows用のrtl_tcp最新版(direct sampling modeもOK)の取得

SDR# (SDRSharp)をRTL-SDRドングルが接続されているPC(「rtl_tcp」を動かすサーバー)とは異なるPCで「rtl_tcp」のクライアントとして動作させる記事を以前に書きました。

その際に配布されいた「rtl_tcp」のバイナリーは「direct sampling mode」が有効になっているものではなかったためネットから「direct sampling mode」指定が有効なバイナリーを探して入手していたと書いていましたが現在の最新版配布は「direct sampling mode」が有効になっているのを確認しました。

「rtl_tcp」は「rtl-sdr」の配布パッケージに含まれていて「ここのURLに詳しい記事があります」

「rtl-sdr」のWindowsバイナリー配布パッケージは「ここのURLのFTPから取得できます」

「direct sampling mode」が有効になっているバージョンの確認は「rtl-sdr-64bit-20240519.zip」で動作させて確認できました。

(64bit版と32bit版がありますが特に問題なければ64bit版がお勧めです)

コマンドプロンプトやバッチファイルでQブランチの「direct sampling mode」を有効にするコマンドラインオプションは以下のようになります。

rtl_tcp -D 2 [-a 待ち受けIPアドレス] [-p 待ち受けポート番号] [-d 2つ接続しているときは「1」指定で2番目のデバイスが対象]

バッチファイルは以下のように記述すれば大丈夫です

(rtl_tcpのあるフォルダを「C:\rtltcp」に置いた場合)

-------------start-rtl-tcp.batなどの名前で保存----------------------

@ECHO OFF

cd /d "C:\rtltcp"

start rtl_tcp -D 2 [-a 待ち受けIPアドレス] [-p 待ち受けポート番号] [-d 2つ接続しているときは「1」指定で2番目のデバイスが対象]

--------------------------------------------------------------------

なお、この記事を書いていた時点でのSDR# (SDRSharp)最新版は

「SDR# (SDRSharp) revision 1920 (2024-04-25) の「Download」ボタンで取得」でした。

（実行時に.NET Runtime8.0が必要です。実行時にダウンロードされます）

SSDの寿命の目安の書き込み量「TBW」をテストしている環境や条件の詳しい話の記事がありました

SSDの寿命の目安となる書き込み量「TBW」(巷ではこの数値のTB量のデータを書き込める目安と言われています)のテスト環境や書き込み条件の専門的な話を要約した記事がありましたので是非見てみてください。

以下のリンクはImpress社のPC Watchで取り上げられていた記事です。

「特集 「TBW」だけが耐久性指標ではない？キオクシアに聞く、SSDの選び方」

上記の記事を読んでいただいての私なりに解釈できた要約を以下に。

基本的なSSDの動作原理として覚えておくと便利な知識は以下のようなことがあります。

SSDはNANDフラッシュメモリーという記憶素子でデータを保存・書き換えできるように作られています、このフラッシュメモリーはRAMの様にほぼ無限に書き換えられるものではなく書き込みデータが安全に保存出てきてある程度の長期間電源無しでも読み出しできるという性質が比較的多くない書き換え回数で劣化するという性質があります。（ここから書き換え可能回数が多くなるとデータの保持期間が短くなっていき実用的でなくなるという事で）

他にもこのNANDフラッシュメモリーはRAMのようにバイト単位での書き換えが可能ではなくある程度のサイズのページ単位(上記の記事によると16KBだそうです)で書き込んだり消去したりしてデータを書き換えます。

あるページの中のデータを書き換える時はこんな感じになるようです。

・書き換え対象ページをコントローラーのRAMのようなページにコピー

・コピーされたRAMのようなページの書き換え部分データを変更する

・書き換え対象ページをデータ消去する

・データを書き換えたRAMのようなページを書き換え対象ページに転送してページ単位で書き込む

ですが実際に書き換え対象のページに書き込むかはコントローラー次第です。（後述ですが多分書き換えページが少ない空きページに書き込んでいそうです）

とNANDフラッシュのデータ書き換えの簡単な原理は上記のような物のようなのですが書き換え回数で劣化する問題やページの書き換えなどはコントローラーというCPUの様な物で複雑に処理されているのだそうです。

CPUのような物なのでそのプログラムのような物もあり、書き換え可能なファームウェアと呼ばれています。

記事によるとそのファームウェア自体もNANDフラッシュに保存されているそうでして、いわゆるSSDが認識されなくなって死んだと言われる状態はNANDフラッシュに保存していたファームウェアが保存の能力が落ちて消えてしまった状態らしいとの内容でした。

コントローラーで重要な役目の一つにNANDフラッシュのページのデータ書き換え回数をなるべく均一に分散させ、SSDの外部からの多数の書き換え要求を全体のNANDフラッシュ素子の書き換えの合計で済むようにするという役目があります（ウェアレベリングという呼び名で呼ばれています）。

詳細な動作の仕組みは企業秘密なのでしょうがページ単位のデータの書き換え回数などを監視していて書き換え頻度が低いページと書き換え頻度が多いページのデータ保存場所を入れ替えして書き換え回数を均一にすることなどなのでしょう（あくまでも個人の考えです）

OSからSSDに対してこのデータ領域は未使用ですという命令が出されることがサポートされていまして(TRIM命令)Windowsの場合はデフラグをするとSSDに保存している空き領域に(TRIM命令)が送られることになっています。

SSD側では保存されているデータが使われているのか使われていないのかは分からないので(TRIM命令)で使っていないと認識できれば読み書き性能の最適化や書き換え可能回数の均一化時のヒントにできるため定期的に行われると性能や寿命が有利になるようになっています。

Windowsのデフラグの定期スケジュールをONにすると標準では1週間単位となっていますがあまり頻繁ではないのは(TRIM命令実行時の)消費電力や性能低下などもろもろの事情のために適度に実行されるようになっているようです。

PCの暇と時間と消費電力などの余裕がある時はデフラグしておくとPC生活の質が良くなっているかもですね。

他にこれも個人の推測ですが、データが保存されている利用領域があまり多くなく未利用領域が多いほうが書き換え頻度の均一には有利だろうと思っていますので個人的に未利用領域のサイズはなるべく多くするように心がけています。（そのために通常以上に頻繁に保存や消去するのでは逆効果だと思いますが）

記事内ではSSDの大容量化で耐久可能なTBWの量が増えていると言う話も出ていますがそれはNANDフラッシュのページ数が増えているという事になるので書き換え数を均一化している効果で集中して書き換えられる部分を全体のページで分散すると耐久度のTBWも増えると言う理屈からです。

OSのドライブ中のデータの性質としてはなかなか書き換わらない部分が多数で頻繁に書き換わる一時領域のような部分は少量という事が一般的な利用形態です。

記事で取り上げられていたTBW以内の書き込み量で寿命となる最悪のケースで取り上げられていた使い方は、SSDの使用領域全域に対してランダムに4KBの書き込み(16KBのページ書き換えが多数発生する)を連続するという使い方が取り上げられています。

連続ではなく散発的に通常のファイルを削除したり新規に作成する場合は1ページの16KBより大きいサイズの連続データで書き込まれますのでページ書き換え回数はさほどではないですし書き換え回数を均一化する仕組みも十分な処理時間があって寿命はそれなりに長くなると言う事の様です。

PCでそのような少量のファイルサイズの書き換えが多いケースとしてはWindowsのCドライブのようなテンポラリファイル(動作時に一時的に作られる作業領域)がきついと取り上げられています。テンポラリファイルの代表的な物だとWEBブラウザのテンポラリファイルなどがあります。HTMLファイルや細かなスクリプトファイルなど多数作成されます。

なるべく書き換えの寿命にあらがいたいデータでSSDに保存していたい場合はCドライブとは別のSSDにドライブを作ってそこにデータを保存しておくと長寿命に扱えるという事になります。

Cドライブと同じSSDのディスク内に別のドライブを作っても母体のディスクのSSDは同じですので書き換えの寿命と言う点ではあまり効果はないと思います。

他にSSDの寿命という部分でどんな状態になると寿命なのか？と言う点も挙げられていましたが書き込みできなくなるのはよっぽど使い物にならなくなっている時点とも挙げられていて、一般的には書き込みデータが保持できる時間が少なくなってデータ読み出し時に化けてきた時点が寿命と言っていますね。

SSDと似ているデバイとしてはUSBメモリもNANDフラッシュにデータを保存しています。

USBメモリもコントローラーがあり同じような構造ですが使っているNANDフラッシュの書き換え可能回数や書き換えにかかる時間、コントローラーの性能がSSDよりも安価な物や低消費電力仕様になっているようです。

この辺でいかがでしょうか？

具体的にSSDの寿命を長くして使う決定的な使い方は難しいですね。でも動作温度を低くすることはいいようですね。

続：グラボなくともインテルオンボードグラフィックでフリーソフトの動画の動画形式変換などをしてみる

前の記事で「shotcut」という動画編集ソフトを使って動画の形式変換などを行ってみました。

今度の記事はデスクトップPCやデスクトップPCのグラフィックカードを使うとどれくらい動画の書き出し時間が早くなるかの例です。

参考にするデスクトップPCの仕様は一昔前の物でグラフィックが重いゲームが楽に動くなどの物には遠く及ばない程度のお手ごろな性能の物です。
今の新しいグラフィックボードの物ならばもっと高速に処理できると思います。

ノートPCの仕様も少し前のありがちな仕様になっています。

動画編集で時間がかる動画書き出しをしたい場合に、ノートPC(インテルオンボードグラフィック)・格安ミニPC(インテルオンボードグラフィック)・デスクトップPC(一昔前のグラフィックカード)のどれにすれば財布と釣り合うかの目安にしていただければと思います。



※追記と修正
当初「サンプル動画②」で使っていた動画のエンコードにかなり時間がかかっていましたが他の動画は一般的な「30fps」の動画だったのに「サンプル動画②」だけは倍の「60fps」だったためにフレーム数が倍で処理時間がかかっていました。

そのため従来の「サンプル動画②」は「サンプル動画②-60(60fps)」と名前を変更して新たに比較用の「サンプル動画②-30(30fps)」の情報を追加しました。

他に分かりやすいようにCPUのCinebenchの性能の数値やデスクトップPCの「オンボードインテルHDグラフィック」についての性能も追加しています。



以下に今回計測したノートPCとデスクトップPCの主な仕様を上げておきます。

ノートPC：
・CPU：Intel Core i7-10510U CPU@1.80GHz 2.30GHz
・Cinebench MultiCore:3387 SingleCore:1057
・グラフィックシステム：オンボードインテルUHDグラフィック
・メモリ：32GB
・動画編集のドライブ：SSD

格安ミニPC：(3万円しないで買えます)
・CPU：Intel N100 800 MHz
・Cinebench MultiCore:2794 SingleCore:327
・グラフィックシステム：オンボードインテルUHDグラフィック
・メモリ：16GB
・動画編集のドライブ：SSD

デスクトップPC：
・CPU：Intel Core i7-7700 CPU@3.60GHz 3.60 GHz
・Cinebench MultiCore:5336 SingleCore:1063
・グラフィックカード：NVIDIA Geforce GTX 1050
・オンボード内蔵のグラフィック：オンボードインテルHDグラフィック630
・メモリ：32GB
・動画編集のドライブ：SSD


この動画編集ソフトのエンコーダーがH264やH265-HEVCのハードウェアエンコードをサポートしている名前は以下のような物です。

オンボードインテルUHDグラフィックシリーズ：
オンボードインテルHDグラフィックシリーズ：
「インテルQuickSync」
・H264：h264_qsv
・H265-HEVC：hevc_qsv

NVIDIA Geforceシリーズ：
「NVIDIAグラフィックカード」
・H264：h264_nvenv
・H265-HEVC：hevc_nvenc
※：GTX 1050のハードウェアエンコードはBフレームという動画圧縮に対応していないので動画サイズが大きくなります

CPUでのエンコードになるもの：
・H264：libx264
・H265-HEVC：libx265


以下にサンプルの動画を使って「ハードウェアエンコード」と「CPUだけでエンコード」の「動画ファイルの書き出し」を行った時間の例を挙げておきます。

動画書き出しの時間の目安）

〇サンプル動画①-30(30fps)の時間：30分 1280x720
-出力動画の形式:1280x720 インターレース解除:BWDIF 補完:バイキュービック QVBR:45%  

・ノートPC
CPUエンコード(コーデック「libx264」)：9分40秒(580秒)
CPUエンコード(コーデック「libx265」)：17分6秒(1026秒)
「インテルQuickSync」(コーデック「h264_qsv」)：6分2秒(362秒)
「インテルQuickSync」(コーデック「hevc_qsv」)：6分59秒(419秒)

・格安ミニPC
CPUエンコード(コーデック「libx264」)：11分45秒(705秒)
CPUエンコード(コーデック「libx265」)：21分49秒(1309秒)
「インテルQuickSync」(コーデック「h264_qsv」)：8分23秒(503秒)
「インテルQuickSync」(コーデック「hevc_qsv」)：8分27秒(507秒)

・デスクトップPC
CPUエンコード(コーデック「libx264」)：6分34秒(394秒)
CPUエンコード(コーデック「libx265」)：11分46秒(706秒)
「NVIDIAグラフィックカード」(コーデック「h264_nvenc」)：3分53秒(233秒)
「NVIDIAグラフィックカード」(コーデック「hevc_nvenc」)：3分52秒(232秒)
「インテルQuickSync」(コーデック「h264_qsv」)：5分53秒(353秒)
「インテルQuickSync」(コーデック「hevc_qsv」)：6分1秒(361秒)


〇サンプル動画②-30(30fps)の時間：1時間 1280x720
-出力動画の形式:1280x720 インターレース解除:BWDIF 補完:バイキュービック QVBR:45%  

・ノートPC
CPUエンコード(コーデック「libx264」)：23分9秒(1389秒)
CPUエンコード(コーデック「libx265」)：41分24秒(2484秒)
「インテルQuickSync」(コーデック「h264_qsv」)：12分22秒(742秒)
「インテルQuickSync」(コーデック「hevc_qsv」)：14分9秒(849秒)

・格安ミニPC
CPUエンコード(コーデック「libx264」)：29分36秒(1776秒)
CPUエンコード(コーデック「libx265」)：52分54秒(3174秒)
「インテルQuickSync」(コーデック「h264_qsv」)：15分16秒(916秒)
「インテルQuickSync」(コーデック「hevc_qsv」)：16分0秒(960秒)

・デスクトップPC
CPUエンコード(コーデック「libx264」)：14分11秒(851秒)
CPUエンコード(コーデック「libx265」)：26分15秒(1575秒)
「NVIDIAグラフィックカード」(コーデック「h264_nvenc」)：6分45秒(405秒)
「NVIDIAグラフィックカード」(コーデック「hevc_nvenc」)：6分42秒(402秒)
「インテルQuickSync」(コーデック「h264_qsv」)：9分53秒(593秒)
「インテルQuickSync」(コーデック「hevc_qsv」)：11分5秒(665秒)


〇サンプル動画②-60(60fps)の時間：1時間 1280x720
-出力動画の形式:1280x720 インターレース解除:BWDIF 補完:バイキュービック QVBR:45%  

・ノートPC
CPUエンコード(コーデック「libx264」)：37分44秒(2264秒)
CPUエンコード(コーデック「libx265」)：1時間6分37秒(3997秒)
「インテルQuickSync」(コーデック「h264_qsv」)：22分22秒(1342秒)
「インテルQuickSync」(コーデック「hevc_qsv」)：28分15秒(1575秒)

・格安ミニPC
CPUエンコード(コーデック「libx264」)：52分55秒(3175秒)
CPUエンコード(コーデック「libx265」)：1時間23分46秒(5026秒)
「インテルQuickSync」(コーデック「h264_qsv」)：30分55秒(1855秒)
「インテルQuickSync」(コーデック「hevc_qsv」)：31分16秒(1876秒)

・デスクトップPC
CPUエンコード(コーデック「libx264」)：24分34秒(1474秒)
CPUエンコード(コーデック「libx265」)：43分7秒(2587秒)
「NVIDIAグラフィックカード」(コーデック「h264_nvenc」)：13分20秒(800秒)
「NVIDIAグラフィックカード」(コーデック「hevc_nvenc」)：13分28秒(808秒)
「インテルQuickSync」(コーデック「h264_qsv」)：21分46秒(1306秒)
「インテルQuickSync」(コーデック「hevc_qsv」)：25分30秒(1530秒)

〇サンプル動画③-30(30fps)の時間：1時間 1920x1080
-出力動画の形式:1920x1080 インターレース解除:BWDIF 補完:バイキュービック QVBR:45%  

・ノートPC
CPUエンコード(コーデック「libx264」)：51分19秒(3079秒)
CPUエンコード(コーデック「libx265」)：1時間34分30秒(5670秒)
「インテルQuickSync」(コーデック「hevc_qsv」)：21分39秒(1419秒)
「インテルQuickSync」(コーデック「hevc_qsv」)：25分23秒(1523秒)

・格安ミニPC
CPUエンコード(コーデック「libx264」)：58分14秒(3494秒)
CPUエンコード(コーデック「libx265」)：2時間2分38秒(7358秒)
「インテルQuickSync」(コーデック「h264_qsv」)：27分47秒(1667秒)
「インテルQuickSync」(コーデック「hevc_qsv」)：27分35秒(1655秒)

・デスクトップPC
CPUエンコード(コーデック「libx264」)：32分33秒(1953秒)
CPUエンコード(コーデック「libx265」)：1時間1分59秒(3719秒)
「NVIDIAグラフィックカード」(コーデック「h264_nvenc」)：10分5秒(605秒)
「NVIDIAグラフィックカード」(コーデック「hevc_nvenc」)：10分4秒(604秒)
「インテルQuickSync」(コーデック「h264_qsv」)：17分41秒(1061秒)
「インテルQuickSync」(コーデック「hevc_qsv」)：20分7秒(1207秒)


ソフトウェアエンコードは動画の解像度が1280x720はそんなに重くありませんが1920x1080になるとかなり時間がかかるようになります。
ハードウェアエンコードの場合は1920x1080だと1024x768より速いケースもありますがフレームレートが通常の倍（60fps）のため通常多い(30fps)の倍程度の時間がかかっていたためでした。
 

3万円しない格安ミニPCでもインテルのオンボードグラフィックのハードウェアエンコードを利用すると案外実用的に使えるものだなぁと思いました。

グラボなくともインテルオンボードグラフィックでフリーソフトの動画の動画形式変換などをしてみる

何かの動画を持っている場合に不要部分の削除などの最低限の動画編集をしてデータサイズがコンパクトな形式で保存したい場合がありますよね。

ありがちなのはPCが「グラフィックカード」がついていない（「インテルのオンボードグラフィック」）ノートPCだけど最低限の編集はしたいという場合があります。

ノートPCでもCPUはそこそこの性能はありますのでまぁまぁ重めの処理も何とかなりそうですが「グラフィックカード」がないと動画編集時の重さやH264やH265-HEVCでの動画の形式変換で保存するのに時間がかかりそうです。

しかも環境がいまいちなのに「動画編集ソフト」が有名な有料だととても悲しい気分になります。

そこで有名なフリーの「動画編集ソフト」「Shotcut」を試して動画の不要部分削除とコンパクトな動画形式での保存をしてみます。

この「動画編集ソフト」はフリーで使えて「お試し機能制限」などは一切ありません。

詳細な使い方は「Shotcut 使い方」で検索すれば沢山出てきます。

動画編集時の重さは基本的にグラフィックカードがないと快適ではないのですがここでは最低限の「不要部分のカット」

と「動画の連結」だけを例にします。

他にこの動画編集ソフトで嬉しいのはいわゆる後付けやオプションの「グラフィックカード」がなく「インテルのオンボードグラフィック」だけのPCでも「動画ファイルの書き出し」時のH264やH265-HEVC(MP4)の「ビデオエンコード」が「インテルのオンボードグラフィック」の「ハードウェアエンコード」（「インテルQuickSync」という機能です）が使えてフリーで使えるのに比較的短時間で「動画ファイルの書き出し」が終わるという点がナイスです。

これが「ハードウェアエンコード」が使えずにCPUだけで「動画ファイルの書き出し」を行う場合は以下のような時間がかかります

動画書き出しの例）

ノートPCのCPU：Intel Core i7-10510U CPU@1.80GHz 2.30GHz

出力動画の形式：1280x720 補完:バイキュービック HEVCプロファイル:H265 QVBR:45%  

サンプル動画の時間：25分

CPUでのエンコード(コーデック「libx265」)：18分15秒

「インテルQuickSync」(コーデック「hevc_qsv」)：6分9秒

不要部分のカットは以下のような手順で行います。

・タイムラインの「+」を押して読み込んだ動画を「タイムライン」の「映像トラック」に表示させる

・タイムライン上の映像トラックでプレビューして編集したい不要な時間の最初の場所に「▽」を移動させる

・「][」を押して映像を分割する

・タイムライン上の映像トラックでプレビューして編集したい不要な時間の最後の場所に「▽」を移動させる
・「][」を押して映像を分割する

・「][」を押して映像を分割した「不要な部分の映像クリップ」を選択して「-」を押して削除する
・動画を連結したい場合は動画を開いてタイムラインの「+」を押して読み込んだ動画を「タイムライン」の「映像トラック」に表示させる

・不要部分を削除し終わったら「書き出し」タブのプリセット(「H.264 MainProfile」や「HEVC MainProfile」など)を選択

・「詳細設定」タブで動画の解像度や品質を設定して「ファイルの書き出し」ボタンを押して動画を書き出す

（「インテルQuickSync」の「ハードウェアエンコード」を使用するには「ハードウェアエンコーダーを使用」にチェックを入れて「エンコーダー」を「h264_qsv」(H264)や「hevc_qsv」(H265)を使用します。プリセットを選べば自動的に設定されます）

という感じで「インテルのオンボードグラフィック」のPCで無料のフリーソフトでも意外と編集などができますので試してみてはいかがでしょうか？