- このトピックには14件の返信、3人の参加者があり、最後ににより6年、 2ヶ月前に更新されました。
-
投稿
-
お世話になります。
Win7 Pro 64bit環境で4.5.5(1408)を使用しています。
或るmp3形式の音楽ファイルをTuneBrowserで再生すると、20数秒くらいで強制終了してしまいます。
全く再生されないのではなく、途中までは問題なく再生されます。他の音楽プレーヤーで対象ファイルの再生を試しましたが、特に強制終了する事はありませんでした。
再生を試した音楽プレーヤー
・foobar2000 Ver1.4
・Sound Player uLilith Ver1.0 pre-Beta.4
・AIMP Ver4.51
・MediaMonkey Ver4.1.21.1875
・Windows Media Player Ver12mp3ファイル自体に原因があるとは思うのですが、何処に問題があるのかわかりません。
何かアドバイス(例えば、mp3のxx部分を調べてくれ等)ありましたら是非教えて下さい。以上、ご回答宜しくお願い致します。
こんばんわ。
それだけのソフトで再生できていながらTuneBrowserだけ再生に支障が出ているのというのが、また(^^;アレな感じですね。ログの添付ありがとうございます。ログ内に書かれている通り、ファイルの先頭からのオフセット418477バイト目、996番目のフレームでなにか異常を検知しているようですが、残念ながらこれ以上の情報はわかりません。
もしMP3のファイル構造にお詳しいようでしたら当該位置のフレームヘッダを見ていただければなにかわかるかもしれませんが、わたしのほうでも調べてみますので、問題の出ているファイルをお送りいただけないでしょうか? この後、登録されているメールアドレスに、ファイルの送信方法をご案内します。
お時間のあるときで結構です。お手数をおかけしますが、よろしくお願いします。
こんばんわ。
データの送信ありがとうございました。確認したところ、やはり上で指摘が出ていた位置にゴミデータ(?)が入っていました。MP3の処理については、冒頭部にゴミデータがあることは想定していたのですが、途中にあるものについては現在の動作の通りデコードエラーということでデコードを止めています。
これをスキップして、次の有効なフレームを探してデコードを継続する、というようにできないか、検討します。
mardukさん、Tikiさん、おはようございます。
>途中にあるものについては現在の動作の通りデコードエラーという
>ことでデコードを止めています。
>これをスキップして、次の有効なフレームを探してデコードを継続する、
>というようにできないか、検討します。>
多少データに傷があっても再生できる事は聞けるデータの対象が広がるので
良い事だと思います。
しかし現在の動作も是非残して頂きたく思います。失礼致します。
こんばんわ。
他の音楽プレーヤーには該当箇所を回避する仕組みがあるのですかね
たしかに他のプレーヤーのことはわからないのですが、TuneBrowserでは、
- 現在の処理: 先頭から有効フレームを探して、見つかった以降から再生対象にする. 途中で無効フレームが見つかった場合は中止.
- 新しい処理: とにかく有効フレームを探して再生対象にする. 結果として無効フレームは無視される.
というように変えようと思っています。他のソフトはこの後者の処理になっているものと思います。…というか、それ以外に思いつかないですね。
TuneBrowserでなぜ最初から後者の処理にしていなかったのかというと、無効フレームがあって、それがデータ破損によるものだった場合、結果としてフレーム間の連続性が失われ、聴覚上のパルスノイズにつながる恐れがあると考えた故です。パルスノイズや爆発的なデータは、音楽を聴くときに発生すると不愉快なもので、TuneBrowserがDSD以外では既定でかならずフェード処理を行っていることと同じ理由で、再生ソフトとしてはできるだけ避けなければならないものだと考えています。
ただサンプル的に組んでみた対処では、mardukさんのデータではパルスノイズは認められませんでしたし、ひょっとしたらMP3のような不可逆圧縮の方式では、フレームが不連続になったとしても、原理上パルスノイズは発生しないものなのかもしれません。ただ残念ながら、わたしにはそれを裏付けるだけの知識も数学的能力もありません。
sambacancaoさん、コメントありがとうございます。
しかし現在の動作も是非残して頂きたく思います。
現在は上記のような対処にしようと思っていますが、「現在の動作」について、もしなにかとくに気にされている点があれば、教えていただけないでしょうか?
よろしくお願いします。
Tikiさん、mardukさん、おはようございます。
>>しかし現在の動作も是非残して頂きたく思います。
>現在は上記のような対処にしようと思っていますが、「現在の動作」について、
>もしなにかとくに気にされている点があれば、教えていただけないでしょうか?
聞けない曲がが聞ける様になるのは大変有難い事だと思います。
ただデータに傷がっても再生を続行する為に傷の部分を無音で飛ばしたり、
前後のデータからそれらしいデータを埋めてノイズや音質低下につながったり、
傷の部分をカットして寸足らずになったり等々が起きないか素人考えで心配
だったので、現状のエラーが出たら停止の仕様も残して頂きたかったのです。話は逸れますが、OSXのiTunesの様にMP3に多少傷が有っても普通に再生
されてしまうのでファイルが壊れた事に気付かず後で気づいて処理に追わ
れるよりは現状のTuneBrowser仕様の様にエラーが出たら停止の方が早
めに対応が出来るので良いと感じた次第です。失礼致します。
こんばんわ。コメントありがとうございます。
なるほど、そういうニーズもあるのですね。個人的にはファイルの妥当性をチェックするツールを作って確認していたこともあるのですが、最近は (わたしのところでは) ファイル破損も少なくなり、TuneBrowserにもそういう機能は入っていません。
MP3の今回の対応は、かなり低レイヤの部分に入れる計画ですので、設定での切換えはむずかしいかもしれませんが、もうすこしなにか工夫できないか考えてみます。
こんばんわ。
ご配慮ありがとうございます m(__)m。わたしも、どうすべきかな… というのは迷ったのですが、mardukさんに検証いただいた通り、趨勢としては再生を継続するという方向が一般的のようですので、ここで肩肘張ってもしかたがないのかな、と思いました。
じつは、もともとTuneBrowserには「デコードエラーを検出した場合」の挙動を定義する設定があります (設定ツリーの「再生の設定」「デコードの設定」のページです)。ただこの設定の効き具合というのは、検出できるエラーの程度も含めて、コーデックの種類によってまちまちです。sambacancaoさんのご意見もうかがって、今後時間をかけてこうしたご要望への対処方法を考える価値はあるのかな、と考えていました。
TuneBrowserの基幹部分への影響は、今回計画している対処はMP3に完全にフォーカスした対応になりますし、あくまでもエラーフレームを検出した場合の挙動のはなしですので、わたし自身は全体的にはあまり心配はないなと考えています (ご心配をおかけして申し訳ありません)。ただ、上の返信にも書いたとおり、エラーフレームがあったときの不連続性によるノイズの可能性が少々気がかりではあるのですが、そこは、これまでユーザの方にお送りいただいたエラーを含んだMP3ファイルでも確認をして判断したいと思います。
デコードに関係する変更は、ここしばらく発生しておらず、ひさしぶりです。とはいえ、それは処理が完成されているということでは必ずしもなく、依然として多くのTuneBrowserでの処理はわたしの自己流です。MP3に関してはとくに、フォーマットそのものがレガシーになってきていますので、エンコーダ特有の拡張に関する情報などは、どんどん失われてきているように感じています。これはつまり、世界的に改めて新規開発されるデコーダはもうほとんどないということを意味していて、こうした点はTuneBrowserの「後発の弱み」にもなっています。ですから、こうしてご指摘をいただいて、サンプルケースを得る機会があるのは、とても有難いことだと思っています。
いろいろと考えている最中だったというのもあるのですが、週末の夜中になるとどうも文章が長くなっていけませんね(^^;。後半は適当に読み飛ばしてください。どうぞよろしくお願いします。
補足です。
少々誤解の余地のある表記をしてしまったかもしれません。TuneBrowserはMP3の音声フレームのデコード (PCM化) はFFmpegを利用しています。TuneBrowser独自で処理しているのは、MP3ファイル内のMPEGフレームヘッダを解釈して (エラー判定して) FFmpegに引き渡す処理の部分になります。
こんにちわ。
先ほど4.6.0の先行版を公開しました. 今回の件の対処を入れています. お時間のあるときにでもご確認いただければ有難いです. どうぞよろしくお願いします.
こんにちわ。
さっそくご確認いただき、お手数をおかけしました。よろこんでいただけて、わたしも嬉しいです(^^)。
ありがとうございました。
- トピック「MP3の再生時に曲の途中で再生終了してしまう」には新しい返信をつけることはできません。