昨日の日経新聞の文化面に、レコード針のナガオカの社長さんが書いていたのを見て思い出しました。
実家にあったターンテーブルを持ってきたら、ちゃんと回らない orz
修理しなくては、、、と思いながら早4年。なんと意思の弱いことよ。
それはともかく、ハマッていたのは、STB
からS/P DIF
から録音したwav
ファイルから、ext_bs
でaac
ファイルを作成するところ。短いファイル(
数分)
ならば問題なく変換できているのですが、映画1
本分ぐらい(2
時間弱)
の長さになると、「」と表示されて変換できません。頭キテ、「IEC61937(-1,-2,-6
あたり)
を買って自分でつくっちゃおうか?
」と無謀な思いをはせたりしてました。
物は試しで、Waveファイルの編集をするツールで長いファイル(long.wav)を50分くらいに分割(long1.wav,long2.wav)にして、ext_bsに食わせるとちゃんと、変換できます(long1.aac,long2.aac)。で、これを、
copy /B long1.aac+long2.aac long.aac
とかやって強引につなぎ合わせると全編分のaacが問題なくできました。まあ、継ぎ目のところは1ブロック分デコードできてない可能性はありますが、今回の実験ではちょうどstuffing dataのところで分割したようで問題なかったようです。
で、バイナリエディタBz (Vzを作った人なのね,懐かしい)で中身をみてみると、オリジナルのwavデータのDataチャンク(RIFFチャンクも)の長さが変。dataチャンクの大きさが8000_0000(h) とかになってます。Linuxのarecordコマンドで録音して、録画終了時にkill で止めてるいるためでしょう。
もともとWavファイル(RIFFフォーマット)は4GBを越えられないのは知っていたけど、2時間でも、4800×4×60×60×2= 138240000 だから大丈夫と思っていたのですが、こんな値とは…本来uint32_tで扱わなければならないところを、int32_tで扱っているとすると、負の値になってしまいます。これが原因かな?んー、ext_bsのバグですかね。
普通はWavファイルの作成にでarecord + killなんか使わないのでしょうから、ちゃんとしたwavファイルができていて、この場合数時間でもdataチャンク長は正の値ですから問題が顕在化していないのでしょう。。。
実ファイル長とdataチャンクの長さなんて、どうせ厳密には調べてないと思い、bzでdataチャンクの長さを適当に正の値に変えてやったら、ext_bsでちゃんと最後までaacに変換できました(らっきー)。
というか、linuxでarecordを動かしているスクリプトの中で、arecordを止めるのに、SIGKILLを送っているのがマズイ。ちゃんとSIGTERMにしたらdataチャンクの長さが正しいwavファイルができました。スクリプトは直しておきます。(ああハズカシイ)
effelpist@
Jun@
ＡＳＯＢＯ@
