コマンドライン ツールを使用してオーディオ スニペットを抽出しようとしています。 常に予期しない結果が得られますが、これはオーディオ ファイルの作成方法やエンコード方法に原因があると思われます。
注: コンテンツを共有する方法は他にもあることは承知していますが、私は、コンピューターにあまり詳しくないユーザーや、生のコンテンツから地理的にブロックされているユーザーとコンテンツを共有するためにこの方法を採用しています。
問題の説明/再現手順:
まず最初にyt-dlpポッドキャストをダウンロードするには、これですこのコマンドで:
yt-dlp -x --audio-format mp3 -o GQT_2012-10-14.mp3 https://www.bbc.co.uk/programmes/b01n6vnhファイルはダウンロードされ、正常に再生されます。20:48 から始まり 03:58 まで続くスニペットを抽出して、24:46 に終了するようにします。
私はこれを最初に試しましたFFmpeg(Ubuntu 20.04 のバージョン 4.2.7-0ubuntu0.1) では、次のコマンドを使用します。
ffmpeg -i "/home/user/GQT_2012-10-14.mp3" -ss 00:20:48 -t 00:03:58 GQT_2012-10-12_Snippet1.mp3
これにより、長さ 3 分 58 秒のファイルが生成されますが、開始時間は元のファイルの 20:28 に相当します。それから私は使ってみましたmp3splt の(同じ OS 上のバージョン 2.6.2。これは古いバージョンであることは承知しています)、次のコマンドを実行します。
mp3splt "/home/user/GQT_2012-10-14.mp3" -o GQT_2012-10-12_Snippet1 20.48.00 24.46.00
これにより、同じ出力が生成されます。ファイルは正しい長さですが、予想される開始時間より 20 秒早くなります。
両方のコマンドライン ツールから同じ結果が得られたので、問題は入力ファイルにあると考えられます。 を使用して調査してみましたffprobe。出力内に、次の内容が表示されました。これは、
Duration: 00:43:00.09, start: 0.025057, bitrate: 141 kb/sファイルが 25 ミリ秒後に開始するように「タグ付け」されていると解釈しています。20 秒ではないことは確かです。
私はとにかくこれをゼロにリセットしようとした。この答え、私は成功しませんでした。
抽出されたスニペットのエラーの根本原因を理解し、修正したいと考えています。
答え1
提供されたファイルでいくつかテストしてみましたが、ffmpeg コマンドは実際に要求した正確な場所でファイルを切り取ると思います。
ここでの本当の問題はプレイヤーシーク時に間違ったタイムスタンプが表示される (vlcと の両方を試しましたmplayerが、同じように動作するようです)。vlcファイルを最初からシークせずに再生すると (実際にはバックグラウンドで 20 分間実行しました)、20:48 に達したときに、ffmpeg によって生成されたファイルが開始する位置とまったく同じ位置になります。 で再生を開始しvlcて早送りすると、その位置は 20:28 として表示されます。 ここでの私の推測は、これらのプレーヤーのシークでは、次のキーフレーム (または同様のもの? mp3 形式の内部にはあまり詳しくありません) にスキップし、ビットレート (可変) に基づいて経過時間を推定するだけであるということです。 この効果をよく示すには、vlc を実行して最後近くまでシークし、vlc が 43 分を過ぎても再生を続けることを確認します (42:42 でシークを試しましたが、43:08 まで再生されました)。
まとめると、mp3の正確なタイミングを取得するには、vlcまたはのようなプレーヤーに表示されるタイムスタンプを使用するmplayerのは良い選択肢ではないようです。代わりに、次のようなオーディオ編集プログラムを使用できます。audacityは、最初にファイル全体をデコードするので、タイミングは正確になるはずです。もちろん、カット部分にも使用できるので、ffmpegこの場合は最初からまったく必要ありません。