IPv4枯渇時計

http://www.inetcore.com/

より。
ただ、デザインではNHK時計と共存できないし、下半分欠けるんですよねぇ。。
うーむ。

IPv4枯渇時計

TalkMasterII -> ZEN MX

AMラジオをタイマー録音できる元祖的存在のTalkMasterIIで録音したMP3データをクリエイティブのZEN MXにPCを使わずにインポートするときのドタバタのまとめ。

TalkMaster IIの情報はこちら
ZEN MXのじょうほうはこちら

ちなみにSDカードはパナソニックのちょっと古い512MBのSDカードです。
なお、どちらもファームウェアは現時点での最新版です。

まず、TalkMaster IIでフォーマットした場合、ZEN MXではサポートしてないフォーマットというメッセージが出て×。
で、PCで調べたところ、FATでクラスタサイズが32KB。クラスタ数は 16Kよりちょっと少ない。

じゃぁ、PC(WinXP)でフォーマットすればどーだ、というわけで、標準のクラスタサイズでフォーマット。
するとZEN MXでは認識するけどカードの読み取り時にハング。。。
そのときのクラスタサイズは8KB、クラスタ数は 32Kをはるかに超えて64Kよりちょっと少ない。ってことはWinNT向けだね。昔のDOSはクラスタ数も32Kを超えられなかったはず。録音データの大きさ(28MBがふたつほど)からいって、クラスタ番号がそれほど大きくなってないと思うけど、、、、。

後の可能性というわけで、CMD.EXE開いてFORMATコマンドでFAT、クラスタサイズを16KB指定でフォーマット。
これなら、クラスタ数も32K未満になるしね。
で、うまくインポートできました。。。

というわけで、メモでした。

本質的な改善は何もない模様

『貴方の情報、流出されてしまってませんか？』

のその後ですね。

例によってImpressさんの記事を参照しておきます。
『「ストリートビュー」カメラの位置を40cm低く、全エリアで再撮影

表札のぼかし処理リクエストにも対応』
http://internet.watch.impress.co.jp/cda/news/2009/05/13/23412.html

私が考える本質的問題とは最初にリンクしたエントリにも記載していますが、
「自分達で作成したコンテンツの内容を責任を持って確認した上で公開することを放棄している。
言い換えると、自分達で作成したコンテンツに対して無責任である。」
ということです。

残念なことです。

地デジ普及を本気で考えているなら

地デジ（個人的には「地上波テレビをVHF帯から追い出してUHF帯に移すのに、実はUHF帯に移すだけならアナログのままでよかったんだけど、何か口実がないと主要VHFキー局などに反対されるところを説得するためにデジタル化を餌にした政策」ではないかと思ってる奴ですが）、総務省らはSMAPの草薙氏などのテレビCMをしたりしていますが、まだまだ他力本願な戦術としかいえませんよねぇ。

このままでは「2011年7月25日。日本では地上波テレビは（アナログ）ラジオ以下の聴取率となった」なんてことになっても不思議ではない:-)

冗談はさておき、地デジ普及の主な障害を列挙すると、

1. 受像機が対応しているか？
2. アンテナ（あるいは共同受信設備、またはCATV)が対応しているか？
3. その地域の送信所が対応しているか？
   

の3点となると思います。

このうち3.に関してはもう放送業界を脅してでも総務省がやらせるってことしかないでしょうねぇ。これが遅れればVHFアナログテレビ放送の停止日をずらすしかないわけで。

2.に関しては場合わけが必要で、CATVの場合は当面アナログ変換再送信を認めるかSTB専用に再送信すれば受像機問題も回避は可能。その後ろ向きな対処はおいといて、やはりここは周波数変換でも同一周波数でもどちらでも構わないので、パススルーさせるようにこれも総務省が脅す:-)
パススルーが極めて困難な状況ならアナログ変換再送信させればよいわけでね。

アンテナに関しては自前で持っていればね、アンテナそのものは受像機よりはまぁ安価だし、自前のアンテナを立ててるのなら、まぁ何とかなるでしょ。設置手数料の補助ぐらいあってもいいかもしれないけどね。
問題は共同受信設備でね。これの入れ替えはアパートやマンションの規模がでかくなるとコストがねぇ。VHFのみを前提とした配線だともっと問題だし、、。

まぁその辺はおいといて、1.の受像機問題について。総務省では安価なチューナー（アダプタ）を、と言っているけど俗に言うフルセグでは限界があるでしょう。B-CAS認定などもあるしね。一方、テレビ本体はkakaku.comで見たら8000円ぐらいのがあります。と、いうことはこの値段を最低でも下回らないといけません。

そこで思いついたのは「ワンセグ」です。どうせ14インチクラスならワンセグのQVGAでなんとか耐えられる画質で妥協できると思うんですよね。しかも、ワンセグならチューナーの値段はPC向け周辺機器でわかるように安いことは一目瞭然。一応携帯（液晶）テレビでも1万ぐらいまで落とせている模様。。
だとすれば、次のようなスペックなら5000円ぐらいにはできるのではないか？

ワンセグ（データはなし）、出力はRFコンバータのみ、リモコンはカード型の安物。
電源はACアダプタで、本体の端子は電源、RF入力、RF出力のみ。スイッチは電源スイッチとRF出力のチャンネル切り替え(1/2ch)。あとはリモコン用赤外線受光部のみで、14inchテレビの上に置けるようにコンパクトに。
あーそうそう、アナログLPF入れてブロックノイズをぼかすようにしてその程度を調整できるようにしてもよいと思う:-)
当然、タイマー録画対応なんてのは考えない。（考えても良いけど、STBなんかでやってる方式ですね。）

どうでしょう？
開発期間もそう要らないと思うしねぇ。。

貴方の情報、流出されてしまってませんか？

この記事を書いている時点でGoogleはこの件について自らのプレスリリースを掲載していませんので、とりあえずImpressの記事を二つリンクしておきます。

『Googleマップの「ストリートビュー」機能、日本でも開始』
http://internet.watch.impress.co.jp/cda/news/2008/08/05/20479.html

『「ストリートビュー」のプライバシー問題、グーグルが方針説明

不適切な画像はユーザーからの報告で対処』
http://internet.watch.impress.co.jp/cda/news/2008/08/05/20489.html

一応関連リンクも。
『Googleプレスセンター』（この件について、貴方がここを閲覧しているときには既に問題の解決や何らかの姿勢の公表などが行われているかもしれませんが、この記事を書いている最中にはサービス開始の表明も含めてまだ掲載はありません。）
http://www.google.co.jp/intl/ja/press/

『Googleマップ ストリートビュー』
http://www.google.co.jp/help/maps/streetview/

ご存知Google Mapsのストリートビューですが、後者の記事によると画像はGoogleのスタッフによって撮影・編集されたものだということです。
ですが、記事中で『また、不適切な画像については、ストリートビューのヘルプ画面に「不適切な画像を報告する」というリンクが用意されているため、ここからユーザーからの連絡を受けて対処を行うことで対応していきたいと述べた。
』とあります。

このことから、私が理解したのは、「Googleは自ら撮影・編集したものであっても、自ら責任を持って問題がないかどうかを確認することなく、Internet-Wideに公開する」ということです。

彼らはある種の自動化技術によってある程度プライバシー保護をする工夫をしているようですが、それが完璧でないことも認める説明もあります。『ただし、こうした処理が完全ではない場合もあるため、問題のある画像については報告してほしいと説明。』

これは「自らが撮影した写真を公開する」ということを業務の一環として行う企業体としては、責任を放棄しているように思えます。

実際に、自動車のナンバーや窓から室内の様子が見て取れる事例もあるそうです。私もある店の看板の電話番号がぼやけているものの、かなりの高確率で類推できると思われる事例も見ました（看板にあるのなら公開しても、、と思うかもしれませんが、たとえば毎日日本のあちこちから用もないのに電話をかけられたら業務に支障を来たすでしょう）。

私はGoogleの開発・実現する技術にはすばらしいものがあると思いますが、今回の件は企業体の倫理観に疑問を持たざるを得ないのではないかと思います。

YouTubeではないのだから、自分で撮った写真の内容ぐらい、自分で責任を持って欲しい。
一度流出した情報の回収が困難であることは言うまでもないのだから。
もし、人手などによる十分な事前検査がサービス提供で得られる収入に見合ったコストでできないというのであれば、同等の精度で検査を低コストで行えると「胸を張って言える技術」を開発して用いるのが、技術屋でしょう。それもせずにサービス開始してしまうのは収入の為に問題に目をつぶっているとしか思えません。

せめて、多くのspammerがやっているopt-outのような申告方式をとるのをやめて、opt-inであれば、まだ救いがあるのですが。

この手の問題には私は疎い方ですが、それでも問題を感じたことなので、（どれほどの人が見ているかはわかりませんが）、ここに書いた次第です。

師走ネタ

唐沢俊一氏が2007年12月27日分の裏モノ日記のタイトルに
「師走だなぁ。ぼかぁ、君といるときが一番師走なんだ」
http://www.tobunken.com/diary/diary20071227140541.html

というのを取り上げていますね。
これはかの有名なタモリの発禁アルバム「タモリ3」のネタだと思うのですが、それには言及はありません。
もっとも、受けが違いますけどね。。。

まぁ唐沢氏がこのようなネタを知らないとは思えないので、意図的なんだと思うのですが、、。

PHS: Willcom端末のNetFrontでGmail認証できない

という話題があちこちに出ています。
たくさんあるので、個別リンクは省略します。

世ではGmail(Google)の認証などのHTTPS(SSL)通信の失敗だけが言及されていて、そのせいかWillcomからはGoogleに問い合わせて欲しい旨の対応をされたと書いている方もいます。

で、私は別にSSL通信できない例を発見しました。

http://jvman.jp/

の右肩にある「MyページLOGIN」を選ぶと「SSL通信ができません」と表示されてリンク元の画面に戻ります。
（このページは期間限定だと思うので、そのうちアクセスできなくなると思います。）

Gmailの場合に比べて

・SSL通信ができない旨のメッセージが明確に表示される。
・通信が終了することはない(PTなどの表示はそのまま）

という違いはありますが、なんだかなという感じですね。
ひょっとするとサイト証明書の暗号化鍵のビット長が決めうちで、それを超えると駄目だとか。。
（jvmanの場合はプログラム中でエラーになって表示するけど、Gmailの場合はバッファオーバフロー起こしてるとか言うギャグを思いついたけど、、、さすがにそれはないと信じたい。）

とりあえず、Willcomのサポートに問い合わせを送りました。果たしてどうなるか？
(nineの製造元にも送った方がよいかなぁ??）