【技術】「複数記述符号化分割転送」で高品質インターネットIP音楽放送が可能に[03/23]

このエントリーをはてなブックマークに追加
1壱軸冠蝶φ ★
東北大学とNECは3月23日、音飛びがなく高品質なインターネットIP音楽放送を実現する
「複数記述符号化分割転送技術」技術を発表した。

東北大学が開発した「複数記述(MD)符号化」技術とNECの「マルチパスルーティング」
技術を組み合わせたもの。データの送信帯域をほとんど増加させずに品質を向上させる
という。

リアルタイム放送サービスの場合、パケット再送手段を持たないため、ネットワーク上で
パケットロスが生じると音飛びや画像飛びといった品質低下を招いてしまう。
FEC(Forward Error Correction)などの誤り訂正符号技術もあるが、バーストパケットロス
には対応できないという問題があった。

研究チームは、元の音データを2つ以上の音データに分割して符号化することで、データ
欠落があっても元の音データを復元できるMD方式に着目。1つの高音質な音を2つの
低品質な音に分割し、それぞれの音と復元用の符号データを2つのルートで転送する
方式をシステムに適用した。

音を分割する方法には、東北大で開発された周波数ストライプ分割法を採用。
どちらかの音データが欠落しても、残った音データと復元用の符号データを使って元の
音データに極めて近い音を再生できるという。また、復元用符号を最適化したことで、
160KbpsのMP3の場合でデータ量の増加はわずか7.8Kbpsに抑えた。

東北大学とNECは、既に実証実験を行っており、有効性は確認済み。早期の実用化を
目指すとしている。


依頼スレ>>197さんの依頼に基づき立てました。
http://news21.2ch.net/test/read.cgi/scienceplus/1167732360/197

参考サイト:
NECプレスリリース
http://www.nec.co.jp/press/ja/0703/2301.html
RBB TODAY記事
http://www.rbbtoday.com/news/20070323/39997.html

ソース:ITmedia
http://plusd.itmedia.co.jp/lifestyle/articles/0703/23/news132.html
2名無しのひみつ:2007/03/24(土) 16:42:58 ID:wJYMk8IQ
難しくてようわからんがとにかくすごいんだね?
3名無しのひみつ:2007/03/24(土) 16:46:01 ID:+NwjiNKH
産学連携ってレベルじゃねーぞ
4名無しのひみつ:2007/03/24(土) 17:14:14 ID:AIIWLWqF
オレのBluetoothヘッドセット、音楽聴くと低音すっとんでるんだけどなんで?
5名無しのひみつ:2007/03/24(土) 17:19:14 ID:Ibr7uhc8
5%も増えてるジャン
6名無しのひみつ:2007/03/24(土) 17:19:15 ID:oib+jJyc
はやくちことば
7名無しのひみつ:2007/03/24(土) 17:26:30 ID:dy5xSCU1
しかしルートの異なるプロバイダが2つ必要になるのでしょ
8名無しのひみつ:2007/03/24(土) 17:28:57 ID:kCWBm7fK
なんで5%しか増えないんだ・・・すげえ
9名無しのひみつ:2007/03/24(土) 17:39:50 ID:/apJBuLS
地デジならHD(12セグ)放送のデータ欠損を
ワンセグ放送のデータで補完するようなものか。
まあ、2次元画像情報だといくら補完しても粗が見えやすいかもしれんが
10名無しのひみつ:2007/03/24(土) 18:41:26 ID:5OjkjUwp
これも浅野前知事の成果の一つです
楽天の誘致もしましたし浅野さんが都知事になればもっとすばらしい首都になるでしょう

東北大と浅野は何の関係も無い
楽天は仙台しか場所がなかったわけで別に浅野の功績ではない
浅野時代に暴走族数日本一(人口当たり)になったというのはホント
11名無しのひみつ:2007/03/24(土) 18:48:00 ID:zhUaj5uk
>FEC(Forward Error Correction)などの誤り訂正符号技術もあるが、
>バーストパケットロスには対応できないという問題があった

そうか?LDPCなどのレートレスな符号化で対応できるじゃん。
12名無しのひみつ:2007/03/24(土) 22:05:58 ID:cZE4x+0E
片方欠落しても元の音にきわめて近い音が復元できるなら
2つのうち片方だけ送ることにしてデータ量半分に押さえようぜ
13名無しのひみつ:2007/03/25(日) 12:06:34 ID:1Lx8oPLt
ジャスラックのweb監視組織にブックマークされました。
14名無しのひみつ:2007/03/25(日) 23:44:13 ID:/lCKCJ0A
難し過ぎて判らんが凄い事らしいな。
15名無しのひみつ:2007/03/26(月) 13:23:13 ID:+3NTUJk3
今までは1か0だったのが、1か0.5か0になったってことか?
16名無しのひみつ:2007/03/26(月) 13:40:05 ID:MXCIUf9n
ストリーミングはUDPって関係あんのかな?
17名無しのひみつ:2007/03/26(月) 13:57:56 ID:fO6mMGW4
いくら高品質なものを送れる技術があろうが、中身が全てだろ。
18名無しのひみつ:2007/03/26(月) 17:02:06 ID:IGkYyTts
>>16
まぁよくあるのはTCP上のRTSPで情報交換しつつ
コンテンツ本体はUDP上のRTPで伝送ってのだろうけど。
問題はRTPで何を運ぶか。コンテンツのデータを生のまま
運ぶなんてことはなくて、普通はFECかけたりするよな。
19名無しのひみつ:2007/03/26(月) 17:49:04 ID:ygw/0Msk
>データ量の増加はわずか7.8Kbpsに抑えた
ビットレートが160Kbpsから167.8Kbpsになったってことか?
20名無しのひみつ:2007/03/26(月) 20:20:22 ID:P2UKct/W
ダウンロードできてから再生すればいいのでは?
21名無しのひみつ
それではストリーミングの意味がない。

端的に言えばこの技術は、無駄に通信量を増やさず、かつストリーミングを確実に行えるようにしたもの。

つまり負担軽減+通信保証。