プレーヤー作成中、ブロックデコード関数を公開したけど、仕様の厳しさを感じている。末端でブロックサンプル数が少なくなったときの処理が難しい。

ブロックヘッダにサンプル数を記録すべきでは無いかと考えている。そしてヘッダのブロックあたりサンプル数は最大ブロックサンプル数に変更。そうしないと現在のブロックをデコードするときに何サンプルデコードすべきかわからなくなる。末端までサンプル数固定にするのもありだけど、無音が挿入されるのが汚い。

論文についての返事がないので実装を進めた。ブロックヘッダにサンプル数を入れた。

単純再生サンプル作った。この春できるのはここらへんまでかな。参考にしたリンクは以下。

データフォーマット

ヘッダフォーマット

bit幅 内容 補足
32 'N', 'A', 'R', 'U' NARUファイルであることを示すシグネチャ
32 フォーマットバージョン番号 エンコードしたときのフォーマットバージョン
32 エンコーダバージョン番号 エンコードしたときのエンコーダバージョン
16 チャンネル数  
32 サンプル数 1チャンネルあたりの全サンプル数
32 サンプリングレート  
8 サンプルあたりビット数  
16 ブロックあたりサンプル数 現状固定の想定。
8 フィルタ次数N 2の冪定数に限定
8 AR(p) モデルの次数p N > 2*p を満たさなければならない
8 チャンネル毎の処理法  

ブロックフォーマット

bit幅 内容 補足
16 '0xFFFF' ブロック先頭を示す同期コード
32 ブロックサイズ この領域以降のブロックのサイズ[byte]
16 CRC16 この領域以降のブロックのCRC16値
8 ブロックデータタイプ 0:残差、1:無音(ランレングス符号化)、2:生データ
16 チャンネルあたりサンプル数 このブロックに含まれる1チャンネルあたりのサンプル数
不定 データ 圧縮済みデータ or 生データ

TODOリスト

  • リングバッファアクセス高速化: 済
  • ハンドルのワーク配置化: 済
    • 将来的にフィルタもワーク配置したい。自己割当なしで実装すれば良さそう。
  • CRC16対応: 済
  • コマンドライン整理: 済
  • プリセット選定: 済
    • いまのところ、(NGSA次数, SA次数, ブロックサイズ) と書くとしたとき
      • 高速(低圧縮モード)は(4, 4, 8192)
      • 通常(デフォルト)は(8, 8, 8192)
      • 低速(高圧縮モード)は(16, 8, 16384)
    • でいこうと思ってたけど、フィルタ次数を増やしても負荷インパクトが大きくならない+圧縮率が向上し続けるのを見て、次数は4, 8, 16, 32, 64まで選べるようにした。
  • MSVC環境で _BitScanReverse を使う: 済
  • MSVC環境で gtest できるようにする: 手が空いたらでよい。
  • 評価開始(評価スクリプトを作る。Rubyでいい。)