MP4ファイル結合時の音ズレを防止する為のMP4BOXフロントエンドです。
ダウンロードはこちらから。
1.1.1.0 変更点
・チャプター名の連番の桁数を指定できるように変更しました。
・チャプター設定に「処理終了後に一時停止」オプションを追加しました。
・その他、細かいバグを修正しました。
スポンサーリンク
MP4ファイル結合時の音ズレを防止する為のMP4BOXフロントエンドです。
ダウンロードはこちらから。
・チャプター名の連番の桁数を指定できるように変更しました。
・チャプター設定に「処理終了後に一時停止」オプションを追加しました。
・その他、細かいバグを修正しました。
コメント
一通り新しい機能の動作を確認して特に問題ありませんでした。
動作に全く影響しませんが、ダウンロードページの表記が
1.1.0.0 (2014/03/04)NEW!
となってます。
現在、
0.4.6でのおそらく最終版の
http://www.videohelp.com/tools/MP4Box/old-versionsもしくはhttp://kurtnoise.free.fr/mp4tools/
MP4Box-0.4.6-rev2735.zipファイルのMP4Box.exeとjs32.dll（とVC++2010ランタイムが入ってない場合はmsvcr100.dllも）
バイナリが公開されている物だと一番新しい
https://code.google.com/p/mp4v2/downloads/list
mp4v2-r479-windows-binaries.zipファイルのmp4chaps.exeとlibmp4v2.dll
を使用して結合しています。
.net 3.5が入ってると何故か関係ないですが、.net 2.0のみの環境の場合はVC++2008ランタイムも必要みたいです。最新の0.5.1-DEV-rev5129でも同様でした。
バージョンはちょっと古いものの、
Yamb 2.1.0.0 beta2に同梱されているMP4Box.exeとlibgpac.dll
http://kurtnoise.free.fr/mp4tools/
こちらのmp4v2 tools trunk-r355.zipにあるmp4chaps.exeだとランタイムは必要ないみたいです。
ただ、このバージョンのMP4Boxの別のコマンドでエラー吐いたので使ってないですが…
とても便利なツールなのでダウンロードページやReadMeに、もし推奨バージョン等あれば表記しておいてもらえると助かります。
1.0.2.0のページでMP4Boxの0.5についての記載がありますが、後からこのサイトに来た人だと分かりにくいのではないかと思いまして。
今回は要望に応えてくださりありがとうございました。今後も使わせていただきます。
@nki さま
バージョン表記の指摘ありがとうございます。
こっそり訂正しておきました（- -；
奨励バージョンといいますか、私が動作確認した mp4box.exe と mp4chaps.exe のバージョンをダウンロードページに記載してみました。
MP4BOXの0.5に関する注意点もそちらに移動したので前よりは見つけやすいかと思います。
ランタイム関連は VC++ まわりに詳しくないのでいまいちよくわかってません（＾ ＾；
ビルドの仕方にもよりますが、一般的に出回っている版に関しては mp4box.exe => VC++2010、mp4chaps.exe => VC++2008 が必要な気がするので、その旨も弱気に記載しておきました。。。
WindowsXP のサポートも終了することですし、このツールも Windows7 標準の .NET 3.5 に移行しようかなと思ってみたりしています。
お久しぶりです。
もうかれこれ二年ほどになりますが、バージョン1.1.1.0をずっと問題なく使ってきました。
しかし先日、ちょっと大き目の動画を作ってみたのですが、作成されるチャプターファイルのタイムスタンプがおかしくなることを発見しました。
19:06:28.615 [254]
19:07:53.756 [255]
19:08:24.746 [256]
-10:-17:-05.-997 [257]
-10:-05:-17.-325 [258]
-09:-58:-04.-941 [259]
(中略)
-01:-14:-29.-420 [376]
00:-43:-01.-492 [377]
00:-01:-30.-044 [378]
といった感じで、19時間を過ぎたあたりで、まるで値がオーバーフローしているような挙動を示していますが、心当たりがございませんでしょうか？
チャプター数がちょうど256(8ビット)番目というのが気になったのでもう一度他の動画で試したら当たりでした。
14:30:04.925 [254]
14:38:59.459 [255]
14:49:05.987 [256]
-15:-46:-49.-313 [257]
-15:-45:-59.-307 [258]
-15:-45:-28.-235 [259]
どうやらチャプター数が256個を超えたところからタイムスタンプがおかしくなるようです。
かこん さま
おひさしぶりです。
長い間ご利用いただいているようでありがとうございます。
ご報告いただいた件ですが私の方でも症状を確認しました。
結論から言いますと24時間を超える動画の場合に発生する不具合になります。
① まず Duration の取得を MP4BOX -info が吐き出すテキストを正規表現で解析しているのですが、24時間を境に次のような違いあるため正常に取得できていませんでした。
24時間未満 Duration 23:59:59.999
24時間以上 Duration 1 Days, 23:59:59.999
② 次にチャプター情報を出力する段階で24時間以上だとゼロに戻ってしまうようになっていました。
23:59:58.000
23:59:59.000
00:00:00.000
00:00:01.000
00:00:02.000
いずれも24時間を超える動画を想定していなかったのが原因です（＾ ＾；
①については正規表現を見直し、②については24、25、26と言うように時間部を加算するように変更したところ正常に動作しました。
久しぶりにバージョンアップして1.1.2.0を公開しておきましたので試してみて下さい。
ぬっき～ さま
早速の対応ありがとうございました。
こちらで29時間ほどの動画で試したところ新しい1.1.2.0にて正常に動作することを確認しました。
また新たに紹介してありましたgpac-0.6.2-DEV-rev34にアップグレードしましたが、正常に動作しているようです。ただ、タイムスタンプが0.5.1のときと比べるとほんの少し(2msほど)ですが、違いがあるようです。ただ、1/10フレーム程度の差なので影響はないようです。
ところで24時間を超える場合に問題があるというのは理解できましたが、それとチャプター数が256個以上のタイムスタンプのみ限定というのは何か関係があるのでしょうか？
かこん さま
新バージョンで正常に動作したとのことでひと安心しました。
MP4BOXについても検証していただきありがとうございます。
ご質問の件ですが、私としては次のように解釈しており、必ずしも256個で発生するわけではないと思っています。
高速モードは次のように2つずつ結合されていきます。
1回目 [1]+[2], [3]+[4], [5]+[6], [7]+[8]
2回目 [1 & 2]+[3 & 4], [5 & 6]+[7 & 8]
3回目 [1 & 2 & 3 & 4] + [5 & 6 & 7 & 8]
毎回括弧の部分のDurationを取得・保持するのですが、この時に24時間を超えていると日数×24時間分差し引いた値になっていたのが今回の原因です。
一方でチャプター位置は結合点（上の例のプラスの位置）の時間を保持しておき、全結合完了後に結合点自身より前方分の時間を加算するように再計算します。（実際にはカットされた時間なども誤差修正しています）
この時に日数×24時間分差し引かれた値が含まれていると、それ以降の結合位置の計算でマイナス値が発生してしまうわけです。
こういった処理の関係上から、24時間を超える動画ができたのをn回目とすると「2の(n-1)乗」の倍数の位置からズレが発生することになります。
7～9回目で発生すれば64、128、256の倍数になるので「256」という値がでる確率があがります。おそらく今回はこのパターンではないでしょうか？
なかなか文章でお伝えするのは難しいです。。
ぬっき～ さま
詳細な解説ありがとうございました。
なるほどそういう理由で256番目からずれていたのですね。
確かに高速モードの動作からすると、納得できました。