PESパケットのことをすっかり忘れていた。
何とかDTS、PTS、SCRの処理をやらなくてもいい方法はないものか．．．
(Friioの場合TSストリームはバースト的に受信するのでPCR自体が揺らぐ)

＞friio_EpgDataCapの作者さまへ

いつも愛用させていただいております。
番組情報内の文字列フォントを変更できるようにすることはできませんでしょうか？
iniファイル書き換えで対応、みたいにできると嬉しいのですが・・・

某氏の技術は認めざるを得ないがソースコードの品質は？なので、
MULTI2復号部分だけを抜き出してセクションの処理は作り直した方が
いいかもしれない。(処理もダブって無駄)

個人的にはIMediaDecoderの派生クラスとして実装する予定。

ちょっと本体改造してBS/CSに手をだしてます。

某氏にも報告しましたが、B25Decorderに暗号化されていない平文を入れると例外で落ちます。とりあえず暫定の修正ですので、本家対応後はそちらに従ったほうがいいです。

暫定対応
put_arib_std_b25()
flush_arib_std_b25()

p = curr+4;
の直後に
n = tail-curr-4;
を入れる。

これをやらないと、その後のset_ts_section_data()に渡すパラメーターのnの値がtailポインタを超える長さになり、落ちるようです。どうして平文でのみそれが起きるか等までは検証していないとりあえずの応急の対応です。

あとこちらも報告済みですが、B-CAS内に鍵がない状態でも無理やり解除やってるようです。戻ってきたScrambleKey()がすべて０の場合の処理は考えないととりあえず録画しておいて後で解除・・・ができなくなります。

確証はないですが、EP0へ送信してるデータのうち
40 01で始まるものと40 03で始まる２つは、IICかGPIOで外部ＩＣへ処理を流してる気がします。特にチューナー制御のほう40 03...のはデータ部でチャンネル番号を何らかの形で変換(周波数？)して送信している事からもその可能性は強いかも。
現状の正式ビューアでＢＳ／ＣＳのデモをしている事からも極力ハードウェアの単純化をしてる感じはするので。使用してるＩＣの型番削られてるそうなので推測の域をでないですが。

ARIB STD-B24英語版はＰＤＦで持ってますよー。日本語でも英語でも資料としては同価なので。BMLの解析とかスクリプトのサンプルコードがあればいいなあ・・・

BonDriver改造版、これから拝見させて頂こうかと思います。
もし差し支えなければ今後このWebサイトでリリースするツール類の
ベースとさせて頂きたいと思います。

DirectShowにはMPEG2とAACのデコードだけをやらせるつもりですので、
やりかたさえ分かればあまり深入りの必要はないと考えています。

BMLについては全く無知ですがARIB STD-B24あたりに書いてあるような気がします。
もっとも手軽には英語版しか入手できませんが．．．

とりあえず現状の解析をBonDriverに反映しました。
色々な環境で１時間くらい録画やりましたが、潜在的な問題はあるかもしれません。

現状、通信内容自体はオリジナルのFriioViewと同じものなのでこれによって動作が軽くなったりするわけでもないです。
LED処理と初期化コードあたりは相変わらずブラックボックスです。
オリジナルBonDriverではnProtect使用のソフトが起動中に初期化失敗する事がありましたが、改造版では起動するようになったのが最大の改良かも（ぁ

>私は今は映像と音声の再生系の枠組みを作っていますので
通信内容ハックする前に私もそっちをやってみようと思ってました;;
前ちょっと触ったことありますが、DirectShowって資料が少ないのでほんと大変ですね。

追記
データ放送、BML関連のCoolな資料がみつかれば、データ放送関連もハック再開するかも。

解析お疲れ様です。
ドキュメント化を希望してみたり．．．

BonDriverのリソースに埋め込んでるブラックボックスの部分を
スリムにできれば初期化やチャンネル切替も速くなってかなり
使いやすくなると思います。

私は今は映像と音声の再生系の枠組みを作っていますので
ドライバはお任せします。

ドライバ通信ほぼ攻略できました。LED関連以外は通信データの内容もわかりましたのでアップローダーの解析結果を更新しておきました。

USB標準処理とLED関連を除けば
・チューナーへのデータセット
・チューナーからの情報取得
・ストリーム転送
この３つくらいの処理だけでした。
ＬＥＤ関連処理をドライバに送信しないようにブロックしましたが、何の問題もありませんでしたので、このあたりを省略すればBonDriverがかなり単純にできるかもしれません。

前述したようにCypressの汎用ドライバ使ってるぽいので、うまくやればLinuxで動作させることも可能かもしれません。

凡からMPEG2吐き出すDirectShowのソースフィルタ試作して
何とか絵を出すところまできたがとにかく時間が足りない、
資料が足りない。

通信自体がCypressの汎用ＵＳＢドライバ(cyusb.sys)使ってるぽいので、通信データのヘッダ部だけ解析して表示してみました。(アップしてやばかったら消してください)

BonDriverのオープン成功時と失敗時の比較もしてみましたので報告します。
DevuceIoControl()が失敗しているのですが、
BonDriverオープン成功時
OK=DeviceIoControl(ctrlcode=0022003c,insize=00000100,outsize=00000100,ret(0000004E),overlapper=use)
BonDriverオープン失敗時
NG=DeviceIoControl(ctrlcode=0022003c,insize=00000100,outsize=00000100,ret(00000000),overlapper=use)
FriioViewの該当箇所
OK=DeviceIoControl(ctrlcode=0022003c,insize=00000100,outsize=00000100,ret(0000004E),overlapper=no)

MSDNを見る限り、Overlap指定で開いてる状態でoverlap=NULLのioctrlは予期しない方法でエラーとなってますが、オリジナルではそうなってるしちょっと謎です。

Friioのドライバ通信のダンプを再度調査しましたので、アップローダーにおいておきます。
TsRequestと思われる通信の直前まで（初期化コード？）を調査しましたが、数回のテストでは通信内容は同等でした。
オリジナル通信のダンプを見ると、CreateFileA()でオーバーラップ指定しているにもかかわらず、DeviceIoControl()にてlpOverlapped=NULLという動作をしている箇所があるのが気になります（Win32で想定されていない呼び出しだと思うのですが）

[調査方法]
プロキシＤＬＬによるＡＰＩフック(CreateFileA,DeviceIoControl)
プロキシＤＬＬは今回アップロードしてませんが、必要ならアップします。

ご連絡ありがとうございます。

BonDriverのデバッグ中にもDeviceIoControl()の送信バッファの中身がまれに
書き換わるという現象を確認しています。オリジナルのソフトが送信している
初期化コードの中身自体の解析は非常に困難ですので、キャプチャした結果を
そのまま再生している形になっていますが、最新版ではシーケンスが変更されて
いますので、固定データの最新化を検討します。

何か分かればまたよろしくお願いします。

こんにちわ。データ放送分解ツールの人です。

不正アクセス防止ソフトウェア(メモリ改ざん禁止の為)を採用しているソフトウェアが起動している場合、BonDriverを開くのに失敗するようです。
ちょっとトレースしてみたところ、DeviceIoControl()がアクセス拒否を起こし(特権モードでも同様)初期化コードの送信に失敗しているようでした。オリジナルのFriioViewにおいてはそのようなエラーが発生せずアクセスしているようですので、何かオリジナルの初期化と動作の差違があるのではないかと思い念のため報告します。
本来そのような特殊な環境化で使うことは考慮する必要は無いと思いますが、オリジナルの物と違う呼び出しを行っているとしたら、思わぬ箇所でエラーが発生する可能性もあると思い連絡した次第です。

こんにちは。
ご回答ありがとうございました。

ttp://www.atmarkit.co.jp/fdotnet/dotnettips/024w32api/w32api.html
を見ていただければ、わかりますか？
上記のリンクで、拡張ツール中の人さんがおっしゃるように関数として
書いていただければC#でも使用できるようですね。

お手数をおかけ致しますが、よろしくお願いいたします。

現状C++のクラスをエクスポートしている形になりますので、
そのままでは無理だと思います。

IBonDriverの各メソッドを直接関数としてエクスポートすれば
C#含めVB等から使用できるようになると思います。

関数の型等について仕様を提示頂ければ対応したいと思います。
(当方、C#については全く無知のため．．．)

こんにちは。
BonDriverについて教えてください。
VC++を使用したことが無いので
C#でBonDriverを使用してみたいのですが使用できますでしょうか？
C#で使用する際の簡単なサンプルなどがあると大変ありがたいのですが。
よろしくお願いいたします。

板違い深くお詫びします。あと一言だけ言わせてください。

「個人の家の玄関の敷居から、著作権は入ることは出来ない。」

つまり、個人が利益を目的とせず家庭でするコンテンツの複製は､著作権の権利の外というのが「複製権」のキーテクノロジー､概念です。
　
消尽（しょうじん）という著作権法上の概念もちゃんとありますが、この複製権はそれを超える
根本的な権利、近代的人権のひとつとして位地付けられるべきものです。学習､娯楽の権利は誰も奪うことが出来ません。幸福追求権､学習権はちゃんと憲法にある権利で創刊単に法律なんかで侵食できない権利です。(憲法に反する法律は無効）

「複製できないことが嫌ならB-CAS契約するな､地デジ見るな」というなら、｢家庭内複製が嫌なら放送するな」と返したい。そもそもB−CASカードのビニールを破くことが契約だという擬制は、｢拒否の余地のない契約は契約といわない、強制というのだ。」
国民の代表が審議する国会で決めた「法律」という法的根拠のない国民への強制は許されない。
今でもNHKの受信料が法的強制を伴わないように�械-CASという民間会社に全国民に何かを強制する権利など許されるわけがない。

彼らも自覚していて｢エンフォース」という言葉を使っているがこれはまさに「強制」のことである。

エンジニアの皆様ご苦労様です。このような優秀な技術社集団が日本の宝であるとすれば、
�械-CASカードに天下って規制している官僚OBたちは日本のダニです。

しかしせっかくの技術開発も規制の網がかかれば、責められるだけの日陰者の立場です。
ハードウエアの拡散（チップ、回路の拡散　セカンド・サードメーカーによる供給増加）
と政治(利権自民党からしがらみにありつけず票のほしい民主党へのプッシュ）さらに「録画権」などユーザーサイドの権利を主張して訴訟を提起する弁護団などが技術開発と並んで三大支柱として必要です。特にに急ぐのは国内へのハードウエアの拡散です。ハードエンジニアやーい

沖縄の軍人による民間人虐殺教科書検定のときのように、フタを開けてみると画策している人間はほんの一握りなのです。

EpgDataCapの中の方へ
Ver6使わせてもらっています。
番組情報周りが大変便利になったのですが、ウインドウのサイズを大きくしたときに、今の状態だと「現在の番組情報」がまず大きくなって、大きくなりきったあとにはじめて「次の番組情報」が大きくなります。
これを、たとえば、現在の番組情報欄と次の番組情報欄の枠のあいだにラインを入れて、そこをドラッグすれば、次の番組情報欄のみを大きくするとかできるようになれば、常に現在の番組情報欄と次の番組情報欄の枠の大きさが同じになって見栄えがいいかな、と。
よろしければ実装のご検討よろしくお願いいたします。

本来ならFriioView側が各プラグインの情報を保持するのがスマートでいいんだけどね
AviUtlみたいに

EpgDataCapの中の人へ
対応ありがとうございます。番組情報簡易表示と文字列右折り返し、確認しました。
もしお時間ありましたら、窓の位置情報記憶を装備していただけるとうれしいです。
今現在だと必ず画面左上にでてくるので・・。

雲行き怪しいですね・・・

メールはこちらで確認できましたが、
返信したところ弾かれてしまうようです。
確認をよろしくお願いいたします。

> Technical details of temporary failure:
> TEMP_FAILURE: Could not initiate SMTP conversation with any hosts:
> [2sen.dip.jp. (10): Connection refused]

メールはこちらに届いてないようです。
お手数ですが、ご確認いただけますでしょうか？

開発お疲れ様です。
「現在の番組情報」だけを表示させるプラグインを別個に単体で作っていただくことはできませんでしょうか？
また、現在の番組情報の欄をいわゆる「右端で折り返す」ようにすることはできませんでしょうか？
今の状態だと右端まで自分でスクロールさせないと閲覧できないので、右端で折り返すことができると便利で助かります。

お時間あるときにご検討いただけると幸いです。

ALOEさん、メール返信しました。
(自鯖なので届いていなかったら連絡ください)

tsの項目は処理した、
間違えて消しちゃったのがあったらゴメンネ

ファイルだけじゃなくて項目も消さないと
アップロードされていたという事実が
「許さない人々」にモロバレですよ。

このご時世、御察し下さい。

どれも404なんですけど。

とりあえずデータ放送の分離サンプルコード書いてみました。zlibは別途必要です。

どんなデータがきてるのかを見るのが主目的だったので、モジュール削除によるデータ削除が実装してない等不完全な所もあります。高速化はあまり意識していないので、FIFOもループバッファではなく単純な実装です。

ＢＭＬは仕様も複雑ですのですぐにデータ放送を実装できるわけでもないですが、何かのお役に立てばと思います。

ソースは一部、全体問わず自由に再利用して頂いて構いません。

今からサンプルいじってる程度なのでDirectShowフィルタ難解すぎる。

理想的には「MEDIASUBTYPE_MPEG2_TRANSPORT」の出力ピンを持つ
プッシュモデルのソースフィルタを作ればいいのだろうが．．．
そうすればDirectShow標準の「MPEG-2 Demultiplexer」を使えて
TSデータの扱いは楽になるのだろうけど。

現状ほとんどのプラグインが生TSを手動で処理してることを考えると
AACとMPEG2のストリームをDemultiplexするまでした方がよいのだろうか。
個人的にはDirectShowを使わない方法で実現したほうが楽な気がする。

BonDriverのI/Fに要望のある方ご意見ください。

その方針というか目的というか願いというか
そんなもの全てを叶える第一歩がGPLですよね。嘘ですが。

クローズドソースにする開発者の多くは
本当に開発できる人間とならいくらでも語り合いたいけど
例えば2チャンネルでよく知りもしないくせに聞きかじった単語並べ立てて
知ったかぶってるような、開発者にとって意味のない人間に四の五の言われるよりは
そういった人間はバイナリさえくれてやってれば喜ぶから
無駄もないし腹立つこともないしその方が楽だとかその程度の軽い理由で非公開な気がする。

お前の技術は俺のもの俺の技術は俺のものみたいなジャイアニズムではないと思います。

色々なプラグインが公開され始めフリーオには無くてはならないものになってきました。
それぞれのプラグインは個性的な機能を持ち今後の発展を1ユーザとして期待しています。
ただソースコードを公開されている作者はほとんど居ないのが現状で、私個人としては
自分だけオープンソースにしていることが空回りしていて無駄に思えてなりません。

プラグイン作者にとって開発を行う動機は様々だと思いますが、私にとっては一つの
趣味であると同時に、開発を行う過程で色々な技術を学ぶことができるよい教材だと
考えています。
実際、私のツールは多くの部分で他の方のソースコードを参考にして作られています。
そのお礼と言ってはなんですが、自分がそれらを応用した成果を他の方にも参考にして
もらい一層の発展と別の可能性に期待してソースコードを公開しています。

善意と言いつつも一方的にソースコードを参考にされ、バイナリだけ公開されるようでは
あまり気分が良いものではありません。仮にそれが全く別のアプローチで実現されていた
としても知りようが無く不信感を抱かざるを得ません。

フリーオのプラグインでもそういった流れで、プラグイン開発者が持つ技術をお互いに
参考にし合い、開発者としても得られるものがあり、プラグインを使用するユーザーに
とっても便利なものになっていけばよいと考えています。

フリーである以上、失うものはないと思うので私に続き「Give and take」となるよう
ソースコードを公開する作者が増えてゆくことを期待します。

お初にお目にかかります。
FriioUtilの作者です。
今回はお騒がせして申し訳ありませんでした。
私はPV3拡張ツールを毎日愛用させて頂いておりますが
今回ソフトを開発するにあたって大いに参考にさせていただきました。
この場を借りてお礼を申し上げます。
スタンドアローンソフトの開発計画にも協力させて頂きたいと考えております。

よろしければメールをください。
friioutil@lopox.com

up0043.zipとup0044.zip
削除したー

up0043.zipとup0044.zip
何故か削除パス合ってるはずなのに消せないんですが消しておいてもらえませんか？

You are persistent.

You should concentrate on mass production than the development of software.

We will open detail of low-level API (no idea why this is needed, anyway)
To whoever demonstrates ability to write,

* MPEG2 demux, section filtering, section parsing, all SI table parsing,
* oh, put multi2 decode somewhere in there,
* how about some directshow for preview?
* anything else?
* How about a BDA driver? Is friio programmers so low-skill yet?

Talk is cheap, let's see some action. Wasting time on a driver is irrelevant, you're forgetting the other 99% of the work that you have no skill to do :)

Yes after you finish your hacked "driver" you have encrypted TS. Now what? :)

We wait eagerly for Santa Claus from Taiwan. You can.

MurdocのWEBページにあるじゃん。

誰かMurdoc MP9 1.01をアップローダに上げてください。
お願いします。

こういうものをもうすぐDLLとして公開します。

class CFriioDevice
{
public:
　　CFriioDevice();
　　virtual ~CFriioDevice();

　　const BOOL OpenDevice(void);
　　void CloseDevice(void);

　　const BOOL Connect(void);
　　const BOOL Disconnect(void);

　　const BOOL SetChannel(const BYTE bCh);
　　const DWORD GetTsStream(BYTE *pDest);

protected:
　　// 以下内部コード
};

＞プラグイン開発者の皆様、基本的にオープンソースで行きませんか？
プラグイン開発者はソース開示しないと
叩かれることになりました。

> see ttp://www.nicovideo.jp/watch/sm1654977
> so we call it "development".

Every other civilized country calls it "pedophilia"

Dear Mr. Friio,

>reinventing the wheel, typical thing you folks do.

your job is very good. we all think highly of you products.
but you have done "reinventing the wheel", too.
everything had been done about 15 years ago :-)

see ttp://www.nicovideo.jp/watch/sm1654977

around 7:37

we are always reinventing the wheel, but something will be produced with it.
so we call it "development".

本家はBDAサポートとか書いてるけど、安定動作しないからなぁ。(って言うかほぼ動かん)
やっぱ独自ドライバはがんばって欲しいな。ノンサポートOSの為にも。

I don't intend to trouble you.
It's just a my hobby.

> If software and hardware of friio are high quality, we do not analyze it
There is no problem with our hardware or software during testing.

> Is your customer not Japanese?
BS/CS Friio will be for more than Japanese. No excuse to make non-unicode appli.

> Your FriioView is buggy and childish for Japanese user.
And your non-unicode app is painful to run on Chinese Windows XP.

By the way, we went through 700 "next resale" mails from Nov 1 to 15 and nothing found from you except order and ship confirm email.

If software and hardware of friio are high quality, we do not analyze it.

Friioに迷惑をかける行為は禁止します。

> And your non-unicode app is painful to run on Chinese Windows XP.

We are Japanese.
Is your customer not Japanese?

And, I am extending your application by very "legal" methods.
No binary modifying, No reverse assembly...

> Your FriioView is buggy and childish for Japanese user.
And your non-unicode app is painful to run on Chinese Windows XP.

By the way, we went through 700 "next resale" mails from Nov 1 to 15 and nothing found from you except order and ship confirm email.

ちょいと調子乗りすぎですねぇ。
解析でも何でもないのにすげぇ高圧的態度。
俄然無視でがんばってください！！

がんがれ！

ちがったorz

つ　ttp://comtech.myweb.hinet.net/pdf/jdvbt-90502.pdf　？

正直オープンな単独ドライバにも期待してます。

I sent E-Mail to you about collaborated development at 2007/11/02.
I have not received the reply yet.

I continue the analysis and development until driver interface is
opened to the public.
Your FriioView is buggy and childish for Japanese user.

shine@2sen.dip.jp

ちなみにチャンネル切替時にドライバに渡すデータは下記です。

(WORD)HHLL = 0x0E7F + 0x002A * (ch - 13)

dwIoControlCode = 0x00220020　nInBufferSize = 43　nOutBufferSize = 43　*lpBytesReturned = 43
TX:40,03,00,30,FE,00,05,00,0A,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,26,00,00,00,05,00,00,00,C0,HH,LL,B2,08,

dwIoControlCode = 0x00220020　nInBufferSize = 43　nOutBufferSize = 43　*lpBytesReturned = 43
TX:40,03,00,30,FE,00,05,00,0A,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,26,00,00,00,05,00,00,00,C0,HH,LL,9A,50,

この後、数十回固定のデータを送信する。

TC90502XBGのデータシートどこかにありませんか．．．

what is the point of rewriting friio application.
you're just wasting everyone's time.
you didn't even bother contacting friio developers if you wanted to help.
reinventing the wheel, typical thing you folks do.
if you want to cooperate on appli development, contact, otherwise, shine.

ちなみにドライバ自体の解析をしているわけではないです。
とりあえずFriio標準ドライバを使って動作するアプリを考えています。

DeviceIoControl()のやり取りを見ているとアプリからかなりローレベルの
制御を行っているようですが．．．

I2Cへの送信データと受信データがネックかも知れないですね。
せめてチャンネル切り替えはしたいところかと。
仕様書をみるとPLLのI2Cアドレスは0xC0のようですが多分TC90502XBGの
スルーモードを使用していると思うので、送られるデータは憶測ですみませんが、
0x30(90502アドレス),0xFE,0xC0(PLLアドレス),data・・・じゃないかなと思います。
0xFEは一世代前の復調チップがそれだったので同じじゃないかと・・
data・・・はJDVBT-90502のbyte2〜になります。

・Friioの初期化
・MULTI2復号前TSデータの取得

はできた。

今はチャンネル切替シーケンスの解析中．．．

BCASのアクセスはSHARE設定でお願いしたいです。
将来的に二台同時接続してもBCAS一枚で済むようにしたいので。
大変かと思いますが応援しております。

今はドライバI/Fの解析を進めており、近々TSデータを垂れ流せる
スタンドアロンのツールを公開する予定です。
(プレビューなしのFriioView相当)

固まり次第、拡張ツールも一通りの機能をそろえるようにします。

それ以降はスタンドアロンのツール開発に移行し、拡張ツールを
単独のアプリとして提供します。

旧Friio toolsにあった、320ピクセル表示の機能を追加してもらえないでしょうか？

僕も技術があれば参加したいですが
がんばってとしかいえませんorz

B-CAS制御/Multi2暗号復号、ドライバ制御．．．

FriioView相当のアプリを1から作れる環境が整ってきたような気がします。
みんなでがんばりませんか？

なるほど・・・乙！
テスト8を試してみたところチャンネル設定もちゃんと記憶するようになった。
自分の環境ではプロセスが残るのもなくなったっぽい。

2chはプロバイダ規制で書き込めないのでこちらで．．．

プロセスが終了しない不具合は確認しました、原因解析中です。
録画ボタンは今のところ未実装です。
(Friio側のタイマを無効にする必要があるため。)

こっちに掲示板があるとは知らなかった
この掲示板の方は見てると思うので書きこんだ以下同文を↓

458 名前：名無しさん＠編集中[sage] 投稿日：2007/11/25(日) 15:25:31 ID:77EsWk2N
拡張ツールの中のひとへ

「Friio拡張ツール」のテスト7つかってんだけど
チャンネル設定しても一時的には覚えるが終了してもう一回アプリを起動させると
チャンネル設定するか？のダイアログがまた出てリセットされてる

あと録画ボタンが灰色のままでつかえん。
右クリでならいけたけど

PV3の時はお世話になりました。
今回のfriioツールですが正直デザイン使い勝手ともに
あまりよろしくないかと思います。
具体的には選局ボタン等が大きすぎるのが個人的には
スマートではないと思います。
最終的なデザインがはっきりと見えてこない感じです。

おおーもうすぐ繋ぎの駄DLLをメンテするのから解放されますねっ
iEPG系のツールとやりとりする方法を決めておいた方がいいと思うんですがどうですかね？
オープンソースなことだし勝手にやっちゃえな感じなのかな

とりあえずガワはできたと思います。
まずはFriio標準ウィンドウと同等の操作を行えるGUIを作ることにします。

　・チャンネル切替
　・録画/停止
　・ステータスバーに情報表示
　・簡易タイマ

それ以降はオーバーレイ、DirectShowFilter関係をいじる予定。

　・アスペクト比変更(超額縁、サイドカット)
　・静止画キャプチャ(できればメモリプレイバック機能付き)

さらに究極はFriioViewをTSデータのソースとしてのみ使用し
録画、プレビュー系を再構築？

→PV3の掲示板に移動させて頂きました。(拡張ツール中の人)

製作がんばってください！
PV3のも愛用してますし、拡張ツールの本命として期待しています！

削除しといた。
アクセス禁止関係はわからないので中の人に任せよう、。

削除 up0010.htm friio注文フォーム

↑はどこかのサイトにPOSTメソッドでデータを自動送信する不正なJavaScriptです。
ファイルの削除と投稿者のアクセス禁止をお願いします。

市販のレコーダーと同等の機能なんて求めておりませんのでよろしくお願いします。

期待してます、頑張れ〜！

Friio入手おめでとうございます。
ツールを作成するとの宣言ですが、期待しています。
PV3拡張ツールと同等を目指すとのことですが、個人的なワガママをいうと、
市販のレコーダーと同等の機能がおそらく多くの人が求めている姿だと思いますのでそれをイメージしていただければと思います。
もちろん、市販のレコーダーと言っても抽象的な表現だと思いますがｗ
プラス静止画キャプチャ機能が拡張ツールと同様に充実していれば嬉しい限りです。
あと、今回もソースを同梱されることを望みます。
がんばってくださいね。

BS対応まだぁ？

複数行の書き込みが出来る掲示板を設置しました。
ツールへの要望や情報交換にご活用ください。