独自開発の「マルチスレッド・バーニアコンペンセーション(MTVC)」を搭載した、新性能第3世代「ブロードキャスト・サウンドプロセッサ(BSP G3)」による配信を、2020年2月より開始した。
この新性能第3世代「ブロードキャスト・サウンドプロセッサ(BSP G3)」は、ダイナミックレンジの最適化により低ビットレートでの品質も確保し、温和で芯のある迫力のサウンドカラー演出により、据え置かれたスピーカーのみならず、スマートフォンの小型スピーカーでも聴きやすく、そしてイヤホン・ヘッドホンでも疲れないサウンドを実現したものとなっている。
第1・第2世代ブロードキャスト・サウンドプロセッサの長期間にわたる使用で、いくつかの品質的・技術的な問題、特に信頼性・可用性・保守性の低さが表面化しており、配信サイトとして持続性を高めるため、これら問題を解決した新しい「サウンドプロセッサ」を開発した。
新しい「サウンドプロセッサ」は従来とおりLinuxで稼働しつつ、エンコーダーも含め構成ソフトウエア全てをUnix系シェルで動作するコマンドラインソフトウエアとし、ネイティブでオープンソース(OSS)、かつフリーソフトウエア(GPLやLGPL, 修正BSDライセンス等
※)のみの「FLOSS (Free/Libre Open Source Sofrware)」のものに絞り、「UNIX哲学」を尊重し白紙から全面的にシェルスクリプトで構築している。
※現状ではDebianのリポジトリに含められるライセンス形態のみに収まっている.
現在公開している全走行音番組の品質は、標準モードは廉価ターンテーブルのアナログレコード程度、LOWモードがノーマルポジションのカセットテープ程度、ECOモードはAMステレオ放送程度とし、処理を施している。
(LOWモードの非常用データは狭幅ステレオ)
システムの全面更新は、第1世代ブロードキャスト・サウンドプロセッサの試験導入以来、16年ぶりとなる。
※「ブロードキャスト・サウンドプロセッサ」の目的と解説については, 第1世代・第二世代ブロードキャスト・サウンドプロセッサの解説記事を参照していただきたい.
■様々な問題が表面化した第1・第2世代プロセッサ
最初のテスト版プロセッサは、当方の環境に非Unix系プロプライエタリOSが残存していた2004年頃より検討や試行を行っていたものであり、2007年に試験運用を開始した第1世代プロセッサは非Unix系プロプライエタリOSで、そして小改良した第2世代プロセッサはLinux移行後も使う目的で、Linux上で非Unix系プロプライエタリOSのAPI互換環境上で動作させるものであった。
導入当時の、現在のものに比してローパワーなPCで実現できる画期的なものだったが、反面処理速度は満足のいくものではなく、経年でハードウエアの老朽化や長期の使用で陳腐化する等、様々な問題が表面化していた。
例えば、非Unix系プロプライエタリOSのアプリケーションにありがちなGUIによる項目設定は、見た目にはゴージャスで便利そうなものの、そのデザインによってはツマミを目分量で設定する等、数値で設定することが困難かつ曖昧なものもあり、再現性が悪いものとなっていた。
プロセッサ部は互換環境を介して動作していたこともあり、そのアプリケーションがクラッシュすると古のSF作品よろしくパラメータを再設定する必要がある等、堅牢で安定し設定が明確なUnix系コマンドアプリ等との差が大きく見受けられた。
エンコード部は第2世代プロセッサよりシェルスクリプトによりLinuxネイティブで動作させることができていたが、互換環境下で動作していたプロセッサ部のデータの出力は標準出力に対応していないため、オンデマンドでのデータの受け取りが不可能で、大量の中間処理ファイルをストレージに常に置く必要があった。
このような使い方は効率の悪いものであり、ストレージに占める割合もストレージがギガバイト単位の時代には悩まされる要因となっていた。
さらにプロセッサ部で使用していた非Unix系プロプライエタリOSのアプリケーションのほとんどに、ライセンス面で商用利用ができない条項が含まれるものや、そもそもプロプライエタリで自由ではないもの、開発者がメンテナンスを放棄し改良等が行われなくなったソフトウエアがあり、Linux移行後の当方の環境の中で、そしてウェブサイトを維持するために必要なソフトウエアの中で「最も不自由なもの」となっていた。
この制約もあり、ウェブサイトとしてスポンサーを募集したり、広告表示ができなかった。
また、サウンド的にも決して理想的なものではなく課題となっていた。
これらの問題を解決する方法を模索しなければならなかったが、ウェブサイトに注力できなかった時期が続いていたこともあり、第2世代プロセッサを維持したままであった。
■無線機・トランスミッター用音声処理技術の応用
様々な事情で余裕が無い状態が続き、それから脱しつつあった際に数十年来の課題と気分転換を兼ねて「AMトランスミッター」(AMラジオ送信機)を実験用ボード(ブレッドボード)で試作し、様々なサウンドを試すようになった。
アマチュア無線家として送信機の自作や、振幅変調(AM)での交信も経験もあり、AMの扱いがSSB(抑圧搬送波単側波帯)やFM(周波数変調)に比べて工夫が必要なのは解っていたが、特にAMトランスミッターは音楽のような音を上手に電波に乗せる(変調する)ためには、事前の処理が欠かせないことを再認識させられた。
既製ICによる音声処理回路(コンプレッサ・リミッタ)の検討、それをLinuxで再現する試行を繰り返し、インターネットで内外のサイマルラジオ放送やストリーミング動画の音声等を受信したり、CDや走行音等も含めて様々な音声を処理し、AMトランスミッターやFMトランスミッターで平均変調度を高くし再送信できるようにした
※。
※この処理を経て、AMトランスミッターでJ-WAVEやInterFM,各地のコミュニティーFM,海外のBBC等を聴くと、いかにも「ラジオ」という音で楽しめる。バラエティー色の強いAM局等のそれらと趣きの違う番組をAMラジオで楽しめるのは愉快なことである。
このLinuxでの処理については「UNIX哲学」
※を尊重し、Linux上で動作するネイティブなソフトウエアを用いてシェルスクリプトで構成したもので、今回その成果・知見をウェブサイトのデジタルストリーミングに反映した。
※マイク・ガンカーズ「UNIXの哲学」
小さいものは美しい。
各プログラムが一つのことをうまくやるようにせよ。
できる限り早く原型（プロトタイプ）を作れ。
効率よりも移植しやすさを選べ。
単純なテキストファイルにデータを格納せよ。
ソフトウェアを梃子(てこ)として利用せよ。
効率と移植性を高めるためにシェルスクリプトを利用せよ。
拘束的なユーザーインターフェースは作るな。
全てのプログラムはフィルタとして振る舞うようにせよ。
■FLOSSを用いシェルスクリプトで構成し、堅牢性や持続性を確保した「第3世代プロセッサ」
第3世代プロセッサは以前のプロセッサの反省点を反映しゼロベースで作り直したもので、構成ソフトウエアをFLOSS (Free/Libre Open Source Sofrware) のみとし、シェルスクリプトで作成したものである。
シェルスクリプトは特殊なバイナリではなく単なるテキストファイルであり、このファイルに全ての構成・手順と設定値(パラメータ)を記し保存・バックアップすることで、設定値の完全数値化と人間による可読性を確保し、保守性の向上を図っている。
これにより、GUIソフトウエアによる操作の拘束性と非可読な設定ファイルを排除し、且つ古くメンテナンスされていないものを含む全てのプロプライエタリソフトウエアをパージし、構成ソフトウエアをFLOSSのみに絞り込んでシステムを大幅に簡素化した。
構成ソフトウエア全てをFLOSS化することは、流行に囚われず、使途の制約を受けず、再現性と冗長性・移植性・保守性・持続性を確保し、ベンダーロックインの排除に役立っている。
これにより、一般向け非Unix系プロプライエタリOS自身やそれに向けたソフトウエア等にありがちな、流行り廃りや計画的陳腐化による「急速な陳腐化」や、プロプライエタリなライセンスという「縛り」、使途の制約、個人開発者の「我侭」や「邪心」・公開終了・ウェブサイト消失・消去等によるトラブルや持続性の低下・停止を回避している。
今回使用している構成ソフトウエアは全てFLOSSであり、第3世代プロセッサの開発を開始した2020年時点でメンテナンスや開発がされているもの、ディストリビューションでパッケージ管理されているもの、あるいはそれらのソースコードから独自にビルドしたものを使用している。
その結果、採用した構成ソフトウエアについては世界的な利用実績があり、知見の公開が広くなされているものに絞り込むことができた。
デプロイが容易なシェルスクリプト化により、必要とするソフトウエアやライブラリ類さえ揃っていれば、どのUnix系システムでも同じ処理を再現可能とした。
このようにした理由は、第1・第2世代プロセッサを実行していたPCが老朽化しソフトウエアも問題が多かったため、別の環境で維持させるよりもシステムを新しくし、シェルスクリプトによって容易化と移植性の向上を図ることにより、問題を解決させることにあった。
結果的にクラウド処理にも適し、必要なソフトウエアと潤沢なコンピュータ資源,高速回線さえ用意していれば、SSHを介しローカル側の元データをネットワーク越しにあるLinuxや各種BSD,MacOS XのUnix系マシン、Linux端末化したAndroidスマートフォン・タブレット、さらにはUnix系スーパーコンピュータ等へ送り込んで処理させることも出来、その送り先コンピュータのアーキテクチャも問わず(CPUアーキテクチャ・32bit,64bit問わず)処理が可能となった。
これにより、本システムの実行環境(クラウドのインスタンスも含む)を複数かつ低コストで作成することが出来、分散処理環境を容易に素早く立ち上げることが可能である。
■マルチコア・マルチスレッド対応と、省メモリ、オンザフライ可能な構成に
第3世代サウンドプロセッサは、安定した動作を実現しながらメモリおよびディスク資源の浪費を抑えた。
非Unix系プロプライエタリOS上でネイディブ動作するソフトウエアには、長時間の大容量データの処理に大量のメモリや巨大なテンポラリファイルを必要とするものが多く、その資源が尽きて作業に失敗することが多々見受けられる。
特に私共のような長時間コンテンツを扱う者として、長時間コンテンツを失敗無く作業できるようにすることは重要な要求であり、そのため本システムではUNIX哲学を尊重し、Unixシェルプログラミングの要でもある「パイプライン処理」によるオン・ザ・フライなストリーミング処理とすることにより、大量のメモリや巨大テンポラリファイルを利用すること無く、長時間データでも失敗することのない堅牢なシステムとした。
以前のシステムでは「プロセッサ部」と「エンコーダー部」が別構成となって中間ファイルの保存を要していたものを、「パイプライン処理」等を活用することで全行程を一体化し、マスターデータの入力から配信データの出力まで連続処理(オン・ザ・フライ処理)を実現し、メモリとディスク資源の使用も削減した。
オン・ザ・フライ エンコードにより、録音原盤やマスタリング中のデータから処理後の状態を直接試聴できるようになり、ターゲットにも適したマスタリング作業の最適化に寄与している。
一方で、LinuxまたはUnix系OSに備わっている基礎技術でもある「パイプ」を積極的に利用しているため、CPUのマルチコア・マルチスレッドといった並列処理技術を必然的かつ積極的に利用することとなり、CPU資源を有効に利用したものとなっている。
これらを実現しているUnix系OSのカーネルやシェル、そしてモダンなファイルシステムとの組み合わせは堅牢性とパフォーマンスに優れたものであり、上記のメリットを最大限に享受できるものとなっている。
また、予想よりもメモリ使用量が少なかったこともあり、要所のパイプ間に既存のコマンドを利用したダブルバッファを実装し、実行速度の向上を図った。
■「マルチスレッド・バーニア・コンペンセーション (MTVC)」による、懐かしく芯の太いサウンドカラーを醸成
本システムの要は、独自に考案した「マルチスレッド・バーニア・コンペンセーション (MTVC)」である。
このMTVCは、筆者がプライベートで実験しているFMおよびAMラジオトランスミッター向けに、無線局・放送局用機材やプロプライエタリソフトウエアを参考に、FLOSSを組み合わせて構成・実現したものである。
無線機用2バンド音声処理回路およびテープレコーダー用音声処理ICを、Linux上でシミュレートした成果を多バンド化のうえ応用し、処理バンド間のクロスオーバー部分を補償する副処理機構(クロスオーバー・コンペンセーター)を加えて「バーニア制御」化している。
特に芯の太い音を醸成しながら、ダイナミックレンジの制約が厳しいAMラジオトランスミッターの平均変調度を上げることに成功し、音楽やトークのみならず鉄道走行音や自然音といった録音も難なく変調・送信させることができ、これをデジタルストリーミング向けに応用し、そこそこの音質でも長時間の聴取で疲れにくいよう、サウンドカラーも温和で芯の太い音を目指した。
醸し出される音は、やや癖のある80年代後半から00年代初頭の放送局のアナログ処理機構による音を模倣したもので、最近のデジタルプロセッサを用いた癖を抑えている放送局のトレンドからは外れた音だが、第1世代プロセッサ導入の頃より目標としていた音で、今回それが実現したものである。
ダイナミックレンジの最適化により低ビットレートでの品質も確保し、サウンドカラーの演出により据え置かれたスピーカーのみならず、スマートフォンの小型スピーカーでも聴きやすく、そしてイヤホン・ヘッドホンでも疲れないサウンドを実現している。
■配信コーデックの統一と、カスタムビルドによるエンコード品質の向上
配信に使用するコーデックについても、品質の統一を図る観点とライセンスの縛りを排除する方針から、各ブラウザ・デバイス間で共通利用できる特許切れコーデックに統一した
※。
※iOS向けを除くが、Debianパッケージで用意もされているコーデックライブラリを使用している。
特許切れのレガシーなコーデックであるが、利用にあたり品質に優れたオープンソース・フリーソフトウエアのエンコーダーを採用し、Unix系環境の強みを活かし変換環境に特化した最適化やビルドオプション、モダンなコンパイラやライブラリ等を利用して自らバイナリを作成する「カスタムビルド」を行い、モダンコーデックに肉迫する品質を目指した。
特に、最近のCPU・SoCやコンパイラで積極的に利用されている新技術による恩恵により、以前に比べて品質の良いバイナリの生成が出来、結果としてエンコード品質も向上したものとなっている。
一方、コーデック変更に伴う品質確保と最近の通信事情を考慮し、配信ビットレートを標準モードを96kbpsに、LOWモードを48kbpsに、ECOモードを24kbps(非常用は16kbps)にした。
10年前と比べ通信環境が変化しており、またコーデック変更に伴う要求もあり、この機会に変更したものである。
現在のバックボーンや利用状況から察するに、配信ビットレートを50％増やしてもサーバー・回線・クライアントいずれにも通常の利用に影響を与えるほどのものではなく、それでいて品質統一やサーバーストレージの消費を抑えることが可能、という判断もある。
受信量に制約のある回線や混雑時にご利用の場合は、ぜひLOWモード、またはECOモードのご利用を試していただきたい。
当方の検証では、公称128kbpsの4Gモバイル回線(実効速度約64kbps)
※において、LOWモードとECOモードでの受信を確認している。
※au「povo 2.0」 データトッピング無しの回線。
■多分岐・並列同期エンコード処理による処理時間短縮
第2世代プロセッサのエンコード部で採り入れていた「多分岐並列同期エンコード処理」を改良のうえ実装し、「標準」「LOW」「ECO(通常)」「ECO(非常用)」の4ビットレートのデータを同時並行で処理・出力することで、全体の処理時間短縮を実現している。
「多分岐並列同期エンコード処理」は、シェルの機能やコマンド，ソフトウエアの機能を存分に利用したもので、かつ並列同期処理とすることで協調しながら音飛びすることなく、マルチスレッドで処理するものである。
同期処理のため処理の遅いプロセスに速度を合わせることになるが、非同期処理では避けられなかった「音飛び」を防いだ安定した処理が可能であり、また多分岐同期処理とすることで複数のビットレートデータを同時に処理することができ、ビットレート毎に処理を繰り返すよりも実質的に大幅な処理時間短縮が図られ、またCPUのマルチコア・マルチスレッド機能を積極的に利用するので、効率の良い処理方法となっている。
加えてクラウド対応により、数ある番組データをネットワーク上・クラウド上にある複数のコンピュータ・インスタンスで重複させることなく逐次並列処理ができるようにすることで、更なる処理時間短縮も可能な仕様となっている。
実際、筆者の環境で最大4台のLinuxコンピュータで処理を行なったことがあり、ネットワークで接続できるコンピュータがあれば、限界まで複数同時処理させることが可能である。
■今後の課題
一方で、シェルスクリプト特有の制約や音声処理のための機能不足等もあり、ある程度の聴取に支障の無いエラーやクリッピング等を許容することで、完璧な100%の高音質を目指さず、現実的な80~90％の目標・品質に留め妥協している。
よって本システムは、一般向け非Unix系プロプライエタリOS上のみで動作する、お金を出せば誰でも簡単に使える最新かつプロプライエタリな技術満載のソフトウエアを用いた「高性能」なものではないが、本「第3世代サウンドプロセッサ」はFLOSSとシェルスクリプトによって構成され、Linux端末化したAndroidデバイスも含めた数多くのUnix系プラットフォームに対応する、シンプルでありながら汎用性の高い、経済的かつ持続可能な「新しい性能 (新性能)」なものになっている。
この「新性能」という語のニュアンスは、古くからの鉄道ファンの方ならお解りいただけるかと思う。
当サイトは現在のところ鉄道走行音の配信のみだが、将来は音楽やトークのコンテンツを、新性能第3世代「ブロードキャスト・サウンドプロセッサ(BSP G3)」による処理で配信できればと思う。
《おことわり》
ブロードキャスト・サウンドプロセッサのスクリプトそのものや、具体的な構造(ブロック・ダイアグラム)、パラメータ設定等の公開はしていない。
これは「秘伝のスパイス」「秘伝のタレ」と、理解していただきたい。
2022.3.6 初出
