未分類」カテゴリーアーカイブ

接尾辞の ‘-ship’ は船の意味ではない

会社員向け研修で講師がアカデミックなことをしゃべり出したら、まず真偽を疑った方がいい。

skinship, internshipなどの接尾辞 ‘-ship’ の語源が船のshipなはずがないことは直感的に分かる。まして「船が港Aから港Bへ人を運ぶことから、人と人の間や関係性を意味する接尾辞」というのは完全に誤りだ。

念のため語源辞典で調べてみる。

https://www.etymonline.com/word/-ship

意味は「品質、条件、行為、力量、技能、事務所、地位、~との関係」など。中英語の ‘-schipe’、古英語の ‘-sciepe’ 、アングル語の ‘-scip’ が語源で、これらは「状態、存在の状態」を意味し、ゲルマン祖語では ‘-skepi-‘ とある。インド・ヨーロッパ祖語までさかのぼると ‘(s)kep’ で、「切る、皮をそぐ、たたき切る」などから ‘shape’ 、つまり「形づくる、創造する」の原義を持つらしい。

一方、船の意味の ‘ship’ の語源は古英語で ‘scip’ 、ゲルマン祖語で ‘skipa-‘、いずれも最初から船、ボートの意味で、もともと「切り出された木、中が空洞になった木」。「切る、裂く」の原義があり、接頭辞 ‘schizo-‘ と同じ語源までたどれるとする説もあるようだ。

接尾辞の ‘-ship’ が「形づくる (shape)、創造する (create)」という意味で木を切る、皮をそぐ、たたき切るのに対し、船の ‘ship’ は同じ木の加工でも「切り裂く (split)」方の意味。かつて精神分裂症と訳されていた ‘schizophrenia’ (統合失調症)の接頭辞 ‘schizo-‘ につながるのはうなずける。

https://www.etymonline.com/word/ship

つまり接尾辞の ‘-ship’ と船の ‘ship’ は無関係どころか、ほぼ反対の原義をもつことになる。

接尾辞の ‘-ship’ は何かを創り出す条件や性質のこと、たとえば leadership なら leader を leader たらしめる条件や性質、sportsmanship なら sportsman を sportsman たらしめる条件や性質を意味していると考えると、なるほどと思える。

高校時代にハイデガーを読んで、やたらと言葉の語源にこだわる。そんな会社員が日本にそう多くないことは分かっているし、いちいちそんな会社員がいることを前提に講師が話す必要もないと思う。

ただ、会社員向けの研修を受けていると、講師が無理をしてアカデミックなことを話して墓穴を掘る場面に出くわし、聴いているこちらが気まずくなることがままあり、悲しい。

中国式QRコード決済について(1):不便さこそが取引を安定させる

たまたま中国のQRコード決済にかんする書き物にTwitterでツッコミを入れる機会があったので、筆者の考えをまとめておく。

送金は「決済スキーム」と「送金スキーム」の部品にすぎない

ツッコミを入れたのはこちらの記事。

『QRコード”送金”が推進した中国のキャッシュレス事情』(2019/04/02)

決済と送金、「この両者はスキームがまったく異なります」としている。

「取引の当事者以外に債権を引き受ける人(会社)が必要になる」ことで、「決済事業者の理解をとりつけることが商売の壁になってはいけません」としている。

しかし送金のスキームに取引の当事者以外に債権を引き受ける人は必要ない、というのは端的に間違っている。

それが間違いである第一の理由は、送金は単に「決済のスキーム」と「送金のスキーム」の両方を構成する部品に過ぎず、「送金のスキーム」にも取引の当事者以外の人が必要だからだ。

第二の理由は、決済事業者の理解を取り付けるという壁、つまり、決済にかかわる一見ムダと思われるコストが発生するからこそ、あらゆる取引と決済の基礎になる金融システムが安定するからだ。

以下、この点を説明してみる。

まず取引とは、有形のモノ、無形の情報を、お金(貨幣)に換算して交換することだ。

この記事の「決済のスキーム」「送金のスキーム」では情報の流れが無視されているので、それを補ってみる。

わざわざ情報の流れを付け加える理由は、取引を成り立たせるのに必要不可欠な「信用」が情報のやりとりだからだ

【決済のスキーム】
(1)顧客は店舗に、モノを購入しますという情報を送る。
(2)店舗はクレジットカード会社に、顧客から注文を受けたという情報を送る。
(3)クレジットカード会社は店舗に、モノの価値相当の貨幣を送る。
(4)店舗は顧客に、モノを送る。
(5)店舗はクレジットカード会社に、モノを発送したという情報を送る。
(6)顧客は店舗とクレジットカード会社に、モノを受け取ったという情報を送る。
(7)顧客はクレジットカード会社に、モノの価値相当の貨幣を送る。

このうち(3)(7)が送金で、(5)がモノの発送、その他は情報の送信だ。

債権は(2)で店舗がクレジットカード会社に送信する情報の中身のことである。顧客が店舗にいくらの借りがあるかという情報だ。

このように送金は「決済のスキーム」の部品、(3)と(7)にすぎない。

一方、上の記事で「送金のスキーム」とされるものは以下のとおり。

「決済のスキーム」と比べやすいように、番号はそのままにする。

【送金のスキーム】
(1)顧客は店舗に、モノを購入しますという情報を送る。
(2)なし
(3)顧客は店舗に、モノの価値相当の貨幣を送る。
(4)店舗は顧客に、モノを送る。
(5)なし
(6)顧客は店舗に、モノを受け取ったという情報を送る。(必須ではない)
(7)なし

このうち(3)が送金で、(5)がモノの発送、その他は情報の送受信だ。

どちらも、お金を送る、情報を送る、モノを送るの3つの要素からなり、本質的に違いはない。

ここで債権は(1)で顧客が店舗に自ら送信する情報の中身のことだ。

スキームの信用は金融機関が裏付けになっている

じつは上記の2つのスキームでは、重要な関係者が無視されている。それは銀行や郵便局など、主に現金を管理する金融機関だ。

【決済のスキーム】
(1)顧客は店舗に、モノを購入しますという情報を送る。
(2)店舗はクレジットカード会社に、顧客から注文を受けたという情報を送る。
(3-1)クレジットカード会社は店舗の現金管理者(銀行など)に、モノの価値相当の貨幣を送る。
(3-2)店舗の現金管理者は店舗に、いつでも現金を手渡せるようにする。
(4)店舗は顧客に、モノを送る。
(5)店舗はクレジットカード会社に、モノを発送したという情報を送る。
(6)顧客は店舗とクレジットカード会社に、モノを受け取ったという情報を送る。
(7ー1)顧客はクレジットカード会社の現金管理者(銀行など)に、モノの価値相当の貨幣を送る。
(7ー2)クレジットカード会社の所有現金の管理者はクレジットカード会社に、いつでも現金を手渡せるようにする。

先ほど債権が発生するのは(2)の情報送信だと書いたが、この情報が正しく管理されないと正しい取引が成立しない。

そして新たに登場した銀行は、店舗や顧客の現金を管理している。現金が正しく管理されないと正しい取引が成立しない。

クレジットカード会社が債権という情報を、銀行が現金を正しく管理するからこそ、顧客と店舗は安心して決済できる。決済のスキーム全体に対する信用が生まれる。

そして情報の管理、現金の管理には当然コストが発生する。人や情報システムの運用などなど。

そのコストはクレジットカード会社の決済手数料や、銀行の送金・振込手数料として、顧客と店舗が負担する。これは信用の対価だ。信用はタダではない。

【送金のスキーム】
(1)顧客は店舗に、モノを購入しますという情報を送る。
(2)なし
(3ー1)顧客は店舗の現金管理者(銀行など)に、モノの価値相当の貨幣を送る。
(3ー2)店舗の現金管理者は店舗に、いつでも現金を手渡せるようにする。
(4)店舗は顧客に、モノを送る。
(5)なし
(6)顧客は店舗に、モノを受け取ったという情報を送る。
(7)なし

送金のスキームではクレジットカード会社の代わりに、顧客と店舗が自己責任で情報を管理する。

コストをかけて信用を与えてくれる第三者がいないため、顧客と店舗は一対一でだまし合うこともできる。

ただ、現金を管理する銀行はやはり必須だ。現金を手渡しするにしても、全財産をタンス預金にしない限り、取引の準備として銀行に現金の管理を任せることになる。

現金の管理には当然コストが発生する。そのコストは銀行の送金・振込手数料として、顧客か店舗が負担する。これも取引全体の信用を保つための対価だ。信用はタダではない。

そして中国のQRコードによる送金の場合、支付宝やWeChat Payが銀行の役割をはたす。(以下支付宝で代表させる)

「いや、支付宝は銀行口座とひもづける必要があるので現金を管理するのはやはり銀行だ」という反論がありそうだ。

その反論を受け入れるとすれば、支付宝は現金ではなく債権の情報を正しく管理する必要がある。これはクレジットカード会社と同じ役割だ。すると「送金のスキーム」ではなく「決済のスキーム」になってしまう。

だが重要なのは「決済のスキーム」なのか「送金のスキーム」なのかではない。

重要なのは、銀行や郵便局と同じくらい支付宝を信用できるか、できるとしてその信用のコストを誰が負担するのかという点だ。

たとえば銀行のシステムがたびたび不具合で停止するとか、不正アクセスを受けて残高が消えるとか、職員が不正をはたらいて金をくすねるとか・・・。

これでは銀行の信用が成り立たず、決済のスキームも送金のスキームも成立しない。信用はタダではない。

その信用を支えているのは、金融機関を厳しく規制する法律である。厳しい規制をクリアするために、銀行は多額の投資をしてシステムや職員の品質を維持している。

クレジットカード会社も厳しい法規制をクリアすることで正しく情報を管理し、社会的信用を保つことができている。

銀行やクレジットカード会社がコストをかけて社会的信用を維持することで、初めて顧客と店舗は安心して取引ができる。

信用のコストは必ず誰かが負担している

何度でもくり返すが、信用はタダではない。

銀行やクレジットカード会社の場合、顧客や店舗が自ら手数料でそのコストの一部を負担している。

では銀行やクレジットカード会社ほど厳しい規制を受けない支付宝を、どうやって信用すればいいのだろうか。

支付宝はユーザの残高(または残高情報)が突然ゼロになったりしないように、社員がシステムを不正操作して金をくすねたりしないように、十分な投資をしているだろうか。

法的規制なしに誰がそれを保証してくれるのだろうか。

日本のQRコード決済事業者は、顧客向けにも、店舗向けにも、手数料が低いことを売りにしているが、では正しく情報や現金を管理することを保証するコストは、誰が負担しているのか。

事業者が赤字覚悟で手数料を下げているなら、そもそも事業を継続できるのだろうか。

ある日突然QRコード決済事業を停止され、現金として引き出せないとなれば、文字どおり元も子もない。

サービス開始当初こそ、派手なキャンペーンで一部の顧客や店舗は食いつくだろう。

しかし、長期的に安定した社会インフラとして定着するためには、長期的な人やシステムへの投資が必要になり、そのコストは決済サービスの利用者、つまり顧客、店舗がいずれ負担せざるを得なくなる。

非効率さこそ金融システムを安定させる

つまり、冒頭の記事の主張とは逆で、「お金を受け取ることに壁をつくる」からこそ、すべての経済的な取引が成立している。

情報やお金を正しく管理すべき事業者が法的規制を受け、コストを負担する必要があるからこそ、事業者の社会的信用が担保される。

そのコストは顧客や店舗が負担せざるを得ない。信用はタダではないから。

日本はよく現金主義だと言われるが、それは多くの日本人がクレジットカード会社さえ信用していないことになる。

これは、日本では社会的信用の値段が高いということだ。逆の言い方をすれば、手数料というコストを負担してでも安全な取引をしたい社会、ということになる。

決済事業者は「エッチな本を描いて誰かに売る」ような、不健全な取引を拒否するかもしれない。それは機会損失というコストをかけて、社会的信用を維持しているに過ぎない。

ヘンな取引の決済に手を貸す決済事業者は、社会的信用を失うからだ。

このように日本社会では「信用の値段」が高いため、QRコード決済事業者のようなゆるい規制しか受けない事業者がかんたんに信用されないのは言うまでもない。

決済事業者が一万円札で折った折り紙の取引は拒否したのは、その機会損失が社会的信用のために負担すべきコストより小さいからだ。

くり返しになるが、取引を成立させる基盤になる社会的信用のコストはタダではない。誰かが負担しなければならない。

したがって、「送金の手数料で稼ぐビジネスモデルは早々に崩壊する」ということは絶対にない。

送金の手数料こそ、ビジネスを成立させる基盤となる社会的信用の原資だからだ。

「もし銀行が高い手数料をとりつづけたとすれば、ユーザーの資金はあっという間にスマホのウォレットアプリに移されてしまうでしょう」ということも、絶対に起こらない。

仮に人々が銀行の手数料負担を避けるために、ほんとうにQRコード決済事業者に自分の貯金・預金をごっそり移せば、一国の金融システム全体が危機におちいる。

あらゆる事業者の資金繰りが悪化し、QRコード事業者も信用を受けられず、経営状況はまたたく間に悪化する。

金融システムは法規制によってある程度非効率だからこそ、社会的な信用によって維持され、安定している。

規制によって手数料というマイナスのインセンティブが働き、大量の資金の短期的な移動が防げる。

そのおかげで金融システム全体が安定し、その信用が保たれ、あらゆる取引を安心して行うことができる。もちろんこれは日本に限ったことではない。

このことを理解していないとすれば、経済の基礎を理解していないとしか言いようがない。

(なお当然だが、中国人もAliPayやWeChat Payに移しているのは手持ち現金の一部だけだ。かつ、現金を移動するそのインセンティブになっているのは、利便性以外にも、高い利子がつく理財商品がある。ただ、投資リスクが高いため、さすがに中国政府も規制を強め始めているようだ。なぜか。金融システム全体の信用がゆらぎかねないからだ。その信用のコストをそろそろ事業者に負担させようということだ)

これで上記の記事が根本的なところで誤っていることを説明できたと思う。

法的規制という不便さ、非効率性によってはじめて一国の金融システムは安定化し、あらゆる決済の信用が担保される。

規制をなくせばみんなが幸せになるといった、ネオリベラリズム的ユートピアは、地球上のどこにも存在しない。

欧州議会による日本のGDPR十分性認定草案に対するEDPB(欧州データ保護会議)意見書

2018/12/05にEDPB(欧州データ保護会議)がGDPRに関するEC(欧州議会)の日本の十分性認定についての意見書を公開した。41ページにわたる詳細な意見書で、すべて紹介するのは難しいので「EXECUTIVE SUMMARY」の部分だけ要約してみたい。

まず確認しておくべきはEDPBがどれだけECの十分性認定草案に意見をつけても、認定取消になることはないという点だ。改善すべき点が少なくないという意見書であり、十分性認定に反対するという意見書ではない。

では「EXECUTIVE SUMMARY」だけでも全242項目のうち30項目あるが、一つずつ見ていく。

1. 欧州議会が2018/09/05の十分性認定実施の正式な手続きを開始した。

2. 欧州議会が2018/09/25にEDPBに意見を求め、関連資料をEDPBに提出した。

3. 欧州議会がEDPBとの議論の結果、十分性認定草案を2回書き直し、2018/11/13最終版をEDPBに送付、この最終草案に対する意見書である。

4. EDPBが欧州議会の十分性認定の保護レベルにつき分析、検討を行った。
5. EDPBは十分性認定草案の商業的側面、行政的側面の両方を調査、日本の法的枠組みでの個人データ保護の有効性を評価した。

6. EDPBは2018/02の旧第29条作業部会(W29)の十分性認定に関する参照資料を主に参照した。

7. EDPBは日本の法的枠組みが欧州データ保護法制をコピーすることを期待していない。

8. しかし、個人データの正確性、収集データの最少化、保存期間の制限、データのセキュリティ、利用目的の制限、独立した監督機関である個人情報保護委員会など、主要な点でGDPRの原理原則との一致を求める。

9. 加えて、EDPBは日本が追加の補完的ルールによりギャップを埋めている努力を歓迎する。

10. EDPBは欧州議会がEDPBの懸念に応えて十分性認定の決定を強化している努力を歓迎する。

ここまでは事実の確認。いよいよここからがEDPBの意見になる。

全般的な課題

11. しかしながら、EDPBは日本の法体系において以下の重要な領域を強化し、注意深くモニタリングするよう提案する。
12. 第一の課題:既存の法的枠組みに対する「補完的ルール」という、十分性の新たな建付けで、具体的で有効な法執行の問題を生じないことを保証する必要がある。(要は、個人情報保護法そのものを改正するのでなく「補完的ルール」という対応で大丈夫か?ということ)
13. 第二の課題:EDPBは「補完的ルール」の法的強制力について欧州議会と日本は継続してモニタリングするよう繰り返し求めている。

商業利用に特化した課題

14. 十分性合意の商業的側面でEDPBは特定の懸念を持っており、説明を求めたい。

15. EDPBは「補完的ルール」が、APEC越境プライバシールールシステムによるEU個人データの第三国へのさらなる移転を除外していることを歓迎する。

16. 日本の法制度では、第三国への個人情報移転の法的基礎の一つは、日本の保護レベルを十分満たしていることとしているが、第三国の保護レベル評価の際に「補完的ルール」が含まれていないように見える。したがって日本に移転されたEU個人データが、さらに第三国へ移転される場合は、GDPRのデータ保護枠組みと同等とみなすことはできない。

17. 日本からさらに第三国へ移転される場合、EUの個人データ保護レベルが保証されるかどうかのモニタリングは欧州議会が代わって行うべきである。

18. さらに、同意と義務の透明性に懸念がある。日本の法制度でのデータ主体の同意は、同意取り下げの権利を含んでいない。また、データ主体に事前に情報提供がなされるか疑念がある。

19. 日本の補償システムはEUのデータ主体にとって容易にアクセスできるものではない。ヘルプラインは日本語しかない。個人情報法語委員会のウェブサイトの仲裁サービスの情報も英語版がない。FAQなど重要な情報も日本語しかない。EU域内のデータ主体には少なくとも英語のオンラインサービスがあるべき。

20. EDPBは十分性認定の草案のいくつかの点につきさらなる説明による確証を歓迎する。

21. 例えば、GDPRではデータ処理者の一つとみなされる「委託先(trustee)」が個人データ処理の目的や手段を決定、変更できるのか、あいまいである。

22. 民主主義社会においてデータ主体の権利(アクセス権、修正権、拒否権)の制限の必要性と、基本的人権の本質を尊重しているのかどうかに関する文書が不足している。

23. EUに移転された欧州個人データは、日本の法制度では3年間の記録義務を課しているが、「ライフサイクル」全体を通して有効な保護を受けられるのか、欧州議会が注意深くモニタリングするよう期待している。

行政機関によるEU個人データへのアクセスについての課題

24. 法執行や国家安全保障に関するEU個人データの取扱いについて、EDPBは追加説明を求める。

25. 法執行の分野では、EUのルールと同等のように見えるが、いくつかの法律や判例の翻訳が存在しないため、EU法と「本質的に等価」かどうか結論付けられない。

26. 国家安全保障の分野では、日本政府は自由にアクセス可能な情報源、または企業による自発的な情報開示を通じてのみ個人情報を入手するとしているが、EDPBは専門家やメディアがそれに対して懸念を示していることを知っている。行政機関による監督方法についてさらなる説明を歓迎する。

27. データ主体に対する補償方法について日本政府が追加したメカニズムを歓迎するが、新たなメカニズムが日本法における監督や補償の不足を完全に補っていない点を懸念している。新たなメカニズムがその不足を完全に補うよう、さらなる説明を歓迎する。

28. EDPBは今回の十分性認定がGDPR施行後初であり、今後の前例となる点を重視している。EU日本間の十分性認定による保護に何ら不足が無いよう、欧州議会は確保する必要がある。

29. 「補完的ルール」によってなされた改善は重要である。

30. しかしながら、欧州議会の十分性認定と日本の個人データ保護の枠組みについて、EDPBは少なくない懸念を持っており、さらなる説明が必要である。既存の国内法の枠組みに、限定的な規則を追加するという方式にも、法運用上の疑問がある。EDPBは欧州議会にこれら懸念に対するさらなる説明とエビデンスを要求する。また欧州議会が現行の十分性認定の草案にある4年に1回ではなく、2年に1回のレビューを実施するよう求める。

以上が「EXECUTIVE SUMMARY」の部分の要約である。

要するにEDPB(欧州データ保護会議)は以下のような点についてさらなる説明と対応を求めている。

・既存の法制度に対する「補完的ルール」という建付けで、本当に法的な実効性を担保できるのか?
・行政による法執行や国家安全保障に関して、本当に個人の基本的人権をベースにした個人データ保護は担保されるのか?
・少なくとも英語で、必要情報の入手や手続きができるようにすべき。

個人的には、2019/02に日欧EPAが発効する可能性が高いとされているので、同じタイミングで2年に1回のレビューという条件付きでEDPBも十分性認定草案の正式に採択するのではないかと思う。

OBS Studioでニコニコ生放送をするときマイクの音声にエフェクトをかける方法

自分のメモ代わりの記事。

OBS Studioを使ってPCの画面キャプチャと音声と、マイクからの音声入力をミックスして配信するとき、マイクからの入力音声にエフェクトをかける方法。

前提としてYAMAHAのミキサーAG03/AG06がセッティング済みとする。AG03/AG06のようなミキサーがなくても、PCのサウンドカードとは別モノとして認識される音声入力デバイスなら何でもよい。

OBS Studioでニコニコ生放送をするためのプラグインも導入済みとする。

OBS Studio公式サイト

OBS Studio ニコニコ生放送プラグインのインストール方法

次に、マイクからの入力音声を出力する先を「ライン(AG06/AG03)」ではなく、仮想オーディオデバイスにする必要があるので、何らかの仮想オーディオデバイス・ドライバをインストールする。

「NETDUETTO」というアプリケーションに付属する「Yamaha NETDUETTO Driver(WDM)」を利用する方法もあるが、わざわざ仮想オーディオデバイス・ドライバをインストールするだけのためにアプリを入れたくない、という人もいるはず。

なので純粋に仮想オーディオデバイス・ドライバだけをインストールする。

こちらの「VB-CABLE Virtual Audio Device」

英語サイトだが、DOWNLOADボタンをクリックしてZIPファイルをダウンロード、適当な場所に解凍。

32bit環境であればその中にある「VBCABLE_Setup.exe」を、Windows 10なら64bitなので「VBCABLE_Setup_x64.exe」を右クリックし「管理者として実行」をクリックし、インストールする。

「VB-Cable」というやや派手なインストーラー画面が出てくるが「Install」をクリックするだけ。PCの再起動が必要なので、再起動すると、仮想オーディオデバイスが有効になる。

Windowsのサウンド設定そのものは、再生、録音とも「ライン AG06/AG03」でよい。

ミキサーAG06/AG03上では「HEADSET」のマイク入力、ヘッドホン出力に、PC用のヘッドセットのマイク、ヘッドホンプラグをそれぞれ差しておく。(USBでPCと接続するヘッドセットは使えない)

同ミキサー上で「TO PC」は「INPUT MIX」にしておく。OBS StudioでPCの音声とAG06/03から入力されたマイクの音声がMIXされて配信されるので、ここで「LOOPBACK」にしてはいけない。

次にOBS Studioのメニューの「ファイル」>「設定」>「音声」の設定。

「デスクトップ音声デバイス」は「既定」、つまりWindowsの設定を同じにする。
「マイク音声デバイス」は「CABLE Output (VB-Audio Virtual Cable)」に変更する。ここがポイント。

そしてメニューの「編集」>「オーディオの詳細プロパティ」の設定。

「マイク」の「音声モニタリング」は、「モニターと出力」にしてはいけない。ここがポイント。

「モニターと出力」にすると、加工前と加工後のマイクからの入力音声が両方とも配信されてしまう。

加工前の音声だけで良ければ「モニターオフ」、加工後のマイクからの入力音声を確認したければ「モニターのみ(出力はミュート)」にする。

「デスクトップ音声」の「音声モニタリング」は「モニターオフ」。PC音声はAG06/AG03経由で戻ってくるので、ここでモニターする必要はない。

次に、マイクからの入力音声にエフェクトをかける任意のアプリの設定をする。

「録音デバイス(Input)」は「ライン (AG06/AG03)」にする。PCの音声ではなく、マイクからの入力音声「だけ」にエフェクトをかけたいからだ。ここでPCのサウンドカードを指定すると、PCの音声にエフェクトがかかってしまう。

「再生デバイス(Output)」は「CABLE Input (VB-Audio Virtual Cable)」に変更する。ここがポイント。

こうすれば、先ほどAG06/AG03上で「INPUT MIX」にしておいたので、AG06/AG03に接続されたマイクからの入力音声だけがエフェクト・アプリに入力される。AG06/AG03上で「LOOPBACK」にしてしまうと、PCの音声までエフェクト・アプリに入ってしまうので、マイク入力を含めたすべての音声にエフェクトがかかってしまってダメになる。

エフェクト・アプリの以上の設定で、エフェクトを・アプリの出力が、仮想オーディオデバイス「VB-Audio Virtual Cable」を通ってOBS Studioの「マイク音声デバイス」へ入っていくことになる。

つまり、物理的なマイクからOBS Studioの「マイク音声デバイス」に入るまでの経路は以下のとおり。

物理的なマイク
⇒ AG06/AG03 (INPUT MIXモード)
⇒ PCの「録音デバイス」の「ライン AG06/AG03」
⇒ エフェクト・アプリの「録音デバイス(Input)」の「ライン AG06/AG03」
⇒ エフェクト・アプリの「再生デバイス(Output)」の「CABLE Input (VB-Audio Virtual Cable)」
⇒ 仮想オーディオデバイス内部で「Input」から「Output」へ通過
⇒ OBS Studioの「マイク音声デバイス」の「CABLE Output (VB-Audio Virtual Cable)」

AG06/AG03のようなミキサーではなく、外付けのオーディオデバイスの場合も同じ流れ。

物理的なマイク
⇒ 外付けのオーディオデバイスの入力
⇒ PCの「録音デバイス」の外付けオーディオデバイス
⇒ エフェクト・アプリの「録音デバイス(Input)」の外付けオーディオデバイス
⇒ エフェクト・アプリの「再生デバイス(Output)」の「CABLE Input (VB-Audio Virtual Cable)」
⇒ 仮想オーディオデバイス内部で「Input」から「Output」へ通過
⇒ OBS Studioの「マイク音声デバイス」の「CABLE Output (VB-Audio Virtual Cable)」

どちらにしてもPCのサウンドカードから出力される音声で、最終的な出力は確認できないため、OBS Studioの録画機能で少し録画してみて、想定どおりにエフェクト付きマイク入力音声と、PC音声が出力されていることを確認する。

PC本体の音声はOBS Studio上で「デスクトップ音声デバイス」を「既定」にしてあるので、直接OBS Studioに入る。

以上で、PC本体の音声に、PC上のエフェクトアプリでエフェクトをかけて加工したマイクからの音声をMIXして、配信できる。

Amazon Cloud Drive Sync Never Ends

Amazon Cloud Drive (US site 1TB plan) file sync between local PC and cloud drive is too slow compared with Dropbox. I decided to stop using it.

For syncing about 30,000 files, Amazon Cloud Drive PC application never finishes syncing after two days while Dropbox Plus plan (1TB) PC application finishes at least within one day.

I choose Dropbox Plus plan.