mp3を正しくデコードできていない

フォーラム TuneBrowser mp3を正しくデコードできていない

  • このトピックには5件の返信、2人の参加者があり、最後にTikiにより6年、 3ヶ月前に更新されました。
6件の投稿を表示中 - 1 - 6件目 (全6件中)
  • 投稿者
    投稿
  • #4084
    orange_in_space
    参加者

    mp3のデコードが正しく無いせいで、(浮動小数点表現で言う所の)-1.0~1.0を越えるデータを正しくデコードできていません><

    世の中の結構多くのソフトウェアでそうなのですが、
    (例えばWMPやWinamp、プロ向けのソフトウェアではCakewalk(sonar)やCubase 8(9.5では修正されたそうです)等)
    (逆に標準で正しくデコードできている例をひとつあげるとfoobar2000等)

    おそらくデコーダ(ffmpeg?)から16bitで受け取って、その後音量に関する処理をしているようですが、
    そもそもmp3は、(16bitの結果を得たい場合に)16bit整数でデコードできるようなフォーマットではありません><

    詳しくは私が作成したmp3チェックデータとその説明書を読んでいただけるとありがたいです><
    https://github.com/orange-in-space/mp3-playback-check-audiodata

    使用したバージョン: Free Edition 4.5.5 x64
    オーディオインタフェース: Roland(BOSS) GS-10
    (WASAPIループバックでも調査したのでオーディオインタフェースは無関係)

    また、整数での処理にこだわっている点についてですが、
    (ここを参考にしました) https://tunebrowser.tikisoft.net/forums/topic/787/

    (完全に追って無くてソースコードを斜め読みなので申し訳ないのですが)
    ffmpegのmp3デコーダは内部32bit floatで処理しているようです><
    https://github.com/FFmpeg/FFmpeg

    もしそうであるのであれば輪をかけて、16bit整数でデコーダから受け取る事のデータ精度上の意味は全くありません><
    単にデコーダが勝手に決めた結果的に元データと全く無関係と言える精度に落とし込んでいる(しかも波形が破壊されている)ので
    その16bitでのデコード結果をそのまま尊重するのは本末転倒です><

    整数にどうしてもこだわるのであれば24bit整数で処理するデコーダがあるらしいのでそれを使うといい感じかもです><
    一例(ただしこれはGPLv2・・・><;)
    https://sourceforge.net/projects/mad/

    (何者か情報)
    orange
    マストドン(いつも居る(?)): https://mstdn.nere9.help/@orange_in_space
    ツイッター(最近あんまり使ってない): https://twitter.com/orange_in_space
    趣味で音関連のプログラミングしたりしてる人です><

    #4086
    Tiki
    キーマスター

    こんにちわ。

    mp3は32bit floatでデコードしています.

    最終的にfloatのままではデバイスには引き渡せないので、出力時にデバイスに合わせて24または32bitの整数に変換しています。ご指摘のべつのトピック (https://tunebrowser.tikisoft.net/forums/topic/787/) は、ゲイン調整をどこで効かせるかという議論で、整数化する前か後かという話でした。

    どうぞよろしくお願いします。

    #4088
    orange_in_space
    参加者

    ごめんなさい><;
    早とちりしていました><;
    失礼しました><;

    御返事を読んであれ?><;っと思ってあちこち見て、”Gain”(全体ゲインの切り替え)と書いてある所から”-3dB”に設定したら、
    私が作成したチェック用データも正しく再生できました><
    (でも、ヘルプに記載が無いような><;)

    ただ、私が作成したチェック用データは、+1dBFSオーバーするように作っているので、その分以上音量を下げるようにそこを設定すれば正しく再生できますが、さらに全体ゲインの切り替えで下げた値以上の音量のmp3データを再生した場合には、ボリュームバー(出力ボリュームでしょうか?)の状態に関わらずクリッピングを起こしてしまう一方で、非圧縮や可逆圧縮の出力デバイスと同等の量子化bit数のデータが必ず丸められてしまうと思うので(私はbitパーフェクト再生にはこだわらないので、精度が十分であれば問題ないと思いますが)、意図がちょっとわからないです・・・><

    そもそもデータの方が正しくない(のにそういうデータが例えばamazon mp3にもアーティストが自サイトで配ってるファイル等にもたくさんある)のが問題なのであれですが><;

    勘違いごめんなさい><;

    #4090
    Tiki
    キーマスター

    こんにちわ。ご確認いただき、ありがとうございました。

    #4099
    orange_in_space
    参加者

    勇み足過ぎた点本当にごめんなさい><

    ものすごく失敗してしまった上で申し上げにくいのですが、一応感じた点としては、

    正しくデコードできているか、それとも設定とデータの組み合わせて内部で問題が起きていてクリッピング等を起こしているか表示された方が、わかりやすいかと思います><(出来る事ならばその警告表示に、設定を変えれば正しくデコードできる可能性がある事を示唆するヒント表示があったらさらに便利かもです><)

    その表示が無い点と(Gain設定とは別の)標準のボリュームの処理が整数化の後に入っていてその手前の処理でのデータの健全性に対して効果が無い点が特にヘルプに記載が無いので(それも私の見落としだったらごめんなさい><)、おそらく初期設定のままでは正しく再生出来ない事がある事を知らずにそのまま使ってクリッピングした状態の音を聴いてる人がかなりいるのではないかと><
    (Gain設定の実際の仕組みに気づけなかったユーザーはもちろん、例えば仮にGain設定を知っていて例えば-3dBに設定しているユーザーであっても、想定(設定)以上のピークになっているデータ(3dBFS下げてもダメなデータは滅多に無いでしょうが><;)を再生してしまった場合に気づけないですよね?>< ピークメーターはその後に入っていて(?)クリッピングインジケータも無い(?)ですし、Gain設定で下げても表示は変わらないようなので・・・><)

    #4102
    Tiki
    キーマスター

    おはようございます。

    以下の設定を変更すると、クリッピングが発生したときに、ピークメーターの色を赤くすることができます。設定画面の

    • ツリー項目「再生の設定」「デコードの設定」
    • 右側の項目「デコードのその他の設定」「クリップを検出する」

    前のhttps://tunebrowser.tikisoft.net/forums/topic/787/の議論もそうでしたが、この設定はあまりお勧めはしていません(^^;。orange_in_spaceさんも書かれているように、圧縮形式でクリップを起こす音源は本当に多いので、あまりそれを気にしてもいいことはないのかなと思っていました。おっしゃるようにユーザーの方に「知るきっかけを与える」という意味では、有用かもしれませんね。

     

6件の投稿を表示中 - 1 - 6件目 (全6件中)
  • トピック「mp3を正しくデコードできていない」には新しい返信をつけることはできません。