ダークソウル v1.05

もう今更だけどマッチング改善パッチについて

生身ホストだと、侵入も白サインも入れ食いな感じ
もうSLもそれほど気にしなくてよくなった
侵入のSL上限撤廃もあってか生身だと侵入が多くて攻略しずらい（難しいんじゃなくて邪魔なくらい侵入がくる）

今が買い時かもしれないね
発売日組は乙（私もだけど）

ダークソウルの修正が神すぎる

早速2キャラ目作った
盾が弱体化したおかげで難易度があがったような気がする。おかげでかなり新鮮な気持ちで遊べてる。ただ難敵だった首なしとかがなんだか弱くなった気がする。他、強靭の高い人型が手強くなったように感じる。ハベルさんとか森の騎士とか

装備も道具も揃ってる1キャラ目だと印象は逆だった。4周目の最初だけど敵の目がワルくなって囲まれにくいし技量キャラだから火力上がってすごく楽になった。

マッチングはまだダメだね
SL30でサイン見えない拾えない
森バイトも呼ばれない
攻略は別として、対人は平和霧盾とかバグエンチャとか速射が出来なくなってお子様がゲオに走ったせいもあるかもね
それもあってネガキャンもすごい

ダークソウル買ってきた

オンラインでプレイできない不具合のせいで祭りになってる模様

もともとソロでやるつもりだったからオフでも害がないのでそのままプレイ中
フリーズの不具合は三日間やって二回経験した。ゲームのせいなのかPS3のせいなのかはわからないけど、フリーズを再現する方法によく似た状況でフリーズしたのでバグっぽい。
病み村で猛毒状態のときに敵の攻撃と毒死と回復を同時に行なったところ瓶を飲んでる動作のまま死ぬ事もままならないまま停止した。
あとは牛頭デーモン前の黒騎士との戦闘中に一度。
それ以外は処理落ちも無い。2chのゲハとかニュー速あたりに書き込まれているような
一時間のうちに5回もフリーズとか、PS3を初期化しなきゃいけなくなったとか、処理落ちで遊べないとかいうことはないな。
そういうのって初期型筐体のせいで起こる熱暴走との兼ね合いなんじゃないのかね、と思ってみたり。でも最近新型PS3でも起きると言ってる人もいるしよくわからないね。
少なくともアマゾンとか2chで言われる程、酷い不具合はないなぁ。PS3アンチによるネガキャンと便乗したお祭り好きの悪ふざけが度を越えてるんじゃないのかなと思う。まあ…いつもの感じだわね。
冷静に見てみると、デモンズの系譜の作品としては良くできてるなと思う。続編ではないのだけれど、操作はほぼ共通だし、自キャラの動きとかも違和感はない。
ストーリー的にも悪くはない。
デモンズと比べて難易度が上って無理ゲーになったとの意見も見られたけど、私はむしろ逆だと思う。レベルや武器の成長度によっては勝負にならない敵もいるけども、全体的な難易度はさがっているように思う。ただ個々のステージ的な概念が薄くなったおかげで、強化してから来たほうがいいところに迷いこんで絶望する可能性は増えたね。前作で言えば装備も貧弱でスタミナも低い段階で巨大腐敗人2匹か金骸骨を複数相手に戦え的な難しさだろうか。
箇条書きでまとめてみる
■良かった点
・装備が増えた
・敵が増えた
・世界が広くなった（ステージが増えた）
・システム的な部分が醸しだしてる雰囲気を凡そ継承してくれてる
・防具の強化ができる
・廃墟や遺跡、洞窟探索的な雰囲気は良かった
・不用品を処分してソウルに変えることができる（進行による）
・低Lv鍛冶用の石が簡単に入手できる
・侵入が消耗品化（しつこさが無くなる）
・かっこいい盾がいっぱい
・死んでも弱体化しない
■悪くなった点
・パリィがイマイチ使えない（特に後半は失敗時のリスクもあるし、そもそもパリィ不可の攻撃が多い）
・敵の追跡がしつこい（どこまでも追ってくるので、逃げても仕方ない）
・敵がこちらに気付く速さと距離の長さ（相手は米粒ほどに小さく見えてても気付いてすっ飛んでくる） 。これのせいで囲まれるシチュエーションが多すぎる。
・デモンズにあった異常性（ラトリアの雰囲気や王城の死んだ街感みたいな）が無いせいで、ダークファンタジーって感じではない（暗さはあるけどデモンズのそれとは違う）
・アイテムが高い
・ザコが強い（物量的な意味合い）、ボスが弱い。道中の苦労とボスの難易度の釣り合いが取れてない。
・矢の入手が面倒
・魔法が回数制限
・隠密は消えないけど、盗賊は消える
・前作みたいな濃い人物が少ない（フロム脳非活性に繋がる）
・敵のグロさは増したけど、嫌悪感や恐怖感みたいなインパクトは薄くなった
・前作でのソウル体的なものの代りに亡者化、見た目が透けるとかじゃなくて爺婆化する（能力は落ちないので攻略中は亡者のままでいる場合が多い…）
・火炎壺と金松脂はバランスブレイカー
・呪いは拷問すぎる（効果も解呪の手段も）
デモンズでは雑魚戦は極力パリィ狙いで、ボス戦は回避と盾受けっていう感じでプレイしていたけど、ダークソウルは基本盾受けだけで何とかなるのとパリィが可能か不可能かわかりにくい、後半に敵が巨大化していくとパリィは不可能になってくるし、致命も取れない場合もあり手数を稼ぐのに槍か刺突剣での盾チクメインになりがち。大型武器は狭いステージで回避を頑張りながら少ない手数で攻めなきゃいけない。逆に小さいものや人間サイズのザコはとにかく群れて囲もうとしてくる。ステージの特性を覚えて路地に誘いこむなどしないとタコ殴りされる。
タコ殴りにされると回避のタイミングもイマイチ合わないし、パリィも狙いにくい。弓や魔法で戦う人はもっと辛い。
なんとなく体感ではキングスフィールド臭さみたいなのが強くなった気がする。
デモンズのシステムを継承してキングスを作ったらこうなちゃったよって感じ。
逆にビクビクしながら潜っていく雰囲気みたいなのはダークソウルの方が全体的に見たら上かなと思う。局所的に見たらラトリアとか腐れ谷に勝るものはない。ダークソウルは全体的に嵐1と2、坑道1と2、城2と3みたいな構成に感じる（敵の行動的な部分も）。
デモンズ命でデモンズLoveで仕方ないって人は、デモンズをもう一度最初からやった方がいいんじゃねーかって言ってた人がいたけど、それはなんとなく納得できる。あの雰囲気はやっぱりデモンズにしかない。
ダークソウルはこれ単体でなら、なかなか面白いゲームだけどもデモンズの後継っていう重圧や期待感に全て答えることはできてないね。
発売直後の不具合を加味したら評価はいくらか下るけど
それを度外視したら、なかなか良作だと思う
今後の調整とか不具合の解消でもっと面白くなると思うよ。
特に攻略を進めているときの、やめられない止まらない感はすごいね。
次へ次へと行きたくなる。今回はルート（と帰還のためのショートカット）を探すのも作業に入るから、ほんとに探索してるっていう感じはある。
デモンズはどちらかというと探索より攻略っていう要素が強い、探索はアイテム探しくらいだし迷うような複雑さはラトリア1か、沼地の広大さくらいしかない。それ故のやりやすさからトライアンドエラーも抵抗なく、「あ、死んだ。チクショーもう一回」が何度でも出来たんだけど、ダークソウルは拠点となる篝火からの距離によっては、もう一回じゃなくて「気晴らしに他を見にいってみようかな」となる。そういう性質の違いは何度も死ぬにあたって感じた。
ただ、デモンズ2として見ると、アメリカ映画の続編的な残念さはあるかな
デモンズを求めるなら新しいキャラを作るか、PS3のユーザーを新しくつくってデモンズを真っ新な状態からやりなおすのがいいよ、もちろん頭に強い衝撃を与えて色々忘れた後でね。

最近のGNOMEとからKDEとか

GNOME3とかKDE4とか
人と違うこと=凄いこと みたいな風潮が感じられる
フランス映画をみて
オカッパ頭で
CCBみたいな伊達眼鏡かけて
アジアンな小物とリュックサックと缶バッチとニルヴァーナが好きな人みたい
GNOME3って使いやすいと言えるかな？
何でも慣れが要るのは当たり前としてもアレは論外だと思う
KDEは、また安定感に欠けてるし
アクティビティに存在価値を感じない
なんなの？最近のデスクトップ環境

モバイルビューきたこれ

bloggerにモバイルビューがつきましたね
可もなく不可もない程度の見易さ
ガラケーじゃ相変わらず見れないのは残念

Cでの入力待ち無しでの入力判定

int kbhit();

if(kbhit()){
.....
}
何かキーを押したらループから抜けるとか
キーを押したら入力を開始するとか
ループ抜けだけに使うならgetchでバッファにある入力値を捨てた方が綺麗

btrfs雑感

zfs相当のsend recvがないと運用には厳しいけど、個人で使ってる分はファイルの変更履歴が残して置けるのは便利
使っていようと思えば使っていられる。 パフォーマンスも悪くはない。

そういえば、ext4とbtrfsを性能とかで比較して「ext4の勝ち～btrfs超ザコなんですけどｗｗ」的な
blog書いてる人って馬鹿なの？死ぬの？
あるいはバグって止まったとか、マウントが死ぬほど遅いとか。

広い目で見た性能ならext3がまだしばらくの間ベストだよ、と。



kernelもナンバリングで開発版と安定版わけなくなったから紛らわしくなってるけど
btrfsってまだ開発途中であってテストリリースなんだよね（安定版kernelに入ってても）。
ＦＳそのものの仕様も変わりうるし（ある日kernelのバージョンアップと同時に読み書きできなくなったり）
性能出すためのチューニングより機能の実装とか安定化（バグ潰し）の方が優先だから
そういうオバカさんたちが期待して求めることと、現状のbtrfsの進捗やリリース状況があってないのが
なんとも開発者達が不憫だなぁと。

目新しい機能だからってメジャーディストリ側で安易に対応するからバカが脊髄反射するんだと思うんだよね。
やめてほしい。

Playstation Networkの障害

結構大規模（期間的な意味合いで）な障害になってるねぇ…データセンタが海外にあるが故なんだろうけど
国内での対応が鈍い。怒られたくない現地スタッフがしばらく足掻いたりしたんかね。

構築とか運用とかって仕事をしてると何となくわかるんだけど
こういう障害の広がりかたをするときっていうのは
大概にして、オペレータとか連絡を受けたSEとかが
「やっべぇ怒られる」ってんで、「内々に済まそう」と思って
初動を誤ったときに、こんな風に成りやすいと思うんだよね

「あれ？なんでだ？上手くいかんぞ」なんて足掻いてるうちに
内部的な被害が大きくなっていって、しまいには会社的には大事に発展するのね

攻撃とかデータ引っ込ぬくのはもちろん手動でやる馬鹿はいないから
攻撃が成功した時点で、ものの数分の間に抜くもんは抜かれて、ログを消すなり改竄するなりするんだし
発表にあった「不正な挙動に気付いた」っていうタイミングでは、すでに流出は止められないんだけど
「気付いた」ときに、「上流にあるL3とかFirewallの外側のポート全部閉じました」が正解なのよね
そこがまず「攻撃を受けた」とされる時点での、現場の保全につながるわけだしね

あるいは速攻で対象になってるマシンの電源ひっこぬくとかね
情報漏れるより、システムぶっ壊れても復旧する方が安いし
仮に乱暴してハードぶっこわれても保守入ってもらう方が安い

攻撃できてるってことは、管理者権限も盗られてる可能性も充分あるわけで、ツールでアタックされてるだけじゃなくて
攻撃してる側も、攻撃の進捗とか、他のログイン状況とかを監視できる状況にあるわけで
何か気付けば、痕跡だけ消して逃げおおせたり、あるいは速攻で他のアカウントを締め出すとか
パスワード全部変えるとか、システムに破壊的なダメージを与えていくとか、色々とできるんだしさ
「あ」と思った瞬間に、「どうとでもなるように準備しとく」のが賢い攻撃なんだからさ
悠長なことはしてられないはずなのよね 守ってる側は。
「あれ？」と思ったとき＝「もう繋がってない」っていう状況じゃないと、攻撃する側には常に有利なわけよ
 
そこでマゴマゴしてるから、あんな自信なさげな発表しちゃうんだと思うよ

まあ今回悪さした奴は、そんなに賢い奴じゃないみたいだから、まだいいけど
もう少しばかり知恵の働くやつで、もっと悪意があれば、最悪の自体を招いていたかもね
犯人は捕まらない、個人情報やクレジットカードの情報は業者とか犯罪者に流れて…みたいな
しかも、その根拠とか消去みたいなものはソニー側では確認できない（ログがない）とかで
「保障はしない、責任も取れない」状態で「事実関係を確認している」なんて言いながら世間から叩かれまくる なんていうね

今回は「攻撃があった事が確認されている」のと「漏れた情報はわかっている」ということで、「まだマシ」だと思う
認めてなかったクレジットカードの情報についても漏洩した事は確認されてるしね

私としてはクレジットカードで支払いしてたから、不安はすごくあるんだけども
さっさと何とかしてくれって感じ、グズグズしてんなよと。

ROM焼きで変になったとき

kernelだけ、とか
バグったROMを入れると
突如として、どうがんばってもSDがマウントできなくなったりする
（リカバリかけようとしてもSDを認識しないとか）

そんなときは以下

fastboot oem enableqxdm 0

android 2.3.3にした

今のところ快適
バッテリの持ちについては明日書く

pacman 3.5.0がきてる

testingでアップグレードあり
そのままだと依存関係のチェックで引っ掛って何もできなくなるので
pacman -Syしたあと、pacman -Sfd pacmanで無理矢理インストールすればOK
インストールされたらpacman-db-upgradeを実行する

btrfs with lzo

btrfsのlzo圧縮対応は地味にありがたいなぁ
zlibと比べると格段に低負荷になることと
圧縮率は落ちはすれども、テストケースによっては
無圧縮よりも高速にファイルの複製などができるようだ

sched autogroupについて

arch Linuxには2.6.38のパッケージが来ていて
デフォルトで有効になっていた
暫定対応時のようにcgroupディレクトリ以下にセッションID単位にファイルが出来て
みたいな確認方法が無いようなので、本当にきちんと動いているかは
負荷をかけてみるしかない　という感じ。

該当箇所のソースを読んでないので挙動については推測だけど
プロセス生成時に、自分でSIDを割り当てなければ何かとグルーピングされる。
デーモンプロセスについては追ってないんだけど、自分で呼び出した子プロセスに関してはグルーピングされてそう。
初期化処理の中でsetsidする奴は親プロセスになる、何から何処から呼び出しても。
これを考えると複数のサービスが混在するサーバとかでも有益なんじゃないかな。
特定サービスへの局所的な高負荷で他のサービス全体に悪影響を及ぼしたりしなくなる
と考えると非常に有益、コンテンツフィルタしたりウィルスチェックをするようなゲートウェイサービスには特に有益だろうな
F-Secureのウィルスチェックゲートウェイみたいなやつ。数あるサービスの中でもかなり重い部類に入るし、接続要求があると子プロ生成っていう動作を取るから効果的面な気がする。

「make -j70みたいなことをしても、ほかのプロセスに悪影響だしたりしないよ」
みたいなふれこみは正しかった。確かに動画を再生してもスムーズだった。
その最中にブラウザでtableが山ほど入れ子になったベンチマーク目的のページを開いても
きちんと描画も続いた、高負荷時はデスクトップ環境からみて「このプロセスは応答していません」扱いになることも多々あったんだけど
すごい効果だと思う。

ただそのmake -j70のほうの処理はほかの事をすれば完了は遅くなる。

１プロセスの実行速度よりも全体的な応答性を取りたい場合は
デスクトップ用途以外でも充分有効そう

kernel 2.6.38 リリース

やっときました
気になる日本での通称ミラクルパッチ(a.k.a."the patch that does wonders")ですが
デフォルトで有効かつ特別な対応なしに効いているようです。
これまで手動で対応していた人は起動スクリプトや設定ファイルに書いた変更を元に戻しておきましょう
もし、無効にしたい場合、または有効なはずなのにうまく動いてないという場合は
このファイルを確認しましょう　/proc/sys/kernel/sched_autogroup_enabled
ちなみに私はまだ試せてません
今日帰ったら早速やります
kernel newbieから超訳します

CPUに飢えたプロセスがいくつかあるとします。
まず同じセッションIDをもつ４つのプロセス
次にそれぞれ異なるセッションIDの２つのプロセス
automatic process groupingなし: [proc.1 | proc.2 | proc.3 | proc.4 | proc.5 | proc.6] automatic prosess groupingあり: [proc.1,2,3,4 | proc.5 | proc 6]
セッションIDとはUnixのプロセスが持つIDです。ps -eoで見ることができます。
setsid(3)によって新しいセッションIDが生成されて、そこからフォークした子プロセスに継承されます。
bashは起動のたびにsetsid(3)で新しいセッションIDを生成しますので、つまりは"make -j20"を実行しながら、何の問題もなくwebブラウズが出来たりするわけです。
この機能は2.6.24で実装されたgroup scheduringを利用しています。
/proc/sys/kernel/sched_autogroup_enabledで無効の設定を行うこともできます
(訳注たぶんbool）

つまりここでまとめられるプロセスというのが
何らかの親プロセスから生成された子プロセスがsetsidを行わない場合
(session IDが親プロセスと変わらない場合）
setsidで新しいセッションIDが生成された場合は
そのプロセスが親になって下にぶら下がるプロセスが、そのセッションIDでまとまる
ちなみにこれ、魔法でも何でもなくて過去実装された機能を有効活用するための実装
Linusが気に入ったのは効果も含めて、過去資産をスマートかつ有効に活用するアイデア
日本ではミラクルパッチとか魔法のパッチとか言われて
これだけで何倍高速化される　みたいな認識ですが
このパッチはスケジューリングにおける無駄を省くパッチになります
特にデスクトップ用途では色んなプロセスが山ほど立ち上がるので
そいつらが個別にCPU割り当てを要求して、その都度１つ１つを相手にするよりも
取りまとめて効率化することで無駄な遅延を起こさせないようにしましょう
という内容
つまりデスクトップ用途に限った話で言えばグループスケジューリングを
自動化してなかった今までがおかしいわけで、そこからやっとマシになった
高速化といってもプログラムの実行速度が速くなるわけじゃなくて
沢山の「ながら作業」をしてもプチフリしたり、描画が細切れに行われてるのを黙って待ったり
っていうイラっとするシチュエーションから開放されますよ　という話。
とどのつまりが、遅くなりにくくするパッチなわけ
（高速に動作するようになったのは動作の無駄が減ったスケジューラのみ）
よそ様のブログなどを見ていると「別に速くなった実感ないけどｗｗｗなにこれｗｗ」的な
書き込みをみるんだけど、単発で実行している以上に早くなったりはしないよと。
/.Jの200行パッチの記事とコメを真に受けたりすると、とっても恥ずかしいです
あのパッチから何故そんな話になるのかも理解できないなぁ・・・
フォアグラウンドアプリの優先度をブーストするとか
TTYのロック数を減らすことで高速化してるとか
TTYとGUIアプリの相互関係について議論とか
しかもそういうのに限って高いモデがついてる
悪意はないのだろうけど、外から見に来てる人間は有害だよなぁ・・・
間違ってても高モデで「参考になる」とかなら、それが正しいと勘違いするバカが量産されるじゃないのさ
あとLinusが大改造を嫌う　とかね。いるんだよああいうの真に受けてブログとか酒の席とかでわかったように偉そうな批判する奴がさ。
Linuxが嫌がるのは「俺様専用実装ｶｯｺｲｲ」とか
ただの名前変更のために超大なレビュー時間を割かれるとか
規模に関わらず、さっさとテストしたいパッチなのにも関わらずに
つべこべ議論して、何だかんだグダグダ言いながらレビューやテストから逃げたいがために没にしようとしてるダメメンテナが引き起こしたフレーム紛いの
なが～いスレッドだったり
むしろ商用利用とかって観点でみるとLinusはダイナミックすぎるところがあるから
冷や冷やするくらいだ。そんな大規模なパッチ今いれないでーくらいのね。

radikoが最高な件

radiko.jp

最高すぎる なぜって？
IPサイマルラジオというフツーのラジオをPCで聞けるサービス
ポッドキャストやネットラジオとは違うんです

だ か ら

伊集院光の深夜の馬鹿力が聞けるわけですよ
PCで！もう電波の入り具合で悩む必要なし 最高
伊集院万歳 

memo

#!/usr/bin/env ruby

module PARS_CONF

  def get_conf(conf_file)

    if File::ftype(conf_file) == "file"

      return Array[*open(conf_file).read.split(/(\n|\r)/).map{|f|

          f.split(/\r/)

        }.flatten]

    end

  end


  def ldif_conf(conf_file)

    if File::ftype(conf_file) == "file"

      return get_conf(conf_file).select{|b| 

        b =~ /(^uid\:[[:blank:]]|^mail\:[[:blank:]])/

      }.each{|x| 

        x.gsub!(/(^uid\:[[:blank:]]|^mail\:[[:blank:]])/,"")

      }

    end

  end

  

  def running_conf(conf_file)

    if File::ftype(conf_file) == "file"

      return get_conf(conf_file).select{|b| 

        b =~ /(^user[[:blank:]]|^[[:blank:]]*description[[:blank:]].*@.*)/}.each{|x| 

        x.gsub!(/(^user[[:blank:]]|^[[:blank:]]*description[[:blank:]])/,"")

      }

    end

  end



  def aliases_get(conf_file)

    if File::ftype(conf_file) == "file"

      return Array[*open(conf_file).read.split(/((^\s*)(:|,)(\s*)$)/).map{|f| 

          f.gsub!(/(^\#.*$\n)|(\\$\n)|([[:blank:]]*)/,"") ;f.split(/\n/)}.flatten]

    end

  end



  protected :get_conf

  protected :ldif_conf

  protected :running_conf

  protected :aliases_get


  def get_ac(conf_file)

    if File::ftype(conf_file) == "file"

      case File::extname(conf_file)

      when /(ldif|LDIF|ldap|LDAP)/

        return ldif_conf(conf_file).sort

      when /(cli|CLI)/ 

        return running_conf(conf_file).sort

      when /ali/

        return aliases_get(conf_file).sort

      else

        return get_conf(conf_file).sort

      end

    end

  end

end


class COMP_AC

  include PARS_CONF

  def initialize(file1, file2)

    @A1 = get_ac(file1)

    @A2 = get_ac(file2)

  end


  def show_comp()

    printf("%s only,\t%s only\n" ,ARGV[0],ARGV[1])

    a = [(@A1 - @A2).sort, (@A2 - @A1).sort]

    if a[0].length > a[1].length

      count = a[0].length

      a[1].fill(a[1].length ,count) { nil }

    elsif a[0].length < a[1].length

      count = a[1].length

      a[0].fill(a[0].length , count) { nil }

    else

      count = a[0].length

    end

    i = 0

    while i < count

      printf("\"%s\",\"%s\"\n",a[0][i],a[1][i])

      i += 1

    end



  end

end


if ARGV[0].nil? or ARGV[1].nil? then

  print < out.csv

EOS

elsif ARGV.size > 0 then

  COMP_AC.new(ARGV[0], ARGV[1]).show_comp

end

royal

やはりこいつは良い

K271mk2 レビュー

比較論だけでも仕方ないので単体でのレビューを


音質面ではＡＫＧらしい、高音域が伸びやかで低音域が引き締まるタイプ
中音域は前面に配置されている。ソースによりけりだけど、大体の場合は高音≧中音＞低音って感じの音量になる。
K271mk2の更なる特徴として、やはりモニター用というべきなのか、かなり音の分離がよい。音場感を超えて分離がいいため「自分はソースの粗探しをしているのか？」と思えるほど。
良くも悪くも分離がいいため、「できれば聞きたくない音」も聞こえる。
例えばボーカルの口がﾍﾟﾁとかﾍﾟﾁｬとかｸﾁｬっと鳴る音など。

全体的なバランスを重視した聴き心地より、一音一音の再現性と分離を重視した作り。
私はモニター用ヘッドホンばかり愛用しているから、すごく「良い」とは思うけど
民生機やＤＪ用ヘッドホンなどから、ここに手を出すと「びっくりする」と思う。
（もちろん、良くも悪くも。感動と失望も込み込み）

機能面について特筆すべきは頭から外したときのミュート機能とケーブル交換だろう。
ミュート機能は正直微妙だった。スイッチになってる弱そうなゴムバンドも心配だし
頭から外した流れで首にかけたりするとミュートにならない。フラットな場所に寝かせるくらいの扱いじゃないとだめ。
とにかく少しでもゴムにテンションがかかればスイッチが入る、ヘッドホンを頭にかけ際の縦へのヘッドバンドの伸びだけでなく、ハウジングをもって横に広げるだけでもバンドが縦にスライドするためスイッチがはいる。
一度スイッチが入ると、ヘッドバンドがビニル、スライドがプラスチックなので滑りが悪くスムーズに戻らない。
結局引っかかって途中で止まる、どこかに寝かせた衝撃（ｺﾄｯ程度の些細な衝撃）や手で戻す動作などできっかけを作ってやらないと基元に戻らないため意味がない。
あえてスイッチを切りたければバンドを手で引き下げる（または上から押す）動作がいる。
これならＤＡＰの再生を停止したほうが早い。



ケーブル交換はありがちなケーブル断線やプラグの磨耗に簡単に対応できる程度のものと思っておいたほうがいい。
使い勝手と音質を天秤にかけて総合的に優秀なのはやはり標準ケーブルだ。
ただ、キンクなどでケーブルを痛めたり抜き差しでプラグが磨耗したりで接触不良を起こすような
故障は長く使えば必ず起きるし、持ち歩けば当然ながらそういう機会も増えるので、交換可能な機構は保守性という観点でみると非常に素晴らしい。



また比較論にはなるけK271mk2を買うかK272HDを買うかで悩む人は多いようなので
ちょっとその点に触れておく。

まず前提として「モニター用ヘッドホン的な音質の製品が欲しい」という前提が必要
■リスニング用として
・”より”モニター的な音質がいいならk271mk2
・「総合的に聞き易い」ものがほしいならK272HD(あくまで比較論、K272HDもそこいらの民生機と比べるとものすごくモニター的）
・持ち歩くならK271mk2（保守性が高い、加えて一音一音のメリハリが強いため外で聴いても環境ノイズに埋もれにくい。ただ室内での静かな環境で聴く分にはやや疲れる。）
・据え置きならK272HD（保守性は低いが、聴きやすい。ムシしてもいいレベルだけど一音一音のメリハリはK271mk2よりは劣る、最大限K272HDで良い音と思うなら室内で）


■モニター用として
・モニター用としての全体的なバランスをみるとどちらも低音域がほかの域に比べて出ていないので、どっちもやめといた方がいい。K27xに合わせて低音いじると過多になる。
・複数（種類）のモニタ用ヘッドホンを使ってモニタするなら、選択肢としては充分にあり。その際はK271mk2をオススメする。
・宅録目的でリスニングと兼用するつもりならK272HDの方が気分よく聴ける。

全体的に見て一長一短なんだけど、ほとんど同等の性能（カタログスペックは若干K271mk2が上）
傾向や得手不得手に微妙な違いがある（まあコンセプトを反映しているだけのことだが）

どっちを選んでも大差はないが、大きくわけてポータブルならK271mk2のほうが安心感はある。
腰を据えて音楽を聴くならK272HDのほうがいい（K271mk2だと粗もかなり目立って聞こえる）


値段的には代理店的な相場もあってK271mk2のほうが安い（本国の相場に近い）
K272HDはサウンドハウスなら安いが価格的には数千円上、正規代理店を通すと倍の値段になる。
C/Pで選ぶならK271mk2(ほぼ同等の性能で、細かいことを気にしないで流し聴きするならどっちも同じだから）
付属品も充実（ストレート、カールのケーブル2種、レザー風、ベロア地のイヤパッド2種）という点を踏まえるとかなりお買い得。


全部ひっくるめて考えるとK271mk2がよい、価格以上の満足度はあると思う。
ただ私としては屋内利用に限ってリスニング目的でAKGを使うというならK272HDをオススメしたい。
こちらもC/Pでみると価格以上に効果あると思う。

極端だけど正直な話、色味で選んでもいい気がする。
紺と黒系の色合いにかっこよさを感じるならK271mk2
ベージュっぽい色合い（ハウジングの色は16進なら#30331a）にかっこよさを感じるならK272HD

あるいは色的にK271mk2は外っぽいイメージ
K272HDは室内にあるのが自然に見える色合い　だと個人的には思う。

音質的差異はそんな選び方でも別にいいくらいもんで
神経質になるほどじゃない

K271mk2とケーブル交換について

手軽に入手できるオヤイデのケーブルは音に若干ディストーションがかかったような
不思議な音質。悪いとは言わないがソースをかなり選ぶと思う。
まさかケーブルひとつでこんなにも違うとはなぁと思って驚いた。

正直に言うと違和感がひどいのとタッチノイズが出やすいので使用を断念した（許されるなら返品したいくらい）
これでもう少し柔らかかったら印象ぜんぜん違ったのかもしれない。


標準ケーブルはオヤイデのものと比べて解像度は落ちるものの素直な感じ。

標準ケーブルでK271mk2を使う場合、音質に限ってはK272HDとぱっと聞き違いはわからない。
低音の張りみたいなものはK272HDのほうがよかったが、高音域とか全体的な分離はK271mk2が良い。
総じての聴き心地は拮抗してる。


ケーブルの材質とか質感も一緒、やわらかくてクセがついたらもどりにくい。
カールコードはまだ試してないけどポータブルだとカールしてる部分が重く動くたびにコネクタ部分に負荷がかかるので
こちらは据え置きで使いたい。ストレートケーブルは単純にまとめてケースにでも入れておけばいい（スマートフォンの付属品についてくるようなショボイレザーケースが適当でよい）

同じ材質で1m30cmくらいのケーブルがあると助かるんだけどなぁ。

K271mk2のメリットはやっぱりケーブル交換なんだけど
今のところは断線したりステレオミニプラグがバカになっても交換できるくらいの
有り難味しかないのが悲しいなぁ。

海外では何ぼか流通してるもんなんだろうか？同程度の品質でいいから2000円いかない程度で入手できれば凄く安心感があるんだが。

ただまあ壊れたにしても、少なくともオヤイデではもうケーブル買わないな・・・
前に買ったステレオミニケーブルも正直イマイチで使ってないし、いい加減もったいない。

K271Mk2を買ったよ

ケーブル交換可能なところに惹かれて購入
ポータブル用途なので短かい方がいい

オヤイデから1m30cmのケーブルを入手し使ってます

音質はK272HDからなら違和感なく移行可能です
若干、272HDより一音一音はタイトな傾向
音場は少し曖昧に、解像度は向上といった違い
特に低音の引き締めは強くなる
バスブーストで持ち上げてやると爆発的に強く出てくるようになる。
たぶん、死ぬほど素直なのかな。幸いなことに破綻した感じはない。

馴れもあるからまだ272HDの方が好きだけど、性能的に優秀なのは271mk2だと思う。

ちなみに何故、買い替えたかというと
272HDの飾りでついてる銀色の輪っかが取れたため
接着剤で付け直してます。その間動かしたくないので、どうせなら家用にしてしまいたいなと。
ケーブル長すぎてポータブルに向いてない。

気付いたんだけどイヤパッドに互換性あるね これ。
新品の布地パッド使うのもったいないので、272HDのを取り付けてみたらピッタリだった。
逆も然りで、271mk2のレザーパッドも272HDにピッタリ。こりゃいいわ。


2011-03-07 追記
小柳出のケーブルはあんまり良くなかった
音質どうこうよりケーブルが固くて、取り回しがイマイチなのと
硬さゆえにタッチノイズが酷い、歩いていて自分の体にケーブルが触れるたびに
ザリザリ鳴ったりボッボッ鳴る、邪魔くさくて使ってられない。

据置きなら硬い方がいい場合もあるけど、ポータブルっていう用途に限っては
柔らかくないとダメ。

激安DAC

 上海問屋で発売された激安DAC DN-DAC195を購入してみた

音質は残念だけど小さくてよい

今のセット

記念撮影

アンプはarrow

かわいい

うほっ

yaourtメモ

-Syu --devel --aur
で全部アップデート

DOCKケーブル購入

DOCK STAAR.のDS-SALとM2-SALを購入

ちょっとトラブルもあったので報告おば



まずトラブルのほうですがM2-SALの方が内部の接触不良（たぶんハンダ不良）らしく
再生中にちょっとでも触ると左チャンネルしか鳴らなくなる
速攻でDOCK　STAARに連絡したら「代替品と返送用封筒を送るので届いたら返送して」という対応
やり取りが面倒くさそうだから自力で直すことも視野に入れつつ連絡してたんで
この対応の良さ（話の早さ）にはビックリ。いいメーカーだと思う。


気になる音質ですけど、ZYCABLEからの移行だと正直あんまり音質差は感じない
（値段的にはSALのほうが1000円ちょっと高いのでガッカリ感はある・・・）

気のせい？レベルの話をすると
SALのほうが音はほそくて一音一音が引き締まってる印象
arrowのクセのある音場には合うと思う。
解像度とか分解能には寄与するところはない（ZYとの比較論）
音場は広くなるというより、左右と奥に一歩ずつ遠ざかる感じ
arrowは音源の位置が近い（広さはないが配置はしっかりしてるタイプ）のため
広がりを与えるとちょうどいい。

ちなみにZYとSALの違いは単線かより線かの違い。
SALはそのまんま針金3本って感じで
ZYCABLEは左右チャンネル分は銀線でGNDは銅線、いずれも極太
気兼ねなく持ち出すなら曲げに強いZYCABLEの方がいい（私が扱い間違ってコネクタ破損させるまでトラブルなかった）
SALは曲げを繰り返すと断線するはず（単線だからデリケート）


国内メーカーで対応もきちっとしてるDOCK　STAARはなかなかいいです。
値段は割高だけど、なにより対応がいい点は高評価。
ケーブルは消耗品だし受注生産品だから出来栄えにムラがある都合上
作り手に信用おけるかどうかが大事だと思う。ブログに載ってる宣伝文句はさておき
客の心象を考えた対応をしてくれるところは信用おけると思う。
品質は悪くはなかった（故障箇所を除き）。

高いけど、割りとオススメ。

mailx(mailコマンド）でgmailのSMTPを使う

msmtpがあればいい。


Gentooのドキュメントにわかりやすい記述があった
認証まわりの設定値はGoogleのドキュメントを参照

あとは ~/.mailrc に以下を書く
set sendmail="/usr/bin/msmtp"


アラートメールなんかを携帯で受けたいときには
smtp立てるより、こっちの方がいい（もちろん自宅サーバに限って）

アホみたいに遅いけどね（認証とか入るから）

rubyの勉強続き

コンパクトにしてみた

ruby楽しいよ

個人の感想です


むか～し開発の仕事をしていて
C/C++やらJavaやらPerlを使っていたのだけれど
正直、好きじゃなかった

趣味でやってる分には楽しかったんだけど
途中で作るのが面倒になる

「ああもうシェルスクリプトでいいや」

充分にテストされてコンパクトで早いcoreutilsやら
枯れた実装かつノウハウ（悪いものも含めて）が充分にあるawkやらsedやら
bashやらzshの固有拡張機能があれば、いちいちPerlやら何やら持ち出すのが
バカバカしい。
（もちろんスクリプトで作りにくい、または現実的には困難なものもあるけど）

仕事じゃなくなってから、仰々しいものを作ったりしなくなったのも
「シェルスクリプトでいいや」を助長させてたと思う


なんで、シェルスクリプトでいいかというと
使い慣れたツールとの連携が可能、かつ楽
なによりも手軽に試せる。デバッグは面倒だけどテストは楽。
殆どのLinuxならzsh以外ならデフォルトで入ってるから
Linux間では可搬性も高い（違ったとしてもパスくらいだし）。


で、Rubyの勉強として過去作ったスクリプトの移植を試みてるんだけど
楽しいね。ほんと、純粋に楽しい。
awkやsed、grepレベルの文字列操作なら特に何も意識しなくても普通にできるし
「ちょっとやってみようかな」と思ったらすぐ試せる。シェルスクリプトばりに手軽。

PerlもJavaも構文が嫌いだった。Perlは後付臭いOOも嫌い。
あくまで”嫌い”なだけです。機能や性能や思想的な価値がRubyより劣るとか言ってるわけではありません。
ただ、私はPerlやJavaは大嫌いです。くそったれだと思います（個人の感想です）。
「ちょっとした小間使い的なツール作成」だと絶対に使いたくない。
（規模によってはJavaがいいかな、と思うこともある。ただしPerlはイヤだ）

RubyのALGOLみたいな構文はアレな気はしてたんだけど、書いてみてナルホドという感じ
こうじゃないといけなかったんだなぁと。

OOネイティブな感じもすばらしい。



思想的なものには一切興味はないんだけど
（例えばRubyのどこそこはどう美しい、それはなぜか　とか）
規模問わず、お手軽にはじめられるのはいい。

とりあえずRubyで実装して、思考を整理したり実装する機能を選別したり検証してから
ほかの言語に移植（要件とか運用で使う言語変わるし）とかしてもいいかなと思えるくらい、良い。

rubyでtapを覚えたかも

そのうち綺麗にします
とりあえずtapを覚えた
ファイルのhash取り込みも

snapshot.rb

勉強メモ

引き続きRuby中

メモを残す

#!/usr/bin/env ruby


require 'date'






def parse_dir(conf)
 snap = Hash::new

# hoge.tap{|h| hoge.each_pair{|src, dst| h[src] = "a"} }


 conf.each_pair {|src, dst| 
  _src = src.sub(/$\//,"").split(/\s*\/\s*/)
 if _src.size == 0
  snap[src] = "#{dst}/rootfs_#{Time.now.strftime("%Y%m%d").to_s}"
 else
  snap[src] = "#{dst}/#{_src[_src.size - 1].strip}_#{Time.now.strftime("%Y%m%d").to_s}"
 end
 }
 return snap
end


def get_conf(conf_file)
 conf = Hash[*open(conf_file).read.split(/\n/).map{|f| f.split}.flatten]
 return conf
end

class Snapshot
 def initialize(conf = "/etc/snap.conf")
 @snap = parse_dir(get_conf(conf))
 end
 def do_snap
 @snap.each_pair {|src, dst|
  system("btrfs","sub","snap",src,dst)
 }
 end
end


if ARGV[0] == nil
 snap = Snapshot.new
else
 if File::ftype(ARGV[0]) == "file"
  snap = Snapshot.new(ARGV[0])
 else
  p "no such file"
 end
end

if snap != nil
 snap.do_snap
end

rubyの勉強

やろう　やろう　と思いながら
結局３年くらい勉強しないままにしてたruby
せっかく参考書まで買ったのに一度も目を通してない
というわけで、仕事の空き時間に練習してみた
（参考書がないのでGoogle先生のお世話になりました）
構文からの勉強だから非常に時間がかかった（働け）

先日のbtrfsのスナップショット用スクリプトのruby移植＋α版
ハッシュが使えるお陰で設定ファイルがシンプルになりました。
/path/src /path/dst　の形式で1行ずつ書いてくだけ。
以前の階層に関連する制約がなくなりました。
データ構造をもう少し考えて
1つのでdstにつき、複数のsrcという形式で記述できるように
したほうがよかったかなと思ってます（今後の課題）
#!/usr/bin/env ruby

require 'date'


def parse_dir(conf)
snap = Hash::new
conf.each_pair {|src, dst|
_src = src.sub(/$\//,"").split(/\s*\/\s*/)
if _src.size == 0
snap[src] = "#{dst}/rootfs_#{Time.now.strftime("%Y%m%d").to_s}"
else
snap[src] = "#{dst}/#{_src[_src.size - 1].strip}_#{Time.now.strftime("%Y%m%d").to_s}"
end
}
return snap
end

def get_conf(conf_file)
conf = Hash::new
open(conf_file) {|file|
while i = file.gets
_line = i.split
conf[_line[0]] = _line[1]
end
}
return conf
end
class Snapshot
def initialize(conf = "/etc/snap.conf")
@snap = parse_dir(get_conf(conf))
end
def do_snap
@snap.each_pair {|src, dst|
system("btrfs","sub","snap",src,dst)
}
end
end

if ARGV[0] == nil
snap = Snapshot.new
else
if File::ftype(ARGV[0]) == "file"
snap = Snapshot.new(ARGV[0])
else
p "no such file"
end
end
if snap != nil
snap.do_snap
end

btrfsの明示的に作成されてないサブボリュームの話

人によってはマスターボリュームとか親ボリュームとか言われるアレ


mount -o default,subvolid=0 /dev/hoge /mount/path
subvolid=0でマウントできる。スナップショットも取れる。
マスターとか親とか雰囲気的には間違いじゃないけど
このボリュームID 0さんもサブボリューム。

インストールルートをサブボリュームにしたときは
grubにrootflagsオプションを付ける必要がある。
root=UUID=hogehoge rootflags=subvol=rootfsとか
root=UUID=hogehoge rootflags=subvolid=xxxとか

うちのサブ環境も変えた

比較的最近に購入したWin7機があるんだけど
ゲームと動画編集くらいにしか使わないのでもったいない
というわけで動画をノンリニア編集したりするので容量は無駄遣いできないが
空いてる領域で何かできないかと考えてみた

とにかく現状では容量が足りない（元々ついてたHDDは280GBくらいだったはず）
500GBを増設して、そこに動画の元ネタを入れて編集してるんだけども
今のところキツキツ（Windows上での認識では460GBくらいに見えてる）
そこで500GBを買い足し（2480円）、500GB２つをオンボードで対応してるRAID 0にした。

まずは現在の環境の退避から、Win7のシステムイメージとリカバリ用のブートメディア作成機能の評価もしたかったので
OSの機能のみでやってみる。
シャドウコピーなので、一時間もかからない間にイメージファイルが作成される。
ちなみにこのイメージファイルはXenとかHyper-Vとかと互換性があるVHDイメージで
ディスク管理画面からVHDに接続することも可能。
ブートディスクの作成もCD-Rつっこんで待つだけ
とっても簡単で、すばらしい。

作業が完了したところでリカバリテスト。
そのまま上書きする形でリカバリをしてみたところ、これもすぐ終る
（ディスクイメージは外付けUSB HDDに書き出してあるものを読み出した）

ここからが本番。
SATAに接続されている機器が
0:初期搭載HDD(280GBくらい)
1:初期搭載DVD-RWドライブ
2:増設HDD(500GB)
3:今回足したHDD(500GB)
となってる。
ここでは2,3をグループにする。
0はいじらない。

作成手順は省略。オンボのだし。

作業完了後、そのまま起動してみる。
ブートローダは走ってるようだけどHDDが見つからないようで再起動がかかる。
（ディスクのデバイスIDかインスタンスIDみたいなもんが変わるはずなんで当然）
（またはUUIDみたいなイメージ？）
先ほど作成したブートディスクから起動
復旧をはじめる。指定イメージからの復旧で全体の復旧を試みる。
復旧はエラーなく完了し、再起動。
ところがどっこい同じ症状で起動しない。

またブートディスクをいれて、パーティション構成を見てみると
なにやら変な風に切れてた
なぞの100MB程度の領域がCドライブ
Dドライブ(280GB)
Eドライブ(456GB)
みたいな。
しかも　恐ろしいことにどいつもこいつも「空っぽ」
このシステムイメージからの復旧はディザスタリカバリや
ＨＤＤ交換後のリカバリには使えないらしいという情報をネットでみる
たしかに出来てない（手順はもしかしたらあるのかもしれないが・・・）
面倒だからメーカのシステムリカバリ（ＯＳを工場出荷時に戻す）で対応
退避したものからの復旧は一旦ＶＨＤをマウントして中身を普通のバックアップで
外に逃がして、フォルダ単位で個別復旧（システムファイルなどを手動で上書きできないので、あくまでリストア処理に任せる）
その途中で仕事に出てきたので、まだ結果はでてない。
これが終ったらCentosいれてXen環境の勉強でもしようと思う。
あとはファイルサーバかな。

btrfsのバックアップ運用

ちょっと考えてみた

一括でロールバックする手段はなさそうだから
あまり有り難味はないかもしれない
とりあえずバックアップ用のスクリプトを用意した

bashじゃなきゃだめ

しかもrootfsからみて2階層目までしか取得できない

/etc/snap.confをこんな内容で作成する
SNAP_DIR=(/ /home/user1 /home/user2)
それぞれのパーティション直下に.snapshotっていうサブボリュームを作っておく
なまえが気に入らなければ変数にして合わせて内容を変えればOK

#!/bin/bash

SNAP_DIR=(/)
_CONF="/etc/snap.conf"

##
_BTR_BIN=`which btrfs`
_SNAP_DEST_DIR=()
source "$_CONF"
_S_C=0
_D_C=0

_expr() {
    i=0
    for _A in $*
    do
        if [ "$_A" = "/" ]; then
            _SNAP_DEST_DIR[$i]="/.snapshot/rootfs_"`date '+%Y%m%d'`
        else
            _B=`echo $_A | awk -F/ '{print $2}'`
            _C=`echo $_A | awk -F/ '{print $3}'`
            _SNAP_DEST_DIR[$i]="${_A/$_B/$_B/.snapshot}/"
            if [ -z "$_C" ]; then
                _SNAP_DEST_DIR[$i]="${_SNAP_DEST_DIR[$i]}"$_B"_"`date '+%Y%m%d'`
            else
                _SNAP_DEST_DIR[$i]="${_SNAP_DEST_DIR[$i]/"$_C"\//$_C}""_"`date '+%Y%m%d'`
            fi
        fi
        i=`expr $i + 1`
    done     
}



_expr ${SNAP_DIR[@]}
_S_C=${#SNAP_DIR[@]}
_D_C=${#_SNAP_DEST_DIR[@]}

_I=0
while [ $_I -lt $_S_C -a $_I -lt $_D_C ]
do
    $_BTR_BIN sub snap ${SNAP_DIR[$_I]} ${_SNAP_DEST_DIR[$_I]}
    _I=`expr $_I + 1`
done

うちのOS変えた

最近の変更でいうと、GentooからUbuntuに変えて一年半くらい使ってて
26日にArch Linuxに変えた。

その理由としては、まずFSをbtrfsに変えてみたくなったのとpacmanとABSに興味があった。
あと最近Linuxの先端に疎くなってきているのを感じたので
新しめのkernelとミドルをイジる必要性を感じた（仕事柄もあって）。

まずArchの導入について、感想を言うと
すごく簡単だった。10年以上前に雑誌のオマケにLinuxが付いてた時期（VineとかLaserとか）に導入経験がある人間なら何の苦もなくできる。むしろ自動認識の技術が進歩したり、XもKMSとかHALあたりのおかげで凄く導入しやすい。
最近のUbuntuとかRedhatなんかと比べても手順もそんなに多くはない、ただインストール画面は素気なくて退屈。

デフォルトではbtrfsを作成できないので、CD bootしたあとプロンプトに落ちてから、setupを叩く前にnetcfgしてネットワークを繋げたあと、pacman -Syし、pacman -S btrfs-progs-unstableする必要がある（ちょっとbtrfs-progの名前は今しっかり思いだせない、progだったかprogsだったか…）
とりあえず、これでbtrfsを作成可能になる。

あとはfdiskでパーティション切ったあとbtrfsで初期化して、setupを実行、パーティションの作成と初期化の工程を飛ばせばそのまま導入可能です。

私はその手順ではなく、一度ext4で入れてからbtrfsにコンバートしてみた。
これも難無く終る。ただし、rootfsのパーティション（またはディスク）をbtrfs化するにはCD bootが必要。
変換のためにはbtrfs-progsが要るので、先の手順で落してから変換する。

構成はrootfsのsubvolumeは切らずにrootfsとhomeを別パーティションにして、各ホームディレクトリはサブボリューム化、rootfsのバックアップはrootfs配下にバックアップ格納用サブボリューム（/.rootfs_bk)を作って、その中にスナップショットを格納するようにした。tmpもバックアップされちゃうけどまあいいという事にする。rootfsはsubvolume化するメリットが見付からないのと、rootfs配下の各ディレクトリ全部をサブボリューム化するメリットも特に見付からなかった。よってこの構成。

私が色々と困ったポイントを挙げておく（勘違いしていたのもあるけど）
・領域のサイズ変更はファイルシステム単位でサブボリュームには適用できない（ユーザーディレクトリのquota的な目的には使えない）
・サブボリュームはあえてマウントしなくてもいい（作った時点でマウントされてる、mountコマンドでもmtabでも見えないけど）
・あえてmountしてもいいし,fstabに書いてもいいけど、dfとかでは個別に取り扱われず元パーティションの情報そのまんま出てくる
・dfやmountやその他APIやツールがbtrfsのサブボリュームっていう概念にまだきちんと対応してないので色々と不便（上位のパーティションと同じ情報しか持ってこれない）
・マウントオプションを間違えて（subvolをsubvolumeとか書いちゃって）もエラーにはならず正常終了する、その時はマスターボリュームがdestにbindされる。たぶんmount側での対応がまだでエラーチェックされてない。サブボリューム名を間違えたときは「正しいブロックデバイスではない」と表示される。

あれっと思った部分はいくつかあったけど、結構快適だしスナップショットは便利。安定度も個人で使ってるぶんには不満はない。ただしオンラインリサイズしながら大量の「移動」をしてるとカーネルパニックを起したりする。過負荷は禁物なのか、それとも低いレイヤにアクセスしてる最中に何かすると安定しないのか。まあ普通に使う分には問題ない。



Archそのものの感想としては、結構良いディストリだと思う。システムの見通しもいい。ただ、他のディストロだと快適に使うために予めやってくれてるようなカスタマイズやパッチ当てをあえてしないらしく、ちょっと遅いかなと思う部分もあった。そこらへんの改善メモを遺しておく。

sysctl.confに下記を追加
vm.swappiness=20
vm.vfs_cache_pressure=50

あとkernel 2.6.38で取り込み予定の、噂の高速化パッチと同等の機能を加える変更もいれとく
Archの場合は、rc.localに
mount -t cgroup cgroup /sys/fs/cgroup -o cpu
mkdir -m 0777 /sys/fs/cgroup/user
echo "/usr/local/sbin/cgroup_clean" > /sys/fs/cgroup/release_agent
と書いておく。

.bashrc（ここはログインシェルの同等ファイルに合わせて読み替えて）



if [ "$PS1" ] ; then
           mkdir -m 0700 /sys/fs/cgroup/user/$$
           echo $$ > /sys/fs/cgroup/user/$$/tasks
           echo "1" > /sys/fs/cgroup/user/$$/notify_on_release
fi

と書く

/usr/local/sbin/cgroup_clean を以下の内容で作る（実行権限も与える）
#!/bin/sh
rmdir /sys/fs/cgroup/$1

とりあえずこれで快適、かなり速くなった。今まで色々つかってきたけど、今回が一番高速に動作してるかもしれん。

これでshellから何か実行したときは、特別なスケジューリングがなされる。
（どういう原理なのかはcgroupのドキュメントを見ればわかる、けど私はまじめに読んでないんので知らない）

あとGUI上で何でもかんでもに適用したい場合は、xprofileにmkdirとechoの3行だけ書き足せばOK。
あんまりローレベルすぎる部分に仕込みまくるのは逆効果っぽいので、xprofileまでにしとくのが無難。

Arrowをしばらく使ってみて その2

分離の良さは前回書いた通り

音の特性にクセはないんだけど
音場にクセがあるように感じる

立体的な音場なのはいいんだけど
・左右の位置はとてもいい
・奥行感はあまりない（次の項と関連する）
・奥行より上下（それも斜め）が強い
中音域と人の声が額より若干前かつ、やや斜め上にある。ボーカルは中心よりほんの少しだけ右にある。
低音域は耳から肩の付け根に向かって斜め後ろ側から鳴る。高音域は左右からくる、そんな感じの配置（もちろんヘッドホンなどによって差異はあると思う）

このボーカルの配置に独特なものを感じた。悪いとは思わないが、不思議な聞き心地になる。ちなみにバックコーラスは左斜め後ろから聞こえたり、ボーカルの位置からみてやや左側からくる。ここらはきっとミキシング時の影響による部分なんじゃないかと思うんだけど、確かめようがないので何が原因で違ってくるのかはわからない。

これらの音源配置は割とがっちりしてて、ソースによってブレない。唯一のブレ要素はバックコーラス。

かなり変ったアンプだと思う。何を選ぶかっていうと、やっぱり聞き手を選ぶんじゃないかな。
ソースは色々ためして得手不得手があるのはわかったが、苦手分野と言われてるHR/HMもとりたてて変な鳴り方でも貧弱でもなかった。それどころか、結構良く鳴る。ただ音源の配置に個性があるので、人によって好みは別れそう。

すごいアンプ なのは間違いないんだけど、良いアンプかって言われると微妙。

arrowをしばらく使ってみて

定位の問題は慣れのせいかも

某所にあがってる剛力アンプとかってレビューがあまりにあてにならないので簡単に特徴を書いてみる


まず最も印象が強いのが分離のよさ

点音源と言われてるけどちょっと違う

単純に左右チャンネルの分離がいいだけ

凄まじいステレオ効果なのであたかも点音源のように錯覚するんだと思う

ただソースによってはその分離がよすぎるせいで音に酔う 聴き疲れなんてもんじゃなくて気持ち悪くなる

特にモニター用ヘッドホンなんか使ってると顕著。あえてヘッドホン側の性能落としてやったほうが聴きやすくなる

音の伸びは悪いんじゃなくて味付けしてないんじゃないかと思う

ハウジングに余裕のあるヘッドホンで聞いてる限り不足は感じない

もうすこし詳しい話はまた次回

Arrow の バグ

G3の話

どうもバスブーストに変なクセがあるようだ
最初はクロスフィードかと疑ったんだけど・・・

具体的に言うとバスブーストを有効にすると
ソースによっては定位が狂う場合がある。
中音域がやや右に寄る（減衰はしてないとは思う）。
このせいでかなり気持ち悪い感じに。


ちなみにまったく影響しないソースもある。
うーん 鳴りのいいバスブーストだけに残念だ

arrow届いたよ

やっとArrowが届いたので開封直後レビューというか感想を

今回入手したのはArrow G3です

巷のレビューを見ると評価が極端に割れているように見えるんですが

私は諸手を挙げて大喜びするほど凄いアンプとは思わないし

逆に褒めちぎられてるのを気に入らないのか妙に批判的な感想を述べている人ほど、Arrowはダメとも思わない。

Arrowで良くも悪くも評価の対象となっている部分について、ここで言及してみたいと思います。

■低音の薄さについて

音圧が乏しいと言われますが、結構な量が出ていると思います。

ハウジングがビビるほどにボワボワと鳴る環境に慣れている人からしたら物足りないかもしれませんが

「低音が貧弱すぎる」という評価に繋がるようなものではなかったです。

制動性にしろ応答性にしろ、かなり高い水準にあると思えます。すっきりはっきり鳴るタイプです。

密閉型ヘッドホンなんか聞くと、より良いかもしれません。

■高音域の伸びについて

ダメダメというほど悪くはない、普通だと思うが。

 ■解像度、音場、定位、分離

解像度はスゴいとは思えない。音場感も格別すごくもない。

定位は安定はしてるけど、なんだか居心地の悪さを時々感じる。

音の分離に関しては素晴しいという他ない。

■音質面全体的に

一聴してビックリするほどの個性はない。強みも弱点も無いタイプだと思う。

よく言われるキレの良さですが、分離の良さが寄与したものだと思います。

Arrowの最大の良さは分離ですかね。

■使う上での工夫

バスブーストはかなりのモノです。低音域の音圧を稼ぎたい人は是非。このバスブーストはかなり良いものだ。

ゲインと抵抗値はヘッドホンなどに合わせて設定をイジっていこう。

クロスフィードは1段階目の方がクセない。2段階目にするとソースを選ぶようになる。

ゲインは出来るなら低めで調整したほうがいい。

■総評

思っていたよりダメでもなければ

何ヶ月も待つ程良いものでもない。

値段で考えると、およそ2万数千円になるわけですが

その中堅クラスの価格帯の中では良い方だと思います。

ただ正直期待が大きすぎて肩透かしされた感はあります。

叩いてる人も期待値が高すぎたんじゃないかなぁと邪推してみます

良いアンプだけど革命的にすごい製品だってわけじゃないです。

ハズレ感は無いです。けど大当りでもない。

AKG K272HD 1年経って

前回 のレビューでは購入早々でのレビューでした。今回は十分にエージングが済んだ状態でのレビューとします。
一年と十数日、一日2〜3時間の使用ですので充分ですね。
前回と併わせて御読みください。

前回問題としていた、高音域のキツさ、ハイハットやサ行の問題は使用から3ヶ月ほどで解消されました。
やはり単純に慣らし具合の問題だったようです。今ではかなりマイルドに、それでいて細く艶やかな良さは失われず、非常に良質な高音鳴らしてくれます。


解像度や分解能に関しては特に変化はありません。音場も定位も相変らず。再現性にも変化なし。
このあたりは製品としての安定性を感じます。

低音域の出具合ですが、以前の小気味良さに加えて、より柔軟で弾力性をもった音を出すようになりました。
なんとも形容しがたいのですが、低音域の良さをいくつかに分類すると響き、伸び、張り、音圧があるかと思います。
そこに旨味のような要素が加えられたと思います。響きや伸びは相変わらず乏しいのですが、振動板が柔くなったのかレスポンスは変らず懐が深くなった感じがします。表現力が若干ですが上っているように感じました。


エージングが進む＝劣化も進むということになりますが、今のところ壊れる様子はありません。
イヤーパッドやヘッドバンドもへたりはなく、ハウジング部分にもネジの緩みやハンダ剥離は無さそうです。
北海道では夏と冬に非常に温度差があり、季節の変わり目には非常に機械が壊れ易いのですが、K272HDは耐えてくれているようです。まだまだ元気。

聞き続けていれば耳が慣らされていくというのも当然ありますが、音の傾向はかなり好みの物になりました。
Arrowが届いてどう化けるかが楽しみです。