テレビ局のカメラの何がすごいのか

テレビ局のカメラの凄さについて、専門家ではないが、紹介したい。昨今民生用カメラも高品質なものが増えていたり、YouTuberなどが高価なカメラを導入することも増えているが、何が違うのか、何がすごいのか。

いわゆるスタジオや中継現場で利用する巨大なレンズをもつカメラ「システムカメラ」は、カメラ・レンズ併せて1台数千万円程度するのは普通である。報道現場などで使うショルダーカメラ、いわゆる「ENGカメラ(Electronic News Gathering) 」はオプション等含めて500万円くらいはすると思われる。一方で、YouTuberなども買い始めた高級ミラーレス一眼レフカメラや高級ハンディーカムは高くても50万円—80万円ほどであろう。

その差額は何なのか?保証のレベル?カモられてる?無駄にレンズデカい?

結論からいうと、プロ用として求める機能をきちんと実装しているので、
妥当な値段と言える。(必要かどうかは置いておいて)

以下、大きな違いを列挙する。
色々なメーカーはあるが、レンズはキヤノン、システムカメラ本体はikegami、ENGカメラはソニーのものを基準に述べる。

【レンズ】ズーム倍率

たとえば野球中継で必要な倍率をカバーするこのレンズ⇓

https://cweb.canon.jp/bctv/lineup/4k/4k-d/uj111/index.html
26.6kgもするが、8.3mmから1850mm までカバーする。最短撮影距離は3m。
センサーは2/3型なので、フルサイズカメラの35mm換算だと33mm-7400mm・・・は?
※一般的に普通の構図で撮るには50mm ズームレンズでは300mm程度あるのがふつう。

【レンズ】ブリージング ピント調整の再現

普通のズームレンズでは、ピント調整の操作を行うだけで画角が変わってしまう現象(ブリージング)がある。シネマカメラ用のレンズではブリージングが発生しないような工夫がされているが、システムカメラ用のレンズでも基本的には発生しない。
静止画撮影においてはブリージングは問題にならないが、動画撮影において発生すると若干気になる現象である。

また、ズームした状態でピントを合わせて何度かズームアウト・インの操作を行ってもピント面は変わらない。超遠くの観客席に急にズームインをしてもガチっとピントが合うというテクニックでの撮影も可能となる。


【レンズ】純粋なクオリティ(開放での画質)

昔はそうではなかったかもしれないが、4K撮影に耐えうるためというのもあり
レンズ自体の純粋のクオリティ、解像度の高さなども、民生用の機材とは一線を画す。(定量化が難しい)純粋に解像感=細部を見たときの画質の良さ が異なる。

取り回しの良さ

業務用三脚へのマウント対応や、ENGの場合本体を肩に乗せることができることなどによる安定性がある。用途を絞れば「ジンバル」や、小型アクションカメラのほうが勝る場面も多いが、ENGであればほとんどの場面に対応できる。

【システムカメラ】リモートでの画質調整が可能

リモートでアイリス(F値)や感度、ガンマ値などを変えることができる。そのような操作をする役割を一般的にVE(=Video Engineer)と呼び、カメラと対になる受信端末はCCUと呼ばれる。セットでの導入が必要である。
そしてリモートで画質の調整をすることで、現場ではカメラワークとズームの管理に集中することができ、高品質の映像制作が可能となる。
また、映像・管理以外の信号のほかにインカム音声・タリー・電源もまとめて1つのケーブルで伝送することができるなど、ワークフローに配慮した仕様がある。

⇓システムカメラの例
https://www.ikegami.co.jp/archives/menu1/uhk430


【ENGカメラ】何でも撮れる

内蔵NDフィルタ・内蔵エクステンダー があることで、どのような環境でも適切な撮影が可能。
レンズにもよるが、近くの物撮りから、少し遠くを撮る取材などにも対応可能。現場で何があるかがわからないような場面において非常に適している。
そのほか、業界用の記録媒体への対応(XDCAMレコード機能)や、
端子の充実(SDI・XLRなどに標準対応)による色々な映像・音声機材と連携が容易であることなどが挙げられる。

⇓ENGカメラの例
https://www.sony.jp/xdcam/products/PDW-850/index.html

 

▲放送用機材のデメリット

高いことなどを除くと、センサーサイズが小さいことによる”ボケが弱い”ことがある。デメリットと思う人は業界には少ないが、最近は安いシネマカメラが出ているのでそのようなカメラを使うこともできるし、静止画用のスチールカメラで動画撮影をすることで、ボケがよく出た演出が多用される。一方日本の放送用機材はセンサーサイズが小さく、ボケを求めない方針にあることが多い。(テレビ局の海外支局の映像はボケが激しいことが多い..)

 

あと、民生用機材でもできることが多いのに、大げさなカメラを使うことは必要なのかという議論もある。民生用機材もだが、昨今では"iPhoneでいいのでは"、という話にもなってくる。現状に即した機材選択が大事である。

状態更新・状態遷移の難しさ

キャッシュでユーザーが損をする図

コンピュータのシステムの話で、単にキャッシュってめんどい、という話だが、情報科学を学んだときにあまり深刻に考えていなかったが重要な問題だと思うので述べる。

状態更新・状態遷移のシチュエーションと最新状態の参照について

データソースAと、Aを活用する(たとえば表示する)アプリケーションC
があり、ユーザーはCをある頻度で利用するとする。(たとえばツイートの蓄積されているサーバがAで、WEB版ツイッターのインターフェースがC)

もしいくらでもAへのアクセスが可能であれば、Cへのアクセスの度に随時Aへ取得リクエストをかければよい話だが、一般的にAは例えば外部のAPIであったり、DBサーバだったり、ファイルストアだったり計算サーバだったりする。はたして”いくらでもAへのアクセスが可能”だろうか。実はそのような場面は結構少ない。CとAが同じ物理サーバでかつ、参照コストがかからない(高速アクセス可能なローカルストレージを参照など)場合などであれば問題ないが、そうでない場合が多い。

 

そして至極当然のことだが、これらの対応のために、データソースAが返すべきレスポンスを蓄積して高速・低コストに返す「キャッシュB」が生まれることになる。キャッシュBを介すことで、大量アクセスに対応できたり高速にレスポンスできたり、そもそも静的に保存しているため計算コストが安く済むなどの利点がある。

 

しかし、キャッシュを導入するということは、キャッシュ保持時間=更新頻度というものがついて回る。つまり”常に最新の値を取得できる”ということが無くなり、情報最新性への妥協であったり、時差を考慮したシステムの開発が必要になる。

概念として、そして巨大サービスにおいてそのようなものがあるのは学生のころから知ってはいた(DNSWebブラウザのキャッシュなど)が、いざシステムを開発・運用するとなったときに、この問題は至る所で壁となる。

更新頻度≒更新遅延

一般的にデータの受け渡し・状態遷移の伝播は1段階ではない。多段階になり、そのホップ数が多いほど、更新頻度が低くなる。最新データの取得を希望する場合、更新遅延が長くなるともいえる。今回は主にこの、最新データの取得を希望する場合・リアルタイム性が求められるサービスをつくっている立場から述べる。


複数のホップ数があることをかみ砕くと、

1ホップ目、2ホップ目、の更新頻度がT1,T2,...Tn であった場合、最終的な最大の更新遅延はT1+T2+...+Tnとなる。最小の更新遅延は max(T1,T2,...,Tn)となり大したことないが、タイミングを正確に合わせない限り、最大の更新遅延を引くことは多々ある。ご覧の通りホップ数が増えるごとに最大の更新遅延はどんどん伸び、ユーザー体験は損なわれていく。(一方サーバ管理者はサーバ機能の細分化ができてうれしいことが多い)たとえば最新のニュース記事を見たいのに20分後にならないと見られない、というようなことが起きる。

 

どのような場合に、更新頻度が長くなるのか、いくつか例を挙げる。

例1 外部RSSを参照して、記事の情報を取得する

取得先RSSは静的なファイルではなく動的に生成する場合、レスポンスに時間がかかるし、何より先方のサーバに著しく負担をかけるためアクセス頻度を下げろという要求をされていることもある。
→更新遅延はあっても更新頻度は確保できる という場合もあるが、それすら妨げられる。→先方のシステムが悪いともいえる。

例2 自社の記事管理CMSから、最新の記事5件を取得する

コンテンツ蓄積とともにDBは肥大化していくことや、低頻度のアクセスを想定した廉価なクラウドサービスを利用していることが影響し、高頻度でのアクセスは避けたい・低廉な仮想サーバのためレスポンスに数秒かかることが多々ある。それらの理由からバッファをもって5分単位での更新にするなど。
→DBの設計の難しさの話と、オンプレ至上主義の話につながるが、現実的に出会うことの多い問題である。そして安易に5分単位で更新時間を決めることの是非も・・

例3 いわゆるふつうのCDN

CDNはキャッシュそのものであるから当然ではあるが、CDNを介したデータ取得ということは、TTLが決められており、その事前設定した時間だけ更新頻度が遅くなる。ただ、CDNを使う目的はあくまでアクセスの分散であるから、別に更新頻度を下げる・古い情報の露出を許容しているからというわけではない。
→例えば誤った情報の修正・ネガティブキャッシュの存在など、キャッシュ機能が運用の邪魔をすることがあり、その場合キャッシュの開放(パージ)や、インデックスファイルのみTTLを短くするなどの方法をとるが、リアルタイム性を求めるサービスとCDNの相性の悪さがあることは主張したい。

例4 大きなファイルを取得する・計算する必要がある場合

ちょっと毛色は違うが、大きなファイルを名前を変更せずに更新する事を考えると、リモートサーバから取得している途中はファイルとして破綻しているので、使い物にならない。なので最近のウェブブラウザの挙動でも見られるが、一時ファイルとして別名でダウンロードを行い、ファイル完成後にリネームを行い上書きすることが必要になる。ダウンロードにかかる時間が遅延時間に直結するのはもちろんのこと、この「ダウンロード中のアクセス」を正しく対応しなければ、システムのエラーにつながるのも注意したい。一方でサーバ(Linuxなど)の「リネーム」は”十分一瞬”に終了するからユーザーに影響を与えることはない、のは興味深い。”リネーム中にアクセスしたからファイル破損扱いになった!”ということは起きうるのかもしれないが、十分に無視できる事象といえる。


◆私の驚き

単に情報=データを”すぐに”別の場所=サーバから持ってくるというのがこんなにも困難なことだったのかということに驚く。そしてそれは世の中ほとんどすべてのサービスに影響するものになるから、もっとこれに関する学問やアーキテクチャの議論があっても良いのではと思う。いや、当然すでにあるのだろうけれども少なくとも学生の時にこんなこと考えもしなかった。

 

◆色々経験を経ての教訓

・システム(データフロー)をシンプルにすること。役割などの区別から、多段階での処理をしがちである。一般的に複雑な問題は分割せよと言われている。しかし更新遅延を考えるとそうも言ってられない。一番問題を簡単化するのは、データフローをシンプルにすること。

・あらゆる段階において高速なレスポンスを求めること。普通のサービスで異常が起きても無いのに数秒もかけてレスポンスしているのは異常だし、避けるべき。細かなアルゴリズムの工夫や無駄な処理の削減できることは多々ある。動画像処理やAIなどで計算時間がかかるものもあるが、かなり考慮したシステム設計が必要になる。

・キャッシュサーバの保持時間はあまやかしてはいけない
”キャッシュサーバだから保持時間が長いのは当然でしょ笑”というような甘えた設計では、多段階でデータの受け渡しをすることでかなりのボトルネックになってしまう場合がある。しっかりと処理能力を鑑みて、CPUにはがんばってもらって、できるだけ短い保持時間にするべきである。一見保持時間がいくら長くても良いだろうと思っていても、システムの遠いところで影響を与えることがある。

 

◆おわりに

かなり自分の関わっているプロダクト(コンテンツ管理とその表示WEBインターフェース、他社APIとの連携 など)を基準に偏った内容で、前提設定が足りない部分が多々あると思うが、具体例などはいくらでも出せるので、気になったことがあれば答えられる。

放送現場で使われる有線映像伝送方式・ケーブルの種類

4年半ほど働き、"相場"というものがわかってきて、そろそろ放送現場で使われている技術を語れるようになってきたので、今回、映像伝送方式についてまとめつつ紹介する。

無線・IPは今回含めない。前提として無線より圧倒的に有線のほうが安定するという考えのため有線接続は現場でもまだまだ多用される。IPは有線より方式が乱立しており、さらにIPネットワークの知識も必要で輻輳などの難度の高い障害対応が求められるため、特に流動性の高い映像現場においては有線接続がまだ幅を利かせている。

SDI (Serial Digital Interface)

THE 業界標準。なのにネット上に情報が少ない。

とにかく無劣化無圧縮な信号を銅線(*1同軸ケーブル)を用いて伝送する。

シンプルな接点が接触すれば映像が伝わるので、安定性が高い。加えて遅延もほぼ無く、伝送情報量が多くデジタルで劣化がない。何より100メートルほど伝送できるのでSDIで対応できない場面が少ない。超長距離伝送する場合を除いて、現場での利用率は圧倒的である。

SDIを乱雑に刺したスイッチャーの背面

解像度

規格によって周波数が違い伝送できる容量が異なる。地上波レベルはHD-SDIで伝送可能なので、HD-SDIが一番普及している。4Kを伝送するには12G-SDIが必要になる。

  •  HD-SDI 1.4Gbps の伝送帯域で、HD=1920x1080 を30フレームまで送れる。地上デジタル放送レベルではこれで十分。(地デジは*2 1440x1080 59.94i)
  •  3G-SDI 2.9Gbpsの伝送帯域で、HDを60フレームまで送れる。
  •  6G-SDI 5.9Gbpsの伝送帯域で、4K=3480x2160を30フレームまで送れる。
  •  12G-SDI 12Gbpsの伝送帯域で、4Kを60フレームまで送れる。(BS4K放送は60fpsが基本)

伝送距離

規格とケーブルの品質による(同軸ケーブルは大きく分けて3C・5C等があり、ケーブルの太さと取り回しやすさのトレードオフになっている)が、HD-SDIでは約110メートル程度、12G-SDIでは70メートル程度まで伝送できる。現場回りでの配線は問題ないが社屋の端まで引っ張るには足りないため、リピーター(リクロック)を介したり、あきらめて光ファイバーでの伝送で対応する。最近は基本的には室間は光ファイバーでの伝送をするのが吉(そうなると中身はIPになることもある)

端子

BNCが多く使われる。取り外しには回転が必要で外れにくく非常に便利。

もっと多く普及しているテレビアンテナ用のケーブルに使われるF端子がすべてBNCに入れ替わればよいと思う。

マイナーな端子として、コンパクトに端子を設置するためにDIN・mini-BNC・Micro BNCというものがある。DIN以外はめったに見かけない。

また、BNCの中でも圧着方法は多彩で、それぞれ細かく性能(周波数帯による伝送距離など)が異なる。

音声

無劣化で16チャンネルの音声を伝送可能。

5.1ch=6chの音声とステレオ音声を合わせて伝送できるため8chまでは使われることがあるということもあり、8chまではサポートする機材がある。

HDMI (High-Definition Multimedia Interface)

民生用機材において圧倒的な普及率を誇るため、無視できない規格。SDIとHDMIが混在することが多々あり、*3互いの変換がまた問題となる。

多くのバージョンが存在するため、高解像度の映像を扱う場合はケーブル選定に注意が必要。音声や制御信号も含み、これ1本で多くのことに対応可能できる。

欠点は伝送距離が短いことと、SDIに比べると仕様が複雑であること、何より端子が19ピン・外れやすいなどで安定性が低いことである。

民生用のため著作権保護(HDCP)機能や、機器間の認証・信号が規定されている。

解像度

スタンダードHDMIでは1080iまで、ハイスピードHDMIでは1080pまで、さらに4K・8Kと規格に応じて高解像度・HLGに対応可能となる。

伝送距離

一般的に5メートル以内とされるが、光ファイバーで数十メートルに延長する商品も存在する。

端子

HDMI-Aという一般的な形式に対して、Mini HDMIと呼ばれる HDMI-C端子、Micro HDMIと呼ばれる HDMI-D端子が存在する。小型カメラの多くはMicro HDMI端子を備えている。

いくつかの端子種類が存在するため煩雑なうえ、対応端子によってはさらに接合部が不安定であるので、より確実な接続ができるHDMI-A端子が歓迎される。

音声

仕様上は8chまで対応できるらしいが2chまで対応する機材しかほとんどない。

光カメラケーブル(多治見・LEMO)

完全に業務用。電源やインカム、システムカメラの映像伝送に用いられる。電源・制御は銅線で、映像は光ファイバーで伝送する。各2本ずつ合計6本が束ねられており、このケーブル1本があればすべてが完結する。

200メートル以上は伝送でき、スタジオのシステムカメラとしてはもちろん、中継現場などで多く用いられる。接続部に光端子(フェルール面)があるため微小な汚れでも伝送に障害が発生する。

光カメラケーブルの端子 カナレ社ウェブサイトより https://www.canare.co.jp/products/fiber_optic_systems/index.php?tid=1_015

その他

放送業界では基本的には使われないがまだまだ存在する。

UVC(USB Video Class)

USBで映像を伝送する規格。もともとはWebカメラからPCに映像を送るためのものだったが、仮想WEBカメラ的に映像をPCに送るために、上記の映像規格をUVCでPCに入力する需要が増えており、変換コネクタが多く販売されている。

多くのブラウザや一般的なアプリケーションで扱うことができるため汎用性は高い。フォーマットはMJPEGが基本だがサポートされるフォーマットも増えている。

映像と音声が異なる仕組みで入ってくるため絵と音がずれることが多い。

音声はUSB Audio Class(USB Audio Class)。

DVI (DVI-D DVI-I DVI-A)

18-24のピンを用いて映像を伝送する。PCモニターでよく利用される。

フルHDから4Kまで対応できるが、アナログ信号も使うことがあり、互換性のため様々な端子がある。基本的にはDVI-Dを想定していればよい。音声は通さない。

Display Port (Thunderbolt) 

8KまでのPCの様々な解像度に対応する。伝送距離が短い。音声は伝送できる。

HDMIと同じくバージョンが多数あり、ケーブルの選定が難しい。Thunderbolt端子がカバーするプロトコルにも含まれる。昨今のThunderbolt4対応のUSB Type-Cケーブル周りで普及が進んでいる。

VGA(D-SUB・RGB)

古いコンピュータはだいたい対応している、世の中で一番普及している映像ケーブル。15ピンの端子で 2048x1152 (フルHDよりちょっと大きいのでモニタとしては十分)まで表示できる。しかしアナログ。音声は伝送できない。

 

 

使わないので説明を省略

コンポジット S端子RCA

SD画質までしか対応していない(規格が作られていない)ため、ほとんど見かけないが、端子がついているモニタなどは多い。余った端子を有効活用したいときには考えるがSD画質なので萎える。

コンポーネント端子 D端子(D1~D5)

D5はフルHDを伝送できるため一部現場で見かけることもある。端子などの機材がまったく存在しないので触ることはない。

*1:特性インピーダンスが75Ωの同軸ケーブル

*2:インタレースで59.94回/秒画面が更新されるということ。フレームレートでいうと29.97fps。送出前までは1920x1080ピクセルで管理されているが地デジ形式にエンコードする際にピクセルアスペクト比を横方向に膨らませて1440x1080ピクセルにすることでデータ容量を節約している。

*3:特にSDIの世界で多用されるインターレースからプログレッシブへの変換がうまくいく機材は限られており、インタレース規格を維持した過去の偉人への憤りは甚だしい。

動画ビットレート感覚

動画のビットレートは、動画視聴環境・満足度に大きく影響するものの、評価軸が画質となるため主観で判断するしかなく、それ故あまり語られることが少ない。

テレビのマスター機器の設定は地デジの仕様・MPEG2ノウハウの不足があり頻繁に変えられないことから難しいが、動画配信となるとH264であるし、しがらみもなく、ビットレートを任意に定めることができる。ただし、映像素材品質・映像素材種類・配信環境・エンコーダ圧縮性能・解像度・受信環境・求められる安定性をもとに適切なものを選ばなければならない。結局のところは自分の”ビットレート感覚”に頼らざるを得ない。

世の中のビットレート

 まずは、世の中で流れている動画ビットレートの相場を知るべきである。ということで調べた世の中のビットレート(自分・拾ってきたもの)を以下羅列する。

実測:地上波TS MPEG2


BS11 18Mbps MAX 22Mbps
BS民放系 13Mbps MAX 15Mbps
BSプレミアム 15Mbps MAX 18Mbps
地デジ本放送 13Mbps MAX 16Mbps
地デジカラーバー 2.4Mbps
地デジムービングカラーバー 5.5Mbps 

参考:BS4K・8K HEVC(H.265)


4K MAX 30Mbps
8K MAX 100Mbps

動画ウェブ配信 H.264 fullHD 30f

YouTube 9Mbps

Amazo Prime 16Mbps

ベースバンド

HDMI 60p 3.2Gbps
HD-SDI 60i 1.4835Gbps

 自分のビットレート感覚は

HLSの技術的問題は別途述べるとして、基本的にはビットレートは低いに越したことはない。

ちなみに今自分の設定するH264 720p30F の配信サービスにおいては、QVBRでMAX 500kbps 1.5Mbps 2Mbps の3ストリームとしている。

主観ではあるが、2Mbpsほどあれば動きが相当激しくなければ十分の地デジを上回る画質となり十分であると考える。つまりは地デジレベルを目指さなければ1.5Mbpsくらいで充分。

(もし10Mbpsくらいで投げられれるならば、最高の画質になりそう)

これはエンコーダの品質が優れているからであって、市販のエンコーダやPCでの配信(OBSなど)では、同等の画質を再現するには+1Mbpsほど必要であると思われる。

 

受信環境の話

いわゆる”ギガ”の消費のためには低ければ低いほどいいが、一番重要なのは、動画が停止しないこと、バッファ状態にならないことである。実際の状況を想定すると、4G回線の非CA状態であれば10Mbps以上出る。ただし昼12時台や夕方18時台の混雑時間帯には2,3Mbpsくらいになることは想定され、さらに格安SIMの状況や通信制限状態(128kbps)もありうる。流石に128kbpsは無理なので、格安SIMが時間帯によっては際限なくスピードが落ちることを想定すると、500kbpsやそれより低いビットレートを用意することは重要と思える。さらに、そこまで基準を下げておけば、残念なWi-Fi環境などにおいても役立ちそうである。

今後の課題

先に挙げたビットレートを定めるための条件を改めてみて、まだ自分の中でさっぱり解決できていないこととしては、エンコーダ圧縮性能・画質の定量評価、解像度とビットレートの関係がある。画質の定量評価は、永遠の悩みだとはおもうが、解像度とビットレートの関係(同じ1.5Mbpsで360pと720pではどちらがいいのか、など)は、動画を見る画面の大きさにも依存するところがあり、まだ答えが出ていない。

広島テレビ新社屋移転STL切替

2018年9月23日早朝 広島テレビの新社屋移転に伴うSTL切替の放送休止の記録を記す。

 

0時50分 最終番組GOINGが終了

CM等のあと、移転の旨のトリキリ画面

f:id:nbter:20180923225034j:image

その後、シンプルなカラーバー画面に。

f:id:nbter:20180923225148j:image

1時2分放送波停止し、テレビも放送波が来ていない表示に

 

数時間後、新しい、ロゴ入りのカラーバーが映った。

f:id:nbter:20180923225256j:image

放送開始6時の直前に、ネットマークになる。

f:id:nbter:20180923225434j:image

6時より、特別番組で新社屋からの放送が開始した。EPG画像や、右上局ロゴは変更がなかった。

WAVEファイルとラジオ 概要

Waveファイル、拡張子でいうと.wavは、PCM(パスル符号変調)でアナログ音声を最も単純にデジタル化した無圧縮音声ファイル形式であるので、今の時代において一般的には、”ただの音質が最高に良いファイル形式”という認識を持つ人が多くなっていると思う。

一方放送局では、テレビはさておき、ラジオではWaveのまま放送波に乗り、聴取者に届くため、常用するファイル形式である。そして放送に利用する上で必要な機能であるタイムコードやCue信号などを付加するBWFという拡張形式も存在し、実は奥の深いファイル形式でもある。

BWF

1997年にEBU (欧州放送連合)が仕様策定したこともあり、放送業界独自の技術と言って過言でない。また日本独自にBWF-Jという拡張形式も存在する。民放連の定めるラジオCM素材搬入基準は、BWF-Jである。

EBUによるBWFのドキュメント| https://tech.ebu.ch/docs/tech/tech3285.pdf

JPPAによるBWF-Jのドキュメント| http://www.jppanet.or.jp/bwf-j/jppa-1-2009_bwf-j_audio_file_format.pdf

放送に携わる皆さまへ | 一般社団法人 日本民間放送連盟

2GBの壁

4GBの壁とも呼ばれるが、Waveは32ビット記述をされており、ヘッダ内にファイルサイズを示す部分があるため、32ビットで示せないファイルサイズになることができない。符号ありの整数として解釈されることも多く、その場合2GB程度までが限界となる。Waveはビットレートとサンプリングレートを自由に決めることができるが、一般的なレートにおいては、数時間の音声で2GBに達してしまう。よって限界を超える長時間番組をファイル化することが本来できないが、BWFにより、複数ファイルを同一音声として扱うことで対応する。またWAVE64という64ビットバージョンのファイル形式も存在し、問題は解決することができる。

WAVと32bitの壁 | Harmonic-Sound

 

今後、Waveのヘッダや、BWF(BWF-J)によるファイル構造の違いを調べ、いじっていきたい。

放送技術とIT

この4月より社会人となり、同時に放送業界に関わることになった。

今まで情報科学を専攻し、趣味でもウェブ系とか、仮想化、ネットワーク系に主に触れてきた。

覚悟していた通り放送技術は本当に特殊で苦労する一方、学んできた技術・知っている知識との関わりを面白いと感じることも多い。

そこで、普通のIT好きの目線で、知名度の低い放送技術を少しずつ解説していきたい。