Tag: audio

破 reCAPTCHA 的 Buster

在「用 Google 的 Speech Recognition API 破 Google 的 reCAPTCHA」與「reCAPTCHA 與語音辨識：以子之矛，攻子之盾」都提過用語音辨識功能破 reCAPTCHA，現在又有一套了，而且直接在各瀏覽器的 extension 平台上架：「Buster: Captcha Solver for Humans」。

說明可以看到一樣是透過聲音的部份辨識：

Buster is a browser extension which helps you to solve difficult captchas by completing reCAPTCHA audio challenges using speech recognition. Challenges are solved by clicking on the extension button at the bottom of the reCAPTCHA widget.

除了安裝很簡單以外，設定也弄得很簡單，這個套件支援多種不同語音辨識 API，包括 Google、Microsoft 以及 IBM 的服務，只要在套件的設定頁輸入 API key 就可以了...

另外剛好也跟 reCAPTCHA 有關，在 Hacker News 上的「Google's Captcha in Firefox vs. in Chrome (grumpy.website)」看到 Google Chrome 與 Mozilla Firefox 在跑 reCAPTCHA 的不同之處 (Chrome 的流程順很多，Firefox 卡很多)，不過我覺得證據還有點弱，需要再看其他的測試...

另外裡面有提到一些奇怪的東西，像是 W3C 的替代方案 (這個組織提的東西...)：「Inaccessibility of CAPTCHA」，找時間來研究一下...

自動校正字幕時間的軟體 subsync

看到用 Python 寫的「smacke/subsync」這個軟體，可以自動校正字幕時間：

Language-agnostic automatic synchronization of subtitles to video, so that subtitles are aligned to the correct starting point within the video.

他把上面這個變成下面這個：

因為不是用 machine learning 所以速度意外的快。演算法是對影片本身產生一個 array，然後對字幕也產生 array，最後對兩個 array 用個簡單的公式校準：

  • Discretize video and subtitles by time into 10ms windows.
  • For each 10ms window, determine whether that window contains speech. This is trivial to do for subtitles (we just determine whether any subtitle is "on" during each time window); for video, use an off-the-shelf voice activity detector (VAD) like the one built into webrtc.
  • Now we have two binary strings: one for the subtitles, and one for the video. Try to align these strings by matching 0's with 0's and 1's with 1's. We score these alignments as (# matching digits) - (# mismatched digits).

就這樣解決問題 XD

Google Hangouts 將會使用固定 IP 位置

Google 宣佈 Hangouts 將會使用固定 IP 位置，讓系統管理員更方便管理：「Dedicated Hangouts Meet IP addresses」。

We’re adding a range of official, fixed IP addresses to be used exclusively for classic Hangouts and Hangouts Meet in G Suite domains.

目前看到的資訊是：

IPv4: 74.125.250.0/24
IPv6: 2001:4860:4864:5::0/64

然後文章裡的說明是二月 14 日會變更：

Hangouts Meet and classic Hangouts will stop using the old IP address on February 14, 2019.

管理者可以調整關於這段 IP 的流量，通常是調高優先權？不過要調低也是可以...

用 FFmpeg 處理單聲道聲音產生空間感

先提供指令 (需要新版 FFmpeg)，把單聲道的 1.wav 加工成 2.wav (兩聲道)：

ffmpeg -i 1.wav -filter_complex '[0:0]stereotools=delay=20[aout]' -map '[aout]' -y 2.wav

這是看了『如何讓聲音有「立體感」？』後的實驗：

裡面提到要怎麼讓單聲道錄音產生空間感，其中一個方式是將單聲道的 audio stream 複製到兩邊，但讓左右聲道差 0.02 秒 (也就是 20ms)，讓兩邊聲音有些微差距而產生空間感。

查了資料後發現這個功能可以靠 FFmpeg 裡 stereotools 的 delay 達成：

delay
Set delay in milliseconds how much to delay left from right channel and vice versa. Default is 0. Allowed range is from -20 to 20.

但 Ubuntu 16.04 內的 FFmpeg 版本不夠新 (2.8.15)，測試時說沒有 stereotools 這個 filter，所以找了「FFMPEG 4 : Jonathon F」這個 PPA，改用 4.x 版的 FFmpeg 就可以用了。

算是找個機會玩看看... 另外也熟悉一下 FFmpeg 的 -filter_complex 到底是什麼語法。

把 YouTube 對 channel 與 user 的自動播放功能關掉...

YouTube 在 channel 與 user 頁面會自動播放會讓人覺得頗困擾 (頁面一打開就有聲音)，所以想要找看看有沒設定可以關掉... 找了之後發現很久前就有被問過，但是當時得到沒有這個功能的回答：「How do I DISABLE autoplay from other channels on my YouTube channel?」。

既然如此就只能找套件來解了... 目前是透過 Userscript 擋下自動播放，程式碼不長也蠻好懂的：「Disable YouTube Channel/User Home Page Video AutoPlay」。

這樣總算是不會被聲音搞到...

又一個 TCP BBR 的測試結果

TCP BBR 是 Google 發表的 TCP congestion control 演算法，是一個純伺服器端就能夠改善 TCP 壅塞處理的機制。在 Linux Kernel 4.9 之後被納入了。

而 Spotify 有大量資料要傳到使用者端 (像是音檔)，剛好是 TCP BBR 改善的對象之一，實際測試後得到了很不錯的改善數據：「Smoother Streaming with BBR」。

Spotify 公佈的資料沒有提到平台，所以先稍微了解一下他的音質，也就是「Audio settings」這篇。

在 Desktop 是 160kbps/320kbps Ogg (Standard/HQ)。在 Web Player 則是 128kbps/256kbps AAC (Standard/HQ)。

行動平台部份比較複雜，在 iOS 上是 96kbps/160kbps/256kbps Ogg (Normal/High/Extreme)，另外有 Automatic 自動調整的設定。在 Android 平台則是 24kbps HE-AACv2 (Low) 與 96kbps/160kbps/320kbps Ogg (Normal/High/Very high) 以及 Automatic。

而最後 Chromecast 則是 128kbps/256kbps (Standard/Premium)。

測試時可以發現 shutter (指跟不上播放速度) 的情況降低了 6%～10%，而且下載速度增加了 5%～7% (對於慢速的裝置改善更多，10%～15%)：

Taking daily averages, stutter decreased 6-10% for the BBR group. Bandwidth increased by 10-15% for the slower download cohorts, and by 5-7% for the median. There was no difference in latency between groups.

而各地區的差異也可以看出來改善很多：

另外他們在測試時，剛好遇到秘魯的機房連外發生問題，結果意外發現 BBR 還是可以穩定在這種網路環境下運作：

In Peru, the non-BBR group saw a 400-500% increase in stutter. In the BBR group, stutter only increased 30-50%.

In this scenario, the BBR group had 4x bandwidth for slower downloads (the 10th percentile), 2x higher median bandwidth, and 5x less stutter!

在 Ubuntu 18.04 上可以直接設定 BBR，在 Ubuntu 16.04 則可以參考「Ubuntu 16.04 用 speedtest-cli 測試 TCP BBR 效能」這篇的方式升級 kernel 後設定 BBR。

OS X 接藍芽耳機要注意的地方...

在 Twitter 上看到 OS X 接藍芽耳機時的音質問題：

看了一些討論，看起來除了蘋果自己的耳機外，其他家的藍芽耳機不一定會開 AAC 或是 aptX。雖然現在沒有其他家的藍芽設備，但以後如果買了要注意一下...

Google 發表新的 TTS (Text-to-Speech) 技術 Tacotron 2

Tacotron 是 Google 發表的 TTS 技術 (i.e. 輸入文字，請電腦發音)，而前一版的 Tacotron 的錄音可以參考「Audio samples from "Tacotron: Towards End-to-End Speech Synthesis"」，論文則是在「Tacotron: Towards End-to-End Speech Synthesis」這邊可以看到。

這一版的則是在 Twitter 上看到有人提到：

這一版叫做 Tacotron 2，錄音可以參考「Audio samples from "Natural TTS Synthesis by Conditioning WaveNet on Mel Spectrogram Predictions"」，論文在「Natural TTS Synthesis by Conditioning WaveNet on Mel Spectrogram Predictions」。

這次在錄音頁面的最下面提供了盲測 (人類與 Tacotron 2 的錄音)，基本上已經分不出哪個是真人了...

Savitech (盛微) 的 USB 音效驅動程式會安裝 Root CA (被發了 CVE-2017-9758)

在 Hacker News 上看到 CERT 的「Savitech USB audio drivers install a new root CA certificate」提到 Savitech USB audio driver 會安裝自己的 Root CA：

Savitech provides USB audio drivers for a number of specialized audio products. Some versions of the Savitech driver package silently install a root CA certificate into the Windows trusted root certificate store.

出自「Inaudible Subversion - Did your Hi-Fi just subvert your PC? (原網站已經無法訪問，參考備份連結 https://archive.is/K6REr)」，CVE 編號是 CVE-2017-9758，最初是由 n3kt0n 提出的：「某單位 drivers silently install certificate in trusted root certificate authorities store [CVE-2017-9758]」：

Mitre assigned this exposure the identifier CVE-2017-9758, but was initially tracked by HITCON ZeroDay project as ZD-2017-00386.

有兩把 CA public key 被塞進去。雖然目前還沒有徵兆 private key 有外洩，但還是建議儘快移除：

There is currently no evidence that the Savitech private key is compromised. However, users are encouraged to remove the certificate out of caution. The two known certificates are:

SaviAudio root certificate #1
‎Validity: Thursday, ‎May ‎31, ‎2012 - ‎Tuesday, ‎December ‎30, ‎2036
Serial number: 579885da6f791eb24de819bb2c0eeff0
Thumbprint: cb34ebad73791c1399cb62bda51c91072ac5b050

SaviAudio root certificate #2
Validity: ‎Thursday, ‎December ‎31, ‎2015 - ‎Tuesday, ‎December ‎30, ‎2036
Serial number: ‎972ed9bce72451bb4bd78bfc0d8b343c
Thumbprint: 23e50cd42214d6252d65052c2a1a591173daace5

另外 Savitech 也放出了新版的 driver，不包含 Root CA：

Savitech has released a new driver package to address the issue. Savitech drivers version 2.8.0.3 or later do not install the root CA certificate. Users still must remove any previously installed certificate manually.

看了一下說明，看起來是當時為了支援 Windows XP 而做的，但微軟已經不提供驅動程式的數位簽章了，所以就只好這樣搞...

現有語音控制的安全性問題：使用聽不見的高頻下令

雖然相關的理論很早就有了，但上個禮拜放出來的論文完整實做出來，叫做 DolphinAttack，取自於海豚可以聽見人類所聽不到的聲音：「DolphinAtack: Inaudible Voice Commands」(這邊的錯字是作者造成的，submit 到 arXiv 的標題有錯，但論文內描述則是對的)。

無論是 Siri 或是 Google Now，或是其他的控制軟體，都設計成能接受多種不同語調的人，而這個部份目前放的都太寬，造成人類聽不到的區段也可以下令：

也可以看到成功機率很高：

應該會有些調整...