<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>ALT+Development</title>
	<atom:link href="http://dev.yuichiroharai.com/feed/" rel="self" type="application/rss+xml" />
	<link>http://dev.yuichiroharai.com</link>
	<description>ALT+Development</description>
	<lastBuildDate>Sun, 18 Dec 2011 11:28:44 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.3</generator>
		<item>
		<title>続・Stage3DとGraphicsを比較してみました</title>
		<link>http://dev.yuichiroharai.com/post/the-sequel-to-stage3d-vs-graphics/</link>
		<comments>http://dev.yuichiroharai.com/post/the-sequel-to-stage3d-vs-graphics/#comments</comments>
		<pubDate>Sat, 17 Dec 2011 15:00:11 +0000</pubDate>
		<dc:creator>yuichiroharai</dc:creator>
				<category><![CDATA[Flash+ActionScript]]></category>

		<guid isPermaLink="false">http://dev.yuichiroharai.com/?p=32</guid>
		<description><![CDATA[Stage3D VS Graphics 2 - wonderfl build flash online 申し訳ありません、前回の記事「Stage3DとGraphicsを比較してみました」で紹介したwonderflのサンプルにミスがありましたので、修正+新たに機能追加したものをフォークする形で投稿しました。 前回のサンプルでは描画領域のサイズをステージサイズの縦横の小さい方のサイズに合わせて正方形になるように定めていました。例えばステージサイズが800×600だったら描画領域は600×600といった具合になります。 さらに、描画領域のサイズは常に偶数になるようにしていました。その理由はソフトウェアレンダリングのStage3Dでは描画領域(バッファサイズ)が奇数だと処理が遅くなるという情報「Twitter / @keim_at_si: wonderflでStage3Dコンテンツあげる人は ...」を聞いていたためです。 しかし、ステージサイズが465×465(wonderflの固定サイズ)以下の時には描画領域を465×465に固定するという処理も同時に行っていたため、結果的に偶数にならない状態となっていました。 前回の記事では描画領域を偶数に調整している事に触れず、説明不足だった事をお詫び致します。 今回フォークしたサンプルでは、描画領域が偶数と奇数でどのくらいの違いがあるのかを確認するため、偶数/奇数の切り替えボタンと描画領域のサイズ表示の機能を追加しています。 そしてこのサンプルを使って色々と検証を行った所、Stage3D(ソフトウェア)で処理が遅くなる条件が分かったのでまずはその説明を先にしておきます。 Stage3D(ソフトウェア)で処理が遅くなる条件 冒頭で描画領域(バッファサイズ)が奇数だと処理が遅くなると言いましたが、正確には現在のバッファサイズではなくて今までで一番大きいバッファサイズが対象となります。 例えば、バッファサイズが最初は500×500だった時に501×501に変更すると処理が重くなります。しかし、最初に500×500だった時に499×499に変更しても処理は重くなりません。 逆に、バッファサイズが最初から499×499で処理が重い時に500×500に変更すれば処理は軽くなりますが、最初に499×499だった時に498×498にしても処理は軽くなりません。 最大サイズが対象なので、501×501→499×499→500×500と変更しても処理は重いままですし、502×502→500×500→501×501と変更しても処理は軽いままです。 今回のサンプルではこの条件で処理が重くなる時には描画領域のサイズ表示を赤字にするようにしてあります。興味があればぜひ実際に確認してみて下さい。 では、改めて検証結果について説明していきます。 比較の検証結果 検証に使用したマシンのスペックは前回と同じです。 Model: Mac Mini Early 2009 OS: Mac OS X 10.6.8 CPU: &#8230; <a href="http://dev.yuichiroharai.com/post/the-sequel-to-stage3d-vs-graphics/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
		<wfw:commentRss>http://dev.yuichiroharai.com/post/the-sequel-to-stage3d-vs-graphics/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Stage3DとGraphicsを比較してみました</title>
		<link>http://dev.yuichiroharai.com/post/stage3d-vs-graphics/</link>
		<comments>http://dev.yuichiroharai.com/post/stage3d-vs-graphics/#comments</comments>
		<pubDate>Tue, 13 Dec 2011 15:00:48 +0000</pubDate>
		<dc:creator>yuichiroharai</dc:creator>
				<category><![CDATA[Flash+ActionScript]]></category>

		<guid isPermaLink="false">http://dev.yuichiroharai.com/?p=30</guid>
		<description><![CDATA[Stage3D VS Graphics - wonderfl build flash online Flash Player 11から登場したStage3DによってGPUを使った高速な描画処理が可能になりましたが、Flash Player 10以前のメイン描画機能のGraphicsクラスとの処理速度の違いを検証するため、両者を比較できるサンプルをwonderflに投稿しました。 当初、Stage3DについてはGPUを使った場合のみの検証を想定していました。 しかし、先日(2011/12/06)のFLASH MEETUPにて、現時点ではFlash Player 11を搭載したマシンでStage3Dを使用する場合、GPUで動作するのは50%程度(逆に言えば残りの50%はソフトウェアレンダリングを使用している)という話が出ていたそうなので、それはちょっと少ないなぁと思いソフトウェアレンダリングを使った場合の検証も追加してみました。 ※ FLASH MEETUPの内容については「2011/12/06 FLASH MEETUP #flashmeetup - Togetter」を参考にしています。 結論から言うと、Stage3Dは(Context3D.configureBackBufferメソッドで指定する)描画領域が大きいほど負荷がかかります。一方で、Graphicsの場合は描画領域の大きさも当然負荷に影響がありますが、それ以上に三角形などのひとつひとつの描画処理が増えるほど大きな負荷が掛かります。 つまり、密度の高い複雑な形状の物体を描画する場合はStage3Dの方がかなり有利ですが、フルスクリーンモード時などに画面サイズいっぱいに描画を行う場合、シンプルな形状の場合はGraphicsの方が負荷が軽くなるケースが出てきます。 極端な話、Stage3Dは特に何も描画せずにContext3Dクラスのclear()とpresent()を毎フレームごとに呼び出すだけでも負荷が掛かっていました。 では、サンプルの説明と検証内容について書いていきます。 サンプルの説明 比較になるようにStage3DとGraphicsの両方で同じものを表示していますが、細かい違いなどの留意点をいくつか先に説明しておきます。 まず、テクスチャに使っている画像は256×256で固定です。Stage3Dではミップマップを使う事で描画する面に合わせて最適なサイズの画像が使われるようにできますが、Graphicsにはそういった機能は無いのでStage3Dでもミップマップは使用していません。 次に、アンチエイリアスの設定はStage3DではContext3D.configureBackBufferメソッドを呼び出す時に16(最高品質)を指定しています。実際は2(最小限)や4(高品質)でも実用に耐えれるレベルだったりするので、その場合は処理速度はそれなりに早くなります。 GraphicsではbeginBitmapFillメソッドを呼び出す時にスムージングをtrueにしてアンチエイリアスを掛けています。こちらは細かい品質の設定はできません。 ちなみに、何故かソフトウェアレンダリングのStage3Dではアンチエイリアスが掛かりませんでした。 (このサンプルに問題があるのかもしれませんが…。) 続いて、面が重なった際に手前の面が正しく表示されるようにするための深度管理についてですが、Stage3DではContext3D.setDepthTestメソッドを使って深度管理を実現しています。面が重なった際には手前のピクセルの後に奥のピクセルを描画する時には処理をキャンセルする事ができるでの、効率良くパフォーマンスが向上されている事が想像できます。 しかし、Graphicsではピクセル単位での深度管理はできないので、drawTrianglesメソッドの第4引数を使って面の裏側(奥)を先に描画してから表側(手前)で上書きするようにしています。この方法だと正しく表示はされますが無駄な描画が発生する事になりますので、Stage3Dと違って処理速度の向上は期待できません。 Stage3D(GPUとソフトウェアレンダリング)とGraphicsの切り替え &#8230; <a href="http://dev.yuichiroharai.com/post/stage3d-vs-graphics/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
		<wfw:commentRss>http://dev.yuichiroharai.com/post/stage3d-vs-graphics/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Event.RESIZE時にStage3Dの描画を行うとフリーズ</title>
		<link>http://dev.yuichiroharai.com/post/freese-when-stage3d-draws-on-resize-event/</link>
		<comments>http://dev.yuichiroharai.com/post/freese-when-stage3d-draws-on-resize-event/#comments</comments>
		<pubDate>Sun, 20 Nov 2011 15:00:44 +0000</pubDate>
		<dc:creator>yuichiroharai</dc:creator>
				<category><![CDATA[Flash+ActionScript]]></category>

		<guid isPermaLink="false">http://dev.yuichiroharai.com/?p=29</guid>
		<description><![CDATA[「音に反応する球面 - Stage3D « ALT+Development」を作った時の事なんですが、フルスクリーン表示の際にウィンドウサイズを変更するとフリーズする問題が発生してしまいました。色々調べてみた所、どうやらStageクラスのEvent.RESIZEイベントに登録したリスナー内でStage3Dの描画を行うと問題が起きるようです。 wonderflに動作確認できるコード「Event.RESIZE時にStage3Dの描画を行うとフリーズ - wonderfl build flash online」を乗せておきました。本当にフリーズしてブラウザクラッシュに繋がりますので閲覧する時はくれぐれもご注意を。 動作確認に使った環境は以下の通りで、いずれのブラウザでもフリーズしていまいます。 OS: Mac OS X 10.6.8 Browser: Safari 5.1.1, Firefox 8.0, Chrome 15.0, 追記 (2011.11.21)：スタンドアローンのFlash Playerで実行した場合は問題ありませんでした。 コードの全文は以下の通り。 package { import com.adobe.utils.AGALMiniAssembler; import flash.display.*; import flash.display3D.*; import flash.events.Event; public class &#8230; <a href="http://dev.yuichiroharai.com/post/freese-when-stage3d-draws-on-resize-event/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
		<wfw:commentRss>http://dev.yuichiroharai.com/post/freese-when-stage3d-draws-on-resize-event/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>音に反応する球面 &#8211; Stage3D</title>
		<link>http://dev.yuichiroharai.com/post/sphericial-beat-sample-stage3d/</link>
		<comments>http://dev.yuichiroharai.com/post/sphericial-beat-sample-stage3d/#comments</comments>
		<pubDate>Fri, 18 Nov 2011 15:00:09 +0000</pubDate>
		<dc:creator>yuichiroharai</dc:creator>
				<category><![CDATA[Beatport]]></category>
		<category><![CDATA[Flash+ActionScript]]></category>

		<guid isPermaLink="false">http://dev.yuichiroharai.com/?p=28</guid>
		<description><![CDATA[音に反応する球面 - Stage3D - wonderfl build flash online 追記 (2011.11.19)：私の非力なマシンで「Preview Fullscreen」ボタンを押してフルスクリーンで見た所、ブラウザが落ちてしまいました。。。ローカルでテストした時は問題は無かったのですが。 参考のために環境を書いておきます。 ・Mac Mini Early 2009 ・Mac OS X 10.6.8 ・Intel Core 2 Duo 2GHz ・2 × 2GB DDR3 1067 MHz ・NVIDIA GeForce 9400 問題なく観れてる方もいましたのでしばらくはこのままにしておきますが、問題が多そうでしたら対処したいと思います。 追記 (2011.11.21)：スペックに関係なくフリーズする問題だと分かりました。詳細は「Event.RESIZE時にStage3Dの描画を行うとフリーズ « ALT+Development」にまとめておきました。 遅ればせながら、Flash &#8230; <a href="http://dev.yuichiroharai.com/post/sphericial-beat-sample-stage3d/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
		<wfw:commentRss>http://dev.yuichiroharai.com/post/sphericial-beat-sample-stage3d/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>loadPCMFromByteArrayに渡すByteArray</title>
		<link>http://dev.yuichiroharai.com/post/bytearray-passed-to-loadpcmfrombytearray/</link>
		<comments>http://dev.yuichiroharai.com/post/bytearray-passed-to-loadpcmfrombytearray/#comments</comments>
		<pubDate>Sun, 13 Nov 2011 15:00:14 +0000</pubDate>
		<dc:creator>yuichiroharai</dc:creator>
				<category><![CDATA[Flash+ActionScript]]></category>

		<guid isPermaLink="false">http://dev.yuichiroharai.com/?p=25</guid>
		<description><![CDATA[Flash Player 11の新機能のloadPCMFromByteArrayメソッドにByteArrayを渡した時、ひょっとしたらサウンドの再生中にそのByteArrayを操作したらサウンドに影響与えられないかなぁと思って試したところ、残念ながら渡したByteArrayはコピーされて内部に格納されるので影響は無いようです。もしかしたらと思ったんですけどね。。。 「flash.media.Sound - Adobe® Flash® Platform 用 ActionScript® 3.0 リファレンスガイド」にあるように、loadPCMFromByteArrayメソッドにByteArrayを渡すと、ByteArrayの現在位置から第2引数で指定したサンプル数の分だけデータが読み取られ、ByteArrayの位置もその分移動していました。 内部的には新たにByteArrayを作り、readBytesメソッドで渡したByteArrayを読み込んでコピーを作成している様に見えますね。 というわけで、再生中のサウンドを操作したい場合は、従来通りに空のSoundインスタンスを再生し、SampleDataEvent.SAMPLE_DATAイベントで加工済みのByteArrayを小出しにする方法が良いみたいです。 loadPCMFromByteArrayメソッドで何でも出来るわけじゃなく、使い分けが必要ですね。]]></description>
		<wfw:commentRss>http://dev.yuichiroharai.com/post/bytearray-passed-to-loadpcmfrombytearray/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>loadPCMFromByteArrayでサイン波の再生</title>
		<link>http://dev.yuichiroharai.com/post/play-sine-wave-with-loadpcmfrombytearray/</link>
		<comments>http://dev.yuichiroharai.com/post/play-sine-wave-with-loadpcmfrombytearray/#comments</comments>
		<pubDate>Thu, 03 Nov 2011 15:00:33 +0000</pubDate>
		<dc:creator>yuichiroharai</dc:creator>
				<category><![CDATA[Flash+ActionScript]]></category>

		<guid isPermaLink="false">http://dev.yuichiroharai.com/?p=24</guid>
		<description><![CDATA[loadPCMFromByteArrayでサイン波の再生 - wonderfl build flash online Flash Player 11の新機能のひとつSound.loadPCMFromByteArrayメソッドを使ってサイン波を再生するFlashコンテンツをwonderflに投稿しました。 後、サイン波のような単純な波形を再生した時にcomputeSpectrum(FFT)のstretchFactorを変えるとどういうスペクトラムデータが得られるのかを確認したかったので、前回の記事「computeSpectrum(FFT)のstretchFactorについて」でも使ったスペクトラムデータの視覚化も行っています。 後、音量にはくれぐれもご注意下さい！特に6オクターブ辺りから上は耳や再生機器に負担掛けますので。 loadPCMFromByteArrayメソッドは「flash.media.Sound - Adobe® Flash® Platform 用 ActionScript® 3.0 リファレンスガイド」にあるように、生のサウンドデータ(ByteArray)を読みこんで再生できる新しいメソッドです。 以前のFlash Player 10では、Soundインスタンスに対してSampleDataEvent.SAMPLE_DATAイベントのリスナーを登録し、そのリスナー関数内でその都度細かくByteArrayデータを生成して渡していました。 しかし、loadPCMFromByteArrayメソッドを使えば、あらかじめ再生する全ての分のサウンドデータを用意する事ができます。リスナーも使わないので直感的にも簡単に実装が行えるようになったと思います。 今回はサイン波を再生するためにByteArrayを0から生成していますが、(MP3などをロードした)Soundインスタンスのextractメソッドを使ってもByteArrayデータを取得でき、これをloadPCMFromByteArrayメソッドに渡して再生することも可能です。 「blog.alumican.net » Blog Archive » FlashPlayer11のサウンド新機能を試してみる」ではロードしたMP3データをByteArrayに変換してloadPCMFromByteArrayで再生するサンプルが確認できます。 この記事でも触れている再生が完了しないバグ(？)は私も遭遇したので、wonderflのコードでは再生位置が決められた時間に達したら停止しする事で応急処置しています。]]></description>
		<wfw:commentRss>http://dev.yuichiroharai.com/post/play-sine-wave-with-loadpcmfrombytearray/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>computeSpectrum(FFT)のstretchFactorについて</title>
		<link>http://dev.yuichiroharai.com/post/about-stretchfactor-of-computespectrum-fft/</link>
		<comments>http://dev.yuichiroharai.com/post/about-stretchfactor-of-computespectrum-fft/#comments</comments>
		<pubDate>Wed, 02 Nov 2011 15:00:43 +0000</pubDate>
		<dc:creator>yuichiroharai</dc:creator>
				<category><![CDATA[Flash+ActionScript]]></category>

		<guid isPermaLink="false">http://dev.yuichiroharai.com/?p=23</guid>
		<description><![CDATA[computeSpectrum(FFT)のstretchFactor - wonderfl build flash online (フーリエ変換を使用した時の)SoundMixer.computeSpectrumメソッドのstretchFactor引数と出力されるスペクトラムデータ(ByteArray)の関係性を視覚化するwonderflのコードを作ってみました。 Adobeのリファレンス「flash.media.SoundMixer - Adobe® Flash® Platform 用 ActionScript® 3.0 リファレンスガイド」によると、stretchFactorはサンプリング解像度を表し、値が0の場合は44.1KHzでサンプリングされ、1の場合は22.05KHz、2の場合は11.025KHz、…となると書いてあります。 そこで、stretchFactorを2^n(0、1、2、4、8、16、…)の範囲で値を増やしていくと、出力されるByteArrayのデータが段々と粗くなって同じ値が連続して現れるようになります。最初は256個全てに異なる値が入っていたものが、2個、4個、8個、…、と同じ値が連続し、最終的には256個全てが同じ値となります。 しかし、よく見ると右端に半端なデータが見受けられます。例えば、stretchFactorを256にすると、255個のデータが同じとなり、最後の1個のデータが別の値になっていました。 そこで色々と試したところ、stretchFactorを0 or 1 or (2^n)+1 (0、1、2、3、5、8、…)にすると、ByteArrayのデータがきれいに並ぶようになりました。 stretchFactorが3の時は2個ずつ同じ値が連続して128種類、5の時は4個ずつ同じ値が連続して64種類、…といった具合に異なる値が半分ずつ減っていきます。 正直、どうしてこうなるのかはよく分かっていませんが、データがきれいに返ってくる(2^n)+1の方が使いやすいので、私はこの方法を使用するようにしています。 ちなみに、「Ripple Beat」では、stretchFactorを65にして使っています。この場合は4種類のデータが得られ、一番最初の値を波紋エフェクトのパラメータにしています。試行錯誤した結果、この方法がサウンドのキックにシンクロしやすかったので。]]></description>
		<wfw:commentRss>http://dev.yuichiroharai.com/post/about-stretchfactor-of-computespectrum-fft/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Ripple Beatをwonderflに投稿しました</title>
		<link>http://dev.yuichiroharai.com/post/ripple-beat-on-wonderfl/</link>
		<comments>http://dev.yuichiroharai.com/post/ripple-beat-on-wonderfl/#comments</comments>
		<pubDate>Fri, 28 Oct 2011 15:00:00 +0000</pubDate>
		<dc:creator>yuichiroharai</dc:creator>
				<category><![CDATA[Beatport]]></category>
		<category><![CDATA[Flash+ActionScript]]></category>

		<guid isPermaLink="false">http://dev.yuichiroharai.com/?p=21</guid>
		<description><![CDATA[Ripple Beat - 音に反応する波紋 - wonderfl build flash online 「Ripple Beat」で使用している波紋エフェクトの部分を抜き出して、wonderflに投稿してみました。 wonderfl版は画像サイズが212*212と2倍近く大きくなっていて、より視覚効果が分かりやすくなっているかと思います。 サンプルで使用しているトラックはMinimal/Techno/Tech Houseのお気に入りをチョイスしています。 コードの解説も後ほど記事にできればと。]]></description>
		<wfw:commentRss>http://dev.yuichiroharai.com/post/ripple-beat-on-wonderfl/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Beatportビジュアライザ『Ripple Beat』を正式公開しました</title>
		<link>http://dev.yuichiroharai.com/post/beatport-visualizer-ripple-beat/</link>
		<comments>http://dev.yuichiroharai.com/post/beatport-visualizer-ripple-beat/#comments</comments>
		<pubDate>Sat, 22 Oct 2011 15:00:32 +0000</pubDate>
		<dc:creator>yuichiroharai</dc:creator>
				<category><![CDATA[Beatport]]></category>
		<category><![CDATA[Flash+ActionScript]]></category>

		<guid isPermaLink="false">http://dev.yuichiroharai.com/?p=19</guid>
		<description><![CDATA[デモ版として先行公開していた「Ripple Beat」を正式公開しました。 今回から全てのジャンルのランキングを視聴できるようなりました。加えて、ランキング100位までの曲を25、50、100曲単位で表示できるようにしました。 今回の更新内容は以下の通りです。 全てのジャンルのランキングを表示できるようにしました。 表示範囲を「1〜25」、「26〜50」、「51〜75」、「76〜100曲」(25曲表示)、「1〜50曲」、「51〜100曲」(50曲表示)、「1〜100曲」(100曲表示)の7パターンから選べるようになりました。 サンプル音源のローディング状況が分かるように視覚化しました。]]></description>
		<wfw:commentRss>http://dev.yuichiroharai.com/post/beatport-visualizer-ripple-beat/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Beatportの波形画像の扱い方</title>
		<link>http://dev.yuichiroharai.com/post/beatport-using-waveform/</link>
		<comments>http://dev.yuichiroharai.com/post/beatport-using-waveform/#comments</comments>
		<pubDate>Fri, 07 Oct 2011 15:00:18 +0000</pubDate>
		<dc:creator>yuichiroharai</dc:creator>
				<category><![CDATA[Beatport]]></category>

		<guid isPermaLink="false">http://dev.yuichiroharai.com/?p=17</guid>
		<description><![CDATA[「Ripple Beat」でも使っているBeatportの波形画像の扱い方についてまとめてみました。 Beatport APIを通じてトラック情報を取得するとその中に波形画像のURLが含まれており、JSONデータの場合は、images -> waveformがそれに当たります。 (ちなみに、XMLデータの場合は拡張子がjpgとなっていますが、pngの間違いだと思われます。) 実際の画像は、「Underworld - Dark And Long (Christian Smith Tronic Treatment Remix)」の波形画像のように横幅1500px、高さ250pxで固定となっています。曲の長さに関わらず横幅が一定なので1秒辺りのピクセル数は可変ということになります。 1秒辺りのピクセル数を求める 1秒辺りのピクセル数 = 波形画像の横幅(1500pxで固定) ÷ 曲の長さ(秒) 先ほどの「Underworld - Dark And Long (Christian Smith Tronic Treatment Remix)」の曲の長さは7:19なので439秒です。なので、1500pxをこの値で割ると約3.4168...となり、これが1秒辺りのピクセル数となります。 サンプル音源の切り取り位置について Beatportではサンプル音源の長さは基本的に2分=120秒となっています。そして、全体の長さの40%を開始位置とし、残り60%の内の最初の120秒を対象に切り取っているようです。(*1) ちなみに、サンプル音源が120秒に満たない(=全体の長さが200秒に満たない)場合は残りの60%全てを対象とするので、全体の長さが短いほどサンプル音源の長さも短くなるようです。 追記 (2011.10.23)：どうやらBeatportサイトでも仕様が統一されていないようで、波形の表示は上記のルールに従っていると思うのですが、サンプル音源の切り取り方が間違っています。。。全体の長さが200秒より小さく120秒以上の場合、サンプルの切り取り範囲は長さが120秒になるように開始位置が前にずれます。そして、全体の長さが120秒に満たない場合は、全てがそのままサンプル音源となります。(*2) サンプル音源の波形を任意の横幅で切り取る サンプル音源の波形画像の横幅は曲の長さによって異なりますので、任意の横幅で切り取るためにはトラックごとに拡大縮小を行う必要があります。 &#8230; <a href="http://dev.yuichiroharai.com/post/beatport-using-waveform/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
		<wfw:commentRss>http://dev.yuichiroharai.com/post/beatport-using-waveform/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

