Signal-ios: オーディオ品質

私はこれを見てきました。 ええ、より高いサンプリングレートは良いことかもしれません。 また、コーデックをSpeexからOpusに変更したかった。 残りが機能するときにこれを処理します;）

私はその品質がとても気に入りました。それは純粋な声であり、他には何もありませんでした。 私の唯一の不満は、誰かが話すときと受信者がそれを聞くときの間のわずかな遅れです。

通話品質が良いよりも、受信状態が悪い場合でもうまく機能する方がいいと思います。

-私の2c

理想的には、接続帯域幅がサポートしている場合、アプリはより高品質の音声を提供し、必要に応じて標準品質にフォールバックします。

私の携帯電話ネットワークは、iPhoneからAMR-WBをサポートする別の電話に通常の電話をかけるときに、 http：//en.wikipedia.org/wiki/Adaptive_Multi-Rate_Widebandをサポートします

これらの最適化は、誰が話しているのか、誰かが何を言っているのかについて攻撃者に情報漏えいを引き起こす可能性があるため、注意する必要があります。
現在、変更は予定されていません。 いつかOpusに切り替わるかもしれませんが、次の週には切り替わらないかもしれません。

Signalを1日に複数回使用した後、オーディオ品質に対するスタンスを逆転させたいと思います。私は本当により良い音質を望んでいます。

これらの最適化は、誰が話しているのか、誰かが何を言っているのかについて攻撃者に情報漏えいを引き起こす可能性があるため、注意する必要があります。

この脅威の正式な分析はありますか？ 他のドメインのサイズに関連して私が見たサイズチャネル攻撃のほとんどはかなり脆弱であり、Signalへのユーザビリティの影響はかなり深刻です。

そうは言っても、コマンドラインエンコーダにはこの正確なシナリオのためのハードCBRモードがあります。

この脅威の正式な分析はありますか？

私はこれを調べましたが、答えはイエスです。生のパケットデータから音素を再構築できます。 Opus RFCは、CBRモードを使用し、ネットワークの状態に基づいてエンコードレートを変更することを提案しています。 もちろん、これはOpusに限定されるものではなく、Speexでも実行できます。

これは、 https ： ます。 どちらの側にも音が出ないというユーザーの報告：
アリス（Androidの場合）： https ：
ボブ（iOSの場合）： https ：

@riyapennはい、いくつかの関連するバグがあります。 これは、コアの問題を最もよく捉えています。

iOSはOpusをサポートしていないため、OpusはSignalでサポートされていないように感じます。

Opusがあれば通話品質が大幅に向上するので、残念です。

Signalのオーディオ品質に不満がある場合は、一番上の投稿にスタ​​ーを付けてください。

iOSはOpusをサポートしていないため、OpusはSignalでサポートされていないように感じます。

それは正しいですが、SignalチームがiOSでのOpusのプロトコルネゴシエーションまたはソフトウェアデコードを提供するPRを拒否することはないと思います。

そうは言っても、 @ Cormakと@riyapennによって提起された問題は、他のチケットで詳細にカバーされています。 生産的な入力が行われていないように見えるため、このスレッドをプロジェクトの貢献者にロックすることをお勧めします。

2.7.0になります

iOSはOpusをサポートしていないため、OpusはSignalでサポートされていないように感じます。

Opusは、現在ベータ版で使用しているWebRTCフレームワークに含まれており、まもなくアプリストアに追加される予定です。