□□■x-アプリ / SonicStage V / CP 63th■□□

調べたのでよければどーぞ。
世界数多のAACエンコーダ、デコーダのギャップレス実現方法の斜め上を行く実装の仕方でした。
2曲目以降の開始ポイントが本来より最大511か1023(=X)サンプルぐらい前後にずれるかも。（あんまり調べてないので）
末尾が次曲の先頭に、次曲の先頭が末尾に、なんてことが耳がいい人はわかるかもしれない。
CD44khzでもそのずれは最大X/44100秒なので気付けないと思いますが・・・シャッフル再生で気づくかも

■Xアプリv5のAAC.3gpの実装
・拡張子は3gpを使っているが明らかに内部はMP4フォーマット

■AACギャップレスに対応したというものの・・・その種明かしをしてみると。
・Xアプリv5でCDから取り込むAACファイルはギャップレス再生が（耳に狂いがない限り）できているのは事実。だが、、、
・エンコーダ特有の初期ディレイは0サンプル、そして末尾のパディング部分も0サンプル
　なにを意味するかというと強制的に入力するサンプル数を1024の倍数で切っている（AACのいつもの）（もっと調べる必要あり）
　どうしてギャップレスを実現できているかというとここがミソで、CUEによってからもたらせる本来のサンプル単位の切れ目を
　勝手に1024の倍数単位にするため、（CUEからのズレを最小限にしつつ）前後に都合よく動かしている。
　よって最終曲末尾以外に作られた無音は発生しない仕組みと思われる。それかぶった切らてるかも（調べてないので）
・以上より当然WAVにデコードすれば本来のサンプル数はずれる
・SMPBは当然読まないのでiTunes(QT)の2112+αの部分は無音デコードされるためギャップレス再生はできない
・moraは買ってないが多分こんな感じなのだろう
・HE-AACは何も調べていない
・一般人にはこんな苦し紛れのAACギャップレス実装しても騒がれないから平気なんだろう

例）　　　　CUEから得られるサンプル数　　※実証してない空論です。おそらくこんな感じ
1曲目　　10740サンプル（1024*10+500）→10240サンプルを圧縮、最後の500サンプルは次曲の先頭へ持ち越し
2曲目　　30000サンプル（1024*29+304）→（500+1024*29+304）→また持ち越すと本来のCUEからズレが大きくなるから今度は次の曲の先頭から都合よく220サンプル借りてこよう→30720サンプルを圧縮
以下、そんなせめぎ合いが繰り返し。