1. このサイトではcookie (クッキー) を使用しています。サイトの利用を継続した場合、cookieの使用に同意したものとみなさせていただきます。 詳しくはこちらをご覧ください。

m4aのエンコードについて

It's2019-01-08に開始した「ツクールMV」の中の討論

    タグ:
  1. It's

    It's ユーザー

    私は、BGM素材を作ったりしているのですが、MVは、持っていないので、
    サイトの素材も今の所、MVには、対応していません。
    フォーラムにも登録したしMVにも素材を対応させたいと思い、
    MVの仕様を確認した所、m4aファイルが必要だという事が分かりました。

    ループタグの付け方等は、ネットで調べて分かったのですが、
    質問したいのは、ITUNSMPBタグについてです。

    このタグを調べてみると、どうやらギャップレス再生というのに使うものだと分かりました。
    このギャップレス再生ですが、メーカーごと、機器ごと、ソフトウェアごとに方式やサポートが
    バラバラなようです。

    アツマールでは、ITUNSMPBタグが無いとループの曲が再生されないようだとアナウンス
    されていますが、ITUNSMPBは、Appleの方式のようで、
    他のギャップレス再生の方式もあるようです。
    例えば、フラウンホーファーFDKAACエンコーダーでは、
    ITUNSMPBとISO標準の両方のギャップレス再生の方式をファイルに含める事が出来るようです。
    このISO標準といった他のギャップレス再生の方式は、ツクールMVで作られたブラウザ版の
    プロジェクトでは無視されるのでしょうか?
    あるいは、ハードウェア環境によっては、両方含めておいた方が汎用性を高く出来るのでしょうか?
    また、ブラウザ版をプレイする際、スマホ等のハードウェアがITUNSMPBのギャップレス再生を
    サポートしていない場合、BGMが正常に再生されないという事は、あるのでしょうか?

    それから、ITUNSMPBタグが必要という事は、ループ処理にギャップレス再生を使っている
    という事だと思うのですが、LOOPSTART等のツクールのループタグによる再生とは、
    どのような関係性になっているのでしょうか?
    詳しい方おりましたら、よろしくお願いします。
     
    #1
    ネオジムリンクス がいいね!しています
  2. It's

    It's ユーザー

    引き続き、自分で調べてみました。
    HTML5の<audio>タグで扱う事が出来るフォーマットは、ブラウザが対応しているかどうか、
    みたいだったので、aacに関しての対応状況を調べてみました。

    Chrome ネイティブ対応(ブラウザ単体でaacを鳴らせるという事) デコーダー ffmpeg
    Safari ネイティブ対応 デコーダー Quick Time
    IE ネイティブ対応 デコーダー 分かりませんでした。
    Chromium 非対応
    FirefoxとOpera 非対応だが、OSやハードウェアが対応していれば鳴らす事が出来るようです。
    参考 MDN web docs HTMLのaudio及びvideoで対応しているメディア形式
    参考 Safari HTML5 オーディオとビデオガイド

    やはり、ネイティブ対応のブラウザでもデコーダーが違うのと、
    ハードウェア依存等の場合は、ITUNSMPBに対応していない可能性があるように思えます。
    ただ、この問題は、mpeg4の規格自体の問題のようで、昔から付いて回っている問題のようです。
    参考 FFmpeg Wikipedia 音ズレ問題辺りに書いてあります。

    調べていた時に参考になりそうな記事を見つけました。
    参考 ChromeのWebAudioが抱える不具合と対策
    参考 エンコーダーディレイについて

    ギャップレス再生は、このエンコーダーディレイで発生する無音部分を切り落とす処理のようなのですが、
    これが残っている場合、ツクールのループ再生時にも、おそらくサンプルがずれてしまうのではないでしょうか?
    ツクールMVのコアスクリプトの方で、この事に関する補正処理は、されているのでしょうか?
    自分は、HTML5もjavascriptも全く読めないので、コアスクリプトを見ても良く分かりませんでした。

    こんなサイトもありました。
    参考 Media Source Extensions(MSE)を利用してオーディオのギャップレス再生に使う方法らしいです。
    ITUNSMPBの解析をしている部分もあります。

    上記サイトのような方法、または、Chromeのバグフィクスの記事などによる方法を使って、
    あるいは、それを応用して、エンコーダー、デコーダーによらずに
    ギャップレス再生可能なファイル = 綺麗にループするファイルを作成するような
    プラグインは、既に存在していたりしますか?していない場合、作成する事は、可能なのでしょうか?
    ITUNSMPBだけでもそうした仕組みがあれば、ハードウェアやソフトウェアによる相性問題を
    ある程度軽減出来そうな気がします。

    HTML5やjavascriptに関する知識がありませんので、変な質問をしていたらすみません。
    BGM制作者としては、綺麗にループ出来ないのは、困りものです。
    MV素材作りたかっただけなのに、かなり難しい質問になってしまいましたが、
    どなたかよろしくお願いします。
     
    #2
    リンクス がいいね!しました
  3. It's

    It's ユーザー

    調べていけば行くほど、素人には荷が重いという事が分かりました(笑)
    エンコーダーディレイ値が変わらないなら、波形編集で何とかなるかもと思って
    Audacityで拡大しながら遅延を調べてみた所、

    ITUNSMPBの入るデータでは、遅延が見られず、
    フラウンホーファーFDKAACエンコーダーのISO標準のみでは、2048サンプルの遅延。
    FFmpegネイティブエンコーダーでは、1600サンプルの遅延でした。

    エンコーダー自体が、エンコーダーディレイ分をすでに切ってしまっているものもあれば、
    ファイル内に明示されていて、デコーダーでそれを読み取る事で対応しているものもあるようで、
    先に遅延分を波形編集で切ってしまうと二重にディレイ分が切られてしまう可能性が
    ありそうで無理でした。
    という感じで、ちょっとこれは、お手上げですね(笑)

    結果として、元も子もないのですが、もっとも普及率が高そうなiTunesでエンコードしておく、
    というのが今出来る精一杯の対策なのかなと思いました。

    と、ここで、じゃあ、公式どうなってるんだろう?と思い、
    MV20万本突破記念BGM集を覗いてみると、なんと、ループタグがありませんでした。
    Audacityで波形を拡大してみると、オーディオの最初の部分に0.1秒に満たない程のフェードイン、
    最後の部分は、ゼロクロスからファイル終端までの0.1秒に満たない程が音量0にされていました。
    なるほど~。一見するとなんでこんなに無理やりループっぽく見せているのだろう?
    と思いましたが、mpeg4やjavascriptの事情など色んな要素を考えた場合、
    これが最善なのかもしれません。
    これでもデコーダが対応していなければ、正確に再生されない可能性は、あると思います。
    しかし、この方法では、ループタグに対応していない状況でも正確に鳴らせます。
    ループタグを使った作り方が出来なくなりますが、javascriptは、動作が重たいようで、
    曲は、軽量化する必要がありそうです。そうなると、ループ部分だけの大体1分程のデータに
    収める方が無難でもあります。そしてなによりループタグが要らないので、制作が楽です。
    また、iTunesでエンコードすれば、遅延は出ない?っぽいですから編集、変換もしやすいですし、
    普及率を考えると相性問題も最大限起こりにくくなってそうな気はします。
    もちろん曲のループポイントで音が一瞬切れるのは分かりますが、ノイズは発生しませんね。

    昔のツクールは、綺麗にループして当たり前で、3分でも5分でも曲を再生出来ましたが、
    その感覚でいるとMVは、面食らってしまいますね。ブラウザ対応状況や、APIの状況などは、
    調べていて目が回りました。
    というわけで、もはや、質問でもなんでもなくただのメモになりましたが(笑)
    同じ疑問を持った人のお役に立てたらと思います。
    とはいえ、エンコーダーディレイ問題が解決出来ればそれが一番いいと思いますので、
    一応、諦める以外の方法を知っている人が居ましたら、引き続き、返信は、お待ちしてます。

    追記 2019 2 20
    すごく今更ですみませんが、多分、間違った事を言っていた事に
    気づいてしまったので、訂正します。

    MV20万本突破記念BGM集ですが、オーディオの最初は、フェードインでは無いと思います。
    これは音源の音自体の出だし部分の波形が見えているだけで、フェードイン加工は、されていないと思います。
    また、ゼロクロスから終端まで音量0にされていると言いましたが、oggファイルと比べてみると、
    この音量0部分は、oggファイル側には、存在しません。つまり、これが問題のエンコーダーディレイだと思われます。
    iTunesでエンコードをした場合、オーディオの開始部分のエンコーダーディレイは、削除されますが、
    ファイルの終わり側に追加される無音部分は、ファイル作成時には、削除されないようです。
    なので、正確なファイル加工部分は、終端がゼロクロスで切ってあるという部分だけだと思われます。
    この方法が最善そうだなあという事は、変わりありません。

    しかし、m4a周りは、複雑な事情が取り巻いていて、
    これは、素材屋さんも増えないわけだと思いました(笑)
     
    最後に編集: 2019-02-20
    #3

このページを共有