Hatena::ブログ(Diary)

What will be done tomorrow? RSSフィード

2017-07-19 (Wed)

GPD Pocketがなかなか来ないなあ

| GPD Pocketがなかなか来ないなあを含むブックマーク

GPD PocketがいろんなGPD社の事情によってなかなか発送されず微妙な気分になっている人たちが沢山居るんだけど僕もその中のひとりだ。


正直7〜8インチタブレット+小型軽量のBTキーボード、という組み合わせと比べた場合、あまり違いはないのではないかなーと思わなくもないが、膝の上に載せて使えるというところは非常に大きいメリットのような気がする。それ以外の部分ではメモリが多いとかZ3735Fとかと比べるとCPUも1.5倍以上高速だとかいろいろあるとは思うが、あまり支配的な要素ではない気がする。

ひねた見方をすると、かばんに入れて持ち歩いているときの重量ではiWork7(270g)+KKmoonキーボード(130g)のほうが100g近く軽い。重たくてちょっと大きくても平気、みたいな人だったら85000円くらいまで値下がりしてきているLAVIE Hybrid ZERO HZ300/FAというやつのほうが画面大きい・CPUはGPD Pocketの2倍くらい速い・キーボード配列が素直って感じなので、GPD Pocketが圧倒的に素晴らしい、って感じでもないのだ。


僕があまりイライラせずに待てているのはiWork7とかmiix2 8とかの代替手段をすでにいっぱい持っているからってのと、最近気力がなくてやる気も出ないので「別に来ても来なくてもどっちでもいいやー」みたいな感じになっているところが大きい。後者はあまりいいことではない。

トラックバック - http://d.hatena.ne.jp/naoya2k/20170719

2017-07-11 (Tue)

洲本-深日航路の社会実験が始まってた

| 洲本-深日航路の社会実験が始まってたを含むブックマーク

d:id:naoya2k:20150309:p1 「和歌山と淡路島をつなぐ深日航路は復活できるのだろうか」で否定的なことを書いていた洲本〜深日港の旅客輸送なんだけど、なんとこの6月25日からの3か月間、毎日4往復の定期運航を行って需要調査する社会実験が始まっていた。


http://awaji.tv/www/info/detail.jsp?id=33008 (淡路島TV記事)

平成29年6月25日から9月下旬までの3か月間で、

1日4往復、合計8便が運航され、

片道の所要時間は、およそ55分となっています。

洲本港の始発は、午前9時40分で、

深日港発の最終便は、午後6時となっています。

乗船定員は68人で、

料金は片道で大人1500円、こども500円、

小学生未満は 無料となっています。


また自転車は、専用のキャリーバックに入れておけば、

無料で持ち込むことができます。

http://www.town.misaki.osaka.jp/umi/doc/pilot_cruise.pdf (岬町のサイトにあるパンフレットPDF)


55分。子供のときの記憶で30分くらいだと思ってたのだけど結構時間かかるんだなあ。あと1500円ってのもちょっと値が張る感じ。高速バスで洲本-三宮が1800円/約90分、洲本-梅田が2350円/約120分ということを考えたら、やっぱり大阪に行くにはバスの方がそれなりによさそうで定期的に使うには厳しいかも、みたいな感じ。

でも自転車持ち込みをアピールしているところなんかは抑えるべきところは抑えているようにも思われ、TravelVisionの記事には「バーベキューが楽しめるプランや洲本温泉に入浴するプランも用意し」とあるのでそのへんが魅力的に映れば需要も喚起できるかもしれない。


ただアピール足りてない感じはある。「深日 洲本 船便」などで検索しても出てくるのはニュースサイトで社会実験を始めるということを伝える記事だけで、実際に乗る人にとって有用な一次情報アクセスできない。一次情報っぽいやつで一番上に見つかるのが

http://www.town.misaki.osaka.jp/fukeport/port_index.html 「深日航路再生へ向けて」という岬町のページなんだけどここの最後アップデートが「平成29年2月28日」というのはちょっと残念な感じがした(上にリンクしたオフィシャルっぽいパンフレットPDFにはどうやってたどり着いたのか思い出せないくらいだし、温泉とセットのプランなどもまだ発見でいていない)。


合理的に考えたらいろいろ厳しい感じもするけど、船便はバスと違ってなんだかんだ楽しいので定着すると嬉しいなあと個人的には思う。

トラックバック - http://d.hatena.ne.jp/naoya2k/20170711

2017-07-09 (Sun)

スクフェス等と相性の悪いAndroid端末について(2)

| スクフェス等と相性の悪いAndroid端末について(2)を含むブックマーク

d:id:naoya2k:20170610:p1SH-02Fとラブライブスクールアイドルフェスティバル(スクフェス)との相性が悪かった件について書いた。その後たまにスクフェスやアイドルマスターシンデレラガールズ(デレステ)をやっていたのだがどう考えても正しくタップしているつもりなのにMISS判定が出て納得が行かない現象が多発していてその原因を探っていた。


そのうち、特にデレステのほうで、交互連打のようなシチュエーションで頻繁に発生していたMISSの原因について、なんとなく推測がついた。

SH-02Fのタッチパネルは2本の指で交互連打を行うと、片方の指が画面から離れた直後にもう片方の指が画面についた場合に、1本指でスライドしたように入力されるのだ。だから交互連打の譜面が来たら正しくタップしていてもアプリには正しくなく伝わってしまう。


これはタッチパネル構造上仕方ない面もある。タッチパネルでは周期的に静電容量をスキャンしている(国産の初期のスマートフォンではこの周期が画面の表示の周期と合ってなくて指でなぞる操作をしたときにガタガタしたりするといったような、基本的設計ができていなかったりしてアホかと思ったものだ)。あるタイミングで左の指の一本の接触だけ検知されていて、次のスキャンのタイミングで右の指が一本だけが接触しているような状態だったら、タッチパネルからはそれが別の指かどうか判別できなくて、一瞬で指が動いたように見えてしまう。


原理上仕方ない面があるとはいえおそらくSH-02Fのタッチパネルドライバは短い時間なら指が離された場合でもタッチが継続したと判定するような制御を行っている。静電タッチパネルノイズに弱く、ある程度そういう制御がないとユーザからすればドラッグ操作の途中で指が外れたような判定をされてしまったり、指をタッチパネルに置いて長押ししているだけなのになぜか連打になったりしてしまう。ハードウェアでのノイズ対策ケチったり軽量化とか防水とかTVアンテナとかのために無理な設計を強いられたりしたしわ寄せなのかもしれないと推測してしまう。


Androidの「開発者向けオプション」の中の「ポインタ位置: 現在タップデータをオーバーレイ表示する」をONにして確認してみた結果が下記である


f:id:naoya2k:20170709165906p:image

これが二本の指でタッチしたときのスクリーンショットである。この左上側の指と右下の指を交互に連打すると下のようになる。

f:id:naoya2k:20170709165907p:image

ちょっと連打するとあっさり間に線が引かれてしまう。これは左上から右下 あるいはその逆に指が動いたと判定されたということだ。交互連打譜面でこれが発生すると当然タップしていないと判定されてMISSになってしまう。これはつらい。もちろんこの交互押下の2本の指の間が十分に離れていればアプリ側でも(急な遠距離の移動は指が変わったと判定するなどで)がんばってスライドとの見分けがつくように判断することも可能かもしれないが、スクフェスとかデレステのように顔アイコン位置が隣接しているとそれも難しいと思う。


Nexus7 2013で同じことをやってみたがちょっと試したくらいで線が引かれるようなことは全くなかった。前回の現象と異なり、これについては店頭でもすぐに試せそうなのでAndroid端末を選ぶときにはこれを店頭にある端末で確認してからにしようと思った。

トラックバック - http://d.hatena.ne.jp/naoya2k/20170709

2017-06-13 (Tue)

Android端末のCPU制御のこと続き

| Android端末のCPU制御のこと続きを含むブックマーク

土曜日で書いたAndroidスクフェス挙動に対して「勝手に省電力モードに入ってしまい」というような意訳のブコメがついていたんだけど、自分の中では省電力モードかいイメージでは全然なかったのでちょっと違和感があった。もう今時のコンピュータではMAXよりも下のCPUクロックで動くのが平常運転であり特別モードではない。車に例えれば6速ATでずっと2速で坂を上ろうとしていたのに突然平地になって4速に上がってしまい次に来た上り坂でガタガタしちゃった、みたいな感じ。そのときの4速は燃料カットのような一般想像される省エネモードとはちょっと違う。


なにやらよくわからないがモバイル向けWebページはどんどん重くなっているしアプリ起動時などにはやはりCPUパワーが必要になるので瞬間最大CPUパワーは上げていかざるを得ない。一方で延々と処理をしつづけるWebページや無駄に3Dアニメーションが動いている非リアルタイムゲームなどでそんな最大CPUパワーを使うと電池の無駄なのでCPUパワーを下げなければいけない。このへんをアプリから情報なくしてOS判断するのは非常に困難である。同じスクフェスの中でも練習特別練習相手を考えているような場合には電力消費少なくしておいてほしいし、シーン切り替え時やライブ中は十分なCPUパワーが供給されるようにしてほしい。結局のところそんな判別は無理なのでOSに「このアプリ、あるいはこのActivityが画面に出ているときは高速に動いてくれ」みたいなリストを持たせる方法となり、結果的にそれがベンチマークブースターだとか言われて批判対象になったりしていた(本当に最近の状況はよく知らない)。


ASUS端末のGame GenieとかSamsung端末のGeme Toolsなどはそういう部分の設定ができるものなのかと思っていたのだがどうもそうでもなさそうでちょっと残念。

トラックバック - http://d.hatena.ne.jp/naoya2k/20170613

2017-06-12 (Mon)

なぜ僕たちにハイレゾが必要なのか

| なぜ僕たちにハイレゾが必要なのかを含むブックマーク

http://qiita.com/keiya/items/c994c200e8b38b6c7935

に書かれていることは半分間違っていると思う。個人的意見では48kHzより上のサンプリング周波数は要らないが量子化ビット数は20bitくらいあるべきだ。まあ24bitが都合いいのだろう。つまり24bit/48kHzがもっとメジャーになってほしい。24bit/192kHzは不要というのは同意できる。


もし録音したい対象が一つの楽器群だったり一人の声だったりするならそれは16bitの分解能で十分だろう。65536段階の位相が表現できるからだ。しかし僕らが聞いているのは大量の楽器が詰め込まれたオケに、9人の歌声が重なった楽曲群である。9人の声を同音量で重ねて音割れを許容しない場合、一人の音声データのピーク位相を3640くらいまでに抑える必要があり、12〜13bit相当の音質になる。で、それで十分なのか? という話である


さらにオケが入るとさらにボーカルのダイナミックレンジは半分くらいに下げないといけなくなるかもしれない。そうするとミックスされた音声に含まれる一人の声の分解能は11bitくらいまで下がってしまう。そしてそれが問題ないのかというとちょっと問題あるような気がするかも、という感じ。


冒頭のリンクのサイトではバイクの絵で256色でも問題ないと言っているがそれはバイク単体の絵だからであって、風景にめちゃくちゃ明るい太陽や木々がありバイクが逆光で非常に暗く描かれており微妙明暗必要な絵だった場合に「バイクが真っ黒に塗りつぶされてしまっても全体の傾向は変わらないしいいよね」といっているような話である。9人が歌って素人には聞き分けられないから花陽の声は潰れてもいいよね、とかではダメなのである



(とか書いているが自分ではハイレゾ音源は持ってないどころかSBCのBTイヤホンを使ってるような適当な人間なのであまり自信がない)

トラックバック - http://d.hatena.ne.jp/naoya2k/20170612

2017-06-10 (Sat)

スクフェスと相性の悪いAndroid端末について

| スクフェスと相性の悪いAndroid端末についてを含むブックマーク

ラブライブスクールアイドルフェスティバル(スクフェス)とAndroidはミョーに相性が悪いという不満を家族からぶつけられていた。スクフェス自体はそこまで重たいゲームではないのだがAndroid端末によってはガタついたりタップの反応が良くなくてまともにゲームができないらしい。ということで僕も余らせてたSH-02Fという当時ハイエンドの性能を誇っていた端末に入れて試してみた。


結果はひどいものだった。まずフレームレートが安定しない。正しいタイミングでタップしているはずなのにBADやMISSになる、挙句に曲の途中で0.3秒くらいフリーズするというような現象が発生しどれだけ設定を弄っても改善しない。比較対象としてアイドルマスターシンデレラガールズスターライトステージ(デレステ)を入れてみたが、こちらも似たような現象は発生するものスクフェスよりはましである


設定変更の一環で

・描画負荷を減らすためにレンダリング解像度を落とす(adb am display-size 720x1280などをやる)

・サーマルスロットリングをさせないように冷え冷えの場所でやる

などをやってみたが現象はあまり改善しなかった。


2週間ぐらい断続的に考えた結果、そもそも処理が重すぎてガタついているわけではなく、処理が軽いせいで変なことになっているという可能性に思い当たった。デレステでは2D軽量より3D軽量にしたほうが安定しているような気がしたのだ。スクフェスは処理が軽すぎるせいで、スマホCPUが「あ、さぼっていいや」と判断してしまった結果、直後に来た処理にリアルタイムに反応できない状況になっているのだ。多分、直近のCPU使用率が下がっていたらCPUクロックと電圧を下げる、みたいな制御が行われている。ゲームの譜面は緩急がついており、その緩の部分で下がったCPUパワーのまま急のゾーンに突入する、そうするとフレームレートは下がるしタップの反応も遅れ、ゲームとしてむちゃくちゃになる。


これを改善するために裏で無駄CPUパワーを消費する処理を動かしてみた。下記のようなスクリプトadb shellで動かした。

while true
do
echo "!!"
sleep 0.01
done

結果として上記スクリプト実行中はゲームの滑らかさが大幅に改善されかなり安定して60fpsが維持されるようになった。タップ不安定さはまだちょっと残っているが。で、結局こういうことしないとゲームがまともに遊べないんならちょっとつらいよね。端末によって違うし表面上のスペックでは全くわからないよね。悩ましいなあ、

2017-05-24 (Wed)

docomo withで不公平感解消ってどうなの?

| docomo withで不公平感解消ってどうなの?を含むブックマーク

残念なのか良かったのかわからないけどもうドコモから離れてしまったので悩む必要はなくなっている。もしドコモに留まっていたら今回の施策にいろいろ悩んでしまったに違いない。


今回新プランを選ぶためには新しい端末を購入する必要がある。Arrows beかGalaxy feelで、これを使い続ける限り1500円引きということだ。iPhone SE 128GBの月々サポートは税込1566円つまり税抜では1450円となっていて少しだけ今回のdocomo withのほうが割引が大きい。そういう意味ではまあ妥当な感じである(しかもドコモiPhone SEアップルストア価格より3240円高く、それを踏まえるとiPhone SEの月々サポートは実質1325円くらいしかない)。



とはいいつつも、下記の狙いを聞くと微妙な気分になってしまう。

http://k-tai.watch.impress.co.jp/docs/news/1061428.html

プランを導入する背景や狙いは何か、代表取締役社長の吉澤和弘社長は「ドコモに留まって欲しい」「不公平感の解消」の2つだと語る。

制度をころころ変えてるってのは、その1点だけでかなり不公平なんだよ。今回のプランが導入される直前に機種変した人は今日どんなふうに思ったのかを考えればわかるはず。


もし僕がドコモに留まっていたら今まだドコモ的には僕の使用中の機種はSH-02Fだったと思う。そしてそれを買い換える必要もまったくない。なぜなら実際に使っているのはSO-05Dであり、それに代わる端末はドコモからは当面出なさそうだからだ。たまたま「そろそろ機種変だな」と思ってた人だけが恩恵に預かれるような料金プランのどこに不公平感の解消の要素があるというのか。


しかも上記記事によれば今後「docomo with」対象機種を拡充していくという。これがどこまで吉澤社長の言葉をそのまま伝えているかからないが、今回「Galaxy FeelとかArrows Beみたいな端末しか選べないなら要らない」って思ってXperiaを買って、もしその直後に対象機種に追加されたら、納得できるだろうか?

トラックバック - http://d.hatena.ne.jp/naoya2k/20170524