私は C++ でクロスプラットフォームのオーディオ エディタを開発しており、メディア ファイルを 1 秒あたり 0 ～ 5 回 (再生モードで、または画面にサウンドを再描画するときに) 読み取ります。実装はファイルを開き、そのファイルに対するすべての読み取り操作の間、記述子を開いたままにします。
そのファイルが開いていても、ファイル操作を禁止しない方がユーザーにとってよりフレンドリーだと思います。ユーザーが再生中にそのファイルを削除できるようにします（必要に応じて）。次にそのファイルから次のブロックを読み取ろうとして失敗した後、プログラムは再生を停止します。
最新の Windows / Linux / Mac OS システムでは、open()/close() 操作は高価ですか?
しかし、巨大な MP3 ファイルを open()/close() するのは難しいでしょう。なぜなら、MP3 の「seek()」はコストがかかる (必要なブロックの前にすべてのブロックのヘッダーを読み取る) からです。
多くのプロ オーディオ アプリ (または少なくとも一部) は、再生中はファイルを開いたままにし、再生していないときはファイルを閉じます。ただし、Pro オーディオ アプリは、MP3 などの形式をネイティブに処理することはできません。常に最初に非圧縮形式に変換されます。この理由の1 つは、MP3 のサンプル精度のシーク時間が非常に悪いことです。理論的には、MP3 読み取りライブラリはファイルを閉じて、何も変わらなければ中断したところから再開することができますが、MP3 ライブラリがこれをサポートしているとは思いません。対照的に、圧縮されていないファイルは非常に高速で、簡単に検索できます。
質問に戻ります。画面を再描画するたびに、また再生中に頻繁に再オープンして再シークしますか? それはできますし、画面を開いたままにしておくのに比べて、画面の再描画をドラッグすることさえないかもしれません. 最新のマシンは、特にファイルが 1 つだけの場合は、十分なバッファリングを使用して再生中に確実に追いつくことができるため、それも実行可能です。本当にやりたい場合は、いくつかのテストを行って、パフォーマンスへの影響を確認し、これだけのためにユーザーのマシンを本当に遅くする必要があるかどうかを確認する必要があります。
また、「フレンドリー」とは何ですか？ユーザーが別のアプリでファイルを「変更」する可能性があることを示唆していますが、その方法と理由は? たとえば、ユーザーがプログラムを「変更」した瞬間にプログラムを再開しようとするとどうなるでしょうか。変更には、別のファイルでの置換が含まれる場合がありますが、多くのアプリケーションでは、最初に元のファイルを削除し、次に置換を書き込む (または置換を所定の位置に移動する) ことによって、ファイルを "置換" します。では、アプリが間違ったタイミングでファイルを開こうとするとどうなるでしょうか? 「ああ、ファイルがなくなったので、再生を停止します」と表示されます。さらに悪いことに、置換が部分的にしか書き込まれていないときにプログラムが開きます。うん。さらに悪いことも想像できますが、それが始まりです。
ファイルに書き込む必要がある場合 (ID3 タグなど)、通常はファイルを RW モードで開く (または既に開いているファイル記述子を再度開く) ことで実行できます。ファイル。状況が競合状態に満ちているため、非常に慎重に計画しない限り、再生中に再生サンプルの数、再生サンプルの場所などを変更する操作を行うことはお勧めしません。やるとしたら自分のアプリでやった方がレースはコントロールしやすいから。
そのため、価値があるかもしれませんが、強くお勧めしません。他のアプリの作成が不十分な場合、悪いことが起こる可能性があります。