peerc****@lists*****
peerc****@lists*****
2003年 9月 18日 (木) 14:19:21 JST
-------- MODE = Modify REMOTE_ADDR = 210.149.233.3 REMOTE_HOST = -------- LE-YON -------- １ユーザーのメモ書き *このページは 練習を兼ねて、PeerCastを使っていて気が付いたことを忘れないようにメモしてみようかと、そういうページ;; 日記じゃないのだから過去の履歴は消して結果を整理した方がよさそうですね、そろそろ。 ---- :9月1日:タグ関連にかなり加筆修正 :7月20日:作成 ---- *LAN内の他のマシンでPeerCastからのストリーム配信を受けるには 本家かどこかに「''''LAN内に一台PeerCastを稼動させておけば、他のPCはそこから直接配信を受けられる''''」というような記述があったような気がします。しかし、実際やろうとしてみるとなかなかうまくいきませんでした。また、これに関する解説などもなぜか非常に少ないようです。;; できてしまえば大したことはなかったのですが、同じことで悩んでる人もあろうかと思います。というわけで、;; ;; 追記:http://www.PeerCast.org/jp/に次のようにありました。 >同じLAN内にいる人たちは自分のマシンにクライアント・ソフトウェアをインストールしなくても、ストリームのチャンネルを聴くことができます。オフィスにはLAN全体にストリームを供給するPeerCastクライアントが1台だけあれば良いのです。 **環境 LAN内のマシンには192.168.0.で始まるプライベートなIPが割り当てられている。;; PeerCastが動いているPCのIPは192.168.0.2とする。このPCはポート7144を開けておく。;; **PeerCastの設定 PeerCastの設定画面のまんなか辺に''フィルター''という項目があります。ここに追加します。;; 追加する設定はIP Maskを''192.168.0.255''とし、チェックボックスは左から3つにつけます。（''127.0.0.1と同じ''）;; そして、[設定を保存]を押すのを忘れずに;; ;; これであとはプレイヤーに配信元を教えてあげるだけです。 **プレイヤー側 Winampのプレイリストに次のURLを追加すればそのチャンネルが聞けるようになります。;; ''''''http://192.168.0.2:7144/stream/[ChannelID].ogg'''''';; ;; もしくは（面倒ですが）html文書に ''''''http://192.168.0.2:7144/pls/[ChannelID]'''''' へのリンクを書いておき、それをクリックしても同様に聞けるようです。 ---- フィルターの設定についてはよく理解していませんが、とりあえず動いています。;; 詳しい方がいたら適当に書き加えてほしいです。;; **8月5日追記 フィルターの設定はどうやら、指定したIP（IP範囲？）からの接続をタイプ別で許可/拒否するものらしい(参考:PeerCastJpWindows) ---- *127.0.0.1(localhost)について 127.0.0.1は''ループバックアドレス''といって、自分自身を指すネットワークアドレスだそうです。 カレントディレクトリとかと同じ考え方だと思います。 **PeerCastにおけるアドレス取得 PeerCastでは自分のグローバルIPの取得に特定のサーバーへの問い合わせを行います。;; もし、このサーバーが落ちていた場合には、自分のIPを127.0.0.1としてしまいます。 これは、いってみれば''間違った思い込み''のようなものですが、これによりおかしなことが起こります。 ・・・・いろいろあるかもしれませんが、とりあえず実際に遭遇した例で説明しておくと、次のような感じ **個々のPeerCastの具体的な動作 あるPCで動作しているPeerCastの状況を考えてみます。;; PeerCastはネットワークを介して外から送られてきた情報を元に新たな接続を試みるわけですが、 送られてきたアドレスが127.0.0.1であった場合を考えると、 -まず、peercestクライアントは127.0.0.1に、つまりLocalhostへ接続しようとします。 -すると、LocathostにはすでにPeerCast(自分自身)がいるので、これとの間で接続が確立します。 -結局、同じPC上のPeerCast同士が接続されてしまいます。 この接続は無意味であり、またこの間では新たな情報は一切交換されないはずですが、実際にこの状況になるとその接続を介して大量のデータが流れるらしく、マシンがとんでもなく重くなります。;; そのときにはPeerCastのWebインターフェース等で接続状況を確認して、127.0.0.1との接続を切れば元に戻ります。ただし、間違えてWinamp等との接続を切らないように(^^; ;; しかし、いちいち監視していたのでは大変です。 **解決策 上の例では送られてきた情報が間違っていた、つまり自分以外のどこかのPeerCastが 自IPを127.0.0.1として動作していたために、自分のPeerCastがおかしな動作をしてしまいました。;; 逆に自分のPeerCastが自IPを127.0.0.1とした場合には相手側で同様のことが起こります。;; これを防ぐための方法を挙げると -手動でIPを調べて''forceIP''指定してしまう。しかしIPは頻繁に変わる可能性があるため、しょっちゅう確認する必要があり、あまりいい方法とはいえない。 -''filter''の設定で''127.0.0.1''を''ban''してしまう。こうすれば、ローカルのPeerCastからの接続は拒否されるため、上のようなことは起こらなくなる。 ２つ目に挙げた方法は、自IPが127.0.0.1であるという間違った情報が外に流れていくのを防ぐものではなく、自衛策にしかなりません。結局lookuoHostが落ちた場合に間違った情報が流れ出すのを防ぐには現状では１つ目の方法を実行するしかないような気がします。 しかし、自衛として２つ目の設定は行っておいたほうがいいでしょう。この場合PeerCastにはアドレス直指定でアクセスするようにします。（ただし、何をやっているのかよくわからないなら設定しないほうがいいかも） ---- グローバルなアドレスが127.0.0.1というのはあり得ないのだから、PeerCast内部で対処してくれるといいなと思ってみたり。;; この問題に関して、anoさんのLocalHost対策の方がまとまっていますが、とりあえず自分としてまとめておきたかったので。 ---- *file://で配信できないファイルがあるのはなぜ？ file://を使って配信（FileSource）しようとすると、某ポート開放のoggではできるのに、自分でエンコードしたoggファイルでは配信できなかったことがありました。;; 考えられる原因としては -ソースがモノラルだから（？） -Winampで書き込んだタグのせい -もしかしてCBRじゃないのでは？ とりあえず調べてみました。;; **とりあえず実験 ソースからエンコードしなおして配信できるか確認しました。;; **条件 ソース：Radioからの録音、モノラル22kHz16bit;; エンコード：ビットレートはCBR45kbps、エンコーダーはoggdropXPd;; 配信方法：[file://c:/なんたら]による直接配信（[[ここ http://peercast-jp.sourceforge.jp/cgi-bin/note.cgi?FileSource]]）;; **結果？ 配信してみると、とりあえず成功。おや？;; 次にWinampでタイトルなどのタグ情報を書き込んでからやってみると、今度は配信できない。こっちか！;; 確認のため、Winampにてタグをなしにして更新したファイルを試すとこれもだめ。 **Winampのせいか Winampでタグを書き込むと配信できなくなるようです。一度書き込んでしまうと消してもだめ、きっと空白のタグが書き込まれているからでしょう。;; Winampによるタグ更新の前後でバイナリ比較するとファイルの先頭と末尾がかなり変わっていました。しかし、WindowsMediaPlayerでも再生はできるのでoggの仕様からは外れていない模様。というか、タグ情報自体オプション（＝あってもなくても動く）だろうと思いますが。;; -結局Winampは''''shift-JIS''''にしか対応してないとかそういう感じ 以前配信できなかった原因はWinampによるタグの書き込みによってファイル構造が変わったためでしょう **対策は？ 上に書いたようにタグをWinampで編集したことによる問題っぽいので、 -他のタグ編集ツールを用いる 具体的には、[[SuperTagEditor改 http://hp.vector.co.jp/authors/VA012911/]]がすでに.oggに対応していました。[[mp3infp http://www.win32lab.com/fsw/mp3infp/index.html]]も;; これらを使えば'''解決''';; ところで、oggのエンコーダーは現状では''CBR''に対応しておらず、実際は'''最大と最小のビットレートを同じにしたVBR'''による''疑似CBR''になっているようです。 *ビットレート指定について エンコードする際に選択できるビットレート指定にはいくつかありますが なんとなく用語解説っぽく並べてみると、 :CBR:固定ビットレート。単位時間当たりのビット数は一定。 :VBR:可変ビットレート。単位時間当たりのビット数は変動。音質一定 :ABR:可変ビットレート。ファイル全体でのビット数一定。 :Q指定(QB):可変ビットレート。Quality(音質)一定。Qualityレベルを指定。 ;; 微妙にかぶってるような部分もありますが、区別しているものは -結果として何を一定にするのか なのでしょう。;; そのため、''''Q指定''''以外はビットレートを指定し、''''Q指定''''は音質を指定するようになっています。たぶん。 用語がoggエンコーダでの表記と違いますが適当に読み替えられるでしょう。;; *配信している曲とかのタイトル（タグ情報）が再生側で見えない Winampから''''oddcastDSP''''プラグインを用いて、MP3ソースをogg配信すると、再生側でタグ情報が正常に表示されませんでした。具体的には日本語（２バイト文字）があると、それ以降がみんな消えてしまいます。;; 明らかに文字コードの問題でしょうが、peercastのタスクトレイのポップアップには日本語も正しく表示されていたりする・・・。;; ということは、peercastは正しく認識しているにもかかわらずプレイヤー（Winamp）に送る際にそのまま（対応した文字コード等に変換せずに）送っていることが問題なのでしょう。;; 本来タグには''vorbiscomment''形式を使うべきで、そこでは''''UTF-8''''がのぞましいようです。しかし、実際にはそれぞれの環境で用いられている文字コード、''''Shift-JIS''''(Windows)や''''EUC''''(Unix?)で出力しているアプリが多いようです。 **対策 ''''oddcastDSP''''を使う場合の、根本的な解決策はまだ知りません。;; あらかじめoggに変換してのファイル配信ならば正常な表示が可能です。（下の項目参照） *mp3をoggに 貯めこんだmp3をoggに変換したいということがよくあると思います。;; エンコードされたものを再エンコードするので情報の劣化は避けられず、音質を考えるとよくないはずですが、wav等のソースがすでにないことが多いので・・・。 とりあえず実際に試した方法を挙げてみます。まず、エンコードから -wavに変換してから、''''oggdropXPd''''でエンコード -[[AudioEncorder http://kazuki.s18.xrea.com/index.html]]で直接 -[[Lilith http://www.project9k.jp/index.htm]]で直接 １番目の方法はタグ情報が失われてしまうので、手動で移行せねばならず面倒。;; ２・３番目はどちらもタグ情報がそのまま移行できますが、''''Lilith''''の方がリサンプリングなどより細かな設定が可能かもしれません。;; anoさんがコメントで紹介されていた[[dMC http://www.dbpoweramp.com/dmc.htm]]は使ってみたのですがうちではEncode途中（？）でエラーで止まってしまいました。原因不明;; また、後からタグを編集する場合、[[Winampは使えない http://peercast-jp.sourceforge.jp/cgi-bin/note.cgi?LE%2DYON#i14]]ので他のタグ編集ソフトを使いましょう。 -多くのファイルのタグをまとめて編集するなら[[SuperTagEditor改 http://hp.vector.co.jp/authors/VA012911/]]が.oggに対応しています。 -１つだけ編集するなら[[mp3infp http://www.win32lab.com/fsw/mp3infp/index.html]]の方が使いやすいでしょうか。こちらも.oggに対応。 これらで追加・修正したタグは、再生側にも正常に表示されるようです。 これで、タグの移行を含めたmp3からoggへの変換ができるようになりました。 *ストレスのない配信がしたい ストレスがないって何だろう、配信する側への負荷が少なくてスムーズに聞ければストレスは感じないかな、あと特許とか気にしなくていいとか．．．、というわけでエンコード済みのoggを直接ストリームとして流すだけのfile://による直接配信をすることに。;; ファイルを直接配信する方法は[[ここ http://peercast-jp.sourceforge.jp/cgi-bin/note.cgi?FileSource]];; 配信を始めるときにビットレートを指定しますが、この配信方法だと完全に送信ビットレートが固定となってしまうようです。 このため、指定したビットレートとoggファイルの実際のビットレートとにずれがある場合、受信側において'''バッファオーバーフロー'''や'''バッファアンダーラン'''(?)が起こってしまいます。つまり、音飛びしたり、途切れたりします。;; 実際にやってみた例では、ビットレートに''19''を指定するとときどき音が止まって''''prebuffering''''が発生し、''20''だと逆にバッファがあふれて音とびを起こしました。;; ビットレートを小数で指定できれば改善するのでしょうけど、無理なようで。 いくつかファイルを作成して確認してみましたが、、、、例を挙げると、;; エンコーダにはLilithを使用して、CBRとQB、それぞれで可能な最低品質で下のように -''''CBR''''（（疑似？）固定ビットレート）48Kbps -品質ベース（''''QB''''?）（公称45.001Kbps） モノラルソースなので、実際のビットレートは数字の半分になるようです。;; 確認のため書いておくと、この結果は、おそらくソース依存かつレートの指定依存なので、この場合はこうだったという参考にしかなりません。;; それで、結局、これらを比べたところでは''''QB''''のほうがレートのばらつきが少なかったように感じました。 実際の配信で途切れが少なかったのも、''''QB''''の方でしたが、ただ単に整数に近いビットレートだっただけかもしれず．．．。 結局、配信する際の設定としては、バッファがあふれて音飛びするよりは、たまに音が止まって読み込みにいくほうが、聞いていてストレスを感じないので、上の例では''19''を指定するのがいいかと思います。;; 結局のところ -完全な''''CBR''''ができないかなぁ ＞エンコーダー -ビットレートを細かく指定できないかなぁ ＞エンコーダー、peercast -可変ビットレート配信はできないのかなぁ ＞peercast というわけで現在はこれらの方法を検索中 現状ではOgg自体がCBRに対応できていないようですが、．．．だれか作ってたりしないかなぁ(謎);; *配信できないファイル再び 以前の配信できないファイルは、タグ情報の形式がおかしかったためでしたが、また別の問題が。;; OddcastDSPで配信している時の話なのですが、Oddcast内ではWinampで再生したものがリアルタイムでOggにエンコードされて配信データが作られているのだと思います。;; 最初はMp3をソースにして配信をしていてそのときは問題がなかったのですが、あるときOggをソースにしたところ、Oddcast PluginがWinamp共々落ちてしまいました。 問題はビットレートか、チャンネル数か、他のエンコード設定か;; 原因は特定できてません。しかし解決策はありそうな予感;; 少なくとも、一部のOggファイルはソースにしても問題なく配信できます。;; とりあえず、その辺りで実験してみようと思います。結果はそのうち。 なんにしてもOddcastは不思議です。べたデータをエンコードしてるだけじゃないのでしょうか？ ---- [[#rcomment]] - 2003-09-18 (Thu) 14:19:21 ''[[pax]]'' : 結局、oddcastの最新版をCVSで見つけたのでUTF-8にエンコードさせてなんとかなりました。ちゃんと動いてるか検証中。 - 2003-09-17 (Wed) 15:47:08 ''[[pax]]'' : peercast側で対処する問題ではないと思うけど、なんとかできないか試してみてるところです・・・ - 2003-09-17 (Wed) 15:43:14 ''[[pax]]'' : 本来のogg vorbisタグはUTF-8エンコードされなければいけないのですが、winamp+oddcastだとSJISのまま送られてくるようです - 2003-09-14 (Sun) 05:30:57 ''[[LE-YON]]'' : UNICODEも何通りかあるようですが、8ビット目を使うとだめなのですかね - 2003-09-12 (Fri) 13:40:11 ''[[pax]]'' : oddcastもconfig画面が妙に重かったり、なんか怪しげ・・・英語力さえあればforumに要望書くんですけどね・・・ - 2003-09-12 (Fri) 13:39:04 ''[[pax]]'' : 以前oddcastのタグで日本語が正常に通る版を頂いたのですが、元ビルドが古いせいか、曲間でprebufferingが・・・ - 2003-09-12 (Fri) 13:37:52 ''[[pax]]'' : mp3のID3v2でUNICODEエンコードしたタグでもバケちゃいました(；´д⊂) - 2003-09-01 (Mon) 18:12:58 ''[[LE-YON]]'' : 混乱中です。2つのパターンがあって、１つめはmp3ソースをoddcastDSPでogg配信する、２つめはmp3ソースをあらかじめoggに変換しておいて直接配信する。この2つのどっちの話をしているのか混乱している記述があるかも。 - 2003-09-01 (Mon) 17:39:28 ''[[LE-YON]]'' : 個々のファイルのタグ編集なら[[mp3infp http://www.win32lab.com/fsw/mp3infp/index.html]]が使いやすそうです - 2003-09-01 (Mon) 02:15:07 ''[[LE-YON]]'' : dMCはタグのみの編集には使えないようだが、foobar2000ならoggにも直にタグを書き込めるようです。しかし、タグ編集だけなら[[SuperTagEditor改 http://hp.vector.co.jp/authors/VA012911/]]が.oggに対応してました。 - 2003-08-28 (Thu) 19:30:23 ''[[Lunarchan]]'' : MP3等→ogg変換はfoobar2000でやるのが結構良いかもしれません。APEv2タイプのタグで記録してfoobar2000で変換したOggをPeerCastで流したところ、無事に再生できました。マルチバイト対応なので、日本語もいけてます。APEv2タグは中身がUTFっぽい挙動してます。中国語でもいけるんで。 - 2003-08-24 (Sun) 20:46:44 ''[[LE-YON]]'' : aveの計算はファイルサイズからしているのでしょうか。あと、dMCがタグ編集に使えるなら、大本のエンコーダーと組み合わせて細かなことができますね。 - 2003-08-23 (Sat) 23:50:09 ''[[ano]]'' : 昔、[[こんなやりとり http://ano.hearview.net/memo/?date=20030427#p01]]したんですよ。あれから、file://の仕様が変わっていないところを見ると…file://VBR.oggによる完全な配信は今後も無理っぽいような気が。ちなみに、nominal=min=maxエンコードでは確実に''''ave''''<=''''nominal''''です。そのaveの変動はファイルの内容次第としか。ただ、私個人のソースでは'''品質指定によるVBR'''より'''疑似CBR'''の方がbitrateの変動は少なかったです。あと、bitrate自体の細かい指定は大元のツールではできたはずです。そこらのエンコーダが対応してないだけで…。 - 2003-08-23 (Sat) 21:01:34 ''[[LE-YON]]'' : dMCですか。日本語のタグは大丈夫でしょうか。ちょっと見てみます。 - 2003-08-23 (Sat) 16:20:58 ''[[ano]]'' : mp3=>ogg、[[dMC http://www.dbpoweramp.com/dmc.htm]]使ってます。 - 2003-08-09 (Sat) 08:13:55 ''[[LE-YON]]'' : もうちょっと調べてからと思ってここにメモしておいたのですが、返答ありがとうございます。とりあえず、タグをなくすとか、エンコードの設定を確認するとかして調べて見ます。 - 2003-08-08 (Fri) 08:39:10 ''[[ano]]'' : OggVorbis、タグ情報周りで過去にいろいろありました。以前は文字数制限が。で、それは確か修正されたはずなんですが、一部のファイルや組み合わせ（？）でスキップされる場合は確かにあります。手元では日本語がタグ情報に入っているある特定のファイルのみスキップされたので、「utf8でも一部の領域で変な動作しているんだけど心当たりはない？」と本家フォーラムには投げてあります。 - 2003-08-05 (Tue) 08:19:40 ''[[ano]]'' : LocalHost対策は…長いので、私のページにでも書いておきましょうか。仰るとおり、localhostをbanすると、Win32GUI系はまともに動作しなくなるでしょう。 - 2003-08-05 (Tue) 05:47:37 ''[[LE-YON]]'' : しかし、こうするとタスクトレイからの再生が素直に通らないような・・・. - 2003-08-05 (Tue) 05:45:55 ''[[LE-YON]]'' : localhost対策とは？結局は自IPが127.0.0.1にされてもおかしなことが起こらないということでしょうか。 - 2003-07-20 (Sun) 16:51:02 ''[[ano]]'' : 192.168.*.*でPeerCastにアクセスして、127.0.0.1をbanすると、本家が落ちたときのlocalhost対策になります…。 - 2003-07-20 (Sun) 16:49:24 ''[[ano]]'' : いらっしゃいませ。ちなみに、うちの環境ではルータから192.168.''1''.*というIPが割り当てられてます。環境ごとに微妙に違うでしょうね。 --------
