Javascript

Browserify を利用する vorbis-encoder-js をリリースしたので、 履歴とハマリポイント等を備忘録として書き残していく。 既存のライブラリでは何が足りなかったのか higuma/ogg-vorbis-encoder-js - GitHub Garciat/libvorbis.js - GitHub 上記どちらのライブラリでも AudioBuffer から Ogg Vorbis 形式の音楽ファイルを生成し、DLさせる所までは実現した。 しかし、元々想定される用途が Web Audio API を利用して、マイクからの音声データをDLする所がゴールだったようで、 タグ情報を埋め込む事考えられておらず、任意のタグ情報が埋め込めない。 また、モダンなプロジェクトなら Browserify や webpack の事は考慮に入れると思うのだが、そうでもないらしく微妙に使い勝手が悪い。 最初のコミットが1年も2年も前なので仕方ない側面もある。 そういった経緯から要望を満たすライブラリが無かったので、 GitHub で公開されている既存プロジェクトのソースコードを参考に作る事にした。 要件 Node.js での利用を想定する JavaScript での利用は Browserify を利用する 任意のタグ情報を設定出来ること ビルド環境の構築は頑張らない ログ libvorbis のビルド libvorbis はC言語で書かれているので、JavaScriptに変換するために Emscripten を経由する必要がある。 もともとC言語で書かれたライブラリを任意の言語に変換して使おうという要望は LLVM というプロジェクトで実現されており、 Emscripten は LLVM が生成した中間コードを JavaScript に変換する機能に特化している。 従って、あれやらそれやらのインストールが必要で、 いつまで経ってもコンパイルが通る環境が作れない！ 参考リンク：emscriptenで遊んでみた - kashiの日記 結局 Emscripten に特化したコンテナは Docker Hub で公開されていたので利用することにした。

音楽ファイルにはアーティスト情報等のメタ情報を埋め込んでいる事が多い。 ゲーム音楽のループBGM絡みで勉強することになったのでそのまとめ。 ファイルにメタ情報を埋め込む そもそもファイル内にメタ情報を埋め込むという発想はWAV形式やAIFF形式の時代から既に採用されていたようだ。 これらのファイルフォーマットはコンテナ形式で動作するため、コーデックとセットで動かす事は可能。 しかしリニアPCMをそのままぶち込むものとして認識されてしまった事で、ファイルサイズばかり無駄にデカイ使えない形式として認識されてしまったようだ。 1993年にMP3(MPEG-1 Audio Layer-3)が登場。 MD(ATRAC)に迫る圧縮率を叩き出し、PCの音楽ファイルフォーマットはこれ一色になった。 更にiPodが2001年に登場、アメリカそして日本でも爆発的に普及した。 MP3ではアーティスト情報等を管理したいという要望が生まれた。 1996年に独自実装していた「Studio3」というソフトウェアに乗っかる形でID3という形で仕様が決定された。 そういった意味では、アーティスト情報をファイルに埋め込む文化はMP3が起源といえるだろう。 参考リンク: 【音源管理の精髄】　WAVでリッピングするとタグはどうなる？　【ネットワークオーディオTips】 WAV - Wikipedia WAV ファイルフォーマット - 前田稔(Maeda Minoru)のプログラム入門 その103「WAVの構造と現状」 - BB Watch AIFF - Wikipedia MP3 - Wikipedia ID3タグ - Wikipedia オーディオ符号化とその応用 - これまでの25年と今後の展望 - ミニディスク - Wikipedia ATRAC - Wikipedia iPod - Wikipedia Ogg のメタ情報に関して Ogg VorbisではVorbisCommentという規格が使用されている。 Ogg Flacと構造は殆ど同じだと思うので、Flacの解説サイトのリンクも抜粋。 参考リンク: Vorbis - Wikipedia VorbisComment - xiph.org Flacファイルのメタデータ(タグ)構造 - 白旗製作所 おまけ：LOOPSTART、LOOPLENGTHに関して Ogg VorbisではコメントにLOOPSTART、LOOPLENGTHという値を格納すると、 一部プレイヤーではループ再生を行ってくれる。

JavaScriptでOggのエンコードがしたいので調査した結果の備忘録。 結論から言えば下記のようなプロジェクトが既にあるらしいので、順番に試していく予定 higuma/ogg-vorbis-encoder-js - GitHub Garciat/libvorbis.js - GitHub brion/ogv.js - GitHub 基礎調査 ogg javascriptでぐぐったら解決。 そのものズバリな記事がヒットした。 ogv.jsがすごい - necotech blog JavaScriptでOgg VorbisとかWebMとかをデコードするライブラリ Emscriptenを使って、Cのライブラリ(liboggzとかlibtheoraとか)をJavaScriptのコードにコンパイルしてる どうやらOggのライブラリはC言語で作られているようでJavaScriptにコンパイルし直せばブラウザ上でデコード/エンコードが出来るというわけか。 （クロスプラットフォームにするなら当然か） Emscriptenに関してもちょっと調べてみた Emscriptenとは EmscriptenでC言語をJavaScriptに変換する - Qiita Emscriptenとは EmscriptenはC/C++言語からLLVMを生成し、それをJavaScriptに変換するコンパイラのことです。 C言語の標準ライブラリやPOSIXの一部もサポートし、OpenGL ES2.0も使えるそうです。 Write once, run anywhereって奴か。 プロジェクトに関して Emscriptenなる便利なコンパイラが存在するのであれば、さぞかしプロジェクトは沢山ありそうだ。 その通りなようで、GitHubでプロジェクトが色々とヒットした。 higuma/ogg-vorbis-encoder-js - GitHub Garciat/libvorbis.js - GitHub brion/ogv.js - GitHub ざっと読んだ限り、higuma氏のプロジェクトが一番簡潔で使いやすそうな気がした。 楽曲のタイトルやアーティスト情報、LOOPSTART等のタグ情報を入れて行きたいので、組み合わせ次第といったところか。 実際に動かしてみる必要がありそうだ。

能書き 前回再帰関数で0.24sの関数を作成した。 前回の調査でわかってること start()関数を叩くまでタイムは動かない 以下の3変数は上書き出来ない(getterを使った関数) cash items prices 用意されているloop関数は超絶遅い shikakuとprogramming以外は取る必要無し 最速を狙う場合、1秒以内の極僅かな時間で何万work()関数を実行する為 if文は出来れば減らしたい for, whileより再帰関数が若干速い？ 作戦 ifもforもwhileも再帰関数も何も使わないのが一番速いに決まっている。 そしてstart()関数を叩くまでにはいくら時間を使っても計上されない。 だから作るんだよ…work()とpurchase()関数しか実行せずに1億円貯まる関数を…！ そしてstart()直後にその関数を叩けば最速に違いない。 調査 各種ワードチェック print(items); // { affiliate: 0, kabu: 0, programming: 0, shikaku: 0, tochi: 0 } 使える関数確認 これが出来ないと相当キツイから確認 必須関数（下記を確認していく） eval Array.map Array.forEach Array.join print([1, 2, 3].map(function(it){return it + 1;})); // [ 2, 3, 4 ] [1, 2, 3].forEach(function(it){print(it * 2);}); // 2 // 4 // 6 eval("[1, 2, 3].

試行錯誤の結果 何回かやって得られた感想を箇条書き start関数を叩くまでタイムがスタートしない 初期処理のコストは実質0 関数や変数等の準備を十分行ってから望む事が出来る cash、items、pricesは単なる変数に思えるが上書きできない ES6で実装されたgetterを使っているものと思われる 本気でハックすれば突破出来る？…多分不可能なのだろう 用意されているloop関数は超絶遅い 2番目の引数がms単位でsetIntervalと同じ作りだと思われる 製作者が発表している0.8sですら、1msに1度しか実行できないloop関数では800回程度しか実行出来ない 800回のwork()で1億とか到底無理で、関数内でfor文を回して1000回程度のwork()を叩きまくる糞関数を定義することになる つか、それがまかりとおるなら最初からfor文で回せばよくね？ 1秒以内に何万とwork()関数を実行する為、shikakuとprogramming以外は取る必要無し if文は遅い 条件判定式自体のコストはそれほどではないのだが、何万work()を実行する事になるのでその度に調査していては無駄。 for、whileと様々なループ文を試してみたが、再帰関数が最速なようだ あくまでElectronで使われているV8のエンジン固有の話だと思われる これが多分最速だと思います うちの環境(MacbookPro Retina13インチ)で0.24秒をマークした。 works_num = function(num) { return function(){ for (var i = 0; i < num; i++) { work(); } } }; shikaku = function shikakutore(it, works, loop){ return function(){ for (var i = 0; i < loop; i++) { works(); purchase(it); } }; }; shikaku_tore = shikaku(0, works_num(20), 25); program_tore = shikaku(4, works_num(500), 1); hatarake = (function(){ function hatarake(){ shikaku_tore(); program_tore(); cash < 100000000 ?

即時関数とは JavaScriptにおいて、 下のような書き方を即時関数と呼ぶらしい。 (function(){ 処理 })(); この書き方してるライブラリは山のようにあるけど、 名前もわからん動作もわからん、そもそも何だこの気持ち悪い書き方は？ 紹介してる書籍やサイトにも辿り付けないで苦労した。 挙動 関数の尻に()を付けるとその場で実行される。 function hoge() { // 処理 } hoge(); // 関数hogeが実行される しかし、{}は開始と終了時に行が変わると解釈される。 // その場で関数を実行したい function hoge() { // 処理 }(); //　↓内部ではこのように解釈されるので関数hogeは動作しない＞＜； function hoge() { // 処理 } (); …で、function(){}を式として認識させれば挙動を邪魔されることはない （下記参考サイトを参照） // 以下の書き方は全て同様 +function hoge(){ alert('hogeを実行') }() -function hoge(){ alert('hogeを実行') }() (function hoge(){ alert('hogeを実行') })() しかし、+や-等を使うと戻り値が数値にキャストされてしまうので、 即時関数の書き方は下が一般的となる。 (function(){ 処理 })(); メリット グローバル変数が汚れない (function hoge(){ 処理 })(); alert(hoge); // underfindと表示される 参考サイト 三等兵「知ってて当然？初級者のためのJavaScriptで使う即時関数(function(){…})()の全て」 http://d.

結論 jQueryのセレクタは右側から評価する jQueryは長いセレクタの場合、右側から解釈するので、 ヒット数の多いものが右側に来ると非常に時間が掛かる。 // NG: li要素の一覧を先に取得するので、IDで絞った意味がない $("#conditions li"); // OK: このように使えばIDがconditionsのものから検索出来る $("#conditions").find("li"); 重い処理はキャッシュを使う 変数を宣言して、jQueryオブジェクトを保存することをキャッシュと呼ぶらしい。 例えば何度もhogeクラスの要素を使う場合、 下記のように書いておけばHTMLを全て検索する処理は一度で済む。 var $hoge = $(".hoge"); var $piko = $hoge.find(".piko"); 速度改善のきっかけ jQueryを使用しているページを業務内で触っていたが、 Tableの表示がものすごく遅い…という訳で CSSやJavascriptを修正して速度改善することになった。 条件 Excelの「ウィンドウ枠の固定」っぽい表示にする jQueryのライブラリを使用して実装すること カラムの動的な表示・非表示を行う チェックボックスを複数作成し、チェックが消えるとカラム非表示 ぐぐってみた JavaScriptコーディング等を書く上でのパフォーマンス確認事項３０ http://phpspot.org/blog/archives/2010/06/javascript_87.html JavaScriptに関しては良い感じだが、jQueryに関しては少ない。 幾つかの項目は可読性が犠牲になるので余裕があればで良いだろう。 jQuery(“ul > li”) のように使う。 jQuery(“ul li”) は広義すぎる jQueryは右側から解釈するのでどちらもNG 例ならjQuery(“ul”).children(“li”)、もしくはjQuery(“ul”).find(“li”)とするのが良いだろう。 jQueryを良くする25のTIPS http://blog.webcreativepark.net/2008/12/17-225630.html 最初に読む書籍としてはかなり良い。 口語が多いので十分理解できたら別のページがよさそう。 jqueryのセレクタを高速化する http://nex.xrea.jp/?s=1231 シンプルな結論だった